---------- Forwarded message ----------
From: S Roderick <kiwi [dot] net [..] ...>
Date: 2015-08-03 23:11 GMT+02:00
Subject: Re: [Orocos-users] Real-time control using Orocos
To: Andrew Porterman <andrew [dot] porterman [..] ...>
Cc: Orocos Users <orocos-users [..] ...>
On Aug 03, 2015, at 11:15, Andrew Porterman <andrew [dot] porterman [..] ...>
wrote:
Hi all,
Thank you for the quick reply!
2015-08-03 5:24 GMT+02:00 S Roderick <kiwi [dot] net [..] ...>:
> On Jul 31, 2015, at 13:52, Willy Lambert <lambert [dot] willy [..] ...> wrote:
>
>
>
>
> 2015-07-31 18:36 GMT+02:00 Andrew Porterman <andrew [dot] porterman [..] ...>:
>
>> Hi Orocos community,
>>
>> I'm working on a robotics project that requires real-time control.
>> I installed Orocos using the debian packages and I'm using ROS nodes next
>> to it (MoveIt!, vision etc.).
>> I played around with Orocos, but until know I was only using it on a
>> standard Ubuntu 14.04 installation.
>>
>> The project requires my controller to run with 1ms period.
>> The question is however: how to set-up Orocos in real-time (or online,
>> but at least more performant)?
>> I'm reluctant to really install xenomai, which seems cumbersome.
>> I saw on an old post on the forum (
>> http://www.orocos.org/forum/orocos/orocos-users/getting-started-orocos-l...
>> )
>> that I could install a real-time kernel in Ubuntu.
>> It states that there is no need for recompilation of the Orocos code, is
>> this correct? (compiler flags?)
>>
>
> Yes it's true, the only thing you need to recompile is your linux kernel
> modified with preemt-rt patches. I would say 1ms is the limit between the
> xenomai need and the preempt RT need, some application are know to work at
> 1ms perfectly with a prempt-rt vanilla kernel.
>
> Note that xenomai has moved ahead to 3.0 which should be by far easier to
> integrate as it would be transparently used under a posix "skin". I don't
> know if someone have already done that for now.
>
>
> We run several robot control applications at 2ms (500 Hz) on COTS PCs with
> Linux Preempt RT and have no problems. You have to be careful with
> application design, but overall Linux is more than capable for our work.
>
>
>
>> Is this enough to unlock the real-time behavior of Orocos?
>>
>
> The realtimeness is not an orocos property, it's your system property. And
> when you add the preemptRT patch to the linux kernel sources, it has
> nothing to do with Orocos, it's your OS that you setup (which is a part of
> your system).
>
> The fact you have Orocos or not will not provide you the realtimeness, you
> can still bullshit into your Orocos code or design. The "only" thing that
> Orocos does, is to be aware that some user need realtimeness. For instance
> you may reserve memory at startup in your data flow connectors (Ports). The
> API gives you a way to do it, but it will not do it for you.
>
> If you don't know how to do a "bare metal" realtime application, you
> certainly won't be able to do it with Orocos either. But if you do know how
> to manage that, Orocos will help you setting this us more easily and
> securely (for instance because synchronisation mecanism like mutex, signal,
> are embedded in the framework).
>
> I see, this is also my motivation to use Orocos in the first place.
>
>
>> Can I just run
>> $rosrun ocl deployer-gnulinux -s start.ops
>> I looked into the documentation on orocos.org, but I found only some
>> scattered information, some of it rather old or pointing to 1.x versions.
>> I try to give an overview of my questions in a more structured way here
>> below.
>>
>> 1 General Orocos functionality
>>
>> If I understand correctly:
>> -> all components that are dynamically deployed by deployer-gnulinux = 1
>> process
>>
>
> Yes
>
>
>> -> 1 component ~ 1 thread:
>>
>
> No
>
>
>> More correctly 1 component is run by an activity which assigns it to a
>> thread
>>
>
> No !!! You may attach several components to the same thread. Typically
> when having a sequence of periodic components in a chain, it's a better
> idea to use one thread to trig all those components.
>
>
> I’d say it depends. Sometimes you want many components processing data,
> and sometimes you want one component. It varies. But it is true that each
> component has an associated activity, but it is not that each activity has
> a thread.
>
That is where I'm left a bit confused.
The code documentation of the Activity class starts with: "An activity is
an object that represents a thread. ... One Activity object maps to one OS
thread."
http://www.orocos.org/stable/documentation/rtt/v2.x/api/html/classRTT_1_...
But the wiki documentation did indeed state the opposite…
The API doc’s are incorrect.
I also wonder what the effect is when multiple activities share the same
thread and you interact with the thread like this:
this->getActivity()->thread()
(
http://www.orocos.org/stable/documentation/rtt/v2.x/doc-xml/orocos-compo...
example 6.1)
As a rule, you shouldn’t need to (nor should you) access the thread itself.
There are exceptions, but they are definitely unusual ...
Orocos doesn't enforce any threading constraints. You have to design your
> threading yourself and make your own decisions. Cf previous explanations,
> this is required for real time applications, so Orocos is aware of that and
> let you do your job.
>
>
> Orocos provides the ability to thread things, and it isn’t always clear on
> when it does or doesn’t thread. You’ll have to get into the details within
> your own application.
>
What I'm doing now is:
1) I create components (taking into account proper RT design rules)
2) I assign an activity to the component = Is that what you mean with
'design your threading yourself', Willy?
It is at this level that Orocos wants me to design my threading, no?
Creating pthreads in an Orocos component is definitely not what we want to
do, no?
You always assign an Activity to a component. But the type of Activity is
what dictates the threading, synchronization, etc.
3) Orocos maps activities to OS resources (threads): What happens here? If
I understand you correctly, it is not completely clear what happens here?
Are there rules that Orocos follows, like: if activity has a priority,
scheduler or period different than the the other activities => create new
thread?
AFAIK yes.
Some rules off the top of my head (not all are guaranteed to be correct -
Peter is the canonical source of info. here)
1) If you use an Activity with a period (and priority and scheduler), you
get a thread that wakes the Activity on that period.
2) If you use an Activity with zero period, I *think* that you get a thread
that runs once and then waits for you to trigger it again.
3) If you use an Activity with a period, priority and scheduler, that all
match another Activity’s period, priority and scheduler, then IIRC you
re-use the thread from 3).
4) If you use a Slave Activity then there is no associated thread per se,
but you end up using the thread of the Master activity.
5) If you use a FileDescriptorActivity, you get a thread that wakes on file
descriptor read/writes and optionally a timeout.
We have a large Orocos application and explicitly use the Master/Slave
paradigm to schedule the bulk of the application (everything is
synchronized of hardware). So most of our Activity’s are Slaves, then there
are a handful of periodic Activity’s for housekeeping, logging, and some
other hardware access, and then there might be one or two NonPeriodic for
specific tasks. But others structure their systems differently - there are
multiple possible valid ways of solving the same problem.
> The documentation mentions that activities can be grouped in a thread if
> they have the same period.
> Is this always the case or sometimes? In which order are they put
> together?
>
This is an optimisation of OS resources for performance, so at your level
you have to do as if they were isolated. If you really need them to work in
order (cf previous explanation), just use MasterSlave Activities and
schedule them explicitly, because it's a choice you make at the system
level.
AFAIK it is also true that one thread may be used for multiple independent
activities that have the same priority, scheduler, and period. And
Master/Slave activities have their own set of caveats.
Hence Activities make the abstraction of the OS resources, and I should use
them to create my application.
They assume however that every component runs is independent, in the sense
that it shouldn't matter when it's getting triggered (before/after another).
That is seldom the case in our systems. There is nearly always some kind of
coupling between components in a time sense. A motion pipeline implemented
with several components must run them in order, for example.
Is there a use case of this?
Since components communicate data, it will have quite some impact.
Suppose I have three components A, B, C. Each of them reads data from the
previous component.
In case they are executed in this order, C will output data based on the
input of A a the same time instance.
In case they are executed in reverse order, C will output data based on the
input of A two samples ago…
Yep. Coupling in time => sequencing or synchronization.
How do the master-slave activities work?
The master contains the thread, and must explicitly trigger each slave.
This can be used to sequence components like your ABC example above.
Do I have to call excute() or trigger() from within my master component?
Yes. I think it’s actually update() if you call within a state machine.
If I do so, I couple the implementation of a component with the assignment
of activities (hence mapping on OS resources)?!
How is this used in practice?
For my A,B,C example, should I create an extra 'component' (a scheduler)
that calls execute/trigger on A,B,C in the order I want?
You can do that, but it’s heavyweight.
What is the reason to differentiate between execute and trigger (and
update) BTW?
I don’t recall.
For your ABC example, which is effectively a pipeline, we use two approaches
a) use a Master/Slave relationship to sequence the components.
b) use EventPorts to wake each component appropriately.
Why you would use one vs the other is a much longer discussion than I’m
willing to get into here. But we tend to use b) for small, often static,
pipelines (think image processing), while we use a) to synchronize lots of
optional pipelines to a hardware signal.
>
> Does the priority you can assign to an Activity influence this too?
>>
> I'll try to answer the question myself:
It influences OS resource assignment, but not necessarily the order of
execution (it could still end up in the same thread as another activity, in
a random order).
>
>> 2 Design
>>
>> My current application consists of a controller, a component that
>> interfaces with the motor encoders, and a component that interfaces with
>> the motor servo-drives.
>> The controller reads a desired trajectory from a ROS topic.
>> As I understand correctly, each component is periodic or non-periodic,
>> but I want them to be triggered one after the other (as the control flow
>> goes).
>> I could call execute()/update()/loop()/step() manually on each component,
>> but what is the advantage then of using Orocos?
>>
>
> If you want asynchronous chain of event, you have EventPorts that will
> trigger asynchronous components (I advice not to use this with periodic
> components). If you have a periodic chain, then it's a scheduling problem
> and you have to setup a component that will do this job. for instance :
> https://github.com/kmarkus/fbsched
>
> This is basically the scheduler component as I described above.
Thanks for this link, I didn't know about it.
I see it does call update() on the components not the execute() or
trigger() as described in the documentation.
Is there a difference?
>
>
> You’ve also got FileDescriptorActivity, which triggers off of say a socket
> or file read/write. Very useful with hardware.
>
This is indeed of interest.
>
> Or should I place all the functionality described above in a single
>> component? This makes my component however less reusable.
>>
>
> This is *THE* question you have to answer yourself. It depends a lot on
> your context. See here for some guidelines :
>
> http://orocos.org/forum/orocos/orocos-users/experience-building-structur...
>
> Performance issue, maintenability, scalability, code reuse, and many other
> dimensions of your problem should be taken into account to decide.
>
> My personnal advice is : don't forget to do software architecture before
> thinking about packaging your SW into components. Years after years using
> Orocos and ROS if think that you hardly never need to reuse the components
> but you need to reuse the underlying library. Orocos is "just" the specific
> glue code you write to assembly those libraries into a working application.
>
> Of course it's better if you can reuse a component, but it might be stupid
> to push the generalization to a level that has strong impact on
> performance. Splitting your application in a lot of little component is
> very reusable, but catastrophic in term of performance.
>
>
> Not necessarily catastrophic for performance. You can easily have an
> application with lots of components that has no worse performance than
> having one component. It’s a compromise between lots of pieces, scheduling,
> and complexity. What works for one person doesn’t always work for another.
>
> You have to find the compromise that fits to *your* system first, then
> tries to reuse. Else you'd have reusable components that are so bad that
> you will not reuse them.
>
>
>
>> Are there examples or guidelines for this kind of applications?
>>
>> 3 Verification
>>
>> How do I assess the RT performance of the application. Does Orocos
>> provide tools?
>> I found the ThreadScope component that puts a boolean on a parallel port,
>> but I don't have a parallel port anymore...
>> I could use the logging infrastructure.
>> The following wiki page
>> http://www.orocos.org/wiki/rtt/rtt-20/real-time-logging/using-real-time-... explains
>> RT-logging.
>> It makes distinction between text msgs and data.
>>
>
> Don't use logging to validate an application. It's not done for that. The
> best way to validate realtiness has always been to use a gpio and an
> oscilloscope :D
>
>
> I completely disagree with this Willy. Logging can and is used to validate
> applications. A scope is a great tool to use, but it isn’t always
> available. High resolution real-time logging can be an incredibly useful
> asset, especially as it can run every time the app. runs and provides data
> no matter what the situation. It’s incredibly useful as a forensic tool.
>
> Orocos provide a Reporting component that allows you to scope some
> signals. It will help in debugging a lot of thing, but as it's a part of
> the system it will change your time behavior and rely on some realtime part
> of your system that you have to check before hand (typically the timeclock).
>
>
>> The first I probably won't need, I only log error messages when something
>> goes wrong at run-time.
>> For the latter case, the data logging, this page only mentions NetCDF.
>> I see that there is OCL::NetcdfReporting, next to reporting to other
>> (file) formats: are all RT? Or only the one to NetCDF?
>>
>>
> There are other types of Reporter, but I can't remind which exists.
>
>
>
> Writing to a file takes time, hence it seems reporting can only be done at
low frequencies.
Not at all. We report at 500 Hz and never lose a cycle. But it takes
careful design and very dedicated runtime profiling to ensure that you meet
all your deadlines.
Hope this all helps.
S
Is there something specific with the NedCDF reporter wrt. the others, which
makes it more suitable for RT reporting?
As you can see, Orocos provides a lot of different ways of doing things.
> This is both a blessing and a curse - there is no one right way, and so
> each of the application designers on the ML have come up with different
> ways of doing things and of structuring systems.
>
> HTH
> S
>
Thank you a lot!
This certainly helps!
Andrew
>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
Fwd: Real-time control using Orocos
hi all
I think that there are two separate problems that are complementary, one
is the scheduling-synchronization (run a chain of components in a
precise order in such a way the data in the port has been refreshed)
and the other one is scheduling- realtime problem (been sure that a
given activity is triggered periodically).
In my understanding in orocos only the first problem is addressed clearly.
I have the impression (polarised by speaking of this problem with Herman
and Enea) that RT-component is more or less a RT-container, in the sense
that the composability is not really addressed, apart for the use of
event port, that in my opinion is not easily scalable, as the components
that you write should already be very aware of the surrounding context,
so limited re-usability.
on the contrary the realtime periodicity is the main focus (please
correct if i am wrong).
This tread is very interesting and this is a problem that comes out
again and again...
for the problem N.2 (real-time design and test):
i see that many people say that
'' You have to be careful with application design ''
that this exactly means?
which are the golden rules in writing the component?
and which are for the deployment?
which are the tools to check if you achieve this?
Is it possible to make and interpret a check without being a RT-guru ?
if some of you guys has build up some experience, i am very interested
to hear it.
For the problem N.1
i made a little test myself
https://github.com/gborghesan/sched_test
the goal is to have a chain of 100 components that are triggered in
sequence (each one reading from a port a vector, write in such vector a
value, and write the vector in a port).
to make it short (more details in the repo), doing by trigger from a
supervisor component does not do the job.
operation are blocking for the caller (or can be send and collected in a
such a way the operation in block n-1 is ended before sending operation
in n) and works.
however, this is not very good (again, i have to decide before-hand
whether the block is going to be periodical or triggered from outside to
decide whether the code is in update or in a operation, so the same
dilemma between event and normal ports...).
I also noticed that a side effect of calling an operation in a running
component (with 0 period) triggers the update hook.
mine solution is then to add a empty operation that is called in place
of trigger, and as a side effect, calls the code in the updateHook.
(maybe this could be a standard operation in the base class? returning
false if the component is not running or if it is periodic ? )
lastly, the other option is tu put all the code that should be called
sequentially in single component....
cheers, Gianni, and sorry for non-inline posting !
On 08/04/2015 06:30 PM, Andrew Porterman wrote:kiwi [dot] net [..] ...>>andrew [dot] porterman [..] ...>>:
> (Forward: this reply didn't make it to the forum it seems.)
> ---------- Forwarded message ----------
> From: *S Roderick* <kiwi [dot] net [..] ...
> Date: 2015-08-03 23:11 GMT+02:00
> Subject: Re: [Orocos-users] Real-time control using Orocos
> To: Andrew Porterman <andrew [dot] porterman [..] ...
> <mailto:andrew [dot] porterman [..] ...>>
> Cc: Orocos Users <orocos-users [..] ...
> <mailto:orocos-users [..] ...>>
>
>
> On Aug 03, 2015, at 11:15, Andrew Porterman <andrew [dot] porterman [..] ...
> <mailto:andrew [dot] porterman [..] ...>> wrote:
>>
>> Hi all,
>>
>> Thank you for the quick reply!
>>
>> 2015-08-03 5:24 GMT+02:00 S Roderick<kiwi [dot] net [..] ...
>> <mailto:kiwi [dot] net [..] ...>>:
>>
>> On Jul 31, 2015, at 13:52, Willy Lambert <lambert [dot] willy [..] ...
>> <mailto:lambert [dot] willy [..] ...>> wrote:
>>>
>>>
>>>
>>> 2015-07-31 18:36 GMT+02:00 Andrew Porterman
>>> <andrew [dot] porterman [..] ...
>>>
>>> Hi Orocos community,
>>>
>>> I'm working on a robotics project that requires real-time
>>> control.
>>> I installed Orocos using the debian packages and I'm using
>>> ROS nodes next to it (MoveIt!, vision etc.).
>>> I played around with Orocos, but until know I was only using
>>> it on a standard Ubuntu 14.04 installation.
>>>
>>> The project requires my controller to run with 1ms period.
>>> The question is however: how to set-up Orocos in real-time
>>> (or online, but at least more performant)?
>>> I'm reluctant to really install xenomai, which seems cumbersome.
>>> I saw on an old post on the forum
>>> (http://www.orocos.org/forum/orocos/orocos-users/getting-started-orocos-l...)
>>> that I could install a real-time kernel in Ubuntu.
>>> It states that there is no need for recompilation of the
>>> Orocos code, is this correct? (compiler flags?)
>>>
>>>
>>> Yes it's true, the only thing you need to recompile is your linux
>>> kernel modified with preemt-rt patches. I would say 1ms is the
>>> limit between the xenomai need and the preempt RT need, some
>>> application are know to work at 1ms perfectly with a prempt-rt
>>> vanilla kernel.
>>>
>>> Note that xenomai has moved ahead to 3.0 which should be by far
>>> easier to integrate as it would be transparently used under a
>>> posix "skin". I don't know if someone have already done that for now.
>>
>> We run several robot control applications at 2ms (500 Hz) on COTS
>> PCs with Linux Preempt RT and have no problems. You have to be
>> careful with application design, but overall Linux is more than
>> capable for our work.
>>
>>> Is this enough to unlock the real-time behavior of Orocos?
>>>
>>>
>>> The realtimeness is not an orocos property, it's your system
>>> property. And when you add the preemptRT patch to the linux
>>> kernel sources, it has nothing to do with Orocos, it's your OS
>>> that you setup (which is a part of your system).
>>>
>>> The fact you have Orocos or not will not provide you the
>>> realtimeness, you can still bullshit into your Orocos code or
>>> design. The "only" thing that Orocos does, is to be aware that
>>> some user need realtimeness. For instance you may reserve memory
>>> at startup in your data flow connectors (Ports). The API gives
>>> you a way to do it, but it will not do it for you.
>>>
>>> If you don't know how to do a "bare metal" realtime application,
>>> you certainly won't be able to do it with Orocos either. But if
>>> you do know how to manage that, Orocos will help you setting this
>>> us more easily and securely (for instance because synchronisation
>>> mecanism like mutex, signal, are embedded in the framework).
>>
>> I see, this is also my motivation to use Orocos in the first place.
>>
>>> Can I just run
>>> $rosrun ocl deployer-gnulinux -s start.ops
>>> I looked into the documentation on orocos.org
>>> <http://orocos.org />, but I found only some scattered
>>> information, some of it rather old or pointing to 1.x versions.
>>> I try to give an overview of my questions in a more
>>> structured way here below.
>>>
>>> 1 General Orocos functionality
>>>
>>> If I understand correctly:
>>> -> all components that are dynamically deployed by
>>> deployer-gnulinux = 1 process
>>>
>>> Yes
>>>
>>> -> 1 component ~ 1 thread:
>>>
>>> No
>>>
>>> More correctly 1 component is run by an activity which
>>> assigns it to a thread
>>>
>>> No !!! You may attach several components to the same thread.
>>> Typically when having a sequence of periodic components in a
>>> chain, it's a better idea to use one thread to trig all those
>>> components.
>>
>> I’d say it depends. Sometimes you want many components processing
>> data, and sometimes you want one component. It varies. But it is
>> true that each component has an associated activity, but it is not
>> that each activity has a thread.
>>
>>
>> That is where I'm left a bit confused.
>> The code documentation of the Activity class starts with: "An activity
>> is an object that represents a thread. ... One Activity object maps to
>> one OS thread."
>> http://www.orocos.org/stable/documentation/rtt/v2.x/api/html/classRTT_1_...
>> But the wiki documentation did indeed state the opposite…
>
> The API doc’s are incorrect.
>
>> I also wonder what the effect is when multiple activities share the
>> same thread and you interact with the thread like this:
>> |this->getActivity()->thread()
>> (http://www.orocos.org/stable/documentation/rtt/v2.x/doc-xml/orocos-compo...
>> 6.1)
>> |
>
> As a rule, you shouldn’t need to (nor should you) access the thread
> itself. There are exceptions, but they are definitely unusual ...
>
>>> Orocos doesn't enforce any threading constraints. You have to
>>> design your threading yourself and make your own decisions. Cf
>>> previous explanations, this is required for real time
>>> applications, so Orocos is aware of that and let you do your job.
>>
>> Orocos provides the ability to thread things, and it isn’t always
>> clear on when it does or doesn’t thread. You’ll have to get into
>> the details within your own application.
>>
>>
>> What I'm doing now is:
>> 1) I create components (taking into account proper RT design rules)
>> 2) I assign an activity to the component = Is that what you mean with
>> 'design your threading yourself', Willy?
>> It is at this level that Orocos wants me to design my threading, no?
>> Creating pthreads in an Orocos component is definitely not what we
>> want to do, no?
>
> You always assign an Activity to a component. But the type of Activity
> is what dictates the threading, synchronization, etc.
>
>> 3) Orocos maps activities to OS resources (threads): What happens
>> here? If I understand you correctly, it is not completely clear what
>> happens here?
>> Are there rules that Orocos follows, like: if activity has a priority,
>> scheduler or period different than the the other activities => create
>> new thread?
>
> AFAIK yes.
>
> Some rules off the top of my head (not all are guaranteed to be correct
> - Peter is the canonical source of info. here)
> 1) If you use an Activity with a period (and priority and scheduler),
> you get a thread that wakes the Activity on that period.
> 2) If you use an Activity with zero period, I *think* that you get a
> thread that runs once and then waits for you to trigger it again.
> 3) If you use an Activity with a period, priority and scheduler, that
> all match another Activity’s period, priority and scheduler, then IIRC
> you re-use the thread from 3).
> 4) If you use a Slave Activity then there is no associated thread per
> se, but you end up using the thread of the Master activity.
> 5) If you use a FileDescriptorActivity, you get a thread that wakes on
> file descriptor read/writes and optionally a timeout.
>
> We have a large Orocos application and explicitly use the Master/Slave
> paradigm to schedule the bulk of the application (everything is
> synchronized of hardware). So most of our Activity’s are Slaves, then
> there are a handful of periodic Activity’s for housekeeping, logging,
> and some other hardware access, and then there might be one or two
> NonPeriodic for specific tasks. But others structure their systems
> differently - there are multiple possible valid ways of solving the same
> problem.
>
>>
>>>
>>> The documentation mentions that activities can be grouped in a
>>> thread if they have the same period.
>>> Is this always the case or sometimes? In which order are they put
>>> together?
>>>
>>>
>>> This is an optimisation of OS resources for performance, so at your
>>> level you have to do as if they were isolated. If you really need
>>> them to work in order (cf previous explanation), just use MasterSlave
>>> Activities and schedule them explicitly, because it's a choice you
>>> make at the system level.
>>
>> AFAIK it is also true that one thread may be used for multiple
>> independent activities that have the same priority, scheduler, and
>> period. And Master/Slave activities have their own set of caveats.
>>
>> Hence Activities make the abstraction of the OS resources, and I
>> should use them to create my application.
>> They assume however that every component runs is independent, in the
>> sense that it shouldn't matter when it's getting triggered
>> (before/after another).
>
> That is seldom the case in our systems. There is nearly always some kind
> of coupling between components in a time sense. A motion pipeline
> implemented with several components must run them in order, for example.
>
>> Is there a use case of this?
>> Since components communicate data, it will have quite some impact.
>> Suppose I have three components A, B, C. Each of them reads data from
>> the previous component.
>> In case they are executed in this order, C will output data based on
>> the input of A a the same time instance.
>> In case they are executed in reverse order, C will output data based
>> on the input of A two samples ago…
>
> Yep. Coupling in time => sequencing or synchronization.
>
>> How do the master-slave activities work?
>
> The master contains the thread, and must explicitly trigger each slave.
> This can be used to sequence components like your ABC example above.
>
>> Do I have to call excute() or trigger() from within my master component?
>
> Yes. I think it’s actually update() if you call within a state machine.
>
>> If I do so, I couple the implementation of a component with the
>> assignment of activities (hence mapping on OS resources)?!
>> How is this used in practice?
>> For my A,B,C example, should I create an extra 'component' (a
>> scheduler) that calls execute/trigger on A,B,C in the order I want?
>
> You can do that, but it’s heavyweight.
>
>> What is the reason to differentiate between execute and trigger (and
>> update) BTW?
>
> I don’t recall.
>
> For your ABC example, which is effectively a pipeline, we use two approaches
> a) use a Master/Slave relationship to sequence the components.
> b) use EventPorts to wake each component appropriately.
>
> Why you would use one vs the other is a much longer discussion than I’m
> willing to get into here. But we tend to use b) for small, often static,
> pipelines (think image processing), while we use a) to synchronize lots
> of optional pipelines to a hardware signal.
>
>>
>>
>>> Does the priority you can assign to an Activity influence
>>> this too?
>>
>> I'll try to answer the question myself:
>> It influences OS resource assignment, but not necessarily the order of
>> execution (it could still end up in the same thread as another
>> activity, in a random order).
>>
>>>
>>> 2 Design
>>>
>>> My current application consists of a controller, a component
>>> that interfaces with the motor encoders, and a component that
>>> interfaces with the motor servo-drives.
>>> The controller reads a desired trajectory from a ROS topic.
>>> As I understand correctly, each component is periodic or
>>> non-periodic, but I want them to be triggered one after the
>>> other (as the control flow goes).
>>> I could call execute()/update()/loop()/step() manually on
>>> each component, but what is the advantage then of using Orocos?
>>>
>>>
>>> If you want asynchronous chain of event, you have EventPorts that
>>> will trigger asynchronous components (I advice not to use this
>>> with periodic components). If you have a periodic chain, then
>>> it's a scheduling problem and you have to setup a component that
>>> will do this job. for instance :
>>> https://github.com/kmarkus/fbsched
>>
>> This is basically the scheduler component as I described above.
>> Thanks for this link, I didn't know about it.
>> I see it does call update() on the components not the execute() or
>> trigger() as described in the documentation.
>> Is there a difference?
>>
>>>
>>
>> You’ve also got FileDescriptorActivity, which triggers off of say
>> a socket or file read/write. Very useful with hardware.
>>
>> This is indeed of interest.
>>
>>
>>> Or should I place all the functionality described above in a
>>> single component? This makes my component however less reusable.
>>>
>>>
>>> This is *THE* question you have to answer yourself. It depends a
>>> lot on your context. See here for some guidelines :
>>> http://orocos.org/forum/orocos/orocos-users/experience-building-structur...
>>>
>>> Performance issue, maintenability, scalability, code reuse, and
>>> many other dimensions of your problem should be taken into
>>> account to decide.
>>>
>>> My personnal advice is : don't forget to do software architecture
>>> before thinking about packaging your SW into components. Years
>>> after years using Orocos and ROS if think that you hardly never
>>> need to reuse the components but you need to reuse the underlying
>>> library. Orocos is "just" the specific glue code you write to
>>> assembly those libraries into a working application.
>>>
>>> Of course it's better if you can reuse a component, but it might
>>> be stupid to push the generalization to a level that has strong
>>> impact on performance. Splitting your application in a lot of
>>> little component is very reusable, but catastrophic in term of
>>> performance.
>>
>> Not necessarily catastrophic for performance. You can easily have
>> an application with lots of components that has no worse
>> performance than having one component. It’s a compromise between
>> lots of pieces, scheduling, and complexity. What works for one
>> person doesn’t always work for another.
>>
>>> You have to find the compromise that fits to *your* system first,
>>> then tries to reuse. Else you'd have reusable components that are
>>> so bad that you will not reuse them.
>>>
>>> Are there examples or guidelines for this kind of applications?
>>>
>>> 3 Verification
>>>
>>> How do I assess the RT performance of the application. Does
>>> Orocos provide tools?
>>> I found the ThreadScope component that puts a boolean on a
>>> parallel port, but I don't have a parallel port anymore...
>>> I could use the logging infrastructure.
>>> The following wiki page
>>> http://www.orocos.org/wiki/rtt/rtt-20/real-time-logging/using-real-time-... explains
>>> RT-logging.
>>> It makes distinction between text msgs and data.
>>>
>>>
>>> Don't use logging to validate an application. It's not done for
>>> that. The best way to validate realtiness has always been to use
>>> a gpio and an oscilloscope :D
>>
>> I completely disagree with this Willy. Logging can and is used to
>> validate applications. A scope is a great tool to use, but it
>> isn’t always available. High resolution real-time logging can be
>> an incredibly useful asset, especially as it can run every time
>> the app. runs and provides data no matter what the situation. It’s
>> incredibly useful as a forensic tool.
>>
>>> Orocos provide a Reporting component that allows you to scope
>>> some signals. It will help in debugging a lot of thing, but as
>>> it's a part of the system it will change your time behavior and
>>> rely on some realtime part of your system that you have to check
>>> before hand (typically the timeclock).
>>>
>>> The first I probably won't need, I only log error messages
>>> when something goes wrong at run-time.
>>> For the latter case, the data logging, this page only
>>> mentions NetCDF.
>>> I see that there is OCL::NetcdfReporting, next to reporting
>>> to other (file) formats: are all RT? Or only the one to NetCDF?
>>>
>>>
>>> There are other types of Reporter, but I can't remind which exists.
>>
>> Writing to a file takes time, hence it seems reporting can only be
>> done at low frequencies.
>
> Not at all. We report at 500 Hz and never lose a cycle. But it takes
> careful design and very dedicated runtime profiling to ensure that you
> meet all your deadlines.
>
> Hope this all helps.
> S
>
>> Is there something specific with the NedCDF reporter wrt. the others,
>> which makes it more suitable for RT reporting?
>
>>
>> As you can see, Orocos provides a lot of different ways of doing
>> things. This is both a blessing and a curse - there is no one
>> right way, and so each of the application designers on the ML have
>> come up with different ways of doing things and of structuring
>> systems.
>>
>> HTH
>> S
>>
>>
>> Thank you a lot!
>> This certainly helps!
>>
>> Andrew
>>
>>
>> --
>> Orocos-Users mailing list
>> Orocos-Users [..] ...
>> <mailto:Orocos-Users [..] ...>
>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
>
>
>
Fwd: Real-time control using Orocos
Hi Gianni,
On Wed, Aug 5, 2015 at 11:46 AM Gianni Borghesan <
gianni [dot] borghesan [..] ...> wrote:
> hi all
> I think that there are two separate problems that are complementary, one
> is the scheduling-synchronization (run a chain of components in a
> precise order in such a way the data in the port has been refreshed)
> and the other one is scheduling- realtime problem (been sure that a
> given activity is triggered periodically).
>
> In my understanding in orocos only the first problem is addressed clearly.
>
> I have the impression (polarised by speaking of this problem with Herman
> and Enea) that RT-component is more or less a RT-container, in the sense
> that the composability is not really addressed, apart for the use of
> event port, that in my opinion is not easily scalable, as the components
> that you write should already be very aware of the surrounding context,
> so limited re-usability.
>
> on the contrary the realtime periodicity is the main focus (please
> correct if i am wrong).
>
> This tread is very interesting and this is a problem that comes out
> again and again...
>
> for the problem N.2 (real-time design and test):
> i see that many people say that
>
> '' You have to be careful with application design ''
>
> that this exactly means?
> which are the golden rules in writing the component?
> and which are for the deployment?
> which are the tools to check if you achieve this?
> Is it possible to make and interpret a check without being a RT-guru ?
>
> if some of you guys has build up some experience, i am very interested
> to hear it.
>
> For the problem N.1
>
>
> i made a little test myself
>
> https://github.com/gborghesan/sched_test
>
>
> the goal is to have a chain of 100 components that are triggered in
> sequence (each one reading from a port a vector, write in such vector a
> value, and write the vector in a port).
>
> to make it short (more details in the repo), doing by trigger from a
> supervisor component does not do the job.
> operation are blocking for the caller (or can be send and collected in a
> such a way the operation in block n-1 is ended before sending operation
> in n) and works.
>
> however, this is not very good (again, i have to decide before-hand
> whether the block is going to be periodical or triggered from outside to
> decide whether the code is in update or in a operation, so the same
> dilemma between event and normal ports...).
>
> I also noticed that a side effect of calling an operation in a running
> component (with 0 period) triggers the update hook.
>
> mine solution is then to add a empty operation that is called in place
> of trigger, and as a side effect, calls the code in the updateHook.
> (maybe this could be a standard operation in the base class? returning
> false if the component is not running or if it is periodic ? )
>
>
> lastly, the other option is tu put all the code that should be called
> sequentially in single component....
>
>
It would be nice if you could also add the data-triggered solution in your
test, where you add the input port as an EventPort and let the writes on
the port trigger the next component in-line. I assume for this test
use-case it is also a valid solution.
R.
> cheers, Gianni, and sorry for non-inline posting !kiwi [dot] net [..] ...>>andrew [dot] porterman [..] ...>>:
>
>
>
>
> On 08/04/2015 06:30 PM, Andrew Porterman wrote:
> > (Forward: this reply didn't make it to the forum it seems.)
> > ---------- Forwarded message ----------
> > From: *S Roderick* <kiwi [dot] net [..] ...
> > Date: 2015-08-03 23:11 GMT+02:00
> > Subject: Re: [Orocos-users] Real-time control using Orocos
> > To: Andrew Porterman <andrew [dot] porterman [..] ...
> > <mailto:andrew [dot] porterman [..] ...>>
> > Cc: Orocos Users <orocos-users [..] ...
> > <mailto:orocos-users [..] ...>>
> >
> >
> > On Aug 03, 2015, at 11:15, Andrew Porterman <andrew [dot] porterman [..] ...
> > <mailto:andrew [dot] porterman [..] ...>> wrote:
> >>
> >> Hi all,
> >>
> >> Thank you for the quick reply!
> >>
> >> 2015-08-03 5:24 GMT+02:00 S Roderick<kiwi [dot] net [..] ...
> >> <mailto:kiwi [dot] net [..] ...>>:
> >>
> >> On Jul 31, 2015, at 13:52, Willy Lambert <lambert [dot] willy [..] ...
> >> <mailto:lambert [dot] willy [..] ...>> wrote:
> >>>
> >>>
> >>>
> >>> 2015-07-31 18:36 GMT+02:00 Andrew Porterman
> >>> <andrew [dot] porterman [..] ...
> >>>
> >>> Hi Orocos community,
> >>>
> >>> I'm working on a robotics project that requires real-time
> >>> control.
> >>> I installed Orocos using the debian packages and I'm using
> >>> ROS nodes next to it (MoveIt!, vision etc.).
> >>> I played around with Orocos, but until know I was only using
> >>> it on a standard Ubuntu 14.04 installation.
> >>>
> >>> The project requires my controller to run with 1ms period.
> >>> The question is however: how to set-up Orocos in real-time
> >>> (or online, but at least more performant)?
> >>> I'm reluctant to really install xenomai, which seems
> cumbersome.
> >>> I saw on an old post on the forum
> >>> (
> http://www.orocos.org/forum/orocos/orocos-users/getting-started-orocos-l...
> )
> >>> that I could install a real-time kernel in Ubuntu.
> >>> It states that there is no need for recompilation of the
> >>> Orocos code, is this correct? (compiler flags?)
> >>>
> >>>
> >>> Yes it's true, the only thing you need to recompile is your linux
> >>> kernel modified with preemt-rt patches. I would say 1ms is the
> >>> limit between the xenomai need and the preempt RT need, some
> >>> application are know to work at 1ms perfectly with a prempt-rt
> >>> vanilla kernel.
> >>>
> >>> Note that xenomai has moved ahead to 3.0 which should be by far
> >>> easier to integrate as it would be transparently used under a
> >>> posix "skin". I don't know if someone have already done that for
> now.
> >>
> >> We run several robot control applications at 2ms (500 Hz) on COTS
> >> PCs with Linux Preempt RT and have no problems. You have to be
> >> careful with application design, but overall Linux is more than
> >> capable for our work.
> >>
> >>> Is this enough to unlock the real-time behavior of Orocos?
> >>>
> >>>
> >>> The realtimeness is not an orocos property, it's your system
> >>> property. And when you add the preemptRT patch to the linux
> >>> kernel sources, it has nothing to do with Orocos, it's your OS
> >>> that you setup (which is a part of your system).
> >>>
> >>> The fact you have Orocos or not will not provide you the
> >>> realtimeness, you can still bullshit into your Orocos code or
> >>> design. The "only" thing that Orocos does, is to be aware that
> >>> some user need realtimeness. For instance you may reserve memory
> >>> at startup in your data flow connectors (Ports). The API gives
> >>> you a way to do it, but it will not do it for you.
> >>>
> >>> If you don't know how to do a "bare metal" realtime application,
> >>> you certainly won't be able to do it with Orocos either. But if
> >>> you do know how to manage that, Orocos will help you setting this
> >>> us more easily and securely (for instance because synchronisation
> >>> mecanism like mutex, signal, are embedded in the framework).
> >>
> >> I see, this is also my motivation to use Orocos in the first place.
> >>
> >>> Can I just run
> >>> $rosrun ocl deployer-gnulinux -s start.ops
> >>> I looked into the documentation on orocos.org
> >>> <http://orocos.org />, but I found only some scattered
> >>> information, some of it rather old or pointing to 1.x versions.
> >>> I try to give an overview of my questions in a more
> >>> structured way here below.
> >>>
> >>> 1 General Orocos functionality
> >>>
> >>> If I understand correctly:
> >>> -> all components that are dynamically deployed by
> >>> deployer-gnulinux = 1 process
> >>>
> >>> Yes
> >>>
> >>> -> 1 component ~ 1 thread:
> >>>
> >>> No
> >>>
> >>> More correctly 1 component is run by an activity which
> >>> assigns it to a thread
> >>>
> >>> No !!! You may attach several components to the same thread.
> >>> Typically when having a sequence of periodic components in a
> >>> chain, it's a better idea to use one thread to trig all those
> >>> components.
> >>
> >> I’d say it depends. Sometimes you want many components processing
> >> data, and sometimes you want one component. It varies. But it is
> >> true that each component has an associated activity, but it is not
> >> that each activity has a thread.
> >>
> >>
> >> That is where I'm left a bit confused.
> >> The code documentation of the Activity class starts with: "An activity
> >> is an object that represents a thread. ... One Activity object maps to
> >> one OS thread."
> >>
> http://www.orocos.org/stable/documentation/rtt/v2.x/api/html/classRTT_1_...
> >> But the wiki documentation did indeed state the opposite…
> >
> > The API doc’s are incorrect.
> >
> >> I also wonder what the effect is when multiple activities share the
> >> same thread and you interact with the thread like this:
> >> |this->getActivity()->thread()
> >> (
> http://www.orocos.org/stable/documentation/rtt/v2.x/doc-xml/orocos-compo...
> >> 6.1)
> >> |
> >
> > As a rule, you shouldn’t need to (nor should you) access the thread
> > itself. There are exceptions, but they are definitely unusual ...
> >
> >>> Orocos doesn't enforce any threading constraints. You have to
> >>> design your threading yourself and make your own decisions. Cf
> >>> previous explanations, this is required for real time
> >>> applications, so Orocos is aware of that and let you do your job.
> >>
> >> Orocos provides the ability to thread things, and it isn’t always
> >> clear on when it does or doesn’t thread. You’ll have to get into
> >> the details within your own application.
> >>
> >>
> >> What I'm doing now is:
> >> 1) I create components (taking into account proper RT design rules)
> >> 2) I assign an activity to the component = Is that what you mean with
> >> 'design your threading yourself', Willy?
> >> It is at this level that Orocos wants me to design my threading, no?
> >> Creating pthreads in an Orocos component is definitely not what we
> >> want to do, no?
> >
> > You always assign an Activity to a component. But the type of Activity
> > is what dictates the threading, synchronization, etc.
> >
> >> 3) Orocos maps activities to OS resources (threads): What happens
> >> here? If I understand you correctly, it is not completely clear what
> >> happens here?
> >> Are there rules that Orocos follows, like: if activity has a priority,
> >> scheduler or period different than the the other activities => create
> >> new thread?
> >
> > AFAIK yes.
> >
> > Some rules off the top of my head (not all are guaranteed to be correct
> > - Peter is the canonical source of info. here)
> > 1) If you use an Activity with a period (and priority and scheduler),
> > you get a thread that wakes the Activity on that period.
> > 2) If you use an Activity with zero period, I *think* that you get a
> > thread that runs once and then waits for you to trigger it again.
> > 3) If you use an Activity with a period, priority and scheduler, that
> > all match another Activity’s period, priority and scheduler, then IIRC
> > you re-use the thread from 3).
> > 4) If you use a Slave Activity then there is no associated thread per
> > se, but you end up using the thread of the Master activity.
> > 5) If you use a FileDescriptorActivity, you get a thread that wakes on
> > file descriptor read/writes and optionally a timeout.
> >
> > We have a large Orocos application and explicitly use the Master/Slave
> > paradigm to schedule the bulk of the application (everything is
> > synchronized of hardware). So most of our Activity’s are Slaves, then
> > there are a handful of periodic Activity’s for housekeeping, logging,
> > and some other hardware access, and then there might be one or two
> > NonPeriodic for specific tasks. But others structure their systems
> > differently - there are multiple possible valid ways of solving the same
> > problem.
> >
> >>
> >>>
> >>> The documentation mentions that activities can be grouped in a
> >>> thread if they have the same period.
> >>> Is this always the case or sometimes? In which order are they put
> >>> together?
> >>>
> >>>
> >>> This is an optimisation of OS resources for performance, so at your
> >>> level you have to do as if they were isolated. If you really need
> >>> them to work in order (cf previous explanation), just use MasterSlave
> >>> Activities and schedule them explicitly, because it's a choice you
> >>> make at the system level.
> >>
> >> AFAIK it is also true that one thread may be used for multiple
> >> independent activities that have the same priority, scheduler, and
> >> period. And Master/Slave activities have their own set of caveats.
> >>
> >> Hence Activities make the abstraction of the OS resources, and I
> >> should use them to create my application.
> >> They assume however that every component runs is independent, in the
> >> sense that it shouldn't matter when it's getting triggered
> >> (before/after another).
> >
> > That is seldom the case in our systems. There is nearly always some kind
> > of coupling between components in a time sense. A motion pipeline
> > implemented with several components must run them in order, for example.
> >
> >> Is there a use case of this?
> >> Since components communicate data, it will have quite some impact.
> >> Suppose I have three components A, B, C. Each of them reads data from
> >> the previous component.
> >> In case they are executed in this order, C will output data based on
> >> the input of A a the same time instance.
> >> In case they are executed in reverse order, C will output data based
> >> on the input of A two samples ago…
> >
> > Yep. Coupling in time => sequencing or synchronization.
> >
> >> How do the master-slave activities work?
> >
> > The master contains the thread, and must explicitly trigger each slave.
> > This can be used to sequence components like your ABC example above.
> >
> >> Do I have to call excute() or trigger() from within my master component?
> >
> > Yes. I think it’s actually update() if you call within a state machine.
> >
> >> If I do so, I couple the implementation of a component with the
> >> assignment of activities (hence mapping on OS resources)?!
> >> How is this used in practice?
> >> For my A,B,C example, should I create an extra 'component' (a
> >> scheduler) that calls execute/trigger on A,B,C in the order I want?
> >
> > You can do that, but it’s heavyweight.
> >
> >> What is the reason to differentiate between execute and trigger (and
> >> update) BTW?
> >
> > I don’t recall.
> >
> > For your ABC example, which is effectively a pipeline, we use two
> approaches
> > a) use a Master/Slave relationship to sequence the components.
> > b) use EventPorts to wake each component appropriately.
> >
> > Why you would use one vs the other is a much longer discussion than I’m
> > willing to get into here. But we tend to use b) for small, often static,
> > pipelines (think image processing), while we use a) to synchronize lots
> > of optional pipelines to a hardware signal.
> >
> >>
> >>
> >>> Does the priority you can assign to an Activity influence
> >>> this too?
> >>
> >> I'll try to answer the question myself:
> >> It influences OS resource assignment, but not necessarily the order of
> >> execution (it could still end up in the same thread as another
> >> activity, in a random order).
> >>
> >>>
> >>> 2 Design
> >>>
> >>> My current application consists of a controller, a component
> >>> that interfaces with the motor encoders, and a component that
> >>> interfaces with the motor servo-drives.
> >>> The controller reads a desired trajectory from a ROS topic.
> >>> As I understand correctly, each component is periodic or
> >>> non-periodic, but I want them to be triggered one after the
> >>> other (as the control flow goes).
> >>> I could call execute()/update()/loop()/step() manually on
> >>> each component, but what is the advantage then of using Orocos?
> >>>
> >>>
> >>> If you want asynchronous chain of event, you have EventPorts that
> >>> will trigger asynchronous components (I advice not to use this
> >>> with periodic components). If you have a periodic chain, then
> >>> it's a scheduling problem and you have to setup a component that
> >>> will do this job. for instance :
> >>> https://github.com/kmarkus/fbsched
> >>
> >> This is basically the scheduler component as I described above.
> >> Thanks for this link, I didn't know about it.
> >> I see it does call update() on the components not the execute() or
> >> trigger() as described in the documentation.
> >> Is there a difference?
> >>
> >>>
> >>
> >> You’ve also got FileDescriptorActivity, which triggers off of say
> >> a socket or file read/write. Very useful with hardware.
> >>
> >> This is indeed of interest.
> >>
> >>
> >>> Or should I place all the functionality described above in a
> >>> single component? This makes my component however less
> reusable.
> >>>
> >>>
> >>> This is *THE* question you have to answer yourself. It depends a
> >>> lot on your context. See here for some guidelines :
> >>>
> http://orocos.org/forum/orocos/orocos-users/experience-building-structur...
> >>>
> >>> Performance issue, maintenability, scalability, code reuse, and
> >>> many other dimensions of your problem should be taken into
> >>> account to decide.
> >>>
> >>> My personnal advice is : don't forget to do software architecture
> >>> before thinking about packaging your SW into components. Years
> >>> after years using Orocos and ROS if think that you hardly never
> >>> need to reuse the components but you need to reuse the underlying
> >>> library. Orocos is "just" the specific glue code you write to
> >>> assembly those libraries into a working application.
> >>>
> >>> Of course it's better if you can reuse a component, but it might
> >>> be stupid to push the generalization to a level that has strong
> >>> impact on performance. Splitting your application in a lot of
> >>> little component is very reusable, but catastrophic in term of
> >>> performance.
> >>
> >> Not necessarily catastrophic for performance. You can easily have
> >> an application with lots of components that has no worse
> >> performance than having one component. It’s a compromise between
> >> lots of pieces, scheduling, and complexity. What works for one
> >> person doesn’t always work for another.
> >>
> >>> You have to find the compromise that fits to *your* system first,
> >>> then tries to reuse. Else you'd have reusable components that are
> >>> so bad that you will not reuse them.
> >>>
> >>> Are there examples or guidelines for this kind of applications?
> >>>
> >>> 3 Verification
> >>>
> >>> How do I assess the RT performance of the application. Does
> >>> Orocos provide tools?
> >>> I found the ThreadScope component that puts a boolean on a
> >>> parallel port, but I don't have a parallel port anymore...
> >>> I could use the logging infrastructure.
> >>> The following wiki page
> >>>
> http://www.orocos.org/wiki/rtt/rtt-20/real-time-logging/using-real-time-...
> explains
> >>> RT-logging.
> >>> It makes distinction between text msgs and data.
> >>>
> >>>
> >>> Don't use logging to validate an application. It's not done for
> >>> that. The best way to validate realtiness has always been to use
> >>> a gpio and an oscilloscope :D
> >>
> >> I completely disagree with this Willy. Logging can and is used to
> >> validate applications. A scope is a great tool to use, but it
> >> isn’t always available. High resolution real-time logging can be
> >> an incredibly useful asset, especially as it can run every time
> >> the app. runs and provides data no matter what the situation. It’s
> >> incredibly useful as a forensic tool.
> >>
> >>> Orocos provide a Reporting component that allows you to scope
> >>> some signals. It will help in debugging a lot of thing, but as
> >>> it's a part of the system it will change your time behavior and
> >>> rely on some realtime part of your system that you have to check
> >>> before hand (typically the timeclock).
> >>>
> >>> The first I probably won't need, I only log error messages
> >>> when something goes wrong at run-time.
> >>> For the latter case, the data logging, this page only
> >>> mentions NetCDF.
> >>> I see that there is OCL::NetcdfReporting, next to reporting
> >>> to other (file) formats: are all RT? Or only the one to NetCDF?
> >>>
> >>>
> >>> There are other types of Reporter, but I can't remind which exists.
> >>
> >> Writing to a file takes time, hence it seems reporting can only be
> >> done at low frequencies.
> >
> > Not at all. We report at 500 Hz and never lose a cycle. But it takes
> > careful design and very dedicated runtime profiling to ensure that you
> > meet all your deadlines.
> >
> > Hope this all helps.
> > S
> >
> >> Is there something specific with the NedCDF reporter wrt. the others,
> >> which makes it more suitable for RT reporting?
> >
> >>
> >> As you can see, Orocos provides a lot of different ways of doing
> >> things. This is both a blessing and a curse - there is no one
> >> right way, and so each of the application designers on the ML have
> >> come up with different ways of doing things and of structuring
> >> systems.
> >>
> >> HTH
> >> S
> >>
> >>
> >> Thank you a lot!
> >> This certainly helps!
> >>
> >> Andrew
> >>
> >>
> >> --
> >> Orocos-Users mailing list
> >> Orocos-Users [..] ...
> >> <mailto:Orocos-Users [..] ...>
> >> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
> >
> >
> >
> >
>
> --
> ------------------------------------------------
> Gianni Borghesan, PhD
> Robot Assisted Surgery group
> Robotics Research group
> KU Leuven,
> Department of Mechanical Engineering,
> Division of PMA
> Room 01.017
> Celestijnenlaan 300B, B-3001 Heverlee, Belgium.
> Tel: +32 163 29267
> Fax: +32 163 22987
> ------------------------------------------------
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>