1,089
edits
Generic protocol: Difference between revisions
Jump to navigation
Jump to search
no edit summary
m (start and stop connection from Nasal console) |
No edit summary |
||
| Line 2: | Line 2: | ||
FlightGear supports multiple concurrent IO connections. | FlightGear supports multiple concurrent IO connections. | ||
You could use the FGNetFDM (--native) protocol or the --generic protocol (which allows you to design custom packets with the specific fields you choose.) Both of these can send the data out as UDP packets which then can be read by your external program using standard socket communication. | You could use the FGNetFDM (<code>--native</code>) protocol or the <code>--generic</code> protocol (which allows you to design custom packets with the specific fields you choose.) Both of these can send the data out as UDP packets which then can be read by your external program using standard socket communication. | ||
This same basic mechanism also would permit your external program to send control commands so if some day you want to do some sort of hardware or | This same basic mechanism also would permit your external program to send control commands so if some day you want to do some sort of hardware or software in the loop testing of your UAV controller, that is also a possibility. | ||
software in the loop testing of your | |||
There is a slightly complex, but pretty flexible mechanism for specifying an IO channel, what type of | There is a slightly complex, but pretty flexible mechanism for specifying an IO channel, what type of communication will get sent over it, which direction, and at what rate. Look for a file called README.IO that briefly explains much of this. | ||
In addition, there is a "generic" protocol where you can create an | In addition, there is a "generic" protocol where you can create an XML file specifying exactly what data values you wish to send across your IO channel. We don't have generic "USB" support, but if you have a Serial -> USB device that looks like a COM port on the computer side, then that should work without any problem ... just be careful which COM port your USB device gets assigned to. | ||
There is the native_fdm protocol to control FlightGear using an external FDM and there is the generic protocol that uses the XML configuration files. | There is the native_fdm protocol to control FlightGear using an external FDM and there is the generic protocol that uses the XML configuration files. | ||
| Line 15: | Line 14: | ||
The ''generic'' communication protocol for FlightGear provides a powerful way of adding a simple ASCII based or binary input/output protocol, just by defining an XML encoded configuration file and placing it in the [[$FG ROOT]]/Protocol/ directory. | The ''generic'' communication protocol for FlightGear provides a powerful way of adding a simple ASCII based or binary input/output protocol, just by defining an XML encoded configuration file and placing it in the [[$FG ROOT]]/Protocol/ directory. | ||
The generic protocol can be easily set up for both input and output. And it supports not just a single medium, but can be easily made to use files, FIFOs, sockets etc. The generic protocol is really good for things like exporting to a delimited | The generic protocol can be easily set up for both input and output. And it supports not just a single medium, but can be easily made to use files, FIFOs, sockets etc. The generic protocol is really good for things like exporting to a delimited ASCII file for import into spreadsheet for instance. | ||
I think it makes sense (when dealing with live data) for the generic protocol to enter a while loop and read data until there is no more available. That way if the sender is sending at a higher rate or FlightGear gets behind for any reason, FlightGear will get caught up each iteration. This obviously does not work well for file input though, so you'd have to differentiate. | I think it makes sense (when dealing with live data) for the generic protocol to enter a while loop and read data until there is no more available. That way if the sender is sending at a higher rate or FlightGear gets behind for any reason, FlightGear will get caught up each iteration. This obviously does not work well for file input though, so you'd have to differentiate. | ||
| Line 252: | Line 251: | ||
same device twice, so you two command line options won't work either. As | same device twice, so you two command line options won't work either. As | ||
far as I can tell this will require some code modifications if you want to | far as I can tell this will require some code modifications if you want to | ||
use direct serial | use direct serial communication. | ||
Another option might be to write a thin glue layer that talks to FlightGear | Another option might be to write a thin glue layer that talks to FlightGear | ||