How to find velocity using V5 rotation sensor

Programming Support PROS Support
#1

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?

#2

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.

1m / ( 2.75" * 0.0254 * pi) = 4.557 revolutions/meter

Now that we know that, we can calculate further…

1 revolution/second = 0.219 meters/second ( 1s / 4.557rev/meter )

360 degrees/second = 0.219 meters/second

36000 centidegrees/second = 0.219 meters/second

Finally, we can calculate the conversion from cd/s to m/s.

0.219m/s / 36000 = 0.000006095628 -or- 6.095628215e-6

Multiply this conversion factor by the get_velocity value should result in a m/s output.

#3

I am pretty sure that dividing by 39.37 is the same as multiplying by 0.0254. Because there are 39.37 inches in a meter (or something like that)

#4

1/36000 * 2.75 * PI/39.37 = 0.00000609557

It looks like your answer is the exact same as theirs?

2 Likes
#5

Is this some subtle error that I am making in my calculations? Or is it a PROS thing or my rotation sensors completely messing up?

#6

Lols, didn’t look at it close enough. It should be right then!

What kind of values are you seeing? I wouldn’t expect very high values, less than 1 m/s.

1 Like
#7

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?

#8

The original formula posted is incorrect

36000 x 2.75 x M_PI / 39.37 = 7899.86

It is missing the 1/36000.

Should be

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

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.

#10

You are correct.

You should probably investigate further what values are getting output from the get_velocity call.

#11

Ok. I will do that pretty soon and give an update.

#12

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).

#13

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?

1 Like
#14

So, per https://github.com/OkapiLib/OkapiLib/blob/4cbcee923033693ddbfcc4871761f76d60230536/include/okapi/api/util/mathUtil.hpp#L68

There are 300 ticks/revolution when using the blue cartridge. This would yield:

1624 ticks/sec / 300 ticks / revolution = 5.4133 Rev/Sec
5.4133 Rev/Sec * 2.75 (inches) * PI = 46.766 inch/sec
46.766 inch/sec * 2.54 cm/inch * 1 m / 100 cm = 1.187 meters per second

Are you using blue cartridges?

1 Like
#15

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.

#16

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.