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.

Tuesday, May 12, 2020

Ready to Compete!

Our 3 minute pitch presentation was re-worked and fine-tuned this week and in my unbiased opinion it looks awesome! The big event happens tomorrow (Wednesday) at 5:30 pm AST, see https://voltaeffect.com/cohort/ for links to watch online. We are scheduled to be the 4th of 15 teams presenting, at 5:55 pm.

I had been hoping to get AMOS out on the water this weekend for a bit, but the weather did not really cooperate:


We got over 15 cm of snow on Saturday, May 9!!! There isn't really a spring season in New Brunswick. Just winter, 2nd winter, and then black fly season.

Last week this new little GPS stick arrived:

so I plugged it into the Pi and tried it out. From a cold start it wasn't as fast as advertised. It took 5 minutes to find 4 satellites (instead of the advertised 29 seconds). But this was still quite a bit faster than the 15 minutes that it was sometimes taking for the old GPS unit. The specified average accuracy was 5 m, and a quick backyard test (no I didn't really jump over the fence with AMOS) seemed to confirm this:


It's kind of a scary amount of detail that you can get in this Esri / ArcGIS mapping software... it allows you to zoom in even more than the level of this picture. Good thing I wasn't nude sun-bathing when the satellite took that picture. 😎







Tuesday, May 5, 2020

Fish Finding and Pitch Preparation

I produced a rough draft of our PowerPoint presentation for next week's Volta Cohort pitch competition (see https://voltaeffect.com/cohort-finalists-spring2020/) and Jata did a great job of re-arranging basically everything so that it looked really good! Today we did a sound / video check for a smaller Volta pitch competition which takes place tomorrow at noon. I think if you want to see it you can get a free ticket from eventbrite here: https://www.eventbrite.ca/o/volta-3570959959. The main event pitch competition for a $25000 investment in the company takes place next week, May 13.

Getting ready for the pitch hasn't left much time for hardware / software work on AMOS, but I did get a bit of code written on adding live mapping capability to the BoatCaptainMap app and did 3D-print some parts for mounting a fish finder with its ultrasound transducer to the back plate of AMOS. No, AMOS is not looking for fish, but I read somewhere that using a fish finder was the most economical way to do water depth measurements, so I figured it would be worth a try.

The fish finder uses the +12V from the AMOS battery for power, and has a cable going to an ultrasonic transducer. Normally the transducer would be mounted onto the transom of a boat, but I
3-D printed a part to secure it to the back plate, just to the right of the pH probe in the above picture. The fish finder also has a NMEA-0183 output, which sends out depth readings every second. The NMEA standard is available but it has a ridiculous price, something like $1000 or more, depending on what industry you're in. From all the free information that I could find online, it seemed like the NMEA-0183 output was basically an RS-422 signal. So along with the special NMEA-0183 cable I bought for the fish finder, I bought an RS-422 to USB converter for AMOS. But once I actually got the cable and looked at the instructions, it turns out that the signal is actually RS232, not RS-422. So this evening I just ordered a 3 foot USB to RS232 cable from Amazon which should do the job. Hopefully over the next few days I'll find some time to drill more holes in the AMOS boxes, and solder some wires to connect everything together. I'm looking forward to burning my fingers again, it's been awhile. 😄

Tuesday, April 28, 2020

Volta Cohort Pitch Competition

