needed a robot that could retrieve apples from the backyard that had fallen from the tree.  We could  reprogram  our tennis ball retrieval robot to look for apples instead of tennis balls.   But we still need our  tennis retrieval robot, so that option is no good.  We could reprogram it to retrieve tennis balls and apples, but that would slow it down because now it has to determine whether it is sensing an apple or a tennis ball,  and it works just fine at the speed it is. So that's no good. Likewise we  could reprogram our robot that reports red things,  but the problem is that robot works just fine the way its also. 

         In our book, "Build Your Own Teams of Robots Using Lego Mindstorms NXT and Bluetooth” we present a third alternative, robot teamwork.  Let's get the robot  that  finds red things to work together with the robot that retrieves tennis balls to create a robot application that retrieves apples (red  ones of course) from the back yard.   This approach does require multiple robots to be involved in the solution, but it has the advantage of  not having to totally reprogram or dismantle a working robot.

In this book we introduce the Bluetooth Robotic-Oriented Network (BRON). BRON  is a communication technique that allows teamwork between  two or more robots.  BRON allows robots to share sensors,  actuators, end effectors, motor power,  and programming in order to accomplish as a team what they could not do individually.  Rather than having to totally re-purpose a robot, or build a completely new robot from scratch,  BRON allows you to use  existing robots to work in teams to perform tasks that they were not originally designed to perform as individuals.  With BRON, we use each robot to do what it is designed to do, and by adding communications between the robots,  we can get the team of robots to do new things.

Even a general purpose robot is limited by the number  or type of sensors it  has, or by the types of end effector it possesses.  Sometimes we  may only have access to a stationary robot , where a mobile robot  will do the trick.  It might be determined that a  four-wheeled tractor is the required type of mobility, and as it turns out the robot we have is  bipedal, or has been designed with only two wheels.  But we can't go too far in the other direction either.  It's not practical  or possible to build a different robot for every task or for every scenario we require a robot.  First,  building a robot requires time and  the parts are costly.  Sensors can be expensive.  We wouldn't want to build one robot to turn off the lights and a separate robot to turn on the lights. There  would be a  lot of  unnecessary duplication.   However, we could dismantle the robot we have to build the robot we need.   We really don't like this option.  After we  have put in the time and effort to build a robot, test it, and it does what we want it to do,  we're usually happy and we keep it.

So what is the solution?   We don't  want to build  a new robot for every tasks that pops up, and we don't want to  to dismantle a perfectly good  working robot that already serves one purpose  in order to do some new task.  Sometimes we're lucky and we have a third alternative. We  might have a robot

that seeks and reports the position of red things and we might

have another robot that retrieves tennis balls.  What if  we