The society has two Baxters, called robot 1 and robot 2 here. Robot 2 stands on a Dataspeed Mobility Base. Both run the same robot software (version 1.2.0), and in October 2026 both passed the same full check through the bridge, with a version from before the first release. A program written for one therefore runs on the other.
| Robot 1 | Robot 2 | |
|---|---|---|
| Robot software | 1.2.0 | 1.2.0 |
| Stands on | the Mobility Base | |
| On the university network | 011603p0009.hull.ac.uk |
011602p0013.hull.ac.uk |
| Full robot check through the bridge | passed, 7 October 2026 | passed, 12 October 2026 (one check skipped: no gripper mounted) |
| Bridge version 1.0.0 | tested | not tried yet |
The society has two electric grippers, which are mounted on whichever robot needs them. The library checks what is mounted each time a program starts.
Three separate systems
Each Baxter is a complete ROS 1 system of its own: a computer inside the robot, and its own ROS master (the program that tells the robot’s other programs where to find each other). The Mobility Base is a third system: its own computer runs an older ROS 1 (Kinetic) with a master of its own.
The three never talk to each other. Both robots even use exactly the same topic names (/robot/joint_states, for example), so they can’t simply share one ROS 1 network.
Where they meet: ROS 2
Each system gets its own bridge, and all bridges run on one machine. A bridge can give its robot a name, and puts that name in front of everything of the robot on the ROS 2 side. Robot 1’s joint states then arrive as /one/robot/joint_states, robot 2’s as /two/robot/joint_states. The base’s bridge takes the name of the robot standing on it.
This is the usual ROS 2 way of keeping several robots apart, with one namespace per robot. All of them sit in one ROS 2 system, so RViz can show both robots in one picture, and one program can move both:
import baxter_interface
one = baxter_interface.Robot('one')
two = baxter_interface.Robot('two')
with baxter_interface.at_once(): # both at the same time
one.Limb('left').move_to_neutral()
two.Limb('left').move_to_neutral()one and two are just examples: the name is set in each robot’s settings file. A robot without a name keeps the plain topic names, which is the normal case when only one robot is in use.
The network
The bridge has to reach the robot, and the robot has to reach the bridge back: it connects to the bridge machine to receive commands. There are three ways to wire this up:
- A cable straight to one robot. The computer’s wired connection is set to link-local, and the robot gives itself an address starting with
169.254.after about a minute. The address can change when the robot restarts. - A small switch with the bridge machine, both robots and the base’s computer on it, all with link-local addresses. This is how the base was first reached.
- The university network. The robots have names there (in the table above), and the university’s lab machines reach a robot this way: Baxter on a lab machine.
Your own programs don’t need to be on the robot’s network at all. They only need to see the bridge machine’s ROS 2 traffic, on the same ROS 2 domain (a number all programs of one ROS 2 system share; the bridge uses 42). Guest and university Wi-Fi often block the messages ROS 2 uses to find other programs. The bridge’s repository explains how to name the other machine directly in that case, in own-machine.md.
Status
The names and both bridges have been tested with stand-ins for two robots. Each robot and the base have worked through the bridge on their own. Both real robots at the same time haven’t been tried yet, and neither has robot 2 with version 1.0.0.