Back in March, our controller at Measurand mentioned a competition that I might be interested in: The Volta Cohort Pitch Event (https://voltaeffect.com/cohort-finalists-spring2020/). There was a written online application with a number of questions pertaining to your business. 15 applicants would be picked to pitch their business at an event in Halifax on May 13, and up to 5 of those would win investments of $25000 and become part of the Volta cohort where they would receive mentoring and assistance with their business. Last week an email arrived to say that In Nature Robotics had made it to the group of 15, although due to  COVID-19 the pitch event will be held entirely online. So Jata and I will have to figure out what to tell people about the company in a 3 minute online PowerPoint spiel. No problem!

Last week was also favorable for testing, although not at first. On Saturday I drove down to the same launching point as the week before, but it was much windier, and the current looked even stronger. While I was waiting for a GPS signal and making some adjustments to the protective cage, the GPS signal actually came through and the propeller whirred to life, knicking two of my knuckles. I had considered moving to a beefier more powerful propeller, but now I'm glad I didn't! Here is a short video recording of the current, which doesn't really do it justice:


I had wanted to try out some new software that had just been coded that morning. As sometimes happens, there was a tiny bug that ruined the entire test. I had forgotten to convert a heading variable from radians to degrees, which totally messed up the new algorithm to skip waypoints that the boat had already passed. So after the boat had struggled against the current for about an hour I gave up and towed it back. 

Sunday was much better. It actually would have been nice to have some strong wind and current to really test out the fixed software, but the current seemed a bit less, and there was scarcely any wind at all. It took the boat about 2 hours to go from the launching point down to a point a little beyond the Westmoreland Street Bridge, a trip of about 9 km. On the way it collected pH and temperature data, and took a number of pictures:

The route AMOS followed (I towed it upriver along the shore).

Temperature Data (with interpolation turned on)

pH Data (probably not accurate, I'm going to try cleaning the probe before the next test).

One of the planned pictures was this one of the Delta Fredericton.

Zoomed in shot of some guy in a kayak.

Nice shot of Westmoreland Street Bridge.

It took about 2 hours to tow AMOS back to the launching point, and since it was a nice day many people were out walking and biking. Quite often they would ask what I was towing and one lady even took my picture. I did my best to give them a short explanation; it was probably good practice for next month's competition. 😊

Tuesday, April 21, 2020

How to Run Down The River

This past weekend we were blessed with some nice warm, sunny weather so it seemed like an ideal time to try out the new AMOS-Cat boat on something more significant than the large puddle in our backyard. On Saturday, I biked down to the St. John River to check out a prospective launching area about 8 km upriver from the main downtown core of Fredericton. The spot had a bit of a parking area for 5 or 6 cars and a nice inclined path leading down to the water. The current looked a bit fast, but not so fast that I couldn't tow AMOS upriver in the kayak if necessary.

So I mapped out a course that would take AMOS about 8 km down to the Westmoreland Street Bridge, collect some sensor data and collect pictures at selected locations en route:


On Sunday AMOS started the course shortly after noon. There was the usual 10 or 15 minute wait for a valid GPS signal (a new GPS is on its way which should hopefully speed that up) and then it was off down the river. The strong spring current pulled it along rapidly at first, but it tended to overshoot the interpolated waypoints (there are 10 interpolated waypoints between each of the yellow markers shown above) and then reverse direction to try to get back to the waypoint that it had missed. The software has an algorithm which gives up on trying to reach a particular waypoint (and moves on to the next one) if the distance to that waypoint increases over any 4 minute interval. The problem on this day though was that in most places AMOS couldn't make any forward progress against the current, so it spent a lot of time just "hovering" out in the middle of the river, or even moving backwards in areas of strong current. I will need to change the algorithm to move onto the next waypoint whenever the direction to that waypoint is opposite to the intended direction of the planned route. That will result in some loss of waypoint achievement accuracy, but it should be preferable to waiting for long periods of time while the boat is barely moving against a strong current.

AMOS made it about 2 km down the river before I gave up and decided to tow it back upriver with the kayak. This was about 45 minutes of hard paddling! Here is a map of the route that AMOS took:


The return trip was much closer to shore to avoid as much of the current as possible and because the water was still freezing cold.

Lots of people were out walking on the nearby river trail, and many of them asked about the robot (safely from a distance) so I guess it was good publicity, even though it wasn't quite functioning as intended. Here is a short video taken of AMOS moving upriver in an area where the current wasn't too bad:






Tuesday, April 14, 2020

Backyard Puddle Test

We had a fair amount of rain yesterday and last night, which combined with the leftover snow from winter to make a giant puddle in the corner of our backyard. Although it didn't really provide quite enough room for AMOS to get going, I felt the need to try out the boat in  some actual water for the first time this year:


The boat quickly became fetched up on an alder and needed to be rescued by wading part-way into the puddle and reaching for it with a hockey stick. This version of AMOS (AMOS-Catamaran or AMOS-Cat for short) seemed to have about the same draught as the surfboard version, i.e. about one cm, maybe a bit more at the back end due to the weight of the battery.

A lot of work was done this past week on the new version of the PC BoatCaptain software for controlling AMOS and viewing info on ArcGIS maps. I was able to get the boat route, safety locations, and photographic locations all to appear properly in the application and in the saved web maps, and was also able to load those saved web maps into the application. For some reason though, I could only view multi-colored data points from within the application; when I tried to save a map with multi-colored data points in it to the web, all of the points in the web map became the same color. I suspect it's just a limitation of the SDK that I'm using, or the web service that does the saving of the map, but I asked a question on a relevant forum to see if anyone else knew.

For this week I want to focus more on the new BoatCaptain software for controlling and interacting with AMOS. The weather is quickly warming up and it will soon be time to start collecting more test data!

Tuesday, April 7, 2020

Happy Birthday to That Hobo Who Works in Our Backyard Playhouse

There is a bit of a running family joke that there is a hobo squatting in our daughter's playhouse. I have been using the playhouse as a work space lately in the afternoons when the sun is out. It is nice and quiet there, without any of the distractions that are typical within a 5-person home. Today was my birthday, so unbeknownst to me, Kelly went out in the morning to decorate it before my afternoon work session:


Much of this past week has been spent re-writing the graphics code for the new version of the desktop BoatCaptain software. I eventually figured out the methodology required for creating graphics in the application's map that will also show up the same way in a version of the map stored on the web. Saving simple symbols was fairly straightforward, but getting custom image icons (using the "PictureMarkerSymbol" .Net ArcGIS class) to save properly in the version stored on the web took me hours to figure out. It turns out that you need to explicitly define the dimensions of the PictureMarkerSymbol, otherwise it won't display at all on the web.

For example:
    
      PictureMarkerSymbol crossMarker = new PictureMarkerSymbol(new Uri(sImagePath));
      crossMarker.Height = 20;
      crossMarker.Width = 20;
      
Kelly happened to notice a Facebook post about a boy that had 3D-printed a number of "ear guards" that help to ease some of the pressure on the ears of hospital workers wearing masks with elastic straps that hook behind the ears. The model of the part can be found here: https://www.thingiverse.com/thing:4249113. She wondered if I could make any on my printer, and I wasn't sure; I usually have trouble printing things with small details over a large surface area. After a bunch of tweaks and a few failed prints I was able to find some settings I had never tried before that worked really well. I made 3, which she gave to a nurse she knows, so we'll see if they're actually useful or not. The new 3D printing configuration also worked really well for this pH probe holder that I just made today:







Tuesday, March 31, 2020

Box Cat AMOS and Old Dog Learning New Software

The bottom half of the Catamaran AMOS was fiberglassed this week and the whole thing (without electronics) weighed in at 14.6 lbs. This is a bit heavier than the fiberglassed AMOS surfboard, which was only 10.6 lbs, but is to be expected, since the aluminum plates joining the Catamaran pontoons weighed 6.8 lbs. I feel like it would definitely be possible to cut a few pounds by using smaller plates, but this should be OK for now.

Ideally I would like to use smaller electronics enclosures than what I used before, and embed them into the pontoons to cut down on wind resistance, but I'll hold off trying that until after verifying the maneuverability of the boat in the water. So for now, it's just the same old electronics boxes:


The rest of this post will delve a bit into programming nerdiness, so if you have something better to do, go ahead and x this browser tab, I won't mind.

I have neglected the actual code operating on AMOS for a few months now, not really wanting to write something that couldn't be easily tested with all the local waterways frozen. Adding the code for reading in files with picture commands and then taking high resolution pictures at the desired heading(s) could be easily tested indoors, so that occupied a day or two, and seemed to work fine.

The mapping application for AMOS (called "BoatCaptainMap" for now) had some weird disabled navigation arrows in the top-left corner:


They were always there, but for some reason I only just noticed them this past week. After hours of reading, Googling, and frustration I eventually discovered that they were there because I was using a "UserControl" to hold the map grid, when I should have been using a regular Window instead. Fortunately it was relatively straightforward to transition the application to use a Window.

Here is a list of the menu headers and their associated menu items that I have identified for now as being the core user functions required for this app:

File: Load Map, Save Map, Download data file, Download log file, Download image files, Download AMOS code, Send AMOS code, Exit

Preferences: Connection, Alarms, Route, Sensors, Camera, LiDAR (object avoidance), Battery

Data: View data, Map view, Time view, Edit data, Data settings, Export data, Import data

Help: About, User Manual, Website

Some of these functions exist (at least partially) in the older BoatCaptain software, or in test code that I have written recently, but most of them are new functions which will need to be added over the next month or so.

Yesterday I started working on the "Save Map" function, which ideally should take the entire map (of data, or the route, or whatever) as it appears on the screen and save it to the user's ArcGIS account. There are more than a few examples floating around online of how to do this, and I happened to pick one that looked suitable, only to eventually discover after many hours (at 2:30 am) that it was an outdated example that wasn't really correct. I guess security-aware software that uses stuff like OAuth2 or similar technology needs to be updated from time to time, to ensure that it is still as secure as possible. After using more recent documentation and code, I was able to get it working, only to discover that the graphics overlays of sensor points and lines for AMOS to follow that I had in the app were not getting saved to the ArcGIS web map. Argh. Turns out that ArcGIS doesn't allow you to store graphic overlays to their system; rather you need to add things called "features" or "feature sets" to your map, and then those can be properly stored online. I think that the features can actually look the same as graphic overlays, but of course they are programmed differently, so it looks like I'll have to backtrack a bit and re-do most of my graphics code.




Tuesday, March 24, 2020

AMOS Remote Unveiled

Moving into week 2 of the COVID-19 quarantine, my work days are still fortunately much the same as they have been for the last 2 years. Wake-up, eat, shower (sometimes not), work on AMOS-stuff until noon, go for a solitary half-hour ski in the woods, do Measurand stuff until 5, have supper, sometimes go for another ski, do some more AMOS and / or software contracting stuff, then relax for a bit before bed. I guess the only difference is that I'm no longer working in the Measurand building.

This past week I finished populating the components for the AMOS Remote board:



Once my soldering faults were corrected, I tested everything out. The USB to serial wireless connection worked well, but I couldn't properly connect the USB to the Bluetooth (HM-10) board for setting up some default Bluetooth parameters. I looked up the schematic, and pictures of the HM-10 on Amazon (the pins are labeled on the bottom of the HM-10 board), and discovered that the board pin layout was the reverse of what it should have been. After de-soldering and re-soldering the HM-10 upside-down, it worked fine. Reversing the layout of the pins on the mainboard looks like it should be pretty straightforward.

While I was working on soldering, I also soldered up an ADS1115 variable gain board, to get a better picture for the website and instruction manual. The soldering job was better than last time, but still looked a bit messy, and required some hacking around in Photoshop to improve it a little bit:




On the weekend, I spent some time applying fiberglass to the top and sides of AMOS-CAT (the Catamaran version of AMOS). It took me about 2 hours to cut and tape the fiberglass cloth in place on one of the pontoons. Kind of like wrapping a very difficult Christmas present. Thankfully, my daughter Bexie was agreeable to wrapping the other pontoon (for a reasonable price). She was able to do the job in about an hour, and frankly did a better job than I did. The picture below shows the boat after the cloth was applied to the top and sides and epoxied in place. I still need to sand it down and smooth out the bubbles and sharp edges before fiberglassing the bottom.


Tuesday, March 17, 2020

100% Work at Home

I have now switched to working 100% at home, to do my bit to help reduce the infection rate of the COVID-19 virus. The cold that I had last week seems mostly better now, and never developed into a fever or cough, so that's good at least. It's hard to say how long this thing is going to last; if the experience in China is anything to go by, it looks like we will be in for a rough couple of months at least.

On the AMOS front, last week I was able to get some 1/8" thick aluminum plates cut out and drilled by Marcus at Mason & Sons Metal Fabrication and Welding in Rusagonis, NB. Altogether the plates add a bit of weight (~ 6.8 lbs) but they are definitely quite sturdy and hold the pontoons together quite nicely. I also added some 1/4" diameter threaded rods to 6 locations around the perimeter for securing the solar panel with wingnuts. The threaded rods were held in place at first with a bit of construction adhesive, but they still felt a bit loose, so I added some Gorilla epoxy. They seem secure now, but I'll want to test them out a bit, as I suspect they might work their way loose over time. I'm thinking some long slots that the solar panel slides into might work better than threaded mounting posts.

Here is a picture of Kirsten holding the Cat version of AMOS with the aluminum plates:


For now I'll just use the same electronics boxes that the surfboard AMOS had on the front and back metal plates. Later on I might try out smaller boxes recessed into the pontoons themselves. Having the boxes recessed would significantly cut down on wind resistance.

The software user interface for defining where and how to take pictures was completed just today. Here is a demo video that I made of laying out a route that leaves from Liberty State Park and circles around the Statue of Liberty, stopping to take 5 pictures of the statue at each of 4 different locations around Ellis Island. I won't actually attempt a field test of this route; it's just fun to imagine taking AMOS to exciting destinations while I'm stuck inside the house. :-)


Tuesday, March 10, 2020

102 Day Countdown

In order to meet the goal of having AMOS ready for sale by summer of this year, 3 main things will have to happen over the next 102 days:

1. Finish map-based user software for planning routes for AMOS, and viewing previously saved data and live data. PC, iOS, and Android versions of this software will be required.
2. Create documentation for the robot and its associated user software.
3. Update website with software, documentation, product pages, and custom ordering software.

Some progress was made on the first of these this past week. The PC route planning software was updated to allow the user to define "safe" locations on the map (where AMOS can head to if it needs to re-charge) or picture locations where AMOS takes one or more pictures while pointed in a particular direction. The safe locations feature has been implemented on AMOS already, but the picture locations feature is something new. Possibly it's not a great idea to be adding new features at this point, but it seems like a feature that users would like, and it's not exactly straightforward to manually collect pictures with AMOS (like I have been doing up to now) by executing Linux shell commands. Right now the mapping software just requires the user to hold the 'S' key while left-clicking on the map to define a safe location, or hold the 'P' key while left-clicking to define a picture location.





The picture locations will also require some other parameters for specifying camera direction and number of shots. These will be set in a separate interface that the user can bring up with the 'Edit Pictures' button.

A co-worker at Measurand had suggested that I apply to the Volta Cohort: https://voltaeffect.com/cohort/. So I spent a day working on answers to their application questions. I am sure they will be receiving a lot of applications, but if my submission makes their initial cut I will have to go down to Halifax on May 13 to pitch In Nature Robotics on stage against 14 other startups.

The circuit boards for the wireless module arrived successfully from China last week. Coincidentally I developed a cold yesterday, but I'm sure it's unrelated. I've got one board mostly populated, but am just waiting on an FTDI-breakout board, which also happens to be arriving from China.

I drew up some simple aluminum plates for holding the two foam pontoons of the Catamaran version of AMOS together. There will be two 30 x 40 cm plates at either end of the boat to support the electronics boxes, and two 15 x 40 cm plates to support the center part of the boat and give it some structural stiffness. Hopefully the same construction adhesive that I used to glue the foam together will also work on the aluminum. It seems to be pretty strong stuff. Once those are finished I'll apply a fiberglass coating to the pontoons.

Tuesday, March 3, 2020

Meet Jata, Employee #1!

Thanks to some funding support from Venture For Canada, In Nature Robotics is pleased to announce that Jata MacCabe will be the company's first ever employee, working as a sales and marketing intern for the May to September summer term of this year. Jata is a multi-scholarship student and is currently completing her 3rd year of Computer Science at the University of New Brunswick, specializing in information systems. She has also completed a number of business and marketing courses and has extensive experience building and promoting digital communication platforms for small businesses, which should serve her well in her upcoming work term.


In less exciting news, I got the pontoons for the Cat-AMOS nicely sanded to a smooth finish, and visited a metal fabricator to inquire about possibly getting them encased in aluminum. The pontoons as built could not be encased in aluminum, since any welding process would certainly melt them, but it would be possible to make a twin-hull aluminum Catamaran that could be filled with some sort of spray foam, for buoyancy in the event of a leak or damage. The only problem is that any sort of aluminum structure of the size required to hold the solar panel and electronics boxes would weigh at least 35 lbs, probably more. The current surfboard design is only about 29 lbs, with the battery, electronics boxes, and everything included. So I guess I'll be sticking with a fiberglass shell for the foam pontoons. Hopefully I'll take better care around the edges this time to make sure that everything is nice and smooth without any fiberglass splinters. 

I also got more done on the ArcGIS-based mapping software for viewing diagnostic files recorded from AMOS. The following video is an example of the interface for viewing where the boat traveled, and what its internal temperature, voltage, and heading was at any given point of time.






Wednesday, February 26, 2020

In Nature Robotics Expansion?

Thankfully my knee surgery on Monday went well (according to the operating surgeon) so this week is mostly being spent doing computer work in bed or on the sofa. Before leaving for the surgery though, I did manage to cut out a couple of pontoon shapes with the hot wire cutter, that will be later glued together. It was a bit harder to maintain a straight line than I had expected, so some sanding and smoothing will still be required after they are glued together.


I'll also need to cut out another pair of pontoons, so that they can all be glued at the same time.

On Friday of last week I carried AMOS across the University of New Brunswick (UNB) campus on a freezing cold -26 deg C morning to meet with some professors who might be willing to provide an evaluation of AMOS with respect to its mechanical and software design. The evaluation could include up to 40 hours of their time, but would require approval from IRAP in order to get funding.

The day before that, I had a Webex conference with some people from Esri, the company that makes the ArcGIS software that AMOS uses for posting data, planning routes, etc. This was to find out if In Nature Robotics would be a good fit for their startup program. Last night I got a confirmation email that In Nature Robotics was in fact accepted, pending some document signing. This could be a good opportunity to market AMOS to other companies that are already using ArcGIS for map-based data collection of environmental data. It also comes with up to 3 years of free usage of their software and support.

Lastly, and perhaps most significantly, I got an email notification from the Venture For Canada website a few days ago, to let me know that they did not actually have an automatic notification system available to let employers know when someone had applied to one of their job postings. As I got absolutely zero traction with the posting I had created last fall for the winter term, I had assumed that the posting for the spring term had gotten a similar (zero) response. But actually there were 6 applications there, some of them quite good! So stay tuned to find out if In Nature Robotics will be doubling its work-force soon...

Tuesday, February 18, 2020

Interpolated Data Maps & Cat Boats

Last week some more time was spent on adding a data interpolation feature to the data mapping software. The result turned out pretty good I think:


I would also like to create some mapping software for monitoring AMOS in real time or after the fact via a saved log file. It could be used to pinpoint exactly where AMOS was at any given point in time, the route that it took, what the diagnostics outputs were over time, etc. The mapping software I have done so far has used the ArcGIS .NET software development kit from Esri. I actually have a Webex conference with Esri on Thursday to discuss possibly joining a program for startups that they have. 

The other activity for this week was coming up with a basic layout / design for the catamaran version of AMOS:



I'm not really sure yet if I like it or not. It is shorter than the current version of AMOS (6 feet long instead of 8 feet) and approximately the same width and height, so that's good I guess. I'll think about it for a day or two maybe before cutting up a bunch of EPS foam with the new hot wire cutter (btw the new hot wire cutter works great, I tried it out on a few scrap pieces of EPS).

On a personal note, I am undergoing knee surgery this Monday to fix a small tear in the meniscus of my left knee. I'm not sure what it will mean in terms of mobility, so maybe next week will just be spent writing code in bed. 😊


Tuesday, February 11, 2020

Better Data For 2020

There are at least a couple of ways that AMOS could be updated to provide users with improved water quality data. One would be to add some industrial water quality probes that are capable of collecting calibrated data for a wide variety of parameters. Another would be to improve the data presentation software that is used to represent the data that AMOS collects. Some progress was made on both these fronts this week.

In order to continue updating the map-based data presentation software that AMOS uses, I first needed to get a new Esri ArcGIS license, as the free one I was using had expired. Luckily Esri offers a free account with some limitations for developers, which turned out to be good enough for my purposes. Using some temperature data that AMOS had collected last October, I was able to generate this nice color coded water temperature plot:


I think the color coded points on the data map look better than having blobs of varying sizes on the map. With color coding, you can also imagine a feature where data could be interpolated in the locations between sampling points by taking a weighted average of the surrounding points.

I have also been asking around and getting quotes from 4 of the major water quality probe manufacturers. Basically I would like to have a multi-sonde that comes with probes for temperature, turbidity, pH, dissolved oxygen, and blue-green algae. All of the manufacturers seem to support communications interfaces with 3rd party dataloggers, typically using RS-232 or RS-485. So far I have gotten prices from a couple of the manufacturers, and am waiting for quotes from the other two. The sensors are not cheap, so I want to do my research and make sure that the ones I decide on will be able to provide AMOS with reliable, accurate measurements.

In preparation for an experimental catamaran version of AMOS, I found a hot-wire cutting device on Amazon that looks like it should be suitable for cutting through 2" sheets of pink insulation:

Hopefully it will help me to make more even cuts in the foam with fewer gouges and less time spent sanding.

Tuesday, February 4, 2020

Workation Time

The update at the end of last week's blog mentioned that the presentation to the Raspberry Pint club went pretty well; if you would like to see the presentation (and the other presentations from that evening) you can do so at the following YouTube link:


The slides from the presentation can also be found here: https://drive.google.com/drive/u/1/folders/12L3EXMMcrxIQD2Ic7eXweo_RAyHzjQuS

I find it amazing how much I say "ummm"  and "ahhh" when speaking. It's not something I'm actually aware of when speaking, so not too sure how to go about fixing it. Maybe hire a public speaker if AMOS ever takes off.

This week I had to travel down to San Diego for some meetings related to my job with Measurand. Luckily though, we got finished a bit early, so I was able to find some time to get out and enjoy the southern west coast sunshine and do a tour of this massive boat (the USS Miday):


I spent a few hours touring the boat, which was de-commissioned in the early 90's and converted to a museum about 15 years ago. Here's a nice pic of the San Diego downtown, taken from the flight deck: