design of a dc motor speed controller
TRANSCRIPT
Cardiff UniversitYSCHOOL OF ENGINEERING
DC Motor Speed Control
Project Report
Philip Strong
31/3/2012
Acknowledgments
The author would like to express appreciation to the following people for their
assistance and encouragement throughout this project.
Dr M Ghassempoory Project Supervisor
School of Engineering, Cardiff University
Dr R Philp Project Moderator
School of Engineering, Cardiff University
Mr R Rogers Laboratory Technician
School of Engineering, Cardiff University
Mr R Pope Debugging help
Student, Cardiff University
Mr E Collins Parts selection and design help
Graduate, Cardiff University
License
This document is licensed under a Creative Commons
Attribution-ShareAlike 3.0 Unported License.
1
Abstract
This paper documents the design and construction of a DC motor speed controller
controlled by a computer. The requirements are defined and then the design process
explained. The final product is exhibited followed by a discussion of the success of
the project, with suggestions for how to further improve the device. The project was
successful, however a noise related bug was found with the over-current protection
feature; the report includes recommendations to overcome this.
2
Contents
Acknowledgments...................................................................................................- 1 -
License................................................................................................................... - 1 -
Abstract...................................................................................................................- 2 -
CD-ROM contents.................................................................................................. - 6 -
List of Figures......................................................................................................... - 7 -
List of Tables.......................................................................................................... - 7 -
Nomenclature......................................................................................................... - 8 -
1. Introduction...................................................................................................... - 9 -
1.1. About this report........................................................................................ - 9 -
1.2. Project aims...............................................................................................- 9 -
1.3. Requirements definition...........................................................................- 10 -
2. Background and Research.............................................................................- 12 -
2.1. Existing products and related works........................................................- 12 -
2.2. Motor driver............................................................................................. - 12 -
2.2.1. National Semiconductor LMD18200.....................................................- 13 -
2.2.2. Linear Technology LT1160...................................................................- 13 -
2.3. Control system.........................................................................................- 13 -
2.3.1. Microchip PIC.......................................................................................- 14 -
2.3.2. Arduino.................................................................................................- 14 -
3. Development.................................................................................................. - 15 -
3
3.1. Hardware design..................................................................................... - 15 -
3.1.1. High level design..................................................................................- 15 -
3.1.2. Functional description.......................................................................... - 15 -
3.1.2.1. MCU..................................................................................................- 16 -
3.1.2.2. Optoisolation.....................................................................................- 16 -
3.1.2.3. Comparator.......................................................................................- 16 -
3.1.2.4. 5V PSU............................................................................................. - 17 -
3.1.2.5. Other components.............................................................................- 17 -
3.1.3. Schematic design.................................................................................- 17 -
3.1.4. PCB design.......................................................................................... - 19 -
3.1.4.1. Track width and placement...............................................................- 20 -
3.1.4.2. Switching power supply.....................................................................- 20 -
3.1.4.3. Autorouting........................................................................................- 21 -
3.2. Software design.......................................................................................- 21 -
3.2.1. High level design..................................................................................- 21 -
3.2.1.1. Arduino firmware...............................................................................- 21 -
3.2.2. RPM measurement.............................................................................. - 23 -
3.2.3. Serial protocol...................................................................................... - 24 -
3.3. Final product............................................................................................- 24 -
3.3.1. Hardware..............................................................................................- 24 -
3.3.2. Arduino firmware.................................................................................. - 25 -
4
3.3.3. Test software........................................................................................- 25 -
4. Conformance..................................................................................................- 27 -
4.1. Requirements conformance.....................................................................- 27 -
4.2. Testing.....................................................................................................- 28 -
5. Discussion......................................................................................................- 30 -
5.1. Time management...................................................................................- 30 -
5.2. Problems encountered.............................................................................- 30 -
5.3. Further work............................................................................................ - 32 -
5.3.1. Current limitation and threshold............................................................- 32 -
5.3.2. Advanced motor control....................................................................... - 32 -
5.3.3. Transfer protection to Arduino..............................................................- 33 -
5.3.4. Decrease size and current capability of on-board 5V PSU..................- 33 -
6. Conclusion..................................................................................................... - 34 -
References........................................................................................................... - 35 -
Appendix A – Schematic diagram.........................................................................- 36 -
Appendix B – Arduino code.................................................................................. - 37 -
5
CD-ROM contents
This document attaches a CD-ROM with related material. The contents of this disk
are as follows.
Report (DOCX and PDF)
Test Application
Arduino firmware
KiCad schematic
FreePCB PCB design
6
List of Figures
Figure 1 - Hardware block diagram.......................................................................- 14 -
Figure 2 - Schematic diagram...............................................................................- 17 -
Figure 3 - PCB design.......................................................................................... - 18 -
Figure 4 - Arduino firmware block diagram...........................................................- 21 -
Figure 5 - Rotary encoder signal (Potma, 2004)...................................................- 22 -
Figure 6 - Photo of populated PCB.......................................................................- 24 -
Figure 7 - Test application screenshot..................................................................- 25 -
List of Tables
Table 1 - Summary of requirements.....................................................................- 11 -
Table 2 - Protocol definition..................................................................................- 24 -
Table 3 - Requirements conformance...................................................................- 27 -
7
Nomenclature
Abbreviation Meaning
PWM Pulse width modulation
PCB Printed circuit board
MCU Microcontroller Unit
DAC Digital to Analogue converter
PID Proportional Integral Derivative
RS232 A standard for serial communications and control signals
between devices
I2C Inter-Integrated-Circuit, a serial data bus for communicating
between integrated circuits
PIC Peripheral Interface Controller, a microcontroller designed and
manufactured by Microchip
AVR A microcontroller designed and manufactured by Atmel
FPGA Field programmable gate array
Net Wire network, a series of connected traces on a PCB
8
1. Introduction
1.1.About this report
This report documents the research, process and results used and obtained
throughout the project.
The first chapter introduces the project and summarises the development process.
The second chapter outlines the research undertaken throughout the project and
gives an insight into the relative advantages of the available options. Chapter 3
discusses the decisions made, the steps taken whilst designing the system and
demonstrates the finished product and accompanying software interface. Chapter 4
compares the final product with the initial requirements, and describes the
techniques and results used to test the system. Chapter 5 discusses the success of
the project and suggest recommendations for improving the system, and chapter 6
concludes the report.
1.2.Project aims
Several milestones were set to control the development process, which have been
outlined below.
Project planning: Produce a plan which includes initial project aims and
requirements, a time management plan and research of existing related projects.
Research: Compare and consider methods of implementation. Research areas are
predominately related to parts selection and then interfacing the various parts to
each other. Specific attention is to be paid to methods of protection, robustness of
the driver and interfacing the driver with the computer.
9
Design and prototype: Propose a draft schematic diagram and then construct a
prototype. Note issues with the prototype and change the schematic where
appropriate. Design a PCB based on the successful final prototype.
Manufacture and populate the PCB with the circuit: Implement the hardware design
designed in the previous objective, and test to ensure the circuit functions as it
should.
Write and optimise a firmware for the microcontroller: With a working hardware
device defined it will be possible to write a firmware to control all the features.
System testing: Test the combined hardware and software, ensuring that the
firmware is adequate for the hardware functions. Compare the product to the initial
specification to ensure the product is fit for purpose. Test each component
individually making sure there is nothing overlooked.
Evaluation of the product: Suggest any further work for the design and
implementation.
Project report: Issue a full report, documenting the planning, research, design
implementation and discussion of the product.
1.3.Requirements definition
The specific requirements of the system were defined early, and did not change
significantly throughout the course of the project. The requirements are outlined
below and summarised in Table 1.
A power requirement is imposed; the driver must be able to supply a current of 3A at
50V continuously, in a forward and reverse state. A brake must also be available to
stop the motor. Robustness of the system is critical, and several protections must be
10
considered; thermal shutdown, over-current shutdown and short circuit protection
must be apparent, as well as full optical isolation between the motor driver and the
control system. The final basic requirement was to allow the system to communicate
with the host computer over an RS232 interface.
Further, optional specification definitions offered were to provide the system a USB
interface, and read back the RPM of the attached motor. The frequency of the PWM
signal was required to be outside of the audible range, so that the motor would not
emit a high frequency tone whilst powered up. The final optional requirement was
allowing multiple motors to be controlled with the system.
Description Requirement
Voltage and current 50V, 3A
Controls Speed, direction and brake
Robustness Thermal cut-out, over-current cut-out, short circuit
protection
Protection Full optoisolation
Connection PWM frequency outside the audible range
Motor control RS232 (USB as further requirement)
Motor feedback Allow multiple motors to be controlled by the system (as
further requirement)
Multiple motors RPM sampling (as further requirement)
Table 1 - Summary of requirements
11
2. Background and Research
2.1.Existing products and related works
There are many motor drivers available on the market; however few come close to
the requirements of this project.
The closest product found to the requirements of this project is an Atmel AVR based
dual motor controller employing PID control and interfacing over an RS232
connection. However, the limitations of this motor driver are that it requires multiple
voltage sources, and that no attention has been paid to the robustness of the circuit.
The board appears to use the National Semiconductor LMD18200. This can be
found at the following URL:
http://www.procyonengineering.com/embedded/motorcontrol/motorctrl-avr/
Another related product is a 50V, 5A dual motor controller. This motor controller has
multiple methods of interface, via I2C, analogue voltage input, and an RC servo
interface. Again, this motor controller pays little attention to protections, and appears
to have no current threshold, thermal sensing or electronic isolation. This motor
board uses discrete MOSFETs to drive the motors. This can be found at the
following URL:
http://www.zagrosrobotics.com/shop/item.aspx?itemid=601
2.2.Motor driver
The requirement for the motor was the ability to drive a current of 3A at a voltage of
50V. For this to be possible, some form of electronic control would be necessary to
convert a control signal, likely to be logic level, to the high voltage and current
12
required. A dedicated H-bridge chip was selected for its simplicity, ease of interface
and cost efficiency. The other options were using a mechanical relay, which would
be noisy, inefficient, slow and unreliable, and to create an H-bridge using MOSFET
chips, which would be more difficult to interface, increase the chance of failure and
provide less protection features. The following commercially available H-bridge chips
which fulfilled the requirements were considered.
2.2.1. National Semiconductor LMD18200
The National Semiconductor LMD18200 is a 3A, 55V H-bridge in a TO-220 package,
whilst being capable of handling a 6A peak current for 200ms. This chip includes a
thermal warning output, thermal shutdown, short circuit protection and current sense
capabilities. Compatible with TTL and CMOS inputs, and with internal clamp diodes
and charge pump, the LMD18200 is simple to interface to a microcontroller based
control system. (National Semiconductor, 2012)
2.2.2. Linear Technology LT1160
The Linear Technology LT1160 is a half-/full-bridge power MOSFET driver, capable
of driving a peak current of 1.5A for 10µs at 60V. This chip offers under voltage
protection but no short circuit protection, current sensing or thermal shutdown.
2.3.Control system
For the control system, it was apparent that a microcontroller was the only option
which combined the PWM ability and general purpose input / output with the serial
interface required, whilst remaining cost effective. Other options would include
discrete logic, which was disregarded due to high complexity, cost and inability to
modify, and an FPGA based system, which would be less cost efficient with no
13
benefit. Two mainstream microcontroller options were considered, the Microchip PIC
series and the Arduino prototyping platform.
2.3.1. Microchip PIC
The PIC series from Microchip comprises of an expansive range of microcontrollers
varying in physical size, specification and capability. Many devices have a serial
interface, capture / compare / PWM and analogue to digital conversion, as well as
many other features. The PIC series can be programmed in many languages
including BASIC, C and assembler. (Microchip, 2006)
2.3.2. Arduino
Arduino is an open source prototyping and development platform based on the Atmel
AVR series of microcontrollers. The hardware is simple to use, with USB connectivity
and pin sockets to connect wires to. The programming environment is based on C++
with an abstraction layer to simplify the syntax for ease and speed of programming.
The Arduino can utilise raw AVR assembler to write timing critical routines or to
increase performance.
The Arduino can take advantage of all the features available on the AVR
microcontroller, such as PWM output, analogue to digital conversion, precise timing
and a serial interface. (Arduino, 2012)
14
3. Development
In this section, the steps pursued to design the system will be outlined, from a
hardware and then a software perspective, whilst outlining the reasons behind
certain choices and the considerations made when selecting methods.
3.1.Hardware design
3.1.1. High level design
The first step in the design of the hardware was to produce a block diagram
describing the functional characteristics of the system. The final block diagram can
be seen in Figure 1.
Figure 1 - Hardware block diagram
3.1.2. Functional description
The block diagram shows the functional layout of the system; however the purpose
of each component may be unknown. The reasoning behind the functional
components being chosen will be discussed.
15
3.1.2.1. MCU
An early design proposed contained the microcontroller on the motor driver board
itself, making the system a fully contained unit to be interfaced with a computer. It
was later decided that the driver board should be physically separated from the
microcontroller and connected via a cable, to allow the use of the driver board to be
more flexible.
This arrangement allows the system to fulfil partially the extra requirement to control
multiple motors. By allowing the drive circuitry to be separated from the control, it
would be a simple process to add a second driver to the microcontroller if required,
but also allow the cost to be reduced if only one motor is required to be driven.
3.1.2.2. Optoisolation
A key requirement of this system was robustness and safety. Optoisolation
electronically isolates both sides of the circuit, so that any unwanted voltage spikes
on one side would not transfer to the other, thus protecting the microcontroller and
the computer connected to it. As the frequency of the PWM would be outside the
audible range, a fast switching optoisolator was chosen to allow the signal to
propagate from the controller to the motor driver uninhibited. With a 60KHz signal
with 256 varying PWM levels, an optoisolator with a speed of 15MBaud was
required, however in testing a 10MBaud optoisolator proved sufficient.
3.1.2.3. Comparator
The chosen H-bridge motor driver, the National Semiconductor LMD18200, has a
CS (current sense) pin which provides 377µA per 1A drawn at the output (National
Semiconductor, 2012). This current is passed through a 1.8KΩ resistor to create a
voltage of 0.68V per amp drawn at the output. This is fed into one input of a
16
comparator; the other input is attached to a potentiometer to create a voltage
threshold. If the current drawn exceeds the preset threshold, the current warning pin
is activated to warn the microcontroller that the current threshold has been breached.
3.1.2.4. 5V PSU
As the motor driver is electronically isolated from the microcontroller and USB power
source, the motor driver is required to generate its own 5V power source from the
input voltage source, to drive the optoisolators and comparator. As the supply
voltage range of the H-bridge is from 12-55V, a switched mode power supply was
chosen to provide a stable 5V voltage at a range of input voltages, whilst not emitting
excess heat and requiring its own cooling.
3.1.2.5. Other components
As the optoisolator chips were active low, it was apparent that when disconnected
from the microcontroller or in a fault situation, the output of the optoisolator would
remain high. In the case of the brake and direction input, this is irrelevant however
the PWM input being held high would cause the attached motor to run at its
maximum RPM. As such an inverter was connected to the output of the optoisolator
to ensure that a fault or disconnection would result in the motor receiving no power.
3.1.3. Schematic design
The block diagram was then used to create a schematic diagram, using the chosen
parts. The schematic can be viewed in Figure 2, a full size version can be found in
appendix A. The open source software package KiCAD was chosen for the design of
the schematic.
The component choices were made based on the recommendations and figures
given in the datasheets of the respective components.
17
The Arduino platform was chosen as the microcontroller to drive the control system,
due to its clear and powerful programming interface and built in USB-to-serial
conversion.
The National Semiconductor LMD18200 H-bridge was chosen as it included the
required protection circuitry and was easily interfaced with a microcontroller.
The National Semiconductor LM2576HV-5.0 was chosen as the 5V power source, as
it was capable of generating 5V with an input voltage range of 7V – 60V, and a
current of 3A to allow for future expansion.
The optoisolator chosen was the Vishay VO2631, chosen due to its logic level inputs
and outputs, high switching rate and ability to have 2 channels per 8 pin DIP chip.
Figure 2 - Schematic diagram
18
3.1.4. PCB design
A PCB was designed using the FreePCB PCB design package, based on the
schematic diagram of the circuit. Considerations were made during the design of the
PCB to ensure robustness and safety. The final design for the PCB is shown in
Figure 3.
Figure 3 - PCB design
19
3.1.4.1. Track width and placement
Due to the high current nature of the project, adequate track width was paramount to
prevent damage to the circuit and reduce the risk of failure. Using a PCB track width
calculator, a width of 160mil (1mil = 1 thousandth of an inch) was decided upon for
the high current parts of the circuit. The peak current of 6A was used, with a peak
voltage of 55V. The allowed temperature rise was 10°C and a copper thickness of
70µm was assumed. This resulted in a recommended track width of 154mil, so a
160mil track was used. The calculator can be found at the following URL:
http://www.desmith.net/NMdS/Electronics/TraceWidth.html
The datasheet for the LMD18200 H-bridge recommended the VS pin have a heatsink
of a 1 square inch copper area, to allow heat to be dissipated in the case of a current
spike, which was implemented as part of the Vin trace.
The optical isolation was implemented to prevent there being any electrical
connection from one side of the board to the other. This meant that there should be
no copper connection from either side, and so there was no copper trace placed
underneath the optoisolator chips.
A ground plane was added to the board to increase resistance to interference,
reduce time for the board to be milled, and reduce wear on the PCB manufacture
hardware.
3.1.4.2. Switching power supply
The switching power supply on the circuit board required specific layout
requirements. The most notable requirement is ensuring the external components
are as close to the chip as possible, with minimum ground loops (National
20
Semiconductor, 2004). This meant a balance had to be struck between a well
performing power supply and ease of construction. The decision was made to
optimise the performance of the power supply at the cost of the components being
very close together.
3.1.4.3. Autorouting
The FreePCB package used to design the PCB contains an autorouting function to
automatically route the traces. This is done by attaching pins on the chips to ‘nets’,
which are then connected via traces at the autorouting stage.
To ensure optimum safety and performance, part of the routing was done by hand
before allowing the autorouter to function. This allowed the high current traces to be
routed with a sufficient gap between them to prevent against shorting. Critical traces
related to the 5V power supply were also hand routed to prevent the autorouter from
causing problems.
3.2.Software design
The software for the system comprises of two packages; a firmware for the Arduino
microcontroller and a test application for the host.
The Arduino was responsible for communication with the host, generating the signals
to control the motor driver, and interpreting the signals from the rotary encoder on
the motor. The host test application would have to send commands to the Arduino,
and display the received commands.
3.2.1. High level design
3.2.1.1. Arduino firmware
The Arduino firmware design is very simple. The process is shown in Figure 4.
21
With this design, it is assumed that the host will monitor the status of the current and
thermal flags, and take appropriate action if either is to change state. This would
result in a maximum of an 80ms delay between the flag occurring and the
corresponding reaction, however this could be mitigated by programming the
protection into the Arduino firmware.
22
UPDATE OUTPUTSSet new PWM duty cycle, direction
and brake states
GET DEVICE STATUSSample RPM and pin states
Send values to host
GET SERIAL DATAIs there data in the
serial buffer?
INITStart RS232 link
Define PWM frequencySet pin directions
Figure 4 - Arduino firmware block diagram
3.2.2. RPM measurement
The expected input from the motor is a rotary encoder. The number of pulses per
rotation is unknown, so this will need to be definable in the Arduino firmware. The
signal from a rotary encoder is shown in Figure 5 - Rotary encoder signal (Potma,
2004)Figure 5.
Figure 5 - Rotary encoder signal (Potma, 2004)
By attaching signal A to an interrupt, and incrementing a counter, we can count the
number of pulses made. If this number is sampled and cleared at a regular interval,
the RPM can be calculated.
To determine the rotational direction of the motor stator, the state of signal B can be
determined as the signal A interrupt is fired. When the motor is turning right and
signal A is at its rising edge (at point 1), signal B is low. When the motor is turning
left and signal A is at its rising edge (at point 3), signal B is high.
23
3.2.3. Serial protocol
A serial protocol was designed to allow the host to communicate with the
microcontroller. The protocol consists of 8 bytes, where each unit of data is at least
one byte. The first byte is a start byte, which is 0x0F. Both the host and the Arduino
listen for this start byte before parsing the next 7 bytes. This ensures that the start of
the packet is synchronised with the protocol parser and will stop the wrong byte
being interpreted as another. This is important as the Arduino could read another
byte as power, and turn the speed of the motor up when unwanted. The protocol is
defined inError: Reference source not found.
Byte ID Control packet Status packet0 START_BYTE START_BYTE1 Power Current flag2 Brake Thermal flag3 Direction RPM MSB4 NULL_BYTE RPM LSB5 NULL_BYTE NULL_BYTE6 NULL_BYTE NULL_BYTE7 NULL_BYTE NULL_BYTE
Table 2 - Protocol definition
3.3.Final product
3.3.1. Hardware
The PCB was manufactured by Cardiff University using a PCB mill and was then
populated with the components by the author. A photograph of the finished product
is shown in Figure 6.
24
Figure 6 - Photo of populated PCB
3.3.2. Arduino firmware
The Arduino firmware was implemented as per the design. Notable considerations
were the use of direct C commands rather than native Arduino commands for pin
manipulation, to improve performance. The entire Arduino firmware can be seen in
appendix B.
25
3.3.3. Test software
C# was used to implement a small test application to control the motor driver. This
application sends bytes conforming to the protocol to the Arduino based on the state
of the onscreen controls, and displays the received data. A screenshot of the
application can be seen in Figure 7.
Figure 7 - Test application screenshot
26
4. Conformance
4.1.Requirements conformance
The design conforms to the requirements initially specified. The requirements and
actual specification are shown in Table 3. As can be seen, the project comfortably
exceeded all given requirements.
Description Requirement Actual specification
Voltage and current 50V, 3A 12-55V input, 3A
continuous (6A peak)
Controls Speed, direction and
brake
Speed, direction and
brake
Robustness Thermal cut-out, over-
current cut-out, short
circuit protection
Thermal cut-out, over-
current cut-out, short
circuit protection
Protection Full optoisolation Full optoisolation and zero
copper between host and
motor driver
Connection RS232 (USB as further
requirement)
USB via Arduino
Motor control PWM frequency outside
the audible range
62.5KHz PWM frequency
Motor feedback RPM sampling RPM sampling
Multiple motors Allow multiple motors to
be controlled by the
system
Modular approach to allow
multiple drivers to be
controlled by the same
microcontroller
Table 3 - Requirements conformance
27
4.2.Testing
The system was tested at many stages during the development, from the prototyping
stage to after the production of the PCB. The main testing was done after the PCB
had been manufactured and will be the focus of this section.
The testing documentation consists of a test, an expected outcome and an actual
outcome. If the outcome is not as expected, a justification will be provided.
Test Connection established between PC and motor driver. An LED
was attached to the power control pin, and the power bar
manipulated in the test application.
PASS
Expected
outcome
Brightness should change proportional to the position of the
slider.
Actual
outcome
Brightness changes proportional to the position of the slider.
Test Motor speed changes respective of the input from the computer.
PASS
Expected
outcome
As power byte increases, motor speed should increase.
Actual
outcome
Motor speed increases proportional to the amount of power
requested by the host.
Test Motor direction changes respective of the input from the
computer.
PASS
Expected
outcome
When toggling the direction in the test application, motor
direction should change.
Actual
outcome
Motor direction changes correctly.
28
Test Thermal warning flag pin is correctly connected to the
controller.
PASS
Expected
outcome
When the pin is manually pulled low, the thermal warning flag
pin would go high.
Actual
outcome
Thermal warning flag goes high as expected.
Note: It was decided that attempting to test the warning flag feature would be unsafe
in the available environment, and could risk damaging the motor driver board as it
would require increasing the heat of the driver chip to 145°C. The test assumed the
thermal warning flag feature was functional in the motor driver chip.
Test Over-current flag goes high when current goes over the pre-
set threshold.
FAIL
Expected
outcome
Current flag is low until the current reaches the threshold.
Actual
outcome
Current flag gives inaccurate readings, output is very noisy.
The output of the current sense pin on the motor driver chip provides 377µA per amp
drawn by the output. Current spikes are likely, and the current drawn is not
consistent. This results in a noisy output which causes the current flag to be
unreliable. Possible solutions to this problem are posed later in the report.
Test PWM frequency is above audible range.
PASS
Expected
outcome
When running the motor, there should not be a fixed, high
frequency whine from the motor.
Actual
outcome
The motor does not make any high frequency whine.
Test RPM is measured using the rotary encoder signals.
29
PASS
Expected
outcome
RPM measurement rises in the test application when power
supplied is increased.
Actual
outcome
RPM display rises proportional to power applied.
The accuracy of the RPM measurement cannot be guaranteed, as no RPM
measurement equipment was available for comparison. However the RPM
measurement feature can be used to give an indication of the relative speed of the
motor.
30
5. Discussion
5.1.Time management
A Gantt chart was created at the beginning of the project to manage the flow of time.
As the initial time plan was to include April, time pressure was increased towards the
end of the project, and as such there was less time to complete the report than was
expected. The Gantt chart is shown in Figure 8.
Objectivenumber
Oct Nov Dec Jan Feb Mar Apr
12345678
Figure 8 - Project Gantt chart
The objectives referred to in Figure 8 are as described in the project aims; a
summary is as follows.
1. Project planning2. Research and compare different methods3. Design and prototype4. Manufacture and populate PCB5. Write and optimise microcontroller firmware6. System testing7. Product evaluation8. Project report
31
5.2.Problems encountered
During the project, several problems occurred which had to be overcome to ensure
the completion of the system. The problems which occurred will be discussed along
with the solutions posed.
The 5V power supply initially used a National Semiconductor LM5009 150 mA Step-
Down Switching Regulator. This would not provide a stable 5V output on
breadboard, which could be due to poor placement of external components. As it
was unclear as to whether this was down to the placement of the components or the
design of the circuit, it was decided that another voltage regulator would be used.
The solution was to use a National Semiconductor LM2576 switching power supply,
which when implemented on breadboard gave a very stable 5V output.
During the design of the PCB, it was necessary to have two different track widths for
the same net, however the FreePCB software makes this very difficult. The solution
to this problem was to create two separate nets; one for the high current traces and
one for the low current traces. This was then joined by the laboratory technician
using Altium Designer.
When machining the PCB, there were two problems. The first problem was that the
alignment camera was not fully calibrated prior to milling. This resulted in the holes
being drilled approximately 2-3mm from where they were intended to be, thus
causing the board to be unusable. The second problem was a translation problem
from the schematic and prototype to the PCB design. Two small pin misplacements
caused the Vcc and GND pins on one of the optoisolators to be swapped. The first
PCB machining problem was fixed by the laboratory technician, and the PCB re-
32
milled. The second problem was fixed by redesigning a small area of the PCB and
having the PCB re-milled.
5.3.Further work
5.3.1. Current limitation and threshold
The requirements stated robustness of drive and protection as a key element in the
design. However, the current sensing turned out to be buggy and ineffective, with
spikes causing the current limit flag to go high even when under light loads.
There are several potential solutions to this problem. Firstly, a software filter could be
implemented to require the current limit flag to be high for a set period of time,
allowing for noise. The current limit flag could be sampled at a regular rate, and only
after several concurrent high states would a subroutine be called to take action.
Another method would be to include a filter on the output of the current sense pin of
the H-bridge. This would filter the noise and only allow the state to be registered
when the pin had been high for a predetermined time.
A final method would be to use another H-bridge chip with a built in comparator,
such as the National Semiconductor LMD18245. This chip contains a 4-bit input to a
DAC as one input to the comparator, and the current sense pin attached to the other
input. This will allow a constantly variable current threshold which can be controlled
by the microcontroller. (National Semiconductor, 2012)
5.3.2. Advanced motor control
To improve the functionality of the system, more advanced motor control could be
implemented by adding to the microcontroller firmware. The data the microcontroller
can utilise is the rotational speed of the motor, the number of rotations, the position
33
of the motor stator and the power being supplied to it. Using this information, it would
be possible to implement a PID control system to maintain a constant RPM or move
an attached device to a specific position. Thus the system could be reprogrammed to
act as a servo controller for an industrial application.
To prevent physical damage and potential overheating, a stall prevention could be
implemented, to cut the motor out when not rotating. This would allow the system to
warn the host that the motor has stalled so that the mechanical problem can be
traced.
5.3.3. Transfer protection to Arduino
At present, the Arduino acts as a transfer layer between the host and the motor
driver. It is assumed that the host will be programmed to monitor the thermal and
current flags, and to take appropriate action. This functionality could be moved to the
Arduino firmware to increase the speed of response and decrease the chance of
failure.
5.3.4. Decrease size and current capability of on-board 5V PSU
The on-board 5V power supply was chosen for its stability of voltage and ease of
integration; however a smaller, lower current alternative could be used in its place to
reduce the size and weight of the board, as well as the component costs.
34
6. Conclusion
The goal of this project was to design and create a DC motor speed controller. The
requirements were clear and concise, giving basic requirements and additional
requested features for implementation if time were to allow it. The product was
manufactured using commercial of the shelf components, and communicates with
the host system using an Arduino prototyping board.
Overall, the final product exceeds the requirements, including the additional
requested features. Potential problems with the system have been identified, with
methods to improve the system suggested.
If the author were to undertake this project again, a similar design process would be
employed, as it was felt that this was successful and resulted in an adequate final
product. However, more time would be spent on the design of the microcontroller
firmware, as the current system is lacking in features and does not act on the
protections offered by the motor driver board.
35
References
Arduino, 2012. Arduino FAQ. [Online]
Available at: http://arduino.cc/en/Main/FAQ
[Accessed 23 3 2012].
Microchip, 2006. 8-bit PIC Microcontroller Solutions. [Online]
Available at: http://ww1.microchip.com/downloads/en/DeviceDoc/39630C.pdf
[Accessed 23 3 2012].
National Semiconductor, 2004. LM2576/LM2576HV Series SIMPLE SWITCHER 3A
Step-Down Voltage Regulator. [Online]
Available at: http://www.ti.com/lit/ds/symlink/lm2576.pdf
[Accessed 25 3 2012].
National Semiconductor, 2012. 3A, 55V DMOS Full-Bridge Motor Driver. [Online]
Available at: http://www.national.com/pf/LM/LMD18245.htm
[Accessed 25 3 2012].
National Semiconductor, 2012. LMD18200 3A, 55V H-bridge. [Online]
Available at: http://www.national.com/pf/LM/LMD18200.html
[Accessed 23 3 2012].
Potma, C., 2004. Bascom and AVR, Encoders. [Online]
Available at: http://www.qsl.net/pa3ckr/bascom%20and%20avr/encoders/index.html
[Accessed 26 3 2012].
36
Appendix A – Schematic diagram
37
Appendix B – Arduino code
////////////////////////////////////////////////////// //// Philip Strong 2012 //// //// DC Motor Speed Controller //// //////////////////////////////////////////////////////
// This sketch translates the serial protocol as defined below into // controls for the related motor controller board. There are 255 steps of // PWM control set to 62.5KHz, to ensure it is out of the audible range. // The current and thermal pins are monitored.
// Packet definition// The packet is comprised of 8 bytes. The control packet (incoming) // contains 4 blank bytes for future expansion. The status packet // (outgoing) contains 3 blank bytes for future expansion. The packets// are defined as follows.
// Byte ID Control packet Status packet// 0 START_BYTE START_BYTE// 1 Power Current flag// 2 Brake Thermal flag// 3 Direction RPM MSB// 4 NULL_BYTE RPM LSB// 5 NULL_BYTE NULL_BYTE// 6 NULL_BYTE NULL_BYTE// 7 NULL_BYTE NULL_BYTE
#define ENCODER_PULSES_PER_ROTATION 1000#define SPD 5 // Define pins#define BRK 6#define DIR 7#define THR 11 #define CUR 12#define START_BYTE 0x0F#define NULL_BYTE 0xFF
byte power, timeout; // Default power status, recommended 0boolean direction = false; // Default direction statusboolean brake = true; // Default brake status, recommended trueunsigned int rpm = 0; // int is 16 bit, assumed RPM will be less than
65536unsigned int tempRPM = 0;
void setup() TCCR0B = TCCR0B & 0b11111000 | 0x01; // Sets TCCR0B (timer 0) to 62.5KHz Serial.begin(57600); // Start serial communications at 57600 baud pinMode(SPD, OUTPUT); // Define pin directions pinMode(BRK, OUTPUT); pinMode(DIR, OUTPUT); pinMode(THR, INPUT); pinMode(CUR, INPUT);
38
attachInterrupt(0, rpmInterrupt, RISING); // encoder pin on interrupt 0 (pin 2)
// Every 40ms the Arduino checks the serial buffer for data, if new data is // received the outputs are updated. The RPM is calculated, then the status // of the device sent to the host Could be made more precise using millis() // rather than delay() to ensure exactly 40msvoid loop() delay(2560); // 40ms adjusted for timer 0 change by multiplying by 64. if(getValues()) updateValues(); // Update the output if the values have
been changed by serial if (timeout > 15) resetValues; // Kill motor and brake if data connection
lost until connection re-established rpm = tempRPM * 1500 / ENCODER_PULSES_PER_ROTATION; tempRPM = 0; sendValues();
// Send status of values to the computervoid sendValues() Serial.write(START_BYTE); Serial.write(digitalRead(CUR)); Serial.write(digitalRead(THR)); Serial.write((rpm>>8)&0xFF); // Send high byte of RPM Serial.write(rpm&0xFF); // Send low byte of RPM Serial.write(NULL_BYTE); // Reserved byte Serial.write(NULL_BYTE); // Reserved byte Serial.write(NULL_BYTE); // Reserved byte
// Checks RX buffer for data and if present decodes the packetbyte getValues() if(Serial.available() > 7) byte counter = 0; // This segment syncronises the reader with the start of the packet to // ensure the data is read correctly. Failure to do this could result //in the wrong byte being interpreted, and as such the motor being //given more power than is desired. for (byte i = 0; i < Serial.available(); i++) if(Serial.read() == START_BYTE) power = Serial.read(); // Power brake = Serial.read(); // Brake direction = Serial.read(); // Direction Serial.read(); Serial.read(); Serial.read();
Serial.read(); // Purge null bytes timeout = 0; i = 255; return 1; else return 0;
39
timeout++;
// Updates the outputs based on the global variable statesvoid updateValues() if(brake) //digitalWrite(BRK, LOW); bitClear(PORTD, 6); // Optimise digitalWrite(BRK, LOW); analogWrite(SPD, power); else bitSet(PORTD, 6); // Optimise digitalWrite(BRK, HIGH); if(direction) bitSet(PORTD, 7); else bitClear(PORTD, 7); // Optimise digitalWrite(DIR, direction); analogWrite(SPD, power);
// In warning situations, all values are reset to 0void resetValues() power = 0; brake = 0; direction = 0; updateValues();
// Counts the number of pulses from the motorvoid rpmInterrupt() tempRPM++;
40