Chief Delphi
Page 2 of 3 < 1 2 3 >
Show 100 post(s) from this thread on one page

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   Extra Discussion (http://www.chiefdelphi.com/forums/forumdisplay.php?f=68)
-   -   pic: Encoder Graph (http://www.chiefdelphi.com/forums/showthread.php?t=101485)

JohnFogarty 30-01-2012 01:01
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?

Ether 30-01-2012 08:33
Re: pic: Encoder Graph
 
Quote:
Originally Posted by John_1102 (Post 1116306)
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?
  1. Get new_value (of counts)
  2. delta_counts = new_value - previous_value
  3. speed = delta_counts / cycle_time* (scaled to whatever units you want to use for speed*)
  4. previous_value = new_value


*See posts 23, 24, & 26 of this thread.

flameout 30-01-2012 09:16
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.

JohnFogarty 30-01-2012 15:07
Re: pic: Encoder Graph
 
Awesome, thanks this should really help out thanks for anyone who has been testing this along with me.

Nikhil Bajaj 30-01-2012 16:01
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!

Ether 30-01-2012 16:20
Re: pic: Encoder Graph
 
Quote:
Originally Posted by Nikhil Bajaj (Post 1116588)
If you're in 4x mode and timing the gaps between transitions to get the rate
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?)

Joe Ross 30-01-2012 19:12
Re: pic: Encoder Graph
 
Quote:
Originally Posted by Ether (Post 1116600)
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?)
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.

Ether 30-01-2012 19:54
Re: pic: Encoder Graph
 
Quote:
Originally Posted by Joe Ross (Post 1116693)
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.
I guess that would explain why you get a cleaner signal reading raw counts and averaging over the sample time, like you said.

DonRotolo 30-01-2012 21:48
Re: pic: Encoder Graph
 
Quote:
Originally Posted by John_1102 (Post 1116011)
1440 per revolution
Is it me, or does that seem like an awful lot of pulses per revolution for just controlling its speed. I'd imagine 1/1000 of that data would be more than enough. Or?

Ether 30-01-2012 21:56
Re: pic: Encoder Graph
 
Quote:
Originally Posted by DonRotolo (Post 1116801)
Is it me, or does that seem like an awful lot of pulses per revolution for just controlling its speed.
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.

JohnFogarty 31-01-2012 22:04
Re: pic: Encoder Graph
 
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;
        }
    }

Ether 31-01-2012 22:44
Re: pic: Encoder Graph
 
Quote:
Originally Posted by John_1102 (Post 1117461)
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;
        }
    }
Rather than putting the exact same post in two different threads, it's probably better to post a link:

http://www.chiefdelphi.com/forums/sh...9&postcount=27

http://www.chiefdelphi.com/forums/sh...6&postcount=29

wireties 31-01-2012 23:15
Re: pic: Encoder Graph
 
Quote:
Originally Posted by Ether (Post 1116814)
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.
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?

Ether 31-01-2012 23:22
Re: pic: Encoder Graph
 
Quote:
Originally Posted by wireties (Post 1117558)
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?
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

wireties 01-02-2012 17:29
Re: pic: Encoder Graph
 
Quote:
Originally Posted by Ether (Post 1117568)
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
Personally, I would not throw away dynamic range for zero benefit but still - it surprises me that the FPGA does not count that fast. This is good data to have - thanks again Ether!


All times are GMT -5. The time now is 08:52.
Page 2 of 3 < 1 2 3 >
Show 100 post(s) from this thread on one page

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