(snip)

One minor precision:

> 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).
>

This statement is true for RTT::extras::PeriodicActivity,

"Multiple PeriodicActivities having the same priority and periodicity will
be executed in the same TimerThread one after the other."

This is not true for RTT::Activity. Each will have its own thread.

> 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.
>
>
Cheers,

On Aug 03, 2015, at 17:07, Willy Lambert <lambert [dot] willy [..] ...> wrote:
>
>
>
> 2015-08-03 17:15 GMT+02:00 Andrew Porterman <andrew [dot] porterman [..] ... andrew [dot] porterman [..] ...>>:
> Hi all,
>
> Thank you for the quick reply!
>
> 2015-08-03 5:24 GMT+02:00 S Roderick <kiwi [dot] net [..] ... kiwi [dot] net [..] ...>>:
> On Jul 31, 2015, at 13:52, Willy Lambert <lambert [dot] willy [..] ... lambert [dot] willy [..] ...>> wrote:
>>
>>
>>
>> 2015-07-31 18:36 GMT+02:00 Andrew Porterman <andrew [dot] 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... <http://www.orocos.org/forum/orocos/orocos-users/getting-started-orocos-linux-preempt-rt>)
>> 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_... <http://www.orocos.org/stable/documentation/rtt/v2.x/api/html/classRTT_1_1Activity.html#details>
> But the wiki documentation did indeed state the opposite...
>
> 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... <http://www.orocos.org/stable/documentation/rtt/v2.x/doc-xml/orocos-components-manual.html> example 6.1)
>
>> 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?
> 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?
>
>>
>> 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).
> 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...
>
> How do the master-slave activities work?
> Do I have to call excute() or trigger() from within my master component?
> 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?
>
> What is the reason to differentiate between execute and trigger (and update) BTW?
>
>
>> 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 <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... <http://orocos.org/forum/orocos/orocos-users/experience-building-structure-orocos>
>>
>> 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-... <http://www.orocos.org/wiki/rtt/rtt-20/real-time-logging/using-real-time-logging> 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.
>
> You are just transposing the validation need on the logging tools that you have to check anyway. I may agree on the fact it's less work to check that way and that it helps validating functionnal needs, but I've also seen so many times developpers being confident ontheir wrong logging system... I won't continue the discussion because the original question was not how to validate a software but how to check realtiness and my answer is : "with a reference clock". I do not consider logging as a valid reference clock.

I think you’re being pedantic. I’ve also seen oscilloscopes used incorrectly to “prove” something. The simple fact is that high-resolution logging information can be used to reason about a program’s actual execution and timing. I appreciate that that isn’t your approach, but it does work well for others and is thus simply a valid alternative.

>
>
>> 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.
>
> The media on which you send the data is not a matter as long as you have well designed log queue to buffer log messages that a logging thread will transmit to the media. Especially for files, it's by far more efficient if you send big dataset to the disk than write octet by octet. Of course the mean log rate shall be less than your file writing rate, but you can manage burst with a log message queue.

The media definitely does matter. HDD vs SSD vs Compact Flash all make a difference in how you approach the problem, and the particular idiosyncrasies of each that you have to deal with. A solution for an HDD may not actually work for an SSD in certain corner cases.

HTH
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 <http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users>
>
>
>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ... <mailto:Orocos-Users [..] ...>
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users <http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users>

Btw you can find USB portable oscilloscopes for something like 100€ today,
they won't have a Ghz bandwidth but our softwares never requires that.

2015-08-03 23:07 GMT+02:00 Willy Lambert <lambert [dot] willy [..] ...>:

>
>
> 2015-08-03 17:15 GMT+02:00 Andrew Porterman <andrew [dot] porterman [..] ...>:
>
>> 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...
>>
>> 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)
>>
>>>
>>> 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?
>> 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?
>>
>>
>>
>>> 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).
>> 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...
>>
>> How do the master-slave activities work?
>> Do I have to call excute() or trigger() from within my master component?
>> 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?
>>
>> What is the reason to differentiate between execute and trigger (and
>> update) BTW?
>>
>>
>>>
>>> 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.
>>>
>>
> You are just transposing the validation need on the logging tools that you
> have to check anyway. I may agree on the fact it's less work to check that
> way and that it helps validating functionnal needs, but I've also seen so
> many times developpers being confident ontheir wrong logging system... I
> won't continue the discussion because the original question was not how to
> validate a software but how to check realtiness and my answer is : "with a
> reference clock". I do not consider logging as a valid reference clock.
>
>
>
>>
>>> 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.
>>
>
> The media on which you send the data is not a matter as long as you have
> well designed log queue to buffer log messages that a logging thread will
> transmit to the media. Especially for files, it's by far more efficient if
> you send big dataset to the disk than write octet by octet. Of course the
> mean log rate shall be less than your file writing rate, but you can manage
> burst with a log message queue.
>
>
>
>> 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
>>>
>>>
>>
>> --
>> Orocos-Users mailing list
>> Orocos-Users [..] ...
>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>>
>>
>