pic: Encoder Graph
 

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?

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.

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.

Re: pic: Encoder Graph
 

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

Re: pic: Encoder Graph
 

1440 per revolution

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?

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.

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

Re: pic: Encoder Graph
 

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.

Re: pic: Encoder Graph
 

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.

Re: pic: Encoder Graph
 

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

Re: pic: Encoder Graph
 

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

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?