Brushless motors, industrial servos, encoders, resolvers etc.

Several times, (during the smart pin presentation, and here, for example) questions have been asked about brushless motors and encoders. I think it's time to start a separate thread to bundle them. I think the P2 is an excellent device for motion control and drive applications. It is even powerful enough to control a whole machine so that running a single motor is just a sub-feature that can be handled by a single cog using some smart pins.

First, I'd like to set apart two different applications. All three phase motors are somewhat "brushless" but there are different types and different methods how to control them.

1. Driving fans, pumps, vehicles and so on. Here you only need velocity or torque control ("throttle") and don't care about the exact position of the rotor. There are two sub-cases:

a) Induction motors (squirrel cage) are mainly used in industrial machines. Simpler drives just apply three phase shifted sine waves with a fixed V/f ratio and hope that the motor will follow (and not stall). This is OK for fans or propellers which have little friction. Better drives examine the phase shift between voltage and current (vector control) to measure torque/load and adapt voltage and frequency accordingly. This can still be done sensorless (without encoder, resolver or hall sensors).

b) Permanent magnet or so-called "brushless DC" motors are used in model aircrafts, robots, power drills and similar devices. Because of the permanent magnets in the rotor the commutation of the windings has to fit the current rotor position exactly to generate torque. This is usually done by applying voltage (PWM) to only two of the three motor terminals and axamining the zero crossing of the third and then switching to the next winding pair in the right moment.

2. If you need exact position control and/or torque control near zero speed (for example, for a Segway like vehicle or for an industrial robot, mill or lathe) the sensorless control methods doen't work any longer. You need some sort of position sensor. For an induction motor an incremental encoder would be sufficient because the starting angle of the rotor doesn't matter. However, in applications where weight or size matters permanent motors are used because of their better power density. But now you need some absolute information about the rotor position for commutation.

a) Older or cheap chinese servo drives use hall sensors plus an incremental encoder. Hall sensors (or the equvalent emulated signals from an absolute optical encoder) provide 6 states per electrical revolution or a resolution of 60°. This is enough for a rough guess of the rotor position and can be used for startup. However, to get optimum torque and symetry a more precise position information should be acquired as soon as possible by sampling the next state transition (edge) of the hall signals or an index pulse of the incremental encoder if available. Once you have an exact snapshot of the position you can forget about the hall signals and solely use the incremental signals. The disadvantage of this method is that you need cables and connectors with many wires and pins, up to 14 for differential A/B/Z (incremental quadrature + index) and U/V/W (hall sensor) signals plus power.

b) Resolvers: these are rotating differential transformers which have a primary winding and two secondary windings. A sine or square wave of fixed amplitude and frequency (around ~10V and 10kHz) is applied to the primary winding. The secondary windings output two sine waves with identical phase but an amplitude modulated with sine and cosine of the rotor angle. The original angle can be computed with the arctan function of the relative amplitude ratio of the two secondary signals. Offset, gain and phase errors are cancelled out. Resolvers need only 6 wires and are very robust because the don't need a glass disc or other sensitive components.

c) Modern "state of the art" servo motors have absolute encoders. There are several different methods of how to achieve absolute encoding (parallel gray code, magnetic "compass-like" sensors, incremental encoders with a second nonius track to name a few) but in the end it doesn't matter how they work internally because they can be treated as a black box. They use a serial protocol to transmit the position information digitally. The big advantage is that you only need 4 wires to connect most of them (2 lines for RS485 data and 2 for power) and you don't need a complicated analogue front end as for resolvers.

Incremental encoders usually have resolutions of 500 to 5000 lines per revolutions resulting in 2000 to 20000 quadrature states per revolution. Resolvers and high end absolute encoders can reach 14 to 20 bits (up to ~1 million states) per revolution. And although nobody needs to resolve arc-seconds high resolution helps a lot getting better velocity and acceleration values.

The next questions are: do we need drivers for the P2 supporting brushless motors? What are the most common target applications? Is anybody interested at all? Are stepper motors more important?

I've already written some drivers for different types of encoders and resolvers but I think they are not of much use to anybody except me. But if there are any specific questions of how to connect any of theese sensors to the P2 I think I can help.

Comments

  • I'm certainly academically interested, but have no immediate plans to use one any longer.

  • MaW,
    Thanks you for your detailed description of types of brushless motors, and suggestion for using the P2 as a driver;
    ManAtWork wrote: »
    I think the P2 is an excellent device for motion control and drive applications. It is even powerful enough to control a whole machine so that running a single motor is just a sub-feature that can be handled by a single cog using some smart pins.

    . . . . . . .

    The next questions are: do we need drivers for the P2 supporting brushless motors? What are the most common target applications?

    Brushless motors are common and efficient and gaining popularity. I think a brushless motor driver suite for the P2 should be a core module.

    Just recently I was scoping a pottery wheel for a family member.
    As far as I could see a brushless motor would be a perfect fit for the power and speed control requirements.
    From what I could see most manufacturers used complicated single phase speed controllers - until I found a modern manufacturer who extolled the virtues of a brushless motor!

  • ManAtWork

    Nice write up
  • When talking about "brushless motors" we see a motor, that has no physical connection to the rotor. The magnetisation of the rotor is either done permanently by attaching a magnet to the rotor or the magnetic field in "induced" by creating Eddy currents (squirrel cage motor, asynchronous motor) or by the magnetic field of the stator (reluctance motor with must be salient). There are hybrid motors around combining different principles in favor of simple construction, simple control or just cheap, but they mostly lack power density or efficiency.
    That said, the motors of interest are brushless direct current motors (BLDC) and permanent magnet synchron motors (PMSM).
    The main difference between this motor types is: a BLDC-motor is driven with DC. That means: two terminals of the motor are connected in a given motor and there is a constant current driven to the motor, no matter which phase is commutated. Having 3 phases and two directions of current, there are six states the current can flow and only these six states have to be controlled what allowes simple drives with just 3 Hall sensors.
    In contrast a PMSM is an 3-Phase AC-motor just like an asynchron motor. That means: the three phases are active in every moment and voltage and current are changing continuously in an harmonic way, they are sinoidal.

    The point is: motors are like presidents: they are never perfect. A motor should create a torque proportinal to the current independent of rotor angle and speed and should create a BEMF (Back-Electro-Magnetic-Force) independent of current and angle, proportional to the speed. In reality this is not the case.
    A BLDC has to be commutated, e.g. the current has to be switched to the phases according to the rotor state. Commutation gives a dip in torque and so creates some noise. Also during one state the motor constants show a ripple.
    A PMSM needs rotor position synchronous three phase AC-current to create a constant torque and the BEMF is a 3-phase AC voltage.

    You are free to drive a BLDC motor with AC-currents, what overcomes the commutation spikes, but there will be torque ripple. In this case you need an rotor angle sensor with at least 1% in resolution. So the advantage of primitive control is lost

    Why you should a certain motor: the simple fact is: BLDC-Motors are easy to manufacture and there is real mass production. Really cheap motors are of BLDC-construction. A PMSM is mostly used for high performance applications and so they are designed carefully and not cheap. They are more sophisticated and more expensive.

    A BLDC motor runs smoother when not commutated blockwise therefore some drivers "PWM" the voltage close to the commutation point. But those are always compromises.

    Like in real life: perfect is just another word for disaster.
  • I think the easiest way to get a pottery wheel running would be a standard induction motor and a standard VFD. They are cheap, rugged and water tight. Weight and size don't matter here and the higher inertia of a heavier motor might actually help (flywheel).

    Of course, it would be possible to do this with a P2 but as soon as you need more than ~200W a power stage connected directly to mains voltage would be preferable. I don't know if those IRAM IGBT modules targeted for washing machines and air conditioners are still available.
  • Nice write up. I learned a few things too :)
  • @ManAtWork

    What are your thoughts/findings regarding motor command resolution and PID sampling rates?

    In my world, I don't experience any noticeable benefits by increasing either of the above.
  • This is a great thread. I will even move to the P2 if necessary to follow what is being discussed. I experimented with a sensorless BLDC but set it aside after a short time because I could not detect the zero-cross of the floating coil. Since that time I got a dual trace oscilloscope and I plan to pick up where I left off as soon as I'm done with current projects.
  • It is unlikely that I will need a controller for the types of electric motors you mention in your write up. I think it would be very useful to others that may need a motor controller and more importantly having a controller using the P2 chip. It brings professionalism and practical use to the P2 chip and a library of useful functions that other chip manufactures are sometimes lacking.
  • Mickster wrote: »
    What are your thoughts/findings regarding motor command resolution and PID sampling rates?

    In my world, I don't experience any noticeable benefits by increasing either of the above.
    Might need to be more specific. Increasing from what rates? If you decrease the rate I'm sure you'll find reduced performance eventually.

  • The faster the control loop runs, the smaller the control error will be and the better control quality. Imagine to have a mechanical system, that accelerates with 5 G, and ask, what can be the error in position after one control cycle? The idea behind is: you can not precisely control a system were the external forces can not be compensated by the motor forces. So if an external yerk creates an error in position, an internal yerk of same value has to compensate this one and an additional yerk has to bring the system back on track. So a motor that allows 5 G to accelerate can compensate an external force of 2,5 G. Now accept an deviation on 1µm and calculate the time scale using Newton.
  • Mickster wrote: »
    What are your thoughts/findings regarding motor command resolution and PID sampling rates?

    Well, choosing a specific sample rate is always a compromise. You can't say higher is always better. First, higher resolution and sampling rate cost money as you need more expensive encoders and a more powerful CPU. So as always with commercial projects, you should select one that fits your needs but doesn't cost more than necessary.

    But there are a few rules that have physical and not only financial reasons:

    1. Sampling rate and resolution are always connected. If your sampling rate is too high your resolution of the velocity and acceleration values actually gets worse! Velocity is calculated as derivation of position (dp/dt) and since dp is an integer number in digital systems the result suffers heavily from aliasing effects. This is actually the biggest problem for high dynamic motion control. It can get so bad that you get a series of alternating -1, 0 +1 values instead of a continous range. This is the reason why a digital drive always produces more or less grunting noises at low speeds whereas an analogue servo with tachometer benefits from a continous velocity signal.

    2. The effective frequency of the ripple currents have to be above the audible range. I'd select at least 8kHz or better 10kHz PWM frequency. With symetrical (triangle mode, not sawtooth) PWM the ripple currents have twice the PWM switching frequency because there are two conducting phases per period. Sampling rate of the current PID control loop is sensibly equal to number of conducting phases per second or equal to twice the PWM frequency, in practice 16 or 20kHz.

    3. Sample rate of the velocity and position control loop has to be much lower than that of the current control loop. If the current error has no time to settle down (at least most of it) until the next sample of the velocity loop hunting can occur. (Hunting means both control loops are "fighting" against each other with opposite phase/polarity leading to oscillation). In practice, this means that the velocity sample rate should be below 1/4 of the current sampling rate. If additional delays or dead times are present (sigma delta ADCs, filtering, communication across optocouplers...) it has to run even slower.

    4. Any mechanical resonance frequencies should be either well above the velocity control loop bandwith (don't care) or well below (can be actively dampened). This means that the connection between the motor shaft and the load has to be as stiff as possible. If there are flexible elements (belts, rubber couplings...) with resonance frequency in the range of 100 to 300Hz, for example, there has to be enough phase margin in that range to be able to dampen it. Otherwise filtering is required to avoid oscillation.

    As I said at the beginning judgement is required to select the best possible compromise. If the motor has to run smooth and silent while there are no high precision requirement (camera pod as example) you can select a low sample rate or apply heavy filtering. If you need high precision and the best possible acceleration but don't care about noise you can choose higher sample rates. My pick&place machine runs very noisy but with amazing speed, for example. If you need both, speed and smooth operation, for example to achieve a good surface quality with a milling machine, you need expensive encoders with the highest possible resolution.

    BTW, there is a big difference between command filtering (to smoothen low resolution) and feedback signal filtering (to get better velocity signal continuity with a low pass filter or to suppress resonances with a notch filter). The command filter is outside the loop and doesn't affect stability. If you have multiple axes it also has very little impact on the toolpath if the delays for all axes are equal. On the other hand feedback filtering increases dead time and requires reduced loop gain to avoid oscillation. So in general, low command resolution with filtering is harmless but feedback filtering has to be done with great care.
  • Duane Degn asked about how to read hall sensor signals as "low resolution encoder" and if it's possible to do it with smart pins.

    Probably the most straight forward solution would be to poll them with software. As there are only 6 states per electrical period (periods per revolution = number of pole pairs) this doesn't cost an extra cog if you have a loop running at several kHz, anyway, say the current PID control loop. For example a motor with 4 pole pairs running at 10kRPM would result in 10000/60*4*6=4000 state changes per second.

    The 3 signals could be decoded like this:
    pos:= lookup(uvw: 0,2,1,4,5,3)
    
    assuming that uvw is the 3 bit input pattern. The counter value can be updated by adding pos of the current state minus pos of the last state interpreted as signed modulo 6 values.

    But if you insist on using smart pins here is the solution:
    Set each of the 3 input pins (U, V, W) to quadrature counter mode. Assign the input sources as 3 groups: AB=UV, VW and WU. To get the encoder position, add all three counters and shift the result right by 1 bit.
  • evanhevanh Posts: 9,806
    edited 2020-09-10 - 08:59:54
    I'm guessing the lookup() needs an array of eight, with cases 0 and 7 as fillers.

    The smartpin solution looks very cool, if only for its ingenuity! It doesn't directly provide the needed angle for commutation though. So that leaves either still polling the sensors in software or deriving them from a known starting angle.

  • UVW pos
    001 0
    011 1
    010 2
    110 3
    100 4
    101 5
    
    000 and %111=7 are illegal codes, so I think the lookup with 6 values is just right.
  • The fillers aren't meant to be used. They're there to generalise a fast lookup.

  • Duane DegnDuane Degn Posts: 10,262
    edited 2020-09-10 - 16:32:13
    ManAtWork wrote: »
    Duane Degn asked about how to read hall sensor signals as "low resolution encoder" and if it's possible to do it with smart pins.

    I have a bunch (7) of these sensored brushless motors which I plan to use in various projects. As pointed out, these sensors have pretty low resolution but I think they could still be very useful in robotics projects.

    If I were only interested in odometry, then occasionally polling the sensors is fine. One of my interests is determining speed as a robot or skateboard begins to move. I'd like to achieve very smooth acceleration from a stop. I think measuring the time between transition states will be important to achieve this smooth acceleration. I'm not sure how tightly the polling will need to occur in order to measure these time intervals precisely. When I start writing the software to do this, I'll likely ask for feedback from the forum.

    In case anyone reading isn't aware, sensored brushless motors are often used with a reduction belts and pulleys (or gears). These reduction mechanisms increase the accuracy of the encoders (per wheel revolution) until they're comparable to other (low resolution) robot encoders.

    Thank you @ManAtWork for all the information you've provided in the thread.


  • That addition of UV VW and WU signals is genius MaW. I thought it would cancel out to zero, but I wrote out a few rotations and it doesn't. Amazing

    The summary at the top is super useful, thanks

    One thing I would like to do with the P2 is build an 'impedance matched' mini motor. The hope is that position could be inductively sensed from the coils that aren't being driven, but we'll see. Some months ago I gave a prototype wound pole to my transformer manufacturer and asked for a quote on getting a bunch of them wound up. I said it wasn't urgent, which was probably a mistake, because I haven't received a price. Its an area of interest for me, did a fair bit of finite element modelling of motors a few decades back


  • Duane Degn wrote: »
    One of my interests is determining speed as a robot or skateboard begins to move. I'd like to achieve very smooth acceleration from a stop. I think measuring the time between transition states will be important to achieve this smooth acceleration. I'm not sure how tightly the polling will need to occur in order to measure these time intervals precisely.

    The smart pins only count states. There are also speed and time measurement modes but I found out that they are not very useful for motion control. They are intended for single edge to edge measurement (ping sensors) or frequency counters. For motion control velocity can be zero (timeout) or reverse direction and the smart pin modes do not handle that very well.

    I think it would be better to generate pin-change events with SETPAT and trigger an interrupt for each state change. A very short ISR can then read the counters and the absolute time and store position+timestamp pairs in a buffer or mailbox.

    If you read that values with a much slower software loop (~100Hz) you can calculate velocity as position delta divided by timestamp delta since the last iteration. This should give a relative good resolution as long as there are enough state changes. Near zero speed it won't work very well.
  • Duane DegnDuane Degn Posts: 10,262
    edited 2020-09-11 - 15:37:08
    ManAtWork wrote: »
    I think it would be better to generate pin-change events with SETPAT and trigger an interrupt for each state change. A very short ISR can then read the counters and the absolute time and store position+timestamp pairs in a buffer or mailbox.

    If you read that values with a much slower software loop (~100Hz) you can calculate velocity as position delta divided by timestamp delta since the last iteration. This should give a relative good resolution as long as there are enough state changes. Near zero speed it won't work very well.

    I'll try to implement these suggestions. Thank you.



Sign In or Register to comment.