ros2 topic "vehicle_local_position" publishes nothing [Holybro Pixhawk 4]

[JohnnyLiu2886]

I set up the uorb message "vehicle_local_position" in the urtps_bridge_topics.yaml files. And it works in the simulation when I am using "make px4_sitl_rtps gazebo_boat". The subscription function in my code can be called because the gazebo simulator can publish "vehicle_local_position" uorb messages to the ros2.

However, when I ran the same code on the Holybro Pixhawk 4, it did not publish any "vehicle_local_position" messages to the ros2. Therefore, I cannot get the local position data from the pixhawk.

I don't think it is the problem of my code as the "vehicle_gps_position" can be received as usual.

I think there is some module which I did not use with the pixhawk.

Could someone tell me what I need to install on the pixhawk 4 if I want to get the "vehicle_local_position" messages?

[adk4davsys]

Are you running micrortps_client on your Pixhawk 4? For my use case, I have to issue the command micrortps_client start -d /dev/ttyS2 via QGC's Mavlink Console in order to start the client on PX4. Also, use ros2 topic list to check the topics are being published from your Pixhawk.

[JohnnyLiu2886]

Are you running micrortps_client on your Pixhawk 4? For my use case, I have to issue the command micrortps_client start -d /dev/ttyS2 via QGC's Mavlink Console in order to start the client on PX4. Also, use ros2 topic list to check the topics are being published from your Pixhawk.

Thank you for your response. I knew what you are talking about as I was successful to use the pixhawk 4 holybro hardware with ros2 but it is not the reason of the problem.

"micrortps_client start" will be ran automatically when using "make sitl_rtps gazebo_boat" and the I knew that the topic is really running when I am running "make sitl_rtps gazebo_boat" and "micrortps_agent -t UDP". I added the topic on both .yaml files of ros2 workspace and PX4-Autopilot. Therefore, it must run when I call "make sitl_rtps gazebo_boat" and "micrortps_agent -t UDP".

The problem is that those uorb topic are not useful for my situation. They are not working because they are not designed for changing the speed during the trajectory_setpoint.

It is also not the problem of using real Pixhawk 4 or not. It is because other topic like vehicle_command, offboard_control_mode, trajectory_setpoint and vehicle_gps_position are all working on both pixhawk 4 holybro hardware and gazebo software.

I tried them and they ran successfully. The only problem is that I cannot find a uorb message which can define the maximum xy velocity for trajectory_setpoint dynamically.

[adk4davsys]

@JohnnyLiu2886 Ah I see. I never developed with gazebo_boat. But couldn't you just set limits in your code before publishing to trajectory_setpoint? Hope you'll find some workarounds. Good luck.

[JohnnyLiu2886]

@JohnnyLiu2886 Ah I see. I never developed with gazebo_boat. But couldn't you just set limits in your code before publishing to trajectory_setpoint? Hope you'll find some workarounds. Good luck.

Sorry, I finally found that I am off-topic as I am too concentrate on my work of controlling the maximum velocitiy.

I was going to get the vx, vy, vxy_max, ref_lat and ref_lon of from uorb topic vehicle_local_position. I am currently trying it with pixhawk 4 holybro and I am successful to see "/fmu/vehicle_local_position/in [px4_msgs/msg/VehicleLocalPosition]" when I called "ros2 topic list -t" in the terminal.

However, vehicle_local_position did not publish anything to my ros2 subscriber.

I think the followings are the reasons of the problem:

1. setting both send and receive of vehicle_local_position to true.
   • I did this because I want to control vxy_max through vehicle_local_position at the beginning. I also want to get the horizontal velocitiy and position of refence point of local position data.
2. I need to use estimator_local_position or vehicle_local_position_groundtruth instead.
   • I don't know why estimator_local_position.msg, vehicle_local_position_groundtruth.msg and vehicle_local_position.msg have the same content. The same thing also happens for vehicle_local_position_setpoint and trajectory_setpoint.

I will tried the above two solutions. If it is still not working, it will be because px4 no longer use this uorb message.

[JohnnyLiu2886]

fmu

I did something wrong here. Instead of "/fmu/vehicle_local_position/in", I need to subscribe to "/fmu/vehicle_local_position/out". However, it is still not working.

[adk4davsys]

@JohnnyLiu2886 That sounds frustrating, I have been there. One thing I have found is that when I edit urtps_bridge_topics.yaml file, I have to clean my colcon workspace using clean_all.bash. This is a script inside the package px4_ros_com/scripts. Try that and see if it works.

[JohnnyLiu2886]

