Long Weekend Data Testing

AMOS was once again crammed into our van along with 5 people, a dog, and a cat to visit my parents this past New Brunswick Day weekend. I was hoping to try out the air propeller cage that I had "created" by ripping apart a regular fan cage so that it only had about half of its original wire spokes. Even this reduced cage seemed kind of heavy, and I wasn't sure how well it would work atop the small servo motor.

On Saturday morning, I got a chance to try it out on a planned 7 km round trip journey. Unfortunately it only made it 2.4 km out before the wind picked up (maybe ~ 20 km/hr) and AMOS started to have trouble steering. The difficulty initially was mostly to do with software; basically the algorithm would provide a short burst of air power to either the left or right side, depending on the desired turning direction, and then it would wait for the boat to glide into the correction orientation. This had been proven to work well in calm waters, but happened to be insufficient for windy conditions with waves. After spending about 5 minutes swinging the propeller and fan cage back and forth, the lever arm connected to the servo motor slipped relative to the motor shaft (its gear teeth were later seen to be badly stripped) and the propeller swung around backwards. So I paddled over, flicked off the switch, hooked up a rope, and towed AMOS back to the cottage. During those 2.4 km, AMOS did manage to acquire some interesting data with its temperature, pH, and turbidity sensors. This data can be seen on a public arc-gis website here: https://arcg.is/18XbjH. Viewing data for all 3 sensors at the same time on the map is a bit confusing, so I created screen captures of each of the sensors separately:

The westernmost pH value is erroneous, as I had forgotten to remove the cap on the pH probe for that measurement. The turbidity measurements, are simply expressed in volts of received light level, so higher turbidity corresponds to a lower voltage value. Slightly east of the long road on the map, I believe there is a pipe emptying into the ocean. That might account for the higher turbidity, higher temperature, and slightly reduced pH at that location.

The next day, I modified the software to improve the turning function. It did seem to work pretty well for getting AMOS going in the right direction while waves were pushing it up against some rocks. About a minute later though, it appeared that the software on AMOS had crashed, as the propeller stopped turning and it slowly floated toward Prince Edward Island in a ~ 25 km/hr offshore breeze. I paddled out to rescue it, and then later looked at the log file to figure out what had happened. It turned out that the Android phone I was using to set it up had inadvertently sent out a 'q' character over the dying Bluetooth connection, at just about the point where AMOS went out of Bluetooth wireless range. 'q' was the character used by the AMOS software to quit running. I have since changed this so that the user now has to type the word "quit" before the AMOS software executes its quit function.

I have decided to get rid of the heavy metal cage. Some protection is still required for the propeller, although it doesn't necessarily have to be affixed to the propeller mounting, weighing down the servo motor. Instead, I'm going to try mounting a chicken wire cage to the surfboard itself, to form a sort of perimeter fence around the propeller. If AMOS didn't look like a redneck robot boat before, it certainly will now with the chicken wire fence around its back end. 😜

Setbacks And Distractions On The Road to Autonomy

Some efforts were made to print the air propeller cage design from last week, but they all failed. It was basically just too big, requiring about 24 hours to complete, and every time there was some glitch or other that would ruin the print and add a bunch more plastic to our garbage bin. So I uploaded it to the 3D printing service that I had used for some parts in the past, and got an online quote for $90 US for the cage. But it turned out that they couldn't print it either. They recommended that I try re-ordering using nylon instead of PLA and a different printing process, but that would have cost about $450 US, so I declined. Thankfully, they did fully refund the original $90.

So instead, I have tried "trimming" down the metal fan cage, by cutting and removing about half of the spokes. I also 3D printed a new piece to support it more rigidly (the previously used plywood bent too much, and ruined the gear mechanism on the servo motor). The replacement servo motor is expected on Thursday, so I'll know then if the reduced metal cage is light enough.

The Android and PC software was completed for "talking" to the 2nd humidity / temperature sensor inside the battery box and getting its data. I'll do the same for the iOS software after I get the BLE (Bluetooth Low Energy) communications board replaced with the genuine HM-10 model. I also just today added some software for switching the solar panel output voltage on / off to the charge controller. This will avoid the "sometimes" problem (in bright noonday sun) of having too much voltage output from the controller, which causes the electronic speed controller to complain and make beeping noises without turning the propeller. 

My brother, Andrew had asked me to consider some ideas for aspects of AMOS that could function as standalone student projects. The ideas that I came up with were (i) a sensor deployment mechanism for deploying one to four sensor probes into water at depths up to 30 m, (ii) a new layout configuration for the surfboard, boxes, and solar panel that reduces everything from a 2.5 m x 0.6 m x 0.6 m form factor to a 1.8 m x 0.6 m x 0.4 m form factor, and (iii) a fiber optic turbidity probe. The fiber optic turbidity probe is not directly related to the core work that is required for AMOS, but could potentially be an interesting product in its own right. Basically it would use two multimode fiber optic cables connected at one end to a single 850 nm LED, and at the other end to two photodiodes. One cable would have a large break in its path (perhaps 20 mm?) that passes through the water being tested, and the other cable would have a much shorter break (perhaps 2 mm?) near the same location as the first, but not close enough that light would interfere from one fiber to the other:

