-
Notifications
You must be signed in to change notification settings - Fork 13.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[PLEASE DO MERGE] ECL reference frame alignment fix #12771
Conversation
72008a3
to
e3981b8
Compare
e3981b8
to
8a3b222
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Small changes, otherwise I think it is OK. It would be great to have a log from Flight Review attached.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, rebase and we'll get this in
msg/vehicle_odometry.msg
Outdated
float32[4] q # Quaternion rotation from NED earth-fixed frame to XYZ body frame | ||
float32[4] q # Quaternion rotation from FRD body frame to fixed frame | ||
|
||
float32[4] q_err # Quaternion rotation from odometry's fixed frame to local_origin_frame |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
q_odom
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about q_offset?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think you need a new topic just to propagate the aligned frame. A simple field stating the alignment is enough. Use the vehicle_visual_odometry
.
src/modules/ekf2/ekf2_main.cpp
Outdated
@@ -286,6 +290,7 @@ class Ekf2 final : public ModuleBase<Ekf2>, public ModuleParams | |||
uORB::Publication<wind_estimate_s> _wind_pub{ORB_ID(wind_estimate)}; | |||
uORB::PublicationData<vehicle_global_position_s> _vehicle_global_position_pub{ORB_ID(vehicle_global_position)}; | |||
uORB::PublicationData<vehicle_local_position_s> _vehicle_local_position_pub{ORB_ID(vehicle_local_position)}; | |||
uORB::PublicationData<vehicle_odometry_s> _vehicle_aligned_visual_odometry_pub{ORB_ID(vehicle_aligned_visual_odometry)}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No need for a new message.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@TSC21 I think this would be cleaner than using instances to publish this, especially because you could potentially have multiple odometry sources. Also, we generally don't change a topic and re-publish it under a new instance, right?
@kamilritz you have https://github.com/PX4/Firmware/blob/master/msg/vehicle_odometry.msg#L21. Just set the frame to |
4ddc9ef
to
8ea7e75
Compare
@TSC21 I added the vehicle_visual_odometry as a multi instance topic. Instance 0 is the original visual odometry, while instance 1 is the aligned odometry. This way we can log the both instances of the odometry message and plot them for analysis. |
@@ -59,9 +59,10 @@ class PublicationMulti | |||
* @param meta The uORB metadata (usually from the ORB_ID() macro) for the topic. | |||
* @param priority The priority for multi pub/sub, 0 means don't publish as multi | |||
*/ | |||
PublicationMulti(const orb_metadata *meta, uint8_t priority = ORB_PRIO_DEFAULT) : | |||
PublicationMulti(const orb_metadata *meta, uint8_t priority = ORB_PRIO_DEFAULT, int instance = 0) : |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure we are supposed to change these. @dagar can you comment?
2227e10
to
2697786
Compare
@jkflying can we get this is in. |
I think the change on |
1b9ee35
to
d8c00f3
Compare
@TSC21 I reverted some of the commits such that we have now again vehicle_aligned_visual_odometry and no multi instance topic any more. |
For what reason? |
It's to be more in line with how we deal with other topics like the obstacle_distance, where we have the _fused version. Using the same topic for both input and output can be confusing. |
I have said this to @kamilritz on Slack but I can say it here as well: The only issue I see with this is that RTPS will not work with multi topics. That means that if we want to send mocap data through ROS2, you won't be able to use multi instances. While using with aliases it would work right. One of the main reasons it was opted to use aliases with this is that you could send mocap or vision data from RTPS/ROS and that would be handled differently on the system because the aliases would be taken as different topics in the RTPS stream. I would say that's ok because you won't send mocap and vision at the same time. But if for some reason you wanted to record groundtruth in ulog, you won't be able to do it, at least using RTPS. |
src/modules/ekf2/ekf2_main.cpp
Outdated
sqrtf(fmaxf(ev_odom.pose_covariance[ev_odom.COVARIANCE_MATRIX_ROLL_VARIANCE], | ||
fmaxf(ev_odom.pose_covariance[ev_odom.COVARIANCE_MATRIX_PITCH_VARIANCE], | ||
ev_odom.pose_covariance[ev_odom.COVARIANCE_MATRIX_YAW_VARIANCE])))); | ||
sqrtf(fmaxf(_ev_odom.pose_covariance[_ev_odom.COVARIANCE_MATRIX_ROLL_VARIANCE], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we only fuse yaw, this should be the yaw variance only.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
agree. will add this
msg/vehicle_odometry.msg
Outdated
@@ -29,7 +29,8 @@ float32 y # East position | |||
float32 z # Down position | |||
|
|||
# Orientation quaternion. First value NaN if invalid/unknown | |||
float32[4] q # Quaternion rotation from NED earth-fixed frame to XYZ body frame | |||
float32[4] q # Quaternion rotation from FRD body frame to fixed frame | |||
float32[4] q_offset # Quaternion rotation from odometry's fixed frame to local_origin NED frame |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about "Quaternion rotation from odometry fixed frame to navigation frame."
src/modules/ekf2/ekf2_main.cpp
Outdated
for (unsigned i = 0; i < 4; i++) { | ||
aligned_ev_odom.q[i] = ev_quat_aligned(i); | ||
aligned_ev_odom.q_offset[i] = quat_ev2ekf(i); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use copyTo here?
src/modules/ekf2/ekf2_main.cpp
Outdated
aligned_ev_odom.vy = aligned_vel(1); | ||
aligned_ev_odom.vz = aligned_vel(2); | ||
|
||
// Compute orientation in local_origin_NED frame |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Prefer "navigation frame"
src/modules/ekf2/ekf2_main.cpp
Outdated
|
||
vehicle_odometry_s aligned_ev_odom = _ev_odom; | ||
|
||
// Rotate external position and velocity into local_origin_NED frame |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Prefer "navigation frame"
src/modules/ekf2/ekf2_main.cpp
Outdated
// publish external visual odometry after fixed frame alignment if new odometry is received | ||
if (new_ev_data_received) { | ||
float q_ev2ekf[4]; | ||
_ekf.get_ev2ekf_quaternion(q_ev2ekf); // rotates from EV to EKF reference frame |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Prefer "EKF navigation frame"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@kamilritz Build is broken - can you please fix and post a quick test log with the fixed state? |
@@ -56,4 +56,4 @@ float32 yawspeed # Angular velocity about Z body axis | |||
# If angular velocity covariance invalid/unknown, 16th cell is NaN | |||
float32[21] velocity_covariance | |||
|
|||
# TOPICS vehicle_odometry vehicle_mocap_odometry vehicle_visual_odometry vehicle_aligned_visual_odometry | |||
# TOPICS vehicle_odometry vehicle_mocap_odometry vehicle_visual_odometry vehicle_visual_odometry_aligned |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if mocap is not aligned?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are people still using it? At the moment it is used only in LPE and Attitude estimator.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can just call it vehicle_odometry_aligned
. I don't think anyone will be using mocap and VO simultaneously as a source of odometry. Maybe as groundtruth, but that is beyond the scope of this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
vehicle_odometry_aligned
will be messed with the vehicle_odometry
, which is curre tly being used as the feedback of the estimator. Let's keep it this way for now.
Why was this merged? It's still missing the RTPS ID for the new alias. Note to self: have to make it mandatory. |
This includes a update in ECL that fixes the alignment between an external vision reference frame and the EKF reference frame. In addition to the ECL update, this also adds a new odometry topic on which now the aligned visual odometry is published from ekf_main.cpp
This has been tested extensively.
The wrong alignment of the reference frame made fusion of GPS and external vision pose information impossible.
The correct alignment of the visual odometry was tested on several recorded logs:
Note: the jump in the external vision quaternion is due to the handling of non canonical quaternion by the external vision sensor.