Ground station gets no indication if secondary GPS has been unloaded at the driver level

[WickedShell]

If you operate a multiple GPS setup and for some reason the driver on the secondary GPS was unloaded (ie due to being unplugged or losing power) the ground station doesn't have any indication that the second GPS is no longer valid. We stop sending GPS2_RAW packets, which could be considered the indication (but that approach has it's own problem), but it leaves GCS's like Mission Planner showing the last data for GPS2 (which can look valid such as 17 satellites etc) but in reality there is no GPS2 anymore and this can be confusing.

A couple of solutions come to mind:
1 - Leave it as is, this is actually the behaviour people would rather see.
2 - If no GPS2 is loaded then send 0's for lat/lon/alt/sat count/groundspeed etc (and 99.99 for HDOP)
3 - Add a mavlink field to report the age since the last GPS position message came in, which would let the GCS get a better idea if the data is stale.

I'm leaning towards option 2, but I'm open to other suggestions.

[magicrub]

Option 2 sounds best to me
On Aug 13, 2015 2:52 AM, "WickedShell" notifications@github.com wrote:

If you operate a multiple GPS setup and for some reason the driver on the
secondary GPS was unloaded (ie due to being unplugged or losing power) the
ground station doesn't have any indication that the second GPS is no longer
valid. We stop sending GPS2_RAW packets, which could be considered the
indication (but that approach has it's own problem), but it leaves GCS's
like Mission Planner showing the last data for GPS2 (which can look valid
such as 17 satellites etc) but in reality there is no GPS2 anymore and this
can be confusing.

A couple of solutions come to mind:
1 - Leave it as is, this is actually the behaviour people would rather see.
2 - If no GPS2 is loaded then send 0's for lat/lon/alt/sat
count/groundspeed etc (and 99.99 for HDOP)
3 - Add a mavlink field to report the age since the last GPS position
message came in, which would let the GCS get a better idea if the data is
stale.

I'm leaning towards option 2, but I'm open to other suggestions.

—
Reply to this email directly or view it on GitHub
#2697.

[rmackay9]

Constantly sending messages for a GPS that doesn't exist .. would we do that only if a GPS was lost or would we always send values even for GPS that had never been attached? I.e. GPS2 isn't set up for most vehicles, would we always send GPS2 messages? I suspect (and hope) not.
I think sending one final messages if a GPS disappears makes sense although the problem is we don't have guaranteed delivery so it might be lost.

[magicrub]

This is a rare event of a hardware failure and in the case that it does
happen I'd rather there be too much logged than not enough.

On Thu, Aug 13, 2015 at 12:55 PM, Randy Mackay notifications@github.com
wrote:

Constantly sending messages for a GPS that doesn't exist sounds .. would
we do that only if a GPS was lost or would we always send values even for
GPS that had never been attached? I.e. GPS2 isn't set up for most vehicles,
would we always send GPS2 messages? I suspect (and hope) not.
I think sending one final messages if a GPS disappears makes sense
although the problem is we don't have guaranteed delivery so it might be
lost.

—
Reply to this email directly or view it on GitHub
#2697 (comment)
.

[rmackay9]

ok, yes, that makes sense. .. and so it should appear in the dataflash as well.
https://github.com/diydrones/ardupilot/blob/master/ArduCopter/Log.cpp#L648

[WickedShell]

This is why I haven't just sent in a PR for it. I'm not fully convinced it's the best approach.

I think with proposed second solution it makes sense to look up if the second GPS is configured (IE do you have a second serial port configured to provide a potential GPS2? If not then don't sent the mavlink message for GPS2_RAW. It would mean most users don't see an increase of bandwidth, and addresses the issue here.

[Naterater]

This one appears important to me and hasn't had attention in a while. Is it still an issue @WickedShell?

[WickedShell]

Yes.

[kangs-sysense]

@WickedShell, your thought from 2015 Aug 13 would seem to be a good solution.

If there is a concern about sending out too much data (ie sucking up bandwidth), would a time-out feature be possible? For example, given the update rate for the second GPS, only send 0's for 10 of those update periods. If the telemetry is so bad that it misses 10 updates, then I would submit it's more likely that the specific set up has other issues. :-) It could be an adjustable parameter.

BUT, there's an argument to be made for the ground control software to deal with it.

I guess the missing component is that ArduPilot isn't informing the GCS that the second GPS has gone away. Not sure if it's worth creating a whole new mavlink message to deal with it though. This is where things start feeling like that proverbial can of worms.