Timeout while uploading MissionPlan in Android

[divyanshupundir]

I am currently testing my Android app using jMAVSim and PX4_SITL. While trying to upload a MissionPlan to the drone, and I am getting WARN [mavlink] Operation timeout on the console and the following logs in Android Studio Logcat:

2020-10-30 15:25:03.894 30927-31026/<package> E/LOG_<package>.repositories.DroneRepository: TIMEOUT: Timeout
    io.mavsdk.mission.Mission$MissionException: TIMEOUT: Timeout
        at io.mavsdk.mission.Mission$1.onNext(Mission.java:420)
        at io.mavsdk.mission.Mission$1.onNext(Mission.java:414)
        at io.grpc.stub.ClientCalls$StreamObserverToCallListenerAdapter.onMessage(ClientCalls.java:421)
        at io.grpc.ForwardingClientCallListener.onMessage(ForwardingClientCallListener.java:33)
        at io.grpc.ForwardingClientCallListener.onMessage(ForwardingClientCallListener.java:33)
        at io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl$1MessagesAvailable.runInContext(ClientCallImpl.java:519)
        at io.grpc.internal.ContextRunnable.run(ContextRunnable.java:37)
        at io.grpc.internal.SerializingExecutor.run(SerializingExecutor.java:123)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
        at java.lang.Thread.run(Thread.java:764)

This is the code that I use:

    public void uploadAndExecuteMission(@NonNull Mission.MissionPlan missionPlan) {
        Disposable d = mDrone.getMission()
                .uploadMission(missionPlan)
                    .doOnComplete(() -> logD("Uploading mission"))
                    .doOnError(this::logE)
                .andThen(mDrone.getAction().arm())
                    .doOnComplete(() -> logD("Armed"))
                    .doOnError(this::logE)
                .andThen(mDrone.getMission().startMission())
                    .doOnComplete(() -> logD("Starting mission"))
                    .doOnError(this::logE)
                .subscribe(() -> { }, this::logE);

        mCompositeDisposable.add(d);
    }

Everything works perfectly well when I try to arm, take off, or land the drone (both in SITL and a physical drone).

Does anyone have any ideas on what could be going wrong and how to fix it? Thanks in advance.

[JonasVautherin]

Can you upload a mission from QGC? Just to test if everything is fine on the drone side.

Also did you try the Java RunMission example? You could run it from your computer, and that would verify that the Java part works.

[divyanshupundir]

Can you upload a mission from QGC?

I am able to upload the mission using QGC.

Also did you try the Java RunMission example?

This is also working. I ran it using mavsdk_server_manylinux2010-x64 on the same PC.

I also basically, copy-pasted the mission generation and upload code from RunMission in the function that I had mentioned:

public void uploadAndExecuteMission(@NonNull Mission.MissionPlan missionPlan)

But even though the code worked as a separate Java program. On Android, it's giving the same TIMEOUT error.

[JonasVautherin]

Ok, that's already helpful! One more thing: would you mind trying to connect your Android app through the mavsdk_server_manylinux2010-x64 you used on your PC? In the android-client example it would be a matter of entering the IP of your laptop here (with the Android device and the laptop being on the same LAN, obviously).

If that works, it will suggest that the mavsdk_server embedded in the Android package is somehow not working anymore (maybe there were changes), and that would probably be fixed by just updating it (which I should do anyway).

[divyanshupundir]

would you mind trying to connect your Android app through the mavsdk_server_manylinux2010-x64 you used on your PC?

I tried this just now and it's working. You're right, it's probably the Android mavsdk_server that's not working as expected.

that would probably be fixed by just updating it (which I should do anyway).

Could you please let me know when you'd be doing that? If it's not anytime soon, I guess I could just build it myself from the repo. master should have the changes you're talking about, right?

And thank you again.

[JonasVautherin]

I'll do it today or tomorrow :+1:.

[JonasVautherin]

I just published 0.5.0 (both mavsdk:0.5.0 and mavsdk-server:0.5.0), they should be available from Maven in a few hours. Please let me know how it goes :+1:.

EDIT: actually mavsdk:0.5.1, because for some reason maven could not release 0.5.0 :see_no_evil:.

