On Wed, 14 May 2008, Stephen Roderick wrote:

> On May 14, 2008, at 04:11 , Ruben Smits wrote:
>
>> On Tuesday May 13 2008 17:53:35 snrkiwi wrote:
>>> The OCL motion_control/CartesianVelocityController component appears to
>>> mix
>>> up calculation of cartesian pose via forward kinematics, with the
>>> transformation of cartesian-space velocities to joint-space velocities.
>>> Because the second part of this component should only be running when you
>>> are in a cartesian-space motion, the FK results are not always available.
>>
>> The FK and IK are put together for two reasons:
>>
>> The CartesianVelocityController is created as a wrapper around a
>> RobotnAxesVelocityController. The RobotnAxesVelocityController offers the
>> nAxesSensorPosition and receives the nAxesOutputVelocity. The
>> CartesianVelocityController translates this input from jointspace to
>> cartesianspace and vice-versa for the output.
>
> Understandable, but then how can I reuse this component if I have a
> _position_ (or torque) based robot, and not a velocity based one? If the FK
> was separate from IK+velocity, then I could reuse the FK component without
> change.

This is an (important) matter of 'granularity': "to what extent do we want
to reuse components to build new applications?"

The whole idea of _component_-based software development is to reuse only
"coarse grained" pieces of functionality, and not "fine grained"
functionality (which is what _object_-oriented software development is all
about; both are complementary of course).
One important consideration behind "componentization" is that communication
and "instrumentation" overhead is "large" for components, so using as few
of them as possible is better. One (not too golden) rule of thumb is to use
one component for all the functionality that runs in the same activity (=
thread, process) with the same frequency (if applicable) and with high data
sharing.

Components should be "easy and cheap" to reuse by _users_, not by
_developers_.

>> For this translation the CartesianVelocityController needs the
>> kinematic-structure of the Robot. This kinematic-structure is the same for
>> the forward position kinematics as for the inverse velocity kinematics.
>
> Yes, but the actual kinematic-structure is stored in the separate Robot
> component already. The CartesianVelocityController component simply holds
> both an FK and an IK solver, based on the kinematics. These two solvers are
> independant - they could certainly be in two components without any issue.

They can be in two different _objects_ (but even there I would object :-)),
but it makes little sense to put them in two _components_ (unless these
components provide their specific services to various clients at the same
time).

>>> I'm wondering what people think of splitting this into two components?
>>> # CartesianRobot that can be always calculating CartesianSensorPosition
>>> # CartesianVelocityController, which has the same functionality as now
>>> except for the FK calculation.
>>>
>>> This would allow you to have a CartesianRobot that is always producing the
>>> measured cartesian pose, while you could turn the other component off and
>>> on as necessary.
>>
>> Maybe it is better to just add the ability to activate/deactivate the IK in
>> the existing component? It is less work, and results in a cleaner solution
>> IMO, because the kinematic calculations stay in one component.
>
> Doesn't the component based approach here really lend itself towards turning
> off individual components, rather than pieces within components? Certainly I
> haven't come across any components within Orocos yet, that turn off only
> pieces of their functionality rather than their whole.

The reason for this "lack" is that we have not yet made applications that
work in a "software oriented architecture" way (i.e., as "web-like
services") but rather as high-efficiency, rather centralized executables in
their own sense.

> I think we are really just discussing the amount of decoupling we're each
> comfortable with ...?
Yes, indeed. And I would like to first discuss the more generic motivations
behind decoupling, because they are very different when speaking about
components or speaking about objects.

Herman

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm