Unified command interface

[nkhedekar]

The command interface should include 4 commands -

1. SetMotorCommand
2. SetPositionCommand
3. SetVelocityCommand
4. SetTorqueCommand

And 2-3 should internally mask out options and use 1 to actually set a command.

Original issue:
ntnu-arl#2

[vyas-shubham]

Currently, we have sendRadCommand / sendDegreeCommand to access the full command that can be sent to the motor.

The full command is: sendRadCommand(cmd_pos, cmd_vel, Kp, Kd, feedforward_tau).

While working with the sendVelocity/Position command, the respective gains Kp/Kd are also needed. Do you then envision the command's arguments as follows: sendPositionCommand(cmd_pos, Kp)?

This doesn't exist for sendTorqueCommand as the motors have direct torque control and all other arguments can be set to zero.

[nkhedekar]

So I think the commands could be something like this:

std::map<int, motorState> SetMotorCommand(std::map<int, motorCommand> motorRadCommands);
std::map<int, motorState> SetPositionCommand(std::map<int, motorCommand> motorRadCommands);
std::map<int, motorState> SetVelocityCommand(std::map<int, motorCommand> motorRadCommands);
std::map<int, motorState> SetTorqueCommand(std::map<int, motorCommand> motorRadCommands);

However inside the function the nonrelevant fields will be set to zero. So in the case of the position, we could send - position, kp, kd, and everything is explicitly set to zero. Also, the SetPositionCommand would internally call the SetMotorCommand

[vyas-shubham]

That is interesting. Although, the motorCommand struct has all the necessary fields for the full command:

    struct motorCommand{
        float p_des;
        float v_des;
        float kp;
        float kd;
        float tau_ff;       
    };

How about a different struct for position/velocity/torque commands? Or is that too confusing/convoluted?

[nkhedekar]

Sure, a separate struct could work too. If the same is to be kept, the functions should mention in their docstrings that they mask out the unused values internally.