All Caged Up

After finishing last week's blog I encountered another long string of 3D printing failures on my own printer. We did have a snowstorm one day, but other days the weather was fine, and I have no idea why the prints all failed. I had thought previously that temperature or humidity could have been an issue but now I'm not so sure. The usual reason for failure was that some extra plastic occasionally leaked out of the block holding the extruder, and molten blobs of the plastic landed on top of the print and cooled, so that the extruder would eventually collide with it, knocking the print loose from the base, resulting in a failed mess.

So I just sent off the front and back pieces of the cage to 3DHubs. By not including any side pieces (I used a bunch of 2 mm diameter metal rods for this) I was able to save a lot on printing costs (cost was less than $100 vs. ~ $400 for printing the whole cage). Here is the finished result:

If you are determined to jam your hand in between the metal rods or between the plastic spokes you can still hurt yourself, but I think it offers a reasonable level of safety, while allowing good air flow.

I decided to make the air rudders (to be mounted behind the cage) out of thin aluminum sheets. Here is a video of one of them epoxied to the servo motor:

At first the servo wouldn't turn and I was worried that epoxy had gotten into the gears, but it was fortunately just some loose wiring. A second air rudder will run in parallel to this one, and be driven by a bit of coat hanger joining the two of them.

I also tried out a new inertial measurement unit this week (the AltIMU-10 v5 Gyro, Accelerometer, Compass, and Altimeter from Pololu Electronics www.polulu.com). So far I've been able to get temperature, magnetic, acceleration, and gyro data out of the thing in all 3 axes at about 50 Hz. I'm not sure yet whether or not it would be a good replacement for the electronic compass (without gyros) that I'm using now. The hope is that it might provide more reliable orientation data for AMOS in rough, dynamic water.

The Quest For a Cage

Far too much time was spent this past week trying to figure out how to enclose the air propeller in a protective cage, with a servo motor and air rudders also attached behind the cage. I spent a few days coming up with what seemed like a workable design in OpenSCAD, but when I uploaded the files to 3DHubs I was shocked by the price tag for the work: approximately $1000 CAD. The propeller was almost 10 inches in diameter, so the cage had to be fairly substantial in order to properly enclose it. I was able to reduce the diameter of the enclosure a bit though, and remove some of the material from the sides and back. This helped a fair amount, but the price was still ~ $400 CAD. I would do better to just buy a cheap fan from a hardware store, rip its cage off and epoxy it somehow to the rest of AMOS, the air rudders, and the servo motor. I'm not sure what to do at this point, but I did try splitting up the initial design so that I can print some of the smaller pieces on my own printer. After a few wasted prints (I think the temperature was too low) I now seem to be reliably printing stuff; much better than it had been earlier this year. I'm not 100% sure yet why... perhaps the change in temperature of the extruder or maybe the reduced humidity at this time of year is helping the prints to adhere better to the printer's platform. It will take another day or two to print out the smaller things (pivot joints, air rudders, servo motor holders, etc.) but if these work I may try printing the larger pieces too. I'll have to do it in multiple pieces though and then join them back together somehow.

Here is a picture of the servo motor that I got for controlling the angle of the air rudders:

It is normally used for steering toy remote control cars, but it is supposed to be waterproof, and has a fairly high torque rating: 20 kg-cm, which should be sufficient for controlling the angle of the air rudders. I hooked it up to one of the pulse width modulated (PWM) outputs of the Raspberry Pi and wrote a short program to verify that it turned properly through its specified +/- 90 degree range.

Sufficient Air Power

Because AMOS is somewhat susceptible to getting stuck in stringy seaweed, I bought an inexpensive plastic air propeller (for use with remote control airplanes), and an electronic speed controller from Amazon. This past weekend some scrap wood was added to the back end of AMOS to mount it, and some simple test software was created to calibrate and use the speed controller. I really wasn't too sure how it was going to go, i.e. whether or not this little plastic propeller would produce enough thrust to move AMOS anywhere or not.

Here is a picture of  Checkers with AMOS and the new air propeller:

