Revision history [back]

The REP you referenced is a document that is describing best practices and standards used for coordinate systems in mobile robots in ROS. If you choose to follow those conventions, then indeed, the odometry frame (typically /odom would be a parent of the base frame (typically /base_link). The computer on your robot would need to read the values from the wheel encoders and integrate the kinematics of your robot to provide an estimate of where your robot is relative to where it started. This would be provided to the rest of the ROS world as a transform from the odometry to the base frame (and typically a topic of type nav_msgs/Odometry). If you robot never had any drift, wheel slippage, integration error, etc. then the transform from a truly world-fixed frame to the odometry frame would be constant; of course, this will never happen there will always be drift in your odometry estimate.

Typically the location of the sensors themselves would be described by further transforms that are children of the base frame (e.g. /base_link -> /sensor_1). This us usually done with a URDF and a robot_state_publisher.

There are likely other choices that could make sense for describing this same information (you seem to have an idea of how you would prefer this same information to be described), and you are free to use whatever description you want. That being said, beware that if you don't follow the REP, there are many other packages that may not work with your robot.

The REP you referenced is a document that is describing best practices and standards used for coordinate systems in mobile robots in ROS. If you choose to follow those conventions, then indeed, the odometry frame (typically /odom would be a parent of the base frame (typically /base_link). The computer on your robot would need to read the values from the wheel encoders and integrate the kinematics of your robot to provide an estimate of where your robot is relative to where it started. This would be provided to the rest of the ROS world as a transform from the odometry to the base frame (and typically a topic of type nav_msgs/Odometry). If you your robot never had any drift, wheel slippage, integration error, etc. then the transform from a truly world-fixed frame to the odometry frame would be constant; of course, this will never happen there will always be drift in your odometry estimate.

Typically the location of the sensors themselves would be described by further transforms that are children of the base frame (e.g. /base_link -> /sensor_1). This us usually done with a URDF and a robot_state_publisher.

There are likely other choices that could make sense for describing this same information (you seem to have an idea of how you would prefer this same information to be described), and you are free to use whatever description you want. That being said, beware that if you don't follow the REP, there are many other packages that may not work with your robot.

The REP you referenced is a document that is describing best practices and standards used for coordinate systems in mobile robots in ROS. If you choose to follow those conventions, then indeed, the odometry frame (typically /odom would be a parent of the base frame (typically /base_link). The computer on your robot would need to read the values from the wheel encoders and integrate the kinematics of your robot to provide an estimate of where your robot is relative to where it started. This would be provided to the rest of the ROS world as a transform from the odometry to the base frame (and typically a topic of type nav_msgs/Odometry). If your robot never had any drift, wheel slippage, integration error, etc. then the transform from a truly world-fixed frame to the odometry frame would be constant; of course, this will never happen and there will always be drift in your odometry estimate.

Typically the location of the sensors themselves would be described by further transforms that are children of the base frame (e.g. /base_link -> /sensor_1). This us usually done with a URDF and a robot_state_publisher.

There are likely other choices that could make sense for describing this same information (you seem to have an idea of how you would prefer this same information to be described), and you are free to use whatever description you want. That being said, beware that if you don't follow the REP, there are many other packages that may not work with your robot.

The REP you referenced is a document that is describing best practices and standards used for coordinate systems in mobile robots in ROS. If you choose to follow those conventions, then indeed, the odometry frame (typically /odom would be a parent of the base frame (typically /base_link). The computer on your robot would need to read the values from the wheel encoders and integrate the kinematics of your robot to provide an estimate of where your robot is relative to where it started. This would be provided to the rest of the ROS world as a transform from the odometry to the base frame (and typically a topic of type nav_msgs/Odometry). If your robot never had any drift, wheel slippage, integration error, etc. then the transform from a truly world-fixed frame to the odometry frame would be constant; of course, this will never happen and there will always be drift in your odometry estimate.

Typically the location of the sensors themselves would be described by further transforms that are children of the base frame (e.g. /base_link -> /sensor_1). This us is usually done with a URDF and a robot_state_publisher.

There are likely other choices that could make sense for describing this same information (you seem to have an idea of how you would prefer this same information to be described), and you are free to use whatever description you want. That being said, beware that if you don't follow the REP, there are many other packages that may not work with your robot.