Tuesday, September 22, 2020

Foggy False Obstacles

This past week has been mostly filled with preparations for my upcoming pitch in the Ocean Startup Challenge this Thursday (the 24th), but I did find a bit of time to get out for a quick test on Monday morning. The air temperature was quite cold that morning (a low of 0 °C the night before) so there was a lot of fog on the water when AMOS was starting out:

Similar to what happened a couple of years ago on a foggy day (although with a different LiDAR model) AMOS was detecting a number of false obstacles due to the laser light from the LiDAR reflecting back from the water vapour. AMOS would turn in place until it found a "fog-free" direction and then proceed for a while before changing direction again. This slowed things down a bit at first, but soon the sun burned the fog away and AMOS sped from one end of Kelly's Creek to the other, a distance of almost 6 km in about 80 minutes:

I had to work pretty hard to tow AMOS back to the van in order to get back home in time for lunch and work at Measurand.

My slides and presentation are ready for the pitch on Thursday, although I'm meeting with some people tomorrow to get their feedback, so they might still need a bit more modification. Anyone who is interested can view the slides and speaking notes here:


Tuesday, September 15, 2020

More Capacitors = More Speed

 Work this week continued on efforts to re-wire the electronic speed controller (ESC) behind the propeller motor. This took way longer than I had planned, and involved swapping out the motor, swapping out the electronic speed controller, re-soldering all of the connections, re-calibrating the ESC, learning what all the ESC beeps meant and modifying the calibration software to be able to adjust all of the parameters according to those beeps. No matter what I tried though, the motor was always very choppy when run at medium to high speed. With nothing left to try, I resorted to Google, which fortunately came up with this web site that had a good discussion about some of the problems that can result with an ESC if your cables delivering DC power from the battery are too long: https://www.rcgroups.com/forums/showthread.php?952523-too-long-battery-wires-will-kill-ESC-over-time-precautions-solutions-workarounds

By positioning the ESC outside the box and behind the propeller, I had lengthened the cables delivering the 12 VDC power to the ESC by about a foot or so. The problem is not the extra bit of resistance that this adds, but rather the extra inductance that it adds. The inductance results in voltage spikes at the ESC, which can apparently result in erratic performance of the motor. The solution is to add extra capacitance at the ESC to help smooth out the voltage fluctuations. There is already a 30V 220 μF capacitor on the ESC, but the rule of thumb specified in the above website is to add an additional 220 μF capacitor for each additional 10 cm of power wire length. I added three 330 μF capacitors in parallel over the voltage inputs to the ESC. They were only rated for 25 V, but they seemed to improve things quite a bit, and were able to allow the motor to run at a normal speed.  I also tried adding an additional 330 μF capacitor to see if it might allow the speed to increase further, and it did a little bit, although not quite as much as I had hoped. 

So now there is an ugly cluster of capacitors and an ESC mounted behind the propeller. These would need to be weatherproofed with some silicone or other material if used outdoors on a consistent basis. Better positioning of the solar charge controller would also allow me to shorten the wire leads that power the ESC. Really the only reason for positioning the ESC behind the propeller is to keep it cool. Having it inside the electronics enclosure risks having it heat up to 110 °C on hot days, at which point the ESC firmware immediately cuts its output power by 50%. This sort of thing was happening occasionally back in August when the weather was sunny and the outdoor temperature was close to 30 °C.

Cluster of capacitors are shown here circled in red.

On the weekend I took AMOS and its new capacitors downtown for a test run, and was happy that it beat its old record for going up and down the downtown section of river by 5 minutes: from 47 minutes to 42 minutes. The dissolved O2 levels were good too - I guess those are going back up again now that the water is cooling again:

Tuesday, September 8, 2020

Ocean Startup Challenge!

 There was a big announcement today for In Nature Robotics: we were one of 31 companies out of 158 applicants to be picked for the next round of the Ocean Startup Challenge: http://www.oceanstartupchallenge.ca/announcements/. Starting this Friday, there will be a week of presentations and workshops to get ready for a final pitch presentation, sometime between September 22 and September 24. The 31 companies will be competing for 10 prizes of $25k plus in-kind support. It seems sort of similar to what we went through back in May for the Volta competition; except more of an overall ocean theme. 

I took a couple of days off from AMOS this week to go on a fun family camping trip at Spednic Lake. It would have been nice to try out AMOS there, but the van was packed tightly to the roof with camping supplies, so it wasn't possible. I did manage to get some 3D models of the new WeatherBox put together and tested for water-tightness though. Here is a picture of the component parts (no more little nuts or bolts required!!!) and a picture of the put-together unit (minus the interior locking piece):