[divyanshupundir]

Something seems to be wrong. When I updated to mavsdk-server:0.5.0, I'm not able to takeoff. The logs:

2020-11-02 08:06:51.913 18058-18138/<package> W/Mavsdk: sending again, retries to do: 3  (MIS_TAKEOFF_ALT).
2020-11-02 08:06:52.916 18058-18138/<package> W/Mavsdk: sending again, retries to do: 2  (MIS_TAKEOFF_ALT).
2020-11-02 08:06:53.920 18058-18138/<package> W/Mavsdk: sending again, retries to do: 1  (MIS_TAKEOFF_ALT).
2020-11-02 08:06:54.924 18058-18138/<package> E/Mavsdk: Error: Retrying failed get param busy timeout: MIS_TAKEOFF_ALT
2020-11-02 08:06:54.947 18058-18181/<package> E/LOG_DroneRepository: PARAMETER_ERROR: Parameter Error
    io.mavsdk.action.Action$ActionException: PARAMETER_ERROR: Parameter Error
        at io.mavsdk.action.Action$14.onNext(Action.java:616)
        at io.mavsdk.action.Action$14.onNext(Action.java:610)
        at io.grpc.stub.ClientCalls$StreamObserverToCallListenerAdapter.onMessage(ClientCalls.java:421)
        at io.grpc.ForwardingClientCallListener.onMessage(ForwardingClientCallListener.java:33)
        at io.grpc.ForwardingClientCallListener.onMessage(ForwardingClientCallListener.java:33)
        at io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl$1MessagesAvailable.runInContext(ClientCallImpl.java:519)
        at io.grpc.internal.ContextRunnable.run(ContextRunnable.java:37)
        at io.grpc.internal.SerializingExecutor.run(SerializingExecutor.java:123)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
        at java.lang.Thread.run(Thread.java:764)

Uploading the missions doesn't generate any log messages. So it looks like that these line are not being executed.

.uploadMission(missionPlan) .doOnComplete(() -> logD("Uploading mission")) .doOnError(this::logE)

I tried taking off with the console and triggering RTL from the app, I get similar logs as those of takeoff:

2020-11-02 08:19:38.467 18058-18138/<package> W/Mavsdk: sending again, retries to do: 3  (RTL_RETURN_ALT).
2020-11-02 08:19:39.472 18058-18138/<package> W/Mavsdk: sending again, retries to do: 2  (RTL_RETURN_ALT).
2020-11-02 08:19:40.485 18058-18138/<package> W/Mavsdk: sending again, retries to do: 1  (RTL_RETURN_ALT).
2020-11-02 08:19:41.486 18058-18138/<package> E/Mavsdk: Error: Retrying failed get param busy timeout: RTL_RETURN_ALT
2020-11-02 08:19:41.502 18058-20193/<package> E/LOG_DroneRepository: PARAMETER_ERROR: Parameter Error
    io.mavsdk.action.Action$ActionException: PARAMETER_ERROR: Parameter Error
        at io.mavsdk.action.Action$18.onNext(Action.java:740)
        at io.mavsdk.action.Action$18.onNext(Action.java:734)
        at io.grpc.stub.ClientCalls$StreamObserverToCallListenerAdapter.onMessage(ClientCalls.java:421)
        at io.grpc.ForwardingClientCallListener.onMessage(ForwardingClientCallListener.java:33)
        at io.grpc.ForwardingClientCallListener.onMessage(ForwardingClientCallListener.java:33)
        at io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl$1MessagesAvailable.runInContext(ClientCallImpl.java:519)
        at io.grpc.internal.ContextRunnable.run(ContextRunnable.java:37)
        at io.grpc.internal.SerializingExecutor.run(SerializingExecutor.java:123)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
        at java.lang.Thread.run(Thread.java:764)

Also, I'm able to receive the Battery and GpsInfo data, but no data for Position or PositionVelocityNed (I've only tested these).

There doesn't seem to be any problem with mavsdk:0.5.1 because on rolling back to mavsdk-server:0.4.0, I'm getting the old problems and not the new ones.

[divyanshupundir]

I also noticed some other things after using mavsdk_server_manylinux2010-x64 to connect to SITL. In general, when I run the mavsdk-server on my phone and not the PC, I continuously get these logs in the Logcat:

