Approximate the relationship between PWM pulse width and DC motor input voltage

[miketan3904]

Hi. I have a microcontroller outputting a PWM signal with the pulse width controlled by the program in the microcontroller. This PWM signal is then fed to the ESC to control the speed of a brushless DC motor. I wish to approximate the relationship between the PWM signal pulse width and the DC motor input voltage just by using a linear equation. Does anyone has any idea on how to do this? How do I estimate/measure the DC motor input voltage at different PWM signal pulse width?

Thanks in advance. 

[tooki]

Vout = Vin * duty cycle,

where Vin is your supply voltage, duty cycle is the on time in %.


It’s that simple! (At least that’s what I just learned in school.)

[miketan3904]

Is it really that simple? I thought that the ESC has its own processing to output the voltage to the DC motor.

[tooki]

As far as the equivalence of a PWM signal to a linear voltage, yes, that’s all there is to it.

As for whether the motor speed responds linearly is a somewhat different question, since the ESC has to handle that. But assuming it’s an input designed to handle PWM or an analog voltage, then unless it’s doing something really weird, there should be no difference between feeding it a PWM at 50% duty cycle or a voltage that’s 50% of maximum.

Do you have a link to the ESC datasheet or manual?

[ve7xen]

I think PWM in this context is in the sense of servo control in hobby RC systems. In this context, it is not duty cycle, but pulse width that matters, generally varying from 1ms-2ms full scale. So 0% output is created with a 1ms pulse and 100% output with a 2ms pulse.

Brushless 'DC' motors aren't driven by DC at all, the output of the ESC will be a roughly sinusoidal shape with amplitude dependent on the control input (and possibly some transfer function of the controller). Or the PWM approximation of the same, expecting the motor's inductance to filter it.

So if you are sending 1.5ms PWM pulses (ie. 50% commanded speed) to the controller, the output to the motor should be an 'AC' signal with Vpp of approximately the battery voltage. The frequency of the output will depend on the speed of the motor.

[tooki]

Aren’t you conflating servo control with speed control??

The RC de-facto standard of 1-2ms pulses every 20ms is for servo positioning. But the OP asked about motor speed.

[ve7xen]

Aren’t you conflating servo control with speed control??

The RC de-facto standard of 1-2ms pulses every 20ms is for servo positioning. But the OP asked about motor speed.

The same standard is used for ESCs, they are the same as servos as far as the controller is concerned. So you can use any channel of your radio for ESC or a servo without having to configure anything.

[WattsThat]

The OP clearly states he’s talking about a brushless DC motor.

You supply it DC but the output of an ESC for a brushless motor is a complex PWM signal that emulates variable voltage, variable frequency multi-phase AC. The motors are in actuality three phase synchronous AC machines.

The only relationship between the input and output is that the output is proportional to the input where the output voltage and frequency is determined by the motor back-EMF constant, usually given in volts per 1000 rpm and the frequency by the motor pole count. Post a link to the parts you’re using if you want any of the above explained in actual numbers.

[AaronD]

I used to work for a hobby ESC company.  I wasn't directly involved with that specific part of it - my focus was on special commissions and "auxiliary products" like protocol converters and such - but I was close enough to get a good idea of what the ESC's were doing internally.

Without giving away too much, the "RC servo" input is simply an input.  Nothing more.  It does not control anything directly.  It's just an input to software.  That software can then do anything imaginable with it.  On the other end, that software has a number in it that controls the PWM duty cycle that is used when a motor phase is "on".

(It's actually a trapezoidal waveform, not a sinusoid, to make the code a lot easier.  Most hobby motors are wound for that too, and you can see it by spinning it externally while watching it on an oscilloscope.)

For most of our products, we had a linear input-scaling function that the user could calibrate to their specific radio gear, and then it was a simple equivalence after that.  But again, it's software, so anything is possible.

If you really want a good measurement of what the motor is actually doing, then you need to access the internal number that the software is actually using (some ESC's can give you that; most are just "black boxes" that do their primary job and nothing more), or you need to watch the motor leads on a 'scope and figure out the duty cycle from there.
But good luck with the 'scope!  Technically, it's possible - our ESC-code guy could do it - but there's so much going on that it takes a well-trained eye to sort through the mess of interactions between the motor and the controller!

[Pack34]

I used to work for a hobby ESC company.  I wasn't directly involved with that specific part of it - my focus was on special commissions and "auxiliary products" like protocol converters and such - but I was close enough to get a good idea of what the ESC's were doing internally.

Without giving away too much, the "RC servo" input is simply an input.  Nothing more.  It does not control anything directly.  It's just an input to software.  That software can then do anything imaginable with it.  On the other end, that software has a number in it that controls the PWM duty cycle that is used when a motor phase is "on".

(It's actually a trapezoidal waveform, not a sinusoid, to make the code a lot easier.  Most hobby motors are wound for that too, and you can see it by spinning it externally while watching it on an oscilloscope.)

For most of our products, we had a linear input-scaling function that the user could calibrate to their specific radio gear, and then it was a simple equivalence after that.  But again, it's software, so anything is possible.

If you really want a good measurement of what the motor is actually doing, then you need to access the internal number that the software is actually using (some ESC's can give you that; most are just "black boxes" that do their primary job and nothing more), or you need to watch the motor leads on a 'scope and figure out the duty cycle from there.
But good luck with the 'scope!  Technically, it's possible - our ESC-code guy could do it - but there's so much going on that it takes a well-trained eye to sort through the mess of interactions between the motor and the controller!

You could treat it as a black box. Just ramp the input and measure the output. Bonus points for attaching an encoder to the output shaft and repeat in loaded and unloaded conditions.

[AaronD]

As an example of anything being possible, one of the special commissions that I worked on was a super-low-speed drive.  It still had the full range that everything else did; but it also needed to go slowly while still being smooth.

After studying the existing ESC code (a lot!), I ended up writing a special mode for that super-low-speed, that it would enter and exit automatically.  Like the existing code, it was (nominally) linear, but of course the equation for that line was different.  So I also made an intermediate mode to connect the two lines.  The overall response was now continuous again, but it had two "kinks" in it where the three different lines met.  You couldn't really tell by driving it manually, which was the intended use, so as far as I know, we shipped it like that.

If you really want accurate data, that's something to keep in mind.  That sort of detail will probably not be documented to the public.  We didn't; we just said "it runs slow".