Tuesday, February 26, 2019

Ship Without a Rudder

The bracket that was 3D-printed last week was used to fasten the air propeller cage to the yaw-direction servo motor. Although the servo motor does have a range of +/- 90 degrees, the zero degree position is skewed about 20 degrees relative to the body of the motor, and since I didn't mount the motor at a 20 degree angle relative to AMOS, and chose to make the range of motion symmetric in the software, this meant that the actual range of motion was only +/- 70 degrees. This should still be good enough to turn effectively, although I guess another pool test will be required to confirm that.

As can be seen in the following video, the propeller cage can be moved quite rapidly, but tends to oscillate a lot when stopped abruptly:


Also, the propeller cage tends to pitch forward a bit as the thrust is increased. To help remedy these things, a small plastic piece was 3D printed, and glued to the bottom-front of the cage. The piece helps to stabilize the cage against the top cover of the enclosure. Because the servo is tilted a bit though, and the top cover of the enclosure is not quite flat, the printed part only makes contact within about a +/- 30 degree range. Here is a short video of the motion within that range with the part attached:



The oscillations were reduced with the front support added, but not eliminated entirely. Possibly some springs could be used somewhere to smooth things out further, or maybe the code could be modified to add acceleration / deceleration. 

A communications bug was discovered and hopefully fixed this past week. This bug likely accounted for the intermittent wireless problems during the pool test. There are a handful of commands that can be sent to AMOS over a wireless serial link; included among these is a command for putting AMOS to sleep. The commands (as originally conceived) were fairly simple, ex: 'd' followed by a number and a carriage return to put AMOS to sleep for a specified number of minutes. This simplicity however, resulted in occasional, accidental commands getting issued as a result of the regular serial data traffic between AMOS and the host PC. So to remedy this, the commands have been made much more difficult to execute randomly. For example, to put AMOS to sleep, at least 6 character bytes are now required in the following sequence: 'd', 'o', 'w', 'n', <number of minutes>, <CR>. The odds of getting this sequence randomly (assuming data traffic with a random distribution of bytes) should be less than (1 / 256) ^ 5 or less than 1 in a trillion.

Today a real-time clock (RTC) arrived in the mail, so I hope to have that hooked up and ready to go 
tomorrow. The instructions for configuring the Raspberry Pi look relatively straightforward, and actually if everything works as described, no programming should be required. This will allow AMOS to keep time, even when it is turned off or unplugged from the main battery (the RTC has a coin-cell battery backup).







Tuesday, February 19, 2019

Indoor Pool Test

(Video by Hannah Simpson)

This past weekend Hannah and I took AMOS to the After School Pool Club in Fredericton for a quick one hour test. This was the first time that the new surfboard design had been tested in the water. The pool measured 40 ft x 20 ft, so we had to be a bit careful with the driving to avoid smashing into the walls too much. Steering with the air rudder was a bit sluggish, and took some practice to get the boat moving and turning in the desired direction. Also, the coat hanger cross-piece that joined the two rudders slipped out of its mounting hole a few times, which required some manual intervention with a pair of pliers to set it back into place.

As can be seen in the short video, the boat is quite buoyant; the rockered front and back pieces don't even touch the water. Probably the boat could have been constructed from a single piece of foam insulation, rather than the double-layer that was used in this build.

After bumping into the wall at one point, wireless communications was lost, and this required a reboot and an inspection of the main compartment, which revealed that a USB power cable had slipped out slightly. After re-inserting the cable, the wireless still seemed pretty spotty for a few minutes, but then seemed to somehow magically fix itself and work well again. Not sure what happened there, I'll have to go over the ship log files to see if they offer any clues.

The difficulty with the rudder prompted a re-design of how AMOS steers. Rather than use a pair of rudders to control the direction of air flow, it was decided to just rotate the propeller itself and dispense with the rudders altogether. Today, I 3-D printed a bracket for attaching the propeller assembly to the same servo motor that was used for the rudders. The servo is fairly powerful, so should have no trouble rotating the rudder I think. The servo offers +/- 90 degrees of rotation, which should allow for tighter turns vs. what could be achieved previously with the rudders. I'll need to lengthen the power cables going to the propeller though before trying it out, to avoid straining them too much for large rotation angles.

A nice little bug was also found and fixed this week. When testing out the Boat Captain PC software, I noticed that the GPS timestamps shown on the PC screen seemed to be a few minutes off. The discrepancy was traced back to some code for reading in the streaming GPS data, which was delaying for too long in a loop, so that GPS data was not being read in as fast as it was arriving, resulting in old, buffered data being used for the "current" position. This bug has been present since almost day 1, but may have only become an issue after testing for a while (say half an hour or more). It very likely was responsible for some of the odd navigational behavior that I observed during some of last summer's tests.


Tuesday, February 12, 2019

Not Enough Cold Power

AMOS the backyard datalogger was particularly challenged this past week by very cold, windy weather. Although its 10 amp-hour lithium ion battery is rated for operation at -20 degrees C, it still tended to lose charge rather quickly on nights when the temperature dropped below -15 degrees C. On nights when AMOS was outside, I would usually unplug it before going to bed in order to prevent the battery from getting totally depleted (which would engage its internal battery management system to shut itself off). The Raspberry Pi is relatively power hungry, requiring on average about 5 W of power to run. Just running the Pi, the 10 amp-hour, 12 V battery would not last more than 20 hours.

Running just the RFU220 (wireless) module, the power required is only about 0.5 W, so I decided to try shutting down the Pi for the better part of an hour, waking it up at the top of each hour to boot up, synchronize with a timer server on the Internet to get the correct time (no real-time clock yet), and then log a bit of data, before the RFU220 shuts it back down. The whole process typically required a few minutes to complete. Indoors, it worked fine, AMOS still had lots of charge after operating more than 20 hours in this fashion. Outdoors was a completely different story though. Once the sun went down, most of the battery's life was gone (maybe 20% left?) by about 11 pm. Also, I noticed when the temperature dropped below -10 degrees C, that the speed controller would not function correctly, and the air propeller would beep rapidly and shake back and forth in protest. Turning off the +12 V power supply stopped the shaking and beeping.

So bottom line I guess, is that AMOS won't be going on a polar expedition any time soon.

The ACS712-based current sensor that was described last week was tested out quite a bit this week. Turns out that it is not particularly accurate for low current levels (less than one amp) and seems to have a strong temperature dependence. However, it is useful as a rough gauge of current consumed when the propeller is running, and is also useful in seeing how quickly charge is being applied (when the sun is out and the measured current goes negative).

(The ACS712-based current sensor. The hand model used here should probably use more moisturizer.)


Recently I have been working on the wireless serial communications software for AMOS, improving various things to make it more reliable, especially when signal quality becomes poor.

Tuesday, February 5, 2019

Backyard Datalogger


AMOS is now quietly sitting in the backyard, next to a discarded Christmas tree and a few frozen dog turds. To save battery life, when the sun is not shining, it has been programmed to collect a sample of data (currently just internal and external temperature, a phony pH reading, plus GPS position) and then shut down its main processor (the Raspberry Pi). The small wireless unit (RFU220) continues to run and keeps track of how much time to wait before sending a signal to re-power the Pi. The RFU220 also maintains a PWM signal for the air propeller, so that it does not make an annoying beeping noise when the Pi gets powered down (normally one of the PWM outputs from the Pi is used to control it). If necessary, it is possible to connect (using a 2nd RFU220 at my PC) to wake up AMOS early, make software changes, collect data, etc.

Last week I noticed that the op-amp that I was using for estimating the current draw on the +12 V power line was busted. I'm not sure when this actually occurred, possibly it was some time ago. Rather than attempt to re-build another one of my own design, it seemed like a better approach might be to buy a "ready-made" current module. This one from Amazon looked pretty good:

https://www.amazon.ca/dp/B07JW5R4J8/ref=pe_3034960_236394800_TE_dp_1

It is based on the ACS712 module which uses a Hall-effect sensor to accurately measure current levels up to +/- 20 A. Furthermore, I can place it directly in line with the positive 12 V battery terminal, which should give a good indication of how much current is coming out (or going in when the sun is really shining) of the battery. Adding some monitoring software (on the RFU220) could allow AMOS to get a decent estimate of its charge state in terms of some percentage of full-charge.

The I2C issues dealt with last week are mostly solved, although occasional I2C bus errors still sometimes occur. The errors seem more frequent when the propeller is going at high speed, so possibly some electrical fine tuning of things could help there. I think for now though, the errors are at a low enough frequency (~ 1% or less) that I can just live with it.