Tuesday, August 27, 2019

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.

Tuesday, August 20, 2019

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.


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. 😊

Tuesday, August 13, 2019

Chicken Protection

The chicken wire edition of the propeller cage was built this week:

Initially the 4 blue post holders were all glued to the the fiberglass surface of AMOS, but the front two posts lifted off when I was trying to put the cage on, so I bolted them down to the corner grommets of the solar panel instead. I'm guessing that the back posts may also lift off... if so I think I'll invest in a tube of a different type of epoxy. If anyone knows of a really good brand of epoxy that is waterproof, strong, and durable, please leave a comment below! The chicken wire seems like it will offer enough stiffness to protect against rocks and tree branches; I'll have to try it out later on this week at Woolastook to make sure.

I also bought a new LiDAR device a few days ago, and am waiting for it to arrive any day now. This particular device is IP67, so I'm hoping that it really will be waterproof. The last one (which was IP65) was unfortunately not quite waterproof, and got ruined after being left for too many days out in the rain. The new LiDAR can be configured for I2C data, so I'll try to add it to the existing I2C bus on AMOS, along with the A to D converter and the Inertial Measurement Unit. Luckily there was some Arduino driver software for it on GitHub, so I was able to port that over to suit my needs on the Raspberry Pi.

Tuesday, August 6, 2019

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. 😜