Zap Pow! Learning About DC Motor Inrush Current The Hard Way

Happy Canada Day! And Happy In Nature Robotics one year anniversary! 

One potential propulsion alternative that I have been considering for AMOS is the use of robotic water paddles instead of the air propeller. The air propeller requires about 60 W of power at top speed, but only provides about 1 pound of forward thrust. Going against a 20 km/hr headwind pretty much cancels that thrust out completely. But paddling with minimal exertion in my kayak is sufficient to move forward against that same wind.

One simple solution being considered was to use two DC motors to drive articulated paddle arms that locked rigidly when moved in one direction for forward thrust, and bent freely inward in the other direction to allow them to move against the flow with minimal drag. Here's a hand sketch of the motors and arms seen from the back of AMOS:

To test this out, I bought a couple of small DC garage door opener motors, rated for 12 volts, 6 A, and 2.2 foot-lbs of torque each. I also searched around on Amazon for a suitable DC motor driver and was a bit confused by what was available. Most of the drivers allowed for motion in both directions, but seemed to have mechanical switches for controlling either the direction or the speed, which wouldn't really be suitable. This led to some reading about H-bridge drivers (really just 4 simple switches) which gave me the bright idea that I could use my favourite 4-channel relay product to function as an H-bridge driver, since it was rated for up to 10 A, and up to 30 V.

Over the weekend I wired up a 4-channel relay to the motor, a 12 V lead-acid battery, an Arduino Uno microcontroller, and two small limit switches. The Uno was programmed to drive the motor continuously, reversing direction whenever one of the limit switches was pressed. 

When everything was ready, I started up the Uno only to hear a loud popping noise, with a small smoke plume, and the acrid odor of electronic failure. The motor didn't budge. Hmmm... maybe I wired something wrong? About 30 minutes of carefully checking the wiring proved this to not be the case. Hmmm... maybe there was some weird starting condition in the Uno program that resulted in too much initial current going through one of the relays? To test this hypothesis, a second (new) relay board was brought to the sacrificial altar. This time, the battery was left disconnected, the Uno program was started, and then the battery was connected. The motor shaft started spinning. I pressed one of the limit switches; it reversed direction and spun the other way. Pressed the other limit switch and it swung back. "Hey Kirsten, come check this out!", I yelled. "It's working!" Five seconds later smoke started to appear, then pop, pop! Dead again. 

At first I thought that the relay boards weren't really capable of 10 A or even 6 A operation. But I don't think this is the case. It turns out that DC motors actually have a large inrush of current for about 200 ms before they start moving and producing back EMF which limits the steady-state current going through them. This inrush current can be 2 to 3 times the specified steady-state current. So yeah, those 10 A relays weren't going to be able to handle 6 x 2 = 12 or 6 x 3 = 18 A of inrush current. Eventually I was able to locate a reasonably priced dual H-bridge driver board on Amazon that is rated up to 30 A. There is no documentation for it though, so I'll be guessing a bit at how to  wire it and use it. Hopefully no more electronics will be sacrificed! 😏

Don't Do Anything Stupid

My usual launching point for AMOS testing is at the entrance to Woolastook Park, where there is a small parking area. Perhaps the campground is closed because of COVID-19, because the road leading into the park has been blocked this year with a chain, and large stop signs with an additional warning on printed sheets of paper stuck to the signs: !WARNING DON'T DO ANYTHING STUPID!

Is the extra printed sign more successful at preventing stupidity (i.e. driving a vehicle around the barricade) than just  the STOP signs and chain by themselves? Or maybe it has the opposite effect, and incites rash behaviour? (I wasn't gonna do anything stupid, but now that you mention it, maybe I will!)

A lot of the things that I have tried for AMOS seem a bit stupid or absurd in retrospect, and probably would not have been tried by someone with more knowledge or experience with robotics or boats. Our garage is becoming a collection of failed equipment: broken solar panels, strange wooden structures, kayak beer cooler full of holes, kitchen strainers with the handles sawed off, numerous 3D print fails, and a slew of circuit boards and electronics that are either damaged or no longer relevant. 

Yesterday, I thought I had lost the AirProp module, as the base of it came unglued during a test, the propeller snapped off, and the module fell into the water, hanging by its electrical wires to a depth of about a foot. At the time, I was sitting in the kayak on shore, writing some code and waiting for AMOS to arrive. Eventually I realized that AMOS was no longer approaching, so I stashed the laptop and paddled out to investigate. Stupid! (Or maybe lazy?) Should have bolted the base down, and not relied on epoxy (Gorilla Glue I think) to hold it down. It had held well for almost a year, but probably all the hot weather this month loosened the bond (it can get up to about 50 °C inside the electronics boxes). The plan was to have AMOS spell out something in the water, but I guess that will have to wait for another day:

I figured the AirProp was dead for sure, so I ordered some replacement components from Amazon, After drying out the AirProp module in the hot sun for a few hours though, I tested it out and it actually worked fine! This evening I secured the base of the AirProp properly with a couple of bolts to the electronics box. 

So if there is a moral to this blog post, it would be something like: try not to do anything stupid, but don't worry about making mistakes while learning. Sometimes it all works out OK in spite of your mistakes, and sometimes it doesn't. 😀

Mastery of Remote Settings

It's currently 1:20 am so this blog entry will necessarily be super-brief. The past week seemed to fly by with webinars, meetings, proposals, and thankfully a bit of actual development work on AMOS's communications software for sending / receiving settings. Here is a screenshot of the new interface for configuring how alarms are sent to AMOS:

The rest of this week will be spent finishing up a proposal, and then hopefully there will be some time to get the boat back in the water. It's getting very close to the summer solstice, a happy time of year for solar powered vehicles. It would be fun to see how far AMOS can go (downriver?) in a single day at this time of year! 😎

Under The Bridge Obstacle Course

It had been a couple of weeks since AMOS's last trip on the river, and I was wondering if it would be possible to capture some good video from the deck of a bridge while AMOS traveled underneath, so on Sunday I brought the boat down to the boat launch at Carleton Park and set it on a course that would meander around the Bill Thorpe walking bridge for a while before heading back to Carleton Park. I enabled the LiDAR module for "obstacle avoidance" mode, in order to make sure that the boat did not crash into any of the large concrete pilings. I also brought the kayak in case anything went wrong, and paddled ahead of AMOS to the bridge, stowed the boat in some bushes, and then climbed up to the deck of the bridge to start filming.

The wind was coming out of the north at a about 13 km/h and the current was relatively strong, so AMOS arrived at the bridge quickly, but overshot a little bit and passed underneath before it was supposed to. Thereafter it fought gamely against the wind and current to get back on course, but tended to either (i) move backwards a bit during strong gusts or (ii) encounter a bridge piling obstacle, which resulted in the boat changing course to avoid the collision. The software navigation algorithm moves on to the next waypoint if it detects that the boat is either losing ground or has surpassed a particular waypoint, so the net result didn't actually turn out too bad. In the image below, the yellow path corresponds to the intended route, while the white is the actual route:

Although the weather was overcast and slightly rainy, AMOS still managed to last nearly 2.5 hours before it shut itself down to re-charge, just about 50 m from the planned destination!

Here is a collection of some of the images and video that I took, as well as some of the images that AMOS took with its camera:

Last but not least, here is the depth and temperature data:

Depth

Temperature:

Making Life Easier For Future Users

Software development this week was concentrated on the communications routines for manually controlling AMOS and for loading and controlling the remote script files that are available on the robot. Until now, there was no easy way to modify the execution of a currently running script once it  was started. For example, if I wanted to skip a few steps in a running script file, I would need to send a command to stop the script and the master program, establish a network terminal connection to the boat using PuTTY, manually edit one or more files, then re-start the master program with the modified script file. This was always a bit of a nuisance, and not something that I would expect future users to put up with.

To that end, a simple dialog interface was built for viewing the status of a currently running script, skipping forwards or backwards through it, viewing other scripts available on AMOS or locally, uploading new scripts, etc.

Here is a short video that shows the new interface:

The screen recorder software that I used had an interesting sound effect for each mouse click. I think I'll disable that feature for future screen videos!