As an example for a complex and dynamical real world scenario, the navigation and performance of service tasks in an office environment is chosen. The mobile robot has to drive among different rooms which are connected by a circular corridor (see Fig. 5.4). Furthermore, the robot has to pick up objects from certain offices and has to place them in another office or the kitchen. The defined standard task is the collection of empty bottles from the offices. If an empty bottle is found, it has to be placed at a certain position in the kitchen. Additionally, the robot has to rest in regular time intervals in order to charge the batteries in one of the offices. Therefore (and for other tasks), also the communication with humans is necessary since the system does not have an actuator available, which can be used to connect itself with the power supply unit automatically. The complexity of the scenario arises from the fact that the chosen corridor has no clear structure as a laboratory environment. Due to the fact that also humans interact
Chapter 5: Realization of Cognitive Technical Systems 104 WC Kitchen Electro Printers Archive Door Windows Robot Office 1 Office 2
Figure 5.4.: Mobile robot navigating through the office environment
independently from the robot within the same environment, the interaction of the robot has a dynamic, uncertain, and open character. Human passengers can cross the robot’s way and influence whether office doors are opened or closed. Furthermore, humans usu- ally do not have simple behavior patterns, their intention is hard to measure, and they can change the environment in an (for the system) unexpected manner. Hence, the generation and usage of static navigation maps is not suitable for localization and path planning.
In the following, the system’s measured characteristics and defined operators are de- scribed. These are necessary to perform successfully in the advised scenario and to learn an appropriate mental model containing all relevant facts and relations in order to en- hance the system’s behavior.
Measured characteristics
The robot’s sensors measure different physical effects which are further processed by the control program’s filter routines providing the parameters of the resulting measured characteristics to the cognitive architecture. In the following, the measured character- istics describing the scenes of the chosen example scenario as unambiguous and clear as possible are explained in detail. Furthermore, Table 5.1 summarizes all measured characteristics, their range of parameters, and related sensors.
• With the video camera the four colors red, yellow, green, and blue can be de- tected (e.g., credObjDet). Furthermore, their vertical orientation to each other (e.g., cposOfYellowObj) can also be taken into account.
• With the laser range finder, the shortest distance to an obstacle in a certain di- rection can be measured. Here, the distances to objects in front and on the sides of the robot are used (e.g., cobstacleInFront). Furthermore, an additional characteris- tic caccessibleAreaInFront is used to describe whether the area in front of the robot is accessible in general (e.g., open door in front) or not (e.g., closed door in front or wall in front).
• By the odometry sensors, the x-position (cxPos) and y-position (cyPos) of the robot regarding the initial coordinates are estimated. Furthermore, the robot’s orienta- tion (corientation) within the environment is derived. All three characteristics have numerical parameters, which are strongly influenced by integrating measurement errors.
• If a RFID-tag is detected, ctagDet is set to true and cidOfDetTag stores the related ID of the tag.
• The gripper has two light barriers (one at the front and one at the rear part) which can be free or blocked (e.g., cfirstBarrierClosed=true). Additionally, with cobjGripped, it is described whether the gripper is opened or closed.
• In ctimeOfDay, the current time of day (morning, noon, and afternoon) is contained. Hence, the behaviors of different humans depending on the time of day, e.g., not in the office before 6.00 am and after 8.00 pm, can be considered.
• The batteries’ state-of-charge is represented by the characteristic cbatteryStatus. De- pending on the measured cell voltage, the related parameter is set to empty, middle, or full. Furthermore, the characteristic cisCharging changes based on sudden changes of the cell voltage or related information from a human which connected/discon- nected the robot with the power supply.
• The characteristic clastOperator stores the previous action of the robot. Here, the pa- rameter of clastOperatorchanges after ocreateSound(pleaseConnect) to 1, after ocreateSound (pleaseDisconnect) to 2, after ocreateSound(openDoor) to 3, after ocharging to 4, and after all other operators to 0. Hence, it is also possible to represent the dependency of a certain operator to its predecessor. If the robot drives into a room, the charac- teristic cinsideRoomis set to true and the corresponding room number (detectable by RFID-tags before the rooms) is stored in cnoOfCurRoom. Furthermore, the character- istic crelOrientation changes if the robot turns. The characteristic describes whether the robot is oriented to the center of the office environment, to the corridor (in clockwise (cw) and anticlockwise (acw) direction respectively), or to the windows (see Fig. 5.4).
• Finally, the answers and commands of humans are represented by two characteris- tics describing whether a related button was pressed or not (e.g., cfirstButtonPressed= yes).
Chapter 5: Realization of Cognitive Technical Systems 106
Source Characteristic Range of parameters
Camera credObjDet {true, false}
cyellowObjDet {true, false} cgreenObjDet {true, false} cblueObjDet {true, false}
cposOfRedObj {nil, top, middle, down} cposOfYellowObj {nil, top, middle, down} cposOfGreenObj {nil, top, middle, down} cposOfBlueObj {nil, top, middle, down} Laser cobstacleInFront {close, between, far}
cobstracleLeft {close, between, far} cobstracleRight {close, between, far} caccessibleAreaInFront {true, false}
Odometry cxPos {p ∈ R}
cyPos {p ∈ R}
corientation {p ∈ R | 0 ≤ p < 360}
RFID cidOfDetTag {p ∈ N | 0 ≤ p}
ctagDet {true, false}
Gripper cfirstBarrierClosed {true, false} csecondBarrierClosed {true, false} cobjGripped {true, false}
System ctimeOfDay {morning, noon, afternoon}
cisCharging {true, false}
cbatteryStatus {empty, middle, full}
Operators clastOperator {p ∈ N | 0 ≤ p}
cnoOfCurRoom {p ∈ N | 0 ≤ p} cinsideRoom {true, false} crelOrientation {clockwise, center,
anticlockwise, windows} I/O-card cfirstButtonPressed {true, false}
csecondButtonPressed {true, false} Table 5.1.: Characteristics defined for the scenario
Operators
The operators represented by the cognitive architecture model the actions of the con- trolled technical system. In the case of the chosen scenario, the robot has to perform pick and place tasks in a specific dynamical office environment. Hence, the system has to
• drive on the corridor from room to room, • change its orientation by turning 90◦
or 180◦ , • drive inside and outside rooms,
• pick up and drop objects as bottles, • generate different kinds of sounds, and • wait for certain changes in the environment.
The assumptions of the corresponding operators can be divided into assumptions defined by the system designer to protect the system and assumptions resulting from a certain environment. The first type of assumptions is defined in the controller routines in order to avoid dangerous situations. In contrast to that the second type of assumptions can not be defined in advance since they result from the system’s interaction with the en- vironment. However, the cognitive architecture does not distinguish between different types of assumptions if they are derived from the system’s experiences.
In the following, the functions and assumptions of all operators are described in detail. Furthermore, Tab. 5.2 gives a brief summary by relating each operator to their user- defined assumptions and to the characteristics whose parameters are changed by the operator.
• odriveToRoom(direction) With this operator, the robot can drive along an arbi- trary formed corridor by following the wall. If an open or closed door is detected (here, realized by RFID-tags on the floor), the robot stops. As assumptions for this operator, the robot has to stand near an RFID-tag (e.g., cnoOfDetTag=3) and besides a wall (e.g., crelOrientation=clockwise). Furthermore, no obstacle, excluding a gripped object, may stand in front of the robot (cobstracleInFront=false).
• oturn(direction), ochangeDirection() Through these operators, the robot is turned about a certain angle. Depending on the parameter ‘direction’, the first operator turns the robot +90◦
and −90◦
respectively. As assumption, a RFID-tag has to be detected (e.g., cnoOfDetTag=2). The second operator turns the robot through 180◦
. Here, the robot has to be inside a room (e.g., cinsideRoom=true).
• ocreateSound(sound) This operator is used to create different (depending on the parameter ‘sound’) predefined sounds, like a signal-horn or instructions/questions to humans. It has no assumptions and it can be performed in every situation.
Chapter 5: Realization of Cognitive Technical Systems 108
• owaitForAnswer(question), owaitForFreeSpace() These operators are used to wait for actions from humans. In both cases, the system waits for the corresponding change of the situation (e.g., cfirstButtonPressed=true or caccessibleAreaInFront=true respectively) without any own actions. If the situation is not changed adequately, the operators finish after a certain time interval. As assumptions, the operator ocreateSound(sound) has to be performed beforehand (e.g., clastOperator=1). The second operator requires additionally that the space before the robot is not free (caccessibleAreaInFront=false). • ocharging() Similar to the operators described above, this operator waits until the
parameter of the characteristic cbatteryStatus changes from empty to full. Alterna- tively, the operator can be configured in the way that it stops after a certain time. The operator can only be used after the operators ocreateSound(pleaseConnect) and owaitForAnswer(connection) were applied.
• odriveInsideRoom(), odriveOutsideRoom() Through these operators, the robot drives inside and outside rooms, like offices or the kitchen. To use the first operator, the robot has to stand on the corridor before an open room (e.g., cnoOfDetTag=4 and caccessibleAreaInFront=true) and has to be orientated to this room (crelOrientation=win- dows). In order to use the second operator, the robot has to be inside a room (e.g., cnoOfCurRoom=2) and also has to be orientated to an open door (e.g., crelOrientation= center and caccessibleAreaInFront=true).
• odirectToDoor() The operator can be used to direct the robot straightly to an open door. If the robot turns to an open door by applying the operator oturn, it could happen that the robot is not straightly directed to the door. In this case, the open door is recognized correctly (caccessibleAreaInFront=true), but one of the door- jambs is detected as obstacle (cobstacleInFront=true). Hence, the assumptions to pass the door are not fulfilled, which can be changed by the mentioned operator odirectToDoor. The operator can be applied if an open door is detected in front of the robot (caccessibleAreaInFront=true).
• ogripOject(color), odropObject() These operators are used to pick and place colored objects, like boxes or bottles. Depending on the parameter ‘color’, the first opera- tor orientates the robot to the corresponding colored object, drives to the object, and lifts it up with the gripper. For the execution of this operator, a colored object has to be detected (e.g., cgreenObjDet=true). To place a griped object, the second operator opens the gripper and drives a few centimeters backwards. As assumption for this operator, an object has to be gripped (cobjGripped=true).
Operator(s) Assumptions Relev. changes odriveToRoom(clockwise) cobstacleInFront = far cidOfDetTag
crelOrientation = cw cinsideRoom = false
odriveToRoom(anticlockwise) cobstacleInFront = far cidOfDetTag crelOrientation = acw
cinsideRoom = false
oturn(left) cinsideRoom = false crelOrientation
oturn(right) clastOperator = 0 cobstacleInFront
caccessibleAreaInFront ochangeDirection() crelOrientation = windows crelOrientation
cisCharging = false cobstacleInFront clastOperator = 0 cgreenObjDet cinsideRoom = true caccessibleAreaInFront odirectToDoor() caccessibleAreaInFront = true cobstacleInFront ocreateSound(openDoor) cobstacleInFront = middle cobstacleInFront
crelOrientation = windows clastOperator
clastOperator = 0 caccessibleAreaInFront cinsideRoom = false
owaitForFreeSpace() cinsideRoom = false cobstacleInFront crelOrientation = windows clastOperator
clastOperator = 3 caccessibleAreaInFront odriveInsideRoom() cobstacleInFront = far cobstacleInFront
crelOrientation = windows cinsideRoom cinsideRoom = false cnoOfCurRoom clastOperator = 0 cidOfDetTag caccessibleAreaInFront = true cgreenObjDet
caccessibleAreaInFront odriveOutsideRoom() cobstacleInFront = far cobstacleInFront
crelOrientation = center cnoOfCurRoom cinsideRoom = true cidOfDetTag
caccessibleAreaInFront = true caccessibleAreaInFront ogripObject(green) cgreenObjDet = true cgreenObjDet
cinsideRoom = true cobjGripped cobjGripped = false
clastOperator = 0 cisCharging = false
odropObject() cobstacleInFront = close cobjGripped cinsideRoom = true cgreenObjDet cobjGripped = true
cgreenObjDet = false
Chapter 5: Realization of Cognitive Technical Systems 110
Operator(s) Assumptions Relev. changes
ocreateSound(pleaseConnect) cnoOfCurRoom = 1 clastOperator crelOrientation = windows cisCharging cisCharging = false
clastOperator = 0 cobjGripped = false
owaitForAnswer(connection) clastOperator = 1 clastOperator cisCharging
ocharging() cisCharging = true clastOperator
ocreateSound(pleaseDiscon.) clastOperator = 4 clastOperator owaitForAnswer(discon.) clastOperator = 2 clastOperator cisCharging Table 5.2.: Assumptions and relevant changes of the defined basic operators