Marc Daniels's Posts (6)
Sort by
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.
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.
Gotta get to work....
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:
ss.read aMode
ss.read aRoll
ss.read aPitch
ss.read aThrottle
ss.read aLatitude
ss.read aLongitude
ss.read aAltitude
ss.read aRollAttitude
ss.read aPitchAttitude
ss.read aGroundSpeed
ss.read aAirSpeed
ss.read aCourse
ss.read aClimbRate
ss.read aRSSI
ss.read aFuel
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:
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?
