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
>
>

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

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

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
>

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 [..] ... 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
>