Using the device interface classes

I am using the latest Orocos Toolchain for Linux Xenomai. I would like to test the RT performances of a simple periodic Orocos component by generating a square signal whose output I visualize on an external oscilloscope.

At the end of the Orocos Component Manual, there is mention of IO capabilities using the comedi drivers. I already have a code compiled with Xenomai using the analogy drivers which does exactly what I want (ie the square signal).

My component was created using orocreate-pkg and I deploy it with deployer-xenomai.

However I can't figure out how to use the AnalogOutInterface. Would there be an example somewhere?

Using the device interface classes

On Thu, May 23, 2013 at 2:27 PM, <f [dot] hautbois [..] ...> wrote:
> I am using the latest Orocos Toolchain for Linux Xenomai. I would like to
> test the RT performances of a simple periodic Orocos component by generating
> a square signal whose output I visualize on an external oscilloscope.
>
> At the end of the Orocos Component Manual, there is mention of IO
> capabilities using the comedi drivers. I already have a code compiled with
> Xenomai using the analogy drivers which does exactly what I want (ie the
> square signal).
>
> My component was created using orocreate-pkg and I deploy it with
> deployer-xenomai.
>
> However I can't figure out how to use the AnalogOutInterface. Would there be
> an example somewhere?

There was once code that used this interface class, but it has never
made it into Orocos 2.x. I don't think it has that much value
nowadays...

Peter

Additional inquiries

I've ported my analogy driver code (forgetting the AnalogOutInterface) to Orocos without any noticeable problem when it comes to the header file (#include<analogy/analogy.h>).

However, things get a bit more complicated when running the "make" command in my Orocos component, as I get: "undefined reference to 'a4l_open' in configureHook" and "undefined reference to 'a4l_sync_write' in updateHook". The fix for this error is to add "-lanalogy" after the -L statement for my gcc compiler. However barely have any control over compilation options, and I was not able to find where to add this flag in any CMakeLists.txt files.

One last thing. In <http://www.orocos.org/forum/orocos/orocos-users/xenomai-vs-rtai-real-time-performance>, there are mentions of jitter tests and so on (especially from _snrkiwi_), without any more information. Any way someone could share his knowledge about this?

Thank you

Additional inquiries

On Fri, May 24, 2013 at 10:40 AM, <f [dot] hautbois [..] ...> wrote:
> I've ported my analogy driver code (forgetting the AnalogOutInterface) to
> Orocos without any noticeable problem when it comes to the header file
> (#include).
>
> However, things get a bit more complicated when running the "make" command in
> my Orocos component, as I get: "undefined reference to 'a4l_open' in
> configureHook" and "undefined reference to 'a4l_sync_write' in updateHook".
> The fix for this error is to add "-lanalogy" after the -L statement for my
> gcc compiler. However barely have any control over compilation options, and I
> was not able to find where to add this flag in any CMakeLists.txt files.

You definitely need to spend 1h on a cmake tutorial :-)

>
> One last thing. In , there are mentions of jitter tests and so on (especially
> from _snrkiwi_), without any more information. Any way someone could share
> his knowledge about this?

We're all using the RTT::os::TimeService class to measure elapsed time and do
some bookkeeping to print avg,min,max....

Peter

Additional inquiries

On May 27, 2013, at 16:31 , Peter Soetens wrote:

> On Fri, May 24, 2013 at 10:40 AM, <f [dot] hautbois [..] ...> wrote:
>> I've ported my analogy driver code (forgetting the AnalogOutInterface) to
>> Orocos without any noticeable problem when it comes to the header file
>> (#include).
>>
>> However, things get a bit more complicated when running the "make" command in
>> my Orocos component, as I get: "undefined reference to 'a4l_open' in
>> configureHook" and "undefined reference to 'a4l_sync_write' in updateHook".
>> The fix for this error is to add "-lanalogy" after the -L statement for my
>> gcc compiler. However barely have any control over compilation options, and I
>> was not able to find where to add this flag in any CMakeLists.txt files.
>
> You definitely need to spend 1h on a cmake tutorial :-)
>
>>
>> One last thing. In , there are mentions of jitter tests and so on (especially
>> from _snrkiwi_), without any more information. Any way someone could share
>> his knowledge about this?
>
> We're all using the RTT::os::TimeService class to measure elapsed time and do
> some bookkeeping to print avg,min,max....

We have classes that do scoped timers, using boost's posix_time library, and minimax on that data. It's not rocket science - really simple stuff. The RTT::os::TimeService would do the same thing.
S

Additional inquiries

The RTT::os::TimeService works a treat!

For a period of 1ms, my latency is __+/-25us__ (with a CPU fully loaded and while sending interruptions by moving the mouse and typing on the keyboard). I had the same latency results when testing Xenomai alone with an oscilloscope.

Additional inquiries

On Tue, 28 May 2013, f [dot] hautbois [..] ... wrote:

> The RTT::os::TimeService works a treat!
>
> For a period of 1ms, my latency is __+/-25us__ (with a CPU fully loaded and
> while sending interruptions by moving the mouse and typing on the keyboard).
> I had the same latency results when testing Xenomai alone with an
> oscilloscope.
>