The only thing that needs to be modified is that the camera board is recessed a bit too far inside the enclosure, so that you can see tiny smudges of black (from the enclosure) in the corners of the field of view:

(Please ignore the terrible state of this lawn. 😀)

To fix this, I can try to either (i) elevate the level of the camera board inside the enclosure, or (ii) trim down the thickness of the enclosure a bit. 

I have also been working on re-wiring the electronic speed controller (ESC) to situate it behind the propeller. Unfortunately though, I think I may have broken one or more of the wires going into either the ESC or the propeller motor today, as it was functioning sporadically, depending on how I moved the wire around. I'll try a replacement motor tomorrow, and if that doesn't work I'll try replacing the ESC.

Tuesday, September 1, 2020

Back From The Wilderness

 Avid readers of the blog may have noticed that there was no entry last week; that was the first time in over 2.5 years that the weekly update was missed! Without going into too many details, a long 15 hour bike ride through New Brunswick trails and back roads turned into an even longer 24+ bike ride due to some navigation errors that resulted from poor preparation (forgot 1 phone charger and the other 2 chargers that were brought were not charged, did not bring a printed map (only printed directions), and did not bring proper equipment to change a bike tire, which turned out to be necessary for the last 50 km or so). After being rescued and returned to safety, I was in no condition to think about the blog, and thereby felt justified in skipping a week to catch up on some sleep. Many thanks to Kelly and Dad for searching for us and rescuing us after this misadventure. 

The last time I had AMOS out for a test run was on August 22 at Kelly's Creek. One thing I happened to notice around the middle of this test was that the air propeller motor would sometimes audibly switch down to a lower speed, resulting in a somewhat lesser thrust. Going with the wind the reduction in thrust was not an issue, but on the return trip it was. Some testing in the backyard the next day revealed that the electronic speed controller (ESC) board output power became significantly less when it overheated. Currently, the ESC is sitting in the bottom of the back electronics enclosure, with the battery and a bunch of other electronics, so it makes sense that it could get pretty hot, especially if the weather outside is sunny and warm. By positioning the ESC outside the box, behind the propeller in the airflow however, the output power remained stable, presumably because the ESC was sufficiently cooled. Apparently drone makers know this already; there are instructions available on the Internet for applying a silicone conformal coating to the ESC board to protect it against moisture. The weather is starting to get cooler here, so I might not notice the overheating effect in future tests, but I think I'll re-wire things to put the board outside behind the propeller anyway. 

 Efforts are currently underway to re-design the WeatherBox (i.e. the waterproof enclosure for the camera on AMOS). I would like to get rid of the nuts and bolts and just have a window cap that screws directly onto the enclosure. This would make assembly a whole lot easier, and should look better too. Here are 3D printed versions of the base enclosure piece and an initial window cap (without the plexiglass window) screwed together:

This past week was Jata's last as an intern at In Nature Robotics. One of her projects was an online 3D modeling / ordering tool for AMOS. I have been trying to teach myself 3D modeling using TinkerCAD and other 3D tools to continue her work, but so far have not had much luck. Importing and exporting with these tools tends to do unexpected things to the models. Possibly it is just user error though!

Tuesday, August 18, 2020

Read The Fine Manual

 Last Wednesday I was able to confirm by looking at the end of the dissolved O2 probe with a magnifying glass that there was a small crease in the membrane that was allowing air and water to leak in and electrolyte to leak out. So that confirmed why the previous readings had been getting progressively worse. Here is some better data collected at Woolastook with more electrolyte added and a new membrane over the end of the probe:

As you can see in the above screenshot, this time AMOS followed a route through the middle of the water, where it was relatively deep and there was little danger of damaging the end of the probe by dragging it against rocks, sticks, or other objects. The following graphs show the dissolved O2 data collected so far out at Kelly's Creek and near downtown Fredericton:

The results recorded in early August should be ignored, as the probe was most likely leaking at that time.

We entered an application in to the Ocean Startup Challenge last week: https://www.oceanstartupchallenge.ca/. I know of at least a few other people that have also entered submissions, so probably this contest was quite popular. On September 04, we will know whether or not our application made the short list. 

Just this evening I finished a 6-page quick start manual for getting up and running with AMOS. It hasn't been tested on anyone yet, although Kirsten volunteered to try it out and see if she could get it to work, so I'll try to take her up on that. Check out our support page: https://www.innaturerobotics.com/support to have a look. RTFM! 😀

Tuesday, August 11, 2020