And a video of the propeller in action in our green pool:

https://www.youtube.com/watch?v=NDXu83YbiPo

It was extremely windy when the above video was shot, which likely accounted for some of the rotation that AMOS experienced. At present there are no rudders for directional control, I just wanted to see whether or not the propeller could produce enough thrust to move the boat. For the video, the thrust level was at about 70% of maximum output. This corresponded to a current draw of about 20 A at 12 V, comparable to the maximum amount of power that I used with the water propellers. The battery inside AMOS is rated for a maximum continuous output of 20 A, so I probably wouldn't want to drive it beyond that for any length of time. As expected, there is not as much propulsive thrust exerted by the air propeller, compared to the combined efforts of the two water propellers. However, now that the water propellers are removed, there is less drag in the water. I'm also wondering if a more hydrodynamic hull (perhaps catamaran style?) might also help to reduce drag.

The ribbon extension cable for the camera arrived last week, so that was hooked up and tested to confirm that it worked correctly. I also spent an hour or two searching around the Linux geek forums to figure out how to setup the Pi to automatically connect to any of a number of potential wireless access points. This sounds like it should be easy, I mean PCs have been doing that for years right? But there was actually a lot of conflicting information on the Internet about how to do it on a Raspberry Pi properly. I had tried and failed a few months earlier, and have always been manually editing the /etc/network/interfaces file and rebooting every time I wanted to switch access points. But this time I managed to get the wpa_supplicant.conf file setup properly, so now AMOS can connect to any of 3 potential access points, without the need for editing the configuration file every time.

The next step is going to be to design an air propeller cage (so I don't cut my fingers off) and a motor / rudder system mounted to the cage, behind the propeller for steering. I've been looking at lots of pictures of airboats online, and have some idea of how to do it, but I'm sure there will be some challenges. I also recently purchased a pair of wireless transceivers: https://www.robotshop.com/ca/en/24g-transceiver-rf220su-module.html that claim to have a line of sight range of up to 3 miles, and contain an Atmel AVR 8-bit microcontroller (the same one used in Arduino boards). One of the transceivers will be used on a small mast on AMOS, and besides maintaining a communications link, will be used to continuously monitor the "health" of the main Raspberry Pi board. If the Pi board becomes unresponsive for a set period of time, the smaller 8-bit micro can control a relay that will "hard-reboot" the Pi. The small micro also has pulse width modulated (PWM) outputs, analog to digital inputs, and digital inputs / outputs, but I haven't decided what (if anything) to do with them yet.

Airboat Revisited?

On Wednesday of last week I took AMOS out to Woolastook to try out the new navigation software, and see if perhaps it could collect a test sample grid of temperature and pH points in a 200 x 300 m area of the river. Unfortunately the new software for getting faster updates of the yaw angle (from the magnetometer) proved to be too noisy for the boat's simple turn function, so it would usually tend to fire the thrusters somewhat randomly trying to do a stationary turn. This function worked fine in the pool, but under real world conditions it was no good. To compound difficulties, I had also keyed in the GPS coordinates for the corners of the sampling grid incorrectly, so that the boat was always attempting to drive itself back to shore.

That night, the software was modified to use a filtered average yaw angle from the magnetometer, based on the previous second's worth of data. This restored the original functionality of the simple turn function. The coordinates of the sample grid were also fixed, and the following day, the test was re-attempted. Things started off well and AMOS proceeded into the wind towards the northwest corner of the sample grid. It then proceeded eastward to complete the first row of sampling, but started behaving quite erratically as can be seen in the GPS track shown below:

After about an hour of this, it mysteriously died. I think that possibly the software crashed, although there was no record in the ship's log file or any of the Raspberry Pi log files to indicate what might have caused the crash. The ship's log file indicated that the battery level was OK before the crash, so presumably power was not an issue. One possibility is that some wires might have shorted out inside AMOS, causing the Pi to stop running. There is some reason to suspect this, since it was discovered after the fact that the compass module had pulled out of its enclosure and was free to float around inside the boat. It was this floating compass that was responsible for the erratic navigation during the eastward sampling stage. The next day, Velcro was applied to the compass module to hold it in place within its enclosure, and a second log file was created for the shell software that starts the main AMOS program, to hopefully save the exit code if a crash occurs.

The next couple of days (Thanksgiving) were spent at Mom and Dad's cottage, wiring up the new A to D board that arrived from ControlEverything.com. It was pretty close to what I had before in terms of parts, just professionally soldered and put together, so I'm sure it will be more reliable. There were some minor software changes to make for it too... some of the configuration commands were slightly different, and I needed to do some averaging in software to achieve an 18-bit level of precision. So far it seems to be working quite well. The weather didn't cooperate for most of the weekend, but on Monday, the waves were not too bad, so I released AMOS for what was planned to be a short 1 km test. Unfortunately AMOS only went about 75 m north from the shore, and then struggled to move anywhere... eventually the wind (which was coming from the north) pushed it back to shore where I retrieved it and discovered that the thrusters had both become fouled with seaweed, the leftmost one worse than the right. Below are a picture of the thruster with the seaweed in it and the clump of seaweed by itself after I picked it out by hand:

So apparently the new propeller shield is not very effective, at least not for this common variety of seaweed. So today I spent some time googling various types of airboat designs. This one (https://www.cim.mcgill.ca/~mrl/pubs/anqixu/iros2011_boat.pdf) seemed intriguing, and indicated that a vessel of a size similar to AMOS could be driven using air propellers. I ordered some inexpensive drone equipment from Amazon (https://www.amazon.ca/dp/B07C5KYNY7/ref=pe_3034960_236394800_TE_dp_1) so once that arrives I'll attach it to AMOS and see whether or not it can actually push the boat through the water. 

Tidying Up The Engine Room

I’m tired of sailing my little boat
Far inside the harbor bar --
I want to go out where the big ships float
Out on the deep where the great ones are.
And should my frail craft prove too slight
For waves that sweep those billows o'er,
I'd rather go down in the stirring fight
Than drowse to death by the sheltered shore.

-- author unknown


Two weeks ago I posted a picture of the inside of AMOS after it had been driven home in the van from a test and some of the components had shifted around a bit:

Although the above picture exaggerated the usual condition of AMOS's innards, it wasn't too far from the usual reality. It had gotten to the point where I seemed to be making repairs to the wiring as often as not, and it was time to straighten things up a bit in order to save time going forward.. 

The enclosures that were designed the week before arrived from 3DHubs, so all of the wiring was painstakingly untangled, de-soldered in some cases, the components placed into their respective enclosures, and then re-wired and re-soldered. By some minor miracle, all the electronics worked as they did before the operation took place. A master wiring technician might scoff at the result, but I think that it is a huge improvement.

Without the cover plate:

And with the cover plate:

A ribbon extension cable is on order for the camera, so that it can properly reach from the outside of the boat to the interior of the box.

I had originally intended to build my own printed circuit board to replace the semi-reliable ADC board (the yellowish brown prototyping board in the top-left corner of the above 2 photos). And one morning I set out to do that, but quickly realized that it was going to take weeks. Surely there was something on the Internet already put together? There actually didn't seem to be very much that was suitable, but I did manage to find this: https://store.ncd.io/product/4-channel-i2c-0-20v-analog-to-digital-converter-with-i2c-interface/ It's only 16-bit vs. the 18-bit that I have now, but its sampling rate is 4 times faster, so by maintaining a running average of 4 samples in the software, I should get the equivalent of 18-bit precision. It also accepts a wider input voltage than what I have now, which should help to simplify some of the signal conditioning electronics.

Lastly, some good improvements were made in AMOS's software for holding a fixed heading while driving forward smoothly. The previous control software was usually able to make the boat move forward at a fixed heading, but it was not smooth, requiring the rapid on / off firing of the left and right thrusters to maintain direction, while sacrificing forward speed. The new control algorithm is smoother and faster, and still keeps the boat following a forward course through the water. It has only been tried in the pool so far, but I hope to have it out in the river soon.