I'm not sure what you mean by calibration in this case, but I can tell you what the odom->base_link transform is.
The tf library exists to define coordinate frames and the relationships between them. REP-105 defines some of the principal coordinate frames in ROS, but we'll focus on base_link and odom.
The base_link frame is a coordinate frame that is firmly affixed to the robot. In other words, the +X axis extends straight out of the front of the robot, the +Y axis extends directly to the robot's left, and the +Z axis extends straight up in the air. No matter where the robot goes, the base_link frame is attached to the robot's origin, and so those axes remain in the same location w.r.t. the robot. Just imagine that someone 3D printed a small coordinate frame and glued it to your robot.
Now, as your robot moves around in the world, we have to know what its pose is in that world. That "world" is the odom coordinate frame. When the robot starts out, it's typically at position (0, 0) and with rotation/yaw/heading of 0. That means your pose in the odom frame is (0, 0) with a yaw of 0. If you drive forward 1 meter, than your pose in the odom frame is (1, 0) with a yaw of 0. If you then turn left pi/2 radians, your pose in the odom frame is (1, 0) with a yaw of pi/2. If you drive forward another meter, your robot's odom frame pose is (1, 1) with a yaw of pi/2.
The key point is this: your robot's pose in the world is equivalent to the odom->base_link transform (really, you could say it's base_link->odom, but that's not really important for this discussion). In other words, if I want to transform a point from the base_link coordinate frame to the odom (world) coordinate frame, you need that transform, and that transform is just your robot's odom frame pose.
All the state estimation nodes are doing in r_l is computing the robot's pose in the world frame (e.g., map or odom) and doing two things:
- Sending out a
nav_msgs/Odometry message with the robot's pose, velocity, and respective covariances - Sending out a transform from the
world_frame parameter (e.g., odom) to the base_link_frame parameter (e.g., base_link). Note that this data is the same as the data in (1), but just sent out as a tf message.
The way it computes those things is via sensor fusion. If you have wheel encoders that say you are driving at 1.0 m/s forward, then the EKF integrates those velocities over time, so after 10 seconds, it says you went 10 meters straight forward. If you also have an IMU that says you are turning with some velocity, it integrates those at the same time, so if your wheel ... (more)
Ah, I understand your confusion now. Yes, the EKF doesn't really know anything about the relationships between sensors, as you've stated. It just wants to know, for a given measurement, how to transform it into a frame that it "knows" about, and you provide those transforms.