High Speed Encoder Problem

[Mr. Rogers]

Hey, we have a 128 click encoder for our shooter speed. Our java programmers managed to get an encoder velocity, but it updates constantly and is all over the place, it ranges +/- 1000 clicks per second when we run a constant speed on the shooter motors, any way to clean up the "noise," if that's the problem. Thanks.

[Ty Tremblay]

How are you calculating the rate? Are you using WPILib?

[Mr. Rogers]

It that a lab view feature? We're using a pre-made java class from the 2012 API. It has a " .getRate() " that returns the angular velocity.

[Ty Tremblay]

WPILib is basically the whole thing. I think encoder.getRate() works by reading the number of encoder counts from the FPGA and then dividing by the time elapsed between readings. As your RPMs increase, your noise will increase. Have you tried a moving average?

1000 ticks per second is actually pretty darn slow. That equates to about 470rpm. Is that the speed you're looking for?

[Tom Line]

That's the encoder we gave you :) .

The getrate from the library is an instananeous rate. You'll be better off using the 'get count' function, and then measureing the time between loop updates like this:

(New count - old count ) / loop time

If that ends up still being noisy, you can average, or calculate over more than one loop. Also, make sure you're running in single sample mode rather than 4x to remove phase errors.

[kenavt]

Here's some more info on the data behind the .getRate() method and the equivalent LabVIEW and C++ functions.

http://www.chiefdelphi.com/forums/showthread.php?t=101485

As you can see, it requires some processing to smooth out the output. Tom recommended a good alternative and a quick way to smooth out the getRate() output.

[Ether]

Here's some more info on the data behind the .getRate() method and the equivalent LabVIEW and C++ functions.

http://www.chiefdelphi.com/forums/showthread.php?t=101485

As you can see, it requires some processing to smooth out the output. Tom recommended a good alternative and a quick way to smooth out the getRate() output.

IIR and FIR filter options explained here:
http://www.chiefdelphi.com/forums/showpost.php?p=1123274&postcount=37

[Hawiian Cadder]

Are you sure that your encoder will track that fast? We are making a custom disk for an encoder with only 3 Clicks per rotation to ensure velocity accuracy.

[Mr. Rogers]

That's the encoder we gave you :) .



Yeah. :rolleyes: :rolleyes:
I thought about an average value too, but our programmers don't know how to implement that.

[Mr. Rogers]

If that ends up still being noisy, you can average, or calculate over more than one loop. Also, make sure you're running in single sample mode rather than 4x to remove phase errors.

Yeah, I was wondering if we could do that. All the java classes for encoder need an A and B channel. Could we just sample pulses from one digital port and compare it against the code's timer????

[Ether]

Yeah, I was wondering if we could do that. All the java classes for encoder need an A and B channel. Could we just sample pulses from one digital port and compare it against the code's timer????

Yes, but with the Counter class instead of the Encoder class.

[Mr. Rogers]

Yes, but with the Counter class instead of the Encoder class.



Perfect, Thanks.:)

[Hugh Meyer]

The periodic rate can be controlled either by a fixed value or follow the driver station. If it is set to follow the driver station, which is the default, then the period time will vary because of being a windows app. If you set the period to a specific value the cRIO will maintain a very precise periodic rate. This could also be a source of your problem.

-Hugh

[Ether]

The periodic rate can be controlled either by a fixed value or follow the driver station. If it is set to follow the driver station, which is the default, then the period time will vary because of being a windows app. If you set the period to a specific value the cRIO will maintain a very precise periodic rate. This could also be a source of your problem.

-Hugh

... or you could read the actual elapsed time since the last sample, rather than assuming it is 20ms.

[Ether]

I thought about an average value too, but our programmers don't know how to implement that.

If you use an infinite impulse response filter, it is very simple to do:

new_filtered_value = K*previous_filtered_value + (1-K)* new_sample

... that's all there is to it.

"K" is a tuning constant, which you use to adjust the "strength" of the filter. K must be in the range zero to +1. When K=0, there is no filtering. When K=1, the filtering is so "strong" that the filtered value never changes.

[Ether]

The periodic rate can be controlled either by a fixed value or follow the driver station. If it is set to follow the driver station, which is the default, then the period time will vary because of being a windows app.

Is this situation different at competition than at home?

Does the FMS follow the user's DS, or is it designed to send TeleOp packets at 20ms ?

And even if it is designed to send at 20ms (rather than following the user's DS), I guess the problem would still exist, albeit perhaps in a slightly different form, yes? no? still thinking about it.

[Mark McLeod]

At competition the DS packets are still sent by the DS.
FMS only orders the DS to change modes, but the DS has to send that command to the robot.
Any slow down in the DS PC will delay packets.

One of the checks for slow or lost packets is the CPU utilization on the DS.
(If in the Classmate Driver acct. use: CTRL-Shift-Esc -> Performance)
A saturated netbook can be a cause of lost and delayed packets. I see that pretty often.

[Hugh Meyer]

Is this situation different at competition than at home?

Does the FMS follow the user's DS, or is it designed to send TeleOp packets at 20ms ?

And even if it is designed to send at 20ms (rather than following the user's DS), I guess the problem would still exist, albeit perhaps in a slightly different form, yes? no? still thinking about it.




Ether,

We use C++. There is a configuration variable that sets the periodic rate. If it is zero then the rate will follow the driver station. If it is not zero then the value entered will be the periodic rate. I tell our programmers to ALWAYS set the rate. We have not settled on a value for this year yet. We use a scope to be sure all of our traffic on the CAN bus is complete. This is detailed in other threads as you know.

As best I know FMS does not fiddle with this. Last year we used 100 msec and would show up on FMS as a long ping time. A few times the FTA would tell us about it, but it didn't seem to be a problem. I have some photos of the FMS screen showing this. I will try to find them and post here, but this season has been very busy, so don't hold your breath. :-)

Maybe we should start a new thread about this?

-Hugh

[Ether]

At competition the DS packets are still sent by the DS.
FMS only orders the DS to change modes, but the DS has to send that command to the robot.

Thanks Mark. That makes sense. I think I knew that at one time but forgot (face palm).

So Hugh's comment about DS packet timing variations caused by Windows scheduling of the DS applies equally at home and at competition.

[Brian Selle]

Ether,

We use C++. There is a configuration variable that sets the periodic rate.


What is the class.method that you call to set this? Is it available in Java?

[Ether]

What is the class.method that you call to set this? Is it available in Java?

I'm going to start a new thread, as Hugh suggested, to discuss this. When it's up I'll post a link here.

EDIT: Here's the link:
http://www.chiefdelphi.com/forums/showthread.php?t=103676

[JamesTerm]

If you use an infinite impulse response filter, it is very simple to do:

new_filtered_value = K*previous_filtered_value + (1-K)* new_sample

... that's all there is to it.

"K" is a tuning constant, which you use to adjust the "strength" of the filter. K must be in the range zero to +1. When K=0, there is no filtering. When K=1, the filtering is so "strong" that the filtered value never changes.





I like this IIR... in the video world we call this a blend function as it is a way to blend one pixel onto another... where we would do blending transitions effects for each pixel.

With our recent encoder issue (sorry I don't know how to link to it)... I tried using the blend, but found that it would introduce latency when it is tuned too high. I prefer this over averaging though, but the real winner is the Kalman filter... that one gave good enough results without the latency. And latency makes it much more difficult to tune the PID. (Especially to someone who has not yet mastered the skill of it yet).

[mikets]

We have a similar filter in our library but we called it MovingAverage filter. In a sense, it is averaging the last N points.

/*
* MovingAverage of N points:
* MovingAverage = (MovingAverage*(N - 1) + CurrData)/N
* = MovingAverage*(N - 1)/N + CurrData/N
* = MovingAverage*(1 - Kf) + CurrData*Kf
* where 1/N = Kf
* (N - 1)/N = 1 - 1/N = 1 - Kf
*/

[Ether]

We have a similar filter in our library but we called it MovingAverage filter. In a sense, it is averaging the last N points.

/*
* MovingAverage of N points:
* MovingAverage = (MovingAverage*(N - 1) + CurrData)/N
* = MovingAverage*(N - 1)/N + CurrData/N
* = MovingAverage*(1 - Kf) + CurrData*Kf
* where 1/N = Kf
* (N - 1)/N = 1 - 1/N = 1 - Kf
*/


Actually, what you've shown above is an IIR filter and it does not average just the last N points. The values of all previous samples (not just the last N samples) get included in the calculation (to within the floating-point precision being used). The older samples contribute exponentially less to the output.

As you've shown, it's identical to what was posted earlier.

[mikets]

You are right, it does carry the history of all pass data points.

[JamesTerm]

Here is the Kalman Filter:


/************************************************** ************************************************** *******/
/* KalmanFilter */
/************************************************** ************************************************** *******/

void KalmanFilter::Reset()
{
m_FirstRun=true;
//initial values for the kalman filter
m_x_est_last = 0.0;
m_last = 0.0;
}

KalmanFilter::KalmanFilter(): m_Q(0.022),m_R(0.617) //setup Q and R as the noise in the system
{
}

double KalmanFilter::operator()(double input)
{
//For first run set the last value to the measured value
if (m_FirstRun)
{
m_x_est_last=input;
m_FirstRun=false;
}
//do a prediction
double x_temp_est = m_x_est_last;
double P_temp = m_last + m_Q;
//calculate the Kalman gain
double K = P_temp * (1.0/(P_temp + m_R));
//the 'noisy' value we measured
double z_measured = input;
//correct
double x_est = x_temp_est + K * (z_measured - x_temp_est);
double P = (1- K) * P_temp;

//update our last's
m_last = P;
m_x_est_last = x_est;

//Test for NAN
if ((!(m_x_est_last>0.0)) && (!(m_x_est_last<0.0)))
m_x_est_last=0;

return x_est;
}

[dcherba]

the problem is the time between updates can vary. In our c++ program we execute every 20 to 100 millisec. That means if we were doing the count divided by time there could be a 1-5 range of counts. The best thing to do is get the period of the last cycle. That will be in seconds and will not depend on the cycle time of the calls to the actual program.

For those with good control they used a a custom painted code wheel with one or three cycles to get the longest possible period with the highest quality of timer counts to calculate the speed.

[JamesTerm]

the problem is the time between updates can vary. In our c++ program we execute every 20 to 100 millisec. That means if we were doing the count divided by time there could be a 1-5 range of counts. The best thing to do is get the period of the last cycle. That will be in seconds and will not depend on the cycle time of the calls to the actual program.

For those with good control they used a a custom painted code wheel with one or three cycles to get the longest possible period with the highest quality of timer counts to calculate the speed.


Wow 20-100 ms... what are you guys processing (video imaging?) ;)

Anyhow... it should not matter if you have uneven time delta's as the rate will still work out correctly. Now then our problem is a bit unique in that using the GetDistance() technique... the actual pulses got updated irratically where 1 out of every 3 iterations it would update. I suspect this is because we used 4x setting, and I'll need to test with 1x or 2x to see if this behavior changes. Fortunately, our last years robot produces a fluent rate as I'd expect. In which case dividing by time works really well.

Check out this Encoder Test attachment... l1 = left wheels using GetRate(), l2=left wheels using GetDistance(). The r1 and r2 same for the right side. As you can see these are virtually identical, as these units are in RPS. The iteration intervals are around 10-11 ms, but it wouldn't matter what their size is as the rate would still be the same.

[JamesTerm]

Hey, we have a 128 click encoder for our shooter speed. Our java programmers managed to get an encoder velocity, but it updates constantly and is all over the place, it ranges +/- 1000 clicks per second when we run a constant speed on the shooter motors, any way to clean up the "noise," if that's the problem. Thanks.


We ran into a stroke of luck tonight to find the ROOT cause of a similar problem. This can be best explained like so:

Our shooter was not quite aligned for some time, and as it hit those higher speeds the vibrations of the casing were so intense that it cracked the casing around the encoder... the little wheel inside the encoder started to roll around inside its own casing as such where during certain intervals it briefly lost connection and did not deliver the pulse counts. When I say brief, I mean about 3 iterations per 10 where each iteration ran about 10-11ms. We fixed the damage the best we could with electrical tape, and ensured the wheel inside kept constant contact.

It was interesting how we found this problem by sheer luck... as we just happened to press against it while I was reading the dump, and saw the numbers looking much better during the period it was touched.

Hope this helps.