On 06/21/2013 01:10 PM, f [dot] hautbois [..] ... wrote:
> >We(at KTH, Stockholm) usually use one of the following three alternatives
>
> >1. 'Most realtime': CAN bus
>
> >2. 'A little less realtime': A publish/subscribe component that uses DDS
>
> >3. 'Even less realtime': A publisher/subscribe component that uses ØMQ
>
> >Orocos is, in theory, independent of the underlying transport mechanism
>
> >and this is evident from the existence of CORBA and mqueue transports
>
> >exist. There exists even a YARP transport. In practice, making a new
>
> >transport seems to require more-than-trivial understanding of orocos
> >internals ;-)
>
> >Regards,
>
> >Sagar
>
> How did you integrate CAN in your process?

We usually use kvaser CAN devices. The drivers are not strictly
realtime, but after numerous observations, we have seen that the WCET
does not exceed a certain value once the dataflow is stabilized. This is
'good enough' for us and we make our application robust to whatever
slight variation we observe.

> From what I read, YARP does not provide real-time communication abilities...

Neither does standard CORBA. However, past discussions on this list lead
me to believe that even if the transport implementation is not real-time
in itself, it is still possible to use the transport with a hard
realtime taskcontext (i.e. the TC does not leave hard realtime due to
the transport), but I am not sure about this.

Have you calculated the extent to which you actually need realtime in
the communication? We've seen that many applications work 'good enough'
with fast, interference free communication channels, esp. if we do
something like this

[TC1: RT component]-->[high freq.,non RT comm.]-->[TC2: (simple
interpolating filter)+RT component]

Regards,
Sagar