Cyberbotics' Robot Curriculum/Intermediate programming Exercises

In the previous chapter, you learned to manipulate the e-puck devices in detail by using the C programming. You have now the technical background to start this new chapter about the robotic behavior. Different techniques will be used to program the e-puck behavior. Notably, you will see that your robot has a memory.

Program an Automaton [Intermediate]

During this exercise, you will convert an FSM of the chapter Beginner programming Exercises in the C programming. First, a simple example will be given, a new version of the exercise Simple Behavior: Finite State Machine. Then, you will create your own FSM. It will be a new version of the exercise Better Collision avoidance Algorithm.

Open the World File

Open the following world file:

.../worlds/intermediate_finite_state_machine.wbt

You should observe the same world as in the section Simple Behavior: Finite State Machine.

An Example of FSM

According to the figure Sensors to actuators loop.png, the main loop of your program should always execute its instructions in the following order:

1. Obtain the sensor values
2. Treat these values according to the expected behavior
3. Sends commands to the actuators

In our case, the behavioral part of the robot is modeled using an FSM.

[Q.1] Locate in the given C programming code where are these 3 points. Explain what operations are performed in each of these points.

[Q.2] Describe how the FSM is implemented, i.e., how the current state is modeled, which control structure is used, what kind of instructions are performed in the states, what are the conditions to switch from a state to another, etc.

Create your own FSM

[P.1] By using an FSM, implement a wall following algorithm. (Hint: start to design the structure of the automaton and then find how the transitions are fired and finally set up parameters empirically.)

*Lawn mower* [Intermediate]

In this optional exercise, you will discover another topic of the robotic: the exhaustive research, i.e., your e-puck will move on a surface having an unknown shape, and will have to pass by every place. A cleaning robot or an automatic lawn mower is a typical application of this kind of movement. There are different ways to treat this topic. This exercise presents two of them: the random walk and the walk ”by scanning”.

The random Walking

Open the following world file:

.../worlds/intermediate_lawn_mower.wbt

You should see a grassy board with a white hedge. For the moment, the robot controller is the same as this of the previous exercise, i.e., a simple FSM which lets return your e-puck when it meets a wall. In this subsection, you will create a random walk.

When your e-puck meets a wall, it must spin on itself and go in another direction as depicted in figure below. The next figure depict a possible automaton for a random walk.

