Whatever robot you build, chances are you will need some robot programming it at one time or another to build its behavior.
A few robots are purely mechanical and/or electronics, and don't even use a microcontroller. While it's possible, it's not the majority of robots and we won't talk about these today.
Here the focus is to present the different fields of robot programming. How different is it to program a microcontroller and a PC? How can I structure my code when the robot has a lot of behaviors? So let's get started.
A robot can mainly be seen as a PC controlling physical devices and low-level electronics. The problem is that PCs were not made to control low-level electronics. They have standard interface for inputs and outputs, and they have so much responsibility that they can't control one output with the level of accuracy needed to control components.
You can think of a PC as the boss of the factory, taking orders for products, and organizing the packages to send them to the clients. But he doesn't have time to go down and fill the boxes one by one. That's the role of a microcontroller.
In robotics, you can build a robot by yourself using a microcontroller that will listen to the sensors and give commands to the LEDs, Motors and other actuators. Although you can already achieve some good behaviors with this architecture, a microcontroller won't be enough if you want to add a video camera, or want some advanced artificial intelligence on your robot.
For more advanced programming, you will need a PC computing the high-level function of the robot. It's like your nervous system: the spine can control your movement and receive the nerve signals. If you touch something hot, it can even react automatically to protect you. But the direction you go and the way you feel are all processed by the brain itself.
In robot programming, there are a few basic robotics software architecture that are very common and very efficient. I'll present 3 of them from the most simple to the most complexed.
The first one is the state machine. You can make all kind of simple robots controlled by a state machine.
To create a state machine, you need to list all the basic behaviors you want your robot to do, then you write them into seperate squares, finally you link them with one way arrows and write the conditions for each arrow. I made an example in the picture for a wall-avoiding robot. I have to WAIT between FORWARD and TURN because my motor controller would overheat otherwise. The code associated that State Machine is only about 50 lines on Arduino, counting the communication for the PC. Very simple!
The next common software architecture for robot programming is the subsumption archtitecture. In this case, you don't segment your robot's behavior in states, but in functions. Each box is an independent, reliable function. The robot AI emerges from a careful design that link the boxes together to create more and more complex behaviors.
What is good in a subsumption architecture is that each block can be reused, and you can create more complex behaviors on top of a simple robot. So if you have a wall-avoider robot, you can reuse all the boxes and add targeting box to have a robot that can go from A to B (new box) without bumping in walls (old boxes). Then you can add a cartography behavior that uses the previous architecture to explore areas it doesn't know.
Finally, the most complexed robots like Nao or robots running ROS use a module/component based architecture. Each function is now an independent module with standard inputs and outputs, that can be called from anywhere.
Now you don't need to link all the boxes together like in the subsumption architecture. Every module is a program in itself that can call other modules like they were libraries. Since there is a standard interface for the modules, you can have built-in support for multiple programming languages (like in ROS or Nao). It's very powerful to be able to program really efficient image processing in C++ and then create the interface or the AI easily in Python.
Now that you know all this, you have to decide which robot programming technique is the best for you. The state machine is clearly easier to build and maybe enough for many robots. If you are making a maze-solving micromouse, you may want to use the subsumption architecture. In Nao, I use the module base architecture of course, but most applications are more like a subsumption that organizes modules into an interactive game, and on which I can build more later.
Other pages that may interest you:
Pepper robot programming: find tips and tutorials to program the social robot and create Pepper apps.
How to choose your first robot?. Need help sorting the options for your first robot? This is the best guide to choose it.
A list of useful robotic sensors for your projects. You'll also learn some ideas on how to use them for your projects. Sometimes, you just need to know what sensors exist to inspire new projects.
What is a robot simulation software? Who needs it? Learn what you can do with these software for your robot.