Hello everyone,
I have a list of random questions to submit to you:
- Is it possible to use the OCL::Reporter to do RT monitoring along with
the rxplot tool from ROS ? I know it's doable to use KST but rxplot would
be a big plus.
- When would you use services instead of Orocos components? What's the
philosophical view behind them?
- Is there a way to group several Orocos components inside a
"super-component"? Is it achievable with activities (the goal is to offer
several perspectives according to the users)? How to avoid synchronisation
problems between components and super-components? (is it necessary to
define a clock component?)
- Lastly, what is the best way to include modes? Say you have an OC with
one input port that can be a velocity or position order. You know it's a
velocity or position order according to a "mode" property that you can
change on-the-fly. Is this a legitimate process? If so, how do I make sure
that when a mode is switched the buffer can be emptied?
Many thanks in advance
Flavian
A few general questions on monitoring, services, and orocos comp
2013/7/9 Flavian Hautbois <f [dot] hautbois [..] ...>
> Hello everyone,
>
> I have a list of random questions to submit to you:
>
> - Is it possible to use the OCL::Reporter to do RT monitoring along with
> the rxplot tool from ROS ? I know it's doable to use KST but rxplot would
> be a big plus.
>
> - When would you use services instead of Orocos components? What's the
> philosophical view behind them?
>
> - Is there a way to group several Orocos components inside a
> "super-component"? Is it achievable with activities (the goal is to offer
> several perspectives according to the users)? How to avoid synchronisation
> problems between components and super-components? (is it necessary to
> define a clock component?)
>
>
There is no formal composition of components (I think it is what you ask
for).
You can add some structure in your code to artificially go in this way like
deploymeny,configuration, run time modes, ... As for scheduling you have
the Master/Slave activity that allows you to create schedulers.
I'll let wise people here to precise this related question : "Should
composition be a property of the framework or a property of the tooling ?"
> - Lastly, what is the best way to include modes? Say you have an OC with
> one input port that can be a velocity or position order. You know it's a
> velocity or position order according to a "mode" property that you can
> change on-the-fly. Is this a legitimate process? If so, how do I make sure
> that when a mode is switched the buffer can be emptied?
>
> Many thanks in advance
>
> Flavian
>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
>
A few general questions on monitoring, services, and orocos comp
On 07/09/2013 09:08 AM, Flavian Hautbois wrote:
> - Lastly, what is the best way to include modes? Say you have an OC
> with one input port that can be a velocity or position order. You know
> it's a velocity or position order according to a "mode" property that
> you can change on-the-fly. Is this a legitimate process? If so, how do
> I make sure that when a mode is switched the buffer can be emptied?
>
The answer is "it depends".
First of all, changing RTT properties dynamically (while the component
is running) is NOT supported by RTT. Properties are NOT thread safe !.
Rock/orogen has now support for that by generating setter operations.
For the "how to represent the modes", it actually depends on what you
really want to achieve. For the controller example, we (Rock developers)
decided to move out of having modes and start using a structure instead
that contains separate modes (position, velocity, ...)
http://gitorious.org/rock-base/types/blobs/master/base/JointState.hpp
The rationale being that some controllers can deal with having e.g. both
a position and velocity target.
The fact that a certain target is or is not set is done by using NaNs
(which are covered by Rock's base::unset<T>() and base::isUnset(value),
http://gitorious.org/rock-base/types/blobs/master/base/Float.hpp
http://rock.opendfki.de/wiki/WikiStart/Standards/RG3
A few general questions on monitoring, services, and orocos comp
2013/7/9 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
> On 07/09/2013 09:08 AM, Flavian Hautbois wrote:
>
> - Lastly, what is the best way to include modes? Say you have an OC with
> one input port that can be a velocity or position order. You know it's a
> velocity or position order according to a "mode" property that you can
> change on-the-fly. Is this a legitimate process? If so, how do I make sure
> that when a mode is switched the buffer can be emptied?
>
> The answer is "it depends".
>
> First of all, changing RTT properties dynamically (while the component is
> running) is NOT supported by RTT. Properties are NOT thread safe !.
> Rock/orogen has now support for that by generating setter operations.
>
> For the "how to represent the modes", it actually depends on what you
> really want to achieve. For the controller example, we (Rock developers)
> decided to move out of having modes and start using a structure instead
> that contains separate modes (position, velocity, ...)
>
> http://gitorious.org/rock-base/types/blobs/master/base/JointState.hpp
>
> The rationale being that some controllers can deal with having e.g. both a
> position and velocity target.
>
> The fact that a certain target is or is not set is done by using NaNs
> (which are covered by Rock's base::unset<T>() and base::isUnset(value),
> http://gitorious.org/rock-base/types/blobs/master/base/Float.hpp
> http://rock.opendfki.de/wiki/WikiStart/Standards/RG3
>
This structure is nice and elegant. I am using ROS + Orocos, but I'm not
sure I could plug Rock on top of that, could I? (based on your website
content: http://rock-robotics.org/stable/index.html).
A few general questions on monitoring, services, and orocos comp
On 07/10/2013 09:23 AM, Flavian Hautbois wrote:
> This structure is nice and elegant. I am using ROS + Orocos, but I'm
> not sure I could plug Rock on top of that, could I? (based on your
> website content: http://rock-robotics.org/stable/index.html).
There is a Rock/ROS bridge that is currently available on 'next'
http://rock-robotics.org/next/documentation/ros/index.html
However, it got only limited testing so far, so be ready to have some
rough edges
in addition, Rock components are RTT components, so you can compile them
in Rock and use them as "pure" RTT components.
Finally, base/types is independent of the Rock toolchain, as most of the
algorithms developed in Rock (we have a hard policy that functionality
should be framework-independent, using oroGen only as an integration
layer). So is some JointState-related functionality
(control/motor_controller, control/joint_dispatcher packages).
http://rock-robotics.org/next/documentation/packages/outside_of_rock.html
A few general questions on monitoring, services, and orocos comp
On Tue, Jul 9, 2013 at 9:08 AM, Flavian Hautbois <f [dot] hautbois [..] ...>wrote:
> Hello everyone,
>
> I have a list of random questions to submit to you:
>
> - Is it possible to use the OCL::Reporter to do RT monitoring along with
> the rxplot tool from ROS ? I know it's doable to use KST but rxplot would
> be a big plus.
>
Ros tools like rxplot/rqtplot need a topic with the data to plot. So,
regardless of whether you are using the reporter or not, if you stream the
contents of a port to a ros topic (the payload must be a ros message), you
should be good to go.
>
> - When would you use services instead of Orocos components?
>
A service is like a TaskContext without an Activity. So if it does not
make sense to have an activity around, use a service.
What's the philosophical view behind them?
>
I use services as a tool for aggregating Orocos interfaces (operations,
properties, ports) representing an meaningful application-specific
interface. Instead of querying a peer for a bunch of operations, properties
and ports upon configuration, you just require a service, and if it's ready
off you go. Services help to reduce code duplication within- and
across-components.
>
> - Is there a way to group several Orocos components inside a
> "super-component"? Is it achievable with activities (the goal is to offer
> several perspectives according to the users)? How to avoid synchronisation
> problems between components and super-components? (is it necessary to
> define a clock component?)
>
This has been discussed a few times in the mailing list, but I don't know
if there is anything in the works.
>
> - Lastly, what is the best way to include modes? Say you have an OC with
> one input port that can be a velocity or position order. You know it's a
> velocity or position order according to a "mode" property that you can
> change on-the-fly. Is this a legitimate process? If so, how do I make sure
> that when a mode is switched the buffer can be emptied?
>
RTT allows it, but if you ask me, you're looking for trouble. I would use
separate ports for semantically different data like position and velocity
commands. Changing the mode would make the component consume data from one
port or the other. You might have to do some buffer clearing when switching
to remove old commands.
Cheers,
Adolfo
>
> Many thanks in advance
>
> Flavian
>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
>
A few general questions on monitoring, services, and orocos comp
Thanks for the quick response
2013/7/9 Adolfo Rodríguez Tsouroukdissian <adolfo [dot] rodriguez [..] ...
>
>
>
>
> On Tue, Jul 9, 2013 at 9:08 AM, Flavian Hautbois <f [dot] hautbois [..] ...>wrote:
>
>> Hello everyone,
>>
>> I have a list of random questions to submit to you:
>>
>> - Is it possible to use the OCL::Reporter to do RT monitoring along with
>> the rxplot tool from ROS ? I know it's doable to use KST but rxplot would
>> be a big plus.
>>
>
> Ros tools like rxplot/rqtplot need a topic with the data to plot. So,
> regardless of whether you are using the reporter or not, if you stream the
> contents of a port to a ros topic (the payload must be a ros message), you
> should be good to go.
>
>
>>
>> - When would you use services instead of Orocos components?
>>
>
> A service is like a TaskContext without an Activity. So if it does not
> make sense to have an activity around, use a service.
>
> What's the philosophical view behind them?
>>
>
> I use services as a tool for aggregating Orocos interfaces (operations,
> properties, ports) representing an meaningful application-specific
> interface.
>
Do you have a concrete example for that?
> Instead of querying a peer for a bunch of operations, properties and ports
> upon configuration, you just require a service, and if it's ready off you
> go. Services help to reduce code duplication within- and across-components.
>
>
>>
>> - Is there a way to group several Orocos components inside a
>> "super-component"? Is it achievable with activities (the goal is to offer
>> several perspectives according to the users)? How to avoid synchronisation
>> problems between components and super-components? (is it necessary to
>> define a clock component?)
>>
>
> This has been discussed a few times in the mailing list, but I don't know
> if there is anything in the works.
>
>
>>
>> - Lastly, what is the best way to include modes? Say you have an OC with
>> one input port that can be a velocity or position order. You know it's a
>> velocity or position order according to a "mode" property that you can
>> change on-the-fly. Is this a legitimate process? If so, how do I make sure
>> that when a mode is switched the buffer can be emptied?
>>
>
> RTT allows it, but if you ask me, you're looking for trouble. I would use
> separate ports for semantically different data like position and velocity
> commands. Changing the mode would make the component consume data from one
> port or the other. You might have to do some buffer clearing when switching
> to remove old commands.
>
If possible I would like to avoid using too many ports... From a user point
of view it's easier to modify a variable than to rewire a port, isn't it?
>
> Cheers,
>
> Adolfo
>
>
>>
>> Many thanks in advance
>>
>> Flavian
>>
>> --
>> Orocos-Users mailing list
>> Orocos-Users [..] ...
>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>>
>>
>
>
> --
> Adolfo Rodríguez Tsouroukdissian
> Senior robotics engineer
> adolfo [dot] rodriguez [..] ...
> http://www.pal-robotics.com
>
> PAL ROBOTICS S.L
> c/ Pujades 77-79, 4º4ª
> 08005 Barcelona, Spain.
> Tel. +34.93.414.53.47
> Fax.+34.93.209.11.09
> Skype: adolfo.pal-robotics
> Facebook <http://www.facebook.com/palrobotics1> - Twitter<http://twitter.com/#%21/palrobotics>- PAL
> Robotics YouTube Channel <http://www.youtube.com/user/PALRobotics>
>
> AVISO DE CONFIDENCIALIDAD: Este mensaje y sus documentos adjuntos, pueden
> contener información privilegiada y/o confidencial que está dirigida
> exclusivamente a su destinatario. Si usted recibe este mensaje y no es el
> destinatario indicado, o el empleado encargado de su entrega a dicha
> persona, por favor, notifíquelo inmediatamente y remita el mensaje original
> a la dirección de correo electrónico indicada. Cualquier copia, uso o
> distribución no autorizados de esta comunicación queda estrictamente
> prohibida.
>
> CONFIDENTIALITY NOTICE: This e-mail and the accompanying document(s) may
> contain confidential information which is privileged and intended only for
> the individual or entity to whom they are addressed. If you are not the
> intended recipient, you are hereby notified that any disclosure, copying,
> distribution or use of this e-mail and/or accompanying document(s) is
> strictly prohibited. If you have received this e-mail in error, please
> immediately notify the sender at the above e-mail address.
>
A few general questions on monitoring, services, and orocos comp
On Tue, Jul 9, 2013 at 10:03 AM, Flavian Hautbois <f [dot] hautbois [..] ...>wrote:
> Thanks for the quick response
>
>
> 2013/7/9 Adolfo Rodríguez Tsouroukdissian <
> adolfo [dot] rodriguez [..] ...>
>
>>
>>
>>
>> On Tue, Jul 9, 2013 at 9:08 AM, Flavian Hautbois <f [dot] hautbois [..] ...>wrote:
>>
>>> Hello everyone,
>>>
>>> I have a list of random questions to submit to you:
>>>
>>> - Is it possible to use the OCL::Reporter to do RT monitoring along with
>>> the rxplot tool from ROS ? I know it's doable to use KST but rxplot would
>>> be a big plus.
>>>
>>
>> Ros tools like rxplot/rqtplot need a topic with the data to plot. So,
>> regardless of whether you are using the reporter or not, if you stream the
>> contents of a port to a ros topic (the payload must be a ros message), you
>> should be good to go.
>>
>>
>>>
>>> - When would you use services instead of Orocos components?
>>>
>>
>> A service is like a TaskContext without an Activity. So if it does not
>> make sense to have an activity around, use a service.
>>
>
>> What's the philosophical view behind them?
>>>
>>
>> I use services as a tool for aggregating Orocos interfaces (operations,
>> properties, ports) representing an meaningful application-specific
>> interface.
>>
>
> Do you have a concrete example for that?
>
RTT has!. The RTT::SriptingService [1] provides a bunch of operations all
related to scripting. The RTT::Scripting class [2] is a specialization of
the RTT::ServiceRequester that takes care of setting up all
scripting-related operation callers. You would use [2] in a component that
needs scripting.
[1]
http://www.orocos.org/stable/documentation/rtt/v2.x/api/html/classRTT_1_...
[2]
http://www.orocos.org/stable/documentation/rtt/v2.x/api/html/classRTT_1_...
>
>> Instead of querying a peer for a bunch of operations, properties and
>> ports upon configuration, you just require a service, and if it's ready off
>> you go. Services help to reduce code duplication within- and
>> across-components.
>>
>
>>
>>>
>>> - Is there a way to group several Orocos components inside a
>>> "super-component"? Is it achievable with activities (the goal is to offer
>>> several perspectives according to the users)? How to avoid synchronisation
>>> problems between components and super-components? (is it necessary to
>>> define a clock component?)
>>>
>>
>> This has been discussed a few times in the mailing list, but I don't know
>> if there is anything in the works.
>>
>>
>>>
>>> - Lastly, what is the best way to include modes? Say you have an OC with
>>> one input port that can be a velocity or position order. You know it's a
>>> velocity or position order according to a "mode" property that you can
>>> change on-the-fly. Is this a legitimate process? If so, how do I make sure
>>> that when a mode is switched the buffer can be emptied?
>>>
>>
>> RTT allows it, but if you ask me, you're looking for trouble. I would use
>> separate ports for semantically different data like position and velocity
>> commands. Changing the mode would make the component consume data from one
>> port or the other. You might have to do some buffer clearing when switching
>> to remove old commands.
>>
>
>
> If possible I would like to avoid using too many ports...
>
One extra port is not too many ports.
> From a user point of view it's easier to modify a variable than to rewire
> a port, isn't it?
>
Users like me like the principle of least surprise, and easier does not
necessarily mean better. In the single-port approach it's also easier to
make a mistake like forgetting to change the mode and start sending
different types of commands. Very bad things can happen if you send
positions and the controller is expecting velocities. OTOH, if you have two
ports and start sending commands to a port that is not being listened to,
then nothing will happen, which is just fine. No surprises.
This is just an opinion, choose what's best for your application and its
users.
Adolfo.
>
>
>>
>> Cheers,
>>
>> Adolfo
>>
>>
>>>
>>> Many thanks in advance
>>>
>>> Flavian
>>>
>>> --
>>> Orocos-Users mailing list
>>> Orocos-Users [..] ...
>>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>>>
>>>
>>
>>
>> --
>> Adolfo Rodríguez Tsouroukdissian
>> Senior robotics engineer
>> adolfo [dot] rodriguez [..] ...
>> http://www.pal-robotics.com
>>
>> PAL ROBOTICS S.L
>> c/ Pujades 77-79, 4º4ª
>> 08005 Barcelona, Spain.
>> Tel. +34.93.414.53.47
>> Fax.+34.93.209.11.09
>> Skype: adolfo.pal-robotics
>> Facebook <http://www.facebook.com/palrobotics1> - Twitter<http://twitter.com/#%21/palrobotics>- PAL
>> Robotics YouTube Channel <http://www.youtube.com/user/PALRobotics>
>>
>> AVISO DE CONFIDENCIALIDAD: Este mensaje y sus documentos adjuntos, pueden
>> contener información privilegiada y/o confidencial que está dirigida
>> exclusivamente a su destinatario. Si usted recibe este mensaje y no es el
>> destinatario indicado, o el empleado encargado de su entrega a dicha
>> persona, por favor, notifíquelo inmediatamente y remita el mensaje original
>> a la dirección de correo electrónico indicada. Cualquier copia, uso o
>> distribución no autorizados de esta comunicación queda estrictamente
>> prohibida.
>>
>> CONFIDENTIALITY NOTICE: This e-mail and the accompanying document(s) may
>> contain confidential information which is privileged and intended only for
>> the individual or entity to whom they are addressed. If you are not the
>> intended recipient, you are hereby notified that any disclosure, copying,
>> distribution or use of this e-mail and/or accompanying document(s) is
>> strictly prohibited. If you have received this e-mail in error, please
>> immediately notify the sender at the above e-mail address.
>>
>
>
>
> --
> F. Hautbois
>