My team is using the V5 rotation sensors in our encoder wheels for odometry. While we have odometry working, I wanted to use the rotation sensors to calculate the velocity of our robot in meters per second to help determine the maximum speed of our robot and to debug various autonomous functions. I have tried using both PROS and Okapilib’s versions of calculating velocity from the rotation sensor, and while I have had little trouble using the functions, I do not know what unit the numbers returned by the function are in.

According to the PROS documentation, the get_velocity() function returns the angular velocity in centidegrees per second. That means that to get rotations per second, I should divide the output of the get_velocity function by 36000. When I lay out my entire velocity calculation like this:

double vel = -(Right_Encoder.get_velocity()/36000*2.75*M_PI/39.37);

I get a number way too small to be true. Changing 36000 to 360 works better, but I am not sure if it is completely accurate. When using the Okapilib implementation, which calculated velocity in degrees per second according to the documentation, it also gave wrong numbers, but completely different than the PROS implementation. I was curious if anyone else had tried using a rotation sensor to calculate velocity or knew what unit it actually returned. Do I have some other problem I have not thought about?

I think you may be mixing units and/or converting something wrong.

First, let’s figure out how many revolutions it takes the wheel to travel 1 meter. I’m assuming you’re using a 2.75" omni from the formula you posted. We must convert the inches to meters.

I am getting like 0.0005 (not completely sure about the zeroes, it may be 0.005). If it was around 1 m/s I would be happy because my robot’s theoretical top speed is 1.29 m/s.

Edit: would making my rotations sensor definition static in a header file do anything to mess up the function output?

My original code divides by 36000 so I’m pretty sure it does the same thing. If it was multiplying the rotation velocity by 7000, it would show something a lot larger than 0.005.

Ok so some results now. When driving the robot at about 1 meter per second (measured by motor encoders, so realistically 0.8-1.2 m/s), get_velocity returns 1624. With the calculations posted above, it returns about 0.009. My conversion factor would probably have to be around 1600, but I need to know exactly what it would be (and also why it is not centidegrees per second, like the docs say).

It’s possible the units PROS returns are ticks/second, where ticks are based on the cartridge in the motor. The documentation clearly states that it should be in RPM, though:

and the previous function’s comments say:

The commanded motor velocity from +-100, +-200, or +-600

So the fact you see a value of 1624 (assuming from this function and not from Okapi) indicates the comments are incorrect.

EDIT: Okapi comments also indicate the intended return value is in RPM:

My guess would be Okapi relies on the PROS return value, and it may be that PROS is returning ticks/time (either seconds or minutes, unclear) rather than RPM.

What color gear cartridge are you using when seeing 1624?

I am actually using the V5 Rotation sensor. The documentation says it reads in centidegrees per second, which does not work. I constructed an okapilib version of the rotation sensor (supposed to be degrees per sec) and the velocity function did not work as well. The function outputted 16 at max velocity, which is far too slow to work.

The motor velocity functions work well, and I am using them. However, I want to use the rotation sensor for more accurate velocity because I know that there is play in our wheels and that we cannot take the time to fix the play very soon.