OCCRA
Go to Post They may call us geeks and nerds, but deep down under that prejudice they know they want to be the hard-core, sleep-deprived, hand drill-toting, robot builders we know we are! - vijay24 [more]
Home
Go Back   Chief Delphi > Technical > Programming > C/C++
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Reply
Thread Tools Rating: Thread Rating: 3 votes, 5.00 average. Display Modes
  #76   Spotlight this post!  
Unread 05-01-2010, 02:54 PM
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: 184
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
BTW, you can get the same results that you get with your algorithm by simply adding 1 to the distance if direction is false with the built-in counter and you don't need any of that fancy stuff.

-Joe
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?
Code:
*/
INT32 Counter::Chris_Get()

{      INT32 value ;

	INT32 cnt = m_counter->readOutput_Value(&status);
	
        bool dir = m_counter->readOutput_Direction(&status); 
//Couldn't the registers be different when we read dir vs the cnt read ??

        if(dir )  // Assume dir = 0 decrements count
     
	{ return value  ; } // if we haven't reversed then update count
        else 
       {  return value +1; } // else keep the count at last value
       
}
Quote:
But it will be worse! ;
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

Last edited by vamfun : 05-01-2010 at 04:39 PM.
Reply With Quote
  #77   Spotlight this post!  
Unread 05-01-2010, 04:42 PM
jhersh jhersh is offline
National Instruments
AKA: Joe Hershberger
FRC #2468 (Appreciate)
Team Role: Mentor
 
Join Date: May 2008
Rookie Year: 1997
Location: Austin, TX
Posts: 1,006
jhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond repute
Lightbulb Re: Unexpected results from Encoder::GetRate()

Quote:
Originally Posted by vamfun View Post
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?
Code:
*/
INT32 Counter::Chris_Get()

{     
	INT32 cnt = m_counter->readOutput_Value(&status);
	
        bool dir = m_counter->readOutput_Direction(&status); 
//Couldn't the registers be different when we read dir vs the cnt read ??

        if(dir )  // Assume dir = 0 decrements count
     
	{ return value  ; } // if we haven't reversed then update count
        else 
       {  return value +1; } // else keep the count at last value
       
}
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:

Code:
INT32 Counter::Chris_Get()
{
	//Now all the information is read in one register access!
	tCounter::tOutput output = m_counter->readOutput(&status);

	// dir = 0 decrements count
	if (output.Direction)
	{
		// if we haven't reversed then update count
		return output.Value;
	}
	else
	{
		// else keep the count at last value
		return output.Value + 1;
	}
       
}
Cheers!
-Joe
Reply With Quote
  #78   Spotlight this post!  
Unread 05-02-2010, 04:34 PM
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: 184
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
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:

Code:
INT32 Counter::Chris_Get()
{
	//Now all the information is read in one register access!
	tCounter::tOutput output = m_counter->readOutput(&status);

	// dir = 0 decrements count
	if (output.Direction)
	{
		// if we haven't reversed then update count
		return output.Value;
	}
	else
	{
		// else keep the count at last value
		return output.Value + 1;
	}
       
}
Cheers!
-Joe
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).
Reply With Quote
  #79   Spotlight this post!  
Unread 05-02-2010, 09:19 PM
jhersh jhersh is offline
National Instruments
AKA: Joe Hershberger
FRC #2468 (Appreciate)
Team Role: Mentor
 
Join Date: May 2008
Rookie Year: 1997
Location: Austin, TX
Posts: 1,006
jhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond repute
Re: Unexpected results from Encoder::GetRate()

Quote:
Originally Posted by vamfun View Post
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.
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
Reply With Quote
  #80   Spotlight this post!  
Unread 05-04-2010, 01:18 PM
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: 184
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
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.
.
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
Code:
/*
 * Get the Period of the most recent count.
 * Returns the time interval of the most recent count. This can be used for velocity calculations
 * to determine shaft speed.
 * @returns The period of the last two pulses in units of seconds.
 */
double Counter::GetPeriod()
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.

Quote:
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?
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

Last edited by vamfun : 05-04-2010 at 03:01 PM.
Reply With Quote
  #81   Spotlight this post!  
Unread 05-07-2010, 12:26 AM
jhersh jhersh is offline
National Instruments
AKA: Joe Hershberger
FRC #2468 (Appreciate)
Team Role: Mentor
 
Join Date: May 2008
Rookie Year: 1997
Location: Austin, TX
Posts: 1,006
jhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond repute
Re: Unexpected results from Encoder::GetRate()

Quote:
Originally Posted by vamfun View Post
Also, could you describe the 4x algorithm equations (like your description of the 1x and 2x earlier).
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
Reply With Quote
  #82   Spotlight this post!  
Unread 05-07-2010, 03:01 AM
jhersh jhersh is offline
National Instruments
AKA: Joe Hershberger
FRC #2468 (Appreciate)
Team Role: Mentor
 
Join Date: May 2008
Rookie Year: 1997
Location: Austin, TX
Posts: 1,006
jhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond repute
Re: Unexpected results from Encoder::GetRate()

Quote:
Originally Posted by vamfun View Post
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.
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.

Quote:
Originally Posted by vamfun View Post
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.
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.

Quote:
Originally Posted by vamfun View Post
The only change I would make is to set the rate = zero at this event rather than no report at all.

If you modifiy your GetRate() in the future, I would favor adding the zero rate and same edge flag features.
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.

Quote:
Originally Posted by vamfun View Post
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.
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
Reply With Quote
  #83   Spotlight this post!  
Unread 05-07-2010, 08:37 AM
Alan Anderson's Avatar
Alan Anderson Alan Anderson is offline
Software Architect
FRC #0045 (TechnoKats)
Team Role: Mentor
 
Join Date: Feb 2004
Rookie Year: 2004
Location: Kokomo, Indiana
Posts: 9,126
Alan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond repute
Re: Unexpected results from Encoder::GetRate()

Quote:
Originally Posted by jhersh View Post
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.
If you're trying to maintain zero rate, a simple way to do it is to maintain constant position.
Reply With Quote
  #84   Spotlight this post!  
Unread 05-07-2010, 02:00 PM
jhersh jhersh is offline
National Instruments
AKA: Joe Hershberger
FRC #2468 (Appreciate)
Team Role: Mentor
 
Join Date: May 2008
Rookie Year: 1997
Location: Austin, TX
Posts: 1,006
jhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond repute
Re: Unexpected results from Encoder::GetRate()

Quote:
Originally Posted by Alan Anderson View Post
If you're trying to maintain zero rate, a simple way to do it is to maintain constant position.
Yes of course.
Reply With Quote
  #85   Spotlight this post!  
Unread 05-08-2010, 01:59 AM
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: 184
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
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
.
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.


Quote:
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.
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.

Quote:
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.
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.

Last edited by vamfun : 05-08-2010 at 02:26 AM.
Reply With Quote
  #86   Spotlight this post!  
Unread 05-08-2010, 03:33 PM
jhersh jhersh is offline
National Instruments
AKA: Joe Hershberger
FRC #2468 (Appreciate)
Team Role: Mentor
 
Join Date: May 2008
Rookie Year: 1997
Location: Austin, TX
Posts: 1,006
jhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond repute
Re: Unexpected results from Encoder::GetRate()

Quote:
Originally Posted by vamfun View Post
.
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.
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).

Quote:
Originally Posted by vamfun View Post
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.
As Alan stated, use a position controller, which doesn't use the rate output, it uses the position output.

Quote:
Originally Posted by vamfun View Post
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.
What is the benefit to this? Just cancelling out one set of rates for each dir change?

-Joe
Reply With Quote
  #87   Spotlight this post!  
Unread 05-08-2010, 04:59 PM
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: 184
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]
Quote:
Originally Posted by jhersh View Post
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.
This is like trying to decode the encoder without interrupts using fast reads...just seems you couldn't do it reliably.

Quote:
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).
Thats an idea.. or maybe make DIR flag a two bit output... the first bit is DIR, the second is LAST_DIR



Quote:
As Alan stated, use a position controller, which doesn't use the rate output, it uses the position output.
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.

Quote:
Chris...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.
Quote:
Joe...What is the benefit to this? Just cancelling out one set of rates for each dir change?
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?

Last edited by vamfun : 05-08-2010 at 06:25 PM.
Reply With Quote
  #88   Spotlight this post!  
Unread 07-12-2010, 05:35 AM
jhersh jhersh is offline
National Instruments
AKA: Joe Hershberger
FRC #2468 (Appreciate)
Team Role: Mentor
 
Join Date: May 2008
Rookie Year: 1997
Location: Austin, TX
Posts: 1,006
jhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond repute
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
Attached Files
File Type: zip EncoderRateFix.zip (1.1 KB, 26 views)
Reply With Quote
  #89   Spotlight this post!  
Unread 07-12-2010, 06:09 PM
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: 184
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
I finally took the time to look into this issue. I found the source of the mysterious factor of 2 that was introduced ....

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

-Joe
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 ?

Last edited by vamfun : 07-12-2010 at 06:16 PM.
Reply With Quote
  #90   Spotlight this post!  
Unread 07-14-2010, 11:33 AM
jhersh jhersh is offline
National Instruments
AKA: Joe Hershberger
FRC #2468 (Appreciate)
Team Role: Mentor
 
Join Date: May 2008
Rookie Year: 1997
Location: Austin, TX
Posts: 1,006
jhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond repute
Re: Unexpected results from Encoder::GetRate()

Quote:
Originally Posted by vamfun View Post
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.
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.

Quote:
Originally Posted by vamfun View Post
I still would like you to add a SetMovingAveragePulseCount(int max_count) procedure to allow user control of this.
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.

Quote:
Originally Posted by vamfun View Post
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?
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.

Quote:
Originally Posted by vamfun View Post
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 ?
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
Reply With Quote
Reply


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
[BB] An unexpected change in plans yodameister General Forum 22 12-01-2009 09:26 PM
Inconsistent reading from encoder get rate rwood359 National Instruments LabVIEW and Data Acquisition 5 01-13-2009 07:10 PM
Results from Drexel, thanks from 365. archiver General Forum 1 06-24-2002 02:44 AM
Results from GLR? archiver General Forum 0 06-24-2002 02:44 AM
results from regionals archiver General Forum 0 06-23-2002 10:31 PM


All times are GMT -5. The time now is 02:18 AM.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi