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
aircraft..
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
itself.
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:
http://www.gidenstam.org/FlightGear/misc/c172p-dual_fgfsCVS.tar.gz
(See http://www.gidenstam.org/FlightGear/misc/ for updates and some other
small projects.)
Observations/Comments:
- 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!
Cheers,
Anders
--
---------------------------------------------------------------------------
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
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
