dynamic environment
This group of tactical behaviors provides the source of the control data flow of the tactical layer for plan- based tasks. The behaviors adapt the goals received from the strategic layer to the actual environment – once the needed data is available, e.g. the goal comes within sensor range.
The goal locations received from the global navigation are based on models (e.g. product database,
topologic-metrical map) and apt to be inconsistent with the actual situation of the dynamic environment.
Examples of sources for such inconsistencies in the supermarket scenario are:
• Dynamic objects (e.g. a palette or a parked shopping cart) occupy the target
• Dynamic objects (e.g. a palette or a parked shopping cart) block the way to the target • A self-localization inaccuracy “virtually” moves the model-based target into an obstacle • Moving objects or people temporarily occupy or block a target
• Dynamically generated target points are illegal (e.g. pointing gestures, inaccuracy in the user position
estimation in combination with a “come here” command)
• Errors in the application specific database (e.g. illegal product locations)
• The topological plan is not executable because topological links or areas are blocked by dynamic
objects or by re-arrangements of the shop’s structures (which have not been updated in the topological model)
Four major classes of situations of interest can be identified:
• Target points are occupied or are not reachable
• The user has the get access to the target location, not the robot
• The robot encounters obstacles when having to travel in a neighboring topological area • The topological plan is not executable
4.5. The tactical behaviors Fore these situations of interest several behavior modules were developed which check for the critical situations using the object database (see also [Rit10a]). They either modify the goal location before handing it down to the remaining behaviors or trigger feedback for the user, communicating the problem when it cannot be solved in the tactical layer. The objective is to rely as less as possible on model data but on the real environment instead.
TB: Goal Point Adaptation
This behavior module becomes active when the goal location comes within the robot’s sensor range. The module checks if there is an sufficient amount free space around the goal location for the robot to park. Otherwise the goal is altered according to the obstacles.
Situation: The area surrounding a goal point is occupied by an obstacle or the goal is too close by the obstacle
Input: Goal point
Data used: Occupancy map, and object database, and shape of robot Objective: Displacing the goal point so that it can be reached by the robot Output: New goal point
Fig. 4.35.: Goal Point Displacement: In a dynamic environment goal points (green x or green circle) can be blocked. If the space surrounding the goal location is occupied by an obstacle or that close by an obstacle that the robot can not reach the goal, the goal point is displaced.
Sketch: The free room (light green area) in the close vicinity of the original goal is analyzed and a new goal (red circle) is generated in a suitable distance to the obstacles. In cases of wall-shaped obstacles the goal is moved orthogonally to the obstacle, in all other cases towards the robot.
Screenshot: MCAGUI screenshot showing an exemplary scene with the original goal (green circle) and the new goal (red circle).
If it was identified that the goal point lies within an obstacle but closely to the surface, or the goal point lies that close to an obstacle that the robot cannot reach the goal, the local occupancy grid map is analyzed to find a new suitable position for the goal point. In the general case the goal point is moved away from the obstacle towards the robot to a point where the smallest distance to the closest occupied grid cell is larger than half the robot’s width (with a 20 % safety margin) (see Fig. 4.35 the left hand side sketch and the MCAGUI screenshot). The right hand sketch of Figure 4.35 shows a special case: keeping in mind that the control system was designed to operate a robot in a supermarket, most of the goal points will be product positions at shelves. Therefore, if the goal point is located within (or too close by) an wall-shaped obstacle
(long straight line in the occupancy grid) the goal point is not moved towards the robot but away from the obstacle orthogonally.
TB: Identifying Parking Positions
This behavior module was designed for reaching a target together with a user. If a user is involved, usually not the robot shall reach the target, but the user. In the supermarket scenario the target might be the spot in front of the shelf containing a desired product. To not impair the user, the robot shall drive past the goal a little bit so that the user can easily reach it. This could be handled in the plan, but then the exact direction of approaching the goal would have to be included in the plan as well, relying even more on model data. Here the opposite strategy is taken: model data is replaced by real world data when approaching the goal.
Situation: The robot has to reach a product in Guiding Mode
Input: Target position (maybe already be moved by other behaviors) Data used: Occupancy grid, object database, and shape of robot
Objective: Finding a suitable parking position which enables easy access to the goal for the user
Output: New goal point
Fig. 4.36.: Left: Standard situation – the robot chooses a parking position a little more then half a robot length behind the goal to enable easy access to the product located in the shelf. The brown line shows the target re-direction by the
Goal Point Adaptation described in the preceding section (because the target lies within the shelf). The yellow line
with the green circle indicates the re-direction to ease shopping for the user.
Middle: The position behind the product which the robot should have taken is blocked. So the target location is redirected half a robot length in front of the product. The user has to move around the robot but still has free access to the product.
Right: The target is occupied by an object. The target is moved to the free room and a parking position is found. If the target position is a location to reach while guiding a user (e.g. a product in the supermarket) the precise target location is adapted (Fig. 4.36): basically the robot will move to a target position so that the user can easily reach the goal while not unnecessarily blocking the corridor. Therefore, the robot moves past the goal instead of stopping in front of it. Special situations occur when the goal is at the end of an alley: this is either a dead end and the robot cannot move past the product, or it is an intersection and the robot would block the crossing alley. In these cases the robot stops before the product – the user has to go around the robot but can still reach the goal easily. This behavior is usually combined with the Goal Point Adaptation from the preceding section which makes sure that the target can actually be reached by the robot.
4.5. The tactical behaviors
TB: Generation of Topological Navigation Points
This behavior module enables the robot to pass into a neighboring topological area. The plan from the
strategic layer provides only the center point of the link between two topological areas. Where exactly to
pass this link is identified by this module, taking into account the robot’s position, the succeeding goal, and local obstacles.
Situation: The robot shall move into an neighboring topological area
Input: Topological link to move past, succeeding goal (target location or next link) Data used: Robot position, robot shape, obstacles (object database), free space (occupancy
grid)
Objective: Generation of sub-goals which lead the robot towards and past the topological link. These sub-goals shall take the robot’s position and the succeeding goal into account to generate an efficient path. Of course, these points have to have enough distance to obstacles so that the robot is able to actually reach them.
Output: Two sub-goal points, one on each side of the link
Fig. 4.37.: Topological navigation points: Goal points (red circles) leading the robot into the next topological area, past the topological link (green rectangles), are generated to enable the robot to execute the plan of the topological
navigation. In a dynamic environment the links between the topological areas can be (partially) blocked so the topological navigation points have to be adapted to the free room in the close vicinity of the link.
Left: Sketch illustrating the geometrical construction. The line from robot to the goal is intersected with lines in parallel with the link. The intersections give the first iteration goals – the represent the shortest path. Afterwards circles with the radius equal to the robot’s width are drawn around the obstacles’ corners. The first iteration points are moved along the lines until the are not located inside the circles.
Right: Screenshot from the MCAGUI showing the points leading the robot from area No. 16 to No. 14. The navigation points are adapted to the succeeding goal (green circle at the left hand frame) and the obstacle behind the link.
Geometrical methods are used to lead the robot past the link, to avoid obstacles close by the link and to generate an efficient path regarding the robot’s position and the succeeding goal. The behavior Look for
Corners would be able to move the robot around the obstacles – but it would not enforce that the robot
passes the topological link. In contrast, the behavior presented here enforces the plan of the topological
navigation. For this purpose, two auxiliary goal points are generated, as depicted in Figure 4.37: one in
front of and one behind the link.
Each, before and after the link two parallel straight lines are generated in a defined distance in parallel to the link. The intersections of these two lines with the line from the robot to the succeeding goal are
calculated. These are the first iteration sub-goal points. They meet the requirement of the efficient path. Then for each obstacle a circle is calculated around the closest corner where the radius is half of the robot’s width (plus 20% safety margin). The first iteration points are moved along the lines so that they are not situated inside such a circle. If this is not possible, the median of the intersecting area between the circles is taken. This gives the final (second iteration) sub-goal points.
If the link should not be passable at all this is handled by another behavior: Detection of Blocked Topolog-
ical Links and Areas. Figure 4.41 from the next section shows a video snapshot showing the robot’s view:
the light green circle on the left is the first iteration goal, the darker circle is the second iteration goal point.
TB: Detection of Blocked Topological Links and Areas
This behavior module analyzes if a topological link which is to be passed is actually passable, or not. The result is given back upwards to the strategic layer which will update the topological map and start re- planning, if necessary. Additionally, a corresponding speech output to the user is triggered. This behavior cooperates with the behavior Generation of Topological Navigation Points as it is not able to move the robot itself. The behavior for generating the navigation points will move the robot towards not visible areas of the link.
Situation: A topological link has to be passed Input: Topological link (ID, position, width)
Data used: Shape of the robot, object database, occupancy map Objective: Identify if the link is passable or blocked
Output: State of the link, trigger for speech output
Fig. 4.38.: Detection of blocked topological links: The obstacle on the (H)igh side of the link (green rectangle) blocks the link, the obstacle on the (L)ow side does not block the link.
Left: The robot cannot detect a passage from its current perspective. Therefore the link is marked as partially blocked on the high side and as potentially blocked from a low side perspective.
Right: After moving forward the robot detects that there is a passage. If d2H or the distance between
O1Land O2Hwould have been smaller than dNthe link would have been marked as blocked on the high
and low side therefore the topological map would have been updated resulting in a re-planning.
For the topological navigation it is necessary to be informed about impassable topological links to be able to update the topological map and to re-plan the current task. A geometrical analyzis of the object
database is performed (see Fig. 4.38). It has to be taken into account that the local situation can differ based
4.5. The tactical behaviors side of the corridor it can be obviously passable from a (H)igh side perspective. A video snapshot showing the robot’s perspective can be seen in Figure 4.41 and some screenshots of the MCAGUI show results in Figures 4.39 and 4.40.
Fig. 4.39.: Two links are marked as partially blocked (red box on the link (green boxes)), the left one is additionally marked as MBL (which is not illustrated because the visualization uses the red box for both flags).
Fig. 4.40.: The robot starts on the upper side of the left hand side link and marks it with MBH. After traveling along the link the MBL flag is set as well, completely blocking the link.
Fig. 4.41.: Video snapshot from the robot’s perspective showing a partially blocked bar- rier as indicated by the red line. The green line overlaying the RFID barrier indicates the free part of the link. The green circles indicate the topological navigation points described in the previous section.
Fig. 4.42.: Special Situation: the gap at the lower end of the link is wide enough for the robot. An estimation is necessary if the robot can move around the obstacle on the lower side. This is done based
on the position of the obstacles end point (O2C).
To be able to take care of links being partially blocked or seem to be blocked from a certain perspective four flags are introduced, corresponding to the orientation of the link (which depends on the numbers of the neighboring areas, but has no further effect here) :
• PBH: Link is partially blocked on the high side • PBL: Link is partially blocked on low side
• MBH: Link maybe blocked seen form a high side perspective • MBL: Link maybe blocked seen from a low side perspective
The link is marked as blocked if (see Fig. 4.38):
1. Both PBH and PBL are set and the distance betweenO1Land O2His smaller than the distance needed
2. PBH is set and the distance from O1Lto the low side of the link is smaller than dN 3. PBL is set and the distance fromO2Hto the high side of the link is smaller than dN 4. Both MBH and MBL are set.
The PBx flag is set when the link is obviously blocked on the corresponding side. If an obstacle is detected on the high side, two points (O1H, O1L) are identified: the ones closest to the high and low side of the link
which are in front of or behind the link (not besides the link). The distances between these and the link are measured: if d1Hand d1Lare smaller then the needed space of the robot (dN) the PBH flag is set (the same for the low side accordingly – both d2Hand d2Lare > dNso the PBL flag is not set).
The MBx flag is set when the robot cannot see a passage past the link from the corresponding perspective bit it is not sure that the link is blocked: If an obstacle is detected on the low side, two additional points (O2H, O2L) are identified: the ones closest to the high and low side of the link which are in front of or behind
the link (not besides the link). Both d2Hand d2Lare > dNso the link is not partially blocked on the low side. To determine if the robot can find a passage the field of view (FOV) is analyzed (red line): if the distance between the intersection between the FOV-line and the link’s end (dlink) is > dN and the distance between the first obstacle on this line and the link (d1V) is > dNthere is a passage. If one is smaller no passage is found (as in the sketch). But as d2H>dNthere might be a gap which the robot cannot see. Therefore, the MBL flag is set. (The same is done for the high perspective accordingly – d2H, dlinkand d1V >dNfrom this perspective (orange lines) so the MBH flag is not set – the links remains passable).
A special situation is sketched in Fig. 4.42: d2L>dNso the robot would be able to pass the barrier at the low side. But can the robot actually reach this gap? Now we additionally take the end of the obstacle (O2C)
into account. If d2HL>d2LC we estimate that the robot cannot pass around the obstacle and therefore the
link is marked with the PBL flag.
TB: Generation of Virtual Topological Areas
This behavior module analyzes if a topological area is completely blocked. If this is the case the module provides output for the strategic layer resulting in splitting the topological area into two virtual areas and the re-planning of the current task. Additionally the user is informed.
Situation: The robot shall move to any kind of goal point in the current topological area.
Input: Goal point
Data used: Robot position, robot shape, obstacles (object database)
Objective: When the robot shall move to any kind of goal point in the current topological area and the path is blocked the behavior searches for gaps in the local environ- ment. If no gap of sufficient size is detectable the area is marked as blocked and split along the obstacles into two topological areas.
Output: Position and size of cut between areas, signal for topological re-planning, trigger for speech output to user
As this behavior does not include building a global map (which would be against the general concept), it obviously operates robustly only if the areas are not too large: the two sides bordering the topological area have to be inside the local occupancy map. The aim is to detect blocked corridors, not to detect blocked wide spaces or halls. Basically, this module works in the same way like Detection of Blocked Topological
Links and Areas mentioned before, just taking lines across the area instead of topological links. Figure 4.43