• The directory /opt/www/bruyninckxh2/web/tmp/drutex-9ee0a9ebf00d8ca8588d710e48ba9b76-1 has been created.
  • The directory /opt/www/bruyninckxh2/web/tmp/drutex-9ee0a9ebf00d8ca8588d710e48ba9b76-2 has been created.
  • The directory /opt/www/bruyninckxh2/web/tmp/drutex-9ee0a9ebf00d8ca8588d710e48ba9b76-3 has been created.

Missing classes from motion_control example

Is the source for some of the missing components in the motion_control
example available? Several classes don't seem to be in the trunk e.g.
nAxesSensor, nAxesEffectorVel, CartesianSensor, CartesianEffectorVel.
These look like they might be the same as components I'm about to
implement ...

Cheers
Stephen

Missing classes from motion_control example

On Friday 25 April 2008 16:01:18 S Roderick wrote:
> Is the source for some of the missing components in the motion_control
> example available? Several classes don't seem to be in the trunk e.g.
> nAxesSensor, nAxesEffectorVel, CartesianSensor, CartesianEffectorVel.
> These look like they might be the same as components I'm about to
> implement ...

You can find them in the OCL .tar.bz2 release balls (or SVN trunk/ocl ) under
motion control. But I did not recently test that example, also because you
need to get the KDL dependency correct. For example, OCL trunk works only
with KDL trunk. And I'm not sure which KDL version OCL 1.4.x needs.

Peter

Missing classes from motion_control example

On Apr 25, 2008, at 10:18 , Peter Soetens wrote:

> On Friday 25 April 2008 16:01:18 S Roderick wrote:
>> Is the source for some of the missing components in the
>> motion_control
>> example available? Several classes don't seem to be in the trunk e.g.
>> nAxesSensor, nAxesEffectorVel, CartesianSensor, CartesianEffectorVel.
>> These look like they might be the same as components I'm about to
>> implement ...
>
> You can find them in the OCL .tar.bz2 release balls (or SVN trunk/
> ocl ) under
> motion control. But I did not recently test that example, also
> because you
> need to get the KDL dependency correct. For example, OCL trunk works
> only
> with KDL trunk. And I'm not sure which KDL version OCL 1.4.x needs.

Updated svn to trunk for rtt, kdl and ocl. Still can't find them.
S

trunk $ svn up ocl
At revision 29209.

trunk $ svn info ocl
Path: ocl
URL: http://svn.mech.kuleuven.be/repos/orocos/trunk/ocl
Repository Root: http://svn.mech.kuleuven.be/repos/orocos
Repository UUID: ce417995-dfc9-0310-95a0-acdaff106893
Revision: 29209
Node Kind: directory
Schedule: normal
Last Changed Author: rsmits
Last Changed Rev: 29206
Last Changed Date: 2008-04-23 04:29:17 -0400 (Wed, 23 Apr 2008)

