move3d

Hi,

This comes from the fact that in the the libmove3d robot structure
(p3d_rob) the joint indexed 0 is the base joint, i.e. the world inertial
frame.
The first joint of any robot is therefore indexed 1.

From what you say I understand that the base joint is not copied in the
libmove3d-planners Robot class ?

Alex.

On 09/12/2015 15:01, Jules Waldhart wrote:

Issue #708 has been reported by Jules Waldhart.

----------------------------------------
Bug #708: [p3d,planners] inconsistency of joint IDs
https://redmine.laas.fr/issues/708

• Author: Jules Waldhart
• Status: New
• Priority: Normal
• Assignee: Jules Waldhart
• Category:
• Target version:
  ----------------------------------------
  We really should do something for this. The source of the problem can be found in Robot constructor:

API/Device/robot.cpp,line 84:
m_Joints.push_back(new Joint(this, _Robot->joints[i + 1], i, _copy));
^

So we have 2 convention coexisting: 1st joint a id=0 (Robot) or at id=1 (p3d).
Then, in that same class (Robot), both "conventions" are used. Hence, the confusion is propagated all over move3d-planners

In my opinion the best would be to avoid confusion by using only P3D convention (maybe in a perfect world it is a good idea to use the Robot class convention, and I understand that choice, but in our world...)

Exactly. And in Robot class, calling getJoint(0) will return the first joint.

I think this choice have been made because joint 0 not needed (it's just an interface).

The other option is to fix the inconsistencies, but the confusion will persist. Unless we use a different type to refer to Robot joints incompatible with int (used for p3d joints), but that's quite strange.

I'm not sure I understand the problem then.
The all idea of the API is that the underlying p3d structures are hidden
to the user.
So I wouldn't call that an inconsistency per say.
If accessing the base joint is not needed (as I believe is the case)
then this way of doing thing seems OK to me.

On 12/09/2015 03:28 PM, Jules Waldhart wrote:

Issue #708 has been updated by Jules Waldhart.

Exactly. And in Robot class, calling getJoint(0) will return the first joint.

I think this choice have been made because joint 0 not needed (it's just an interface).

The other option is to fix the inconsistencies, but the confusion will persist. Unless we use a different type to refer to Robot joints incompatible with int (used for p3d joints), but that's quite strange.

----------------------------------------
Bug #708: [p3d,planners] inconsistency of joint IDs
https://redmine.laas.fr/issues/708#change-568

• Author: Jules Waldhart
• Status: New
• Priority: Normal
• Assignee: Jules Waldhart
• Category:
• Target version:
  ----------------------------------------
  We really should do something for this. The source of the problem can be found in Robot constructor:

API/Device/robot.cpp,line 84:
m_Joints.push_back(new Joint(this, _Robot->joints[i + 1], i, _copy));
^

So we have 2 convention coexisting: 1st joint a id=0 (Robot) or at id=1 (p3d).
Then, in that same class (Robot), both "conventions" are used. Hence, the confusion is propagated all over move3d-planners

In my opinion the best would be to avoid confusion by using only P3D convention (maybe in a perfect world it is a good idea to use the Robot class convention, and I understand that choice, but in our world...)

Yes. That would be in a perfect world. The problem is that the interface is not complete. So it is in evolution and people still do the confusion while developing it (so methods in Robot class are inconsistent) and some code of planners accesses to structures of lower level that uses the p3d convention.

In the same kind of inconsistencies I'm sure we can find lot of methods that take, e.g. an API::Trajectory class as input and return a p3d_traj struct.