A behaviour-based control architecture for heterogeneous modular, multi-configurable, chained micro-robots

TL;DR: A new control architecture designed for heterogeneous modular, multi-configurable, chained micro-robots is presented, which can automatically reconfigure its actions to adapt to unpredicted events (such as actuator failure).

Abstract: This article presents a new control architecture designed for heterogeneous modular, multi-configurable, chained micro-robots. This architecture attempts to fill the gap that exists in heterogeneous modular robotics research, in which little work has been conducted compared to that in homogeneous modular robotics studies. The architecture proposes a three-layer structure with a behaviour-based, low-level embedded layer, a half-deliberative half-behaviour-based high layer for the central control, and a heterogeneous middle layer acting as a bridge between these two layers. This middle layer is very important because it allows the central control to treat all modules in the same manner, facilitating the control of the robot. A communication protocol and a module description language were also developed for the control architecture to facilitate communication and information flow between the heterogeneous modules and the central control. Owing to the heterogeneous behaviour of the architecture, the system can automatically reconfigure its actions to adapt to unpredicted events (such as actuator failure). Several behaviours (at low and high levels) are also presented here.

Summary

1. Introduction

• The control architecture described in this article was designed for chained, modular micro-robots.
• These micro-robots are composed of different types of drive module (heterogeneous modules) that can be arranged in different configurations, a feature called multi-configurability.
• The closest robot to the state of the art relies on homogeneous modular robot architectures.
• The MICROTUB architecture is mainly based on behaviours and is divided into three layers: a low-control layer that is embedded in the modules and makes decisions for the modules, a high-control layer that makes decisions that concern the entire robot, and a heterogeneous middle layer that acts as an interpreter between the central control and the modules.
• Two features of the architecture are of special relevance: the module description language (MDL) and the offline control.

2. Robot description

• MICROTUB is a semi-autonomous multi-configurable microrobot for small-diameter pipe inspection and maintenance.
• It has been designed to explore pipes with a camera to detect breakages, holes, leaks and any type of defect [27].
• The micro-robot is heterogeneous and modular, meaning that it is composed of different types of active (they are able to move) and passive (they have to be acted on) modules.
• This interface allows for the mechanical and electrical connection between modules.
• The electrical bus is composed of eight wires: Power (5v) and ground.

2.2. Rotation module

• The rotation module is a two-degrees-of-freedom (DOF) module that allows rotations in the horizontal and vertical planes.
• A combination of these modules can perform undulatory movement (snake-like) that makes the robot move forwards.

2.3. Inchworm modules

• Two modules have been developed to perform inchworm (or worm-like) movements: an extension module and a support module.
• The inchworm mode of locomotion allows the robot to manoeuvre in small spaces.
• The support module is used to fix the microrobot to the pipe; thus, this module does not move.

2.4. Helicoidal module

• The helicoidal module was designed to be a fast-drive module able to push othermodules.
• When the head turns, it goes forwards in a helicoidalmovement (helped by the distribution of thewheels that form a 15° anglewith the vertical) that pulls the body of the micro-robot forwards.
• The wheels of the body help to keep themodule centred in the pipe and prevent the body from turning.

2.5. Other modules

• Some othermodules that have been designed (but not built) are the traveller module, the sensor module and the battery module.
• The traveller module is used to compute the travelled distance by using several wheels featuring encoders and an appropriate algorithm.
• It has been specially designed for pipes.
• The sensor module is a passive module that includes different types of sensor, such as temperature and humidity sensors.
• Currently, the micro-robot requires a cable connection for both the power supply and video transmission.

3.1. Physical layout

• The hardware architecture is shown in Fig. 3; the modules hold an embedded control board, and they are connected via the I2C bus.
• Modules are also connected to their neighbours through a wire (synchronism line).

3.2. Layer structure

• For the proposed architecture, a semi-distributed control has been chosen.
• It collects information from the modules, processes it, and sends information about the situation and state of the robot, as well as commands with objectives, to the modules.
• It includes the following layers: – Heterogeneous Layer: agent that translates com- mands coming from the CC into specific module commands.
• It translates the command ‘‘extend’’ into servomotor movements.
• Mataric [29] defines behaviours as processes or control laws that achieve and/or maintain goals.

