Closed PeterBowman closed 4 years ago
I can confirm object 6061h ("Modes of Operation Display") reports CSP mode is entered successfully with https://github.com/roboticslab-uc3m/yarp-devices/pull/229 and firmware F508M/F509M (tested on CAN ids 19 and 20), despite object 6502h ("Supported drive modes") hinting it was not possible. I did not change any EasySetup configuration.
For the record, iPOS firmware upgrade was tracked at https://github.com/roboticslab-uc3m/teo-hardware-issues/issues/42.
CSP mode successfully tested. I was going to retain old (legacy) interpolation submodes. However, the online position-direct implementation is more than enough (and probably more robust) via CSP, hence I'll probably desist. Offline trajectory execution through legacy modes will be targeted in a new issue.
While providing backward support to pt/pvt modes, I redesigned the way parameters are passed to subdevices via IRemoteVariables(Raw)
iface. From the POV of CanBusControlboard, i.e. this is exposed via YARP ports:
getRemoteVariablesList
: lists all CAN node names, e.g. (id15-ipos id16-ipos ...)
[get] [ivar] [lvar]
getRemoteVariable
: retrieves all available key-value pairs for this node; calls getRemoteVariablesListRaw
to get keys and then iterates on getRemoteVariableRaw
[get] [ivar] [mvar] id15-ipos
setRemoteVariable
: requires a key-value two-element bottle, value is a nested list
[set] [ivar] [mvar] id15-ipos (linInterp ((mode pt) (bufferSize 1)))
Ready at https://github.com/roboticslab-uc3m/yarp-devices/commit/3a9fe3e10e7882a29a040a8fd751e13f08777c31. Old PT/PVT can be configured as described above, but it is currently disabled. Any attempts to switching into position-direct mode with these legacy submodes enabled will lead to a failure. Also, I noticed a persisting integrity counter error and abnormal (= fierce) joint motion; ignoring this as explained in https://github.com/roboticslab-uc3m/yarp-devices/issues/222#issuecomment-575092455.
Offline usage of PT/PVT will be targeted at https://github.com/roboticslab-uc3m/yarp-devices/issues/245.
While providing backward support to pt/pvt modes, I redesigned the way parameters are passed to subdevices via
IRemoteVariables(Raw)
iface. From the POV of CanBusControlboard, i.e. this is exposed via YARP ports:
I added this at https://github.com/roboticslab-uc3m/yarp-devices/commit/bd1a72b63dd22b670fd1e21ff7d670254c195522 (the page has a disclaimer that the protocols may be subject to change anyway).
I just implemented joint velocity checks in CSP mode at https://github.com/roboticslab-uc3m/yarp-devices/commit/9fb6962cd55b0794d6f1103173979e34d5c6cce6. Robot arms behave horribly when controlled via spnav mouse. I presume this is caused by the cartesian controller sending commands that assume the robot has achieved the desired target, thus losing the actual reference (see https://github.com/roboticslab-uc3m/kinematics-dynamics/issues/173#issuecomment-493479201). As a result of this, the arm motion is erratic and goes totally bananas (techie term) when it is told to move faster. Note maxVel
is configured at a notably high 50 degrees/second threshold, even though it seems not enough at all.
Issue https://github.com/roboticslab-uc3m/yarp-devices/issues/188 derived from a long discussionmonologue at https://github.com/roboticslab-uc3m/kinematics-dynamics/issues/173. Velocity checks were added at the joint command level (namely, in this repository). Now I think only callers should be responsible for performing those checks, i.e. the cartesian controller for the case being.
I did a quick search across the robotology org. IControlLimitsRaw::setVelLimitsRaw
is implemented in iCubSimulationControl
, CanBusMotionControl
and GazeboYarpControlBoardDriver
. Their robot board does not support joint velocity limit commands, see ref ("internally cached, not sent to the fw yet"). Ours doesn't, too.
cc @jgvictores for science. ATOW, we use maxVel
in velocity (ref) and position-direct/CSP commands (ref), and incidentally in IPositionControl::setRefSpeed
(ref) as well.
I just implemented joint velocity checks in CSP mode at 9fb6962. Robot arms behave horribly when controlled via spnav mouse.
Guess what, it was my fault and commit https://github.com/roboticslab-uc3m/yarp-devices/commit/ef6e264ab0efda56d5aa697d3a644e8a2170af9c easily fixed this. Of course, high-level apps would still suffer from this very same problem in case high-velocity targets are commanded to the robot boards. So, @jgvictores and I concluded such high-level apps (e.g. the cartesian motion controllers) should always perform position/velocity checks on resulting joint commands prior to sending them down to the joint controllers. Thus, low-level checks are per-joint mandatory lifeboats, but when coordinated motion is required, high-level should also clip those values (and probably perform FK/IK in cartesian space) in order to achieve correct behavior (e.g. linear movement).
In https://github.com/roboticslab-uc3m/yarp-devices/issues/198, an attempt was made to try the CSP mode of operation (https://github.com/roboticslab-uc3m/yarp-devices/issues/198#issuecomment-487375251):
Tested again via object 6502h, Supported drive modes: https://github.com/roboticslab-uc3m/yarp-devices/issues/198#issuecomment-514985662.
Also learned that... (https://github.com/roboticslab-uc3m/yarp-devices/issues/198#issuecomment-516616792)
And, more recently... (ref)