Tuesday, August 28, 2018

Runaway Boat!

A search through the user forums at bluerobotics.com (the manufacturer of the T200 propellers that AMOS uses) turned up some 3D CAD models for propeller shields that users claimed were useful for protecting against weeds, while only contributing a small amount of additional drag. So I sent those off to 3dhubs.com and am expecting them to come in any day now. So no cool swamp air boat designs for now at least.

During the remainder of our week at Cap-Brulé, we were fortunate that the shifting wind and tides moved all the seaweed somewhere else, so I was able to do some more testing on AMOS without having to worry about the propellers constantly getting stuck. I made some changes to the software to improve how remote steering is done using the phone app. Basically, instead of specifying left and right power levels, and hoping that the boat goes straight if the power levels are the same (it never does) I changed it to check the compass heading if the user tells the boat to go straight at a particular power level, and then try to maintain that compass heading and approximate power level using the existing software routines for GPS navigation. Usually the tests of this new software worked pretty well, but a couple of times the software crashed and AMOS continued on into the open water. Even though the program was halted, the propellers still happily turned and sent the boat well away from shore. I tried in vain for about a minute or so both times to re-establish contact, but of course this was impossible as the boat's program was no longer running. So I hastily pulled the kayak into the water and went after it. The weather was quite windy with waves that broke against the kayak's hull and sprayed me in the face. Fortunately the kayak didn't capsize and I was able to catch and retrieve AMOS, probably somewhere around 500 m from shore. I'm still not sure what caused the crashes to occur. The ship's log file was zero bytes both times, as it had not been closed correctly. I should be able to change the software for that to always open and close the file each time the program writes to it... this will slow file logging considerably, but may help to determine what was happening before the crash occurred. Another idea is to create a second program to launch the current AMOS program, and have it automatically re-start the AMOS program if it detects that a crash occurred. Good software should never crash right? But it doesn't hurt to be prepared for a crash anyway.

After we returned from Cap-Brulé there were a few items waiting for me in the mail: the replacement (waterproof) LiDAR sensor (TF02), the 3D printed sensor tow-boat that was described in last week's post, and a 3/4" NPT metal tap for making a threaded hole in the tow-boat. As I had hoped, the replacement LiDAR truly was plug and play. It is a bit bigger and beefier than its predecessor, and can detect objects up to 22 m away. Here is a picture of the new LiDAR mounted atop a small wooden post on AMOS:

Today I was able to create a threaded hole in the tow-boat and then was actually able to screw the top of the pH probe into it for a nice snug fit. I had never done anything like that before, and was pleasantly surprised that it actually worked! I also mounted the turbidity sensor into the central hole, and epoxied a cat-food tin to the top of it to shield it from ambient light. I then did some crude experiments with clear water and water full of loose dirt and twigs (whilst channeling my inner 5-year old) but was unable to determine for sure whether the turbidity sensor was actually working. Usually the readings for the clear water and twiggy, dirty water were the same. But occasionally the reading for the twiggy, dirty water would get very low, so I'm guessing that the water was just not sufficiently mixed and a change in turbidity was only registered when a large particle happened to get between the transmitter and receiver.

These things will be further tested over the next week. 

Tuesday, August 21, 2018

Too Bright, Too Wet, Too Weedy

I tested out the turbidity sensor that I had started hooking up last week, but found that it was greatly affected by ambient light.  As it was only a $14 sensor I had not really expected too much from it. Industrial quality turbidity probes run into the thousands of dollars. Still, it might be able to provide useful data if it were shielded from ambient light; so I designed a small "tow-boat" that can hold the turbidity sensor in an enclosed space with channels that should allow water to flow past the sensor, but also not let much light to enter. The tow-boat also has mounting holes for the pH and temperature probes and was just recently 3D printed by by 3dhubs.com, so should arrive soon:

I'll also need to add a cap of some sort to keep water away from the cable and some plastic tabs that have tiny openings in the sensor casing.

The TF Mini LiDAR sensor arrived this past week, so that was hooked up also, and I ported some Arduino code over to Raspberry Pi to connect to it and start getting data. It worked great, providing object distance data with ~ 1 cm resolution at up to 100 Hz. I figured I would try screwing it down to the front of the hull, just below the line of sight of the camera. As this unit was not waterproof, I applied generous globs of epoxy to the edges and around where the cable plugged in. I wasn't sure whether or not the light from the LiDAR would reflect off of water waves and get detected. A quick test at Cap-Brulé showed that it did indeed reflect off of the water:

It's difficult to see in the above photo, but there is text super-imposed on it ("Distance = 0.74 m") indicating the object distance read by the LiDAR. This was one of 5 pictures taken before the LiDAR stopped working altogether. Apparently my application of epoxy was not sufficiently waterproof, or perhaps water spray leaked in around the transmitter / receiver lenses. Thankfully the same company (Benewake) that makes this particular LiDAR also makes an IP65 waterproof model, the TF02, so I ordered one. It looks like it uses the same data format, so hopefully it will just be plug and play. Probably I should mount the TF02 higher up, perhaps on top of the solar panel in order to avoid sensing reflections off of the surface of the water.

