Evaluating Orocos

We are evaluating using Orocos for a couple of different robotics projects, and I was hoping to get some feedback from some of the more experienced users. Specific questions we have are

* Has anyone ported RTT+KDL+OCL to the Mac (we currently don't need BFL)? We need to run the system on both Mac and Linux. I noticed a post that someone had KDL compiling on a Mac, but we'd need RTT and OCL also. Mostly this looks like porting RTT to a new O/S, which it's been setup nicely to do.
* Has anyone used Orocos in a truly safety-critical system? If so, any impressions you could share?
* Does anyone have any long-term experience with the reliability of Tao/Corba for the distributed aspects of Orocos?
* Does anyone have any measurements of the latency and jitter on periodic/aperiodic commands and data, sent between processes using Corba?
* One of the thorny design issues we foresee is the ability to switch between multiple controllers, and see at least a couple of different ways to do this with Orocos' components. Any suggestions on these 3 possible approaches below (or any other approaches you can think of)?
## Model the controllers as one component, and internally switch between the controllers. This muddies the component interface as it now needs to be the union of all possible data/parameters used by all internal controllers (e.g. some of our cartesian controllers use no force-torque data, or data from 1 sensor, or even data from 2 sensors)
## Model the controllers as individual components, and "turn on" only the currently active controller. We're a little worried about any possible lag in switching time here, though doubt that it would really be an issue
## Model the controllers in a hierarchical fashion, though we're not sure if this is even possible in Orocos (or in general)?

Any other general feedback definitely appreciated. Overall Orocos looks like a great tool, and we'd love to use it. We just need to make sure it will truly fit our needs.

Thanks
Stephen

Evaluating Orocos

On Wed, Apr 16, 2008 at 5:07 PM, snrkiwi <kiwi [dot] net [..] ...> wrote:
> We are evaluating using Orocos for a couple of different robotics projects,
> and I was hoping to get some feedback from some of the more experienced
> users. Specific questions we have are
>
> * Has anyone ported RTT+KDL+OCL to the Mac (we currently don't need BFL)?
> We need to run the system on both Mac and Linux. I noticed a post that
> someone had KDL compiling on a Mac, but we'd need RTT and OCL also. Mostly
> this looks like porting RTT to a new O/S, which it's been setup nicely to
> do.

No, and IMO it would be somewhat har to do. The problem with Mac OS X
is it offers a POSIX API but doesn't implement POSIX real-time
extensions. If you are really interested, I might still have an
initial attempt lingering around on my macbook.

Evaluating Orocos

On Wed, 16 Apr 2008, snrkiwi wrote:

> We are evaluating using Orocos for a couple of different robotics projects,
> and I was hoping to get some feedback from some of the more experienced
> users. Specific questions we have are
>
> * Has anyone ported RTT+KDL+OCL to the Mac (we currently don't need BFL)? We
> need to run the system on both Mac and Linux. I noticed a post that someone
> had KDL compiling on a Mac, but we'd need RTT and OCL also. Mostly this looks
> like porting RTT to a new O/S, which it's been setup nicely to do.

Nobody has ever mentioned a full version of Orocos running on the Mac...

[...CORBA...]
The FMTC people will probably have more to say about this.

[...]
> * One of the thorny design issues we foresee is the ability to switch between
> multiple controllers, and see at least a couple of different ways to do this
> with Orocos' components. Any suggestions on these 3 possible approaches below
> (or any other approaches you can think of)?
> ## Model the controllers as one component, and internally switch between the
> controllers. This muddies the component interface as it now needs to be the
> union of all possible data/parameters used by all internal controllers (e.g.
> some of our cartesian controllers use no force-torque data, or data from 1
> sensor, or even data from 2 sensors)
> ## Model the controllers as individual components, and "turn on" only the
> currently active controller. We're a little worried about any possible lag in
> switching time here, though doubt that it would really be an issue
> ## Model the controllers in a hierarchical fashion, though we're not sure if
> this is even possible in Orocos (or in general)?

We have used a FSM to do switching of controllers, with transition states
to do the switching as a linear "fade out" of the old controller together
with a linear "fade in" of the new one, both working on the Cartesian
endpoint velocity of the robot. This is your first option, I guess. The
reason we did it was exactly to be able to share the state of two
controllers with a minimum of overhead.

> Any other general feedback definitely appreciated. Overall Orocos looks like
> a great tool, and we'd love to use it. We just need to make sure it will
> truly fit our needs.
Thanks for asking these stimulating questions :-)

Herman

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Evaluating Orocos

>> * One of the thorny design issues we foresee is the ability to
>> switch between multiple controllers, and see at least a couple of
>> different ways to do this with Orocos' components. Any suggestions
>> on these 3 possible approaches below (or any other approaches you
>> can think of)?
>> ## Model the controllers as one component, and internally switch
>> between the controllers. This muddies the component interface as it
>> now needs to be the union of all possible data/parameters used by
>> all internal controllers (e.g. some of our cartesian controllers
>> use no force-torque data, or data from 1 sensor, or even data from
>> 2 sensors)
>> ## Model the controllers as individual components, and "turn on"
>> only the currently active controller. We're a little worried about
>> any possible lag in switching time here, though doubt that it would
>> really be an issue
>> ## Model the controllers in a hierarchical fashion, though we're
>> not sure if this is even possible in Orocos (or in general)?
>
> We have used a FSM to do switching of controllers, with transition
> states
> to do the switching as a linear "fade out" of the old controller
> together
> with a linear "fade in" of the new one, both working on the Cartesian
> endpoint velocity of the robot. This is your first option, I guess.
> The
> reason we did it was exactly to be able to share the state of two
> controllers with a minimum of overhead.

I don't suppose you could describe the structure of this solution a
little more? Did the component containing the FSM also contain all the
different controllers, and it internally switched between them (same
structure as my first proposed solution, above)? Or did the FSM
component just turn on/off certain other separate controller
components (proposed solution 2 above)? This is one of the areas we're
currently unclear of how it would be best to design using Orocos.

Any help appreciated
S

Evaluating Orocos

On Fri, 18 Apr 2008, Stephen Roderick wrote:

>>> * One of the thorny design issues we foresee is the ability to switch
>>> between multiple controllers, and see at least a couple of different ways
>>> to do this with Orocos' components. Any suggestions on these 3 possible
>>> approaches below (or any other approaches you can think of)?
>>> ## Model the controllers as one component, and internally switch between
>>> the controllers. This muddies the component interface as it now needs to
>>> be the union of all possible data/parameters used by all internal
>>> controllers (e.g. some of our cartesian controllers use no force-torque
>>> data, or data from 1 sensor, or even data from 2 sensors)
>>> ## Model the controllers as individual components, and "turn on" only the
>>> currently active controller. We're a little worried about any possible lag
>>> in switching time here, though doubt that it would really be an issue
>>> ## Model the controllers in a hierarchical fashion, though we're not sure
>>> if this is even possible in Orocos (or in general)?
>>
>> We have used a FSM to do switching of controllers, with transition states
>> to do the switching as a linear "fade out" of the old controller together
>> with a linear "fade in" of the new one, both working on the Cartesian
>> endpoint velocity of the robot. This is your first option, I guess. The
>> reason we did it was exactly to be able to share the state of two
>> controllers with a minimum of overhead.
>
> I don't suppose you could describe the structure of this solution a little
> more? Did the component containing the FSM also contain all the different
> controllers, and it internally switched between them (same structure as my
> first proposed solution, above)?
Yes. FSM is the right concept to do exactly this: switching the "behaviour"
of one component.

> Or did the FSM component just turn on/off
> certain other separate controller components (proposed solution 2 above)?
No.

> This is one of the areas we're currently unclear of how it would be best to
> design using Orocos.

My rule of thumb is: put everything in one component with its own state
machine if you want to change the behaviour of that component; and only use
multiple components if (i) you want them to run (possibly in the future) in
multiple activities, or (ii) you don't want to (or simple cannot guarantee
to be able to) synchronize their behaviours, or (iii) the interface (e.g.
via the TaskBrowser) between two controllers is very different.

Orocos is designed to allow decoupling between making the decisions about
(i) how to design your system as a composition of components, and
(ii) in what activities ("treads") you want each component to run. I
realize this feature gives you so many options that making the most
appropriate decision for your particular problem can require some thinking :-)