@JohnnyLiu2886 That sounds frustrating, I have been there. One thing I have found is that when I edit urtps_bridge_topics.yaml file, I have to clean my colcon workspace using clean_all.bash. This is a script inside the package px4_ros_com/scripts. Try that and see if it works.

Thanks for your response! I always do it when I am trying to add new topic to my ros2 workspace. Here is my procedure:

1. modify the .yaml inside the PX4-Autopilot
2. Run the .py files to clone the ros2 version of the .yaml files to the template folder of my px4_ros_com ros2 package
3. make clean in the PX4-Autopilot
4. execute clean_all.bash inside the script folder of px4_ros_com.
5. colcon build again
6. make px4_fmu-v5_rtps again

After that, I will see the ros2 topic is matched in the micrortps_agent terminal when I am running my ros2 code.

However, even it is matched, I did not see anything is published when I check it using ros2 topic echo "/fmu/vehicle_local_position/out" .

[JohnnyLiu2886]

It is not working. It is extremely important for me to know the position of reference point in the global frame. Without it, it is difficult to setpoint accurately in the offboard mode. It is because we can only use trajectory_setpoint to set the local setpoint in offboard mode. The local setpoint is depended on the position of reference point.

[JohnnyLiu2886]

I found a module call local_position_estimator status. I checked its status in the nsh terminal. I found that it is not running. After that, I started it and it returned "device reports readiness to read but returned no data (device disconnected or multiple access on port?)"

After that, the pixhawk 4 reboot and the status of the local_position_estimator is not running again.

I thought that is it owing to the indoor environment which preventing the gps function of the ECL EKF from working. However, it is difficult to test the code as there is not screen outdoor.

local-position-estimator: https://docs.px4.io/master/en/modules/modules_estimator.html#local-position-estimator Attitude and position estimator using an Extended Kalman Filter.

It means that the position estimator is not working as it is not running.

[adk4davsys]

Just out of curiosity, what is the output of micrortps_client status within Mavlink Console from your Pixhawk 4?

[JohnnyLiu2886]

Just out of curiosity, what is the output of micrortps_client status within Mavlink Console from your Pixhawk 4?

It was running otherwise, I would not receive gps position on the terminal in the right hand side. I knew that it will not running when micrortps_client status is not running. I always start it before running the micrortps_agent as I knew that it starts the communication between the Jetson Xavier and the pixhawk4 through port dev/ttyTHS0 and port Telem2.

I can control most of my function such as arm, disarm, switch to offboard mode, setpoint, switch to manual mode and receive gps position.

The only failure is to receive data from "vehicle_local_position". I thought it would be because the pixhawk is inside the office. I am developing everything inside the office. Only the gps module is hung outside the window and the pixhawk is still under the roof. I think it is the reason for the local_position_estimator not to run as the gps device inside the pixhawk4 did not receive gps signal.

I am going to test the jetson and pixhawk outside the office and test whether it can run local_position_estimator using the ssh terminal.

[JohnnyLiu2886]

I can get something when I used listener vehicle_local_position in the nsh terminal but I cannot get it in the ros2 even it is listed in the utrtps_bridge_topics.yaml and the "VehicleLocalPosition.cpp" and VehicleLocalPosition.h are existed in the build folder of the ros2 workspace.

[JohnnyLiu2886]

I have tested the vehicle outside the office using ssh. However, everything remains the same.

1. The "vehicle_local_position" topic did not publish anything. I checked it using "ros2 topic echo /fmu/vehicle_local_position/out".

2. I can check the data of "vehicle_local_position" using nsh terminal. It is both working jetson and qgroundcontrol.

3. The module "local_position_estimator" is not running even it is outside the office. When I did this "local_position_estimator start", the pixhawk reboot.

I am not sure why it is happening. I really need some help. Can someone try to subscribe to ros2 topic "vehicle_local_position" and see what is happening? Is there anybody who are successful to get data from the ros2 topic "vehicle_local_position"?

The next thing for me to test is to test it with the latest version of PX4-Autopilot. I am currently using the PX4-Autopilot version on 4 October. The reason for me not to use the latest version is that there is some problem with the cmakefile which preventing me from build the fmu_v5_rtps on the jetson xavier nx successfully. However, I will continue to build it this time.

[JohnnyLiu2886]

After using the latest version of PX4-Autopilot, I can receive the data of "vehicle_local_position" in the gazebo simulator. However, it is not working when I am using holybro pixhawk 4.

[xiaobai-cai-hold]

