Logistics

• Discuss what is expected in the video
• SUbmbit the url not the whole file please
• Please send video of “real robot” if you did that too.
• Sometimes your code would work as is for an extra challenge, but you need to show it in the video

Review

• An x,y,z is always within a specific coordinate system
• For example, is it relative to the bottom left corner of the room, or the center of the robot?
• It is far easier to reason in an appropriate coordinate system
• As long as there are easy ways to convert back and forth.

Coordinate systems

• Pose = position and orientation
• Pose is always with respect of a specific coordinate frame or TF

Natural Coordinate system

• Usually a coordinate begins as the “natural” way to think about It
• Angle of obstacle, with respect to the LIDAR
• Position a corner, with respect to the whole room
• Angle to turn, from the point of view of the robot itself
• So when you see phrases like “with respect to”, and “from the point of view of” you know these refer to coordinate frames.

What is the natural TF hierachy?

• It is very common to want to see that same point or angle from another’s point of view
• How much do I have to turn to point directly away from the wall?
• What direction is the nearest door from me?
• How do I drive in the direction of the fiducial?
• Compare starboard/port and driver vs. passenger side

TF

• TF package in ROS is central
• It recently was rewritten and shows up as TF2 in many places
• It is interesting and important to understand in some more detail

TF framework in ROS

• An API to make conversions of coordinates between systems easy and efficient
• Coordinate systems are given names, e.g. “world” or “lidar-1”
• They are organized into a tree
• Every named tf has just one parent, and unlimited number of children

TF broadcasts

• Any node can report on the relationship between two coordinate system
• Generally this is a node who knows something about one or the other.
• For example, the node that moved the arm, can report the new relative position
• That is, to get from tf “a” to tf “b”, add add 10 to the x or rotate 180 degrees around z.
• TF Listeners
• If my node needs to interpret coordinates I might listen to tf messages
• Allowing to convert coordinates between any two coordinate frames.

Lets look at some code

• If you want to follow along, we are going to look at Introduction to tf2

$ sudo apt-get update
$ sudo apt-get install ros-noetic-turtle-tf2 ros-noetic-tf2-tools ros-noetic-tf
$ sudo apt install evince
$ roslaunch turtle_tf2 turtle_tf2_demo.launch

• Notice that as you use the cursor keys to teleop the orange turtle around, the grey one follows right on it’s heels!

High Level explanation

• Code is using tf2 to create three coordinate frames: one for the “world”, and one each for the two turtles
• Realize that if we give turtle1’s coordinates as x,y, we’d still need to say, in what coordinate frame those were.
• In t1’s coordinate frame, t1’s coordinates are always 0,0!

$ rosrun tf2_tools view_frames.py
$ evince frames.pdf

• See the three coordinate frames and their hierarchical relationship
• The diagram doesn’t display the actual transform just the relationships
• To see those we need to echo the transform:

$ rosrun tf tf_echo turtle1 turtle2
At time 1677784974.758
- Translation: [0.000, 0.000, 0.000]
- Rotation: in Quaternion [0.000, 0.000, -0.200, 0.980]
            in RPY (radian) [0.000, 0.000, -0.402]
            in RPY (degree) [0.000, 0.000, -23.046]

$ rosrun tf tf_echo turtle1 world
rosrun tf tf_echo turtle1 world
At time 1677785078.262
- Translation: [-5.544, -5.544, 0.000]
- Rotation: in Quaternion [0.000, 0.000, 0.000, 1.000]
            in RPY (radian) [0.000, -0.000, 0.000]
            in RPY (degree) [0.000, -0.000, 0.000]

• You can see the transform needed to get from turtle1 to turtle2 is different from the one between turtle1 and world. Why is that?

Visualization

$ rosrun rviz rviz -d `rospack find turtle_tf2`/rviz/turtle_rviz.rviz

• You now visualize all three tfs. Why do two move and one stay still?

Lets see how all this works: tf2_broadcaster

• Examine the code in prrexamples:
  • tf2_demo.launch: Our copy of the launch file
  • turtle_tf2_broadcaster.py: Our copy of the tf2_broadcaster
  • turtle_tf2_listener.py: Our copy of the tf2_listener

$ roslaunch prrexamples start_demo.launch
$ rosrun tf tf_echo /world /turtle1

• Only one turtle so far!
• Notice that it is publishing turtle1’s tfs relative to world
• Drive around and notice that it is updating turtle1’s pose and also a transform

$ roslaunch prrexamples start_demo.launch
$ rosrun tf tf_echo /world /turtle1
$ rosrun tf tf_echo /world /turtle2

tf2 frames are organized in a tree

$ rosrun tf2_tools view_frames.py
$ evince frames.pdf

• Notice, there are no cycles, one root
• This ensures that there’s only one path from one frame to another
• Which ensure that we can compute the transform by following that path
• New frame would be added as a child of an existing frame
• How to decide what the parent frame should be?
• Its the one that has the most obvious and simple transform

Defining TFs (transforms)

• TFs have names which help you understand what physical component it is tied to
• TFs for mobile robots follow a typical hierarchy as follows: map -> odom -> base_link
• base_link for the “center” of the robot. You get to pick it but it should make some intuitive sense. All other parts of the robot are below base_link hierarchically in the tf tree
• Sometimes it’s useful to have another TF which is the center of the footprint of the robot, meaning, a TF projected straight down from base_link and intersecting with the ground plane wherever that is.
• odom for the odometry created TF
• map for the TF of a map built by hand or through slam
• Conventional names and standards for TFs can be found here: (https://www.ros.org/reps/rep-0105.html)

Transforms (TFs)

• TFs are fundamental to understanding anything relating to positions in ROS.
• TFs are built on a hierarchical system of relative positions between different parts of a robot or different objects in the world.
• The base_link is the “center” of the robot. You get to pick it but it should make some intuitive sense.
• TFs allow all other parts of the robot to be described as a relative position to either the base_link directly or to other parts on the robot.
• Odometry is simply measuring the transform between the base_link and the origin point of the odom tf (usually the position at which the robot started).
• Continuing the example from before, lets say I need to know the relative positions of the hand on our robot and an lever in the world.

Thank you. Questions?  (random Image from picsum.photos)