Close
0%
0%

DIY Airboat and Controller

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

Similar projects worth following
EDIT 2: Hi! This project is very old and represents some rather...dubious engineering. Still, it's fun to look back and see where you came from.

EDIT: Wow, only just figured out that the Digi XBee gallery featured me! Check them out here: https://www.digi.com/blog/xbee/boat/For a while, I've been slowly building this boat as a long-term project of mine. It's designed with the propeller above water in order to be usable in weedy/swampy environments, as well as on snow. I also wanted to take on the challenge of designing the control electronics and radio system from scratch as opposed to buying a commercial radio transmitter/receiver pair.Note: this project has been in development for a long time before I posted it on Hackaday Projects, and I have not been logging its progress anywhere else. Thus, many early project logs and details are not logged here.

Boat design:

The airboat is developed on top of a Styrofoam base, which was created by taking a large block of scrap Styrofoam and cutting it into the correct shape. This was coated in liquid plastic to give it strength and durability, as well as helping it to hold screws. The base is wide and designed primarily for stability as opposed to speed. 

All of the electronics are mounted on a wooden board running lengthwise along the foam platform. A wooden pole is used to elevate the main motor and propeller, and a second brace was added for stability. A servo is mounted behind the propeller for steering control. 

Boat electronics:

The electronics are centered around a custom ATMega328p board created early in the project's development (before I posted this on Hackaday Projects). The microcontroller is running at 5 volts, 16 MHz. Two servo headers are populated on the board for control of the main motor and the steering servo. There is also an FTDI compatible header for both programming and radio communication. Recently, an expansion header has also been added for the possibility of adding sensors or other peripherals. It connects to the 6 analog inputs of the ATMega, which gives the benefits of digital I/O plus the functionality of an ADC. Also, the I2C lines of the ATMega happen to be on two of the analog inputs, allowing I2C communication with a "sidecar" microcontroller on an expansion board. Pull-up resistors are populated on the board for this reason.

The main motor is a 3-phase brushless DC motor, driven using a 10 amp ESC. The ESC connects using a standard servo connector and supplies power to the ATMega controller. Power comes from a 3 cell Li-Po airplane battery, modified to use a JST connector instead of the very beefy original connector. The steering servo is nothing special, just a standard size Hitec HS-311 servo with a piece of plastic to serve as a rudder. 

Radio communication is handled by an XBee Series 1 transceiver running at the standard 9600 baud rate. A SparkFun breakout is used for level shifting. 

Controller design:

The controller is built into the shell of a very old Air Hogs helicopter controller. Various plastic supports on the inside were ground down with a Dremel to make room for custom electronics. One of the original 1-axis stick holes was widened, and an analog joystick was mounted in its place. The original rubber-dome trigger PCBs were left in place. 

Originally, for the Power and Charge indicators, colored translucent plastic was affixed to the front panel to simulate the look of a through-hole LED, and a surface-mount LED lit it from the back. I took this out and widened the hole to accommodate 5 millimeter through-hole LEDs. The Charge indicator now is used for radio communication status.

The container for the helicopter charge cable was removed and left open as a window for the XBee radio module to be easily removed and replaced. It also allows users to peek around and see all the hand wired peripherals inside the case. In the past, it also allowed the user to see a status LED, but this was an awkward solution, forcing the user to tilt their head at weird angles to see the LED. There is now a 5 millimeter LED located on the front of the case, making this use obsolete.

Controller electronics:

The controller is driven off of an Arduino Pro Mini 3.3v from SparkFun. This is connected to an XBee breakout, as well as the analog stick, LEDs, and trigger buttons. Power comes from the built-in 6 AA battery pack and is passed through the Pro Mini's internal 3.3v regulator. 

Communications protocol:

**UPDATE** The new communications protocol is a bit better than my earlier one. It still sends a "start-of-packet" indicator, but then sends only 2 bytes: a parameter byte and a data byte. This allows for 256 different parameters to be sent, each having 256 possible values. 8 buttons can be consolidated into a single byte, saving even more transmission time. This protocol is faster at transmitting single parameters to the boat,...

