Identified Components and Modules

Hello,

Since the paper defining our motion control framework with its components and 
modules is still in the pipeline, I'll give a short summary about what has 
been found.  The paper is far more elaborated and I hope a draft will be 
posted soon.

At the moment, the following components are identified :
(where each component resides in its own subdirectory. )

HeartBeatGenerator
Our virtual clock.  Generates time-events (which for example start a thread), 
synchronises component clocks, prioritises timing events. This is a core 
component.

EventHandler
Handles all events not coming from the HeartBeatGenerator. All forms of 
communication can be seen as events. This component decouples event generator 
from event receiver and may execute additional methods (defined by the event) 
as a response to an event.
This is a core component. 

ExceptionHandler
Handles inter-component exceptions, can bring the system to a safe state. 
Secures the stability of the whole system in contrast to local component 
exception handling.

ServoLoop
Controls the actuators

MotionGenerator
Generates setpoints, possibly taking in account the kinematic model and other 
factors. Multiple motion generators may exist in the system with different 
levels of complexity ( a simple interpolator is still called 'motion 
generator' )

Actuator ( with many subtypes )
Any kind of motor or moving part used by the robot to interact with its 
environment.

Sensor   ( with many subtypes )
Any kind of input for our (robot-) system

CommandInterpreter
The core input of the system, gets commands from the user, most commands go 
to the TaskManager, some directly to other components (not yet defined).

TaskManager
With the help of the ComponentSupervisor, Tasks are delegated to other 
components through this manager. It has knowledge of deadlines, distributed 
tasks and the capabilities of the system. It is responsible for configuration 
during runtime and startup time. This thing is huge.

ComponentSupervisor
Takes care of the more technical management of components, this means that it 
has a database of all present components and does nameserving.  Most likely 
delivers ORB/distributed capabilities.  This is a core component.

ObjectFactory
Manages creation and destruction of objects in the whole system. This is a 
core component for real time systems since all objects must be created at 
startup time.

Estimator
Creates/updates models of the system and the environment.

Monitoring
collects data from the system to hand it over to the user.  Used for logging, 
simulation / visualisation purposes.

This list is not exhaustive and I'll get hopefully more input from you all.

The following modules have been identified :

ControlModule
this can be anything, ranging from PI controller to unit converters, to be 
short, anything that can be used in a control loop.

Thread
When started, this will execute ( most likely periodically ) a certain method 
of the Component.

ICC CommandInterpreter
Interprets inter-component commands and delegates them internally to the 
right module. This is our main ``port'' for communication.

FiniteStateMachine
Optionally, the component can be a FSM, with each state executing / running a 
number of modules.

ConfigurationModule
Internally configures / manages the modules present in the component.  Has 
the meta information about the internals of a component. Only needed for more 
complex components (consisting of more than one module).

ProxyModule
Keeps local images of remote components.  Decouples the updating of new 
information with the delivery of information to the component.

ExceptionModule
Makes sure that the internal state of the component is kept consistent when 
an exception occurs.

It was easier to define components than to find modules.  Modules provide 
local functionality which can be used in a wide range of components. The 
identification of modules is more of a software designer problem than a 
framework designer problem and I expect that it will be more implicitly 
solved during the building of the framework. Most software patterns might be 
good candidates to become modules.

In Object Oriented approaches, the modules will be more likely single objects 
with a defined responsibility.  It is evident that these objects will be used 
across components, to comply with reusability.

The above is list of components and modules is hardly nuancated and most of 
them need to be put in perspective or described more technically.

Nevertheless, comments are welcome :-)

kind regards,

Peter Soetens