Revision history [back]

http://wiki.ros.org/navigation/Tutorials/RobotSetup/Odom says that tf doesn't provide velocity so the navigation stack also wants the Odometry message. tf does provide a lookupTwist function but it either is averaging the velocity over a time period or computing velocity from the last two position updates- the averaging could have a lot of latency or smooth over short duration velocities of interest, and only using the last updates could be noisy. So neither method can recover the instantaneous velocity of the odom message. http://answers.ros.org/question/12894/calculating-velocity-from-tf/

It doesn't mention it but the Odom message also has position and velocity uncertainty information in the pose and twist covariance matrices- it is said to be optional but but a pose filtering scheme would make use of that when fusing odometry with imu or other sensor data. (There is an unmaintained tf version that propagates uncertainty http://wiki.ros.org/uncertain_tf , it would be great if this was revived in the future, and then later support multiple tf parents as well...)

http://wiki.ros.org/navigation/Tutorials/RobotSetup/Odom says that tf doesn't provide velocity so the navigation stack also wants the Odometry message. tf does provide a lookupTwist function but it either is averaging the velocity over a time period or computing velocity from the last two position updates- the averaging could have a lot of latency or smooth over short duration velocities of interest, and only using the last updates could be noisy. So neither method can recover the instantaneous velocity of the odom message. http://answers.ros.org/question/12894/calculating-velocity-from-tf/

It doesn't mention it but the Odom message also has position and velocity uncertainty information in the pose and twist covariance matrices- it is said to be optional but but a pose filtering scheme would make use of that when fusing odometry with imu or other sensor data. (There is an unmaintained tf version that propagates uncertainty http://wiki.ros.org/uncertain_tf , it would be great if this was revived in the future, and then later support multiple tf parents as well...)

http://wiki.ros.org/navigation/Tutorials/RobotSetup/Odom says that tf doesn't provide velocity so the navigation stack also wants the Odometry message. tf does provide a lookupTwist function but it either is averaging the velocity over a time period or computing velocity from the last two position updates- the averaging could have a lot of latency or smooth over short duration velocities of interest, and only using the last updates could be noisy. So neither method can recover the instantaneous velocity of the odom message. http://answers.ros.org/question/12894/calculating-velocity-from-tf/

It doesn't mention it but the Odom message also has position and velocity uncertainty information in the pose and twist covariance matrices- it is said to be optional but but a pose filtering scheme would make use of that when fusing odometry with imu or other sensor data. (There is an unmaintained tf version that propagates uncertainty http://wiki.ros.org/uncertain_tf , it would be great if this was revived in the future, and then later support multiple tf parents as well...)

If you have no current or potential subscribers to /odom in your project (doesn't gmapping wnat it or is it using only sensors?) then it could be eliminated, or made optional (Maybe someone else will want to hook your robot up to the nav stack, even if you don't? And does it really cost you much resources to keep publishing it?).

http://wiki.ros.org/navigation/Tutorials/RobotSetup/Odom says that tf doesn't provide velocity so the navigation stack also wants the Odometry message. tf does provide a lookupTwist function but it either is averaging the velocity over a time period or computing velocity from the last two position updates- the averaging could have a lot of latency or smooth over short duration velocities of interest, and only using the last updates could be noisy. So neither method can recover the instantaneous velocity of the odom message. http://answers.ros.org/question/12894/calculating-velocity-from-tf/

It doesn't mention it but the Odom message also has position and velocity uncertainty information in the pose and twist covariance matrices- it is said to be optional but but a pose filtering scheme would make use of that when fusing odometry with imu or other sensor data. (There is an unmaintained tf version that propagates uncertainty http://wiki.ros.org/uncertain_tf , it would be great if this was revived in the future, and then later support multiple tf parents as well...)

If you have no current or potential subscribers to /odom in your project (doesn't gmapping wnat it or is it using only sensors?) then it could be eliminated, or made optional (Maybe someone else will want to hook your robot up to the nav stack, even if you don't? And stack- and does it really cost you much resources to keep publishing it?).

http://wiki.ros.org/navigation/Tutorials/RobotSetup/Odom says that tf doesn't provide velocity so the navigation stack also wants the Odometry message. tf does provide a lookupTwist function but it either is averaging the velocity over a time period or computing velocity from the last two position updates- the averaging could have a lot of latency or smooth over short duration velocities of interest, and only using the last updates could be noisy. So neither method can recover the instantaneous velocity of the odom message. http://answers.ros.org/question/12894/calculating-velocity-from-tf/

It doesn't mention it but the Odom message also has position and velocity uncertainty information in the pose and twist covariance matrices- it is said to be optional but but a pose filtering scheme would make use of that when fusing odometry with imu or other sensor data. (There is an unmaintained tf version that propagates uncertainty http://wiki.ros.org/uncertain_tf , it would be great if this was revived in the future, and then later support multiple tf parents as well...)

If you have no current or potential subscribers to /odom in your project (doesn't gmapping wnat want it or is it using only sensors?) then it could be eliminated, or made optional (Maybe someone else will want to hook your robot up to the nav stack- and does it really cost you much resources to keep publishing it?).