Learning Robotics using Python: Bring robotics projects to life with Python! Discover how to harness everything from Blender to ROS and OpenCV with one of our most popular robotics books.

The term "robot" was used for the first time by Karel Čapek, a Czech writer in his play Rossum's Universal Robots (R.U.R) that he wrote in 1920, to denote an artificial human made out of synthetic organic matter. These robots (roboti in Czech) were made in factories and their purpose was to replace human workers. While they were very efficient and executed orders they were given perfectly, they lacked any emotion. It seemed that humans would not need to work at all because robots seemed to be happy to work for them. This changed after a while and a robot revolt resulted in extinction of the human race.

R.U.R is quite dark and disturbing, but it does not leave the future hopeless. It was considered quite a success back in the day and we certainly do recommend you to read it. As its copyright had already expired in many countries at the time of writing this book, it should not be a problem to find a version online, which is in the public domain.

While many attribute the term robot to Karel Čapek as he wrote the play in which it appeared for the first time, there are sources suggesting that it was actually Čapek's brother Josef who came up with the term (it seems that there was an article in Czech daily print written by Karel Čapek himself, in which he wants to set the record straight by telling this story). Karel wanted to use the term laboři (from Latin labor, work), but he did not like it. It seemed too artificial to him, so he asked his brother for advice. Josef suggested roboti and that was what Karel used in the end.

Now that we know when the term robot was used for the first time and who actually created it, let's find out where does it come from. The explanation that many use is that it comes from the Czech words robota and robotník, which literally means "work" and "worker" respectively. However, the word robota also means "work" or "serf labor" in Slovak. Also, we should take into account that some sources suggest that by the time Karel was writing R.U.R, he and his brother often visited his father in a small Slovak spa town called Trenčianske Teplice. Therefore, it might very well be that the term robot was inspired by the usage of the word "robota" in Slovak language, which is coincidentally, the native language of one of the authors of this book.

Whether the term robot comes from Czech or Slovak, the word robota might be a matter of national pride, but it does not concern us too much. In both cases, the literal meaning is "work", "labor", or "hard work" and it was the purpose of the Čapek's robots. However, robots have evolved dramatically over the past hundred years. To say that they are all about doing hard work would probably be an understatement.

So, let's try to define the notion of a robot as we perceive it today.

When we try to find a precise definition of some term, our first stop is usually some sort of encyclopedia or a dictionary. Let's try to do this for the term robot.

Our first stop will be Encyclopedia Britannica. Its definition of a robot is as follows:

This is quite a nice definition, but there are quite a few problems with it.

First of all, it's a bit too broad. By this definition, a washing machine should also be considered a robot. It does operate automatically (well, most of them do), it does replace human effort (although not by changing the same tasks a human would do), and it certainly does not resemble a human.

Secondly, it's quite difficult to imagine what a robot actually is after reading this definition. With such a broad definition, there are way too many things that can be considered a robot and this definition does not provide us with any specific features.

It turns out that while Encyclopedia Britannica's definition of a robot does not fit our needs well enough, it's actually one of the best ones that one can find. For example, The Free Dictionary defines a robot as "A mechanical device that sometimes resembles a human and is capable of performing a variety of often complex human tasks on command or by being programmed in advance." This is even worse than what we had and it seems that a washing machine should still be considered a robot.

The inherent problem with these definitions is that they try to capture vast amount of machines that we call robots these days. The result is that it's very difficult, if not impossible, to come up with a definition that will be comprehensive enough and not include a washing machine at the same time. John Engelberger, founder of the world's first robotics company and industrial robotics (as we know it today) once famously said, "I can't define a robot, but I know one when I see one."

So, is it even possible to define a robot? Maybe not in general. However, if we limit ourselves just to the scope of this book, there may be a definition that will suit our needs well enough. In her very nice introductory book on the subject of robotics called The Robotics Primer (which we also highly recommend), Maja J. Mataric uses the following definition:

At first sight, it might not seem like a vast improvement over what we have so far, but let's dissect it part by part to see whether it meets our needs.

The first part says, "A robot is an autonomous system". By autonomous, we mean that a robot makes decisions on its own—it's not controlled by a human. This already seems to be an improvement as it weeds out any machine that's controlled by someone (such as our famous washing machine). Robots that we will talk about throughout this book may sometimes have some sort of a remote function, which allows a human to control it remotely, but this functionality is usually built-in as sort of a safety measure so that if something goes wrong and the robot's autonomous systems fails to behave as we would expect them to, it's still possible to get the robot to safety and diagnose its problems afterwards. However, the main goal still stays the same, that is, to build robots that can take some direction from humans and are able to act and function on their own.

However, just being an autonomous system will certainly not be enough for a robot in this book. For instance, we can find many computer programs that we can call autonomous systems (they are not controlled by an individual and make decisions on their own) and yet we do not consider them to be robots.

To get around this obstacle, we need the other part of the sentence that says, "which exists in the physical world".

Given the recent advances in the fields of artificial intelligence and machine learning, there is no shortage of computer systems that act on their own and perform some work for us, which is what robots should be for. As a quite notorious example, let's consider spam filters. These are computer programs that read every e-mail that reaches your e-mail address and decides whether you may want to read it (and that the e-mail is indeed legitimate) or whether it's yet another example of an unwanted e-mail.

