Why Velocity Graph Going Haywire

VEX V5 General Discussion Technical Discussion
1

We recently have been graphing our flywheel velocity so that we can continue to optimize our code for inconsistencies. What we have found has been quite a shock to us. Look at the attachment and let me know what you think. In this test, all we did was set the motors to 127 for a few seconds, but the numbers jump dramatically. We are wondering if there is something wrong with the software/ computer or our encoder and program. We check speed every 20ms and the encoder is running at 500 - 800rpm.
Sorry, its a word document.

[attachment:5699a80cbde0f]

2

I have noticed that the encoder values are nowhere near consistent as well. While (AFAIK) the value on ours doesn’t fall to 0, it does jump around enough to mess with the control loop. To fix the problem I wrote some averaging code that averages the last three RPMs (updated at a 50 millisecond interval):


task launcherSpeedAverage()
{
	int RPMA1 = 0;
	int RPMA2 = 0;
	int RPMA3 = 0;
	while(true)
	{
		for(int i = 0; i < 3; i++)
		{
			RPMA3 = RPMA2;
			RPMA2 = RPMA1;
			RPMA1 = launcherRPM;
			delay(50);
		}

		RPMAverage = ((RPMA1 + RPMA2 + RPMA3) / 3);
	}
}

While this does increase latency, I feel like it is a fair trade because the flywheel seems to be able to reach and stay at it’s target.

3

Ha,

This code is going to give me cancer?! Oh wait, I found it.

:smiley: :slight_smile:

Cool idea, but I feel like that would curve your data. We are going to do more testing. I had no idea our data was fluctuating so much until this test.

4

Are you using EasyC or ROBOTC? If ROBOTC then send me the code so I can see how you are doing the calculations. If EasyC then see this thread
https://vexforum.com/t/ime-update-rates/29441/1

5

We are using RobotC
Here is that section of code we used to get the results above.


        flyPower = 127;
	SensorValue[launchEncoder] = 0;
	launchPower(powerLimit(flyPower));
	datalogDataGroupStart();
	wait1Msec(20);
	speed = SensorValue[launchEncoder];
	datalogAddValue(0, speed);
	datalogAddValue(1, flyPower);
	datalogDataGroupEnd();

I am sure that earlier this season that just watching our values, they where very fluid, but it seems now they jump around a lot more. We are thinking it might be our encoder because it has to run so fast and might be warn. Can amount of code between each speed check make the actual time between checks deviate?

6

The first thing to try is moving that call to datalogDataGroupStart to after the calculation of speed. datalogDataGroupStart sets a time stamp for the values you are going to write into the datalog, but you wait 20mS before calculating speed, so the timestamp and calculated value are not coincident. Modify the code to be like this, it may not matter but something to try.

    flyPower = 127;
    SensorValue[launchEncoder] = 0;
    launchPower(powerLimit(flyPower));
    wait1Msec(20);
    speed = SensorValue[launchEncoder];

    datalogDataGroupStart();
    datalogAddValue(0, speed);
    datalogAddValue(1, flyPower);
    datalogDataGroupEnd();

The thing I really wanted to see was how you were using the multi-tasking capability of ROBOTC and how many IMEs (I was assuming you had IMEs, perhaps that’s wrong and you have a quad encoder) you had. Is the above code running in your usercontrol task or in another one its own?

7

That graph in the *.doc doesn’t really look that random to me - there is some sort of the pattern at the end.

Can you open up the encoder and check if there are any plastic shavings in there?

Also, try replacing encoder with another one and/or run it at the slower speed. You should be able to easily do 10:48 with a small chain. You really don’t need that much ticks if you are going to be averaging over larger interval. Time round-off will be your major source of the error.

Finally, instead of resetting encoder to zero, try to datalog its absolute values and nPgmTime. If there is anything funny going on with multitasking it will be easier to detect.

8

We are using a quad encoder that normally runs at over 600rpm geared directly from the flywheel axle.
We are not sure exactly what you mean by multi tasking capabilities of Robotc. The code is running in user control in a function. We will try the code switch.

We are also going to try graphing an IME and a quad running at the same time on the same graph.

9

As @technik3k suggests, open up the encoder and blow out any accumulated debris.

ROBOTC allows the illusion of code running in parallel by the use of different tasks, however, if used incorrectly the delays you add into the code (ie. the wait1Msec calls) can become inaccurate, one task may not allow another to run at the expected time. If you are running everything in a single task (the usercontrol task) then don’t worry about it, it’s not relavant.

10

I’ve attached our data with the IME which is giving a lot more level responses.
pink - IME
blue - Quad

We will try cleaning the quad and will replace it when our new order comes in. Thank you all for the help.

11

Do you know if PROS has the same issue? That could be wh we got jittery readings.

12

It looks like most of our jitteriness was coming from the sensor reading rather than the code or software. I am still wondering though if slowing the encoder down a little would reduce the chance the encoder would miss read.

Here is our data after cleaning the encoder.

13

If you don’t mind too much, can you post the graph with the x axis? That might give you another data point on how accurate it is as square rooting the x axis should linearize the graph…

14

I’m not sure exactly what you are asking. You want me to square root the x axis (time) to linearize the data?

15

What do you use to graph your data? It looks a thousand times better than when i use excel to graph.

16

I just use excel. Maybe your rate is too low. How much time do you wait before every check?
@jpearman seems to have a good way of posting graphs as a picture???
Mine always end up being really long.