2020-11-02 08:34:46.596 23652-23716/<package> W/Mavsdk: sending again, retries to do: 3  (SYS_HITL).
2020-11-02 08:34:47.598 23652-23716/<package> W/Mavsdk: sending again, retries to do: 2  (SYS_HITL).
2020-11-02 08:34:48.183 23652-23716/<package> I/Mavsdk: heartbeats timed out
2020-11-02 08:34:48.183 23652-23716/<package> D/Mavsdk: Lost 5283920058631409231
2020-11-02 08:34:48.183 23652-23716/<package> I/Mavsdk: System timed out [UUID: 5283920058631409231]
2020-11-02 08:34:48.686 23652-23716/<package> W/Mavsdk: sending again, retries to do: 1  (SYS_HITL).
2020-11-02 08:34:49.693 23652-23716/<package> E/Mavsdk: Error: Retrying failed get param busy timeout: SYS_HITL
2020-11-02 08:34:49.693 23652-23716/<package> E/Mavsdk: Error: Param to determine hitl failed.
2020-11-02 08:34:50.821 23652-23725/<package> D/Mavsdk: Discovered 1 component(s) (UUID: 5283920058631409231)
2020-11-02 08:34:51.120 23652-23725/<package> W/Mavsdk: command denied (512).
2020-11-02 08:34:51.829 23652-23716/<package> D/Mavsdk: Falling back to Gimbal Version 1
2020-11-02 08:34:52.634 23652-23716/<package> W/Mavsdk: sending again, retries to do: 3  (SYS_HITL).
2020-11-02 08:34:53.642 23652-23716/<package> W/Mavsdk: sending again, retries to do: 2  (SYS_HITL).
2020-11-02 08:34:54.223 23652-23716/<package> I/Mavsdk: heartbeats timed out
2020-11-02 08:34:54.223 23652-23716/<package> D/Mavsdk: Lost 5283920058631409231
2020-11-02 08:34:54.223 23652-23716/<package> I/Mavsdk: System timed out [UUID: 5283920058631409231]

