Sage Journals: Discover world-class research

Abstract

This paper describes one of the challenging issues implied by scientific infrastructures on a mobile robot cognition architecture. For a generally applicable cognition architecture, we study the dependencies and logical relations between several tasks and subsystems. The overall view of the software modules is described, including their relationship with a fault management module that monitors the consistency of the data flow among the modules. The fault management module is the solution of the deliberative architecture for the single point failures, and the safety anchor is the reactive solution for the faults by redundant equipment. In addition, a hardware architecture is proposed to ensure safe robot movement as a redundancy for the cognition of the robot. The method is designed for a four-wheel steerable (4WS) mobile manipulator (iMoro) as a case study.

Keywords

mobile robot autonomous vehicle drive architecture design remote handling cognition

1. Introduction

Scientific facilities (SFs) and research infrastructures are indispensable in realizing the dreams of human beings.

They necessitate a combination of state-of-the-art technologies together with reliability, availability, maintainability and safety (RAMS) [1]. The development of autonomous or semi-autonomous mechatronic systems for such an environment is a challenging issue. The challenge arises when the facilities turn into hazardous environments for humans and/or machines. In this case, a robot is utilized in order to minimize human intervention in the non-suitable conditions of the workspace. The robot is used in order to reduce the risks for humans “as low as reasonably possible or achievable” (ALARA or ALARP) [2]. Consequently, it is not acceptable to employ robots or any complex system in SFs if they will become an insecure system which needs on-site maintenance [3]. Therefore, the service robot has to be safe in order to avoid undesirable changes in the environment, and it has to be fault tolerant in order to recover itself without direct human intervention, especially for leaving the test environment.

This necessity is a key requirement for such a robot or any device acceptable for SFs [4].

The aim of this paper is a discussion of a fault-tolerant architecture for the fulfillment of the above-mentioned requirements as well as common needs for service robots, such as flexibility and modularity.

Figure 1.

The four wheel steerable mobile manipulator (iMoro)

The contributions of this paper can be divided into higher-level strategies and lower-level practical issues for design improvements of a safety standards-compatible, fault-tolerant robot for SFs. This paper reflects the decomposition of a high-level mission to generate several commands and the structural behavior of the robot. Next, we describe the necessary modules for achieving the required functionalities of the robot. Moreover, to make the robot compatible with safety requirements, a safety anchor is proposed to provide a low-cost redundant decision-making unit. It maintains the robot's behavior during its mission as well as its exit in the case of unforeseen problems. The design considers the requirements for a robot tasked to explore the Large Hadron Collider (LHC) tunnels of the European Organization of Nuclear Research (CERN) as a sample SF.

Generally speaking, a cognition architecture can be divided into four control schemes: deliberative, reactive, hybrid and behavior-based [5];

Deliberative Sense, plan, and then act.

Reactive React on a predefined action to a perception relation.

Behavior-based Distribute thinking over acting.

Hybrid Combine deliberative and reactive – think slowly, react quickly.

Although all autonomous robots have to include deliberation [6, 7], a pure deliberative architecture cannot accomplish the requirements of contemporary applications [8]. In some cases, it is used in assisting the operator using autonomous functionalities, and in order to predict possible accidents [9]. A study conducted recently addressed several aspects of a deliberative control schema as a divide-and-conquer problem-solving strategy [7].

The hybrid control topology is developed to overcome the limitations of deliberative control and reactive control. It uses the reactive control scheme to respond to environmental changes and high-level planning to handle complex tasks [10, 11]. During this research, we partially apply a hybrid control topology for the architecture of a mobile platform. Moreover, the safety of the mobile manipulator is another issue addressed in this study via a service robot with a lightweight arm [12].

The aim of this paper is to determine a strategy for utilizing a mobile manipulator in inspections planning and scheduling [13] and interventions instead of human intervention [2]. In order to lower the risks, it is more reliable to control the behavior of the autonomous identification or model-based control process by a safe configuration [14]. We propose a redundant safety-compatible architecture to tolerate the faults of the main architecture. It contains a set of actions activated by pre-selected processes through triggers.

2. Problem definition

This paper represents an architecture for a Modular Mobile Manipulator System (MMMS) to be used as a road map for the design and implementation process of mobile robots targeting SFs. The concepts are designed based on the statement of needs and requirements as a part of the PURESAFE project systems engineering documents [4]. The project, “Preventing hUman intervention for incREased SAfety in inFrastructures Emitting ionizing radiation” (PURESAFE), has been initiated to advance theoretical and experimental knowledge regarding semi-autonomous mobile manipulation within the ionizing radiation and contaminated environment of accelerators, in particular the tunnels inside the CERN and the GSI Helmholtz Centre for Heavy Ion Research, Facility for Anti-proton and Ion Research (GSI/FAIR). While perception and navigation are challenging issues for mobile platforms, robot intervention in SFs and hazardous environment imply more significance of architecture design considering fault tolerance and safety in robot cognition.

Although a variety of requirements should be considered in the architecture design of the robot, we only discuss a sample solution to a task scenario described in 2.1. In addition to the challenging issues of mobile manipulator architectures, this research considers an important and mandatory constraint for the robot:

“As a service robot, the robot should not cause human intervention in the test environment. In case of failure in mission, it should be able to return to its station.”

This restriction affects the risk assessment results and highlights the immobility of the robot as the most severe failure of the robot. Moreover, the presence of the robot in the neighborhood of scientific test equipment during operation or maintenance time, arises failure severity even with a low occurrence chance. For instance, any damage to the experiment infrastructure results in a SF shutdown and human intervention in hazardous environment. The robot perception, planning and navigation should be safe and reliable so as to guarantee avoiding any destruction or unplanned shutdown in the SF and to ensure the robot's ability to escape from the test environment in an emergency. To overcome this problem, the proposed architecture design of the robot will be addressed in the following sections. We use IHA Mobile Robot (iMoro) as a case study for experiments and the simulations proposed in this paper. It is also under investigation for the further development of robot intervention for SFs by Tampere University of Technology.1

