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

> On Wed, Apr 16, 2008 at 5:07 PM, snrkiwi <kiwi.net at mac [dot] com> 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 porti 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.

On Thu, Apr 17, 2008 at 2:16 PM, Stephen Roderick <kiwi.net at mac [dot] com> wrote:
> On Apr 17, 2008, at 08:12 , Klaas Gadeyne wrote:
> > On Wed, Apr 16, 2008 at 5:07 PM, snrkiwi <kiwi.net at mac [dot] com> 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
> porti 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

On Thu, Apr 17, 2008 at 2:32 PM, Klaas Gadeyne <klaas.gadeyne at gmail [dot] com> wrote:
[...]
> Even creating a non-real-time porti 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
<https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=533>

Klaas

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

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