Sensor Deployment Arm

An armature for deploying sensor probes into the water was added to AMOS this week. It was basically the simplest design that I could think of; a lever arm connected to a servo motor that swings back and forth with the sensor probe cables attached to it. When swung toward the water, it pulls the probes into the water to deploy them. When swung back in the opposite direction, it pulls the probes back onto the stern deck.The probes are not overly heavy so I didn't bother with any strain relief for the electrical cables. My home-made turbidity probe is possibly a bit too buoyant, so I may need to add a bit of mass to it.

Here is a video of the armature in action in our pool today:

The first time I tried it out in the pool a couple of days ago, I noticed that the turbidity probe output changed drastically by almost 50% after a few minutes of being deployed in the water, and that the probe had settled lower down into the water. Unfortunately the enclosure had flooded with water. After taking it out, emptying out the water, and studying it for a bit, the most obvious source of water intrusion were a pair of fastenings on the underside of the shell. Here is a photo of one of the fastenings:

I built the turbidity shell last year, and I think I must have been planning on filling the holes with some molten 3D printer filament, but never got around to it. So last night I held the probe upside-down under my 3D printer nozzle, turned on the heat, and then manually fed the printer filament through the nozzle so that it dripped down into the hole, filling it up completely. I then smoothed it out later with a heat gun and my finger (hot ouch!).

The blue printer filament sort of looks like a wad of gum. I'm hoping it will be more water-tight than that though. Tomorrow I'll let it sit in the pool for a while to see what happens. If it doesn't work, I'll try 3D printing a new shell without through holes for the fastenings.

Showing AMOS Around Town

This past week was a busy one for AMOS. In preparation for the Fredericton e-Hack event on Monday, I spent some time looking up info on LoRaWAN wireless radio kits and map-based GIS (Geographic Information Systems). Here is a link to a map that I made from the Woolastook grid test: https://arcg.is/01C8Gu.

On Saturday, the sun was bright and shining, and I took AMOS back to the same parking lot near the walking bridge, this time just going directly downriver to collect some temperature samples around the mouth of the Nashwaak River. I was able to try out my new $20 anemometer, which told me that the wind was coming out of the north at ~ 15 km/hr on average, with occasional gusts close to 30 km/hr. The current also seemed pretty strong with a lot of waves. AMOS was still able to make forward progress (albeit slow) against the current and wind when it needed to. Unfortunately, the temperature probe did not work for this test, I think because I had melted part of the probe cable's insulation with a soldering iron the night before. It didn't look like the damage was too bad, but I'm guessing that water must have leaked in, because after AMOS got back home and dried out the probe worked fine. Anyway, I made a cool GIS graph with the temperature from inside the electronics enclosure instead:

