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.
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):
int RPMA1 = 0;
int RPMA2 = 0;
int RPMA3 = 0;
for(int i = 0; i < 3; i++)
RPMA3 = RPMA2;
RPMA2 = RPMA1;
RPMA1 = launcherRPM;
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.
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?
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.
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?
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.
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.
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.
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.