MAVLINK Comms Behavior and Connection setup to GCS

[Bart Hodlik]

Good morning everyone,

In developing a data pipeline for a project, I was configuring the pipeline to handle UDP connections coming out of SITL.

But I found that I wasn't receiving all parameters when using MP or QCS. Nor was I able to set up bi-directional control using UDP. 

In reading the documentation for MAVLINK, I came across this:

MAVLink is built for hybrid networks where...... but are mixed with transfers requiring guaranteed delivery. The key insight is that for most telemetry streams there is not a known or single recipient: Instead, typically an onboard computer, a ground control station and a cloud system all need the same data stream.

On the other hand configuring the onboard mission or changing the system configuration with onboard parameters requires point-to-point communication with guaranteed delivery.....

Am I to understand that there is a dual link occurring? So if I use MP and connect via UDP then I lose out on the point to point control? Or am I mixing up the understanding between application layer multicast and link layer multicast?

In QCS, I set up my link for UDP, but do I need an additional TCP connection to handle control?

Just trying to get this straight so I can work the data flow better. 

[Hamish Willee]

Hi

>  Am I to understand that there is a dual link occurring? So if I use MP and connect via UDP then I lose out on the point to point control? Or am I mixing up the understanding between application layer multicast and link layer multicast? 

No :-). 

The above is a complicated way of saying that MAVLink caters for both broadcast (fire and forget) and guaranteed delivery of message. Most telemetry messages, for example, are broadcast (sent to everyone) and there is no resending, because they are streamed - ie. if you miss one it doesn't matter, because and updated value is coming soon. By contrast a command to do something needs to go to a specific recipient, and that recipient needs to acknowledge the command, so that the sender knows it was received (and if not resend the command).

Broadcast is what happens by default. The addition of resending is done at a higher (microservice layer). I.e. it is not part of the transport at all. There is a convention that if a message is only intended for a recipient then it will name variables in the payload for target_system and target_component and these will be routed to a particular component, and only that component will handle the message - see  https://mavlink.io/en/guide/routing.html

All packets are sent the same way using the same the packet format. In a microservice - e.g. command protocol https://mavlink.io/en/services/command.html defines that messages are sent in a particular order and whether resending is required. 

For your specific case, you should be receiving all parameters if your system uses the parameter protocol properly: https://mavlink.io/en/services/parameter.html

Regards

Hamish

[Bart Hodlik]

Got it. Ok thank you for clarifying that. I wasnt sure if it meant that Tcp was involved or if sysid was being used for the guaranteed delivery.

Makes a lot more sense now. 

This will help me keep my nifi pipe much simpler. 

Thanks

--
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/qv_kgJtiMP4/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/cecca869-6f34-486c-8e91-42973e864efcn%40googlegroups.com auf.