3.3. Command exchange protocol

• The command exchange protocol is used for communication between modules and the CC.
• I2C messages are structures composed of three fields: address, instruction and parameters (depending on the instruction, an I2C message may have none, one or several parameters).
• Parameters are codified in the following manner: the first byte codes for the parameter (it is also used to determine the length of the bytes that follow), and the following bytes code for information.
• Finally, instructions can be divided as follows (see Fig. 6): Low-level commands (LLCs): messages sent from the CC to the modules.
• Messages sent from the operator to the central control, also known as High-level commands (HLCs).

3.3.1. LLCs

• LLCs are commands sent by the CC to the modules and the answers to these messages.
• Currently implemented LLC1 and LLC2 commands are shown in Tables 4 and 5 (at the end of the article), respectively.
• The parameters of SIM (Send Info of the Module), AIM (Answer Info of the Module), SIE (Send information of the Environment) and AIE (Answer information of the Environment) commands (in Table 5) are shown in Table 7 (also at the end of the article).

3.3.2. HLC

• The commands are specified in Table 6 (at the end of the article).
• RPL parameters are composed of a first value, which indicates the type of position (Table 8 third column), plus the coordinates [(x, y, z)] in millimetres (three integers) (when needed).
• The DO, SIR, AIR, SIE and AIE parameters are shown in Table 8.

3.4. Module description language (MDL)

• MDL is essential for inferring functions or skills for the entire robot from the module features through rules and inference engines.
• With MDL, it is possible to create units (groups of modules) that are able to perform more complex tasks.
• It is based on a series of indicators that describe the tasks that the module can perform and a range of values that indicate the level of performance for each indicator.
• Thus, MDL indicators canmalfunction or even stopworking in themodule.
• The servomotor of a module may become stuck and may be able to turn only a percentage of its nominal range of motion.

3.4.1. Indicators

• Push in pipe indicates that the module can go forwards by itself inside a pipe, whereas Push in open air refers to large spaces (including large-diameter pipes).
• Rotate in its x/y/z axis means it has a DOF along that axis.
• Attach and Detach to/from other modules is designed for selfreconfigurablemoduleswith active links (SMAs or electromechanical latches) [31,32].
• Sense proximity front/backwards/lateral refers to any sensor that may detect obstacles.
• Power supply indicates that it has a power supply to share.

4. Low-control layer

• This section is dedicated to the behaviour-based control programs running in each of the modules, also called the low-level control.
• The activation conditions are the only conditions that must be met for a behaviour to run.
• Actions are the outputs of behaviours and define what the behaviours intend to do, including modifying the position and orientation of the module, blocking the motors, retrieving module state or actuator position.
• The environment could be inside a pipe, open air7 or general terrain.
• The working mode is information that is essential for every behaviour of the module to perform its tasks.

4.1. Embedded behaviours

• There are several types of behaviour, which have been classified into several categories (as described in [18]) according to the type and complexity of the tasks they perform.
• Some behaviours perform simple tasks, whereas some are based on other behaviours to perform more complex tasks.
• The behaviours that have been defined are as follows:.

2. Perceptual behaviours: (attempt to gather information about the module and its environment): Self-diagnostic, Situation awareness, Environment diagnostic.

• Walking behaviours (move the module): Vertical sinusoidal movement, Horizontal sinusoidalmovement,Worm-likemovement, Push-Forward movement.
• Not all behaviours can act at the same time; thus, they have to be coordinated.
• A description of the implemented behaviours is given next, followed by the coordination mechanisms.

4.1.1. Avoid overheating

• The purpose of this behaviour is to make sure that the accumulated heat is maintained under certain limits to prevent circuit damage.
• The heat produced in the coil of the motors by the electric current may lead to the burning of the coil.
• (2) In the Laplace domain, Eq. (2) is expressed as Eq. (3). (6) The temperature of the environment is measured by a temperature sensor; the electrical current is obtained from the measurements of the sensors and the electrical and thermal resistance; and thermal capacitance is considered to be constant.
• Fig. 9 shows the evolution of one of the servomotors of the rotation module under different situations.
• When the servomotor releases, the temperature starts to decrease (from D to E), and when the servomotor is commanded to perform the movement again, the temperature again increases (from E in advance).