And sometimes I need to click the takeoff button twice for the drone to respond (both SITL and physical drone). But when the server runs on my PC (Only SITL. I haven't tried a physical drone in this case), I don't get those logs on the console, and even the drone is extremely responsive.

That could be because both the server and SITL are running on the same PC, so there's no data loss. But should this problem occur considering the devices are connected through a LAN (WiFi) that is quite stable?

[julianoes]

What is the PX4 version that you are using?

[divyanshupundir]

What is the PX4 version that you are using?

HW arch: PX4_SITL
FW git-hash: 0ff4fad95cfb8bc4a2fa62088363e57b7c037b23
FW version: 1.11.0 c0 (17498304)
OS: Linux
OS version: Release 5.4.0 (84148479)
Build datetime: Oct 29 2020 15:09:29
Build uri: localhost
Toolchain: GNU GCC, 7.5.0
PX4GUID: 1006554d49534954414c44494e4f30303030
UNKNOWN MCU

[JonasVautherin]

I updated the examples (java + android) here, and it seems like it is working for me. I ran the android-client on my phone against SITL (px4-gazebo-headless) running on my computer.

Would you mind trying the updated example and let me know what happens there?

[divyanshupundir]

I pulled the updated MAVSDK-Java code and I ran the android-client on two phones (API 28 and 29). I had to change this line to int mavsdkServerPort = mavsdkServer.run("udp://192.168.0.255:14550"); since the MAVLINK broadcast is on that IP (the phones and the PC are connected to the same WiFi network)

In both cases, on clicking the takeoff option I got these logs and the drone did not takeoff:

2020-11-02 19:57:28.840 3255-3408/io.mavsdk.androidclient W/Mavsdk: sending again after 0.505538 s, retries to do: 3  (400).
2020-11-02 19:57:29.342 3255-3408/io.mavsdk.androidclient W/Mavsdk: sending again after 1.00718 s, retries to do: 2  (400).
2020-11-02 19:57:29.848 3255-3408/io.mavsdk.androidclient W/Mavsdk: sending again after 1.51396 s, retries to do: 1  (400).

And on clicking the play button I got the following and no response after that:

2020-11-02 19:57:38.289 3255-3255/io.mavsdk.androidclient D/MapsViewModel: [main] - Uploading and starting mission...

Then, I added the following lines in the takeoff option code to log the errors:

case R.id.takeoff:
  drone.getAction().arm()
            .doOnComplete(() -> logger.debug("Armed"))
            .doOnError(throwable -> logger.error(throwable.getMessage(), throwable))
          .andThen(drone.getAction().takeoff())
            .doOnComplete(() -> logger.debug("Taking off"))
            .doOnError(throwable -> logger.error(throwable.getMessage(), throwable))
          .subscribe(() -> logger.debug("Subscribe complete"), throwable -> logger.error(throwable.getMessage(), throwable));
  break;

And this was the output in both the phones:

2020-11-02 20:23:33.548 4552-6548/io.mavsdk.androidclient W/Mavsdk: sending again after 0.50881 s, retries to do: 3  (400).
2020-11-02 20:23:34.055 4552-6548/io.mavsdk.androidclient W/Mavsdk: sending again after 1.01564 s, retries to do: 2  (400).
2020-11-02 20:23:34.565 4552-6548/io.mavsdk.androidclient W/Mavsdk: sending again after 1.52552 s, retries to do: 1  (400).
2020-11-02 20:23:35.073 4552-6548/io.mavsdk.androidclient E/Mavsdk: Retrying failed (400)
2020-11-02 20:23:35.106 4552-6565/io.mavsdk.androidclient E/MapsActivity: [grpc-default-executor-2] - CONNECTION_ERROR: Connection Error
    io.mavsdk.action.Action$ActionException: CONNECTION_ERROR: Connection Error
        at io.mavsdk.action.Action$1.onNext(Action.java:216)
        at io.mavsdk.action.Action$1.onNext(Action.java:210)
        at io.grpc.stub.ClientCalls$StreamObserverToCallListenerAdapter.onMessage(ClientCalls.java:421)
        at io.grpc.ForwardingClientCallListener.onMessage(ForwardingClientCallListener.java:33)
        at io.grpc.ForwardingClientCallListener.onMessage(ForwardingClientCallListener.java:33)
        at io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl$1MessagesAvailable.runInContext(ClientCallImpl.java:519)
        at io.grpc.internal.ContextRunnable.run(ContextRunnable.java:37)
        at io.grpc.internal.SerializingExecutor.run(SerializingExecutor.java:123)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
        at java.lang.Thread.run(Thread.java:764)

Telemetry data is being received since the map is showing the correct drone location and the flight mode and armed logs are being shown as expected:

2020-11-02 19:57:21.891 3255-3440/io.mavsdk.androidclient D/MapsActivity: [grpc-default-executor-5] - armed: false
2020-11-02 19:57:21.907 3255-3438/io.mavsdk.androidclient D/MapsActivity: [grpc-default-executor-4] - flight mode: HOLD

I am using px4_sitl and jmavsim build mentioned here. But I guess, that shouldn't be the reason for this problem.

Looks like the server is having some problem in sending the data. Could it be that something is not working properly in the GRPC server code? Since the Action.java:210 in the error logs points towards this line in Action.java:

stub.arm(request, new StreamObserver<ActionProto.ArmResponse>() { ... }

[JonasVautherin]

int mavsdkServerPort = mavsdkServer.run("udp://192.168.0.255:14550");

This will not do more than udp://:14550 (actually it may to less in some situations). 192.168.0.255/24 is a broadcast address, so I am assuming that you are hoping that this way, MAVSDK will somehow initiate the connection with PX4. But that's not how it works. MAVSDK passively waits for packets to arrive on port 14550. A nice feature would be to allow something like mavsdkServer.run("udp://192.168.0.12:14550") to initiate a connection to PX4, but we don't have it yet (at least not in Java).

This said, I do it the other way round: I let mavsdk_server listen on udp://:14540 (i.e. the default behavior in the android-client), and I make the simulator point to it (and that's why I like px4-gazebo-headless, because it makes it easy to do that; say your phone is on 192.168.1.22, on your computer you can just run (see the README for more info):

docker run --rm -it jonasvautherin/px4-gazebo-headless:1.11.0 192.168.1.22

And px4-gazebo-headless will run a SITL instance in a container that sends MAVLink to your computer (i.e. from the container to the host) on 14550 (so that you can run QGC on your computer), and also to 192.168.1.22:14540, so that android-client receives MAVLink directly.

Would you mind trying that setup, just to check if it could be a network issue? I have been using px4-gazebo-headless for years now, and I find it a good reproducible way to compare our setups :blush:.

[divyanshupundir]

This was extremely helpful! Thanks a lot!

192.168.0.255/24 is a broadcast address, so I am assuming that you are hoping that this way, MAVSDK will somehow initiate the connection with PX4.

You're correct, I was making this mistake from the start. Now I'm able to run the server on the phone itself and everything's working fine.

But I wasn't able to do it using the docker image (docker run --rm -it jonasvautherin/px4-gazebo-headless:1.11.0 192.168.1.22). Because it was using eth0 network interface (and not WiFi), so it wasn't getting connected to my phone. I couldn't find a way to change it to wlo1. So, in the px4_sitl jmavsim build, I started a new mavlink instance using the command mavlink start -x -r 4000000 -o 14540 -t 192.168.0.129 and did what you had suggested, which made it work. Is there a way to change the network interface in the docker image because it looks much easier to use?

I'll fix this issue in my code that connects to the physical drone. Hopefully, it too will work fine.

[JonasVautherin]

Because it was using eth0 network interface (and not WiFi)

I am not sure I understand that. If your laptop is connected to the same LAN as the phone, normally by default the docker container will have access to that network (e.g. it should be able to ping 192.168.0.129). In that case, it should "just work". Choosing the network interface is something that is done at the routing level: when I ping 192.168.0.1 it goes towards my LAN router, and if I ping 10.41.0.1 it goes towards the USB device I connected that exposes a network interface. I don't have to mention the interface anywhere, the route table figured it out, right?

Note that this will send on 14540. You could send both 14540 and 14550 with:

docker run --rm -it jonasvautherin/px4-gazebo-headless:1.11.0 192.168.0.129 192.168.0.129

[divyanshupundir]

Using make px4_sitl jmavsim. partner IP: 127.0.0.1 corresponds to QGC running locally on the laptop. (I have to add 192.168.0.129 using mavlink start manually later):

INFO  [mavlink] mode: Normal, data rate: 4000000 B/s on udp port 18570 remote port 14550
INFO  [mavlink] mode: Onboard, data rate: 4000000 B/s on udp port 14580 remote port 14540
INFO  [mavlink] mode: Onboard, data rate: 4000 B/s on udp port 14280 remote port 14030
INFO  [mavlink] using network interface **wlo1**, IP: 192.168.0.188
INFO  [mavlink] with netmask: 255.255.255.0
INFO  [mavlink] and broadcast IP: 192.168.0.255
INFO  [mavlink] partner IP: 127.0.0.1

Using docker run --rm -it jonasvautherin/px4-gazebo-headless:1.11.0 192.168.0.129

INFO  [mavlink] mode: Normal, data rate: 4000000 B/s on udp port 18570 remote port 14550
INFO  [mavlink] mode: Normal, data rate: 4000000 B/s on udp port 14580 remote port 14540
INFO  [mavlink] mode: Onboard, data rate: 4000 B/s on udp port 14280 remote port 14030
INFO  [mavlink] MAVLink only on localhost (set param MAV_BROADCAST = 1 to enable network)
INFO  [mavlink] MAVLink only on localhost (set param MAV_BROADCAST = 1 to enable network)
  MAV_BROADCAST: curr: 0 -> new: 1
INFO  [mavlink] using network interface **eth0**, IP: 172.17.0.3
INFO  [mavlink] with netmask: 255.255.0.0
INFO  [mavlink] and broadcast IP: 172.17.255.255
INFO  [mavlink] partner IP: 172.17.0.1

I've even set MAV_BROADCAST to 1, and mavlink status shows 192.168.0.129 as a partner IP in one of mavlink instances:

instance #1:
    mavlink chan: #1
    type:       GENERIC LINK OR RADIO
    flow control: OFF
    rates:
      tx: 1.397 kB/s
      txerr: 0.000 kB/s
      tx rate mult: 1.000
      tx rate max: 4000000 B/s
      rx: 0.000 kB/s
    FTP enabled: YES, TX enabled: YES
    mode: Normal
    MAVLink version: 1
    transport protocol: UDP (14580, remote port: 14540)
    partner IP: 192.168.0.129

QGC is getting connected to instance #0 partner IP 172.17.0.1. But the phone isn't.

[JonasVautherin]

Oh, I see where you get this "interface" name :slightly_smiling_face:. I added this into PX4 a few years ago :sweat_smile:.

INFO  [mavlink] using network interface **eth0**, IP: 172.17.0.3
INFO  [mavlink] with netmask: 255.255.0.0
INFO  [mavlink] and broadcast IP: 172.17.255.255

What PX4 does here is choosing an interface to which it will broadcast the MAVLink heartbeats. Here it says eth0, because it is in the docker container, and the docker container does not see you wlo1 interface. But the important part is broadcast IP: 172.17.255.255, which says that the docker container will broadcast the messages (when MAV_BROADCAST is enabled) to 172.17.255.255, which will reach your host.

In other words, MAV_BROADCAST works in px4-gazebo-headless only between the container and the host, but it will not broadcast on the LAN. That is why we pass 192.168.1.129 as an argument, which is written internal into the rcS before PX4 is started.

Now, I don't understand why it doesn't just work for you. Are you running on Windows? That's the only one where I have never tried that :laughing:.

Can you try to ping your phone, with:

# Enter the container
docker run --rm -it --entrypoint /bin/bash jonasvautherin/px4-gazebo-headless:1.11.0

# Install the `ping` command
apt install iputils-ping

# Ping your phone
ping 192.168.0.129

You could also try ping 8.8.8.8 to see if the container has internet access, which should confirm that it has access to the LAN.

[divyanshupundir]

which says that the docker container will broadcast the messages (when MAV_BROADCAST is enabled) to 172.17.255.255, which will reach your host.

Yes, that makes sense. That's why QCG is able to connect to it.

Are you running on Windows?

I'm using Ubuntu 18.04.5

Can you try to ping your phone

root@1957d3ee4ee1:/# ping 192.168.0.129
PING 192.168.0.129 (192.168.0.129) 56(84) bytes of data.
64 bytes from 192.168.0.129: icmp_seq=1 ttl=63 time=8.03 ms
64 bytes from 192.168.0.129: icmp_seq=2 ttl=63 time=7.12 ms
64 bytes from 192.168.0.129: icmp_seq=3 ttl=63 time=7.06 ms
64 bytes from 192.168.0.129: icmp_seq=4 ttl=63 time=23.4 ms
^C
--- 192.168.0.129 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 7.068/11.425/23.475/6.967 ms
root@1957d3ee4ee1:/# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=115 time=4.07 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=115 time=4.01 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=115 time=4.95 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=115 time=5.69 ms
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3002ms
rtt min/avg/max/mdev = 4.018/4.687/5.699/0.691 ms

It looks like docker container is able to reach my phone and the internet.

I don't understand why it doesn't just work for you.

If I could get a penny for every time someone said that to me :laughing: :sweat_smile:.

[JonasVautherin]

It looks like docker container is able to reach my phone and the internet.

Yes, indeed. Last thing I can think of: are you sure that you don't have another SITL instance connected before px4-gazebo-headless (new systems are ignored by mavsdk_server), and that your android-client listens on 14540 (that's the default)?

If I could get a penny for every time someone said that to me :laughing: :sweat_smile:.

Yeah, I guess :laughing:. It's just that px4-gazebo-headless is usually my first tool to test a connection, it's the first time in 3 years that it can ping a phone but doesn't work :sweat_smile:.

[divyanshupundir]

are you sure that you don't have another SITL instance connected before px4-gazebo-headless (new systems are ignored by mavsdk_server)

Yes. I did a completed reboot of all my devices and it's still showing the same problem. It's not a big issue for now. It is working with jmavsim method when I manually add the IP and port.

Thank you again for your help.