Pool Drain Test

As mentioned in the previous blog post, a test was planned to position an AMOS equipped with a conductivity sensor in the pond / stream in back of our house, in order to see if there was any noticeable change in conductivity in the water due to draining of the pool. The pool uses salt and a chlorinator during the summer months to keep it clean, but we need to drain it every fall before the water freezes, to make sure there isn't too much ice build-up in the winter. The water within the pool had a conductivity of  4.395 mS/cm. 

The location where AMOS was placed unfortunately had a fair amount of tree cover:

but thankfully not many leaves were left, and there was a nice bit of sun on the afternoon when the bloat was deployed and this picture was taken (October 23). The depth of the water in this area was almost up to the top of my rubber boots. 

Unfortunately, the good weather did not last, and the rest of the week saw near constant rain, with scarcely any sun at all. On the evening of the 24th, I placed a sump pump into the pool with a garden hose connected it to it, and started pumping out water to the corner of our fence nearest the pool.  The pumping went all night, and I shut it off at around 8 am the next morning. Close to 1 m was pumped out of the pool. The pool has a diameter of 8.2 m, so this would correspond to a volume of:

Volume = pi * (8.2/2)^2 * 1 = 53 cubic meters, or 53000 L. 

Here is a picture showing the location of AMOS relative to the pool:

The distance from the pool to AMOS was approximately 45 m. 

AMOS was configured to collect data every hour, and go into low power mode between samples. The plan was to leave it in place for about a week or so, to evaluate the long-term effect of the pool draining. But low power mode wasn't nearly as low power mode as I had hoped, because I had forgotten that the temperature / conductivity sensor and the GPS board were powered continuously. Had a switching circuit been employed to turn these off when they weren't required, a fair amount of power could have been conserved. As it was, when AMOS was sampling it was consuming about 8 W, but when it wasn't sampling it was still consuming about 3.5 W, which over time, given the lousy weather, proved to be too much, and at 4:00 am on October 26, the main battery detected an under-voltage condition and flipped itself off. 

The data was downloaded from AMOS, and graphed:

The short-term resolution of the conductivity sensor is specified as 0.001 mS / cm. Based on the above graph, the long-term variation (hour-to-hour) appears to be a bit greater, something like  +/- 0.004 mS/cm. There does appear to be a weak upward trend in the above data after the pump was started, but the increase is only about 0.002 mS/cm. The specified stability of the sensor is 0.003 mS/cm/month, so I'm not sure the above data represent conclusive evidence that the draining of the pool affected the conductivity of the stream. The large amount of rain which started on October 24 and continued throughout the week greatly increased the flow through the stream, which might have reduced the amount of pool water that collected around AMOS. The soil in our backyard is fairly loose and sandy also, with good drainage, so perhaps very little pool water would have been transported to the stream, even without the rain. 

So to summarize, it looks like a re-do is in order for Fall 2023. 😊

Zippy Mini-AMOS

 Shortly after fixing the software issues for control of the upside-down servo motor on Mini-AMOS, an improved mechanical attachment was created for the servo, and the boat was brought back to Kelly's Creek for a new test. Only about an hour was available for the test, but the boat was able to travel down the river past a small island about 2 km away and back in less than an hour. The top speed was probably ~ 7 km/h, but with stops at checkpoints and pauses to periodically check the boat's heading, the average speed worked out to ~ 4 km/h. Probably some room for trade-offs there, i.e. sacrificing some positional accuracy for speed. Here's a short video of Mini-AMOS as it sped back past the island:

