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.

laser · imu_link · camera_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
laser/scanThe scanner on top of the car. Every LaserScan message carries this in its header.
imu_link/imuThe IMU on the OSCORE board. Every Imu message stamps 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_link/cameraThe camera at the front of the car. Every image message stamps it.
FIG. A / A CONVENTIONAL LAYOUT
TOP-DOWN · NOSE UP · A CONVENTION YOU SET UPcamera_link frontlaser topimu_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. The LiDAR is on top of the car.
ros2 run tf2_ros static_transform_publisher 0.10 0 0.12 0 0 0 base_link laser

# IMU on the OSCORE board.
ros2 run tf2_ros static_transform_publisher 0.05 0 0.05 0 0 0 base_link imu_link

# Camera at the front of the car, angled slightly down if yours is.
ros2 run tf2_ros static_transform_publisher 0.22 0 0.08 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.