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.

Views: 2666

Reply to This

Replies to This Discussion

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.
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.
Thanks for your comments, Curt and hopslink.

I thought the packets may be accumulating, so I run the FG packets at twice the rate of the SciLab. Plus, the delay stays relatively constant as the sim runs. If it was a problem with packets accumulating, I would expect the delay to grow over time.

I set the control deflections directly. That way I can model the slew rates and delays in SciLab. Do you have any thoughts or suggestions on this?

Tom
You seem to be covering most of the potential snags I can see. Curt would be far better placed to comment...

My experience of the process was fairly painless. I started with 2.0, but found it would not run on my hardware so regressed to 1.91b. After that the only other time I had comms issues was when FG was using a large (>80%) proportion of my system CPU resources. Disabling some of the graphics options freed this up and I now see FG using between 10 and 30% CPU and have no problems.

Other points to note was that increasing packet rates above 50Hz on my machine seems to have little effect (I run FG output at 50Hz and input at 20Hz based round the ArduIMU target specs).

You are welcome to take my code if you think it may be of any use to you.

Paul


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.
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
I am running them both on the same computer. I am on a budget. :)

Thanks for your thoughts. Like most of the problems that hold me up for a long time, it's probably something very simple.

I don't know much about quads, so what is a "backstepping design"?

Tom
Hi Tom,

Question: can you see if the delay happens between when scilab sends the UDP packet and FlightGear reads and react to it? Or is the delay when FlightGear sends the control positions back to scilab and scilab recognizes the change?

You might be able to visually see at which stage the lag is happening if you are running both on the same computer?
Curt,

It is definitely a delay between SciLab sending the packet and Flightgear responding. I have other plots showing the aircraft behavior (pitch, roll, etc.) and the control surfaces are definitely moving at the same time Flightgear is reporting them to SciLab. In other words, the aircraft is clearly flying with control surfaces at zero for the first second or so, and then it begins pitching and rolling at the same time the non-zero control deflections are reported to SciLab.

I really appreciate you taking the time to think about this.

Tom
One other thought ... this would be some extra work, but could you write some other mini-test app to receive the output of scilab (maybe even another scilab program?) That might help determine if the delay is coming from scilab sending, or FlightGear receiving. Also, what version of FlightGear are you running?
That's a good idea. I don't know if I can run two different programs at the same time with SciLab. I may have to enlist my neighbor's help to write a custom program.

We are currently running 2.0, but we have also tried 1.9 with the same results.

Tom
On windows I have no idea, but on linux you could probably modify scilab to output some simple ascii packets and then watch them arrive with "nc", but that would probably be a lot of screwing around, even on linux.

Reply to Discussion

RSS

© 2017   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service