Other testing this week at Cap-Brulé has experienced lots of problems with seaweed. The boat could not go more than about 30 m before getting stuck in a patch of seaweed. Argh. It might be time to reconsider the decision to use electric propellers in the water. Possibly an "air-boat" design would work better. There are some RC boats available such as this one: https://www.youtube.com/watch?v=7mz1_1T-4FY that seem to have plenty of power (~ 500 W) and also seem to be fairly maneuverable. So I'm going to think about it for a bit, and maybe see if I can pick up some parts to make a DIY robot swamp boat.

Tuesday, August 14, 2018

The Weed-Free Strainer Boat

As the summer has progressed, the prevalence of weeds in the St. John River where I have done most of my testing has also increased. Lily pads with their long stems are especially problematic for AMOS's propellers, as the stems seem to enjoy winding themselves around and around the motor shaft, usually causing the motor to stall completely. From what I could read, this problem seems to be universal for all types of propeller driven watercraft. Some larger motors use a "cutter" disc on the shaft, with a sharp outer edge that serves to cut through entangling vegetation. Many of the smaller handheld electric motors (for scuba diving or recreational swimming) use a plastic cage or basket around the propellers, which also helps protect the user's fingers.

Hannah and I took a trip to Walmart to look for suitably sized kitchen strainers that might help to protect the propellers on AMOS from weeds. For a first try, we selected a pair of strainers that had a fairly fine stainless steel mesh. These would be excellent protection against weeds, but I was a bit afraid that the fineness of the mesh would limit the flow of water through the propellers and produce too much drag. I zip-tied and duct-taped the pair of strainers to the mounting U-bolts of AMOS and tested it out in the pool. The initial test was pretty disappointing, as AMOS was quite sluggish. Its top speed was probably less than half what it was without the strainers mounted.

As can be seen in the above photo, the strainers had a plastic "lip" that would be quite useful if you were using them for their intended purpose on the edge of a sink. However this lip was dragging me down. Literally. So I hacked it off with a hand saw, and re-tried the pool test with the lip-less strainers. This time the boat did move faster; about half of its full speed without strainers attached. Perhaps these could be useful for a really weedy area, but I think I could probably get away with more of an open cage type concept, and still have pretty good weed protection.

This week has also seen incremental improvements in the software algorithms used for detecting objects in the water. As expected, this work has been somewhat slow and difficult. I'm working with a set of about 3700 still images that I recorded from an outing on the St. John River. Most of the images don't have any objects in them, but a number of them feature me kayaking in front of AMOS. If the kayak is not too close to the horizon line, it does get "detected" most of the time. The biggest problem at the moment is figuring out how to filter out all the "false positives" that arise from water droplets, shadows, sun reflections, etc. This is a pretty good challenge, but not a hopeless one I think. I think there is still lots of room for improvement in the algorithms that I am using for object detection.

The Mini LiDAR just arrived in the mail today, so I hope to have that hooked up soon and working in conjunction with the camera. I also almost finished hooking up the turbidity sensor this morning. There is a real mess of wires in AMOS now, so simple electronic hook-ups are not quite so simple anymore!

Tuesday, August 7, 2018

Time Away From AMOS

We did a family road trip vacation to Toronto this past week, so I did not have much opportunity to work on AMOS. After returning home and checking to make sure that AMOS was still powered up and working, I was alarmed to see that it was neither powered up nor working. In fact, the battery was completely dead. Connecting the battery terminals to a wall charger for an hour brought it back to life, but the battery icon on the solar charger was flashing ominously, and I was pretty sure I hadn't seen it do that before. The battery voltage was ~ 12.6 V, so if the solar charging were working, I could expect the voltage to climb up to ~ 13.7 V in an hour or less, as the sun was shining brightly at the time. After an hour, the battery voltage still stood at 12.6 V, and the battery icon was still flashing. So something was wrong. I tore apart the "waterproof" connector that was used for the solar panel cables, and confirmed that the crimped wires in this connector were badly corroded. Again. This was the second time that my solar panel crimped wire connections got corroded and were no longer were able to conduct enough electricity to charge the battery.

This time I just made a solder connection with some heat shrink and duct tape to cover up the join. Hopefully it will last a bit longer than my crimped wire connections. I guess time will tell.

A couple of weeks ago I received an interesting promotional email about a couple of different low-cost LiDAR modules. Object detection using a camera-based system seems like it will probably work reasonably well most of the time, but any truly autonomous vehicle should have redundant systems in place to make sure that it doesn't smash into anything. Autonomous cars typically use a combination of cameras, LiDAR, and radar (see for example: https://www.sensorsmag.com/components/three-sensor-types-drive-autonomous-vehicles). The simplest of these was the TFmini LiDAR module (https://www.robotshop.com/ca/en/benewake-tfmini-micro-lidar-module-12-m.html) available for ~ $50 Canadian:

Unlike some of the higher-end LiDARs, this one is just stationary, and has a directional beam width of about 2.3 degrees. It can detect objects up to 12 m away, although in an outdoor environment, that figure goes down to about 7 m I think. It provides updates at 100 Hz, so if it works well I could probably set it atop a pan-tilt module and use it to find a "point-cloud" of objects in the immediate vicinity of AMOS. It also uses 3.3 V logic levels for communications, same as the Raspberry Pi which should make the wiring requirements relatively painless. I ordered one from the robotshop.ca and hope to have it in about a week. I'll probably set it on top of the camera housing and use it to look for obstacles in the immediate forward path. Adding a bit of simple logic should help to keep the sides of our pool from getting robot dents. 😉