On Sat, 10 Nov 2007, Vivian Meazza wrote:

> Anders is hard at work extending this into a co-pilot facility - watch this
> space. Meanwhile - if you are on MP we're aboard and watching you :-).

In case that made you curious, I can provide a preview since my 
prototype has now reached a somewhat useable state.
Pilot and copilot currently have shared control over aileron, elevator, 
rudder, throttle, mixture, elevator trim, flaps and brakes. The copilot
has a limited subset of the instrumentation.

The system consists of two "aircraft":
- The pilot uses a modified variant of the c172p from FlightGear/CVS.
   The pilot need to specify the callsign of the copilot (other copilots
   will be ignored). Note: if your designated copilot uses another aircraft
   than c172p-copilot some of his/her control input will still affect your

   Usage example:
    fgfs --aircraft=c172p-pilot --prop:/sim/remote/pilot-callsign="copilot"

- The copilot uses a special "aircraft" c172p-copilot which
   piggybacks on the designated pilot and captures the local control
   inputs. A current limitation is that only the cockpit view (ctrl-v)
   is jitter free. There is also a noticable delay between control inputs
   and effect, since they are passed via the the multiplayer protocol.
   The severity of this delay depend on round trip time and some other
   factors - the delay seems significantly longer than the round trip time
   Since being part of a control loop most likely wasn't in the
   design spec. for the multiplayer protocol I think we can improve this.
   E.g. by allowing the pilot side to bypass the deliberate
   delay/interpolation of control inputs from the copilot.
   That said, I have flown successfully as copilot in a setup with
   100-120ms round trip time between both pilot and server and copilot and
   server (total delay >500ms). Landing is a bit exciting in that
   case, though.
   The deliberate delay added by AIMultiplayer can be significant - I have
   seen (rare) >5 sec delays on my LAN - I think some unfortunate
   interaction during the startup of the pilot and copilot fgfs instances
   messed up the AIMultiplayer lag tuning.

   Usage example:
    fgfs --aircraft=c172p-copilot --prop:/sim/remote/pilot-callsign="pilot"

The prototype is available here:


(See http://www.gidenstam.org/FlightGear/misc/ for updates and some other 
small projects.)


- In FlightGear/plib the fixed nearplane setting of 10ft cuts away most of
   the aircraft for the copilot.

- The AIMultiplayer processing of incoming MP data adds a deliberate delay
   which sometimes seems to become excessive (> 5 sec on a LAN?).
   I know some extra delay is needed to make animation of MP aircraft
   smooth and avoid extrapolation, but it would be nice to be able to
   reduce or disable it for the control inputs from the copilot. A property
   below multiplayer[x]/controls/ in the AI/MP subtree to control this
   would be nice.

- In the long run I think we'd want the MP system to support something
   similar to publish/subscribe - e.g. the properties sent from the copilot
   is only interesting for the pilot and the extended aircraft state
   sent(/published) by the pilot aircraft is only interesting to the
   copilot or anyone else riding in the cockpit.
   Currently everybody in the neighbourhood receives the data.

Have fun piloting!


Anders Gidenstam
mail: anders(at)gidenstam.org
WWW: http://www.gidenstam.org/FlightGear/JSBSim-LTA/

This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
Flightgear-devel mailing list

Reply via email to