Category Archives: Setbacks

Broken Propellers and Trial by Ordeal

One minor and one major update…

The minor update: a recent pool test showed Poolbot making only starboard turns; this turned out to be due to a broken starboard propeller.

The more significant issue involves ballast.

Both the ComPod and the main body of Poolbot were recently analyzed for displacement and overall ballast neededto dive.  Recall that ComPod has to protrude from the water at least partially in order to allow the XBee inside to communicate with the shore.

Previous displacement checks were done on Poolbot alone, less to get an actual displacement number and more simply to visually check buoyancy, and adjust trim and freeboard in the water.  The ComPod was tested for actual displacement in the kitchen at least once, but using some dificult and questionable methods.  To get a better number, the following extremely high-tech test bed was assembled:

Tank 1
High-Tech Displacement Tank 1

The hard plastic bowl is filled to just before overflowing.  The softer plastic bin will catch the water displaced by the ComPod once it’s inserted into the bowl.  Measure the water in the bin to get displacement.

This measurement went exceptionally well, and resulted in a displacement within about 12 mL of the previous ComPod checks.  The final numbers:

  • ComPod’s volume (displacement): approximately 1470 mL
  • ComPod’s weight: 549 g (including internal electronics)

For neutral buoyancy, the item weight must equal the weight of the volume of water displaced.  As 1 kg of fresh water = 1 L of fresh water (pretty clever that metric system is), ComPod’s required ballast is…  921 g, or 2 lbs, 0.5 oz.

To measure Poolbot’s displacement, aside from the ComPod, is harder.  Poolbot is rather large, requiring a tank at least 25 inches (sorry metric system) long and 11 inches wide, with about the same depth.  Any catch basin must be larger still, to accommodate the overflow without losing any.

tank 2
High-Tech Displacement Tank 2

Thanks to several smaller bins, four plastic bags, and some tape, a reasonable up-scaled version of the previous dunk tank was created; there’s just enough clearance to allow water to overflow straight down into the smaller bins.  The flaw in this design will be obvious from this post-dunking picture.

Tank 3
Post-dunking recovery

Key findings:

  • Use a rigid container, if possible, for the actual dunking.  The soft plastic deformed enough to raise concerns about accuracy.  The strap shown above is wrapped around the bin and several pieces of acrylic plastic and  plywood, to make the sides more stable.  The risk is that the plastic will deform, rather than water overflow, when the object is dunked.
  • Poolbot floats, so is obviously guilty of witchcraft.

Here are the numbers, +/- 100 mL or so for water loss and bin expansion:

  • Poolbot’s volume (displacement, without ComPod): 8050 mL
  • Poolbot’s weight (without ComPod or batteries): 3.6 kg

This means that Poolbot’s ballast must be 4.45 kg, or 9.82 lbs, to compensate for buoyancy.  This number includes all of its current electronics, but does not include batteries.

The challenges that remain:

  • Can the ComPod be kept sufficiently above the waterline to transmit and receive messages?  Or is it time for the extended antenna?
  • If ComPod protrudes enough for XBee communications, are the motors powerful enough to allow for diving without dive planes or some sort of ballast compensation system?

Unfortunately, there’s a third problem lurking, which will be addressed in the next post…

GPS, in the library, with a hammer

The initial motor tests of Poolbot in the pool used an Arduino Uno R3 and the motor shield, and not much else.  The program waited two minutes after the batteries were connected to start the motors in a timed pattern.  No sensors, no I/O, no intelligence.

In order to accommodate additional sensors and features, moving to the Arduino Mega 2560 R3 was needed.  However, the first obstacle was getting the original motor program to work with the new hardware — on first attempt with the Mega, only one motor worked.  Some research and code updates got the Mega to work with the motors.

The next step was to integrate some new components, specifically:

The latter two were tied into Poolbot and its software without a hitch.  Using two of the Mega’s four hardware serial ports enabled direct, fast connections of the XBee and the GPS shield.  While the XBee took some adjustment, it functions.  The GPS shield, however, was flaky in the extreme.  Satellites wouldn’t lock, and data would arrive corrupted.

As it turns out, the GPS shield is physically fine.  After some research, it turns out that the shield’s GPS module, a SkyTraq ST22, has its own nifty configuration software, which can be used with an Arduino Mega configured to echo between serial ports.  Using this showed the Dexter module worked great – the libraries just didn’t function reliably.

Most GPS modules write out information using simple ASCII strings called NMEA codes.  Thanks to a simple program from perceptive coder “Muthanna”, the Mega was able to read incoming GPS data and write it to a laptop screen using a local USB serial port; even when the ComPod was sealed up, Poolbot could even write directly to the SkyTraq viewer software through the USB serial port (some of the GPS information has been blacked out, to avoid revealing the Secret Location of Poolbot’s Development Cabana):

SkyTraq
SkyTraq Reporting from PoolBot

The ST22/SUP500F is a fairly popular module, as a fellow hacker points out.

After writing custom code to pick off the GPS NMEA codes, Poolbot can now (at least on dry land):

  • report its RTC date and time settings
  • establish a serial link with a nearby XBee
  • read GPS data, including date, time, location, and heading
  • read and report internal temperature and humidity information

All this is done through a direct USB link, so in-water testing of all this isn’t yet possible.  The Mega, along with attached sensors, exposed ComPod “guts”, and the separate XBee receiver, is shown below (note the green light showing an active link and receiver signal strength on the XBee labeled “2”; this is connected to a USB cellular charger – no controls here!).

Poolbot improvements
Sensors and Poolbot

Note that ComPod has been moved (more on that in an upcoming post).  Thanks to the SkyTraq software, the GPS module has been configured for “boat” mode, and updates every second.

And here the serial data reported back through the Poolbot USB connection can be seen; all this text is being generated by the Arduino Mega 2560 on-board custom code, developed here at the Poolbot drydock, based on what Poolbot’s sensors report.  The PC is simply a “dumb terminal”:

Poolbot reporting
Poolbot reporting

The GPS doesn’t always report the full set of NMEA codes, due to some faulty string parsing.  This will be fixed shortly.  The other sensors work just fine (the XBee sometimes takes a few seconds to respond, but the code now has a built-in retry mechanism).

The next steps are:

  • Enable reporting of this status data through the remote XBee receiver rather than Poolbot “local” USB
  • Post-process the GPS NMEA codes, checking for signal stability before reporting
  • Reduce the data reported via XBee, and use local Processing code to expand compressed data from Poolbot
  • Increase the serial port speeds
  • Seal everything up and run some water tests, including dives

Slow and steady wins the race…

 

Foiled by Microwave Physics

The good news: API communications between two XBees can be relatively easily set up using an Arduino and the appropriate libraries.

The bad news: 2.4 GHz XBee frequencies don’t travel even six inches through fresh water.  It’s microwave  – this should have been obvious.

The latest test involved using the Arduino XBee libraries available as open-source code, and battery-powered XBee units, with one placed in Poolbot.  A modified example program would transmit regular ASCII “payloads” from inside Poolbot from one XBee; the other was connected to a Sparkfun XBee Explorer USB (plugged directly into an AC wall socket) with an RSSI LED to indicate a working data link.

Sure enough, there was no problem maintaining a data link when Poolbot was sealed with an Arduino-controlled XBee inside on dry land.  But put it into the water and the link died immediately and repeatedly, even though the water was only about six inches deep.

To fix this, the next move is to mount the XBee inside a sealed external box on top of a small PVC pipe connected to Poolbot that will stay above the waterline until diving is needed.  Otherwise, remote mode operations are pretty much impossible.

In related news, 60 mW XBees allow up to 1 mile of separation between modules…

Disaster!

Last night was devoted to creating a “test drive” for Poolbot, to see if (a) the motors worked; (b) the program functioned as expected with the hardware; and (c) if Poolbot would actually drive forward and dive autonomously.

Score: 1 out of 3.  Poolbot never made it to the pool.  Two of the motors wouldn’t turn in “drydock”.  Further tests showed the electronics to be fine; the issue was mechanical.

The motors are “potted” (encased in a filled container) using wax, per the MIT SeaPerch design (check out the handy instruction manual).  This makes disassembly nearly impossible, but if the problem is only “waxy buildup”, melting the wax slightly can get a motor spinning.   A heat gun applied to powered motors allowed one motor to spin freely.  The other is beyond salvage, possibly due to corrosion or melted coil insulation.

Choices: re-pot the working one and use only one dive motor (in other words, rush to test), or get another 12 V motor, and spend a half-day on a sealing process that may still not result in a divable design?  Decisions, decisions…