Wednesday, October 21, 2020

Towing The Line

Someone interested in AMOS recently inquired if it would be possible for it to tow a similar sized (~ 10 kg) boat behind it from one side of a river to the other and back without deviating downstream from the intended path. I responded that it should be possible if the speed of the river were not too great, i.e. too close to (or beyond) the maximum possible speed of AMOS in still water and wind, and that I would attempt a test using the old AMOS surfboard prototype as the vehicle to be towed. 

On Saturday we had a lot of rain (I think around 30 mm) and I didn't want to get wet, so I waited until the following day to do the test. On Sunday it was nice and sunny so I took AMOS down to the river and attached the surfboard base from prototype #2 to the back end and duct-taped a 5 kg weight to the top of the surfboard to simulate a10 kg boat:

Because of the recent rain, the river was very fast. Near the west shore (where AMOS started) it appeared to be ~ 0.5 m/s at the surface, and out in the middle it was more than that (~ 1.1 m/s, see drift calculation below). For some reason, the flow was a bit less on the eastern shore, but probably still ~ 0.3 m/s or so. The photo below shows the intended crossing in yellow, and the actual path in white. On the first attempted crossing from west to east, the battery charge was detected as low (I have been having some problems with the LiFePO4 battery maintaining its charge recently, I think because it has been close to 0 deg C here) so AMOS shut itself down and drifted about 400 m downriver without power for 6 minutes. This would correspond to a surface flow speed of about 400 / 360 = 1.1 m/s, or about 4 km/h, which is too fast for AMOS, especially when trying to tow a second boat. I towed AMOS and the surfboard in my kayak over to the eastern shore, and then let it try to go back west on its own. It was relatively close to the intended course (within 30 m) for about 250 m of westward travel this time, but then the strong current in the middle started to get the better of it, and once again the battery charge got low, so I shut it down and towed it back to the start. 

Some videos of the test were recorded here:

Probably using some water flow velocity sensors would help to keep the boat closer to the intended line, assuming the maximum flow velocity were not too great, but the navigation algorithm would still need to rely on GPS on top of this to make sure that the intended course was being followed. The GPS used in AMOS is a low-cost model, and has a typical accuracy of something like +/- 10 m. High quality handheld units can get down to a couple of meters accuracy I think, and if you want cm-level accuracy you need to use surveyor-type hardware. I'm not sure about the technical feasibility of putting surveyor-type hardware on a robot boat though. 

At any rate, I'm going to re-attempt the straight-line test without the tow vehicle either tomorrow or the following day. The electronic speed controller will be moved back into the battery box for this test, in order to provide a bit of warming for the battery enclosure. It had been moved outside the box, behind the propeller this summer to prevent overheating in the hot summer sun, but that isn't really an issue now near the end of October. 

 Next week I will be presenting an update on AMOS to the Raspberry Pint group via Zoom: @Eventbrite  This is a very tech-savvy group, so will be a good opportunity to get some feedback and tips!

Wednesday, October 14, 2020

I2C Wiring Update

 AMOS was taken out for testing a couple of times this week, but unfortunately there were issues with its performance. It would startup and spin around in a circle, without getting any valid data from the electronic compass. After re-powering, it would cease to work altogether. Some of the re-wiring that I had done the week before to clean things up and get more stable power levels had mistakenly wired the pullup resistors on the A to D converter to +5 V instead of the +3.3 V level that the Raspberry Pi 3B+ computer uses for its logic signals. Also, the compass and realtime clock module were both being powered by the +5V supply line, when in fact they should have been powered by the +3.3 V supply, since the pullup resistors that they have wired directly on their circuit boards were connected directly to the input voltage pins of their respective circuit boards.

Even with the I2C pullups wired to the wrong power supply voltage, it still worked. Or rather, it worked when the propeller was not being used. If the propeller speed was ramped up very quickly, the compass module would often fail catastrophically, requiring nothing less than a full system shutdown and powerup to get it working again. Probably the Pi could usually sink the required amount of current to keep the I2C clock and data lines at the right logic levels, but the added system noise that resulted from quickly turning the propeller to full speed must have created some issues. The initial thinking had been that there was too much noise in the +5 V supply for the I2C devices to function correctly, so I moved the DC-DC converter for generating this voltage closer to the Pi and added a large capacitor (1 mF) between +5 V and GND. It didn't help. After a number of tests, experiments, and hours spent searching the Internet, it slowly dawned on me that the devices should be wired in to the +3.3 V supply instead of the +5 V supply. The one exception to this is the LiDAR module, which still uses +5 V for its power supply, but (when needed) its documentation recommends installing pullup resistors to the logic level voltage, which in this case would be +3.3 V. Because there are already 4 devices with pullups on the same I2C bus though, no pullups for the LiDAR module were required. 

Once everything was correctly wired up to +3.3 V it worked great! I was able to ramp the propeller speed quickly up and down without any catastrophic issues. Occasionally a compass data sample would timeout or be missed, but the device always recovered and kept working without needing to reset things. 

A second significant fix was made this week for backing up and restoring the configuration file that AMOS uses. Sometimes if a user switches off power to the boat while the software is writing to this configuration file, it corrupts the file, leaving it as a zero byte file. This would cause AMOS to crash the next time that it booted up. The solution was to backup the configuration file every time on powerup that it is read successfully, and resort to this backup in the event that the original file gets corrupted. Initial tests seem to indicate that this system works. 

I am looking forward to building the next prototype version of AMOS. Most of the parts for it have been ordered, and I'll pick up some insulation foam sheets from the local hardware store to construct and shape the hull. This time around, I would like to build the hull shape from the glued together insulation sheets, as before, but then use that shape to make a silicone mold for quickly making additional shapes. The additional shapes could be made with a two-part foam mixture, which would cure in the silicone mold and could allow for electronics boxes to be easily inserted into the hull structure while the mixture is curing. 

Tuesday, October 6, 2020

Check the Spam

 I have what might be called an on-again / off-again relationship with my spam folder. Some weeks things are a bit slow and I'll browse it for some cheap amusement to find out what lucrative business opportunities I'm missing, or what strange perversions against human decency I am being blackmailed for. Other times I'll go for weeks without checking it, only to find out that there was actually a valid email in there needing my response. This evening I discovered 3 emails from 8 to 12 days ago requesting my approval and confirmation to be part of a virtual maker fair in Shanghai China, that I had applied to shortly before that ( I did respond to them this evening, so hopefully that will be enough time before the fair starts on October 14. 

This week turned out to be a bit discouraging in terms of development work. I had been trying to 3-D print an enclosure for this solenoid valve: 

which could house a "dry" compartment for electronics, while maintaining a separate enclosure for a water sample of about 200 ml. So far, no combination of solenoid valve, 3-D printed enclosure and other parts and o-rings has been sufficient to keep water out of the dry compartment. And no we're not talking about 100 m of water pressure or anything. We're talking about leaking under kitchen sink pressure conditions. Granted it is a pretty slow leak, but still. I was hoping for better. Some sort of new approach is required for this I think.

On Saturday I took AMOS out to Kelly's Creek for what I hoped would be a long test and leisurely paddle. Nope. A wire got snagged on a stump right at the start and then AMOS made the beeping noise that it makes whenever it reboots. Only it hadn't rebooted properly, and I couldn't get it to startup at all after that. After taking it home and examining it, I was able to fix a wire that had come loose in the battery box. The following day I brought AMOS back to the same spot, but this time it weaved back and forth in a strange manner, as though the compass was not properly calibrated:

The next day I tested the compass out and it seemed fine, but today when I was running the propeller in the backyard, I happened to notice that I was getting a bunch of I2C errors on everything (including the compass) whenever the propeller was run at high speed. The battery box is now a terrible mess of wires and neglect and I really need to clean it up before I can begin to guess at what might be wrong. I was able to nervously open the box with the propeller spinning at max speed and measure the +5 V supply and it seemed OK, but possibly there is a transient problem with the supply when the propeller goes to max speed. Because the I2C problems persist even after the propeller has been stopped. 

Always something to work on!

Wednesday, September 30, 2020

Ocean Startup Challenge Win!

 The pitch in the Ocean Startup Challenge seemed to go OK last week, and fortunately the judges did not ask any really difficult questions. I wasn't expecting to be one of the top 10 companies, but was still kind of eager to find out the results. On Monday evening my phone rang while I was driving into town to pickup Kirsten from cross country practice. I pulled over and took the call, and was quite excited to find out that In Nature Robotics was one of the winners! As I found out just today when the official announcement was made, there were actually 14 winners chosen, so probably good for me that they decided to pick 40% extra! For a video and list of the winners, check out this link: I also did a telephone interview with a fisheries / ocean tech journalist who writes for, so there should be a story about me, In Nature Robotics, and AMOS appearing there soon. (EDIT: Here is the link to the story:

The funding from the contest will be used to build a 4th prototype version of AMOS that will be a hybrid between the previous catamaran and surfboard versions. This time I would like to first make a silicone mold and then try using a two-part foam with that. I would also like to construct it so that the electronics boxes are mostly hidden away within the hull, in order to cut down on wind resistance as much as possible, and make things look a bit neater. I would also like to get some other people using and testing AMOS, to get their feedback and criticisms, and last I'm hoping to do a bit of R&D to work on adding some tech for discrete sample collection and underwater video.

I'll find out more details about the Ocean Startup program and funding next week. In the mean time I'm working on creating a 3D-printed container to house a small solenoid valve. It would be used for collecting physical water samples at different depths. I would like to fit a BLE (Bluetooth Low Energy) module, some batteries, and a microcontroller in there to allow AMOS to communicate with it wirelessly and tell it to open its inlet valve after a certain length of time. Then AMOS could lower the bottle into the water on a rope to the required depth and wait for the valve to open for a few seconds before pulling the bottle up again. A fancier version might also include a pressure sensor to allow the valve to open at a pre-determined depth. 

Tuesday, September 22, 2020

Foggy False Obstacles

