Tag Archives: hardware

Motor Calibration and Completed Python Remote

After some weeks of hefty programming (and after being interrupted by having to return to a regular non-robot-related work schedule), a few successes can be noted:

  • Poolbot’s control language now includes status reporting
  • XBee signal strength is back to normal, after re-soldering the antenna to the right contacts this time
  • A Python remote control is now working and can be used to actually drive the robot
  • A motor calibration jig has been built to determine settings vs. actual speeds on each motor

Why calibrate the motors?  Because Poolbot relies on libraries that set motor speed to a value between 0 and 255 (and Poolbot’s language sets that to a percentage), and “127” on the left motor may not give the same speed as “127” on any other motor.  Waxy buildup and motor variations make the speeds hard to predict. 


(the port size float has been removed above, to accommodate the calibration sensor)

The calibration jig simply combines a stopwatch function and a button with an interrupt-based counter.  The interrupt is tripped by a somewhat expensive Omron reflective sensor.  When the propeller passes in front of the sensor (with a white backing taped in-place), it trips and interrupt and adds to the counter.  If the clock is running, RPM values are automatically calculated and displayed.

Counter Closeup

And the controller?  It reports GPS location, signal strength (in dB), current Poolbot mode, and last command sent.  Buttons set whether to enable a particular motor and the direction to use.  Four sliders set the actual speed of each motor, from 0 to 100.    All of this is handled through the XBee link, in real time.  Put the ‘bot in the water, and you can drive it “digitally” until the signal strength goes to zero.

Offline Calibrator

There are actually two controllers, as having sliders for the drive motors is pointless in the water (if the ‘bot makes it below the surface, GPS and XBee signals will be lost, which will translate into a lost robot).

Online Calibrator

All told, the project now features ~1000 lines of C code on Poolbot itself, plus ~300 in the Python remote.  It’s more than likely these can be reduced by careful use of functions, but that can wait.

Next steps: water test,  move to a larger central tube, add new ballast controls, and upgrade the XBees to a longer range using a real external antenna…

Depth Sensor Arrives

good_newsA depth sensor has arrived: a Measurement Specialties 5541C, which should be good to 14 bar (at least 450 feet of depth).  It’s quite simple, featuring 8 solder points, of which only 6 are needed for normal operation.

It uses the Serial Peripheral Interface, though not by name (the documentation merely mentions a “three-wire interface”).  However, a little research  shows that removing the device select wire from standard 4-wire SPI gives you the same connections as the sensor uses.  Like the camera (next post), the sensor operates with a lower supply voltage than the Arduino, so level-shifting is needed.

SPI Connections

This should be relatively easy.  Here’s the hard part:

sensor and scale
Sensor, with scale

Mounting it to a PCB with some sort of 6-pin connector is going to be a major challenge.

Space Available

Selecting batteries or even solidifying the electronics means figuring out the maximum dimensions of any given rectangular shape that will still fit within the tube.  If only the diameter is limited, then a variety of rectangles may fit.  Time to pull out some geometry…

Geometry calculation

Thanks to a particularly good website for batteries, a complete set of dimensions for a variety of batteries is available.  The equation above can show whether a particular battery will fit in the tube or not, based on its width and length (assuming “depth” extends along the tube’s axis). Performing some calculations with the existing central tube, electronics and two batteries, some options emerge:

  • using an alternative 12 V battery, at 3.8 Ah, measuring 7.6″ x. 2.8″ x 1.85″
  • stacking the electronics within a 5″ x 2.25″ area gives 2.68″ of available height for both the electronics and ballast (not much, but usable) 
tube sizing
Tube size calculations

Motor load measurements are still needed to confirm that 3.8 Ah is sufficient for propulsion.  The Arduino Mega and Motor Shield fit within an area 5″ x 2.25″, but the connectors and DHT11 sensor need to be cleverly stacked on top.  And 2.5 lbs of ballast needs to fit under the electronics within about 2.28″ of space, total.  

It’s either this or recalculating displacement using a longer tube, plus actually building it.

Current Affairs

What’s Poolbot’s maximum operating time in-water before needing to recharge? 

The motors are tied to two (2) 6 V, 4.5 Ah batteries.  It would be convenient to use the same kind of supply for the electronics, but it depends on the current drawn.   For the electronics alone (not the motors), a quick set of measurements reveals some unfortunate numbers:

  • the Arduino Mega 2560 R3 alone draws a reasonable 70 mA, which would allow at least 70 hours of operation (assuming correct reading of the capacity charts) before needing a recharge
  • the GPS and XBee (1 mW) draw only about 7 mA
  • the current draw by the motor shield is a less reasonable 200 mA

At 277 mA, Poolbot will need a recharge after only about 17 hours of operation.  It’s also not known how long the 12 V solar panel will take to recharge the battery packs.  If it takes more than 7 hours, or if there’s less than full sunlight, Poolbot may need significant “basking”/sleeping time between operations.  This assumes that the electronics can be  effectively turned off, and doesn’t even count needing to charge the motor batteries.  What happens if Poolbot drifts while charging?

There’s another issue.  There’s no room left inside Poolbot for all the new electronics, ballast, and four 6 V batteries.  With two batteries for the motors, at 1.75 lbs of weight per battery, about 6.5 lbs of ballast and electronics battery weight remains to maintain Poolbot’s neutral buoyancy (see previous post). 

Using a single 6 V battery to power the Arduino Mega and its accompanying electronics is a bad idea; below 7 V, the Arduino’s on-board regulator won’t work well and operation will become unstable.  So, either a single 12 V battery with the right dimensions and similar Ah figure must be used (good luck) or some significant filtering must be used on a single supply for both the motors and the electronics. 

Bad choices all around…

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…

Designs Today and Tomorrow

The latest Poolbot program updates have enabled XBee transmission of arbitrary strings up to the 100 byte payload limit.  In drydock, the Arduino is connected via USB to a PC, used as a “dumb terminal”; the Arduino is doing all the display work, and the XBees operate in a simple loop confirming that a communications link exists. 

The next steps are to move all the serial link data processing from the Arduino Mega 2560 to a PC.  The Arduino can then transmit compressed sensor data via XBee payloads, and let the PC locally decompress the payload and print the information in a human-readable format.  Remote control of the motors becomes possible.

Pictures sometimes explain better than words, so here’s the design today, and what’s planned for the future.

Today’s Poolbot design