AMOS Looks Underwater

 Last month's assumption that the o-ring seal on the WeatherBox required improvement proved to be correct. The printed part had tiny imperfections underneath the o-ring that allowed water to slowly leak through. A WeatherBox customer who was using it to observe a muskrat underwater came up with a brilliant solution: he found that using some marine goop (ex. https://www.homedepot.ca/product/amazing-goop-marine-109-4-ml-3-7-oz-/1000183125) in the channel holding the o-ring worked to fill in the small imperfections in the plastic and create a watertight seal. I've built a few WeatherBox enclosures since then with the channel filled with Marine Goop and they have all worked quite well.

To take pictures and video underwater with the 6 foot AMOS surfboard, an extension piece was required to get the WeatherBox below the waterline. The bow of the surfboard where the camera is located is pitched upward at about a 20 degree angle, so this requires a curved extension piece. The creation of this extension piece required a couple of weeks. At first, rendering the model in OpenSCAD took days for my laptop to finish, although later iterations of the model used some 2-D optimizations with extrusions that shortened the rendering time to about 24 hours. The first two model attempts also had small gaps on the side with the largest radius of curvature, which led to leaking. Eventually a working model of the curved extension piece was created:

The extension piece was fitted on AMOS and used to capture this underwater backyard pool video:

Apologies to viewers for the acting talent used in the above video. In Nature Robotics operates on a tight budget. 😉