On Sunday, I took AMOS to the Fredericton e-Hack event at Planet Hatch. Eleven-X and some other organizations were there as sponsors, and LoRaWAN radio kits were distributed to the participants. There were quite a few people there, and most of them went to the event as teams. Anyone at the event could pitch an idea to the assembly of people and then the top 6 ideas were chosen based on a voting system. I pitched the idea of AMOS, along with a simplified version of AMOS connected to a buoy or retrofitted to a boat. I think about 10 people in total pitched ideas, and AMOS barely made it in at 6th place. Then teams were formed for the 6 ideas, and we got to work trying to figure out the wireless kits and get some sort of rough prototype and presentation together. Here's a selfie of team AMOS:

 Unfortunately, nobody was able to get their LoRaWAN wireless kit working. That was the part that I was looking forward to hacking, so that was a bit of a disappointment. We spent the remainder of the time trying to throw together a PowerPoint for the final presentation. As my children will tell you, my PowerPoint skills are very poor, so the presentation didn't look as good as those of other teams, but I thought that the actual content was OK. We didn't place in the top 3, so no prizes were won. :-( However, we did get to meet Mike O'Brien, the mayor of Fredericton and spent a few minutes talking to him about AMOS. I also spoke briefly with a CBC reporter, but so far I haven't been able to find any footage of that.

Today I attended the Canadian Export Challenge at the convention center in Fredericton. There were probably a couple hundred people at this one, and I recognized a lot of the same people from the e-Hack event there. You could do a one minute pitch at this event, and the top 20 pitches were selected to go on to the second of three rounds. AMOS didn't get to the next round, but I did get some useful tips about shipping and exporting, such as: try to get the size of AMOS (and its packaging) down to less than 8 feet long, since that is the standard maximum length that most shippers will handle before things get much more difficult. It was also interesting to hear the stories and advice that the panelists had, and meet some of the other attendees.

Tomorrow I'm looking forward to a return to hardware development. I want to get a deployment arm mechanism in place at the back of the boat for deploying sensors into and out of the water.

Sensor Grid Trials

AMOS has been programmed to accept a pair of diagonally opposing GPS coordinates that define a rectangular area for collecting sensor data. It also requires the user to specify how many stops to make in the N-S direction over the grid, and how many stops to make in the E-W direction over the grid, and how many samples to collect at each stop. For example, the following script command:

grid_sample: 45.878336, -66.909070, 45.876592, -66.906151, 5, 5, 10

tells AMOS to make 25 stops (5 in the N-S direction by 5 in the E-W direction) down to the opposite corner at 45.876592, -66.906151. Here is what it looked like with the path to and from and all the sampling stops drawn on a Google Earth view:

The whole thing took a little over an hour to complete, and since the day was overcast and a bit rainy, the battery was nearly fully depleted. I had hoped that the water closer to the inlet of the small cove would be warmer and would make for a nice color map, but alas no. The water temperature was quite uniform throughout, either 14.06, 14.12, or 14.19 deg C everywhere. I don't have the turbidity or pH probes hooked up yet; I'm waiting until I finish building a mechanism for deploying them into the water so that they don't create excess drag when moving around. Here is a graphical representation of the temperatures collected, expressed as a bubble chart in Excel:

Today I tried to repeat the sensor grid test at a location more likely to show some sort of temperature gradient. The goal was to launch AMOS from a parking lot about 1 km north of where the Nashwaaksis River empties into the St. John River. I set up the GPS waypoints in a script file the night before with the intention that AMOS would first travel west about 100 m into the St. John River, then 1 km south where it would do two separate grid patterns around the end of the Nashwaaksis River. Both the wind and the current seemed really strong this morning, with the current running from north to south and the wind probably in excess of 30 km/hour (Andrew, I just bought an anemometer from Amazon so should have better data on that soon!) coming from the northwest. Poor AMOS didn't stand a chance. It struggled gamely for a little over an hour, before its battery quit and the wind quickly pushed it back to shore. I probably should have edited the script to just skip the first waypoint and proceed south instead but part of me kind of enjoyed standing there watching it struggle. At one point when the wind died down a bit it looked like it would almost make it, but in reality it was still pretty far off:

As this is a more populous spot than my usual Woolastook testing ground, there were a few curious onlookers that asked questions about it. Next time I'll have to bring my wallet with its home-made business cards 😃.

I really like the name AMOS, but I'm thinking of changing what the acronym stands for. Instead of "Autonomous Mini Ocean Surveyor", I'm thinking that "Acquatic Mini Observation System" might be more accurate, as it is not really an oceangoing vessel, unless perhaps you're talking about using it in the doldrums around the equator.

It turns out that I was not properly using the real-time clock that I had hooked up to AMOS a couple of months ago. It needed this line at the start of the /etc/rc.local file:

sudo hwclock -s

I had noticed that the ship log times were always wrong after a cold boot in the field without any available Internet, and that missing line was the reason why. AMOS might take a while to reach its destination against a stiff breeze, but at least it now knows exactly how late it is.

Sunny vs. Cloudy

A few things were accomplished this past week. Firstly, AMOS set a couple of new single-outing distance records. On May 23, it traveled 5.35 km in 1 hour and 12 minutes, going back and forth on my usual Woolastook GPS course:

The day started off well weather-wise, but quickly became overcast, and at the 1 hour 12 minute mark, the battery gave out. I'm not certain that it was completely charged prior to the test though.

Today the weather was nice and sunny, and AMOS got a new distance record of 6.12 km on the same course, before I noticed that the screws were loose on the propeller mount causing it to bang around like crazy inside the cage. I'll need to find a more secure way of fastening the screws; perhaps use Loctite or something. For this second test, AMOS was a bit slower; possibly because the weather was a bit windier, but also because I had accidentally sheared off a plastic clip on the side of the boat when loading it into the van, causing a long plastic piece of conduit holding some wires to periodically dip into the water, producing drag. It was encouraging to notice after this second test that the battery voltage (when not running) was the same 13.2 V that it was before the test. Since voltage was recorded every minute in the ship log, I was able to plot a comparison of the voltage levels for the cloudy vs. sunny tests:

As can be seen from the above graph, the fall-off in voltage under high load can be pretty steep if the sun isn't around to keep the battery charged up. At present the software in AMOS is not making any decisions based on voltage, but probably there should be something to put the boat into a low-power state once the voltage gets down to ~ 11 V.

The other big accomplishment this week was that I finally got serial wireless communications from the Android phone (or PC) to Bluetooth (or a USB serial cable) to the RFU220 transmitter to AMOS and back again working much faster, so that it is now actually feasible to download a small image file from the boat. This actually required a few weeks to get right, and up until a few days ago I was semi-convinced that there must have been serious hardware problems impeding correct communications. But the issues were all software. Once the timeouts, flushing, buffering, etc. were finally set properly it just worked. 😸

Edit: Here are the pictures of the screws (indicated by thin red arrows) that came loose:

The stainless steel M3 screw in the top picture is used to hold down the arm mechanism for the servo motor that controls the direction of the propeller. When I noticed that the two black screws were loose (lower picture) there were no screws whatsoever in the other two holes on the same mounting plate. I don't remember if I forgot to screw them in, or more likely they vibrated out at some point and were forever lost. So I'm using a couple of stainless screws now in those holes instead.

Minus One Box

The last week was mostly spent on modifying AMOS to have a lower profile in the water, so that it is not as strongly affected by high winds. This was done by moving the electronics from the 3rd largest box into the 2nd box which was only about half full and had some room to spare. Work was also done to move the power switch from the top of the 2nd box to the side, and to re-wire it to make use of a waterproof gland. After having rain nearly every day this week, I can say with some confidence that the new switch design is waterproof. The old design was not, and I think the box would have been half-full of water if the old switch were still in place.

I traced around the two electronics boxes with a sharpie and then used a drill to cut out a rectangular portion of the fibreglass shell. Then it was a time consuming, mind numbing chore to dig out the pink foam insulation 1 cubic centimeter at a time with a pair of large pliers.  Here is a picture of the half-finished work:

I basically just dug down to the depth of the bottom layer of pink insulation. This bottom layer was quite thin at either end of the boat where the boxes were located, since that was where the surfboard shape started to taper.

Here is the finished result, as seen in our pool at night:

The yellow stuff in front of the box is globs of old glue that were used to hold the box to the board in its former location. The box had to be moved back a bit from the front to an area where the board was thicker.

I have avoided going out for a field trial the past few days due to poor weather, and decided to focus instead on trying to solve some strange communications problems with the Android phone to transmitter box to boat link. Sending and receiving of short commands less than about 100 bytes work great, but trying to send and receive larger things such as image files has proven more challenging. For some reason that I haven't been able to figure out, bytes are getting periodically garbled and I'm not sure why. I use sync bytes, checksums and a sort of packet re-try system which gets the data to arrive eventually, but it's painfully slow. I thought I had it for sure tonight when I discovered that the 3 AA alkaline batteries in the transmitter were down to about 1.25 V each, but that wasn't it at all. Brand new batteries worked exactly the same. I also thought I would fix it by changing from 115200 bps to 9600 bps, but that didn't help at all either. Sometime later I'll try using a PC to transmitter to boat link to see if that works any differently (i.e. bypass the Bluetooth link to see if that helps).

Battle Against The Wind

Yesterday, I brought AMOS back to Woolastook for another test run. Wires and batteries had been moved out of the immediate vicinity of the electronic compass, and some of the control parameters in the software had been tweaked a bit, in the hope that AMOS would more consistently travel in a straight line. Also, I had modified the mounting of the air propeller assembly slightly to help avoid a problem with it sometimes flying off the shaft of the servo motor in high winds. I was optimistic that things would go well...

So I was naturally disappointed when AMOS took off for its destination and promptly ran into the east bank of the inlet. I got in the kayak, paddled a few meters, and then freed it from the grass (more work is required for AMOS to do this by itself). Then AMOS went off in the opposite direction, this time getting stuck on the west bank. I paddled over to free it again, then brought it to shore and connected it to my laptop to check the ship logs to see what might have gone wrong. The logs revealed that AMOS required a long time to get a valid GPS fix, and even when it did get a fix, the initial GPS coordinates were off by quite a lot. For example:

in the above photo the actual GPS track that AMOS thought it was following is given by the thin blue line in the lower-left corner. Although it actually started at the base of the inlet, it thought it was starting about 10 m west of Route 102, and therefore plotted the first interpolated GPS coordinate at a point just west of Route 102. Later, it acquired an accurate GPS position, but by that time it was already headed for an incorrect destination, and kept ramming itself into the west bank accordingly.

After checking the ship logs, the test was repeated, this time with the following result:

This time the interpolated points were plotted correctly, but the GPS location of AMOS seemed to usually be biased about 10 m to the south of where it should have been. So this time AMOS kept crashing repeatedly into the eastern shore. Plotting more frequent GPS waypoints in the center of the inlet probably would have worked a lot better.

At this point, I gave up on the planned GPS course and just tried piloting AMOS around manually. This proved to be more challenging than I expected. I had thought that I would be able to find an azimuth angle for the ship's propeller that would allow AMOS to proceed in a nice straight line, but there was a relatively strong wind coming out of the east that day, with gusts that were probably in excess of 30 km/hour. The gusting wind required constant attention to the azimuth angle of the propeller, and more often than not I would get it wrong, so that AMOS ended up making a lot of circles out in the open water. Eventually, I gave up and just set the angle of the propeller to the zero degree position and observed what kind of a path the boat followed:

The gusting wind proved to be a bit much for AMOS, especially when the boat was headed directly into it. A quick calculation after I got back confirmed that the wind was probably about 30 km/hour:

Assume that the surface area of the boxes and board that are facing into the wind is ~ 0.1 m^2., air density is 1.2 km/m^3, and the wind speed was 30 km/hour or 8.3 m/s:

Force =  0.5 * 1.2km/m^3 * (8.3 m/s)^2 * 0.1 m^2 = 4.1 N = 0.9 lbs.

This wind force is quite close to the maximum thrust of the air propeller on AMOS (~ 1 lb), hence the reason why AMOS appeared to be stalled in the water when the wind picked up.

There are a few ways to combat this wind effect:

1) Reduce the cross-sectional area of material that is facing into the wind.
2) Change the shape of the boxes on AMOS to make them more streamlined, so that the wind flow does not separate as much when it hits them.
3) Increase the thrust of the air propeller, either by upping the pulse frequency on the current setup or by getting a new (larger) propeller and motor altogether. This latter option might also require a beefier battery pack, and a more robust protective cage. I have already had to glue together the existing 3-D printed cage numerous times to repair it after crashes with brush and other shore obstacles.

