You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As per ROS conventions (REP 105), '/odom' is usually the parent of '/base_footprint'. However, in the code odometry_integration.cpp, the following tf is being published: '/base_footprint' -> '/odom'. Is there any particular reason that you prefer to use the backward tf relationship? I am curious to know about it, because it is recommended that we follow the ROS conventions to make the code reusable as well as operable with other ROS packages.
The text was updated successfully, but these errors were encountered:
sayali-purdue
changed the title
Odometry tf relationship is backward
Odometry tf relationship is backward with default param values in odometry_integration.cpp
Dec 21, 2020
Upon further code inspection, I found that car_params.yaml specifies the correct values for the frame_id related params. It sets world_frame to 'odom' and base_frame to 'base_footprint'. However, the default parameter values in the source code file, odometry_integration.cpp, are reversed, i.e. default value of base_frame is 'odom' and default value of world_frame is 'base_footprint'. Therefore, if the parameter values are not provided, then these default values are used to publish the transform (base_footprint -> odom). To make to code more robust, the default values should be changed.
As per ROS conventions (REP 105), '/odom' is usually the parent of '/base_footprint'. However, in the code odometry_integration.cpp, the following tf is being published: '/base_footprint' -> '/odom'. Is there any particular reason that you prefer to use the backward tf relationship? I am curious to know about it, because it is recommended that we follow the ROS conventions to make the code reusable as well as operable with other ROS packages.
The text was updated successfully, but these errors were encountered: