110 km and Counting

AMOS was back at Woolastook for a few days last week, but I think its days on the water will be coming to a close soon for this year. The temperature is getting down near zero in the mornings, and the lead acid battery that I'm currently using doesn't seem to last as long in cold weather. I have been looking at bigger lithium phosphate batteries, perhaps 50 or even 100 AH but they are pretty expensive, so I'll first need to make sure that AMOS is sufficiently mobile with carrying the extra weight, and make a request to In Nature Robotics' finance department. 😏

To date this year, AMOS has traveled 110 km, mostly near Woolastook Park, but some around Cap-Brûlé too. Almost all of it has been autonomous, travelling to pre-programmed GPS coordinates. The 1000 km distance goal I came up with on New Year's day isn't going to happen this year, but all of the testing done so far has highlighted a number of issues that can be solved to help make AMOS a better robot:

• Need to guard against AMOS getting stuck. Some areas of the shore are more amenable to docking than others. Safe points (with maximal sun exposure and not too close to populated areas) were defined in the software for AMOS to try to reach whenever its battery gets low, but sometimes AMOS is too far away from a safe point when a low battery condition occurs, and it must go into low power mode wherever it happens to be at the time. The wind then eventually blows the boat to a random shore location, where it often becomes beached on rocks, or stuck in a shoreline tree or bush. One solution might be to have an anchor system that lets down a small anchor with say a 5 m line. This would hopefully keep the boat in a stable location well enough away from shore to get going again after its battery charges back up.
• Need to look more closely at the LiDAR obstacle avoidance code. Sometimes it seems to be working, but at other times I've seen AMOS veer off directly toward a clump of grass onto the shore, and I'm like, "what the heck?".
• Need to fix up the sensor deployment arm to avoid it getting tangled on electrical cables on the back deck. Sometimes the sensor probes don't quite make it to the surface of the water.
• Need to re-wire the electronics for sleep mode to switch off absolutely everything that doesn't need to be powered. Currently AMOS requires about 2.5 W in sleep mode, but I think I should be able to get this down to close to 0.5 W by only powering the RF220SU radio board, and the solar charge controller. 