Similar to other complex systems, SFs are the subject of frequent inspections and maintenance during their life-times. Moreover, modifications, repairs and inspections have to be accomplished over a short duration to prevent the shutdown of scientific experiments, aging of the robot body, the effects of ionizing or non-ionizing contamination, and hardware corrosion. In the following section, we will define a sample mission for iMoro and describe the necessary hardware and software components in the rest of the paper that are compatible with the described constraints.

2.1 Task description

A mobile manipulator can have wide range of applications within SFs. In this section, to summarize the system description, the authors define a mission as a sequence of tasks to develop necessary hardware and software components. A sample inspection covers the following description:

Mission Receive commands on control room Human Machine Interface (HMI): In point “A”, Fast forward to section “B” addressed on the CAD-based map. Prepare for tele-operation around the device number “36” and then inform the operator for a semi-autonomous operation. Touch the object defined by the operator. Inspect the area defined by the operator and transmit preliminary results. Finally, come back to your station and give detailed data report.2

To task the robot mobile manipulator inside a hazardous area of a SF, there are several limitations and requirements. Some of the key requirements are listed below:

Requirement 1. The physical or chemical effects of materials and test equipment in the environment can affect the work performance and lifetime of electrical components.

Requirement 2. The facilities are mostly designed for humans, the test equipment or special machines accessible through different corridors. There is no dedicated environment or specific landmarks – or setups for a robot except its station. In other words, the environment is unstructured for a robot.

Requirement 3. A lack of communication can frequently occur. The robot shall be tolerant to failures of Wi-Fi or delays of GSM transmitted signals.

Requirement 4. The purpose of utilizing a robot is to prevent human intervention in hazardous environments. Therefore, during the operation of the robot, the area is not suitable for humans, and all robot operations shall be remotely controllable.

Requirement 5. In case of failure, the robot should be able to leave the SF.

Considering these requirements, the mission can break down into sequential tasks. Since, in most cases, the mobile manipulator applications are similar to the described mission, we describe here those tasks, while we describe the overall solution later on.

Task 1. Initialization

Get the global map $^{ℐ} M$ , initial pose $^{ℐ} T _{ℬ_{0}}$ , destination $^{ℐ} T _{ℬ f}$ 3, a final workspace $^{ℐ} W$ , the initial status of the robot, and calibration parameters. Monitor output of the sensors and command their initialization. Verify their functionality and consistency with the initialized variables. Initialize the actuators. Perform a predefined motion and examine the actuators and sensors by verifying the consistency of the commands and feedback.

Task 2. Planning

Convert the global map into a 2D occupancy grid $^{ℐ} M'$ . Plan an energy-optimal obstacle-free path from $^{ℐ} T _{ℬ_{0}}$ to $^{ℐ} T _{ℬ f}$ within $^{ℐ} M'$ . Plan for wondering around the position $^{ℐ} T _{ℬ f}$ within $^{ℐ} W$ . Estimate the elapsed time and power consumption for all of the future tasks programmed within the mission with a safety margin. Compare the power status of the batteries with the estimated power consumption. Wait for extra charge in case of insufficient power.

Task 3. Autonomous Running Mode

Run these modules in parallel, repetitively:

Perception Perceive any change in the environment and status of the robot compared to the preliminary planned motions.

Planning Look–ahead and plan for local movements regarding the high–level commands received and the local obstacles and costs for doing the job.

Actuation Run the planned actions while receiving the joints' feedback for the closed–loop actuator–level control.

Exception Handling In case of single point failures, bypass the current sequence and save the algorithm. Batch the logs and transmit to the supervisory room.

Fault Detection Once in a while, conduct a survey among the software and hardware modules with their model. In case of the detection of unpredicted motions and feedback signals, decide for one of these solutions. Run the relevant fault management component. Call the operator for decision making or manual driving. Run the Safety Anchor (described in Section 5).

Watchdog Independently maintain surveillance of the robot software and hardware modules during the operation.

Task 4. Update Mode

After reaching the target position, map the workspace on a detailed map. Extract the optimum features for accurate localization. Define the local stationary coordinate attached to the features. Obtain transformations between the new coordinate and the predefined coordinates. Upload the collected information to the supervisory room while considering possibility of data loss and a delay in connection. Finalize the autonomous mode and switch to the semi-autonomous mode. Call the operator through all of the available networks, such as Wi-Fi or GSM.

Task 5. Tele-operation Mode

Let the operator define the movements in the virtual environment and execute the commands in order. Update the current status for the operator by the minimal transmission of data to overcome any lack of connection bandwidth and to enable the possibility of augmented reality. In the case of selecting an object, run the visual servoing to approach the vicinity of the target object and do any inspection or manipulation as commanded by the operator. At the same time, maintain the prediction of power consumption. Set an alarm when the power reaches the limit of the safety margin. Quit from the position if the operator has finished the operation or else if the power limitation implies a forced return.

Task 6. Finalization Mode

Return to the nearest safe station. Set all the actuators to their home positions. Next, transmit all the gathered data by the high bandwidth connection, including the final status of the robot and its components and the evaluation of the modules that are gathered during run mode. Clear any temporary information. Recharge the embedded power source.

Task 7. Standby Mode

Turn off any high-consumption hardware and keep the control blocks in sleep mode. Wait for the next trigger and another mission.

According to the tasks and their descriptions, the rest of this paper gives an overview of the hardware and then describes the necessary software modules and the architecture designed for the concisely described tasks.

2.2 Sensors

The robot is equipped with several sensors to collect data from its components and the environment. We describe them in the following subsections.

2.2.1 Laser range finder

(LRF) The laser scanner or LRF provides a 2D map of the environment based on the reflection of its infrared beams. The output data comprise pairs of distance and angle based on a predefined polar coordinate attached to the {ℒℛℱ} coordinate. The origin of {ℒℛℱ} which is virtually defined as attached to the axis of rotation of its motor in such a way that the +z direction is collinear to the axis of rotation. Therefore, all the transmitted points rely on the x – y plane of {ℒℛℱ} The corresponding Cartesian representation of the detected point number k by the laser scanner can be defined as LRF Λ _k (x_Ky_K 0).

The number of detected points during one scan, max(k), depends on the field of view (FOV) and the angular resolution of the laser scanner. Note that the source of systematic and random errors in the positions of the detected points are still in the polar coordinate as errors in the distance and angle [15,16]. We can write for the vector of points:

^{ℬ} Λ ​_{ℒ ℛ ℱ} =^{ℬ} T ​_{ℒ ℛ ℱ}^{ℒ ℛ ℱ} Λ

(1)

The output of the laser scanner determines the position of the robot relative to its environment by a Simultaneous

Localization and Mapping Toolbox (SLAM) as described in Subsection 4.2. Moreover, its output can be a local map for obstacle avoidance and heading estimation.

Despite the fact that the LRF is a robust sensor for the navigation of the mobile platform, it fails in the detection of transparent and reflective materials in the environment [17]. It is also hard to detect darker materials at longer distances. Regarding these issues, the sensor can be considered as a safe sensor for short distances (under 20m). Besides the accurate distance angle measurements, it is possible to define warning zones on the same plane. In this case, the scanner transmits the corresponding situation of each zone. This communication can be safe and totally independent of the points measurements, and can be utilized in the safety anchor mechanism described in Section 5. The warning zones can be defined as relay outputs or logical switches on the hardwired network.

2.2.2 Wheel odometry

Each wheel of the robot is equipped by an encoder on the steering and driving servo motors. The measured values for the joint parameters used in the kinematics and then in the path-following controller are estimated based on these data. The steering actuators provide φ _i as a feedback, and the driving actuators feed the driving speeds v_i. These parameters have been used to determine the velocity vectors of each wheel as shown in Figure 2. The resultant data determine the robot's velocity v and angular velocity ω _b and motion direction ψ _v .

2.2.3 Current sensor

The overall current of the mobile manipulator passes through a current sensor. The measured sensor data can be used for the power consumption and then for the estimation of the remaining autonomy time. Moreover, it can sense any abnormal electrical loss during standby or the run-time of the robot. The energy management methods [3] are also applicable to analyze the information gathered from this sensor.

3. Kinematics

In this section, we present a kinematics formulation in the velocity space for the 4WS mobile platform. Although the equation is quite straightforward, it embeds substantial information pertinent to the relative velocities of the body and wheel modules. A general solution is then given for estimating the body's linear and angular velocity using kinematic constraints and encoders data. The solution uses the least squares method to measure the relative consistency of the legs' velocities, thus detecting faulty encoder data. The mobile robot can be fully functional even after losing the functionality of one of its wheel modules. Hence, this approach can be used to single out a faulty leg during the robot's operation.

Figure 2.

Denoted kinematic parameters

3.1 Inverse kinematics

Figure 2 shows a schematic view of a 4WS mobile robot. The denoted parameters for the configuration of the body and the leg modules are presented in the figure. The coordinate frame U{X̂,Ŷ} is the inertial frame. Frame B{x̂, ŷ} is a fixed-body frame defining the heading of the robot, and B_v{v̂, û} is the velocity frame, that is, the unit vector v̂ determines the direction of the robot's base linear velocity vector. Both B and B _v are attached to the robot's base at point Q, which can be chosen at will. The angles ψ _v and θ _B are the angles v̂ and x̂, respectively, in U. The scalar value v is the magnitude of the linear velocity of point Q. The variables ω _B = θ _B and ω _v = ψ _v are the angular velocities of the base and of v̂, respectively. The constant vectors $\vec{Q L_{i}}$ presented in frame B are denoted by $B_{ℓ_{i}, i} = 1..4$ . The angle φ _i is the heading angle of the i^th leg while v_iv̂_i is the velocity vector of the attachment point L _i . The steering and speed control commands for leg i are calculated using φ _i and v_i, respectively. The following kinematic relations hold:

\begin{matrix} B_{\hat{v}} = R (ψ_{v} - θ_{B}) {[100]}^{T} (a) \\ _{v_{i}} B_{{\hat{v}}_{i}} = v^{B} \hat{v} + w_{B} (\hat{z} \times^{B} ℓ_{i}) (b) \end{matrix}

(2)

in which, ẑ=[0 0 1] ^T and R (ψ _v – θ _B ) is the rotation matrix with angle ψ _v – θ _B around the z-axis, that is, frame B _v in B. For motion control purposes, once the control signals ψ _v ,ω _B and v are calculated for the body frame, the desired signals ψ _i and v_i can be derived using above kinematics equations. Notice that only angle ψ _i and not its derivatives appears in (2a-2b) as the angle of vector $^{B} \hat{v} _{i}$ . This fact justifies having steering actuators to be controlled in position mode.

3.2 Forward kinematics

As mentioned earlier, the speed of the drive actuators and the positions of the steering actuators are measured, that is, positions φ _i for the steering actuators and speeds v_i for the driving actuators. In this subsection, the goal is to derive ψ_v,ω _B and v based on the encoders' measurement data, that is, the sets {v_i,φ _i } for i = 1… 4. Clearly, the relative velocity of the wheel modules with respect to each other must be zero. In other words, the set {v_i,φ _i } applied to a leg should be consistent with other sets. Although the set points for the steering and drive commands are exactly with the kinematics relations due to different loads and different servo dynamics. Since the legs are connected to a rigid base, this inconsistency causes the legs to slip with respect to one another. This slippage is different than the overall slippage of the robot, and cannot be observed through odometry data. In order to measure the consistency of the actuators' actual values, we define the following measure:

e_{i} = \frac{1}{4} \sqrt{\sum_{j = 1, j \neq i}^{4} e_{i j}^{2}}, i \in {1, 2, 3, 4}

(3)

where

\begin{array}{l} e_{i j} = (v_{i} ​^{B} \hat{v} ​_{i} - v_{j} ​^{B} \hat{v} ​_{j}) . ℓ_{i j} (a) \\ ℓ_{i j} = \frac{B_{ℓ i} - B_{ℓ j}}{{‖ B_{ℓ i} - B_{ℓ j} ‖}_{2}} (b) \end{array}

(4)

In the above equations e_ij is the relative velocity line L_i to L_j Clearly, if both wheels are synchronized perfectly and no slippage occurs, e_ij is zero. However, as explained before, in practice these variables are not zero and the value e_ij indicates the relative slippage of the wheel modules i and j. The variable e_i is the measure of the relative slippage of one wheel with respect to the other three wheels. In practice, for the mobile robot to move properly, all e_i s must be small. The value of e_i s determine the overall consistency of wheel i with respect to the other modules. Several cases can be considered for different values of e_i.

In the case where:

m i n (e_{i}) > e_{m a x}

(5)

this means that the legs are somewhat faulty and that they are not consistent with one another. Observing such a condition for a pre-specified interval of time should cause the controller to issue a fault signal to stop the robot.

If e_i is large only for one wheel, it can be interpreted such that the wheel is not consistent with the other wheels and that it is being pushed by them. In this case, different strategies can be considered, such as stopping the robot or singling out the faulty leg from the control loop and setting the actuators of the faulty wheel to rotate freely.

Alternatively, more complex strategies can be designed based on the robot's assigned task and application.

After calculating e_i for all the legs and evaluating their values, the forward kinematics problem can be solved as follows. Let $^{B} \hat{v}$ and $^{B} \hat{v} _{i}$ be denoted by their components by [v_x v_y]^T and [v_ix, v_iy]T. Next, (2b) for all the legs can be rearranged into the following equation:

A {[\begin{array}{l} v v_{x} \\ v v_{y} \\ w_{B} \end{array}]}_{3 \times 1} = B

(6)

in which

\begin{array}{l} A^{T} = {[\begin{matrix} 1 & 0 & \dots & 1 & 0 \\ 0 & 1 & \dots & 0 & 1 \\ - l_{1 y} & - l_{1 x} & \dots & - l_{4 y} & - l_{4 x} \end{matrix}]}_{3 \times 8} (a) \\ B^{T} = {[\begin{matrix} v_{1 x} & v_{1 y} & \dots & v_{4 x} & v_{4 y} \end{matrix}]}_{1 \times 8} (b) \end{array}

(7)

Obviously, in the general case the matrix Equation (6) consists of eight equations and three unknowns. A simple least squares solution is given by:

{[\begin{array}{l} v v_{x} \\ v v_{y} \\ ω_{B} \end{array}]}_{3 \times 1} = AB

(8)

Note that the elements of A are the only function of the constant vectors $^{B} ℓ _{i}$ . Hence, A^† = (AA^T)⁻¹ A^T needs to be calculated once. In practice, we need at least three rows of matrices A and B to solve the forward kinematics. Thus, one way to improve the solution is to eliminate the inconsistent wheel module and eliminate the corresponding rows from (6). Our strategy is based on isolating the leg with a maximum of e_i Next, the rows with respect to that leg are eliminated from matrix A in 7a and the least squares is calculated based on this new matrix. In [18], we show the efficacy of the above strategy and further details of the implementation of this approach.

4. Robot software modules

4.1 Dead reckoning

Generally speaking, the time integration of the velocity vector – known as ‘deductive reckoning’ or Dead Reckoning (DR) – for a mobile platform gives its approximate position with respect to its initial pose [19, chap. 20]:

​^{I} x ​_{B} (t) = ​^{I} x ​_{B_{0}} +^{I} R ​_{B_{0}} \int_{t_{0}}^{t}^{B_{0}} R ​_{B} ​ ​ V_{x} (t) d t

(9)

^{I} y_{B} (t) =^{I} y_{B_{0}} +^{I} R_{B_{0}} \int_{t_{0}}^{t}^{B_{0}} R_{B} V_{y} (t) d t

(10)

^{I} R_{B} (t) =^{I} R_{B_{0}} R_{z} (θ_{B} (t)), θ_{B} (t) = (\int_{t_{0}}^{t} ω_{z} (t) d t)

(11)

The driving velocities of the wheels as regards their steering angles and robot kinematics can generate fundamental data for the localization of the mobile platform.

4.2 SLAM

The errors for the mobile manipulator are accumulative during its motion. In order to reduce the errors, it is necessary to compare the position of the mobile base with respect to its environment. The SLAM [20] method provides the change in location of the robot according to its initial configuration. Moreover, it provides the local map of the environment $^{ℐ} M'$ , which is convertible to an occupancy grid for the planning module.

4.3 Path planning

