I am trying to tune a velocity control loop, but am having trouble finding a way to measure the target RPM. What code should I run to figure this out?
@Mystical Pie I assume you meant current rpm instead of target, becuase you should be setting the target rpm to a value not measuring it. We use a quad encoder to measure our current velocity. Velocity is distance/time, so if you take an encoder reading at set time intervals you can find velocity. Our team has a task dedicated to calculating velocity that first sets the encoder to 0, then waits 10ms, then sets our current speed variable to the value of the encoder. As a result, our velocity is in ticks/10ms. You can use some simple math and some info from the vex website for ticks/rotation of your encoder to find true rpm.
A few threads for you. Both by @jpearman
maybe we need a new Forum subtopic - Best of JPearman
1) Velocity measurement techniques
2) Velocity control
Our teams use a stroboscope to verify we are getting what we are supposed to be. Here is an example with a high end one - https://youtu.be/KPrSPqfVJhA. If you can’t borrow or afford one, there are a few free phone apps - Strobe Tachometer, Strobe Light - that will work if you turn the ambient lights down low enough. I like to verify this way because there are some conditions where your update frequency will affect your actual output.
Am I missing something? Do you hold a sensor in your hand?
Tabor, the strobe has an RPM readout with a variable dial. You start at the theoretical speed and dial the RPM down until you “freeze” the motion of the wheel and that RPM is your actual. Is that your question?
Early season, before we were running a control loop, we used the strobe technique in the video and the readout on the strobe to determine the actual flywheel rpm vs. the theoretical calculation. This was good for understanding how much friction loss we were getting and improve. When we went to closed loop control and setting target values, we read out motor velocities to a file. The file values needed a lot of smoothing because the instantaneous values oscillated quite a bit. The strobe was still a quicker diagnostic for us.
O okay you were taking the question at face value and answering how to get the most accurate target RPM to then be entered in the code. I was with @Sunil on thinking the question was meant to be asked about measuring live RPM in the program, hence my confusion about a third party sensor.
Tabor, yes, my point was that the strobe is a good way to check for math errors in the code. Looks like you had already answered the coding questions above. This was just intended as an additional debug technique!