Proportional Forward Movements

[ns0407]

Hello,
I am trying to code a proportional movement function for moving forwards during auton. What I have so far is this:

void porportionatedriveforward () 
	{
		while (!(chassisactualpos > chassistargetpos - 3 && chassisactualpos < chassistargetpos + 3)) 
		{
		chassisactualpos = leftsidemotorB.get_position(); 
        chassiserror = chassistargetpos - chassisactualpos;
        chassisspeeed = .5*abs(chassiserror); //positive = forward
        leftside.move(chassisspeeed); 
        rightside.move(chassisspeeed);
		pros::lcd::print(0, "Position:%d", chassisactualpos);
        pros::lcd::print(1, "Target Pos:%d", chassistargetpos);
        pros::lcd::print(2, "turnerror:%d", chassiserror);
		pros::delay(50); 
		}
		pros::delay(250); 

	}

I used the same logic, but for turning with inertial sensor rotation values, and it worked fine. But now, the chassis just drives full speed ahead without stopping. I presume that its not attaining the position of the motor properly, as it wouldn’t display anything for the motor position on the brain, but I am not sure. Any help is appreciated. Thank you!

[6210K]

There are multiple things I see here. First, I assume your target position is being defined either as a parameter for this function or elsewhere in your code. Secondly, depending on your position units (revolutions, feet, motor degrees, etc.) you have to determine if ± 3 is a good area of error. Thirdly, If your robot does pass the target, you have set your chassisspeed variable to the absolute value of your error. If you have passed your target, you will continue to go forward with increasing velocity the further you get away from your target. I would recommend changing your chassisspeed to simply your proportional value times the error. Also, a 50 msec delay is probably too much, and you could probably get away with half of that or even less, and that could actually be the root cause of all of this. Additional piece of advice, my team actually takes a filtered average of all motor positions and use that as the target position to ensure we can still perform if an encoder returns a weird value. All it does is finds the outliers in the data with the interquartile range and removes them, then averages all positions. Hope this is both accurate helpful.

[Mavric]

As 6210K mentioned, since you are using the encoder position of the motor ± 3 is probably not enough. I believe encoder units are ~600 per revolution for blue ~1200 for green and ~2100 for red. Can’t remember the exact numbers but it is around that.

This means the robot will only start slowing down ~0.5 degrees before it reaches its target with blue motors and ~0.25 degrees before it reaches its target with green motors. This is absolutely tiny.

When you think about it even 3 degrees would be tiny.

The average Vex wheel circumference is probably ~5 inches so the drivetrain would be slowing ~5 / 120 (360 / 3) inches before the target. Or 1 / ~24th of an inch.

If you were using a green motor it would slow ~5 / ~1440 (360 / ~0.25) or 1 / ~288th of an inch.

This means the drivetrain never gets a chance to slow down and blasts past the target. As mentioned above the abs() error means it then starts to accelerate.

Hope this helps.