ros-controls / ros_controllers

Generic robotic controllers to accompany ros_control
http://wiki.ros.org/ros_control
BSD 3-Clause "New" or "Revised" License
557 stars 527 forks source link

what is an "x controller" #166

Closed goretkin closed 9 years ago

goretkin commented 9 years ago

I think the naming of "x" and "controller" is confusing.

joint_state_controller/src/joint_state_controller.cpp doesn't do any control. I get that it runs in the control loop, but it's not a controller by standard definition. The name is probably here to stay because "Controller Manager" is not going to be renamed either, but it should be explained.

Then there is this structure x_controllers/src/joint_y_controller.cpp where, for example, x=velocity, y=position. What this actually means is that "you are controlling y by controlling x", which is two different meanings of control. You are at liberty to set the x (velocity) and you will regulate y (position). (in another thread I see the word "interface", so in this case you have a velocity interface) Am I correct in this?

I am also wondering, for general applications (where you have non-negligible inertia) you should only be using effort controllers (things that are at liberty to set the effort), right? Otherwise you can't actually set the velocity, the velocity is regulated, and you have a major-minor control loop structure and you have to care about the gains of the minor loop. I suppose you could have nearly unbounded force control and make a joint appear as if its velocity controlled.

Also if you actually have velocity control, then you really only need the P term of a velocity-controlled position regulator. You'll never overshoot, since it's a first-order linear system. And you'll also not have steady state error.

goretkin commented 9 years ago

Perhaps I might help myself by thinking of two examples. Please correct any misunderstanding of mine.

The PR2 has nearly direct-drive motors for many of its joints, and the motors are current-controlled. Joint "effort" is proportional to motor current (perhaps with scaling and some corrections for the counterbalances, though I'm not sure about this). In the PR2 what you are controlling is (roughly) the torque of the joints. For this you use an effort-interface position controller. (set the effort in order to regulate position). This is probably the ideal case in terms of versatility of the actuator in doing position control or force control. In terms of modeling, you probably assume you can set joint effort instantaneously.

Baxter has substantial gear reduction between the joints and motors. The motor eventually reaches back-emf equilibrium, and the velocity at the output of the gearbox is proportional to the voltage. In terms of modeling, do you assume you can set velocity instantaneously? You don't quite have effort control, but it's not quite velocity control either.

For the PR2, the transfer function between joint velocity and the quantity you can set (effort) is probably close 1/s, and in the Baxter, the transfer function is more like (1/(s+1)), does that sound right?

adolfo-rt commented 9 years ago

A mailing list is more appropriate for Q&A, while the issue tracker is for discussing implementation-specific details. Could you please ask these questions on the robot control SIG?. I can post answers there. Also, group questions by topic (one thread, one topic), so others can easily find existing records in the future.

See you on the SIG.

goretkin commented 9 years ago

Thank you for directing me to a mailing list. I had missed it. I will clarify some points as ask on the mailing list. Do you welcome documentation issues here? This is initially the issue I intended to bring up, but it (d)evolved into something more.