Replies to This Discussion

Permalink Reply by Curt Olson on 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.

• ▶ Reply

Permalink Reply by hopslink on 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.

• ▶ Reply

Permalink Reply by Tom Yochum on July 19, 2010 at 11:23am

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

• ▶ Reply

Permalink Reply by hopslink on July 19, 2010 at 2:03pm

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

• ▶ Reply

Permalink Reply by Tom Yochum on 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.

• ▶ Reply

Permalink Reply by Curt Olson on July 21, 2010 at 9:39am

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?

• ▶ Reply

Permalink Reply by Tom Yochum on July 21, 2010 at 2:07pm

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

• ▶ Reply

Permalink Reply by Curt Olson on July 21, 2010 at 2:13pm

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?

• ▶ Reply

Permalink Reply by Tom Yochum on July 21, 2010 at 2:18pm

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

• ▶ Reply

Permalink Reply by Curt Olson on July 21, 2010 at 2:21pm

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

Permalink Reply by Roy Brewer on 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

• ▶ Reply

Permalink Reply by Tom Yochum on July 21, 2010 at 8:59am

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

• ▶ Reply

• ‹ Previous
• 1
• 2
• Next ›
• Page