[Rock-dev] <base/motion_command.h>

[Sylvain Joyeux]

On 11/08/2011 03:35 PM, Chris Müller wrote:
> On 08.11.2011 13:51, Sylvain Joyeux wrote:
>> You need the time at which the actual motors are actuated according to
>> your motion command. Which is not what the motion command will provide
>> you. That was the general idea about not timestamping those: these
>> timestamps are not strictly usable for estimation.
>> anyway, as it would allow the measurement of control loop latencies.
>>
>> However, for the purpose of a motion model, I am wondering why you
>> don't use the motors reported PWM (since you are using the hbridges,
>> you can do that). That would remove the controller =>  actuator driver
>> =>  actuator latency, and work regardless of the controller / control
>> method being used (and, for instance, of the presence of ramping).
>>
> That makes sense, of course.
>
>> If your estimator is deployed in the RT scheduler, does not do an
>> memory allocation, and is using a suitable priority, then you could
>> neglect the latency and create the timestamp on input.
>
> That sounds interesting. I know this is not part of the actual question
> anymore. Is it something I need to configure on the operating system? Or
> can i control that in one of our runtime system (orocos.rb, roby). I
> know this not part of the actual question anymore. Its only for
> extending my knowledge about the capabilities of the framework.
It is not part of the original question, but *is* part of the

A few things are needed:
  * having a RT kernel. Asguard is using Linux-RT, which has proved to
    be more than sufficient for our needs (latencies < 1ms)
    See http://pengutronix.de for packages for Debian. AFAIK, Avalon is
    already using such a kernel.
  * properly configuring the IRQ priorities
  * on the orogen level, declaring tasks as

   task(task_name, task_model).
    realtime.
    priority(priority_value)

  * make sure that you have the right to get RT tasks. This is
    configured, on Debian, in /etc/security/limits.conf. Orocos warns
    you that it's moving realtime tasks on a non-RT scheduler when the
    rights are not setup as they should
  * realize that some devices are *not* hard-RT, i.e. they have
    unbounded latencies (USB comes to mind).
  * realize that the CORBA layer is not RT. The POSIX MQueues are, and
    are completely integrated within Rock (even though it is not really
    well documented, because there are some caveats). In any case, if
    you put the two tasks in the same deployment (i.e. "process"), you
    don't use a transport and are completely fine
  * for this to work you *need* to have NO memory allocation in the
    updateHook. Which is something people should strive for anyway, when
    possible. [*]

The .realtime puts the orocos threads in the RT_FIFO scheduler. In this 
scheduler, tasks of higher priorities will always be executed before 
tasks of lower priorities (which also mean, obviously, that they can 
completely starve a system).

[*] This is not entirely true. RTT contains the TLSF realtime memory
     allocator. However, its usage currently requires that you know the
     upper bound of needed memory, and the installation of RTT. It's not
     integrated in rock since we want to remain RTT-independent at the
     algorithm level.
-- 
Sylvain Joyeux (Dr.Ing.)
Space & Security Robotics

!!! Achtung, neue Telefonnummer!!!

Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 178-454136
Fax:   +49 (0)421 218-454150
E-Mail: robotik at dfki.de

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.:    DE 148646973
Steuernummer:  19/673/0060/3
-----------------------------------------------------------------------