Chief Delphi - pic: Encoder Graph

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

29-01-2012 17:02

pic: Encoder Graph

IKE	29-01-2012 17:04

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?

BitTwiddler

29-01-2012 17:08

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.

JohnFogarty

29-01-2012 17:09

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.

BitTwiddler

29-01-2012 17:16

Re: pic: Encoder Graph

How many counts per revolution is your encoder? I'm trying to figure what your average RPM rate is.

JohnFogarty

29-01-2012 17:24

Re: pic: Encoder Graph

1440 per revolution

BitTwiddler

29-01-2012 17:43

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?

Alan Anderson

29-01-2012 19:02

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.

wireties

29-01-2012 19:24

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

Ether

29-01-2012 19:26

Re: pic: Encoder Graph

Quote:

The values being read by my getRate(); Function in Java

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

"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"

JohnFogarty

29-01-2012 22:51

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.

BitTwiddler

30-01-2012 00:13

Re: pic: Encoder Graph

Quote:

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.

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.

Ether

30-01-2012 00:16

Re: pic: Encoder Graph

Quote:

Originally Posted by BitTwiddler (Post 1116285)

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.

Some of the previous posts have indicated that the genesis of the variations may be within the encoder itself.

BitTwiddler

30-01-2012 00:27

Re: pic: Encoder Graph

Quote:

Originally Posted by Ether (Post 1116287)

Some of the previous posts have indicated that the genesis of the variations may be within the encoder itself.

Kinda looks like it. I don't know if a spinning object can really change rotational velocity that quickly without breaking something.

tsaksa

30-01-2012 00:50

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?

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)

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.

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)

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)

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!

vamfun

08-02-2012 16:17

Re: pic: Encoder Graph

Quote:

Originally Posted by Joe Ross (Post 1116693)

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.

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.

Ether

08-02-2012 16:25

Re: pic: Encoder Graph

Quote:

Originally Posted by vamfun (Post 1122522)

their 250 cnt/rev would limit the speed to 160 rpm.

160 rev/sec. = 9600rpm.

Joe Ross

08-02-2012 16:36

Re: pic: Encoder Graph

Quote:

Originally Posted by vamfun (Post 1122522)

It looks like it's in c++ but not java. I don't have access to LabVIEW right now to check.

It does appear that an enterprising java user should be able to use the c++ patch as a guide to modifying the java library.

vamfun

08-02-2012 18:08

Re: pic: Encoder Graph

Quote:

Originally Posted by Ether (Post 1122529)

160 rev/sec. = 9600rpm.

@#$$&(*^dang! Good catch... I fixed the post. Looks like the 250cnt/rev USdigitals are still in the running. For sure you would run them x1.

I was about to go out and buy some magnetic encoders.

Joe Ross

08-02-2012 21:44

Re: pic: Encoder Graph

Quote:

Originally Posted by Joe Ross (Post 1122535)

It looks like it's in c++ but not java. I don't have access to LabVIEW right now to check.

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).

vamfun

09-02-2012 00:41

Re: pic: Encoder Graph

Quote:

Originally Posted by Joe Ross (Post 1122730)

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).

Thanks Joe,
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.

All times are GMT -5. The time now is 08:52.