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?
Care to tell us what the units of measure on the X and Y axis are? This doesn’t tell me much.
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.
How many counts per revolution is your encoder? I’m trying to figure what your average RPM rate is.
1440 per revolution
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?
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.
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
The values being read by my getRate(); Function in Java
http://www.chiefdelphi.com/forums/showpost.php?p=1115596&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”
@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.
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.
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.
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?
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.
*
*
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.
Awesome, thanks this should really help out thanks for anyone who has been testing this along with me.
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!