The path-planning module comprises two modes: local and global planning. The planner initially plans the required path through requests from $^{ℐ} T _{ℬ_{0}}$ to $^{ℐ} T _{ℬ f}$ as described in Task 2, namely a global plan. It considers a configuration space extracted from $^{ℐ} M'$ based on the initial information and the foreknown structural conditions [21]. The global planner generates a set of via points, $^{ℐ} T _{ℬ_{v i a}}$ , which channelizes the route to approach $^{ℐ} T _{ℬ f}$ .

The module also implements local planning. It receives the current status and some of the upcoming via points, together with the current local map $^{ℬ} M$ imported from the SLAM module based on the LRF sensor. The outcome of the module is a segment of a smooth and obstacle-free path passing near the via points. It can also be extracted from a motion-planning roadmap framework [22, 23].

4.4 Path following

A path follower controller navigates the robot on the given path and returns the resultant pose. The path-following module considers actuator limitations at maximum velocity and acceleration [24 -26]. The path follower also avoids obstacle on the robot's route.

4.5 Mobile manipulator controller

Manipulators are usually provided together with their specialized controllers. However, coordinated tasks have to be performed synchronously between the path follower for the mobile base and the arm controller [27]. We use a mobile manipulator controller to close the outer control loop that follows the task commands distributed among the mobile base and the arm in a similar manner to [28].

Figure 3.

The robot's software and hardware modules

4.6 Fault management

Besides software fault detection and fault-tolerant techniques [29], it is necessary to monitor, verify and recover the robot's sensory data and actuator commands from the instrumentation and control viewpoint. This section contains a brief explanation of the fault management module's functionalities. As a general requirement for the fault tolerance of safety-critical systems [30, chap.1], the robot has redundancy in actuation and sensation. Four steerable wheels [31] reduce the risk of immobility caused by the mechanical hardware. The wheel odometry, IMU, laser scanner and camera provide redundancy for the perception of the robot. The fault management module's job includes:

Monitoring the input and output of the other modules.

In the case of a single point failure of a module, using an alternative function.

Verifying the consistency of the resultant sensory information from the different sources, for each sensor as well as results of sensor fusion:

Δ T =^{B} T ​_{S_{1}} {(^{B} T ​_{S_{2}})}^{- 1}

(12)

where S₁ and S₂ are the localization or detection data from Sources 1 and 2, respectively. For a perfect system, AT becomes the identity 4×4 matrix. It should be noted that the inverse of a transformation matrix is calculated by the transpose of its rotational part as addressed in [28], Therefore, this calculation cannot be singular. Arguments of ΔT represent the inconsistency of the gathered information.

If ΔT –I_4×4 gives a sensible difference, the module learns the difference.

In case of a change in the learned difference, it calls the calibration maintenance module which in turn calibrates the divergent sensor.

In case of unacceptable divergence of the primary navigation sensors, the module suspends the motion of the robot and reports its status. Following the confirmation of the operator, the control changes to tele-operation mode.

Figure 4.

The loop for the synchronization of the mobile manipulation tasks

Some errors can be solved by outlier detection and the substitution of the fused values. For instance, in the following we describe how, at each segment of the path, the module compensates for small errors between the position and velocity feedback of the wheels.

The localization is obtained by dead-reckoning of the odometry data as described in the previous section. The iMoro mobile platform shown in Figure 1 is used to run the experiments. The desired path that is followed by the mobile platform is a cubic Bezier curve with its control points located at {(0, 0), (2m, 0), (2m, 2m), (0, 2m)}. The path is used with two desired heading profiles. Figure 5 shows the body and legs trajectories for following the path with 180° rotation of the main body. Moreover, Figure 6 shows the same trajectories, this time for −90° rotation of the body. Figure 5 also depicts the estimated location of the body's Instantenous Center of Rotation (ICR) during its movement as red dots.

Figure 5.

Experimental results: the robot's trajectories, 180° rotation

Figure 6.

Experimental results: the robot's trajectories, −90° rotation

Figure 7.

Experimental results: Least squares error before and after the elimination of the outlier leg

Figure 8.

Experimental results: leg number for the most inconsistent leg

The forward kinematics solution is solved both with and without eliminating the leg with maximum e_i Figure 7 depicts the pseudo-inverse error before and after the elimination. From the figure, it is clear that the error is reduced considerably by eliminating the leg with maximum e_i from the forward kinematics solution.

Figure 8 shows the sensor number with the biggest e_i at each sample time. From the figure, it is clear that, at each period, a different leg has maximum e_i. This is due to the change in the dynamic loads acting on each leg during movement. Having one specific leg with maximum e_i all the time could indicate a defect in that leg.

5. Safety Anchor (SA)

It is a key requirement for a robot in SFs to be safe or at least compatible with the safety standards' requirements. The first solution is to make the whole system certified by the safety integrated standards, for instance, the Safety Integrity Level (SIL) II or SIL in standards. The solution is suitable for mechatronic systems with lower flexibility and mass-produced products due to its complexity and cost. On the other hand, the perception and navigation of the mobile platform include a variety of procedures and instruments which are not necessarily safe. For the software, certain test techniques exist for the verification of the safety standards' compatibility. However, there are many issues confronting the verification of decision-making for an autonomous robot, even for industrial controlled environments, if we assume that the robots are Automated Guided Vehicles (AGVs). Moreover, the compatibility of the processes and the required modules for decision-making cause an increase in the robot's production costs and verification complexity. Furthermore, the robot must be equipped with safe instruments and safe process units, which is impossible for several sensors. For instance, vision-based estimations and acceleration measurements are not compatible with the current safety regulations.

