Board index FlightGear Support Interfacing

Low generic output frequency

Connecting two computers, using generic protocol, connecting with Matlab?

Low generic output frequency

Postby rokwell » Thu Jul 03, 2014 10:16 am

I am trying to connect flight gear to a real autopilot. To do this I am communicating with the autopilot via UDP and I have written a code that converts all necessary data from flightgear and sends it to the autopilot in the correct format. Controls inputs from the autopilot is converted and sent back to flightgear. So far so good.

But for some reason I cannot get flightgear to send data at a higher rate than 20 Hz. Even if I send the data to a file instead of UDP I still only get 20 Hz even though I specify 100Hz.

Is there some frequency limiter hard coded into flightgear that limits the generic output frequency to 20Hz? My target is to have around 100Hz.
Keep reading the manuals but need to hear from the experienced persons.
rokwell
 
Posts: 72
Joined: Tue Jun 14, 2011 2:00 am
Location: Don Muang Airport, Bkk, Thailand
Version: 2.12
OS: Ubuntu 12.04

Re: Low generic output frequency

Postby Philosopher » Fri Jul 04, 2014 12:24 am

What is your frame rate? I'm pretty sure all the protocols are limited by frame rate, so 100Hz might not be possible. (Running it with the FDM should be possible with a few C++ changes (minimum), but wouldn't be "steady" Hz, only an amount of Hz on average AFAIK.)
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1590
Joined: Sun Aug 12, 2012 6:29 pm
Location: Stuck in my head...
Callsign: AFTI
Version: Git
OS: Mac OS X 10.7.5

Re: Low generic output frequency

Postby Hooray » Fri Jul 04, 2014 12:56 am

Indeed, I/O is frame-rate dependent - typical frame rates are roughly 50-60 fps/hz. Thus, 100hz would seem like a lot, and it would never be steady either, because all I/O is running interleaved with the main loop, i.e. with other subsystems. Unfortunately, FlightGear's I/O system doesn't run in its own thread. Like Philosopher said, you /may/ be able to work around this by using an FDM-coupled subsystem,or by interleaving your I/O subsystem with the FDM, which may either require creative use of listeners & signals (property rules).
Alternatively, you could throttle the frame rate to a sane value like 20-30 fps and then use accelerated sim time. I think several people have used this workaround in the past

Overall, it would be a good idea to file a feature request. In the meantime, you could also use some minor C++ changes:
Subject: Actual programming language for autopilot implementation?
Hooray wrote:I still don't think this needs to be very complicated, especially not with all the pointers that you have now - this is what I got after 5-10 minutes playing around (not really tested in depth yet) - but this should get you started on the right track:

Code: Select all
diff --git a/src/Main/fg_init.cxx b/src/Main/fg_init.cxx
index cb4a2e5..ddafce0 100644
--- a/src/Main/fg_init.cxx
+++ b/src/Main/fg_init.cxx
@@ -1069,6 +1069,10 @@ bool fgInitSubsystems() {
     globals->get_event_mgr()->init();
     globals->get_event_mgr()->setRealtimeProperty(fgGetNode("/sim/time/delta-realtime-sec", true));
 
+    // and now for the FDM-coupled event mgr:
+    globals->get_event_mgr(true)->init();
+    globals->get_event_mgr(true)->setRealtimeProperty(fgGetNode("/sim/time/delta-realtime-sec",true));
+
     ////////////////////////////////////////////////////////////////////
     // Initialize the property interpolator subsystem. Put into the INIT
     // group because the "nasal" subsystem may need it at GENERAL take-down.
@@ -1247,6 +1251,10 @@ bool fgInitSubsystems() {
     
     // ordering here is important : Nasal (via events), then models, then views
     globals->add_subsystem("events", globals->get_event_mgr(), SGSubsystemMgr::DISPLAY);
+
+    // another event system instance that runs coupled with the FDM
+    // to be used for Nasal scripts
+    globals->add_subsystem("fdm-events", globals->get_event_mgr(true), SGSubsystemMgr::FDM);
     
     FGAircraftModel* acm = new FGAircraftModel;
     globals->set_aircraft_model(acm);
diff --git a/src/Main/globals.cxx b/src/Main/globals.cxx
index 8c8ca52..698ef4a 100644
--- a/src/Main/globals.cxx
+++ b/src/Main/globals.cxx
@@ -126,6 +126,7 @@ FGGlobals::FGGlobals() :
     renderer( new FGRenderer ),
     subsystem_mgr( new SGSubsystemMgr ),
     event_mgr( new SGEventMgr ),
+    fdm_coupled_event_mgr( new SGEventMgr ),
     sim_time_sec( 0.0 ),
     fg_root( "" ),
     time_params( NULL ),
@@ -378,9 +379,10 @@ FGGlobals::get_soundmgr () const
 }
 
 SGEventMgr *
-FGGlobals::get_event_mgr () const
+FGGlobals::get_event_mgr (bool fdm_coupled) const
 {
-    return event_mgr;
+    if (!fdm_coupled) return event_mgr;
+    return fdm_coupled_event_mgr;
 }
 
 const SGGeod &
diff --git a/src/Main/globals.hxx b/src/Main/globals.hxx
index 2ec9cc3..73e69ad 100644
--- a/src/Main/globals.hxx
+++ b/src/Main/globals.hxx
@@ -91,6 +91,7 @@ private:
     FGRenderer *renderer;
     SGSubsystemMgr *subsystem_mgr;
     SGEventMgr *event_mgr;
+    SGEventMgr *fdm_coupled_event_mgr;
 
     // Number of milliseconds elapsed since the start of the program.
     double sim_time_sec;
@@ -181,7 +182,7 @@ public:
                                 type = SGSubsystemMgr::GENERAL,
                                 double min_time_sec = 0);
 
-    virtual SGEventMgr *get_event_mgr () const;
+    virtual SGEventMgr *get_event_mgr (bool fdm_coupled=false) const;
 
     virtual SGSoundMgr *get_soundmgr () const;
 
diff --git a/src/Scripting/NasalSys.cxx b/src/Scripting/NasalSys.cxx
index a398301..24d7fb3 100644
--- a/src/Scripting/NasalSys.cxx
+++ b/src/Scripting/NasalSys.cxx
@@ -897,6 +897,7 @@ void FGNasalSys::setTimer(naContext c, int argc, naRef* args)
     }
 
     bool simtime = (argc > 2 && naTrue(args[2])) ? false : true;
+    bool fdm_coupled = (argc > 3 && naTrue(args[3])) ? true: false;
 
     // Generate and register a C++ timer handler
     NasalTimer* t = new NasalTimer;
@@ -904,9 +905,17 @@ void FGNasalSys::setTimer(naContext c, int argc, naRef* args)
     t->gcKey = gcSave(handler);
     t->nasal = this;
 
-    globals->get_event_mgr()->addEvent("NasalTimer",
+    if (fdm_coupled) {
+     static_cast<SGEventMgr *>(globals->get_subsystem("fdm-events"))->addEvent("NasalTimer (FDM coupled)",
+                  t, &NasalTimer::timerExpired,
+                  delta.num, simtime);
+      SG_LOG(SG_NASAL, SG_DEBUG, "Registering FDM-coupled Nasal callback!");
+    }
+    else {
+      globals->get_event_mgr()->addEvent("NasalTimer",
                                        t, &NasalTimer::timerExpired,
                                        delta.num, simtime);
+    }
 }
 
 void FGNasalSys::handleTimer(NasalTimer* t)



Note: I only started with --model-hz=500 to make the difference really obvious
Image

Notice how the remaining subsystems (in particular nasal and events) still run at framerate, only scripts using the new optional settimer() argument will be run fdm-coupled
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: Low generic output frequency

Postby Hooray » Sat Jul 05, 2014 4:32 pm

http://wiki.flightgear.org/FlightGear_I ... orkarounds

The main properties to adjust FlightGear's I/O rate are these:
  • /sim/max-simtime-per-frame - determines how long FlightGear may take to build a single frame
  • /sim/gui/frame-rate-throttled - determines the max frame rate used by FlightGear
  • /sim/model-hz - determines the FDM rate (some subsystems run interleaved with the FDM, e.g. the AP)
  • /sim/speed-up - determines FlightGear's simulation rate

And then there's obviously the "hz" (hertz) parameters itself supported by most I/O options (multiplayer, protocols, generic etc)

You may have to disable vsync throttling (which is typically around 60 fps/hz)

Unfortunately, all of these settings are extremely inconsistent and they have never been formalized, so how well a certain aircraft/FDM, and its subsystems (hardcoded or scripted) may support these properties is fairly random for the time being admittedly. This also applies to many instruments and dialogs which may deal with different properties and support them to varying degrees. Pausing the simulator, and which subsystems to halt, also isn't sufficiently formalized yet[1]. This kind of chaos would be prohibitive in a professional simulator, so we're kinda lacking structure and standardization here...
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: Low generic output frequency

Postby rokwell » Wed Jul 09, 2014 4:23 am

Thanks for the response. i've measured the system performance, it's about 20 Hz. To be able to have 50 Hz like Hooray's example, where to put those codes? I mean which file in the src or do i have to create into a new file?

Thanks
Keep reading the manuals but need to hear from the experienced persons.
rokwell
 
Posts: 72
Joined: Tue Jun 14, 2011 2:00 am
Location: Don Muang Airport, Bkk, Thailand
Version: 2.12
OS: Ubuntu 12.04

Re: Low generic output frequency

Postby rokwell » Wed Jul 16, 2014 10:44 am

I've just replace the vga card from GTX560 to GTX750, the frame rate increased from 21 to 61 fps. So maybe the frame rate is up to the vga card performance (without any changes of coding).
Keep reading the manuals but need to hear from the experienced persons.
rokwell
 
Posts: 72
Joined: Tue Jun 14, 2011 2:00 am
Location: Don Muang Airport, Bkk, Thailand
Version: 2.12
OS: Ubuntu 12.04

Re: Low generic output frequency

Postby Hooray » Wed Jul 16, 2014 11:18 am

that would suggest that you were indeed GPU-limited, not CPU-bound, which basically depends not only on your hardware, but also your startup and run-time settings.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11329
Joined: Tue Mar 25, 2008 8:40 am


Return to Interfacing

Who is online

Users browsing this forum: MSN [Bot], thunderbolt and 1 guest