Companion needs to get system of its FC

[Michael Okincha]

Hi,

I'm creating a companion computer, one of which will be on each of several UAVs on the same MAVlink network.  Each CC is connected to the flight controller (Pixhawk) via a serial link, and the flight controller has the telemetry radio.  Obviously each UAV has its own system ID.

How can each CC reliably determine the system ID of the UAV/FC it's physically connected to?  I could listen for heartbeats and ready the the 'autopilot' field, but the CC might receive a heartbeat from some other UAV before receiving a heartbeat from it's own FC.

Is there a way to say "what is _my_ FC's system ID"?  I would really prefer no to have to hard-code the system ID into each CC.

Thanks!

[Hamish Willee]

Not as far as I know. 

I'm not sure how you could reliably automate allocation of system ids to components, except in a network where you know that there is only one system. 

So perhaps you might manage this with a process - putting the vehicle on its own network, getting the autopilot id, storing it, and using that in future.

Thinking a bit more, this is a more generic problem. The system ID might change, and you might have multiple components that also need to change, such as cameras, gimbals.

So more robustly, to solve the system id changing you need something like the firmware identity of the autopilot in this first phase  and all components then need to check this id and the autopilot system id, then remap their own system id.
(or the autopilot or some notional system manager needs to store the firmware id of all components, and we need to use something like https://mavlink.io/en/messages/development.html#MAV_CMD_DO_SET_SYS_CMP_ID to reset the ids when the "master system id" is changed.

I'll add to the MAV call next week for discussion. This has come up a few times, and generally I believe people are forced to hard code.

Regards

H

[Michael Okincha]

Understood.  One solution might be a way to query the device connected directly on a specific port.  E.g. a serial port is a dedicated link between two devices.  The equivalent of asking the person sitting next to you what their name is.  

Adding some additional special values to the `target_system` would be a simple mechanism.  Zero is already reserved for "broadcast".  I could see various message "scopes" or "ranges" being useful:

   * "all" - broadcast

   * "local/this vehicle" - only physical links, excluding wireless links

   * "N hops" - specifying the number of hops a message should be relayed/forwarded could also be useful.  Setting the max hop distance to one would be the equivalent of saying "this message only for immediate neighbors" on this link.  Naturally the hop would would be reduced by one each time the message is forwarded.

Mike

[Hamish Willee]

Thanks Mike

> One solution might be a way to query the device connected directly on a specific port.  E.g. a serial port is a dedicated link between two devices.  The equivalent of asking the person sitting next to you what their name is.

I didn't suggest this because it depends on the architecture of your vehicle (i.e. it could only work if the system knows that it has direct channels to the component, and that they don't have further channels to other parts of the network and route. From a MAVLink team member point of view I'm interested in generic solutions.

> Adding some additional special values to the `target_system` would be a simple mechanism.  Zero is already reserved for "broadcast".  I could see various message "scopes" or "ranges" being useful:

All of this is again architecture stuff that the components themselves can't know in advance, so you'd have to configure them anyway, which defeats the purpose.

--
Sie erhalten diese Nachricht, weil Sie in Google Groups ein Thema der Gruppe "MAVLink" abonniert haben.
Wenn Sie sich von diesem Thema abmelden möchten, rufen Sie https://groups.google.com/d/topic/mavlink/v_hPLRJLgdM/unsubscribe auf.
Wenn Sie sich von dieser Gruppe und allen Themen dieser Gruppe abmelden möchten, senden Sie eine E-Mail an mavlink+u...@googlegroups.com.
Wenn Sie diese Diskussion im Web verfolgen möchten, rufen Sie https://groups.google.com/d/msgid/mavlink/83d0818b-4732-4bd2-9b2e-a31789b8568cn%40googlegroups.com auf.

[Hamish Willee]

Hi Mike

We had a discussion about this in the dev call. I have to get the following sanity checked, but the thinking is ...

Every drone has a setup period where it is not connected to the network. In this environment there will only be one autopilot so you can get and latch the system id at this point.

So what components should do is something like on boot look for autopilot heartbeats. 

- If one and only one autopilot HEARTBEAT is found in say 5 seconds of boot they should latch its system id as their default system id.

- If multiple heartbeats are found they should keep their default system id.

- If the autopilot system ID is changed, the vehicle should be rebooted off network and the component will then re-latch. If it is not rebooted, or the id is changed after boot then the integrator will need to manually change ids.

This should work provided it is not possible for a component to be connected to other autopilots and not its own autopilot. I think that is a reasonable assumption.

Regards

Hamish