Added missing transform of start and target pose in planner implementations #95
Conversation
|
When setting the goal pose in the odom frame (after driving around some time to accumulate odom drift) the last pose of the returned plan is not correct: |
JustusBraun
left a comment
JustusBraun
left a comment
There was a problem hiding this comment.
@amock if you agree with the comments I can do the implementation (or let copilot try it :D)
mesh_map/src/mesh_map.cpp
Outdated
|
|
||
| // we shouldn't catch/ignore the error that comes from here, as it indicates a misconfiguration | ||
| const geometry_msgs::msg::TransformStamped Tim = tf_buffer.lookupTransform( | ||
| mapFrame(), input_pose.header.frame_id, input_pose.header.stamp); |
There was a problem hiding this comment.
This transform lookup uses a timeout of 0 seconds by default, which will fail immediately if there is latency with the localization e.g. on a real robot. We could either make the timeout configurable using a MeshNav wide parameter every plugin can read, or expose the timeout in the MeshMap::transformToMapFrame method and pass the responsibility to the calling plugin.
| { | ||
| // This planner requires start and goal pose to be in map frame | ||
| const geometry_msgs::msg::PoseStamped start_in_map = mesh_map_->transformToMapFrame(start); | ||
| const geometry_msgs::msg::PoseStamped goal_in_map = mesh_map_->transformToMapFrame(goal); |
There was a problem hiding this comment.
We should catch the transform errors here to prevent MeshNav from crashing and return an error code
…navigation into fix/transform-planner
|
Tested it with Ubuntu 24 and ROS Jazzy. Works with proper error msg etc. 👍 |
2 participants
This change fixes #94. I tested it with a script that sets poses 1m in front of the robot (in base_footprint frame).