Closed loop autopilot simulation with FlightGear - Part 2

Figured out how to close the loop!

Programs can interface with FlightGear through FlightGear's property tree. Very powerful.

If you run FlightGear with the --httpd= option, it will run a webserver on http://localhost: where you can browse the property tree and refresh the current values. Alternatively, in FlightGear you can type "/", and the property tree viewer will pop up and you can view the values changing in real time. I did this to figure out the sign convention for different properties.

The property tree can be read from and written to using a "Protocol". The protocol basically defines the format in which data is exchanged. You identify the nodes in the property tree which you want to interact with, the data types, the string formatting, and voila! Attached are the input and output .xml protocol files which I used (copy to FlightGear's data/Protocol directory).

The data can be passed through several means, serial port, tcp, udp, etc... I chose UDP for ease.

Here is how I ran FlightGear:
fgfs --httpd=5500 --generic=socket,out,40,localhost,5000,udp,output_protocol --generic=socket,in,45,localhost,5010,udp,input_protocol

I made the input data rate faster than the output data rate, because I would rather have FlightGear waiting for a new input value (when it doesn't get a new input, the last one persists) than the input being buffered.

The --generic option allows one to specify a generic protocol, which was defined in the .xml file (attached).
--generic=socket,,, ,,,.

Attached is a .c program which I wrote to interact with the property tree and provide feedback controls to FlightGear. I've implemented simple proportional control for roll and pitch to stabilize the aircraft. Timing is driven by FlightGear. The code makes a blocking call to read UDP data. It waits until it receives a new packet, processes it, and sends a packet with control inputs back to FlightGear. Then it loops again, waiting for another packet from FlightGear. Currently, everything is hardcoded (port numbers, etc ..), but it should be trivial to make it more general purpose.

This should provide a complete framework with which to write an autopilot controller in C.
Comments please!


Views: 5382

Comment by Rana on October 26, 2009 at 4:15am
nice thing !
have you tested it using ur ardupilot 2.3 ?
would love to see some videos you could record using desktop recorders of your PC in which you did it.
Comment by Faisal Shah on October 26, 2009 at 8:11am
Nope, haven't tested it yet - but I do intend to. You can try it yourself though. If you're running a windows machine, all you need are:
1) FlightGear,
Make sure you add the proper environment variables, and \bin\Win32 to your path .
2) CygWin, . Download installer from the top right. Make sure to include the developer options when installing.
3) The three files linked in my post, the two .xml files should be copied to \data\Protocol
4) Compile udpserver.c in cygwin using "gcc -g -o udpserver udpserver.c
5) Run FlightGear with the command in the post, bring the plane up to altitude, and put it in a crazy death spiral.
6. Run updserver.exe and watch the plane stabilize.
Comment by Recmaster on March 31, 2010 at 1:35am
Hi Faisal,

is it possible to load a firmware ArduIMU code to your's udpserver?
Otherwise I dont understend how it could help to make a openloop emulations.
Comment by Tiago Antunes on June 28, 2013 at 12:03pm

hi guys,

I would like know how capture the image (Screenshot) of simulator with command line --jpg-httpd=port. Somebody know help me ??

Comment by adil raja on May 30, 2016 at 11:19am

This is a nice post. However, I wonder how the values for controls written to the property tree are sent to the FDM? Or are they sent at all? Or would it be necessary to use an external FDM while sending data to the property tree?


You need to be a member of DIY Drones to add comments!

Join DIY Drones

© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service