Labview velocity PID

[mhsrobotics3616]

hey
so our team has an arm design that is pretty heavy. it goes up fine but once it gets past its center of gravity it very quickly falls because theres no longer that weight to pull upward instead its going downward. today i decided i would try to figure out PID... do you think that would work for that situation?

to try it out it would need be based on power not position. one thing ive been trying to figure out is how can i convert the encoder value of the tetrix motors to equate to a power. because wouldnt i set the setpoint as the power from the controller.

so yeah any help is very helpfull.... we have a week to get this done lol were in crunch time...

thanks
FTC3616

[MotorHead]

PID is a great way to go for maintaining position. The trick is just getting the tuning parameters correct. I don't think it is necessary to control power. Controlling position is what you need. What you describe with the arm moving is a common problem. Start tuning the PID controller by just setting proportional control. For many systems, this is enough to get the system to be stable and respond to changes in inputs. What you will notice though, the weight of the arm will cause a persistent error. To make this go away, use a little bit of integral control. This term has the effect of adding up error over time and the controller will respond to eliminate the steady state error.

With some patience, I think you will like the results.

[Ether]

Originally Posted by mhsrobotics3616

to try it out it would need be based on power not position. one thing ive been trying to figure out is how can i convert the encoder value of the tetrix motors to equate to a power. because wouldnt i set the setpoint as the power from the controller.

No. If you want to go to a position and hold there, then your setpoint is a position command. The PID takes care of adjusting the voltage sent to the motor to move the arm to, and hold it at, that position.

If it is possible to add a torsion spring, or a counterweight, or even some cleverly positioned surgical tubing which will reduce the "weight" of the arm on both sides of the "center of gravity", that might help too.

[mhsrobotics3616]

thanks for the replies. the problem is that we dont want it just hold a position we want to be able to have control with a joystick thats why i thought it be based on power output versus encoder count. i know that for holding a position i can just use the output degree of the encoder as the setpoint.

i like the surgical tubing idea is a good idea it would slow down the force of the gravity on it it would just create the opposite problem coming back up but i think that it would be better having that continuous gradual force rather than the instantaneous force of the shift of gravity..... i actually really like that idea what do you guys think? i could use it for our first segment of the arm... we have 3 segments the first one stays down till we have a crate pickup with the 2nd segment then the 1st goes 90 degrees up and just stops and it would have an easier time going up with an upward force to help it out

[Ether]

Originally Posted by mhsrobotics3616

thanks for the replies. the problem is that we dont want it just hold a position we want to be able to have control with a joystick thats why i thought it be based on power output versus encoder count. i know that for holding a position i can just use the output degree of the encoder as the setpoint.

You can use the output of the joystick as the setpoint, and the encoder signal as your process variable (feedback).

setpoint and processVariable are inputs to a PID, and the PID takes care of adjusting motor voltage to go to and hold the commanded setpoint.

[mhsrobotics3616]

Originally Posted by Ether

You can use the output of the joystick as the setpoint, and the encoder signal as your process variable (feedback).

that's what confuses me. because joystick output would give me a setpoint between +- 100, how does the encoder correspond to that. because if i gave it encoder value as the feedback wouldn't that make it think that the motors power was what ever the encoder value was which could be 0-infinity.

[Alan Anderson]

Originally Posted by mhsrobotics3616

that's what confuses me. because joystick output would give me a setpoint between +- 100, how does the encoder correspond to that.

You would just need to scale the joystick and the encoder so that they both map to the same range, and would have the same value when the arm was at the commanded position. If it's an arm with a limited range of motion, you might want to use something that provides an absolute measure of the arm angle such as a potentiometer or magnetic sensor, instead of a relative-position measurement such as a quadrature encoder.

[Mark McLeod]

Here's an example of mapping a joystick to the range of a potentiometer.
This would force an arm to a particular setting of the potentiometer.

In this case we have a pot with a minimum value of 1.17v when the arm joint is in the lowest position.
The pot has a maximum value of 3.9v when the arm is in the highest position. (You never want to run your pot right up to it's physical limits, otherwise it can get broken very easily)
The joystick full range gets mapped to the pot's full range in the left box. In other words the joystick value gets converted into pot terms.

The right box applies the PID based on the joystick position (now in desired pot terms), and compares it to the current actual pot value, to produce a motor output that will force the arm in the direction it must go in order to make the actual pot value line up with the desired pot value.