Lift Sync: How to Improve My Program's Accuracy? EZC

I have written a program for syncronizing two sides of a lift.
Heres how it works right now:

-2 joystick buttons tell the lift to go up or down
-The value at which the motors run depends on the encoder values on the two sides relative to each other.
-It is based on speed not position.
-When one side is faster it slows down.
-There is a tolerance of 20 ticks.

The variables are:



The value of the motors that are to slow down is exagerated for visual purposes when I was testing.
Also the wait at the end of the while loop is also larger than it will be in the competition program because of the printscreen blocks.


You can also download the code from here:

I’m asking how can I make it more porportional?
Right now it is only if it’s off by this much it changes motor speed by a set amount.

I’d like to have it so that the motor speed is relative to the calculated error of the encoders.

P.S. Sorry the pictures came out tad bit too big.

This is a way of doing this, the correction coefficient of 0.25 will most likely need to be adjusted depending on how aggressive or passive you want the correction to be. You can also play with the tolerances of ticks in your if condition in the same fashion you were previously doing.

while (1)
    if (up == 1)
	float coeff = 0.25*(SensorValue[RightEncoder] - SensorValue[LeftEncoder]);
        int Correction = abs(coeff);

	if (coeff > 0)   //Left Side Lower
		motor[LeftMotor]  	  = 110+Correction;
		motor[RightMotor]  	  = 110-Correction;

	else if (coeff < 0)//Right Side Lower
		motor[LeftMotor]  	  = 110-Correction;
		motor[RightMotor]  	  = 110+Correction;
		motor[LeftMotor]  	  = 127;
		motor[RightMotor]  	  = 127;


The else if should be removed.
If you had a lower right it would be for example

        R  -   L

error = 50 - 100 = -50;

So the else if would make the left motor greater and the right motor less.

Just remove the else if and check for the absolute value of the error and it will work fine.

Okay I understand.
Thanks guys.

Hi sorry to bring up this thread but it’s very close to what I need for my lift. I’ve written a very similar code to Stanley’s above but as I am rather new to programning I wanted to know how you create the data in the else and else if statements. As I used to dragging in motor blocks, I’m not sure how to transfer your corrections into EasyC. So basically Im asking how do all of this in EasyC? Do I need to use UserCode blocks and write it as you have? Thanks for the help!

in the motor block, where you select -127, 0 or 127 you select the fourth option instead(uservalue) and make it 127-(encoder variable)

you can also use either the math or assignment block i forgot which one it is, to calculate new variables as a funtion of the encoder variable

I’ve attempted to make a P controller for my lift and started with what was above but cant seem to get it to work. I was wondering if any of you might be able to take a look at the code and spot any issues. To test the code out we built a small system which has chain run around a loop with one green link in it to see if they are able to stay equal. The button works and both motors run but the motors never correct themselves. By printing to screen we’ve seen that the encoders are reading correctly but the coefficient and the correction remain at zero. I believe this has to do with the syntax of the code but i need to make sure. Thanks for any help in advance.
Doc1.pdf (164 KB)
PLift.pdf (170 KB)

It may be in the size of the P versus how different the encoder values are.

Make sure both encoders are going up and down in the same direction. If one is going lower while the other is going up you will always be off.

Second obvious one is make sure both 393 motors are geared inside the same way. Can’t tell you how many times I’ve seen that one. Face palm ensues shortly after realizing this one.

OK, now assuming it’s all OK, let’s look at the code and how you adjust things. you can make it more proportional by adjusting that 0.25 value to increase or decrease the motor speeds.

Do you know how far off the values are in the encoders as you detect it being off? That will help bound your problem set. Print the difference off some place (robot C user so not sure how to do that in easy C).

The quad encoder goes 360 ticks per revolution (even though the product page docs still say 90). I don’t know the gearing you have but I will assume it is a 12 tooth on a linear track. If the one gear is off by 10 degrees should be 10 ticks which would only cause 2.5 in your float to adjust. That may be too small. But without knowing how far off your counts are I can’t really say.

If your encoder is measuring the big gear, you don’t have the precision as nice as you could.

Next, the differences in motor speed your are adjusting are at the upper/lower ranges of the motor control which don’t really change the motor speed that much.

Look at this older post to see how the power given is not necessarily linear to the speed of the motor. So just adjusting from 110 to 108 may not get you much difference in actual motor speed.

So playing with your constant of 0.25 may help get more dramatic results. Or you may be over-adjusting a bit already.

Knowing the limit of how far off from 127 helps too. You have a play of 17 in the code right now if you start at 110. 17*4 = 68 which means a 68 degree difference maxes out the one motor and a 440 degree difference (1.22 revolutions) on the downside before you hit 0 and start revving backwards for a while more. Is 68 degrees on a tiny 12 tooth gear too little? (hard to say without looking at actual differences)

Lastly, you did not mention the lift type but I will assume a scissor lift. Small variations down below on the lift lead to wild differences up top. Sometimes, the lift points are exactly the same and you still can get a leaning scissor. So it may not be code correctable as there are friction points somewhere in the scissor making it not lift the same left/right.

Physical left right metal and a sync shaft between motors helps there and can eliminate the need for software based control all together since it is so rigid.

To Team80 Giraffes

Thanks for the tips. I’ve checked the things you mentioned above. The encoders are going the same way and the motors are geared internally for torque. The value of which the encoders will be off is going to be different on my scissor lift than on this system so I want to see that the code is working before putting it on the lift. (I don’t wanna break something) I am running the rack and pinion system on the bottom of my lift, but the encoder is attached at a higher point, one that gets around 1000 or so ticks on the encoder from the lowest point to highest.
I have checked my scissor lift after you mentioned there might be mechanical errors and after a few tests I’ve noticed that one side, the gearbox moves a bit faster than the other and is the cause of the leaning scissor. I’ve ran it up and down a few times to see if it’s possible for the lift to lean when the gearbox is even and it seems like if the gearbox is straight so will be the top; atleast according to my tests. I have numerous braces across the lift on each stage but none connecting the bottom as it travels so far horizontally that it would hit many things on the trip. Like I said, I think if I was able to keep the gearbox going together I would have a straight lift. I’ve tried to implement the changes in the code but still get the same result. I will continue to attempt to mess with it but it seems like a hopeless endeavor as I am a novice programmer and mainly focus on building rather than programming. I’ve recently learned though, that building can only get you so far and sometimes must implement programming for things to work correctly. Thanks for the help, I really appreciate it! :slight_smile:

Nice thanks stanley you answered my burning question and got me where i needed to be!