Some 269 motor testing stuff

So although I have mainly been done with VRC, in my remaining few days in the lab I still feel like doing a little programming project. To pay homage to Jpearman I did something very similar to his testings. Very simple mechanical structure, one 269 motor 12 tooth gear, big red encoder attached, driving an 84 tooth gear with an arrow indicating orientation. Three bumpers, one LCD, one potentiometer, and some interesting programming.

So far I have done some things I wanted to do, such as using one potentiometer and a bumper switch to directly tweak constants, simple PID target control that is easily manageable, again, homage to Jpearman.

And today I was working on automatically printing rerun program. I met Ruiqi at worlds and forgot to ask him about the rerun program, but I guess it would be testing with PID velocity and recording the joystick values only, and then plugging those values back into the loop.

So the first thing with PID velocity is to map out current vs. rpm, and this is all I got today… This has been done by jpearman before nicely, but I figure I would post my mapping here just for fun!

Information: one 269 motor plugged into a 2 wire port, one quad encoder updating velocity every 100 ms interval, acceleration wait time is 1 sec for each update.

https://vexforum.com/attachment.php?attachmentid=9305&stc=1&d=1431013575

Again, this has been done before, and this perhaps is just to again remind VRC community that…

[LIST]
motor value vs. rpm is** not linear**.
From my few trials the motor is practically motionless from power of 0 to 16.
In my case, the greatest velocity easily exceeded 100 rpm, orienting around 113 rpm max.
[/LIST]

I will work on this and if I do get my rerun to work, I’ll make a thorough tutorial about it. Special thanks to Jpearman and Cody who taught me about csv and making graphs with Excel. Thanks for you awesome people now I can do a little programming too!

Martin Ma, Peace
pid test.c (7.91 KB)
1st testing.txt (950 Bytes)

Nicely done.
Would you be able to measure motor value vs voltage across the motor windings along with rpm? I am interested to see what it looks like.

This I will need further learning. I guess, only guessing, that motor values are voltage output at the ports. Motor current changes as the motor takes loads. Someone correct me of I am wrong!

The motor voltage is a complex waveform. If the motor were a simple resistor the waveform would be a varying duty cycle square wave. Due to the motor back-emf and other factors it becomes quite complex, it was a long time ago that I was investigating all these things, here is one old post that shows some examples.
estimating motor current post #15

That’s exactly what I was looking for. Thanks a ton!

Updates:

Today I finally correctly set up the PID velocity control. Gotta say honestly that I have never read about or done anything related to PID velocity; I just know that PID velocity is I-P oriented and that it is done similarly as PID target.

So the way I do it is that I calculate velocity with 10 hz precision, which is a very very slow update rate, and the updating is almost perceptible. But this is the best resolution one can possibly get with a 360 ticks per revolution big red encoder directly attached to a high torque 269 motor.

Not sure if this is the normal way to go, but I figure as this is joystick control integrated PID velocity, I would need to make the joystick value the velocity target, scaling down from 127 to 100 rpm, and then use an algorithm to approximate the “seemingly right” motor value, and then use PID velocity to tweak around it. Which means, from the testing data, we need to find an algorithm that converts target velocity to approximated motor value, which is the inverse scatter plot regression of the previous image:

https://vexforum.com/attachment.php?attachmentid=9310&stc=1&d=1431111182

So, not knowing how to do quadratic regression, actually I should have used an exponential regression, which I will try later, I picked three pairs of values that look about right to calculate a quadratic curve that somehow approximates the scatterplot:


expected = (1/200)*target*target+(7/100)*target+14;

And I think I do need a deadband of joystick in the future, but now the calculating algorithm looks like this:


float PIDVelocityBaseValue (float target)
{
	float expected;
	if (target == 0)
	{
		expected = 0;
	}
	else if (target > 0 && target <= 113)
	{
		expected = (1/200)*target*target+(7/100)*target+14;
	}
	else if (target < 0 && target >= -113)
	{
		expected = -((1/200)*target*target+(7/100)*target+14);
	}
	else if (target > 113)
	{
		expected = 127;
	}
	else if (target < -113)
	{
		expected = -127;
	}
	return expected;
}

And with this rpm target to approximation value with a crappy quadratic regression, I did make the PID loop run:


float VelocityPIDOutput;
int Vtarget;

task PIDvelocity ()
{
	float Kp = 4;
	float Ki = 2;

	int lastPosition;
	int error;

	float proportion;
	float integral;

	while (true)
	{
		velocity = lastPosition - nMotorEncoder[m];
		lastPosition = nMotorEncoder[m];

		error = Vtarget - (velocity)/6;

		proportion = Kp*error;

		integral = error + integral;

		if (Vtarget == 0)
		{
			integral = 0;
		}
		VelocityPIDOutput = proportion+Ki*integral+PIDVelocityBaseValue(Vtarget);

		wait1Msec(100);
	}
}

So it does feel different and smooth with PID velocity integrated joystick control. You can see that I had neither time or idea about how to tune the two constants, so the set of data I printed out barely at the end of class looks pretty bad. Some significant overshoot is observed.

So, I will keep working on this project and adding stuff to it. After I get the tuning nailed I will start writing debug stream automatically printing rerun code program.

I figure VRC community needs some more PID velocity knowledge. Skyrise taught us lifts, needle intakes and PID target well. NBN is a game of crazy transmission, pushing, tracking program and flywheel struggle with precision, so I thought I should do some simple, basic starter stuff with PID velocity (so simple that it involves basically no case statements and my personal first ever function with parameter) and get us more involved and be like, oh, I understand what NBN world champions did with their flywheels, in the future.

Please criticize and offer improvement ideas to my programming! Full program up to this point attached below. Apologize for 0 comments; just trying to save time.

Peace, Martin
testing inverse.JPG
pid test.c (8.77 KB)