Re: Unexpected results from Encoder::GetRate()
 

This is along the lines I was thinking. But it seems that we have to capture the complete register array before we start using the results or at least temporarily halt the interrupts while we do multiple register reads.
I.E Wouldn't this be a possible problem?
Beauty is in the eye of the beholder. I'm pretty happy with the money I'm saving with my hysteresis thermostat even thought the temperature varies a little. All I have to do is figure out a way to connect an encoder to a bi-metalic coil and then hook it to my heater control:)

Re: Unexpected results from Encoder::GetRate()
 

Yes... if you did it that way, you would have a small window for the register to change. However, that is why I put both in the same register. Same thing goes for the period, the count, and the stall information. All related; all in the same register.

If instead you did:

Cheers!
-Joe

Re: Unexpected results from Encoder::GetRate()
 

Thanks, that's what I was looking for. Duh, I finally found the tcounter.h files in Windriver Chipobject directory that describes the output data structure. Had I found those earlier, I could have figured a few more things out for myself.

I still would like to know the details of your GetRate() algorithm that keeps the rate from reporting on a same edge. Its not obvious where you do this.

Also, could you describe the 4x algorithm equations (like your description of the 1x and 2x earlier).

Re: Unexpected results from Encoder::GetRate()
 

The rate calculations and the quadrature decoder are decoupled bits of logic. The "Event Timer" logic takes input from a generic event source... one of which is a quadrature decoder. The quadrature decoder will only indicate an event to the event timer if the direction that is decoded is the same as the previous direction. That's really all there is to it.

The sliding-window average engine that follows the event timer will reset its pipeline of samples on direction changes as well. This is because the rates are unsigned and averaging rates that refer to different directions without sign has no meaning. It could potentially be modified to be signed, but then we are duplicating direction information. Maybe that's a good thing. Thoughts?

-Joe

Re: Unexpected results from Encoder::GetRate()
 

.
Ok...I just have to remind myself that the m_counter object register really represents two counter results... output.value and output.count. They are related only when the output.dir is the same as previous dir. The GetPeriod() intro
really only truly applies to the event timer count not the value count.

So I think I'm clear on that now.

If I wanted to implement my own rate algorithm, I don't think I can determine if a same edge event has occurred by looking at your register information. I believe I would need a same edge flag added to your output register.

The only change I would make is to set the rate = zero at this event rather than no report at all. I think you are throwing out some of the A/B information available to you. When a reversal occurs, your rate will be 180 deg out of phase, rather than just 90. This is slightly more destabilizing and if rate is needed by a PID loop to stabilize an otherwise near neutral or unstable plant it will lead to a several count limit cycle which would probably approach the one generated by a hysteresis controller. Plus, your rate estimate will be biased in the presence of oscillations.

If you modifiy your GetRate() in the future, I would favor adding the zero rate and same edge flag features.

This question probably needs simulation testing but here is my gut reaction: I don't think this is a good thing. It probably won't matter if the default single pulse is maintained. But if a larger averaging window is truly needed to filter the noise, then your implementation has all the drawbacks of a low pass but few of the benefits. If there are no high frequencies in the signal, the pipeline will just cause phase lag. If there are high frequencies, the filter will be reset often giving a shorter effective averaging pipeline (raising filter band width)and lowering the effective noise reduction.

Perhaps this phenomenon was present last year when I did a couple of runs with different pulse averaging lengths and did not see much benefit. http://forums.usfirst.org/showpost.p...43&postcount=5

Re: Unexpected results from Encoder::GetRate()
 

Notation:
A => value of A channel currently
A' => value of A channel last sample
A + B => A XOR B
A | B => A OR B
A & B => A AND B
!A => NOT A

Equations:
Count = (A + A') | (B + B')
Count_Dir = A + B' + !Reverse
Count_Up = Count & Count_Dir
Count_Down = Count & !Count_Dir

(Reverse is a configuration register)

-Joe

Re: Unexpected results from Encoder::GetRate()
 

The only meaning that "Count" in the tTimerOutput register has is the number of samples that are included in the sum presented in "Period". It is simply for the purpose of computing the average while avoiding doing the division in the FPGA.

If you can actually read the registers fast enough to keep up with each edge (which you would need to do to take advantage of a "same edge" flag), then you can just look for the dir to change.

I tend to agree that I should set the rate to 0 on a same edge. I'll look for a way to work that in for next year. As for the same edge flag, that info is not very useful and already available as stated above.

The average engine does have trouble at around 0 rate, which is why I suggested integrating the direction and not resetting the pipeline on direction change. When not at zero, it works great. Presumably in a lot of cases if you want zero rate, you can just turn off the motor, so it doesn't seem like a showstopper case.

Does anyone have a better idea for filtering noise from this kind of system than a sliding window average that doesn't reset at 0? Remember that we are HIGHLY space constrained so keep in mind that we need small and simple algorithms that are effective.

Thanks,
-Joe

Re: Unexpected results from Encoder::GetRate()
 

If you're trying to maintain zero rate, a simple way to do it is to maintain constant position.

Re: Unexpected results from Encoder::GetRate()
 