hello Johnny, I met the same problem as you, I can't subscribe local_position via ros2 both indoors and outdoors. However I can subscribe "vehicle_odometry" data. My service is Pixhawk 4 Do you solve your problem? Thanks for your replying.

[xiaobai-cai-hold]

Just out of curiosity, what is the output of micrortps_client status within Mavlink Console from your Pixhawk 4?

It was running otherwise, I would not receive gps position on the terminal in the right hand side. I knew that it will not running when micrortps_client status is not running. I always start it before running the micrortps_agent as I knew that it starts the communication between the Jetson Xavier and the pixhawk4 through port dev/ttyTHS0 and port Telem2.

I can control most of my function such as arm, disarm, switch to offboard mode, setpoint, switch to manual mode and receive gps position.

The only failure is to receive data from "vehicle_local_position". I thought it would be because the pixhawk is inside the office. I am developing everything inside the office. Only the gps module is hung outside the window and the pixhawk is still under the roof. I think it is the reason for the local_position_estimator not to run as the gps device inside the pixhawk4 did not receive gps signal.

I am going to test the jetson and pixhawk outside the office and test whether it can run local_position_estimator using the ssh terminal.

Dear Johnny: Would you please tell me how do you get gps position? Do you subscribe ''vehicle_gps_position" topic via ros2 on Jetson? I really need your help, expecting for your replying.Thanks. Best wishes.

[marios-stam]

Hello,

I have a similar problem, Whenever I have a GPS lock I can receive the /fmu/out/vehicle_global_position but nothing is published in the /fmu/out/vehicle_local_position.

Although data is being published in the px4 terminal whenever I use the listener vehicle_local_position

 vehicle_local_position
    timestamp: 4624743332 (0.011528 seconds ago)
    timestamp_sample: 4624741223 (2109 us before timestamp)
    ref_timestamp: 923902426
    ref_lat: 55.783786
    ref_lon: 12.516755
    x: -14.27505
    y: 3.84361
    z: 2.18724
    delta_xy: [-0.00006, -0.00005]
    delta_z: -0.82319
    vx: 0.19093
    vy: 0.01925
    vz: 0.00051
    z_deriv: 0.01710
    delta_vxy: [-0.00488, -0.01467]
    delta_vz: -0.01797
    ax: 0.03797
    ay: -0.02035
    az: -0.00985
    heading: -1.64592
    delta_heading: -0.46960
    ref_alt: 53.46507
    dist_bottom: 0.11249
    eph: 0.93882
    epv: 0.46626
    evh: 0.23305
    evv: 0.12988
    vxy_max: inf
    vz_max: inf
    hagl_min: inf
    hagl_max: inf
    xy_valid: True
    z_valid: True
    v_xy_valid: True
    v_z_valid: True
    xy_reset_counter: 2
    z_reset_counter: 2
    vxy_reset_counter: 2
    vz_reset_counter: 2
    heading_reset_counter: 3
    heading_good_for_control: False
    xy_global: True
    z_global: True
    dist_bottom_valid: False
    dist_bottom_sensor_bitfield: 0
    dead_reckoning: False

The output of the command ekf2 status is the following:

INFO  [ekf2] available instances: 8
INFO  [ekf2] 0: ACC: 3932170, GYRO: 3932170, MAG: 396825, healthy, test ratio: 0.0306457 (1.00000) 
INFO  [ekf2] 1: ACC: 4259850, GYRO: 4325386, MAG: 396825, healthy, test ratio: 0.0325211 (1.00000) 
INFO  [ekf2] 2: ACC: 3932170, GYRO: 3932170, MAG: 396809, healthy, test ratio: 0.0303879 (1.00000) 
INFO  [ekf2] 3: ACC: 4259850, GYRO: 4325386, MAG: 396809, healthy, test ratio: 0.0317324 (1.00000) 
INFO  [ekf2] 4: ACC: 3932170, GYRO: 3932170, MAG: 396825, healthy, test ratio: 0.0306722 (1.00000) 
INFO  [ekf2] 5: ACC: 4259850, GYRO: 4325386, MAG: 396825, healthy, test ratio: 0.0325178 (1.00000) 
INFO  [ekf2] 6: ACC: 3932170, GYRO: 3932170, MAG: 396809, healthy, test ratio: 0.0303931 (0.00000) *
INFO  [ekf2] 7: ACC: 4259850, GYRO: 4325386, MAG: 396809, healthy, test ratio: 0.0317454 (1.00000) 

