[Rock-dev] updateHook hanging (blocked?) when started via syskit

Thu Dec 19 14:29:08 CET 2013

First of all, also Syskit uses orocos.rb to "handle" the components.
The ONLY think afaik syskit does ontop on your scripts is creating a 
read-task for each "state" port of your components.
I see no difference otherwise.

A load of 2.0 for CPUs is really tight, i still assume you are simply on 
the system limits. You could/should try the RT-patched kernel and use 
realtime for your aria task.

Matthias

On 17.12.2013 20:07, Christian Rauch wrote:
> Hi,
>
> thanks so far for the comments.
>
> * bundles vs. orocos.rb:
>
> I attached two scripts which start aria and two camera_ids via:
> a) the orocos.rb API (run_via_orocos.rb)
> b) the bundle (run_via_bundle.rb)
>
> Running 'run_via_orocos' for 15 minutes on the robot, no warnings 
> appear; running 'run_via_bundle' these warnings appear within 2 minutes.
> The load (1min avg) is between 1.5 and 2.0 (2 CPUs).
>
> Monitoring both CPUs remotely via ksysguard, one can see that both 
> CPUs have high loads up to 100% around the same time. If I run via 
> bundles, both CPUs might have their maximum load at the same time and 
> this is when a delay occurs. There are no delays with running via 
> orocos.rb when CPUs have maximum load at the same time.
>
> For testing purposes: Is it possible to let syskit use deployments 
> started outside of syskit (e.g. in a bash) by telling syskit which 
> tasks to use by just giving the task names under which they were 
> registered at corba?
>
>
> * for the camera_ids issue:
>
> The updateHook of the camera_ids triggers itself when a new frame is 
> available (or receives a timeout):
> {{{
>     if(mIsFrame && getFrame()) {
>         [...]
>     }
>
>     mIsFrame = false;
>
>     if (cam_interface->isFrameAvailable()) {
>         mIsFrame = true;
>         this->getActivity()->trigger();
>     } else {
>         RTT::log(RTT::Error) << "No frame received during timeout 
> period." << RTT::endlog();
>         report(TIMEOUT_ERROR);
>     }
>
> }}}
>
> But this issue is not only related to the camera. In previous runs of 
> corridor servoing (no cameras started; but Hokuyo, Dynamixel, Xsens) 
> the same Warnings appear.
>
> Regards,
> Christian
>
>
> Am 17.12.2013 11:56, schrieb Matthias Goldhoorn:
>> ah okay,
>> but btw.
>> you mentioned that the tasks are not within the same deployment.
>> the only Linux in responsible (if they are periodic) for the execution.
>> Try to start everything with run scripts (including logger) and with the
>> same-policy. You will get the same behavior like in syskit's start up.
>>
>> So solve the issue try to use the solution Alex mentioned, if the camera
>> would take too long to acquire the images.
>> BUT i assume still you have a too high load on your system. Maybe you
>> have some high-speed sensors and sensor fusion components NOT within the
>> same deployment which leads into your problems.
>>
>> Maybe there are ways to influence the system behavior, but for this you
>> need to identify the components that took your power.
>> You could use the task-scheduler, i added a new option for this to debug
>> execution times of tasks.
>>
>> Summarize:
>> - make sure all high-speed sensor data within one deployment
>> - separate processing components from this base chain
>> - increase priority for important tasks
>> - take a look on the system LOAD (not only the most-consuming component)
>> - debug components with the scheduler (or any way you prefer)
>> - Make sure no TCP connection is active (Use MQueues instead of corba,
>> don't use the Task-inspector while debugging)
>>
>> Matthias
>>
>> On 17.12.2013 11:14, Elmar Berghöfer wrote:
>>> Hi,
>>>
>>> Am 17.12.2013 11:08, schrieb Matthias Goldhoorn:
>>>> On 17.12.2013 11:07, Elmar Berghöfer wrote:
>>>>> No it just was a replacement of the on-board robot PC by the laptop
>>>>> to make clear that it has nothing to do with performance of the
>>>>> on-board pc.
>>>> Who does the serial interface to the robot in this case. I assume
>>>>
>>>> - Laptop -> camera started
>>>> - Onboard-PC Serial interface for seekuhr
>>> no - Laptop -> connected to Robot controller (via usb-serial 
>>> converter).
>>>
>>> Onboard PC not used in this scenario.
>>>
>>> Test should just figure out if the "quite" low performance of the
>>> on-board pc (even if theoretically should already be enough) is an
>>> issue or not.
>>> The Lapptop System has much more performance than the on-board pc.
>>>
>>> Regards
>>> Elmar
>>>
>>>>
>>>> Right, and there you got the same scheduling problems?
>>>>
>>>> Matthias
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Rock-dev mailing list
>>> Rock-dev at dfki.de
>>> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
>>
>>
>> -- 
>>   Dipl.-Inf. Matthias Goldhoorn
>>   Space and Underwater Robotic
>>
>>   Universität Bremen
>>   FB 3 - Mathematik und Informatik
>>   AG Robotik
>>   Robert-Hooke-Straße 1
>>   28359 Bremen, Germany
>>
>>   Zentrale: +49 421 178 45-6611
>>
>>   Besuchsadresse der Nebengeschäftstelle:
>>   Robert-Hooke-Straße 5
>>   28359 Bremen, Germany
>>
>>   Tel.:    +49 421 178 45-4193
>>   Empfang: +49 421 178 45-6600
>>   Fax:     +49 421 178 45-4150
>>   E-Mail:matthias.goldhoorn at informatik.uni-bremen.de
>>
>>   Weitere Informationen:http://www.informatik.uni-bremen.de/robotik
>>
>
>
>
> _______________________________________________
> Rock-dev mailing list
> Rock-dev at dfki.de
> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev

-- 
  Dipl.-Inf. Matthias Goldhoorn
  Space and Underwater Robotic

  Universität Bremen
  FB 3 - Mathematik und Informatik
  AG Robotik
  Robert-Hooke-Straße 1
  28359 Bremen, Germany

  Zentrale: +49 421 178 45-6611

  Besuchsadresse der Nebengeschäftstelle:
  Robert-Hooke-Straße 5
  28359 Bremen, Germany

  Tel.:    +49 421 178 45-4193
  Empfang: +49 421 178 45-6600
  Fax:     +49 421 178 45-4150
  E-Mail:  matthias.goldhoorn at informatik.uni-bremen.de

  Weitere Informationen: http://www.informatik.uni-bremen.de/robotik

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20131219/c33180d6/attachment.htm 