Use Case scenario for Mavlink, Mission Planner, QGroundControl and Companion Computers

Good day. Here is a use case scenario for validation:

A companion computer has it’s own radio and connects directly to Mission Planner or QGroundcontrol. It is using a device id of 192. It sends its heartbeat as required. This is received, and even reflected in QGroundControl Mavlink analyzer. However, it seems because there is no flight controller, both GCS systems believe they are disconnected, and it appears impossible to access the companion controller configuration parameters. Once the flight controller becomes active, things work as expected.

Is this a valid scenario? Is there some reason this is unexpected? Obviously the aircraft cannot fly w/o an FCS. But during maintenance, sometimes it is powered down while configuring and checking other systems. I’m not exactly sure why it must be powered up in this scenario to access the configuration, so I’m confused by the behavior.

Any insights appreciated whether this use case should be supported or not. Thank you!

Nice thoughts, unfortunately I don’t know exactly the question.

I will be following this thread up in the hope someone can bring light to the discussion.

Thank you for taking a look and your reply. The basic question is whether a ground control system should support as much functionality as possible with connected and active components other than component id 190 (such as a companion or other system) even if the flight controller (compid 190) has become inactive?

More detail:

Both Mission Planner and qGroundControl have a concept of being connected. When they are not connected, they don’t permit certain functions, such as setting parameters on devices. This notion of connected seems dependent on the presence of a heartbeat from a flight controller (device 190).

This generally makes sense. However, it is possible for a more functional companion computer (i.e. with a device id 192) to make a full connection and begin transmitting heartbeat, parameters, and really any message, even posision. At least with qGroundControl, the presence of the the companion id heartbeat and messages are registered (seen through Mavlink Analyzer) but features such as parameter setting remain deactivated. So they cannot be managed until the flight controller comes online. In mission planner, the behavior is a little different, but effectively with the same result.

This seems unnecessary, and limits useful scenarios. But maybe there is a reason it must be like this. I’m not sure.

I think that the main trouble with this approach is the risk of being connected to more than one device at the same time,with the risk of GCS misleading behaviours, like switching to one or other device without any notice.

Interesting. Thank you very much for your reply. You may be correct, in that it is a user interface concern. Mission Planner makes this more explicit in the connection drop down. You have to specifically choose the companion device to connect to and it reconfigures, whereas qGroundControl just includes the parameters at the bottom of the flight controller list. I would imagine there is more room for confusion in the latter. Yet even MP blocks connections to the companion when the FCS is inactive.

Usually the flight controller is the hub. However, in this case the companion has the telemetry radio. It acts as an onboard router between the flight controller and the GCS. So it can be active and connected when the controller is not. Even so, it cannot be managed in either gcs until the flight controller comes online.

What do you think about the companion router sending compid=190 state=uninit messages to the gcs until the flight controller boots? I haven’t tried it, so I don’t even know if it would unlock the UI.

1 Like


Sorry… I’ve been away for quite a long time…

Have you made any progress on it?

Best Regards,
Bruno Bagarini

Good evening.

I’ve just been using with flight controller active for now.

I set up a development system and pulled on qgroundcontrol. Next step is to try to mod it to set a key, turn it on and off, auth incoming and sign outgoing.

it isn’t hard, but I’ve hesitated b/c I don’t yet know if this is useful. I’m surprised there is not more chatter about it.

Maybe a secure serial transcreiver is a better all around solution, as then there’s encryption too. And the fc wouldn’t have to waste cycles authing.

I speculate that is what serious solutions are doing, hence the silence? What do you think?