pic: Encoder Graph

[JohnFogarty]

loading photo ...

[IKE]

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]

Care to tell us what the units of measure on the X and Y axis are? This doesn't tell me much.

[JohnFogarty]

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]

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

[JohnFogarty]

1440 per revolution

[BitTwiddler]

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]

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]

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]

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]

@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]

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]

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.

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

[BitTwiddler]

Originally Posted by Ether

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]

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?