Skip to content
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

Merged
merged 8 commits into from
Sep 23, 2019

Conversation

kamilritz
Copy link
Contributor

@kamilritz kamilritz commented Aug 22, 2019

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:
AID_MASK_65
Note: the jump in the external vision quaternion is due to the handling of non canonical quaternion by the external vision sensor.

@kamilritz kamilritz force-pushed the aligned_vehicle_odometry branch from 72008a3 to e3981b8 Compare August 23, 2019 06:38
@kamilritz kamilritz changed the title [WIP] aligned visual odometry ECL reference frame alignment fix Aug 23, 2019
@kamilritz kamilritz force-pushed the aligned_vehicle_odometry branch from e3981b8 to 8a3b222 Compare August 29, 2019 13:59
Copy link
Contributor

@jkflying jkflying left a 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.

src/modules/ekf2/ekf2_main.cpp Outdated Show resolved Hide resolved
src/modules/ekf2/ekf2_main.cpp Show resolved Hide resolved
jkflying
jkflying previously approved these changes Aug 30, 2019
Copy link
Contributor

@jkflying jkflying left a 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

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't like this name. @jkflying @TSC21 any other naming ideas for this?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

q_odom?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about q_offset?

Copy link
Member

@TSC21 TSC21 left a 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.

@@ -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)};
Copy link
Member

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.

Copy link
Contributor

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?

@TSC21
Copy link
Member

TSC21 commented Aug 30, 2019

@kamilritz you have https://github.com/PX4/Firmware/blob/master/msg/vehicle_odometry.msg#L21. Just set the frame to OTHER and add a verification on the ekf2_main to apply the alignment or not.

@kamilritz
Copy link
Contributor Author

kamilritz commented Sep 9, 2019

@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.
! DO NOT MERGE: Making vehicle_visual_odometry as a multi instance topics breaks the EKF replay

@@ -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) :
Copy link
Member

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?

@TSC21 TSC21 requested a review from dagar September 9, 2019 12:19
@kamilritz kamilritz changed the title ECL reference frame alignment fix [DO NOT MERGE] ECL reference frame alignment fix Sep 11, 2019
@kamilritz kamilritz force-pushed the aligned_vehicle_odometry branch from 2227e10 to 2697786 Compare September 19, 2019 12:21
@kamilritz kamilritz changed the title [DO NOT MERGE] ECL reference frame alignment fix [PLEASE DO MERGE] ECL reference frame alignment fix Sep 19, 2019
@kamilritz
Copy link
Contributor Author

@jkflying can we get this is in.

@TSC21
Copy link
Member

TSC21 commented Sep 19, 2019

I think the change on PublicationMulti should be verified first. @dagar

@kamilritz kamilritz force-pushed the aligned_vehicle_odometry branch from 1b9ee35 to d8c00f3 Compare September 23, 2019 10:47
@kamilritz
Copy link
Contributor Author

@TSC21 I reverted some of the commits such that we have now again vehicle_aligned_visual_odometry and no multi instance topic any more.

@TSC21
Copy link
Member

TSC21 commented Sep 23, 2019

@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?

@jkflying
Copy link
Contributor

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.

@TSC21
Copy link
Member

TSC21 commented Sep 23, 2019

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.

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],
Copy link
Member

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agree. will add this

@@ -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
Copy link
Member

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."

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);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use copyTo here?

aligned_ev_odom.vy = aligned_vel(1);
aligned_ev_odom.vz = aligned_vel(2);

// Compute orientation in local_origin_NED frame
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Prefer "navigation frame"


vehicle_odometry_s aligned_ev_odom = _ev_odom;

// Rotate external position and velocity into local_origin_NED frame
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Prefer "navigation frame"

// 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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Prefer "EKF navigation frame"

mhkabir
mhkabir previously approved these changes Sep 23, 2019
Copy link
Member

@mhkabir mhkabir left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@mhkabir
Copy link
Member

mhkabir commented Sep 23, 2019

@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
Copy link
Member

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?

Copy link
Contributor Author

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.

Copy link
Member

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.

Copy link
Member

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.

@mhkabir mhkabir merged commit 7427768 into PX4:master Sep 23, 2019
@TSC21
Copy link
Member

TSC21 commented Sep 23, 2019

Why was this merged? It's still missing the RTPS ID for the new alias.

Note to self: have to make it mandatory.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants