A successful orocos use case

Hello,

I wanted to report about a just-finished project where we successfully
used orocos.

The Grand Cooperative Driving Challenge a.k.a GCDC (http://www.gcdc.net)
was recently held at Helmond, the Netherlands. The challenge was to have
vehicles drive autonomously in a platoon, using various sensors and
wireless communication. We at Kungliga Tekniska Högskolan (Royal
Institute of Technology) in Stockholm, Sweden teamed up with Scania CV
(a Swedish heavy truck manufacturer) and participated in the event.
http://scoop.md.kth.se

A part of our autonomous control system was an x86 based computer
running orocos. This part was responsible for overall supervision, data
i/o over the GPS, CAN, and wireless interfaces, data estimation, fusion,
logging and some platooning logic. The vehicle control was done with a
separate microcontroller using automatically generated code from Simulink.

The system performed extremely well and we are very happy with the
orocos framework. Due to some algorithm related issues, our team dropped
to 4th place in the overall rankings, but the orocos based framework was
reliable, consistent and "just worked and got out of the way."

Hardware: Home made box with Intel Atom based dual core processor on a
mini-itx motherboard.
OS: Ubuntu 10.04 server amd64 build with xenomai-2.5.5.2. However, we
used the gnulinux target for orocos
Orocos version: rtt 1.10.4 and ocl 1.10.2

One reflection on the use of orocos is as follows:

As has been mentioned elsewhere, orocos is for power users. I had to
prepare the various taskcontexts and their connections and basically
give our students {}'s within which to place their code, after giving
them some idea of how the overall system worked.

At a more abstract level, there is a different question: When/why should
orocos (or anything that requires HAND-written C/C++ code) be used. Most
other teams basically used Simulink autogenerated code and/or dSpace
boxes and/or National Instruments prototyping tools where the designers
could focus on dragging and connecting blocks without worrying about
memory issues and segmentation faults. They used C only where absolutely
necessary (e.g.: getting data in via wireless). Our team actually spent
a lot of time training students to write good code. Sometimes the better
programmers had to re-write poorly coded implementations and so on. Even
though it all worked out in the end, there wasn't a good answer to the
occasional, "I am a control/kalman filtering/estimation guy. My code
works in Matlab/Simulink.. I really don't want to care about what a
thread is and what a blocking function is."

In case someone is curious or wants to know more, I am willing to write
a small text detailing how we used orocos and how it fit into the rest
of our system.

Thanks for everything,
Sagar

A successful orocos use case

On Wed, 18 May 2011, Sagar Behere wrote:

> Hello,
>
> I wanted to report about a just-finished project where we successfully
> used orocos.

Thanks! Much appreciated. (Hopefully more users will follow your example :-))