Yes of course. :yikes:

Re: Unexpected results from Encoder::GetRate()
 

.
Well, Ill have to work on you a little more. This flag would make the register a complete representation of the A/B state information which doesn't seem like a bad thing. I don't think a fast read would be practical solution.


I worry about a position servo case which drives to a reference and then holds zero rate. You may not be able to turn off a motor if there isn't sufficient braking torque to hold the controlled object.. ie a heavy manipulator arm.

Can you pipe the DIR flag into the pipeline so there would be 0's and 1's in the pipe line ? If so, couldn't you construct a recursive pipeline sum by summing the 1's in the pipeline and then computing a signed_sum = 2*(sum of 1's) - max_count. Then in GetRate() compute rate = (signed_sum )/period rather than 1/(period/max count). The summation would take a little extra time... not sure what the FPGA could do to optimize this.

The other alternative would be to use a IIR exponential filter. This would weight the latest pulse heavier than prior pulses. I would prefer the FIR pipeline filter over this but it might work fine.

Re: Unexpected results from Encoder::GetRate()
 

My general feeling about indicators that only stick around for one tick of something is that they are basically useless in a register interface. I designed the interfaces to isolate the timing of the measurement from the code that needs it, meaning the code can stop by any time it wants and ask for a value. What you are proposing would only be set for one tick of the encoder, and the information is already available as the change in value of dir. If you look for a change in value of dir, you can get that information any time you read. If you are looking at your proposed same edge flag, then you have to read before the next edge or you've lost the information. Hence my statement that you would have to read fast enough to catch every edge in order to make use of such a bit.

Perhaps I could make the same edge event set the stalled bit immediately, since a same edge represents a stop (except in the ridiculous noise case).

As Alan stated, use a position controller, which doesn't use the rate output, it uses the position output.

What is the benefit to this? Just cancelling out one set of rates for each dir change?

-Joe

Re: Unexpected results from Encoder::GetRate()
 

[quote]This is like trying to decode the encoder without interrupts using fast reads...just seems you couldn't do it reliably.

Thats an idea.. or maybe make DIR flag a two bit output... the first bit is DIR, the second is LAST_DIR



This of course depends on the dynamics of the open loop plant. If there is sufficient loop lag, then usually a rate term is required to place the closed loop poles at the optimum values.

The signed_sum is just the net count (net position change) over the period. Isn't this what you want for a moving average that isn't zero reset?

Re: Unexpected results from Encoder::GetRate()
 

I finally took the time to look into this issue. I found the source of the mysterious factor of 2 that was introduced for the patch. It's caused by the fact that the "Period" variable for TimerOutput is a fixed point number that is not decoded when TimerOutput is read as a complete structure... only when read from the direct accessor. That means the decoding must be done in the driver. Since the fixed point format is 24 bits with 25 integer bits, the data must be shifted by 1 bit position... the factor of two!

I've attached the final patch that went in for those who are curious.

-Joe

Re: Unexpected results from Encoder::GetRate()
 

Thanks Joe, you done well.

A few questions/comments:
1) I see you took my suggestion for the x1,x2 and x4 averaging pulse count. Did you take a look to see if this really helped the rate noise increase with the x2 and x4 configs? I sort of have mixed feelings on this now. It should sure help if all the pulses are within a single reference frame, but would be less effective if averaging pulses which are part of different frames.
I still would like you to add a SetMovingAveragePulseCount(int max_count) procedure to allow user control of this.

2)Did you set the rate = zero at a same edge event rather than no report at all in your subcode? If not is this in your plans?

3)Did you try to implement the signed pipeline as I suggested so you don't have to reset the pipeline at zero crossings http://www.chiefdelphi.com/forums/sh...5&postcount=85 ?

Re: Unexpected results from Encoder::GetRate()
 

Absolutely. At least for the encoder I was using, it made an incredible difference. Both phase noise and high vs. low time noise (slit width). It's essentially mandatory unless you know you have a high precision encoder. Without it, the measurements were very noisy... around 30% variation for my encoder.

As far as your concern about frames, an encoder doesn't have "frames". The pulses are from one slit to the next and are typically pretty uniform (more so than the A-B phase or the slit-spoke ratio). I think this works just great.

I agree. It's always been my intention to have this configurable by the user, I just never got around to adding the function to expose it. Fortunately the rest of the code can handle when the value is changed, so last year the worst a team would have to do is hack in their own little accessor. It's on my list of things to do this year.

This would be an FPGA change... I'm looking into it. Setting the rate to 0 would involve setting the count to 0. This is directly related to #3.

I have not tried it yet, but I have looked at the code and have a good idea of how it would fit in. Essentially, I would add a sign bit to the count output, and instead of resetting the count to 1 on a direction change, I would just set the direction as the sign bit. This way if you change direction, the counts cancel out and gives you 0 (from #2 above). I believe this is the signed sum behavior you were looking for.

It also means that the direction is available in this TimerOutput register as well as the position output register. We would no longer need to access the position register to dermine the direction as we do today. I still need to decide whether to reduce the range of the timer or the resolution to get the bit I need for the sign bit.

-Joe