Tuesday, December 31, 2019

AMOS's New Year Resolutions Part 2

My blog post from a year ago happened to be the most popular in terms of views for 2019 by a long shot. I'm not exactly sure why. It was about AMOS's New Year resolutions, so maybe people were curious, or maybe it was just some fluke of Google Search that happened to funnel some people to my blog. At any rate, in this post I'll look at how AMOS fared in its resolutions for 2019, and then make a few new ones for 2020.

AMOS wasn't ready for autonomous operation until the end of August, which wasn't really optimal in terms of the amount of sunlight available. Its overall reliability was greatly improved over the 2018 version though, and it managed to operate autonomously for three consecutive days on two separate occasions. Had AMOS been ready to go autonomously back in May, it is conceivable that the full 1000 km total distance goal might have been attained. For getting more than 50 km in a single trip, I think this would only be possible with a larger battery.

So just like most people, AMOS didn't quite stick to all of its resolutions. Now for the new ones in 2020:

Time will tell whether or not these are achieved. In working towards the first two resolutions, I am presently learning about JavaScript and WebGL in order to make an online custom ordering system for AMOS. The idea is to have a 3D web interface where you can pick and choose what elements of the robot you would like to have, see what the robot looks like in 3D, rotate it around, zoom in, etc., see its overall specifications and capabilities, and also see how many dollars the whole thing costs.

Wednesday, December 25, 2019

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:

Tuesday, December 17, 2019

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:

Tuesday, December 10, 2019

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.

Venn Garage pitching business idea while playing ping pong.

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!

Wednesday, December 4, 2019

AMOS-IMU Orientation Module

This week saw the addition of another product listing in the In Nature Robotics Ltd. web store, the AMOS-IMU Orientation Module: https://www.innaturerobotics.com/product-page/amos-imu

Here's a picture of me holding it so you can get some idea of its size:

It is the same orientation module that I have been using inside of AMOS this year, and it has worked quite well. It includes three-axis accelerometers, magnetometers, gyro sensors, and two temperature sensors, all of which combined with some simple calibrations make for a very nice, compact orientation sensor, with good dynamic response and resolution of around 0.1°. It even has a barometric pressure sensor, but I haven't tried that out yet. Documentation for the module, source and library files for Arduino and Raspberry Pi are now added on the website here: https://www.innaturerobotics.com/support.

I also took some time this week to come up with a simple means for achieving a basic temperature calibration for the ACS712 current sensor and the AMOS-IMU. I was hoping to use a simple apparatus powered by AMOS's 12V battery, and using an Arduino Uno board for collecting and storing the data in SRAM:

The only drawback of this approach was that whenever I plugged in the USB cable into a PC to download the data, the Arduino would reboot itself and lose whatever data happened to be stored in the SRAM. So I just got rid of the battery and ran a USB cable through a small opening in the box into the PC, to log the data in some terminal software (Tera Term). This actually worked pretty well. The interior of the box started off at around 20 °C and after the box was placed just outside our doggy door, the temperature dropped down to about 0 °C after an hour. I found that the change in output of the ACS712 was pretty much exactly what was specified in their datasheet, and probably not worth bothering to correct in software. I haven't checked the data for all of the orientation sensors yet; they might require some slight temperature compensation in software.

Tuesday, November 26, 2019

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.

Tuesday, November 19, 2019

The End of Testing Season

Fall transitioned very suddenly into winter these past couple of weeks in New Brunswick, effectively halting AMOS's field testing. The final distance total was 180 km, just 20 km shy of the 200 km goal. The upcoming winter months will be spent transitioning AMOS from a pretty good prototype into a viable product that can be consistently manufactured and used by actual customers. One aspect of this involves converting the existing through-hole prototyping board circuits into more professional looking printed circuit boards. RPC Science and Engineering (rpc.ca) is helping out with a circuit board design and layout for the wireless telemetry and diagnostics system that AMOS uses. Some work was also done in-house to get a printed circuit board completed for the 4-channel A to D module, with an I2C interface for easy connection to the Raspberry Pi, and resistors and settable jumper pins for setting gain on individual channels.

Unfortunately I missed an obvious alignment error in the silkscreen printing for the jumper settings table, but otherwise the board looks pretty good. I'll need to populate it with the necessary components and try it out to confirm that it works.

More work was completed on the anchor testing apparatus as well. A small crane assembly and a framework for holding the motors, Arduino board, and motor drivers was 3-D printed and put together for some simple anchor testing:

This time a 16-pound fishing line was used to hold the wrench, and it seemed to work pretty well. It  occupied less space than the previously used string, and didn't get frayed or damaged from use. Some micro-switches have been ordered and will be positioned as "stopping points" for the swivel and lifting motions. I'm wondering about a strain sensor or something for the crane arm to detect when there is slack on the line, as it isn't really a good idea to keep unwinding the fishing line once the anchor reaches the bottom and the line goes slack. Or maybe just let the anchor free-fall without motor intervention.

In Nature Robotics Ltd. expanded its web presence last night, as it now has an official Facebook page. Check it out: https://www.facebook.com/InNatureRobotics/ and give it a "Like" to get a weekly update on what is going on with AMOS and other development work.

Some work has also been done on a business plan for In Nature Robotics Ltd., although this is proving to be a lengthy process. I'm currently evaluating the competition in the Autonomous Surface Vehicle (ASV) space for inland waterways and there are some pretty good products out there, but I think AMOS can find a niche with its light weight, airboat design with low draught allowing it to pass easily through shallow water with vegetation, and ability to operate autonomously for extended periods of time without any human intervention. So far there doesn't seem to be anything out there that can do all 3 of those things, but the competition does seem to be growing and improving quickly!

Tuesday, November 12, 2019

Trawling For Microplastics

My business mentor in the Venn Garage program, Alicia had suggested that it might be interesting to see if AMOS could be used to look for microplastics in water. Microplastics are generally defined as any fragment of plastic that is less than 5 mm in length. There are a number of ways that researchers can sample water to check for microplastics. One of the most common ways is to drag a net with very small pore holes behind a slowly moving boat. Usually the net has a pore hole diameter between 100 and 500 micrometers, depending on the minimum particle size desired. As a quick experiment with AMOS, I 3D-printed an opening for a reusable produce bag, made of a woven fabric material with a pore size somewhere in the 300 to 500 micrometer range.

I took AMOS back to the Kelly Creek Basin area of Woolastook Park, and set it for its usual course. The day before we had had our first major snowstorm of the year, about 10 cm of snow, and there was a bit of a chill in the air. Although the water temperature was around 9 degrees C, the air temperature was only -2 deg C at the conclusion of the test.

After traveling for about 4 km, I noticed that AMOS seemed to be stalled in the middle of the river. I paddled over to investigate, and found that the propeller motor was making a strange, high pitched whining noise. Thinking perhaps it was just a strange combination of the low temperature and low battery, I tried to change the battery for a spare that I had on hand. No difference. So I hitched up AMOS to my tow line and towed it 4 km back to the launch point.

The post-test analysis showed that the motor was completely seized up. Researching a bit about drone performance in cold weather: apparently you should avoid flying a drone in cold, damp weather, such as directly above water that is considerably warmer than freezing air. Humidity from the warm water can condense and build up on the propeller blades, in some cases causing excessive vibration that can damage the motor. That's my best guess as to what must have happened. I didn't think to look for ice buildup at the time, but it probably would not have taken very much to cause a significant vibration. The propeller is very thin and light, and it spins extremely fast.

Back on shore, I had a look at the material collected within the produce bag:

Mostly it was a species of river grass common to the area, but there was also a tiny snail shell, a strange 2 mm long shrimp-like creature, many small black dots (< 1 mm diameter) that appeared to be organic, but I couldn't be sure, and a 2 mm long piece of some white substance which was probably plastic, but might also have been a small bone fragment. Based on the diameter of the collection hole and the distance traveled, approximately 22000 L of water was sampled. There was no noticeable reduction in the speed of AMOS, which was encouraging to see. I guess it was also a good thing to learn that the water around Woolastook Park appears to be mostly free of microplastics (at least visible microplastics).

Wednesday, November 6, 2019

The Race For 200

Since scaling back the original one year distance goal from 1000 km to 200 km, I've been working hard at testing AMOS, trying to reach the 200 km total distance traveled mark before the water freezes over. Right now it's at 167 km, so it's within reach. This past week had a few good test days; with the 10 A-H battery and the weak November mid-morning sun shining, AMOS can go for almost 7 km before it detects the charge getting low and heads for a re-charging location (i.e. one of about 6 predefined spots on the north shore of the river that have good sun coverage and are a bit hidden from populated areas. Rather than hope that it will stay in the re-charging location and charge, I have been just towing the boat back home and plugging the battery into a wall charger. Sort of a cheat I guess, but there are only a few useful solar charging hours at this time of year. In these tests, AMOS has been performing really well. Earlier tests in October were done using my laptop to start a shell connection to the Raspberry Pi and initiate the commands to get it going. I eventually discovered though that the program would suspend itself as soon as the boat got out of WiFi range. So now I've just set AMOS to start itself automatically after booting up, and the program has been running smoothly, at least the last 3 times that I've tried it. I've also tweaked the LiDAR avoidance code a bit, to avoid making too many unnecessary turns.

It's too bad that the boat wasn't ready for heavy testing in the summer months of this year; had it been capable of autonomous operation then, the 1000 km goal might have been achieved.

We are expecting 20 cm of snow here on Friday, and I might be having an arthroscope on my knee next week. But hopefully there will still be some opportunities to get AMOS to 200 km. ☺

Tuesday, October 29, 2019

Visiting Halifax

Just a short blog entry this week as I traveled down to Halifax today for some meetings, and forgot to bring my laptop charging cord, so the battery level is getting low. In the afternoon, I met up with a team of students at the Nova Scotia Community College (NSCC) that are working on a project to design and build an automated sensor deployment mechanism for deploying sensors off the side of AMOS to depths up to 30 m. Here we are standing outside the COVE building:

From left to right are: Alfred White (instructor), myself, Raj Patel, Chuck Taylor, Maya Anuraj, Stephane Kirchoff (instructor). 

We had a good discussion about possible design ideas and I showed them the small demo anchor that I had put together last week.

