Design PD controller with Bullet

User avatar
Dr.Shepherd
Posts: 168
Joined: Tue Jan 04, 2011 11:47 pm

Design PD controller with Bullet

Post by Dr.Shepherd »

Could anyone help this problem?

PD controller is used in robotics to track a reference trajectory, and it is defined as

Code: Select all

torque = kp*(q_d - q) + kd*v
q_d is the desired position, q is current position, v is the velocity. kp and kd are parameters.

My problem is from my experiences, the "set" desired position is always not the same as the actual position the robot arms goes to. Is this correct? Anyone has experience in this?
Basroil
Posts: 463
Joined: Fri Nov 30, 2012 4:50 am

Re: Design PD controller with Bullet

Post by Basroil »

What method are you using to join two bodies together? I've had some success (at high frequency) using the joint constraints with the characteristics of an AX-12 servomotor using the built in speed based controller in joint space. That one takes into account desired velocity and maximum torque, so it's a bit difficult to use with a straight up torque controller but not too difficult to estimate given velocity characteristics of the motor (i.e. just set it to run at maximum speed all the time and let the joint characteristics slow it down). So many ways to set up the problem that it's difficult to know what the cause is for a deviation, and could be as simple as a transformation that never got calculated.
Ateocinico
Posts: 12
Joined: Sat Jun 29, 2013 5:55 pm

Re: Design PD controller with Bullet

Post by Ateocinico »

There is no PD control. There are P, PI and PID controls. And the control must make the controlled system reach the desired position, within an error.
Basroil
Posts: 463
Joined: Fri Nov 30, 2012 4:50 am

Re: Design PD controller with Bullet

Post by Basroil »

Ateocinico wrote:There is no PD control. There are P, PI and PID controls. And the control must make the controlled system reach the desired position, within an error.
There's plenty of PD controllers you can implement in real world applications; they're often used for vehicle suspension systems and other disturbance rejection/ energy dissipation cases. Hell, wait till you see fuzzy PD+PI controllers and you start loosing track of what type of controller the system thinks it's using. Controllers have many different functions, not just achieve x position within t time and e error, but in the case of robots there's generally some integration going on and position response is usually going to take priority. Hopefully Dr.Shepherd can get back to us with what it is that he's trying to do and how he went about doing it.
Ateocinico
Posts: 12
Joined: Sat Jun 29, 2013 5:55 pm

Re: Design PD controller with Bullet

Post by Ateocinico »

PD + PI = PID
A pure PD as Dr.Shepherd describes only amplifies noise and produces overshot.
And OF COURSE there is more than position control. There is speed, direction, temperature, PH control, etc.
Benjamin Kuo or Katsuhiro Ogata anyone?
Basroil
Posts: 463
Joined: Fri Nov 30, 2012 4:50 am

Re: Design PD controller with Bullet

Post by Basroil »

Ateocinico wrote:PD + PI = PID
A pure PD as Dr.Shepherd describes only amplifies noise and produces overshot.
1) Fuzzy PD and PI controller is not the same as PD+PI, at least not for most situations. But that's a topic for another discussion, and just was used for a joke (though seems it wasn't as funny as I thought :wink: )

2) The Kd of a PD/PID controller reduces overshoot by nature, unless you put a negative coefficient (which unless you like making bombs isn't a good idea), Kp (the P in PD and PID) is what increases overshoot (Ki also does to a slightly lower degree). PD controllers are generally good at following trajectories, but don't always stop where you need them to and might have an offset throughout.

3) In the case of bullet, noise will be negligible unless you add it yourself, so he shouldn't have too much issue with it. Filtering techniques are available to deal with noise too, though they do tend to make it less effective than theory (but far more effective in real life).

4) If, now that I'm reading the initial post a third time, he meant that a moving arm doesn't end up where he wants it to at the end of a trajectory (rather than during it as his setup implied), it is entirely due to it being a PD rather than PID, as the PD controller will have some steady state offset in the case of external forces (gravity) and "low" Kp values (depends on how close is close enough, if absolutely zero error is needed Kp goes to infinity). If the steady state position is what he cares about, he just needs to add a small Ki value to let the controller compensate for the external forces dragging the arm down.