Read more »

  • 1 × ATMega328p with custom breakout board Microprocessors, Microcontrollers, DSPs / ARM, RISC-Based Microcontrollers
  • 1 × Hitec standard-size servo HS-311
  • 1 × E-flite Park 370 brushless DC motor Upgraded from the E-flite Park 250 brushless DC motor
  • 1 × E-flite 10 amp electronic speed controller Includes a BEC (battery elimination circuit) to power the receiver
  • 1 × 3 cell Li-Po RC airplane battery Connector changed to JST

View all 11 components

  • Bug hunting and a look back

    CompuCat11/14/2014 at 02:55 0 comments

    I took the boat for a test run and discovered some stuff about the new code. It's quite reliable (as long as the XBees are within range of each other), and the lag problem has been fixed. However, there's some weird bugs, but what can you expect?

    First and foremost, when attempting to run the boat at full throttle, for no apparent reason, the boat will only move at a slow speed. If you move the joystick to just the right place, though, it will run much faster. I'm not sure if this is being exhibited by the ESC or not. It could be normal behavior, but this is unlikely-the ESC was intended for airplanes, and behavior like that could cause the plane to crash. I might be trying to output servo values that the ESC is misinterpreting. I'll have to poke around with the code and see what happens. I'm not sure if the problem's in the old code-I'll have to test that.

    The other bug is also quite weird: once lit, the debug LED will never turn off on the controller. I have no idea why this is happening, so I can't give any commentary here.

    There are some choices I regret making in this project-and some things that happened that were just plain funny.

    • At first, I ordered two breadboard-style PCBs: one for the boat, and one for the controller. I was terrible at soldering back then, and I ruined many of the traces on the board. Oops. Oh well-the ruined board was too big for the controller, anyway. The one in the boat wasn't so bad, and it's still sitting in there.
    • Originally, when I soldered up the transmitter PCB, I had added a 7805 for power regulation. Initial testing proved it to be okay, but I realized later that the 7805 had begun smoking, and the power LED was lighting even with the switch off. To top it all off, I made the fatal mistake of touching the 7805 to see just how hot it was. Not a good idea. I was a newcomer to electronics then, so that spooked me a bit, so I didn't work on the boat for a while after that. I'm still not sure why that 7805 was smoking.
    • I eventually desoldered everything from the bad board except a pullup resistor, a reset switch, and the 28-pin ATMega socket. The board didn't look so good after all the rework. Sorry about the image quality-I didn't feel like getting out my regular camera, so I cheated and used a webcam.
    • Awful soldering made worse by low resolution.
    • Also, the iron I started with wasn't that powerful and came with lead-free solder without flux...ugh. Sure, it's RoHS compliant, but it can be a pain to work with when your iron isn't powerful enough and you're just starting out.
    • I never bothered adding an external programming header to the transmitter-I could just open it up, disconnect the radio and the other headers, and program it, right? Not a good idea-it turns out, I often end up having to disconnect everything, then reconnect it all again, disconnect, reconnect, just for one iteration of code. Annoying.
    • I didn't plan out the wiring that well in the transmitter-there are three cables running between the halves (and one of them is just a single wire for the debug LED-ground runs through another cable), and there are a couple more just for the back half. Also, the power cable running to the switch and back is too short and tends to unplug itself when you lay it open to work on the inside. I would have just used one ribbon cable in hindsight, but oh well. Also, I'd probably have to use a separate pair of 22 gauge wires for power (due to the way the Arduino Pro Mini regulates power, the switch has to be connected to the 9v line in from the battery pack).
    • The Air Hogs controller is a bit cramped and hard to work with, but it's got a nice huge 9 volt battery holder in there. Nope, not a 9v battery, but 6 AAs! Heavy, but they'll last forever. Also, I got free shoulder buttons!
    • Someone I was working with on this project put some Mod Podge to try and waterproof the paint on the side of the boat (we weren't sure if it was water-soluble or not). It turns out, Mod Podge is sticky when cured, and some got on the bottom of the boat. We're careful to store it propped...
    Read more »

  • Motoring along...CRASH!

    CompuCat10/05/2014 at 20:16 0 comments

    Just a quick note-I've literally run into a wall with this project. While doing a dry land test, I fractured the plastic on the corner of the boat. (Mental note-must learn to drive better!) Since the plastic is just a coating on top of a foam base, it probably wasn't as strong as it could have been. The boat is officially grounded until repairs are made. I'm hoping I can get this fixed soon. Fingers crossed.

    PS-To all of you following or just browsing this project page, do you have any suggestions on how to redo the corner? I have the old pieces, but I'm considering just filling it over with more liquid plastic instead of supergluing the old pieces in place. Are there any other modifications or add-ons I should make? I'd love to have some additional feedback to help this project grow. Thanks!

  • Motoring along

    CompuCat09/27/2014 at 22:00 0 comments

    EDIT: Whoops, where'd the picture go? I've fixed that.

    I've finally gotten around to typing a new project log. I've got a lot to tell you, so let's get started.

    First of all, the boat took its maiden journey (admittedly, a while ago) in a small construction pond. Of course, I had to repair the loose wire on the motor. As expected, steering was a bit clunky, and there were code glitches (full motor speed sometimes causes it to stop moving entirely). Still, it was good. Except for the part where the loose wire broke. Again. Since then, the boat has been put aside...until now!

    Now for the new changes. Take a peek!

    The decals are temporary-I haven't gotten around to getting proper decal paper to make them look nice. They've been added along with the new paint job (thanks, U.S. Coast Guard boats for looking so cool!) Also, the rudder (technically, vertical stabilizer) has been beefed up for better control. Also, I've fixed one of my biggest problems: the motor!

    As you can see from the parts list, I have upgraded the motor to a more powerful model, with the added advantage of a better propeller mount and a better motor mount. Yay, no more vibrations! Also, the wires are affixed better, so I don't think I'll have to worry about magic smoke anymore. I'm using the same ESC as before, so I have to be careful not to overload this motor or I might damage the ESC. Also, I had to put bigger bullet connectors on the ESC's cable harness-they were sized for the smaller motor and wouldn't fit the larger one.

    The old motor was fixed after the maiden voyage, but I still got magic smoke out of it. Also, a guy at my local hobby shop notified me that my propeller was on backwards. That probably was affecting the speed of the motor (and thus the boat).

    So! The boat is finally ready for another test. What next? Hmmm....a Hackaday decal somewhere? Nose camera? The possibilities are endless!

    Oh, I forgot to mention. Thanks to the new motor, it's now strong enough to push itself (slowly) over carpeted flooring. Score!

  • Communications update

    CompuCat08/30/2014 at 12:22 0 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:

    • Start of packet
    • Analog joystick X
    • Analog joystick Y
    • Left digital trigger
    • Right digital trigger

    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:

    • Start of packet
    • Parameter to modify
    • New value for parameter

    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.

  • Ongoing fixes, ongoing problems

    CompuCat08/26/2014 at 02:02 0 comments

    Again, I've run into another roadblock in the course of this project.

    First of all: the communications glitch has been solved. Here's the technical lowdown.

    My code has a simple communications protocol:

    • Send a "~" to signal the start of a packet
    • Send a byte for the analog joystick's X position
    • Send a byte for the analog joystick's Y position
    • Send a byte for the status of the left digital trigger
    • Send a byte for the status of the right digital trigger

    I know, I know, the two trigger bytes can be merged for speed. I'm working on that. For now, I just want communications to work. 

    This is implemented fairly easily. The bug, however, came from poor planning. I put some simple code in the receiver to wait for data to arrive in the serial buffer before beginning to process a new packet. Once data arrives, the code checks that the first byte is a tilda ("~"). If so, then it reads four bytes, processes them, and sends the data out to the motors. If the first byte isn't a tilda, it will keep checking each incoming byte until it gets a tilda. See the problem?

    The bug came from my code waiting for data to arrive in the serial buffer. I was waiting for any amount of data, no matter how big or small. In doing so, I overlooked this fact: just because data has arrived doesn't mean the entire packet has finished transmitting. Because of this, the code was trying to process an incomplete data packet. The processing code would finish before the packet completely arrived, returning a -1 (no data) code for each "ghost" byte. Once it finished, the loop would see more data in the buffer: the rest of the broken packet. The tilda ("~") check would fail, and the loop would keep checking incoming bytes until it found the start of the next packet. There still wouldn't be a full packet in the buffer, so the cycle would continue, breaking the communications scheme.

    The fix: The buffer now waits for at least 5 bytes: a full packet. Simple, huh?

    Before this code update, I also had a newline byte sent to mark the end of a packet. With the XBee's onboard redundancy and the tilda already there, I found this to be a waste of time, so I removed it. Instant speed boost!

    However, with every fix comes another gotcha. In this case, it was a hardware problem. When testing the new code, I found that the brushless motor wouldn't turn. Instead, it jittered in place. 

    Quick side note on how brushless motors of the type I use are driven:

    The motor has three sets of electromagnetic coils that turn the shaft. They must be energized in the right order in order for the motor to turn. This is handled by a brushless ESC (electronic speed controller). This is driven in the exact same way as a servo motor, but 0 degrees (on a normal servo) corresponds to "off", and 180 degrees corresponds to "full throttle". Since this ESC has a built in BEC (battery elimination circuit), it also connects to the Li-Po battery and regulates +5 volts to power the receiver.

    I believe that the motor's coils were being energized in the wrong order, causing the jittering back and forth. When I tried to diagnose it, I first tested my receiver (the most custom thing in the system) with the basic Arduino "sweep" test program. It produced the same symptoms and a problem: at full power, the motor began to smoke. I'm not sure why this happened, but it seems to have partially broken the motor. The startup beeps (generated by the ESC and produced by the motor vibrating) are very quiet, when they should be quite loud. I'm not sure where the original fault came from: the ESC improperly driving the motor, or the motor itself. The funny thing is, it was working fine when I had to use the setup for a completely separate demonstration. The only difference was the receiver/controller: I was driving it off of an Arduino UNO. That shouldn't affect the setup, though. Right?

    So, as of now, I'm stuck. I think the next step will be to see if the ESC or the motor needs to be replaced, and if so, which one (or both). I'm curious to know why...

    Read more »

  • Boat assembly, part 1

    CompuCat08/14/2014 at 22:22 0 comments

    I've begun to assemble the boat from individual parts into a whole unit.

    Note: Apologies in advance for the grainy photos-I was taking these at night, and the lighting is horrible where I was assembling it.

    This is the boat base, originally cut from foam and coated in plastic. It's quite stable, and I'm planning to add a fin on the bottom for turning stability. These two parts are the frame that will contain the electronics and motors. They've been varnished with a marine varnish, so they're water-resistant to some degree. They won't survive being dunked underwater and soaked, but the occasional splash won't hurt them.

    After assembling those two parts, I mounted the main motor and propeller. This went fairly easily, except for the fact that the varnish leaked into my screw holes and filled them. Luckily, the varnish is relatively weak, so I was able to screw through it and fix the motor in place.

    The propeller, surprisingly, is not screwed in place. Instead, it slips (loosely) onto the motor shaft, followed by an adapter ring and the end cap. The adapter ring adapts the wide opening of the propeller to a smaller opening able to be clamped onto by the end cap. The end cap has threads that screw onto the main motor shaft, squeezing the propeller into place.

    What's left? I have to mount the electronics and the servo motor onto the boat, and the wood structure needs to be mounted to the base. Stay tuned for future updates!

  • The current state of (mis)communications

    CompuCat08/11/2014 at 03:58 0 comments

    As of now, this project has bumped into a minor problem: the radio transmission system has stopped working. Data is being transmitted via the XBee modules, but the ATMegas are not understanding each other. I will have to look into the code (which I will post soon) and check if the transmitter and receiver code both implement the protocol correctly. While I am at it, I should redo the protocol: it's quite bloated and has lag issues. The XBees are sending and receiving; I have verified this using an XBee Explorer from SparkFun.

    While this is being fixed, I still have to work on the boat final assembly. The foam base is ready to be affixed to the electronics platform: a wooden board running lengthwise across the foam. This will be assembled using a "glue and screw" technique for the best adhesion possible. I'm using some small plastic food containers from the dollar store to hold the electronics and keep them dry. This is especially important for the Li-Po battery. Two separate containers are used: one for the battery, and one for the receiver. The battery is relatively heavy, and this must be placed in the center of the boat to prevent tipping. I also have to find room for the receiver container alongside that (though it is light, placing it on the side would still tip the boat a bit and potentially steer the boat in one direction), and space is tight underneath the brace for the propeller-pole. 

    After this is finished, I will be able to finally test it and start adding cool features (expansion port for sensors?).

View all 7 project logs

Enjoy this project?

Share

Discussions

silvio biasiol wrote 04/14/2016 at 20:58 point

Very cool project! I'm building my first boat :) https://hackaday.io/project/10652-green-powered-sailboat hope you like it! 

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates