Society of Robots - Robot Forum
Software => Software => Topic started by: Robot Attack on July 06, 2011, 12:54:33 PM
-
Hi All,
First time posting here :)
I am working on a project with a miniature (~8" long) 3 DOF robot arm. The arm is controlled by a user from a device which outputs a point in space (X, Y, Z). The joint angle for each axis is derived using reverse kinematic relationships.
Each axis is powered by a Micro Metal Gearmotor with a 298:1 reduction (http://www.pololu.com/catalog/product/2218 (http://www.pololu.com/catalog/product/2218)). Additionally, each axis has two forms of feedback, an optical encoder on the back of the motor which gives relative position and a magnetic encoder on the output shaft which gives the absolute position of the axis. There is quite a bit of backlash in the gearbox (approx 10 deg) so these two values do not necessarily agree.
We are using a standard PID controller. We have been switching between controlling it with the relative position sensor as well as the absolute sensor. We have not observed much of a difference in behavior between the two.
The first degree of freedom is a "shoulder" joint which rotates the arm up and down (Imagine holding your arm straight out and raising and lowering it)
On the way up, the motor must fight gravity. On the way down, it is gravity assisted. When powered off, the weight of the arm easily back drives the motor and it drops.
The problem I am struggling with is getting the arm to smoothly lower itself. It raises fairly well, but when I command a downward movement it moves in large jerks instead of small controlled increments. I suspect that the motor is somewhat underpowered for the job and that when moving downwards gravity is outweighing my PID control. I have tried experimenting with the gains but have not had success in mitigating this problem.
To tune the joint I set I and D to zero then raised P until the system became unstable. Then I backed off P by about 30% and increased D until it was unstable, backing off again. The system becomes unstable quickly with the addition of I so it is kept to 0 or very low.
Any help with this would be very appreciated. I am fairly new to controls and feel somewhat over my head.
Unfortunately due to the proprietary nature of this project, I can not post pictures or videos. I can supply more information if it would be helpful.
Thanks!
-
One guess I have about the jerky downward motion is gear backlash.
When the arm is stationary the motor is holding the arm in position. This has all of the gear meshed in one direction. When you go to lower the arm the gears un-mesh until either gravity pulls the arm down re-meshing the gears or the motor turns enough to re-mesh the gears. Very likely gravity is not keeping the gears meshed until the motor turn enough, then gravity pulls the arm down until the gears mesh again.
You'll need to do some experiments to determine if this is the cause.
-
Waltr, I agree that the backlash is playing a large role in this motion.
Is there any way to smooth it out with clever controls, or is there no way to control a system like this with a lot of backlash?
I think that what I would want is a way to lower the power to the motor until gravity begins to pull the arm down. However, I am not really sure how to implement that. Sounds more complex than a standard PID style control loop.
-
How stiff are the pivot bearings? These may cause the arm not to keep the gears meshed.
You may need to tune the PID with different parameters for each direction since moving the arm up has a different response than moving down.
-
Howdy,
If I'm going to guess, you're doing this:
Arm is at the top. so you send it a command that says "now go down to the ground". So it's a HUGE step, and the error is gigantic at the beginning. Is that about right?
If that's the case, then yes, you can be clever with your controls. Don't use an I gain -- the integral gain is only used if you have steady state error, and you don't seem to. All you need to do is design a simple trajectory, usually a line will be sufficient, that gets you from point A to point B in many smaller steps instead of one massive one. The arm will naturally move slower, since the errors will be smaller, and it SHOULD be able to better fight gravity.
For some context here, I'm working with a robot hand, which is effectively 3 separate 3DOF manipulators. I had to use this trajectory trick since I had crazy backlash in my (plastic!) gears. It now works like a charm, and my controller doesn't even overshoot! An easy way to do this is to make the trajectory go from 0 to 1, and put it into a function. Then just scale it as you want when you're actually using it.
MIKE
-
Hey Mike, thanks for the reply.
The arm we are working on has to follow a user input. For tuning purposes we are using a ramp input, not a large step input as you guessed.
Funny thing is, it actually works a lot smoother and nicer when we do give it a large step (although it tends to overshoot in the "down" direction).
The response we see when the arm is given a ramp input (not unlike the trajectory you mention) is very jerky. To kind of describe what I think is happening:
- The motor is pulling X current to hold the arm out in a set position
- The input is sent and the error begins to increase
- At some point the error is large enough that the motor "releases" and the arm drops down
- The arm overshoots its target and stops with a sudden jerk as the motor is powered in the opposing direction
- Repeat
-----
@ Waltr
The housings of the joint are made of 2 plastic shells clamped together. They are not as stiff as we would like and probably allow the center to center distance of the gears increase when loaded. This definitely makes the backlash grow
Thanks again for the input guys
-
Hm...can you show me the code you use to generate the input? I figure that if I help with the software and Waltr helps with the hardware we can probably get it going haha.
Try these two things:
a) tune the P gain down a bit (say by 15%)
b) although I know it's a user input, try to make it a steeper ramp, or decrease the delay between two successive inputs of it (Um...I assume you do this: ramp = ramp + dx, delay(someTime), repeat, right?)
I had the same behaviour happening with my trajectories, and it turned out that it was more of a software problem than a hardware problem -- however, I would still REALLY love to get my hands on better motors, gearboxes, encoders... :-P
MIKE