|
|
|
 Engineering is so much easier when you give all the components personalities. Then you just watch the drama unfold and try to fix it. - EricVanWyk [more] |
 |
|
|||||||
|
||||||||
The values being read by my getRate(); Function in Java
at a speed of 0.35
Sampling 100ms
Discussion
view entire thread
29-01-2012 17:04
IKE
Re: pic: Encoder Graph
So is this just a stable value, or do you have some sort of feedback loop? Do you think the speed is really varrying between 700 and 1250? That seems like a lot for the relatively short timeframe (if that is in fact ms along the bottom).
Can you share a bit more about what is going on?
29-01-2012 17:08
BitTwiddler
Re: pic: Encoder Graph
Care to tell us what the units of measure on the X and Y axis are? This doesn't tell me much.
29-01-2012 17:09
JohnFogarty
Re: pic: Encoder Graph
I've tried several tuning methods and no matter the length of time I run the built in encoder getRate(); method at it always oscillated that much. I was holding the motor at a constant power of 35% and this is the result I got, I'm not sure why exactly it's happening. I was expecting maybe a small amount of error but that is just insane.
it's sampling every 100ms so each number on the bottom is an increment in hundreds of milliseconds. While the y axis of the graph is supposed to represent the rate.
29-01-2012 17:16
BitTwiddler
Re: pic: Encoder Graph
How many counts per revolution is your encoder? I'm trying to figure what your average RPM rate is.
29-01-2012 17:43
BitTwiddler
Re: pic: Encoder Graph
Looking at the time period from 10-19 (1 second) I compute an average of 915 counts per 100ms sample. Divide that by 1440 counts per revolution that is .635 revolutions per sample or 381 RPM. Seems seriously slow for the shooter or am I misinterpreting the data?
29-01-2012 19:02
Alan Anderson
Re: pic: Encoder Graph
Are you using quadrature encoders and the WPI functions? If you configure it to use 4x decoding, you're likely to be bitten by asymmetry in the signal waveforms. The FPGA code measures rate by determining the time between signal transitions, and those transitions won't always come at a consistent rate unless you use 1x decoding.
29-01-2012 19:24
wireties
Re: pic: Encoder Graph
Remember the servo is not strictly a software system and/or a ideally-behaving mechanical system. The mechatronic systems play a significant role in the feedback. It is possible to have mechanical behaviors for which the servo cannot compensate. Plus your encoder values may require low-pass filtering if they are noisy for some reason.
Applying 35% power means nothing really (especially if there is significant delay in the mechatronics), are you trying PID control? Try the PID with a very small proportional gain and see if it cleans up a bit. Then play with the P and I terms (starting with I about 10% of P) and tell us what effects it has on your control.
Nice job collecting data!
HTH
29-01-2012 19:26
Ether
Re: pic: Encoder Graph
| The values being read by my getRate(); Function in Java |
"there's a lot of noise with the FPGA's rate due to phase errors in the encoder"
"Changing the encoder to 1x decoding decreased this significantly since it always used the same edge"
"Another option would be to calculate the rate from the position, which is equivalent to averaging for the sampling time"
29-01-2012 22:51
JohnFogarty
Re: pic: Encoder Graph
@BitTwiddler
This is a test motor to work with the functions at a low speed your number actually sounds correct. I think the motor I was using at the time was a CIM with a banebot gearbox 14:1 gear reduction.
@Ether I had posted this before we had that discussion in the PID thread. thank you though.
What I was doing was testing the reliability from the data I can receive from the US Digital Encoders.
From there I am looking at implementing a PID "style" Velocity control method.
I am going to use a value read from a Ultrasonic sensor to correspond to a value of "SPEED by encoder" loopup table to activate a controlled speed for the shooter, I found out this was necessary when we were testing out shooter and discovered after each shot there was a bit of time where the motor had to power back up to reach maximum velocity again.
Now our shooter only needed about 45% power to shoot the high basket from the key, at that low rate of power the "recharge" time was a little long, and I also realized throughout the match your battery voltage will deteriorate making the power% inaccurate. I want to be able to set a speed that I have determined through trials and tested encoder RATE/SPEED data to make my power management of the victor autonomous/automatic. Hense a PID Velocity control method.
30-01-2012 00:13
BitTwiddler
Re: pic: Encoder Graph
| This is a test motor to work with the functions at a low speed your number actually sounds correct. I think the motor I was using at the time was a CIM with a banebot gearbox 14:1 gear reduction. |
30-01-2012 00:16
Ether
Re: pic: Encoder Graph
|
Originally Posted by BitTwiddler
Is the motor running with a load? I would expect some kind of shooter wheel mechanism to have some inertia (flywheel) that would tend to smooth out the extreme variations you are seeing.
|
30-01-2012 00:27
BitTwiddler
Re: pic: Encoder Graph
|
Originally Posted by Ether
Some of the previous posts have indicated that the genesis of the variations may be within the encoder itself.
|
30-01-2012 00:50
tsaksa
Re: pic: Encoder Graph
Your post says the counts are taken over 100ms intervals. But in reality the samples will not be taken over exact or equal time intervals due to differences in program execution and timing. Particularly if you are running a virtual machine. You need to read the real time clock to know the real length of each sample interval. Are you getting the real time when each sample is made and then dividing the counts by the real time to get a number proportional to velocity?
30-01-2012 01:01
JohnFogarty
Re: pic: Encoder Graph
No not yet that seems to be the popular suggestion to fix this problem.
how would I go about sampling?
I know I would need to pull the raw value.
Do I store an initial value and then just add to it then divide it by my time?
30-01-2012 08:33
Ether
Re: pic: Encoder Graph
|
Originally Posted by John_1102
No not yet that seems to be the popular suggestion to fix this problem.
how would I go about sampling? I know I would need to pull the raw value. Do I store an initial value and then just add to it then divide it by my time? |
- Get new_value (of counts)
- delta_counts = new_value - previous_value
- speed = delta_counts / cycle_time* (scaled to whatever units you want to use for speed*)
- previous_value = new_value
*See posts 23, 24, & 26 of this thread.
30-01-2012 09:16
flameout
Re: pic: Encoder Graph
I ran a quick test as well (not graphing the data or anything, just dumping it to the standard output) and found a similar amount of variation. I was using whatever WPILibJ defaults to for encoder decoding (1X? 2X? 4X?).
For what I'm writing, however, manual differentiation (to those who don't know what this means, it's the method Ether wrote in the last post) is easier to implement and completely effective.
30-01-2012 15:07
JohnFogarty
Re: pic: Encoder Graph
Awesome, thanks this should really help out thanks for anyone who has been testing this along with me.
30-01-2012 16:01
Nikhil Bajaj
Re: pic: Encoder Graph
Just so everyone knows, from the US Digital website, the length of the on pulse for each channel in phase degrees is 180 +/- 16, and the quadrature delay between channels can be 90 +/- 12 degrees for the E4P encoder. If you're in 4x mode and timing the gaps between transitions to get the rate, the data that you got is what I'd expect it to look like based on the specifications!
30-01-2012 16:20
Ether
Re: pic: Encoder Graph
|
Originally Posted by Nikhil Bajaj
If you're in 4x mode and timing the gaps between transitions to get the rate
|
30-01-2012 19:12
Joe Ross
Re: pic: Encoder Graph
|
Originally Posted by Ether
Is that what the FPGA does? Times the edge-to-edge transitions, and then GetRate() returns a calculation based on only the 2 most recent edges (not averaged over several samples?)
|
30-01-2012 19:54
Ether
Re: pic: Encoder Graph
|
Originally Posted by Joe Ross
That is my understanding, although I haven't seen it documented. If it's 4x, it divides by the the time for the next edge on the opposite input. In 1x, it divides by the time for the same edge on the same input.
|
30-01-2012 21:48
DonRotolo
Re: pic: Encoder Graph
|
Originally Posted by John_1102
1440 per revolution
|
30-01-2012 21:56
Ether
Re: pic: Encoder Graph
|
Originally Posted by DonRotolo
Is it me, or does that seem like an awful lot of pulses per revolution for just controlling its speed.
|
1440/4 = 360 so it seems like he's running a 360 encoder at 4x.
Even at 60rpm that's 29 pulses every 20ms.
31-01-2012 22:04
JohnFogarty
Re: pic: Encoder Graph
This code gave me a VERY constant RATE on my graph.
public void getSpeed(){
samples[counter] = Shooter_En.getRaw();
counter++;
Shooter_En.reset();
if(samples[9] > 0){
counter = 0;
for(int i = 0; i <= 9; i++){
sum = sum + samples[i];
}
AVG = sum / 10;
Rate = AVG / 0.48;
sum = 0;
}
}
31-01-2012 22:44
Ether
Re: pic: Encoder Graph
|
Originally Posted by John_1102
This code gave me a VERY constant RATE on my graph.
Code:
public void getSpeed(){
samples[counter] = Shooter_En.getRaw();
counter++;
Shooter_En.reset();
if(samples[9] > 0){
counter = 0;
for(int i = 0; i <= 9; i++){
sum = sum + samples[i];
}
AVG = sum / 10;
Rate = AVG / 0.48;
sum = 0;
}
}
|
http://www.chiefdelphi.com/forums/sh...9&postcount=27
http://www.chiefdelphi.com/forums/sh...6&postcount=29
31-01-2012 23:15
wireties
Re: pic: Encoder Graph
|
Originally Posted by Ether
Agreed, for the speeds associated with a ball-shooting spinning wheel.
1440/4 = 360 so it seems like he's running a 360 encoder at 4x. Even at 60rpm that's 29 pulses every 20ms. |
31-01-2012 23:22
Ether
Re: pic: Encoder Graph
|
Originally Posted by wireties
What difference does it make? Isn't is just a counter in the FPGA incrementing? For a circuit like that, this rate is nothing. Am I missing something?
|
If it's on a wheel spinning at 5000rpm (like to shooter wheel), then that's 120,000 pulses/sec.
cRIO:
https://decibel.ni.com/content/message/12523
01-02-2012 17:29
wireties
Re: pic: Encoder Graph
|
Originally Posted by Ether
Depends on where he's going to put the encoder and whether the signal is going to the cRIO or the Jag.
If it's on a wheel spinning at 5000rpm (like to shooter wheel), then that's 120,000 pulses/sec. cRIO: https://decibel.ni.com/content/message/12523 |
08-02-2012 16:17
vamfun
Re: pic: Encoder Graph
|
Originally Posted by Joe Ross
That is my understanding, although I haven't seen it documented. If it's 4x, it divides by the the time for the next edge on the opposite input. In 1x, it divides by the time for the same edge on the same input.
|
http://www.chiefdelphi.com/forums/sh...1&postcount=90
Maybe this is equivalent to what you are saying. I wonder if it really got into the WPILIB as indicated.
So... looks like we only have about 40,000 cnts/s to play with on the FPGA.
In my experience, when the pulse interval time gets toward the limit, the FPGA method of deriving rate gets less accurate since the clock edge errors enter into the picture. The getRate() comes into its own when the pulses are sparce since it avoids spikes in rate when a pulse comes in.
edit{
The FPGA limit allows the US digital encoders for a shooter since their 250 cnt/rev would limit the speed to 160 rev/s or 9600 rpm. The minimum encoder wheel cnts/rev for the E4 is 100 so this could be increased to 24000 rpm. This should handle anyones shooter requirements. }
So what is everyone using for a 5000 rpm wheel?
Thinking outloud, if the shooter bandwidth is .5 hz we want the sensor bandwidth to be at least 2.5 hz to keep phase errors negligible. A two color wheel and a light sensor at 5000 rpm gives 500 pulses per sec so we would need a 1000 hz sampling rate to capture this with software without interrupts. Perhaps an encoder is easier.
08-02-2012 16:25
Ether
Re: pic: Encoder Graph
|
Originally Posted by vamfun
their 250 cnt/rev would limit the speed to 160 rpm.
|
08-02-2012 16:36
Joe Ross
Re: pic: Encoder Graph
|
Originally Posted by vamfun
When JoeHersh, I and others worked on fixing getRate problem last year, I thought we got some improvement in the noise with pulse averaging.
http://www.chiefdelphi.com/forums/sh...1&postcount=90 Maybe this is equivalent to what you are saying. I wonder if it really got into the WPILIB as indicated. |
It does appear that an enterprising java user should be able to use the c++ patch as a guide to modifying the java library.
08-02-2012 18:08
vamfun
Re: pic: Encoder Graph
|
Originally Posted by Ether
160 rev/sec. = 9600rpm.
|
I was about to go out and buy some magnetic encoders.
08-02-2012 21:44
Joe Ross
Re: pic: Encoder Graph
|
Originally Posted by Joe Ross
It looks like it's in c++ but not java. I don't have access to LabVIEW right now to check.
|
09-02-2012 00:41
vamfun
Re: pic: Encoder Graph
|
Originally Posted by Joe Ross
To follow up, it looks like LabVIEW does not set the timer averaging either, so c++ is the only language the benefits at the moment (without modifying the library).
|
It seems every year a few of us try to get this function functional and it never quite makes it for everyone.
This thread gives me deja vu with an older thread. I think the noise levels have improved for the x2 and x4 but have yet to see a good set of data.
I regret not having written a good encoder user manual last year when we disected the getRate() routine in this long thread where JoeHersh spilled the secrets of the internals of how this funcion is really coded. Anyway, the info is still there if you can get by a lot of my sidetracks. Unfortunately, I've forgotten half of stuff so I would have to wade through it again too....maybe someday.
view entire thread
Tags
loading ...