Scissor lift potentiometer problem

VEX V5 Technical Support UNOFFICIAL Tech Support
#1

Hello!
I am representing Piratech Robotics team 508V. Our scissor lift bends when it’s on the higher stages so to correct the problem we’ve attached potentiometers on the sides. However, the code is not working as expected, with one side of the lift randomly going down. The potentiometers are facing the same direction.
We are a new team and all but one of us are first-years.

Here is the code we have for our user control task that pertains to the potentiometers:

#include "Main.h"
void OperatorControl ( unsigned long ulTime )
{
unsigned char offsetL = 0;
unsigned char offsetR = 0;
offsetL = 0;
offsetR = 0;
while ( 1 )
{
pot67 = GetAnalogInput ( 2 ) ; // potentiometer controlling motors 6 and 7
pot89 = GetAnalogInput ( 1 ) ; // potentiometer controlling motors 8 and 9
joyLift = GetJoystickAnalog( 2 , 3 ) ; // grab analog input from partner controller
if ( pot67 < pot89 )
{
offsetR = pot89 - pot67; // This is supposed to make the right side of the lift slow down when it controls the motors.
}
if ( pot89 < pot67 )
{
offsetL = pot67 - pot89; // Ditto, but on the left.
}

SetMotor(6, joyLift - offsetL); SetMotor(7, joyLift - offsetL); SetMotor(8, -joyLift + offsetR); SetMotor(9, -joyLift + offsetR);
}
}

Thanks for the help in advance :slight_smile:

#2

Without looking to closely at this, the Pots could be inverted (i.e. one is counting down from 4095 and the other up from 0) even if they are “facing the same way” because/if they are mirrored. I would use an Lcd or the debug stream to check the potentiometer readings.

Also, it seems like it would be a good idea to have an else that sets each offset back to 0 if side is not greater than the other.

#3

In my somewhat-sloppy attempt to remove everything that doesn’t have to do with the potentiometers I removed the else statements I had that did just that- sorry about that. It didn’t seem to help.

I’ll check the potentiometers tonight when we have access to the robot.

#4

Before you get too far, do a little experiment to ensure the pots read the same relative values as you lift the scissor. I have a feeling one may be off a bit in its variable resistance so let’s try to make some software to account for that. But you can adjust for cheap variable resistors not playing nice.

You should measure the pot value in robot C using the debugger windows. Either measure the scissor angle, or the height of the scissor at various points. The height is probably easier, but make sure it is what the robot would push it to, not pulling it by hand from the top because it’s not how your robot will act on its own.

Make sure the left/right sides look relatively similar in their expansion. If you just trust the pot’s are the same left to right all the way up, you may be trying to adjust to what is not reality for your scissor.

Are the start values different? Are the values in between or the end values different? These establish the “good” sets of values your program will try and adhere to. Deviation from left or right from the measured height is what we’ll adjust to. You may want to measure a few times at various heights to make sure it’s still the same. Ensure the pot is really locked down and won’t move. (saw that one in gateway on a scissor and wondered why the preset heights weren’t so “preset” so it migrated up. Tightening some screws helped a lot. It was not the pot going bad, it was it slipped a bit.)

Input these values to a spreadsheet and plot these values in Excel. (or open office if you don’t have Excel) In a perfect world, the lines will be the straight and on top of each other with the same values all the way up. If this is the case, then stop here and program left to equal right as the error to compensate against. If not, then you have some work to do to determine how far off left and right is. Your code assumes left and right follow the same values all the way up and down.

If the lines are different, you want to make a formula of what left side and right side think they should be at various heights. You can also adjust/swap the pots until you get something nice, linear, and the same left/right.

Use Excel’s linear regression functions to get the formula of each line. You could do it by hand if you are a glutton for punishment. (Tip: The scatter plot in excel gives you the right linear regression, not the line plot. Make sure you back test the function to see the error from measured to see if the function is good enough)

If your line is not straight, choose different interpolation types to see what fits best to the data. Now you have two functions you can use to say you’re at different heights from the two pots.

You can figure out the height based upon the left pot and the right pot based upon this handy function Excel gave you. Now you have an error to work with for your motors.

If you are going up, the lesser height should get that side motor moving more or get the other side to move less. If you’re going down, slow down the speedier motor to let the other catch up.

How you do that can be a trick. A PD algorithm would work well I think or a simple trim to throttle back on the too fast side by no more than 5% each go around.

That’s another discussion but the scale of a pot is 4096 while a motor’s full range is 256. You are using an error that can be way over the motor’s allowed range. you will want to put some factor against the error to not have wild gyrations of the motor. OK, the limited range of motion of the pot on the scissor will be less due to not going 270 degrees but you get what I mean, 4096 is way bigger than +127. Don’t send a really big number to the motor for what should be a fine adjustment.

Wait 20ms and loop again to see the new error and adjust the motors again. In your code, you are constantly looping around and anything less than 20ms is not going to affect the motor so you might as well wait.

If you plan to do this, you need to re-validate it over time as the pot may slip to give new start and end values. Once you figure it out, it takes 10 minutes to re-plot the data and get a new function.

Team 80M used this measurement based technique in Sack Attack to keep their arm along the floor at a set angle or in a carrying position. Two pots measured the main arm and the scoop position to get the ideal values in the state of carry vs floor. Buttons controlled the desired state and position and made it a one person driven robot.

Oh yeah, and once again, math (and engineering) rules! :cool:

1 Like
#5

As VEXMEN has already made such a wonderful post about tuning lift potentiometer and using the values, I’ll just share a bit about the method I used when our scissor is not structurally balanced. Now we got rid of all the balance program because we reinforced the structure and elastic assist. Remember that structure is always the best solution to lift wobbling.

The code I wrote looks something like this:



// psudo code don't copy :D

task usercontrol ()
{
int liftcurrentvalue;

if (up button pressed)
{
raise lift at full value + overdirve protection code;
liftcurrentvalue = average sensor value of the lift;
}
else if (down button pressed)
{
lower lift at certain speed + overdrive protection code;
liftcurrentvalue = average sensor value of the lift;
}
else
{
PID lift adjustment
Left side and right side try to reach the average value separately
error for left side is liftcurrentvalue - left sensor value
error for right side is liftcurrentvalue - right sensor value
}
// sensor value difference offset not included. 
}

So basically I know that the majority of time, my lift is not moving. The total amount of time I activate my lift is not long. Considering the power output, I always want the most power when the lift is raising. The only time I really need the lift to balance is when it stops at a certain raised position.

So the code goes like this. Driver control is regular without PID, but average value of the lift on both sides is calculated only when lift is activated detected by whether buttons are pressed or not. This value is given to variable liftcurrentvalue. When the lift stops, the calculation of liftcurrentvalue stops, the variable stays fixed, and the PID block activates. The lift tries to balance itself and resist falling down at the same time.

This worked okay for us, and I remember Pastoral Invasion documented similar process for balance and hold lift in their sack attack notebook. Something to consider. For starters, Pastoral Invasion wrote that their P = 0.5, D = 0.5, I = 0.01. We did some tweaking based on that value for PID and it was fine. So you might start there if you wish to use PID for lift holding.

#6

Thanks for the help, but we’ve done reinforcements to the lift and it now operates perfectly straight. We’ll check this thread if we have problems in the future.
Thanks again!

#7