Announcement OROCOS::SmartSoft

Dear all,

The CORBA based implementation of the SmartSoft framework is being
extended continuously. Since we are adding more and more components to
the repository, we give a short overview
on what is new and on what has changed since the last announcement.

First of all, we shortly summarize the wording used within the SmartSoft
framework. The SmartSoft framework provides a component approach based
on communication patterns. All
intercomponent interactions are mapped onto a small set of predefined
interaction modes.

An introduction to the concepts behind OROCOS::SmartSoft can be found at
http://www1.faw.uni-ulm.de/orocos/html-documentation/page_tutorial_overview.html

Components
are technically implemented as processes. A component can contain
several threads and interacts with other components via predefined
communication patterns. Components
can be wired dynamically at runtime.

Communication Patterns
assist the component builder and the application builder in building and
using distributed components in such a way that the semantics of the
interface is predefined
by the patterns, irrespective of where they are applied. A communication
pattern defines the communication mode, provides predefined access
methods and hides all the communication and
synchronization issues. It always consists of two complementary parts
named the service requestor and the service provider representing a
client/server, a master/slave or a
publisher/subscriber relationship.

Communication Objects
parameterize the communication pattern templates. They represent the
content to be transmitted via a communication pattern. They are always
transmitted by value
to avoid fine grained intercomponent communication each time an
attribute is accessed. Furthermore, object responsibilities are much
simpler with locally maintained objects than with
remote objects. Communication objects are ordinary objects decorated
with additional member functions for use by the framework.

Service.
Each instantiation of a communication pattern provides a service. A
service comprises the communication mode as defined by the communication
pattern and the content as
defined by the communication objects.

The set of communication patterns comprises the following patterns:

- send
- query
- push newest
- push timed
- event

- wiring

The framework explicitly supports dynamic wiring of components at run
time by a separate wiring-pattern. Dynamic wiring can be considered as
the pattern of robotics. Making both the
control flow and the data flow configurable from outside a component is
for example the key to situated skill compositions and is required in
nearly any robotic architecture. The dynamic
wiring pattern tightly interacts with the communication primitives and
makes one of the major difference to other approaches.


Changes:

- The core communication patterns
    - "Send", "Query", "PushNewest", "PushTimed" and "Event" now all
have the further improved and completely homogeneous user API
    - the "wiring" pattern for dynamic wiring of components at runtime
    - the "State Management Pattern" is decoupled from the communication
patterns and now is only ONE way to do state management.

- Communication Objects
    - Basic communication objects for content most needed in mobile
robotics

- Components
    - Nomad Base Server
            This component interfaces the Scout, SuperScout, Nomad 150,
and Nomad 200
            series of robots. Note that you can use this base server for
testing without a real robot in
            conjunction with the Nomadic simulation environment. (You
can download the
            simulation environment from
http://nomadic.sourceforge.net/production/host/,
            following the links entitled "host-2.6.9-i486-*" and "Open
License File")
    - SICK Laser Server
            The SICK Laser Server works both with LMS and PLS devices.
For LMS
            devices, angular and distance resolution is configurable.
    - Laser Tracking Server
            This component extracts objects from laser scans and tracks
them using a
            network optimization approach.
    - Joystick Server
            The joystick server interfaces analog PC joysticks
connecting to the game
            port. Use it for a "quick-and-dirty" teleoperation of your
mobile robot.
    - LIRC server
            The LIRC (Linux Infra Red Control) server reports the keys
pressed on a
            remote control as events. Furthermore it provides a joystick
emulation.

- Documentation
    - A lot of examples explaining how to use the patterns by component
builders and how to use the provided components by application builders
    - Detailed Doxygen documentation of all the patterns and their user
API


For up-to-date information see the web page
http://www1.faw.uni-ulm.de/orocos/ where you can also browse the
automatically generated documentation.




Christian Schlegel and Boris Kluge

--

---------------------------------------------------------------------
Christian Schlegel
FAW Ulm (Research Institute for Applied Knowledge Processing)
PO Box 2060
D-89010 Ulm
Germany

Tel. : ++49 (731) 501 8949
Fax  : ++49 (731) 501 999
email: [email protected]
WWW  : http://www.faw.uni-ulm.de/
---------------------------------------------------------------------