Communications update

A project log for DIY Airboat and Controller

A small, flexible boat and controller system able to travel where a standard boat could not go.

CompuCatCompuCat 08/30/2014 at 12:220 Comments

*EDIT* Whoops, almost forgot! The new code is in the project files folder, along with the old code for reference.

It's time for me to get rid of my old, bloated communications system and replace it with a faster alternative.

My old system would constantly send 5 byte packets:

This is a horribly bloated system. Even if a parameter's value doesn't change, it still wastes time sending the old value. Also, the triggers are digital buttons and can be consolidated into a single byte. To save time, I changed the protocol to send 3 byte packets:

The command-data 2 byte system (thanks, Quinn Dunki for the idea!) allows me to send only the values that change. I can also set an order of importance on the controller's end: if multiple values change, I can set which parameter will be updated first. It would be good if I could get rid of the "start of packet" byte, but that introduces problems related to synchronizing the controller with the boat and making sure that parameter bytes aren't interpreted as data bytes, or vice versa. This system uses one extra byte to save a lot of time and code, and it makes for a pretty bulletproof system. 

There is one fault with a system like this. Suppose the boat is moving away from the controller. In order for the boat to move, the brushless DC motor must be on. If the boat loses connection with the controller, it will finish parsing the last byte received and wait until another byte is sent. 

Hmm...wait a second. If the boat doesn't get another byte from the controller, it'll just leave the motors at their current positions until they are updated. If the boat is out of range, that will never happen, and the boat will just keep motoring along. To complicate things, the boat was going away from the controller in the first place. See the problem?

My solution is to implement a software watchdog timer (I had problems getting the hardware watchdog timer interrupt to work). When a command is received on the boat, the time in milliseconds after startup is recorded. After checking for a command (and parsing it if necessary), the boat will compare the current time in milliseconds after startup. If it is more than a second later than the time the last command was received, it'll stop the brushless DC motor to save battery life and prevent it from motoring away from the user. Unfortunately, it's not smart enough to motor back to the user-that would be nice, but I don't have the right set of sensors and components to implement that.

What's next? Replacing the brushless DC motor. After all, my lab is a no-smoking zone. Wait, does the soldering iron have to go, then? Oh, great, I tried to make a joke and it backfired on me. I'll end this project log here to save me from further humiliation.