Open mengchaoheng opened 1 year ago
sample.launch
of vrpn_client_ros
<launch>
<arg name="server" default="localhost"/>
<node pkg="vrpn_client_ros" type="vrpn_client_node" name="vrpn_client_node" output="screen">
<rosparam subst_value="true">
server: $(arg server)
port: 3883
update_frequency: 100.0
frame_id: world
# Use the VRPN server's time, or the client's ROS time.
use_server_time: false
broadcast_tf: true
# Must either specify refresh frequency > 0.0, or a list of trackers to create
refresh_tracker_frequency: 1.0
#trackers:
#- FirstTracker
#- SecondTracker
</rosparam>
</node>
</launch>
px4.launch of mavros
<launch>
<!-- vim: set ft=xml noet : -->
<!-- example launch script for PX4 based FCU's udp://:14540@127.0.0.1:14557 udp://@192.168.101.60-->
<arg name="fcu_url" default="/dev/ttyUSB0:921600" />
<arg name="gcs_url" default="udp://@192.168.3.169 " />
<arg name="tgt_system" default="1" />
<arg name="tgt_component" default="1" />
<arg name="log_output" default="screen" />
<arg name="fcu_protocol" default="v2.0" />
<arg name="respawn_mavros" default="false" />
<include file="$(find mavros)/launch/node.launch">
<arg name="pluginlists_yaml" value="$(find mavros)/launch/px4_pluginlists.yaml" />
<arg name="config_yaml" value="$(find mavros)/launch/px4_config.yaml" />
<arg name="fcu_url" value="$(arg fcu_url)" />
<arg name="gcs_url" value="$(arg gcs_url)" />
<arg name="tgt_system" value="$(arg tgt_system)" />
<arg name="tgt_component" value="$(arg tgt_component)" />
<arg name="log_output" value="$(arg log_output)" />
<arg name="fcu_protocol" value="$(arg fcu_protocol)" />
<arg name="respawn_mavros" default="$(arg respawn_mavros)" />
</include>
</launch>
Is it because I didn't do this step?
Align your robot’s forward direction with the the system +x-axis.
Is this aligned to the x-axis of the ned or the x-axis of the mocap system?
I observed the log and found that the xyz coordinate system of /mavros/vision_pose/pose does not overlap with the real geographic ENU (X East, Y North, Z Up), but just a FLU (X Forward, Y Left) customized by the optitrack system , Z Up).
So the xyz coordinates of vehicle_visual_odometry_0 are not really NED (X North, Y East, Z Down).
Will this cause errors in ekf fusion? You can compare the xyz value of /mavros/vision_pose/pose with the xyz value of vehicle_visual_odometry_0 and find that they exchanged the xy axis and reversed the z axis, which is the credit of mavros. But why is the output of ekf wrong?
and maybe the problem is visual odometry latency?
This issue has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:
https://discuss.px4.io/t/error-in-local-positioning-of-pixhawk4-using-vicon-data/16011/46
@bresch @bkueng @dagar can you help me please!
It might be a stupid thing, but I always run mavros before I run the vrpn client and remap its data to /mavros/vision_pose/pose
, because I noticed before that if I ran mavros after, this behavior that you mentioned happened.
Try it out and let us know.
If I remember correctly EKF_AID_MASK
has to be set 280 on PX4 <1.13 or visual odometry information to be fused.
ekf2 status
? MAV_ODOM_LP
set to 1? If so do you see an Odometry MAVLink message being published by the autopilot? If it is, fusion is happening correctly. Regarding coordinate frames - MAVROS expects a position and orientation measurement in ENU axes, and perform an internal conversion into NED when turning it into a MAVLink message. It looks to me like you need an additional step in between to transform the FLU axes of your Mocap system into ENU first. If all this is correct, then your vehicle_odometry_aligned
message will be in NED axes, and they'll line up pretty much exactly with vehicle_local_position
.
You mentioned aligning the +x axis of the robot - this needs to be aligned with the global x-axis of the Mocap system, in whatever coordinate convention that the Mocap system uses. Then you need to figure out how to transform that into ROS ENU. For example if your Mocap system gives out coordinates in FLU, you'll need to apply a +270 degree rotation to positions and rotations about the Z axis first before publishing it into ROS.
- Once your system is running, what do you get when you go into the MAVLink shell and type
ekf2 status
?
later I will show you
- Is
MAV_ODOM_LP
set to 1? If so do you see an Odometry MAVLink message being published by the autopilot? If it is, fusion is happening correctly.
Yes! I can see Odometry MAVLink message when MAV_ODOM_LP =1
- Regarding coordinate frames - MAVROS expects a position and orientation measurement in ENU axes, and perform an internal conversion into NED when turning it into a MAVLink message. It looks to me like you need an additional step in between to transform the FLU axes of your Mocap system into ENU first. If all this is correct, then your
vehicle_odometry_aligned
message will be in NED axes, and they'll line up pretty much exactly withvehicle_local_position
.
From the logs, vehicle_odometry_aligned
messages are indeed in the NED axis, but they have nothing to do with vehicle_local_position
, ekf does not enable position fusion.
- You mentioned aligning the +x axis of the robot - this needs to be aligned with the global x-axis of the Mocap system, in whatever coordinate convention that the Mocap system uses. Then you need to figure out how to transform that into ROS ENU. For example if your Mocap system gives out coordinates in FLU, you'll need to apply a +270 degree rotation to positions and rotations about the Z axis first before publishing it into ROS.
In fact, the forward direction of my aircraft is not aligned with the x-axis of the mocap system, but the ekf is not enabled, which may not be the reason. My guess is that the startup sequence of vrpn node and mavros node is wrong, which needs to be verified.
I plot the timestamp of each data by MATLAB:
vehicle_visual_odometry=log.data.vehicle_visual_odometry_0{:,:};
sensor_combined=log.data.sensor_combined_0{:,:};
vehicle_magnetometer=log.data.vehicle_magnetometer_0{:,:};
vehicle_air_data=log.data.vehicle_air_data_0{:,:};
[len1,~]=size(sensor_combined);
[len2,~]=size(vehicle_visual_odometry);
[len3,~]=size(vehicle_magnetometer);
[len4,~]=size(vehicle_air_data);
t1=1:1:len1;
t2=1:1:len2;
t3=1:1:len3;
t4=1:1:len4;
figure,
plot(t1,sensor_combined(:,1),'k-');hold on;
plot(t2,vehicle_visual_odometry(:,1),'r-');hold on;
plot(t3,vehicle_magnetometer(:,1),'b');hold on;
plot(t4,vehicle_air_data(:,1),'k--');hold on;
legend('sensor combined','vehicle visual odometry','vehicle magnetometer','vehicle air data');
Download the log from flight_review, draw the same graph, one is gps , the other is mocap:
so, is the time is error?
a new log, everything is ok! But I don't know what hanppen.
https://logs.px4.io/plot_app?log=01dd3841-b0ce-4d85-bf79-67a8e1bafb06
Unfortunately, I have not been able to reproduce this problem, but after careful analysis of the log, I found two problems:
log:
Why does the height and v_z diverge before the ekf converges after the data of the mocap system is transmitted to the pixhawk through mavros?
There is apparently something strange happening with the accel bias when the vision fusion is starting.
The vision fusion got completely refactored and a lot of bugs were fixed recently, any chance you could try the same tests on the 1.14 release candidate?
test on v1.14.0-beta2, log is https://logs.px4.io/plot_app?log=faa63906-0a64-4a1d-bf8b-c8030fbc5aed
Problem:
[ERROR] [1682506410.410595161]: TM : Time jump detected. Resetting time synchronizer.
2.2 Start the aircraft first, then start ros/mavros, and the following will appear:
[ INFO ] [1682506535.766511963]: RP: mission received
[ERROR] [1682506537.214612200]: FCU: Preflight Fail: Yaw estimate error
[ERROR] [1682506539.297581967]: FCU: Preflight Fail: Yaw estimate error
[ERROR] [1682506542.068707017]: FCU: Preflight Fail: heading estimate not stable
[ERROR] [1682506542.236544900]: FCU: Preflight Fail: Yaw estimate error
[ INFO ] [1682506542.824510012]: HP: requesting home position
or
[ERROR] [1682507013.619805744]: FCU: Preflight Fail: height estimate error
[ERROR] [1682507015.676895252]: FCU: Preflight Fail: height estimate error
2.3 If the mocap data is broken in the middle, it will not be restored automatically. Mavros needs to be restarted, and a prompt appears again:
Preflight Fail: Yaw estimate error
In summary, the best way to use it is to start ros/mavros first and then start the flight control, and ensure that the mocap data is not interrupted.
The problem with v1.13.3 is the unreasonable visual odometer latency. log is https://logs.px4.io/plot_app?log=3ff36663-37c3-4605-9953-80b82c373c33
@bresch
In "test on v1.14.0-beta2, log is https://logs.px4.io/plot_app?log=faa63906-0a64-4a1d-bf8b-c8030fbc5aed" it looks like both mag and ev_yaw fusions are active at the same time. This isn't right, I'll investigate a bit.
The mag is enabled because you have MAV_FRAME set to NED and the mag doesn't agree with the attitude sent by the optitrack. If it's really NED and that the mag is wrong, you can disable it using EKF2_MAG_TYPE
, otherwise set the MAV_FRAME to FRD (the ekf will then only use the vision data).
This issue has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:
https://discuss.px4.io/t/px4-community-q-a-june-28-2023/32873/8
Hi! I am currently trying to feed visual (mocap) feedback through the uxrce by publishing on the topic /fmu/in/vehicle_visual_odometry. It works with a cube orange flight controller, but I cannot switch in position (local position estimation not valid) with a Pixhawk 6c. Both boards are flashed with the latest release. I am wondering if it could be related to the CONFIG_EKF2_EXTERNAL_VISION not being set to true in the bootloader. Any suggestions? Someone made it work?
Thanks!
Describe the bug
I use optitrack as an external position reference, but it seems that ekf is not using position data.
To Reproduce
follow the guide and https://risc.readthedocs.io/1-indoor-flight.html
on my companion computer, run
I can receive Mocap data under topic
/vrpn_client_node/<rigid_body_name>/pose
by runrostopic echo /vrpn_client_node/RigidBody/pose
run
rostopic echo /mavros/vision_pose/pose
, (Not run at the same time as the command that prints/vrpn_client_node/RigidBody/pose
.), so the update time interval is about 20ms?and in the log, we can see the
vehicle_visual_odometry_0
data isExpected behavior
The state of the state estimator(EKF) should directly have a simple coordinate transformation relationship with the external visual position data.
Log Files and Screenshots
The log is here
As shown by the Visual Odometry position data, I pick up the plane, go east, go back near the origin, then go north, return to the origin and put down the plane. The data released by optitrack has been set correctly. At this time, the yaw angle is close to 75 degrees, so roughly the local position data should be exchanged with the x and y axes of the Visual Odometry position data (of course, the z axis is opposite). But the log shows that this is not the case.
Drone (please complete the following information):