First I'm going to try #1 above by getting rid of the 3rd largest box (it's almost empty now anyway) and mounting the propeller on the 2nd box instead. The two remaining boxes will then be embedded about 4 or 5 cm into the foam of AMOS. This should hopefully reduce the cross-sectional area down from about 0.1 m^2 to something like about 0.07 m^2. I should also be able to increase the thrust on the current propeller / motor a little bit without too much difficulty or worry of things overheating or drawing too much current. Since the wind force scales as velocity squared though, this would probably only get me up to about 45 km/hour. Perhaps some smart software could be added to drive AMOS at an angle to the wind (say 45 degrees) which could in theory maybe allow for forward progress in winds up to about 60 km/hour. Maybe some future version could also use flatter waterproof boxes so as to get the cross-sectional area down even more.

Big Logs and Big Magnets

There was still a thin skim of ice over part of the head pond at Woolastook last week when I took AMOS out for a test run. The test started off poorly, with AMOS spinning around in a number of crazy circles, before the screws holding the propeller to the servo motor loosened and the propeller pitched forward onto the deck of the boat. Unfortunately I didn't have any Allen keys with me to tighten the screws, so the testing for that day pretty much had to end there.

The spinning in circles was a problem, and testing the compass output the next day revealed that the LiDAR module was no longer working and was drawing an inordinate amount of current. This current passed through a wire which happened to be in close proximity to the electronic compass, causing a great deal of noise and interference in its magnetic heading output. Opening up the LiDAR electronics enclosure revealed that some water must have gotten into it at some point, as many of the circuit components on the lower half of the board were badly corroded. Its enclosure is supposed to be IP65, so I had hoped it would do better than that if left in the rain or splashed occasionally by waves. So I guess I'll need a new LiDAR module at some point. I'm planning to upgrade to this one: https://www.robotshop.com/ca/en/lidar-lite-3-laser-rangefinder-high-performance-llv3hp.html I think since it is IPX7 rated, capable of being dunked in 1 m of water, able to communicate over I2C, and also draws less than half the current than the previous model I was using. It would also free up a serial port on the Pi for some other (TBD) purpose.

Thinking that the magnetic heading issues had been completely solved, I returned to Woolastook the next day to repeat the test. AMOS fared better this time, but still weaved badly back and forth. Some simple tweaking of the control parameters were able to mostly fix this, but when travelling in certain directions it still tended to weave back and forth quite badly. Also, there was a large amount of floating debris in the pond that day, probably from all the recent flooding the St. John River has seen lately. A couple of times, AMOS got badly slowed down after driving over (and trapping) large logs:

Here is a video showing AMOS take off in a nice straight line:

This version of AMOS moves a bit faster than its beer cooler predecessor and it does so using considerably less forward thrust (about 1 pound vs. almost 10 pounds for the beer cooler version). It is able to do this because of its shallow draught and more hydrodynamic shape.

More testing of the electronic compass today demonstrated that the Lithium ion CR2032 battery used to power the real time clock was fairly magnetic, and since it was nearby the compass was also interfering with the heading output. So I re-wired the compass module to be further away from everything, in its own corner of the front enclosure. An initial garage test seemed to indicate that it was working reasonably well, giving headings that were probably accurate to within about +/- 20 degrees. Some further tweaking of the control parameters will probably also be required, but hopefully I should be able to get this version of AMOS to move consistently in nice straight lines soon.