The Quickstart covers the handful you need to change. This is the rest.

​
Parameters

ros2 param list on a running node is the ground truth. The ones worth knowing before you launch:
To see what a running node ended up with, YAML and command line combined:
The packaged config file sets max_norm_step to 1.0, which is a real speed limit, where the node’s own default of 5.0 is none at all.
Every service path and YAML key here assumes the launch file, which names the node videosdk_bridge. Start it with ros2 run instead and the node is called videosdk_teleop_bridge, so its services are under that name and the packaged YAML does not apply.

​
Dashboard

The stats page is served in process, straight off the bridge. Nothing is published, so nothing new appears in ros2 topic list. The launch file has no argument for it, so add it to your params file:
Or pass it directly when you skip the launch file:
Every stats panel works in both roles. The camera grid works on the leader side, which shows what the far follower publishes.

​
Services

Four, and the side you call them from matters. Releasing is deliberately follower-side only: someone has to be near the arm.
The bridge cannot cut power to the motors, so there is no torque service. Its failsafe holds the arm in place instead. A limp arm has to come from your own driver, which is the only thing here touching hardware.

​
Normalisation

Each machine holds exactly one calibration: its own. The leader divides by its own travel, the follower multiplies by its own, and neither host needs the other’s numbers. Two arms with different travel, such as an SO-101 leader and follower differing by about 19% at the gripper, both still reach their own end stops. For a non-SO-101 robot there is nothing to install. Give joint_min and joint_max in whatever units your topics already carry:
joint_names order is a cross-host contract. joint_min and joint_max are the opposite: per host, and copying them to the other machine gives an arm that tracks but with the wrong gain at the extremes.
Publish joint states from your follower driver at 10 Hz or more. Without them the bridge runs open-loop, echoing what it last commanded, so tracking error and max_misalignment stop meaning anything.

​
Safety

The bridge only catches what it can see from where it sits: whether commands are arriving, and whether the operator is still holding on. Everything about how the arm moves stays in your driver.
max_norm_step defaults to 5.0, five times full travel in one tick, which is no limit at all. Lower it only if your driver has none of its own: two limiters in series means the tighter one wins, and you have two places to look when the arm feels sluggish.

​
Starting and stopping

~/enable exists only on the leader, and it is what makes commands flow. Turn it off and the stream stops, the follower’s watchdog runs out, and the far arm holds where it is. Heartbeats keep flowing either way, so the follower can tell the operator letting go from the link dying.
A service call is not a held deadman. Nobody is physically holding anything, so an operator who walks away leaves the arm armed until the watchdog or the link stops it.
On an emergency stop the bridge simply stops publishing, and your driver’s own behaviour for stale commands takes over. How long the arm takes to settle is watchdog_timeout_s plus whatever timeout your driver uses.

Quickstart

Install, point it at your topics, and drive a robot.

SO-101

Joint travel read from a LeRobot calibration.