I should have prefaced this series of blog entries with the following:
My ideas for this design center around the need for a stable aircraft, either via its own inherent stability and/or provided by an on-board IMU or AHRS. In my case I'm relying on an ArduIMU for stabilization. Once I get the time I'd like to study further the possibility of using one 3 axis accelerometer for short-term pitch and roll stabilization for inherently stable airframes. I'm flying foam aircraft, up to 24 oz in weight and really low wing loadings so this design concept is not a one-size-fits all out-of-box. Right now my airborne code is very simple. The ArduIMU takes over as soon as all channel changes stop. So it is a crude fly-by-wire setup. The ArduIMU roll also limits the roll of aircraft to 60 degrees even under manual control.
I haven't gotten into the PID, turn-rates, navigation, and other heavy computing and will definitely be studying the ArduPilot code for guidance.
I want to give a big 'thank you' to all those responsible for developing and sharing ArduPilot, especially Chris and Jordi, you are an inspiration to us all.
I'm using a baud rate of 38400 for all serial ports; xbee's, Arduino to Palm, ArduIMU to Arduino Mega etc. I found that the higher baud rates increased latency on xbee's but didn't troubleshoot further to really explain the issue. With the packet size and baud rate as they are, the largest packet still allow a long enough time between packets for easy decoding and processing before the next packet arrives, at either end. On the GCS side I'm simply passing every byte as it arrives to the Palm. The Arduino manages the thumb sticks processing, I don't do any control yet using the Palm. I have a landing screen with a simple ILS indicator but have yet to perfect the GPS processing to make it work.
My ultimate goal with this project is a fully autonomous vehicle, able to launch, fly, and land under its own control. So I'm working it up in stages, manual control, fly-by-wire, autonomous flight, autonomous landing, etc...
I'll start posting some code, schematics and documentation as I get it organized but none of it is out of the ordinary for here. Hopefully the following will answer any questions:
Important hardware bits:
To interface with a Palm you'll need a level shifter to get the Palm side to read standard RS-232 signals, 5V won't work. I use one of these and it works well.
The thumb sticks are not very good compared to RC sticks. The range of motion on them is really small. To get reasonable controlability out of them I use exponential throw for them and this works well. The push-button feature of them is however nice. I'll eventually use it on both sticks to change flight modes and other functions. If I ever move this design into a real enclosure I'll probably switch to RC sticks.
So far everything I'm using is common off-the-shelf stuff with the exception of the airborne ArduPilot Mega Beta, I thought it a good recycling project for it, but a regular Arduino Mega will do, or as an alternative , use a Arduino Pro Mini with serial port used for Xbee and I2C for IMU (if you use it).
I use a UBEC on the airborne side for the servo's and a separate one for all the electronics. Ground testing showed voltage drops from heavy servo use so I want to make sure the electronics have thier own clean power. I fly heli's and voltage drops are typical when running servos off the ESC's BEC, so all my heli's have servo UBECs.
The thumb sticks and enclosure layout is very comfortable as-is. I power the GCS off a 750mah 3S and get over an 2 hours of use out of it.
Edit: I forgot to mention the throttle control using the thumb stick: You can open up the stick and remove the spring, but I managed to wreck 2 trying this. After removing the spring, you need to reassemble it and to do so means bending the little metal tabs back over the plastic, press to hard and you can crush the whole thing so be careful if you try this.
Important software bits:
So far I've avoided using any timer or interrupts to keep the code simple for the Arduino side of things.
Servo control: I originally used 2 bytes for the channel data in order to get the microsecond resolution on the servo's but after comparing that to single digit degree resolution I couldn't tell the difference so dropped to 1 byte channel positions. Micro second resolution would be needed for a quad rotor.
Palm: The Palm software I'm using (Handheld Basic HH++) is free for non-commercial use. It runs on most any Palm going back to version 3.5. I've got a box full of Vx's I bought of ebay for $15 and a couple m500. The m500 is better since it has a SD Card slot for data logging. I just got a spare serial cable for mine and have yet to modify it for the GCS. The Palm processor in these older models can handle the graphics needs for simple UAV displays, and at the baud rate I'm using easily keeps up with the data refresh rate. The rate I get allows me to fly looking at the display if needed. Since the display on the palm is limited, I use a small area in the lower left corner as a simple 'master caution' panel. When ever an alert occurs (low fuel, signal loss, etc) a click-able message is displayed along with a unique frequency beep. The alerts are prioritized and the message remains until it is cleared. Any lower priority messages will then display for clearing. There are only 5 or so alerts so the sound alone tells me whats up without having to look down.
The XBee is a Pro, 900Mhz, and it I found it isn't the baud rate that is most important like some have suggested. At first I attempted to use the Xbee like a RC TX/RX sending channel updates at 50HZ and the result was 'latency'. This was caused by the buffers of the XBees filling faster then they were emptied, so what I was seeing was data up to a half a second old.
What does work is to send the least amount of data needed at a rate the Xbee can both process the incoming stream and output the stream. My latest version only sends channel changes to the airborne XBee and the airborne xbee sends channel positions at 20hz. Even when moving the sticks rapidly, the channel changes move the servos good resolution and no latency. The channel positions and expected positions are compare in the GCS and differences result in the GCS resending a servo position. So far I haven't recorded a single instance where the resend was needed.
To keep the xbee workload down (and latency to a minimum) all data is transmitted in binary. The largest packet of data that is sent from the airborne xbee is only 26 bytes big. Since the xbee's PAN ID handle the interference I only have a short preamble (!!!), a one byte Unit ID (for multiple airborne units), and a one byte packet id. The airborne xbee sends 2 types of packets, fast changing data (channel+attitude ) at 20hz, and slow changing data (way point changes+battery voltage+GPS Fix type+GPS Satelites) . This simple protocol seems to work and pose minimal overhead to the Palm and Arduino's. The Palm development software is nice in that the serial stream reader is type specific so once a preamble is detected, reading the packet data into variable is as easy as:
I've been toying with this design for a few weeks and thought I'd post it. I'm using a Palm Vx, Arduino Mega, and XBee Pro for a ground control station. It's pretty rough at the moment. The airborne portion is made up of a ArduPilot Mega beta and a XBee pro. After building a airborne system using a Turborix Satelite receiver and Arduino I decided to eliminate the 'RC' equipment from the design completely. It was surprisingly easy and the range of the XBee Pro is better than my RC equipment. Here is the ground station with a simulated signal running to it:
It is really minimal, and designed to be easily read while flying. The scroll bars are F-Fuel, C-Climb Rate, S-Air Speed, and R-Airborne Receiver Signal Strength. I tried a fully graphic horizon but couldn't see it well so switch to a simple roll and pitch indicator. The pitch indicate shows +-60 degrees, higher angles have the pitch line pegged at max. This allows me to fly looking at the Palm. The scroll bars are set to the typical range expected for the flight. I'm using an ArduIMU for stabilization and am working towards a complete fly-by-wire software before going to full auto-pilot.
Here some pictures, don't laugh :), it is a rough 'sketch'. If I ever find the time I'll move it into a nice enclosure but its tupperware for now:
I flew my ArduPilot V1 in a 33inch wingspan redi-board foam plane on numerous occasions with great success early last year. RTL and way point mode worked great after lowering the gains for the small light craft. Of course it only flies well on calm days since it had no stabilization. I retired it a few months ago and am building a pusher this time, 50-60 inch KFM3 wing, the fuse and tail modeled after the Raven UAV. If it flies I'll post picks :), the wing is built, and the fuse will be ready by tomorrow for some manual flight tests. I've had my ArduPilot V2 sitting on my workbench for far too long, I fly near some hills and frequently in a canyon and wanted to wait for an IMU version.
While I waited for my ArduIMU and Mega, I broke out a 3 axis accelerometer and Arduino Pro I got from SparkFun some time ago. As an exercise in getting to know Ardiuno better I spliced together Kalman code from Jordi and accelerometer code from Ruben Laguna to make a simple tilt gyro, the video shows the results, accurate to +-45 degrees I think, not bad for a few hours work, can't say I understand the Kalman filter any better than I did 6 months ago :)..
I really like that the Mega has additional serial ports, this makes coding for the GPS or IMU, a bi-directional ground station, and other serial devices possible. I got my Mega and ArduIMU the other day and am looking forward to much fun. I wanted to try the 2.5 code with ArduIMU support but the code only includes uBlox parsing and I've got a EM-406 GPS. Anyone know where I can get a uBlox?