Hi,
I have read a lot of papers, (including the RAM from march 09) about software
components for robotics. In general, many people of the robotics community
agrees about to develop software components for robotics.
In this list, we have talked (written) about the communication in rt of
components, or not rt, and if the allocation of memory, etc. Projects like
Player, ROS and Orocos are made with the concept in mind of
little programs (components) that communicated each other using some
transport mechanism. Also, they agree that developing using this methodology
is a very good option specially in the robotics field.
However, one question that come in mind to me is which are the needed
components or which type of components fit better for example to an
industrial robot manipulator of which one for unmanned vehicle, or to
decompose the robotic problem in which components,
A would like to ask your opinion about it, because, I think that it's
important discuss about how to implement components, which transport
mechanism is the better, but I would like to know is someone of you have a
clear idea in a robotic system which are the most appropriate components, or
if there's some literature in this area, because I have not found any
reference about it.
Thanks in advance,
Leo
Software components for robotics
2009/9/24 Leopold Palomo-Avellaneda <leopold [dot] palomo [..] ...>:
> However, one question that come in mind to me is which are the needed
> components or which type of components fit better for example to an
> industrial robot manipulator of which one for unmanned vehicle, or to
> decompose the robotic problem in which components,
just like any design, it's pretty arbitrary and at best guided by some
rules of thumb (name it design patterns). We're doing each time the
requirements->functional decomposition->definition of
interfaces->implementation thing (iteratively). I believe people
regret more their choice of middleware / component model than their
choice of component granularity and decomposition.
Peter
Software components for robotics
A Dijous 01 Octubre 2009, Peter Soetens va escriure:
> 2009/9/24 Leopold Palomo-Avellaneda <leopold [dot] palomo [..] ...>:
> > However, one question that come in mind to me is which are the needed
> > components or which type of components fit better for example to an
> > industrial robot manipulator of which one for unmanned vehicle, or to
> > decompose the robotic problem in which components,
>
> just like any design, it's pretty arbitrary and at best guided by some
> rules of thumb (name it design patterns). We're doing each time the
> requirements->functional decomposition->definition of
> interfaces->implementation thing (iteratively). I believe people
> regret more their choice of middleware / component model than their
> choice of component granularity and decomposition.
>
> Peter
mmm,
are you saying that the people complain more about which middleware-components
have chosen than the component/granularity have designed?
Because, under my "theoretical" point the correct path would be to design your
models and after chose/implement your middleware/component. I know that the
reality is another .... I don't remember if I took the red pill or the blue
pill ....
Regards,
Leo
Software components for robotics
On Thu, Oct 1, 2009 at 14:26, Leopold Palomo-Avellaneda
<leopold [dot] palomo [..] ...> wrote:
> A Dijous 01 Octubre 2009, Peter Soetens va escriure:
>> 2009/9/24 Leopold Palomo-Avellaneda <leopold [dot] palomo [..] ...>:
>> > However, one question that come in mind to me is which are the needed
>> > components or which type of components fit better for example to an
>> > industrial robot manipulator of which one for unmanned vehicle, or to
>> > decompose the robotic problem in which components,
>>
>> just like any design, it's pretty arbitrary and at best guided by some
>> rules of thumb (name it design patterns). We're doing each time the
>> requirements->functional decomposition->definition of
>> interfaces->implementation thing (iteratively). I believe people
>> regret more their choice of middleware / component model than their
>> choice of component granularity and decomposition.
>>
>> Peter
>
>
> mmm,
>
> are you saying that the people complain more about which middleware-components
> have chosen than the component/granularity have designed?
You'd know that if you had walked that path :-)
>
> Because, under my "theoretical" point the correct path would be to design your
> models and after chose/implement your middleware/component. I know that the
> reality is another .... I don't remember if I took the red pill or the blue
> pill ....
The middleware has a direct impact on how you need to implement
something and how easy it is to connect and test distributed stuff.
It's what you 'feel' every day and if it feels bad, you'll soon start
complaining.
Peter
Software components for robotics
On Thu, Oct 1, 2009 at 8:26 AM, Leopold Palomo-Avellaneda
<leopold [dot] palomo [..] ...> wrote:
> A Dijous 01 Octubre 2009, Peter Soetens va escriure:
>> 2009/9/24 Leopold Palomo-Avellaneda <leopold [dot] palomo [..] ...>:
>> > However, one question that come in mind to me is which are the needed
>> > components or which type of components fit better for example to an
>> > industrial robot manipulator of which one for unmanned vehicle, or to
>> > decompose the robotic problem in which components,
>>
>> just like any design, it's pretty arbitrary and at best guided by some
>> rules of thumb (name it design patterns). We're doing each time the
>> requirements->functional decomposition->definition of
>> interfaces->implementation thing (iteratively). I believe people
>> regret more their choice of middleware / component model than their
>> choice of component granularity and decomposition.
>>
>> Peter
>
>
> mmm,
>
> are you saying that the people complain more about which middleware-components
> have chosen than the component/granularity have designed?
>
> Because, under my "theoretical" point the correct path would be to design your
> models and after chose/implement your middleware/component. I know that the
> reality is another .... I don't remember if I took the red pill or the blue
> pill ....
>
> Regards,
>
> Leo
Seems like we speak of components in a generic way and not as
interfaces that may be part of an API and or describe recurrent
patterns throughout different component implementations. Are there any
defined component patterns that recur during most implementations? Are
there any interfaces defined for generic components? Is there a
framework for arbitrary parties to develop components that can be
shared?
Software components for robotics
On Oct 1, 2009, at 05:24 , Peter Soetens wrote:
> 2009/9/24 Leopold Palomo-Avellaneda <leopold [dot] palomo [..] ...>:
>> However, one question that come in mind to me is which are the needed
>> components or which type of components fit better for example to an
>> industrial robot manipulator of which one for unmanned vehicle, or to
>> decompose the robotic problem in which components,
>
> just like any design, it's pretty arbitrary and at best guided by some
> rules of thumb (name it design patterns). We're doing each time the
> requirements->functional decomposition->definition of
> interfaces->implementation thing (iteratively). I believe people
> regret more their choice of middleware / component model than their
> choice of component granularity and decomposition.
Agreed. Changing components later on, either by separating one into
many, or coalescing many into one, etc., is far easier than fighting
with a non-cooperative middleware.
Stephen
Software components for robotics
On Thu, 24 Sep 2009, Leopold Palomo-Avellaneda wrote:
> I have read a lot of papers, (including the RAM from march 09) about software
> components for robotics. In general, many people of the robotics community
> agrees about to develop software components for robotics.
>
> In this list, we have talked (written) about the communication in rt of
> components, or not rt, and if the allocation of memory, etc. Projects like
> Player, ROS and Orocos are made with the concept in mind of
> little programs (components) that communicated each other using some
> transport mechanism. Also, they agree that developing using this methodology
> is a very good option specially in the robotics field.
>
> However, one question that come in mind to me is which are the needed
> components or which type of components fit better for example to an
> industrial robot manipulator of which one for unmanned vehicle, or to
> decompose the robotic problem in which components,
>
> A would like to ask your opinion about it, because, I think that it's
> important discuss about how to implement components, which transport
> mechanism is the better, but I would like to know is someone of you have a
> clear idea in a robotic system which are the most appropriate components, or
> if there's some literature in this area, because I have not found any
> reference about it.
>
My opinion in this matter is that there will never exist a list of "best
components". And the reason is that, typically, each specific application
must make use of its own specific set of resources, and will have its own
specific set of system objectives, and specific design trade-offs...
Herman