Why is the torque interface of libfranka used to implement the OSC_POSE controller instead of the CartesianPose interface of libfranka?

[David0tt]

For my application I am trying to move to specific target poses in cartesian space. To do this, I calculate the pose_error = target_pose - current_pose and use this as the action command for the OSC_POSE (OSCImpedanceController) controller.

However, when i do this the robot stops short of the desired pose (by roughly ~2cm).

I believe this to be a general limitation of a torque impedance type control interface such as the one used by the deoxys C++ backend, since small errors in the feedforward model (e.g. wrong gravity or friction compensation) can lead to relatively large pose errors.

I know that in principle a position control interface would be better suited for this task, however I want to use the deoxys OSC_POSE controller due to its compliant behavior, and to allow interoperability with ML systems (VLA/RL), which require this control interface.

To examine this issue, I tried to examine the deoxys C++ backend. In particular, I realised that it computes the desired joint torques \tau by means of Jacobian and then sends these torques to the libfranka control interface via

void Robot::control(std::function<Torques(const RobotState&, franka::Duration)> control_callback,
                    bool limit_rate,
                    double cutoff_frequency)

However, i have found that there is also the following control interface:

void Robot::control(
    std::function<CartesianPose(const RobotState&, franka::Duration)> motion_generator_callback,
    ControllerMode controller_mode,
    bool limit_rate,
    double cutoff_frequency)

or

void Robot::control(
    std::function<Torques(const RobotState&, franka::Duration)> control_callback,
    std::function<CartesianPose(const RobotState&, franka::Duration)> motion_generator_callback,
    bool limit_rate,
    double cutoff_frequency)

Which i intuitively would believe to be more naturally suited to use, since here one could directly pass the desired CartesianPose, and the robots PD controller converts this into the appropriate torques (i.e. it would do what currently needs to be done by deoxys). As far as i understand it this also would result in a cartesian impedance controller, in particular when using controller_mode = ControllerMode::kCartesianImpedance.

So my question is: why is the torque interface of libfranka used instead of one of the CartesianPose interfaces?