Cartesian Point and Pose Ambiguity

While designing the library we encountered a general problem regarding Cartesian space definitions.

Usually, a robot pose is defined as a CartesianPose with a definition of translation and orientation of the tool center point. This is also true for general objects in space.

In contrast there are also some parameters like mass offset for payload handling that only require a translational offset to work.

As such, we discussed, if it is feasible to also introduce a CartesianPoint data class that only contains translation information to be more precise what is interpreted here.

The upside would be that it is more clear to the user what values are actually relevant.

The downside is a massive increase of complexity in the implementation as well as the usability. CartesianPoints are kind of a subset of CartesianPoses. The data in a CartesianPoint can always be stored in a CartesianPose with arbitrary orientation values.

Having two classes that can represent the same thing would lead to a lot of unnecessary conversions between the two types depending on the interface currently in use.

There also is an implicit conversion problem in regards to math operations. Normal expectation would be that a CartesianPoint and CartesianPose can be added or subtracted from each other, which will sometimes lead to implicit data type conversions. What is the result of a point + a pose and does the type differ from pose + point?

Furthermore, most method interfaces would have to be extended to support CartesianPoint data types or each time a Point is used by a user it has to be converted to a Pose prior the usage. One example is move_ptp, which at time of writing only allows for CartesianPose as the target parameter.

Result

We define:

Every object in Cartesian space used for calculations always has an orientation component and is represented by a CartesianPose. A Point is expressed by a CartesianPose with an arbitrary orientation component, preferably rx,ry,rz = 0.