Must Open QGroundControl First to Successfully Connect to PX4

[jreedy-riis]

Hello! I am using MAVSDK-Java on an Android device to connect to a Pixhawk PX4 using an Orange Cube and an ESP8266 Wifi Module. When using my application with the Gazebo simulator everything works perfectly; however, when connecting to the physical device, I cannot see any information at all besides if I am successfully connected. I am not receiving any telemetry data, battery data, etc. When I open QGroundControl and then go to my app, I am able to see all of the data that I expect. I was wondering if it was related to this issue: https://github.com/mavlink/MAVSDK/issues/1967 where a fix was created in MAVSDK version 1.4.11. I know a new maven release was created a month or so ago, but I am curious if a release with MAVSDK v1.4.11 will resolve my issue. Thank you!

[JonasVautherin]

I think you're right, it's probably solved by v1.4.11. Are you connecting over a serial link?

Let me release a new version of MAVSDK-Java ASAP!

[JonasVautherin]

Pushed, should be on the Maven repository in a few hours (sometimes it takes up to 2 days) :+1:

[jreedy-riis]

Thanks for the quick response and generating a new build! I am using UDP with a wifi module instead of serial. Considering how similar the issues are, I was curious if it would solve my issue as well even though I am not using serial.

[JonasVautherin]

Hmm I think the issue is really for the serial connection. But let's try 1.4.11 and see if that helps! Otherwise we'll continue debugging your specific issue :blush:

[divyanshupundir]

@jreedy-riis, are you using PX4 v1.13.3? The problem that I noticed was that PX4 was waiting for the GCS to send the heartbeat before starting its data streams. In previous builds of MAVSDK, the server would do the same therefore neither would discover the other. In MAVSDK v.14.11, the server will always send heartbeats, therefore this problem should be fixed.

[JonasVautherin]

Yeah but that's for serial connections only, right? I mean serial connections from the point of view of PX4 (so if you connect PX4 to a network over the serial, then that would count as "serial", I would say).

Anyway 1.3.1 is up there, let me know :wink:

[divyanshupundir]

Yes, you are correct. We're using the telem port of a pixhawk which is connected to a Herelink air unit.

Quite interestingly, it only happens for an FMUv5x when the drone is rebooted using the MAVLink command. It works fine on a hard reboot. But that's a PX4 problem.

[jreedy-riis]

Turns out my Pixhawk was actually using Ardupilot instead of PX4. I am now having issues unrelated to MAVSDK-Java after installing PX4 onto it. Once I can get it configured correctly for HITL use with UDP, I will try connecting again and if I experience the same issue I will re-open this ticket. Sorry about the confusion and thank you for looking into my issue!

[jreedy-riis]

Hello, I just got my Wifi Module working correctly on PX4 and I am still experiencing the issue. When I first load my app, it cannot find the device. I have a slight workaround which is before I start the mavsdk server, I will open a socket on port 14550 and start emitting a heartbeat manually to the wifi modules address at port 14555 for about 5 seconds using the MAVLink-Java classes. After the 5 seconds, I close the port and start the server. However, this only initiates the drone.core.connectionState observable to work. Is it possible I need to send my own MAVLink messages requesting the data I would like before I start the MAVSDK server?

Edit: Okay, so I think sending the heartbeat before starting MAVSDK is the fix that I needed, with regards to the data being empty, I think that is just whats being returned from my device. I am going to try and get my device setup using the HITL/SITL combination. I don't think there is anything wrong with MAVSDK-Java, just seems to be an issue with MAVSDK-Server in general.

[JonasVautherin]

When you run MavsdkServer, the typical address is udp://:14540. This tells it to listen for MAVLink messages coming on port 14540. It is equivalent to writing udp://0.0.0.0:14540.

If you want MavsdkServer to send heartbeats to the drone (instead of waiting for the drone to send its heartbeats), you can instead use an address like this: udp://<ip_of_drone>:<port_of_drone>. If the drone IP is 192.168.1.12, and the drone listens on 14555, that means udp://192.168.1.12:14555.

This should have the same effect as your trick, I think :+1:.

[jreedy-riis]

I gave that a try, and it did seem like it was emitting its heartbeat, however, I was then not able to connect to the drone until after I stopped the server and switched back to using udp://0.0.0.0:14550. I think I will just manually emit the heartbeats to the drones ip and port using a separate socket, then let MavsdkServer running on udp://0.0.0.0:14550 handle everything else.