Connecting Motion Capture Data to VOXL (No Postion Estimate)
-
Hello,
We are trying to incorporate motion capture data into the VOXL2 (m0054) in order to fly in position mode. We are using ROS 1 and taking motion capture data, processing and stamping the data onboard the VOXL and publishing it to /mavros/vision_pose/pose. We are seeing data streaming on /mavros/vision_pose/pose when echoing with rostopic echo /mavros/vision_pose/pose. Also when we use px4-listener to listen to vehicle_visual_odometry on the px4 side, we are also seeing data. However, in QGC, it reports no valid local position estimate (in position mode), and EKF2 does not appear to be using the vision data at all. We're not sure what is going wrong where EKF2 is not accepting the information. We've tried following for mocap data on the PX4 documentation along with following along with this forum post.
We have a suspicion that the timestamps might be messed up between MAVROS and PX4 but are unsure. We are seeing weird values when we look at the uORB messages using px4-listener (sample attached below).
Do you have any idea what we might be doing wrong?
VOXL Suite Version: 1.4.1
Sample Vehicle Visual Odometry uORB with report saying "timestamp_sample" in the future relative to timestamp
EKF2 Status
-
@Andrew-Jue How is EKF2_EV_CTRL set in PX4?
-
@Eric-Katzfey It's set to 11 (Horiztonal Postion, Vertical Position, Yaw)
-
@Andrew-Jue Have you made sure that no other service is running that can send odometry messages that conflict with to MAVROS ones? But, yes, you have a good point about the timestamps. PX4 on VOXL 2 runs on "DSP time", not apps proc time so there is a big delta (that moves over time) between standard Linux time and what PX4 uses. That's why we use the timesync protocol to align times between our applications (like VIO) on Linux with PX4 running on DSP.
-
@Eric-Katzfey I don't think that there's anything that should be interfering with MAVROS, though I'm not familiar enough with the VOXL services to know if there's one I need to be worried about. I've attached a screen capture of "voxl-inspect-services" along with the voxl-vision-hub.conf, voxl-px4.conf, voxl-mavlink-server.conf files in case you spot anything that's amiss with them.
voxl-vision-hub.conf:
{ "config_file_version": 1, "en_localhost_mavlink_udp": true, "localhost_udp_port_number": 14551, "en_vio": false, "vio_pipe": "qvio", "secondary_vio_pipe": "ov", "vfc_vio_pipe": "ov", "en_reset_vio_if_initialized_inverted": true, "vio_warmup_s": 3, "send_odom_while_failed": true, "horizon_cal_tolerance": 0.5, "en_hitl": false, "offboard_mode": "off", "follow_tag_id": 0, "figure_eight_move_home": true, "robot_radius": 0.300000011920929, "collision_sampling_dt": 0.1, "max_lookahead_distance": 1, "backtrack_seconds": 60, "backtrack_rc_chan": 8, "backtrack_rc_thresh": 1500, "wps_move_home": true, "wps_stride": 0, "wps_timeout": 0, "wps_damp": 1, "en_tag_fixed_frame": false, "fixed_frame_filter_len": 5, "en_transform_mavlink_pos_setpoints_from_fixed_frame": false, "vfc_rate": 100, "vfc_rc_chan_min": 980, "vfc_rc_chan_max": 2020, "vfc_thrust_ch": 3, "vfc_roll_ch": 1, "vfc_pitch_ch": 2, "vfc_yaw_ch": 4, "vfc_submode_ch": 6, "vfc_alt_mode_rc_min": 0, "vfc_alt_mode_rc_max": 0, "vfc_flow_mode_rc_min": 0, "vfc_flow_mode_rc_max": 0, "vfc_hybrid_flow_mode_rc_min": 0, "vfc_hybrid_flow_mode_rc_max": 0, "vfc_position_mode_rc_min": 0, "vfc_position_mode_rc_max": 2100, "vfc_traj_mode_rc_min": 0, "vfc_traj_mode_rc_max": 0, "vfc_yaw_deadband": 30, "vfc_vxy_deadband": 50, "vfc_vz_deadband": 150, "vfc_min_thrust": 0, "vfc_max_thrust": 0.800000011920929, "vfc_tilt_max": 0.43599998950958252, "vfc_yaw_rate_max": 3, "vfc_thrust_hover": 0.5, "vfc_vz_max": 1, "vfc_kp_z": 5.2899999618530273, "vfc_kd_z": 5.9800000190734863, "vfc_vxy_max": 3, "vfc_kp_xy": 0.63999998569488525, "vfc_kd_xy": 2.559999942779541, "vfc_kp_z_vio": 5.2899999618530273, "vfc_kd_z_vio": 5.9800000190734863, "vfc_kp_xy_vio": 3.2400000095367432, "vfc_kd_xy_vio": 3.9600000381469727, "vfc_w_filt_xy_vio": 10, "vfc_vel_ff_factor_vio": 0.899999976158142, "vfc_xy_acc_limit_vio": 2.5, "vfc_max_z_delta": 3, "vfc_att_transition_time": 0.5, "vfc_stick_move_threshold": 30, "vfc_flow_transition_time": 1, "vfc_q_min": 10, "vfc_points_min": 7, "vfc_en_submode_announcement": 1, "vfc_disable_fallback": false, "vfc_traj_csv": "/data/voxl-vision-hub/traj.csv", "en_voa": true, "voa_upper_bound_m": -0.15000000596046448, "voa_lower_bound_m": 0.15000000596046448, "voa_voa_memory_s": 1, "voa_max_pc_per_fusion": 100, "voa_pie_max_dist_m": 20, "voa_pie_min_dist_m": 0.25, "voa_pie_under_trim_m": 1, "voa_pie_threshold": 3, "voa_send_rate_hz": 20, "voa_pie_slices": 36, "voa_pie_bin_depth_m": 0.15000000596046448, "voa_inputs": [{ "enabled": true, "type": "point_cloud", "input_pipe": "dfs_point_cloud", "frame": "stereo_l", "max_depth": 8, "min_depth": 0.300000011920929, "cell_size": 0.079999998211860657, "threshold": 4, "x_fov_deg": 68, "y_fov_deg": 56, "conf_cutoff": 0 }, { "enabled": true, "type": "point_cloud", "input_pipe": "stereo_front_pc", "frame": "stereo_front_l", "max_depth": 8, "min_depth": 0.300000011920929, "cell_size": 0.079999998211860657, "threshold": 4, "x_fov_deg": 68, "y_fov_deg": 56, "conf_cutoff": 0 }, { "enabled": true, "type": "point_cloud", "input_pipe": "stereo_rear_pc", "frame": "stereo_rear_l", "max_depth": 8, "min_depth": 0.300000011920929, "cell_size": 0.079999998211860657, "threshold": 4, "x_fov_deg": 68, "y_fov_deg": 56, "conf_cutoff": 0 }, { "enabled": true, "type": "tof", "input_pipe": "tof", "frame": "tof", "max_depth": 6, "min_depth": 0.15000000596046448, "cell_size": 0.079999998211860657, "threshold": 3, "x_fov_deg": 106.5, "y_fov_deg": 85.0999984741211, "conf_cutoff": 125 }, { "enabled": true, "type": "rangefinder", "input_pipe": "rangefinders", "frame": "body", "max_depth": 8, "min_depth": 0.300000011920929, "cell_size": 0.079999998211860657, "threshold": 4, "x_fov_deg": 68, "y_fov_deg": 56, "conf_cutoff": 0 }] }voxl-px4.conf
AIRFRAME=MULTICOPTER GPS=NONE RC=M0065_SBUS ESC=VOXL2_IO_PWM_ESC POWER_MANAGER=VOXLPM AIRSPEED_SENSOR=NONE DISTANCE_SENSOR=NONE OSD=DISABLE DAEMON_MODE=ENABLE SENSOR_CAL=ACTUAL ARTIFACT_MODE=DISABLE EXTRA_STEPS=()voxl-mavlink-server.conf
{ "primary_static_gcs_ip": "192.168.8.10", "secondary_static_gcs_ip": "192.168.8.11", "onboard_port_to_autopilot": 14556, "onboard_port_from_autopilot": 14557, "gcs_port_to_autopilot": 14558, "gcs_port_from_autopilot": 14559, "en_external_uart_ap": false, "autopilot_uart_bus": 1, "autopilot_uart_baudrate": 921600, "autopilot_mission_delay_start": -1, "autopilot_mission_delay_sound": false, "autopilot_mission_notif_dur": 0.1, "en_external_ap_timesync": 1, "en_external_ap_heartbeat": 1, "udp_mtu": 0, "gcs_timeout_s": 4.5 } -
@Andrew-Jue I think there are a couple of issues. One is the timestamp issue. You can see here that px4 tries to align the timestamps with timesync information: https://github.com/modalai/px4-firmware/blob/2bbaa6875fedff9c9bc8282a35c4cbb5612046ea/src/modules/mavlink/mavlink_receiver.cpp#L1251. The next issue is that ekf2 doesn't deal with the mocap odometry directly, it relies on the local position estimator module to process that and that module is not included in our build.
-
@Eric-Katzfey So I see that the firmware is supposed to apply the estimated offset to the timestamp to make sure that the timestamps align. Is there a way to change or correct the timesync system if it isn't correct (as seems to be the case here)? Or at least check the timesync status?
And regarding the mocap position estimate, is the local position estimator module you are referring to this LPE estimator referred to in the PX4 documentation or is it a different module specifically for EKF2? I'm just trying to get an understanding of what is going on, especially since it seems like in the documentation from PX4, there's a choice to either use the LPE or EKF2 with slightly different parameters and workflows for each.
Regardless, what method would you recommend for getting mocap position data sent to PX4? Is there a service in VOXL that we could try to route the position data through from ROS that would work better?
-
@Andrew-Jue Unfortunately, we have never tried anything with a mocap system. I was just tracing through the code to try to see what kind of issues there might be. You can see how our voxl-mavlink-server application handles the timesync protocol here: https://gitlab.com/voxl-public/voxl-sdk/services/voxl-mavlink-server/-/blob/master/src/mavlink_services.c?ref_type=heads#L48
-
@Eric-Katzfey I did some more troubleshooting on my own, and I think I've tracked the problem down to voxl-mavlink-server. If I disable voxl-mavlink-server using "systemctl stop voxl-mavlink-server" and start mavros pointing to the UDP ports that voxl-mavlink-server connects to (14556/14557), then I get properly timestamped messages. Looking at the estimator status (px4-listener estimator_status), EKF2 is happily accepting the mocap data.
Running voxl-mavlink-server directly in the terminal with the "-t" parameter to debug timesync protocol handling, it seems like voxl-mavlink-server is intercepting the timesync messages that mavros is trying to send to PX4. This results in MAVROS not being able to estimate the offset to the PX4 clock and stamp it's messages correctly.
I've tried running voxl-vision-hub and voxl-mavlink-server directly in terminal with debug print statements to see what is going on, and it seems like there's an issue with the timesync requests coming from the onboard pipe as opposed to the autopilot. I've attached some samples below:
Standard Timesync request from autopilot
from APob ID: 111 to APob ID: 111 timesync: now-ts1 =-2360.9ms to APob ID: 111 sending our own ts request at 8420226379035 from APob ID: 111 ap ms ahead of voxl: 2361.1msTimesync request from MAVROS
onboard pipe ID: 111 compid: 240 to APob ID: 111 from APob ID: 111 unknown timesync request ts1 = 1744850282998741263 tc1 = 8422617042000 last_voxl_time_sent = 8420226379035There's no final response sending the timesync message (ID:111) back through the onboard pipe to MAVROS.
Looking at voxl-vision-hub and filtering out for just timesync messages
There's only messages to the autopilot, but none coming back. I think that's why our MAVROS timestamps are off; it is not syncing with PX4 correctly.Can you help me figure out how to get the MAVROS timesync requests sent properly so that MAVROS receives the server-side response?
-
@Andrew-Jue I'll take a look. Have you seen this page? https://docs.modalai.com/mavlink/ Can you try leaving voxl-mavlink-server running and try to connect to port 14550 as a "GCS" and see if that helps?
-
@Andrew-Jue Do you need voxl-vision-hub? If you aren't using VIO, obstacle detection, or offboard mode then you can disable it. And try setting en_external_ap_timesync in voxl-mavlink-server.conf to false. I think that will prevent it from intercepting those timesync messages. This is just for the onboard connection. If you use GCS connection then I think there is no intercepting of timesync messages to worry about.
-
@Eric-Katzfey Thank you for the help! Setting en_external_ap_timesync in voxl-mavlink-server.conf to false allows the timesync messages to go through. I didn't need to disable voxl-vision-hub in order to get the timestamp messages.
For future reference, what does the should the fcu_url be to connect from the onboard (Linux side) to the PX4 through the GCS connection? Or is it possible at all? I get errors saying that the address is already in use whenever I'm trying to use port 14550 from the onboard computer. Things work fine running mavros from a different computer or by keeping voxl-vision-hub active.
-
@Andrew-Jue You can use any port you like but you are connecting to port 14550 as a GCS. So you can''t use 14550 or else you'll get the port already in use error.
-
@Eric-Katzfey Okay, thanks again for all your help!
