search

roboticslab-uc3m / yarp-devices

A place for YARP devices
https://robots.uc3m.es/yarp-devices/
9 stars 7 forks source link

Implement cyclic synchronous velocity (CSV) mode #221

Closed PeterBowman closed 4 years ago

PeterBowman commented 5 years ago

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 commented 4 years ago

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 https://github.com/roboticslab-uc3m/yarp-devices/issues/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 commented 4 years ago

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 commented 4 years ago

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: https://github.com/roboticslab-uc3m/kinematics-dynamics/commit/d5f6ebd9c24d39ac8049d28ba394dd9644d8a15f.

I'm happily closing this as WONTFIX.

PeterBowman commented 4 years ago

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: https://github.com/roboticslab-uc3m/yarp-devices/issues/222#issuecomment-575095243.

PeterBowman commented 4 years ago

Implemented at https://github.com/roboticslab-uc3m/yarp-devices/commit/a5f2c7a253f25ee7bcf415bd7cd30177a5ebfbdc and ultimately ready at https://github.com/roboticslab-uc3m/yarp-devices/commit/d747bb092bb59ef8e888bb11234a7e7037e547db after a thorough improvement of the IRemoteVariables interface. To expand on https://github.com/roboticslab-uc3m/yarp-devices/issues/222#issuecomment-575095243:

getRemoteVariablesList

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

getRemoteVariable

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

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

setRemoteVariable

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

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

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

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.

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

PeterBowman commented 4 years ago

Commit https://github.com/roboticslab-uc3m/yarp-devices/commit/66afe3fb8dc61b022561a9570187d7195152b310 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 commented 1 year ago

I might revisit and vastly change this remote-vars interface at https://github.com/roboticslab-uc3m/yarp-devices/issues/260.

Edit: done, see README.