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.
Comments
Good night. Could you provide the code of labview?
(I wrote the receive code like the labview example, but not the sender)
Philippe
What are your plans for the scilab - flightgear interface? I assume since both tools are "free", that your tool will be made available as well (once this delay is resolved)
- Roy
for X-Plane 9, from here.
https://www.youtube.com/watch?v=aTlJF7A1kJc
Tom Y, can you tell if the delay is in the SciLab or Flightgear side? And are you using a TCP or UDP link?