#2313 Add m3 consumable values to Native-FDM protocol
This feature request is in relation to my forum post here: "Out of Fuel" message with networked Flightgear.
It would be great for Native-FDM protocol to transfer the following values for each fuel tank: selected, capacity-m3, capacity-m3, level-m3 and unusable-m3.
This would stop the default c172 from displaying spurious "Out of Fuel" messages when you are using Flightgear on two networked machines.
Native-FDM already transfers level-gal_us but this is not sufficient.
I have spiked out adding the additional values to the protocol built Flightgear and tested a fix between two Ubuntu 20.04 machines and the PR is here.
If this is the correct path I would be pleased to make whatever pragmatic changes are necessary and rebuild and retest for it to be merged.
Steps to reproduce the issue on Flightgear >= 2018::
On leader machine execute the following:
FG_ROOT=/usr/share/games/flightgear FG_HOME=/home/chris/.fgfs /usr/games/fgfs \ --aircraft=c172p \ --enable-auto-coordination \ --timeofday=morning \ --enable-fullscreen \ --enable-terrasync \ --prop:/sim/terrasync/http-server=http://flightgear.sourceforge.net/scenery \ --enable-real-weather-fetch \ --native-fdm=socket,out,60,192.168.1.71,5510,udp \ --native-ctrls=socket,out,60,192.168.1.71,5511,udp \ --httpd=8080 \ --fg-aircraft=/home/chris/.fgfs/Aircraft
On follower execute the following:
FG_ROOT=/usr/share/games/flightgear FG_HOME=/home/chris/.fgfs /usr/games/fgfs \ --aircraft=c172p \ --enable-auto-coordination \ --timeofday=morning \ --enable-fullscreen \ --enable-terrasync \ --prop:/sim/terrasync/http-server=http://flightgear.sourceforge.net/scenery \ --enable-real-weather-fetch \ --fov=66.7 \ --prop:/sim/view[0]/config/heading-offset-deg=-70 \ --prop:/sim/view[0]/config/pitch-offset-deg=0 \ --fdm=null \ --native-fdm=socket,in,60,,5510,udp \ --native-ctrls=socket,in,60,,5511,udp \ --fg-aircraft=/home/chris/.fgfs/Aircraft
And you will see the "Out of fuel!" popup in this screenshot:
Hi Chirs, we're having some discussion about this on the mailing list. It's not intended, that the C++ needs to be extedned for particular aircraft properties, to make this work.
I'm not so familiar myself, but the suggestion is to use the 'generic' protocol, which is confiurable, unlike the 'native FDM' protocol. Apparently you might already even have done this?
Hi James,
This is not about adding properties to the Native FDM protocol but rather
fixing what's already there. The protocol already transmits "level-gal_us"
however this is not sufficient to transmit fuel state to a secondary
instance or satisfy the use cases here:
http://wiki.flightgear.org/Howto:Multi-computing_FlightGear
http://wiki.flightgear.org/Slaving_for_Dummies
https://www.inkdrop.net/dave/multimon.pdf
My attempt in May to have this addressed by the aircraft model failed and
eventually indicated that the root cause is missing properties on the
secondary instances:
https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/9c5da88d-7d59-7da0-1c1e-d415196faeaf%40cox.net/#msg37020341
The ability to run Flightgear like this across multiple computers is a
unique and killer feature. What other flight simulation software allows you
to freely download, install and simultaneously use an unlimited number of
instances of it? Imagine the immersion you could get with four, fix, six
screens powered by two or three beefy PCs.
Creating a generic protocol to work around missing properties in Native FDM
is a frustratingly brittle and error prone process that I doubt many are
willing to undertake.
Regards,
Chris
edit: removed email chain below
Last edit: Chris Speck 2020-07-23
A bit of context here: I don't have personal experience with the Native FDM protocol, but from a software maintenence perspective, we have far too many protocols at the C++ level, and we should be aiming to reduce it. Ideally we'd have /just/ the generic protocol, and make everything run-time configurable, with no properties hard-coded. Since especially for something like fuel, the tank layout, valves, etc is all very aircraft specific, there's no way we can capture that in a standard fixed set of properties.
Obviously that's not where we are today, but I don't understand why you think using the generic protocol would be brittle or difficult; when I checked with other developers, that was exactly the aproach they recommended. Maybe we need to document the generic protocol better, or make its parser more robust, to reduce the brittle-ness? But those are both much better time investments than expanding the native protocol, or any of the 'fixed' protocols, I would say.
And of course, we can just add these properties to the Native FDM protocol as a quick fix, but I don't see any reason why /these/ properties are special compared to the thousands of properties in the C172, which make it necessary to include them. Presumably once these are fixed there's another fifty or hundred you will need added, until you switch to the generic protocol?
I understand the slippery slope argument but it does not apply in this case because this change is about fixing already present broken behaviour.
Native FDM already transmits fuel information, but not in a way that is usable by recieving Flight Gear instances as demonstrated.
A couple problems with it, from an outsider's perspective:
a) it is difficult to determine which nodes should be transmitted
- some appear derived,
- some appear to have no effect,
- some give different values in nasal vs the property browser
b) the xml format spec is overly verbose, e.g.:
- it requires input and output declarations even when identical
- it requires sprintf formatting specifications when it already knows the data types (there could be implied sane defaults)
c) it is not possible to specify the path to a generic protocol at runtime
d) a default install requires root access to update/change these protcols.
e) binary mode is difficult to use, test and troubleshoot in the absence of any tooling or test harness.
It would be amazing if these issues could be addressed. Off the top of my head I could envisage a live interface that lets you add/remove properties based on the browser, and generates a guaranteed working protocol file. Improvements or alternatives to the Generic Protocol system ought to be subject of a different discussion.
For the C172 multi-computer use case there is only one remaining issue regarding cabin temperature, so this is unlikely.
This is also an accessibility issue. It would be good for the project if less technically inclined people were able to rely on the documentation to get multi-compute with the default aircraft going.
If it's limited to a handful more properties, indeed this is okay. Although it seems weird that you aren't removing any properties, in that case. Anyway, I'll take a look at that patches.
About the generic protocol, we do need a seperate discussion (on the developer list), but I would observe that it will only improve if you (or someone like you) steps up to do the work: there is no magical development team that would jump in and work on that. So I'd suggest, if you care about this kind of multi-compute (and I'd also want a discusison about different styles of multi-compute, since this one is the most complex/awkward to support...), then it's on you to decide what protocol(s) you want to base it upon, and then improve those. It doesn't mean you need to /all/ the work yourself, but in the end someone has to put the hours in.
BTW: at least some of the issues you mentioned are fixed already: Generic protocols can now be added and removed at runtime, and the configuration file can live in an add-on or other places that don't require root access. Fixing the XML syntax should be straightforward as well.
Finally, the 'it's difficult to work out which properties to transmit' is valid, but this is aircraft-specific for sure: indeed it's one of the reasons I don't favour this method of multi-compute, becuase you have to work out what to send, and what not to send /for each aircraft/, which is very complex and fragile (if the aircraft is updated)
Hi Folks,
I've done some further digging, and I think I understand better why the
tank properties are required. Apologies to Chris for taking this long to
properly understand the issue.
Basically JSBSim and YASim are setting these properties, but in the
null-fdm case they end up being set to 0. See src/FDM/TankProperties.cxx,
and particularly the bind() code and initialiation. Also JSBSim.cxx line
301, and YASim/FGFDM.cpp line 204. So I think we should add these to the
fdm protocol.
Cabin temperature is definitely c172p-specific - it's all coded in
Systems/c172p-heat.xml. I don't know if that's the only property that is
required though - are those System/*.xml files executed for a null fdm? If
so, then I strongly suspect that there are other properties that are
required to ensure the windows don't steam up etc.
-Stuart
Improving this sort of multi-compute generally sounds like a large and ongoing task that I am happy to contribute towards, but it is a seperate issue to the missing fuel properties. Before I do anything in that space I'd want ensure I've fully explored the area and sought buy-in from the likes of you, Stuart and the other core devs.
This is great, I look forward to seeing it drop in the next release!
Have you had a chance to review my PR?
https://sourceforge.net/p/flightgear/flightgear/merge-requests/219/
I'm going to look at these changes, no worries there :)
And about the larger discusison, indeed let's have it, but orthogonal to getting these small pieces fixed, otherwise we're not helping anybody.
@cgspeck, can you confirm if everything works as expected post merge? In that case, this ticket could be closed. Thanks again!
Hi, thanks for the reminder! It's almost midnight where I am, I can check this tomorrow and get back to you.
Tests pass, thank you for accepting my PR :-) You can mark this ticket as Done.
I'm sorry to re-open this ticket but the merge-request 219 breaks backward compatibility. Following this change, JSBSim can no longer be used as an external FDM since the FDM protocol has been modified. This has been reported by one of JSBSim users (see JSBSim ticket #325).
The thing is that the protocol has not been modified for more than 14 years (commit [00efc0] by Curt Olson) so it has long been forgotten that the first course of action when pushing backward incompatible changes to this protocol is to increment its version
FG_NET_FDM_VERSION:I will proceed with that change and see how JSBSim can support 2 different versions of the protocol (since version 24 will be part of FlightGear LTS release meaning we will have to live with it for quite some time).
Until this problem is solved on both sides (FlightGear and JSBSim) I suggest that we keep this ticket open.
Thanks.
Last edit: Bertrand Coconnier 2020-10-02
So JSBSim is now capable of handling the 2 versions (24 and 25) of FlightGear's FDM network protocol. The code is ugly (well, actually very ugly) but I don't mind since the code to communicate with FlightGear via a socket is quite well isolated from the rest of JSBSim code.
At the moment, the user must manually specify to JSBSim the version of the FDM protocol that his/her copy of FlightGear uses. Is there a way to programatically interrogate FlightGear (hopefully via the same socket) to get the protocol version number ? That would allow JSBSim to automatically select the correct version on its side. Note that in order to be useful, this feature needs to be available on the LTS release of FlightGear as well.
I would also like to tell that this FDM protocol is not very well suited for revisions. The only bit of information that allows to detect a problem is a version mismatch which FlightGear drops via an obscure message in the console:
Is there a way to agree on a procedure about how to update this protocol in a way that would ease the management of several versions by JSBSim ?
@bcoconni I must admit I've not followed this in detail: can you reset my brain sliughtly on the larger issue? I've no problem with making a fix (even on the LTS) to make this easier for JSBsim.
@jmturner I am not sure I understand your question. What do you want me to reset your brain about ?
@bcoconni what I mean is, can you explain what this protocol is, who is using, why do we even have, it etc? I was literraly unaware it existed, and it's likely unmaintained.
Well, this is a connection over a socket that allows using an external FDM with FlightGear rather than the versions of JSBSim, YASim or LaRCsim that are embedded with FlightGear.
JSBSim users generally use this feature to visualize the flight trajectory and aircraft attitude : JSBSim computes the flight and FlightGear displays the result. This is quite a niche application of JSBSim/FlightGear but some users customize programmatically JSBSim with Python and the FDM network interface is used for visualization.
This feature is also used by the Matlab Aerospace Blocket™ to interface with FlightGear (see their documentation).
The problem with this merge request is twofold:
1. The new data is added in the middle of the structure
FGNetFDM. However life would be easier if the new data was added at the end of the structure: in that case, the only difference between version 24 and 25 of the protocol would be the length of the data transmitted over the socket.2. As I mentioned earlier, there is no means to know which protocol version is used by the FlightGear instance that JSBSim is connected to.
As an illustration of how to use this feature, we (JSBSim developers) have documented how to interface JSBSim with FlightGear.
And obviously @cgspeck has created another application for this feature which he explained in the first post of this ticket.
@bcoconni incorrect. Using this protocol for multi-compute Flightgear preceeds my interest in the matter.
Why don't you just use the custom protocol definition feature? With next you can specify the path to them on startup. That way you don't need to make any further changes to Flightgear nor external JSBSim, and you can lock down the protocol that you need.
@cgspeck I mean no offense but this is not a reasonable suggestion: JSBSim is using the FDM network protocol since 2007, you cannot ask us to switch to an entirely different protocol just to avoid an "Out of Fuel" message to be displayed on one of your screen. This is not a fair request especially since, as you pointed out yourself, developping from the ground up an interface for a new protocol is no trivial task. All together, we can do better than that and find a common ground that suits everyone need.
I already went out of my way to modify JSBSim to be able to cope with different FDM protocols. I also suggested some further modifications to FlightGear to keep your patch while being able to interface automatically JSBSim with FlightGear for both protocol versions (24 and 25). I am also ready to code the modifications to FlightGear with a bit of guidance from the core devs.
Obviously, this discussion is addressing the short term future and it is quite possible that at same point in the long term future we should consider dropping the FDM protocol and use the generic protocol instead. However this is an entirely different topic that goes much beyond this ticket.