Posted by Curt Olson on December 2, 2009 at 1:30pm
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.
https://www.youtube.com/watch?v=yIDQq93cpcoWhat 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.Curt.
The new documentation is clearer than the previous model (2005-2009).
With GPS coordinates (WSG-84), you can obtain the values of the magnetic field at this point. After this you only have to rotate it according to the attitude angles FROM the simulator (not from your estimator ofc :P), add some noise and that's it.
FlightGear does not actually have a magnetometer model at the moment either. It's on my todo list if someone else doesn't beat me to it first. If we did add something, it would very likely be based on the world magnetic model too.
We have a flightgear developer working on a flight dynamics model for the easystar glider so we'll have that and a Sig Rascal that are well modeled in FlightGear.
I have some questions since I'm using X-Plane instead FG.
X-Plane doesn't have means to measure magnetometers. Actually I have to emul this measures from a world magnetic model.
Does FG have it? (magnetometers in mG or something like this).
How it is the FG community/support for RC vehicles? X-Plane is nice if you have to make one, but there are a few models in the web to download, test etc
Hi Sean, depending on your bandwidth available, you could send the flightgear truth data to your hardware along with the raw sensor values. Then when you log your ahrs data, you can log the truth values simultaneously.
You can send arbitrary data to FlightGear as well and then log that, so yes, you could send your ahrs data back to flightgear, stuff that in a corner some where (pick your own property names) and then do the logging of the truth plus your data from the FlightGear side.
With the flightgear command line option you use to read in the serial data, try specifying an update rate that is 2x what you are actually sending. If you are sending 5hz data, try sending the data at 10hz. It's possible that the data is getting buffered and that FlightGear isn't clearing it fast enough. If that is the issue, then this will be good evidence, and also it should serve as a pretty good work around.
I'm taking the raw FDM values out of JSBSim (YASim doesn't compute the total acceleration values in the body frame). I haven't done any work to model sensor errors and noise, but I think a very simple model that discretizes the value and adds an appropriate amount of random jitter would probably probably get you a long ways down the road to something pretty realistic.
Curt: No problem. I noticed there wasn't any code posted, so I referenced my post in which there is some bare-bones .C code which someone could use to go down this path :) . I must say, the tree structure thru which various simulation parameters are available is very nice, and powerful.
Kevin, Curt: Regarding input buffering, the development version may well have fixed this problem. However, what I did to get around it was to set FlightGear to a higher input frequency than my code would output. For example, set FlightGear to read input at 60Hz, while the external module would send data to it at 50Hz. So, 10 times every second FlightGear would be waiting for data and not getting any - but that is okay since it just persists with the older inputs. This way, there is no buffering.
Curt: How are you generating gyro, accel, and gps measurements (specifically gyro) ? Are you using the "ground truth" values computed in the FDM, or are you adding your noise+drift to the values and then feeding it to your attitude estimator (Kalman Filter) ? If you are simulating noise+drift, could you post your model? Thanks.
Mark: for testing IMU algorithms, you might even want to capture a FlightGear flight profile to a file. You could log the true attitude and location, then also log the simulated sensor data (gyros, accelerometers, gps). You would have to setup your code so you can read the data from a file "offline" so to speak, but then you could do some quick batch processing, plot the results against the truth, and you'd have a pretty good tool to see how well your filter is doing and if changes or tweaks help or hurt. Everyone talks about their filter converging, but there's nothing like plotting the filter estimates against cold hard truth to get a small dose of reality. :-)
You need to ask Jordi to add an ethernet connection to the ardupilot, then you can talk to FlightGear directly (and quickly) and it opens up many many possibilities.
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.
Comments
Download the WMM from:
http://www.diydrones.com/profiles/blogs/microgear-hardware-in-the-l...
The new documentation is clearer than the previous model (2005-2009).
With GPS coordinates (WSG-84), you can obtain the values of the magnetic field at this point. After this you only have to rotate it according to the attitude angles FROM the simulator (not from your estimator ofc :P), add some noise and that's it.
FlightGear does not actually have a magnetometer model at the moment either. It's on my todo list if someone else doesn't beat me to it first. If we did add something, it would very likely be based on the world magnetic model too.
We have a flightgear developer working on a flight dynamics model for the easystar glider so we'll have that and a Sig Rascal that are well modeled in FlightGear.
Regards,
Curt.
I have some questions since I'm using X-Plane instead FG.
X-Plane doesn't have means to measure magnetometers. Actually I have to emul this measures from a world magnetic model.
Does FG have it? (magnetometers in mG or something like this).
How it is the FG community/support for RC vehicles? X-Plane is nice if you have to make one, but there are a few models in the web to download, test etc
Thank you so much!
You can send arbitrary data to FlightGear as well and then log that, so yes, you could send your ahrs data back to flightgear, stuff that in a corner some where (pick your own property names) and then do the logging of the truth plus your data from the FlightGear side.
Curt.
With the flightgear command line option you use to read in the serial data, try specifying an update rate that is 2x what you are actually sending. If you are sending 5hz data, try sending the data at 10hz. It's possible that the data is getting buffered and that FlightGear isn't clearing it fast enough. If that is the issue, then this will be good evidence, and also it should serve as a pretty good work around.
I'm taking the raw FDM values out of JSBSim (YASim doesn't compute the total acceleration values in the body frame). I haven't done any work to model sensor errors and noise, but I think a very simple model that discretizes the value and adds an appropriate amount of random jitter would probably probably get you a long ways down the road to something pretty realistic.
Kevin, Curt: Regarding input buffering, the development version may well have fixed this problem. However, what I did to get around it was to set FlightGear to a higher input frequency than my code would output. For example, set FlightGear to read input at 60Hz, while the external module would send data to it at 50Hz. So, 10 times every second FlightGear would be waiting for data and not getting any - but that is okay since it just persists with the older inputs. This way, there is no buffering.
Curt: How are you generating gyro, accel, and gps measurements (specifically gyro) ? Are you using the "ground truth" values computed in the FDM, or are you adding your noise+drift to the values and then feeding it to your attitude estimator (Kalman Filter) ? If you are simulating noise+drift, could you post your model? Thanks.
You need to ask Jordi to add an ethernet connection to the ardupilot, then you can talk to FlightGear directly (and quickly) and it opens up many many possibilities.
-
1
-
2
-
3
-
4
of 4 Next