How to handle stream rates

DonLakeFlyer commented 4 weeks ago

Related to discussion in #11696...

So the current state of affairs as I understand it:

PX4 firmware automatically sets up a number of telemetry streams to ground station. A GCS does not have to request individual telemetry values. QGC does nothing special with respect to telemetry streams and PX4.
ArduPilot mostly does the same thing except for Copter. Because of this QGC requests the streams an initial vehicle connect. It does not request individual telemetry values. It requests by stream type. The user has the ability to set the rate on each stream type.
For ArduPilot QGC has an option to not do this such that the vehicle side controls the telemetry sent to GCS. This option is off by default in order to prevent users from being confused by a default copter setup not working with QGC. The user would first have to set various copter params and then turn off QGC control of streams.

There has been discussion that a ground station should be in control asking for the telemetry it needs in order to run and that would be a better solution to this whole thing. I tend to disagree with that. The reason being that there is more to telemetry than the absolute minimum to run a decent GCS. This is also the fact that there is a pile of telemetry information that a GCS doesn't need to run, but that and end user might need to be able to say debug a problem with the vehicle. You tend to only know that after the fact. Or in other words by the time you may realize you need to turn on some more telemetry to diagnose it's already too late and the problem has gone by.

To me having a vehicle send a good default set of telemetry makes the whole system more user friendly out of the box. There is also the issue that some telemetry may only be available if various hardware or settings are added to or turned on in the vehicle. To me the vehicle should mainly be in control of this stuff by default. Sure the user can override/tweak but that should not be required by default.

Looking for feedback on telemetry usage so we can come up with a good solution that works for everyone.

DonLakeFlyer commented 4 weeks ago

@HTRamsey, @julianoes, @Davidsastresas, @rmackay9 fyi...

DonLakeFlyer commented 4 weeks ago

Can somebody detail how Mission Planner deals with all of this?

HTRamsey commented 4 weeks ago

Maybe a simple start would be to just request stream rates for Copter until AP makes it similar to the others?

julianoes commented 3 weeks ago

There has been discussion that a ground station should be in control asking for the telemetry it needs in order to run and that would be a better solution to this whole thing.

I think the Copter way is the right way, and a ground station should request what it needs. The whole default set is a lazy hack, in my opinion.

There is even an issue in PX4 to change this, I suspect it's just that no one ever bothered to actually do the changes.

The one argument for the default set would only really be bandwidth limitations which the drone is potentially more aware of (e.g. due to the baudrate) although QGC could still request a few messages at a good enough rate and PX4 can scale it all down if it doesn't fit within the 57600 radio bandwidth.

DonLakeFlyer commented 3 weeks ago

I think the Copter way is the right way, and a ground station should request what it needs. The whole default set is a lazy hack, in my opinion.

What part of how Copter works exactly? And can you explain why you think it is the way to go? I want to understand this. I looked at the PX4 Issue you linked to and that discussion seems related to limited bandwidth across SiK Radios. Is that really an important scenario any more?

DonLakeFlyer commented 3 weeks ago

@rmackay9 Any insights on the history of ArduPilot with respect to this? Why have other vehicle types moved to in initiating streams from the vehicle side of things?

DonLakeFlyer commented 3 weeks ago

On of my arguments for the vehicle side setting up a default set of streams is that it becomes a sort of mini-log on the ground station side. That way all that information is in telemetry logs which can then be replayed for debugging purposes. Let me know if that's just off base. It also way easier to see what's coming across the telemetry link from mavlink if it's already there. Instead of having to poke your way through the mavlink spec to figure out what you want. That can end up being clear as mud. For example MAVLINK_MSG_ID_ADSB_VEHICLE. Is that something you have to specifically ask for or not? In reality it isn't (I think I have that right), it automatically gets sent to the ground station when the vehicle has ADSB support.

julianoes commented 3 weeks ago

I don't know how/if Copter works. I'm just thinking it doesn't make sense to send all sorts of debug data when all the GCS wants to do is to show location, battery, HUD, etc.. To me it should be the client that asks for data and not the sender that blasts out stuff.

Davidsastresas commented 3 weeks ago

I think what Julian said makes sense. Maybe we could implement those message that request individual messages instead of stream rates ( groups of messages ). This way we could target exactly the messages we are interested in for QGC and no more. Also, I think this could have the benefit of working the same for both AP and PX4.

I think going over handlemessage in vehicle, as well as firmware plugins and vehicle factgroups should give us the messages we would need to request individually. About rate, we could leave something as default and leave the setting exposed in mavlink submenu.

I think I could take care of this within the next few weeks for master if everybody else is fine with this approach. Thanks!

mavlink / qgroundcontrol

How to handle stream rates #11773