Not this kind of driving!
image source
CSC 297 Robot Construction: Driving Motors
Not this kind of driving!
image source
Poorly driven motors
image source
I often get asked "What motors should I use for my robot?" I sometimes respond that the question ought to be "how should I control the motors in my robot?" Even so, it's a bit like asking "What clothes should I wear?" The answer depends on what you want do, where, how well, how attractively, and how often, what sort of computer brain you have, what design and fabrication skills you possess, how much effort you are willing to expend, and how much money you have available. When you are new, or even not so new, to robot construction, the range of possibilities and attendant complexities seem bewildering. It is hard to know where to start.
In fact, the subject is complex, and to build anything but very simple robots, some complexity must be dealt with. But not necessarily all of it all at once. This segment tries to provide a gentle introduction to the underlying issues along with pointers to additional resources and some practical information about specific, commonly used hardware. Even so, it goes messy a bit fast for my liking. Well, got to start somewhere...
A bare electric motor is basically two inert hunks of interlaced copper wire, iron, and sometimes permanent magnets: a rotor and a stator, with a bearing between them. For simple motors, connecting the appropriate AC or DC power source across a pair of wires will make the rotor spin. Putting an electrical switch in a wire enables a person to summon vast power with the flick of a finger. This is useful for power machinery and other cool appliances. But robots have no human to flick a switch every time they move. And many motors used in robots will do nothing except maybe burn up if you connect a power source to their wires. More is needed than metal hunks and electricity.
Quite a bit more, as it turns out. The electronic stuff lying between a metal muscle and the digital brain of a robot is called the motor driver, and is the subject of this segment.
The terms "motor controller" and "motor driver" are sometimes used
interchangeably to refer to low- and intermediate-level electronic
modules lying between high-level control processors and the
interlacings of iron, copper, and other materials that constitute
physical motors.
We will reserve the term driver for circuitry that
provides primary electrical power to a motor.
We will use controller more generically for modular circuitry that
provides various levels of abstraction and smarts that facilitate
control of motors by higher level processors.
A driver may contain a controller, and a controller may be a driver,
but we will not use the term driver for a controller that puts out
only low-power signals.
Before a driver can be selected, you need to know something about the power and current requirements of your motor, which in turn, depends on the requirements of the task. Motor characterization and selection can be a complex issue, but there are a few rules of thumb that will get you a long ways. These can be summarized as follows: Don't ever plan to operate a motor anywhere near its maximum torque or power more than momentarily. Numerically, it's a good idea to keep normal operating forces below 25% of maximum values.
In a bit more detail, the following first-order model is useful for understanding the major issues. The model applies directly only to DC motors, but some of the power principles apply to other designs as well.
A stalled motor has maximum torque, but no movement, and hence does no work. A free-running motor has maximum velocity, but exerts no torque, and so also does no work. It is natural to ask at which point a motor does the most work (outputs maximum power). This turns out to be when it is loaded so it turns at 1/2 the max rpm at that voltage. But you don't want to run it there.
To see why, let ωf be the fraction of
the free-running velocity at which a loaded motor is turning
(a value between 0 and 1, or 0% and 100%).
It is easily shown that the current passing through the motor is given by
I = Imax ( 1 - ωf ).
The motor output power is given by the back-emf across it
times the current.
Pm = Vrev I
= V ωf Imax ( 1 - ωf )
= Pstall ( ωf - ωf2).
The value Pstall is the resistive power dissipated as heat
in the motor coils when the motor is stalled.
The above formula has a maximum at ωf = 1/2, and the output work at that point is 1/4 the resistive stall power. However, there is an additional 1/4 Pstall dissipated in the coils, which means the motor is operating at a maximum of 50% mechanical efficiency (before friction and other losses) which is not very good for a motor.
The current is 1/2 the stall value. This can be hard on drivers, which are generally better at delivering power at high voltage and low current than vice-versa, due to (relatively) fixed voltage drops across power transistors.
Motor performance under the linear model at various rotational velocities is summarized in the following table. Rotation is percent of free-running velocity, powers are percent of maximum motor output, and current/torque is percent of stall current/torque.
| Rotation | Motor power | Dissipated power | Total power | Current/torque |
| 00% | 00% | 400% | 400% | 100% |
| 10% | 36% | 324% | 360% | 90% |
| 25% | 75% | 225% | 300% | 75% |
| 50% | 100% | 100% | 200% | 50% |
| 75% | 75% | 25% | 100% | 25% |
| 90% | 36% | 04% | 40% | 10% |
| 100% | 00% | 00% | 00% | 00% |
1.0 MW: Needs a custom driver
image source
Twenty years ago, if you wanted to control a motor from a computer, you had two choices: you could either build a driver yourself from discrete components (power transistors, resistors, capacitors etc., along with op-amps and logic chips); or you could purchase a solution from an industrial automation company (usually you'd get the motors and drivers as a package along with propriatary digital hardware and software). The first approach requires a LOT of low-level electronic design skill, board fabrication, soldering, and so forth. The second tends to be very expensive, relatively high-power, hard to modify, and to lock you into a particular vendor's product line.
Since then, two market changes have made life easier for the amateur robot constructor. The first is the development of a large number of low-power, low-cost single-chip integrated circuits with published interfaces for controlling and/or driving various sorts of motors. This market was essentially driven by the explosion of computer-controlled consumer devices with numerous motors, including VCRs, DVDs, digital cameras, and automotive AC and engine control systems. The product engineers simply needed small, inexpensive, standardized driver components to work with.
The second is the emergence of a robot-hobbyist market with low-cost and easily usable components all the way from microcontrollers to wheels and legs. This was spurred by the increasing popularity of robot-building educational programs, and by competitions such as robo-soccer and battle-bots. The first hobby components widely used in robots were the simple, lightweight servos originally developed for RC aircraft and vehicle enthusiasts. These servos, along with their simple control protocol are still very useful for the budding constructor, but there is now much more available, including fairly high-power systems used by battle-botters.
So you can still build your own driver or go pro, but both will cost you:
the first in design and construction effort;
the second in cold, hard cash, plus dealing with a marketing model
that is aimed at industrial automation professionals,
and is often opaque and difficult for the individual constructor to access.
So given that a driver sits between a computer and a motor, how does a comuter talk to a motor driver? Existing solutions tend to fall into two basic classes: simple, where the input is effectively a few digital bits and/or one analog value, the output is similarly constrained, and the driver is stateless as far as the user in concerned; and complicated, where essentially arbitrary amounts of command and state information can be transferred to and from the driver via serial communication protocols.
Simple, stateless implementations are relatively easy to use. They typically need little or no micro-controller support software, and can even be effectively accessed with discrete digital or analog circuitry. Typically the master system provides a few bits and/or one analog value to describe what it wants the motor to do.
Individual bits usually encode commands like on/off, forward/reverse. Three bits can be used to select one of 8 preset speeds. Some simple stepper controllers move the motor one step whenever the step bit goes from high to low (or vice versa).
Analog values are usually used to specify motor position, motor speed, or motor current, voltage or torque. There are three common ways of direct encoding an analog value.
The first method is to use an actual analog voltage input in some range. (e.g., 0V-5V, 0V-Rail). This can come from an microcontroller analog out, a D/A converter, a sensor circuit output, or even a manually operated potentiometer.
The second method, known as direct PWM (Pulse Width Modulation) uses a rapidly pulsed digital signal, usually at fixed frequency, where the pulse width can be varied. The fraction of the period that the pulse is high, known as the duty cycle, represents an analog value. The duty cycle times the peak voltage is exactly the time-averaged mean of the signal, which makes low-pass filtering an easy way to convert PWM to analog voltage. Direct PWM typically uses high frequency, 1kHz-1MHz, and is often chosen to be ultrasonic, 20KHz+ to avoid audible buzz. PWM signals can be generated directly by a timed loop in a microcontroller, but this consumes lots of general-purpose cycles and is poor practice. Many microcontrollers have special PWM-out ports that offload this task from the the main processor. There are PWM generation chips with serial interfaces, and also higher-level motor controllers that output PWM as a signal for a lower-level driver.
The third method is hobby RC PWM. This is a particular, simple coding developed for hobby radio-control models, which originally used analog, discrete-component circuits. In this protocol the length of a 1.0 ms - 2.0 ms pulse repeated at approximately 50Hz encodes an analog value in some fixed range with 1.5 ms being the center of the range, 1.0 ms the low end, and 2.0 ms the high end. In RC modeling, ranges are usually servo positions or motor velocities of standard RC components, which come integrated with the electronics that interpret the signal and drive the motor. The protocol could, however, be used to transmit an analog value for any purpose. RC PWM can be reasonably generated by a microcontroller program since the pulse frequency is low and the inter-pulse timing is not crucial. There are multi-RCservo controllers available that communicate with a microcontroller via a higher-level protocol to take the load of discrete pulse generation off of the high-level controller.
If a driver is to implement more complex behavior than can specified by a few bits and analog values, a more sophisticated communication system is needed. The standard method of doing this is to transmit a time sequence of digital signals, which allows an arbitrary amount of information to be transferred. The simplest example is a two-level binary signal over a single line. Such sequential communication arrangements are called serial protocols, and are universally used for communication between digital devices. They essentially require a digital state machine on each end to handle encoding and decoding. In modern practice, the state machine in even the simplest serial-capable devices is usually a general purpose processor running ROM, firmware, or software programs.
Serial communication is dramatically enabling for motor driver/controllers in two ways. First, commands of arbitrary complexity can be issued, for example, "go to position x at speed y with max acceleration z", or "hold position x with restoring force y subject to damping z". Second, significant state can be downloaded to the controller to modify its behavior - that is, it can be a programmable device.
The cost of all this is implementing and using a serial protocol. There are a great many of these, and both parties must use the same protocol or chaos results. Implementation of serial communication usually involves both software run on the processors at either end, and special hardware to handle low-level signal processing and synchronization efficiently. A protocol generally specifies both electrical characteristics of the signal transmission medium, and something about signaling, synchronization, and sometimes data encoding.
Because the electrical bases may differ, some protocols are hardware incompatible. And because the signal-processing hardware may differ, certain protocols may be signal incompatible. Software "bit-banging", where lines are monitored for changes in a fast program loop can sometimes substitute for special-purpose signal processing hardware, but this is extremely wasteful of general-purpose cycles, and works only if the processor clock is many times faster than the data transmission rate. On the other hand, there are protocol "families" that can run over the same hardware, and require only some initial negotiation between the communicating parties to set parameters.
Almost all general-purpose micro-controllers incorporate one or more hardware-facilitated serial ports, and have available low-level firmware or software for making use of them.
Serial protocols themselves can be roughly divided into "simple" and "advanced" systems. The simple ones (e.g. TTL, I2C) typically have only a single, binary line (per direction), and limited handshaking and negotiation. Advanced ones (e.g. USB, Ethernet) may involve multiple signal lines (busses), non-binary signal levels, dynamic negotiation for resources, and other complexities.
There are a variety of these. Communication is sent as a timed series of high/low levels representing bits over a single line. Additional wires are sometimes used for power, clock signals, and various flag conditions. They typically need protocol-specific software in the microcontroller, and frequently hardware as well. The basic rules are usually fairly simple, but software that handles all the possible error conditions that can arise in a graceful, recoverable manner is quite tricky to write. Fortunately, library functions are usually available.
Some of the slower serial protocols can be implemented raw in a microcontroller with program-accessible digital outputs via "bit-banging" loops, (e.g. Arduino SoftwareSerial library), but this is enormously wasteful of processor cycles. It's better to have a microcontroller with integrated hardware support (e.g. a UART - Universal Asynchronous Receiver Transmitter). for serial send and receive. Older protocols such as RS232 and RS485 need special hardware anyway, since they use higher voltages than are available at standard digital outputs.
The following are some commonly encountered simple serial protocols.
USB and Ethernet are well-known examples of advanced serial protocols. They are, fast communication/hardware standards designed for multiple devices on the same bus. They are quite complicated (i.e., don't even think of trying try to bit-bang them). Advanced motor controllers, especially programmable ones that need lots of program data, often have USB or ethernet ports. The microcontroller or computer employing such a device must also be so equipped. Software for communicating with specific devices is sometimes specialized and must be obtained from the device manufacturer. Frequently the low-level instruction set for programmable peripherals is not published, and the only way to use them is with the manufacturer's software. Which may not exist for the system of your choice. Some devices have been "reverse engineered" by various interested parties. Such unsanctioned software should be used with caution of course. Always consider the source.
Serial protocols were originally distinct from busses, which use multiple, parallel wires to transmit data faster by using larger chunks (still in serial fashion). As serial protocols have themselves gone multi-wire, and advanced communication techniques have reduced the number of parallel bus wires, and in particular, the use of classic "ribbon cables" which have interference and other issues at high speeds, the line has blurred. We include here some classic busses that have been used to connect (mostly industrial) automation peripherals.
Some common advanced protocols are listed below.
Motors in robots are often activated with more finesse than an on-off switch. But let's start there. Robots differ from simple power machinery in operating under internal adaptive control. These days, the "brains" required for such control are usually provided by digital electronic processors - basically, computers.
So how does a computer flip a switch? It seems it should be easy, since computers contain millions of switch-like elements. However, these "switches" do not direct enough power to run a motor and are not directly accessible from the outside world. In fact, connecting one of them to anything external would compromise the function of the computer.
To allow computers to affect the outside world, designers provide them with special "high-power" switches, known as digital outputs. In the simplest case, the computer logic can dynamically set these to one of two voltages, referred to as digital high and low. Computer systems known as microcontrollers, intended for use in automation and robotics, may have several dozen such outputs.
Ordinary consumer computers are trickier to use. They usually do not have simple, program-accessible digital outputs, but only more specialized channels over which a computer "sub-brain" talks to another computer sub-brain using complex digital languages known as communication protocols. Using a consumer computer as the brains of a robot requires connecting special hardware peripherals, often microcontrollers themselves, and installing software that allows the central computer to control these intermediate devices.
But let's return to computer/controllers that do have program-accessible digital outputs. Unfortunately, the term "high power" used above is a relative term. Microcontroller digital outputs cannot run a motor. Many of them cannot even light a small LED. Unless otherwise specified, the robot constructor should assume that digital outputs will not provide more than about 1 milliamp at the specified voltage. This won't even run a modest mechanical relay.
What is needed is a low-input-power electronic switch. Which sounds like a transistor. In fact, transistors make adequate switches for some applications. They usually need a bit of circuitry around them to maintain correct bias, and some more to prevent them feeding power back into the computer brain and frying it if a user connects something the wrong way.
Motors, however, are beasts. Real beasts. They are extreme inductive loads. Electric currents cannot be started in them quickly, and they can produce destructively high voltage spikes if they are suddenly disconnected. They can also act as generators, able to dump significant power into a system as they transform mechanical energy back into electrical energy. The rotational energy of a spinning motor can easily exceed anything that can be absorbed by a reasonably-sized capacitor. Preventing a motor from destroying the electronics it is connected to requires special protective circuitry.
Luckily, since switching motors on and off is a common operation,
clever folk have designed and packaged for sale integrated circuits
that hide a lot of the utilitarian complexity.
Such circuits, often generically called
H-bridges
function as digitally controlled DC power switches.
Connected to a microcontroller on one end and a motor on the other
they can implement a simple motor driver.
Strictly speaking, an H-bridge is an electrically-controlled, current-reversing DC power switch. It is functionally equivalent to a double-pole, double-throw switch used to swap the connectivity of a pair of wires. Technically, it need not be electronic -- an H-bridge could be implemented with relays -- but we are primarily interested in electronic versions.
Low power H-bridges, up to a couple of amps and a few tens of volts, are available as single-chip units. A typical example is the STMicroelectronics L298 dual H-bridge (2A, 46V, 25KHz, $5-$7 Mouser). A large variety of similar ICs is available. Some of these chips require external power components, generally capacitors, diodes and resistors, to absorb and dissipate energy and protect the circuit from inductive, generative, and stalled/short-circuit motor conditions.
The most common control interface is a pair of digital inputs that select forward, reverse, coast and brake modes for the motor, and an "enable" logic input that allows power to be switched on and off. The enable is often switchable at a very high rate to permit something called PWM control, which we will discuss in a bit. Forward and reverse are self-explanatory. Coast and brake are unpowered motor modes. In coast, the leads are open; in brake, they are shorted together so the emf generated by the rotating motor produces an energy-dissipating current through the switch and coils.
Chips usually have additional outputs for signalling fault conditions such as over-heating or over-current, and may have current-sense pins that can be used to obtain information about the current through the motor. Chips intended primarily for driving steppers or brushless DC have additional internal logic and I/O pins, but can often be used in simple H-bridge mode for driving brushed motors. High-power chips may have multiple power-in and output pins to distribute the electrical and thermal loads. In high-power situations, correct soldering of pins to heat-sinking leads is of critical importance.
Another common switch circuit, referred to as a half-H-bridge, (or half-H or half-bridge) is fuctionally equivalent to a double-pole, single-throw switch (aka a three-way switch). An H-bridge can be built from two half-bridges wired together correctly. Since half-bridges are useful in themselves for various applications, many motor driver switch circuits actually consist of several half-bridges on the same chip or board, giving the user flexibility to configure a variety of drive systems. A widely used single-chip example is the Texas Instruments L293 series quadruple, half-H driver (1A, 36V, 100KHz? $4 Mouser)
The most obvious use of an H-bridge is driving a reversable, DC brush motor. In conjunction with an enable switch, usually built into the circuit, an H-bridge allows a pair of digital outputs to turn the motor on and off and control its direction. Generally one input to the circuit (the enable) turns the power on and off, and the other sets the direction of rotation.
A pair of H-bridges, or four half-bridges, can be used to control a two-pole stepper motor in single-step mode. With this scheme, it is possible to command non-cannonical configurations of a stepper, which could possibly damage the motor or controller. It is up to the micro-controller logic to avoid commanding problematic settings; consequently, a program bug could cause hardware damage. Discrete logic hardware, inserted between the controller and the driver can be used to eliminate such possibilities.
Just choosing off, forward, or reverse for a motor on an action timescale is a rather crude method of control, and not adequate for any but the simplest robots. A more refined interface would be to control the voltage across the motor more precisely than just choosing max or off. A motor free-running or under fixed load tends to develop a final velocity proportional to the applied voltage. Similarly, a motor running at fixed speed tends to develop torque proportional to the applied voltage. Thus voltage seems like a usable handle on motor behavior.
There are single-chip circuits called digital-to-analog converters or DACs put out an analog voltage proportional to a numeric value coded in a set of digital inputs. Standard 8- or 12-bit binary integer codes are a common example. Many microcontrollers come with built-in analog outputs. DAC output is typically low-power, but if fed into a suitable amplifier, can provide a voltage-controlled power source capable of driving a motor.
The main difficulty is that general-purpose amplifiers are often poorly suited for driving motors which, as noted above, are heavy inductive loads, can generate sustained back-power, may produce voltage spikes due to commutation, need to be reversed, and have numerous other ideosyncracies. The amp needs to be designed for motors.
There are a couple of methods by which basic H-bridge switches are commonly adapted to implement voltage control.
A simple approach, found on some inexpensive, single-chip brushed-motor drivers, is to combine an H-bridge with simple transistor amplifier circuits whose output is governed by a reference voltage input pin. The H-bridge thus behaves as a variable-gain switch rather than just a switch. Such chips are usually low-power and may have a low switching rate. An example is the Rohm BA62xy series, which can provide 2A and up to 24V. It is possible to implement speed control for a brushed DC motor by controlling the reference voltage. This approach is poorly suited for higher-power applications because simple transistor amplifiers generate considerable waste heat when operating in middle ranges between full-on and full-off.
If an H-bridge supports rapid on-off switching, (usually 20KHz and above) a more general and energy-efficient technique known as pulse-width modulation (PWM) can be used to achieve effects equivalent to direct voltage control. The basic idea is to turn the power switch on and off very fast, avoiding the wasteful middle range of simple transistor amplifiers. If done quickly enough, the motor behaves as if a voltage equal to the overall average were being applied. For periodic on-off pulses, this average is equal to the output voltage times the fraction of the period the switch is on, a quantity known as the duty cycle.
The PWM approach works particularly well with motors where the inductive nature of the load can be used to advantage. The torque produced by a motor is, to a first approximation, proportional to the current running through the coils. Because suddenly interrupting the current flowing in an inductor can produce extremely high voltages, fast-switch motor driver circuits are usually equipped with "free-wheel" diodes that allow current to continue to circulate after an applied voltage is removed. This prevents overvoltage damage to circuit components. An effect of this is that applying a voltage pulse to the motor just gives a little kick to the current flowing in the coils, rather than producing a surge. The torque produced by a sufficiently fast train of pulses is thus relatively smooth rather than oscillating quickly as might be naively expected.
Many H-bridge drivers support PWM control. In such drivers, the "power on" pin is often labeled PWM rather than "enable". The L293 and L298 chips mentioned above can both be driven with inaudible (> 20 KHz) PWM signals. A slightly higher-performance single-chip example is the Texas Instruments LMD18200. The chip is rated 55V, 3A, 500KHz, and retails for around $16. The V-A rating would imply potential output power on the order of 150W, however single chips run at high amperage tend to overheat quickly. How quickly depends on how well the chip is heat-sunk. In casual use, it would probably be wise to limit continuous output current to one amp or so.
Drivers intended for PWM control sometimes contain an internal
PWM generator that can be connected to an analog reference input.
This provides effective switched amplifier functionality without
using lossy transistor amplifier circuits.
An example is the
ON Semiconductor STK681 Series.
PWM-capable H-bridges, one per motor phase, can be used as the driver back end for almost any control strategy on any motor. The common factor is the extremely high switching rate employed, typically tens of KHz to a few MHz. Generating these pulses usually involves special-purpose hardware. Tasking a microcontroller to explicitly generate PWM pulses using serial program timing is poor use of processor resources and difficult to implement for multiple motors. Generally speaking, direct PWM should be used only if the microcontroller has special hardware for PWM signal generation (luckily, many do). There are special PWM chips that can be used if your microcontroller does not have on-board generators. Motor drivers more sophisticated than H-bridges usually employ PWM control at some stage.
From an application standpoint, important H-bridge parameters are: the maximum output current, the drive voltage the circuit can sustain, and the maximum PWM switching rate it supports. The following tables list some commonly-available, H-bridge drivers together with associated parameters, a source distributor, and approximate cost.
There are hundreds of these, used to run the digitally-controlled motors that have crept into thousands of consumer products in the last two decades, from toasters to digital cameras. The following list contains a few of the most commonly employed.
Many modern chips are surface-mount packages, which can be difficult to solder into your robot by hand. Fortunately, carrier and development boards are often available at reasonable cost. These may simply provide access to chip pin-outs, or they may include peripheral protective components recommended by the manufacturer. Some of these boards are also included in the list.
Single-chip drivers with simple controllers are available with outputs up to about 30V and a few amps. Maximum sustained output power is typically a few tens of watts. To drive higher power motors, control circuitry must be connected to heat-sunk power transistors, and special circuitry for absorbing large power surges from overrunning and back-driven motors. Such assemblies can be purchased as prebuilt units, which is usually a good idea, since the design of a good discrete-component power amplifier is a significant engineering challenge.
In higher power applications it is common to use separate controller and driver modules. The controller performs control computations based on host processor inputs and motor-state feedback, and outputs low-power analog, PWM, or digitally encoded numeric signals. These go into a power amp or power H-bridge module attached to the motor.
You can buy controller chips designed to directly drive high-power MOSFETs if you want to build your own power boards. This reduces the design load, but you still need to put in all the power protection circuitry. This include free-wheel diodes, filter and surge capacitors, current sense power resistors, etc. etc. Probably better to pay for the board unless you really like soldering.
Even single-chip drivers usually require some added external components. The most important is often a large capacitor on the supply side to prevent rapid power switching from producing large voltage swings in the supply line. Low-ohm current-sense resistors and additional filter capacitors are also common additions.
A number of board-level H-bridge circuits have been produced for the hobby market, and to a lesser extent, for embedded control developers. Some of these are just carriers or development boards for popular single-chip circuits, sometimes with recommended external components and heat sinks incorporated. Others are higher power, built either by ganging several single-chip circuits together, or from discrete power components. Pricing tends to be proportional to output power. Single-chip boards can be had for under $10, while high-power units can cost several $100s. Brand names include Vantec, 4QD, RoboteQ, Robot Power, IBC, Robot Solutions, RoboClaw, Sabertooth, Syren, Scorpion, Polulu, and RageBridge. Some examples are listed below.
As noted above, PWM-capable H-bridges with appropriate program control logic, can be used to drive practically any type of motor. However, your main microcontroller may not be the best place for all the control logic to be executed. Just as direct PWM pulse generation would put heavy demands on a microcontroller, other motor-control operations that require rapid, high precision timing can also impose a heavy program burden. A case in point is the coil commutation required to drive brushless DC and stepper motors.
In a brushed DC motor, commutation (switching of current between different coils) is performed mechanically inside the motor. For brushless and stepper motors, the switching is performed externally, usually by electronic circuits. The commutation system must decide which coils to energize and at what time to obtain efficient motor performance. These decisions often require information about the current position and velocity of the motor and must be performed many times per motor rotation. Having to make high-frequency time-critical computations can interfere seriously with higher-level control operations that a microcontroller needs to perform. Consequently, this work is usually offloaded onto simpler, special-purpose control circuitry.
Brushless DC motors work by having several sets of armature coils that,
when activated in sequence, pull and push a rotor, usually made with
permanent magnets, so that it rotates in the desired direction.
The switching is arranged so that whatever position the rotor is in, the
appropriate electromagnets just ahead and behind each permanent magnet pole
are activated to pull or push as needed.
Doing this requires information about the position of the rotor.
This is often provided by shaft encoders, commonly
Hall effect sensors.
Position and velocity information can also be obtained by observing the
induced emf in the undriven phases. This requires slightly more
sophisticated computation, but reduces the wire-count going to the motor.
Brushless motors are most commonly designed with three sets of coils
or "phases".
Three-phase brushless motor controllers are special-purpose circuits
designed to do the necessary computation and switching.
Some are drivers on their own;
others need to be attached to power transistors with appropriate
protective circuitry, or to H-bridges.
From the user standpoint, they have three sets of outputs, one for
each coil or phase, often three sets of sense ports to which the
hall-effect encoders built into the motor are connected,
and control inputs for direction and PWM or reference-voltage signals.
Minimal drivers using phase sensing may have only 3 or 4 wires going
to the motor.
The beauty of this setup is, that with the controller handling all
the position-dependent commutation, the device looks and acts to
the user like a brushed DC motor with only one input to control.
This reduction is the source of the name "brushless DC motor".
Brushless motor drivers are characterized by the number of phases (usually 3),
the maximum current they can put out, and the maximum output voltage they can
handle.
It is important to make sure your driver matches your motor.
Most have some sort of thermal overload protection, but you don't
want that kicking in while your robot is attempting a coordinated motion.
The easiest-to-use brushless DC motors are ones designed
for RC vehicles.
The hobby industry produces a large variety of brushless motors and
Electronic Speed Controllers (ESCs) for them, some with
current ratings of 60 amps or more.
One end of the ESC connects to the motor with three power wires.
Exchanging any pair of the power wires reverses the direction of the motor.
On the other end is a 2-wire power input that connects directly to a battery,
and a standard 3-wire RC controller input.
The RC standard PWM sets the speed of the motor.
Only the ground (black) and the control (yellow/orange) wire need to be
connected.
The power (red) wire is sometimes connected to a "battery eliminator circuit"
(BEC) in the ESC, which provides enough 5V power to run a couple of standard
servos without needing a separate servo power supply.
On non-BEC-equipped ESCs, this wire may carry motor-battery voltage, which
could fry delicate equipment, so be careful. If in doubt, leave it
unconnected.
ESCs typically need to be "armed" before they will deliver power to
the motor. The protocol differs between makers, but usually it involves
powering the ESC and providing a "low throttle"
(but not always as low as possible) PWM signal for some period
of time (e.g. one second). Usually the ESC will beep to indicate that
the arming procedure has been completed.
Some ESCs are off-line programmable using cards that implement serial
communication over the control line.
Brands include
E-flite, eRC, Castle Creations, Electrifly, Exceed-RC, HobbyWing (EZRUN, XERUN),
Leopard, Toro, and Traxxas.
Outside of the hobby world, life starts to get complicated.
At the low-power end, there are single-chip drivers of varying
complexity, tending towards serial-interface programmable devices.
An example of a direct-control monolithic brushless motor driver is the
ON Semiconductor LB11920 10W, $7.
It provides direct PWM drive via externally generated pulses).
It also provides internal PWM with duty cycle determined by an input
analog voltage.
It can deliver 30V and transient currents up to 3.5A.
Steady-state output power is on the order of 10W.
There are also industrial board-level drives.
Many of these are very expensive, and marketed to automation professionals,
which can make them a bit inaccessible to the beginning constructor.
An example at the lower end of the range is the
Applied Motion BD series (e.g., BD5-G1-AH).
They can output 30W-300W, and cost $170-$230.
These are not direct PWM drivers, but instead provide digital selection from
7 internal presets, a manually adjustable internal POT,
or external voltage reference.
Applied Motion also supplies
matched BL series motors (e.g. BL030-H03-G)
They run 30W-300W, $100-$400.
Motors with integrated gearheads are also available.
For specs and additional information see
Applied Motion brushless DC motors and drives.
Stepper motors are electromechanically similar to brushless DC motors
in that they consist of a magnetic rotor turned by externally
commutated sets of stator coils.
Functionally, the term usually refers to applications where the motor
frequently holds stationary in one of a number of discrete positions,
and has a control mode where it is moved sequentially from one discrete
position to an adjoining one.
Such a move is referred to as a "step"; hence the name "stepper motor".
Mechanically, motors sold as steppers often have many more stable positions
per rotation than do brushless DC motors.
In contrast to "DC" motors, which are typically used in situations
where motor velocity is of primary importance,
stepper motors are often used in applications where they hold
a specified, stationary position.
They are typically rated to produce
a designated "holding" torque at a given drive current, generally
at a fairly low voltage.
For this sort of operation, a constant-current drive is easier to work with
than a constant-voltage, and drivers designed for use with stepper
are usually of this sort.
To a first approximation, a constant current will produce
the same torque independent of motor speed.
As the rotational velocity increases, the motor generates a back-emf,
and the voltage, and hence power, supplied by a constant current driver
must increase to keep the current the same.
With such a driver, and ignoring inertial loading,
a stepper can be clocked (stepped) at
any speed with good performance right up to the stall torque.
In practice, the inertia of the motor rotor and attached load
significantly limits the rate at which the motor velocity can be
changed.
If you suddenly start driving a stepper at anything above very low speeds,
it will almost always stall and miss steps.
The critical factor is the acceleration that can be produced by the
maximum torque.
Using a stepper under clocked control almost always requires that the
motor speed be carefully ramped up and down.
Stepper motors work by sequential activation of aramature coil sets.
The most common stepper configuration uses two sets of coils or "phases".
Call them A and B. Current can be sent through either coil in one of two
directions. The sequence of coil activations A+ B+ A- B-
advances the motor 4 "steps", and is repeated for further movement.
By partially activating adjacent phases, stable positions between the main
steps can be maintained.
This is known as microstepping.
As the number of microsteps increases, the graph of the partial
current vs. microstep approaches a sine wave.
In the limit the driving currents in the two phases become sinusoids
offset by 90 degrees.
This is exactly the drive needed for a synchronous induction motor.
The two devices are, in fact, electro-mechanically identical and
interchangable.
The difference is in how you want to implement control: as a series of
steps, or as an adjustable phase velocity.
In principle, you can control a stepper with a pair of H-bridges, switching
between phases as needed.
To get any semplance of good performance, you would need to implement something
similar to constant-current drive.
The simplest approach is to monitor the motor current by passing it through
a low-ohm resistor, and implement a PWM control strategy to keep the
current constant.
If you were using a microcontroller to do this, you would not want it
trying to do anything else.
Compared to DC and brushless motors, the hobby market for stepper
motors is underdeveloped.
There are a couple of low-power stepper driver boards available
(from Pololu and Easydriver), but most products are aimed at commercial
equipment manufacturers (e.g. printers) and industrial automation.
Driving a stepper motor at high accelerations and speeds and with
good efficiency turns out to be an annoyingly complex control problem.
For low-speed positioning applications you can get away with simple
solutions, but to make use of the real potential of a stepper, you
either need to develop some expertise in control theory, or
purchase a commercial control solution.
Bottom line is, using steppers is a significant step.
You may well need to solder chips and components or purchase an
industrial solution, both of which will require some device-specific
research.
If you decide to solder your own stepper driver,
the simplest integrated devices are chips designed to drive a single phase
at constant current.
An example is the
STMicroelectronics TEA3718 series.
To drive a stepper, you need two of these, and a controller for switching
them on and off in the correct sequence.
But they do the tricky constant-current control for you.
A step up are circuits that take a clock (step) signal and step the motor
for you, doing their best to move the motor to your clock signal
independent of the load on it.
Some of these implement smooth microstepping as well.
An example is the
Toshiba TB6560 series.
All you need to do with this one is send step signals.
Of course you still need to ramp-up and ramp-down the clock pulses
yourself to avoid inertial stall of the motor and other issues
If you don't want to solder and deal with chip datasheets,
you have the industrial boards with the usual cost and accessibility issues.
They're easier to use and cheaper than they once were, but you are still often
buying into vender-specific components and software.
A low-end example is the Applied Motion 834-xxxx series
70W-140W, $150-$400, (plus motors).
The drivers we have seen so far
allow us to turn motors on and off, apply constant voltage or constant
current to motor coils, and handle phasing on brushless and stepper motors.
However, motor voltage and current are usually not directly related to the
robot parameters most convenient for dealing with your application.
So generally you are committed
to dealing with at least some elementary aspects of control theory.
More on that in a bit.
However, it is possible to buy motor controllers that do more work for you.
For example, there are controllers that will apply a specified
torque to a DC motor or bring a stepper to a specified velocity without
stalling.
There are controllers that will move a motor from its
current position to a specified one at a specified speed
or in a specified amount of time (if possible), using a variety of
velocity profiles.
There are even controllers that will coordinate simultaneous motion of
several motors.
Controllers that allow a position to be specified are commonly
referred to as servomotors or servos for short.
Generally, servos are expensive, industrial automation equipment with
relatively sophisticated serial communication interfaces.
There is one exception.
RC standard servos were developed for the radio control vehicle
hobby market.
They are typically built around small, geared-down brushed DC motors,
and provide a range of motion, often 0 to 180 degrees.
They are slow, imprecise, and have limited torque.
Control is usually limited to specifying a position, with little
or no speed or timing control.
However, they have three huge advantages for the beginning robot constructor.
First, they are complete, integrated units with controller, driver, motor,
and gearing all in a compact box.
Second, they have a simple, uniform control interface, where position
is specified by a 1.0 ms - 2.0 ms digital pulse repeated at around 50 Hz.
Third, they are relatively inexpensive, with some going for under $10.
Inside, RC servos usually sense position using a potentiometer
and have a custom IC decoding the PWM input and implementing a simple
position control algorithm.
Potentiometers are an inherently inaccurate method of measuring
position, and the highly geared-down units are generally not back-drivable,
which limits controllability under load. Nevertheless, with imagination,
they are adequate for many purposes.
A lot of legged bots have been built using RC servo units.
There is a wide range of RC servos available, including some moderately
high-end and powerful units with metal gearing.
Brands include Hitec, Futaba, Robotzone eRC, Spektrum, JR.
RC servos are marketed as "standard" or "digital".
The difference is in the controlling IC, which in a standard servo is
analog electronics, and in a digital servo uses a microprocessor.
The control interface and mechanicals are all the same.
Digital servos supposedly have faster response and finer control.
RC servos aside, higher-level control generally comes at a cost.
In money of course, but also in terms of interface complexity
and application specificity.
You can drive just about any motor using PWM-capable H-bridges, even
AC ones (by using PWM to synthesize waveforms), but the computational
load on the microcontroller may be high, and the programs difficult to write.
Higher-level controllers lower this load, but are often restricted particular
motor types (steppers, brushed DC, brushless, etc.), and often require
specific types of sensors on the motors
(Hall effect, optical position encoders, inductive pickups, etc.)
Some are limited to particular makes.
Some require special software packages to use, which may run only on
on particular hosts.
At the low-cost end of things, there are monolithic motor control
chips of varying levels of sophistication.
Generally the user needs to wire protective circuitry and power
amps or H-bridges around them.
At a minimum, these controllers store several bytes of state,
and accept a variety of commands. They are effectively programmable
devices, and communicating with them involves serial protocols
that must be implemented on the host microcontroller.
Using them needs to be worth the trouble.
The full specs and control interface of more sophisticated
chips may be unpublished.
Some were developed in conjuction with equipment manufacturers
to meet an application need. Some have license-only capabilities.
Understand what you are getting and how to use it.
An example of a general-purpose controller chip is the
Texas Instruments LM628/LM629
These controllers are designed to drive DC and brushless DC motors
equipped with a quadrature position encoder.
The output goes to a power amp (628) or to an PWM-capable H-bridge (629),
so these are controllers, but not drivers in our parlance.
They can perform position and velocity PID control, and generate
trapezoidal velocity profiles for moving from one position to another.
Another example is the
Avago HCTL-1101 series
of motion controllers.
These are even more sophisticated, and can drive a variety of DC, brushless,
and stepper motors in several standard modes including PID position,
proportional velocity, and trapezoidal velocity profile.
An incremental position position encoder on the motor is required.
Output is available as PWM and digitally encoded numeric values.
These must be fed to amps or H-bridges, so again, they do not count
as drivers, just controllers.
They are designed so that several can be used in in
coordination with each other.
Beyond commodity motor controller chips, are industrial automation
control systems.
Making use of these is a profession in itself, and (for now) a bit
beyond the scope of this introduction.
If you need equipment of this sort, be prepared to do a lot of learning,
(though if you need high precision steppers or servos,
you don't have a lot of choice).
Following, just a few words.
As mentioned previously, industrial equipment tends to be high-power,
high-cost, and vender-specific.
Systems commonly bundle controller, driver, and often motor and power supply,
with a programming interface.
The latter often involves custom and proprietary software,
and may run on custom hardware as well.
This can make integrating such systems with your favorite
microcontroller (e.g. an arduino) difficult or impossible.
The underlying business model is factory automation.
Much equipment is available only through professional sales reps or
installer/distributers.
These people generally have little time to help out amateur robot builders
working on a budget of a few hundred or thousand dollars.
With enough money and enough calling or emailing around,
you can usually manage to purchase industrial equipment,
but you have to figure out what you need and how to make it work yourself.
And unlike hobby equipment, making this easy for the buyer is not
part of the game.
There are some de-facto "standards" in the industry; most of them started out
as vendor-specific interfaces, and were adopted by other manufacturers
for cross-compatibility.
For example, Modbus is a widely used serial communication protocol for
industrial electronic devices originally developed in 1979 by Modicon
(now Schneider Electric).
There are also a handful of high-level industrial control
programming languages/interfaces including
SiNet programming, Q programming, and CANopen.
There are a large number of companies involved in industrial automation.
Major players include
ABB, Applied Motion, Baldor, Bosch Rexroth, Control Techniques, Emerson,
Lenze, Moog, Mitsubishi, National Instruments, Omran, Panasonic,
Rockwell Automation, Samsung, Schneider Electric, Siemens, Yaskawa.
An (unusual for 2014) player focused on online marketing is
Automation Direct,
which is organized like a familiar online retailer, but offers
industrial-automation lines of merchandise.
Worth checking out to get a picture of what is involved in the business
if nothing else.
Exactly how to make motors move precisely how you want them to
is the subject of control theory.
It can get complicated.
However, control theory always starts with some model of what the controller
can tell the motor to do.
Three standard control modes, for which theory is well developed are:
Control algorithms (derived from control theory) are typically implemented
on digital processors - computers or microcontrollers.
As we noted previously, a digital computer cannot, by itself,
make a motor do anything.
Which is why we have motor controllers and drivers.
From the standpoint of control theory,
the job of a motor driver is to map signals that a processor/microcontroller
can put out, to a standard control model on the motor;
in other words, to provide an interface by which a computer can
either directly command the torque, speed, or position of a motor,
or set something that is functionally related to
torque, speed, or position in a way that control theory can get hold of.
Higher level controllers offer higher-level primitives such as
velocity profiles or way-pointed paths, or coordinated movement of
several, mechanically interlinked motors.
Generally they make use of lower-level control primitives to accomplish
this.
The main difficulty is that motors, as mentioned above, are beasts.
They do not directly transform electrically well specified quantities
(voltage or current) into torque or velocity.
Instead, the relationship depends on the speed of the motor
the characteristics of the applied load, and possibly other variables.
For now, recall the first-order model for a DC motor.
If the motor is running efficiently, then the back-emf
is nearly equal to the applied voltage, and the motor is running at close
to its "free-running" velocity.
If the load stays constant, then increasing the voltage increases the
speed of the motor in nearly linear fashion.
So a controllable voltage source, or the PWM equivalent
would give us a means of velocity control on a DC motor.
To a certain extent, this works.
With some top-level feedback and decent kinematic design, you can drive a
mobile robot more or less where you want it to go using voltage control
of motors on a pair of wheels.
If you need to move fast or precisely however, you need more.
The voltage/velocity relationship is approximate and asymptotic.
The high inductance of motor coils means that it takes a while for
a voltage change to translate to change in current and thus motor torque.
The inertia of the motor and the attached load means it takes a
(usually longer) while for a change in torque to translate to a change
in velocity.
If the load changes, or is velocity dependent, then even the
asymptotic relationship between voltage and velocity is non-linear.
All these delays and approximations add up.
Using naive voltage ~ velocity control to move a robot around often results
in performance that is an order of magnitude worse
(measured in time or precision) than what the motor and drive voltage
can theoretically accomplish, especially for small, precise movements.
So any decent controller tries to do better.
For example, if you want to change the speed of a motor, you don't
just raise the voltage to that corresponding to the final speed you want.
Instead, you drive the voltage hard to overcome the inductance
and inertial delays, and then back off once the motor reaches the
desired speed.
This involves measuring the motor velocity and setting voltage as some
function of the measure velcity and the desired velocity.
And when you start doing this, all sorts of other undesirable effects
start popping up, such as overshoot and oscillation.
Handling such issues in an optimal or near optimal way is the meat
and potatoes of control theory, and good methods of managing most
effects are known.
However, the control algorithms that do the job often involve
a considerable amount of non-obvious-to-the-beginner
and pain-to-implement complexity.
The faster, smoother, and more precise the task requirements,
and the more interacting components there are,
the harder the control job.
That is why it is worth paying very good money for a controller
already designed and matched to a particular motor or configuration
of motors (e.g. a robot arm).
We will conclude with a brief discussion of simple control
strategies that can be applied to (locally) linear systems.
The basic idea is that you have a system whose state can be described,
at least locally, by a real vector,
a goal position in that state space that you want
the system to be in, and a sensor that provides the current state
of the system.
The state space can be anything for which a vector-space representation makes
sense (position, velocity, force) but for this discussion,
imagine we are talking about position.
In fact, imagine we are talking about one-dimensional position.
The discussion carries over to multi-dimensional systems with
appropriate replacement of scalars with vectors and linear operators.
The difference between the current position and the desired position
is called the error.
Now suppose we can apply some action to the system that causes a change
in the derivatives of the current state.
(If we could set the state directly, we would just do that, no need for
a controller).
For example, if we want to be at position 0, and are at position 5,
then setting the velocity to -5 per second would move us towards the
goal (and get us there in 1 second).
Now we probably don't want to do exactly that since, although we didn't
mention it, what we probably wanted was for the system to be at 0
and at rest.
OK, so the goal can be more complicated than we first thought, but
let's add "at rest" for the moment.
Suppose that instead of setting the velocity to -5 and letting the
system go, we set the velocity to whatever will get us to the
goal from the current location in 1 second. So v(x) = -x (per second).
Written as a differential equation, the condition is dx(t)/dt = -x(t).
Which has general solution x(t) = A * exp(-t), and if x starts at x0,
the exact solution is x(t) = x0 * exp(-t).
So wherever the system starts, it is 1 - 1/e = 63% of the way to the goal
after one second, 86% of the way after 2 seconds, 95% of the way after
3 seconds, and so forth.
In a theoretical sense, the system never quite reaches the goal, but
for all practical purposes it get very close quite quickly.
If we want to get there faster, we set the velocity to a higher
multiple of the distance: v(x) = -ax, where the constant a is referred
to as the gain.
We can do this up to the limits of the system,
and the time scales down proportionately.
This scheme is called proportional control because the
control input is proportional to the error. With minor variations it
is widely used in situations where the derivative of the goal variable
is a controllable input.
Now suppose that instead of being able to directly control the velocity of
a motor, we can only directly control the torque (i.e. the current).
From mechanics, we know that torque on rotating system is proportional
to angular acceleration, or the second derivative of position.
Suppose we try the same scheme, and set the torque proportional to the
negative of the error (so it tends to be restoring).
We could go through the differential equation, but instead we will just
observe that this situation is the classic harmonic oscillator, whose
solution we know to be sinusoidal oscillation in time.
Well this is not so good. The system gets to the goal, but rather than
stopping, performs an undamped oscillation about the goal location.
So we do something very clever. We introduce "fake" damping.
We can do this by keeping track of the velocity of the system as well
as its location and add to the restoring torque, a counter-acting
torque that is proportional to the velocity.
As an equation, T = -ax - bv.
This is the classic damped harmonic oscillator, whose behavior is
well studied.
If we want the system to go a quickly towards the goal as possible but
not bounce, we set a and b for critical damping.
In practice, a and b are usually selected to give a slightly underdamped
system, since that actually gets to the goal (crosses it) and approaches
it faster than the critically damped case.
This scheme is called proportional derivative control
or PD control for short because the velocity
is the derivative of the error term. Variations are widely used in
situations where the controllable inputs are analogous to forces
acting on a dynamic system where the goal is a position.
A variation called proportional integral derivative or
PID control adds an integral term, which over time can cancel
an offset error due to, say, a constant external force acting on the system.
Variations of proportional, PD and PID control work very well in
many simple situations.
Their biggest problem is that if there are delays between sensing
and actuation (and there always are) then oscillations can arise
in situations where the non-delayed system is perfectly stable.
These can be undamped, or even growing.
As a rule of thumb, your are pretty safe if the characteristic
time of the system (the time it takes to get 64% of the way to the goal)
is 10 times the largest delay. A lot of systems can tolerate more delay
than that, but as delays approach the characteristic time, unstable
behavior is very likely.
Stability problems also arise in highly non-linear systems,
and in multi-dimensional systems where the effect of motors can cancel each
other out (such configurations are called singularities)
Another issue is that P/PD/ PID systems are a bit slower than they need to be,
especially when approaching the goal position.
If rapid movement to a very precise location is required, much more complex
control may be required. In some cases this may involve solving multi-variate
optimization problems subject to constraints (e.g. move from A to B
as fast as possible subject to the constraint that the maximum voltage
that can be supplied is V).
Modern digital processors make it possible to dynamically solve such
problems in some situations.
More frequently, solutions are computed offline, stored as lookup tables,
and scaled to the actual situation by relatively simple parametric
transformations, coupled with some stabilizing feedback.
Figuring out all this is tough work, but it can pay off,
another reason why matched commercial controllers are sometimes
worth the high cost.
There are entire books written about control theory - in fact, about
specific aspects of control theory. It is a large subject.
If you want to know more, the
Wikipedia article
is a reasonable starting point.
Steppers
Servos and Higher-Level Controllers
RC Servos
Motor Controller Chips
Industrial Automation Systems
Tiny Control Theory
Simple Linear Control