The sealed lead acid (SLA) replacement battery was tested out in AMOS last week and it did provide a much more stable voltage for the charge controller, but even though I set the limit on the charge controller to 13.5 V, it still created an output of 14 V in bright sunlight. This was a bit too much for the propeller's speed controller which would beep in annoyance and refuse to turn. Perhaps if it did turn though, the extra load would pull the voltage down to a more agreeable level?
The damaged 3D printed fan cage was replaced with an old metal fan cage that I had on hand. The shape of it was ok, but it was a bit too large and heavy. The servo could still turn it, but it seemed to not be as stable as it was before. Probably I'll go back to a plastic cage, just more robust than before.
Some more progress was made on the iOS app, until I ran into a bit of a stumbling block. I had bought what was advertised as a HM-10 BLE module from a vendor on Amazon back in March, but it was actually a knock off imitation device. Up until now it seemed to still work well enough, despite not having all the features of a true HM-10. It seemed to do everything perfectly with the Android app, but for some reason it does not send any data to the iOS app. Data flows fine in the other direction for sending movement commands, etc., but I wasted hours trying to find some way to send BLE data to the app with no success. So I guess I'll just have to find a genuine HM-10 somewhere.
Tuesday, July 16, 2019
Tuesday, July 9, 2019
Turn On, Burn In and Burn Out
In preparation for releasing AMOS into the wild on its own, some reliability testing was done with the air propeller running for extended periods of time. AMOS was placed on our pool deck in the hot sun and the air propeller was run at its maximum speed. A temperature probe was inserted into the electronics box containing the battery, speed controller and solar charge controller, and hooked up to an external Arduino board, which was in turn connected to a PC. Additional temperature sensors were in the other electronics box and connected to the sensor deployment arm, but there was some concern that the solar charge controller and battery might get too hot, hence the additional probe for that box.
It was found that the temperature within the power box would approach 45 degrees C in the mid-day sun. This temperature seemed to be more or less independent of whether or not the air propeller was actually running, so probably most of the heating was directly from the sun, not from the self-heating of the electronics. The moving air propeller might have helped to remove some of the heat as well, perhaps compensating for the electronic heating. This temperature is actually kind of close to the recommended maximum (120 degrees F or 49 degrees C) for the battery being used: https://dakotalithium.com/product/dakota-lithium-12v-10ah-battery/?v=3e8d115eb4b3. It was also noticed that the output voltage of the solar charge controller would fluctuate wildly (about + / 2 V) when it reached its floating charge level (about 13.6 V). Often this fluctuation would mess up the speed controller for the propeller, causing it to stop moving the prop and start beeping loudly. Other times the Raspberry Pi board would re-boot itself. The solar charge controller was replaced, but the fluctuation at the floating charge level remained about the same, although so far no strange speed controller behavior or rebooting was observed. Unfortunately this may mean that there is a problem with the battery (perhaps it got too hot?). A replacement lead acid unit will be swapped in tomorrow to see if that might be the case.
Here is a typical plot of the voltage while running the air propeller at full speed in bright sunlight:
A couple of the voltage transitions in the above graph made sense (changing the prop speed from 6 to 7 and then back again) but the brief jumps near the 0.5 hour mark and the 0.5 V drop at the 2 hour mark are unexplained. An additional unexplained 0.5 V drop was noticed again this evening without the propeller running. Could be some weird stuff going on in the battery when it gets too hot. It'll be interesting to see what the less complicated lead acid battery does. The low-charge detection software was improved for AMOS this week too. Before it just used a fixed 11.3 V limit for the low-charge condition; now it looks for a slope in the voltage curve less than -1 volt / hour. So far this seems to work well, but it needs more testing.
Lastly, In Nature Robotics Ltd. now has a logo (thanks kids for recommending the logo-maker website: https://www.freelogoservices.com):
and a website: www.innaturerobotics.com (thanks kids for recommending wix.com). The website is quite preliminary right now, but will be updated gradually over time.
It was found that the temperature within the power box would approach 45 degrees C in the mid-day sun. This temperature seemed to be more or less independent of whether or not the air propeller was actually running, so probably most of the heating was directly from the sun, not from the self-heating of the electronics. The moving air propeller might have helped to remove some of the heat as well, perhaps compensating for the electronic heating. This temperature is actually kind of close to the recommended maximum (120 degrees F or 49 degrees C) for the battery being used: https://dakotalithium.com/product/dakota-lithium-12v-10ah-battery/?v=3e8d115eb4b3. It was also noticed that the output voltage of the solar charge controller would fluctuate wildly (about + / 2 V) when it reached its floating charge level (about 13.6 V). Often this fluctuation would mess up the speed controller for the propeller, causing it to stop moving the prop and start beeping loudly. Other times the Raspberry Pi board would re-boot itself. The solar charge controller was replaced, but the fluctuation at the floating charge level remained about the same, although so far no strange speed controller behavior or rebooting was observed. Unfortunately this may mean that there is a problem with the battery (perhaps it got too hot?). A replacement lead acid unit will be swapped in tomorrow to see if that might be the case.
Here is a typical plot of the voltage while running the air propeller at full speed in bright sunlight:
Lastly, In Nature Robotics Ltd. now has a logo (thanks kids for recommending the logo-maker website: https://www.freelogoservices.com):
Tuesday, July 2, 2019
In Nature Robotics Ltd.
Yesterday, I officially started the company "In Nature Robotics Ltd.". Previously I had been conducting the business of designing and building AMOS under the name of my software consulting business: "Simpson's Helpful Software", but I don't think that name would work very well for trying to sell robots. Also, it seemed like it was time to start making things more official; getting a logo, website, business plan, that sort of thing.
Besides starting a robotics company, I also got AMOS out for a couple of field trials last week, added some code to help ensure that GPS data is accurate before starting a planned route, and did some work on porting over previously developed Android code to the iOS app. Kirsten and Checkers came out for one of the tests, and although Checkers didn't enjoy sitting in the canoe, we were still able to verify that the new USB data hotspot was working well. The 2nd test was at Cap Brule; it was a nice calm day with ideal conditions for collecting data, but unfortunately I entered an invalid GPS coordinate, which caused AMOS to veer onto the beach after it had collected the first point of data. I had hoped to repeat the test later that weekend, but strong winds and waves kept AMOS on dry land.
Tuesday, June 25, 2019
Dead Solar Panel
A couple of days ago I discovered that the solar panel was not working. The day before that, the solar charging data had indicated that it was only charging the battery for a few hours near noon, and usually it charges the battery whenever the sun is out. Opening the waterproof case for the charge controller revealed that the Velcro backing on the controller had come loose and the controller was resting face down on the other equipment in the box. I don't think that anything had shorted out, and the controller still appeared to be working correctly, although there was no output from the panel. Solar panels are capable of operating with a short circuit between their outputs, it's actually a rating that they are specified for: "short-circuit current". So I'm not exactly sure what happened. I contacted the panel vendor to see about replacement, but have not heard back yet.
Up until now, I have been using my iPhone in AMOS as a hotspot, whenever cell connectivity was required. It never actually worked very well. Even though my phone was right inside AMOS, it would often drop the connection, requiring a reset of either the phone or AMOS to get re-established. So last week I bought the Huawei LTE E8372 Hotspot Turbo Stick: https://www.thesource.ca/en-ca/cell-phones/portable-internet/huawei-lte-e8372-hotspot-turbo-stick/p/108036412 I was able to use the same 100 MBytes data plan that I had for the Android phone. So far I have just done some limited testing with it, but it seems to work well. It's also pretty small and plugs into one of the available USB charging ports on the charge controller. I'll have to try it out in an actual field test soon.
The turbidity sensor enclosure is coming along, but so far isn't quite 100% waterproof. The weak point now is near the top, where the cable enters the housing. I hung an old lawnmower spark plug from the bottom of it to weigh it down and make it more vertical in the water, and by taking up some of the slack in the electrical cable I can keep the top end from getting immersed in the water. It's not ideal, but might work OK for now.
Software-wise, things are coming along also. I modified the startup code to make sure that a GPS fix is acquired prior to saving sensor data. Previously, AMOS would wake-up from sleep mode to collect data, but GPS data was not always available before the sensor data was collected. I also added code for better handling the low battery condition. Now if the battery voltage dips below 11.3 V an alarm can be sent via email and / or text, and AMOS goes into low power mode for an hour, in the hope that some exposure to sunlight will give it some more charge.
Up until now, I have been using my iPhone in AMOS as a hotspot, whenever cell connectivity was required. It never actually worked very well. Even though my phone was right inside AMOS, it would often drop the connection, requiring a reset of either the phone or AMOS to get re-established. So last week I bought the Huawei LTE E8372 Hotspot Turbo Stick: https://www.thesource.ca/en-ca/cell-phones/portable-internet/huawei-lte-e8372-hotspot-turbo-stick/p/108036412 I was able to use the same 100 MBytes data plan that I had for the Android phone. So far I have just done some limited testing with it, but it seems to work well. It's also pretty small and plugs into one of the available USB charging ports on the charge controller. I'll have to try it out in an actual field test soon.
The turbidity sensor enclosure is coming along, but so far isn't quite 100% waterproof. The weak point now is near the top, where the cable enters the housing. I hung an old lawnmower spark plug from the bottom of it to weigh it down and make it more vertical in the water, and by taking up some of the slack in the electrical cable I can keep the top end from getting immersed in the water. It's not ideal, but might work OK for now.
Software-wise, things are coming along also. I modified the startup code to make sure that a GPS fix is acquired prior to saving sensor data. Previously, AMOS would wake-up from sleep mode to collect data, but GPS data was not always available before the sensor data was collected. I also added code for better handling the low battery condition. Now if the battery voltage dips below 11.3 V an alarm can be sent via email and / or text, and AMOS goes into low power mode for an hour, in the hope that some exposure to sunlight will give it some more charge.
Tuesday, June 18, 2019
Sensor Deployment Arm
An armature for deploying sensor probes into the water was added to AMOS this week. It was basically the simplest design that I could think of; a lever arm connected to a servo motor that swings back and forth with the sensor probe cables attached to it. When swung toward the water, it pulls the probes into the water to deploy them. When swung back in the opposite direction, it pulls the probes back onto the stern deck.The probes are not overly heavy so I didn't bother with any strain relief for the electrical cables. My home-made turbidity probe is possibly a bit too buoyant, so I may need to add a bit of mass to it.
Here is a video of the armature in action in our pool today:
The first time I tried it out in the pool a couple of days ago, I noticed that the turbidity probe output changed drastically by almost 50% after a few minutes of being deployed in the water, and that the probe had settled lower down into the water. Unfortunately the enclosure had flooded with water. After taking it out, emptying out the water, and studying it for a bit, the most obvious source of water intrusion were a pair of fastenings on the underside of the shell. Here is a photo of one of the fastenings:
I built the turbidity shell last year, and I think I must have been planning on filling the holes with some molten 3D printer filament, but never got around to it. So last night I held the probe upside-down under my 3D printer nozzle, turned on the heat, and then manually fed the printer filament through the nozzle so that it dripped down into the hole, filling it up completely. I then smoothed it out later with a heat gun and my finger (hot ouch!).
The blue printer filament sort of looks like a wad of gum. I'm hoping it will be more water-tight than that though. Tomorrow I'll let it sit in the pool for a while to see what happens. If it doesn't work, I'll try 3D printing a new shell without through holes for the fastenings.
Here is a video of the armature in action in our pool today:
The first time I tried it out in the pool a couple of days ago, I noticed that the turbidity probe output changed drastically by almost 50% after a few minutes of being deployed in the water, and that the probe had settled lower down into the water. Unfortunately the enclosure had flooded with water. After taking it out, emptying out the water, and studying it for a bit, the most obvious source of water intrusion were a pair of fastenings on the underside of the shell. Here is a photo of one of the fastenings:
I built the turbidity shell last year, and I think I must have been planning on filling the holes with some molten 3D printer filament, but never got around to it. So last night I held the probe upside-down under my 3D printer nozzle, turned on the heat, and then manually fed the printer filament through the nozzle so that it dripped down into the hole, filling it up completely. I then smoothed it out later with a heat gun and my finger (hot ouch!).
The blue printer filament sort of looks like a wad of gum. I'm hoping it will be more water-tight than that though. Tomorrow I'll let it sit in the pool for a while to see what happens. If it doesn't work, I'll try 3D printing a new shell without through holes for the fastenings.
Tuesday, June 11, 2019
Showing AMOS Around Town
This past week was a busy one for AMOS. In preparation for the Fredericton e-Hack event on Monday, I spent some time looking up info on LoRaWAN wireless radio kits and map-based GIS (Geographic Information Systems). Here is a link to a map that I made from the Woolastook grid test: https://arcg.is/01C8Gu.
On Saturday, the sun was bright and shining, and I took AMOS back to the same parking lot near the walking bridge, this time just going directly downriver to collect some temperature samples around the mouth of the Nashwaak River. I was able to try out my new $20 anemometer, which told me that the wind was coming out of the north at ~ 15 km/hr on average, with occasional gusts close to 30 km/hr. The current also seemed pretty strong with a lot of waves. AMOS was still able to make forward progress (albeit slow) against the current and wind when it needed to. Unfortunately, the temperature probe did not work for this test, I think because I had melted part of the probe cable's insulation with a soldering iron the night before. It didn't look like the damage was too bad, but I'm guessing that water must have leaked in, because after AMOS got back home and dried out the probe worked fine. Anyway, I made a cool GIS graph with the temperature from inside the electronics enclosure instead:
On Sunday, I took AMOS to the Fredericton e-Hack event at Planet Hatch. Eleven-X and some other organizations were there as sponsors, and LoRaWAN radio kits were distributed to the participants. There were quite a few people there, and most of them went to the event as teams. Anyone at the event could pitch an idea to the assembly of people and then the top 6 ideas were chosen based on a voting system. I pitched the idea of AMOS, along with a simplified version of AMOS connected to a buoy or retrofitted to a boat. I think about 10 people in total pitched ideas, and AMOS barely made it in at 6th place. Then teams were formed for the 6 ideas, and we got to work trying to figure out the wireless kits and get some sort of rough prototype and presentation together. Here's a selfie of team AMOS:
Unfortunately, nobody was able to get their LoRaWAN wireless kit working. That was the part that I was looking forward to hacking, so that was a bit of a disappointment. We spent the remainder of the time trying to throw together a PowerPoint for the final presentation. As my children will tell you, my PowerPoint skills are very poor, so the presentation didn't look as good as those of other teams, but I thought that the actual content was OK. We didn't place in the top 3, so no prizes were won. :-( However, we did get to meet Mike O'Brien, the mayor of Fredericton and spent a few minutes talking to him about AMOS. I also spoke briefly with a CBC reporter, but so far I haven't been able to find any footage of that.
Today I attended the Canadian Export Challenge at the convention center in Fredericton. There were probably a couple hundred people at this one, and I recognized a lot of the same people from the e-Hack event there. You could do a one minute pitch at this event, and the top 20 pitches were selected to go on to the second of three rounds. AMOS didn't get to the next round, but I did get some useful tips about shipping and exporting, such as: try to get the size of AMOS (and its packaging) down to less than 8 feet long, since that is the standard maximum length that most shippers will handle before things get much more difficult. It was also interesting to hear the stories and advice that the panelists had, and meet some of the other attendees.
Tomorrow I'm looking forward to a return to hardware development. I want to get a deployment arm mechanism in place at the back of the boat for deploying sensors into and out of the water.
On Saturday, the sun was bright and shining, and I took AMOS back to the same parking lot near the walking bridge, this time just going directly downriver to collect some temperature samples around the mouth of the Nashwaak River. I was able to try out my new $20 anemometer, which told me that the wind was coming out of the north at ~ 15 km/hr on average, with occasional gusts close to 30 km/hr. The current also seemed pretty strong with a lot of waves. AMOS was still able to make forward progress (albeit slow) against the current and wind when it needed to. Unfortunately, the temperature probe did not work for this test, I think because I had melted part of the probe cable's insulation with a soldering iron the night before. It didn't look like the damage was too bad, but I'm guessing that water must have leaked in, because after AMOS got back home and dried out the probe worked fine. Anyway, I made a cool GIS graph with the temperature from inside the electronics enclosure instead:
On Sunday, I took AMOS to the Fredericton e-Hack event at Planet Hatch. Eleven-X and some other organizations were there as sponsors, and LoRaWAN radio kits were distributed to the participants. There were quite a few people there, and most of them went to the event as teams. Anyone at the event could pitch an idea to the assembly of people and then the top 6 ideas were chosen based on a voting system. I pitched the idea of AMOS, along with a simplified version of AMOS connected to a buoy or retrofitted to a boat. I think about 10 people in total pitched ideas, and AMOS barely made it in at 6th place. Then teams were formed for the 6 ideas, and we got to work trying to figure out the wireless kits and get some sort of rough prototype and presentation together. Here's a selfie of team AMOS:
Today I attended the Canadian Export Challenge at the convention center in Fredericton. There were probably a couple hundred people at this one, and I recognized a lot of the same people from the e-Hack event there. You could do a one minute pitch at this event, and the top 20 pitches were selected to go on to the second of three rounds. AMOS didn't get to the next round, but I did get some useful tips about shipping and exporting, such as: try to get the size of AMOS (and its packaging) down to less than 8 feet long, since that is the standard maximum length that most shippers will handle before things get much more difficult. It was also interesting to hear the stories and advice that the panelists had, and meet some of the other attendees.
Tomorrow I'm looking forward to a return to hardware development. I want to get a deployment arm mechanism in place at the back of the boat for deploying sensors into and out of the water.
Tuesday, June 4, 2019
Sensor Grid Trials
AMOS has been programmed to accept a pair of diagonally opposing GPS coordinates that define a rectangular area for collecting sensor data. It also requires the user to specify how many stops to make in the N-S direction over the grid, and how many stops to make in the E-W direction over the grid, and how many samples to collect at each stop. For example, the following script command:
grid_sample: 45.878336, -66.909070, 45.876592, -66.906151, 5, 5, 10
tells AMOS to make 25 stops (5 in the N-S direction by 5 in the E-W direction) down to the opposite corner at 45.876592, -66.906151. Here is what it looked like with the path to and from and all the sampling stops drawn on a Google Earth view:
The whole thing took a little over an hour to complete, and since the day was overcast and a bit rainy, the battery was nearly fully depleted. I had hoped that the water closer to the inlet of the small cove would be warmer and would make for a nice color map, but alas no. The water temperature was quite uniform throughout, either 14.06, 14.12, or 14.19 deg C everywhere. I don't have the turbidity or pH probes hooked up yet; I'm waiting until I finish building a mechanism for deploying them into the water so that they don't create excess drag when moving around. Here is a graphical representation of the temperatures collected, expressed as a bubble chart in Excel:
Today I tried to repeat the sensor grid test at a location more likely to show some sort of temperature gradient. The goal was to launch AMOS from a parking lot about 1 km north of where the Nashwaaksis River empties into the St. John River. I set up the GPS waypoints in a script file the night before with the intention that AMOS would first travel west about 100 m into the St. John River, then 1 km south where it would do two separate grid patterns around the end of the Nashwaaksis River. Both the wind and the current seemed really strong this morning, with the current running from north to south and the wind probably in excess of 30 km/hour (Andrew, I just bought an anemometer from Amazon so should have better data on that soon!) coming from the northwest. Poor AMOS didn't stand a chance. It struggled gamely for a little over an hour, before its battery quit and the wind quickly pushed it back to shore. I probably should have edited the script to just skip the first waypoint and proceed south instead but part of me kind of enjoyed standing there watching it struggle. At one point when the wind died down a bit it looked like it would almost make it, but in reality it was still pretty far off:
As this is a more populous spot than my usual Woolastook testing ground, there were a few curious onlookers that asked questions about it. Next time I'll have to bring my wallet with its home-made business cards 😃.
I really like the name AMOS, but I'm thinking of changing what the acronym stands for. Instead of "Autonomous Mini Ocean Surveyor", I'm thinking that "Acquatic Mini Observation System" might be more accurate, as it is not really an oceangoing vessel, unless perhaps you're talking about using it in the doldrums around the equator.
It turns out that I was not properly using the real-time clock that I had hooked up to AMOS a couple of months ago. It needed this line at the start of the /etc/rc.local file:
sudo hwclock -s
I had noticed that the ship log times were always wrong after a cold boot in the field without any available Internet, and that missing line was the reason why. AMOS might take a while to reach its destination against a stiff breeze, but at least it now knows exactly how late it is.
grid_sample: 45.878336, -66.909070, 45.876592, -66.906151, 5, 5, 10
tells AMOS to make 25 stops (5 in the N-S direction by 5 in the E-W direction) down to the opposite corner at 45.876592, -66.906151. Here is what it looked like with the path to and from and all the sampling stops drawn on a Google Earth view:
The whole thing took a little over an hour to complete, and since the day was overcast and a bit rainy, the battery was nearly fully depleted. I had hoped that the water closer to the inlet of the small cove would be warmer and would make for a nice color map, but alas no. The water temperature was quite uniform throughout, either 14.06, 14.12, or 14.19 deg C everywhere. I don't have the turbidity or pH probes hooked up yet; I'm waiting until I finish building a mechanism for deploying them into the water so that they don't create excess drag when moving around. Here is a graphical representation of the temperatures collected, expressed as a bubble chart in Excel:
Today I tried to repeat the sensor grid test at a location more likely to show some sort of temperature gradient. The goal was to launch AMOS from a parking lot about 1 km north of where the Nashwaaksis River empties into the St. John River. I set up the GPS waypoints in a script file the night before with the intention that AMOS would first travel west about 100 m into the St. John River, then 1 km south where it would do two separate grid patterns around the end of the Nashwaaksis River. Both the wind and the current seemed really strong this morning, with the current running from north to south and the wind probably in excess of 30 km/hour (Andrew, I just bought an anemometer from Amazon so should have better data on that soon!) coming from the northwest. Poor AMOS didn't stand a chance. It struggled gamely for a little over an hour, before its battery quit and the wind quickly pushed it back to shore. I probably should have edited the script to just skip the first waypoint and proceed south instead but part of me kind of enjoyed standing there watching it struggle. At one point when the wind died down a bit it looked like it would almost make it, but in reality it was still pretty far off:
As this is a more populous spot than my usual Woolastook testing ground, there were a few curious onlookers that asked questions about it. Next time I'll have to bring my wallet with its home-made business cards 😃.
I really like the name AMOS, but I'm thinking of changing what the acronym stands for. Instead of "Autonomous Mini Ocean Surveyor", I'm thinking that "Acquatic Mini Observation System" might be more accurate, as it is not really an oceangoing vessel, unless perhaps you're talking about using it in the doldrums around the equator.
It turns out that I was not properly using the real-time clock that I had hooked up to AMOS a couple of months ago. It needed this line at the start of the /etc/rc.local file:
sudo hwclock -s
I had noticed that the ship log times were always wrong after a cold boot in the field without any available Internet, and that missing line was the reason why. AMOS might take a while to reach its destination against a stiff breeze, but at least it now knows exactly how late it is.
Subscribe to:
Posts (Atom)