Summary

I’ve been diving into my first coding assignment for the mobile robotics class. I’ve been getting familiar with the following:

• Modeling the position of a basic 4 wheeled robot using sensor data from IMU and wheel encorders using some generous assumptions (No sideways slipping, all rotation must translate to velocity of some sort (no loss of traction)
• The Odometry and GPS topics
• Different frames of reference and how the transform broadcaster works in Ros2
• Subscribers and Publishers within a Node
• Rviz2

See this assignment for more details

Essentially I was given a rosbag with a bunch of sensor data for a Terrasentia robot (the professors company), which is a 4 wheeled robot with fixed wheels. I asked to create the ‘odometry’ node for it, which tracks its position in the global reference frame.

I was given all sorts of sensor data including wheel velocity, imu data, gps data, and acceleration data.

For the first part I calculated its forward velocity by averaging the speed of the left and right wheels, then taking the average of those two speeds. I got the angular velocity, $\omega$, from the IMU and used that to calculate the heading of the robot.

<aside> 💡 Note I could also have found $\omega_z$ using the wheel date like this: (vr - vl)/2*l where l is the distance from the center of the robot to the wheels and vr/vl are the average velocities of the right and left wheels respectively.

</aside>

Using this info and making some forgiving assumptions (movment in x-y plane only, no sliding, no loss of traction), I was able to track the position. Equations looked like this:

• v = (vr + vl)
• $\omega_z$ = from imu (yaw)
• posX = poxX + dt*(v*cos(heading))
• posY = posY + dt(v*sin(heading))
• heading = heading + dt($\omega_z$))

dt was 0.1 and was specified in the by a timer created in the node constructor. This dt was in line with the publishing rate of the sensor data, which makes sense.

With this data I could visualise this robot’s path by having Rviz listen to the published messaged to the /Odom topic.

<aside> 💡 I did have a problem here to start that taught me a lot about how reference frames work in ros/rviz. Initially, Rviz was not working and was discarding all messages it heard from the /odom topic. Essentially the issue was that all rviz visualization is built from the map frame of reference. I had only defined the transformation between the base_link (robot) frame to the odom frame. Rviz did not know here the odom frame was relative to the map frame. This seems silly because in this case the odom frame was the world frame, and was aligned with the map frame, meaning the axes and origin of the odom frame was aligned with the map frame, so there was no transformation to do, but rviz didn’t know that. To solve this I had to using a static transform publisher like so:

ros2 run tf2_ros static_transform_publisher "0" "0" "0" "0" "0" "0" "1" "map" "odom" )

This continuously published a message that essentially said the transfomration from the map frame to the odom frame involves no translation or rotation (passed as a quaternion).

</aside>

Here the the path of the robot using the wheel encoder and IMU data. Pretty all over the place . . .