Velocity Control implementation strategy

[arocchi]

The current velocity control implementation strategy needs to be checked.
Pros:

• works very nicely

Cons:

• needs a magic number for the SetMaxForce parameter, otherwise weird things happen (i.e., setting 0 velocity sometimes the joint starts to move if SetMaxForce is called using a big number). If we set SetMaxForce to the joint effort limit, the control does not work, if it is 1.1 times that number, it magically works again even though the actual torque which is commanded to the physics engine is clamped anyway to the effort limit. We need to investigate this better.
• there is a bug at the moment when switching from velocity to other control kinds, so that after using velocity control both torque and position control modes cannot be used (I suspect this could be solved easily by setting velocity ref to 0, max force to 0 when switching from velocity control to any other control)

Possible other implementation: using gazebo's JointController
Pros:

• it is a PID, so similar to the one implemented on the robot (I suppose?)
• control switching works

Cons:

• doesn't work at the moment: what PID values should we set?

[traversaro]

Just for reference, the velocity control implemented in the iCub (I don't know about the coman) is described here: http://wiki.icub.org/wiki/Force_Control#Available_control_modes

[EnricoMingo]

Problem: with he actual version of the joint velocity controller is not possible to read torque. The returned value is always the maximum. We should pass through the JointController. There is some commented code inside coman.h in sendVelocityToGazebo. May you try to use it?

[lornat75]

Notice that the “implicit switch” is a feature that is implemented on the iCub, but we have been discussing to remove it for many reasons. I would suggest that in the simulator you postpone implementing this logic until strictly required.

Also I would like to hear your opinion on this matter.

From: Silvio Traversaro [mailto:notifications@github.com]
Sent: mercoledì 6 novembre 2013 17:13
To: EnricoMingo/gazebo_yarp_plugins
Subject: Re: [gazebo_yarp_plugins] Velocity Control implementation strategy (#27)

Just for reference, the velocity control implemented in the iCub (I don't know about the coman) is described here: http://wiki.icub.org/wiki/Force_Control#Available_control_modes

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/27#issuecomment-27886871.

[MirkoFerrati]

I agree on postponing the implicit switch, let's wait and see what will be running on coman.
We read about the minimum jerk in velocity control but we decided it was too much for now. So we just used the setVelocity of the gazebo joints directly.

[EnricoMingo]

What I was suggesting was to use simply the JointController interface of GAZEBO, why: first it is a simple PID on velocity level, second its the common interface for all the dynamic engines (while setVelocity maybe is not available outside ODE). Before it was not working because there are problems with the PID of the position control that has to be set to 0. Alessio already opened an issue about this in the repository of GAZEBO.

[MirkoFerrati]

Ok, I didn't connect the PID reset issue with the velocity JointController
not working. The commented code will not work out of the box, but it's easy
to write a JointCmd message, just replace mutableposition with
mutableVelocity. Should I do this and push before lunch?

2013/11/7 EnricoMingo notifications@github.com

What I was suggesting was to use simply the JointController interface of
GAZEBO, why: first it is a simple PID on velocity level, second its the
common interface for all the dynamic engines (while setVelocity maybe is
not available outside ODE). Before it was not working because there are
problems with the PID of the position control that has to be set to 0.
Alessio already opened an issue about this in the repository of GAZEBO.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/27#issuecomment-27954030
.

[EnricoMingo]

Why will not work?

[MirkoFerrati]

Ok, it will work cause somebody else wrote prepareJointVelocityMsg in the
right way. I had not noticed it before.

2013/11/7 EnricoMingo notifications@github.com

Why will not work?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/27#issuecomment-27954503
.

[EnricoMingo]

^^

[arocchi]

By implicit switch do you mean switching controller on the fly?
If that is the case, implementing it would mean adding one line of code at best and three lines of code at worst (two for the switch back from velocity control, in case we still use this current method to do velocity control, joint.SetVelocity(0,0); joint.SetMaxForce(0,0); -, one to the switch to position control - JointController::AddJoint(currentJoint)) and would save you from restarting the simulation every time you switch control, so from a purely practical point of view I don't get why you would want to postpone it!
Whether switching makes sense, though, is a completely different matter, of course :)

[lornat75]

Of course nobody wants to restart the simulator to change mode. The idea is that you call an explicit function to switch mode (in doing so you can reset PIDs, trajectory generators and all you need); the current iCub implementation implicitly switch modes when you send position/velocity/torque commands with a logic that is explained in the documentation page reported before. This is handy for the user, but a little confused to understand. Plus it may not be always possible, or forcing an overhead, depending on the hardware/simulation.

[arocchi]

Enrico, since #39 the torque readings should now correctly work also for the joint velocity control. Let's check this tomorrow afternoon together and at least part of the issue is solved (the BUG part)