<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">First of all, also Syskit uses
      orocos.rb to "handle" the components.<br>
      The ONLY think afaik syskit does ontop on your scripts is creating
      a read-task for each "state" port of your components.<br>
      I see no difference otherwise.<br>
      <br>
      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.<br>
      <br>
      Matthias<br>
      <br>
      On 17.12.2013 20:07, Christian Rauch wrote:<br>
    </div>
    <blockquote cite="mid:52B0A0D5.4070302@dfki.de" type="cite">Hi,
      <br>
      <br>
      thanks so far for the comments.
      <br>
      <br>
      * bundles vs. orocos.rb:
      <br>
      <br>
      I attached two scripts which start aria and two camera_ids via:
      <br>
      a) the orocos.rb API (run_via_orocos.rb)
      <br>
      b) the bundle (run_via_bundle.rb)
      <br>
      <br>
      Running 'run_via_orocos' for 15 minutes on the robot, no warnings
      appear; running 'run_via_bundle' these warnings appear within 2
      minutes.
      <br>
      The load (1min avg) is between 1.5 and 2.0 (2 CPUs).
      <br>
      <br>
      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.
      <br>
      <br>
      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?
      <br>
      <br>
      <br>
      * for the camera_ids issue:
      <br>
      <br>
      The updateHook of the camera_ids triggers itself when a new frame
      is available (or receives a timeout):
      <br>
      {{{
      <br>
      &nbsp;&nbsp;&nbsp; if(mIsFrame &amp;&amp; getFrame()) {
      <br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [...]
      <br>
      &nbsp;&nbsp;&nbsp; }
      <br>
      <br>
      &nbsp;&nbsp;&nbsp; mIsFrame = false;
      <br>
      <br>
      &nbsp;&nbsp;&nbsp; if (cam_interface-&gt;isFrameAvailable()) {
      <br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; mIsFrame = true;
      <br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; this-&gt;getActivity()-&gt;trigger();
      <br>
      &nbsp;&nbsp;&nbsp; } else {
      <br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RTT::log(RTT::Error) &lt;&lt; "No frame received during
      timeout period." &lt;&lt; RTT::endlog();
      <br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; report(TIMEOUT_ERROR);
      <br>
      &nbsp;&nbsp;&nbsp; }
      <br>
      <br>
      }}}
      <br>
      <br>
      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.
      <br>
      <br>
      Regards,
      <br>
      Christian
      <br>
      <br>
      <br>
      Am 17.12.2013 11:56, schrieb Matthias Goldhoorn:
      <br>
      <blockquote type="cite">ah okay,
        <br>
        but btw.
        <br>
        you mentioned that the tasks are not within the same deployment.
        <br>
        the only Linux in responsible (if they are periodic) for the
        execution.
        <br>
        Try to start everything with run scripts (including logger) and
        with the
        <br>
        same-policy. You will get the same behavior like in syskit's
        start up.
        <br>
        <br>
        So solve the issue try to use the solution Alex mentioned, if
        the camera
        <br>
        would take too long to acquire the images.
        <br>
        BUT i assume still you have a too high load on your system.
        Maybe you
        <br>
        have some high-speed sensors and sensor fusion components NOT
        within the
        <br>
        same deployment which leads into your problems.
        <br>
        <br>
        Maybe there are ways to influence the system behavior, but for
        this you
        <br>
        need to identify the components that took your power.
        <br>
        You could use the task-scheduler, i added a new option for this
        to debug
        <br>
        execution times of tasks.
        <br>
        <br>
        Summarize:
        <br>
        - make sure all high-speed sensor data within one deployment
        <br>
        - separate processing components from this base chain
        <br>
        - increase priority for important tasks
        <br>
        - take a look on the system LOAD (not only the most-consuming
        component)
        <br>
        - debug components with the scheduler (or any way you prefer)
        <br>
        - Make sure no TCP connection is active (Use MQueues instead of
        corba,
        <br>
        don't use the Task-inspector while debugging)
        <br>
        <br>
        Matthias
        <br>
        <br>
        On 17.12.2013 11:14, Elmar Bergh&ouml;fer wrote:
        <br>
        <blockquote type="cite">Hi,
          <br>
          <br>
          Am 17.12.2013 11:08, schrieb Matthias Goldhoorn:
          <br>
          <blockquote type="cite">On 17.12.2013 11:07, Elmar Bergh&ouml;fer
            wrote:
            <br>
            <blockquote type="cite">No it just was a replacement of the
              on-board robot PC by the laptop
              <br>
              to make clear that it has nothing to do with performance
              of the
              <br>
              on-board pc.
              <br>
            </blockquote>
            Who does the serial interface to the robot in this case. I
            assume
            <br>
            <br>
            - Laptop -&gt; camera started
            <br>
            - Onboard-PC Serial interface for seekuhr
            <br>
          </blockquote>
          no - Laptop -&gt; connected to Robot controller (via
          usb-serial converter).
          <br>
          <br>
          Onboard PC not used in this scenario.
          <br>
          <br>
          Test should just figure out if the "quite" low performance of
          the
          <br>
          on-board pc (even if theoretically should already be enough)
          is an
          <br>
          issue or not.
          <br>
          The Lapptop System has much more performance than the on-board
          pc.
          <br>
          <br>
          Regards
          <br>
          Elmar
          <br>
          <br>
          <blockquote type="cite">
            <br>
            Right, and there you got the same scheduling problems?
            <br>
            <br>
            Matthias
            <br>
            <br>
          </blockquote>
          <br>
          <br>
          <br>
          _______________________________________________
          <br>
          Rock-dev mailing list
          <br>
          <a class="moz-txt-link-abbreviated" href="mailto:Rock-dev@dfki.de">Rock-dev@dfki.de</a>
          <br>
          <a class="moz-txt-link-freetext" href="http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev">http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev</a>
          <br>
        </blockquote>
        <br>
        <br>
        --
        <br>
        &nbsp; Dipl.-Inf. Matthias Goldhoorn
        <br>
        &nbsp; Space and Underwater Robotic
        <br>
        <br>
        &nbsp; Universit&auml;t Bremen
        <br>
        &nbsp; FB 3 - Mathematik und Informatik
        <br>
        &nbsp; AG Robotik
        <br>
        &nbsp; Robert-Hooke-Stra&szlig;e 1
        <br>
        &nbsp; 28359 Bremen, Germany
        <br>
        <br>
        &nbsp; Zentrale: +49 421 178 45-6611
        <br>
        <br>
        &nbsp; Besuchsadresse der Nebengesch&auml;ftstelle:
        <br>
        &nbsp; Robert-Hooke-Stra&szlig;e 5
        <br>
        &nbsp; 28359 Bremen, Germany
        <br>
        <br>
        &nbsp; Tel.:&nbsp;&nbsp;&nbsp; +49 421 178 45-4193
        <br>
        &nbsp; Empfang: +49 421 178 45-6600
        <br>
        &nbsp; Fax:&nbsp;&nbsp;&nbsp;&nbsp; +49 421 178 45-4150
        <br>
        &nbsp; <a class="moz-txt-link-abbreviated" href="mailto:E-Mail:matthias.goldhoorn@informatik.uni-bremen.de">E-Mail:matthias.goldhoorn@informatik.uni-bremen.de</a>
        <br>
        <br>
        &nbsp; Weitere
        Informationen:<a class="moz-txt-link-freetext" href="http://www.informatik.uni-bremen.de/robotik">http://www.informatik.uni-bremen.de/robotik</a>
        <br>
        <br>
      </blockquote>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Rock-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Rock-dev@dfki.de">Rock-dev@dfki.de</a>
<a class="moz-txt-link-freetext" href="http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev">http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev</a>
</pre>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
 Dipl.-Inf. Matthias Goldhoorn 
 Space and Underwater Robotic

 Universit&auml;t Bremen
 FB 3 - Mathematik und Informatik
 AG Robotik
 Robert-Hooke-Stra&szlig;e 1
 28359 Bremen, Germany
 
 Zentrale: +49 421 178 45-6611
 
 Besuchsadresse der Nebengesch&auml;ftstelle: 
 Robert-Hooke-Stra&szlig;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:  <a class="moz-txt-link-abbreviated" href="mailto:matthias.goldhoorn@informatik.uni-bremen.de">matthias.goldhoorn@informatik.uni-bremen.de</a>

 Weitere Informationen: <a class="moz-txt-link-freetext" href="http://www.informatik.uni-bremen.de/robotik">http://www.informatik.uni-bremen.de/robotik</a></pre>
  </body>
</html>