Revision history [back]

There are many different ways that people architect robot systems that use ROS. For example, there are "native-ROS" robots like the PR2, Baxter, Turtlebot, etc. These robots all have a Linux computer of some kind that has a full-blown OS and a version of ROS running. These robots also have lower level, embedded computers for things like motor control. The main computer and OS on the robot then employs various mechanisms for communicating with these lower level control computers. They may use communication protocols like EtherCAT, RS232, or CAN, and various hardware/driver solutions for implementing these protocols.

Another strategy often employed is to have the robots themselves be non-ROS robots. This is more common for applications like swarm robots, and quadrotors where each individual agent is fairly simple. In this case, ROS typically runs on some off-board computer and some sort of communication tool (rosserial, a custom node, etc) is used to pass data between the ROS world and the robots (control commands, sensor readings, etc.).

In between the two previous ideas would be a very small embedded computer that is capable of running ROS (Raspberry Pi, odroid, BBB, etc.). In this case the small computer could run ROS and natively communicate with other ROS computers, and it could perform its own low-level control and sensor interfacing.

If you want to run a ROS node that you've developed on a normal PC directly on a robot, then that robot must be able to run ROS and must have a host OS.