A lack of sun and cold weather kept AMOS from getting too far this past week, but here is some temperature data for Sept. 26 to 28 (http://arcg.is/uTS90):

Marketing Is The Only Thing That Matters

After arriving to Measurand for my afternoon shift one day last week I was somewhat surprised to find out that I needed to go get interviewed by a software consultant that had been hired by the company to review our software processes. His name was Alan I think, and he turned out to be a pretty friendly guy. We briefly introduced ourselves, and immediately found out that we were both working toward similar goals; both doing consulting work and working at regular jobs to help make ends meet while trying to become successful entrepreneurs. He has progressed further than I have, as I believe he mentioned something about actual customers. His business involved setting up smart lighting systems for large buildings, in order to use less energy and save their customers money. It sounded like a great idea. Then, after I briefly described what I was doing with AMOS, he gave me these sage words of advice:

"Nothing else matters except marketing. None of the other shit is important; it doesn't even matter if everything is working right, you can fix it later. Seriously, marketing is the most important thing. If you don't do it right, you've got nothing."

I smiled, nodded, and said something like "Hmm.... OK." and that was that. The significance and truth of his advice didn't really sink in until later, after the interview was over and I went back to working at my desk. I'm kind of like a "fish out of water" when it comes to marketing.

(Unfortunate minnow found dead on the deck of AMOS a couple of days ago.)

so finding customers might be a bit of a challenge. Fortunately though, In Nature Robotics was recently accepted into the Venn Garage program (http://www.venninnovation.com/en/venn-garage), a mentorship program offered to small startup businesses in New Brunswick, to help them validate their idea, acquire early adopter customers and initial funding, and prepare their startup team for successful entry into leading accelerators. Hopefully over the next year, I'll pick up some good marketing tips and knowledge from people who have done it successfully in the past. I also applied to the Creative Destruction Lab accelerator program (https://www.creativedestructionlab.com/program/) to their Oceans stream, based in Halifax (https://www.creativedestructionlab.com/streams/oceans/). Last week I had a video interview with a few people from there, and will find out by October 2 whether or not I got in.

AMOS spent another 4 days on its own at Woolastook this past week, and collected some good temperature and  pH data (https://www.innaturerobotics.com/sample-data-1). Although it has been a while since I did a very crude calibration of the probe with some kitchen vinegar and tap water, it does seem as though the water around Woolastook is a bit acidic. Apparently that's not uncommon in this particular part of North America. On Thursday, AMOS set a new single day distance record of 12.25 km.

The weather is currently quite cloudy and rainy, so I have AMOS back home where I'll see if I can fix some intermittent low voltage issues on the +5 V supply, and maybe hook the GPS antenna back up. There seemed to be a few spots around Woolastook where finding a GPS signal was a bit of a challenge.

A Week of Finger Burning (a.k.a. Soldering)

Turns out AMOS had sustained a bit more damage than I had originally thought last week. The pH and turbidity electronics signal boards had also been fried, so they had to be replaced too. Luckily they weren't super-expensive. Re-doing all of the wiring for the new Raspberry Pi 3B+ and the replacement RF220SU wireless unit took an inordinate amount of time though. The heating element in my soldering iron was slowly dying and the pins on the wireless transceiver were spaced only 2 mm apart, so needless to say there were some moments of extreme frustration trying to get all of the little solder blobs onto the right pins and wires. I really like the wireless module, but I wish there were a better package for it, i.e. something with a 20-pin header for easily plugging, unplugging wires would make things so much easier. Could be a new product there...

I just finished wiring up and testing everything today, so I think this new build of AMOS is ready to go. Although it's still a bit of a mess inside, the CPU box has considerably more room with the smaller Pi board, no more USB hub, and a few stray wires cleaned up:

I'm anxious to get AMOS back in the water for more testing. The forecast is calling for 5 straight days of sunshine, so hopefully it will be able to get lots of km over the next week.

Here's a picture taken from a couple of weeks ago on one of the first rescue missions. AMOS is looking kind of lonely under the shade of some trees on the south side of the river:

Zapped Circuit Boards

After AMOS had been on its own for 5 days, I drove out to pick it up so that it would be safe from Hurricane Dorian and so that I could modify the power cable for the cellular hotspot to be software controlled (i.e. shut off whenever AMOS goes into sleep mode).

Although it had a low battery and was too weak to extract itself from some branches near the shore, it appeared to be working normally when I picked it up. So I unplugged the power cables inside the battery box, loaded it into the van, and drove home. After I got home however, it would no longer boot up properly, even after the battery was sufficiently charged. A few hours of hardware troubleshooting revealed that the short-range wireless module was somehow short-circuited, and drawing too much power. Also, the 3.3 V regulator on the Raspberry Pi mainboard was only putting out about 2.6 V. Replacing the regulator with a different one didn't seem to help either, i.e. the Pi board would still not boot up. 

Later that same day, I drove the van to Kirsten's cross country practice to pick her up. While waiting in the parking lot for 10 minutes, the van's battery mysteriously died, and could no longer be started when the practice ended. Turned out the alternator was shot and needed to be replaced, so overall not a great day for electronics. Maybe I was emanating some weird electromagnetic radiation or something that day. Actually I think what probably happened with AMOS was that when I unplugged the power cable in the battery box and transported it in the van, it probably shorted out on the +12 V battery terminal, destroying both the Pi board and the wireless transceiver.

Turns out it's not all bad though. I had been contemplating switching the Raspberry Pi Compute module for the smaller, less expensive Raspberry Pi 3B+. The 3B+ actually has a slightly faster processor than the compute module, built in WiFi and Bluetooth, and 4 USB ports all included, whereas the Compute module only has one USB port, and requires a separate hub to add WiFi and Bluetooth functionality. Originally I had gotten the Compute module because it had two camera ports, and might make 3D ranging possible using stereovision. Turns out it's way easier to do that with LiDAR though, so no real need for two visual cameras. The 3B+ has fewer I/O ports too, but it still has way more than AMOS needs right now; about 13 extra digital I/O pins are still available for any new functionality. 

Here is a comparison shot showing the reduction in size between the Compute module and the 3B+:

The next few days are going to be spent setting up the 3B+ and the replacement wireless module. The software changes are pretty minimal, just pin re-numbering mostly. Most of the time will be spent setting up the software, as I don't have a workable image ready for this board yet, plus a bit of time for soldering together the replacement wireless module.

The Quest For Sun

AMOS has been mostly on its own for the past week in Kelly's Creek, near Woolastook Park. Hannah and I deployed it on Saturday morning, and tested out the LiDAR "avoidance mode". Once it did seem to work, but another time it did not, as AMOS plowed directly into the side of the canoe. I believe I was able to correct a software bug related to that this morning, but have not had a chance to test it out yet. That day was also very windy, and AMOS overshot a couple of its sampling waypoints and had to return against a strong west wind with gusts > 20 km/hr. Here is a map showing the track (in blue) that it followed before it eventually ran low on power and drifted under some trees on the south shore:

Even though the next day was sunny, it was not able to charge at all under the trees on the south bank of the river, so I took the kayak out and towed it to the north shore, letting it sit there for about an hour and a half to properly charge in the bright noon-day sun. Then I set it to continue on its way, where it traveled to the far end of the waterway, before shutting off its propeller at the planned time of 3 pm. After I got home, I opened a terminal connection to it, to discover that it had once again drifted to the south shore. So I found a place on Google maps on the north shore well away from houses, and created a short script to send it to that spot, 500 m across the water. The day after that was quite rainy and overcast, and AMOS never really charged very much, so again through the terminal connection and various file scripts, I set AMOS to mostly drift around, just using the propellers to stay away from the shoreline. It eventually covered 2.5 km, but that was over about 3 hours. Eventually it came to rest against someone's dock for the night:

I tried to steer it away from the dock, but the battery was too low to drive the servo controlling the propeller direction, so it just kept ramming itself into the dock instead. Nothing to do but leave it for the night, and hope that no one minded I guess. During the night, the wind must have taken AMOS a few hundred meters northeast to a less populated area. The battery must have gotten pretty low during the night I think, so I just let it charge up today, which was only partly sunny:

9:00 am --> 11.454 V
10:08 am --> 11.666 V
11:19 am --> 11.810 V
11:59 am --> 12.022 V
5:30 pm  --> 12.25 V

I was a bit surprised that it didn't charge up to more than 12.25 V by 5:30, as the afternoon was much sunnier than the morning, and from what I could tell from the boat's camera, it was in a spot on the north shore without noticeable shade. Here is the view from the camera when the boat was facing west:

 Normally in bright sunshine all afternoon, I would have expected to see the battery voltage climb up to over 13 V.

I added some software to AMOS to define optional "safe" locations in the text script files. These are locations where AMOS will head to when its battery starts to get low. I tested it out this evening and it seemed to work, choosing the closest safe location, although AMOS was pretty close to that point already, so it wasn't a very hard test.

Tomorrow looks like it's going to be rainy again, so if there's time, I think I'll make a trip out to retrieve AMOS and modify it to switch off power to the cellular hotspot during sleep mode. Right now it's just on all the time, which could be wasting a few watts of power at times when I can't even communicate with the boat anyway.

Waking up and Charging

The first day that AMOS was left on its own (last Wednesday) there was a bug in its software that didn't properly close down the configuration file after writing to it, so that when the Pi processor was put into sleep mode the night before, the configuration file actually got erased. This caused a crash when AMOS woke up at 9:00 am the next morning. I had some meetings that day, and wasn't able to monitor the progress of its maiden solo (non) voyage. That afternoon however, there was a strong wind from the south, so that AMOS was actually blown from its swampy location at the south end of the cove, to the north bank of the river, about 1 km away. When I checked the GPS location that evening, I thought there must be some mistake, but a picture taken from the camera confirmed its location next to somebody's dock:

I went out in a rainstorm that evening to retrieve it and bring it back to the swampy cove. I also fixed the bug that had caused the crash when waking up out of sleep mode.

The next morning turned out to be grey and overcast, so AMOS didn't have much charge when it woke up at 9:00 am. It traveled for about 3.5 km though, before it went into sleep mode to recharge its batteries. This time however, AMOS drifted onto the south river bank, where there was an exceptionally steep hill, very thick with trees that very nicely shaded the robot from the sun. It was hardly charging at all, so again I went out that evening to fetch it back, again in the rain, and this time with a bit of thunder and lightening as well. Here is a pic of where it was hiding, nicely shaded under some trees:

We were scheduled to leave for a family vacation on the weekend, so I brought AMOS back home after that, did some more minor debugging, and set it up in the backyard to test out the solar charging, sleep mode, and battery management software while we were away. These tests have mostly gone OK, with only some minor software issues that have been fixed. The biggest problem that these and the actual field tests of last week have confirmed is how to make sure that AMOS gets enough sun to properly re-charge itself. Basically AMOS needs to drive itself out into a place where there is known to be sun shining, then shut itself off (including GPS) to conserve power, and hope that it doesn't blow too far away. Right now if it needs to re-charge in the daytime, it is set to go back into sleep mode for an hour. Probably this should only be 10 minutes though, so that it can check to see if it has drifted too far away, and quickly correct its position if necessary, before going back into sleep mode to re-charge. Finding enough sun is going to be a bit of a challenge, all the more so now that summer is coming to an end.

Distance Record and Initial Autonomy

Last Thursday I was able to get AMOS loaded into the van and deployed again at Woolastook by 9:15 am, which allowed enough time for a nice 2.75 hour test, covering nearly the entire length of Kelly's Creek and back again. Below is a map depicting the route that it took:

The total distance covered was 10.85 km, which smashed AMOS's previous single-trip distance record of 6.12 km. This was encouraging, since it meant that a fully autonomous AMOS, operating in this relatively closed area might have some hope of reaching the goal of 1000 km of total traveled distance before the end of the year. There are fewer hours of available sunlight each day, so I really need to get it running on its own soon.

I was able to get the new LiDAR module hooked up, and finished debugging the software that I had written for it. It seemed to work pretty well. The software has two basic modes of operation when using LiDAR data:

1. Safety Mode: Stop moving the boat whenever an obstacle is encountered.

2. Avoidance Mode: Try to turn the boat until it finds a direction without an obstacle, then proceed in that direction for 60 seconds before returning to the previous navigation plan.

Here is a picture showing the new LiDAR module:

It is the small black device with two lenses bolted into a blue plastic piece that was 3-D printed and velcroed to the visual camera enclosure.

The last few days have been a bit of a scramble, trying to add some new features to the software for going into a "rest" mode where the boat just sits there, but is still connected to the Internet with GPS access, and also a "sleep" mode, where the boat is almost entirely powered down, except for the RFU220 wireless module and a few other components. These other components could also be switched off, but I haven't had time to do that yet. The clock times for going into these modes can be set from the same text script that is used to specify the GPS waypoints for sampling. There is also now a means for setting the "wake up" clock time for when AMOS can go on its way and begin sampling, provided its battery voltage is high enough (> 12.4 V). If the battery hasn't been charged enough, it goes back to sleep for another hour, and then tries again.

After some slightly rushed backyard testing, I was able to deploy AMOS back to Kelly's Creek again this evening, but this time I left it there. If all goes as planned, it will wake up tomorrow at 9:00 am and repeat the course shown above. At 3:00 pm it will go into rest mode, and then at 11:00 pm it will go into sleep mode. I'm kind of nervous about people tampering with it. I laminated she following sheet and duct taped it to the front deck of the boat:

AMOS – Autonomous Mini Observation System

This robotic vehicle is collecting water quality data over the area indicated in the above map. Please do not interfere or tamper with it! For more information, visit www.innaturerobotics.com or email info@innaturerobotics.com.

THANK YOU

If somebody does steal the boat, here is a picture indicating its last known whereabouts:

I put it in the grossest, swampiest place I could find to deter would-be thieves and vandals. 😊