Closed PeterBowman closed 6 years ago
[1] Deprecated in YARP 2.3.70 (despite what that inline comment says...) in favor of the yarp::dev::IPidControl
interface, removed in current devel (3.0.0):
bool setTorquePid(int j, const Pid &pid)
bool setTorquePids(const Pid *pids)
bool setTorqueErrorLimit(int j, double limit)
bool setTorqueErrorLimits(const double *limits)
bool getTorqueError(int j, double *err)
bool getTorqueErrors(double *errs)
bool getTorquePidOutput(int j, double *out)
bool getTorquePidOutputs(double *outs)
bool getTorquePid(int j, Pid *pid)
bool getTorquePids(Pid *pids)
bool getTorqueErrorLimit(int j, double *limit)
bool getTorqueErrorLimits(double *limits)
bool resetTorquePid(int j)
bool disableTorquePid(int j)
bool enableTorquePid(int j)
bool setTorqueOffset(int j, double v)
[2] Removed without any prior advice at current YARP devel (3.0.0):
bool getBemfParam(int j, double *bemf)
bool setBemfParam(int j, double bemf)
[3] Not implemented in our devices, YARP provides a trivial implementation for backward compatibility (just a return false;
) and seemingly designed to replace the last two methods:
bool getMotorTorqueParams(int j, yarp::dev::MotorTorqueParameters *params)
bool setMotorTorqueParams(int j, const yarp::dev::MotorTorqueParameters params)
[4] Also not implemented by us, trivial implementation in upstream header file:
bool setRefTorques(const int n_joint, const int *joints, const double *t)
What can be done here:
All of this applies to the set of ...Raw methods as well. Keep in mind that YARP 3.0.0 is still unstable and may undergo changes at any time before the final release.
Require YARP 2.3.70 either at root CMakeLists.txt
I'd rather go this way, but ASIBOT still has 2.3.68 (at least until I apply the solution mentioned at https://github.com/roboticslab-uc3m/asibot-main/issues/42#issuecomment-383283868) and the protocol changed, which means that two distinct YARP versions would need to run on the same PC: for daily work (e.g. yarp-devices) and just for talking to ASIBOT via remote CB. A temporary, per-device solution seems less invasive.
Either leave [2] as they are, even if not used anymore
Reminds me of the old open loop control mode, also deleted without the usual deprecation process. We ended up leaving a dummy setOpenLoopMode(Raw)
definition (example) and some ugly commented-out bits (example). Despite looking a bit noisy, I prefer to hide unused methods behind preprocessor clauses.
PS if ever requiring YARP 2.3.70 or later, safely remove all occurrences: grep -ri openloop
.
Same deprecation process has been applied to yarp::dev::IVelocityControl2(Raw)
(velocity PID setters/getters). Updating title.
Updating title, several other interfaces have been modified as a result of long planned deprecations. This covers all set<Whatever>Mode(int)
as setPositionMode(int)
in IPositionControl
.
I'd rather go this way, but ASIBOT still has 2.3.68 (at least until I apply the solution mentioned at roboticslab-uc3m/asibot-main#42 (comment)) and the protocol changed, which means that two distinct YARP versions would need to run on the same PC: for daily work (e.g. yarp-devices) and just for talking to ASIBOT via remote CB. A temporary, per-device solution seems less invasive.
As spoken with @jgvictores, we'll set 2.3.70 as the minimum required YARP version.
To sum up:
find_package(YARP)
) were deleted.setOpenLoopMode
).setBemfParam(Raw)
and getBemfParam(Raw)
will no longer exist at YARP 3.0. These have been hidden behind macro guards that check YARP_VERSION_MAJOR!=3
.YARP_VERSION_MAJOR
macro is redefined and shadows the one generated by <yarp/conf/version.h>
:
https://github.com/roboticslab-uc3m/yarp-devices/blob/e28a984e8eb05b74efaece9619dbf066e1f915dd/libraries/YarpPlugins/CanBusControlboard/CMakeLists.txt#L35-L39getMotorTorqueParams
, setMotorTorqueParams
and setRefTorques
have been implemented just in the controlboard-like devices (e.g. CanBusControlboard). CAN node devices have been left out, see #162.IControlMode2
available for YARP bindings at 2.3.70, thus some examples will require 2.3.72 in order to change control mode.VOCAB_PIXEL_...
). I might start an issue/pr for this matter.Related to the previous point, one has to manually encode the corresponding vocab
Pretty convinced the elegant way would be to implement VOCAB
in yarp.i
.
Not sure how to achieve this. I tested simple .i files and a few macros scattered around header files, everything gets exported except macro functions. That is, VOCAB_CM_POSITION
and the like should be wrapped (VOCAB
and VOCABX
not, for instance), but actually they aren't.
Same here. In YARP, things like #define BOTTLE_TAG_INT 1
and #define BOTTLE_TAG_VOCAB (1 + 8)
are wrapped. Info: http://www.swig.org/Doc3.0/Scripting.html#Scripting_nn3 (4.2.3).
Been playing around with lying to SWIG
(haven't got typedef
mechanism to work), will inform after having some results. This for reference: https://stackoverflow.com/questions/11403520/preprocessor-macro-in-swig
PS: Regarding https://github.com/robotology/yarp/pull/1655 it seems there would have been more elegant ways (avoiding the second Vocab.h
inclusion, or via %ignore
).
Fix has been implemented and merged upstream, https://github.com/robotology/yarp/pull/1696
PS: requires SWIG >= 3.0.11 (Xenial comes with 3.0.8).
Related: https://github.com/roboticslab-uc3m/yarp-devices/commit/c2023a1629cfd77c9d09f674c32cd7c4fbf25edc (const correctness of IPositionDirect::setPositions
in YARP 3.0 per https://github.com/robotology/yarp/issues/1351).
Several methods have been removed in favour of the
yarp::dev::IPidControl
interface (stable since YARP 2.3.70). Starting from YARP 3.0.0,yarp::dev::ITorqueControl
will lack several PID-related methods, which is currently breaking our cron builds at YARP's devel branch (example).Suggested steps:
ITorqueControl
handles newIPidControl
methods via deferred calls, ref).