4.1.2. Avoid actuator damage

• The purpose of this behaviour is to ensure that the torque of the motors remains under certain limits to avoid damage to themotors or actuators.
• If the torque exceeds a certain limit, the servomotors are immediately released.
• This purpose is achieved by keeping the instant current intensity under a certain limit, which has been determined experimentally.
• The consumption increases very fast, and consequently it should be blocked below 120 mA.

4.1.3. Avoid mechanical damages

• This behaviour is in charge of the mechanical security of the module, resolving any possible danger it may encounter owing to improper use of the actuators.
• Singular points are produced, for example, when the links of each arm are aligned.
• They are produced at angles of 25° (inside the workspace) and 147° (limit of the workspace).
• The higher value can only be avoided by using software (see Fig. 11(b)).
• Additionally, as described for the extension module, the mechanical design prevents that position from being reached, but that position should also be avoided.

4.1.4. Self-diagnostic

• The purpose of this behaviour is to examine the functioning of themodule:whether the actuators canmove,whether the levels of intensity and torque are acceptable, whether the communication bus is working, whether the synchronism line is functioning, or whether the sensors are working correctly.
• This behaviour records the setpoints (desired positions) of the actuators and compares them with their real positions.
• If the positions are not approaching (and there is no problem with the torque and intensity, meaning it is not blocked), then there may be a problem with the actuator, and an alarm state is activated and communicated to the CC.
• To verify the synchronism lines, in the configuration check phase, the behaviour checks if the signals Sin and Sout have been activated at any time.

4.1.5. Situation awareness

• This behaviour attempts to determine the position of the module/micro-robot: inside a narrow pipe, a wide pipe, or open air.
• It makes use of the contact sensors, infrared (IR) sensors, and the intensity and torque control system of the servomotors, among other sensors.
• The touch (and camera) module plays a very important role because it features touch sensors to detect obstacles, which, in this case, are elbows and bifurcations.
• Through the contact sensor, the module can detect whether it has collided into something, and other behaviours may act accordingly.

4.1.6. Vertical and horizontal sinusoidal movements

• Modules with rotational DOFs can perform several movements (some of them are similar to snake-like rolling, rotating, or lateral shifting) based on a central pattern generator [33].
• The position of the actuators follows two sinusoidal waves: one for the vertical actuators and one for the horizontal actuators (Eqs. (7) and (8)).
• Inside pipes, it is also possible to negotiate elbows by pushing against the pipe walls.

4.1.8. Push-forward movement

• This behaviour can be found in modules that have selfpropulsion capabilities, such as the helicoidal module.
• This behaviour activates the actuator to move forwards or backwards as commanded.

4.2. Behaviour fusion

• Some behaviours collaborate to achieve their goal , whereas others compete or act independently from each other.
• Behaviours are divided into sets of priorities and tasks.
• Its output can be overridden by LLC1 commands received directly from the CC.
• Perceptual behaviours act independently because they only inform and have no actuator control.
• Their output feeds back to the other behaviours with information regarding broken actuators, current situation, and other parameters.

5. Heterogeneous middle layer

• The heterogeneous layer controls several tasks that take place between the module and the CC and/or other modules, such as communication.
• Each time a command is receivedby themodule, it is processedby theheterogeneous layer and translated into specific instructions for themodule.
• When an action has to be executed (i.e., extend), the CC sends an I2C message to every module with the command to follow.
• The heterogeneous layer of each module translates this message into proper commands for the module.
• The heterogeneous layer also controls the following tasks: communications, configuration check and MDL phase.

5.1. Communications

• The heterogeneous layer receives commands from the CC and sends commands to the CC when the CC asks if there is something to communicate .
• This process is how the modules communicate with the CC or other modules.
• In the inverse procedure, the module sends a command to the CC, and if necessary, the heterogeneous layer translates the message.

5.2. Configuration check

• The purpose of this task is to determine the configuration of the micro-robot and the position of the modules in the robots chain.
• The first time this behaviour acts is after the mechanical connection of the modules and power-up, when the phase of awareness starts: every module knows its position in the modular chain.
• This procedure occurs as follows (see Fig. 14): The CC sends a GPS message to all modules.
• All modules activate their synchronism lines. .
• The second module sends a PC1 message and puts its Sin synchronism line down, and thus, the first module knows it has finished.

