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.

> 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.

>> 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.

I think we are really just discussing the amount of decoupling we're
each comfortable with ...?
S

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

 On Wednesday, May 14, 2008, at 09:58AM, "Herman Bruyninckx" <Herman.Bruyninckx at mech [dot] kuleuven [dot] be> wrote:

>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.

Then to me, wanting to always have FK results available, this lends itself to having the FK occur inside the robot component and not tying it to any one controller (of which there may be several).

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

This is an interesting concept ... and not one you see very often. Can you talk a little more about this ... (or point to some industry source about it)?

>>>> 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'm not sure what you're getting at here.

>> 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.

There is a difference there, and I definitely still think about things in an OO-point of view, at times. So where do _you_ draw the distinction between coupling of objects, and coupling of components?

S

On Wed, 14 May 2008, S Roderick wrote:

[...]
>> Components should be "easy and cheap" to reuse by _users_, not by
>> _developers_.
>
> This is an interesting concept ... and not one you see very often. Can you talk a little more about this ... (or point to some industry source about it)?

The electronics industry has always done that. And the construction
industry. And most industries that are more mature than software
engineering. Which is about _any_ industry :-)

[...]
>>> 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.
>
> There is a difference there, and I definitely still think about things in an OO-point of view, at times. So where do _you_ draw the distinction between coupling of objects, and coupling of components?

Rule of thumb:

- OO coupling = finding the appropriate balance between protection and access to shared variables
- component coupling = finding the appropriate balance between doing things

yourself and _communicating_ with others to do it for you.

Components have more "communication overhead", since they could run in
separate processes and computers.

Herman

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