GPS : passthrough mode to allow setup from PC configuration software

[Olivier-ADLER]

Add a passthrough mode to allow GPS setup from GPS PC configuration software through the APM USB port.

This will avoid using an FTDI cable + adapter for GPS setup or tests.

[owenson]

+1 for this.

[rmackay9]

yes, it is a good idea..

[owenson]

I don't mind taking this on - what do you think about having it activate similar to throttle passthrough. Maybe hold roll right, throttle high, power on apm to get GPS pass through?

[Olivier-ADLER]

I think that it would be safer to use a mavlink command to trig this. Anyway it's mandatory to use a PC to connect to the GPS.

So i think that the best would be to have a mavlink command inside Mission Planner to trig the passthrough mode, and then redirect the serial stream to a virtual com port so that the GPS stream can be accessed from this virtual com port inside U-blox U-center.

[monkeypants]

What if the GPS pass-through was tunnelled over MavLink in a relay fashion. i.e. instead of either being an autopilot or a tunnel, it could be both at the same time. What I mean is, the autopilot would decode UBX messages from telemetry and send them to the GPS, and encode messages from the GPS and send them over telemetry.

???

Chris Gough

On Wed, Aug 7, 2013 at 10:52 PM, Olivier-ADLER notifications@github.comwrote:

I think that it would be safer to use a mavlink command to trig this. Anyway it's mandatory to use a PC to connect to the GPS.

So i think that the best would be to have a mavlink command inside Mission Planner to trig the passthrough mode, and then redirect the serial stream to a virtual com port so that the GPS stream can be accessed from this virtual com port inside U-blox U-center.

— Reply to this email directly or view it on GitHubhttps://github.com/diydrones/ardupilot/issues/364#issuecomment-22248629 .

.

[owenson]

The problem is that we would need to write a driver to present a fake comport so other software can access the gps - thats quite a lot of work. The apm presents one comport which is used for mavlink .. so mavlink has to be turned off to allow gps passthrough - hence why I suggested with esc passthru because the apm will be inactive.

Best Gareth On 7 Aug 2013 14:04, "Chris Gough" notifications@github.com wrote:

What if the GPS pass-through was tunnelled over MavLink in a relay fashion. i.e. instead of either being an autopilot or a tunnel, it could be both at the same time. What I mean is, the autopilot would decode UBX messages from telemetry and send them to the GPS, and encode messages from the GPS and send them over telemetry.

???

Chris Gough

On Wed, Aug 7, 2013 at 10:52 PM, Olivier-ADLER notifications@github.comwrote:

I think that it would be safer to use a mavlink command to trig this. Anyway it's mandatory to use a PC to connect to the GPS.

So i think that the best would be to have a mavlink command inside Mission Planner to trig the passthrough mode, and then redirect the serial stream to a virtual com port so that the GPS stream can be accessed from this virtual com port inside U-blox U-center.

— Reply to this email directly or view it on GitHub< https://github.com/diydrones/ardupilot/issues/364#issuecomment-22248629> .

.

— Reply to this email directly or view it on GitHubhttps://github.com/diydrones/ardupilot/issues/364#issuecomment-22249244 .

[monkeypants]

The problem is that we would need to write a driver to present a fake

comport so other software can access the gps - thats quite a lot of work.

And I suppose it would have to be done for each supported operating system, and maintained when they change. OK I see your point.

The apm presents one comport which is used for mavlink .. so mavlink has to be turned off to allow gps passthrough - hence why I suggested with esc passthru because the apm will be inactive.

I understood that, but felt nervous about a switch that turned it into "not an autopilot" because it's a new failure mode. I realise there would be checks and balances, but...

The way Paparazzi does this is to have GPS passthrough mode as entirely different firmware, rather than some kind of behavior-changing switch. So I can't imagine a situation where accidentally changing it into not-an-autopilot would be dangerous, you can't accidentally flash new firmware during flight. That's why I suggested keeping it as a functioning autopilot while in GPS passthrough mode, it that were possible it would be even better.

Chris Gough

Best Gareth On 7 Aug 2013 14:04, "Chris Gough" notifications@github.com wrote:

What if the GPS pass-through was tunnelled over MavLink in a relay fashion. i.e. instead of either being an autopilot or a tunnel, it could be both at the same time. What I mean is, the autopilot would decode UBX messages from telemetry and send them to the GPS, and encode messages from the GPS and send them over telemetry.

???

Chris Gough

On Wed, Aug 7, 2013 at 10:52 PM, Olivier-ADLER notifications@github.comwrote:

I think that it would be safer to use a mavlink command to trig this. Anyway it's mandatory to use a PC to connect to the GPS.

So i think that the best would be to have a mavlink command inside Mission Planner to trig the passthrough mode, and then redirect the serial stream to a virtual com port so that the GPS stream can be accessed from this virtual com port inside U-blox U-center.

— Reply to this email directly or view it on GitHub< https://github.com/diydrones/ardupilot/issues/364#issuecomment-22248629>

.

.

— Reply to this email directly or view it on GitHub< https://github.com/diydrones/ardupilot/issues/364#issuecomment-22249244> .

— Reply to this email directly or view it on GitHubhttps://github.com/diydrones/ardupilot/issues/364#issuecomment-22253689 .

.

[owenson]

Hi Chris

Yes - it'd probably also need a new PPM firmware too to support the extra com port. Plus, it costs money to write drivers for 64bit Windows - you need them signed!

The APM wouldn't be able to switch into GPS pass-thru once it was powered up, in the same way it can't switch into ESC passthru. And given having the throttle high would switch into ESC pass thru anyway, adding the extra, AND ROLL RIGHT - there's no risk of triggering it by mistake - afterall, currently you'd enter esc pass thru if you did it now..

A new firmware is an option - and relatively easy to add - it's a pain though having to reflash - it takes several minutes.

Best Gareth

On 7 August 2013 15:26, Chris Gough notifications@github.com wrote:

The problem is that we would need to write a driver to present a fake

comport so other software can access the gps - thats quite a lot of work.

And I suppose it would have to be done for each supported operating system, and maintained when they change. OK I see your point.

The apm presents one comport which is used for mavlink .. so mavlink has to be turned off to allow gps passthrough - hence why I suggested with esc passthru because the apm will be inactive.

I understood that, but felt nervous about a switch that turned it into "not an autopilot" because it's a new failure mode. I realise there would be checks and balances, but...

The way Paparazzi does this is to have GPS passthrough mode as entirely different firmware, rather than some kind of behavior-changing switch. So I can't imagine a situation where accidentally changing it into not-an-autopilot would be dangerous, you can't accidentally flash new firmware during flight. That's why I suggested keeping it as a functioning autopilot while in GPS passthrough mode, it that were possible it would be even better.

Chris Gough

Best Gareth On 7 Aug 2013 14:04, "Chris Gough" notifications@github.com wrote:

What if the GPS pass-through was tunnelled over MavLink in a relay fashion. i.e. instead of either being an autopilot or a tunnel, it could be both at the same time. What I mean is, the autopilot would decode UBX messages from telemetry and send them to the GPS, and encode messages from the GPS and send them over telemetry.

???

Chris Gough

On Wed, Aug 7, 2013 at 10:52 PM, Olivier-ADLER < notifications@github.com>wrote:

I think that it would be safer to use a mavlink command to trig this. Anyway it's mandatory to use a PC to connect to the GPS.

So i think that the best would be to have a mavlink command inside Mission Planner to trig the passthrough mode, and then redirect the serial stream to a virtual com port so that the GPS stream can be accessed from this virtual com port inside U-blox U-center.

— Reply to this email directly or view it on GitHub<

https://github.com/diydrones/ardupilot/issues/364#issuecomment-22248629>

.

.

— Reply to this email directly or view it on GitHub< https://github.com/diydrones/ardupilot/issues/364#issuecomment-22249244>

.

— Reply to this email directly or view it on GitHub< https://github.com/diydrones/ardupilot/issues/364#issuecomment-22253689> .

.

— Reply to this email directly or view it on GitHubhttps://github.com/diydrones/ardupilot/issues/364#issuecomment-22254898 .

[Olivier-ADLER]

I don't think that we need to support something else than Windows 32 and 64, because anyway the U-blox Ucenter software is only available for Windows.

There are free virtual com port drivers for Win32, i'm not sure for Win64.

Olivier

[owenson]

Creating a virtual com port and tunnelling through mavlink are a significant effort. I can't really see that the advantages (which are minimal given gps pass thru is an infrequent activity) justify the effort?

Ten seconds resetting the apm and you have gps passthru .. once youre finished reboot and you're back to apm.

Best Gareth On 7 Aug 2013 21:10, "Olivier-ADLER" notifications@github.com wrote:

I don't think that we need to support something else than Windows 32 and 64, because anyway the U-blox Ucenter software is only available for Windows.

There are free virtual com port drivers for Win32, i'm not sure for Win64.

Olivier

— Reply to this email directly or view it on GitHubhttps://github.com/diydrones/ardupilot/issues/364#issuecomment-22280088 .

[Olivier-ADLER]

Yes mavlink tunneling is not necessary. Sending a command through mavlink to switch to GPS passthrough is enough.

Is it possible if Mavlink is bypassed to use the 3DR radio for raw serial ?

To make GPS tests and optimization, it's important to be able to use U-center during flight so that we can see the effect of different GPS settings.

Olivier

[owenson]

Olivier

In theory yes. Ill have to look at how easy it is to turn off mavlink whilst leaving apm to run.. perhaps Randy will know.

Best Gareth On 7 Aug 2013 21:33, "Olivier-ADLER" notifications@github.com wrote:

Yes mavlink tunneling is not necessary. Sending a command through mavlink to switch to GPS passthrough is enough.

Is it possible if Mavlink is bypassed to use the 3DR radio for raw serial ?

To make GPS tests and optimization, it's important to be able to use U-center during flight so that we can see the effect of different GPS settings.

Olivier

— Reply to this email directly or view it on GitHubhttps://github.com/diydrones/ardupilot/issues/364#issuecomment-22281628 .

[Olivier-ADLER]

I think it's not necessary to fully turn off mavlink, just avoid Mavlink packets to enter the 3DR radio sending buffer, and send instead the GPS packets.

There is no need for a virtual com port driver. Just close Mission Planner after switching to GPS serial mode, and open the GPS control software, configured with the 3DR radio as the serial port.

Olivier

[proficnc]

What about physically connecting the GPS to the 3DR radio and leaving the APM out of it. I assume the plan is still to look at interference/ jamming effects of FPV transmitters. If that is the case, then just leaving the TX line from the GPS connected to the APM while both are connected to the 3DR radios configured for 38400bps then connect the u-blox software to the 3DR virtual com. No need to write anything, and a functional autopilot to fly realistic tests.

[proficnc]

By both, I mean the TX and RX line of the GPS The 3dr radio would not be connected to the APM

[owenson]

I think there's several reasons for this feature:

• gps debug (my primary desire)
• gps tuning (olivier)
• gps config/update (most users)

So the primary aim is just to make it as easy as poss with the simplest code changes. On 7 Aug 2013 22:39, "proficnc" notifications@github.com wrote:

What about physically connecting the GPS to the 3DR radio and leaving the APM out of it. I assume the plan is still to look at interference/ jamming effects of FPV transmitters. If that is the case, then just leaving the TX line from the GPS connected to the APM while both are connected to the 3DR radios configured for 38400bps then connect the u-blox software to the 3DR virtual com. No need to write anything, and a functional autopilot to fly realistic tests.

— Reply to this email directly or view it on GitHubhttps://github.com/diydrones/ardupilot/issues/364#issuecomment-22286325 .

[owenson]

Olivier et al

Looks like it may be a real nuisance to allow flight at the same time as gps passthrough. The mavlink stuff is called by the scheduler and I can't see an easy/safe way to remove tasks.

How critical is it that you can fly as well as do gps passthrough? I imagine most people want this just to change config options on their gps / test it's working.

Best Gareth

[rmackay9]

This is done (for the APM2 only) and there's a wiki page showing how to do it: http://copter.ardupilot.com/wiki/common-ublox-gps/

[matthewlloyd]

Here's a trivial commit that adds functionality to ArduCopter (including Pixhawk / PX4) that lets you turn on GPS passthrough mode via the CLI. Connect to the CLI, run 'test gpspt', close the Mission Planner, run u-Center and connect using the same COM port and baud as the CLI. It's a direct bidirectional communication path. For now, you have to reboot to turn it off. I find this useful for configuring and testing the GPS (e.g. looking at the SVINFO message to see CN0 signal strength levels) without having to swap any DF13 cables.

https://github.com/matthewlloyd/ardupilot/commit/d73d23824af7ba2eb009c7dfe9f09049dad390ad

[rmackay9]

Matthew, That's a nice patch. One large problem we have at the moment is flash space for the APM2 so we've been planning to get rid of the CLI and instead do everything over mavlink. We could of course keep the CLI for just the Pixhawk but to keep things consistent I've been planning to get rid of it for all boards.

[jpkh]

Or we can always have simple sketch just for passtrough. That might be easiest for APM platform.

[matthewlloyd]

Thanks Randy, well it was mostly copy+paste as you can probably tell :) Yeah it's unfortunate the APM2 is so space constrained, as I was writing this I noticed that some CLI features I was using disappeared when I merged (the "gps" test mode).

My vote would be to keep the CLI around for platforms that have enough flash space for it, it's handy for debugging, and on Pixhawk/PX4 it's a convenient way to get access to nsh (though maybe you have another convenient way planned :)). I wonder too whether Mavlink versions of the existing CLI features will really take up much less flash space than the CLI versions. OTOH, having these features accessible GUI-style via the Mission Planner is appealing, if all the same information and features get exposed. Just my 2c.