ekf2:0 EKF dt: 0.0100s, attitude: 1, local position: 1, global position: 1
ekf2: ECL update: 481536 events, 376983us elapsed, 0.78us avg, min 1us max 257us 1.868us rms
ekf2: ECL full update: 481536 events, 131033920us elapsed, 272.12us avg, min 154us max 1400us 106.425us rms
ekf2: IMU message missed: 1 events
ekf2: vehicle_air_data messages missed: 0 events
ekf2: vehicle_gps_position messages missed: 0 events
ekf2: vehicle_magnetometer messages missed: 0 events

ekf2:1 EKF dt: 0.0090s, attitude: 1, local position: 1, global position: 1
ekf2: ECL update: 529594 events, 588849us elapsed, 1.11us avg, min 0us max 3519us 16.664us rms
ekf2: ECL full update: 530477 events, 226992325us elapsed, 427.90us avg, min 153us max 7090us 460.337us rms
ekf2: IMU message missed: 3029 events
ekf2: vehicle_air_data messages missed: 10 events
ekf2: vehicle_gps_position messages missed: 0 events
ekf2: vehicle_magnetometer messages missed: 0 events

ekf2:2 EKF dt: 0.0100s, attitude: 1, local position: 1, global position: 1
ekf2: ECL update: 481544 events, 456258us elapsed, 0.94us avg, min 1us max 366us 4.603us rms
ekf2: ECL full update: 481545 events, 134128066us elapsed, 278.54us avg, min 155us max 3575us 116.008us rms
ekf2: IMU message missed: 4 events
ekf2: vehicle_air_data messages missed: 0 events
ekf2: vehicle_gps_position messages missed: 0 events
ekf2: vehicle_magnetometer messages missed: 0 events

ekf2:3 EKF dt: 0.0090s, attitude: 1, local position: 1, global position: 1
ekf2: ECL update: 529609 events, 544438us elapsed, 1.03us avg, min 0us max 3428us 19.792us rms
ekf2: ECL full update: 530490 events, 230280288us elapsed, 434.09us avg, min 154us max 7271us 546.845us rms
ekf2: IMU message missed: 3028 events
ekf2: vehicle_air_data messages missed: 24 events
ekf2: vehicle_gps_position messages missed: 0 events
ekf2: vehicle_magnetometer messages missed: 0 events

ekf2:4 EKF dt: 0.0100s, attitude: 1, local position: 1, global position: 1
ekf2: ECL update: 458212 events, 341217us elapsed, 0.74us avg, min 0us max 283us 3.559us rms
ekf2: ECL full update: 458213 events, 168429979us elapsed, 367.58us avg, min 188us max 1385us 170.907us rms
ekf2: IMU message missed: 1 events
ekf2: vehicle_air_data messages missed: 0 events
ekf2: vehicle_gps_position messages missed: 0 events
ekf2: vehicle_magnetometer messages missed: 0 events

ekf2:5 EKF dt: 0.0090s, attitude: 1, local position: 1, global position: 1
ekf2: ECL update: 503732 events, 524217us elapsed, 1.04us avg, min 1us max 3641us 21.105us rms
ekf2: ECL full update: 504614 events, 268481453us elapsed, 532.05us avg, min 188us max 7258us 620.737us rms
ekf2: IMU message missed: 2997 events
ekf2: vehicle_air_data messages missed: 98 events
ekf2: vehicle_gps_position messages missed: 0 events
ekf2: vehicle_magnetometer messages missed: 0 events

ekf2:6 EKF dt: 0.0100s, attitude: 1, local position: 1, global position: 1
ekf2: ECL update: 458208 events, 417826us elapsed, 0.91us avg, min 0us max 405us 5.438us rms
ekf2: ECL full update: 458208 events, 140829455us elapsed, 307.35us avg, min 190us max 1383us 133.094us rms
ekf2: IMU message missed: 1 events
ekf2: vehicle_air_data messages missed: 0 events
ekf2: vehicle_gps_position messages missed: 0 events
ekf2: vehicle_magnetometer messages missed: 0 events

ekf2:7 EKF dt: 0.0090s, attitude: 1, local position: 1, global position: 1
ekf2: ECL update: 503713 events, 487342us elapsed, 0.96us avg, min 1us max 3723us 20.150us rms
ekf2: ECL full update: 504594 events, 235721296us elapsed, 467.15us avg, min 190us max 6530us 578.247us rms
ekf2: IMU message missed: 2997 events
ekf2: vehicle_air_data messages missed: 265 events
ekf2: vehicle_gps_position messages missed: 0 events
ekf2: vehicle_magnetometer messages missed: 0 events 

Could you please help me?