Coming up next week is the final round of  the 2021 edition of the Ocean Startup Challenge (https://oceanstartupproject.ca/challenge/). In Nature Robotics is in the mix again this year, and will be pitching on Thursday, September 9. 

The Cape Breton Tour

Last week we traveled to the Bras d'Or Lake in Cape Breton to do a small demonstration of AMOS to people from university, government, and industry. Before that though, I drove down to Dartmouth to meet up with Lawrence and head over to Red Bridge Pond for a quick AMOS demonstration to Yves Bernard, Ulrich Lobsiger, Mike Hayes, Mike Cyr, Karan Kharecha, and Eric Siegel. 

                                                  Photo credit : Lawrence Taylor

The night before, I had plotted a course for AMOS to follow around the perimeter of the pond and we were at the pond about an hour before the scheduled start, so I tried it out. The planned course did not take into consideration a small island of grass that was not apparent in the map. AMOS headed directly for it, and promptly got stuck. I paddled out in the kayak and retrieved it, then plotted a different out and back course that stayed in deeper water. Once people arrived, AMOS performed well over the defined course, and Yves used his drone to get some video footage. (Hopefully the footage turned out ok - there was some question about whether the SD card used to save it had been formatted correctly.) Here is some footage captured from the AMOS video camera that was set to record a frame every time the LiDAR detected an obstacle: 

Later that day Lawrence and I drove to Whycocomagh in Cape Breton where we had rented a cottage on the shore of the Bras d'Or Lake. Here was our view from the front porch the next morning: 

                                                                                 Photo credit: Lawrence Taylor

During our stay in Whycocomagh, we were hosted by Bruce Hatcher, the University Chair in Marine Ecosystem Research at UCCB and the director of the Bras d'Or Institute. He had a Zodiac boat:

                                                                        Photo credit: Lawrence Taylor

that we used to travel to the Waycobah Fish Farm to get ready for the demonstration. Because the forecast predicted strong winds of around 30 km/h in the afternoon, we chose some waypoints for the demonstration that were relatively sheltered between two docks. We did a trial run of most of the waypoints that AMOS executed perfectly. About a dozen people showed up for the demonstration: 

                                                                               Photo credit: Lawrence Taylor

and I introduced AMOS to them, before setting it off on its pre-programmed course:

                                                                              Video credit: Lawrence Taylor

Things were going well, just as before:

                                                                                  Video credit: Lawrence Taylor

but then AMOS unexpectedly disappeared near a large grey boat that was parked at the corner of the opposing dock. Bruce and a couple of his students went over to investigate in the Zodiac. When they approached the area, one of the students exclaimed "Oh shit Bruce, I think it must have gone under the dock and disintegrated!" Upon closer inspection however, AMOS was found underneath the large grey boat, which actually happened to be a catamaran. They were able to retrieve it, and since it did not seem to be moving anywhere on its own, brought it back to our dock, where it was discovered that the propeller blades had both been broken, most likely when it was underneath the catamaran. Unfortunately, I had left the spare propeller back at the cottage, so that was the end of the demo. AMOS did capture some interesting footage from its experience though:

                                                                                            
After the demo, Lawrence and I went out with Bruce and Allison and Piotr to check out a 50 m "Death Hole" with a couple of ROVs. This hole featured a mysterious layer of floating material about 16 m deep that both ROVs were able to examine with their camera systems. Allison and Piotr's ROV collected water samples for their lab at Dalhousie University using a very cool apparatus of spring actuated syringes. Bruce's ROV collected a smelly, dark sample of mud from the bottom of the hole:

On the return trip back to Dartmouth, Lawrence and I stopped near Antigonish to try collecting some data in Pomquet Cove. The wind here proved to be a bit too much for AMOS,  so we tried a stream on the other side of the highway instead:

                           Video credit: Lawrence Taylor

The water in the stream was a bit mucky and shallow in some areas, and required a few minutes of manually controlling AMOS to get it unstuck and drive it back to a location where it could be easily retrieved.

Overall, the demos were a good experience, and served to highlight a number of key areas that will require further development:

• More power, need a larger propeller, larger motor, and larger / more batteries.
• More streamlined and durable construction.
• More accurate positioning (i.e. requires a GNSS system). 
• Need to have ability to reverse direction of propeller for backing out of tight spots.
• Software improvements for defining survey grids, saving / loading standard GPS coordinate file formats.

I2C Wiring Update

 AMOS was taken out for testing a couple of times this week, but unfortunately there were issues with its performance. It would startup and spin around in a circle, without getting any valid data from the electronic compass. After re-powering, it would cease to work altogether. Some of the re-wiring that I had done the week before to clean things up and get more stable power levels had mistakenly wired the pullup resistors on the A to D converter to +5 V instead of the +3.3 V level that the Raspberry Pi 3B+ computer uses for its logic signals. Also, the compass and realtime clock module were both being powered by the +5V supply line, when in fact they should have been powered by the +3.3 V supply, since the pullup resistors that they have wired directly on their circuit boards were connected directly to the input voltage pins of their respective circuit boards.

Even with the I2C pullups wired to the wrong power supply voltage, it still worked. Or rather, it worked when the propeller was not being used. If the propeller speed was ramped up very quickly, the compass module would often fail catastrophically, requiring nothing less than a full system shutdown and powerup to get it working again. Probably the Pi could usually sink the required amount of current to keep the I2C clock and data lines at the right logic levels, but the added system noise that resulted from quickly turning the propeller to full speed must have created some issues. The initial thinking had been that there was too much noise in the +5 V supply for the I2C devices to function correctly, so I moved the DC-DC converter for generating this voltage closer to the Pi and added a large capacitor (1 mF) between +5 V and GND. It didn't help. After a number of tests, experiments, and hours spent searching the Internet, it slowly dawned on me that the devices should be wired in to the +3.3 V supply instead of the +5 V supply. The one exception to this is the LiDAR module, which still uses +5 V for its power supply, but (when needed) its documentation recommends installing pullup resistors to the logic level voltage, which in this case would be +3.3 V. Because there are already 4 devices with pullups on the same I2C bus though, no pullups for the LiDAR module were required. 

Once everything was correctly wired up to +3.3 V it worked great! I was able to ramp the propeller speed quickly up and down without any catastrophic issues. Occasionally a compass data sample would timeout or be missed, but the device always recovered and kept working without needing to reset things. 

A second significant fix was made this week for backing up and restoring the configuration file that AMOS uses. Sometimes if a user switches off power to the boat while the software is writing to this configuration file, it corrupts the file, leaving it as a zero byte file. This would cause AMOS to crash the next time that it booted up. The solution was to backup the configuration file every time on powerup that it is read successfully, and resort to this backup in the event that the original file gets corrupted. Initial tests seem to indicate that this system works. 

I am looking forward to building the next prototype version of AMOS. Most of the parts for it have been ordered, and I'll pick up some insulation foam sheets from the local hardware store to construct and shape the hull. This time around, I would like to build the hull shape from the glued together insulation sheets, as before, but then use that shape to make a silicone mold for quickly making additional shapes. The additional shapes could be made with a two-part foam mixture, which would cure in the silicone mold and could allow for electronics boxes to be easily inserted into the hull structure while the mixture is curing. 

Ocean Startup Challenge Win!

 The pitch in the Ocean Startup Challenge seemed to go OK last week, and fortunately the judges did not ask any really difficult questions. I wasn't expecting to be one of the top 10 companies, but was still kind of eager to find out the results. On Monday evening my phone rang while I was driving into town to pickup Kirsten from cross country practice. I pulled over and took the call, and was quite excited to find out that In Nature Robotics was one of the winners! As I found out just today when the official announcement was made, there were actually 14 winners chosen, so probably good for me that they decided to pick 40% extra! For a video and list of the winners, check out this link: https://www.oceanstartupchallenge.ca/announcements/. I also did a telephone interview with a fisheries / ocean tech journalist who writes for https://www.saltwire.com/, so there should be a story about me, In Nature Robotics, and AMOS appearing there soon. (EDIT: Here is the link to the story: https://www.saltwire.com/business/local-business/video-cod-collagen-project-and-a-boat-called-amos-east-coast-entrepreneurs-among-winners-of-ocean-startup-challenge-504940/)

The funding from the contest will be used to build a 4th prototype version of AMOS that will be a hybrid between the previous catamaran and surfboard versions. This time I would like to first make a silicone mold and then try using a two-part foam with that. I would also like to construct it so that the electronics boxes are mostly hidden away within the hull, in order to cut down on wind resistance as much as possible, and make things look a bit neater. I would also like to get some other people using and testing AMOS, to get their feedback and criticisms, and last I'm hoping to do a bit of R&D to work on adding some tech for discrete sample collection and underwater video.

I'll find out more details about the Ocean Startup program and funding next week. In the mean time I'm working on creating a 3D-printed container to house a small solenoid valve. It would be used for collecting physical water samples at different depths. I would like to fit a BLE (Bluetooth Low Energy) module, some batteries, and a microcontroller in there to allow AMOS to communicate with it wirelessly and tell it to open its inlet valve after a certain length of time. Then AMOS could lower the bottle into the water on a rope to the required depth and wait for the valve to open for a few seconds before pulling the bottle up again. A fancier version might also include a pressure sensor to allow the valve to open at a pre-determined depth. 

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:

https://drive.google.com/drive/u/0/folders/1NDSK35QObOzhbu_-wzTQwxbSCig7iita

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!

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

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

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

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

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

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

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

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

Don't Do Anything Stupid

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

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

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

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

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

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

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!

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.

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

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

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.

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.

AMOS Featured in the MagPi

Merry Christmas / Happy Holidays!

I was planning on taking this week off from the blog, but just discovered this evening that AMOS appeared in the January 2020 edition of the MagPi: https://magpi.raspberrypi.org/issues/89/pdf. This is the official Raspberry Pi magazine. So definitely pretty cool, and worth bragging about! 😊

The magazine edition can be downloaded for free from the above link, but here are some screen captures of parts of it:

Starting to Get Real

A few small things happened this week that helped to reinforce my belief that AMOS can be a viable product.

On Friday, some market research reports that I had requested through Venn Innovation and MaRS Knowledge & Insights came in. In total there were 9 different reports mostly dealing with water monitoring technology. I've only read 2 of the reports so far, but it is clear that the World's water supply is increasingly being threatened by pollution, global warming, changes in weather, and other factors, and that there is a growing demand for reliable, effective monitoring technology for making sure that our water is safe. It seems clear to me that automated robotic water sampling will be needed in the future; hopefully AMOS can be part of that.

On the software side of things, with the help of the ArcGIS API, I came up with a pretty simple interface for planning a route for AMOS:

You basically just left-click the waypoints in the sequence that you want AMOS to follow, or right-click on a point to remove it. Then click the 'Save' button to save the route to a text file for upload to AMOS. It sure beats entering GPS coordinates by hand. I've made mistakes that have resulted in some serious head scratching when AMOS started to head off to the latitude and longitude of my typo.

In Nature Robotics now has an official presence on Twitter: @nature_robotics (https://twitter.com/nature_robotics). It was encouraging to see how many people there are on Twitter that are actively engaged in water monitoring and research about water. Many thousands to be sure. In Nature Robotics now follows a little over 200 of them, and will be following more gradually.

Over the course of the last 21 months that I've spent working on AMOS-related things, some spare parts have managed to accumulate around our basement. My part-time employer (Measurand Inc.) is having a Secret Santa gift exchange this year, with the rule being that the gift must be hand-made or less than $15 in price. Since I drew the Occupational Health and Safety Coordinator, I thought I could make some use of a spare humidity sensor and Arduino to help him make sure things aren't too hot, cold, humid, or dry in the workplace:

Anchor Development, Mapping Software, and Getting Out to Socialize

This week I experimented with a few different physical configurations of a microswitch and a 3D-printed "bumper" for the anchor, so that the anchor software would have some definite way of telling when the anchor was fully lifted up out of the water. Easy stuff right? Nope. The wrench that I am currently using as an anchor tends to sway and rotate a bit as it is being lifted up on the fishing line by the stepper motor. My initial iterations of the bumper were too small, and generally the wrong shape to be able to consistently strike the microswitch. Also, the microswitch wasn't really at an ideal angle for making contact with the bumper. I now have a conical shaped bumper which is large enough to strike the microswitch on the crane at the right angle, and still small enough to probably avoid getting stuck on the edge of the boat. I'm going to have to adjust the motor stepping rate though, because it currently slows down when it thinks it is getting close to the switch, which can sometimes cause enough vibration to set the switch closed prematurely. If changing the motor speed doesn't work, maybe changing the software to wait for a slightly longer switch closure time will work better.

I have also spent a couple of days doing tutorials and trying to learn about the ArcGIS software development kit (SDK) for adding really fancy mapping features and graphics to the user software for controlling AMOS, generating a mapped path for it to follow, and viewing the resultant data in a nice eye catching format. It's a pretty huge SDK, but initially at least, I'll probably only need to use a small portion of it, so hopefully by next blog I'll have a cool little software demo to show for my efforts.

Even robot nerds need to get out sometimes, have some beer and pizza, and socialize a little bit. As I've written before,  In Nature Robotics is part of the Venn Garage program (http://www.venninnovation.com/en/venn-garage) and this evening there was a social event to meet the other startup members. There was even a friendly "pitch" competition in which the founders pitched their businesses, except it was with a bit of a twist, you had to be playing ping pong while doing so.

I was able to listen to other people talk about their business while playing ping pong, but when it came time for me to speak, I found it impossible to concentrate on the ball too... I mostly hit wild shots or net shots while I tried to explain in a short minute what I was doing with AMOS. It was fun though, and interesting to hear about all the diverse ideas that people were working on. There might even be some potential contacts and / or opportunities for AMOS that originated from this too, which would be awesome!

First Products and SEO

As mentioned previously, the vital parts of AMOS will be released as products in their own right in the coming months, leading up to the release of the entire robot in the summer of 2020. The first of these was the waterproof housing that was built for the Raspberry Pi camera that AMOS uses:

This product was called the WeatherBox, and a link to its store location can be found here: https://www.innaturerobotics.com/product-page/weatherbox-for-raspberry-pi-camera-v2 This product was actually split into two different models, one with the Raspberry Pi v2 camera and cable included (WeatherBox-CAM) and one without.

The second was the 16-bit, variable gain A to D board that was described last week. It was populated with all of the necessary components, and all four channels and gain settings were successfully tested out with a little Arduino program and circuit that I made for that purpose:

This one was called the ADS1115-BRVG and its product page can be found here: https://www.innaturerobotics.com/product-page/ads1115-variable-gainboard.

Since the website's SEO (Search Engine Optimization) is still sub-optimal, I'm reading some tutorials on how to get your webpage to show up higher in search page rankings. Apparently there is something like 200 different parameters that Google considers in these rankings. Right now I'm just starting out; trying to make sure all the pages on the website have suitable titles and descriptive text. One thing that was encouraging today, was that when I searched for "nature robotics" with the quotation marks on Google, www.innaturerobotics.com was the first link. Without the quotation marks, it was on page 2, 14th place overall. Those high rankings are probably biased by my location however, as I read that Google ranks local businesses higher.

This coming week I would like to try some calibration experiments on the IMU (Inertial Measurement Unit) and current draw sensor. I suspect that both of these are affected somewhat by temperature, so I'll try heating them up in a box and then put them outside to cool slowly for an hour or two, to see how the outputs change. The magnetometers on the IMU should also be calibrated more carefully than what I did previously by hand. Probably a motor turning apparatus, similar to what I have used before at Measurand would work well.