Hi Ruben

On 08/05/2015 11:56 AM, Ruben Smits wrote:
> Hi Gianni,
> On Wed, Aug 5, 2015 at 11:46 AM Gianni Borghesan
> <gianni [dot] borghesan [..] ...
> <mailto: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.

I push in the repo, it works with a caveat:

since the update hook is run once when the configure hook is called,
and, since the update hook is meant to be executed when data is present,
and, since calling the configure hook is non blocking and therefore
there is no insurance that once you call configure (and update) in node
N the configure and update in node N+1 is finished, there can be a
problem in initialization.

I solved this by using a flag that is set at the first update, and
returns immediately (thus over-riding the default behaviour f calling
the update just after the configure).

By the way. which is the reason to call the update in front of an
operation or the configure call?

>
> R.
>
> cheers, Gianni, and sorry for non-inline posting !
>
>
>
>
> 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 [..] ... kiwi [dot] net [..] ...>
> <mailto:kiwi [dot] net [..] ... 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 [..] ...>
> > <mailto:andrew [dot] porterman [..] ...
> <mailto:andrew [dot] porterman [..] ...>>>
> > Cc: Orocos Users <orocos-users [..] ...
> <mailto:orocos-users [..] ...>
> > <mailto:orocos-users [..] ...
> <mailto:orocos-users [..] ...>>>
> >
> >
> > On Aug 03, 2015, at 11:15, Andrew Porterman
> <andrew [dot] porterman [..] ... andrew [dot] porterman [..] ...>
> > <mailto: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 [..] ...>
> >> <mailto:kiwi [dot] net [..] ... kiwi [dot] net [..] ...>>>:
> >>
> >> On Jul 31, 2015, at 13:52, Willy Lambert
> <lambert [dot] willy [..] ... lambert [dot] willy [..] ...>
> >> <mailto:lambert [dot] willy [..] ...
> <mailto:lambert [dot] willy [..] ...>>> wrote:
> >>>
> >>>
> >>>
> >>> 2015-07-31 18:36 GMT+02:00 Andrew Porterman
> >>> <andrew [dot] porterman [..] ...
> <mailto:andrew [dot] porterman [..] ...>
> <mailto:andrew [dot] porterman [..] ...
> <mailto: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>
> >>> <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 [..] ...>
> >> <mailto: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 [..] ...
> <mailto:Orocos-Users [..] ...>
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>