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