An Interruption Most Rude

 On Tuesday evening I was speaking about AMOS (over Zoom) to the Raspberry Pint group in London, England. It was supposed to be an update of the last 9 months of development work since I had presented to them previously back in January. I started off with a recap of the reason and history behind AMOS, and then got into the details of the recent improvements on the AMOSRemote wireless transceiver, the AMOS-IMU electronic compass, and then... my screen turned red. Entirely red. I was able to press the ESC key to view windows in the background, but the PowerPoint was still red. We decided that I should try to stop sharing, and then try re-sharing to get it going again. I clicked the 'Stop Share' button, and that's when the stream of porn and loud music started. The presentation had apparently been hacked by someone. A couple of the guys tried some things to resume control with unsatisfactory results, but then had a pretty clever idea: ask everyone to turn on their video. Anyone who didn't comply would be booted out of the presentation. I think this resulted in a few people needing to leave who didn't have working cameras, but the intruder must have also left, because I was free to continue my presentation after that. The "intermission" had been about 10 minutes, and I felt a bit weird for a few minutes after that, but I was able to finish without incident and answer the questions from the audience afterward. Hopefully it will be possible to splice together a video of my presentation at some point. Until then y    (Edit: Richard Kirby at Raspberry Pint has already edited the video: https://www.youtube.com/watch?v=yHVf25cZ-AI&fbclid=IwAR2EUiuZ1--wo5dYfUvKESNI-UL03GPUu0JSVwXt4maH_EfZ_fMTm4NZLsI  )You can see the PPT slides here (guaranteed to be family friendly!): 

 https://drive.google.com/drive/u/0/folders/12L3EXMMcrxIQD2Ic7eXweo_RAyHzjQuS

This week has been fairly busy with meetings, but there has been a bit of time to work on the creation of a mold for constructing AMOS hulls out of two-part foam: 

The idea is to make a mold that will be lined with saran wrap and filled with a two-part foam mix that expands very quickly to make a foam with a density of ~ 2 lbs / cubic foot. Once finished, the mold will be in a shape that is a mix of the catamaran and surfboard prototypes. The hope is that it will be possible to enclose the electronics boxes (or wooden blocks of the same size) within the hull while the foam is curing. There will need to be some vent holes too, to prevent the pressure of the expansion from breaking the mold or the boxes. 

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:

https://drive.google.com/drive/u/0/folders/1yRDRWJ9n-_gsIMj5ravp85tAzXxHyVYP

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: https://www.eventbrite.com/e/raspberry-pintdigital-making-fun-with-raspberry-piarduino-esp32-etc-tickets-124921590841?utm-medium=discovery&utm-campaign=social&utm-content=attendeeshare&aff=estw&utm-source=tw&utm-term=listing @Eventbrite  This is a very tech-savvy group, so will be a good opportunity to get some feedback and tips!

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. 

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 (http://www.makercarnival.org/). 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!