After that I drove over the bridge to attend an event sponsored at Innovacorp for local small businesses to meet up with local student talent and have a bite of pizza. This event was packed with lots of amazing businesses and students. Each business had just one minute to talk about what they were about and what they were looking for in terms of hiring. After that the students walked around and met up individually with all the business owners.

In Nature Robotics Ltd. is looking at hiring a student to help out with sales and marketing efforts, starting with a term position in January. The ideal candidate should have great communication skills, have some technical background, and be able to work well independently. If you or someone you know might be interested, please send me a resume: murray@innaturerobotics.com.


Tuesday, October 22, 2019

Salt Water is Deadly (For Electronics)

It turns out that the camera module was permanently damaged by just a few drips of salt water that got into its enclosure. Also, the solar panel is no longer functioning. Yesterday (after receiving some instructions from the manufacturer) I pried open the electronics box at its base, and did a couple of multimeter tests. The open circuit voltage was way too low, even after completely drying out the electronics overnight. I think I'll see if I can find a replacement that has some better water resistance. This is the second one that I've burned through, although I'm not sure exactly what happened to the first one, it stopped working after a really hot day in June, so maybe it overheated.

I did a bit of experimenting this week with possible anchor designs, trying out a NEMA-17 stepper motor with a TB6600 stepper motor driver and an Arduino Uno. I even tried 3D printing some gears, but the mechanical precision of my prints isn't really that great; the gears kept getting locked up at a certain point. I'll need to buy a stepper motor with a gearbox attached to it, in order to lift an anchor that weighs more than a 250 g wrench. Anyway, this is where things stand with that right now:

I also got out to Wookastook for a couple of tests. The first of these was kind of strange: a couple of times AMOS seemed to get locked into a mode where its propeller just got stuck at some angle, so that it kept turning repeatedly in a tight circle. The program was still running, but not saving anything to the log file, so I'm not sure exactly what happened. I've seen the same thing happen sometimes before, but previously I thought it was just caused by the program crashing, but I was able to confirm this time that the program was actually still running. Possibly it was a multithreading bug in the program that resulted in a deadlock condition. I tried inserting more debug code to see if I could better isolate what was going on before the problem occurred, but of course after that debug code was added I haven't been able to reproduce the issue. I'll try it out some more over the next few days, to hopefully reproduce and fix the issue.

Tuesday, October 15, 2019

Flipped In The Surf

Usually every Thanksgiving, we drive down in the van to visit my parents at their cottage in Cap-Brulé. This weekend was no exception, and of course AMOS was squeezed into the van along with 5 people, a dog, and my kayak on the roof. One of my parents' neighbors had wondered if AMOS would be able to measure the distribution of water temperatures along the coastline where a lagoon empties into the ocean, so I was hoping to give it a try. The first day we were there was quite windy and wavy, with rain and gusts up to
40 km/hr, so AMOS stayed in the shed. The following day was better in the afternoon, so my mother, father, and I drove it down to a small boat launch area near the cottage.

The waves were still a bit too strong to successfully launch AMOS from shore, so I pulled it along in the kayak for a while, and then let it go on its own, following the planned GPS sample points. At one point, when it was on its own though, fairly close to shore, a strong wave struck it broadside and flipped it over solar panel down. The propeller post snapped off on the sandy bottom and the electronic control boxes were both submerged, under the boat for about a minute before I was able to frantically paddle over to set things right-side up. 

We didn't want to get salt water from AMOS or the kayak on the van, so Dad (who is 77) and Mom (73) both carried AMOS approximately 1 km back to the cottage, while I carried the kayak. They got there first, so Dad then came back to help me finish carrying back the kayak. I then had a look at the damage:

