[prev in list] [next in list] [prev in thread] [next in thread] 

List:       orocos-users
Subject:    [Orocos-users] Two-headed activities
From:       kiwi.net () mac ! com (S Roderick)
Date:       2012-01-13 20:19:51
Message-ID: 109BBFDB-9881-4DB8-B9A4-D7D241B45305 () mac ! com
[Download RAW message or body]

On Jan 13, 2012, at 10:35 , Stephen Roderick wrote:

> On Jan 7, 2012, at 04:15 , Markus Klotzbuecher wrote:
> 
> > On Fri, Jan 06, 2012 at 07:38:19PM +0100, Stephen Roderick wrote:
> > > On Jan 6, 2012, at 09:08 , Markus Klotzbuecher wrote:
> > > 
> > > > On Fri, Jan 06, 2012 at 01:42:38PM +0100, S Roderick wrote:
> > > > > We have a need to synchronize a suite of components, controlled by a
> > > > > single Coordination component, to a hardware signal. But that signal
> > > > > isn't available during initialization and shutdown (which takes many
> > > > > seconds), and may block or dissappear at certain times. During these
> > > > > periods, we still want the Coordinator to be able to run
> > > > > periodically. So I think we need a custom Activity that is periodic
> > > > > by default, but otherwise synchronized to the hardware signal when
> > > > > available. Obviously the Coordinator component and/or the activity
> > > > > will have to deal appropriately with the timeout on the hardware
> > > > > signal.
> > > > > 
> > > > > Has anyone done anything like this before? Does anyone have any
> > > > 
> > > > Not exactly, but similar. 
> > > > 
> > > > > alternative suggestions?
> > > > 
> > > > The event driven scenario: Have a periodic TimerComponent trigger your
> > > > event driven Coordinator at your desired "base" frequency. Then simply
> > > > connect your event generating hardware component (or any other!).
> > > > 
> > > > I like this one somewhat better, because it doesn't require a new
> > > > primitive (the custom Activity). One the other hand for ultra-low
> > > > latencies the latter might do slightly better; YMMV.
> > > 
> > > Your idea does have merit, however, you hit the nail on the head as
> > > we need very low latency. But out of curiosity, how do you imagine
> > 
> > Ok. But note that RTT is indeed quite efficient at communicating event
> > messages. On my machine using C++ components the wakeup latency with
> > this approach was few tens of microseconds ([1], Section 4.2).
> > 
> > > connecting the "event generating hardware component"? Particularly
> > > as that item isn't an Orocos component.
> > 
> > You will have a software (driver) component too, no? That one defines
> > a port to which it writes a data-sample according to the hardware
> > signal. Then you only need to connect that output port to an event
> > port of your coordinator.
> > 
> > Markus
> 
> We have ended up doing this a little differently, but I wanted to communicate the \
> result, along with a few interesting things learned along the way. 
> Our hardware driver is in a non-Orocos controlled thread, and writes to a pipe when \
> the hardware updates. This is the signal we want to sync on. This signal is not \
> available until the hardware is fully initialized (takes several seconds), and is \
> not available if certain hardware faults occur. 
> Our coordinator is simply a state machine, now run by a FileDescriptorActivity \
> (FDA). The FDA timeout capability is used to drive this component when the hardware \
> signal is not available. We had to add a method call to the run() blocks for each \
> state of interest, to process the FDA results (error, timeout,  isUpdated, etc) and \
> react accordingly.  
> Interesting observations (these pertain to RTT v1)
> 
> - emitting an event to the coordinator causes additional step() executions to occur \
> (i.e update hook executions, and state machine cycles). This can overload CPUs ... \
> which is what happened to us (we went from the intended 500 Hz, to almost 4 kHz). \
> This will also occur for commands (search for trigger() in EventProcessor and \
> CommandProcessor implementations). The user implemention must deal with this. 
> - it might be possible that the work fd set in FDA can be used when not \
> initialized, if an isUpdated() call occurs before loop(). This would not be the \
> typical call sequence, but ... 
> - I believe that there is a possible race condition in the FDA implementation, that \
> can theoretically cause fd activity to be missed. The timing for this to occur is \
> very fine though. You have to watch() a new fd exactly when an existing fd activity \
> occurs. The loop within a loop in loop() that processes the trigger-update-sets \
> command can set do_trigger to false, causing the fd activity of that cycle to be \
> ignored.

And one thing I missed

- for cases such as ours, where the file descriptor being watched is periodic in \
nature, I think we should allow the FDA to be configured with an _intended_ period. \
This allows the component, or components called via slave activities, to use the \
intended period (e.g. getPeriod() ) in computations. So a Computational component \
used within a Periodic activity in one deployment, or with a FD activity that is \
based on a periodic signal in a different deployemtn, requires no additional \
configuration or changes.


[prev in list] [next in list] [prev in thread] [next in thread]