Articles Forum Examples Download Open Source
Oct 17, 2007
Copyright(c) 2007 by Pocomatic Software. All Rights Reserved.
To control complexity, speed up development/delivery, and reduce total lifecycle cost, software for robotic systems are increasingly built from reusable components. Robotic systems are inherently component-based at the hardware layer. Therefore, there are far less hesitations and far more practices on pursuing “component-based development” (CBD) or "component-based software engineering" (CBSE) at the software layer in the robot industry/community than in others, indicated by the overwhelming number of robotic component collections, toolkits, and frameworks, such as Player/Stage, CARMEN, OROCOS, ORCA, MARIE, CLARAty, MIRO, Microsoft Robotics Studio, as well as the OMG Robotic Technology Component (RTC) and its experiemental implementation OpenRTM-aist.
The productivity in developing a given robotic software system and the customizability/extendibility in deploying and evolving it are not solely determined by how well robot monitoring and controlling functions are factored in separate components as in the component collections or toolkits listed above, but also heavily rely on how effective and flexible these components are able to be assembled back together into a seamlessly collaborated application and deployed in a service and device driver adapting environment. Some frameworks listed above do come with assembly solutions (Such as the XML deployment of OROCOS, and the OMG-D&C for OMG-RTC). However, these assembly solutions were designed for their particular component models, hence are not applicable to third party components. This largely prohibits the reusability of third party components and legacy implementations, rules out the transferability of developer/user skills and experiences, and discourages the interchangeability of development tools across frameworks. Hence, robotic applications are still largely assembled, deployed, and configured manually using low level APIs and/or proprietary configuration files.
PocoCapsule IoC & DSM is an open and customizable component framework that addresses above issues with its following characteristics:
Neutral to heterogeneous component programming models: Any C++ programming artifacts, such as instances of arbitrary user or third party defined C++ classes, template classes, K&R structs, and even function pointers are valid/manageable components in PocoCapsule. Therefore, PocoCapsule can be used as an assembly framework for any of the above robotic component collections/toolkits.
Simple core assembly model/schema: Instead of requiring a steep learning curve, long ramp up time, and high development and maintenance cost, the core model/schema of PocoCapsule is exceptionally simple, intuitive, and straightforward to application developers and novice.
Easily extensible and customizable assembly schema: Instead of mandating a single rigid “one-size-fits-all” robotic application model description schema at a predefined abstraction level, PocoCapsule allows domain users or third parties to easily and flexibly define extended and customized domain specific modeling (DSM) schemas.
Lightweight and zero overhead: PocoCapsule is able to fit in the most rigorous real-time embedded environments and does not introduce performance overhead and real-time latency.
These characteristics are clearly illustrated through out the following simple robotic vehicle example originated from the Microsoft Robotics Studio. In this example, a robotic vehicle motion control application is built from 7 components as illustrated in the following diagram:
To explicitly illustrate the programming model neutrality and assembly model customizability of the PocoCapsule framework, this robotic vehicle control system is built in two different sets of programming/assembling models to be described in the next two sections respectively.
Full source code of this example can be found in the examples/basic-ioc/robotic-vehicle directory of PocoCapsule installation.
In this scenario, component implementations are simply plain old C++ objects (POCOs) without any special dependency on an underlying middleware framework or the PocoCapsule container itself. These components represent controlling and monitoring modules or controllable and event emitter devices. Each component could have four kind of ports:
Device controller receptacle ports: These ports are implemented by controller components as setter methods to accept injected device driver references (as plain old C++ callback object pointers).
Event emitter receptacle ports: These ports are implemented by event emitter components as setter methods to accept injected event sink references (as plain old C++ callback object pointers).
Controllable device facet ports: These ports are implemented by controllable device components as getter methods to return their device driver references (as plain old C++ callback object pointers). These references can be injected into desired receptacle ports of device controller components.
Event sink ports: These ports are implemented by event receive components as getter methods to return their event sink references (as plain old C++ callback object pointers). These references can be injected into desired receptacle ports of event emitter components.
The robotic vehicle monitoring and control system could then be built by wiring up these ports. These wirings and instantiate of components are described in a domain specific modeling (DSM) schema as defined in the DTD file. This schema has mainly three important elements, namely the <component>, <controls>, and <listens>.
A <component> element declares a robotic component instance of the specified C++ class. A <controls> child element of a <component> declares a wire from the specified controller receptacle port of this component to the specified facet port (of the specified type) of a controllable device component. For instance, a <controls> wire from the LeftWheelControlOut receptacle port of the VehicleController component to the ControlIn facet port of the left-wheel device is declared as follows:
|
This <controls> element declares a controller-to-controllable wiring that is illustrated in the following diagram:
Similarly, a <listens> child element of a <component> declares a wire end up at the specified event sink port (of the specified type) of this component that comes from the specified receptacle port of an event emitter component. For instance, a <listens> wire end up at the LeftWheelSpeedDataIn sink port of the VehicelController component that comes from the SpeedDataOut port of the left-wheel event emitter is declared as follows:
|
This <listens> element declares an emitter-to-skin wiring that is illustrated in the following diagram:
Full source code of this example can be found in the examples/corba/rtc directory of PocoCapsule installation.
In this scenario, by OMG Robotic Technology Component (RTC) specification, components are simply CORBA objects with IDL interfaces extended from RTC::LightweightRTObject.
These components represent controlling and monitoring modules or controllable and event emitter devices. Each component could have four kind of ports, according to Robotic Technology Component (RTC):
Device controller receptacle ports: These ports are implemented by controller components as connect_<receptacle_name> setter methods to accept injected device driver references (as CORBA callback object references).
Event emitter receptacle ports: These ports are implemented by event emitter components as connect_<receptacle_name> setter methods to accept injected event sink references (as CORBA callback object references).
Controllable device facet ports: These ports are implemented by controllable device components as provide_<facet_name> getter methods to return their device driver references (as CORBA callback object references). These references can be injected into desired receptacle ports of device controller components.
Event sink ports: These ports are implemented by event receive components as get_consumer_<sink_name> getter methods to return their event sink references (as CORBA callback object references). These references can be injected into desired receptacle ports of event emitter components.
The robotic vehicle monitoring and control system could then be built by wiring up these ports. These wirings and instantiate of components are described in a domain specific modeling (DSM) schema as defined in the DTD file. This schema has mainly three important elements, namely the <component>, <uses>, and <listens>.
A <component> element declares a robotic component instance of the specified CORBA object implementation class. A <uses> child element of a <component> declares a wire from the specified controller receptacle port of this component to the specified facet port (of the specified type) of a controllable device component. For instance, a <uses> wire from the LeftWheelControlOut receptacle port of the VehicleControllerImpl component to the Control facet port of the left-wheel provider component is declared as follows:
|
This <uses> element declares a controller-to-controllable wiring that is illustrated in the following diagram:
Similarly, a <listens> child element of a <component> declares a wire end up at the specified event sink port (of the specified type) of this component that comes from the specified receptacle port of an event emitter component. For instance, a <listens> wire end up at the LeftWheelSpeedDataIn sink port of the VehicelControllerImpl component that comes from the SpeedDataOut port of the left-wheel event emitter is declared as follows:
|
This <listens> element declares an emitter-to-skin wiring that is illustrated in the following diagram:
Back to the PocoCapsule articles page
This page has been visited:
| free hit counter html code |