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.
FlightGear can't output data faster than it's render frame rate. You could possibly get faster output by running FlightGear on a faster machine, turning down graphics options, in some case running in a smaller window. I'm sure there are tips and tricks on our wiki for boosting frame rates.
thanks for your fast response, indeed according to your comment I tried to modify the output by qgroudcontrol and now I can fully simulate my sensors Yay!
But still, I couln't get the udp output for some higher rate (>30Hz), this problem is probably due to the framerate of Flightgear. Is that correct?
I did the same UDP connection with JSBSim (standalone simulator) and I can have any output(or input) at any rate (just configure the socket at higher rate)..
Is there anyway with flightgear to get higher rate?
I don't know that anyone has done sensor noise/bias modeling inside FlightGear .... at least not from the perspective of typical low cost UAV sensors. Probably the approach I would take would be to create some simple nasal (built in script language) module that runs every frame and takes the pure FlightGear sensor data and dirties it up based on your desired parameters ... then sends that value to your HIL rather than the original.
Hi Curt Olson, I am trying to get a full HIL simulation in order to complete a full navigator-autopilot flying board. I guess people usually define the protocol file to get the acceleration, angular velocity, airspeed, GPS and so on and send them by UDP to the software. Then they generate the "real"-simulated signals by adding noise (bias,drift...). My question is there anyway to get direct output from flightgear to simulate all these sensors. I've seen the FG code with FGsensor, FGAccelerometer, FGMagnetometer.... I tried to configure those sensors to get my output without success (no property "magnetometer" in my properties tree). Does anyone have a clue for helping me.
You need to think about a couple things. (Assuming all the connectivity and baud rate issues are resolved so data is properly flowing.)
- Is flightgear setup to properly interpret whatever information the ardupilot is sending out?
- It's not exactly clear what you are trying to do or what you are expecting to have happen?
- Do you want FlightGear to show the real world values? then you must disable the built in flight dynamics, and make sure you are updating all the position and rotation values from the external source.
I've never used the APM+IMU myself so I'm not aware that the the APM should automatically talk to flightgear without someone doing the necessary work to output the data in a format that flightgear can understand, or on the flightgear side, parse the APM output format.
Well I'm connecting my Ardupilot mega board+IMU sensor board to PC via usb cable. The board is also connected to a receiver. Now the transmitter is sending signals to the board. That's for sure but the FlightGear simulation is not connecting to the board. It is not showing any values in the Ardupilot Sim (interface which shows values of lat, long, alt, roll, pitch, yaw etc.). In other words I cannot control my simulation using the transmitter. And I'm unable to figure out the problem. Does this problem make any sense to you?
I've never used the xbee myself. For desktop (hardware in the loop) testing, I usually use a direct serial connection. In the field for real flying I have been using a maxstream xtend. Serial communication is "simple" once you get it working, but if it doesn't work it's often difficult to debug. I'd check that the wires are all connected right (tx, rx, gnd, etc.) that you have the right baud rate set on both ends, that the hardware is really trying to talk ... what you think should be sending data really is sending data, etc.
Hi,
Sorry for bothering again. I just wanted to ask if you're using xbee or not? Is data transmission possible without xbee? I mean if the board is connected to PC through a serial port then shouldn't data transmission be accomplished through that?
Actually I'm not getting any values from IMU and I just wanted to confirm if it's an xbee issue or not because in my view it shouldn't be an xbee issue.
Comments
FlightGear can't output data faster than it's render frame rate. You could possibly get faster output by running FlightGear on a faster machine, turning down graphics options, in some case running in a smaller window. I'm sure there are tips and tricks on our wiki for boosting frame rates.
thanks for your fast response, indeed according to your comment I tried to modify the output by qgroudcontrol and now I can fully simulate my sensors Yay!
But still, I couln't get the udp output for some higher rate (>30Hz), this problem is probably due to the framerate of Flightgear. Is that correct?
I did the same UDP connection with JSBSim (standalone simulator) and I can have any output(or input) at any rate (just configure the socket at higher rate)..
Is there anyway with flightgear to get higher rate?
best regards
Hi Duc,
I don't know that anyone has done sensor noise/bias modeling inside FlightGear .... at least not from the perspective of typical low cost UAV sensors. Probably the approach I would take would be to create some simple nasal (built in script language) module that runs every frame and takes the pure FlightGear sensor data and dirties it up based on your desired parameters ... then sends that value to your HIL rather than the original.
Regards,
Hi Curt Olson,
I am trying to get a full HIL simulation in order to complete a full navigator-autopilot flying board. I guess people usually define the protocol file to get the acceleration, angular velocity, airspeed, GPS and so on and send them by UDP to the software. Then they generate the "real"-simulated signals by adding noise (bias,drift...). My question is there anyway to get direct output from flightgear to simulate all these sensors. I've seen the FG code with FGsensor, FGAccelerometer, FGMagnetometer.... I tried to configure those sensors to get my output without success (no property "magnetometer" in my properties tree). Does anyone have a clue for helping me.
Thanks a lot!
- Is flightgear setup to properly interpret whatever information the ardupilot is sending out?
- It's not exactly clear what you are trying to do or what you are expecting to have happen?
- Do you want FlightGear to show the real world values? then you must disable the built in flight dynamics, and make sure you are updating all the position and rotation values from the external source.
I've never used the APM+IMU myself so I'm not aware that the the APM should automatically talk to flightgear without someone doing the necessary work to output the data in a format that flightgear can understand, or on the flightgear side, parse the APM output format.
I've never used the xbee myself. For desktop (hardware in the loop) testing, I usually use a direct serial connection. In the field for real flying I have been using a maxstream xtend. Serial communication is "simple" once you get it working, but if it doesn't work it's often difficult to debug. I'd check that the wires are all connected right (tx, rx, gnd, etc.) that you have the right baud rate set on both ends, that the hardware is really trying to talk ... what you think should be sending data really is sending data, etc.
Sorry for bothering again. I just wanted to ask if you're using xbee or not? Is data transmission possible without xbee? I mean if the board is connected to PC through a serial port then shouldn't data transmission be accomplished through that?
Actually I'm not getting any values from IMU and I just wanted to confirm if it's an xbee issue or not because in my view it shouldn't be an xbee issue.
Hi Curt,
Thanks a lot for your help.
Hi Maryam,
Here's a good like to fetch the different available FlightGear releases. The vYYYYMMDD files are pre-release snapshots of the latest developer work.
http://mirrors.ibiblio.org/pub/mirrors/flightgear/ftp/Win32/
-
1
-
2
-
3
-
4
-
5
of 5 Next