In order to make the system tolerant to faults in these modules, we define a redundant controller. The controller is supposed to be safety compatible for both the hardware and software. The software must be reactive and simple, and therefore easy to examine. The hardware requirement for such software becomes suitable for implementation on a safe Programmable Logical Controller (PLC) or any other safe process unit. It should be noted that target application for this design comprises tunnels and corridor-shaped SFs. Locally, the watchdog on the robot, and remotely, the operator, can trigger the SA when the functionality of the robot is not as expected.

5.1 Hardware architecture

A schematic hardware architecture of the mobile platform is shown in Figure 9. The sensors and actuators are connected to the embedded PC, which runs all of the necessary cognition subsystems. The embedded PC is connected to the motor drives, arm joints, laser scanners, cameras, IMU and encoders. Most of the robot sensors provide the perception of the robot and its environment for object manipulation. The embedded PC is the target of the remote development method described in [32] during its run-time and debugging and the development of its algorithms. It should be noted that any failure in the embedded PC during its run-time can cause the immobility of the robot or a collision with other facilities in the environment.

In order to avoid failure, the authors propose adding a safety anchor topology as a redundant decision-maker for the mobile platform, as shown in Figure 9. During the robot's run-time, in case of any embedded PC failure, the safety PLC can be triggered by the watchdog or supervisory system to manage the mobile platform in escape mode by a reactive controller. Ignoring complex mathematical procedures and high-level algorithms, the PLC solves the navigation problem at the lowest possible level to guide the robot to safe places [33] before the operation of the accelerators. The redundant system can benefit from off-the-shelf, safe and certified components to guaranty the safety of the system.

The LRF sensors provide for the availability or occupancy of any predefined zone by toggling the corresponding signal. The signal goes through the logical circuits of the PLC. By limited conditional statements programmed on the PLC, the system reacts by commanding the motor drives in real-time. Since the logic, codes and connections are reactive, time-invariant and simple, their verification is easier and more dependable. In the same architecture, we can also program and utilize the embedded PC by means of the remote development method described in [32, 34].

Figure 9.

The hardware architecture related to cognition; the yellow parts are the proposed safe components

5.2 SA logic

The hardware described in 5.1 needs a special setup, adjustment and programming. The LRF zones need the warning and alarm zones to be set up similar to the zones shown in Figures 10, 11 and 12. The reason for using the LRFs is their flexibility in the definition of sensitive zones and their compatibility with the safety standards. Generally speaking, the pseudo-code for the PLC can show the reactions between the sensors and actuators in Table

1. It should be noted that the system design is reactive. However, for the clarity of the commands' order, it is shown as a sequence of commands.

Table 1.

The pseudo-code for the PLC

1 Initialize the sensors.

2 Disconnect the actuators from the embedded PC.

3 Stop the wheels.

4 Align the steering.

5 Read LRF output.

6 Adjust the drive speeds by visibility of obstacles.

7 Steer the robot.

8 When robot arrived, finalize the movement.

9 Return to 5.

Figure 10.

LRF zones, crab steering

Figure 11.

LRF zones, robot spins around

Figure 12.

LRF zones, cross movements

Furthermore, in the solution, we consider the conditions in SFs. For instance, it is common that the experiment infrastructures are located at one side of a tunnel or a corridor – as they are at CERN LHC or GSI/FAIR – and the transportation corridor usually runs along beside them in parallel or circular patterns. Therefore, within the path-selection routines, we give higher priority to following the simpler wall of the corridor. According to Table 1, let us divide the navigation into two parts: the determination of the robot's velocity (driving), and steering. In the upcoming paragraphs, we describe the overall idea and the benefits of a 4WS mobile robot for this purpose.

The robot's steering capabilities, as described in Section 3, include a vast area of selection and calculation so as to determine it for each wheel of the robot [24, 35]. However, a robust solution, a dependable implementation and a reliable verification method for such calculations become complicated, especially if a safe solution is required. Recall that the robot's immobility is a high-severity failure. For the purpose of simplification, we assume that the robot has only two types of steering: crab steering and spin around to keep the detection [36], planning [37], kinematics, and control [26] simpler than contemporary solutions.

5.2.1 Crab steering

Crab steering means that the angular velocity ω _B shown in Figure 2 and mentioned in (2b), becomes approximately zero. Fn other words, the instantaneous center of rotation (ICR) goes to infinity. As such, (2b) becomes:

v_{i}^{B} \hat{v} ​_{i} = v^{B} \hat{v}

(13)

This means that the velocity vectors of the body and legs become parallel (or equal) to each other. In such a case, it is not necessary to solve the system of kinematic equations of the robot and the direction of B_v^{^}; body's velocity vector defines the wheels' steering angles B_v^{^}_i. Any change in the steering comes from the change in the body's movement direction (not the heading). In this case, the robot can continue with high-speed linear motion up to a sensible change in the velocity direction regarding the actuator limitations.

Crab steering activates when the robot is approximately parallel to the simpler wall of the corridor while the robot has obstacle in front as shown in Figure 10. The crab steering maintains the distance from the side obstacles or walls without lowering speed. The magnitude of velocity vector v is proportional to the proximity of the obstacles in front of the vehicle. It should be noted that, instead of a distance measurement, a corresponding number for the zone is considered.

5.2.2 Spin around

There exists another method which leads to a significant simplification of the complicated path-follower kinematics. The 4WS robot can turn around on the spot without any linear movement, or negligible translational movements. In this case, the ICR converges into the centroid of the robot. In this case, another term of the velocity analysis becomes zero. The kinematics relations in (2b) become:

v_{i} ​^{B} \hat{v} ​_{i} = ω_{B} (\hat{z} \times ​^{B} ℓ ​_{i})

(14)

