A few things were accomplished this past week. Firstly, AMOS set a couple of new single-outing distance records. On May 23, it traveled 5.35 km in 1 hour and 12 minutes, going back and forth on my usual Woolastook GPS course:
The day started off well weather-wise, but quickly became overcast, and at the 1 hour 12 minute mark, the battery gave out. I'm not certain that it was completely charged prior to the test though.
Today the weather was nice and sunny, and AMOS got a new distance record of 6.12 km on the same course, before I noticed that the screws were loose on the propeller mount causing it to bang around like crazy inside the cage. I'll need to find a more secure way of fastening the screws; perhaps use Loctite or something. For this second test, AMOS was a bit slower; possibly because the weather was a bit windier, but also because I had accidentally sheared off a plastic clip on the side of the boat when loading it into the van, causing a long plastic piece of conduit holding some wires to periodically dip into the water, producing drag. It was encouraging to notice after this second test that the battery voltage (when not running) was the same 13.2 V that it was before the test. Since voltage was recorded every minute in the ship log, I was able to plot a comparison of the voltage levels for the cloudy vs. sunny tests:
As can be seen from the above graph, the fall-off in voltage under high load can be pretty steep if the sun isn't around to keep the battery charged up. At present the software in AMOS is not making any decisions based on voltage, but probably there should be something to put the boat into a low-power state once the voltage gets down to ~ 11 V.
The other big accomplishment this week was that I finally got serial wireless communications from the Android phone (or PC) to Bluetooth (or a USB serial cable) to the RFU220 transmitter to AMOS and back again working much faster, so that it is now actually feasible to download a small image file from the boat. This actually required a few weeks to get right, and up until a few days ago I was semi-convinced that there must have been serious hardware problems impeding correct communications. But the issues were all software. Once the timeouts, flushing, buffering, etc. were finally set properly it just worked. 😸
Edit: Here are the pictures of the screws (indicated by thin red arrows) that came loose:
The stainless steel M3 screw in the top picture is used to hold down the arm mechanism for the servo motor that controls the direction of the propeller. When I noticed that the two black screws were loose (lower picture) there were no screws whatsoever in the other two holes on the same mounting plate. I don't remember if I forgot to screw them in, or more likely they vibrated out at some point and were forever lost. So I'm using a couple of stainless screws now in those holes instead.
Tuesday, May 28, 2019
Tuesday, May 21, 2019
Minus One Box
The last week was mostly spent on modifying AMOS to have a lower profile in the water, so that it is not as strongly affected by high winds. This was done by moving the electronics from the 3rd largest box into the 2nd box which was only about half full and had some room to spare. Work was also done to move the power switch from the top of the 2nd box to the side, and to re-wire it to make use of a waterproof gland. After having rain nearly every day this week, I can say with some confidence that the new switch design is waterproof. The old design was not, and I think the box would have been half-full of water if the old switch were still in place.
I traced around the two electronics boxes with a sharpie and then used a drill to cut out a rectangular portion of the fibreglass shell. Then it was a time consuming, mind numbing chore to dig out the pink foam insulation 1 cubic centimeter at a time with a pair of large pliers. Here is a picture of the half-finished work:
I basically just dug down to the depth of the bottom layer of pink insulation. This bottom layer was quite thin at either end of the boat where the boxes were located, since that was where the surfboard shape started to taper.
Here is the finished result, as seen in our pool at night:
I traced around the two electronics boxes with a sharpie and then used a drill to cut out a rectangular portion of the fibreglass shell. Then it was a time consuming, mind numbing chore to dig out the pink foam insulation 1 cubic centimeter at a time with a pair of large pliers. Here is a picture of the half-finished work:
I basically just dug down to the depth of the bottom layer of pink insulation. This bottom layer was quite thin at either end of the boat where the boxes were located, since that was where the surfboard shape started to taper.
Here is the finished result, as seen in our pool at night:
The yellow stuff in front of the box is globs of old glue that were used to hold the box to the board in its former location. The box had to be moved back a bit from the front to an area where the board was thicker.
I have avoided going out for a field trial the past few days due to poor weather, and decided to focus instead on trying to solve some strange communications problems with the Android phone to transmitter box to boat link. Sending and receiving of short commands less than about 100 bytes work great, but trying to send and receive larger things such as image files has proven more challenging. For some reason that I haven't been able to figure out, bytes are getting periodically garbled and I'm not sure why. I use sync bytes, checksums and a sort of packet re-try system which gets the data to arrive eventually, but it's painfully slow. I thought I had it for sure tonight when I discovered that the 3 AA alkaline batteries in the transmitter were down to about 1.25 V each, but that wasn't it at all. Brand new batteries worked exactly the same. I also thought I would fix it by changing from 115200 bps to 9600 bps, but that didn't help at all either. Sometime later I'll try using a PC to transmitter to boat link to see if that works any differently (i.e. bypass the Bluetooth link to see if that helps).
Tuesday, May 14, 2019
Battle Against The Wind
Yesterday, I brought AMOS back to Woolastook for another test run. Wires and batteries had been moved out of the immediate vicinity of the electronic compass, and some of the control parameters in the software had been tweaked a bit, in the hope that AMOS would more consistently travel in a straight line. Also, I had modified the mounting of the air propeller assembly slightly to help avoid a problem with it sometimes flying off the shaft of the servo motor in high winds. I was optimistic that things would go well...
So I was naturally disappointed when AMOS took off for its destination and promptly ran into the east bank of the inlet. I got in the kayak, paddled a few meters, and then freed it from the grass (more work is required for AMOS to do this by itself). Then AMOS went off in the opposite direction, this time getting stuck on the west bank. I paddled over to free it again, then brought it to shore and connected it to my laptop to check the ship logs to see what might have gone wrong. The logs revealed that AMOS required a long time to get a valid GPS fix, and even when it did get a fix, the initial GPS coordinates were off by quite a lot. For example:
in the above photo the actual GPS track that AMOS thought it was following is given by the thin blue line in the lower-left corner. Although it actually started at the base of the inlet, it thought it was starting about 10 m west of Route 102, and therefore plotted the first interpolated GPS coordinate at a point just west of Route 102. Later, it acquired an accurate GPS position, but by that time it was already headed for an incorrect destination, and kept ramming itself into the west bank accordingly.
After checking the ship logs, the test was repeated, this time with the following result:
This time the interpolated points were plotted correctly, but the GPS location of AMOS seemed to usually be biased about 10 m to the south of where it should have been. So this time AMOS kept crashing repeatedly into the eastern shore. Plotting more frequent GPS waypoints in the center of the inlet probably would have worked a lot better.
At this point, I gave up on the planned GPS course and just tried piloting AMOS around manually. This proved to be more challenging than I expected. I had thought that I would be able to find an azimuth angle for the ship's propeller that would allow AMOS to proceed in a nice straight line, but there was a relatively strong wind coming out of the east that day, with gusts that were probably in excess of 30 km/hour. The gusting wind required constant attention to the azimuth angle of the propeller, and more often than not I would get it wrong, so that AMOS ended up making a lot of circles out in the open water. Eventually, I gave up and just set the angle of the propeller to the zero degree position and observed what kind of a path the boat followed:
The gusting wind proved to be a bit much for AMOS, especially when the boat was headed directly into it. A quick calculation after I got back confirmed that the wind was probably about 30 km/hour:
Assume that the surface area of the boxes and board that are facing into the wind is ~ 0.1 m^2., air density is 1.2 km/m^3, and the wind speed was 30 km/hour or 8.3 m/s:
Force = 0.5 * 1.2km/m^3 * (8.3 m/s)^2 * 0.1 m^2 = 4.1 N = 0.9 lbs.
This wind force is quite close to the maximum thrust of the air propeller on AMOS (~ 1 lb), hence the reason why AMOS appeared to be stalled in the water when the wind picked up.
There are a few ways to combat this wind effect:
1) Reduce the cross-sectional area of material that is facing into the wind.
2) Change the shape of the boxes on AMOS to make them more streamlined, so that the wind flow does not separate as much when it hits them.
3) Increase the thrust of the air propeller, either by upping the pulse frequency on the current setup or by getting a new (larger) propeller and motor altogether. This latter option might also require a beefier battery pack, and a more robust protective cage. I have already had to glue together the existing 3-D printed cage numerous times to repair it after crashes with brush and other shore obstacles.
First I'm going to try #1 above by getting rid of the 3rd largest box (it's almost empty now anyway) and mounting the propeller on the 2nd box instead. The two remaining boxes will then be embedded about 4 or 5 cm into the foam of AMOS. This should hopefully reduce the cross-sectional area down from about 0.1 m^2 to something like about 0.07 m^2. I should also be able to increase the thrust on the current propeller / motor a little bit without too much difficulty or worry of things overheating or drawing too much current. Since the wind force scales as velocity squared though, this would probably only get me up to about 45 km/hour. Perhaps some smart software could be added to drive AMOS at an angle to the wind (say 45 degrees) which could in theory maybe allow for forward progress in winds up to about 60 km/hour. Maybe some future version could also use flatter waterproof boxes so as to get the cross-sectional area down even more.
So I was naturally disappointed when AMOS took off for its destination and promptly ran into the east bank of the inlet. I got in the kayak, paddled a few meters, and then freed it from the grass (more work is required for AMOS to do this by itself). Then AMOS went off in the opposite direction, this time getting stuck on the west bank. I paddled over to free it again, then brought it to shore and connected it to my laptop to check the ship logs to see what might have gone wrong. The logs revealed that AMOS required a long time to get a valid GPS fix, and even when it did get a fix, the initial GPS coordinates were off by quite a lot. For example:
in the above photo the actual GPS track that AMOS thought it was following is given by the thin blue line in the lower-left corner. Although it actually started at the base of the inlet, it thought it was starting about 10 m west of Route 102, and therefore plotted the first interpolated GPS coordinate at a point just west of Route 102. Later, it acquired an accurate GPS position, but by that time it was already headed for an incorrect destination, and kept ramming itself into the west bank accordingly.
After checking the ship logs, the test was repeated, this time with the following result:
This time the interpolated points were plotted correctly, but the GPS location of AMOS seemed to usually be biased about 10 m to the south of where it should have been. So this time AMOS kept crashing repeatedly into the eastern shore. Plotting more frequent GPS waypoints in the center of the inlet probably would have worked a lot better.
At this point, I gave up on the planned GPS course and just tried piloting AMOS around manually. This proved to be more challenging than I expected. I had thought that I would be able to find an azimuth angle for the ship's propeller that would allow AMOS to proceed in a nice straight line, but there was a relatively strong wind coming out of the east that day, with gusts that were probably in excess of 30 km/hour. The gusting wind required constant attention to the azimuth angle of the propeller, and more often than not I would get it wrong, so that AMOS ended up making a lot of circles out in the open water. Eventually, I gave up and just set the angle of the propeller to the zero degree position and observed what kind of a path the boat followed:
The gusting wind proved to be a bit much for AMOS, especially when the boat was headed directly into it. A quick calculation after I got back confirmed that the wind was probably about 30 km/hour:
Assume that the surface area of the boxes and board that are facing into the wind is ~ 0.1 m^2., air density is 1.2 km/m^3, and the wind speed was 30 km/hour or 8.3 m/s:
Force = 0.5 * 1.2km/m^3 * (8.3 m/s)^2 * 0.1 m^2 = 4.1 N = 0.9 lbs.
This wind force is quite close to the maximum thrust of the air propeller on AMOS (~ 1 lb), hence the reason why AMOS appeared to be stalled in the water when the wind picked up.
There are a few ways to combat this wind effect:
1) Reduce the cross-sectional area of material that is facing into the wind.
2) Change the shape of the boxes on AMOS to make them more streamlined, so that the wind flow does not separate as much when it hits them.
3) Increase the thrust of the air propeller, either by upping the pulse frequency on the current setup or by getting a new (larger) propeller and motor altogether. This latter option might also require a beefier battery pack, and a more robust protective cage. I have already had to glue together the existing 3-D printed cage numerous times to repair it after crashes with brush and other shore obstacles.
First I'm going to try #1 above by getting rid of the 3rd largest box (it's almost empty now anyway) and mounting the propeller on the 2nd box instead. The two remaining boxes will then be embedded about 4 or 5 cm into the foam of AMOS. This should hopefully reduce the cross-sectional area down from about 0.1 m^2 to something like about 0.07 m^2. I should also be able to increase the thrust on the current propeller / motor a little bit without too much difficulty or worry of things overheating or drawing too much current. Since the wind force scales as velocity squared though, this would probably only get me up to about 45 km/hour. Perhaps some smart software could be added to drive AMOS at an angle to the wind (say 45 degrees) which could in theory maybe allow for forward progress in winds up to about 60 km/hour. Maybe some future version could also use flatter waterproof boxes so as to get the cross-sectional area down even more.
Tuesday, May 7, 2019
Big Logs and Big Magnets
There was still a thin skim of ice over part of the head pond at Woolastook last week when I took AMOS out for a test run. The test started off poorly, with AMOS spinning around in a number of crazy circles, before the screws holding the propeller to the servo motor loosened and the propeller pitched forward onto the deck of the boat. Unfortunately I didn't have any Allen keys with me to tighten the screws, so the testing for that day pretty much had to end there.
The spinning in circles was a problem, and testing the compass output the next day revealed that the LiDAR module was no longer working and was drawing an inordinate amount of current. This current passed through a wire which happened to be in close proximity to the electronic compass, causing a great deal of noise and interference in its magnetic heading output. Opening up the LiDAR electronics enclosure revealed that some water must have gotten into it at some point, as many of the circuit components on the lower half of the board were badly corroded. Its enclosure is supposed to be IP65, so I had hoped it would do better than that if left in the rain or splashed occasionally by waves. So I guess I'll need a new LiDAR module at some point. I'm planning to upgrade to this one: https://www.robotshop.com/ca/en/lidar-lite-3-laser-rangefinder-high-performance-llv3hp.html I think since it is IPX7 rated, capable of being dunked in 1 m of water, able to communicate over I2C, and also draws less than half the current than the previous model I was using. It would also free up a serial port on the Pi for some other (TBD) purpose.
Thinking that the magnetic heading issues had been completely solved, I returned to Woolastook the next day to repeat the test. AMOS fared better this time, but still weaved badly back and forth. Some simple tweaking of the control parameters were able to mostly fix this, but when travelling in certain directions it still tended to weave back and forth quite badly. Also, there was a large amount of floating debris in the pond that day, probably from all the recent flooding the St. John River has seen lately. A couple of times, AMOS got badly slowed down after driving over (and trapping) large logs:
This version of AMOS moves a bit faster than its beer cooler predecessor and it does so using considerably less forward thrust (about 1 pound vs. almost 10 pounds for the beer cooler version). It is able to do this because of its shallow draught and more hydrodynamic shape.
More testing of the electronic compass today demonstrated that the Lithium ion CR2032 battery used to power the real time clock was fairly magnetic, and since it was nearby the compass was also interfering with the heading output. So I re-wired the compass module to be further away from everything, in its own corner of the front enclosure. An initial garage test seemed to indicate that it was working reasonably well, giving headings that were probably accurate to within about +/- 20 degrees. Some further tweaking of the control parameters will probably also be required, but hopefully I should be able to get this version of AMOS to move consistently in nice straight lines soon.
The spinning in circles was a problem, and testing the compass output the next day revealed that the LiDAR module was no longer working and was drawing an inordinate amount of current. This current passed through a wire which happened to be in close proximity to the electronic compass, causing a great deal of noise and interference in its magnetic heading output. Opening up the LiDAR electronics enclosure revealed that some water must have gotten into it at some point, as many of the circuit components on the lower half of the board were badly corroded. Its enclosure is supposed to be IP65, so I had hoped it would do better than that if left in the rain or splashed occasionally by waves. So I guess I'll need a new LiDAR module at some point. I'm planning to upgrade to this one: https://www.robotshop.com/ca/en/lidar-lite-3-laser-rangefinder-high-performance-llv3hp.html I think since it is IPX7 rated, capable of being dunked in 1 m of water, able to communicate over I2C, and also draws less than half the current than the previous model I was using. It would also free up a serial port on the Pi for some other (TBD) purpose.
Thinking that the magnetic heading issues had been completely solved, I returned to Woolastook the next day to repeat the test. AMOS fared better this time, but still weaved badly back and forth. Some simple tweaking of the control parameters were able to mostly fix this, but when travelling in certain directions it still tended to weave back and forth quite badly. Also, there was a large amount of floating debris in the pond that day, probably from all the recent flooding the St. John River has seen lately. A couple of times, AMOS got badly slowed down after driving over (and trapping) large logs:
Here is a video showing AMOS take off in a nice straight line:
This version of AMOS moves a bit faster than its beer cooler predecessor and it does so using considerably less forward thrust (about 1 pound vs. almost 10 pounds for the beer cooler version). It is able to do this because of its shallow draught and more hydrodynamic shape.
More testing of the electronic compass today demonstrated that the Lithium ion CR2032 battery used to power the real time clock was fairly magnetic, and since it was nearby the compass was also interfering with the heading output. So I re-wired the compass module to be further away from everything, in its own corner of the front enclosure. An initial garage test seemed to indicate that it was working reasonably well, giving headings that were probably accurate to within about +/- 20 degrees. Some further tweaking of the control parameters will probably also be required, but hopefully I should be able to get this version of AMOS to move consistently in nice straight lines soon.
Tuesday, April 30, 2019
The Cost of Building AMOS
The past couple of days were a bit of a mad scramble to search through old receipts from 2018 and figure out how much I owed our government in taxes. In doing so, I found out that almost $5000 was spent on hardware expenditures for AMOS. Of this amount, probably less than $2000 was for parts that are currently being used on the second surfboard prototype. Some electronic circuit boards got fried, some things such as the water propellers and kayak beer cooler are no longer used, and some of the $5000 was for items such as a 3D printer and other smaller tools that were necessary for building and repairing various things. Of course the much larger cost associated with this project was the large amount of time spent, and the opportunity cost of not working at a paying job full-time.
Today was a small breakthrough software-wise, as I was able to finally fix some issues with the Bluetooth Low Energy (BLE) communications between the Android app and the battery powered wireless transmitter. The communications had generally worked well for sending small packets of information, ex: commands for steering or propelling AMOS forward, but tended to fail quite often when sending larger amounts of information, such as for transmitting image data. BLE splits up communications into packets of about 20 bytes or less, which complicates things somewhat. Also, the closer you get to the minimum wireless power level, the more inconsistent the communications get, with timeouts and garbled data becoming more frequent. Since the serial wireless link I am using for long range communications (the RF220SU) does not have a particularly robust hardware layer for dealing with errors, I ended up having to do it myself in software. Non-essential small packets are still sent as they were before, with just some basic identification bytes and a few bytes of actual data. For larger amounts of data, I created a packet structure that had some header bytes to identify the packet and indicate how much data was to follow, and then included a couple of checksum bytes at the end. A basic handshaking protocol was also used to acknowledge the receipt of each packet sent. And then a series of retries and timeouts was used to help ensure that the data arrived. Once all the glitches were solved (and there were quite a few of those) it seemed to work pretty well.
Today was a small breakthrough software-wise, as I was able to finally fix some issues with the Bluetooth Low Energy (BLE) communications between the Android app and the battery powered wireless transmitter. The communications had generally worked well for sending small packets of information, ex: commands for steering or propelling AMOS forward, but tended to fail quite often when sending larger amounts of information, such as for transmitting image data. BLE splits up communications into packets of about 20 bytes or less, which complicates things somewhat. Also, the closer you get to the minimum wireless power level, the more inconsistent the communications get, with timeouts and garbled data becoming more frequent. Since the serial wireless link I am using for long range communications (the RF220SU) does not have a particularly robust hardware layer for dealing with errors, I ended up having to do it myself in software. Non-essential small packets are still sent as they were before, with just some basic identification bytes and a few bytes of actual data. For larger amounts of data, I created a packet structure that had some header bytes to identify the packet and indicate how much data was to follow, and then included a couple of checksum bytes at the end. A basic handshaking protocol was also used to acknowledge the receipt of each packet sent. And then a series of retries and timeouts was used to help ensure that the data arrived. Once all the glitches were solved (and there were quite a few of those) it seemed to work pretty well.
Wednesday, April 24, 2019
Security Breach
On the evening of April 15 I unwittingly made a blunder in uploading a configuration file that contained some texting and email credentials to a site for storing source code (GitHub). To its credit, GitHub promptly emailed me a warning message to alert me that I was "sharing too much". But I had left the computer to go eat some supper and do other things, and didn't return until about 3 hours later. At that time, I discovered that the account password used to allow AMOS to send text messages had been changed, and there were notifications of hundreds of errors in my inbox, relating to this texting account. This was not good. In order to remove any trace of the file online, I removed the entire GitHub repository. I then contacted the texting service company to alert them that my account had been compromised. They gave me some instructions to follow in order to change my credentials, but the account had already been associated with a new email address, so I was unable to do that (the file shared on GitHub also had email credentials, so they must have used my Gmail address and password to read my Gmail, and thereby change the texting account info). I informed the texting service of that and requested that they freeze my account if possible.
The account was frozen, but not before $170 of texting charges had been racked up. More back and forth with the texting provider got my account set back up properly though, and thankfully no more charges have been incurred. I also changed my Gmail password of course, and many of my other passwords too, just as a precaution, in case they also might have been accessible through Gmail. I had a look at one of the phony messages and it was in French, and I think it was one of those: "Something bad has happened to your account, please click this link: ..... to fix the problem." messages. So to the thousands of people that received these, please accept my sincere apologies.
I have since enabled two-factor authentication for my texting account and will also make sure any other passwords stored in configuration files are encrypted. Nothing beats learning the hard way eh?
The account was frozen, but not before $170 of texting charges had been racked up. More back and forth with the texting provider got my account set back up properly though, and thankfully no more charges have been incurred. I also changed my Gmail password of course, and many of my other passwords too, just as a precaution, in case they also might have been accessible through Gmail. I had a look at one of the phony messages and it was in French, and I think it was one of those: "Something bad has happened to your account, please click this link: ..... to fix the problem." messages. So to the thousands of people that received these, please accept my sincere apologies.
I have since enabled two-factor authentication for my texting account and will also make sure any other passwords stored in configuration files are encrypted. Nothing beats learning the hard way eh?
Tuesday, April 16, 2019
Living The Dream
Some days living the dream is harder than others. Today was one of those days. Work on AMOS was delayed for about an hour this morning due to a clogged kitchen sink. I tried using a plunger, sucking the drain with a shop vac, and poking around with a long piece of plastic, to no avail. The smell of the water that came out had a disgusting fishy odor, but whatever solid material was in there was not budging. While doing this, Kirsten was in a minor panic before her math test, and was texting every few minutes for advice on how to solve a couple of problems.
After giving up on the sink, I continued adding some code to the iOS version of Boat Captain for Bluetooth Low Energy (BLE) communications with the AMOS remote controller. Here's a picture of the remote controller inside a waterproof Pelican case:
Some of the wires in there have pins on both ends and are intended for prototyping boards. The problem though is that sometimes the crimped connections to these pins fail (especially when you cram the wires into little boxes). I wasted 2 hours on Friday trying to figure out why some new software changes were not working; only to discover that a broken wire in the remote controller box was to blame.
After the morning sun had charged AMOS up a bit, I took the Android phone, the remote controller box, and AMOS and headed over to the beaver pond across the road. Normally the area of the pond near the road is overgrown with grass and vegetation, but at this time of year, there is a nice bit of water there, with a substantial layer of ice a couple of inches below the surface.
Here was the launching point for AMOS:
The moment the propeller was turned on, I heard a loud honking coming from nearby:
It was a large goose, and he (or she) did not seem pleased to have AMOS motoring around on its turf. It did eventually stop honking, but remained standing nearby for at least half an hour. Driving AMOS around in this location was pretty tricky. There were a lot of ice patches, tufts of grass, and a high amount of wind. AMOS seemed a bit under-powered. Maybe a beefier motor and propeller would help things a bit. Possibly it would have been easier to steer if the phone acted as a tilt controller, instead of using regular push buttons, ex: tilt forward to go forward, tilt left to turn left, etc. Eventually AMOS ran aground on an ice patch, so I just left it there to grab some lunch and then ran to Measurand.
After giving up on the sink, I continued adding some code to the iOS version of Boat Captain for Bluetooth Low Energy (BLE) communications with the AMOS remote controller. Here's a picture of the remote controller inside a waterproof Pelican case:
Some of the wires in there have pins on both ends and are intended for prototyping boards. The problem though is that sometimes the crimped connections to these pins fail (especially when you cram the wires into little boxes). I wasted 2 hours on Friday trying to figure out why some new software changes were not working; only to discover that a broken wire in the remote controller box was to blame.
After the morning sun had charged AMOS up a bit, I took the Android phone, the remote controller box, and AMOS and headed over to the beaver pond across the road. Normally the area of the pond near the road is overgrown with grass and vegetation, but at this time of year, there is a nice bit of water there, with a substantial layer of ice a couple of inches below the surface.
Here was the launching point for AMOS:
The moment the propeller was turned on, I heard a loud honking coming from nearby:
It was a large goose, and he (or she) did not seem pleased to have AMOS motoring around on its turf. It did eventually stop honking, but remained standing nearby for at least half an hour. Driving AMOS around in this location was pretty tricky. There were a lot of ice patches, tufts of grass, and a high amount of wind. AMOS seemed a bit under-powered. Maybe a beefier motor and propeller would help things a bit. Possibly it would have been easier to steer if the phone acted as a tilt controller, instead of using regular push buttons, ex: tilt forward to go forward, tilt left to turn left, etc. Eventually AMOS ran aground on an ice patch, so I just left it there to grab some lunch and then ran to Measurand.
After supper, I returned to the pond to find that AMOS was still in the same spot, but the ice had risen up under it. Of course it was still impossible to get AMOS moving off the ice on its own power, but an attempt to do so attracted the attention of a curious beaver who poked his head up a couple of times to have a look.
Fearful of what might happen to AMOS overnight if I left it with the geese and beavers, I went back home to fetch the kayak. With a bit of effort, I was able to slowly paddle and pole the necessary 100 feet or so to retrieve it and bring it back to our backyard.
I spent the remainder of today ramming a plumber's snake down our kitchen drain, without any luck. Still clogged, so I guess we will have to call a plumber. Kirsten said she aced her math test though, so at least there's that! 😸
Subscribe to:
Posts (Atom)








