This weekend I tried out a plywood mold and two-part foam for building AMOS hulls. Everything went well for a while: I had the shed / playhouse heated at the right temperature (about 25 deg C), and got 5 or 6 batches of the foam properly mixed and poured into the mold. The foam expanded similar to what I had seen on the Internet beforehand, and there seemed to be a sufficient number of vent holes to relieve pressure from the expanding foam. Then I tried to take the mold apart. The interior had been lined with plastic wrap, in order to prevent the foam from sticking to the wood. Except it didn't work. The foam somehow tended to get underneath the wrap, and in some cases seemed to melt it and mix with it. I tried to hack and cut away at the wooden exterior of the mold, but only succeeded in breaking everything, including the foam pontoons. Here are some pics of the carnage:
Tuesday, November 17, 2020
Tuesday, November 10, 2020
Later that day Lawrence and I drove to Whycocomagh in Cape Breton where we had rented a cottage on the shore of the Bras d'Or Lake. Here was our view from the front porch the next morning:
After the demo, Lawrence and I went out with Bruce and Allison and Piotr to check out a 50 m "Death Hole" with a couple of ROVs. This hole featured a mysterious layer of floating material about 16 m deep that both ROVs were able to examine with their camera systems. Allison and Piotr's ROV collected water samples for their lab at Dalhousie University using a very cool apparatus of spring actuated syringes. Bruce's ROV collected a smelly, dark sample of mud from the bottom of the hole:
On the return trip back to Dartmouth, Lawrence and I stopped near Antigonish to try collecting some data in Pomquet Cove. The wind here proved to be a bit too much for AMOS, so we tried a stream on the other side of the highway instead:
The water in the stream was a bit mucky and shallow in some areas, and required a few minutes of manually controlling AMOS to get it unstuck and drive it back to a location where it could be easily retrieved.
- More power, need a larger propeller, larger motor, and larger / more batteries.
- More streamlined and durable construction.
- More accurate positioning (i.e. requires a GNSS system).
- Need to have ability to reverse direction of propeller for backing out of tight spots.
- Software improvements for defining survey grids, saving / loading standard GPS coordinate file formats.
Thursday, October 29, 2020
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!):
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:
Wednesday, October 21, 2020
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: 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!
Wednesday, October 14, 2020
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
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!
Wednesday, September 30, 2020
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: https://www.oceanstartupchallenge.ca/announcements/. I also did a telephone interview with a fisheries / ocean tech journalist who writes for https://www.saltwire.com/, so there should be a story about me, In Nature Robotics, and AMOS appearing there soon. (EDIT: Here is the link to the story: https://www.saltwire.com/business/local-business/video-cod-collagen-project-and-a-boat-called-amos-east-coast-entrepreneurs-among-winners-of-ocean-startup-challenge-504940/)
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.