Various software improvements have also been made for both Mini-AMOS and the regular surfboard AMOS. The water propeller on Mini-AMOS can now also be driven backwards, which gives it some extra maneuverability when being manually driven with either the PC or mobile app. Some bugs / stability issues were fixed in the AMOS robot and PC software, and all of the software has been brought into Jira (an online issue & project tracking software: https://www.atlassian.com/software/jira) and bitbucket (https://bitbucket.org/) for easier issue tracking and organization of all of the various AMOS software pieces. 

Next up will be an interesting citizen science sort of test of AMOS right here in our backyard. Every year about this time, we empty most of the water in the pool before it freezes. Since we use a salt-water chlorinator for the pool, the water being drained is a bit salty, and I have often wondered what kind of an environmental impact there might be on the small stream / pond in our backyard, about 80 m slightly downhill from the pool. The demo surfboard AMOS will be placed in the stream / pond with an anchor and a conductivity / temperature sensor, and allowed to float there for a day or two before the pool is drained, and then while the pool is drained (probably about another day). If a significant amount of salt reaches the stream / pond, the conductivity sensor should register a change. AMOS will be configured to be in sleep mode most of the time to conserve power, as there isn't much sunlight in that part of the backyard, especially at this time of year, but it will wake up to take readings every hour. 

Mini AMOS / Wireless HAT Field Trial

 It turned out that the output signal I was using to drive the relay switch on the Wireless HAT board was too weak: instead of activating the coil at 3.3 V, it got pulled all the way down to ~ 0.3 V. Fortunately the output wasn't damaged, and just needed a little boost. I knew I had purchased a bag of NPN power transistors about 4 years ago that never got used, but I searched all over the house, garage, and playhouse, to no avail. Probably they will turn up somewhere. Instead though, I discovered this old board:

from a 2004 Circuit Cellar electronics design contest that I had entered. It was intended to be a combined optical / acoustic motion capture device, but it was pretty glitchy and I never got a chance to  finish it. Instead, my 3 daughters were born (10 weeks ahead of schedule) and the project was permanently shelved (but not thrown away 😉). Anyway, the board had four 2N3904 signal transistors on it, so I de-soldered one, soldered it up to the relay coil, digital output and a 1K resistor, and then the relay worked great - AMOS was able to switch on and off into its low power state. 

The problem with the real-time clock (RTC) was much easier to fix. I had simply forgotten a command-line call to set it up properly. 

The remaining hardware was hooked up for the Mini-AMOS build, and the boat was tested out in the pool under manual control. It seemed to work pretty well, and had plenty of power with the water prop. Yesterday, I brought the boat to Kelly's Creek to give it a spin on a planned route. I had to tow the boat out past the weeds in order to avoid fouling the propeller.

But when the boat was allowed to start on its course, it behaved very erratically, sometimes looping in wide circles, and other times weaving back and forth, following a seemingly random path:

Going over the code later, it was easy to see that the reason for the erratic motion was because the instructions for setting the rudder angle did not take into consideration the fact that the servo motor on AMOS Mini is mounted upside-down. There was also some code that was incorrectly setting the rudder angle back to zero at various times. These code issues have been fixed, but I will need to also find a better way of securing the servo motor at the back end of the body board. It was basically just epoxied into a slot at the back, and towards the end of the test I could see that it was starting to work its way loose a bit.

AMOS Wireless HAT version 2.0

The modified AMOS Wireless HAT boards arrived a couple of weeks ago, along with a larger A to D board for easier soldering, and a different 40-pin header that fits much more comfortably onto the Raspberry Pi board pins. I went ahead and populated all of the components, but did notice a few problems during assembly:

1) The relay switch is too big to fit on the top side of the board where it was supposed to go, and the package size for the switch is smaller than I expected, so it was necessary to solder some jumper wires onto the bottom side of the board to connect it. 

2) The A to D board extends a bit too far over a terminal block that was intended for the A to D inputs. The input wires can just be soldered to the board directly though, so not a big problem. 

3) The USB-serial converter board is dangerously close to the metal shell of the HDMI connector on the Pi board. For testing purposes, a piece of duct tape was stuck over the USB-serial converter board to avoid shorting. The USB-serial converter board is also directly over the camera connector on the Pi board, so there is no room to insert a camera cable. The HAT board needs to include a hole large enough to accommodate a camera cable. 

4) A lot of the text that I had added to the second version of the board (company name, website, etc.) is missing from the board. I'm not sure why, but I'll try to figure it out before the next version. 

Issues 2 and 3 could have been avoided with better 3D modeling I guess, but 1 and 4 require a board re-design anyway, so little would have been gained by fancy 3D analysis. 

Here's what the top of the combined boards looks like when placed inside an electronics enclosure for testing:

You can't really see the wireless sub-module and and USB-serial converter because they are on the bottom side of the HAT board. Even though the compass module and GPS are not installed yet, and the wires from the battery box are not yet connected, it is clear that this should really reduce the amount of wiring, to clean up the enclosure. 

This build will be a new shorter prototype AMOS with a single water prop. It won't be solar-powered, but I'm hopeful that it should be quick and speedy for relatively short (< 3 hours) missions. Here are a couple of pics:

Before flicking on the power switch to test it out, I checked for shorts on the 3.3 V and 5 V power lines. There were none, but I was still a bit doubtful that it would work, so I was pleasantly surprised to see the red power LED on the Pi board come on properly when I flipped the switch, and saw some reassuring flickers of the green activity LED also, indicating that the Pi board was busy with the task of booting up.

Initial tests of the A to D function, humidity / temperature sensor, and discovery / setup of the wireless module worked well, however the relay switch for going into sleep mode and the RTC module did not work. I'll need to debug these to figure out what the issues are. I'll also need to hook up the remaining components to test / debug them as well. Once it's ready it will be exciting to take it for a spin! 😊 

Loose Fit, Tight Fit, and Misfit

This past month I was able to get AMOS out to the water a couple of times for some testing. The first time, I noticed that the boat always seemed to want to head off into the opposite direction. Initially I thought that the problem might have been an invalid initial GPS position, but even after physically moving the boat to other waypoints further along the planned track, it persisted in moving in a direction exactly opposite to the planned direction. Testing a couple of days later at home showed that the compass error was consistently about 180 degrees. I tried using an old compass calibration for the same device, but it too gave similar errors. I also double-checked the IMU board orientation within its enclosure, but it was correct. The only thing I can think of is that the polarity of the magnetometers must have been reversed somehow. Nothing in the part's datasheet says whether this is possible or not, and I'm not sure what sort of event (large magnetic field nearby?) might have caused the reversal to occur. During the last calibration, the heat got accidentally left on during the final temperature calibration, which caused some of the calibration apparatus to melt, and undoubtedly exposed the chip to some higher than normal temperatures. Perhaps higher than its specified limit of 85 degrees C. Not sure if that could have caused the polarity of the sensors to reverse though. 

For AMOS's second trip to the water, the IMU board was simply reversed, so that it could properly be used for navigation. The fish finder was running, measuring depth, and an underwater Weatherbox was used to record some underwater videos at various points along the course. Here's a short video of AMOS setting out on the course:

and the resulting interpolated depth map that was produced:

However, the Weatherbox had a bit of a leak, and must have quickly filled up with water, because none of the videos recorded were recognizable (mostly weird brown color flashes and bits of electronic noise). Unfortunately, the Raspberry Pi camera died after about 2 hours (the last recorded video was cut short) and couldn't be revived, even after a thorough drying later at home. Initially I thought that the leak might have been caused by the parts coming loose due to the temperature difference of the water (colder) vs. the air (warmer) where the parts were screwed together. But a later test at home in a bucket of room temperature water showed that the screwed together parts leaked fairly rapidly, and a closer inspection showed that there were some imperfections in the glued surface under the o-ring. Repeating the test with a different WeatherBox showed no leaking at all after 24 hours. Re-gluing the original WeatherBox, using a 10 lb weight to hold down the o-ring helped reduce the amount of leaking, but did not get rid of it entirely. It's possible there could be some other crack or imperfection in this WeatherBox that is causing leaking to occur. I think I will need to fit the WeatherBox with a leak sensor or two to help save money on Raspberry Pi cameras. 😏

I started working on populating the AMOS Wireless HAT board last week. I started with the 40-pin female socket for plugging into the 40-pin male connector on the Raspberry Pi, since I had some uncertainty about the board design and how it would fit atop the Raspberry Pi board. I soldered the 40-pin female socket to the Wireless HAT board, and then went to try plugging it into the Raspberry Pi board, but realized that the socket was soldered to the wrong side of the HAT board. Oops. So I took out another board, and soldered a new connector to the proper side of it this time. But when I tried to plug it into the Raspberry Pi board, it didn't really want to fit. I could make it fit by using a very large pipe wrench, but large pipe wrenches and circuit boards don't mix well. And commercial HAT boards plug into the Raspberry Pi board quite nicely, without any use of excess force. So I ordered some (hopefully) better 40-pin connectors on Amazon, which claim to be designed for use with the Raspberry Pi. I then tried my hand at soldering the tiny AtoD chip to the board, to see whether that was possible. It was not. The heat / size of my soldering gun, and my general lack of soldering skill was too much for the tiny pads, and they were easily mutilated and destroyed. So I also ordered a few evaluation-type AtoD boards from Amazon which are much larger and easier to solder, and adjusted the PCB design accordingly. Hopefully all of the parts and modified boards will be here in a couple of weeks, so I can try again.

