On 11/23/2010 05:42 PM, Tinne De Laet wrote:
> First of all I think the documentation page about the workflow
> (http://www.orocos.org/dfki/orogen/workflow.html) is missing.
> This way I could not find what command I actually had to use to create
> c++ code from my test.orogen file.
> Since the documentation is not on the wiki, there was also no way I
> could help to complete the documentation.
I have that page ready but I am waiting for other stuff to be ready
before releasing "everything", i.e. orogen for RTT2 + a lot of other
stuff related ot orogen. I just attached the oroGen cheat sheet to this
mail with (hopefully) the missing information.

> The first thing I was puzzled about is about what exactly should be in
> my test.orogen file ... as an example I forgot to define my namespace,
> resulting in an awkward error.
> I think it would definitely help if there is an example file that
> could be downloaded.
orogen create <directory> gives you such a template. You have been hit
by the "missing workflow page" problem.

> Next, I was expecting that the generated component would just inherit
> from TaskContext, but apparently the generated component inherits from
> TaskBase. However, I don't find the TaskBase in the orogen
> API(http://www.orocos.org/dfki/api/orogen/index.html).
> Why is orogen not generating a component that directly inherits from
> TaskContext?
Because orogen does not touch your code. So, if you modify the spec (add
properties, operations, ports, ...), they get added to the Base class.
Base is not in the API documentation as it is part of the code
generation thing, really.

> Another problem I have with the generated code is that the generated
> TaskBase also includes an activity. I don't want to attach an activity
> to my TaskContext at compilation time. I want to attach one at
> configuration time.
Yes, and the taskbase does *not* include an activity. The version you
are using is simply giving an accessor for a "default activity", which
was meant for simplicity reasons. I just removed that accessor by the way.

> Another functionality I was missing at first sight is the decoupling
> between deployement and property initialization.
> It seems that you have to set the value of the properties in your
> deployement blocks with something like: my_task.property = new_value
> In my use cases however I usually have components that read some
> properties from a application-wide property file.
> Is it possible to do something like this in orogen?
The nominal workflow in the orogen-centric toolchain is

* write your tasks. They *are* activity-independent and get compiled
into a task library. With oroGen master, if OCL is installed, that
task library should be loadable in the deployer.
* create deployment processes. The only setup you do there is
assign an activity to a task. Other stuff (setting properties,
connecting ports, ...) is really meant for testing purposes.
* finally, setup and startup your system either with a Ruby script (it
is very simple and requires no knowledge of Ruby, really !) or the
supervision system (more complex, but a lot more powerful).

> Hope my comments and questions help to give a first impression how
> dummy orocos users are working with orogen.
Yes, and this is greatly appreciated. You are being hit by the "not
properly documented problem" that we are fixing at this very moment ;-)

On Tue, Nov 23, 2010 at 19:48, Sylvain Joyeux <sylvain [dot] joyeux [..] ...> wrote:
> On 11/23/2010 05:42 PM, Tinne De Laet wrote:
>> First of all I think the documentation page about the workflow
>> (http://www.orocos.org/dfki/orogen/workflow.html) is missing.
>> This way I could not find what command I actually had to use to create
>> c++ code from my test.orogen file.
>> Since the documentation is not on the wiki, there was also no way I
>> could help to complete the documentation.
> I have that page ready but I am waiting for other stuff to be ready
> before releasing "everything", i.e. orogen for RTT2 + a lot of other
> stuff related ot orogen. I just attached the oroGen cheat sheet to this
> mail with (hopefully) the missing information.
>
>> The first thing I was puzzled about is about what exactly should be in
>> my test.orogen file ... as an example I forgot to define my namespace,
>> resulting in an awkward error.
>> I think it would definitely help if there is an example file that
>> could be downloaded.
> orogen create <directory> gives you such a template. You have been hit
> by the "missing workflow page" problem.
>
>> Next, I was expecting that the generated component would just inherit
>> from TaskContext, but apparently the generated component inherits from
>> TaskBase. However, I don't find the TaskBase in the orogen
>> API(http://www.orocos.org/dfki/api/orogen/index.html).
>> Why is orogen not generating a component that directly inherits from
>> TaskContext?
> Because orogen does not touch your code. So, if you modify the spec (add
> properties, operations, ports, ...), they get added to the Base class.
> Base is not in the API documentation as it is part of the code
> generation thing, really.
>
>> Another problem I have with the generated code is that the generated
>> TaskBase also includes an activity. I don't want to attach an activity
>> to my TaskContext at compilation time. I want to attach one at
>> configuration time.
> Yes, and the taskbase does *not* include an activity. The version you
> are using is simply giving an accessor for a "default activity", which
> was meant for simplicity reasons. I just removed that accessor by the way.
>
>> Another functionality I was missing at first sight is the decoupling
>> between deployement and property initialization.
>> It seems that you have to set the value of the properties in your
>> deployement blocks with something like: my_task.property = new_value
>> In my use cases however I usually have components that read some
>> properties from a application-wide property file.
>> Is it possible to do something like this in orogen?
> The nominal workflow in the orogen-centric toolchain is
>
>  * write your tasks. They *are* activity-independent and get compiled
>    into a task library. With oroGen master, if OCL is installed, that
>    task library should be loadable in the deployer.
>  * create deployment processes. The only setup you do there is
>    assign an activity to a task. Other stuff (setting properties,
>    connecting ports, ...) is really meant for testing purposes.
>  * finally, setup and startup your system either with a Ruby script (it
>    is very simple and requires no  knowledge of Ruby, really !) or the
>    supervision system (more complex, but a lot more powerful).
>
>> Hope my comments and questions help to give a first impression how
>> dummy orocos users are working with orogen.
> Yes, and this is greatly appreciated. You are being hit by the "not
> properly documented problem" that we are fixing at this very moment ;-)

Thanks for all the useful additional information! I will try it out as
soon as I can find some free time.
Looking forward to the completed docs too ;)

Thanks,

Tinne