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