AMOS Wireless HAT Module

 A lot has happened in the last few months, both in the greater world and in my own life. The war in Ukraine has unfortunately occupied much of my attention. I'm hopeful that the Russian invaders will be repelled from that country, but the present situation there is terrible, and I fear for the worst, both for Ukraine and the world as a whole. In my own life, I started officially working full-time at Measurand in March, although I had been unofficially working there full-time since November of last year. This means a bit less time for AMOS and In Nature Robotics, but the job itself is interesting, involving embedded product development and firmware. Plus having a full-time salary is helpful, given the way costs seem to be going higher and higher lately. 

In my own experience using AMOS, and in some of the feedback I've gotten from customers, one recurring issue has been the tangle of wires within the AMOS CPU box that connect the Raspberry Pi to the rest of the equipment (wireless module, AtoD, sensors, etc.). Sometimes one or more of these wires become disconnected, and it can be a challenge to find the disconnected wire and attach it to the correct location. 

Enter the new AMOS Wireless HAT (HAT stands for Hardware Attached on Top). 

It has a 40-pin header that plugs directly into the Raspberry Pi board, and uses printed circuit board traces rather than wires to connect the AMOS wireless equipment, AtoD board, and temperature and humidity sensors. It also allows direct soldering in of wires from the battery box module (for the propeller and rudder control). 

I have already noticed a few things that should be changed on the board, but the order for the first 5 prototypes is already in production, so I'll populate one to see how it goes, and then make some changes after that. 

The weather here is warming up; I'll need to get the demo AMOS up and running again to do some weekend testing again soon!

Winter QA Testing

 Generally it's not a great idea to do AMOS testing in the winter-time. The local rivers and lakes are frozen, so an hour's drive is required to find the nearest available liquid water in the Bay of Fundy. And careful planning is required to ensure that tides, wind, waves, and the cold are all manageable. 

Two recent AMOS robot sales however required that the testing be done, so the van was loaded up in early January for a test down to McLaren Beach, just outside of St. John.

Both AMOS robots were equipped with underwater camera modules. Unfortunately, these proved to be problematic for the air temperatures of -7 deg C and water temperatures of 5 deg C. The plastic tubing, normally quite flexible at room temperature, became as stiff as steel in the cold. In shallow water, this meant that AMOS would get stuck (if it was moving slowly) or might snap off the top connector of the tubing if it struck the bottom at a high speed. So I packed everything up and headed back to make a couple of plugs for the camera holes; the underwater testing component would have to happen indoors. Fortunately the final destinations for these robots are considerably warmer than Canada in the wintertime, so freezing camera tubing won't be an issue. 

A return trip was then made to the Irving Nature Park a few days later, as McLaren Beach was inaccessible due to a recent snowstorm. The waves were stronger here, as it was less sheltered, but the first AMOS went through its sampling course flawlessly. The second one had trouble even starting however. It started up fine prior to leaving, and started up fine inside the van, but within a few minutes of having it outside on the beach (again about -7 deg C) it abruptly lost power and the LED light on the  power switch went out. My guess at this point was that the switch was faulty and didn't perform well in the cold, so after driving back I replaced it. 

A third trip was then made a few days later to Lorneville, as there was a strong wind out of the south that day, and the selected spot offered a bit of shelter from the strong open-water waves. Once again however, the AMOS robot lost power in the cold, usually shortly after the propeller was driven at high speed. This time I thought to carefully check the solar charge controller, and realized that its short-circuit protection circuit was engaging. This was a newer version of a controller which I've been using for the last 3 years; previous versions allowed you to disable the short-circuit protection feature, but this version did not. So back to Fredericton, to replace the solar charge controller with an older model. 

On the fourth trip back (to McLaren Beach), the 2nd AMOS robot also worked flawlessly:

So now both units have been shipped out and are due to arrive early this week. I'm looking forward to seeing how they will be used over the next few months. Hopefully around the middle of this year I will be able to provide an update blog with some details!

In support of these systems, the support page has been updated, and a number of YouTube instructional videos for assembly and testing have been created. These are a bit rough at present, but they should be effective I think.