|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
| Thread Tools | Rate Thread | Display Modes |
|
#1
|
||||
|
||||
|
High Speed Encoder Problem
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.
|
|
#2
|
||||
|
||||
|
Re: High Speed Encoder Problem
How are you calculating the rate? Are you using WPILib?
|
|
#3
|
||||
|
||||
|
Re: High Speed Encoder Problem
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.
|
|
#4
|
||||
|
||||
|
Re: High Speed Encoder Problem
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? |
|
#5
|
||||
|
||||
|
Re: High Speed Encoder Problem
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. |
|
#6
|
|||||
|
|||||
|
Re: High Speed Encoder Problem
Here's some more info on the data behind the .getRate() method and the equivalent LabVIEW and C++ functions.
http://www.chiefdelphi.com/forums/sh...d.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. |
|
#7
|
||||
|
||||
|
Re: High Speed Encoder Problem
Quote:
http://www.chiefdelphi.com/forums/sh...4&postcount=37 |
|
#8
|
||||
|
||||
|
Re: High Speed Encoder Problem
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.
|
|
#9
|
||||
|
||||
|
Re: High Speed Encoder Problem
Yeah.
I thought about an average value too, but our programmers don't know how to implement that. |
|
#10
|
||||
|
||||
|
Re: High Speed Encoder Problem
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????
|
|
#11
|
||||
|
||||
|
Re: High Speed Encoder Problem
Quote:
|
|
#12
|
||||
|
||||
|
Re: High Speed Encoder Problem
Perfect, Thanks.
![]() |
|
#13
|
|||||
|
|||||
|
Re: High Speed Encoder Problem
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 |
|
#14
|
||||
|
||||
|
Re: High Speed Encoder Problem
Quote:
|
|
#15
|
||||
|
||||
|
Re: High Speed Encoder Problem
Quote:
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. |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|