20,741
edits
Telnet usage: Difference between revisions
Jump to navigation
Jump to search
m
no edit summary
mNo edit summary |
mNo edit summary |
||
| Line 7: | Line 7: | ||
Many things (view parameters, weather, time of day, etc.) are configurable via the property system. For things like weather and view selection which don't change rapidly, you can send over new property values using the "telnet" interface. For things that could change rapidly (like view position/orientation) you probably want to blast over udp packets at 60hz or whatever your screen refresh rate. | Many things (view parameters, weather, time of day, etc.) are configurable via the property system. For things like weather and view selection which don't change rapidly, you can send over new property values using the "telnet" interface. For things that could change rapidly (like view position/orientation) you probably want to blast over udp packets at 60hz or whatever your screen refresh rate. | ||
The autopilotss (there are several different implementations) are part of the models. (Rationale is that autopilot devices normally are mounted *in* the | |||
aircrafts in the real world =). If you are developing your own stand-alone autopilot and want it on another host, there are several ways to interface | |||
to the simulator to control the aircraft remotely. | |||
Everything you need to read and set to control an aircraft is in the aircraft's property tree. (This is how the aircraft is controlled internally too) This property tree can be read and modified (if the property is not a read-only one) across the network. | |||
The simplest way to /set/ a property is perhaps via the telnet interface. fgfs --telnet=<port> then do "telnet <host> <port>" and type "help" to see | |||
the syntax. You can read properties aswell, that way, but perhaps you rather prefer to get data synchronously. This can be achieved through the | |||
general i/o-interface. | |||
Regarding the autopilot, I believe you have to set the target speed value and then activate that particular autopilot mode, so you need to actually set two values. You should be able to look in the autopilot gui to see the exact property names (I don't have them here off the top of my head.) And watch out for spelling: that's one thing I've learned to check when things don't work as expected. With properties, the compiler can't spell check variable names at compile time so typos can creep in. When something doesn't behave as expected, it's worth looking in the property tree while the code is running to see if any new properties (with similar, but not quite exact spellings) have appeared. | Regarding the autopilot, I believe you have to set the target speed value and then activate that particular autopilot mode, so you need to actually set two values. You should be able to look in the autopilot gui to see the exact property names (I don't have them here off the top of my head.) And watch out for spelling: that's one thing I've learned to check when things don't work as expected. With properties, the compiler can't spell check variable names at compile time so typos can creep in. When something doesn't behave as expected, it's worth looking in the property tree while the code is running to see if any new properties (with similar, but not quite exact spellings) have appeared. | ||
At a lower level, the FlightGear waypoint system (route manager) can handle any arbitrary latitude and longitude and altitude. However, something that might work better for you (?) would be to just set up a basic autopilot that can hold a commanded heading, altitude, speed, etc. and then monitor the flight location from the remote search algorithm and pass heading updates to the autopilot. | |||
The autopilot target values are all stored in the property system, so it's really straightforward to change them from a remote application using the | |||
"telnet" interface. And likewise you could monitor aircraft location through the same interface. | |||
There are commands available for clearing the list, removing entries, etc. | |||
<pre> | |||
@clear ... clear route | |||
@pop ... remove first entry | |||
@delete3 ... delete 4th entry | |||
@insert2:k...@900 ... insert "k...@900" as 3rd entry | |||
k...@900 ... append "k...@900" | |||
</pre> | |||
For example '''set /autopilot/route-manager/input @clear''' | |||
This works also from the property browser, or via Nasal etc. The route manager dialog uses the same interface. | |||
Of course, you have to use an autopilot which takes the waypoints from the route manager if you want your aircraft flown through all the points. The default AP does this. | |||
Everything that you can do in the "Route-Manager" dialog can be done via any way to write to properties. The dialog itself does exactly that. There's a command property /autopilot/route-manager/input. You can send commands to add/insert/remove/pop waypoints from the list, which you can see in the dialog. Here's the syntax description from $FG_ROOT/gui/dialogs/route-mgr.xml and src/Autopilot/route_mgr.cxx: | |||
command interface /autopilot/route-manager/input: | |||
<pre> | |||
@clear ... clear route | |||
@pop ... remove first entry | |||
@delete3 ... delete 4th entry | |||
@insert2:[EMAIL PROTECTED] ... insert "[EMAIL PROTECTED]" as 3rd entry | |||
[EMAIL PROTECTED] ... append "[EMAIL PROTECTED]" | |||
</pre> | |||
The telnet server can be activated with the <code>--telnet=port</code> [[Command Line Parameters|command line option]], where port is the number of the listening port that will be opened locally by the FlightGear fgfs process (note that the --props parameter is equivalent). | The telnet server can be activated with the <code>--telnet=port</code> [[Command Line Parameters|command line option]], where port is the number of the listening port that will be opened locally by the FlightGear fgfs process (note that the --props parameter is equivalent). | ||