6. High-control layer

• The CC represents the high-control layer in the control architecture.
• It is also based on behaviours that target the entire micro-robot.
• To determine the capabilities of the robot, the CC makes use of an inference engine and a set of rules that make use of the MDL commands from each module to set the capabilities for the entire micro-robot.
• Modules can be grouped into units to develop different capabilities; these units can in turn be grouped into super-units to possess even newer capabilities.
• The capabilities of the entire micro-robot are the consequence of a combination of the capabilities of all modules and the position of the modules in the chain.

In the first case, the chain could perform an inchwormmovement, whereas this is not possible in the second one. There are three possible locations for the modules:

• They can develop their capabilities independently of where are they placed, also known as Anywhere.
• Anywhere Sequential Adjacent Robot Bat Rot +.
• Then, capabilities are inserted in the rules, and those that are fulfilled are activated.
• The CC can also deduce or infer which modules are needed for a specific task.

6.1. Behaviours

• Continuing with the classification made in Section 4.1, the behaviours that have been defined for the CC are shown in the following list.
• As explained previously, some behaviours perform simpler tasks, whereas more complex behaviours are based on these to perform more complex tasks.
• Balance/stability, also known as 1. Postural behaviours.
• Edge following, Pipe following, Stripe following, also known as 4. Path following behaviours.

6.1.1. Balance/stability

• This behaviour is responsible for determining the orientation of the robot and changing it when necessary in order to be in the correct position for the current task.
• If neither of them is in the right position, the behaviour will make the necessary movements to place the module in the right position.
• In the vertical sinusoidal wave movement, if the robot lays down, it is necessary to recover the position before continuing with the vertical sinusoidal movement.
• In (b), the robot makes an arc and consequently falls down as shown in (c).
• Then, it orients itself into a straight position, leaving the first degree of freedom vertical.

6.1.2. Walking behaviours

• The move straight forward/backward behaviour controls the forward and backward movements of the micro-robot.
• The use of one or another depends on the type of modules comprising the robot, the predominant modules, the environment through which it is moving and the state of the module (e.g., in terms of power supply andmechanical viability).
• If the predominant modules are rotation modules, a snakelike gait is performed.
• They only have to relay the signals coming from the synchronism line.
• As mentioned previously, there are several types of movement that a micro-robot can perform, such as lateral shifts and rolling gaits.

6.1.3. Obstacle negotiation

• When something is detected in the path of the micro-robot, the behaviour is in charge of selecting the appropriate actions to move around the obstacle.
• The robotmust then select the actions to negotiate the turn.
• When an obstacle is encountered in the open air, it is slightly more complicated because there are many available options.
• The easiest way is to go back and then slightly turn and go forwards.
• If the object is detected again, the same algorithm is performed.

6.1.4. Path following behaviours

• Edge followingmakes use of distance (IR) and touch sensors and seeks to keep the micro-robot from operating too close to a wall or object.
• Depending on the measurements received from the IR sensors of the modules, the behaviour will output the coordinates where the robot should go.
• Pipe following controls themovement of the robot inside a pipe, trying to keep the best movement gait and negotiating elbows and bifurcations.

6.1.5. Wandering

• This behaviour controls the movement of the robot when there is no specific task selected.
• The robot moves around, looking for possible damage and trying to avoid colliding into an obstacle.
• It also may follow the pipes by making a map of the path using the travelled distance measuring system.

6.1.6. Goal oriented behaviours

• The behaviours reach a place and reach a landmark function in a similar manner.
• Starting from its own position, the behaviour estimates where the objective is and moves the robot in that direction.
• The behaviour ’find a pipe break’ utilises the wandering behaviour tomove inside the pipewhile looking for breaks or holes with the camera and IR sensors.
• The repair behaviour is an example of what will be possible when repairing tools are developed and added to the robot.
• The behaviour will control moving the robot while it repairs the damaged pipe.

6.2. Behaviour fusion

• The behaviour fusion scheme for the CC algorithms is shown in Fig. 17.
• Higher-level behaviours (i.e., path following, obstacle negotiation, exploration (wandering) and goal oriented) follow a subsumption-like procedure in order to coordinate.
• Thus, obstacle negotiation is the highest-level behaviour.
• This output is received by the walking behaviours, which compete amongst themselves for the control of themodules.
• The output of the action selection mechanism can be suppressed by the balance/stability behaviour, which is in charge of keeping the micro-robot in the most appropriate position.

6.2.1. Action selection mechanism

• The outputs of the four walking behaviours (go forwards, turn, move laterally and rotate) have to bemerged into a unique output.
• Because these are all competing behaviours, one behaviour must be selected to follow.
• The selection criteria depend on two factors: the situation and the destination of the micro-robot.
• These also encode distance scales, such as near or far.

7. Offline control

• Offline control refers to the control algorithms that occur when the micro-robot is not running (as opposed to online control, which has been covered in the previous sections).
• These offline algorithms aim to select the best configuration of the micro-robot (regarding both module position and parameter configuration) for later use in the online control.
• A physically accurate robotic simulation system has been developed to provide a very efficient method of prototyping and verifying control algorithms, hardware design, and exploration systemdeployment scenarios.
• Two types of GA have been developed: configuration demand: in heterogeneous configurations, for a given task, the GA has to determine which modules to use for an optimal configuration and/or the optimal position of the modules in the chain.
• The results of these offline algorithms feed the action selection mechanisms and the inference engine rules of the CC, helping to develop new rules.

8.1. Validation

• Validation experiments have been performed regarding not only external parameters (position, velocity) but also internal variables (torque, intensity).
• The simulator has been validatedwith data taken from real modules to adjust its parameters as much as possible, to be able to generate newmovement patterns and gaits, and to test new module concepts.
• Table 10 shows some tests performed in the helicoidal module at different slopes.

8.2. Simulation

• Several examples of the use of the architecture are provided.
• Each of them is well suited for each respective situation in pipes or open air.
• After interconnecting the modules, the system is aware of the configuration of the robot.
• The combination of several rotationmodules plus an inchworm unit leads to several possible movements.

8.3. Optimisation

• A micro-robot composed of six rotation modules performed a snake-like gait.
• The algorithm goal was to optimise its sinusoidal wave parameter to move as fast as possible.
• The chromosome was composed of 21 bits: seven each for the amplitude, angular velocity, and phase.
• The results of the algorithm (for which the parameters can be seen in Table 11) are shown in Fig. 23.

8.4. Real experiments

• In this section two experiments made with the real robot are presented.
• In the second experiment (Fig. 25), a snake-like configuration is presented.

9. Conclusions

• A control architecture for chained, modular robots composed of heterogeneous modules has been presented.
• The control architecture is structured in three levels.
• C. Unsal, P.K. Khosla, Mechatronic design of a modular self-reconfigurable robotics system, in: Proceeding of the 2000 IEEE International Conference on Intelligent Robots and Systems, pp. 1742–1747. [11].

Figures

Table 1 Types of parameters.

Fig. 12. Elbow negotiation inside pipes.

Fig. 5. I2C frames.

Fig. 6. HLC and LLC commands.

Fig. 16. Contact, rotation, helicoidal and passive modules inside a pipe.

Fig. 17. Behaviour fusion scheme for central control behaviours.

Table 4 LLC1 commands.

Table 2 MDL indicators.

Table 3 MDL values.

Table 5 LLC2 commands.

Fig. 11. Extension module at its higher and lower positions.

Fig. 10. Maximum servomotor consumption with blocking.

Fig. 15. Example of orientation behaviour.

Fig. 23. Results of GA algorithm in open air (parameter optimisation).

Table 11 GA experiment PO 1: Open air.

Fig. 24. Wormmodule tests.

Fig. 25. Negotiating an elbow inside a 36 mm diameter pipe.

Fig. 14. Configuration check sequence diagram.

Table 6 HLC commands.

Table 7 SIM and AIM, SIE and AIE parameters.

Table 8 SIR, SIE and RPD parameters.

Frequently asked questions

Q1. What are the contributions mentioned in the paper "A behaviour-based control architecture for heterogeneous modular, multi-configurable, chained micro-robots" ?

In this paper, the authors present a control solution for chained, modular robots composed of different types of module ( heterogeneous modules ) that can be arranged in different configurations, a feature called multi-configurability.