Revision history [back]

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.