Tuesday, June 30, 2020

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! 😏

Tuesday, June 23, 2020

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



Tuesday, June 16, 2020

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! 😎

Tuesday, June 9, 2020

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:





Tuesday, June 2, 2020

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!

Tuesday, May 26, 2020

New Look For the Website!

Jata has been working on improving the appearance of the website; you should definitely go have a look: https://www.innaturerobotics.com/. There are now alternating pictures on the main page, color schemes consistent with the company logo, nice looking fonts and text that is properly lined up, and overall just way better organization and appearance!



This past weekend I realized that so far this year AMOS must have been using an incorrect magnetometer calibration file. I must have copied over an old version of the file by mistake at some point over the winter. Certain orientations like east or southeast were still fairly accurate, which explains why the first couple of tests in April, where AMOS was travelling southeast down the St. John River went well. The previous method that I had used for calibrating the magnetometers involved maximizing and minimizing the X, Y, and Z magnetometer signals by slowly rotating the AMOS- IMU around and observing the data outputs on the screen until the observed min and max values no longer changed. This method could give inaccurate results however if for example there were some occasional spurious low or high outputs. So I decided to try a new method for calibrating just the X and Y magnetometers by rotating them slowly in a horizontal circle. By doing this, it was possible to use an iterative best-fit method to accurately estimate what the X and Y sensor offsets were. Testing out the calibration later on, the accuracy seemed to be typically within +/- 10 degrees, which is good enough for AMOS's navigation needs. On Saturday I took the boat out for a test in the same spot as the week before. It followed the track pretty well, and no towing was required, although I did need to push the boat away from some overhanging trees a few times, since I had forgotten to bring the chicken wire cage to protect the propeller.

The yellow dots and lines correspond to the planned waypoints and routes respectively. The white dots and lines correspond to the actual route that AMOS took, as measured by the GPS. The wind was pretty strong that day, so it was good to see that it could navigate the 4 km course correctly in about two hours.

Here are the interpolated versions of the depth and temperature that the fish finder recorded:



At the moment I'm updating the BoatCaptainMap software to include a lot of the functionality that the old version of the c++ application had. I created a C++ DLL from the old existing code to handle the communications routines, since these were a bit of a pain to write and I didn't want to do it again in c#. I also re-used some of the bitmap button images (stop sign and arrow buttons) from the old app in the new one:


At some point, these will need to be made over too, but for now they're good enough.


Tuesday, May 19, 2020

Fish Finder Depth Sensor

Sadly we did not win one of the five Volta Cohort investments last week, but it was still a valuable experience nonetheless. We were able to practice refining our pitch and improve the focus of the business, which should help us going forward.

The next couple of days were spent writing driver software and hooking up cables to convert the RS-232 output from the fish finder into depth measurements for AMOS's Raspberry Pi. I bought a 3 foot long RS-232 to USB cable for this purpose, but couldn't find the male DB-9 plug for soldering that I thought I had lying around somewhere. So  I snipped the cable near the end and pulled out the bare circuit board inside:


This afforded some better soldering points for the white, green, and black wires on the top surface of the board. And as luck would have it, I didn't mix up the green and white TX/RX cables.

The fish finder outputs NMEA 0183 sentences in ASCII text at 4800 bps, something like this:

$INDPT,1.1,0.0*47
$INHDG,,,V,,V*60
$INHDT,,T*0B
$INGLL,,,,,,V*16
$INVTG,,T,,M,,N,,K*5E
$INMTW,10.1,C*14
$PSMT,0,0,0,2,appver,0*28
$INDPT,1.1,0.0*47
$INHDG,,,V,,V*60
$INHDT,,T*0B
$INRMC,,V,,,,,,,,,*21
$PSMT,0,0,0,2,appver,0*28
$INDPT,1.1,0.0*47
$INHDG,,,V,,V*60
$INHDT,,T*0B

The lines that matter are the ones that start with either $INDPT or $INMTW. These correspond to either depth or temperature respectively. Fortunately there are lots of websites around that summarize what the NMEA sentences mean, so I didn't need to pay $1000 or more for the official standard. Writing the software driver for the Pi to parse this info was pretty straightforward. Just needed to make sure that the software polled the serial port frequently enough to keep the depth data current. Depth is sent out only once per second by the device, so it's not exactly a compute-intensive task.

On Sunday Kirsten and I took advantage of some good weather to take the canoe and AMOS out for a test. Unfortunately AMOS kept veering off to the left for no known reason. A later inspection back at the house indicated that one of the electronic compass wires had come unplugged. The following day I tried again, but the same thing happened, it kept trying to go west when it should have been going north. Wanting to test the fish finder anyway, I towed AMOS around in the kayak for about an hour. I didn't cover quite as much water as I thought I did, but the results for the depth measurements were pretty good:


and with interpolation turned on:


That evening I checked the compass calibration on the grass in our backward and found that it was indeed off by about 90 degrees, i.e. when the boat was pointed north the compass output indicated that it was facing east. I'm not sure yet if this is some new hardware problem, or if the compass calibration got messed up somehow and needs to be re-calibrated. Hopefully that'll get solved tomorrow.