This past week has been mostly filled with preparations for my upcoming pitch in the Ocean Startup Challenge this Thursday (the 24th), but I did find a bit of time to get out for a quick test on Monday morning. The air temperature was quite cold that morning (a low of 0 °C the night before) so there was a lot of fog on the water when AMOS was starting out:

Similar to what happened a couple of years ago on a foggy day (although with a different LiDAR model) AMOS was detecting a number of false obstacles due to the laser light from the LiDAR reflecting back from the water vapour. AMOS would turn in place until it found a "fog-free" direction and then proceed for a while before changing direction again. This slowed things down a bit at first, but soon the sun burned the fog away and AMOS sped from one end of Kelly's Creek to the other, a distance of almost 6 km in about 80 minutes:

I had to work pretty hard to tow AMOS back to the van in order to get back home in time for lunch and work at Measurand.

My slides and presentation are ready for the pitch on Thursday, although I'm meeting with some people tomorrow to get their feedback, so they might still need a bit more modification. Anyone who is interested can view the slides and speaking notes here:

Tuesday, September 15, 2020

More Capacitors = More Speed

 Work this week continued on efforts to re-wire the electronic speed controller (ESC) behind the propeller motor. This took way longer than I had planned, and involved swapping out the motor, swapping out the electronic speed controller, re-soldering all of the connections, re-calibrating the ESC, learning what all the ESC beeps meant and modifying the calibration software to be able to adjust all of the parameters according to those beeps. No matter what I tried though, the motor was always very choppy when run at medium to high speed. With nothing left to try, I resorted to Google, which fortunately came up with this web site that had a good discussion about some of the problems that can result with an ESC if your cables delivering DC power from the battery are too long:

By positioning the ESC outside the box and behind the propeller, I had lengthened the cables delivering the 12 VDC power to the ESC by about a foot or so. The problem is not the extra bit of resistance that this adds, but rather the extra inductance that it adds. The inductance results in voltage spikes at the ESC, which can apparently result in erratic performance of the motor. The solution is to add extra capacitance at the ESC to help smooth out the voltage fluctuations. There is already a 30V 220 μF capacitor on the ESC, but the rule of thumb specified in the above website is to add an additional 220 μF capacitor for each additional 10 cm of power wire length. I added three 330 μF capacitors in parallel over the voltage inputs to the ESC. They were only rated for 25 V, but they seemed to improve things quite a bit, and were able to allow the motor to run at a normal speed.  I also tried adding an additional 330 μF capacitor to see if it might allow the speed to increase further, and it did a little bit, although not quite as much as I had hoped. 

So now there is an ugly cluster of capacitors and an ESC mounted behind the propeller. These would need to be weatherproofed with some silicone or other material if used outdoors on a consistent basis. Better positioning of the solar charge controller would also allow me to shorten the wire leads that power the ESC. Really the only reason for positioning the ESC behind the propeller is to keep it cool. Having it inside the electronics enclosure risks having it heat up to 110 °C on hot days, at which point the ESC firmware immediately cuts its output power by 50%. This sort of thing was happening occasionally back in August when the weather was sunny and the outdoor temperature was close to 30 °C.

Cluster of capacitors are shown here circled in red.

On the weekend I took AMOS and its new capacitors downtown for a test run, and was happy that it beat its old record for going up and down the downtown section of river by 5 minutes: from 47 minutes to 42 minutes. The dissolved O2 levels were good too - I guess those are going back up again now that the water is cooling again:

Tuesday, September 8, 2020

Ocean Startup Challenge!

 There was a big announcement today for In Nature Robotics: we were one of 31 companies out of 158 applicants to be picked for the next round of the Ocean Startup Challenge: Starting this Friday, there will be a week of presentations and workshops to get ready for a final pitch presentation, sometime between September 22 and September 24. The 31 companies will be competing for 10 prizes of $25k plus in-kind support. It seems sort of similar to what we went through back in May for the Volta competition; except more of an overall ocean theme. 

I took a couple of days off from AMOS this week to go on a fun family camping trip at Spednic Lake. It would have been nice to try out AMOS there, but the van was packed tightly to the roof with camping supplies, so it wasn't possible. I did manage to get some 3D models of the new WeatherBox put together and tested for water-tightness though. Here is a picture of the component parts (no more little nuts or bolts required!!!) and a picture of the put-together unit (minus the interior locking piece):

The only thing that needs to be modified is that the camera board is recessed a bit too far inside the enclosure, so that you can see tiny smudges of black (from the enclosure) in the corners of the field of view:

(Please ignore the terrible state of this lawn. 😀)

To fix this, I can try to either (i) elevate the level of the camera board inside the enclosure, or (ii) trim down the thickness of the enclosure a bit. 

I have also been working on re-wiring the electronic speed controller (ESC) to situate it behind the propeller. Unfortunately though, I think I may have broken one or more of the wires going into either the ESC or the propeller motor today, as it was functioning sporadically, depending on how I moved the wire around. I'll try a replacement motor tomorrow, and if that doesn't work I'll try replacing the ESC.