Well I'm back in the basement tinkering after a brief hiatus. After a couple in-air resets of the Ardupilot, I decided that I really wanted to do some simulation before commiting anything into the air again. I think the resets (and crashes) were caused by running out of RAM on the Arduino, but at least now I can give code changes a thorough shakedown before flight.

My workplace does avionics integration for real aircraft, and in most of our labs we use X-Plane and Labview to do simulation testing of aircraft avionics systems. We already have a set of VI's developed that handle all of the UDP communication between Labview and X-Plane.

I borrowed these VIs from work and wrote an interface to take the flight variables and pass them to and from the ArduPilot. I finally got everything working and my ArduPilot spent yesterday evening flying the X-Plane Cessna 172 around Ottawa.

One neat feature (I think) is how I'm getting the servo commands back into X-Plane. I built a 2-servo pitch/roll tray. On the tray I mounted my ArduIMU. The Ardupilot drives the two servos which causes the tray to pitch/roll. The ArduIMU senses this motion and sends its Euler angles back to the Labview computer. The labview computer decodes the ArduIMU pitch and Roll and sends these values over to X-Plane as Joystick positions. A couple of advantages of this method over simply outputting servo commands from the Ardupilot Serial port are:

- I'm testing the whole system (including the PWM signal code and the mux chip).
- I can fly the X-Plane aircraft in manual mode using my transmitter (more realistic, and makes a good way of positioning the aircraft for testing.)
- It's cool to see this little robot arm shift around while the aircraft flies along the flight plan.

I'll post a little video clip of the system in action later tonight.

Here are the details of my closed-loop path.

1. The computer running X-plane sends the aircraft position data (lat/long/alt/pitch/roll/heading) over the LAN to the Labview PC.
2. The Labview PC takes the X-Plane data, formats per the ArduIMU binary message protocol and sends it out the Serial port to the ArduPilot.
3. Ardupilot is set to GPS Protocol 3 (IMU) and listens to the serial data from labview thinking it's from an ArduIMU and does it's autopilot work.
4. The Channel 1 and 2 servo output from ArduPilot is connected to the little tilt table I built.
5. On the tilt table, the ArduIMU outputs Euler Angle Data (Pitch/Roll). I'm using a Sparkfun XBee USB explorer (without the XBEE) to translate the serial output from the ArduIMU back into USB format.
6. Labview reads the Pitch/Roll Data in, formats this data as a joystick position, and sends it to X-Plane.
7. Go back to step 1.

As you can see in the pictures, I am also powering the ArduPilot and ArduIMU from the computer's USB ports. This seems to work well, and I don't have to keep an eye on the voltage of a lipo pack during testing.

I can share the labview VI's I personally created for this little project. (Basically they create the simulated ArduIMU output, and read the ArduPilot and ArduIMU telemetry), however, the VIs that do the communication with X-Plane, while not complicated are not something I can give away (I like my job too much ;) )

The picture at the top of this post is the Local Map screenshot from X-Plane after completing a flightplan consisting of 15 waypoints.

Below are a couple pictures of my setup.

I had a couple of very brief flights with my slightly modified ArduPilot 2.6 code this evening.

I only had the chance to do a couple of passes in fly by wire mode, but the initial results are promising.

Still some gain tuning to do, but this isn't bad for a first attempt.

In the plot below:

Blue line is bank angle

Red line is pitch

Green is heading.

Blue DOTS indicate times when the Ardupilot was in Fly By Wire mode.

As you can see I'm getting oscillations of ~5 degrees around zero. Time for some gain tuning.

More importantly, I do think I am having range issues with the Ardupilot. The antenna down range test before the flight was not quite as good as I'm used to, however I decided it was safe to try. During the flight I did have a few glitches while in Manual mode, so I'd like to improve my range test results to try to clear those up.

Time to clean up my wiring a little. As you can see it's a bit of a rats nest right now.

Tom

In case it is useful to anyone, here is my code for controlling the 4th channel through the Ardupilot board.

The main thing that stumped me for a while is you need to change timer2 from CTC mode to Normal mode. The default Ardupilot code has Timer 2 in CTC mode which resets the counter every time the throttle compare interrupt is captured. To drive two channels you need to be in Normal mode allowing the timer to go all the way to 255 before resetting.

Channels 3 and 4 to have noticable more granularity than the first two channels (as expected), but within this granularity, the movement is nice and reliable. In the linked video, you can see that when being controlled by the ardupilot the rudder motion is slightly more jerky.

I also added an extra flight mode to my code called SERVO_TEST. When in servo_test, the main loop skips any sort of navigation or stabilization, and simply passes the radio inputs through to the servos. I did this so I could get a feel for how well my servo code was working.

I hadn't seen any code on the site for channel 4 actually integrating into an Ardupilot software load, so I thought I would post mine..

My pin assignments are as follows:
pinMode(2,INPUT); //- Aileron in
pinMode(3,INPUT); //- Elevator in
pinMode(8,OUTPUT); //- Throttle out
pinMode(9,OUTPUT); //- Elevator out
pinMode(10,OUTPUT); //- Aileron out
pinMode(11,OUTPUT); //- Rudder out
pinMode(12,INPUT); //- Rudder in
pinMode(13,INPUT); //- throttle in