This looks like good news :-) How is the jitter doing? (That is, the
_variation_ in the latency.)

But don't generalize it to all computational
hardware that you might be using now and in the future.

Herman
--
University of Leuven, Mechanical Engineering, Robotics Research Group
<http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
Vice-President Research euRobotics AISBL <http://www.eu-robotics.net>
Open RObot COntrol Software <http://www.orocos.org>
Associate Editor JOSER <http://www.joser.org>

Additional inquiries

Further statistics (everything is in nanoseconds except the variance which is in ns^2, the test is the same as the one described above):

Min : 971707 ; Max : 1054494 (slightly worse) Mean : 999480 (remember the period is 1ms) ; Variance : 3670040 -> standard deviation : 1916

Flavian

Additional inquiries

On Tue, 28 May 2013, f [dot] hautbois [..] ... wrote:

> Further statistics (everything is in nanoseconds except the variance which is
> in ns^2, the test is the same as the one described above):
>
> Min : 971707 ; Max : 1054494 (slightly worse)
> Mean : 999480 (remember the period is 1ms) ;

I am a bit confused by this answer (Hint: you should use a context-preserving
threading policy...)

Since we were discussing the _latency_ number, I would be tended to
interpret your latency numbers as very bad, since latency is the same as
the desired period...? Hopefully you are reporting the _period_ itself?

> Variance : 3670040 -> standard deviation : 1916
>
> Flavian

Herman

Additional inquiries

>
> On Tue, 28 May 2013, f [dot] hautbois [..] ... wrote:
>
> Further statistics (everything is in nanoseconds except the variance which
>> is
>> in ns^2, the test is the same as the one described above):
>>
>> Min : 971707 ; Max : 1054494 (slightly worse)
>> Mean : 999480 (remember the period is 1ms) ;
>>
>
> I am a bit confused by this answer (Hint: you should use a
> context-preserving
> threading policy...)
>

I guess I shouldn't use the website GUI then.

>
> Since we were discussing the _latency_ number, I would be tended to
> interpret your latency numbers as very bad, since latency is the same as
> the desired period...? Hopefully you are reporting the _period_ itself?
>
>
No, I measure the period of the signal. During the test, the minimum period
is 971707 (1ms - 29us), maximum period is 1054494 (1ms + 50us) -> total
latency is 79us. Measured mean period : 999480 (~=1ms), measured jitter ~=
2us.

2013/5/28 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>

> On Tue, 28 May 2013, f [dot] hautbois [..] ... wrote:
>
> Further statistics (everything is in nanoseconds except the variance
>> which is
>> in ns^2, the test is the same as the one described above):
>>
>> Min : 971707 ; Max : 1054494 (slightly worse)
>> Mean : 999480 (remember the period is 1ms) ;
>>
>
> I am a bit confused by this answer (Hint: you should use a
> context-preserving
> threading policy...)
>
> Since we were discussing the _latency_ number, I would be tended to
> interpret your latency numbers as very bad, since latency is the same as
> the desired period...? Hopefully you are reporting the _period_ itself?
>
> Variance : 3670040 -> standard deviation : 1916
>>
>> Flavian
>>
>
> Herman
>

Additional inquiries

On Tue, 28 May 2013, Flavian Hautbois wrote:

>>
>> On Tue, 28 May 2013, f [dot] hautbois [..] ... wrote:
>>
>> Further statistics (everything is in nanoseconds except the variance which
>>> is
>>> in ns^2, the test is the same as the one described above):
>>>
>>> Min : 971707 ; Max : 1054494 (slightly worse)
>>> Mean : 999480 (remember the period is 1ms) ;
>>>
>>
>> I am a bit confused by this answer (Hint: you should use a
>> context-preserving
>> threading policy...)
>>
>
> I guess I shouldn't use the website GUI then.
>
>> Since we were discussing the _latency_ number, I would be tended to
>> interpret your latency numbers as very bad, since latency is the same as
>> the desired period...? Hopefully you are reporting the _period_ itself?
>>
> No, I measure the period of the signal. During the test, the minimum period
> is 971707 (1ms - 29us), maximum period is 1054494 (1ms + 50us) -> total
> latency is 79us. Measured mean period : 999480 (~=1ms), measured jitter ~=
> 2us.

Thanks! This looks _a lot_ better :-)

Note that latenc is typically only using the values that are _late_, since
the implicit assumption is that a process/thread will _never_ be woken up
earlier than requested...

> 2013/5/28 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
>
>> On Tue, 28 May 2013, f [dot] hautbois [..] ... wrote:
>>
>> Further statistics (everything is in nanoseconds except the variance
>>> which is
>>> in ns^2, the test is the same as the one described above):
>>>
>>> Min : 971707 ; Max : 1054494 (slightly worse)
>>> Mean : 999480 (remember the period is 1ms) ;
>>>
>>
>> I am a bit confused by this answer (Hint: you should use a
>> context-preserving
>> threading policy...)
>>
>> Since we were discussing the _latency_ number, I would be tended to
>> interpret your latency numbers as very bad, since latency is the same as
>> the desired period...? Hopefully you are reporting the _period_ itself?
>>
>> Variance : 3670040 -> standard deviation : 1916
>>>
>>> Flavian
>>>
>>
>> Herman
>>
>
>
>
>

Additional inquiries

2013/5/28 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>

> On Tue, 28 May 2013, Flavian Hautbois wrote:
>
>
>>> On Tue, 28 May 2013, f [dot] hautbois [..] ... wrote:
>>>
>>> Further statistics (everything is in nanoseconds except the variance
>>> which
>>>
>>>> is
>>>> in ns^2, the test is the same as the one described above):
>>>>
>>>> Min : 971707 ; Max : 1054494 (slightly worse)
>>>> Mean : 999480 (remember the period is 1ms) ;
>>>>
>>>>
>>> I am a bit confused by this answer (Hint: you should use a
>>> context-preserving
>>> threading policy...)
>>>
>>>
>> I guess I shouldn't use the website GUI then.
>>
>> Since we were discussing the _latency_ number, I would be tended to
>>> interpret your latency numbers as very bad, since latency is the same as
>>> the desired period...? Hopefully you are reporting the _period_ itself?
>>>
>>> No, I measure the period of the signal. During the test, the minimum
>> period
>> is 971707 (1ms - 29us), maximum period is 1054494 (1ms + 50us) -> total
>> latency is 79us. Measured mean period : 999480 (~=1ms), measured jitter ~=
>> 2us.
>>
>
> Thanks! This looks _a lot_ better :-)
>
> Note that latenc is typically only using the values that are _late_, since
> the implicit assumption is that a process/thread will _never_ be woken up
> earlier than requested...

I have to admit that the fact I had a shorter period was bugging me. Could
you expand a little bit on that?

Additional inquiries

On May 28, 2013, at 09:09 , Flavian Hautbois wrote:

> 2013/5/28 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> On Tue, 28 May 2013, Flavian Hautbois wrote:
>
>
> On Tue, 28 May 2013, f [dot] hautbois [..] ... wrote:
>
> Further statistics (everything is in nanoseconds except the variance which
> is
> in ns^2, the test is the same as the one described above):
>
> Min : 971707 ; Max : 1054494 (slightly worse)
> Mean : 999480 (remember the period is 1ms) ;
>
>
> I am a bit confused by this answer (Hint: you should use a
> context-preserving
> threading policy...)
>
>
> I guess I shouldn't use the website GUI then.
>
> Since we were discussing the _latency_ number, I would be tended to
> interpret your latency numbers as very bad, since latency is the same as
> the desired period...? Hopefully you are reporting the _period_ itself?
>
> No, I measure the period of the signal. During the test, the minimum period
> is 971707 (1ms - 29us), maximum period is 1054494 (1ms + 50us) -> total
> latency is 79us. Measured mean period : 999480 (~=1ms), measured jitter ~=
> 2us.
>
> Thanks! This looks _a lot_ better :-)
>
> Note that latenc is typically only using the values that are _late_, since
> the implicit assumption is that a process/thread will _never_ be woken up
> earlier than requested...
>
> I have to admit that the fact I had a shorter period was bugging me. Could you expand a little bit on that?

Probably because it's doing absolute time calculations. So it's trying to hit 1.0010, then 1.0020, 1.0030, etc. So if it runs long on one cycle (actual is 1.0011) then on the next cycle you lose that amount of overrun to get back on target (so 1.0020 - 1.0011 = 0.0009 = 10% short).
S

How to link analogy with an Orocos component

Create your Orocos Component using >orocreate-pkg MyComponent. Then do:

>cd MyComponent

>make

>cd /build/src/CMakeFiles/MyComponent.dir/

In this directory you'll find a file link.txt. You must add -lanalogy right before -lpthread.

/!\ This solution is _not_ elegant, as list.txt is generated by CMake. Could a developer point out where this particular line in link.txt is generated? Thanks

How to link analogy with an Orocos component

On Mon, May 27, 2013 at 4:16 PM, <f [dot] hautbois [..] ...> wrote:
>
> Create your Orocos Component using orocreate-pkg MyComponent
> Then do:
>
> >cd MyComponent
>
> >make
>
> >cd /build/src/CMakeFiles/MyComponent.dir/
>
> In this directory you'll find a file link.txt. You must add -lanalogy right
> before -lpthread.
>
> /!\ This solution is _not_ elegant, as list.txt is generated by CMake. Could
> a developer point out where this particular line in link.txt is generated?
> Thanks

edit the CMakeLists.txt file and use:

find_library( ANALOGY analogy )
target_link_libraries( mycomponent ANALOGY )

which will work if libanalogy.so is in your standard library search paths.

Peter

Peter

How to link analogy with an Orocos component

Taking a CMake tutorial would be the thing to do ;)

But in that particular case it kind of hard to figure out where to begin and what is or isn't possible (to me it feels like diving into the Linux kernel source before learning C++).

I guess there are a lot of people who want to use Orocos but don't necessarily know CMake; for those people it would be nice to have sort of a tutorial in your already very good Orocos Component Manual, named "adding external libraries".

That could be useful for people wanting to use OpenCV for example.