Board index FlightGear Support Interfacing

Event driven communication to FG, not at a regular rate?

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

Event driven communication to FG, not at a regular rate?

Postby chriscalef » Wed Jan 29, 2020 11:53 pm

Hi, it seems as if this is not the way it is done, but I just thought I'd ask to make sure: I have an external application that is consuming a UDP stream of aircraft properties from FG, and that is going well. However, I would also like to (very rarely) send information/commands back to FG.

I understand that I can make a generic socket input connection at any Hz, and that it can be a different rate from my UDP outgoing connection, but it would be ideal for my situation if I could have FG just listen on the socket and deal with my messages at whatever time they come in, rather than expecting to receive a steady stream of many packets per second.

I have a hand-rolled socket library which I may use to accomplish this, if FG doesn't have a built in way to do it, or I might just go ahead and use the existing system, with the understanding that it is not that much wasted bandwidth at the end of the day regardless... but it did seem worth asking about.

On a related note: what happens if I do set up an input socket type, and then do not send packets at that speed? Will FG hang up waiting for packets, or just ignore the problem and move on? I'm curious about this both in terms of both A) whether I could wait and only send packets when I feel like it, and also B) what happens if my frame rate in the external application were to drop below the Hz specified for the FG input connection.

Thanks, and Happy Flying!
Chris
chriscalef
 
Posts: 279
Joined: Wed Feb 20, 2013 9:28 pm

Re: Event driven communication to FG, not at a regular rate?

Postby Hooray » Thu Jan 30, 2020 7:04 pm

For starters (prototyping), you could easily use the "props" (property/telnet) daemon and/or the mongoose-based AJAX wrapper (check Phi)

http://wiki.flightgear.org/Telnet_usage

For anything involving binary data (think images/video), you'd probably want to implement a similar mechanism on top of UDP or extend the telnet protocol accordingly: http://wiki.flightgear.org/Property_Tree/Sockets

However, one of the lowest-hanging fruits would indeed be using/extending the telnet protocol as needed - for instance, a number of core developers discussed the idea of allowing custom telnet commands to be implemented in scripted form via Nasal - as per the "addcommand()" API, just specific to the telnet context.


For the technical details of extending the built-in telnet dameon via new commands, see the examples at (this is implemented and commited):

http://wiki.flightgear.org/Improved_J661_support
http://wiki.flightgear.org/Telnet_usage ... nsubscribe

Note that you can already implement fgcommands in Nasal via the addcommand API, and that you can already invoke those fgcommands via the telnet daemon - so you can accomplish this already "as is". However, there still is the long-standing idea to provide a more direct way to specify/register new telnet commands via Nasal, possibly at runtime or by loading those scripts/XML commands from $FG_ROOT

http://wiki.flightgear.org/Howto:Add_ne ... FlightGear
http://wiki.flightgear.org/Nasal_librar ... mand.28.29
http://wiki.flightgear.org/Howto:Extend_Nasal


In addition, there is also the option to simply set up an interactive Nasal REPL (shell) and hook that up to the telnet daemon, we have existing code for this sort of thing: http://wiki.flightgear.org/Interactive_Nasal_REPL


Personally, I'd suggest to review the implementation of the susbscribe/unsubscribe telnet commands and then use those as a template to implement new commands to register/invoke custom Nasal code - once that works, you could also adapt the telnet code to run the whole REPL interpreter that way. At that point, you end up with a Nasal-enabled telnet daemon that you can use to run all sorts of scripts on demand, without requiring a regular rate.

If in doubt, refer to the mailing list archives to dig out the old discussions suggesting a Nasal-capability to register telnet commands.

Overall, this approach would be fairly simple and extremely powerful - i.e. no more than 100 lines of code, most of which could be taken from existing examples.

Finally, there is also the option of wrapping SGSocket via Nasal/cppbind to expose such functionality to scripting space and get really fancy.
There is also a so called "Emesary" framework (available in Nasal and C++ space) that can be used to implement a message-based protocol: http://wiki.flightgear.org/Emesary
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: 11835
Joined: Tue Mar 25, 2008 8:40 am

Re: Event driven communication to FG, not at a regular rate?

Postby daweed » Fri Jan 31, 2020 8:35 am

chriscalef wrote in Wed Jan 29, 2020 11:53 pm:On a related note: what happens if I do set up an input socket type, and then do not send packets at that speed? Will FG hang up waiting for packets, or just ignore the problem and move on? I'm curious about this both in terms of both A) whether I could wait and only send packets when I feel like it, and also B) what happens if my frame rate in the external application were to drop below the Hz specified for the FG input connection.

Thanks, and Happy Flying!
Chris



Hello,

Using Generic protocol with my interface solution , i can say that when data does not change i don't push them to FG (hashing data before sending to be compare with the one of the previous loop, if current hash is different from the previous one has, i will send data, if not, nothing is pushed to FG)
i am using TCP socket connexion.
I never lost connexion between Pi and FG because data were not sent.

Regards
Linux Mint 20
AMD Ryzen 7 3700X |32 Go RAMGeForce RTX 2080 8 Go
FG Interface
Lyon Saint Exupery Scenery

ATC on LFLL on Friday 19:00 UTC => 22:00 UTC
daweed
 
Posts: 374
Joined: Thu Dec 11, 2014 10:45 am
Location: LFKP LFLL
Callsign: daweed
OS: Linux Mint 20

Re: Event driven communication to FG, not at a regular rate?

Postby Hooray » Fri Jan 31, 2020 10:39 am

Of course, it would also be possible to add a new "version" tag to the generic protocol, to support new/breaking changes.
For the Arinc 661 stuff, we also ended up using property hashing - it was only later on that we realized that the property tree implementation already uses hashing internally, and that it would be trivial to expose that C++ code to scripting space and/or access a property's hash using a dedicated fgcommand

For the time being, more sophisticated networking requires C++ changes - but the telnet protocol is extremely easy to extend as needed, I believe it's using plib's netchat API, and that could even be factored out into a standalone component for any "chat-like" (query/response) protocols, including even a script-able response handler via Nasal.

We have all the building blocks in place, and regardless of the path you pursue, it's very little code that needs to be written from scratch - it's mostly boilerplate taken from various existing subsysstems.

But for prototyping purposes, I would definitely suggest to tinker with the telnet/props approach, you can easily implement a simple "hello world"-style telnet command and then take it from there so that arbitrary Nasal functions can be executed there by registering them as telnet commands.

But again, not even that is needed - there's already the fgcommand-based approach that works "as is", without requiring C++ changes:

  • write your response handler in Nasal
  • register it as a new fgcommand (see wiki: fgcommands / bindings or README.commands)
  • open fgfs with the props/telnet daemon running
  • connect to fgfs via telnet
  • run your new fgcommand (type help for details)


The only issue here is that any function arguments/return values must be marshaled through the property tree structure - but it's still a straightforward mechanism.

If you hit any throughput/bandwidth limits, those can also be fixed fairly easily.
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: 11835
Joined: Tue Mar 25, 2008 8:40 am

Re: Event driven communication to FG, not at a regular rate?

Postby Hooray » Fri Jan 31, 2020 12:32 pm

okay, it seems as if what I've written above is a little outdated - apparently, the "nasal via telnet" option has been explicitly added a while ago - seemingly, it just never got documented anywhere (?):

https://sourceforge.net/p/flightgear/ma ... /36227216/
James Turner wrote:Well the good news is since a few days ago, Nasal can be done over Telnet, if you start FG with —allow-nasal-from-sockets

Send (over telnet)


>nasal
controls.raise_gear();
##EOF##

For example (the end-of_nasal marker can be customised if needed but ##EOF## is the default)


If in doubt, I'd suggest to check the full thread for context (possibly while reviewing the corresponding commits) and then raise any remaining questions on the developers mailing list, offering to document the new feature on the wiki in the process.

Even though, speaking in general, the more proper answer to the questions posed in that thread (having a front-end agnostic abstraction wrapper to send notifications to the sim) would have been "Emesary", as Richard alluded to here:

https://sourceforge.net/p/flightgear/ma ... /36213611/
Richard Harrison wrote:Of course now I'm going to mention that we really should look at a
directly bridging Emesary notifications via a socket and straight into
Nasal space - as that's a clean way of interfacing from the external
world. Probably I should add the C++ version of Emesary with a Nasal
bridge to the core at some point..


In other words, the I/O mechanism (keyboard, joystick/mouse) could greatly benefit from dedicated Emesary bindings/support, i.e. at the fgcommand/XML layer - so that aircraft, and certain aircraft functionality could "auto-magically" support RPC for key functionality, via Emesary notifications.

https://sourceforge.net/p/flightgear/ma ... /36213137/
James Turner wrote:What we can't currently solve, is custom aircraft controls, or which
bypass controls.nas in non-standard ways - those will always need
something on the Telent (or whatever) client to know that aircraft's
peculiarities and be modified, I think

[...]

the simulator supplies some core
actions and some place-holder ones for 'AP disengage' but aircraft can
either replace existing ones or define completely new ones. This would
also allow easier customizing of input configs (joystick etc) per
aircraft since we can bind a button to action 'engine swivel' and if
there's no such action, do something else.

Part of the motivation here was also to fix the fact our mapping of
'ASCII' control codes to key shortcuts is very unreliable (number one
bug reports on Mac), but that's also where I got stuck since I'm trying
to ensure existing global and aircraft key shortcuts all work as before,
but also that different keyboard mappings (eg, which key combo generates
[ or ] for the flaps) are handled consistently. It's ... complicated.

[...]

Now if I continue with the action idea at some point in the future, then the ‘action’ element of the pick animation would become a ‘efis-waypoint-button’ action, and you’d be able to send a command like:

invoke_action(‘efis-waypoint-button’)

…. from Nasal or telnet or whatever. But this won’t work until I complete the action concept, and of course that aircraft are updated to use this concept.



As an side, it doesn't seem James is fully aware of what Emesary could bring to the table here ?

In case you're hoping to do higher throughput I/O via telnet, see James' comments here, where he talks about a dedicated mechanism to collection property subscriptions into "lists" that are marked "dirty" to allow lazy updates: https://sourceforge.net/p/flightgear/ma ... /36213280/
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: 11835
Joined: Tue Mar 25, 2008 8:40 am


Return to Interfacing

Who is online

Users browsing this forum: No registered users and 1 guest