The main processor box only had a few drips of water in it, but the battery box had a few mm of water resting on its bottom. Probably some of the cable glands could have been a bit tighter. While manipulating the battery and wires, the +12 V contact shorted out on another wire with a loud pop and some smoke. Uh oh. Turns out it was only a digital I/O from the Raspberry Pi that got fried though, so no big deal. I was able to just change the software to use a different one. And actually, although the flip prevented me from collecting about half of the data that I was hoping for, the plots of temperature and turbidity still turned out pretty good (https://www.innaturerobotics.com/sample-data-1):

The water intrusion didn't seem to cause any harm inside the battery box, but so far I haven't been able to get the camera module working. There were still a few drops of condensation inside the plexiglass camera cover, so I'm hoping the newly re-charged desiccant that I put in there will dry things out enough so that it works again soon. 

I guess for wavy conditions, it might make sense to have a keel, or at least some fins on the bottom of AMOS to help stabilize it. Maybe an add-on option that customers can purchase. ☺

Tuesday, October 8, 2019

Stuck In The Mud

AMOS did another 20 km of traveling around Woolastook this past week, bringing its yearly total up to 130 km. I'm hoping to maybe reach 200 km before things get too cold. A couple of improvements were made this week also:

  1. Fixed up the LiDAR code so that it now seems to be working as intended. 
  2. Shifted the position of the sensor deployment arm and made a small fitting to better route some electrical cables on the back deck, so the sensors no longer become entangled. 
I also ordered some stepper motors and drivers for making an anchor deployment mechanism. Having an anchor would not have helped today though, as the water level in the Kelly Creek waterway was unusually low. That happens sometimes, depending on the level of flow downstream through the Mactaquac Dam. What it meant for AMOS though, was that its waypoint in the northeastern corner of the route was probably located in the middle of a mudflat. AMOS was unable to turn properly at about 12:50 pm today near that location, and it kept trying until 3:00 pm, when the program was set to stop traveling anyway. If AMOS had a depth sensor it would help avoid those sorts of situations...

I cleaned off my iPhone camera lens and tried to record some video today too. Here are a couple of the best ones. For some reason YouTube really seems to degrade the quality, so I'm going to try posting the files directly here this time:

Good closeup of AMOS.

Sensors getting deployed.

Tuesday, October 1, 2019

110 km and Counting

AMOS was back at Woolastook for a few days last week, but I think its days on the water will be coming to a close soon for this year. The temperature is getting down near zero in the mornings, and the lead acid battery that I'm currently using doesn't seem to last as long in cold weather. I have been looking at bigger lithium phosphate batteries, perhaps 50 or even 100 AH but they are pretty expensive, so I'll first need to make sure that AMOS is sufficiently mobile with carrying the extra weight, and make a request to In Nature Robotics' finance department. 😏

To date this year, AMOS has traveled 110 km, mostly near Woolastook Park, but some around Cap-Brûlé too. Almost all of it has been autonomous, travelling to pre-programmed GPS coordinates. The 1000 km distance goal I came up with on New Year's day isn't going to happen this year, but all of the testing done so far has highlighted a number of issues that can be solved to help make AMOS a better robot:

  • Need to guard against AMOS getting stuck. Some areas of the shore are more amenable to docking than others. Safe points (with maximal sun exposure and not too close to populated areas) were defined in the software for AMOS to try to reach whenever its battery gets low, but sometimes AMOS is too far away from a safe point when a low battery condition occurs, and it must go into low power mode wherever it happens to be at the time. The wind then eventually blows the boat to a random shore location, where it often becomes beached on rocks, or stuck in a shoreline tree or bush. One solution might be to have an anchor system that lets down a small anchor with say a 5 m line. This would hopefully keep the boat in a stable location well enough away from shore to get going again after its battery charges back up.
  • Need to look more closely at the LiDAR obstacle avoidance code. Sometimes it seems to be working, but at other times I've seen AMOS veer off directly toward a clump of grass onto the shore, and I'm like, "what the heck?".
  • Need to fix up the sensor deployment arm to avoid it getting tangled on electrical cables on the back deck. Sometimes the sensor probes don't quite make it to the surface of the water.
  • Need to re-wire the electronics for sleep mode to switch off absolutely everything that doesn't need to be powered. Currently AMOS requires about 2.5 W in sleep mode, but I think I should be able to get this down to close to 0.5 W by only powering the RF220SU radio board, and the solar charge controller. 
A lack of sun and cold weather kept AMOS from getting too far this past week, but here is some temperature data for Sept. 26 to 28 (http://arcg.is/uTS90):

Tuesday, September 24, 2019

Marketing Is The Only Thing That Matters

After arriving to Measurand for my afternoon shift one day last week I was somewhat surprised to find out that I needed to go get interviewed by a software consultant that had been hired by the company to review our software processes. His name was Alan I think, and he turned out to be a pretty friendly guy. We briefly introduced ourselves, and immediately found out that we were both working toward similar goals; both doing consulting work and working at regular jobs to help make ends meet while trying to become successful entrepreneurs. He has progressed further than I have, as I believe he mentioned something about actual customers. His business involved setting up smart lighting systems for large buildings, in order to use less energy and save their customers money. It sounded like a great idea. Then, after I briefly described what I was doing with AMOS, he gave me these sage words of advice:

"Nothing else matters except marketing. None of the other shit is important; it doesn't even matter if everything is working right, you can fix it later. Seriously, marketing is the most important thing. If you don't do it right, you've got nothing."

I smiled, nodded, and said something like "Hmm.... OK." and that was that. The significance and truth of his advice didn't really sink in until later, after the interview was over and I went back to working at my desk. I'm kind of like a "fish out of water" when it comes to marketing.

(Unfortunate minnow found dead on the deck of AMOS a couple of days ago.)

so finding customers might be a bit of a challenge. Fortunately though, In Nature Robotics was recently accepted into the Venn Garage program (http://www.venninnovation.com/en/venn-garage), a mentorship program offered to small startup businesses in New Brunswick, to help them validate their idea, acquire early adopter customers and initial funding, and prepare their startup team for successful entry into leading accelerators. Hopefully over the next year, I'll pick up some good marketing tips and knowledge from people who have done it successfully in the past. I also applied to the Creative Destruction Lab accelerator program (https://www.creativedestructionlab.com/program/) to their Oceans stream, based in Halifax (https://www.creativedestructionlab.com/streams/oceans/). Last week I had a video interview with a few people from there, and will find out by October 2 whether or not I got in.

AMOS spent another 4 days on its own at Woolastook this past week, and collected some good temperature and  pH data (https://www.innaturerobotics.com/sample-data-1). Although it has been a while since I did a very crude calibration of the probe with some kitchen vinegar and tap water, it does seem as though the water around Woolastook is a bit acidic. Apparently that's not uncommon in this particular part of North America. On Thursday, AMOS set a new single day distance record of 12.25 km.

The weather is currently quite cloudy and rainy, so I have AMOS back home where I'll see if I can fix some intermittent low voltage issues on the +5 V supply, and maybe hook the GPS antenna back up. There seemed to be a few spots around Woolastook where finding a GPS signal was a bit of a challenge.

Tuesday, September 17, 2019

A Week of Finger Burning (a.k.a. Soldering)

Turns out AMOS had sustained a bit more damage than I had originally thought last week. The pH and turbidity electronics signal boards had also been fried, so they had to be replaced too. Luckily they weren't super-expensive. Re-doing all of the wiring for the new Raspberry Pi 3B+ and the replacement RF220SU wireless unit took an inordinate amount of time though. The heating element in my soldering iron was slowly dying and the pins on the wireless transceiver were spaced only 2 mm apart, so needless to say there were some moments of extreme frustration trying to get all of the little solder blobs onto the right pins and wires. I really like the wireless module, but I wish there were a better package for it, i.e. something with a 20-pin header for easily plugging, unplugging wires would make things so much easier. Could be a new product there...

I just finished wiring up and testing everything today, so I think this new build of AMOS is ready to go. Although it's still a bit of a mess inside, the CPU box has considerably more room with the smaller Pi board, no more USB hub, and a few stray wires cleaned up:

I'm anxious to get AMOS back in the water for more testing. The forecast is calling for 5 straight days of sunshine, so hopefully it will be able to get lots of km over the next week.

Here's a picture taken from a couple of weeks ago on one of the first rescue missions. AMOS is looking kind of lonely under the shade of some trees on the south side of the river:

Tuesday, September 10, 2019

Zapped Circuit Boards

After AMOS had been on its own for 5 days, I drove out to pick it up so that it would be safe from Hurricane Dorian and so that I could modify the power cable for the cellular hotspot to be software controlled (i.e. shut off whenever AMOS goes into sleep mode).

Although it had a low battery and was too weak to extract itself from some branches near the shore, it appeared to be working normally when I picked it up. So I unplugged the power cables inside the battery box, loaded it into the van, and drove home. After I got home however, it would no longer boot up properly, even after the battery was sufficiently charged. A few hours of hardware troubleshooting revealed that the short-range wireless module was somehow short-circuited, and drawing too much power. Also, the 3.3 V regulator on the Raspberry Pi mainboard was only putting out about 2.6 V. Replacing the regulator with a different one didn't seem to help either, i.e. the Pi board would still not boot up. 

Later that same day, I drove the van to Kirsten's cross country practice to pick her up. While waiting in the parking lot for 10 minutes, the van's battery mysteriously died, and could no longer be started when the practice ended. Turned out the alternator was shot and needed to be replaced, so overall not a great day for electronics. Maybe I was emanating some weird electromagnetic radiation or something that day. Actually I think what probably happened with AMOS was that when I unplugged the power cable in the battery box and transported it in the van, it probably shorted out on the +12 V battery terminal, destroying both the Pi board and the wireless transceiver.

Turns out it's not all bad though. I had been contemplating switching the Raspberry Pi Compute module for the smaller, less expensive Raspberry Pi 3B+. The 3B+ actually has a slightly faster processor than the compute module, built in WiFi and Bluetooth, and 4 USB ports all included, whereas the Compute module only has one USB port, and requires a separate hub to add WiFi and Bluetooth functionality. Originally I had gotten the Compute module because it had two camera ports, and might make 3D ranging possible using stereovision. Turns out it's way easier to do that with LiDAR though, so no real need for two visual cameras. The 3B+ has fewer I/O ports too, but it still has way more than AMOS needs right now; about 13 extra digital I/O pins are still available for any new functionality. 

Here is a comparison shot showing the reduction in size between the Compute module and the 3B+:

The next few days are going to be spent setting up the 3B+ and the replacement wireless module. The software changes are pretty minimal, just pin re-numbering mostly. Most of the time will be spent setting up the software, as I don't have a workable image ready for this board yet, plus a bit of time for soldering together the replacement wireless module.

Tuesday, September 3, 2019

The Quest For Sun

AMOS has been mostly on its own for the past week in Kelly's Creek, near Woolastook Park. Hannah and I deployed it on Saturday morning, and tested out the LiDAR "avoidance mode". Once it did seem to work, but another time it did not, as AMOS plowed directly into the side of the canoe. I believe I was able to correct a software bug related to that this morning, but have not had a chance to test it out yet. That day was also very windy, and AMOS overshot a couple of its sampling waypoints and had to return against a strong west wind with gusts > 20 km/hr. Here is a map showing the track (in blue) that it followed before it eventually ran low on power and drifted under some trees on the south shore:

Even though the next day was sunny, it was not able to charge at all under the trees on the south bank of the river, so I took the kayak out and towed it to the north shore, letting it sit there for about an hour and a half to properly charge in the bright noon-day sun. Then I set it to continue on its way, where it traveled to the far end of the waterway, before shutting off its propeller at the planned time of 3 pm. After I got home, I opened a terminal connection to it, to discover that it had once again drifted to the south shore. So I found a place on Google maps on the north shore well away from houses, and created a short script to send it to that spot, 500 m across the water. The day after that was quite rainy and overcast, and AMOS never really charged very much, so again through the terminal connection and various file scripts, I set AMOS to mostly drift around, just using the propellers to stay away from the shoreline. It eventually covered 2.5 km, but that was over about 3 hours. Eventually it came to rest against someone's dock for the night:

I tried to steer it away from the dock, but the battery was too low to drive the servo controlling the propeller direction, so it just kept ramming itself into the dock instead. Nothing to do but leave it for the night, and hope that no one minded I guess. During the night, the wind must have taken AMOS a few hundred meters northeast to a less populated area. The battery must have gotten pretty low during the night I think, so I just let it charge up today, which was only partly sunny:

9:00 am --> 11.454 V
10:08 am --> 11.666 V
11:19 am --> 11.810 V
11:59 am --> 12.022 V
5:30 pm  --> 12.25 V

I was a bit surprised that it didn't charge up to more than 12.25 V by 5:30, as the afternoon was much sunnier than the morning, and from what I could tell from the boat's camera, it was in a spot on the north shore without noticeable shade. Here is the view from the camera when the boat was facing west:

 Normally in bright sunshine all afternoon, I would have expected to see the battery voltage climb up to over 13 V.

I added some software to AMOS to define optional "safe" locations in the text script files. These are locations where AMOS will head to when its battery starts to get low. I tested it out this evening and it seemed to work, choosing the closest safe location, although AMOS was pretty close to that point already, so it wasn't a very hard test.

Tomorrow looks like it's going to be rainy again, so if there's time, I think I'll make a trip out to retrieve AMOS and modify it to switch off power to the cellular hotspot during sleep mode. Right now it's just on all the time, which could be wasting a few watts of power at times when I can't even communicate with the boat anyway.

Tuesday, August 27, 2019

Waking up and Charging

The first day that AMOS was left on its own (last Wednesday) there was a bug in its software that didn't properly close down the configuration file after writing to it, so that when the Pi processor was put into sleep mode the night before, the configuration file actually got erased. This caused a crash when AMOS woke up at 9:00 am the next morning. I had some meetings that day, and wasn't able to monitor the progress of its maiden solo (non) voyage. That afternoon however, there was a strong wind from the south, so that AMOS was actually blown from its swampy location at the south end of the cove, to the north bank of the river, about 1 km away. When I checked the GPS location that evening, I thought there must be some mistake, but a picture taken from the camera confirmed its location next to somebody's dock:

I went out in a rainstorm that evening to retrieve it and bring it back to the swampy cove. I also fixed the bug that had caused the crash when waking up out of sleep mode.

The next morning turned out to be grey and overcast, so AMOS didn't have much charge when it woke up at 9:00 am. It traveled for about 3.5 km though, before it went into sleep mode to recharge its batteries. This time however, AMOS drifted onto the south river bank, where there was an exceptionally steep hill, very thick with trees that very nicely shaded the robot from the sun. It was hardly charging at all, so again I went out that evening to fetch it back, again in the rain, and this time with a bit of thunder and lightening as well. Here is a pic of where it was hiding, nicely shaded under some trees:

We were scheduled to leave for a family vacation on the weekend, so I brought AMOS back home after that, did some more minor debugging, and set it up in the backyard to test out the solar charging, sleep mode, and battery management software while we were away. These tests have mostly gone OK, with only some minor software issues that have been fixed. The biggest problem that these and the actual field tests of last week have confirmed is how to make sure that AMOS gets enough sun to properly re-charge itself. Basically AMOS needs to drive itself out into a place where there is known to be sun shining, then shut itself off (including GPS) to conserve power, and hope that it doesn't blow too far away. Right now if it needs to re-charge in the daytime, it is set to go back into sleep mode for an hour. Probably this should only be 10 minutes though, so that it can check to see if it has drifted too far away, and quickly correct its position if necessary, before going back into sleep mode to re-charge. Finding enough sun is going to be a bit of a challenge, all the more so now that summer is coming to an end.

Tuesday, August 20, 2019

Distance Record and Initial Autonomy

Last Thursday I was able to get AMOS loaded into the van and deployed again at Woolastook by 9:15 am, which allowed enough time for a nice 2.75 hour test, covering nearly the entire length of Kelly's Creek and back again. Below is a map depicting the route that it took:

The total distance covered was 10.85 km, which smashed AMOS's previous single-trip distance record of 6.12 km. This was encouraging, since it meant that a fully autonomous AMOS, operating in this relatively closed area might have some hope of reaching the goal of 1000 km of total traveled distance before the end of the year. There are fewer hours of available sunlight each day, so I really need to get it running on its own soon.

I was able to get the new LiDAR module hooked up, and finished debugging the software that I had written for it. It seemed to work pretty well. The software has two basic modes of operation when using LiDAR data:

1. Safety Mode: Stop moving the boat whenever an obstacle is encountered.

2. Avoidance Mode: Try to turn the boat until it finds a direction without an obstacle, then proceed in that direction for 60 seconds before returning to the previous navigation plan.

Here is a picture showing the new LiDAR module:

It is the small black device with two lenses bolted into a blue plastic piece that was 3-D printed and velcroed to the visual camera enclosure.

The last few days have been a bit of a scramble, trying to add some new features to the software for going into a "rest" mode where the boat just sits there, but is still connected to the Internet with GPS access, and also a "sleep" mode, where the boat is almost entirely powered down, except for the RFU220 wireless module and a few other components. These other components could also be switched off, but I haven't had time to do that yet. The clock times for going into these modes can be set from the same text script that is used to specify the GPS waypoints for sampling. There is also now a means for setting the "wake up" clock time for when AMOS can go on its way and begin sampling, provided its battery voltage is high enough (> 12.4 V). If the battery hasn't been charged enough, it goes back to sleep for another hour, and then tries again.

After some slightly rushed backyard testing, I was able to deploy AMOS back to Kelly's Creek again this evening, but this time I left it there. If all goes as planned, it will wake up tomorrow at 9:00 am and repeat the course shown above. At 3:00 pm it will go into rest mode, and then at 11:00 pm it will go into sleep mode. I'm kind of nervous about people tampering with it. I laminated she following sheet and duct taped it to the front deck of the boat:

AMOS – Autonomous Mini Observation System

This robotic vehicle is collecting water quality data over the area indicated in the above map. Please do not interfere or tamper with it! For more information, visit www.innaturerobotics.com or email info@innaturerobotics.com.


If somebody does steal the boat, here is a picture indicating its last known whereabouts:

I put it in the grossest, swampiest place I could find to deter would-be thieves and vandals. 😊

Tuesday, August 13, 2019

Chicken Protection

The chicken wire edition of the propeller cage was built this week:

Initially the 4 blue post holders were all glued to the the fiberglass surface of AMOS, but the front two posts lifted off when I was trying to put the cage on, so I bolted them down to the corner grommets of the solar panel instead. I'm guessing that the back posts may also lift off... if so I think I'll invest in a tube of a different type of epoxy. If anyone knows of a really good brand of epoxy that is waterproof, strong, and durable, please leave a comment below! The chicken wire seems like it will offer enough stiffness to protect against rocks and tree branches; I'll have to try it out later on this week at Woolastook to make sure.

I also bought a new LiDAR device a few days ago, and am waiting for it to arrive any day now. This particular device is IP67, so I'm hoping that it really will be waterproof. The last one (which was IP65) was unfortunately not quite waterproof, and got ruined after being left for too many days out in the rain. The new LiDAR can be configured for I2C data, so I'll try to add it to the existing I2C bus on AMOS, along with the A to D converter and the Inertial Measurement Unit. Luckily there was some Arduino driver software for it on GitHub, so I was able to port that over to suit my needs on the Raspberry Pi.

Tuesday, August 6, 2019

Long Weekend Data Testing

AMOS was once again crammed into our van along with 5 people, a dog, and a cat to visit my parents this past New Brunswick Day weekend. I was hoping to try out the air propeller cage that I had "created" by ripping apart a regular fan cage so that it only had about half of its original wire spokes. Even this reduced cage seemed kind of heavy, and I wasn't sure how well it would work atop the small servo motor.

On Saturday morning, I got a chance to try it out on a planned 7 km round trip journey. Unfortunately it only made it 2.4 km out before the wind picked up (maybe ~ 20 km/hr) and AMOS started to have trouble steering. The difficulty initially was mostly to do with software; basically the algorithm would provide a short burst of air power to either the left or right side, depending on the desired turning direction, and then it would wait for the boat to glide into the correction orientation. This had been proven to work well in calm waters, but happened to be insufficient for windy conditions with waves. After spending about 5 minutes swinging the propeller and fan cage back and forth, the lever arm connected to the servo motor slipped relative to the motor shaft (its gear teeth were later seen to be badly stripped) and the propeller swung around backwards. So I paddled over, flicked off the switch, hooked up a rope, and towed AMOS back to the cottage. During those 2.4 km, AMOS did manage to acquire some interesting data with its temperature, pH, and turbidity sensors. This data can be seen on a public arc-gis website here: https://arcg.is/18XbjH. Viewing data for all 3 sensors at the same time on the map is a bit confusing, so I created screen captures of each of the sensors separately:

The westernmost pH value is erroneous, as I had forgotten to remove the cap on the pH probe for that measurement. The turbidity measurements, are simply expressed in volts of received light level, so higher turbidity corresponds to a lower voltage value. Slightly east of the long road on the map, I believe there is a pipe emptying into the ocean. That might account for the higher turbidity, higher temperature, and slightly reduced pH at that location.

The next day, I modified the software to improve the turning function. It did seem to work pretty well for getting AMOS going in the right direction while waves were pushing it up against some rocks. About a minute later though, it appeared that the software on AMOS had crashed, as the propeller stopped turning and it slowly floated toward Prince Edward Island in a ~ 25 km/hr offshore breeze. I paddled out to rescue it, and then later looked at the log file to figure out what had happened. It turned out that the Android phone I was using to set it up had inadvertently sent out a 'q' character over the dying Bluetooth connection, at just about the point where AMOS went out of Bluetooth wireless range. 'q' was the character used by the AMOS software to quit running. I have since changed this so that the user now has to type the word "quit" before the AMOS software executes its quit function.

I have decided to get rid of the heavy metal cage. Some protection is still required for the propeller, although it doesn't necessarily have to be affixed to the propeller mounting, weighing down the servo motor. Instead, I'm going to try mounting a chicken wire cage to the surfboard itself, to form a sort of perimeter fence around the propeller. If AMOS didn't look like a redneck robot boat before, it certainly will now with the chicken wire fence around its back end. 😜

Tuesday, July 30, 2019

Setbacks And Distractions On The Road to Autonomy

Some efforts were made to print the air propeller cage design from last week, but they all failed. It was basically just too big, requiring about 24 hours to complete, and every time there was some glitch or other that would ruin the print and add a bunch more plastic to our garbage bin. So I uploaded it to the 3D printing service that I had used for some parts in the past, and got an online quote for $90 US for the cage. But it turned out that they couldn't print it either. They recommended that I try re-ordering using nylon instead of PLA and a different printing process, but that would have cost about $450 US, so I declined. Thankfully, they did fully refund the original $90.

So instead, I have tried "trimming" down the metal fan cage, by cutting and removing about half of the spokes. I also 3D printed a new piece to support it more rigidly (the previously used plywood bent too much, and ruined the gear mechanism on the servo motor). The replacement servo motor is expected on Thursday, so I'll know then if the reduced metal cage is light enough.

The Android and PC software was completed for "talking" to the 2nd humidity / temperature sensor inside the battery box and getting its data. I'll do the same for the iOS software after I get the BLE (Bluetooth Low Energy) communications board replaced with the genuine HM-10 model. I also just today added some software for switching the solar panel output voltage on / off to the charge controller. This will avoid the "sometimes" problem (in bright noonday sun) of having too much voltage output from the controller, which causes the electronic speed controller to complain and make beeping noises without turning the propeller. 

My brother, Andrew had asked me to consider some ideas for aspects of AMOS that could function as standalone student projects. The ideas that I came up with were (i) a sensor deployment mechanism for deploying one to four sensor probes into water at depths up to 30 m, (ii) a new layout configuration for the surfboard, boxes, and solar panel that reduces everything from a 2.5 m x 0.6 m x 0.6 m form factor to a 1.8 m x 0.6 m x 0.4 m form factor, and (iii) a fiber optic turbidity probe. The fiber optic turbidity probe is not directly related to the core work that is required for AMOS, but could potentially be an interesting product in its own right. Basically it would use two multimode fiber optic cables connected at one end to a single 850 nm LED, and at the other end to two photodiodes. One cable would have a large break in its path (perhaps 20 mm?) that passes through the water being tested, and the other cable would have a much shorter break (perhaps 2 mm?) near the same location as the first, but not close enough that light would interfere from one fiber to the other:

The received light level for the path with the short break should be minimally affected by light scattering due to turbidity, whereas the received light level for the other path should be significantly affected by light scattering due to turbidity. Both paths should experience similar light loss due to LED power fluctuations, temperature effects, fiber bending,  and environmental fouling within the sensor chamber. The sensor design has the advantage that a pressure-tight sensor housing is not required, as there are no electrical components within the sensor chamber itself. Hopefully the ratio of the received light levels would follow some sort of repeatable function as the turbidity is varied say between 0 and 3000 NTU.

Another idea that might be kind of cool would be a sort of "production" robot (robots making robots!) that uses a foam hot wire cutter to automatically cut out and shape the foam pieces that form the AMOS surfboard. This would save considerable time, and probably improve the consistency and quality of the final product.

Tuesday, July 23, 2019

Getting Autonomous-Ready

One of the missing requirements for an autonomous vessel was the capability to remotely login to the  Raspberry Pi computer on AMOS and change configuration file settings, upload / download files, make code changes, reboot, etc. The problem was that even if you did happen to know what the actual Internet address was for AMOS, the cell network or some other networking layer would not allow you to setup for example a secure shell (SSH) server on port 22 (or any other port I think). I had hoped that setting up port forwarding on the USB hotspot device would do the trick, but it did not. After a fair amount of Google searching, I came across https://remote.it/ which allowed me to do exactly what I wanted. Essentially they act as a sort of go-between, between AMOS and the remote user. So by registering AMOS with their service, I can open up a terminal session on  my PC to AMOS, so long as AMOS has some sort of link to the Internet.

A second humidity sensor was added to the battery box this past week, along with some software for getting data from it. I still need to add more software for the iOS, Android, and PC apps though to include this extra data. Also, the new (genuine) HM-10 Bluetooth Low Energy module arrived this week, so I'll need to hook that up soon and replace the cheap imitation version that I have been using up until now.

Kirsten and I took AMOS out to Woolastook for a field test on the weekend, but it didn't go well. The metal cage was too heavy, and would pitch forward and get stuck on the servo motor arm, making any sort of steering impossible. We went for a canoe trip anyway though, and towed AMOS along behind us. So it's back to a plastic cage for the air propeller I guess. Here is a 3D model of half the cage:

I'm not sure yet if this model will fit on my 3D printer, I'll give it a try tomorrow. It might just barely fit on the bed if I align it diagonally, although it will require a lot of support material when aligned that way. Oh well, if it works it will be a lot less expensive than outsourcing the print. This particular curved design is better than the previous 3D printed model, as it does not require additional metal rods for the sides, and has more and thicker spokes, so should be considerably more durable.

Tuesday, July 16, 2019

Cage and Bluetooth Upgrades

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