The received light level for the path with the short break should be minimally affected by light scattering due to turbidity, whereas the received light level for the other path should be significantly affected by light scattering due to turbidity. Both paths should experience similar light loss due to LED power fluctuations, temperature effects, fiber bending,  and environmental fouling within the sensor chamber. The sensor design has the advantage that a pressure-tight sensor housing is not required, as there are no electrical components within the sensor chamber itself. Hopefully the ratio of the received light levels would follow some sort of repeatable function as the turbidity is varied say between 0 and 3000 NTU.

Another idea that might be kind of cool would be a sort of "production" robot (robots making robots!) that uses a foam hot wire cutter to automatically cut out and shape the foam pieces that form the AMOS surfboard. This would save considerable time, and probably improve the consistency and quality of the final product.

Getting Autonomous-Ready

One of the missing requirements for an autonomous vessel was the capability to remotely login to the  Raspberry Pi computer on AMOS and change configuration file settings, upload / download files, make code changes, reboot, etc. The problem was that even if you did happen to know what the actual Internet address was for AMOS, the cell network or some other networking layer would not allow you to setup for example a secure shell (SSH) server on port 22 (or any other port I think). I had hoped that setting up port forwarding on the USB hotspot device would do the trick, but it did not. After a fair amount of Google searching, I came across https://remote.it/ which allowed me to do exactly what I wanted. Essentially they act as a sort of go-between, between AMOS and the remote user. So by registering AMOS with their service, I can open up a terminal session on  my PC to AMOS, so long as AMOS has some sort of link to the Internet.

A second humidity sensor was added to the battery box this past week, along with some software for getting data from it. I still need to add more software for the iOS, Android, and PC apps though to include this extra data. Also, the new (genuine) HM-10 Bluetooth Low Energy module arrived this week, so I'll need to hook that up soon and replace the cheap imitation version that I have been using up until now.

Kirsten and I took AMOS out to Woolastook for a field test on the weekend, but it didn't go well. The metal cage was too heavy, and would pitch forward and get stuck on the servo motor arm, making any sort of steering impossible. We went for a canoe trip anyway though, and towed AMOS along behind us. So it's back to a plastic cage for the air propeller I guess. Here is a 3D model of half the cage:

I'm not sure yet if this model will fit on my 3D printer, I'll give it a try tomorrow. It might just barely fit on the bed if I align it diagonally, although it will require a lot of support material when aligned that way. Oh well, if it works it will be a lot less expensive than outsourcing the print. This particular curved design is better than the previous 3D printed model, as it does not require additional metal rods for the sides, and has more and thicker spokes, so should be considerably more durable.

Cage and Bluetooth Upgrades

The sealed lead acid (SLA) replacement battery was tested out in AMOS last week and it did provide a much more stable voltage for the charge controller, but even though I set the limit on the charge controller to 13.5 V, it still created an output of 14 V in bright sunlight. This was a bit too much for the propeller's speed controller which would beep in annoyance and refuse to turn. Perhaps if it did turn though, the extra load would pull the voltage down to a more agreeable level?

The damaged 3D printed fan cage was replaced with an old metal fan cage that I had on hand. The shape of it was ok, but it was a bit too large and heavy. The servo could still turn it, but it seemed to not be as stable as it was before. Probably I'll go back to a plastic cage, just more robust than before.

Some more progress was made on the iOS app, until I ran into a bit of a stumbling block. I had bought what was advertised as a HM-10 BLE module from a vendor on Amazon back in March, but it was actually a knock off imitation device. Up until now it seemed to still work well enough, despite not having all the features of a true HM-10. It seemed to do everything perfectly with the Android app, but for some reason it does not send any data to the iOS app. Data flows fine in the other direction for sending movement commands, etc., but I wasted hours trying to find some way to send BLE data to the app with no success. So I guess I'll just have to find a genuine HM-10 somewhere.

Turn On, Burn In and Burn Out

In preparation for releasing AMOS into the wild on its own, some reliability testing was done with the air propeller running for extended periods of time. AMOS was placed on our pool deck in the hot sun and the air propeller was run at its maximum speed. A temperature probe was inserted into the electronics box containing the battery, speed controller and solar charge controller, and hooked up to an external Arduino board, which was in turn connected to a PC. Additional temperature sensors were in the other electronics box and connected to the sensor deployment arm, but there was some concern that the solar charge controller and battery might get too hot, hence the additional probe for that box.

It was found that the temperature within the power box would approach 45 degrees C in the mid-day sun. This temperature seemed to be more or less independent of whether or not the air propeller was actually running, so probably most of the heating was directly from the sun, not from the self-heating of the electronics. The moving air propeller might have helped to remove some of the heat as well, perhaps compensating for the electronic heating. This temperature is actually kind of close to the recommended maximum (120 degrees F or 49 degrees C) for the battery being used: https://dakotalithium.com/product/dakota-lithium-12v-10ah-battery/?v=3e8d115eb4b3. It was also noticed that the output voltage of the solar charge controller would fluctuate wildly (about + / 2 V) when it reached its floating charge level (about 13.6 V). Often this fluctuation would mess up the speed controller for the propeller, causing it to stop moving the prop and start beeping loudly. Other times the Raspberry Pi board would re-boot itself. The solar charge controller was replaced, but the fluctuation at the floating charge level remained about the same, although so far no strange speed controller behavior or rebooting was observed. Unfortunately this may mean that there is a problem with the battery (perhaps it got too hot?). A replacement lead acid unit will be swapped in tomorrow to see if that might be the case.

Here is a typical plot of the voltage while running the air propeller at full speed in bright sunlight:

 A couple of the voltage transitions in the above graph made sense (changing the prop speed from 6 to 7 and then back again) but the brief jumps near the 0.5 hour mark and the 0.5 V drop at the 2 hour mark are unexplained. An additional unexplained 0.5 V drop was noticed again this evening without the propeller running. Could be some weird stuff going on in the battery when it gets too hot. It'll be interesting to see what the less complicated lead acid battery does. The low-charge detection software was improved for AMOS this week too. Before it just used a fixed 11.3 V limit for the low-charge condition; now it looks for a slope in the voltage curve less than -1 volt / hour. So far this seems to work well, but it needs more testing.

Lastly, In Nature Robotics Ltd. now has a logo (thanks kids for recommending the logo-maker website: https://www.freelogoservices.com):

and a website: www.innaturerobotics.com (thanks kids for recommending wix.com). The website is quite preliminary right now, but will be updated gradually over time.

In Nature Robotics Ltd.

Yesterday, I officially started the company "In Nature Robotics Ltd.". Previously I had been conducting the business of designing and building AMOS under the name of my software consulting business: "Simpson's Helpful Software", but I don't think that name would work very well for trying to sell robots. Also, it seemed like it was time to start making things more official; getting a logo, website, business plan, that sort of thing.

Besides starting a robotics company, I also got AMOS out for a couple of field trials last week, added some code to help ensure that GPS data is accurate before starting a planned route, and did some work on porting over previously developed Android code to the iOS app. Kirsten and Checkers came out for one of the tests, and although Checkers didn't enjoy sitting in the canoe, we were still able to verify that the new USB data hotspot was working well. The 2nd test was at Cap Brule; it was a nice calm day with ideal conditions for collecting data, but unfortunately I entered an invalid GPS coordinate, which caused AMOS to veer onto the beach after it had collected the first point of data. I had hoped to repeat the test later that weekend, but strong winds and waves kept AMOS on dry land.

Dead Solar Panel

A couple of days ago I discovered that the solar panel was not working. The day before that, the solar charging data had indicated that it was only charging the battery for a few hours near noon, and usually it charges the battery whenever the sun is out. Opening the waterproof case for the charge controller revealed that the Velcro backing on the controller had come loose and the controller was resting face down on the other equipment in the box. I don't think that anything had shorted out, and the controller still appeared to be working correctly, although there was no output from the panel. Solar panels are capable of operating with a short circuit between their outputs, it's actually a rating that they are specified for: "short-circuit current". So I'm not exactly sure what happened. I contacted the panel vendor to see about replacement, but have not heard back yet.

Up until now, I have been using my iPhone in AMOS as a hotspot, whenever cell connectivity was required. It never actually worked very well. Even though my phone was right inside AMOS, it would often drop the connection, requiring a reset of either the phone or AMOS to get re-established. So last week I bought the Huawei LTE E8372 Hotspot Turbo Stick: https://www.thesource.ca/en-ca/cell-phones/portable-internet/huawei-lte-e8372-hotspot-turbo-stick/p/108036412 I was able to use the same 100 MBytes data plan that I had for the Android phone. So far I have just done some limited testing with it, but it seems to work well. It's also pretty small and plugs into one of the available USB charging ports on the charge controller. I'll have to try it out in an actual field test soon.

The turbidity sensor enclosure is coming along, but so far isn't quite 100% waterproof. The weak point now is near the top, where the cable enters the housing. I hung an old lawnmower spark plug from the bottom of it to weigh it down and make it more vertical in the water, and by taking up some of the slack in the electrical cable I can keep the top end from getting immersed in the water. It's not ideal, but might work OK for now.

Software-wise, things are coming along also. I modified the startup code to make sure that a GPS fix is acquired prior to saving sensor data. Previously, AMOS would wake-up from sleep mode to collect data, but GPS data was not always available before the sensor data was collected. I also added code for better handling the low battery condition. Now if the battery voltage dips below 11.3 V an alarm can be sent via email and / or text, and AMOS goes into low power mode for an hour, in the hope that some exposure to sunlight will give it some more charge.