I’ve been trying to send GPS data from my NVIDIA Jetson Xavier to PX4 Cube Orange. I am currently sitting indoors, where I shouldn’t be able to obtain GPS lock. I’ve connected my Cube Orange to my computer via Micro USB cable, and I am looking at the MavLink Inspector window on QGroundControl.
My Jetson Xavier is connected to the TELEM 2 port via USB-TTL cable, and following the guide shown here. As a result, I am able to see my Cube Orange connected serially to my Jetson Xavier as /dev/ttyUSB0 when I run: ls -l /dev/serial/by-id
As for the configuration on the flight controller, I have disabled MAVLink on port TELEM 2, and enabled uXRCE with the parameter UXRCE_DDS_CFG to TELEM 2. Baud rate for port TELEM 2 remains default at 921600.
I’ve followed the tutorial on ROS2 advertiser and listeners from here, used what I learned to create my own advertiser that advertises SensorGps uORB message. It’s basically similar to the DebugVectAdvertiser shown in the guide, with the following modifications to the message content: sensor_gps.lat = 403177769; sensor_gps.lon = 495889669; sensor_gps.alt = 0; sensor_gps.alt_ellipsoid = 0; sensor_gps.eph = 10; sensor_gps.epv = 1; sensor_gps.hdop = 1.2; sensor_gps.vdop = 0.8; sensor_gps.fix_type = 3; sensor_gps.device_id = 1; sensor_gps.satellites_used = 15; sensor_gps.heading = 157 * (M_PI / 180); sensor_gps.s_variance_m_s = 5;
And the values for eph and epv are basically those that simulators send. So, I’m expecting this to work, but it just keeps saying that there is no local and global position estimates in QGroundControl. I successfully see my GPS_RAW_INT message in the MAVLink Inspector panel, but unlike in the case of the simulator, I’m unable to see GLOBAL_POSITION_INT topic among the others.
What does the issue stem from? Am I not publishing the SensorGps uOrb topic properly? Do additional parameters need to be checked? Or is it that a GPS sends more than just SensorGps uOrb topic? I’ve tried looking for solutions, but seems like everyone has done this via either using external sources, or using local position estimates provided by computer vision SLAM algorithms. In my case, I’m trying to just send the GPS coordinates to the flight controller, exactly how the GPS device would.
Did you try using the ROS2 command line tool from a laptop running ubuntu 22.04 to see your global_position_int messages . What does it show then . or are you saying here you were able to see the global_position_int while using the simulator
Hi, I’m talking about the QGroundControl’s MAVLink Inspector page. When running a simulator (for example, Gazebo), the simulated drone is able to transform the GPS_RAW_INT, which is the SensorGps uOrb topic into a Global Position estimate.
However, in the case of sending the SensorGps uOrb topic through a ROS 2 connection, this global position estimate is not obtained.
Hi,
The purpose of ROS2 in Px4 is to translate UORB topics in Px4 to meaningful ROS2 messages. Strange that basic function doesn’t work.
What is your Px4 version
I believe I have wrongly defined the problem in my previous comment. The issue is not related to ROS 2, as it works exactly how it should. I am sending a SensorGps uOrb message, and the uXRCE-DDS agent can successfully send it to the client on PX4, which I can see and validate on the QGroundControl’s MAVLink Inspector page (the GPS_RAW_INT topic).
However, my problem is that, although I am able to send this SensorGps message to the flight controller, there is invalid local and global position estimates. These messages pop up on QGroundControl. And when I check the MAVLink Inspector, I can see that the GLOBAL_POSITION_INT topic is in fact not there. I believe that this topic is the output of EKF 2, which fuses GPS data with internal sensors, but despite sending the GPS data, neither local nor global position estimates are obtained.
I’m using PX4 version v1.14
My ROS 2 interface is uXRCE-DDS (which works without an issue, sends the message properly)
I’m on Ubuntu 20.04, but trying the same on Ubuntu 22.04 yields the same result, as the issue seems to be on the flight controller being unable to obtain the global position estimate.
I would agree. I bet that the EKF2 instance is not picking up on this message since (for some reason) a parameter is set to not pay attention to it.
A good place to look for it would be under EKF2_GPS_*
Also, do you have a GPS that actually works, and if so how do your messages compare to the ones sent by your GPS?
In fact, it might be a good idea to get your system working on a traditional GPS before moving over to your ROS2 GPS injection (if you have not already)
Yes, i need some help in getting my ROS2 working in PX4. however i am using PX4 v13.3 . here i have to use the FastRTPSDDS + FASTRTPS gen1.08 to move with ROS2 .
Kindly check the link below regarding my GPS working otherwise through QGC
Yes, there in fact was a parameter that was denying the SensorGps messages to be picked up by the EKF2, and that was the vel_ned_valid = True. Doing that fixed my issue.
Interesting though, I had disabled the 3D velocity fusion from the parameter EKF2_GPS_CTRL, but for some reason EKF2 was waiting for the velocity to be valid, despite not fusing it into the algorithm. Could it be a bug?
