udp://127.0.0.1 won't connect. udp:// will.

[linuxguy123]

To reproduce:

Take AutoPilot Server example, version 1.3.4. Strip out all the code in main() except

        std::this_thread::sleep_for(std::chrono::seconds(1));

This creates a stand alone MAVLink server. Edit Run it.

Run Takeoff and Land example.

This IP address will fail, whether passed in on the command line or hard coded in add_any_connection().

./a.out udp://127.0.0.1:14551

This IP address will connect:

./a.out udp://:14551

MissionPlanner connects properly with 127.0.0.1 and Port 14551.

[julianoes]

That's by design. When you add 127.0.0.1 you start sending UDP packets to that IP, rather than listening on that port. It's basically the same as the call https://github.com/mavlink/MAVSDK/blob/425577aa5629d591a854a65fd1f2dd6d88b526d9/src/mavsdk/core/include/mavsdk/mavsdk.h#L133.

Also check these docs: https://github.com/mavlink/MAVSDK/blob/425577aa5629d591a854a65fd1f2dd6d88b526d9/src/mavsdk/core/include/mavsdk/mavsdk.h#L83-L86

[linuxguy123]

Thanks for the prompt reply.

Is this a general UDP thing or specific to MAVSDK ?

 For UDP, the host can be set to either: 
      *   - zero IP: 0.0.0.0 -> behave like a server and listen for heartbeats. 
      *   - some IP: 192.168.1.12 -> behave like a client, initiate connection 
      *     and start sending heartbeats. 

If this is the case, the IP addresses in the AutoPilot Server example are incorrect. The APServer "server" portion, ie the AP, is set up with IP 127.0.0.1:14551. The APServer "client" portion, ie the GCS is set up with upd://:14551. According to the above, it should be the other way around.

And why does MissionPlanner need an IP address to connect to the server ? It works with udp:127.0.0.1:14551.

I saw that both the server and client used add_any_connection(). I thought the client/server functionality selection would have occurred when one set the configuration ie:

mavsdk::Mavsdk::Configuration configuration(
            mavsdk::Mavsdk::Configuration::UsageType::Autopilot);
        mavsdkTester.set_configuration(configuration);

or

mavsdk::Mavsdk::Configuration configuration(
        mavsdk::Mavsdk::Configuration::UsageType::GroundStation);
    mavsdk.set_configuration(configuration);

[julianoes]

The CLI argument format is not a general thing, no. It's a format we adopted for MAVSDK. MissionPlanner uses it differently.

In my mind specifying 127.0.0.1:14551 to mean to listen on 127.0.0.1 doesn't actually make much sense. You're basically saying I want to listen locally but you can only listen locally, you can't listen "on another IP". All you can do is to listen on one network interface only, e.g. on your own IP 192.168.x.y, or for all 0.0.0.0 which is the same as not specifying it for MAVSDK.

---

The APServer "server" portion, ie the AP, is set up with IP 127.0.0.1:14551. The APServer "client" portion, ie the GCS is set up with upd://:14551. According to the above, it should be the other way around.

I don't know APServer and how it works. One thing I know is that we seem to have it backwards in the PX4 (and probably ArduPilot) world. So if you consider the autopilot to be "the server", that's wrong, because generally the autopilot is sending out UDP packets containing heartbeats in broadcast and anyone can listen to them (locally) and then send UDP back.

In the web on the other hand a webserver is not sending out it's website on broadcast for anyone to listen but it's listening on its local port 80 for anyone wanting to get the website.

I thought the client/server functionality selection would have occurred when one set the configuration ie:

This mainly sets the component IDs.