So I’m having some pretty major consistency issues with my team’s current robot. Essentially our launch system works like a tennis ball launcher where a ball is rolled between two spinning wheels. The system works fine as far as shooting the proper distance but because the launcher is left running most of the match, batteries drain rapidly. This then leads to the wheels slowing down even though they’re at the same motor values as they were at the start of the match. To solve this I am looking to measure the RPMs of the wheels and have them adjust to reach the proper RPM. I was thinking of using Optical Shaft Encoders but am not really sure how I would do that. Any suggestions?
There have been a few threads about measuring RPM already.
What you want to do is measure the ticks from the encoder per unit time. There is a constant for the ticks per revolution and then you scale it up to the final driven wheel to get to the flywheel Revolutions per time unit of choice. The IME versus the big red encoders are slightly different scales in ticks per revolutions.
The per unit time is the time you measure now versus time the last measurement in the previous loop run. This can be derived from the current nPgmTime versus the last value you saved off or the value of your loop. That will be in units of milliseconds.
ticks_per_millisecond = (new_sensor_value - old_sensor_value)/(new_time - old_time)
Adjust your ticks_per_millisecond into your chosen units. revolutions per minute is common.
rev_per_minute = ticks_per_millisecond / ticks_per_revolution * milliseconds_per_minute
I will let you look up the values of ticks per revolution and you can figure out milliseconds per minute. Be careful of big numbers and integers so you may want to per-compute (1 / ticks_per_revolution * milliseconds_per_minute) into one value to multiply by (or divide by depending upon how you want to do it)
That will give you an instantaneous rotational velocity. That can be a bit noisy or troublesome if you measure too quick. So either average a few RPM values together or wait a few milliseconds between readings to not have too weird of a value. I suggest waiting longer between RPM values but that can mess with your motor controller.
Then log to the debug stream the values of RPM, time, and motor power to start visualizing what is going on. Make a graph of RPM and power on Y axis with time on the X axis.
Okay, thanks for the advice. This should give me a solid starting point for programming the system. Today I opened up one of the large red encoders to take a peek at the insides and I’m experimenting with filling all but one hole with glue and then coloring over the glue to stop any light from passing through. Hopefully this means that the encoder will read one tick for every revolution which should simplify things quite a bit. Is there an easy way to add a delay between RPM values without screwing up my controller input?
This will not help with calculating velocity, it will have a detrimental effect.
I might be wrong, but in RobotC I think you could launch a task that does nothing but read the encoders and calculate your RPMs and put those RPMs into variables you can use elsewhere in the program. Since the task runs independently of your main controller code, your main code won’t have to wait around for an RPM evaluation.
Try again, I edited FullMetalMentor’s post by mistake, my bad.
You might be wrong, but you are right 
you could also save yourself all the trouble, upgrade to 4.52, add an IME to the motor and call
getMotorVelocity
Thanks for this tip, I generally avoid RobotC updates as I had a bad experience with an update breaking things in the past. So this time I took the update and tried to use the new getMotorVelocity but couldn’t get it working. Is there any documentation for me to read up on built in functions? Also, we don’t have the IME’s but we do have a bunch of Quad Encoders. If I link the quad encoders to the motors in motor and sensor setup, can it be used with getMotorVelocity or will I need to do it the long way?
getMotorVelocity is only supported for IMEs. The IME returns the velocity information, the quad encoder does not. You can find links to (some) documentation in the ROBOTC help menu. We may work on a cheat sheet over the next few weeks, it’s long overdue, we’ll have to see if we can find time.
Do you happen to have a good resource for learning about simultaneous tasks in RobotC? This seems like my best option but I’m struggling to figure out how to implement it.
James Pearman’s programming tips thread. Specifically this post:
https://vexforum.com/t/sprocket-and-chain/14951/1
Look at the next 4 posts in that thread too. You will see an attachment in there with some examples.