closed-loop software simulation with Flightgear and SciLab

My neighbor and I have been trying to do something similar to Tom Hastie's simulation (see here) but using only free software. Our goal is to get a closed-loop, all-software simulation using Flightgear as the flight simulation and SciLab as the autopilot stand-in. This allows for quick prototyping of your autopilot code without risking your aircraft. The best part, of course, is that it doesn't cost anything. :)

Brian (my neighbor and software guru) created a simple UDP server program to set up the connection between Fligthgear and SciLab. I wrote some prototype navigation/flight planning software in SciLab. When we run the simulation, we get flight data coming into SciLab and servo commands going back to Flightgear. However, there appears to be an approximately 2 second delay between when SciLab sends the command and the servos move in Flighgear. This causes the navigation algorithm to go unstable.

We have tried using both Flightgear versions 1.9 and 2.0.

I will try to upload some plots showing what we are getting when I get home.

Has anyone tried using Flightgear and SciLab together like this? Any thoughts on what we should try?

@Roy Brewer:

Yes, we were planning on sharing our code once we had this resolved. We were orginally trying to finish this for the "write DIY" T3 contest, so that tells you how long we have been working on this! Wives, kids, and jobs keep getting in the way! :P I was planning on sharing our flighplan and navigation code, as well as some tools I created for designing full-state feedback controllers using LQR.

For what it's worth, I have done something similar using "microgear" which is a stand-alone autopilot app (it builds under linux or probably cygwin) so you can run it on a linux pc, presumably a windows pc, and on something like a gumstix or mpc-5200 embedded processor that runs linux.

I haven't experienced any of the delays you mentioned, I've run this configuration entirely in software with FlightGear running on the same PC as the autopilot app. I've also run "hardware in the loop" with the autopilot app running on the gumstix -- communicating sensor and actuator data via an ethernet connection.

Here's one thought ... UDP packets can stack up and be held in the network buffer until the remote end gets around to processing them. If your scilab code is grabbing one packet and running it's processing loop, then grabbing the next packet and processing it ... what happens if FlightGear sends packets faster than scilab is processing? You can get a build up in the buffer and it can show up in lags like this.

FlightGear should be handling this already by reading all available packets and tossing out all but the newest one. This way if one side starts after the other, or there's some sort of pause in the code or processing loop on one end or the other, the side that is behind will quickly catch up to real time.

Regards,

Curt.

Replies

Roy Brewer July 21, 2010 at 8:51am

Thanks for answering my questions.

I am nowhere near the level you are, so I cannot help. If I understand correctly, you are running scilab one one computer and flightgear on another, and using a network UDP packets to communicate between the two? Have you tried running both programs on the same computer?

Good luck resolving this issue. I am looking forward to seeing your code. (I am leaning more toward backstepping design for my quadrotor, but even that may be a long way off).

- Roy

- Roy
Tom Yochum July 20, 2010 at 7:55am

This is the plot showing what SciLab is seeing. The top plot is the control commands from SciLab, the middle plot is the control deflections reported by Flightgear. As you can see, there is an approximate 1.5 second delay that remains fairly constant. The x-axis is time in seconds.
hopslink July 19, 2010 at 11:00am

Version 1.91b seems to be the most cooperative, based on feedback from the T3 round 6 thread and elsewhere. Are you configuring FG to accept packets at a higher rate than you actually feed, as that may be worth a go. Also do you set control surface positions directly? or use some other method.

Sorry, no experience with SciLab, but have done some FlightGear comms with Tcl.
Curt Olson July 19, 2010 at 10:48am

For what it's worth, I have done something similar using "microgear" which is a stand-alone autopilot app (it builds under linux or probably cygwin) so you can run it on a linux pc, presumably a windows pc, and on something like a gumstix or mpc-5200 embedded processor that runs linux.

I haven't experienced any of the delays you mentioned, I've run this configuration entirely in software with FlightGear running on the same PC as the autopilot app. I've also run "hardware in the loop" with the autopilot app running on the gumstix -- communicating sensor and actuator data via an ethernet connection.

Here's one thought ... UDP packets can stack up and be held in the network buffer until the remote end gets around to processing them. If your scilab code is grabbing one packet and running it's processing loop, then grabbing the next packet and processing it ... what happens if FlightGear sends packets faster than scilab is processing? You can get a build up in the buffer and it can show up in lags like this.

FlightGear should be handling this already by reading all available packets and tossing out all but the newest one. This way if one side starts after the other, or there's some sort of pause in the code or processing loop on one end or the other, the side that is behind will quickly catch up to real time.

Regards,

Curt.

This reply was deleted.

Discussions

closed-loop software simulation with Flightgear and SciLab

Replies

Activity