View Single Post
  #49   Spotlight this post!  
Unread 23-04-2010, 19:07
vamfun vamfun is offline
Mentor :Contol System Engineer
AKA: Chris
FRC #0599 (Robodox)
Team Role: Engineer
 
Join Date: Jan 2009
Rookie Year: 2003
Location: Van Nuys, California
Posts: 183
vamfun is a glorious beacon of lightvamfun is a glorious beacon of lightvamfun is a glorious beacon of lightvamfun is a glorious beacon of lightvamfun is a glorious beacon of lightvamfun is a glorious beacon of light
Send a message via AIM to vamfun
Re: Unexpected results from Encoder::GetRate()

Quote:
Originally Posted by jhersh View Post
Why would I want the range that a number represents to be different based on the direction that the shaft was last rotating?
Simply to be more accurate for the edge oscillation case.
Your scheme and mine will both have 1 count ambiguity...it just occurs at different times. I am interested in the best estimate of angle not just the count. I am showing a preference to have the best estimate at edge reversal rather than a count later. I can do this because of B channel information.
Lets take a simple 1 deg resolution encoder. We start with 0 angle, rotate to 1.1 deg and reverse to .99 and continue back to .1 and eventually back to 0. Error = true - encoder
Angle..joe count/chris count... joe error/chris error

0.0..0/0....0/0
1.1..1/1... 0.1/0.1*****tie
0.9..0/1...0.9/-0.1*****chris wins
0.5..0/1...0.5/-0.5*****tie.
0.1..0/1....0.1/-0.9*****joe wins
0.0..0/0.....0/0******tie

So if we are oscillating in a band about the 1 deg edge [.9 to 1.1], my algorithm will give a better estimate of angle position on reversal and we are the same going forward past 1. My rate will be zero without special compensation when oscillating in band, yours needs compensation to avoid huge rates with high frequency small amplitude oscillations (see Edit). Likewise, if we oscillate about the 0 deg edge or any edge.

So the reason for introducing the hysteresis is to avoid the rate spikes associated with the edge oscillation without giving up anything on accuracy. I.e. both have the same maximum error , just shifted in the cycle.

Edit:
Refer back to the above example and assume a small oscillation about the 1 deg edge with .1 deg amplitude at 10 rad/s. The truth rate amplitude should be 1 deg/s. Mine will be 0 yours will be (1*10) deg/s. The error in rate estimate for mine will in general be A*w , yours will be (1-A)*w where w is the frequency (rps) and A is the angle displacement amplitude. The ratio between our errors (joe/chris) is roughly 1/A for small A. Therefore , very small amplitude vibrations can cause very large differences in accuracy. E.g. A =.01 ... your error can be 100 times mine. In absolute terms, my error will be equal to the truth amplitude (100%) , while yours will be 100%/A. This you know and that's why you compensated for this effect in GetRate(). Using the hysteresis scheme, this is automatically compensated for in the GetDistance() count hence no compensation is required in GetRate() if you just divide the count by the count period.


Quote:
I'm not clear on what algorithm you are using to compute the rate in software. Depending on what you are using, this may or may not be a moot point or have other issues. Please describe what you are using.
Lets assume its just (new-old)/dt without special filtering. If my dt spans multiple counts, then it is moot...but if I'm rocking on an edge like Alan mentioned...it can lead to trouble unless we do some compensation somewhere with your algorithm.


Quote:
This is not an accurate statement. A rate is a difference in timing between two events. As such the first event can not have a "rate" associated with it because there is no reference as to when that motion began. That is why the first edge in a given direction can not calculate a rate.
We have two events.... crossing same edge in forward and reverse directions.
-Joe

Last edited by vamfun : 24-04-2010 at 04:10.
Reply With Quote