Property Tree/Native Protocol Slaving: Difference between revisions

Jump to navigation Jump to search
no edit summary
No edit summary
No edit summary
Line 23: Line 23:


If you have a specific need that doesn't easily fall within the existing interface structure, it's not all that hard to add your own custom interface. There are several examples (i.e. native_ctrls, native_fdm, native_gui, etc.) which you can copy and modify to suit your needs. If the new interface is of general interest or if you make a persuasive argument, we could probably add it to the FG code base.
If you have a specific need that doesn't easily fall within the existing interface structure, it's not all that hard to add your own custom interface. There are several examples (i.e. native_ctrls, native_fdm, native_gui, etc.) which you can copy and modify to suit your needs. If the new interface is of general interest or if you make a persuasive argument, we could probably add it to the FG code base.
I'd take a look at net_fdm.h and native_fdm.c.  The data structure received by FlightGear can easily be modified to include whichever parameters you'd like to control from your Matlab sim.  You just need to add code to set the appropriate FlightGear properties.
It doesn't make sense to modify the current version of FlightGear because different people have different requirements.  For instance, if you allow both control positions and surface deflections to be sent, how does the fdm know which one to use?  Furthermore, the native_fdm is designed to control actual rotation rates and velocities, so control positions don't factor into this.  It seems like you'd like a little bit of each, which to me means a custom modification.


We have discussed a more flexible (xml configurable) udp binary interface, but no work has commenced on that front.
We have discussed a more flexible (xml configurable) udp binary interface, but no work has commenced on that front.

Navigation menu