There is no doubt that such a system is helpful (if you disagree, try to read some of the e-mails in your Spam folder—I am pretty sure it will be a boring read). It's estimated that over 60 percent of all e-mail traffic in 2014 can be attributed to spam e-mails. Being able to automatically filter them can save us a lot of reading time. Also, as there is a no human involved in the decision process (although, we can help it by marking an e-mail as spam), we can call such a system as autonomous. Still, we will not call it a true robot. Rather, we call them "software robots" or just "bots" (the fact that their name is shorter may come from the fact that they are short of the physical parts of true robots).

While software robots are definitely an interesting group on its own, it's the physical world in which robots operate that makes the process of creating them so exciting and difficult at the same time. When creating a software robot, you can count on the fact that the environment it will run in (usually the operating system) will be quite stable (as in, not too many things may change unexpectedly). However, when you are creating a real robot, you can never be sure.

This is why a real robot needs to know what is happening in the environment in which it operates. Also, this is why the next part of the definition says, "can sense its environment".

Sensing what is happening around a real robot is arguably its most important feature. To sense their surrounding environments, robots usually have sensors. These are devices that measure physical characteristics of the environment and provide this information back to the robot so that it can, for instance, react to sudden changes of temperature, humidity, or pressure. This is quite a big difference from software robots. While they just get the information they need in order to operate somewhat magically, real robots need to have a subsystem or subsystems that take care of obtaining this information. If we look at the differences between robots and humans, we will not find many (in our very high-level view, of course). We can think of sensoring subsystems as artificial replacements for human organs that provide this sort of information to the brain.

One important consequence of this definition is that anything that does not sense its environment cannot be called a robot. This includes any devices that just "drive blind" or move in a random fashion because they do not have any information from the environment to base their behavior on.

Any roboticist will tell you that robots are very exciting machines. Many will also argue that what makes them so exciting is actually their ability to interact with the outside world (which is to move or otherwise change the environment they are in). Without this, they are just another static machine that might be useful, but rather unexciting.

Our definition of a robot reflects this in its last part when it says, "can act on it to achieve some goals".

Acting on the environment might sound like a very complex task for a robot, but in this case, it just means changing the world in some (even very slight) way. We call these parts of robots that perform this as effectors. If we look at our robot vs human comparison, effectors are the artificial equivalents of hands, legs, and other body parts that allow it to move. Effectors make use of some lower-level systems such as motors or muscles that actually carry out the movement. We call them actuators. Although, the artificial ones may seem to function similar to the biological ones, a closer look will reveal that they are actually quite different.

You may have noticed that this part is not only about acting on the robot's environment, but also about achieving some goals. While many hobby roboticists build robots just for the fun of it, most robots are built in order to carry out (or, should we rather say, to help with) some tasks, such as moving heavy parts in a factory or locating victims in areas affected by natural disasters.

As we said before, a system or a machine that behaves randomly and does not use information from its environment cannot really be considered a robot. However, how can it use these information somehow? The easiest thing to do is to do something useful, which we can rephrase as trying to reach some goal that we consider useful, which in turn brings us back to our definition. A goal of a robot does not necessarily need to be something as complex and ambitious as "hard labor for human". It can easily be something simple, such as "do not bump into obstacles" or "turn the light switch on".

Now, as we have at least a slight idea of what a robot is, we can move on to briefly discuss where robots come from, in other words, the history of robotics.

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.

Reactive control is probably the simplest architecture (or paradigm) one can put together with the primitives described previously. In this paradigm, as we can see in the following figure, there is no planning process involved. There is a direct connection between sensing and acting, which means that as soon as some sensory data comes in, the effectors act on the environment in some predefined way:

Just as the reflexes in your body do not send the information about something happening all the way up to the brain (which would be quite slow), but rather just to the nearest spinal cord so that the response could be fast, a reactively-controlled robot will not have any complex computation, but fast, precomputed actions that will be stored somewhere.

Suppose you were programming a chess playing robot with the rules of ordinary chess, it would be your robot's turn, then your robot's opponent's, and so on. It's obvious that in a setting like this, your robot does not really need to be extremely fast. However, it will be great if it did some planning about the future so that it can anticipate the future opponent's turns and then adjust its strategy, based on the opponent's current turn.

A set up like this will be perfect for hierarchical (or deliberative) control paradigm. As you can see in the following figure, the loop of planning, acting, and sensing is closed. Thus, the system can actively move towards its goal, whatever that might be:

So far, we discussed control paradigms that was either fast but not very flexible, or smart but quite slow. What we will really need in many cases is something in between. Also, this is precisely what a hybrid control paradigm tries to offer.

How can we use this in a real-life robot? Suppose we want to build a robotic waiter that would serve drinks in a coffee shop (coincidentally, that is what most of this book is about). Such a waiter would definitely need to have its own internal representation of the coffee shop (where are the tables and chairs located, and so on). Once it's given a task of delivering a cup of coffee to a given customer, it will have to plan its path and then move alongside that path. As we can expect this coffee shop to be quite a good one, there maybe other guests inside too. We cannot let our robot bump into any chair or a table, let alone colliding with a customer randomly while it's trying to deliver coffee. For this, we need a well tuned reactive controller.

The following figure shows the schematics of the hybrid control paradigm. We can see that the robot at first plans its task, but breaks it down it into series of actions that can be executed by the reactive paradigm. One interesting thing to note here is the fact that the sensory data is available to aid the planning (as it needs to do some planning) and the acting (as it does the reactive control) parts of the system:

That's about it! Now, you know what a robot is, what makes it a robot, where it came from, the parts needed to create a robot, and how you can architecturally put it together. It's about time you build one yourself!