Using Mocap with ROS 2 for Starling 2
-
The flight cage I am using has an Optitrack motion capture camera system installed that communicates my Starling 2 drone's position data on the LAN using NatNet protocol. I have a ROS 2 package on my computer that can receive this data. I plan to transmit this data to the drone after it has been converted to the appropriate format. By referencing this guide, I see that mocap data should be published to the
vehicle_visual_odometrytopic. When PX4 is running on the drone, I can access the ROS 2 topic/fmu/in/vehicle_visual_odometry. However,when I publish test data to this topic it does not have any obvious effect. By using theros2 topic echocommand I can see that the data is indeed getting published. However, echoing the /fmu/out commands return nothing, including the commands that are supposed to return the drone's position.Publishing to /fmu/in/vehicle_visual_odometry
Listening to /fmu/in/vehicle_visual_odometry while publishing topic
Attempting to listen to /fmu/out topics
When I disable PX4 with
systemctl disable voxl-px4I am able to view the data from these /fmu/out topics. But still, publishing to vehicle_visual_odometry does not change the /fmu/out readings that display vehicle position.Images of /fmu/out commands when not publishing to /fmu/in/vehicle_visual_odometry
when publishing to /fmu/in/vehicle_visual_odometry
-
@labkit can you confirm if you have VIO actively going as well? There could be competing information for incoming odometry messages - can you send a screenshot of
voxl-inspect-servicesand then also show what you have for the value of ekf2_ev_ctrl.Thanks!
Zach -
@Zachary-Lowell-0 I said yesterday that echoing the /fmu/out topics only worked if voxl-px4 was disabled on startup and run in a terminal with voxl-px4. This no longer appears to be the case, although I don't know what changed from yesterday to cause this. Now
ros2 topic echocan print those topics when px4 is launched at startup. However, the topics still don't print the data I would expect if the drone were correctly reading the data I publish to/fmu/in/visual_odometry, unchanged from yesterday.The qvio server was on. I disabled it, but that didn't fix the issue of the drone not using the data from /fmu/in/vehicle_visual_odometry. I believe that shutting down this server should disable VIO, correct? This is the output after disabling qvio server and having px4 enabled to launch at startup.
Here is the output of /fmu/out/vehicle odometry when I am not publishing to /fmu/in/vehicle_visual_odometry
And here is the output when I am publishing to it using the command
topic pub /fmu/in/vehicle_visual_odometry px4_msgs/msg/VehicleOdometry '{timestamp: 1234567890, timestamp_sample: 1, pose_frame: 1, position: [1.23, 4.56, 7.89], q: [0.707, 0.707, 0.0, 0.0], velocity_frame: 1, velocity: [0.5, 1.0, -2.3], angular_velocity: [0.1, 0.2, -0.3], position_variance: [0.01, 0.02, 0.03], orientation_variance: [0.001, 0.002, 0.003], velocity_variance: [0.005, 0.01, 0.02], reset_counter: 0, quality: 1}'which is supposed to provide it with test mocap data.
This is the value of ekf2_ev_ctrl from QGroundControl.
-
Understood - ofcourse disabling wont do much as it is the same thing as running it from command line/bash vs in systemd - I am surprised it created different results when running in systemd vs bash.
Reason I want to disable/stop qvio is so that when you echo the /out topic you arent receiving anything from the ekf2 inside PX4 that is ingesting and creating the output.
Lastly, the fmu/in/visual_odometry, and fmu/out/visual_odometry are not supposed to be the same - the fmu/out is post processing - they should differ as it fuses all sensor data and such - what is the movement you are expecting?
Also have you checked the yaml file for PX4 - looks like there is a ros2 message specific just for mocap odometry.
