MicroGear hardware in the loop demonstration with FlightGear

I'm almost embarrassed to post this video. It was done almost entirely with open-source software, so it's obviously way behind what people are doing with commercial software and commercial systems. But I have fun and entertain myself with this stuff, so I thought I'd share a brief snippet.


What you are seeing is FlightGear (http://www.flightgear.org). I have a FlightGear model of a Sig Rascal 110 (which I've flown in real life many times.) The 3d model and the flight dynamics model are also open-source so of course are also subpar from anything that would be done commercially. The FlightGear flight dynamics engine is outputting gyro, accelerometer, and gps data to an external embedded computer running MicoGear. MicroGear takes the "sensor" data, runs it through a 15 state kalman filter (the one piece here that isn't open-source) and estimates roll, pitch, yaw, and location.

Because this is FlightGear I already know the true pitch, roll, and yaw, but I promise I'm not cheating here. The kalman filter on the embedded board is estimating these values and using them as input to the autopilot and routing algorithms also running on the embedded board. The only difference between this and real life from the microgear/embedded-processor point of view is that it's not getting it's data from the onboard sensors and it's not driving servos directly. Instead it sends the servo commands back to FlightGear and the control surfaces are moved over there in the simulator.

This turns out to be a really nice hardware in the loop testing platform and many subtle issues that show up in real life, also show up in the simulator. Because this is FlightGear, a person can throw a variety of weather conditions at the system, turbulence, high winds, etc. You can disable fuel consumption and run for hours or days if you like.

I am very tempted to turn in a "virtual" entry into one of the upcoming DIY drones contests. :-) Oops, I almost started to crack a smile there. Ok, I'm back to my long, sullen, down trodden facial expression, because after all this is all pretty much all open-source software -- which just sucks -- total crap I know -- sorry to even waste your time and bandwidth with any of this guys. I won't post anything ever again until I have something actually useful or interesting to show.


Views: 2524

Comment by Curt Olson on December 2, 2009 at 5:37pm
Jokes are never funny if you have to explain them (well and most of mine aren't that funny anyway ... my wife's most repeated words are "yes, yes I get it, yes ... no, I'm still not laughing."

I am one of the founding authors of the FlightGear project and it's been my baby since about 1996. I'm not a literary genius, but I was hoping that if I layered it on extra thick, folks would understand I'm clearly being a bit sarcastic. There's probably a better word for it than sarcasm. Anyway, I'll shut up now.
Comment by Mike Bakula on December 2, 2009 at 8:23pm
Sweet! Can you talk a little bit about how you're getting data into/out of FlightGear?
Comment by Curt Olson on December 2, 2009 at 8:39pm
Sure. I'm using the "generic" protocol (not an inspired name but oh well.) The way this works is you create an "xml" file that defines the data fields that are sent out (or read in.) In addition you can provide offsets and scaling factors (i.e. to do feet to meters conversion, degrees to radians, etc. if the other end is expecting different units) The FlightGear "generic" protocol offers binary variants (appropriate for UDP socket communication or maybe serial communication) and ascii variants (appropriate if you want to dump a tab delimited file.)

Once you create the xml file that defines the fields and format of the output (or input) data, then there is a funky command line option you use to invoke it. It gets a bit complicated to work through the first time, but essentially you can define the direction (in or out), the data rate (for example, I've chose to output imu data at 50hz and gps data at 4hz.) In addition you can decide if you want to send the data to a file, a serial port, or a network socket (udp or tcp). So there are lots of options to match just about any need. Maybe almost as many options as "wget". :-)

So in this case I've defined 3 protocol files: an IMU protocol, a GPS protocol, and then an actuator protocol which the remote end sends back to FlightGear and that defines the control surface deflection rather than the keyboard, joystick, mouse.

I've run my microgear code on a remote embedded computer (and that's what you see in the video), but you can also just as easily run the microgear code on the same pc which is nice if you want to throw together a little demo on a laptop and not have to drag along a bunch of extra hardware and cables.

I was just thinking it wouldn't be that hard to emulate some simple thermopiles (probably idealized, but you could dirty up the signal if you wanted) so this same basic approach could be used to test simpler autopilots as well.
Comment by Michael Zaffuto on December 2, 2009 at 11:01pm
Hi Curt,

Is there an EasyStar model available for FlightGear? And if not.....
What is involved with adapting, extracting, a 'model file set' from another simulator that is compatible with a Flightgear?

I noticed that Flying Model Simulator, http://www.flying-model-simulator.com/ , uses zip files of model airplanes that represent their shape, sound and numerical data of flight simulation revelance. I found downloads for the simulator, http://www.mpx-easystar.de/uploads/media/fms2alpha85.exe as well as http://www.mpx-easystar.de/uploads/media/fmsdiskme.exe . Interestlingly enough for lots of people on this site, they have EasyStar models for the simulators as well, original: http://www.mpx-easystar.de/uploads/media/easystar.zip and w/ailerons http://www.mpx-easystar.de/uploads/media/easystar_ailerons.zip and one file compatible with another simulator IPACS Aerofly http://www.mpx-easystar.de/uploads/media/as_easystar.zip .
Comment by Faisal Shah on December 2, 2009 at 11:46pm
Thanks Curt for this wonderful tool. For those of you who are curious on how to get data in and out of flightgear, I wrote a blog post which details it here: http://www.diydrones.com/profiles/blogs/closed-loop-autopilot-1 . Included is also a C program (which you can run under CygWin) which interfaces with FlightGear, and you can replace the code in it with your own autopilot code. As an example, it has a simple PID controller which adjusts the pitch and roll angles to a fixed value. See the post for more info and file attachments.
Comment by Kevin Hashawan on December 3, 2009 at 12:18am
I've been doing this for a while, and have a couple of issues that you might be able to clarify.

Firstly, is there some way to get a decent resolution timer out of flightgear for calculating time deltas, or even the delta directly. Secondly, flightgear seems to have some strange issues when I'm sending data to it at rates faster than 50hz, it never drops data but it seems to be buffering it with a long delay before the results are onscreen, upwards of 10 seconds, this doesnt occur if Ionly send data at a rate such as 10 or 20hz (generic, tcp. I should really try udp...)
Comment by Curt Olson on December 3, 2009 at 5:42am
Michael: I'm not familiar with the specifics of "Flying Model Simulator". FlightGear is built around OSG, so if you can get the 3d model into a format supported by OSG, then FlightGear should be able to load it. (AC3d, 3ds, flt, etc. etc.) The flight dynamics will be the larger challenge I think.
Comment by Curt Olson on December 3, 2009 at 5:46am
Hi Kevin:

decent resolution timer: yes, but could you explain further what you are trying to do and what's not working like you would expect?

input buffering: I think there was a "bug" in version 1.9.1 and previous where the input handler of the "generic" protocol would just take the first message off the message queue and use that. If the remote end was sending messages faster than the FlightGear frame rate, the buffer would build up and FlightGear would begin to lag. In our development version, we've changed this behavior to flush the input queue and just process the most current packet, that way if FlightGear does get delayed for some reason (loading a big 3d model for instance) it will catch right back up.
Comment by Curt Olson on December 3, 2009 at 5:51am
Faisal: thanks for reminding me about your blog post. It looks like you've used the same basic communication mechanism I used here. And the development version of FlightGear does fix the input buffering problem so you can choose any input rate you like.

Comment by Mark Colwell on December 3, 2009 at 7:28am
Curt, great sim, now to get it going for testing ArduPilot & IMUs without crashing... hardware takes too long to repair... parts cost too much ....


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

Join DIY Drones


Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service