core: more than one vehicle on one UDP port

[julianoes]

This adds support to command multiple drones that connect e.g. on the UDP port 14540.

[JonasVautherin]

Is it right that:

1. We maintain one UDP connection to each drone (with heartbeat etc).
2. All the connected drones receive all the messages sent by the client (i.e. as a client, I cannot send a message to only one specific drone).
3. Each message is sent independently (i.e. we are not using multicast).

And why is it limited to UDP connections?

[julianoes]

1. We maintain one UDP connection to each drone (with heartbeat etc).

We can, but we don't have to. You can also have multiple drones sending to the same UDP port but from different remote ports.

2. All the connected drones receive all the messages sent by the client (i.e. as a client, I cannot send a message to only one specific drone).

For now, yes. @bkueng was voting not to do that because it might cause problems (depending on how the autopilot handles it) but in theory messages with target system IDs should just fall off the autopilot if they don't match.
If this turns out to be a problem, we could move to a map from system ID to remote port.

3. Each message is sent independently (i.e. we are not using multicast).

Right 🤔.

And why is it limited to UDP connections?

For TCP, as far as I know, you have to have one listen port per drone, so per connection.

[JonasVautherin]

We can, but we don't have to. You can also have multiple drones sending to the same UDP port but from different remote ports.

Right. But I mean we still receive all the heartbeats of all the drones, don't we?

My concern is that this may not scale for a swarm (does it really work to receive the heartbeats from 50 drones, and send each message to all of them everytime?).

So is this here to support only "a few drones" (like 3-5)? Because in this case, why not doing it at the higher level, using multiple instances of the SDK (which would work for TCP, too)?

[julianoes]

My concern is that this may not scale for a swarm (does it really work to receive the heartbeats from 50 drones, and send each message to all of them everytime?).

Maybe? 😄 yes, maybe we need to implement directing the messages and a configuration option to disable it.

So is this here to support only "a few drones" (like 3-5)? Because in this case, why not doing it at the higher level, using multiple instances of the SDK (which would work for TCP, too)?

The idea here was that you can provide one UDP port and the different drones don't need to know that they have each another SDK instance listening for them but they can all send their mavlink stuff to a default port and will be heard.

[JonasVautherin]

The idea here was that you can provide one UDP port and the different drones don't need to know that they have each another SDK instance listening for them but they can all send their mavlink stuff to a default port and will be heard.

The drones never know the implementation detail, do they? Be it one SDK instance or multiple ones. In the end, there is a discovery mechanism (the drones broadcast on 14540), and then there is a point-to-point connection between the GS and the drone (the GS is connected to ip:port pairs). In our case we kind of mix the discovery with the pairing, but both exist.

I am saying that because I see two different applications:

• Multi-drone control: e.g. I want to map a big area and I want to fly 3 drones at the same time. In that case, I can fire 3 instances of the SDK and control them independently at the client level.
• Swarm control: I want to broadcast information for many (hundreds, thousands) drones in order to synchronize them, but I am not necessarily interested in having a heartbeat for each of them (e.g. I don't think that the 1000+ drones in those light events actually broadcast anything back to the GS).

And this is kind of in-between, isn't it?

I mean, we can also merge that already and see later how it evolves.

[julianoes]

In our case we kind of mix the discovery with the pairing, but both exist.

I guess that's true but there is no mechanism to move the port to somewhere else after the discovery.

Multi-drone control

If the 3 drones are in the same network and connect to the same port, the SDK could be handy. If you insist, we can throw the multi drone stuff out, I guess.

Swarm control:

Not sure how it would scale to 1000. I know that mavlink system IDs run out at 255, so that's a limit anyway.

[JonasVautherin]

I guess that's true but there is no mechanism to move the port to somewhere else after the discovery.

I don't know how the connection works, you're right 😅. My point is that if I know (without discovery) that there is a drone on 192.168.1.44:14557, I should be able to connect to it, right? Without a need for 14540 anywhere. Maybe I'm wrong, and I need to study it in more detail, too.

If the 3 drones are in the same network and connect to the same port, the SDK could be handy. If you insist, we can throw the multi drone stuff out, I guess.

Let's merge it for now. I guess my point is that at some point we should probably have a bigger discussion about those applications.

Not sure how it would scale to 1000. I know that mavlink system IDs run out at 255, so that's a limit anyway.

For "real" broadcast, we could imagine having a system were we don't set the system ID. E.g. GNSS satellites broadcast to the whole world, but don't know all the devices listening to them. And that kind of application is maybe not in the scope of the SDK, btw. But when we get feature requests for "swarm" control, I'm not always sure what the purpose is exactly.

[julianoes]

My point is that if I know (without discovery) that there is a drone on 192.168.1.44:14557, I should be able to connect to it, right?

No! The drone connects to 14550 (or 14540), and the ground station listens. At least that's what the mavlink specs says.

I'm not always sure what the purpose is exactly.

I never know. Unless it's for the Intel show, I can see the purpose of that.

[JonasVautherin]

No! The drone connects to 14550 (or 14540), and the ground station listens. At least that's what the mavlink specs says.

The drone opens port 14556, and broadcasts on 14550. Or 14557 and 14540. But way you want to connect mavros to the drone and you don't receive the broadcast (or you tell mavros to listen on 14541 ), then you use 14557. At least that's what I think I was doing with mavros.

[julianoes]

So you're saying MAVROS is not up to spec then.

[JonasVautherin]

Not sure. If I remember correctly, when the broadcast did not work, I could connect mavros to the px4 (by giving the 14557 address to mavros) instead of connecting the px4 to mavros (i.e. by using the mavlink interface -t option).

But maybe I'm just wrong. Let's forget it for now =).

[hamishwillee]

No! The drone connects to 14550 (or 14540), and the ground station listens.
At least that's what the mavlink specs says.

AFAIK the MAVLink spec says nothing about what ports connect to what. By convention, PX4 defines this set of standard ports. I believe ArduPilot use the same convention.

Offboard APIs are expected to listen at 14540.
PX4 also listens at 14557, and that is indeed what MAVROS uses (for whatever reason MAVROS initiates the communication rather than listening for connections).

The linked simulation page above shows the various relationships as confirmed by inspection and testing. It took a lot of work, and I am now fairly confident it is accurate.

[julianoes]

AFAIK the MAVLink spec says nothing about what ports connect to what.

I'm referring to Lorenz's words then. And the port is also listed in https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers 😄

[hamishwillee]

Hardly canonical - that just says 14550 |   | UDP | MAVLink | Unofficial. What it should say is "MAVLink GCS port".

Upshot, I'm always right :-)

[julianoes]

You should fix it ;)