I've been spending the last few weeks reading the Orocos manuals in order to evaluate Orocos' functionality as well as experimenting with a port to Visual Studio (which still needs a lot more work).
After reading the Orocos Components Manual I was left with the impression that scripts are the intended mechanism for controlling inter-task communication and that their equivalent is awkward to achieve directly in code. Am I wrong here?
In some scenarios, the application, which we will write, will be required to dynamically sequence the execution of its tasks according to a user's configuration. The number of possible configurations are likely to be too great to handle with simple if .. else statements in scripts. Instead, we may need code that does the following:
1) Holds a collection of tasks e.g. using a vector of tasks.
2) Configures these tasks via data ports.
3) Checks the properties of tasks in this collection to determine their state and when they are ready to execute.
4) Subscribe to events from the tasks in this collection to determine when they have completed execution.
5) Executes these tasks by causing them to run one of their programs or by forcing them to transition into a different state.
In Issue 1.6.0 of the Orocos Components Manual I've seen an example in page 68 of where code causes a program to run (the first part of number 5 above) and an example in page 112 where code seems to subscribe to events (number 4 above).
My question is how elegantly can 2, 3 and the second part of 5 be performed in code? Where scripts fail to supply us with the flexibility that we need can we easily replace them with code?
Thanks for your help.
Is it simple to control tasks through code rather than through s
Sorry for the late reply, kind-of missed this topic...
On Monday 19 January 2009 18:49:19 rparussel [..] ... wrote:
> I've been spending the last few weeks reading the Orocos manuals in order
> to evaluate Orocos' functionality as well as experimenting with a port to
> Visual Studio (which still needs a lot more work).
If everyone who started a port to Visual Studio could just show each other the
code, life would be so much easier (don't take this personal :-). Stuff you at
least might consider is located here:
<https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=605>
>
> After reading the Orocos Components Manual I was left with the impression
> that scripts are the intended mechanism for controlling inter-task
> communication and that their equivalent is awkward to achieve directly in
> code. Am I wrong here?
We aim for equivalence. Yet, state machines are easier to describe in
scripting, we don't really have an equally easy alternative in C++. Also
commands behave differently in C++ as in scripting. In C++ you need to write
code if you want to wait for command completion, in scripting, this is done
automatically for you. Other than that, there is not that much difference.
>
> In some scenarios, the application, which we will write, will be required
> to dynamically sequence the execution of its tasks according to a user's
> configuration. The number of possible configurations are likely to be too
> great to handle with simple if .. else statements in scripts. Instead, we
> may need code that does the following:
>
> 1) Holds a collection of tasks e.g. using a vector of tasks.
In Orocos speak, we would say ' a list of peer TaskContexts'
> 2) Configures these tasks via data ports.
What do you mean ? configure the tasks by connecting data ports or by writing
data to the ports ?
> 3) Checks the properties of tasks in this collection to determine their
> state and when they are ready to execute.
ok.
> 4) Subscribe to events from the
> tasks in this collection to determine when they have completed execution.
ok.
> 5) Executes these tasks by causing them to run one of their programs or by
> forcing them to transition into a different state.
ok.
>
> In Issue 1.6.0 of the Orocos Components Manual I've seen an example in page
> 68 of where code causes a program to run (the first part of number 5 above)
> and an example in page 112 where code seems to subscribe to events (number
> 4 above).
>
> My question is how elegantly can 2, 3 and the second part of 5 be performed
> in code? Where scripts fail to supply us with the flexibility that we need
> can we easily replace them with code?
I need more clarity about what you mean with 2.
For doing 3, make the task a peer and check the properties of the peer like
this:
If you need to do this in real-time, make 'par1' a member variable and do the
getProperty in configureHook() or so. In case every peer has par1, you could
also create an std::vector of Property objects.
For item 5, the best way to force a transition is to emit an event of the task
and react to that event in C++ or in a script statemachine.
To emit an event of a peer task, do:
task1 did register a C++ callback function on its 'change' event.
Hope this helps,
Peter
Thanks Peter, for your
Thanks Peter, for your detailed reply. It will be useful in the near future. I apologise for not replying earlier.
With regard to item 2 that I listed, we would need to write code that wrote data to ports on tasks.
Kind regards
Rick
Is it simple to control tasks through code rather than through
Hello,
I am also trying in my spare time to port Orocos under Windows with MinGW, which I
think is the quickest way. However, it would be very
interesting to have a Visual Studio port. Considering that MinGW uses the win32
API and CMake can generate Visual Studio projects, I am not very sure of the major differences between the two targets. To date, I managed without too
many problems to:
- Compile Boost with MinGW
- Compile ACE + TAO with MinGW / MSYS
- Generate Orocos project with CMake for Eclipse CDT / MinGW
The next steps are:
- Implement the FOSI for win32
- Add a "win32" target in the CMake files
Moreover, if someone has already implemented FOSI for win32, I would
really like to have these files to accelerate our development.
Also, since I am not
a CMake expert, your help would probably be required when adding the
win32 target.
Well, for futur tracking this talk would have been better on a more explicit topic.
Philippe Hamelin
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Sorry for the late reply, kind-of missed this topic...
On Monday 19 January 2009 18:49:19 rparussel [..] ... wrote:
> I've been spending the last few weeks reading the Orocos manuals in order
> to evaluate Orocos' functionality as well as experimenting with a port to
> Visual Studio (which still needs a lot more work).
If everyone who started a port to Visual Studio could just show each other the
code, life would be so much easier (don't take this personal :-). Stuff you at
least might consider is located here:
<https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=605>
>
> After reading the Orocos Components Manual I was left with the impression
> that scripts are the intended mechanism for controlling inter-task
> communication and that their equivalent is awkward to achieve directly in
> code. Am I wrong here?
We aim for equivalence. Yet, state machines are easier to describe in
scripting, we don't really have an equally easy alternative in C++. Also
commands behave differently in C++ as in scripting. In C++ you need to write
code if you want to wait for command completion, in scripting, this is done
automatically for you. Other than that, there is not that much difference.
>
> In some scenarios, the application, which we will write, will be required
> to dynamically sequence the execution of its tasks according to a user's
> configuration. The number of possible configurations are likely to be too
> great to handle with simple if .. else statements in scripts. Instead, we
> may need code that does the following:
>
> 1) Holds a collection of tasks e.g. using a vector of tasks.
In Orocos speak, we would say ' a list of peer TaskContexts'
> 2) Configures these tasks via data ports.
What do you mean ? configure the tasks by connecting data ports or by writing
data to the ports ?
> 3) Checks the properties of tasks in this collection to determine their
> state and when they are ready to execute.
ok.
> 4) Subscribe to events from the
> tasks in this collection to determine when they have completed execution.
ok.
> 5) Executes these tasks by causing them to run one of their programs or by
> forcing them to transition into a different state.
ok.
>
> In Issue 1.6.0 of the Orocos Components Manual I've seen an example in page
> 68 of where code causes a program to run (the first part of number 5 above)
> and an example in page 112 where code seems to subscribe to events (number
> 4 above).
>
> My question is how elegantly can 2, 3 and the second part of 5 be performed
> in code? Where scripts fail to supply us with the flexibility that we need
> can we easily replace them with code?
I need more clarity about what you mean with 2.
For doing 3, make the task a peer and check the properties of the peer like
this:
<code>
TaskContext* peer = this->getPeer("task1");
Property<double> par1 = peer->properties()->getProperty<double>("par1");
if (par1.value() > some_thing ) {
// ...
}
// etc.
</code>
If you need to do this in real-time, make 'par1' a member variable and do the
getProperty in configureHook() or so. In case every peer has par1, you could
also create an std::vector of Property objects.
For item 5, the best way to force a transition is to emit an event of the task
and react to that event in C++ or in a script statemachine.
To emit an event of a peer task, do:
<code>
TaskContext* peer = this->getPeer("task1");
Event<void(void)> do_change = peer->events()->getEvent<void(void)>("change");
do_change(); // emits the event of task1
// etc.
</code>
task1 did register a C++ callback function on its 'change' event.
Hope this helps,
Peter
--
Peter Soetens -- FMTC -- <http://www.fmtc.be>
<font color="#888888">--
Orocos-Users mailing list
Orocos-Users [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
<font><blockquote>
Is it simple to control tasks through code rather than through s
On Jan 22, 2009, at 10:17 , Philippe Hamelin wrote:
> Hello,
>
> I am also trying in my spare time to port Orocos under Windows with
> MinGW, which I think is the quickest way. However, it would be very
> interesting to have a Visual Studio port. Considering that MinGW
> uses the win32 API and CMake can generate Visual Studio projects, I
> am not very sure of the major differences between the two targets.
> To date, I managed without too many problems to:
>
> - Compile Boost with MinGW
> - Compile ACE + TAO with MinGW / MSYS
> - Generate Orocos project with CMake for Eclipse CDT / MinGW
You compiled boost and ACE/TAO from source? What about cmake?
> The next steps are:
> - Implement the FOSI for win32
> - Add a "win32" target in the CMake files
Have you looked at using the pthreads-win32 package? Using its posix
layer and a combination of the gnulinux/macosx fosi's seems the most
straight-forward direction to me. That is certainly the direction I'm
leaning towards, and it sounds like Peter has walked this path
somewhat before ...
Cheers
Stephen
Is it simple to control tasks through code rather than through
Well we are having a discussion on two separates threads :)
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hello,
I am also trying in my spare time to port Orocos under Windows with MinGW, which I think is the quickest way. However, it would be very interesting to have a Visual Studio port. Considering that MinGW uses the win32 API and CMake can generate Visual Studio projects, I am not very sure of the major differences between the two targets. To date, I managed without too many problems to:
- Compile Boost with MinGW
- Compile ACE + TAO with MinGW / MSYS
- Generate Orocos project with CMake for Eclipse CDT / MinGW
<blockquote>
You compiled boost and ACE/TAO from source?
<blockquote>
Yes, I compiled Boost and ACE/TAO from source. To compile Boost from source, just download boost-src and bjam-ntx86. Unzip bjam in the boost source directory. Then execute :
bjam --toolset=gcc -sTOOL=mingw install
This will compile boost, install the headers and lib files in C:\Boost.
For ACE/TAO, it was quite easy except that I had a compilation problem. There's a typedef redefinition problem. I had to add a condition into os_types.h of ACE/TAO to not redefine the variable is we are using MINGW.
<blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">What about cmake?
<blockquote>
I used CMake to generate the Makefiles for MinGW. You can also use the Eclipse CDT/MinGW generator of CMake.
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The next steps are:
- Implement the FOSI for win32
- Add a "win32" target in the CMake files
<blockquote>
Have you looked at using the pthreads-win32 package? Using its posix layer and a combination of the gnulinux/macosx fosi's seems the most straight-forward direction to me. That is certainly the direction I'm leaning towards, and it sounds like Peter has walked this path somewhat before ...
<blockquote>
Yes pthreads for windows is something I will consider. However, the semaphore part of the FOSI has to be recoded anyways. Someone has already coded the win32 FOSI and we are still waiting for the patch :-). My direction is a bit different than Peter's way, since I'm not using Cygwin. By using MinGW I can compile native win32 application without being dependant of the Cygwin DLL, which is not very fast.
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Cheers
Stephen
<blockquote>
Regards,
Philippe Hamelin