Separate XPlane sensor and GCS roles

[GoogleCodeExporter]

Feature that you'd like us to add or change you'd like us to make:
The current XPlane "GCS" currently fills two roles: an interface with XPlane to 
supply sensor inputs and accept movement commands, and a standard set of GCS 
functions like send_message, print_control_mode, etc.  There is no reason these 
two purposes need to be combined.  In fact, debugging/testing/using a GCS would 
be greatly aided by the ability to enable the XPlane sensor/control interface 
while using a non-"XPlane" GCS.

I suggest adding a constant like XPLANE_INTERFACE and setting to ENABLED or 
DISABLED, and change most of the tests for GCS_PROTOCOL == GCS_PROTOCOL_XPLANE 
to XPLANE_INTERFACE == ENABLED.  GCS_Xplane.pde could either be split into two 
files or, more simply, scoot pipe() below print_buffer() and put the #if 
GCS_PROTOCOL == GCS_PROTOCOL_XPLANE check in between these two functions.

These suggested code changes took me about 5 minutes; it would be very nice to 
not have to re-approve my changes every time I merge with a new public revision.

Original issue reported on code.google.com by bjpcalt...@gmail.com on 28 Sep 2010 at 10:53

[GoogleCodeExporter]

This is probably better done with a modular interface for the IMU, so that the 
Xplane information can be presented as a peer to the output from the regular 
IMU.

Original comment by DrZip...@gmail.com on 29 Sep 2010 at 5:22

• Added labels: Milestone-Later, Priority-Medium, Type-Enhancement

[GoogleCodeExporter]

That's probably the best way to do things in the future, but can we implement 
my five-minute change for now so that people can have access to this feature in 
the beta?

Original comment by bjpcalt...@gmail.com on 29 Sep 2010 at 5:28

[GoogleCodeExporter]

I made an update. It took more than 5 minutes, BTW. Code had to be updated in 
15 places, configs updated, new defaults made, etc. Debugging and verification 
might take an hour. Would you be able to verify and submit a patch if you find 
adverse behavior? Also would you be able to send updated text for the user 
manual on the Wiki?
Thanks,
Jason

Original comment by jasonshort on 29 Sep 2010 at 10:21

[GoogleCodeExporter]

Original comment by jasonshort on 29 Sep 2010 at 10:21

• Changed state: Fixed

[GoogleCodeExporter]

I'll verify that r957 works like my local version (allowing simultaneous use of 
XPlane interface and an alternate GCS); my test bench setup for this purpose 
consists of an APM/shield + FTDI converter connected to the telemetry pins on 
the shield (2 COM ports) using a slightly modified version of Obourne 
ArdupilotSim and a simple terminal program to communicate with my GCS protocol.

I'd be happy to write some updated Wiki text for using Xplane after these 
changes; the current text is already out of date with the change to the APM_GPS 
library where GPS selection is performed through GPS_PROTOCOL.  How and to whom 
should I deliver it? (I don't have commit privileges)  Do you happen to know 
where people could find the binaries for the file previously found at
http://vps.oborne.me/ardupilotsim.zip
...I know the source code can be found in a subdirectory of
http://ardupilot.googlecode.com/svn/branches/ArduPilot_2_7/X-Plane/
(perhaps we should add a svn:externals link to this directory from the 
ardupilot-mega project?)

Original comment by bjpcalt...@gmail.com on 29 Sep 2010 at 10:54

[GoogleCodeExporter]

The Ardupilot sim code has been implemented into the APM Planner code. so no 
need for the externals link.

Original comment by Meee...@gmail.com on 29 Sep 2010 at 11:37

[GoogleCodeExporter]

After integrating your changes into my version of the code, my GCS worked 
simultaneously with the HIL interface.

Two changes, neither of which actually change functionality:
 * APM_Config.h.example specifies that ENABLE_HIL is ENABLED by default, but it is (prudently) DISABLED by default.
 * The void pipe() function currently declared in HIL_output.pde should probably belong in GCS_Xplane.pde, although it isn't actually used in either place currently.

Here's how I would change step 1 in Xplane.wiki:
--------------
*1)* Add settings to your custom configuration file:

First, let the APM know that it will be receiving location and IMU information 
via the HIL (hardware in [the] loop) IMU protocol:
{{{
#define GPS_PROTOCOL        GPS_PROTOCOL_IMU
}}}

Second, tell the APM to send servo control commands and other information via 
HIL protocol over Serial0:
{{{
#define ENABLE_HIL          ENABLED
}}}

Third, select your desired ground control station protocol; for instance, the 
Standard GCS.  The GCS does not have to be GCS_PROTOCOL_XPLANE:
{{{
#define GCS_PROTOCOL            GCS_PROTOCOL_STANDARD
// GCS_PROTOCOL_NONE        No GCS output
// GCS_PROTOCOL_STANDARD    standard APM protocol
// GCS_PROTOCOL_SPECIAL     special test protocol (?)
// GCS_PROTOCOL_LEGACY      legacy ArduPilot protocol
// GCS_PROTOCOL_XPLANE      HIL simulation ground station
// GCS_PROTOCOL_IMU         ArdiPilot IMU output
// GCS_PROTOCOL_JASON       Jason's special secret GCS protocol
}}}

Fourth, select the serial port on which you want your GCS to operate; it is 
recommended to usually avoid choosing 0 as this is the same port that the IMU 
information will be transmitted on.  A good choice is 3, which is the telemetry 
port (TelemPort) on the IMU shield:
{{{
#define GCS_PORT            3
}}}

Original comment by bjpcalt...@gmail.com on 29 Sep 2010 at 11:39

[GoogleCodeExporter]

Ah, thanks Michael -- in that case, the broken vps.obourne.me link should be 
replaced with
http://code.google.com/p/ardupilot-mega/source/browse/Tools/trunk/ArdupilotMegaP
lanner/bin/Release/

Original comment by bjpcalt...@gmail.com on 29 Sep 2010 at 11:42