Hello everyone,
I am trying to implement a cartesian impedance controller from DLR's unified passivity based control framework. And I would like to create an orocos RTT component for forward kinematics or Jacobian calculation. Has somebody ever tried to make an orocos RTT component for this or is everybody using the KDL implementation.
Currently our negative feedback position controllers are running on 1Khz what probably is too fast for a 7Dof Jacobian and Forward kinematics calculation. Therefore I want to persue this pat only if the maximum frequency of these components is acceptable thus at least 100Hz.
Regards
Max Baeten
FK and Jacobian calculation in RTT
On Fri, 17 Jan 2014, m [dot] j [dot] j [dot] baeten [..] ... wrote:
> Hello everyone,
>
> I am trying to implement a cartesian impedance controller from DLR's unified
> passivity based control framework. And I would like to create an orocos RTT
> component for forward kinematics or Jacobian calculation. Has somebody ever
> tried to make an orocos RTT component for this or is everybody using the KDL
> implementation.
RTT components are meant to put several functions (like KLD dynamics
functions!) inside one and the same "process"/"thread"/"activity. It does
not make sense to put individual KDL functions each in their own RTT
component!
> Currently our negative feedback position controllers are running on 1Khz what
> probably is too fast for a 7Dof Jacobian and Forward kinematics calculation.
> Therefore I want to persue this pat only if the maximum frequency of these
> components is acceptable thus at least 100Hz.
>
> Regards
>
> Max Baeten
Herman
FK and Jacobian calculation in RTT
On Sunday, January 19, 2014 07:58:29 PM Herman Bruyninckx wrote:
> RTT components are meant to put several functions (like KLD dynamics
> functions!) inside one and the same "process"/"thread"/"activity. It does
> not make sense to put individual KDL functions each in their own RTT
> component!
Why not?
If the function is indeed costly *and* is reused (IK comes to mind), why
putting it in a single RTT component would be "bad" ?
FK and Jacobian calculation in RTT
On Jan 20, 2014, at 04:51 , Sylvain Joyeux <sylvain [dot] joyeux [..] ...> wrote:
> On Sunday, January 19, 2014 07:58:29 PM Herman Bruyninckx wrote:
>> RTT components are meant to put several functions (like KLD dynamics
>> functions!) inside one and the same "process"/"thread"/"activity. It does
>> not make sense to put individual KDL functions each in their own RTT
>> component!
> Why not?
>
> If the function is indeed costly *and* is reused (IK comes to mind), why
> putting it in a single RTT component would be "bad" ?
Agreed. It's comes down to the context of the system and the algorithms employed, rather than some generic set of rules that must apply.
S
FK and Jacobian calculation in RTT
On Mon, 20 Jan 2014, S Roderick wrote:
> On Jan 20, 2014, at 04:51 , Sylvain Joyeux <sylvain [dot] joyeux [..] ...> wrote:
>
>> On Sunday, January 19, 2014 07:58:29 PM Herman Bruyninckx wrote:
>>> RTT components are meant to put several functions (like KLD dynamics
>>> functions!) inside one and the same "process"/"thread"/"activity. It does
>>> not make sense to put individual KDL functions each in their own RTT
>>> component!
>> Why not?
>>
>> If the function is indeed costly *and* is reused (IK comes to mind), why
>> putting it in a single RTT component would be "bad" ?
>
> Agreed. It's comes down to the context of the system and the algorithms
> employed, rather than some generic set of rules that must apply.
Not agreed... It _is_ a generic rule that processes take up orders of
magnitude more resources than function calls, so the obvious _first_ thing
to think of is to reuse functionality as _functions_, not as
processes/activities. Assigning one single process to one single function
should be a well-motivated _exception_, and any (even implicit) suggestion
that "the context" is in general equally ready to accept either solution is
hard to motivate.
For example, in the context of IK/ID functionality: sharing the "costly"
_code_ of such a function is simple when deploying it as a function where
the different callers keep their own computational state of the function,
but reuse the executable code by just pointing to it; such decoupling of
computational state from the code of the algorithm does _in general_ not
require deployment in different processes (if the code is re-entrant).
About the cost of IK code: we are talking order of magnitude "kilobytes" of
binary executable code, so even using multiple copies of it is cheap,
compared to the "megabytes" of mainstream communication middleware and
software frameworks. Especially in an open source context, compiling in the
code in various "components" is not an issue (which is different in a
proprietary context, obviously, where deployment in a "DRM service" makes
sense, for the purpose of implementation hiding).
I am very open to be proven wrong, as always.
> S
Herman
FK and Jacobian calculation in RTT
On Tuesday, January 21, 2014 08:48:44 AM Herman Bruyninckx wrote:
> Not agreed... It _is_ a generic rule that processes take up orders of
> magnitude more resources than function calls, so the obvious _first_ thing
> to think of is to reuse functionality as _functions_, not as
> processes/activities.
1. You are equating component and process, which is obviously a
misreprentation (would I want to start a flamewar, I would say FUD given that
you KNOW how RTT is architectured).
2. You are assuming here that a function is cheap. It is obviously dependent
on the function ! Path planning algorithms can take easily north of 100ms to
run for *each run*. A ping-pong between two RTT components takes 25
microseconds.
It is interesting to see this discussion pop up here, as we are considering
using RTT as a form of plugin system and doing some serious benchmarking and
optimization to the RTT channel implementation for this purpose.
The motivation in our case is to integrate *once* algorithms that are shared
between planning and runtime (as e.g. IK) by being able to "hide" the
component as a function call within the motion planning algorithm (which would
only see a boost::function object, never an actual RTT component). So far, I
am honestly leaning towards "it is doable".
> Assigning one single process to one single function
> should be a well-motivated _exception_, and any (even implicit) suggestion
> that "the context" is in general equally ready to accept either solution is
> hard to motivate.
Rock's development guidelines stresses strongly that most of the functionality
should be put in libraries. In the end, some components *are* as few calls as
possible to single functions *because of this process*.
> For example, in the context of IK/ID functionality: sharing the "costly"
> _code_ of such a function is simple when deploying it as a function where
> the different callers keep their own computational state of the function,
> but reuse the executable code by just pointing to it; such decoupling of
> computational state from the code of the algorithm does _in general_ not
> require deployment in different processes (if the code is re-entrant).
Again component != process.
FK and Jacobian calculation in RTT
On Tue, 21 Jan 2014, Sylvain Joyeux wrote:
> On Tuesday, January 21, 2014 08:48:44 AM Herman Bruyninckx wrote:
>> Not agreed... It _is_ a generic rule that processes take up orders of
>> magnitude more resources than function calls, so the obvious _first_ thing
>> to think of is to reuse functionality as _functions_, not as
>> processes/activities.
> 1. You are equating component and process, which is obviously a
> misreprentation (would I want to start a flamewar, I would say FUD given that
> you KNOW how RTT is architectured).
I know what the _intention_ was (and that correspond to what you have in
mind) but unfortunately I also know how most newcomers are _using_ the RTT
infrastructure, and that is almost invariably "the ROS way", that is, by
assuming that each RTT component should be deployed in its own process or
thread...
> 2. You are assuming here that a function is cheap. It is obviously dependent
> on the function ! Path planning algorithms can take easily north of 100ms to
> run for *each run*. A ping-pong between two RTT components takes 25
> microseconds.
Depending on the _deployment_ of these components, and their current
_execution state_... (That is, are the components currently _ready_ to engage
in such a ping-pong or not, or are one or more context switches needed
before that ping-pong can take place.)
And your numbers do not invalidate my generic statements, nor do they
corroborate them, since timing is one of the most variable and
undeterministic aspects of any component-based system of any complexity.
> It is interesting to see this discussion pop up here, as we are considering
> using RTT as a form of plugin system and doing some serious benchmarking and
> optimization to the RTT channel implementation for this purpose.
That is definitely a worthwhile effort to undertake! But both of us were
present at a presentation at ICRA last year, where such "serious
benchmarking" was also undertaken (and not by amateurs), but nevertheless
many questions could be posed about the refutability of the benchmarks.
> The motivation in our case is to integrate *once* algorithms that are shared
> between planning and runtime (as e.g. IK) by being able to "hide" the
> component as a function call within the motion planning algorithm (which would
> only see a boost::function object, never an actual RTT component). So far, I
> am honestly leaning towards "it is doable".
>From your brief description, this looks the same motivation as what made us
(Markus Klotzbücher and myself) decide to start the "microblx" library;
pure C, no C++ or other dependencies there, because it should also work on
all kinds of embedded hardware such as FPGAs.
Also no "class APIs" either, so that "hiding" is not needed/possible, and
executed code and computational state of that code are 100% separated.
>> Assigning one single process to one single function
>> should be a well-motivated _exception_, and any (even implicit) suggestion
>> that "the context" is in general equally ready to accept either solution is
>> hard to motivate.
> Rock's development guidelines stresses strongly that most of the functionality
> should be put in libraries. In the end, some components *are* as few calls as
> possible to single functions *because of this process*.
Rock is, by far, the best development toolkit around, in my opinion.
_Because_ its developer(s) are knowledgeable in the tricky stuff of
multi-component system design :-)
>> For example, in the context of IK/ID functionality: sharing the "costly"
>> _code_ of such a function is simple when deploying it as a function where
>> the different callers keep their own computational state of the function,
>> but reuse the executable code by just pointing to it; such decoupling of
>> computational state from the code of the algorithm does _in general_ not
>> require deployment in different processes (if the code is re-entrant).
> Again component != process.
That is a rule that I am _trying_ to make people understand since about 5-6
years, but the efficiency of that teaching invariably turns out to be close
to zero, unfortunately... For one reason or another, the semantics of "!="
seems difficult to convey in a ROS-dominated world :-(
Of course, I support your continuing efforts to keep on repeating
the message. But having a "Simulink"/"microblx"/"function blocks"
alternative available (including lots of reference implementations with
relevant functionality, sich as planning and IK/ID) would our teaching
jobs _a lot_ easier :-)
Off topic: would anyone care to speculate on the importance of the
observation that Google bought more or less all robotics companies in the
US, _except_ the ROS-driven ones...?
> Dr. Ing. Sylvain Joyeux
Herman
FK and Jacobian calculation in RTT
2014/1/21 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> On Tue, 21 Jan 2014, Sylvain Joyeux wrote:
>
> On Tuesday, January 21, 2014 08:48:44 AM Herman Bruyninckx wrote:
>>
>>> Not agreed... It _is_ a generic rule that processes take up orders of
>>> magnitude more resources than function calls, so the obvious _first_
>>> thing
>>> to think of is to reuse functionality as _functions_, not as
>>> processes/activities.
>>>
>> 1. You are equating component and process, which is obviously a
>> misreprentation (would I want to start a flamewar, I would say FUD given
>> that
>> you KNOW how RTT is architectured).
>>
>
> I know what the _intention_ was (and that correspond to what you have in
> mind) but unfortunately I also know how most newcomers are _using_ the RTT
> infrastructure, and that is almost invariably "the ROS way", that is, by
> assuming that each RTT component should be deployed in its own process or
> thread...
It's not because most people use badly the system that it becomes the rigth
way ;p.
Assembling librairies into components and affecting then to
machines/process/thread/slave activity is 2 different jobs.
The first one is a system job where you are mainly create functionnal
paths, the second one is a pure informatician problem.
>
> 2. You are assuming here that a function is cheap. It is obviously
>> dependent
>> on the function ! Path planning algorithms can take easily north of 100ms
>> to
>> run for *each run*. A ping-pong between two RTT components takes 25
>> microseconds.
>>
>
> Depending on the _deployment_ of these components, and their current
> _execution state_... (That is, are the components currently _ready_ to
> engage
> in such a ping-pong or not, or are one or more context switches needed
> before that ping-pong can take place.)
>
> And your numbers do not invalidate my generic statements, nor do they
> corroborate them, since timing is one of the most variable and
> undeterministic aspects of any component-based system of any complexity.
>
>
> It is interesting to see this discussion pop up here, as we are
>> considering
>> using RTT as a form of plugin system and doing some serious benchmarking
>> and
>> optimization to the RTT channel implementation for this purpose.
>>
>
> That is definitely a worthwhile effort to undertake! But both of us were
> present at a presentation at ICRA last year, where such "serious
> benchmarking" was also undertaken (and not by amateurs), but nevertheless
> many questions could be posed about the refutability of the benchmarks.
>
>
> The motivation in our case is to integrate *once* algorithms that are
>> shared
>> between planning and runtime (as e.g. IK) by being able to "hide" the
>> component as a function call within the motion planning algorithm (which
>> would
>> only see a boost::function object, never an actual RTT component). So
>> far, I
>> am honestly leaning towards "it is doable".
>>
>
> From your brief description, this looks the same motivation as what made
>> us
>>
> (Markus Klotzbücher and myself) decide to start the "microblx" library;
> pure C, no C++ or other dependencies there, because it should also work on
> all kinds of embedded hardware such as FPGAs.
> Also no "class APIs" either, so that "hiding" is not needed/possible, and
> executed code and computational state of that code are 100% separated.
>
>
> Assigning one single process to one single function
>>> should be a well-motivated _exception_, and any (even implicit)
>>> suggestion
>>> that "the context" is in general equally ready to accept either solution
>>> is
>>> hard to motivate.
>>>
>>
> Rock's development guidelines stresses strongly that most of the
>> functionality
>> should be put in libraries. In the end, some components *are* as few
>> calls as
>> possible to single functions *because of this process*.
>>
>
> Rock is, by far, the best development toolkit around, in my opinion.
> _Because_ its developer(s) are knowledgeable in the tricky stuff of
> multi-component system design :-)
>
>
> For example, in the context of IK/ID functionality: sharing the "costly"
>>> _code_ of such a function is simple when deploying it as a function where
>>> the different callers keep their own computational state of the function,
>>> but reuse the executable code by just pointing to it; such decoupling of
>>> computational state from the code of the algorithm does _in general_ not
>>> require deployment in different processes (if the code is re-entrant).
>>>
>>
> Again component != process.
>>
>
> That is a rule that I am _trying_ to make people understand since about 5-6
> years, but the efficiency of that teaching invariably turns out to be close
> to zero, unfortunately... For one reason or another, the semantics of "!="
> seems difficult to convey in a ROS-dominated world :-(
>
> Of course, I support your continuing efforts to keep on repeating
> the message. But having a "Simulink"/"microblx"/"function blocks"
> alternative available (including lots of reference implementations with
> relevant functionality, sich as planning and IK/ID) would our teaching
> jobs _a lot_ easier :-)
>
> Off topic: would anyone care to speculate on the importance of the
> observation that Google bought more or less all robotics companies in the
> US, _except_ the ROS-driven ones...?
>
> Dr. Ing. Sylvain Joyeux
>>
>
> Herman
>
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
>
FK and Jacobian calculation in RTT
On Tuesday, January 21, 2014 11:19:24 AM Herman Bruyninckx wrote:
> Off topic: would anyone care to speculate on the importance of the
> observation that Google bought more or less all robotics companies in the
> US, _except_ the ROS-driven ones...?
Google being a software company (and Rubin already being in the software
world), I personally believe that it is simply something they did not feel
they needed to acquire.
Why did Google not buy "ROS"? (Was FK and Jacobian calculation
On Tue, 21 Jan 2014, Sylvain Joyeux wrote:
> On Tuesday, January 21, 2014 11:19:24 AM Herman Bruyninckx wrote:
>> Off topic: would anyone care to speculate on the importance of the
>> observation that Google bought more or less all robotics companies in the
>> US, _except_ the ROS-driven ones...?
>
> Google being a software company (and Rubin already being in the software
> world), I personally believe that it is simply something they did not feel
> they needed to acquire.
My interpretation is that Google wants to focus on more "mechatronics"-like
robotics, for which ROS has no added value, and the "Android" ecosystem
indeed already has a lot more to offer.
For me it is also very relevant that Rethink was _not_ bought; I presume
because of the low "mechatronics" performance of its hardware... (compared
to what companies like Boston Dynamics, Bot&Dolly, and Shaft can realise).
All just speculations, of course :-)
> Dr. Ing. Sylvain Joyeux
Herman
Why did Google not buy "ROS"? (Was FK and Jacobian calculation
On 21 January 2014 20:11, Herman Bruyninckx <
Herman [dot] Bruyninckx [..] ...> wrote:
> On Tue, 21 Jan 2014, Sylvain Joyeux wrote:
>
> > On Tuesday, January 21, 2014 11:19:24 AM Herman Bruyninckx wrote:
> >> Off topic: would anyone care to speculate on the importance of the
> >> observation that Google bought more or less all robotics companies in
> the
> >> US, _except_ the ROS-driven ones...?
> >
> > Google being a software company (and Rubin already being in the software
> > world), I personally believe that it is simply something they did not
> feel
> > they needed to acquire.
>
> My interpretation is that Google wants to focus on more "mechatronics"-like
> robotics, for which ROS has no added value, and the "Android" ecosystem
> indeed already has a lot more to offer.
>
> For me it is also very relevant that Rethink was _not_ bought; I presume
> because of the low "mechatronics" performance of its hardware... (compared
> to what companies like Boston Dynamics, Bot&Dolly, and Shaft can realise).
>
> All just speculations, of course :-)
>
>
Google didn't just buy mechatronics companies; they bought Bot & Dolly
(high-precision manipulator control) and Industrial Perception (vision).
However, Herman is right in that they bought several companies with
high-performance aspects and ignored those without. It seems to me that
they decided they already have a software infrastructure (whether it be
Android or ROS, which is, after all, open source so they can use it without
buying it), or can build one easily enough from what they have, and instead
focused on filling the gaps they need for their first target market (stated
as things like packaging), i.e. mechatronics, sensor processing and control.
I think that it's unlikely Google would use ROS, though. They want to
control the entire stack, which means using something they control. At the
most, they would fork ROS, but I can't see any benefit in forking what is
effectively a package manager instead of just taking the guts of the
packages they want and putting them into an Android framework.
Geoff
Why did Google not buy "ROS"? (Was FK and Jacobian calculation
On Wed, 22 Jan 2014, Geoffrey Biggs wrote:
> On 21 January 2014 20:11, Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...> wrote:
> On Tue, 21 Jan 2014, Sylvain Joyeux wrote:
>
> > On Tuesday, January 21, 2014 11:19:24 AM Herman Bruyninckx wrote:
> >> Off topic: would anyone care to speculate on the importance of the
> >> observation that Google bought more or less all robotics companies in the
> >> US, _except_ the ROS-driven ones...?
> >
> > Google being a software company (and Rubin already being in the software
> > world), I personally believe that it is simply something they did not feel
> > they needed to acquire.
>
> My interpretation is that Google wants to focus on more "mechatronics"-like
> robotics, for which ROS has no added value, and the "Android" ecosystem
> indeed already has a lot more to offer.
>
> For me it is also very relevant that Rethink was _not_ bought; I presume
> because of the low "mechatronics" performance of its hardware... (compared
> to what companies like Boston Dynamics, Bot&Dolly, and Shaft can realise).
>
> All just speculations, of course :-)
>
>
> Google didn't just buy mechatronics companies; they bought Bot & Dolly (high-precision
> manipulator control) and Industrial Perception (vision). However, Herman is right in that they
> bought several companies with high-performance aspects and ignored those without. It seems to me
> that they decided they already have a software infrastructure (whether it be Android or ROS,
> which is, after all, open source so they can use it without buying it),
But they can not _control_ is, as they do with Android, which is, on the
surface, also "open source". (But does not _operate_ like a real open
source project.)
> or can build one easily
> enough from what they have, and instead focused on filling the gaps they need for their first
> target market (stated as things like packaging), i.e. mechatronics, sensor processing and
> control.
>
> I think that it's unlikely Google would use ROS, though. They want to control the entire stack,
> which means using something they control. At the most, they would fork ROS, but I can't see any
> benefit in forking what is effectively a package manager instead of just taking the guts of the
> packages they want and putting them into an Android framework.
That is also what I expect to happen...
> Geoff
Herman
FK and Jacobian calculation in RTT
Hi,
On 01/17/2014 04:28 PM, m [dot] j [dot] j [dot] baeten [..] ... wrote:
> Hello everyone,
>
> I am trying to implement a cartesian impedance controller from DLR's unified
> passivity based control framework. And I would like to create an orocos RTT
> component for forward kinematics or Jacobian calculation. Has somebody ever
> tried to make an orocos RTT component for this or is everybody using the KDL
> implementation.
From my perspective (and I think most people I know using Orocos),
I use the KDL implementation (=library) inside a component.
>
> Currently our negative feedback position controllers are running on 1Khz what
> probably is too fast for a 7Dof Jacobian and Forward kinematics calculation.
KDL is implemented with real-time in mind (no reallocations...) and
(depending on your available hardware of course)
normally 1kHz shouldn't be a problem for those operations.
I would be more worried about IK on higher DOF robots
> Therefore I want to persue this pat only if the maximum frequency of these
> components is acceptable thus at least 100Hz.
as a reference:
in the comanipulation demo using iTaSC
(see http://orocos.org/wiki/orocos/itasc-wiki/itasc-tutorials/human-pr2-coman...)
I use a 20DOF PR2 robot for which I calculate FK and multiple Jacobians as a little step of the whole algorithm (including svd on 20x24 matrix) that completes within 0.01s
(100Hz)
Previous year someone mentioned the intention to do benchmark tests on the different KDL algorithms,
I'm interested if there where any results :)
>
> Regards
>
> Max Baeten
>
>
>
hth,
Nick