User Survey: Deployment Tool Used

Hi

I would appreciate if you could reply to this email stating which
deployment toolS you use:

1) XML
2) Orocos Script
3) Lua
4) Rock
5) Other

Thank you in advance

-H

Results of User Survey: Deployment Tool Used

Hello

These are the results of the survey as of 26.2.2013

The total recipents on the orocos-users list is 215.

We had 19 responces which means 9% of people on the list responded.

Following you will see the results. Please be aware that combination of
usage (eg ROS launch + Lua) where counted as one instance in each tool.

x = current use
0 = future use
u = unknown number

No totals are included. We provided a rudimentary bar graph:

Respondendts:
xxx xxx xxx xxx xxx xxx x

1) XML
xxxxxxxx

2) Orocos Script
xxxxxxxxxxxxx

3) Lua
oooo
xxxxxxxxxxxx

4) Rock
u - if you use Rock you don´t use the others?

5) Other

ROS luanch:
xxxx

ORO_main():
x

-H

Re: User Survey: Deployment Tool Used

We are currently using ops file for deployment.

But since supervision is a hassle, I just started on the implementation of Lua.

rFSM seems promising but I haven't found the right example yet which allows us to monitor all components and restart a set of components if anything fails.

Regards,

Tim

User Survey: Deployment Tool Used

2) Orocos scripts only, currently.

May upgrade to lua soon if it is well supported.

On Mon, Feb 18, 2013 at 1:28 PM, Hugo A Garcia <hugo [dot] a [dot] garcia [..] ...> wrote:
> Hi
>
> I would appreciate if you could reply to this email stating which deployment
> toolS you use:
>
> 1) XML
> 2) Orocos Script
> 3) Lua
> 4) Rock
> 5) Other
>
> Thank you in advance
>
> -H
>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>

User Survey: Deployment Tool

1) Orocos Script
2) Lua

cheers

Nic

User Survey: Deployment Tool Used

On Feb 18, 2013, at 6:28 AM, Hugo A Garcia <hugo [dot] a [dot] garcia [..] ...> wrote:

> Hi
>
> I would appreciate if you could reply to this email stating which deployment toolS you use:
>
> 1) XML
> 2) Orocos Script
> 3) Lua
> 4) Rock
> 5) Other
>
> Thank you in advance
>
> -H

Couple of questions about connecting components within ROS

Dear all,
I'm a novice of OROCOS. I'm using it mainly to achieve real-time control.

I've couple of questions:
1) I have two components which have to communicate. Let's say:
componentA --[outPortA]-----------<msg>--------------[inPortB]-->componentB
How should I define the communication between these components? I was
thinking of:

A) create two different .ops files which i will run as two different ros
nodes and make them communicate by ros messages. However, will I achieve
real time communication?

B) create one .ops file to launch both components within the same OROCOS
process/ROS node and make them communicate within the process.

I would rather use the A solution, but I need real-time communication.

2) can I use .xml files instead of .ops file using OROCOS within ROS...
I always have errors..

Thanks a lot!
Edoardo

Couple of questions about connecting components within ROS

2013/2/19 Edoardo Lopez <e [dot] lopez [..] ...>:
> Dear all,
> I'm a novice of OROCOS. I'm using it mainly to achieve real-time control.
>

You have to precise what you mean by real-time on this ML as people
are using Orocos for a wide range of "real time requirement".

> I've couple of questions:
> 1) I have two components which have to communicate. Let's say:
> componentA --[outPortA]-----------<msg>--------------[inPortB]-->componentB
> How should I define the communication between these components? I was
> thinking of:

Depends where you puts you components in. Are they in the same process or not ?
You don't need Ros messages to communicate between 2 pure Orocos
components. And I'll go further, you shoudn't if they are in the same
process. You can use the "ros msg" communication if your 2 components
are in 2 different process. But you have other ways to do that in
Orocos (Corba, Message queues). It depends if you need (hard ?) real
time communication between your components.

>
> A) create two different .ops files which i will run as two different ros
> nodes and make them communicate by ros messages. However, will I achieve
> real time communication?

I'm not an expert of this, but I'm quite sure that you loose RT as
soon as you use Ros communication.
If you need RT comm between your components, it is quite sure you will
put them in the them process and use Orocos communication.

>
> B) create one .ops file to launch both components within the same OROCOS
> process/ROS node and make them communicate within the process.
>
> I would rather use the A solution, but I need real-time communication.
>
>
> 2) can I use .xml files instead of .ops file using OROCOS within ROS...
> I always have errors..
>

What you may have missed is that Orocos is a standalone framework.
Many people here have Orocos working without ROS. Some people, like
me, are using Orocos for low level stuff (hardware interfacing, motion
control, security management,...) and ROS for higher level (image
processing, decision making, user interfaces,...). This mean that my
robot can move without any ROS inside. What I mean here, is that you
can (and maybe should) design your RT control, without thinking about
ROS. ROS only comes in minds when you will do your final integration.

In case of motion control the interface may be :
_ IN : receiving order
_ OUT : sending feedback
If this is send on Orocos ports, you don't care when you develop your
Orocos application *how* those data will be shared. You may use your
component in a pure Orocos system with local inter thread
communication , or reuse that component in a ROS/Orocos system with
ports connected with ROS infrastructures (messages). To go further you
don't even know if the one that is giving you orders is on the same
computer or over network...

This is a exemple of what Orocos provide : separation of concerns. One
of your problem may be that you are mixing things in the same question
:
1/_ what a component is doing
2/_ where you deploy it
3/_ how you communicate

For 1/ it is the job of the architect, and then of "Components
Builders". Splitting your application into components : how many ?
what functionnality over which ? what I wish to reuse in a different
system,... The only thing to care is how computation is done and we
don't care about what is going in the world, it may have an nuclear
attacks, it's not our buissiness. It includes *how* components
communicate. The only thing to matter is what to do if I have data,
and what to do if I have no data. We may even unknow here if the
component is periodical or not !

For 2/ and 3/ is is the job of the "System Builder". Here you care
about assembling parts, and you have system level requirements such as
security, qualilty of service, number of computers ... This will
impose choices on where you put things. Here is where you ask yourself
if you need RT comm or not, and with which constraints. This question
can go beyond Orocos as it may engage the choice of an RT OS.

So you may need to split the question into :
1/ What are the good pratices to design my "real time control" ?
2/ With an existing "control", where do I need RT comm, how should I
"map" my application into thread/process/computers..
3/ Given this "map", which communication can I choose to acheive
required service level (RT, bandwith, delay, loss of data, and other
communication level caracteristics)

The only answer I can give you to your question is : it is not the
communication that shall impose you a map of thread/process, the
communication has to fit. I suggest you to decide :
_ how many components will design
_ decide where you need RT communication (for instance giving a "goto"
order rarely requires RT. but executing the order may require RT)
_ decide how many thread/process/computers you need to do what you
want (For instance, my localisation is critical so I want it in a
separate process).
_ how many ros nodes you need (you can have several components in a
node). This imposes a process mapping, as component in different nodes
are in different process because ROS forces you to have a process per
node (this is a framework constaint that Orocos doesn't have btw ;p)

Last advice, if you want to play with Orocos, you should begin with a
sandbox with a pure Orocos system. You may use ROS for the building,
Os deps, developping, but you should use a flat orocos deployer to set
up your application. I'll help you a lot.

Disclamer : I'm just an Orocos user, what I say here is my personnal
view of all that, it doesn't engage the Orocos team. I have no doubt
they'll correct my wrong declarations.

>
> Thanks a lot!
> Edoardo
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users

Couple of questions about connecting components within ROS

On Wed, 20 Feb 2013, Willy Lambert wrote:

[... a big chunk of very interesting "tutorial" material from an advanced
user deleted...]

> Disclamer : I'm just an Orocos user, what I say here is my personnal
> view of all that, it doesn't engage the Orocos team. I have no doubt
> they'll correct my wrong declarations.

There is no such thing (anymore) as "the Orocos team", but an active
community of (advanced) Orocos users-turned-developers. Which is what I
dreamt of to happen ten years ago :-)

Herman

Couple of questions about connecting components within ROS

Dear Willy,
thanks a lot for your outstanding explanation.
I have a rough experiences in ROS, that's why probably I'm trying to use
ROS everywhere.

Your explanation will help me a lot in defining HOW design my system. As
I understood, I should use OROCOS as a stand-alone framework for
controlling my devices which require hard real-time, while using ROS
only for feedback and/or order (let's say supervision + other
no-real-time stuffs).

I really appreciate your help. I will try to define my project
considering all your suggestions.