Leaky Dissolved O2 Sensor?

 After acquiring a few weeks of experience with the new dissolved oxygen sensor on AMOS, I am unfortunately a bit disappointed with its performance. Software-wise and electrically it worked great. They have some nice simple I2C and serial commands for getting data and calibrating, and you can get temperature compensated data at a rate of about 1 Hz. The bad part is that the calibration doesn't seem to hold for more than a few hours. The sensor probe is a galvanic one, in the sense that it uses an anode and cathode surrounded by an electrolyte to produce an electric current (and small voltage) when oxygen molecules cross over the probe's membrane. If I fill the probe with electrolyte (requires ~ 2 ml), calibrate, and then do a test run with AMOS, the results seem generally pretty good. If I go out again even just a few hours later, the results seem a bit lower, and then lower still the next day. Even re-calibrating doesn't really seem to work very well if it has been a long time since the initial filling of electrolyte solution. The membrane on the probe is quite thin, and a bit flimsy (slightly thicker than saran wrap), so I'm wondering if it just doesn't make a very tight seal? The online shop where I bought the sensor sent me an email request to review it, so I gave it a mediocre 3 stars with a description of the issues I was having. They said that they would forward my comments to the manufacturer, so we'll see if I hear back. 

Anyway, here are some pretty good results obtained near downtown Fredericton on Saturday, about an hour after filling with electrolyte and calibrating:

The dissolved O2 readings were all within a narrow band of 9.1 to 9.2 mg/L, which is a normal, expected level for the amount of oxygen dissolved in water. 

Later that afternoon I took AMOS out to Woolastook to collect some more data, but this time the readings started off a bit under 9 mg/L, jumped around a bit, and then seemed to gradually drift lower to under 5 mg/L as AMOS traveled along the 4 km route:

Today I re-visited Woolastook, and performed a re-calibration before leaving, but did not re-fill any of the electrolyte. This time the dissolved O2 started off at around 7 mg/L, and then dropped down to nearly 0 mg/L about halfway through the test: 

Since I saw a number of small fish swimming around, I don't think the level could have possibly been that low! I'll try going back tomorrow, but will top up the electrolyte again to see what difference that makes. The probe manual is vague about how often re-calibration is required, but does say that the electrolyte should last for about 2 years before it is depleted. Perhaps there is an issue with dragging the probe behind AMOS? It is mostly horizontal while AMOS is moving. Or maybe the probe membrane is getting damaged by dragging it through shallow water, grass, etc. close to the shoreline? I'll try not to waste too much more time on this, but these things kind of bother me! 😖

Tuesday, August 4, 2020

Paddle Test Take 2

Despite the 3-D printed "paddle fail" of a couple of weeks ago, I had not given up on the idea of 3-D printing something for paddle propulsion. This time around, I made a simple rectangular paddle with a hollow tube along one edge for mounting onto the motor shaft. To test out the concept and see if a pair of paddles would generate sufficient thrust for AMOS, I used a chisel to gouge out some motor mounting holes in the old surfboard, and wired up (this time properly!) the DC motor controller to an Arduino Uno, and wrote a simple program for driving both motors at the same speed. 

It seemed like maybe it was faster than the air propeller version, although to be certain I guess I would need to program both boats for the same GPS course and race them against each other. It still remains to be seen how the paddles would fare in some of the weedy locations that the airboat frequents. This video recorded on the weekend shows the airboat version of AMOS moving through some pretty dense river grass (although the depth transducer and turbidity probe had to be pulled out of the water to minimize drag):

While AMOS was traveling through the river grass, it was also measuring the dissolved oxygen content of the water. From the few tests that I have done in the river near downtown Fredericton and out at Woolastook over the last couple of weeks, it looks like the dissolved oxygen content is dropping.  Here is the latest dissolved oxygen data from downtown Fredericton:

Dissolved oxygen content near downtown Fredericton on Aug. 02, 2020 varied from 5 mg/L (purple) to 9.1 mg/L (red). 

Unfortunately our humid weather over the last few weeks coupled with repeated testing has dissolved the construction adhesive that was bonding the foam pontoons to the aluminum plates. To remedy this, I spent about $13 for a tiny package of two-part "marine" epoxy. It is supposed to offer a bonding strength of 4000 psi, and be waterproof. So we shall see. I re-bonded the delaminated sections a few days ago, and it seems to be holding quite strongly so far!

Tuesday, July 28, 2020

AMOS: Will Work For Beer!

This past weekend I had some time to take AMOS out on the St. John River in a couple of locations to test out the new dissolved oxygen sensor. The first location was just south of the Walking Bridge in downtown Fredericton, near the West bank of the river. AMOS did a short up and down run there on Friday and Saturday:

