Neobotics Foundation Inc.
TF framesNEORACER DOCS
NEORACER DOCS
These docs are public and open source.Edit on GitHub
API REFERENCE / ROS 2

ROS 2 TF FRAMES.

The sensor messages stamp a frame name in their header, but the racecar_neo teaching driver runs no transform broadcaster, so on that stack alone there is no /tf tree relating the frames until you add one. The osracer stack, which ships on the same car for and navigation, does publish a full tree. Knowing which one you are running saves an afternoon of staring at an empty RViz.

lidar_link · imu_linkracecar_neo: no /tfosracer: full tree
FIG. A / THE osracer TF TREE
/tf TREE · osracer · robot_state_publishermapadded by SLAModomadded by SLAMbase_footprintground projectionbase_linkbody originlaserfixedimu_linkfixedcamera_linkfixedleft_steering_hinge_linkcontinuousLeft_front_wheel_linkcontinuousright_steering_hinge_linkcontinuousright_front_wheel_linkcontinuousleft_rear_wheel_linkcontinuousright_rear_wheel_linkcontinuous
The transform tree osracer's robot_state_publisher broadcasts, straight from its URDF. map and odom are added by SLAM on top. Note the LiDAR frame is laser here, not lidar_link, and the steering hinges and wheels are continuous joints, which is why the 3D model can steer and roll. See it move on the hardware 3D model page.
THE FRAMES

THE FRAMES.

FrameStamped onWhere it is
lidar_link/scanThe scanner at the front of the chassis. Every LaserScan message carries this in its header.
imu_link/imu, /magThe IMU board near the middle of the car. Both the Imu and MagneticField messages stamp it.
base_linkyou add itThe body origin, by convention the rear axle. Nothing publishes it for you; it is the root you attach the sensors to.
camera_linkyou add itThe camera, just behind the LiDAR. The base /camera image leaves its frame blank, so you assign one if you need it in TF.
FIG. A / A CONVENTIONAL LAYOUT
TOP-DOWN · NOSE UP · A CONVENTION YOU SET UPlidar_link frontcamera_link behind LiDARimu_link centerbase_link root · rear axle
A common arrangement: base_link at the rear axle as the root, with the sensors offset forward and up from it. The exact offsets are yours to measure; nothing in the driver assumes them.
//Wiring the tree with static transforms

The quickest way to give ROS 2 the geometry is one static_transform_publisher per sensor. The arguments are x y z yaw pitch roll parent child, in metres and radians. Measure the offsets on your own car; the numbers below are an example, not a spec.

bash
# base_link sits at the rear axle. LiDAR is forward and a little up.
ros2 run tf2_ros static_transform_publisher 0.17 0 0.10 0 0 0 base_link lidar_link

# IMU is near the center, low.
ros2 run tf2_ros static_transform_publisher 0.05 0 0.05 0 0 0 base_link imu_link

# Camera, just behind the LiDAR, angled slightly down if yours is.
ros2 run tf2_ros static_transform_publisher 0.15 0 0.09 0 0 0 base_link camera_link

For anything beyond a quick test, move these into a robot_state_publisher driven by a URDF, so the whole tree comes up with one node and stays in one place.