search

roboticslab-uc3m / kinematics-dynamics

Kinematics and dynamics solvers and controllers.
https://robots.uc3m.es/kinematics-dynamics/
GNU Lesser General Public License v2.1
20 stars 14 forks source link

Implement actuator control #115

Open PeterBowman opened 7 years ago

PeterBowman commented 7 years ago

The ICartesianControl interface could provide a method to control an end-effector actuator (e.g. a gripper tool). To not interfere with tool (see #95), a new act/VOCAB_CC_ACT method/RPC vocab pair is proposed.

PeterBowman commented 7 years ago

This is easier to accomplish on AmorControlBoard since we have dedicated API methods for controlling the gripper. On the other hand, BasicCartesianControl connects (as of its current implementation) to a remote controlboard and use all of its joints, regardless whether there are fake ones (i.e. actuators such as the LacqueyFetch or the TextilesHand, see yarp-devices/libraries/BodyYarp) or not. Didn't try it, but I guess that the robot controlboard plugin was launched without these additional "joints" so far.

To sum up, BasicCartesianControl should be able to distinguish motor and actuator joints via explicit --param value options, or fetch this information from the remote controlboard in case it implements the appropriate interface. I was thinking more about yarp::dev::IAxisInfo (VOCAB_JOINTTYPE_UNKNOWN for actuator joints?) or yarp::dev::IRemoteVariables (retrieve the list of motor/actuator joints with getRemoteVariable?). That said, the remote fetch solution would entail changes in the yarp-devices repository.

jgvictores commented 7 years ago

Sounds interesting. If implemented on yarp-devices, should also go in simulator, as in https://github.com/roboticslab-uc3m/openrave-yarp-plugins

PeterBowman commented 7 years ago

My current concept for the future actuator-related method in the ICartesianControl interface is the following signature:

bool act(int command);

Where command would evaluate to one vocab of the following new set:

Still wondering how would this cope with hypothetical implementations of generic (non-gripper) actuators of any kind. Should the controller/remote controlboard/both be aware of the actuator type?

PeterBowman commented 7 years ago

WIP at the amor-cc-actuator branch (locally) to get a first insight of this interface working on AMOR. As noted before, broader changes are required to accomplish this in the generic controller with custom actuators.

ICartesianControl vocabs:

https://github.com/roboticslab-uc3m/kinematics-dynamics/blob/a9b6ecd1cfc2ea28041e2dc752b25c7d809bfe47/libraries/TeoYarp/ICartesianControl.h#L86-L91

New method signature:

https://github.com/roboticslab-uc3m/kinematics-dynamics/blob/a9b6ecd1cfc2ea28041e2dc752b25c7d809bfe47/libraries/TeoYarp/ICartesianControl.h#L245-L254

Implementation at AmorCartesianControl:

https://github.com/roboticslab-uc3m/kinematics-dynamics/blob/a9b6ecd1cfc2ea28041e2dc752b25c7d809bfe47/libraries/TeoYarp/AmorCartesianControl/ICartesianControlImpl.cpp#L224-L251

Used in several apps: keyboardController, streamingDeviceController, haarDetectionController.

PeterBowman commented 6 years ago

That said, the remote fetch solution would entail changes in the yarp-devices repository.

Marking as blocked.

PeterBowman commented 5 years ago

Update: I'm not convinced anymore about the IRemoteVariables interface, see https://github.com/roboticslab-uc3m/yarp-devices/issues/198#issuecomment-495322968. Also, the upstream work on yarp-devices would imply https://github.com/roboticslab-uc3m/yarp-devices/issues/211.

@jgvictores OK to merge amor-cc-actuator branch into develop as a first approach for tackling this problem (at least) on AMOR? We'll most probably rewrite that part sooner or later, but those changes would not be lost (and it will spare me doing a lot of merge commits on the already-too-long run).

PeterBowman commented 5 years ago

Update: I'm not convinced anymore about the IRemoteVariables interface, see roboticslab-uc3m/yarp-devices#198 (comment). Also, the upstream work on yarp-devices would imply roboticslab-uc3m/yarp-devices#211.

Note: https://github.com/roboticslab-uc3m/yarp-devices/issues/20 will enable arbitrary CAN bus + YARP wrapper configurations, and https://github.com/roboticslab-uc3m/yarp-devices/issues/171 is going to wrap raw joints involved in the actuation. Two remarks:

PeterBowman commented 2 years ago

Per https://github.com/roboticslab-uc3m/kinematics-dynamics/issues/162#issuecomment-532344770:

I plan to merge numRobotJoints and numSolverJoints into one entity that represents motor joints, only. That is, the (until and for now) only additional YARP-handled joint, which corresponds to the LacqueyFetch single-motor gripper, will be exposed via a dedicated YARP port to which BasicCartesianControl would have to connect via a separate remote_controlboard device in case it needs to access actuator commands (https://github.com/roboticslab-uc3m/kinematics-dynamics/issues/115). See rationale at https://github.com/roboticslab-uc3m/yarp-devices/issues/228#issuecomment-532200863.

We might want to rethink the whole act command stuff. See also https://github.com/roboticslab-uc3m/yarp-devices/issues/228.