Board index FlightGear Support Interfacing

Richard's Emesary and visionary Narendram M (omega95)

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

Richard's Emesary and visionary Narendram M (omega95)

Postby Michat » Sat Mar 28, 2020 5:12 am

Howdy Richard. I wonder if your emesary tool could help providing a generic solution for this old development idea made by the amazing dear visionary Narendram M (omega95) 8) .

Mainly I want to know if your msg tool could provide protocol and fast communications between two connected pc equipments (not sure if is local or mp protocol). Reducing response time as he showed in this video.

User avatar
Posts: 1041
Joined: Mon Jan 25, 2010 6:24 pm
Location: Spain
Version: 191b
OS: GNewSense

Re: Richard's Emesary and visionary Narendram M (omega95)

Postby jano » Sat Mar 28, 2020 1:37 pm

imho, the best way to improve dual control would be using a peer to peer approach, with a high sending rate. even then, you'll have a latency except if you find a way to have the player having the command run the fdm, and when changing hand, the other pilot run the fdm (like in a real plane, when only one pilot take the command).

I remember having tried it with XIII (yeh, long ago :) ) on the c172p back in the days, was fun to control the plane and see the effects 2 secondes later :)

Posts: 184
Joined: Thu Nov 29, 2007 11:32 pm
Location: france
Callsign: jano
Version: git
OS: debian SID

Re: Richard's Emesary and visionary Narendram M (omega95)

Postby Richard » Sun Mar 29, 2020 10:56 am

There's already been a lot of work on dual control of aircraft - the one thing holding us back is the latency of the current fgms infrastructure; for some reason it is around 900ms (measured on my system with two FG instances) - which leads to a delay of approximately 2seconds between control input and visible effect. Reports that I've received indicate that the latency is fairly constant.

There are a number of possibly solutions;
1. Figure out what is causing the current delay - is it infrastructure or the architecture we're using
2. Use the current fgms as it currently is but switch to peer to peer for short range. This isn't as easy as it sounds as we have to be careful to not break large group flights (e.g. 10+ aircraft in close proximity)
3. Design a new protocol that is more suitable to dual control (i.e. allowing low speed and high speed data)
4. Use another system to replace fgms (I started working on integrating ffs2play but haven't got very far with this)

Using Emesary to perform dual control is already something that I did some work on with the F-14 - and it provides a much cleaner solution than the current dual control - however as yet I haven't pursued it much further because of the latency but also because there are some future plans I have for the underlying protocol to better enable generic transmission of properties in a packed manner but also to permit the recipient to be able to request a property name map for a notification. That's the weak point of the current Emesary MP bridge - i.e. that all transmitters and recipients need to know the format of the notifications to be able to pack/unpack.
Posts: 783
Joined: Sun Nov 02, 2014 10:17 pm
Version: Git
OS: Win10

Re: Richard's Emesary and visionary Narendram M (omega95)

Postby Hooray » Sun Mar 29, 2020 11:04 am

Emesary could help with quite a few things in FlightGear, but for that to happen, it would need to be better integrated with existing infrastructure/systems.

Specifically, a dedicated fgcommand layer would make sense - because that's how emesary can be used all over the place in the form of bindings (cockpit bindings, GUI dialogs).
The other obvious thing is property tree tooling - and when it comes to multiplayer in particular, it would make sense to hook up our existing XDR handling helpers to the property tree.

That way, you could get/set properties via XDR data structures - possibly in conjunction with a dedicated XDR encoding per property.
This would simplify a ton of things in FlightGear that have to do with serialization/persistence of properties/data structures (think multiplayer, but also instant replay/fgtape).

Also, Emesary is transport agnostic, so it would make sense to have a bridge for our existing SGSocket class, or at least the generic protocol system - in conjunction with an event based message type, so that publish/subscribe schemes can be implemented on top of Emesary via arbitrary SGIOChannels.

At that point, the sky is the limit, because all sorts of binary protocols could be implemented on top of FlightGear's existing I/O means and the Emesary system with properties.

In summary, Emesary needs some simgear helpers to integrate with the existing SGCommandMgr and SGSubsystemMgr infrastructure, and with XDR encoding/decoding helpers - possibly in the form of native SGPropertyNode types.

Once these systems are fully exposed, Emesary could be used for better/new MP protocols/systems, but also for things that require currently hard-coded I/O protocols.
Including dedicated protocols to inter-link multiple fgfs instances (multiplayer, dual-control, fsweekend, linuxtag)

Just look at Stuart's FG1000 work or the PUI2Qt transition: the key takeaway really is to stop using Nasal blobs all over the place, and instead register Nasal functions as fgcommands that work over Emesary - at that point, we can have our cake and eat it, regardless of the underlying transport/protocol - and that would even work for setups where Emesary processes notifications sent from different threads.

This will also make it straightforward to render canvas based avionics in different fgfs instances. But before any of that can happen, additional interfacing is needed, and some better documentation/examples. Everything else will follow automatically, especially once the system supports XDR natively - at that point, people could even implement a completely new MP environment on top of SGSocketUDP + SGPropertyNode + Emesary

Richard wrote in Sun Mar 29, 2020 10:56 am:but also to permit the recipient to be able to request a property name map for a notification. That's the weak point of the current Emesary MP bridge - i.e. that all transmitters and recipients need to know the format of the notifications to be able to pack/unpack.

FWIW, there was once a patch floating around on the forum that moved the static map into a PropertyList encoded XML file (part of fgdata) that would use inheritance/params to customize things, this would even make per-aircraft configs/maps possible.

I don't think this got ever committed, but James commented on it on the forum or the issue tracker - basically the existing map was converted to PropertyList/XML and then "versioned", this would make all sorts of fancy things possible, especially in conjunction with XDR-based property representations

I think, that patch overlapped with ThorstenB's flight recorder work, so there is quite a bit of overlapping functionality here if these 3 use-cases can be unified.
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,
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Posts: 11951
Joined: Tue Mar 25, 2008 8:40 am

Return to Interfacing

Who is online

Users browsing this forum: No registered users and 2 guests