relationship between ROS and robot hardware

asked 2012-02-13 17:55:43 -0600

Anonymous

Hello, I just got started with ROS and I have a quick clarification question before I get myself into the wrong mindset about thinking of ROS. Please let me know if any of the following are correct/incorrect/half-correct - thanks in advance!

I want to build a teleoperated robot. I have a 'laptop' and a 'workstation' from which I wish to control the robot.

scenario 1: install ROS on 'laptop'. SSH into laptop from workstation to control robot. This is like Turtlebot.
scenario 2: install ROS on 'workstation', use a Bluetooth/Wireless stack on 'workstation' to receive input from robot, make complex decisions, and send commands to differential drives & whatnot. Is the 'laptop' still necessary on the robot (translating bluetooth messages to the actuators)? Is this more like NXT, where the NXT brick doesn't actually have ROS loaded on it but rather is being controlled by a ROS-powered workstation via bluetooth stack?
scenario 2 (continued): if ROS is not installed on the physical robot (teleop), what components of ROS would I actually use on the workstation? The NXT brick would handle all the basic moving & sensing, and the workstation only has to use ROS bluetooth to handle data?

edit retag flag offensive close merge delete

add a comment

3

answered 2012-02-14 02:45:15 -0600

DimitriProsser

11163 ●79 ●116 ●169

Both of those options are "correct". There is not a correct way to handle this kind of system. It's entirely based on your application's needs.

For example, many quadrotors don't have ROS loaded on the bot itself. They run a dedicated firmware that was specifically designed for efficiency and speed. Since they provide a communications protocol, one must simply write a ROS node that translates ROS commands into simple drive commands. All complex decision-making is performed on the "workstation". This is similar to the NXT scenario. You do all of the major processing off the robot and then let the dedicated hardware (the "brick") do all of the low-level stuff. There is no "right" way.

On my robot, we have two PCs that communicate as a single system. We then connect to those PCs via ssh to add additional computation power to the system.

It also depends how much control you want over hardware. You can either access hardware through the built-in controls (on the "brick") via a programming API, or you can control the drivers directly with the "laptop" configuration.

Another thought to consider is latency. If the laptop (local) does most of the base work, then latency matters less. If you're using scenario 2, EVERY command must be sent across the wireless signal. If latency is bad, robot performance will be directly affected.