> The Grand Cooperative Driving Challenge a.k.a GCDC (http://www.gcdc.net)
> was recently held at Helmond, the Netherlands. The challenge was to have
> vehicles drive autonomously in a platoon, using various sensors and
> wireless communication. We at Kungliga Tekniska Högskolan (Royal
> Institute of Technology) in Stockholm, Sweden teamed up with Scania CV
> (a Swedish heavy truck manufacturer) and participated in the event.
> http://scoop.md.kth.se
>
> A part of our autonomous control system was an x86 based computer
> running orocos. This part was responsible for overall supervision, data
> i/o over the GPS, CAN, and wireless interfaces, data estimation, fusion,
> logging and some platooning logic. The vehicle control was done with a
> separate microcontroller using automatically generated code from Simulink.
>
> The system performed extremely well and we are very happy with the
> orocos framework. Due to some algorithm related issues, our team dropped
> to 4th place in the overall rankings, but the orocos based framework was
> reliable, consistent and "just worked and got out of the way."
>
> Hardware: Home made box with Intel Atom based dual core processor on a
> mini-itx motherboard.
> OS: Ubuntu 10.04 server amd64 build with xenomai-2.5.5.2. However, we
> used the gnulinux target for orocos
> Orocos version: rtt 1.10.4 and ocl 1.10.2
>
> One reflection on the use of orocos is as follows:
>
> As has been mentioned elsewhere, orocos is for power users. I had to
> prepare the various taskcontexts and their connections and basically
> give our students {}'s within which to place their code, after giving
> them some idea of how the overall system worked.
>
> At a more abstract level, there is a different question: When/why should
> orocos (or anything that requires HAND-written C/C++ code) be used. Most
> other teams basically used Simulink autogenerated code and/or dSpace
> boxes and/or National Instruments prototyping tools where the designers
> could focus on dragging and connecting blocks without worrying about
> memory issues and segmentation faults. They used C only where absolutely
> necessary (e.g.: getting data in via wireless). Our team actually spent
> a lot of time training students to write good code. Sometimes the better
> programmers had to re-write poorly coded implementations and so on. Even
> though it all worked out in the end, there wasn't a good answer to the
> occasional, "I am a control/kalman filtering/estimation guy. My code
> works in Matlab/Simulink.. I really don't want to care about what a
> thread is and what a blocking function is."

They don't have to care about those things in Orocos either. And it remains
possible to deploy Simulink-generated code in an Orocos component.

_The_ reason to use Orocos should be that you want to integrate lots of
different frameworks, for the cases in which none of them provides
everything by itself.

Matlab/Simulink/RealTime Workbench _is_ getting closer to the Orocos/RTT
goals, but at a significant cost (financial and vendor lock-in).

> In case someone is curious or wants to know more, I am willing to write
> a small text detailing how we used orocos and how it fit into the rest
> of our system.

A "user story" would fit nice on the Orocos website. But your current
summary is already perfect for that purpose!

> Thanks for everything,
> Sagar

Thanks for using!

Herman

A successful orocos use case

2011/5/18 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>

> On Wed, 18 May 2011, Sagar Behere wrote:
>
> Hello,
>>
>> I wanted to report about a just-finished project where we successfully
>> used orocos.
>>
>
> Thanks! Much appreciated. (Hopefully more users will follow your example
> :-))
>
>
> The Grand Cooperative Driving Challenge a.k.a GCDC (http://www.gcdc.net)
>> was recently held at Helmond, the Netherlands. The challenge was to have
>> vehicles drive autonomously in a platoon, using various sensors and
>> wireless communication. We at Kungliga Tekniska Högskolan (Royal
>> Institute of Technology) in Stockholm, Sweden teamed up with Scania CV
>> (a Swedish heavy truck manufacturer) and participated in the event.
>> http://scoop.md.kth.se
>>
>> A part of our autonomous control system was an x86 based computer
>> running orocos. This part was responsible for overall supervision, data
>> i/o over the GPS, CAN, and wireless interfaces, data estimation, fusion,
>> logging and some platooning logic. The vehicle control was done with a
>> separate microcontroller using automatically generated code from Simulink.
>>
>> The system performed extremely well and we are very happy with the
>> orocos framework. Due to some algorithm related issues, our team dropped
>> to 4th place in the overall rankings, but the orocos based framework was
>> reliable, consistent and "just worked and got out of the way."
>>
>> Hardware: Home made box with Intel Atom based dual core processor on a
>> mini-itx motherboard.
>> OS: Ubuntu 10.04 server amd64 build with xenomai-2.5.5.2. However, we
>> used the gnulinux target for orocos
>> Orocos version: rtt 1.10.4 and ocl 1.10.2
>>
>> One reflection on the use of orocos is as follows:
>>
>> As has been mentioned elsewhere, orocos is for power users. I had to
>> prepare the various taskcontexts and their connections and basically
>> give our students {}'s within which to place their code, after giving
>> them some idea of how the overall system worked.
>>
>> At a more abstract level, there is a different question: When/why should
>> orocos (or anything that requires HAND-written C/C++ code) be used. Most
>> other teams basically used Simulink autogenerated code and/or dSpace
>> boxes and/or National Instruments prototyping tools where the designers
>> could focus on dragging and connecting blocks without worrying about
>> memory issues and segmentation faults. They used C only where absolutely
>> necessary (e.g.: getting data in via wireless). Our team actually spent
>> a lot of time training students to write good code. Sometimes the better
>> programmers had to re-write poorly coded implementations and so on. Even
>> though it all worked out in the end, there wasn't a good answer to the
>> occasional, "I am a control/kalman filtering/estimation guy. My code
>> works in Matlab/Simulink.. I really don't want to care about what a
>> thread is and what a blocking function is."
>>
>
> They don't have to care about those things in Orocos either. And it remains
> possible to deploy Simulink-generated code in an Orocos component.
>
> _The_ reason to use Orocos should be that you want to integrate lots of
> different frameworks, for the cases in which none of them provides
> everything by itself.
>
> Matlab/Simulink/RealTime Workbench _is_ getting closer to the Orocos/RTT
> goals, but at a significant cost (financial and vendor lock-in).
>
>
> In case someone is curious or wants to know more, I am willing to write
>> a small text detailing how we used orocos and how it fit into the rest
>> of our system.
>>
>
>
> A "user story" would fit nice on the Orocos website. But your current
> summary is already perfect for that purpose!
>
>
+1, please do write details somewhere

> Thanks for everything,
>> Sagar
>>
>
> Thanks for using!
>
> Herman
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
>

A successful orocos use case

2011/5/18 Sagar Behere <sagar [dot] behere [..] ...>

>
> At a more abstract level, there is a different question: When/why should
> orocos (or anything that requires HAND-written C/C++ code) be used. Most
> other teams basically used Simulink autogenerated code and/or dSpace
> boxes and/or National Instruments prototyping tools where the designers
> could focus on dragging and connecting blocks without worrying about
> memory issues and segmentation faults. They used C only where absolutely
> necessary (e.g.: getting data in via wireless). Our team actually spent
> a lot of time training students to write good code. Sometimes the better
> programmers had to re-write poorly coded implementations and so on. Even
> though it all worked out in the end, there wasn't a good answer to the
> occasional, "I am a control/kalman filtering/estimation guy. My code
> works in Matlab/Simulink.. I really don't want to care about what a
> thread is and what a blocking function is."
>
>
We had the same issues to make the bridge between the "simulink/algorithm
guys" and the coders in some of our projects. As part of my PhD project, I
use Orocos v1.X with the Orocos RTW target for Simulink
[1]. This allows me to perform rapid prototyping of control algorithms
and test them easily on the bench. Surprisingly,
the code generated by Simulink is very optimized and the computation time is
excellent, even with several matrix operations. Moreover, there's no problem
with memory allocation and real-time stuff, since all the memory is
initialized in the configureHook. However, the generated code becomes a kind
of black box and is difficult to debug. Nevertheless, the Orocos RTW target
has been a very useful tool during prototyping.

Philippe

[1] http://www.orocos.org/simulink

A successful orocos use case

On Wed, May 18, 2011 at 14:54, Philippe Hamelin
<philippe [dot] hamelin [..] ...>wrote:

> 2011/5/18 Sagar Behere <sagar [dot] behere [..] ...>
>
>>
>> At a more abstract level, there is a different question: When/why should
>> orocos (or anything that requires HAND-written C/C++ code) be used. Most
>> other teams basically used Simulink autogenerated code and/or dSpace
>> boxes and/or National Instruments prototyping tools where the designers
>> could focus on dragging and connecting blocks without worrying about
>> memory issues and segmentation faults. They used C only where absolutely
>> necessary (e.g.: getting data in via wireless). Our team actually spent
>> a lot of time training students to write good code. Sometimes the better
>> programmers had to re-write poorly coded implementations and so on. Even
>> though it all worked out in the end, there wasn't a good answer to the
>> occasional, "I am a control/kalman filtering/estimation guy. My code
>> works in Matlab/Simulink.. I really don't want to care about what a
>> thread is and what a blocking function is."
>>
>>
> We had the same issues to make the bridge between the "simulink/algorithm
> guys" and the coders in some of our projects.
>

In general the benefit of the tools like Simulink and RTW is that it allows
you to do your job
closer to the problem domain (a matrix equations of a Kalman filter) rather
than a solution
domain (a low-level C/C++ matrix manipulation).

This idea fits nicely with the model-driven engineering and domain specific
languages approach.
Simply do your job with a right tool (domain-specific language) and leave
the transformation to
the final artifact (C/C++ code) to an expert (an automated model-to-text
transformation).

I believe, that with the right toolset the Orocos can be successfully used
as "only a runtime",
so the simulink/algorithm guys will not even notice a difference.

A successful orocos use case

On Tue, 24 May 2011, Piotr Trojanek wrote:

> On Wed, May 18, 2011 at 14:54, Philippe Hamelin <philippe [dot] hamelin [..] ...philippe [dot] hamelin [..] ...>> wrote:
> 2011/5/18 Sagar Behere <sagar [dot] behere [..] ...sagar [dot] behere [..] ...>>
>
> At a more abstract level, there is a different question: When/why should
> orocos (or anything that requires HAND-written C/C++ code) be used. Most
> other teams basically used Simulink autogenerated code and/or dSpace
> boxes and/or National Instruments prototyping tools where the designers
> could focus on dragging and connecting blocks without worrying about
> memory issues and segmentation faults. They used C only where absolutely
> necessary (e.g.: getting data in via wireless). Our team actually spent
> a lot of time training students to write good code. Sometimes the better
> programmers had to re-write poorly coded implementations and so on. Even
> though it all worked out in the end, there wasn't a good answer to the
> occasional, "I am a control/kalman filtering/estimation guy. My code
> works in Matlab/Simulink.. I really don't want to care about what a
> thread is and what a blocking function is."
>
>
> We had the same issues to make the bridge between the "simulink/algorithm guys" and the coders in some of our projects.
>
> In general the benefit of the tools like Simulink and RTW is that it allows you to do your job
> closer to the problem domain (a matrix equations of a Kalman filter) rather than a solution
> domain (a low-level C/C++ matrix manipulation).
>
> This idea fits nicely with the model-driven engineering and domain specific languages approach.
> Simply do your job with a right tool (domain-specific language) and leave the transformation to
> the final artifact (C/C++ code) to an expert (an automated model-to-text transformation).
>
> I believe, that with the right toolset the Orocos can be successfully used as "only a runtime",
> so the simulink/algorithm guys will not even notice a difference.

I agree.

But there is room for an open source replacement for Simulink (and its
toolchain) nevertheless! :-)

Any takers...?

> Piotr Trojanek

Herman

> Robot Control and Recognition Systems Team<http://robotics.ia.pw.edu.pl />,
> Institute of Control & Computation Engineering<http://www.ia.pw.edu.pl/iaiis_en />,<http://www.ia.pw.edu.pl />
> Warsaw University of Technology<http://eng.pw.edu.pl />