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.

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –

Replies

  • 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

  • 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.
  • 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.
  • 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.

Activity

DIY Robocars via Twitter
RT @TinkerGen_: "The Tinkergen MARK ($199) is my new favorite starter robocar. It’s got everything — computer vision, deep learning, sensor…
Monday
DIY Robocars via Twitter
Monday
DIY Robocars via Twitter
RT @roboton_io: Join our FREE Sumo Competition 🤖🏆 👉 https://roboton.io/ranking/vsc2020 #sumo #robot #edtech #competition #games4ed https://t.co/WOx…
Nov 16
DIY Drones via Twitter
First impressions of Tinkergen MARK robocar https://ift.tt/36IeZHc
Nov 16
DIY Robocars via Twitter
Our review of the @TinkerGen_ MARK robocar, which is the best on the market right now https://diyrobocars.com/2020/11/15/first-impressions-of-tinkergen-mark-robocar/ https://t.co/ENIlU5SfZ2
Nov 15
DIY Robocars via Twitter
RT @Ingmar_Stapel: I have now explained the OpenBot project in great detail on my blog with 12 articles step by step. I hope you enjoy read…
Nov 15
DIY Robocars via Twitter
RT @DAVGtech: This is a must attend. Click the link, follow link to read the story, sign up. #chaos2020 #digitalconnection #digitalworld ht…
Nov 15
DIY Robocars via Twitter
RT @a1k0n: Got a new chassis for outdoor races (hobbyking Quantum Vandal) but I totally didn't expect that it might cause problems for my g…
Nov 11
DIY Drones via Twitter
First impressions of the Intel OpenBot https://ift.tt/36qkVV4
Nov 10
DIY Robocars via Twitter
Nov 9
DIY Robocars via Twitter
Excellent use of cardboard instead of 3D printing! https://twitter.com/Ingmar_Stapel/status/1324960595318333441
Nov 7
DIY Robocars via Twitter
RT @chr1sa: We've got a record 50 teams competing in this month's @DIYRobocars @donkey_car virtual AI car race. Starting today at 10:00am…
Nov 7
DIY Robocars via Twitter
Nov 6
DIY Robocars via Twitter
RT @a1k0n: Car's view, using a fisheye camera. The ceiling light tracking algorithm gave me some ideas to improve ConeSLAM, and having grou…
Nov 5
DIY Robocars via Twitter
RT @a1k0n: To get ground truth I measured the rug, found the pixel coordinates of its corners, calibrated my phone camera with my standard…
Nov 5
DIY Robocars via Twitter
RT @a1k0n: @DIYRobocars is back in December, but outside. Time to reinvestigate ConeSLAM! I rigged up a quick and dirty ground-truth captur…
Nov 5
More…