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.

The Cost of Building AMOS

The past couple of days were a bit of a mad scramble to search through old receipts from 2018 and figure out how much I owed our government in taxes. In doing so, I found out that almost $5000 was spent on hardware expenditures for AMOS. Of this amount, probably less than $2000 was for parts that are currently being used on the second surfboard prototype. Some electronic circuit boards got fried, some things such as the water propellers and kayak beer cooler are no longer used, and some of the $5000 was for items such as a 3D printer and other smaller tools that were necessary for building and repairing various things. Of course the much larger cost associated with this project was the large amount of time spent, and the opportunity cost of not working at a paying job full-time.

Today was a small breakthrough software-wise, as I was able to finally fix some issues with the Bluetooth Low Energy (BLE) communications between the Android app and the battery powered wireless transmitter. The communications had generally worked well for sending small packets of information, ex: commands for steering or propelling AMOS forward, but tended to fail quite often when sending larger amounts of information, such as for transmitting image data. BLE splits up communications into packets of about 20 bytes or less, which complicates things somewhat. Also, the closer you get to the minimum wireless power level, the more inconsistent the communications get, with timeouts and garbled data becoming more frequent. Since the serial wireless link I am using for long range communications (the RF220SU) does not have a particularly robust hardware layer for dealing with errors, I ended up having to do it myself in software. Non-essential small packets are still sent as they were before, with just some basic identification bytes and a few bytes of actual data. For larger amounts of data, I created a packet structure that had some header bytes to identify the packet and indicate how much data was to follow, and then included a couple of checksum bytes at the end. A basic handshaking protocol was also used to acknowledge the receipt of each packet sent. And then a series of retries and timeouts was used to help ensure that the data arrived. Once all the glitches were solved (and there were quite a few of those) it seemed to work pretty well.

Security Breach

On the evening of April 15 I unwittingly made a blunder in uploading a configuration file that contained some texting and email credentials to a site for storing source code (GitHub). To its credit, GitHub promptly emailed me a warning message to alert me that I was "sharing too much". But I had left the computer to go eat some supper and do other things, and didn't return until about 3 hours later. At that time, I discovered that the account password used to allow AMOS to send text messages had been changed, and there were notifications of hundreds of errors in my inbox, relating to this texting account. This was not good. In order to remove any trace of the file online, I removed the entire GitHub repository. I then contacted the texting service company to alert them that my account had been compromised. They gave me some instructions to follow in order to change my credentials, but the account had already been associated with a new email address, so I was unable to do that (the file shared on GitHub also had email credentials, so they must have used my Gmail address and password to read my Gmail, and thereby change the texting account info). I informed the texting service of that and requested that they freeze my account if possible.

The account was frozen, but not before $170 of texting charges had been racked up. More back and forth with the texting provider got my account set back up properly though, and thankfully no more charges have been incurred. I also changed my Gmail password of course, and many of my other passwords too, just as a precaution, in case they also might have been accessible through Gmail. I had a look at one of the phony messages and it was in French, and I think it was one of those: "Something bad has happened to your account, please click this link: .....   to fix the problem." messages. So to the thousands of people that received these, please accept my sincere apologies.

I have since enabled two-factor authentication for my texting account and will also make sure any other passwords stored in configuration files are encrypted. Nothing beats learning the hard way eh?

Living The Dream

Some days living the dream is harder than others. Today was one of those days. Work on AMOS was delayed for about an hour this morning due to a clogged kitchen sink. I tried using a plunger, sucking the drain with a shop vac, and poking around with a long piece of plastic, to no avail. The smell of the water that came out had a disgusting fishy odor, but whatever solid material was in there was not budging. While doing this, Kirsten was in a minor panic before her math test, and was texting every few minutes for advice on how to solve a couple of problems.

After giving up on the sink, I continued adding some code to the iOS version of Boat Captain for Bluetooth Low Energy (BLE) communications with the AMOS remote controller. Here's a picture of the remote controller inside a waterproof Pelican case:

Some of the wires in there have pins on both ends and are intended for prototyping boards. The problem though is that sometimes the crimped connections to these pins fail (especially when you cram the wires into little boxes). I wasted 2 hours on Friday trying to figure out why some new software changes were not working; only to discover that a broken wire in the remote controller box was to blame.

After the morning sun had charged AMOS up a bit, I took the Android phone, the remote controller box, and AMOS and headed over to the beaver pond across the road. Normally the area of the pond near the road is overgrown with grass and vegetation, but at this time of year, there is a nice bit of water there, with a substantial layer of ice a couple of inches below the surface.

Here was the launching point for AMOS:

The moment the propeller was turned on, I heard a loud honking coming from nearby:

It was a large goose, and he (or she) did not seem pleased to have AMOS motoring around on its turf. It did eventually stop honking, but remained standing nearby for at least half an hour. Driving AMOS around in this location was pretty tricky. There were a lot of ice patches, tufts of grass, and a high amount of wind. AMOS seemed a bit under-powered. Maybe a beefier motor and propeller would help things a bit. Possibly it would have been easier to steer if the phone acted as a tilt controller, instead of using regular push buttons, ex: tilt forward to go forward, tilt left to turn left, etc. Eventually AMOS ran aground on an ice patch, so I just left it there to grab some lunch and then ran to Measurand.

After supper, I returned to the pond to find that AMOS was still in the same spot, but the ice had risen up under it. Of course it was still impossible to get AMOS moving off the ice on its own power, but an attempt to do so attracted the attention of a curious beaver who poked his head up a couple of times to have a look.

Fearful of what might happen to AMOS overnight if I left it with the geese and beavers, I went back home to fetch the kayak. With a bit of effort, I was able to slowly paddle and pole the necessary 100 feet or so to retrieve it and bring it back to our backyard. 

I spent the remainder of today ramming a plumber's snake down our kitchen drain, without any luck. Still clogged, so I guess we will have to call a plumber. Kirsten said she aced her math test though, so at least there's that! 😸

3D Printing Level Up

I have been 3D printing things for about a year now, but it was only this past week that I finally figured out how to prevent molten plastic from pooling on the heating block and dropping onto my prints, sometimes ruining them. The key was to properly install the guide tube and extruder tip, and take care to make sure that they were tightly butted up against one another. To do this, the extruder tip was first tightened into the heating block, and then backed off a couple of turns. Then the guide tube was screwed into the other end as far as possible. The extruder tip was screwed back in and tightened as much as possible against the guide tube above it. This was all done (carefully!) with the printer's pre-heating routine on, in order to match actual printing conditions. I got all this from a website, which unfortunately I can't remember or seem to find now. I've searched the Internet about this particular problem before, but only this site offered a logical solution to the problem that actually worked.

I was able to print a nice enclosure for the camera that should actually be waterproof now. Here it is on top of the new enclosure that I spent the last 2 days getting ready so that it could replace the one that I accidentally melted last week:

I also cleaned up the wires a bit on this side of the boat. Previously they were just loose, single insulated cables crammed into a cable gland on the enclosure. The white cable above is a piece of Ethernet cable that now does the same thing with a bunch of extra wires for future functionality. I also routed this cable and others on the opposite side of the boat in some plastic hot water heater tubing in order to avoid getting it snagged. I'll need to get some pieces to secure this tubing onto the sides of the boat at some point.

A bit of software was completed this week too - the Android Boat Captain software was modified to request lower quality images when a Bluetooth connection was used, and work was begun on the iOS version of Boat Captain.

Making and Breaking

Things are finally starting to warm up around here. If we can get a few days in a row of warm temperatures, I think I'll be able to take AMOS across the road to the stream and beaver pond for a field test. First though I'll need to finish some repairs for a couple of minor mishaps that took place recently.

Thankfully I was able to sort out the remaining Bluetooth Low Energy issues for the Android version of the Boat Captain software. It now can send and receive data and download images from AMOS. I needed to lower the quality of the jpeg pictures though to allow them to download in a semi-reasonable length of time. Next up will be the iOS version. In testing things out though, I happened to notice that the stem of the camera housing had snapped off, near where it entered the front electronics enclosure. The stem was a 3-D printed part, and the interior of it was only partially solid, with a sort of honey-comb-like structure for half of its wall thickness. I suspect this camera housing was not quite water-proof anyway, so this became a good opportunity to re-design it into something smaller, lighter, and more water-proof.

Here is the result after a few 3-D print attempts:

It was a bit smaller than the old one, and the screw holes for the Plexiglas window worked better with this design, so that the window had a nice amount of compression on the o-ring underneath. But the overall design was still not waterproof. Once I had it actually mounted into the hole on the electronics box, it became totally obvious that water would just leak down through the gap between the lower ring and the vertical tube and then run down the tube onto the electronics below. This prompted an idea to close the gap by melting some extra PLA filament with a heat gun into the crack, effectively creating a permanent bond between the lower ring and the vertical tube (both also made of PLA). This actually seemed to work pretty well, but unfortunately, the heat gun also melted the nice circular hole of the electronics box, so that it became much larger, and now looks like this:

So this required ordering a new box (~ $30) from Amazon. It will probably require a few hours to drill new holes into it, de-solder wires, install new cable glands and then re-solder wires. Argh.

Android BLE Integration (Nearly)

Things slowly came together this past week for adding Bluetooth Low Energy (BLE) capability into the Android Boat Captain software. I used Android Studio on my wife's computer for a day to do this, but found it a bit cumbersome to drag my electronics and USB cables back and forth between my laptop and her computer. This prompted some browsing of new computers on the Internet for a couple of hours, but this exercise revealed that the computer I wanted to buy was over $1000 so plan B was to try installing Android Studio on the Mac partition of my hard drive, to see if it fared any better than it did under Windows. Lo and behold it did!!! It was pretty much as fast as it was on my wife's computer, and didn't suffer any of the same debugging problems that I had under Windows. Why it performed so poorly under Windows, I'm not sure. Maybe it was general Windows 10 slowness, or the 2000 or so things that always seem to be running in the background, I don't know.

Anyway, I was able to make some steady progress after that. The reason I wasn't receiving any BLE traffic before was that I had to wait for a notification that data had arrived in the Android code. The process for requesting and receiving BLE data is somewhat convoluted. The literature claims that the reason for this is to conserve power. That may be so, but it sort of seems more complicated than it needs to be, as there are a number of steps involved in setting up a connection, more steps involved for sending out data and verifying that the data was really sent, then steps involved for enabling notifications for the receipt of data, and then finally actually receiving the data when it does arrive. Plus, the data arrives in little chunks that are no more than 20 bytes in size, so the actual data packets have to be stitched back together afterward. The 20-byte packet size and notification-based-approach also makes data transfer a bit slow; unless I can figure out some way to reliably speed it up, it'll be like travelling back in time 30 years to the days of dial-up modems. The slow speed is fine for simple control commands that only require a few bytes, but makes things like image downloads pretty slow.

Everything communications-wise is almost all working now. The commands for controlling propeller power and direction, and requesting basic sensor data all work, but some of the more complicated commands for requesting image samples and / or bringing the boat back to the GPS location of the phone need a bit more work. After that I'll switch over to iOS and do it all over again...