0

I have a DC motor attached to a robot car wheel which can give me the PWM data as the motor is linked with the TB6612FNG H-bridge, but there is no other sensor to measure the RPM of the wheel. The problem is that I need to find out the distance traveled and also, for now, the car speed is slowly build-up so the PWM data is not fixed. Is there a library on STM32F103 to convert PWM to RPM or is there a formula I can use to find out?

Zheng Xian
  • 119
  • 3
  • Knowing the input to the motor, voltage and PWM, you can **estimate** the RPM and so with time the distance traveled, but load on the motor will make the speed vary somewhat. You need to measure the RPM or distance moved directly if you want any accuracy. Even if you use an encoder on the motor shaft to measure speed exactly, slippage between wheel and ground could confound distance estimates. – Neil_UK Aug 27 '21 at 06:03
  • Is there a formula to find the RPM using the voltage and PWM? – Zheng Xian Aug 27 '21 at 06:07
  • Yes, but it's different for every motor. Read the datasheet for yours (when specified, it's usually called Kv), or measure it for yours. – Neil_UK Aug 27 '21 at 06:11
  • 1
    The RPM is very load dependent for DC motors. If you can measure the current as well, you should be able to predict the RPM much better. – winny Aug 27 '21 at 07:11
  • By having the real measurement of RPM and PWM how do I estimate/convert other values of PWM to RPM? – Zheng Xian Aug 27 '21 at 10:24
  • The motor is JGB37-520 12V which is 319RPM @12V (26Kv) – Zheng Xian Aug 27 '21 at 10:54
  • The motor's response to a given voltage and PWM will depend on the inertia (at least during acceleration / deceleration), incline, wind resistance, etc. In the same way you can't predict a car's speed just by the position of the accelerator pedal. You have to measure it by monitoring the wheel rotation speed. – Transistor Aug 31 '21 at 08:20
  • please see my answer here https://electronics.stackexchange.com/questions/473410/how-to-calculate-speed-of-dc-motor/642994#642994 – Andrey Nov 18 '22 at 19:57

1 Answers1

1

The only answer I can come up with is that there is no easy answer. You may empirically "calibrate" your system but even that depends on many aspects you probably have no way of measuring or estimating. Just to name few:

  • Motor load (Is the car driving uphill, downhill or on a flat surface?)

  • Acceleration rate

  • Friction

  • Power source (battery) voltage

You may measure the back-EMF (voltage generated by the spinning DC motor when not driven) by sampling the voltage between the PWM pulses but that is rather tricky. Your motor is driven in a bridge configuration the sampling timing (plus filtering) would have to be synchronous with the PWM frequency. Rather complex to solve.

The simplest solution by far is the one you are trying to avoid: Add a rotation sensor and measure the rotation directly. If you can ignore error when you are changing direction(?) (car moving in one direction through inertia while you are actively controlling the motor in opposite direction (braking)) you may add a simple optical through beam sensor and a flag on a shaft that would interrupt the beam. (Resolver). You certainly may use an encoder but I suspect you may not want to change your (mechanical) design too much and may be sensitive to the budget.

Martin Vana
  • 684
  • 1
  • 11
  • +1 on the idea regarding the encoder. The issue with incremental encoders is that they can be expensive. A 'poor man's' solution is to use an optical encoder obtaining a relation between the traveled distance and the rpms. I did this some time ago in a project for a coil winding machine (for inductor and transformer making) where I had to calculate the number of windings and match it to my magnet wire bobbin total length. In OP's case, the travel could be characterised in terms of both rpms and pwm values. – Daniel Melendrez Sep 19 '21 at 00:04
  • I appreciate the concerns regarding encoder cost. And I realize that the mechanical complexity related to adding an encoder to an existing design may be prohibitive. That's why I was proposing using a thru-beam sensor (single $'s cost) and adding a flag on a shaft. That way you get only two pulses per revolution (or single if you detect only one edge) but at reasonable cost and design complexity. A sample sensor may be something like: https://www.digikey.com/en/products/detail/tt-electronics-optek-technology/OPB832W55Z/1637189 – Martin Vana Sep 19 '21 at 04:56