Revision history [back]

Hi stevemartin.

A potentially large source of error in this method is using ros::Time::now() to get a time stamp for the pulse/count. Since ROS is quite abstracted from the hardware, the timestamp can be off by a substantial margin and it can be random since the process load of the CPU varies.

Be that as it may, all you need to calculate RPM are the timestamps if this is called at every tick, the count difference shouldn't matter (since it is 1). That said, you could do it with the following equation.

RPM = 60*(1/(time*ticks_per_rotation))

because,

time_per_rotation = time*ticks_per_rotation
RPS = 1/time_per_rotation

Since ROS timestamps aren't incredibly accurate, a more robust way would be to measure the number of pulses in the last second and extrapolate the RPM from there. You can use a moving window filter to publish an RPM message at the same rate as the pulses (if needed). If you need a more sensitive measure, you can reduce the window time frame

Hi stevemartin.

A potentially large source of error in this method is using ros::Time::now() to get a time stamp for the pulse/count. Since ROS is quite abstracted from the hardware, the timestamp can be off by a substantial margin and it can be random since the process load of the CPU varies.varies. If the pulses per second are relatively low, it shouldn't matter too much.

Be that as it may, all you need to calculate RPM are the timestamps if this is called at every tick, the count difference shouldn't matter (since it is 1). That said, you could do it with the following equation.

RPM = 60*(1/(time*ticks_per_rotation))

because,

time_per_rotation = time*ticks_per_rotation
RPS = 1/time_per_rotation

Since ROS timestamps aren't incredibly accurate, a more robust way would be to measure the number of pulses in the last second and extrapolate the RPM from there. You can use a moving window filter to publish an RPM message at the same rate as the pulses (if needed). If you need a more sensitive measure, you can reduce the window time frame

Hi stevemartin.

A potentially large source of error in this method is using ros::Time::now() to get a time stamp for the pulse/count. Since ROS is quite abstracted from the hardware, the timestamp can be off by a substantial margin and it can be random since the process load of the CPU varies. If the pulses per second are relatively low, it shouldn't matter too much.

Be that as it may, all you need to calculate RPM are the timestamps if this is called at every tick, the count difference shouldn't matter (since it is 1). That said, you could 1).You can do it with the following equation.

RPM = 60*(1/(time*ticks_per_rotation))

because,

time_per_rotation = time*ticks_per_rotation
RPS = 1/time_per_rotation

Note, that this is the RPM of the encoder. If there is a gearbox involved you'll have to multiply it by the gearbox factor.

Since ROS timestamps aren't incredibly accurate, a more robust way would be to measure the number of pulses in the last second and extrapolate the RPM from there. You can use a moving window filter to publish an RPM message at the same rate as the pulses (if needed). If you need a more sensitive measure, you can reduce the window time frame

Hi stevemartin.

A potentially large source of error in this method is using ros::Time::now() to get a time stamp for the pulse/count. Since Rather, get the timestamp from the message and use it as 'now'. But this is still not guaranteed to be accuracy since ROS is quite abstracted from the hardware, the timestamp can be off by a substantial margin and it can be random since the process load of the CPU varies. If the pulses per second are relatively low, it shouldn't matter too much.

Be that as it may, all you need to calculate RPM are the timestamps if this is called at every tick, the count difference shouldn't matter (since it is 1).You can do it with the following equation.

RPM = 60*(1/(time*ticks_per_rotation))

because,

time_per_rotation = time*ticks_per_rotation
RPS = 1/time_per_rotation

Note, that this is the RPM of the encoder. If there is a gearbox involved you'll have to multiply it by the gearbox factor.

Since ROS timestamps aren't incredibly accurate, a more robust way would be to measure the number of pulses in the last second and extrapolate the RPM from there. You can use a moving window filter to publish an RPM message at the same rate as the pulses (if needed). If you need a more sensitive measure, you can reduce the window time frame