(Note that I'm using RADIO_TYPE 0, so I have no code in the RADIO_TYPE 1 sections).

radio.pde

servos.pde

SERVOTEST.pde

Below is a video from my shop of the rudder motion, both in MANUAL mode (straight from the radio) and in SERVO_TEST mode (radio read by the ArduPilot and Passed through untouched).

I think I've debugged one of the issues I was having with my OpenLog connecting to Ardupilot. This will probably be blatantly obvious to you veteran Arduino Programmers, but it got me, so I figured I'd post in case it helps anyone else.

After a few flights with only the open log and the ArduIMU, I decided to integrate the ArduPilot board and move the logger to the Ardupilot board. My ArduIMU was now talking to the ArduPilot, and I hacked up the ArduPilot code to remove the autopilot/radio functionality and simply combine the ArduIMU input with barometric pressure, and spit out the aircraft parameters as fast as possible.

While stripping down the ArduPilot code for my purposes, I made a whole bunch of changes at once (Mistake #1).

Once everything was back together, I found that I was only getting a log created about half the time. Sometimes there would mysteriously be no log file created. Other times, I would have a small file filled with a bunch of null characters. While debugging I would connect the OpenLog to my FTDI cable and find that it was now operating at 9600baud rather than the desired 57600baud.

The reset to 9600 was the clue. The OpenLog has an emergency reset function. If you get the OpenLogger stuck in an unknown baud rate, you can power it up with the RX line grounded. When this is detected, the OpenLogger goes back to 9600baud on the next power cycle.

So here's my current theory.

One of the changes I made to the ArduPilot code was to add a delay at startup. The reason I added this delay was because of the instructions in the OpenLog datasheet. The OpenLog instructions state: "Turn on OpenLog, wait ~2 seconds and start throwing text at it!" So I added a delay(3000); statement to the void setup() function.

It took a few days of working backwards to figure out what was causing the OpenLog problems. Then I stumbled on this page in the Arduino Reference library:

http://www.arduino.cc/en/Tutorial/DigitalPins

Thats when I realized that I had placed the delay() function before the Serial.Begin() functions in setup().(Mistake #2) I think this meant that during the 3 second delay, the serial pins were in their default input/high impedance state, giving a somewhat random response from the serial logger at the other end.

I moved the delay() line to the end of the setup() function (after the all the initialization is done) and I did 10 powercycles in a row. Each one resulted in log being correctly written to the microSD card.

Tom

Had a few more flights with the ArduIMU yesterday.

I should mention, that with regards to RC flying, my main interest is competing in IMAC (Scale Aerobatics). Basically it's flying giant scale aircraft through predefined aerobatic patterns for judges. Last year I competed in intermediate (3rd of 5 difficulty levels) and this year I'll be moving up to Advanced (4th of 5 levels).

Arising from this interest, my long term goal would be to get an autopilot doing aerobatics.

Anyways, yesterday was the first flight of the spring with my contest aircraft, shown here.

After the first flight, to confirm that everything was still working, I couldn't help but put the ArduIMU/GPS on board for some data collection.

What I really wanted to know was if typical IMAC aerobatic manuevers could be detected by the sensors used on the IMU. If the sensors railed as soon as I departed level flight, then we might have to rethink things a little. On the second flight with the IMU on board, I put the plane through the Intermediate contest sequence from last year. By flying a known sequence it makes it easy to figure out what the aircraft was doing at each point of the flight, and to determine if the sensor data is appropriate.

The initial data analysis is favourable. I am using the ArduIMU code associated with the recent Ardupilot 2.5.1 work with a few tweaks to work with my equipment. I also added the gyro rate information to the ASCII data stream to give me a better idea of what's going on inside the ArduIMU.

Here are a couple of snapshots from the data:

The starting of the engine is clearly visible in the Roll Rate data. The engine is hand propped. A few flips with choke on to get it primed, and then a few flips with choke off and she's running:

You can see that the engine introduces alot of vibration noise into the rate gyros. I'm not too worried at this point because:
- I had the system hard mounted without much padding.
- I will be installing this in my smaller electric aircraft to start.

If I ever get cocky enough to Ardupilot a gas plane, I might have to add some filtering to the rate gyros to damp out this vibration.

The last maneuver in the sequence is a rolling circle. Basically, you need to fly a circle, while rolling the plane. You need to do 4 rolls in total, so after each 90 degree heading change the aircraft should have completed one more full roll. In my opinion, it's by far the most difficult maneuver they force us to do. Anyways, the data shows just how bad my "roller" is:

There's more stuff in there, but the fact that I can make sense of the outputs gives me hope that I can teach the Ardupilot to do the same :)

Thoughts, and To Do List:
1. GPS signal seems to go wonky as the aircraft rolls inverted (even for short periods). Still haven't decided if this is an issue, since during aerobatics, the attitude and attitude rate is more important than the lat/long. The key will be to make sure that the Attitude and Rate numbers aren't peturbed by momentary GPS jumps.

2. Definitely want to integrate the static airpressure system into the data record (I'm not sure I trust the GPS altitude numbers)

3. Add accelerometer data to the output stream. It would be intesting to see if I can track the gravity vector as I do a slow roll across the field.

4. Right now the data log is time stamped with the GPS Time of Week (TOW) value. Since the ArduIMU is spitting out sensor data faster than my GPS is updating the TOW, I'm ending up with multiple datapoints with the same time value. I think I will switch the timestamp source from TOW to "timeNow" (Arduino milliseconds since boot) to try to prevent this.

That's all for today. More to come.

Tom

It was my first flight with an Ardu-anything today. Working towards getting an ArduIMU/ArduPilot working.

So far it was just a data logging flight. I had a GPS and ArduIMU installed in my Stevens Aero Edge 540 along with an OpenLog from Sparkfun.

After downloading the data into MATLAB, and some manipulation, I outputted a Google Earth KMZ file of the flight:

You can view an animation of the flight in Google Earth here:

Google Earth KMZ file

The plan is to eventually tune ArduPilot/IMU into this aircraft (using the great start that has been going on with 2.5.1 code here).

Tom