trunk $ egrep -Ri \"cartesiansensor\" ocl | egrep -v \"Binary|.svn|xml\"
ocl/debian/liborocos-ocl-cartesian-dev.install:usr/include/ocl/
CartesianSensor.hpp
ocl/doc/usage.dox:*

  • OCL::CartesianSensor
    ocl/motion_control/cartesian/CartesianControllerPos.cpp:
    _position_meas(\"CartesianSensorPosition\"),
    ocl/motion_control/cartesian/CartesianControllerPos.hpp: ///
    OCL::CartesianSensor
    ocl/motion_control/cartesian/CartesianControllerPosVel.cpp:
    _position_meas(\"CartesianSensorPosition\"),
    ocl/motion_control/cartesian/CartesianControllerPosVel.hpp: ///
    OCL::CartesianSensor
    ocl/motion_control/cartesian/CartesianControllerVel.cpp:
    _position_meas(\"CartesianSensorPosition\"),
    ocl/motion_control/cartesian/CartesianControllerVel.hpp: ///
    OCL::CartesianSensor
    ocl/motion_control/cartesian/CartesianGeneratorPos.cpp:
    _position_meas(\"CartesianSensorPosition\"),
    ocl/motion_control/cartesian/CartesianGeneratorPos.hpp: ///
    frame, shared with OCL::CartesianSensor
    ocl/motion_control/cartesian/CartesianVelocityController.cpp:
    cartpos_port(\"CartesianSensorPosition\",KDL::Frame::Identity()),
    ocl/motion_control/cartesian/cpf/program_moveto.ops: do
    CartesianSensor.start()
    ocl/motion_control/cartesian/cpf/program_moveto.ops: do
    CartesianSensor.stop()

    trunk $ find ocl -iname '*cartesiansensor*'

    trunk $ ls
    kdl ocl ocl-template rtt rtt-examples

    trunk $ find . -iname '*cartesiansensor*'

    trunk $

  • Ruben Smits's picture

    Missing classes from motion_control example

    On Friday April 25 2008 16:42:17 S Roderick wrote:
    > On Apr 25, 2008, at 10:18 , Peter Soetens wrote:
    > > On Friday 25 April 2008 16:01:18 S Roderick wrote:
    > >> Is the source for some of the missing components in the
    > >> motion_control
    > >> example available? Several classes don't seem to be in the trunk e.g.
    > >> nAxesSensor, nAxesEffectorVel, CartesianSensor, CartesianEffectorVel.
    > >> These look like they might be the same as components I'm about to
    > >> implement ...
    > >
    > > You can find them in the OCL .tar.bz2 release balls (or SVN trunk/
    > > ocl ) under
    > > motion control. But I did not recently test that example, also
    > > because you
    > > need to get the KDL dependency correct. For example, OCL trunk works
    > > only
    > > with KDL trunk. And I'm not sure which KDL version OCL 1.4.x needs.
    >
    > Updated svn to trunk for rtt, kdl and ocl. Still can't find them.
    > S
    >

    The missing classes are all deprecated. Look at the naxes.xml and
    cartesian.xml files for the usage of the new style components.

    Ruben

    Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

    Missing classes from motion_control example

    On Apr 25, 2008, at 10:46 , Ruben Smits wrote:

    > On Friday April 25 2008 16:42:17 S Roderick wrote:
    >> On Apr 25, 2008, at 10:18 , Peter Soetens wrote:
    >>> On Friday 25 April 2008 16:01:18 S Roderick wrote:
    >>>> Is the source for some of the missing components in the
    >>>> motion_control
    >>>> example available? Several classes don't seem to be in the trunk
    >>>> e.g.
    >>>> nAxesSensor, nAxesEffectorVel, CartesianSensor,
    >>>> CartesianEffectorVel.
    >>>> These look like they might be the same as components I'm about to
    >>>> implement ...
    >>>
    >>> You can find them in the OCL .tar.bz2 release balls (or SVN trunk/
    >>> ocl ) under
    >>> motion control. But I did not recently test that example, also
    >>> because you
    >>> need to get the KDL dependency correct. For example, OCL trunk works
    >>> only
    >>> with KDL trunk. And I'm not sure which KDL version OCL 1.4.x needs.
    >>
    >> Updated svn to trunk for rtt, kdl and ocl. Still can't find them.
    >> S
    >>
    >
    > The missing classes are all deprecated. Look at the naxes.xml and
    > cartesian.xml files for the usage of the new style components.

    Found naxes-test.xml and cartesian-test.xml.

    So the most up-to-date approach is in "ocl/motion_control", correct?

    Having dug through the ocl/motion_contro/cartesian test example, I
    have some more questions (yes they just keep coming, sorry!)

    - some of the cartesian classes use Read/WriteDataPorts, while others
    use simply DataPort. Why the difference, and which do you recommend?
    The first seems to provide more information as you know which are
    inputs and which are outputs.

    - some classes use DataPort > while others use
    std::vector*>. Why the difference, and which do
    you recommend?

    - there are different naming approaches to cartesian data throughout
    the classes. Some are _position_meas, _velocity_desi, etc, while
    others are simply cartvel, naxespos, etc. Again, why the difference?
    The 2 schemes do make it harder to connect the dots. Personally, the
    _position_meas, etc, provides the better information as a name. YMMV.

    - to figure out what port on one task is connected to which ports on
    other tasks, you really have to look at the name given each port when
    constructed, even though the name of the data member (ie
    "RTT::ReadDataPort< KDL::Twist > _velocity_desi;") almost gives
    enough information to connect the ports. Correct?

    - there is an implicit ordering in computation of the robot, velocity
    controller, generator, and controllerposvel tasks, isn't there. It's
    actually based on the matching periodicity and the order of creation
    of the tasks. Right?

    - if I'm not mistaken (and the above assumption on implicit ordering
    is correct), then there's a one cycle delay between updating measured
    robot position and actully outputting new drive values, right? On one
    cycle, the measured position is updated, and data propogates through
    the velocity controller, the generator, and the controller, providing
    updated drive values. But it's the next cycle, during
    robot.updateHook() that these new drive values actually go to
    hardware. Correct?

    Just trying to figure out the what and the why, so as to better map
    what's already in Orocos to what we need.

    As always, thanks!
    S

    Ruben Smits's picture

    Missing classes from motion_control example

    On Friday April 25 2008 16:01:18 S Roderick wrote:
    > Is the source for some of the missing components in the motion_control
    > example available? Several classes don't seem to be in the trunk e.g.
    > nAxesSensor, nAxesEffectorVel, CartesianSensor, CartesianEffectorVel.
    > These look like they might be the same as components I'm about to
    > implement ...

    The motion_control components were resently refactored. We did not yet had the
    time to update the tests and examples. I'll try to fix this as soon as
    possible.

    Ruben

    Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm