Implement cyclic synchronous velocity (CSV) mode

[PeterBowman]

Our yarp::dev::IVelocityControl implementation uses Technosoft's Profile Velocity mode of operation. This mode implies a known acceleration ramp (given by IVelocityControl::setRefAcceleration, also available in the IPositionControl interface), that is, the drive will never command the motor to achieve the desired velocity instantaneously. On the other hand, in external reference speed mode it is assumed that the acceleration is not limited given the default configuration:

In external reference speed mode, you can limit the maximum acceleration at sudden changes of the speed reference and thus to get a smoother transition. This feature is activated by setting Controlword.5=1 and the maximum acceleration value in object Profile Acceleration (6083 h ).

We might want to check this mode out in the context of a velocity-controlled application.

[PeterBowman]

A standard-compliant and perhaps more feature-attractive alternative exists: CSV (cyclic synchronous velocity) mode. It is achieved in CSP mode (cyclic synchronous position, see #222) with relative positioning. See iPOS CANopen user manual (2019), section 10.1.1, Controlword in Cyclic Synchronous Position mode (CSP):

In absolute position mode, the drive will always travel to the absolute position given to object 607Ah. This is the standard mode.

In relative position mode, the drive will add to its current position the value received in object 607Ah. By sending this value periodically and setting the correct interpolation period time in object 60C2h, it will be like working in Cyclic Synchronous Velocity mode (CSV).

[PeterBowman]

It is achieved in CSP mode (cyclic synchronous position, see #222) with relative positioning.

Disclaimer, to be honest: this is not velocity control per se. We are going to mask velocity commands passing through yarp::dev::IVelocityControl into relative position targets, that is, there will always be a position control loop under the hood. Spoken with @jgvictores and @smcdiaz.

[PeterBowman]

Disclaimer, to be honest: this is not velocity control per se.

In addition, the velocity profile mode of operation (iPOS) adheres best to yarp::dev::IVelocityControl commands, note the acceleration-related methods. We discarded this iPOS mode due to previous failures in movl commands via BasicCartesianControl. Today, however, we tried again and succeeded: motion followed a nice linear path with a SYNC/command period of 30 milliseconds and a 0.5 gain. In fact, we were able to extend TEO's right arm even with a 1 kg load attached to it, ultimately achieving millimeter precision. We just had to switch back to position control mode in order to avoid the arm falling down on motion completion: roboticslab-uc3m/kinematics-dynamics@d5f6ebd.

I'm happily closing this as WONTFIX.

[PeterBowman]

ASWJ we'd like to allow users to enter into CSV mode at will via IRemoteVariables, i.e. change the internal mapping for IVelocityControl commands (default: velocity profile mode).

Proposed protocol: #222 (comment).

[PeterBowman]

Implemented at a5f2c7a and ultimately ready at d747bb0 after a thorough improvement of the IRemoteVariables interface. To expand on #222 (comment):

---

getRemoteVariablesList

Lists all CAN node IDs prepended with "id", e.g. (id15 id16 ...).

• RPC sample usage: [get] [ivar] [lvar]
• Response: (id15 id16 id17 id18 id19 id20)

---

getRemoteVariable

Retrieves all available key-value pairs for the selected node. Calls getRemoteVariablesListRaw to get raw keys and then iterates on getRemoteVariableRaw.

• RPC sample usage: [get] [ivar] [mvar] id15
• Response: (id15 (linInterp ((enable 0))) (csv (enable 0)))

If key equals all, it returns remote vars for all available CAN nodes.

• RPC sample usage: [get] [ivar] [mvar] all
• Response: ((id15 (linInterp ((enable 0))) (csv (enable 0))) (id16 (linInterp ((enable 0))) (csv (enable 0))) (id17 (linInterp ((enable 0))) (csv (enable 0))) (id18 (linInterp ((enable 0))) (csv (enable 0))) (id19 (linInterp ((enable 0))) (csv (enable 0))) (id20 (linInterp ((enable 0))) (csv (enable 0))))

---

setRemoteVariable

Requires a key-value two-element bottle, value is a nested list.

• RPC sample usage: [set] [ivar] [mvar] id15 (linInterp ((enable 1) (mode pt) (bufferSize 1)))

Multiple keys can be bound per call, just nest them within an additional layer of bottles.

• RPC sample usage: [set] [ivar] [mvar] id15 ((linInterp ((enable 1) (mode pt) (bufferSize 1))) (csv (enable 1)))

Same strategy works if you want to set the exact same remote variable (or variables) for all available nodes, just use all as key.

• RPC sample usage: [set] [ivar] [mvar] all (linInterp ((enable 1) (mode pt) (bufferSize 1)))
• RPC sample usage: [set] [ivar] [mvar] all ((linInterp ((enable 1) (mode pt) (bufferSize 1))) (csv (enable 1)))

It is also possible to target multiple nodes in a single call, and set one or more remote variables at once. Use multi as key.

• RPC sample usage: [set] [ivar] [mvar] multi ((id15 (csv (enable 1))) (id17 (csv (enable 0))))
• RPC sample usage: [set] [ivar] [mvar] multi ((id16 ((linInterp ((enable 0))) (csv (enable 1)))) (id20 (csv (enable 1))))

---

Yes, the more you look at it, the more Lispy it feels: https://xkcd.com/297/.

[PeterBowman]

Commit 66afe3f adds an enable option that reflects and controls internal state of both linInterp and csv raw variables. I reflected it in the above comment. Note we get and set a dictionary in linInterp, whereas csv is happy with a bare list.

[PeterBowman]

I might revisit and vastly change this remote-vars interface at #260.

Edit: done, see README.