H2020 RIA COMANOID H2020-RIA-645097 · H2020 RIA COMANOID H2020-RIA-645097 Milestone M3.2: A...

H2020 RIACOMANOID

H2020-RIA-645097

Milestone M3.2:

A preliminary version of D3.3:Preliminary safety guidelines and strategies provided to WP1

March 2, 2018

M3.2 H2020-RIA-645097 COMANOID March 2, 2018

Project acronym: COMANOIDProject full title: Multi-Contact Collaborative Humanoids in Aircraft Manu-

facturing

Work Package: WP IIIDocument number: M3.2Document title: A preliminary version of D3.3:Preliminary safety guidelinesand strategies provided toWP1Version: 1.0

Delivery date: March 2, 2018Nature: ReportDissemination level: Public

Authors: Marco Cognetti, Daniele De Simone, Leonardo Lanari,Giuseppe Oriolo (DIAG, Sapienza University of Rome)

The research leading to these results has received funding from the European Union H2020Program/2015-2020 under grant agreement no645097 COMANOID.

2

Contents

1 Preliminaries 51.1 Mission contexts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2 Robot states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3 General safety guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Safety Behaviors 72.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3 Override behaviors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3.1 Safe fall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3.2 Emergency stop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4 Proactive behaviors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4.1 Evasion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.4.2 Visual tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.4.3 Footstep adaptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.4.4 Velocity/force scaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.4.5 Add contact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.5 Final remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3

Cited Works

[Caron and Kheddar, 2016] Caron, S. and Kheddar, A. (2016). Multi-contact walking patterngeneration based on model preview control of 3D COM accelerations. In 16th 2016 IEEE-RASInternational Conference on Humanoid Robots.

[Caron et al., 2016] Caron, S., Pham, Q.-C., and Nakamura, Y. (2016). ZMP support areas formulti-contact mobility under frictional constraints. IEEE Transactions on Robotics. to appear.

[Cognetti et al., 2016] Cognetti, M., De Simone, D., Lanari, L., and Oriolo, G. (2016). Real-timeplanning and execution of evasive motions for a humanoid robot. In 2016 IEEE Int. Conf. onRobotics and Automation, pages 4200–4206.

[ISO TS 15066, 2016] ISO TS 15066 (2016). Robots and robotic devices – collaborative robots.Standard, International Organization for Standardization.

[Koolen et al., 2012] Koolen, T., de Boer, T., Rebula, J., Goswami, A., and Pratt, J. (2012).Capturability-based analysis and control of legged locomotion, part 1: Theory and applicationto three simple gait models. Int. J. of Robotics Research, 31(9):1094–1113.

[Pratt et al., 2006] Pratt, J., Carff, J., Drakunov, S., and Goswami, A. (2006). Capture point: Astep toward humanoid push recovery. In 2006 6th IEEE-RAS Int. Conf. on Humanoid Robots,pages 200–207.

[Samy and Kheddar, 2015] Samy, V. and Kheddar, A. (2015). Falls control using posture reshap-ing and active compliance. In 15th 2015 IEEE-RAS International Conference on HumanoidRobots, pages 908–913.

[Sherikov et al., 2014] Sherikov, A., Dimitrov, D., and Wieber, P. B. (2014). Whole body motioncontroller with long-term balance constraints. In 2014 IEEE-RAS International Conference onHumanoid Robots, pages 444–450.

4

Chapter 1

Preliminaries

The objective of this chapter is to introduce some basic concepts (mission contexts and robotstates) that are needed to discuss the activation of safe behaviors. Also, we provide a qualitativedescription of the safety guidelines that have inspired the design of such behaviors.

1.1 Mission contexts

The mission contexts identify the spatial zones where the robot must operate in the various phasesof the demo mission. We define three mission contexts:

• Flat floor: The robot is moving on the ground floor or on the first floor landing (flat surfaces).On the ground floor, the robot is going to or coming from the stairs. On the first floor, it isapproaching the location where the bracket is, or moving from the latter location towardsthe entrance of the cargo area, or returning from the cargo area towards the stairs.

• Stairs: The robot is climbing (descending) the stairs to go from the ground (first) floor tothe first (ground) floor. The stairs are equipped with a handrail.

• Cargo area: The robot is moving inside the cargo area for the main part of its mission.

1.2 Robot states

The robot states characterize what the robot is doing at a certain time instant. We identify fiverobot states:

• Idle. The robot is standing in double support at a fixed position and not performing anyparticular task.

• Manipulation. The robot is standing in double support and it is executing a task (typicallya manipulation task) that does not require any stepping.

• Locomotion. The robot is moving in the environment by taking steps. This includes walking,multi-contact locomotion and stair climbing/descending.

5


• Falling. The robot has lost balance and is falling.

• Stopping. The robot is performing an emergency stop.

The first three are normal operation states, whereas the last two are emergency states. Inparticular, an idle state can be included in a mission plan as an intentional pause, e.g., at thetransition between different phases or for debugging purposes; or, it can be the release state foran emergency stop or another behavior that has encountered a failure (e.g., a walking patterngeneration that is unable to find a feasible solution).

1.3 General safety guidelines

We now introduce some general guidelines that should be followed for safe robot operation.

• Watch what you’re doing. The robot should always watch its main area of operation. Whenperforming a manipulation task, it will therefore look at its hand or at the object to bemanipulated. When walking, it should keep its gaze directed to the area where it is aboutto step.

• Be on the lookout. If the robot is idle, then it can freely monitor the environment, focusingin particular on objects that are not included in its current 3D map (e.g., moving objects).

• Evade if you can. When a moving object approaches the robot, perform an evasive actionif this can be done safely.

• Stop if you must. In a situation of clear and present danger, stop any operation as soon aspossible.

• Respect humans. In the presence of humans, robot velocities and forces should be scaleddown in order to reduce the potential damage in the case of a collision [ISO TS 15066, 2016].

• Look for support. When locomotion is expected to be challenging (e.g., on the stairs),the robot should try to establish additional contact with the environment (e.g., with thehandrail), so that it has at least two support points at all times. The possibility of improvingbalance by adding contacts should also be considered whenever a significant risk of fallingis detected.

Some of these guidelines will be realized as safety behaviors (see next chapter) that are activatedto improve the level of safety in dangerous situations, while others must also be taken into accountwithin the planning/control stage. For example, watch what you’re doing calls for visual-servoedmanipulation or locomotion strategies; look for support has consequences at the planning/stage(e.g., generation of stair climbing motions must include handrail grasping and releasing) but willalso result in a safety behavior.

6

Chapter 2

Safety Behaviors

We now describe the behaviors that the robot adopts to guarantee safety for itself and the envi-ronment (including humans). First, we discuss the assumptions under which these behaviors havebeen designed, particularly in terms of which information must be available for their activation.

2.1 Assumptions

We assume that at any time instant:

• The current mission context is one of those defined in Section 1.1, and the robot is in oneof the states defined in Section 1.2.

For example, the robot may be idle on flat floor, or walking in the cargo area. The otherassumptions are related to which information must be made available at all instants by the sensorysystem. We do not discuss in any detail the perception processes that provide such information.

• The robot is aware of its location w.r.t. a 3D map maintained by the SLAM module.

• The robot is aware of the current risk of fall rfall. Estimation of rfall will be based on iner-tial measurements, and should consider the ZMP support area [Caron and Kheddar, 2016,Caron et al., 2016] as well as the context in which the robot is operating (e.g., risk of fallin the stairs context should be intrinsically larger than on flat floor).

• The robot is aware of the current battery level lbattery.

• The robot is made aware of contact surfaces in its workspace through flag fcs. Contactsurfaces are surfaces (or points) of the 3D map with which the robot may safely establish acontact for additional support. Labeling of contact surfaces is made at the SLAM level.

• The robot is made aware of unexpected objects in its field of view, and in particular knowsthe minimum distance duo to the closest unexpected object. Unexpected objects are objectsthat are not present in the current 3D map, and may be moving (e.g., humans) or not (e.g.,cables on the floor). If there is no such object in the field of view, duo is set to ∞.

• The robot is made aware of unexpected contacts with the environment through flag fuc.Depending on the contact detection mechanism, other information may be available, suchas the location of the contact point in terms of the robot kinematic chains.

7


safetybehaviors

rfall

lbattery

fcs

duo

fuc

context state

override

proactive

sensoryinformation

flat floorstairscargo area

idlemanipulationlocomotionfallingstopping

safe fallemergency stop

evasionvisual trackingfootstep adaptationvelocity/force scalingadd contact

Figure 2.1: The activation of safety behaviors depends on the current mission context and robotstate, and is triggered by information coming from the sensory system.

2.2 Overview

The designed safety behaviors are of two kinds:

1. Override behaviors. These behaviors actually stop (or put on hold) the mission and forcethe robot to take action against a dangerous situation that has been detected.

2. Proactive behaviors. These behaviors do not stop the mission, but try to increase the overallsafety level by calling for an adaptation or enhancement of the currently active behavior.Proactive behaviors are activated in situations of intermediate risk.

Behaviors are best described using the terminology of finite state machines. In particular, eachbehavior will be characterized by:

• a triggering condition, that specifies the robot state(s) and mission context(s) from whichthe behavior can be activated, together with the events that actually cause the activation,which are invariably expressed in terms of information coming from the sensory system (seeFigure 2.1);

• the actions that realize the behavior, and the robot state during such actions;

• the release condition for terminating the behavior, and the state to which the robot isreturned upon release.

All triggering conditions are continuously checked by the robot. If its triggering condition ismet, a behavior can therefore interrupt another behavior prior to its natural release: for example,an emergency stop may occur at any time during normal robot operation.

8


2.3 Override behaviors

As previously stated, override behaviors stop (or put on hold) the mission and force the robot totake action against a clearly dangerous situation that has arisen. We define two override behaviors:

• Safe fall: The robot has detected an unrecoverable loss of balance, and must fall so as tominimize damages to itself and the environment.

• Emergency stop: The robot has identified a clear and present danger, and it must stop itsoperation as soon as possible.

2.3.1 Safe fall

The occurrence of falls cannot be excluded. The robot may lose balance when performing a stepor due to a hardware/software fault. An external perturbation (e.g., a collision with an object)may also lead to a loss of balance.

The safe fall behavior is triggered if:

• State: any.

• Context: any.

• Event: rfall > rhighfall , where rhigh

fall is a threshold associated to unrecoverable loss of balance.

The safe fall behavior is specified as follows:

• Action: the robot acts so as to minimize the potential damage to its own structures and/orthe environment. To this end, several aspects must be considered [Samy and Kheddar, 2015]including (i) how to fall, i.e., which internal posture to assume before impact to preserverobot integrity (ii) where to fall, i.e., how to choose the landing surfaces so as to avoidfragile components.

• State during action: falling.

Since a fall is regarded as a catastrophic event, the safe fall behavior can only be released bythe intervention of a human operator, who will also reset the robot to an appropriate state.

• Release condition: by human intervention.

• Release state: by human intervention.

2.3.2 Emergency stop

When the robot identifies a situation that hinders safe operation (e.g., a moving object has enteredits proximal area, or the battery level is dangerously low), it must stop moving as soon as possible(stop if you must guideline). Clearly, in humanoids this must be done properly.

The triggering condition for emergency stop is:

9


• State: any except falling.

• Context: any.

• Event: three events may independently trigger an emergency stop:

E1 duo < dstopuo , where dstop

uo is the radius of the robot proximal area (unexpected objectin the robot proximal area).

E2 fuc is active (unexpected contact).E3 lbattery < llow

battery, where llowbattery is the minimum acceptable battery level for safe

operation.

The emergency stop behavior is defined as follows.

• Action: the specific action depends on the triggering conditions:

A1 If the robot state was idle and the triggering event was E1 or E3, the robot will augmentits support polygon (by moving its feet or establishing a new contact point) and/orassume a low-impact configuration (e.g., by folding its arms).