For generating a random integer between 0 and X, import the standard library (#include <stdlib.h>) and the time library (#include <time.h>), and write the two following instructions:

// The utility of this line is to have at every simulation a different
// series of random number
srand(time(0));

// change X by the maximal bound (in the double format)
int random_value = X * rand() / (RAND_MAX+1);

In a random walk, this figure shows the possible output ways when an e-puck detects an obstacle.

A possible automaton for a random walk.

[Q.1] Which part of the random walk is impossible to realize by using BotStudio?

[P.1] Implement the automaton given in the figure: Random Walk. For the stop conditions, you can either use a timer or use a condition over the encoders. (Hint: you can merge the ”turn - left” state and the ”random turn - left” state. Ibid for the right part.)

[Q.2] Generally speaking, is a random walk algorithm efficient in term of surface coverage? (Hints: Does the e-puck pass by every point? Are there places where the e-puck spends more time?)

A walk ”by scanning”

Another solution for performing an exhaustive coverage is to ”scan” the area as depicted in figure. Firstly, a horizontal scanning is performed, and then, when the robot has no more possibilities to go on, a vertical scanning is performed. The corresponding automaton is depicted in the next figure. This automaton is the biggest you have seen until now.

A possible trajectory of a walk ”by scanning”

A possible automaton for walking ”by scanning”. OF, OR and OL means that an obstacle is detected respectively in front, at right or at left of the robot. FR and FL means that no obstacle is detected respectively at right and at left of the robot.

[P.2] Implement the automaton given in the figure: "by scanning". (Hint: you can use the symmetry of this automaton for a shorter implementation.)

[Q.3] Generally speaking, is the walk ”by scanning” algorithm efficient in term of surface coverage? (Hints: Can you find another topology of the room in order to have a place where the e-puck never passes? Are there places where the e-puck spends more time?)

Your Progression

At this moment, you know how the program uses an FSM for creating a robot behavior. An FSM can be formalized mathematically. Moreover, there is a theory behind this concept: the automata theory. FSM is only a part of this theory. You can find there other kinds of automata. For example, a probabilistic automaton has probabilities on its transitions. So, a state and fixed sensor values may have different next states. For more information about this topic, you can refer to:

Automata theory

This is a good starting point. In the literature, you will find several related books.

Behavior-based Artificial Intelligence

Until now, you have learned to program a robotic behavior by using a finite state automaton. The three following exercises will explain you a completely different way to treat this subject: the behavior-based robotic that was introduced by the professor Rodney Brooks in a paper of 1986.

The behavior-based robotic is a way to create a robotic behavior (to program the robot controller). The idea is to separate a complex behavior into several smaller behavioral modules. These modules are independent and semi-autonomous. They have a delimited role to play. They work together without synchronization. Typical examples of these modules could be: ”go forward”, ”stay upright”, ”stop if there is an obstacle”, ”follow a wall”, ”search food”, ”be happy”, or ”help the community”. You may observe that these examples are placed hierarchically. Down in the hierarchy, there will be the reflex modules (like ”stay upright”). Up in the hierarchy, there will be the goals of the robot (like ”find food”). A reflex module can influence its hierarchical superiors. Indeed, if you stumble, the fact to stay standing is the most important: the order coming from your foot sensation dominates your ability to think.

The external structure of a module is shown on the figure. A module receives input values directly from the sensor or from another module. These values can be inhibited by another module. Similarly, the output values are directed either directly on an actuator or on another module. Finally a module may have a reset function.

There is several ways to implement these modules. We decided to use C functions for modeling them. Indeed, a function receives arguments as input and returns output values. For the code simplification, some of these values are stored in global variables in order to facilitate the communication between the modules.

The external shape of a behavioral module

Behavioral Modules [Intermediate]

In this exercise, you will observe practically the behavior-based robotic with two modules: an obstacle avoidance module and a wall following module. First, you will observe the modules independently. Then, you will mix them together.

This exercise is closely related with the two following ones.

Open the World File

Open the following world file:

.../worlds/intermediate_oam.wbt

You should observe an environment punctuated by obstacles. Don't hesitate to move them or to overlay them.

Obstacle avoidance Module (OAM)

The given robot controller uses actually only the obstacle avoidance module (OAM). This module is a reflex module. It will run all the time. It receives as input the IR sensor values. If an obstacle is detected in front of the e-puck, the OAM will compute its own speed estimation in order to avoid the collision. It can only spin the robot on itself (left speed = - right speed). Finally, the OAM actualize the side variable in order to memorize where the wall is. This information will help other modules.

[P.1] Run the simulation both on the virtual and on the real e-puck.

[Q.1] Describe the e-puck behavior. What is its reaction when it meets a wall? What is its trajectory when there is no obstacle in front of it?

[Q.2] The OAM generates a motor speed difference, but the robot goes forward. Why?

[Q.3] In the OAM function, what is the way to compute the motor speeds difference (the delta variable)?

Wall following Module (WFM)

The second module (named wall following module (WFM)) creates a constant motor speed difference according to the side variable. Its role is to attract the e-puck against the wall. If there was only this module, the robot would collide with the wall. Fortunately, if the OAM module is also enabled, it will create a repulsion. The combination of these two modules will create a more powerful behavior: the robot will be able to follow a wall. In biology, this phenomenon is called emergence.

The figure depicts the interaction between these two modules. Horizontally, the schema separations are similar to the figure Sensors to actuators loop.png, it's the perception-to-action loop. Vertically, the modules are separated by hierarchical layers. The most bottom layer is the reflex one. The black arrow from the OAM to the WFM symbolizes the side variable.

The interactions between the OAM and the WFM

[P.2] In the main loop of the main function, uncomment the wfm() function call and compile your program. Run the simulation both on the virtual and on the real e-puck. Observe the robot behavior. Try to move the obstacle at which the e-puck is ”linked”.

[Q.4] Describe the e-puck behavior.

[Q.5] Compare the figure and the given controller code. (Hints: How the black arrow is implemented? How the sensor values are sent to the modules?)

[Q.6] Explain the utility of each term of the sum present in the wb_differential_wheels_set_speed(...) function call.

*[P.3]* In simulation, try to obtain an e-puck trajectory as smooth as possible by changing the macro variables (see the variables defined with the #define statement). The figure with two arrows (green and red) depicts a smooth trajectory in comparison of a sinuous one. Note that a smooth trajectory depends a lot on the environment, i.e., if you obtain a smooth trajectory and you change the obstacle width, your robot will probably have a sinuous trajectory.

The green arrow represents a smooth trajectory, while the red arrow represents a sinuous trajectory.

Create a line following Module [Intermediate]

In the previous exercise, you observed the interactions between two modules. In this exercise, similarly, you will see some other modules and their interactions. The aim of this exercise is to observe how three modules can generate a powerful line following controller. At the end, you will create your own module.

Open the World File

Open the following world file:

.../worlds/intermediate_lfm.wbt

The e-puck is on the starting blocks for turning around the ring.

Three modules for a Wall Following

The robot controller of this exercise uses three modules:

• Line following module (LFM): First, this module receives the linear camera values (the last line of the camera). With the help of the find_middle(...) function, it finds the middle of the black line in front of the robot. Then, it computes its own appreciation of the motor speeds. Similarly to the OAM, this function only creates a motor speed difference. This is a high level module. Its inputs values can be inhibited.
• Line entering module (LEM): This module observes also the linear camera values. It notice if there is a line in the robot field of view.
• Line leaving module (LLM): This module works collectively with the LEM. It notice if there is no line in the robot field of view.

The utility of the LEM and LLM appears when the e-puck enters or leaves a line. With these modules, these two events are mastered. In this exercise, these two modules are used to inhibit the LFM if there is no line to follow. This enables to move straightforward. In the next exercise, we will use these two events for a more helpful purpose.

The interactions between these modules are depicted in the schema.

Interactions between the LFM, LEM and LLM

[P.1] Run the simulation both on the virtual and on the real e-puck.

[Q.1] Compare the figure and the given controller code. Don't look at the UTM yet. (Hints: what is the role of the LFM's inhibitor, how the LEM and the LFM are related in the code, why is there no links between them in the figure, etc.)

[Q.2] Explain the algorithm of the LEM.

[P.2] Modify the given code in order switch on the 8 LEDs when the e-puck detects a line and switches them off when there is no detected line.

Your own Module

[P.3] Implement a new module (called utm()) which will let the e-puck perform a u-turn when there is no more line in front of it. This module will work when the WFM is inhibited and conversely. In this module, the robot should only generate a motor speed difference.

Mix of several Modules [Intermediate]

During the two previous exercises, you observed 5 different modules. Now, you will combine them to obtain a more complex behavior.

Open the World File

Open the following world file:

.../worlds/intermediate_behavior_based.wbt

You should observe the world depicted on the figure. A line is painted on the ground. It has a ”C” shape. Some obstacles are dispersed along the line.

The environment of this exercise

Combination of several Modules

The goal of this exercise is to obtain the following behavior: the e-puck follows the line, but, if it detects an obstacle, it must go round the obstacle until it finds again the line.

The given robot controller contains all the previous modules, but there is no link between them. The schema shows a possible way to link them. The most important point in this schema is to observe the interactions from a module to another:

• OAM: It's the only reflex module. If the OAM detects an obstacle, it must inhibit the LFM in order to avoid its influence. The OAM has also to inform the WFM where is wall.
• LEM: Its role is to remove the inhibition on the LFM when it detects a black line. Moreover, it has to inform the WFM that is has to stop following the wall.
• LLM: It has to inhibit the LFM if the black line is lost.

Interactions between all the modules

[P.1] Implement the interactions between the modules to obtain the behavior described above. Refer to the schema for the interactions. (Hint: The code pieces, that you have to modify, are labeled by a TODO comment.)

[Q.1] What are the advantages of the behavior based robotic in respect to finite state machine based robotic? And what are the disadvantages? Is it conceivable to use a combination of these two techniques? Give an example.