ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

Yes, you can publish on /odom directly from the Due, and it should work fine. One possibility is to use the rosserial package. I've done this from an Arduino Leonardo. (However, I've dropped rosserial on the smaller Arduinos because of the memory usage of rosserial. You shouldn't have any problems on a Due.)

You should publish the odometry as geometry_msgs/Twist. Normally, you want to publish in the base_link frame, which often has its origin midway between the two wheels. By convention, x is straight ahead, and z is up. Therefore, since we assume there is no side-slip, you'll have the current linear velocity in linear.x and the rotational velocity in angular.z. All other values will be zero. For dealing with odometry, it's more convenient to use Twist rather than a quaternion, IMHO. (Unless you have other needs.)

You should publish odometry at a rate equal to or higher than your planning loop rate. Also take your other sensors into account: you want up-to-date odometry when publishing a point cloud, for example. Depending on your setup, anything from 10-100 Hz might be best. Keep in mind the bandwidth required by rosserial, too. By default it's only 57600 baud, and messages are not tiny.

Yes, you can publish on /odom directly from the Due, and it should work fine. One possibility is to use the rosserial package. I've done this from an Arduino Leonardo. (However, I've dropped rosserial on the smaller Arduinos because of the memory usage of rosserial. You shouldn't have any problems on a Due.)

You should publish the odometry as geometry_msgs/Twistnav_msgs/Odometry. Normally, you want to publish in the base_link frame, which often has its origin midway between the two wheels. By convention, x is straight ahead, and z is up. Therefore, since we assume there is no side-slip, you'll have the current linear velocity in linear.x and the rotational velocity in angular.zvelocities in twist.linear.x and twist.angular.z. The pose will be in pose, including a quaternion for orientation. All other velocity values will be zero. For dealing with odometry, it's more convenient to use Twist rather than a quaternion, IMHO. (Unless you have other needs.)zero.

You should publish odometry at a rate equal to or higher than your planning loop rate. Also take your other sensors into account: you want up-to-date odometry when publishing a point cloud, for example. Depending on your setup, anything from 10-100 Hz might be best. Keep in mind the bandwidth required by rosserial, too. By default it's only 57600 baud, and messages are not tiny.