High Speed Encoder Problem

[Ether]

Originally Posted by 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.

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]

Originally Posted by Ether

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]

Originally Posted by 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.

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]

Originally Posted by Hugh Meyer

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]

Originally Posted by btslaser

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/sh...d.php?t=103676

[JamesTerm]

Originally Posted by Ether

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]

Originally Posted by 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
 */

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]

Originally Posted by 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.

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]

Originally Posted by 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.

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.