Cheers,
Edoardo

On 02/20/2013 03:41 PM, Willy Lambert wrote:
> 2013/2/19 Edoardo Lopez <e [dot] lopez [..] ...>:
>> Dear all,
>> I'm a novice of OROCOS. I'm using it mainly to achieve real-time control.
>>
> You have to precise what you mean by real-time on this ML as people
> are using Orocos for a wide range of "real time requirement".
>
>> I've couple of questions:
>> 1) I have two components which have to communicate. Let's say:
>> componentA --[outPortA]-----------<msg>--------------[inPortB]-->componentB
>> How should I define the communication between these components? I was
>> thinking of:
> Depends where you puts you components in. Are they in the same process or not ?
> You don't need Ros messages to communicate between 2 pure Orocos
> components. And I'll go further, you shoudn't if they are in the same
> process. You can use the "ros msg" communication if your 2 components
> are in 2 different process. But you have other ways to do that in
> Orocos (Corba, Message queues). It depends if you need (hard ?) real
> time communication between your components.
>
>
>> A) create two different .ops files which i will run as two different ros
>> nodes and make them communicate by ros messages. However, will I achieve
>> real time communication?
> I'm not an expert of this, but I'm quite sure that you loose RT as
> soon as you use Ros communication.
> If you need RT comm between your components, it is quite sure you will
> put them in the them process and use Orocos communication.
>
>> B) create one .ops file to launch both components within the same OROCOS
>> process/ROS node and make them communicate within the process.
>>
>> I would rather use the A solution, but I need real-time communication.
>>
>>
>> 2) can I use .xml files instead of .ops file using OROCOS within ROS...
>> I always have errors..
>>
>
>
> What you may have missed is that Orocos is a standalone framework.
> Many people here have Orocos working without ROS. Some people, like
> me, are using Orocos for low level stuff (hardware interfacing, motion
> control, security management,...) and ROS for higher level (image
> processing, decision making, user interfaces,...). This mean that my
> robot can move without any ROS inside. What I mean here, is that you
> can (and maybe should) design your RT control, without thinking about
> ROS. ROS only comes in minds when you will do your final integration.
>
> In case of motion control the interface may be :
> _ IN : receiving order
> _ OUT : sending feedback
> If this is send on Orocos ports, you don't care when you develop your
> Orocos application *how* those data will be shared. You may use your
> component in a pure Orocos system with local inter thread
> communication , or reuse that component in a ROS/Orocos system with
> ports connected with ROS infrastructures (messages). To go further you
> don't even know if the one that is giving you orders is on the same
> computer or over network...
>
> This is a exemple of what Orocos provide : separation of concerns. One
> of your problem may be that you are mixing things in the same question
> :
> 1/_ what a component is doing
> 2/_ where you deploy it
> 3/_ how you communicate
>
> For 1/ it is the job of the architect, and then of "Components
> Builders". Splitting your application into components : how many ?
> what functionnality over which ? what I wish to reuse in a different
> system,... The only thing to care is how computation is done and we
> don't care about what is going in the world, it may have an nuclear
> attacks, it's not our buissiness. It includes *how* components
> communicate. The only thing to matter is what to do if I have data,
> and what to do if I have no data. We may even unknow here if the
> component is periodical or not !
>
> For 2/ and 3/ is is the job of the "System Builder". Here you care
> about assembling parts, and you have system level requirements such as
> security, qualilty of service, number of computers ... This will
> impose choices on where you put things. Here is where you ask yourself
> if you need RT comm or not, and with which constraints. This question
> can go beyond Orocos as it may engage the choice of an RT OS.
>
> So you may need to split the question into :
> 1/ What are the good pratices to design my "real time control" ?
> 2/ With an existing "control", where do I need RT comm, how should I
> "map" my application into thread/process/computers..
> 3/ Given this "map", which communication can I choose to acheive
> required service level (RT, bandwith, delay, loss of data, and other
> communication level caracteristics)
>
> The only answer I can give you to your question is : it is not the
> communication that shall impose you a map of thread/process, the
> communication has to fit. I suggest you to decide :
> _ how many components will design
> _ decide where you need RT communication (for instance giving a "goto"
> order rarely requires RT. but executing the order may require RT)
> _ decide how many thread/process/computers you need to do what you
> want (For instance, my localisation is critical so I want it in a
> separate process).
> _ how many ros nodes you need (you can have several components in a
> node). This imposes a process mapping, as component in different nodes
> are in different process because ROS forces you to have a process per
> node (this is a framework constaint that Orocos doesn't have btw ;p)
>
> Last advice, if you want to play with Orocos, you should begin with a
> sandbox with a pure Orocos system. You may use ROS for the building,
> Os deps, developping, but you should use a flat orocos deployer to set
> up your application. I'll help you a lot.
>
> Disclamer : I'm just an Orocos user, what I say here is my personnal
> view of all that, it doesn't engage the Orocos team. I have no doubt
> they'll correct my wrong declarations.
>
>> Thanks a lot!
>> Edoardo
>> --
>> Orocos-Users mailing list
>> Orocos-Users [..] ...
>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users

Couple of questions about connecting components within ROS

2013/2/20 Edoardo Lopez <e [dot] lopez [..] ...>:
> Dear Willy,
> thanks a lot for your outstanding explanation.

my pleasure, just giving back what I received here some years ago ^^.

> I have a rough experiences in ROS, that's why probably I'm trying to use ROS
> everywhere.

I understood that in your previous mail, and as I was taugth here,
it's not because you've discover something wonderful for a use case
that you have touse it every where ! It also fits to Orocos, you'll
probably find that components are marvellous (and they are :p) but
don't use them everywhere. For instance, you "core computation" (it
migth be motion control equations) still have to be usable outside
Orocos (just call your existing libs inside components).

Orocos is not just a stack in ROS (as it may seems if you discovered
it from ROS wiki). Handling it requires some time.

>
> Your explanation will help me a lot in defining HOW design my system. As I
> understood, I should use OROCOS as a stand-alone framework for controlling
> my devices which require hard real-time, while using ROS only for feedback
> and/or order (let's say supervision + other no-real-time stuffs).
>

You did not understood everything then ;p. I just helped into saying
what you have to define, not to define for you. It depends on what are
your requirements. If you give details people here will help you
making rigth decisions. It depends on how your system is confidential
or not.

But I did give some clues from my experience.

I have a mobile robot that is designed to have high acceleration
(8m/s2 on the floor) and good precision (in terms of localisation and
trajectory following : 1cm). This requires high control frequency (let
say 10ms) and data acquisition (localisation). It will not kill or
harm anybody whatever happens. The robot has to play in a competition
so have an "artificial intelligence".

What I did (or should have done as some choice were wrong in pratice,
but I just wrote the good ones) :
_ use a linux with a preempt RT patch. As the robot won't kill anybody
no need for some stronger, costly hard real time systems as xenomai.
But the performance (especially control frequency) requires high
response in general.
_ use a framework that provide very good performance for motion
control and localisation (that was Orocos)
_ use a framework for prototyping and high level tasks (that was ROS).

But some "project" constraints such as time, forced me to use the ROS
hokuyo driver, instead of integrating it in Orocos as it should had
been done (so it uses ROS communicationto send datas to the Orocos
localisation stuff).

Only when all those system requirements are mapped, I can design my Orocos part.

>
> I really appreciate your help. I will try to define my project considering
> all your suggestions.
>
> Cheers,
> Edoardo
>
>
> On 02/20/2013 03:41 PM, Willy Lambert wrote:
>>
>> 2013/2/19 Edoardo Lopez <e [dot] lopez [..] ...>:
>>>
>>> Dear all,
>>> I'm a novice of OROCOS. I'm using it mainly to achieve real-time control.
>>>
>> You have to precise what you mean by real-time on this ML as people
>> are using Orocos for a wide range of "real time requirement".
>>
>>> I've couple of questions:
>>> 1) I have two components which have to communicate. Let's say:
>>> componentA
>>> --[outPortA]-----------<msg>--------------[inPortB]-->componentB
>>> How should I define the communication between these components? I was
>>> thinking of:
>>
>> Depends where you puts you components in. Are they in the same process or
>> not ?
>> You don't need Ros messages to communicate between 2 pure Orocos
>> components. And I'll go further, you shoudn't if they are in the same
>> process. You can use the "ros msg" communication if your 2 components
>> are in 2 different process. But you have other ways to do that in
>> Orocos (Corba, Message queues). It depends if you need (hard ?) real
>> time communication between your components.
>>
>>
>>> A) create two different .ops files which i will run as two different ros
>>> nodes and make them communicate by ros messages. However, will I achieve
>>> real time communication?
>>
>> I'm not an expert of this, but I'm quite sure that you loose RT as
>> soon as you use Ros communication.
>> If you need RT comm between your components, it is quite sure you will
>> put them in the them process and use Orocos communication.
>>
>>> B) create one .ops file to launch both components within the same OROCOS
>>> process/ROS node and make them communicate within the process.
>>>
>>> I would rather use the A solution, but I need real-time communication.
>>>
>>>
>>> 2) can I use .xml files instead of .ops file using OROCOS within ROS...
>>> I always have errors..
>>>
>>
>>
>> What you may have missed is that Orocos is a standalone framework.
>> Many people here have Orocos working without ROS. Some people, like
>> me, are using Orocos for low level stuff (hardware interfacing, motion
>> control, security management,...) and ROS for higher level (image
>> processing, decision making, user interfaces,...). This mean that my
>> robot can move without any ROS inside. What I mean here, is that you
>> can (and maybe should) design your RT control, without thinking about
>> ROS. ROS only comes in minds when you will do your final integration.
>>
>> In case of motion control the interface may be :
>> _ IN : receiving order
>> _ OUT : sending feedback
>> If this is send on Orocos ports, you don't care when you develop your
>> Orocos application *how* those data will be shared. You may use your
>> component in a pure Orocos system with local inter thread
>> communication , or reuse that component in a ROS/Orocos system with
>> ports connected with ROS infrastructures (messages). To go further you
>> don't even know if the one that is giving you orders is on the same
>> computer or over network...
>>
>> This is a exemple of what Orocos provide : separation of concerns. One
>> of your problem may be that you are mixing things in the same question
>> :
>> 1/_ what a component is doing
>> 2/_ where you deploy it
>> 3/_ how you communicate
>>
>> For 1/ it is the job of the architect, and then of "Components
>> Builders". Splitting your application into components : how many ?
>> what functionnality over which ? what I wish to reuse in a different
>> system,... The only thing to care is how computation is done and we
>> don't care about what is going in the world, it may have an nuclear
>> attacks, it's not our buissiness. It includes *how* components
>> communicate. The only thing to matter is what to do if I have data,
>> and what to do if I have no data. We may even unknow here if the
>> component is periodical or not !
>>
>> For 2/ and 3/ is is the job of the "System Builder". Here you care
>> about assembling parts, and you have system level requirements such as
>> security, qualilty of service, number of computers ... This will
>> impose choices on where you put things. Here is where you ask yourself
>> if you need RT comm or not, and with which constraints. This question
>> can go beyond Orocos as it may engage the choice of an RT OS.
>>
>> So you may need to split the question into :
>> 1/ What are the good pratices to design my "real time control" ?
>> 2/ With an existing "control", where do I need RT comm, how should I
>> "map" my application into thread/process/computers..
>> 3/ Given this "map", which communication can I choose to acheive
>> required service level (RT, bandwith, delay, loss of data, and other
>> communication level caracteristics)
>>
>> The only answer I can give you to your question is : it is not the
>> communication that shall impose you a map of thread/process, the
>> communication has to fit. I suggest you to decide :
>> _ how many components will design
>> _ decide where you need RT communication (for instance giving a "goto"
>> order rarely requires RT. but executing the order may require RT)
>> _ decide how many thread/process/computers you need to do what you
>> want (For instance, my localisation is critical so I want it in a
>> separate process).
>> _ how many ros nodes you need (you can have several components in a
>> node). This imposes a process mapping, as component in different nodes
>> are in different process because ROS forces you to have a process per
>> node (this is a framework constaint that Orocos doesn't have btw ;p)
>>
>> Last advice, if you want to play with Orocos, you should begin with a
>> sandbox with a pure Orocos system. You may use ROS for the building,
>> Os deps, developping, but you should use a flat orocos deployer to set
>> up your application. I'll help you a lot.
>>
>> Disclamer : I'm just an Orocos user, what I say here is my personnal
>> view of all that, it doesn't engage the Orocos team. I have no doubt
>> they'll correct my wrong declarations.
>>
>>> Thanks a lot!
>>> Edoardo
>>> --
>>> Orocos-Users mailing list
>>> Orocos-Users [..] ...
>>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
>

Couple of questions about connecting components within ROS

On 02/20/2013 05:30 PM, Willy Lambert wrote:
> But some "project" constraints such as time, forced me to use the ROS
> hokuyo driver, instead of integrating it in Orocos as it should had
> been done (so it uses ROS communicationto send datas to the Orocos
> localisation stuff).
The obvious question here, from my side, is why you did not use rock's
hokuyo driver. It *is* a RTT component.

Sylvain

Couple of questions about connecting components within ROS

2013/2/20 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>:
> On 02/20/2013 05:30 PM, Willy Lambert wrote:
>>
>> But some "project" constraints such as time, forced me to use the ROS
>> hokuyo driver, instead of integrating it in Orocos as it should had
>> been done (so it uses ROS communicationto send datas to the Orocos
>> localisation stuff).
>
> The obvious question here, from my side, is why you did not use rock's
> hokuyo driver. It *is* a RTT component.
>
> Sylvain

_ I can't remind if it was available at this time.
_ Our process was to prototype with ROS then switch to Orocos, but did
not had the time to do the last step.
_ Is this driver usable outside rock ? In a pure Orocos world ? Then
I'll take it when I'll have the time
_ last reason, and main one : because I did not know it was there,
because there is still no place to search for existing components.

Couple of questions about connecting components within ROS

On Wed, 20 Feb 2013, Edoardo Lopez wrote:

> Dear Willy,
> thanks a lot for your outstanding explanation.
> I have a rough experiences in ROS, that's why probably I'm trying to use
> ROS everywhere.
>
> Your explanation will help me a lot in defining HOW design my system. As
> I understood, I should use OROCOS as a stand-alone framework for
> controlling my devices which require hard real-time, while using ROS
> only for feedback and/or order (let's say supervision + other
> no-real-time stuffs).

<shameless plug>
The rFSM package (that is Orocos-independent, but very well integrated with
it) is a very good tool for supervision, with a couple of "best practices"
about what "supervision" (aka as "Coordination") really means and how it
can be done in a way that support automatic Validation & Verification.
</shameless plug>
Another good source of supervision approach is what LAAS is doing with
their BIP efforts.

> I really appreciate your help. I will try to define my project
> considering all your suggestions.

> Cheers,
> Edoardo

Herman

> On 02/20/2013 03:41 PM, Willy Lambert wrote:
>> 2013/2/19 Edoardo Lopez <e [dot] lopez [..] ...>:
>>> Dear all,
>>> I'm a novice of OROCOS. I'm using it mainly to achieve real-time control.
>>>
>> You have to precise what you mean by real-time on this ML as people
>> are using Orocos for a wide range of "real time requirement".
>>
>>> I've couple of questions:
>>> 1) I have two components which have to communicate. Let's say:
>>> componentA --[outPortA]-----------<msg>--------------[inPortB]-->componentB
>>> How should I define the communication between these components? I was
>>> thinking of:
>> Depends where you puts you components in. Are they in the same process or not ?
>> You don't need Ros messages to communicate between 2 pure Orocos
>> components. And I'll go further, you shoudn't if they are in the same
>> process. You can use the "ros msg" communication if your 2 components
>> are in 2 different process. But you have other ways to do that in
>> Orocos (Corba, Message queues). It depends if you need (hard ?) real
>> time communication between your components.
>>
>>
>>> A) create two different .ops files which i will run as two different ros
>>> nodes and make them communicate by ros messages. However, will I achieve
>>> real time communication?
>> I'm not an expert of this, but I'm quite sure that you loose RT as
>> soon as you use Ros communication.
>> If you need RT comm between your components, it is quite sure you will
>> put them in the them process and use Orocos communication.
>>
>>> B) create one .ops file to launch both components within the same OROCOS
>>> process/ROS node and make them communicate within the process.
>>>
>>> I would rather use the A solution, but I need real-time communication.
>>>
>>>
>>> 2) can I use .xml files instead of .ops file using OROCOS within ROS...
>>> I always have errors..
>>>
>>
>>
>> What you may have missed is that Orocos is a standalone framework.
>> Many people here have Orocos working without ROS. Some people, like
>> me, are using Orocos for low level stuff (hardware interfacing, motion
>> control, security management,...) and ROS for higher level (image
>> processing, decision making, user interfaces,...). This mean that my
>> robot can move without any ROS inside. What I mean here, is that you
>> can (and maybe should) design your RT control, without thinking about
>> ROS. ROS only comes in minds when you will do your final integration.
>>
>> In case of motion control the interface may be :
>> _ IN : receiving order
>> _ OUT : sending feedback
>> If this is send on Orocos ports, you don't care when you develop your
>> Orocos application *how* those data will be shared. You may use your
>> component in a pure Orocos system with local inter thread
>> communication , or reuse that component in a ROS/Orocos system with
>> ports connected with ROS infrastructures (messages). To go further you
>> don't even know if the one that is giving you orders is on the same
>> computer or over network...
>>
>> This is a exemple of what Orocos provide : separation of concerns. One
>> of your problem may be that you are mixing things in the same question
>> :
>> 1/_ what a component is doing
>> 2/_ where you deploy it
>> 3/_ how you communicate
>>
>> For 1/ it is the job of the architect, and then of "Components
>> Builders". Splitting your application into components : how many ?
>> what functionnality over which ? what I wish to reuse in a different
>> system,... The only thing to care is how computation is done and we
>> don't care about what is going in the world, it may have an nuclear
>> attacks, it's not our buissiness. It includes *how* components
>> communicate. The only thing to matter is what to do if I have data,
>> and what to do if I have no data. We may even unknow here if the
>> component is periodical or not !
>>
>> For 2/ and 3/ is is the job of the "System Builder". Here you care
>> about assembling parts, and you have system level requirements such as
>> security, qualilty of service, number of computers ... This will
>> impose choices on where you put things. Here is where you ask yourself
>> if you need RT comm or not, and with which constraints. This question
>> can go beyond Orocos as it may engage the choice of an RT OS.
>>
>> So you may need to split the question into :
>> 1/ What are the good pratices to design my "real time control" ?
>> 2/ With an existing "control", where do I need RT comm, how should I
>> "map" my application into thread/process/computers..
>> 3/ Given this "map", which communication can I choose to acheive
>> required service level (RT, bandwith, delay, loss of data, and other
>> communication level caracteristics)
>>
>> The only answer I can give you to your question is : it is not the
>> communication that shall impose you a map of thread/process, the
>> communication has to fit. I suggest you to decide :
>> _ how many components will design
>> _ decide where you need RT communication (for instance giving a "goto"
>> order rarely requires RT. but executing the order may require RT)
>> _ decide how many thread/process/computers you need to do what you
>> want (For instance, my localisation is critical so I want it in a
>> separate process).
>> _ how many ros nodes you need (you can have several components in a
>> node). This imposes a process mapping, as component in different nodes
>> are in different process because ROS forces you to have a process per
>> node (this is a framework constaint that Orocos doesn't have btw ;p)
>>
>> Last advice, if you want to play with Orocos, you should begin with a
>> sandbox with a pure Orocos system. You may use ROS for the building,
>> Os deps, developping, but you should use a flat orocos deployer to set
>> up your application. I'll help you a lot.
>>
>> Disclamer : I'm just an Orocos user, what I say here is my personnal
>> view of all that, it doesn't engage the Orocos team. I have no doubt
>> they'll correct my wrong declarations.
>>
>>> Thanks a lot!
>>> Edoardo
>>> --
>>> Orocos-Users mailing list
>>> Orocos-Users [..] ...
>>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users

Couple of questions about connecting components within ROS

On 02/20/2013 05:26 PM, Herman Bruyninckx wrote:
> <shameless plug>
And let's go with my own: http://rock-robotics.org/stable/system

User Survey: Deployment Tool Used

3) Lua (partially using Eclipse GMF editor)
1) XML

