AP_GPS: Suppress unnecessary telemetry transmission #28221
Conversation
libraries/AP_GPS/AP_GPS.cpp
Outdated
| @@ -1369,6 +1369,10 @@ uint16_t AP_GPS::gps_yaw_cdeg(uint8_t instance) const | |||
|
|
|||
| void AP_GPS::send_mavlink_gps_raw(mavlink_channel_t chan) | |||
| { | |||
| if (params[0].type == GPS_TYPE_NONE || drivers[0] == nullptr) { | |||
There was a problem hiding this comment.
We continue to send this message to "clear" the GCS's concept of what the GPS data is. So it might stop displaying a position on a map or something.
That's my recollection, anyway.
OK, I looked it up: e995a19
This behaviour is on purpose.
I think this might be reasonable:
| if (params[0].type == GPS_TYPE_NONE || drivers[0] == nullptr) { | |
| if (params[0].type == GPS_TYPE_NONE) { |
There was a problem hiding this comment.
I agree with the comment.
libraries/AP_GPS/AP_GPS.cpp
Outdated
| @@ -1405,7 +1409,7 @@ void AP_GPS::send_mavlink_gps_raw(mavlink_channel_t chan) | |||
| void AP_GPS::send_mavlink_gps2_raw(mavlink_channel_t chan) | |||
| { | |||
| // always send the message if 2nd GPS is configured | |||
| if (params[1].type == GPS_TYPE_NONE) { | |||
| if (params[1].type == GPS_TYPE_NONE || drivers[1] == nullptr) { | |||
There was a problem hiding this comment.
| if (params[1].type == GPS_TYPE_NONE || drivers[1] == nullptr) { | |
| if (params[1].type == GPS_TYPE_NONE) { |
per referenced PR, this is on purpose
muramura
force-pushed
the
AP_Suppress_unnecessary_telemetry_transmission
branch
2 times, most recently
from
fb3dcbe
to
6175b63
Compare
|
|
|
This PR now makes sending of gps-0 and gps-1 symmetric, which is nice. Taking this to DevCall. |
|
... oh, implications are that if you set you GPS type to zero then you will no longer get messages at all, so your position will freeze at the last message, rather than starting to receive empty messages. |
|
@peterbarker san. I think there is no point in sending this message if FIX_TYPE is less than or equal to GPS_FIX_TYPE_NO_FIX (1). |
muramura
force-pushed
the
AP_Suppress_unnecessary_telemetry_transmission
branch
2 times, most recently
from
c71522a
to
0ce307c
Compare
|
we need to check the impact of this change on MissionPlanner, mavproxy, plot.ardupilot.org and MAVExplorer |
|
Will the tools fall over if the GPS_RAW message is not present? |
|
what happens if GPS1_TYPE=0 and GPS2_TYPE != 0 with MissionPlanner? |
|
Ping @muramura can you test the tooling, please? |
|
Mission Planner uses the data from GLOBAL_POSITION_INT messages for displaying vehicle location, if no GLOBAL_POSITION_INT messages are received at all or it contains zero lat/lng then it uses GPS_RAW_INT for location data. GPS2_RAW messages are not used to display location. |
muramura
force-pushed
the
AP_Suppress_unnecessary_telemetry_transmission
branch
from
0ce307c
to
ddd6e62
Compare
|
@peterbarker san MISSION PLANNER recognizes GPS2. 
|
|
@muramura Indeed, however it wont use it for displaying position on the map. As described above. |
|
@EosBandi san The position of GPS2 is reflected in the location data of GLOBAL_POSITION_INT. 
|
|
@muramura san, you are right and this is a feat of ArduPilot. |
muramura
force-pushed
the
AP_Suppress_unnecessary_telemetry_transmission
branch
from
ddd6e62
to
2b4cc13
Compare
|
APM PLANNER2 is OK.
|
If data cannot be obtained from the GPS device, telemetry transmission should be suppressed.
The GCS can detect a device malfunction if it is unable to receive telemetry from the GPS.
Since the GCS on the transmitter has a narrow bandwidth, refraining from sending meaningless telemetry data allows the bandwidth to be allocated to other telemetry.
AFTER
BEFORE