which shows the constant angles of the wheels perpendicular to $^{B} ℓ _{i}$ . Therefore, the change rate of the heading defines the driving velocity of each wheel v_i while $v \hat{v}$ – the linear velocity of the body – becomes zero.

6. Conclusion

In this paper, we study the architecture of a mobile platform. The overall architecture, including a variety of software modules, is studied in detail, and is suitable for risk assessment and RAMS analysis. Moreover, a top-down strategy is described to show how a high-level mission can be broken down into several tasks as well as which hardware/software are required to accomplish the mission. In order to consider safety concerns in Scientific Facilities (SFs), we propose “Safety Anchor”, a redundant decision-making system that can ensure that the robot leaves any hazardous environment without the presented cognition architecture. Moreover, Safety Anchor guarantees meeting the challenging limitations of the actuators by solving the kinematics of the robot in its simplified form. The specifications and design requirements of a four wheel steerable mobile manipulator, the IHA Mobile Robot (iMoro), are considered as a case study in this paper.

Footnotes

1

Robot videos are available at:

2

The numbers and names here are only samples for non-quantitative addresses by the operator.

3

It should be noted that $^{A} T_{B}$ stands for the homogenous transformation representing a coordinate frame ℬ with respect to another coordinate frame 𝒜.

7. Acknowledgements

This work, supported by the European Union's Seventh Framework Program under the Marie Curie Initial Training Network, was carried out within the framework of the PURESAFE, Preventing hllman intervention for incREased SAfety in infrastructures Emitting ionizing radiation, under RE A grant agreement number 264336.

References

Sharma

Dinesh

Kumar

, and Ajay

Kumar

. Reliability analysis of complex multi-robotic system using ga and fuzzy methodology. Applied Soft Computing, 12(1):405–415, 2012.

Fabry

Thomas

Vanherpe

Liesbeth

Feral

Bruno

, and Christian

Braesch

. Developing an interactive intervention planner-a systems engineering perspective. International Journal of Advanced Robotic Systems, 10(337), 2013.

Parasuraman

Ramviyas

Pagala

Prithvi

Kershaw

Keith

, and Manuel

Ferre

. Energy management module for mobile robots in hostile environments. In Advances in Autonomous Robotics, pages 430–431. Springer, 2012.

Aref

M. M.

Oftadeh

Koivumäki

Ghabcheloo

, and Mattila

System requirement document for modular mobile manipulator system. PURESAFE System Engineering Documents, WP 3(RP10–RP14), 2012.

Kleinehagenbrock

Fritsch

, and Sagerer

Supporting advanced interaction capabilities on a mobile robot with a flexible control system. In Intelligent Robots and Systems, 2004.(IROS 2004). Proceedings. 2004 IEEE/RSJ International Conference on, volume 4, pages 3649–3655. IEEE, 2004.

Palomeras

El-Fakdi

Carreras

, and Ridao

COLA2: A control architecture for AUVs. IEEE Journal of Oceanic Engineering, 37(4):695–716, 2012.

Rajan

Kanna

Frédéric

, and Javier

Barreiro

. Towards deliberative control in marine robotics. Marine Robot Autonomy, pages 91–175, 2013.

Rauch

Christian

Köhler

Tim

Schröer

Martin

Berghöfer

Elmar

, and Kirchner12

Frank

. A concept of a reliable three-layer behaviour control system for cooperative autonomous robots. 35th German Conference on Artificial Intelligence, September 24–27, 2012.

Vasudevan

Shia

Yiqi

Gao

Cervera-Navarro

Bajcsy

, and Borrelli

Safe semi-autonomous control with enhanced driver modeling. American Control Conference (ACC), pages 2896–2903, 2012.

10.

Chung

Kim

, and Kim

Development of the multi-functional indoor service robot psr systems. Autonomous Robots, 22(1):1–17, 2007.

11.

Rajaie

Zweigle

Häussermann

Käppeler

U.P.

Tamke

, and Levi

Hardware design and distributed embedded control architecture of a mobile soccer robot. Mechatronics, 21(2):455–468, 2011.

12.

Choi

Dongeun

Choi

Junho

Cho

Changhyun

Park

Shinsuk

, and Sungchul

Kang

. A safe robot arm with safe joints and gravity compensator. International Journal of Control, Automation and Systems, 11(2):362–368, 2013.

13.

Baudin

Mathieu

Bonnal

Pierre

, and Ruiz

Jean-Michel

. Combining activity DSM with temporal logic for collaborative planning and scheduling. International Journal of Advanced Robotic Systems, 10(337), 2013.

14.

Lecchini

Lanzon

, and Anderson

B.D.O.

A model reference approach to safe controller changes in iterative identification and control. Automatica, 42(2):193–203, 2006.

15.

Craig

Glennie

. Rigorous 3d error analysis of kinematic scanning lidar systems. Journal of Applied Geodesy, 1(3):147, 2007.

16.

Guoqiang

Corradi

Paolo

Menciassi

Arianna

, and Paolo

Dario

. An integrated triangulation laser scanner for obstacle detection of miniature mobile robots in indoor environment. IEEE/ASME Transactions on Mechatronics, 16(4):778–783, 2011.

17.

Yang

S.W.

and Wang

C.C.

Dealing with laser scanner failure: Mirrors and windows. In IEEE International Conference on Robotics and Automation, ICRA, pages 3009–3015. IEEE, 2008.

18.

Oftadeh

Reza

Aref

Mohammad M.

Ghabcheloo

Reza

, and Jouni

Mattila

. Mechatronic design of a four wheel steering mobile robot with fault-tolerant odometry feedback. IFAC Mechatronic Systems, 1(1): 663–669, 2013.

19.

Bruno

Siciliano

and Khatib

Oussama

