tutorial ... That led to me having a few generic questions about iTaSC,
as well as issues / comments.
Let's start with the questions:
- how tightly is iTaSC linked to lua ? From what I read on the
documentation, it is only used for coordination. In other words, I
should be able to deploy a single iTaSC-based controller without lua,
lua being only used to switch between the various configurations. Is
that right ? If that is indeed right, I personally believe that the
documentation should spend more time explaining how to build a
controller before going into the whole coordination issue, as people
will *need* controllers before they can coordinate them.
- VKC: what is updateVKCE for ? The initialized port ?
- SubRobot: same for updateRobotState and sendToRobot.
- I have the impression (from my very quick reading) that some of the
examples should be subclassing the SubRobot/VKC class from itask_core
but do not. Is that right ? Or am I missing something ?
Big issue:
- the eigen_toolkit which is directly embedded in itask_core. I guess
that is required for the lua stuff, or ?
Smaller issue:
- the fact that most of the repositories are ROS stacks. Honestly, you
are currently cutting the packages in pieces so small that it stops
making a lot of sense to me (making itasc_robot_objects, itasc_tasks and
itask_solvers packages would make a lot more sense). This is definitely
not a showstopper, though.
Comments / need for clarifications / help on iTaSC-related subje
More comments ! Now that I found out that there *was* some
computation-related documentation (in the form of a PDF), I can maybe
give some more useful comments ...
- really, drop the lua stuff in the first twenty slides. As long as I
have not understood what all the "control" parts do, the lua stuff is
really useless information.
- Really give an idea of what each single component type does (VKC,
SubRobot, Object, Link, whatever) after the overview. One by one.
Ideally constructing something in the process (i.e. maybe start with the
objects / robots, then add the VKC, then add constraints and finally add
the solver). Tell us what the I/O are in terms of the role of the
component (because, honestly, I don't read control equations without
being the guy that wrote them or having a 2-page explanation for each
term). Finally, what does the scene do ? How do I use it ?
Comments / need for clarifications / help on iTaSC-related subje
On 10/25/2012 10:28 AM, Sylvain Joyeux wrote:
> More comments ! Now that I found out that there *was* some
> computation-related documentation (in the form of a PDF), I can maybe
> give some more useful comments ...
are you referring to 'itasc_manual.pdf'?
>
> - really, drop the lua stuff in the first twenty slides. As long as I
> have not understood what all the "control" parts do, the lua stuff is
> really useless information.
> - Really give an idea of what each single component type does (VKC,
> SubRobot, Object, Link, whatever) after the overview. One by one.
> Ideally constructing something in the process (i.e. maybe start with the
> objects / robots, then add the VKC, then add constraints and finally add
> the solver). Tell us what the I/O are in terms of the role of the
> component (because, honestly, I don't read control equations without
> being the guy that wrote them or having a 2-page explanation for each
> term). Finally, what does the scene do ? How do I use it ?
>
The current documentation is indeed very limited. It had as main focus people that know about the iTaSC paper (and ideally Ruben Smits Phd).
Those people didn't knew much about the FSM part, at the time. Therefore the bias to 'lua stuff'.
I intend to clean up the documentation as soon I have some publications about it out and some time.
At the moment, I would recommend you to read the following paper, which describes in words (and without any lua stuff) the iTaSC idea chopped up in the same way as the code.
The current scene 'knows where everything is' (as a scene normally does), and since it knows that, it serves as a 'gathering point' which collects all task outcomes, joint
positions... It divides also this data among all components that need to know (eg. a VKC of a task needs to know only the pose between the object frames between which it is
defined).
A paper that explains everything in detail is on its way and also a way to deal with iTaSC in an easy way.
hth,
nick
Comments / need for clarifications / help on iTaSC-related subje
On 10/29/2012 07:43 PM, Dominick Vanthienen wrote:
>
>
> On 10/25/2012 10:28 AM, Sylvain Joyeux wrote:
>> More comments ! Now that I found out that there *was* some
>> computation-related documentation (in the form of a PDF), I can maybe
>> give some more useful comments ...
> are you referring to 'itasc_manual.pdf'?
>>
>> - really, drop the lua stuff in the first twenty slides. As long as I
>> have not understood what all the "control" parts do, the lua stuff is
>> really useless information.
>> - Really give an idea of what each single component type does (VKC,
>> SubRobot, Object, Link, whatever) after the overview. One by one.
>> Ideally constructing something in the process (i.e. maybe start with the
>> objects / robots, then add the VKC, then add constraints and finally add
>> the solver). Tell us what the I/O are in terms of the role of the
>> component (because, honestly, I don't read control equations without
>> being the guy that wrote them or having a 2-page explanation for each
>> term). Finally, what does the scene do ? How do I use it ?
>>
> The current documentation is indeed very limited. It had as main focus people that know about the iTaSC paper (and ideally Ruben Smits Phd).
> Those people didn't knew much about the FSM part, at the time. Therefore the bias to 'lua stuff'.
> I intend to clean up the documentation as soon I have some publications about it out and some time.
> At the moment, I would recommend you to read the following paper, which describes in words (and without any lua stuff) the iTaSC idea chopped up in the same way as the code.
Vanthienen, D., De Laet, T., Decré, W., Bruyninckx, H., De Schutter, J. (2012). Force-Sensorless and Bimanual Human-Robot Comanipulation. 10th IFAC Symposium on Robot
Control. international symposium on robot control. Dubrovnik, Croatia, 5-7 September 2012 (art.nr. 127)
>
> The current scene 'knows where everything is' (as a scene normally does), and since it knows that, it serves as a 'gathering point' which collects all task outcomes, joint
> positions... It divides also this data among all components that need to know (eg. a VKC of a task needs to know only the pose between the object frames between which it is
> defined).
>
> A paper that explains everything in detail is on its way and also a way to deal with iTaSC in an easy way.
>
> hth,
>
> nick
>
>
Comments / need for clarifications / help on iTaSC-related subje
On Wed, 24 Oct 2012, Sylvain Joyeux wrote:
> Context: I was looking into using Rock tools to interface with iTaSC
> tutorial ... That led to me having a few generic questions about iTaSC,
> as well as issues / comments.
>
> Let's start with the questions:
>
> - how tightly is iTaSC linked to lua ? From what I read on the
> documentation, it is only used for coordination.
Indeed.
> In other words, I
> should be able to deploy a single iTaSC-based controller without lua,
> lua being only used to switch between the various configurations. Is
> that right ? If that is indeed right, I personally believe that the
> documentation should spend more time explaining how to build a
> controller before going into the whole coordination issue, as people
> will *need* controllers before they can coordinate them.
I do not agree: designing controllers without taking coordination into
account has led, time and again, to coordination-behind-the-screens in
control implementations. We have learned that the hard way ourselves.
> - VKC: what is updateVKCE for ? The initialized port ?
> - SubRobot: same for updateRobotState and sendToRobot.
> - I have the impression (from my very quick reading) that some of the
> examples should be subclassing the SubRobot/VKC class from itask_core
> but do not. Is that right ? Or am I missing something ?
>
> Big issue:
> - the eigen_toolkit which is directly embedded in itask_core. I guess
> that is required for the lua stuff, or ?
No, for the solver, that uses SVD.
> Smaller issue:
> - the fact that most of the repositories are ROS stacks. Honestly, you
> are currently cutting the packages in pieces so small that it stops
> making a lot of sense to me
I agree with you. Our last refactoring went way too far in "modularizing"
the whole thing. Our current refactoring will do better; but it is a
_huge_ undertaking, taking much longer than expected.
> (making itasc_robot_objects, itasc_tasks and
> itask_solvers packages would make a lot more sense). This is definitely
> not a showstopper, though.
>
Herman
Comments / need for clarifications / help on iTaSC-related subje
On 10/24/2012 04:25 PM, Herman Bruyninckx wrote:
>> In other words, I
>> should be able to deploy a single iTaSC-based controller without lua,
>> lua being only used to switch between the various configurations. Is
>> that right ? If that is indeed right, I personally believe that the
>> documentation should spend more time explaining how to build a
>> controller before going into the whole coordination issue, as people
>> will *need* controllers before they can coordinate them.
>
> I do not agree: designing controllers without taking coordination into
> account has led, time and again, to coordination-behind-the-screens in
> control implementations. We have learned that the hard way ourselves.
Not if you give good guidelines on how to write the controller. The
issue, as always, is that you need to split the controller components
"properly" so that the controller behaviour can be changed by rewiring /
reconfiguring these components.
Putting the coordination at the front of the documentation is *really*
messing the understanding. I want *first* to create single-behaviour
controllers and *then* coordinate these controllers to manage my system.
Moreover, I want to understand *how* I can coordinate them using
whatever *tool* I want (i.e. not necessarily lua).
>> - VKC: what is updateVKCE for ? The initialized port ?
>> - SubRobot: same for updateRobotState and sendToRobot.
>> - I have the impression (from my very quick reading) that some of the
>> examples should be subclassing the SubRobot/VKC class from itask_core
>> but do not. Is that right ? Or am I missing something ?
>>
>> Big issue:
>> - the eigen_toolkit which is directly embedded in itask_core. I guess
>> that is required for the lua stuff, or ?
>
> No, for the solver, that uses SVD.
Well, obviously Eigen is required for the solver. I don't see how the
solver requires a RTT typekit though.
>
>> Smaller issue:
>> - the fact that most of the repositories are ROS stacks. Honestly, you
>> are currently cutting the packages in pieces so small that it stops
>> making a lot of sense to me
>
> I agree with you. Our last refactoring went way too far in "modularizing"
> the whole thing. Our current refactoring will do better; but it is a
> _huge_ undertaking, taking much longer than expected.
So ... You are currently rewriting / refactoring the whole thing ? Which
means what ? That we should hold uintil you are finished ?
Comments / need for clarifications / help on iTaSC-related subje
On Thu, 25 Oct 2012, Sylvain Joyeux wrote:
> On 10/24/2012 04:25 PM, Herman Bruyninckx wrote:
>>> In other words, I
>>> should be able to deploy a single iTaSC-based controller without lua,
>>> lua being only used to switch between the various configurations. Is
>>> that right ? If that is indeed right, I personally believe that the
>>> documentation should spend more time explaining how to build a
>>> controller before going into the whole coordination issue, as people
>>> will *need* controllers before they can coordinate them.
>>
>> I do not agree: designing controllers without taking coordination into
>> account has led, time and again, to coordination-behind-the-screens in
>> control implementations. We have learned that the hard way ourselves.
> Not if you give good guidelines on how to write the controller.
No! Because the _real_ problem is that the coordination requires
_knowledge_ about the _application_, that should not be put inside the
control component.
> The issue, as
> always, is that you need to split the controller components "properly" so
> that the controller behaviour can be changed by rewiring / reconfiguring
> these components.
That motivation is exactly why we have materialized the concerns of Coordination and
Configuration into explicit components :-) So, we are back to (my!) square
zero :-)
> Putting the coordination at the front of the documentation is *really*
> messing the understanding.
This is a comment that I can agree to! But _something_ has to come first...
> I want *first* to create single-behaviour
> controllers and *then* coordinate these controllers to manage my system.
This is _your_ use case... Other people have first a "task plan" in mind,
and are then looking for "control" components that can realise parts of
that plan.
And there are several other work flows out there. Very difficult to make
good documentation for, in a serial way.
> Moreover, I want to understand *how* I can coordinate them using whatever
> *tool* I want (i.e. not necessarily lua).
Agreed.
>>> - VKC: what is updateVKCE for ? The initialized port ?
>>> - SubRobot: same for updateRobotState and sendToRobot.
>>> - I have the impression (from my very quick reading) that some of the
>>> examples should be subclassing the SubRobot/VKC class from itask_core
>>> but do not. Is that right ? Or am I missing something ?
>>>
>>> Big issue:
>>> - the eigen_toolkit which is directly embedded in itask_core. I guess
>>> that is required for the lua stuff, or ?
>>
>> No, for the solver, that uses SVD.
> Well, obviously Eigen is required for the solver. I don't see how the solver
> requires a RTT typekit though.
>>
>>> Smaller issue:
>>> - the fact that most of the repositories are ROS stacks. Honestly, you
>>> are currently cutting the packages in pieces so small that it stops
>>> making a lot of sense to me
>>
>> I agree with you. Our last refactoring went way too far in "modularizing"
>> the whole thing. Our current refactoring will do better; but it is a
>> _huge_ undertaking, taking much longer than expected.
> So ... You are currently rewriting / refactoring the whole thing ? Which
> means what ?
- Bringing in the "BRICS Component Model" in a better way.
- improved solvers
- also more declarative specifications than the very procedural and
explicit approach via the VKC model
- But most importantly, to design one or more DSLs (Domain Specific
Languages) to make itasc programming easier.
> That we should hold uintil you are finished ?
That depends on what kind of applications you need. There are quite a lot
of them for which the current itasc is ok, and the new developments might
be overkill...
> Sylvain Joyeux (Dr.Ing.)
Herman
Comments / need for clarifications / help on iTaSC-related subje
On 10/25/2012 09:43 AM, Herman Bruyninckx wrote:
>>> I do not agree: designing controllers without taking coordination into
>>> account has led, time and again, to coordination-behind-the-screens in
>>> control implementations. We have learned that the hard way ourselves.
>> Not if you give good guidelines on how to write the controller.
>
>
> No! Because the _real_ problem is that the coordination requires
> _knowledge_ about the _application_, that should not be put inside the
> control component.
Yes. So, again, "good guidelines on how to write a single controller
that can be reused"
>> The issue, as always, is that you need to split the controller
>> components "properly" so that the controller behaviour can be changed
>> by rewiring / reconfiguring these components.
>
> That motivation is exactly why we have materialized the concerns of
> Coordination and
> Configuration into explicit components :-) So, we are back to (my!)
> square
> zero :-)
Since rock and rock-roby follows that design for more than two years
now, I can't agree more.
>> I want *first* to create single-behaviour controllers and *then*
>> coordinate these controllers to manage my system.
>
> This is _your_ use case... Other people have first a "task plan" in mind,
> and are then looking for "control" components that can realise parts of
> that plan.
Even with that in mind, the process would be:
- *conceptually* split the task into separate controllers. What you
need to have here is a structure that constrains you enough to
understand what a "good" controller should look like. I thought that
iTaSC what doing that by splitting the VKC, the controller and the
trajectory generators.
- implement each control structure separately (don't know the proper
itasc-speak for that one). In essence: have a running, non-coordinated,
controller that works.
- implement the coordination to realize the whole task
What I need to understand here is a "controller development" guideline,
NOT "how do I coordinate the controllers".
>
> And there are several other work flows out there. Very difficult to make
> good documentation for, in a serial way.
Doing good documentation *is* very hard indeed...
>>>> Smaller issue:
>>>> - the fact that most of the repositories are ROS stacks. Honestly,
>>>> you
>>>> are currently cutting the packages in pieces so small that it stops
>>>> making a lot of sense to me
>>>
>>> I agree with you. Our last refactoring went way too far in
>>> "modularizing"
>>> the whole thing. Our current refactoring will do better; but it is a
>>> _huge_ undertaking, taking much longer than expected.
>> So ... You are currently rewriting / refactoring the whole thing ?
>> Which means what ?
>
>
> - Bringing in the "BRICS Component Model" in a better way. - improved
> solvers
> - also more declarative specifications than the very procedural and
> explicit approach via the VKC model
> - But most importantly, to design one or more DSLs (Domain Specific
> Languages) to make itasc programming easier.
>
>> That we should hold uintil you are finished ?
>
> That depends on what kind of applications you need. There are quite a lot
> of them for which the current itasc is ok, and the new developments might
> be overkill...
Not having a good way to build up controller instances (i.e. WITHOUT
coordinations) in itasc is IMO a killer for me -- but since I am not the
one that is going to use itasc, that might not be a showstopper for
"them". *If* they go for itasc and *if* I can get a proper understanding
of the itasc structure (which I definitely have not), I would most
probably make itasc-specific extensions to rock-roby and orogen to
support their development.
What I understand is that the component structure is not fundamentally
going to change, only the tools around them, right ?
Comments / need for clarifications / help on iTaSC-related subje
On Thu, 25 Oct 2012, Sylvain Joyeux wrote:
> On 10/25/2012 09:43 AM, Herman Bruyninckx wrote:
>>>> I do not agree: designing controllers without taking coordination into
>>>> account has led, time and again, to coordination-behind-the-screens in
>>>> control implementations. We have learned that the hard way ourselves.
>>> Not if you give good guidelines on how to write the controller.
>>
>>
>> No! Because the _real_ problem is that the coordination requires
>> _knowledge_ about the _application_, that should not be put inside the
>> control component.
> Yes. So, again, "good guidelines on how to write a single controller that can
> be reused"
I am curious what _your_ good guidelines would be... Mine are: look at the
whole BCM concept, and apply it.
>>> The issue, as always, is that you need to split the controller components
>>> "properly" so that the controller behaviour can be changed by rewiring /
>>> reconfiguring these components.
>>
>> That motivation is exactly why we have materialized the concerns of
>> Coordination and
>> Configuration into explicit components :-) So, we are back to (my!) square
>> zero :-)
> Since rock and rock-roby follows that design for more than two years now, I
> can't agree more.
I am not surprised :-)
>>> I want *first* to create single-behaviour controllers and *then*
>>> coordinate these controllers to manage my system.
>>
>> This is _your_ use case... Other people have first a "task plan" in mind,
>> and are then looking for "control" components that can realise parts of
>> that plan.
> Even with that in mind, the process would be:
>
> - *conceptually* split the task into separate controllers. What you need to
> have here is a structure that constrains you enough to understand what a
> "good" controller should look like. I thought that iTaSC what doing that by
> splitting the VKC, the controller and the trajectory generators.
It could still do better, in this respect.
> - implement each control structure separately (don't know the proper
> itasc-speak for that one). In essence: have a running, non-coordinated,
> controller that works.
> - implement the coordination to realize the whole task
>
> What I need to understand here is a "controller development" guideline, NOT
> "how do I coordinate the controllers".
There are no control development guidelines, _because_ the current itasc
implementation has only one "controller", in the form of the current
"solver".
Hence, our ongoing efforts to enlarge the choice of solvers, and insights
about which one to use for what purposes. I guess that would come in the
direction of what you are looking after, as "guidelines".
>> And there are several other work flows out there. Very difficult to make
>> good documentation for, in a serial way.
> Doing good documentation *is* very hard indeed...
>>>>> Smaller issue:
>>>>> - the fact that most of the repositories are ROS stacks. Honestly, you
>>>>> are currently cutting the packages in pieces so small that it stops
>>>>> making a lot of sense to me
>>>>
>>>> I agree with you. Our last refactoring went way too far in "modularizing"
>>>> the whole thing. Our current refactoring will do better; but it is a
>>>> _huge_ undertaking, taking much longer than expected.
>>> So ... You are currently rewriting / refactoring the whole thing ? Which
>>> means what ?
>>
>> - Bringing in the "BRICS Component Model" in a better way. - improved
>> solvers
>> - also more declarative specifications than the very procedural and
>> explicit approach via the VKC model
>> - But most importantly, to design one or more DSLs (Domain Specific
>> Languages) to make itasc programming easier.
>>
>>> That we should hold uintil you are finished ?
>>
>> That depends on what kind of applications you need. There are quite a lot
>> of them for which the current itasc is ok, and the new developments might
>> be overkill...
> Not having a good way to build up controller instances (i.e. WITHOUT
> coordinations) in itasc is IMO a killer for me -- but since I am not the one
> that is going to use itasc, that might not be a showstopper for "them". *If*
> they go for itasc and *if* I can get a proper understanding of the itasc
> structure (which I definitely have not), I would most probably make
> itasc-specific extensions to rock-roby and orogen to support their
> development.
>
> What I understand is that the component structure is not fundamentally going
> to change, only the tools around them, right ?
No, the component structure is going to change _dramatically_; at least, if
_I_ have any say in that issue :-)
The reason is the very poor efficiency of the current design with tons of
components, causing too much (conceptual and communication) overhead that
can not be defended in an industrial context. For example, I want to have a
design that can be deployed on FPGAs, because there is no fundamental
reason why we can only use (Orocos/RTT) components in itasc.
> Sylvain Joyeux (Dr.Ing.)
Herman
> Senior Researcher
>
> Space & Security Robotics
> Underwater Robotics
>
> !!! Achtung, neue Telefonnummer!!!
>
> Standort Bremen:
> DFKI GmbH
> Robotics Innovation Center
> Robert-Hooke-Straße 5
> 28359 Bremen, Germany
>
> Phone: +49 (0)421 178-454136
> Fax: +49 (0)421 218-454150
> E-Mail: robotik [..] ...
>
> Weitere Informationen: http://www.dfki.de/robotik
> -----------------------------------------------------------------------
> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
> Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
> Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
> (Vorsitzender) Dr. Walter Olthoff
> Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
> Amtsgericht Kaiserslautern, HRB 2313
> Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
> USt-Id.Nr.: DE 148646973
> Steuernummer: 19/673/0060/3
> -----------------------------------------------------------------------
>
>
--
KU Leuven, Mechanical Engineering, Robotics Research Group
<http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
Vice-President Research euRobotics <http://www.eu-robotics.net>
Open RObot COntrol Software <http://www.orocos.org>
Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>
Comments / need for clarifications / help on iTaSC-related subje
On 10/25/2012 10:06 AM, Herman Bruyninckx wrote:
> On Thu, 25 Oct 2012, Sylvain Joyeux wrote:
>
>> On 10/25/2012 09:43 AM, Herman Bruyninckx wrote:
>>>>> I do not agree: designing controllers without taking coordination into
>>>>> account has led, time and again, to coordination-behind-the-screens in
>>>>> control implementations. We have learned that the hard way ourselves.
>>>> Not if you give good guidelines on how to write the controller.
>>>
>>>
>>> No! Because the _real_ problem is that the coordination requires
>>> _knowledge_ about the _application_, that should not be put inside the
>>> control component.
>> Yes. So, again, "good guidelines on how to write a single controller that can be reused"
>
> I am curious what _your_ good guidelines would be... Mine are: look at the
> whole BCM concept, and apply it.
>
>>>> The issue, as always, is that you need to split the controller components "properly" so that the controller behaviour can be changed by rewiring / reconfiguring these
>>>> components.
>>>
>>> That motivation is exactly why we have materialized the concerns of Coordination and
>>> Configuration into explicit components :-) So, we are back to (my!) square
>>> zero :-)
>> Since rock and rock-roby follows that design for more than two years now, I can't agree more.
>
> I am not surprised :-)
>
>>>> I want *first* to create single-behaviour controllers and *then* coordinate these controllers to manage my system.
>>>
>>> This is _your_ use case... Other people have first a "task plan" in mind,
>>> and are then looking for "control" components that can realise parts of
>>> that plan.
>> Even with that in mind, the process would be:
>>
>> - *conceptually* split the task into separate controllers. What you need to have here is a structure that constrains you enough to understand what a "good" controller
>> should look like. I thought that iTaSC what doing that by splitting the VKC, the controller and the trajectory generators.
>
> It could still do better, in this respect.
>
>> - implement each control structure separately (don't know the proper itasc-speak for that one). In essence: have a running, non-coordinated, controller that works.
>> - implement the coordination to realize the whole task
>>
>> What I need to understand here is a "controller development" guideline, NOT "how do I coordinate the controllers".
>
> There are no control development guidelines, _because_ the current itasc
> implementation has only one "controller", in the form of the current
> "solver".
> Hence, our ongoing efforts to enlarge the choice of solvers, and insights
> about which one to use for what purposes. I guess that would come in the
> direction of what you are looking after, as "guidelines".
>
>>> And there are several other work flows out there. Very difficult to make
>>> good documentation for, in a serial way.
>> Doing good documentation *is* very hard indeed...
>
>>>>>> Smaller issue:
>>>>>> - the fact that most of the repositories are ROS stacks. Honestly, you
>>>>>> are currently cutting the packages in pieces so small that it stops
>>>>>> making a lot of sense to me
>>>>>
>>>>> I agree with you. Our last refactoring went way too far in "modularizing"
>>>>> the whole thing. Our current refactoring will do better; but it is a
>>>>> _huge_ undertaking, taking much longer than expected.
>>>> So ... You are currently rewriting / refactoring the whole thing ? Which means what ?
>>>
>>> - Bringing in the "BRICS Component Model" in a better way. - improved solvers
>>> - also more declarative specifications than the very procedural and
>>> explicit approach via the VKC model
>>> - But most importantly, to design one or more DSLs (Domain Specific
>>> Languages) to make itasc programming easier.
>>>
>>>> That we should hold uintil you are finished ?
>>>
>>> That depends on what kind of applications you need. There are quite a lot
>>> of them for which the current itasc is ok, and the new developments might
>>> be overkill...
>
>> Not having a good way to build up controller instances (i.e. WITHOUT coordinations) in itasc is IMO a killer for me -- but since I am not the one that is going to use
>> itasc, that might not be a showstopper for "them". *If* they go for itasc and *if* I can get a proper understanding of the itasc structure (which I definitely have not),
>> I would most probably make itasc-specific extensions to rock-roby and orogen to support their development.
>>
>> What I understand is that the component structure is not fundamentally going to change, only the tools around them, right ?
>
> No, the component structure is going to change _dramatically_; at least, if
> _I_ have any say in that issue :-)
there is a refactoring on the way right now, that will change component structure in a less dramatical way
and will clean up the highest priority mess
should be out one of these weeks
>
> The reason is the very poor efficiency of the current design with tons of
> components, causing too much (conceptual and communication) overhead that
> can not be defended in an industrial context. For example, I want to have a
> design that can be deployed on FPGAs, because there is no fundamental
> reason why we can only use (Orocos/RTT) components in itasc.
>
>> Sylvain Joyeux (Dr.Ing.)
>
> Herman
>> Senior Researcher
>>
>> Space & Security Robotics
>> Underwater Robotics
>>
>> !!! Achtung, neue Telefonnummer!!!
>>
>> Standort Bremen:
>> DFKI GmbH
>> Robotics Innovation Center
>> Robert-Hooke-Straße 5
>> 28359 Bremen, Germany
>>
>> Phone: +49 (0)421 178-454136
>> Fax: +49 (0)421 218-454150
>> E-Mail: robotik [..] ...
>>
>> Weitere Informationen: http://www.dfki.de/robotik
>> -----------------------------------------------------------------------
>> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
>> Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
>> Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
>> (Vorsitzender) Dr. Walter Olthoff
>> Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
>> Amtsgericht Kaiserslautern, HRB 2313
>> Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
>> USt-Id.Nr.: DE 148646973
>> Steuernummer: 19/673/0060/3
>> -----------------------------------------------------------------------
>>
>>
>
> --
> KU Leuven, Mechanical Engineering, Robotics Research Group
> <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
> Vice-President Research euRobotics <http://www.eu-robotics.net>
> Open RObot COntrol Software <http://www.orocos.org>
> Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>
>
>
Comments / need for clarifications / help on iTaSC-related subje
On 10/25/2012 10:06 AM, Herman Bruyninckx wrote:
> On Thu, 25 Oct 2012, Sylvain Joyeux wrote:
>
>> On 10/25/2012 09:43 AM, Herman Bruyninckx wrote:
>>>>> I do not agree: designing controllers without taking coordination
>>>>> into
>>>>> account has led, time and again, to
>>>>> coordination-behind-the-screens in
>>>>> control implementations. We have learned that the hard way ourselves.
>>>> Not if you give good guidelines on how to write the controller.
>>>
>>>
>>> No! Because the _real_ problem is that the coordination requires
>>> _knowledge_ about the _application_, that should not be put inside the
>>> control component.
>> Yes. So, again, "good guidelines on how to write a single controller
>> that can be reused"
>
> I am curious what _your_ good guidelines would be... Mine are: look at
> the
> whole BCM concept, and apply it.
BCM being ?
>>>> I want *first* to create single-behaviour controllers and *then*
>>>> coordinate these controllers to manage my system.
>>>
>>> This is _your_ use case... Other people have first a "task plan" in
>>> mind,
>>> and are then looking for "control" components that can realise parts of
>>> that plan.
>> Even with that in mind, the process would be:
>>
>> - *conceptually* split the task into separate controllers. What you
>> need to have here is a structure that constrains you enough to
>> understand what a "good" controller should look like. I thought that
>> iTaSC what doing that by splitting the VKC, the controller and the
>> trajectory generators.
>
> It could still do better, in this respect.
It can always do better. The question is: how good does it do it right now.
I have to apologize. Going back to the 'iTasc user guide' on orocos.org,
I actually found out something I missed: section 2. Which is a
one-liner, because it links to the PDF.
>> - implement each control structure separately (don't know the proper
>> itasc-speak for that one). In essence: have a running,
>> non-coordinated, controller that works.
>> - implement the coordination to realize the whole task
>>
>> What I need to understand here is a "controller development"
>> guideline, NOT "how do I coordinate the controllers".
>
> There are no control development guidelines, _because_ the current itasc
> implementation has only one "controller", in the form of the current
> "solver".
> Hence, our ongoing efforts to enlarge the choice of solvers, and insights
> about which one to use for what purposes. I guess that would come in the
> direction of what you are looking after, as "guidelines".
>
> The reason is the very poor efficiency of the current design with tons of
> components, causing too much (conceptual and communication) overhead that
> can not be defended in an industrial context.
???? Why is that so much overhead ? Since you actually have a pretty
rigid computation structure, you could run all components in a single
thread, removing all of the context-switching and all of the
synchronization primitives on the communication path. I thought that
using these computation models was in the "grand scheme of things" at KUL.
> For example, I want to have a
> design that can be deployed on FPGAs, because there is no fundamental
> reason why we can only use (Orocos/RTT) components in itasc.
And I seem to remember that some people on the ML do deploy RTT tasks on
softcores, so ...
Please don't fall into the trap of developping an 'itasc component
implementation' parallel to RTT to reach these goals...
Comments / need for clarifications / help on iTaSC-related subje
On Thu, 25 Oct 2012, Sylvain Joyeux wrote:
> On 10/25/2012 10:06 AM, Herman Bruyninckx wrote:
>> On Thu, 25 Oct 2012, Sylvain Joyeux wrote:
>>
>>> On 10/25/2012 09:43 AM, Herman Bruyninckx wrote:
>>>>>> I do not agree: designing controllers without taking coordination into
>>>>>> account has led, time and again, to coordination-behind-the-screens in
>>>>>> control implementations. We have learned that the hard way ourselves.
>>>>> Not if you give good guidelines on how to write the controller.
>>>>
>>>>
>>>> No! Because the _real_ problem is that the coordination requires
>>>> _knowledge_ about the _application_, that should not be put inside the
>>>> control component.
>>> Yes. So, again, "good guidelines on how to write a single controller that
>>> can be reused"
>>
>> I am curious what _your_ good guidelines would be... Mine are: look at the
>> whole BCM concept, and apply it.
> BCM being ?
BRICS Component Model. (Not fully finished or published, yet.)
>>>>> I want *first* to create single-behaviour controllers and *then*
>>>>> coordinate these controllers to manage my system.
>>>>
>>>> This is _your_ use case... Other people have first a "task plan" in mind,
>>>> and are then looking for "control" components that can realise parts of
>>>> that plan.
>>> Even with that in mind, the process would be:
>>>
>>> - *conceptually* split the task into separate controllers. What you need
>>> to have here is a structure that constrains you enough to understand what
>>> a "good" controller should look like. I thought that iTaSC what doing that
>>> by splitting the VKC, the controller and the trajectory generators.
>>
>> It could still do better, in this respect.
> It can always do better. The question is: how good does it do it right now.
>
> I have to apologize. Going back to the 'iTasc user guide' on orocos.org, I
> actually found out something I missed: section 2. Which is a one-liner,
> because it links to the PDF.
>>> - implement each control structure separately (don't know the proper
>>> itasc-speak for that one). In essence: have a running, non-coordinated,
>>> controller that works.
>>> - implement the coordination to realize the whole task
>>>
>>> What I need to understand here is a "controller development" guideline,
>>> NOT "how do I coordinate the controllers".
>>
>> There are no control development guidelines, _because_ the current itasc
>> implementation has only one "controller", in the form of the current
>> "solver".
>> Hence, our ongoing efforts to enlarge the choice of solvers, and insights
>> about which one to use for what purposes. I guess that would come in the
>> direction of what you are looking after, as "guidelines".
>
>>
>> The reason is the very poor efficiency of the current design with tons of
>> components, causing too much (conceptual and communication) overhead that
>> can not be defended in an industrial context.
> ???? Why is that so much overhead ? Since you actually have a pretty rigid
> computation structure, you could run all components in a single thread,
> removing all of the context-switching and all of the synchronization
> primitives on the communication path. I thought that using these computation
> models was in the "grand scheme of things" at KUL.
>
>> For example, I want to have a
>> design that can be deployed on FPGAs, because there is no fundamental
>> reason why we can only use (Orocos/RTT) components in itasc.
> And I seem to remember that some people on the ML do deploy RTT tasks on
> softcores, so ...
One or our students is looking into that, but I have not seen any results
yet.
> Please don't fall into the trap of developping an 'itasc component
> implementation' parallel to RTT to reach these goals...
It is not a trap, it is the way to go! Because the core itasc is a
constrained optimization _computation_, so it doesn't _need_ components to
be realised. Many Orocos/ROS users fall in the opposite trap: they think
nothing can/should be done without TaskContexts/Nodes :-)
> Sylvain Joyeux (Dr.Ing.)
Herman
> Senior Researcher
>
> Space & Security Robotics
> Underwater Robotics
>
> !!! Achtung, neue Telefonnummer!!!
>
> Standort Bremen:
> DFKI GmbH
> Robotics Innovation Center
> Robert-Hooke-Straße 5
> 28359 Bremen, Germany
>
> Phone: +49 (0)421 178-454136
> Fax: +49 (0)421 218-454150
> E-Mail: robotik [..] ...
>
> Weitere Informationen: http://www.dfki.de/robotik
> -----------------------------------------------------------------------
> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
> Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
> Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
> (Vorsitzender) Dr. Walter Olthoff
> Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
> Amtsgericht Kaiserslautern, HRB 2313
> Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
> USt-Id.Nr.: DE 148646973
> Steuernummer: 19/673/0060/3
> -----------------------------------------------------------------------
>
>
--
KU Leuven, Mechanical Engineering, Robotics Research Group
<http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
Vice-President Research euRobotics <http://www.eu-robotics.net>
Open RObot COntrol Software <http://www.orocos.org>
Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>
Comments / need for clarifications / help on iTaSC-related subje
On 10/25/2012 10:24 AM, Herman Bruyninckx wrote:
>>> I am curious what _your_ good guidelines would be... Mine are: look
>>> at the
>>> whole BCM concept, and apply it.
>> BCM being ?
>
> BRICS Component Model. (Not fully finished or published, yet.)
I can't comment on the BRICS component model since ... you know ... I
have no information at all about it.
Component models are (usually) useless for this particular purpose. They
say what a component looks like, not what it does -- or more accurately
how it should be doing what it does -- because that is
application-dependent. One can give very high-level guidelines, but
that's not enough. I am currently writing a paper about these issues,
but the only thing we will manage to do (I believe) is giving a "hint"
on what guidelines "good" components should follow. Hardly a
bullet-point list of things that should be / should not be done.
Comments / need for clarifications / help on iTaSC-related subje
On Thu, 25 Oct 2012, Sylvain Joyeux wrote:
> On 10/25/2012 10:24 AM, Herman Bruyninckx wrote:
>>>> I am curious what _your_ good guidelines would be... Mine are: look at
>>>> the
>>>> whole BCM concept, and apply it.
>>> BCM being ?
>>
>> BRICS Component Model. (Not fully finished or published, yet.)
> I can't comment on the BRICS component model since ... you know ... I have no
> information at all about it.
You do :-) In the sense that important bits and pieces have been
explained/introduced already on this mailinglist (5Cs, deployment phases,
metamodelling), as well as on some workhops that you attended.
> Component models are (usually) useless for this particular purpose.
They are not... Or rather: software framework component models are useless,
but _computational_ component models (which are a different animal!) are.
> They say
> what a component looks like, not what it does -- or more accurately how it
> should be doing what it does -- because that is application-dependent.
The BCM model explicitly introduces the 5Cs for the reason you mention: to
model (to some extent) the commonalities in the _behaviour_ of components
that _do_ something. (Computation, Configuration, Communication,
Coordination) as well as in their structural interactions (Composition).
> One
> can give very high-level guidelines, but that's not enough.
By definition. But I am _so_ surprised by how _powerful_ these little but
high-level guidelines can be; _exactly because_ they apply to so broad
categories of use cases.
> I am currently
> writing a paper about these issues, but the only thing we will manage to do
> (I believe) is giving a "hint" on what guidelines "good" components should
> follow. Hardly a bullet-point list of things that should be / should not be
> done.
I agree. But such list of hints can grow incrementally over time. I am
working on exactly such a document (as a BRICS deliverable) for some years
now, and it will contain several dozens of such "hints". All together, I
really think they provide a tsunami shift in the minds of robot developers
:-)
> Sylvain Joyeux (Dr.Ing.)
Herman
> Senior Researcher
>
> Space & Security Robotics
> Underwater Robotics
>
> !!! Achtung, neue Telefonnummer!!!
>
> Standort Bremen:
> DFKI GmbH
> Robotics Innovation Center
> Robert-Hooke-Straße 5
> 28359 Bremen, Germany
>
> Phone: +49 (0)421 178-454136
> Fax: +49 (0)421 218-454150
> E-Mail: robotik [..] ...
>
> Weitere Informationen: http://www.dfki.de/robotik
> -----------------------------------------------------------------------
> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
> Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
> Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
> (Vorsitzender) Dr. Walter Olthoff
> Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
> Amtsgericht Kaiserslautern, HRB 2313
> Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
> USt-Id.Nr.: DE 148646973
> Steuernummer: 19/673/0060/3
> -----------------------------------------------------------------------
>
>
--
KU Leuven, Mechanical Engineering, Robotics Research Group
<http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
Vice-President Research euRobotics <http://www.eu-robotics.net>
Open RObot COntrol Software <http://www.orocos.org>
Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>