A2 If the robot state was idle and the triggering event was E2, the robot will immedi-ately sdecrease joint stiffness on the kinematic chain where the contact has occurred,provided that the latter is on the upper body. Otherwise, the robot will maintain itscurrent pose.

A3 If the robot state was manipulation, the robot should safely abort the task and stopits motion as soon as possible, regardless of the triggering event.

A4 If the robot state was locomotion, the robot should stop walking as soon as possible,regardless of the triggering event. This may be obtained by properly using the captura-bility concept, e.g., see [Pratt et al., 2006, Koolen et al., 2012, Sherikov et al., 2014].

• State during action: stopping.

As for safe fall, releasing the emergency stop behavior requires an external intervention, withone notable exception.

• Release condition: if the triggering event was E1, the behavior can be released whenduo > dstop

uo . If the triggering event was E2 and E3, a human operator should intervene torelease the robot.

• Release state: if the triggering event was E1, the robot can be returned to the previousstate (before activating the behavior). Otherwise, by human intervention.

2.4 Proactive behaviors

In situations of intermediate risk, proactive behaviors try to increase the overall safety level withoutstopping the mission. To this end, they call for an adaptation or enhancement of the currentlyactive behavior. We define five proactive behaviors:

10


• Evasion: when idle, the robot performs an evasive maneuver to avoid collision with anapproaching moving object (if any).

• Visual tracking: when idle, the robot keeps its gaze directed at the closest unexpected objectin its field of view (if any).

• Footstep adaptation: when walking, the robot modifies its footsteps to avoid collisions withunexpected objects in its path (if any).

• Velocity/Force scaling: the robot reduces its velocities/forces when a close unexpectedobject is perceived.

• Add contact: if the robot estimates a moderate risk of fall, it tries to establish new contactsfor additional support.

2.4.1 Evasion

If an unexpected object approaches the robot in an idle state, the latter should execute an evasivemaneuver, provided this can be done safely (evade if possible guideline).

The evasion behavior is triggered if:

• State: idle.

• Context: flat floor or cargo area.

• Event:(dstop

uo < duo < devasionuo

)AND (duo < 0).

Here, devasionuo is a distance threshold under which evasion is assumed to be advisable; clearly,

devasionuo > dstop

uo . The condition on the time derivative of duo can be implemented by lookingat variations of this quantity over a small time interval.

The evasion behavior is defined as follows.

• Action: an evasion maneuver is planned in real time based on the spatial relationshipbetween the robot and the approaching object [Cognetti et al., 2016]. Feasibility of themaneuver with respect to the current 3D map is continuously checked. Whenever the ma-neuver becomes unfeasible, the associated flag fevasion is set to FALSE and the emergencystop behavior is invoked.

• State during action: locomotion.

Release of this behavior is specified by:

• Release condition: (duo > devasionuo ) OR (fevasion = FALSE).

• Release state: idle (if duo > devasionuo ) or stopping (if fevasion = FALSE).

11


2.4.2 Visual tracking

If the robot is in an idle state and an unexpected object appears in its field of view, the robot willdirect its gaze at it (be on the lookout guideline).

The visual tracking behavior if triggered if:

• State: idle.

• Context: any.

• Event: devasionuo < duo < ∞.

Note that this behavior cannot be triggered if the robot is in the manipulation or the locomotionstates. In these cases, in fact, averting the gaze from the current task can be dangerous (watchwhat you’re doing guideline).

The visual tracking behavior is defined as follows.

• Action: the robot should move its head so as to track the closest unexpected obstacle inits field of view.

• State during action: idle.


• Release condition: duo = ∞.

• Release state: idle.

2.4.3 Footstep adaptation

During locomotion, it is possible that unexpected objects (either moving, such as humans, orfixed, like cables on the ground) may interfere with the planned footsteps. In this case, the robotshould replan its footsteps using the new information.

The footstep adaptation behavior is triggered if:

• State: locomotion.

• Context: flat floor or cargo area.

• Event: duo < dfootstepuo , where dfootstep

uo is a distance threshold under which footstep adap-tation may be advisable.

The footstep adaptation behavior is defined as follows.

• Action: the robot re-invokes walking pattern generation after adding to the current mapthe unexpected objects that are closer than dfootstep

uo .

• State during action: locomotion.


• Release condition: (duo > dfootstepuo ) OR (footsteps successfully adapted).

• Release state: locomotion.

12


2.4.4 Velocity/force scaling

In the vicinity of an unexpected object, which may be a human, tighter bounds are enforced onrobot velocities/forces (respect humans guideline).

The velocity/force scaling behavior is triggered if:

• State: manipulation or locomotion.

• Context: any.

• Event: duo < dscaleuo , where dscale

uo is a distance threshold under which scaling is advisable.Clearly, dscale

uo > dstopuo .

The velocity/force scaling behavior is defined as follows.

• Action: robot velocities and/or forces are scaled down so as to fit the tighter bounds.

• State during action: remains manipulation or locomotion.

If the robot state is locomotion, velocity/force scaling also affects the CoM trajectory; thisrequires proper handling at the level of walking pattern generation. As for the scaling threshold,dscale

uo = dfootstepuo appears to be a sensible choice.


• Release condition: duo > dscaleuo .

• Release state: remains manipulation or locomotion.

2.4.5 Add contact

In the presence of a moderate risk of fall, the robot tries to establish new contacts for additionalsupport (look for support guideline).

The add contact behavior is triggered if:

• State: idle or manipulation.

• Context: any.

• Event: (rlowfall < rfall < rhigh

fall ) AND (fcs = TRUE).Here, rlow

fall is the threshold above which the risk of fall is considered to be moderate. Notethe role of flag fcs which indicates the presence of a reachable contact surface in the robotworkspace.

Note that locomotion is not a triggering state for this behavior because it is intrinsically riskyto try to establish a new contact while the robot is walking. Moreover, if the robot is climb-ing/descending stairs, additional contact with the handrail has already been enforced at the plan-ning stage.

The add contact behavior is defined as follows.

13


• Action: the robot selects an additional support point and establishes contact.

• State during action: manipulation.


• Release condition: the additional contact has been established.

• Release state: the state returns to the initial state, i.e., either idle or manipulation.

2.5 Final remarks

We now provide some final remarks concerning the safety behaviors presented in this document. Inparticular, we briefly discuss (i) the relationship among the different thresholds used for triggeringthe behaviors, and (ii) the transitions among robot states resulting from these behaviors.

Figure 2.2, top, summarizes the different thresholds that have been defined on duo, i.e., thedistance between the robot and the closest unexpected object. If the robot is idle and such anobject enters the robot field of view (duo < ∞), the visual tracking behavior is triggered. If theobject moves and approaches the robot (dstop

uo < duo < devasionuo ), the robot performs an evasion in

order to avoid it. Finally, if the closest unexpected object is too close (duo < dstopuo ), an emergency

stop is performed.Figure 2.2, bottom, is a similar representation for the risk of fall rfall. As soon as rfall becomes

significant (rlowfall < rfall < rhigh

fall ) the robot activates the add contact behavior. If a fall is deemedinevitable (rfall > rhigh

fall ), the robot will perform a safe fall.Finally, Figure 2.3 gives a compact view of the five robot states and the transitions among them

resulting from safety behaviors. Red arrows indicate transitions resulting from override behaviors:in particular, transitions entering the stopping state are the result of an emergency stop behavior,whereas transition entering the falling state are the result of a safe fall behavior. Black arrowsidentify transitions due to proactive behaviors; for example, the evasion behavior brings the statefrom idle to locomotion.

14


Figure 2.2: The relationships between the different thresholds used for quantities duo (top) andrfall (bottom), each with its corresponding behaviors.

manipulation locomotionidle

stopping falling

Figure 2.3: Transitions among robot states resulting from safety behaviors. Red arrows: transitionsresulting from override behaviors. Black arrows: transitions resulting from proactive behaviors.

15

Date post:	09-Oct-2020
Category:	Documents
Upload:	others
View:	5 times
Download:	0 times

H2020 RIA COMANOID H2020-RIA-645097 · H2020 RIA COMANOID H2020-RIA-645097 Milestone M3.2: A...

Documents