, editors. Springer handbook of robotics. Springer, 2008.

20.

Tamjidi

Taghirad

H.D.

, and Aghamohammadi

On the consistency of EKF-SLAM: Focusing on the observation models. In IEEE/RSJ International Conference on Intelligent Robots and Systems, pages 2083–2088. IEEE, 2009.

21.

Choi

Curry

R.E.

, and Elkaim

G.H.

Continuous curvature path generation based on bezier curves for autonomous vehicles. IAENG International Journal of Applied Mathematics, 40(2):91–101, 2010.

22.

Agha-Mohammadi

Chakravorty

, and Amato

N.M.

FIRM: Feedback controller-based information-state roadmap a framework for motion planning under uncertainty. In IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), pages 4284–4291. IEEE, 2011.

23.

Agha-Mohammadi

Ali-Akbar

Chakravorty

Suman

, and Nancy

Amato

. Firm: Sampling-based feedback motion planning under motion uncertainty and imperfect measurements. International Journal of Robotics Research (IJRR), 33(2):268–304, 2014.

24.

Oftadeh

Ghabcheloo

, and Mattila

A novel time optimal path following controller with bounded velocities for mobile robots with independently steerable wheels. IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), Japan,2013.

25.

Arrichiello

Filippo

Chiaverini

Stefano

Indiveri

Giovanni

, and Paola

Pedone

. The null-space-based behavioral control for mobile robots with velocity actuator saturations. The International Journal of Robotics Research, 29(10):1317–1337, 2010.

26.

Oftadeh

Reza

Ghabcheloo

Reza

, and Jouni

Mattila

. Time optimal path following with bounded velocities and accelerations for mobile robots with independently steerable wheels. IEEE International Conference on Robotics and Automation (ICRA), pages 2925–2931, 2014.

27.

Aref

Mohammad M.

Ghabcheloo

Reza

Kolu

Antti

Hyvönen

Huhtala

, and Jouni

Mattila

. Position-based visual servoing for pallet picking by an articulated-frame-steering hydraulic mobile machine. IEEE International Conference on Robotics, Automationand Mechatronics (RAM), Manila, Philippine, pages 218–224, 2013.

28.

Aref

Mohammad M.

Reza

Ghabcheloo

, and Jouni

Mattila

. A macro-micro controller for pallet picking by an articulated-frame-steering hydraulic mobile machine. Accepted for IEEE International Conference on Robotics and Automation(ICRA), Hong Kong, pages 6816–6822, 2014.

29.

Pekka

Alho

and Jouni

Mattila

. Software fault detection and recovery in critical real-time systems: An approach based on loose coupling. Fusion Engineering and Design, 2014.

30.

Ducard

Guillaume JJ

. Fault-tolerant flight control and guidance systems: Practical methods for small unmanned aerial vehicles. Springer, 2009.

31.

Lin

Chih-Jui

Hsiao

Su-Ming

Wang

Ying-Hao

Yeh

Cheng-Hao

Huang

Chien-Feng

, and Li

Tzuu-Hseng S

. Design and implementation of a 4WS4WD mobile robot and its control applications. In System Science and Engineering (ICSSE), 2013 International Conference on, pages 235–240. IEEE, 2013.

32.

Oftadeh

Aref

M. M.

Ghabcheloo

, and Mattila

Unified framework for rapid prototyping of Linux based real-time controllers with Matlab and Simulink. In IEEE/ASME International Conference on Advanced Intelligent Mechatronics (AIM), pages 274–279, Taiwan, 2012.

33.

Kershaw

Bertone

Bestmann

Feniet

Forkel-Wirth

Grenard

, and Rousset

Remotely operated train for inspection and measurement in CERN LHC tunnel. Particle Accelerator Conference, pages 2902–2904, 2009.

34.

Oftadeh

Aref

M. M.

Ghabcheloo

, and Mattila

Real-time system integration for mobile manipulation. International Journal of Advanced Robotic Systems, 11(15), 2013.

35.

Reza

Oftadeh

Aref

Mohammad M.

Reza

Ghabcheloo

, and Jouni

Mattila

. Bounded-velocity motion control of four wheel steered mobile robots. IEEE/ ASME International Conference on Advanced Intelligent Mechatronics (AIM), Australia, pages 255–260, 2013.

36.

Ziaei

Zahra

Oftadeh

Reza

, and Jouni

Mattila

. Global path planning with obstacle avoidance for omnidirectional mobile robot using overhead camera. IEEE International Conference on Mechatronics and Automation (ICMA), pages 697–704, 2014.

37.

Agha-Mohammadi

Ali-Akbar

Agarwal

Saurav

Mahadevan

Aditya

Chakravorty

Suman

Tomkins

Daniel

Denny

Jory

, and Amato

Nancy M

. Robust online belief space planning in changing environments: Application to physical mobile robots. IEEE International Conference on Robotics and Automation (ICRA), pages 149–156, 2014.

Fault Tolerant Control Architecture Design for Mobile Manipulation in Scientific Facilities

Abstract

Keywords

1. Introduction

2. Problem definition

2.1 Task description

2.2 Sensors

2.2.1 Laser range finder

2.2.2 Wheel odometry

2.2.3 Current sensor

3. Kinematics

3.1 Inverse kinematics

3.2 Forward kinematics

4. Robot software modules

4.1 Dead reckoning

4.2 SLAM

4.3 Path planning

4.4 Path following

4.5 Mobile manipulator controller

4.6 Fault management

5. Safety Anchor (SA)

5.1 Hardware architecture

5.2 SA logic

5.2.1 Crab steering

5.2.2 Spin around

6. Conclusion

Footnotes

1

2

3

7. Acknowledgements

References