 Robotics Lab Department of Communications and Information Engineering University of Murcia
|
(Click on any image to enlarge it) One of the advantages of using Java is the real achievement of having platform independence. Thus, the development of the components is typically done in desktop computers with standard operating systems, while the actual deployment occurs in embedded systems that support Java. The current tested deployment systems include both Linux and Linux RT and embedded Java microcontrollers. Moreover, the Java implementation makes a simple process the integration of the human-interfaces in web-based scenarios. The functional architecture is based on ThinkingCap. It is a two layers architecture, for controlling mobile robots, one layer for reactive processes and the other for deliberative processes (Figure 1). The modules group the different functionalities present in typical mobile robotics systems (navigation, perception, control and planning), in which sensing and acting are a must. An important role is played by a centralised data structure called Local Perceptual Space (LPS). It is a geometrically consistent robot centric space which maintains a coherent model of the local environment of the robot, taking into account the a priori information (map) and the currently perceived information (sensors).  Figure 1. ThinkingCap-II functional architecture The Virtual Robot module provides an abstract interface to the sensori-motoric functionalities of the robot, effectively hiding the hardware components. The Perception module receives sensor data from the Virtual Robot and applies a certain set of perceptual routines, including sonar and laser based feature extraction and detection, and intelligent sensor fusion. The perceptual routines also access the LPS as a reference and to modify it in the case of evidence of a new environment feature (Figure 2).   Figure 2. LPS status in navigation and docking tasks The Controller module closes the control loop by taking as input the information included in the LPS and generating as output robot control values (Figure 3). It is typically implemented as a library of fuzzy behaviours for navigation, like obstacle avoidance, wall following, and door crossing. It includes a context-dependent blending mechanism that combines the recommendations from different behaviours into a trade off control. These three modules form the reactive layer.  Figure 3. Controller output values The Navigation module is in charge of modelling the environment by using both the LPS and an a priori world model (if available). It typically includes a series of map-building, localisation and path-planning algorithms, like fuzzy grid maps, fuzzy segments maps, topological maps, Kalman filters, and A* and D* planners (Figure 4). Finally, the Planner/Monitor module generates and supervises plans that are needed to solve the robot task. If needed, the planner may modify the current set of active or applicable behaviours in the Controller. These two modules form the deliberation layer.   Figure 4. Fuzzy grid map for path-planning and D* costs This architecture has been implemented and used in different types of robots and has shown good capabilities to serve as an abstract guideline to organise the software which has to be run in a module robot. Moreover, is simple enough to help understand how a given system works. The main goals of the TC-II software architecture design were: multi-robot support, distributed robot control, and flexible and reusable components. To achieve these goals, the TC-II software kernel includes and offers: specification of run-time parameters for the different modules, flexible configuration of the system (in terms of modules, robots and CPUs), and a predefined components library. The kernel makes extensive use of all the Object Oriented features of the Java language. The kernel defines an abstract model of a TC-II module, which all the modules must follow. These modules will correspond to the different modules of the functional architecture. Depending on the complexity of the system there could be a one to one correspondence of a one to many correspondence. For instance the Perception can be implemented as a single module or as a collection of submodules, but in any case the modules must stick to the abstract model definition. The abstract module has support for single thread and multi thread execution. As the modules can be distributed among a set of CPUs, the kernel relies on a centralised communication scheme, where all the communication goes through a blackboard. In addition, this blackboard is based on a event system so that modules do not need to poll the blackboard but wait until the desired type of event has occurred. The communication mechanism is detailed in the next section. The abstract TC-II module includes a port to put data into the blackboard and to receive data from the blackboard (via both polling and events). As TC-II has been used to develop many robotics systems, there exists a collection of algorithms and methods packaged in what is called standard components library. This is readily available to the system designer and includes methods for sensor fusion, map-building, path-planning, and localisation. The designer has simply to instantiate any of these methods from inside the desired module. In addition to this, the run-time characteristics of the system can be specified and customised by the use of configuration files, loaded when a TC-II application is launched (Figure 5). The kernel supports two different types of general configuration files, and contains methods to parse and check them. These configurations are used by all the modules:
 Figure 5. Default TC-II architecture launcher In addition to them, the kernel also includes an application specific configuration file, which might or might not be used by the different modules:
 Figure 6. RDF and WDF specification for a simulated experiment The blackboard of TC-II has been
designed to work in distributed scenarios, with different modules
running in different machines. It is also possible connecting more than
one robot to the system, where robots may need information from other
robots for coordination purposes and a global monitor to visualise the
location of the different robots. In this case, some kind of robot
specific naming and addressing is needed (to avoid that a module sends
a command to the wrong robot). Thus, each robot maintains its own
blackboard and, in addition, there is a global blackboard, which is
shared by the different robots.
In order to interface each robot instance with the global system, the architecture includes a connection module which is run in each robot (Figure 7). This module, the Router, is connected to both the local and global blackboards. This module is in charge of filtering information sent to and received from the global blackboard, acting as a lightweight communication router.  Figure
7. TC-II multi-robot architecture
In the example (Figure 7), there are two robots in execution, using the single robot TC-II architecture, running the modules needed for autonomous navigation. There are also two Router modules that receive tuples from the local blackboard and resend them to the global blackboard if needed. Thus, with this extension, a group of robots can be remotely monitored and/or controlled. As cited before, all the implementation has been done in Java, allowing external modules (like a global observer, a remote controller or a scheduler) to be embedded in a web page as a Java applet or as an external Java application (Figure 8). These external modules can also interact with the system, for instance for sending tasks to a given robot.  Figure 8. TC-II external monitor Platform independence is for granted by the use of the Java language, and it is a very important feature of the TC-II framework. This allows running and debugging the code in personal computers and testing it in the real platform. The TC-II framework takes benefit of this and includes a Simulator module that can simulate different sensor types, like range sensors (sonar, laser, radar) and positioning sensors (GPS, laser, compass), and platform models, like differential, tricycle and Ackerman drives (Figure 6). The sensor simulation is realistic enough for taking into account multi-path reflection, noise, and different firing patterns, while the platform simulation is based on kinematics equations and some pseudo dynamics constraints (i.e. the minimum time to perform a full turn of the steering wheel). The combination allows for testing the efficiency and performance of the different modules and their algorithms with an acceptable degree of realism. The simulator can simulate multiple robots, and their sensors not only reflect the environment but also the other robots. In addition, the simulator implements a 3D module for visualization purposes (Figure 9).  Figure 9. 3D visualization of a simulated environment The Simulator is implemented as a Virtual Robot that is not attached to any real device, and the same RDFs used by the real robots are used by the simulator to configure the sensor types and models and the platforms kinematics and constraints. Thus, switching between a real robot and a simulated one is as simple as changing the class name of the Virtual Robot section in the ADF. In addition, the model of the environment is specified using a WDF (which might be the same as that used by the robots). Applications
We are preparing a downloadable version. This will be available soon. VideosThe following links include videos of different robots performing autonomous tasks. All of them use TC-II as the infrastructure for the control software. In the following video our custom Quaky-II robot plays soccer (sort of). The robot uses a fixed camera to detect the different objects (ball and net), and tries to score by pushing the ball (orange) into the net (blue). The video processing relies on robust colour segmentation. The sonar ring is used for obstacle avoidance.
|
|
Last updated on January 11, 2005 |
|