Pozdrawiam
Konrad Banachowicz

User Survey: Deployment Tool Used

On 02/18/2013 01:28 PM, Hugo A Garcia wrote:
> Hi
>
> I would appreciate if you could reply to this email stating which
> deployment toolS you use:
>
> 1) XML
> 2) Orocos Script
> 3) Lua
> 4) Rock
All Rock users: 4), e.g. either oroGen deployments and either Ruby
scripts (outside of components) or syskit (system model deployment)

Sylvain

User Survey: Deployment Tool Used

> On Mon, 18 Feb 2013, Hugo A Garcia wrote:
>
> > Hi
> > I would appreciate if you could reply to this email stating which
deployment toolS you use:
> >
> > 1) XML
> > 2) Orocos Script
> > 3) Lua
> > 4) Rock
> > 5) Other

We're using Lua at Tecnalia. (Should change my subscription address, I
know...)

>
> I am also interested in _how_ the deployment is designed, and what
"models"
> and/or "tools" are being used, if any. (I put these words between
quotation
> marks, since there are many possible ways that these terms can be filled
> in...)
>

Unfortunately, no tool at all, although I'm very interested in any
suggestion in this respect.

Tried to set up BRIDE some time ago but I failed to do so, and the
bride-users mailing list (linked from the BRIDE site) apparently doesn't
exist.

> > Thank you in advance
> >
> > -H
>
> Herman
>

User Survey: Deployment Tool Used

On Mon, Feb 18, 2013 at 1:28 PM, Hugo A Garcia <hugo [dot] a [dot] garcia [..] ...>wrote:

> Hi
>
> I would appreciate if you could reply to this email stating which
> deployment toolS you use:
>
> 1) XML
> 2) Orocos Script
> 3) Lua
> 4) Rock
> 5) Other
>
>

Method 2 and 3
Bert

>
>
> Thank you in advance
>
> -H
>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
>

User Survey: Deployment Tool Used

On 02/18/2013 01:28 PM, Hugo A Garcia wrote:
> Hi
>
> I would appreciate if you could reply to this email stating which
> deployment toolS you use:
>
> 1) XML
> 2) Orocos Script
> 3) Lua
> 4) Rock
> 5) Other
2+1
3+1
Cheers, Gianni.

>
> Thank you in advance
>
> -H
>
>

User Survey: Deployment Tool Used

On Feb 18, 2013, at 07:28 , Hugo A Garcia wrote:

> Hi
>
> I would appreciate if you could reply to this email stating which deployment toolS you use:
>
> 1) XML
> 2) Orocos Script
> 3) Lua
> 4) Rock
> 5) Other
>
> Thank you in advance

XML.

Currently intending to use Lua when we get to v2.
S

User Survey: Deployment Tool Used

2013/2/18 S Roderick <kiwi [dot] net [..] ...>

> On Feb 18, 2013, at 07:28 , Hugo A Garcia wrote:
>
> > Hi
> >
> > I would appreciate if you could reply to this email stating which
> deployment toolS you use:
> >
> > 1) XML
> > 2) Orocos Script
> > 3) Lua
> > 4) Rock
> > 5) Other
> >
> > Thank you in advance
>

Orocos scripts for simple deployments.
Lua for complex deployments (most of the time with rFSM to coordinate the
components)

Charles.

>
> XML.
>
> Currently intending to use Lua when we get to v2.
> S
>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>

User Survey: Deployment Tool Used

2013/2/18 Charles Lesire-Cabaniols <charles [dot] lesire [..] ...>:
>
>
>
> 2013/2/18 S Roderick <kiwi [dot] net [..] ...>
>>
>> On Feb 18, 2013, at 07:28 , Hugo A Garcia wrote:
>>
>> > Hi
>> >
>> > I would appreciate if you could reply to this email stating which
>> > deployment toolS you use:
>> >
>> > 1) XML
>> > 2) Orocos Script
>> > 3) Lua
>> > 4) Rock
>> > 5) Other
>> >
>> > Thank you in advance
>
>
> Orocos scripts for simple deployments.
> Lua for complex deployments (most of the time with rFSM to coordinate the
> components)
>
> Charles.
>

Same for me. The rationale behind this is that only scripts can
provide sequential deployment, which is required to build a scalable
system. So XML is not an option.
I'm not using Rock because it was not stable when I began my projects,
but today I'll consider this as an option.

Note that I never do some dynamic deployment (I mean I will never
disconnect/reconnect ports). I don't have the need to do this yet, but
I think the question matters, because it would be helpfull when
switching behaviors/control modes of robots.

@Hermann : I'm doing the work "by hand" inside those files. I modeled
this implicitely with these rules :
_ main application is split is different levels (harware interfacing,
actuators chain, sensor chain, supervision, ...). each level has
preriquisite about others (for instance, actuators and sensors
required hardware). This ordering is done by hand because in my case
in is simple enougth to do so.
_ the deployment happens in several steps : load all libraries for
each level, load components for each level, add peers and connect
ports of each level, configure components of each level. The
rationale of this is that you need this to be done in past steps of
other levels (for instance to connect a port you need a component...)
_ each step is calling groups of scripts that brings all "step hooks"
in a file, so I have a bit of composition. The idea is to have
composition in my deployment. For instance I can have a group "Motion
actuators" in the hardware level. Each each is calling groups or leaf
that are "one component=one deployment script". For instance the
"Motion actuators" are calling LeftDrive, RigthDrive ... in raw for
each steps.