Herman

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Evaluating Orocos

On Apr 17, 2008, at 08:12 , Klaas Gadeyne wrote:

> On Wed, Apr 16, 2008 at 5:07 PM, snrkiwi <kiwi [dot] net [..] ...> wrote:
>> We are evaluating using Orocos for a couple of different robotics
>> projects,
>> and I was hoping to get some feedback from some of the more
>> experienced
>> users. Specific questions we have are
>>
>> * Has anyone ported RTT+KDL+OCL to the Mac (we currently don't need
>> BFL)?
>> We need to run the system on both Mac and Linux. I noticed a post
>> that
>> someone had KDL compiling on a Mac, but we'd need RTT and OCL also.
>> Mostly
>> this looks like porting RTT to a new O/S, which it's been setup
>> nicely to
>> do.
>
> No, and IMO it would be somewhat har to do. The problem with Mac OS X
> is it offers a POSIX API but doesn't implement POSIX real-time
> extensions. If you are really interested, I might still have an
> initial attempt lingering around on my macbook.

Sorry, I should have been more specific. We're not looking to make the
Mac port real-time, realizing as you mentioned that the O/S just isn't
set up for that. Our goal would be to run either simulation or GUI
capabilities on a Mac, using Orocos. So any port of RTT would just use
the POSIX interface, but would simply downgrade any realtime requests
to non-realtime.

Evaluating Orocos

On Thu, Apr 17, 2008 at 2:16 PM, Stephen Roderick <kiwi [dot] net [..] ...> wrote:
> On Apr 17, 2008, at 08:12 , Klaas Gadeyne wrote:
> > On Wed, Apr 16, 2008 at 5:07 PM, snrkiwi <kiwi [dot] net [..] ...> wrote:
> >
> > > We are evaluating using Orocos for a couple of different robotics
> projects,
> > > and I was hoping to get some feedback from some of the more experienced
> > > users. Specific questions we have are
> > >
> > > * Has anyone ported RTT+KDL+OCL to the Mac (we currently don't need
> BFL)?
> > > We need to run the system on both Mac and Linux. I noticed a post that
> > > someone had KDL compiling on a Mac, but we'd need RTT and OCL also.
> Mostly
> > > this looks like porting RTT to a new O/S, which it's been setup nicely
> to
> > > do.
> > >
> >
> > No, and IMO it would be somewhat har to do. The problem with Mac OS X
> > is it offers a POSIX API but doesn't implement POSIX real-time
> > extensions. If you are really interested, I might still have an
> > initial attempt lingering around on my macbook.
> >
>
> Sorry, I should have been more specific.

/me too apparently :-)

> We're not looking to make the Mac
> port real-time, realizing as you mentioned that the O/S just isn't set up
> for that. Our goal would be to run either simulation or GUI capabilities on
> a Mac, using Orocos. So any port of RTT would just use the POSIX interface,
> but would simply downgrade any realtime requests to non-realtime.

Even creating a non-real-time port is not as trivial as expected.
What I did/tried (and which seemed the most logical way) is to start
from the (non-real-time) gnulinux port, and see where it failed.
>From the top of my head: Mac Os X (see src/os/gnulinux/fosi.h) does not have

- struct timespecs (worked around IIRC);
- the clock_gettime call, clock_gettime(CLOCK_REALTIME, &tv);
- recursive mutexes (worked around IIRC);

...

I'm not saying it's impossible (on the contrary), but I started with
the idea of porting RTT to mac os x in a
single-rainy-saturday-morning, and I failed miserabely.

regards,

Klaas

Evaluating Orocos

On Thu, Apr 17, 2008 at 2:32 PM, Klaas Gadeyne <klaas [dot] gadeyne [..] ...> wrote:
[...]
> Even creating a non-real-time port is not as trivial as expected.
> What I did/tried (and which seemed the most logical way) is to start
> from the (non-real-time) gnulinux port, and see where it failed.
> From the top of my head: Mac Os X (see src/os/gnulinux/fosi.h) does not have
>
> - struct timespecs (worked around IIRC);
> - the clock_gettime call, clock_gettime(CLOCK_REALTIME, &tv);
> - recursive mutexes (worked around IIRC);
>
> ...
>
> I'm not saying it's impossible (on the contrary), but I started with
> the idea of porting RTT to mac os x in a
> single-rainy-saturday-morning, and I failed miserabely.

In case you are not subscribed to orocos-dev, see

Klaas