Dissolved oxygen levels on Friday (July 24) ranged from 14.2 mg/L to 15.6 mg/L. There had been a strong thunderstorm with about 10 ml of rain, about 5 hours before the readings were taken. Rain water absorbs oxygen from the atmosphere as it falls, so that can increase oxygen levels in surface water, especially near land where the runoff flows into the river.

Dissolved oxygen levels on July 25 ranged from 12.1 mg/L to 12.9 mg/L. The water appeared slightly more cloudy, but there was no visible evidence of any algae.

Later, on the afternoon of the 25th, I took AMOS to the Kelly Creek Basin area near Woolastook. This water was more sheltered, and I wondered if algae would be more plentiful there, with an associated lower level of dissolved oxygen. Indeed, there definitely was more algae, which was noticeably visible in some shallow pockets of still water:

There was also some petroleum-based material just below the algae in this photo.

AMOS recorded more variation in dissolved oxygen here, with levels ranging between 11.1 mg/L and 15.5 mg/L:

The low-ish purple readings in the above image near the small island were near several small patches of algae, where the water was fairly shallow. I would have expected the readings in the small sheltered cove in the western edge of the above map to have had lower dissolved oxygen readings, but actually these readings were at a uniformly good level of about 13.75 mg/L. This area also happened to have a large amount of water grass and other vegetation growing in it, which probably offered a beneficial photosynthesis boost to the oxygen levels there. 

I was able to observe a number of small fish in the water, and there were a few people out fishing as well. A couple of them enjoyed paddling out to meet AMOS in the water, and were impressed that it stopped before hitting them and turned to go in a different direction. They even gave AMOS a can of beer. 😊

Tuesday, July 21, 2020


This weekend, a second attempt at writing a complete geo-message on the St. John River was made:

Due to the cloud cover that day, AMOS didn't have enough charge to complete the approximately 10 km message: "AMOS WAS HERE". The intended route was indicated in the above screenshots by the yellow path. The GPS points listed in the ship's log file are the white points at top, and the measured depth data (collected every second) appears below.

The dissolved oxygen software was coded last week, and the actual equipment arrived yesterday, so hopefully tomorrow I'll find some time to hook it up and try out the calibration routine (it can be calibrated in air to atmospheric oxygen levels). 

A few days were also devoted to working out some bugs (really just code that was never finished) for various network communications routines in the new BoatCaptain user software. 

We are also now trying to find beta test locations for AMOS. If you happen to know of anyone needing automated, geographically distributed water monitoring (preferably in Atlantic Canada), please let me know!!! 

Tuesday, July 14, 2020

Poor Printed Paddle

This evening I thought it might be cool to do a video demo for the blog of the prototype paddle that I 3-D printed. Until you actually try something, you're never really sure how it's going to go. Hope you have a good laugh:

The paddle was hinged so that it would bend freely in one direction but would be unable to bend in the other direction. In theory, this would allow a back and forth motion of the paddle to propel AMOS forward. I guess I'll need to think some more on the mechanical design of this one.

Today I also started writing some code for a new dissolved oxygen probe from Atlas Scientific. It uses an I2C interface and is fairly well documented, so it shouldn't be too hard to add. It had been on back order for about a month, but just shipped yesterday, so hopefully it will be here soon:

Other software work this week has been completed on the Boat Captain program for downloading data and log files from AMOS. 

On Friday afternoon, I did a short live demo of AMOS in downtown Fredericton. Everything worked great! Here's the track comparison image, depth data and a nice picture that AMOS took before it returned to the launching point:

Tuesday, July 7, 2020

New Distance Record

AMOS set a new single-trip distance record on the weekend, but just barely: 10.95 km. According to this blog, the previous record was 10.85 km set last year. I had a route planned for a little over 12 km, but ran into a strong headwind on the final stretch and had to leave to go home for supper. Here's a video of the boat approaching the Walking Bridge:

Lots of people in motorboats paused to inspect AMOS on its journey, but luckily no one took it. Perhaps the crazy jumble of wires coming out of the back box act as a deterrent. I should probably transfer the warning text that I made for last year's AMOS to this one.

Here's the route that AMOS took, expressed as depth data:

The new 30A dual-motor driver arrived in the mail this week and I eagerly hooked it up to try it out, but goofed and reversed the + and - 12 volt battery wires by mistake. So... I never got it working and it now seems to be a brick. A replacement is on its way, but according to Amazon it's not expected until September. I got a shipping notification today though, so hopefully it won't really take that long.

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:



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:


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.