Of course, I wish I had a tool to do all this for me...

What I would expect of such a tool in mess : scalability, modularity,
groups/composition for pre made functionnal set of components (the
question behind this is where composition has to be done, in composed
components, or in the "user view of the system"), easy to use from the
"System builder" point of view (I want to know the less about the
components), dependency management.

>>
>>
>> XML.
>>
>> Currently intending to use Lua when we get to v2.
>> S
>>
>> --
>> Orocos-Users mailing list
>> Orocos-Users [..] ...
>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
>
>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>

User Survey: Deployment Tool Used

On Wed, 20 Feb 2013, Willy Lambert wrote:

> 2013/2/18 Charles Lesire-Cabaniols <charles [dot] lesire [..] ...>:
>>
>> 2013/2/18 S Roderick <kiwi [dot] net [..] ...>
>>>
>>> On Feb 18, 2013, at 07:28 , Hugo A Garcia wrote:
>>>
>>>> Hi
>>>>
>>>> I would appreciate if you could reply to this email stating which
>>>> deployment toolS you use:
>>>>
>>>> 1) XML
>>>> 2) Orocos Script
>>>> 3) Lua
>>>> 4) Rock
>>>> 5) Other
>>>>
>>>> Thank you in advance
>>
>> Orocos scripts for simple deployments.
>> Lua for complex deployments (most of the time with rFSM to coordinate the
>> components)
>>
>> Charles.
>
> Same for me. The rationale behind this is that only scripts can
> provide sequential deployment, which is required to build a scalable
> system. So XML is not an option.

In XML one could _model_ the deployment, which is then _deployed_ on a
_runtime_ that can do the sequencing. (In between, an optimizing scheduler
could be put, if required.)

> I'm not using Rock because it was not stable when I began my projects,
> but today I'll consider this as an option.

I would recommend it!

> Note that I never do some dynamic deployment (I mean I will never
> disconnect/reconnect ports). I don't have the need to do this yet, but
> I think the question matters, because it would be helpfull when
> switching behaviors/control modes of robots.
>
> @Hermann : I'm doing the work "by hand" inside those files. I modeled
> this implicitely with these rules :
> _ main application is split is different levels (harware interfacing,
> actuators chain, sensor chain, supervision, ...). each level has
> preriquisite about others (for instance, actuators and sensors
> required hardware). This ordering is done by hand because in my case
> in is simple enougth to do so.

It is simple enough, yes. But if you (or rather, all of us) could do this
in a _model_, then we would have more options to adapt to different
"platforms":, etc.

> _ the deployment happens in several steps : load all libraries for
> each level, load components for each level, add peers and connect
> ports of each level, configure components of each level.

The "level" concept is very important, and I think we can "standardize"
them, to a large extent. The Workshop we have last week in Leuven "decided"
that we are going to try to make the next step in that direction, together,
in that community of two dozen or so senior people.

> The
> rationale of this is that you need this to be done in past steps of
> other levels (for instance to connect a port you need a component...)
> _ each step is calling groups of scripts that brings all "step hooks"
> in a file, so I have a bit of composition. The idea is to have
> composition in my deployment.

You "have" it already, but you called it "levels" before... :-)

> For instance I can have a group "Motion
> actuators" in the hardware level. Each each is calling groups or leaf
> that are "one component=one deployment script". For instance the
> "Motion actuators" are calling LeftDrive, RigthDrive ... in raw for
> each steps.
>
> Of course, I wish I had a tool to do all this for me...

Me too!

> What I would expect of such a tool in mess : scalability, modularity,
> groups/composition for pre made functionnal set of components (the
> question behind this is where composition has to be done, in composed
> components, or in the "user view of the system"), easy to use from the
> "System builder" point of view (I want to know the less about the
> components), dependency management.

Herman

User Survey: Deployment Tool Used

2013/2/20 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>:
> On Wed, 20 Feb 2013, Willy Lambert wrote:
>
>> 2013/2/18 Charles Lesire-Cabaniols <charles [dot] lesire [..] ...>:
>>>
>>>
>>> 2013/2/18 S Roderick <kiwi [dot] net [..] ...>
>>>>
>>>>
>>>> On Feb 18, 2013, at 07:28 , Hugo A Garcia wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> I would appreciate if you could reply to this email stating which
>>>>> deployment toolS you use:
>>>>>
>>>>> 1) XML
>>>>> 2) Orocos Script
>>>>> 3) Lua
>>>>> 4) Rock
>>>>> 5) Other
>>>>>
>>>>> Thank you in advance
>>>
>>>
>>> Orocos scripts for simple deployments.
>>> Lua for complex deployments (most of the time with rFSM to coordinate the
>>> components)
>>>
>>> Charles.
>>
>>
>> Same for me. The rationale behind this is that only scripts can
>> provide sequential deployment, which is required to build a scalable
>> system. So XML is not an option.
>
>
> In XML one could _model_ the deployment, which is then _deployed_ on a
> _runtime_ that can do the sequencing. (In between, an optimizing scheduler
> could be put, if required.)
>
>
>> I'm not using Rock because it was not stable when I began my projects,
>> but today I'll consider this as an option.
>
>
> I would recommend it!
>
>
>> Note that I never do some dynamic deployment (I mean I will never
>> disconnect/reconnect ports). I don't have the need to do this yet, but
>> I think the question matters, because it would be helpfull when
>> switching behaviors/control modes of robots.
>>
>> @Hermann : I'm doing the work "by hand" inside those files. I modeled
>> this implicitely with these rules :
>> _ main application is split is different levels (harware interfacing,
>> actuators chain, sensor chain, supervision, ...). each level has
>> preriquisite about others (for instance, actuators and sensors
>> required hardware). This ordering is done by hand because in my case
>> in is simple enougth to do so.
>
>
> It is simple enough, yes. But if you (or rather, all of us) could do this
> in a _model_, then we would have more options to adapt to different
> "platforms":, etc.
>
>
>> _ the deployment happens in several steps : load all libraries for
>> each level, load components for each level, add peers and connect
>> ports of each level, configure components of each level.
>
>
> The "level" concept is very important, and I think we can "standardize"
> them, to a large extent. The Workshop we have last week in Leuven "decided"
> that we are going to try to make the next step in that direction, together,
> in that community of two dozen or so senior people.
>
>
>> The
>> rationale of this is that you need this to be done in past steps of
>> other levels (for instance to connect a port you need a component...)
>> _ each step is calling groups of scripts that brings all "step hooks"
>> in a file, so I have a bit of composition. The idea is to have
>> composition in my deployment.
>
>
> You "have" it already, but you called it "levels" before... :-)
>

I'm not sure to understand, or not sure you understood.

Some parts of the deployment needs that things has been done for all levels.

For instance I do sequentially :
_ the deployment of all components of all levels (hardware, motion
control, localisation).
_ the connection of ports with the rule "each component connects its
inputs, and never its outputs"
_ the configuration of all components.
_ the start of main managers that will start/stop groups of components.

So I have a main deployment script that is calling 4 hooks, one for
each step. Each hooks is calling the differents steps of the different
levels (with a manual dependency management : hardware before the
other,...). This is the "Robots System Builder" point of view.

The 4 hooks of the XXX level are in the same script. So from the "XXX
System Builder" point of view I provide an independant deployment.
This file is calling the hooks of different groups of components. The
order and the contents of those hooks depends of which "XXX System"
you are setting up inside a pool of available components. The
rationale behind this is that in pratice it is different
people/services in a compagny that are doing the different parts
(event at the system level).

In fact those scripts are just doing composition overhead. They have
no real contents. The contents is in leaf scripts. Each component has
a deployment script (and in fact each component should have several
deployment script, one for each system, but in pratice you commonly
use the same, differences are more common in setting up properties in
the configuration step). It is where you have deployment commands like
: loadComponant, connectPort, ...

To go in your direction, as I highly support your level formalisation,
problems comes when you interface the different levels. I think it
comes from the lack of composition inside Orocos. I can't easily make
port connections from a level to the other without knowing anything of
it. For instance when connection motion control/localistion onto
hardware. What's behind this is that we put in the deployment phase
all the system knowledge but I'm not sure you can do system level
composition to the end in such a context (I mean having 2 different
level deployment totally independants). Thing are still fuzzy in my
head on such problems, and where my personnal deployment system shows
limitations.

>
>> For instance I can have a group "Motion
>> actuators" in the hardware level. Each each is calling groups or leaf
>> that are "one component=one deployment script". For instance the
>> "Motion actuators" are calling LeftDrive, RigthDrive ... in raw for
>> each steps.
>>
>> Of course, I wish I had a tool to do all this for me...
>
>
> Me too!
>
>
>> What I would expect of such a tool in mess : scalability, modularity,
>> groups/composition for pre made functionnal set of components (the
>> question behind this is where composition has to be done, in composed
>> components, or in the "user view of the system"), easy to use from the
>> "System builder" point of view (I want to know the less about the
>> components), dependency management.
>
>
> Herman

User Survey: Deployment Tool Used

On Feb 20, 2013, at 08:50 , Willy Lambert wrote:

> 2013/2/18 Charles Lesire-Cabaniols <charles [dot] lesire [..] ...>:
>>
>>
>>
>> 2013/2/18 S Roderick <kiwi [dot] net [..] ...>
>>>
>>> On Feb 18, 2013, at 07:28 , Hugo A Garcia wrote:
>>>
>>>> Hi
>>>>
>>>> I would appreciate if you could reply to this email stating which
>>>> deployment toolS you use:
>>>>
>>>> 1) XML
>>>> 2) Orocos Script
>>>> 3) Lua
>>>> 4) Rock
>>>> 5) Other
>>>>
>>>> Thank you in advance
>>
>>
>> Orocos scripts for simple deployments.
>> Lua for complex deployments (most of the time with rFSM to coordinate the
>> components)
>>
>> Charles.
>>
>
> Same for me. The rationale behind this is that only scripts can
> provide sequential deployment, which is required to build a scalable
> system. So XML is not an option.

This isn't true. You can do this with the deployer using multiple "-s" options. That's how we load and start the system in "layers". And how you can deal with the following issue ...

> Note that I never do some dynamic deployment (I mean I will never
> disconnect/reconnect ports). I don't have the need to do this yet, but
> I think the question matters, because it would be helpfull when
> switching behaviors/control modes of robots.

The inability to do "dynamic deployments" is a huge stumbling block with the deployer. Things like ethercat that create ports at runtime, based on what is connected, just can't be supported using XML + deployer.
S

User Survey: Deployment Tool Used

2013/2/20 Stephen Roderick <kiwi [dot] net [..] ...>:
> On Feb 20, 2013, at 08:50 , Willy Lambert wrote:
>
>> 2013/2/18 Charles Lesire-Cabaniols <charles [dot] lesire [..] ...>:
>>>
>>>
>>>
>>> 2013/2/18 S Roderick <kiwi [dot] net [..] ...>
>>>>
>>>> On Feb 18, 2013, at 07:28 , Hugo A Garcia wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> I would appreciate if you could reply to this email stating which
>>>>> deployment toolS you use:
>>>>>
>>>>> 1) XML
>>>>> 2) Orocos Script
>>>>> 3) Lua
>>>>> 4) Rock
>>>>> 5) Other
>>>>>
>>>>> Thank you in advance
>>>
>>>
>>> Orocos scripts for simple deployments.
>>> Lua for complex deployments (most of the time with rFSM to coordinate the
>>> components)
>>>
>>> Charles.
>>>
>>
>> Same for me. The rationale behind this is that only scripts can
>> provide sequential deployment, which is required to build a scalable
>> system. So XML is not an option.
>
> This isn't true.

It is true, because it is just *my* use case ;p. I was not speaking
about what you can do or not with Orocos

> You can do this with the deployer using multiple "-s" options. That's how we load and start the system in "layers". And how you can deal with the following issue ...
>

I wasn't aware that -s can be used several times.

>> Note that I never do some dynamic deployment (I mean I will never
>> disconnect/reconnect ports). I don't have the need to do this yet, but
>> I think the question matters, because it would be helpfull when
>> switching behaviors/control modes of robots.
>
> The inability to do "dynamic deployments" is a huge stumbling block with the deployer. Things like ethercat that create ports at runtime, based on what is connected, just can't be supported using XML + deployer.
> S
>

User Survey: Deployment Tool Used

2013/2/18 Charles Lesire-Cabaniols <charles [dot] lesire [..] ...>

>
>
>
> 2013/2/18 S Roderick <kiwi [dot] net [..] ...>
>
>> On Feb 18, 2013, at 07:28 , Hugo A Garcia wrote:
>>
>> > Hi
>> >
>> > I would appreciate if you could reply to this email stating which
>> deployment toolS you use:
>> >
>> > 1) XML
>> > 2) Orocos Script
>> > 3) Lua
>> > 4) Rock
>> > 5) Other
>> >
>> > Thank you in advance
>>
>
> Orocos scripts for simple deployments.
> Lua for complex deployments (most of the time with rFSM to coordinate the
> components)
>

The same for me.

Nicola

>
>
> Charles.
>
>
>>
>> XML.
>>
>> Currently intending to use Lua when we get to v2.
>> S
>>
>> --
>> Orocos-Users mailing list
>> Orocos-Users [..] ...
>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>>
>
>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
>

User Survey: Deployment Tool Used

On 02/18/2013 03:30 PM, Nicola Preda wrote:
>
>
> 2013/2/18 Charles Lesire-Cabaniols <charles [dot] lesire [..] ...
> <mailto:charles [dot] lesire [..] ...>>
>
>
>
>
> 2013/2/18 S Roderick <kiwi [dot] net [..] ... <mailto:kiwi [dot] net [..] ...>>
>
> On Feb 18, 2013, at 07:28 , Hugo A Garcia wrote:
>
> > Hi
> >
> > I would appreciate if you could reply to this email stating
> which deployment toolS you use:
> >
> > 1) XML
> > 2) Orocos Script
> > 3) Lua
> > 4) Rock
> > 5) Other
> >
> > Thank you in advance
>
>
> Orocos scripts for simple deployments.
> Lua for complex deployments (most of the time with rFSM to
> coordinate the components)
>
>
> The same for me.
for me too.
>
> Nicola
>
>
>
> Charles.
>
>
> XML.
>
> Currently intending to use Lua when we get to v2.
> S
>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> <mailto:Orocos-Users [..] ...>
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
>
>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> <mailto:Orocos-Users [..] ...>
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
>
>
>

User Survey: Deployment Tool Used

1. roslaunch + orocos script

On Mon, Feb 18, 2013 at 10:20 AM, Tinne De Laet <
tinne [dot] delaet [..] ...> wrote:

> On 02/18/2013 03:30 PM, Nicola Preda wrote:
> >
> >
> > 2013/2/18 Charles Lesire-Cabaniols <charles [dot] lesire [..] ...
> > <mailto:charles [dot] lesire [..] ...>>
> >
> >
> >
> >
> > 2013/2/18 S Roderick <kiwi [dot] net [..] ... <mailto:kiwi [dot] net [..] ...>>
> >
> > On Feb 18, 2013, at 07:28 , Hugo A Garcia wrote:
> >
> > > Hi
> > >
> > > I would appreciate if you could reply to this email stating
> > which deployment toolS you use:
> > >
> > > 1) XML
> > > 2) Orocos Script
> > > 3) Lua
> > > 4) Rock
> > > 5) Other
> > >
> > > Thank you in advance
> >
> >
> > Orocos scripts for simple deployments.
> > Lua for complex deployments (most of the time with rFSM to
> > coordinate the components)
> >
> >
> > The same for me.
> for me too.
> >
> > Nicola
> >
> >
> >
> > Charles.
> >
> >
> > XML.
> >
> > Currently intending to use Lua when we get to v2.
> > S
> >
> > --
> > Orocos-Users mailing list
> > Orocos-Users [..] ...
> > <mailto:Orocos-Users [..] ...>
> > http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
> >
> >
> >
> > --
> > Orocos-Users mailing list
> > Orocos-Users [..] ...
> > <mailto:Orocos-Users [..] ...>
> > http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
> >
> >
> >
> >
>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>

User Survey: Deployment Tool Used

On 02/18/2013 04:22 PM, Jonathan Bohren wrote:
> 1. roslaunch + orocos script
Same here.
>
>
> On Mon, Feb 18, 2013 at 10:20 AM, Tinne De Laet
> <tinne [dot] delaet [..] ... <mailto:tinne [dot] delaet [..] ...>>
> wrote:
>
> On 02/18/2013 03:30 PM, Nicola Preda wrote:
> >
> >
> > 2013/2/18 Charles Lesire-Cabaniols <charles [dot] lesire [..] ...
> <mailto:charles [dot] lesire [..] ...>
> > <mailto:charles [dot] lesire [..] ... <mailto:charles [dot] lesire [..] ...>>>
> >
> >
> >
> >
> > 2013/2/18 S Roderick <kiwi [dot] net [..] ...
> <mailto:kiwi [dot] net [..] ...> <mailto:kiwi [dot] net [..] ...
> <mailto:kiwi [dot] net [..] ...>>>
> >
> > On Feb 18, 2013, at 07:28 , Hugo A Garcia wrote:
> >
> > > Hi
> > >
> > > I would appreciate if you could reply to this email
> stating
> > which deployment toolS you use:
> > >
> > > 1) XML
> > > 2) Orocos Script
> > > 3) Lua
> > > 4) Rock
> > > 5) Other
> > >
> > > Thank you in advance
> >
> >
> > Orocos scripts for simple deployments.
> > Lua for complex deployments (most of the time with rFSM to
> > coordinate the components)
> >
> >
> > The same for me.
> for me too.
> >
> > Nicola
> >
> >
> >
> > Charles.
> >
> >
> > XML.
> >
> > Currently intending to use Lua when we get to v2.
> > S
> >
> > --
> > Orocos-Users mailing list
> > Orocos-Users [..] ...
> <mailto:Orocos-Users [..] ...>
> > <mailto:Orocos-Users [..] ...
> <mailto:Orocos-Users [..] ...>>
> > http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
> >
> >
> >
> > --
> > Orocos-Users mailing list
> > Orocos-Users [..] ...
> <mailto:Orocos-Users [..] ...>
> > <mailto:Orocos-Users [..] ...
> <mailto:Orocos-Users [..] ...>>
> > http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
> >
> >
> >
> >
>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> <mailto:Orocos-Users [..] ...>
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
>
>
>

User Survey: Deployment Tool Used

- Up to now (RTT 1.x), mostly XML.
- Now that we're seriously embracing RTT 2.x, one of the scripting
alternatives will probably be favored. I still have to test the Lua stuff
in more detail to make an informed decision.

Cheers,

frodo's picture

User Survey: Deployment Tool Used

On 18/02/13 15:30, Nicola Preda wrote:
>
>
> 2013/2/18 Charles Lesire-Cabaniols <charles [dot] lesire [..] ...
> <mailto:charles [dot] lesire [..] ...>>
>
>
>
>
> 2013/2/18 S Roderick <kiwi [dot] net [..] ... <mailto:kiwi [dot] net [..] ...>>
>
> On Feb 18, 2013, at 07:28 , Hugo A Garcia wrote:
>
> > Hi
> >
> > I would appreciate if you could reply to this email stating
> which deployment toolS you use:
> >
> > 1) XML
> > 2) Orocos Script
> > 3) Lua
> > 4) Rock
> > 5) Other
> >
> > Thank you in advance
>
>
> Orocos scripts for simple deployments.
> Lua for complex deployments (most of the time with rFSM to
> coordinate the components)
>
>
> The same for me.
>
As I haven't start yet with rFSM, method: 2. But I'm planning to use Lua
for that.

Sergio
> Nicola
>
>
>
> Charles.
>
>
> XML.
>
> Currently intending to use Lua when we get to v2.
> S
>
>
>

User Survey: Deployment Tool Used

On 02/18/2013 01:28 PM, Hugo A Garcia wrote:
> Hi
>
> I would appreciate if you could reply to this email stating which
> deployment toolS you use:
>
> 1) XML
> 2) Orocos Script
> 3) Lua
> 4) Rock
> 5) Other
>
> Thank you in advance

Mostly XML. Sometimes pure C++ i.e. ORO_main().

Never Orocos script, because
http://www.orocos.org/stable/documentation/ocl/v2.x/doc-xml/orocos-deplo...

does not always have scripting equivalents for the XML statements (for
example, 2.4.1 talks about setting Period, Priority and Scheduler via
XML, but the scripting equivalent is missing). This information is
surely <somewhere>, but the XML info was consolidated right on that one
page and therefore it was just simpler to use XML at that moment. And
once you use XML for one project, it is easier to continue using XML for
subsequent projects. That said, someday I do want to use scripting
because that is just ... nicer.

Random thought: A graphical 'System Builder' for orocos would be cool to
have some day. You drag and drop components/connections from a palette,
right click and configure their properties, press a button and launch.
Something like Simulink, but better :P

Regards,
Sagar

User Survey: Deployment Tool Used

On Mon, 18 Feb 2013, Hugo A Garcia wrote:

> Hi
> I would appreciate if you could reply to this email stating which deployment toolS you use:
>
> 1) XML
> 2) Orocos Script
> 3) Lua
> 4) Rock
> 5) Other

I am also interested in _how_ the deployment is designed, and what "models"
and/or "tools" are being used, if any. (I put these words between quotation
marks, since there are many possible ways that these terms can be filled
in...)

> Thank you in advance
>
> -H

Herman

User Survey: Deployment Tool Used

Hi,

I would appreciate if you could reply to this email stating which
> deployment toolS you use:

In "frequency of use" order:

1)Lua (rttlua)
2)XML (deployer / deployer-gnulinux)
3)XML + ops (deployer / deployer-gnulinux)

Most of the time wrapped into bash scripts or ROS Launch files...

- Enea

User Survey: Deployment Tool Used

Hi Hugo,

Here is my usage in decreasing order:

1. Lua
2. XML
3. Orocos Script

Br,
Shashank

On Mon, Feb 18, 2013 at 1:46 PM, <
orocos-users-request [..] ...> wrote:

> Send Orocos-Users mailing list submissions to
> orocos-users [..] ...
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
> or, via email, send a message with subject or body 'help' to
> orocos-users-request [..] ...
>
> You can reach the person managing the list at
> orocos-users-owner [..] ...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Orocos-Users digest..."
>
>
> Today's Topics:
>
> 1. User Survey: Deployment Tool Used (Hugo A Garcia)
> 2. Re: Gravity Compensation app (Praveen Ramanujam)
> 3. Re: User Survey: Deployment Tool Used (Hugo A Garcia)
> 4. Re: User Survey: Deployment Tool Used (Nico Hochgeschwender)
> 5. Re: User Survey: Deployment Tool Used (Enea Scioni)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 18 Feb 2013 13:28:46 +0100
> From: Hugo A Garcia <hugo [dot] a [dot] garcia [..] ...>
> Subject: [Orocos-users] User Survey: Deployment Tool Used
> To: "orocos-users [..] ..."
> <orocos-users [..] ...>
> Message-ID:
> <
> CADrVvHya13ie4u_5USyFUtne57gHC1CWx7thrxOHp9pb5+3D3g [..] ...>
> Content-Type: text/plain; charset="utf-8"
>
> Hi
>
> I would appreciate if you could reply to this email stating which
> deployment toolS you use:
>
> 1) XML
> 2) Orocos Script
> 3) Lua
> 4) Rock
> 5) Other
>
> Thank you in advance
>
> -H
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.mech.kuleuven.be/pipermail/orocos-users/attachments/2013021...
>
> ------------------------------
>
> Message: 2
> Date: Mon, 18 Feb 2013 04:31:29 -0800 (PST)
> From: Praveen Ramanujam <praveen [dot] ramanujam [..] ...>
> Subject: Re: [Orocos-users] Gravity Compensation app
> To: Enea Scioni <scnnee [..] ...>
> Cc: "\"Orocos-Users [..] ...\""
> <Orocos-Users [..] ...>
> Message-ID:
> <1361190689 [dot] 69503 [dot] YahooMailNeo [..] ...>
> Content-Type: text/plain; charset="utf-8"
>
> Dear Enea,
>
> Thank you for the reply.
> May be this point is important or may be not.. I am using Firmware version
> 2.0, does it make difference for this app ?
>
>
>
> ??? It sounds like you are not able to access/communicate to ethercat
> devices on the youBot...
> ??? Could you please check the following:
> ??? 1) Do you have rights to access to these devices (i.e. run fix_caps.sh
> in youbot_driver_rtt ) ?
>
> When I run this command, I get the following :
>
> configuring capabilities on deployer
> configuring capabilities on deployer-corba
> configuring capabilities on deployer-corba-gnulinux
> configuring capabilities on deployer-gnulinux
> configuring capabilities on rttlua
> configuring capabilities on rttlua-gnulinux
> configuring capabilities on rttlua-tlsf
> configuring capabilities on rttlua-tlsf-gnulinux
> configuring capabilities on deployer
> configuring capabilities on deployer-corba
> configuring capabilities on deployer-corba-gnulinux
> configuring capabilities on deployer-gnulinux
> configuring capabilities on rttlua
> configuring capabilities on rttlua-gnulinux
> configuring capabilities on rttlua-tlsf
> configuring capabilities on rttlua-tlsf-gnulinux
>
> ??? 2) Are the "run/stop" button(s) on the youbot on? If not, it is likely
> that you have only the onboard pc powered, and not the youBot Base and
> Arm...
>
> Everything seems to be ok and when i try to run with youbot_driver with
> out orocos, it works fine.
>
> Best Regards
> Praveen
>
>
>
>
>
>
>
>
> >________________________________
> > From: Enea Scioni <scnnee [..] ...>
> >To: Praveen Ramanujam <praveen [dot] ramanujam [..] ...>
> >Cc: "Orocos-Users [..] ..." <
> Orocos-Users [..] ...>
> >Sent: Saturday, February 16, 2013 4:08 PM
> >Subject: Re: [Orocos-users] Gravity Compensation app
> >
> >
> >Dear Praveen,
> >
> >
> >root@pramanuj-laptop:~/orocros/youbot_hardware/youbot_driver_rtt#
> ./run.sh -r
> >
> >OROCOS RTTLua 1.0-beta5 / Lua 5.1.4 (gnulinux)
> >>1.664 [ ERROR ?][youbot::sendMBX] Setting parameter failed with status 8
> >>1.664 [ ERROR ?][youbot] setDefParam: setting param nr ? to 3 failed.
> pwd?
> >>1.667 [ ERROR ?][youbot::sendMBX] Setting parameter failed with status 8
> >>1.667 [ ERROR ?][youbot] setDefParam: setting param nr ? to 3 failed.
> pwd?
> >>1.671 [ ERROR ?][youbot::sendMBX] Setting parameter failed with status 8
> >>1.671 [ ERROR ?][youbot] setDefParam: setting param nr ? to 3 failed.
> pwd?
> >>1.674 [ ERROR ?][youbot::sendMBX] Setting parameter failed with status 8
> >>1.674 [ ERROR ?][youbot] setDefParam: setting param nr ? to 3 failed.
> pwd?
> >>1.678 [ ERROR ?][youbot::sendMBX] Setting parameter failed with status 3
> >>1.678 [ ERROR ?][youbot] setDefParam: failed to read param nr ?
> >>1.705 [ ERROR ?][youbot::sendMBX] Setting parameter failed with status 8
> >>1.705 [ ERROR ?][youbot] setDefParam: setting param nr ? to 3 failed.
> pwd?
> >>1.709 [ ERROR ?][youbot::sendMBX] Setting parameter failed with status 8
> >>1.709 [ ERROR ?][youbot] setDefParam: setting param nr ? to 3 failed.
> pwd?
> >>1.712 [ ERROR ?][youbot::sendMBX] Setting parameter failed with status 8
> >>1.712 [ ERROR ?][youbot] setDefParam: setting param nr ? to 3 failed.
> pwd?
> >>1.715 [ ERROR ?][youbot::sendMBX] Setting parameter failed with status 8
> >>1.715 [ ERROR ?][youbot] setDefParam: setting param nr ? to 3 failed.
> pwd?
> >>1.718 [ ERROR ?][youbot::sendMBX] Setting parameter failed with status 3
> >>1.718 [ ERROR ?][youbot] setDefParam: failed to read param nr ?
> >>.....Arm calibration failed.
> >>Base calibration failed.
> >>INFO: created undeclared connector root.initial
> >>rfsm_timeevent: time-event extension loaded
> >>Please run "youbot_test_help()" for information on available functions
> >>>?
> >>
> >>
> >>It would be of great if you can help me fix this.
> >>
> >>
> >It sounds like you are not able to access/communicate to ethercat devices
> on the youBot...
> >Could you please check the following:
> >1) Do you have rights to access to these devices (i.e. run fix_caps.sh in
> youbot_driver_rtt ) ?
> >2) Are the "run/stop" button(s) on the youbot on? If not, it is likely
> that you have only the onboard pc powered, and not the youBot Base and
> Arm...
> >
> >
> >Regards,
> >- Enea
> >
> >
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.mech.kuleuven.be/pipermail/orocos-users/attachments/2013021...
>
> ------------------------------
>
> Message: 3
> Date: Mon, 18 Feb 2013 13:36:26 +0100
> From: Hugo A Garcia <hugo [dot] a [dot] garcia [..] ...>
> Subject: Re: [Orocos-users] User Survey: Deployment Tool Used
> To: Nico Hochgeschwender <nico [dot] hochgeschwender [..] ...>
> Cc: "orocos-users [..] ..."
> <orocos-users [..] ...>
> Message-ID:
> <CADrVvHwpwKDbq+Oucvdv1=
> 4ApZ-9jxQBOd6B5FanRjNoSLxLQQ [..] ...>
> Content-Type: text/plain; charset="utf-8"
>
> On Mon, Feb 18, 2013 at 1:33 PM, Nico Hochgeschwender <
> nico [dot] hochgeschwender [..] ...> wrote:
>
> > Hi
> >>
> >> I would appreciate if you could reply to this email stating which
> >> deployment toolS you use:
> >>
> >
> > What's the objective for the survey?
> >
> > Nico
>
>
>
> > The objective of the survey is to get a feel of what users are currently
> > using for deployment.
> >
> > -H
> >
> >
> >
> >> 1) XML
> >> 2) Orocos Script
> >> 3) Lua
> >> 4) Rock
> >> 5) Other
> >>
> >> Thank you in advance
> >>
> >> -H
> >>
> >>
> >
> >
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.mech.kuleuven.be/pipermail/orocos-users/attachments/2013021...
>
> ------------------------------
>
> Message: 4
> Date: Mon, 18 Feb 2013 13:33:09 +0100
> From: Nico Hochgeschwender <nico [dot] hochgeschwender [..] ...>
> Subject: Re: [Orocos-users] User Survey: Deployment Tool Used
> To: Hugo A Garcia <hugo [dot] a [dot] garcia [..] ...>
> Cc: "orocos-users [..] ..."
> <orocos-users [..] ...>
> Message-ID:
> <20130218133309 [dot] 1zplyks2ogkoow0w [..] ...>
> Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes";
> format="flowed"
>
> > Hi
> >
> > I would appreciate if you could reply to this email stating which
> > deployment toolS you use:
>
> What's the objective for the survey?
>
> Nico
>
>
> >
> > 1) XML
> > 2) Orocos Script
> > 3) Lua
> > 4) Rock
> > 5) Other
> >
> > Thank you in advance
> >
> > -H
> >
>
>
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 18 Feb 2013 13:46:38 +0100
> From: Enea Scioni <scnnee [..] ...>
> Subject: Re: [Orocos-users] User Survey: Deployment Tool Used
> To: Hugo A Garcia <hugo [dot] a [dot] garcia [..] ...>
> Cc: "orocos-users [..] ..."
> <orocos-users [..] ...>
> Message-ID:
> <
> CALQ8SFA824YCoAhfUSAS_fiGg_jM+PdyVr4kouu+JZEhhKy0Ag [..] ...>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi,
>
> I would appreciate if you could reply to this email stating which
> > deployment toolS you use:
>
>
> In "frequency of use" order:
>
> 1)Lua (rttlua)
> 2)XML (deployer / deployer-gnulinux)
> 3)XML + ops (deployer / deployer-gnulinux)
>
> Most of the time wrapped into bash scripts or ROS Launch files...
>
> - Enea
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.mech.kuleuven.be/pipermail/orocos-users/attachments/2013021...
>
> ------------------------------
>
> _______________________________________________
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
>
> End of Orocos-Users Digest, Vol 69, Issue 26
> ********************************************
>

User Survey: Deployment Tool Used

> Hi
>
> I would appreciate if you could reply to this email stating which
> deployment toolS you use:

What's the objective for the survey?

Nico

>
> 1) XML
> 2) Orocos Script
> 3) Lua
> 4) Rock
> 5) Other
>
> Thank you in advance
>
> -H
>

User Survey: Deployment Tool Used

On Mon, Feb 18, 2013 at 1:33 PM, Nico Hochgeschwender <
nico [dot] hochgeschwender [..] ...> wrote:

> Hi
>>
>> I would appreciate if you could reply to this email stating which
>> deployment toolS you use:
>>
>
> What's the objective for the survey?
>
> Nico

> The objective of the survey is to get a feel of what users are currently
> using for deployment.
>
> -H
>
>
>
>> 1) XML
>> 2) Orocos Script
>> 3) Lua
>> 4) Rock
>> 5) Other
>>
>> Thank you in advance
>>
>> -H
>>
>>
>
>
>
>