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

[Christian Rauch]

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
>

-- 
  Christian Rauch
  Space Robotics

  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-6619
  Empfang: +49 421 178 45-6600
  Fax:     +49 421 178 45-4150
  E-Mail:  Christian.Rauch at dfki.de

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: aria_delay_test.tar.gz
Type: application/x-gzip
Size: 2689 bytes
Desc: not available
Url : http://www.dfki.de/pipermail/rock-dev/attachments/20131217/1a5c1a78/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4988 bytes
Desc: S/MIME Cryptographic Signature
Url : http://www.dfki.de/pipermail/rock-dev/attachments/20131217/1a5c1a78/attachment-0001.bin