search

cedricxie / apollo_perception_ros

Object detection / tracking / fusion based on Apollo r3.0.0 perception module in ROS
287 stars 119 forks source link

A bug for coordinate transform #11

Open hzdsdhr opened 5 years ago

hzdsdhr commented 5 years ago

Hi, I think there is a bug for coordinate transform in lidar_process, check the code in lidar_process.cpp 255~260(bool LidarProcess::GetSensorTrans(const double query_time, Matrix4d* trans)): try { tf2listener.lookupTransform(FLAGS_lidar_tf2_frame_id, FLAGS_lidar_tf2_child_frame_id, query_stamp, stamped_transform); } catch (tf2::TransformException& ex) { AERROR << "Exception: " << ex.what(); return false; } This function trys to get the sensor's pose and location to transform all the objects into a global coordinate like /world for latter tracking. So "FLAGS_lidar_tf2_child_frame_id" should be like "velodyne"(or something like that), and "FLAGS_lidar_tf2_frame_id" should be a global frame like "/world". But by checking gflags file perception_gflags.cc in src/perception/apollo_perception_ros/src/common/, I found this: DEFINE_string(lidar_tf2_frame_id, "base_link", "the tf2 transform frame id"); DEFINE_string(lidar_tf2_child_frame_id, "velodyne64", "the tf2 transform child frame id"); So FLAGS_lidar_tf2_frame_id is "base_link". First of all, there is no such frame in Apollo. Apollo's frame is like:velodyne64->novatel->world. Second, by reading other code, the base_link is more like vehicle body frame. So This transform won't transform objects in velodyne frame into world frame but the base_link(vehicle frame). This is not correct for tracking, because tracking should happen in a fix(not moving) frame. Please check and tell me if I'm right or not.

hzdsdhr commented 5 years ago

@cedricxie can you take a look and feed back? Thank you.