vectr-ucla / direct_lidar_odometry

[IEEE RA-L & ICRA'22] A lightweight and computationally-efficient frontend LiDAR odometry solution with consistent and accurate localization.
MIT License
882 stars 186 forks source link

Coordinate Frame #6

Closed danieldive closed 2 years ago

danieldive commented 2 years ago

Hi,

Thank you for sharing this great work.

I've set of problem such as defining the coordinate system of the odometry . Which coordinate frame do you use for odometry NED or BODY. I thought you use NED coordinate frame so that I expected when I move Lidar + IMU to the North direction, x should be positive increased but it has not been stable behaviour. I also moved the system to the East direction it should be caused positive increase on y axis but same problem. I think you use BODY frame or something different coordinate frame for odometry.

I wonder also how do you send odometry information to the autopilot of drone. I prefered mavros and selected the related odometry ros topic and send them without change so I saw the odometry message in the autopilot but when odometry receive to the autopilot of drone it looks like x and y exchanged in autopilot even they are not exchanged odometry output of direct lidar odometry.

Summary of the Question is that which coordinate frame do you use for odometry ? How can I set up the odometry frame to NED? x and y are negative decreased when I move lidar+imu to the North and the East respectively. and Z looks like 180 reversed. Should I multiply x and y with minus or apply rotation matrix to fix negative decreasing x, y odometry ?

How can I ensure that autopilot and your odometry coordinate plane are in the same coordinate plane ?

kennyjchen commented 2 years ago

Hi @danieldive -- thanks for your interest in our work. We use ROS convention (forward left up) as our coordinate system, as defined in REP 103 here: https://www.ros.org/reps/rep-0103.html#coordinate-frame-conventions

The output odometry is relative to the starting location, which is what we define as the origin. I may need more information on your specific setup, but it sounds like a transformation between the ROS convention and your desired coordinate system is needed, as you mentioned.

Let me know if that helps.

danieldive commented 2 years ago

Thank you @kennyjchen Sorry to resuscitate ! In which coordinate frame do you provide your FRD odometry to autopilot. I assume you've used px4 as a autopilot so did you enable external vision rotation to able to take off drone ? It seems that autopilot needs odometry in NED coordinate frame although px4 do FRD to NED transformation by choosing rotation external vision at the parameter section, do you have any other transformation in another module except in slam and autopilot software. I saw no drift your flight video but in reality especially when the slam algorithm exploring new places ( like when you pass an edge ) drift is beginning.

kennyjchen commented 2 years ago

Hi @danieldive -- we have a custom autopilot solution and use NWU, so we don't apply a transformation between odometry and our autopilot. It sounds like if another coordinate frame is needed, you can apply a transformation upstream of the autopilot. Alternatively, you could also try transforming the raw point cloud data (which is usually in ROS convention) into FRD to get the odometry into NED for your PX4.