In the very first part of this chapter, we tried to come up with a good (modern) definition of a robot. It turns out that the definition we came up with does not only describe a robot as we know it (or would like to know it), but also gives us some great pointers as to what parts can we most definitely find in (or on) a robot. Let's see our definition again:
"A robot is an autonomous system which exists in the physical world, can sense its environment, and can act on it to achieve some goals."
So, what will these most important parts be? Here is what we think should be on this list.
It will be hard for a robot to exist in the physical world without a physical body. While this obviously has its advantages (having a real world robot you can play with is much more exciting than having a computer simulation), there is also some price to be paid. For instance, a physical robot can only be at one place at a time, cannot really change its shape, and its functions are quite limited by how its body looks. As its environment will be the physical world, it's safe to assume that the robot will not be the only object in it. This already poses some challenges, such as making sure that the robot won't run into some wall, object, human, or even another robot. Also, in order to do this, the robot needs to be able, as the definition says, to sense its environment.
We already discussed in quite some depth about how important a robot's sensors are because without them, he would be just lost. A good question to ask might be, "So, what does a robot actually sense?". As in many other places (in science and technology), it depends on what the robot's purpose and goal in a given environment is, the design of the robot, and the amount of power it consumes, and so on. A good robot designer and programmer tries to take all these dependencies into account so that in the end, the final robot can have the right amount of information about its environment to fulfill its purpose and reach its goals.
One important notion with regards to sensing is that of a state. A state of a robot basically means a description of all its parameters at any given time. For instance, if we consider a robot to have some sound sensors (thanks to which it could measure the noise level in its environment), but no way of figuring out how much battery power does it have left, we can call its state partially-observable. On the other hand, if it had a sensor for every output of the robot and every physical characteristic of the environment the robot resides in, we can call such a state fully observable.
Now that we know the state of the robot in the environment, our robot needs something that can be used to leave some effect on its environment. Something like an effector.
We already touched (albeit briefly) on the topic of effectors when we were trying to decipher parts of our definition of a robot, so we already know that effectors let the robot do physical things and the small subparts of them, actuators, are actually those that do the heavy lifting.
What we did not mention was that, historically, there are two main activities effectors can help with: locomotion and manipulation.
In general, locomotion means moving around: going from point A to point B. This is of great interest in a subfield of robotics, which is called mobile robotics. This area of research is concerned with all sorts of robots that move in the air, underwater, or just on the ground.
By manipulation, we mean a process of moving an object from one place to another. This process is of huge interest to manipulator robotics, which is concerned mostly with all sorts of robotic arms that in the vast majority of cases, are used in industry.
Just for the sake of completeness, what are the different effectors our robots can make use of? Among the most basic ones, it will definitely be motors of all sorts along with some wheels that will allow the robot to move around.
Once we have data from the environment, we can also act on it. There is just one piece missing here: the link between them.
After all, we finally came to the conclusion of this whole system. If it was not for controllers, a robot could never ever be fully autonomous. This is to use data from sensors to decide what to do next and then execute some actions using effectors. This may look like a simple description, but in the end, it turns out that controllers are quite difficult to get right, especially when you are playing with them for the first time.
For most mobile robots and vast majority of hobby robots, controllers are usually microprocessors that are programmed in some low-level programming language. It's also not uncommon for a robot to use multiple controllers. However, while it definitely helps to have a backup controller ready in case your main one brakes down and great to have a modular system in which everything is its own module (and has its own controller), you do not get this for free. The price you have to pay is the communication between controllers, which requires a good deal of expertise.
Now that we have all the building blocks for a robot ready, we should at least briefly discuss the ways in which they can be organized. This might not seem important, but it turns out that having a good design up front can save us a lot of effort, energy, and resources. So, let's dive into how we can put a robot together architecturally.