 |
 |
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Developing intelligent capabilities for robotic systems requires the integration of various technologies from different disciplines. It also requires the interaction of various software components within a real-time system, and the management of uncertainties resulting from the interaction of the robot with its environment. The uncertainties from the environment, the complexities of software/hardware interactions, and the variability of the robotic hardware make the task of developing robotic software complex, hard, and costly. Hence, it has become increasingly important to leverage robotic developments across projects and platforms. Because a number of the algorithms developed for robotic systems can be generalized, it is possible to use these algorithms on various platforms irrespective of the details of their implementations. It is such algorithms that CLARAty is trying to provide a framework for, while maintaining the ability to easily integrate platform-specific algorithms.
With the increased interest in developing rovers for future Mars exploration missions, a significant number of rover platforms have been designed and built over the past decade. Several NASA centers and university partners use these platforms to test their newly developed technologies in order to improve the autonomous robot capabilities. Because of isolated software development efforts, exacerbated by differences in the mechanical and electrical designs of these vehicles, they have historically shared little in terms of software infrastructure. As a result, transferring capabilities from one rover to another has been a major and costly endeavor. Furthermore, because robotics systems cover several domain areas, researchers of a single domain also needed to integrate their newly developed technology into the complex robotic environment. Proper integration requires an in-depth understanding and characterization of the behavior of various components of the system, which may vary from one platform to another.
The CLARAty architecture has two distinct layers: the Functional Layer and the Decision Layer. The Functional Layer uses an object-oriented system decomposition and employs a number of known design patterns to achieve reusable and extendible components. These components define an interface and provide basic system functionality that can be adapted to a variety of real or simulated robots. It provides both low- and mid-level autonomy capabilities. The Decision Layer couples the planning and execution system. It globally reasons about the intended goals, system resources, and state of the system and its environment. The Decision Layer uses a declarative-based model while the Functional Layer uses a procedural-based model. Because the Functional Layer provides an adaptation to a physical or simulated system, all specific model information is collocated in the system adaptations. The Decision layer receives this information by querying the Functional Layer for predicted resource usage, state updates, and model information. However, additional adaptation specific heuristics are often used with current planners to assist in plan generation. These adaptation specific heuristics, which are only used by the Decision Layer, can be accessed directly and not via the Functional Layer.
The Decision Layer accesses the Functional Layer at various levels of granularity. The architecture allows for overlap in the functionality of both layers. This intentional overlap allows users to elaborate the declarative model to lower levels of granularity. But is also allows the Functional Layer to build higher level abstractions (e.g. navigator) that provide mid-level autonomy capabilities. In the latter case, the Decision Layer serves as a monitor to the execution of the Functional Layer behavior, which can be interrupted and preempted depending on mission priorities and constraints.
The Functional Layer includes a number of generic frameworks centered on various robotic-related disciplines. Packages included in the Functional Layer are: digital and analog I/O, motion control and coordination, locomotion, manipulation, vision, navigation, mapping, terrain evaluation, path planning, science analysis, estimation, simulation, and system behavior. The Functional Layer provides the system's low- and mid-level autonomy capabilities. Control algorithms such as vision-based navigation, sensor-based manipulation, and visual target tracking that use a predefined sequence of operations are often implemented in the Functional Layer. In some cases though, it is possible to generate such sequence of operations by modeling them as activities and having the Decision Layer schedule instantiations of these activities based on appropriate mission goals and constraints.
The Functional Layer has four main features. First, it provides a system level decomposition with various levels of abstractions. For example, a general locomotor provides an interface to any type of mobility platform whether it is a wheeled vehicle, a legged mechanism, or a hybrid of the two. A functional specialization of the locomotor is the wheeled locomotor. This specialization introduces the concept of wheeled mobility and wheel configuration. This functional specialization extends the locomotion interface to include additional capabilities. Further extensions of the wheeled locomotor include special types of wheel locomotors with known locomotion models.
Second, the Functional Layer separates algorithmic capabilities from system capabilities. It is important to decouple system limitations from the algorithmic limitations in order to avoid propagation of assumptions that are unique to a particular platform. Algorithms are expressed in their most general terms without compromising understandability and efficiency. Where efficiency requirements are not met, specializations are provided to overwrite the general solution. An example of this can be found in the manipulation domain. General inverse kinematics algorithms provide a generic solution for all serial manipulators but are often not efficient. As a result, they are overwritten with specialized, more efficient versions. The general versions however, are useful in instances where the specialized solutions have not been derived yet or for validating the specialized implementation.
Third, the Functional Layer separates the behavioral definitions and interactions of the system from the implementation. This separation not only allows the dynamic binding of adaptations at runtime, but it also makes both the functional and implementation trees extensible. For example, a wheeled locomotor separates considerations related to the behavioral and functional models from considerations related to the hardware interface. Another example is the controlled motor, which separates the specialization to a particular hardware controller from the functional specialization of a controlled motor to a joint (which extends the motor functionality by imposing checking of joint limits on all the move commands).
Fourth, the Functional Layer provides flexible runtime models. The runtime model is part of the abstraction model, of which, one part is associated with the generic functionality and the other with the adaptation. The runtime model associated with the adaptation is dependent on particular capabilities of the underlying hardware and can change from one system to another. For example, a system with a distributed motion control architecture does not need to run the servo control and trajectory generation threads on the main processor. This capability can be implemented in firmware on distributed processors.
The Decision Layer is a global engine that reasons about system resources and mission constraints. It includes general planners, executives, schedulers, activity databases, and rover and planner specific heuristics.
The Decision Layer plans, schedules, and executes activity plans. It also monitors the execution modifying the sequence of activities dynamically when necessary. The goal of a generic Decision Layer is to have a unified representation of activities and interfaces. The current instantiation of the Decision Layer which we use at JPL features a tight coupling of the planner and the executive. For this example, the planner implementation is the CASPER planning and scheduling system and the executive implementation is the TDL executive system.
The Decision Layer interacts with the Functional Layer using a client-server model. The Decision Layer queries the Functional Layer about availability of system resources in order to predict the resource usage of a given operation. The Decision Layer sends commands to the Functional Layer at various levels of granularity. The Decision Layer can utilize encapsulated Functional Layer capabilities with relatively high-level commands, or access lower-level capabilities and combine them in ways not provided by the Functional Layer. The former is valuable when planning capabilities are limited, or when under-constrained system operation is acceptable. The latter is valuable if detailed, globally optimized, planning is possible, or if resource margins are small. CLARAty supports both modes of operation. Status on resources, state conditions, and activity execution is reported from the Functional Layer to the Decision Layer asynchronously or synchronously at rates specified by the Decision Layer.
Document Clearance #: CL 03-2746
