3.3. The resulting control architecture
This section describes the control architecture resulting from the derived requirements, the application of the fundamental methods, and the introduced sources of inspiration. Three main fields of duty can be identified in the demands posed on the robot by the environment and the needed features. These are (1) the task and topological route planning, (2) the handling of the dynamic environment including the interaction with humans, and finally (3) the safe and reliable local navigation. Therefore a three-layered navigation concept was foreseen to cover the mentioned three identified fields. The first layer, called strategic layer, is responsible for deliberative long-term planning. It houses the task planner and the topological navigation. The tactical layer contains a behavior-based control system to deal with moving objects in a local area, with the predictive avoidance of obstacles and with the interaction with nearby humans. The behaviors are based on different modules for scene analysis like object and user tracking. And finally, at the bottom of the hierarchy, the reactive layer’s goal is to fulfil movement tasks inside a local topological area using a
Behavior Network as its control mechanism. It is based on the dynamic calculation and fusion of several 3D
velocity set-point vectors.
These three layers of the navigation system plus the application-specific communication layer and the platform-specific Hardware Abstraction Layer make up the layered control architecture as illustrated in Fig. 3.5. Details on these layers will be elaborated on in the next chapter when the navigation system is described.
Fig. 3.5.: The robot’s control architecture: it consists of the three layers of the navigation system, the
3.3.1. The architecture of the infrastructure
To operate a fleet of robots, these have to be embedded into an infrastructure. The idea is to keep the individual robot as autonomous as possible. Thus they can be introduced more easily and are able to operate even when the infrastructure is temporarily unavailable. Thus the intelligence has to be kept within the individual robots and a central server is only used as central information database.
Fig. 3.6.: When operating several robots, these are embedded into a infrastructure. Each robot communi- cates via WiFi with a central server. The server collects status information such as position and target from all robots and distributes it. Customers can control one robot using the user interface, or a group of robots using the user interface of the master robot. And finally an operator is able to control robots too.
Figure 3.6 illustrates the overall system’s setup and infrastructure. When a WiFi connection is established between a robot and the central server, the robot registers itself and continuously sends its current status and updates of the map in case of severe changes. In return the server sends a aggregated collection of the remaining robots’ data and map updates, e.g. increased traverse costs for certain topological areas due to heavy traffic. If environmental sensors are integrated (like the intelligent environment (see Appendix C.3 “The intelligent environment”)) the server collects and aggregates and distributes the data, such as the users’ positions or the path of other moving objects). A user can control one robot via the user interface provided by the robot’s communication layer. If the user wants to control more than one robot, the robots exchange the control information via the central server which acts as broker. Finally, an operator logged on the the server is to control any of the robots.
3.3.2. Thelocal world model
According to the control architecture a three-leveled world representation was developed. The local world
3.3. The resulting control architecture
Fig. 3.7.: The four levels of the local world model with the corresponding control components.
several levels corresponding to the degree of abstraction of the contained data (see Fig. 3.7). It provides a general interface to pre-processed information accessible for all modules of the control system. It encapsu- lates the actually used sensor systems and abstracts the information from them, making the control system independent from the sensor hardware just as the Hardware Abstraction Layer makes the control system independent from the robotic platform. The information is stored and then shared in a network transpar- ent memory area to be accessible for all components via MCA blackboards to ensure high availability of the data. The LWM is partially shared between the robots so that these know each other’s position, mo- tion, current mode of operation and goals. Modifications of the annotated topological map are shared as well to inform other robots about structural changes of the environment. The three level of abstraction are introduced here:
1. Data acquisition level: The reactive behaviors responsible for the obstacle avoidance work based on a binary occupancy grid map that is kept in the world model. These grid merges the information
from various sources like laser range finders whose data is acquired in the Hardware Abstraction
Layer or information received from other robots or memorized at an earlier point in time. This level
additionally houses the inner state of the robot like its position and velocity, the actual task and target or actual errors and so on. Comparable information is kept about the robot’s user.
2. Data interpretation level: The more deliberative behavior modules make use of an object database. This database is generated by both identifying and tracking objects in the grids and estimating their movement models. Additionally, other robots are added when these communicate their position, intended goals, and movements. Finally, the user is identified and tracked. This can be either done by an on-board stereo camera system or an external system – depending on the actually integrated systems.
3. Abstract data level: The highest level of abstraction houses the topologic-metrical map of the super- market with semantic annotations and online modifications: The environment is split up into several areas. The areas are mapped in a topological map. Each node is enhanced with metric information of its size and links as well as with semantic information about the node. The semantic information can be used as an indication of whether a node should be used or avoided in a global plan. Addition- ally, this information can imply restrictions to velocity or acceleration, certain dangers which wait in this area like a grate in the floor which would render an optical motion sensor useless or “invisible obstacles” like a mirror that could trick a camera system. Additional information like a blockage of a corridor or the prohibition to enter a room or other warnings can be stored. The information can be shared with other robots.
3.3.3. Interfaces
The interfaces between the individual layers and between the layers and the LWM are implemented using the MCA framework. There are two types of members of interfaces: edges which transport one floating- point value according to the control-sense-cycle of MCA and blackboards which represent areas of network transparent shared memory protected by semaphores for the storage of large amount of data which can be accessed from all parts of the control system. Figure 3.8 shows the application of these methods throughout the control architecture.
From a data point of view the interfaces have a defined “language”: topmost these are command and event messages, below we have 3D locations and then finally the velocity set point vectors. Each layer houses a fusion module which collects all the individual tasks in the given language, transforms it to the language of the bordering layer and hands it over.
The components for environmental perception are integrated likewise: the user tracker provides a 3D location of the user and the force sensor provides a 3D force vector which is then interpreted as velocity set point vector.
There is one exception to these MCA-based interfaces. The command interface between the strategic
layer and the communication layer is based on a classical TCP connection with a defined set of commands
3.3. The resulting control architecture
Fig. 3.8.: In the control architecture two control cycles are implemented using the two types of interfaces pro- vided by MCA: the first one connects the control data with the status information using MCA-edges and the second one provides abstracted environmental data using the LWM and MCA-blackboards.
Thecommand interface
The command interface is implemented by a classical TCP connection instead of the MCA-interfaces ap- plied in the remaining control system. The reason is that MCA is, as the name states, a controller architec- ture. Thus, it is good for modeling control applications which apply control-sense loops. Other concepts can be implemented in MCA as well, but this is not what MCA was designed for. For the application-specific
communication layer one might want to use alternative methods and maybe other programming languages
instead of C++. As TCP connections are widely spread it was the method of choice. The two exemplary
communication layers for InBOT for example were implemented in QT or Java respectively as they are
much more favored in developing graphical high-level applications.
The command messages inform the control system about a task to fulfill (in most cases to move to a certain location) or to switch into another mode of operation. Additional commands include the information if a user is attached or if there is a location of interest nearby where the robot should slow down while passing it.
The event messages inform the communication layer about started or finished actions, about problems and if there is a special situation apparent or action planned which could be interesting for the user (“InformUser event”). The information to generate these events is collected from all over the control system, especially from the local world model, the target reaching behavior and the scene analysis group. The messages are
Tab. 3.1.: Commands and Events used by the command interface Commands Events AttachUser PositionChange DetachUser Error MoveToPosition ArrivedAt ChangeMode LostContactToUser SetMaximumSpeed TooLargeDistanceToUser ShowLocation UserStopsPushingTrolley DriveToUser StartedShowLocation Servoing StoppedShowLocation SetTargetObject Parking BumperPressed SendGoal InformUser listed in table 3.1.
Each message is accompanied by a set of parameters, a defined start and end sequence as well as a check sum to ensure that the messages have been received completely and correctly, especially when transmitting via WiFi.
3.3.4. Data flow
Figure 3.8 shows the data flow throughout the control architecture. There are two main direction of data flow: control data flows downwards while becoming more concrete and sensor data rises up while becoming more abstract. There are two methods of transporting the information depending on their character: time critical and sparse information are transported directly using MCA-edges, large amounts of information and not time critical ones are exchanged using MCA-backboards via the LWM. The two main currents generate several cycles: each layer has its own cycle with a defined cycle time and is connected to the neighboring cycles by the main currents.
3.3.5. Integration with the MCA2 framework usingUComs
The Modular Controller Architecture MCA ([143], [168]) was developed at the FZI to be able to set up modular architectures efficiently. As described, the modules are integrated in a continuous sense-control loop. To extend the control (software) system beyond the level of the embedded PCs, special microprocessor boards were developed at the FZI. The UCOM-board ([130]) which contains a DSP with dedicated memory, a FPGA, various A/D and D/A converters, and a CAN-bus interface is integrated seamlessly as the lowest part of the architecture. So called Remote Parts can be executed on the PC which let the UCom appear to be just an ordinary MCA program or module to the MCA framework.