Proposal: General endpoint specification

Overview

This feature request targets point #4 on the wish list about being able to configure the teleoperation pipeline for different endpoints. This extends the the possible applications of the teleoperation pipeline and also enables its use with other robots than REEM.

Target changes

The current pipeline implementation already handles different types of endpoints. For example the retargeting of the head motion is done quite simple. Only the head orientation is mapped onto the robot. Retargeting the arm motion on the other hand involves the shoulder, elbow and hand endpoints.

But there is currently no way to retarget only parts of the body or parts of the motion of an endpoint. For example, one might only want to retarget the head motion, even if the motion of the whole body of the operator is captured and a robot with more than needed DOFs is available. Or one might only want retarget the the hand motion without caring about the elbow - the used robot might not even have one.

The above outlined differences mainly target motion_adaption, which is doing the rescaling of the target endpoints. The used IK service of the tree_kinematics package is already able to work with multiple endpoints and allows the specification, which task space directions are used (position and orientation).

Proposals for the interface redesign

List here your thoughts about how the above described feature could/should be implemented.

Marcus

My thoughts went into two directions: My main goal is to find an abstract endpoint definition, which allows to cover all/many use cases. Since I haven't found such a definition yet and I also expected that there might be some iterations/redesigns needed to find such, I tried to come up with simpler definitions. These need to cover at least the current use cases: retargeting the complete upper body of REEM and Robosem.

Currently 2 different endpoint types are implemented:

for the head and torso fixed/unscaled translations and unchanged orientations
for the arms (elbow and wrist endpoints) complex scaling of translations and calculation of new orientations

For Robosem we would need to add a new typ for the 2-DOF arms (2-DOF shoulder + fixed arm).

So, we could implement these 3 types and add new ones as needed.

Another idea is to allow the specification of involved segments. For example, the scaling of the translations for REEM's wrists involves 3 segments (torso->shoulder, shoulder->elbow, elbow->wrist), for Robosem's arms 2 and for the head and torso only 1. That however covers only the scaling of the translations. I still miss a good idea on how to integrate orientations into this approach. Maybe, we allow to specify if orientations are not mapped, mapped untouched or compute from scratch, such as in the case of the REEM's arms.

Adolfo

I'd first like to see some doc on how motion adaption currently works, in particular how it chooses to adapt each frame. I checked the different branches in Github, and the doc is very poor.

Motion adaption should only adapt frames specified in the relevant configuration file, nothing else. So, even if we have a full humanoid robot, the application might be such that it only requires adapting a small subset of endpoints. I was thinking in something of the likes of:

coupling_type1
  requisite1: foo
  requisite2:
    -bar
    -baz

coupling_type2
...

The coupling_type represents each different type of supported adaption, and the requisites represent the requirements for that particular type of adaptaiton (input/output frames, extra metadata). I cannot provide a comprehensive list of examples without digging into the code, but this would be the next logical step.

The endpoint term is a bit overloaded, as it may also refer to IK endpoints. It might also be useful to bring IK endpoints into the discussion as well, as they might also be subject to a similar specification.

Wiki

Page

User