Proceedings of the KGCOE Multi-Disciplinary Engineering Design Conference Page 11
Total Page:16
File Type:pdf, Size:1020Kb
Multi-Disciplinary Engineering Design Conference Kate Gleason College of Engineering Rochester Institute of Technology Rochester, New York 14623
Project Number: 07302
MODULAR & SCALABLE MOTOR CONTROLLER SUBSYSTEM
Matt Oesterling/ EE Dev Shenoy/ CE
Ashish Karini/EE Latesia Desnots/EE Rich Cooper/CE
Rahul Gupta/EE Steve Tallau/ CE
ABSTRACT at RIT events and may be considered for US First robotic competitions. The scope of this document is to provide an overview of the design and development of a robotic vehicular NOMENCLATURE motor control system. This modular, scalable, open architecture microcontroller based platform will be ISA – Industry Standard Architecture implemented in future senior design projects within COM – Communication the Systems and Control Technology track at RIT. CPLD – Complex Programmable Logic Device PC104 bus architecture integrates motor modules and CAN – Controlled Area Network data acquisition devices with the microcontroller and SPI – Serial Peripheral Interface PWM – Pulse Width Modulation allows the capability of extending the system with µP – Microprocessor, Microcontroller additional devices. MHz –- Mega Hertz PCB – Printed Circuit Board INTRODUCTION MISO – Master In Slave Out MOSI – Master Out Slave In Many past RIT senior design projects have used I2C – Inter-Integrated Circuit bus standard Protocol robotic systems to carry-out necessary functions, tests DB9 – Serial Connector and data acquisition as needed for design UPS – Universal Power Supply requirements. In many cases, application specific motor control systems were designed by these groups which often consumed resources, time, and attention that could otherwise be used toward the original DEVELOPMENT PROCESS project objective. Design Specifications Having a flexible motor controller as well as a modular, scalable robotic platform will eliminate this The Design specifications were developed from problem. Senior design projects as well as academic customer requirements provided by Dr. Hensel of the research projects will be able to extend the capabilities Mechanical Engineering department at RIT. A PC104 of this motor controller for their specific needs without form factor board using an AMD µP was required, having to redesign an entirely new motor controller. which has a stackable bus architecture that operates under ISA specifications. Interfacing with motor Within the Controls and Technology track, teams are modules and data acquisitions boards is done over the currently working on motor modules, platforms, and stackable PC104 bus. A motor control daughter board data acquisition projects that will all be integrated with is used for interfacing with motors and sends/receives the motor controller system. The resulting robotic motor commands as well as sensor information vehicle will be used as a prototype to demo/showcase provided by the motor modules. As an auxiliary
© 2005 Rochester Institute of Technology Proceedings of the Multi-Disciplinary Engineering Design Conference Page 2
device, a PWM output is also onboard. The system The core functionality and features required of the should use less than 25% of its computing power and motor controller interface have been listed below: operate on a 12 Volt rechargeable battery for up to 1 Communication interface with the PC104 hour. system (through the ISA bus). Communication interface with the motor Design Concepts and Feasibility control modules (using the CAN protocol). Communication interface with an unspecified Many design concepts were developed and evaluated. auxiliary device (basic 8 bit PWM Of these, communication protocol, motor control generations). daughterboard architecture, and software architecture Noise filters on all incoming and outgoing are discussed here. signals.
Different protocols for communicating with the motor The core functionality and features required from the modules, including SPI, I2C, and CAN were explored PC104 system have been listed below: and it was decidedly found among all the P7200 teams Communication interface to the client side that the CAN protocol would be the most efficient system. method of communication. System to keep track of the motor controller The motor control daughterboard could be architected subsystem’s state. in numerous ways. The use of FPGA’s versus Interrupt handler to process requests for CPLD’s was discussed and CPLD’s were found to be information received from the client system a better/cheaper alternative. As well as how to side. implement CPLD logic to decode ISA addresses and Interrupt handler to process requests for route the motor commands correctly. More detailed information received from the motor control analysis can be found in the concept development modules. document. The functionality of the PC104 power system is listed Software architecture concepts were weighed to find below: the advantages and disadvantages of different Regulated step down voltage from a 12V operating systems to be employed on the AMD power source. processor. Linux was found to be the most suitable. Regulated power supply to the PC104 system. PRELIMINARY DESIGN PROCESS Regulated power supply to the motor controller interface components. Motor Controller Organization
The motor controller subsystem can be seen as being Motor Controller Interfaces composed of three subcomponents; PC104 system, Below are the various interfaces that the motor motor controller interface and PC104 power system. controller subsystem is composed of: Table 1 briefly summarizes each subcomponent. Software system: o Interface to an external client PC104 system Motor controller PC104 power system. interface system o Interface to the PC104 system (using the ISA bus). CPLD system: o Interface to the PC104 system (using the ISA bus) Run the main Contain the Contain the o Interface to the CAN controller motor controller necessary power system (using SPI and various software system. components circuitry to command lines). The PC104 required to provide the CAN control & encoding system: system operates communicate with PC104 with o Interface to the CPLD system. using a stripped the motors using the required o Interface to the CAN bus. down Linux the CAN protocol. power to operating system. operate. The interfaces of the power system are given below: From the battery: Table 1: Motor Controller System Subcomponents o 12V
Paper Number 07302 Proceedings of the KGCOE Multi-Disciplinary Engineering Design Conference Page 3
To the PC104 system (using a 10 pin ATX connector): o -5V, 5V, -12V To the CPLD o 1.8V To the CAN controller and the transceiver: o 5V, 2.5V Software System The external interface to communicate to the motor controller software system is done using a specified instruction set. These instructions can be invoked by the external client system using a text file or using a wrapper that directly feeds the instructions to the motor controller software system.
Internal to the motor controller’s software system is an interface to the ISA bus, used for communicating with the CPLD.
The following information needs to be shared between the motor controller system and any possible external systems that interface to it. Linear Motion: Velocity, Acceleration, Direction, Displacement Rotational Motion: Angle, Acceleration Temperature from thermocouples Power reading (to determine traction loss) General motor specifications Figure 1: Mircoprocessor Software State Diagram The instruction set that defines the motor control interface protocol at present consists of 17 The system loops infinitely until it gets an external instructions. These instructions can be used to access instruction. Upon getting an external instruction the information as well as to send information to control relevant instructions subsystem is invoked and the the motor platform. instruction is encapsulated in a CAN 2.0 packet and sent over the ISA bus to the CPLD. The GET and Each instruction sent to the motor control module TRIGGER commands are handled by a separate consists of the following data fields: process. This process is shown in Fig. 2. 8 bits representing the motor control module ID 8 bit representing the instruction to be sent to the motor controller. A possible 16 bit input.
The proposed 16 bit input will be a represent a discrete percentage between 0 and 100%. 100% would represent the largest safest input that is pre-determined Figure 2: GET and TRIGGER Command Process by the particular motor module team. The complete instruction set can be found in the appendix under This process will then update the Decoder with the table A1. correct flag information and will update the class that contains all the low level commands with the correct The software state machine is depicted in Fig. 1 information specified by a GET command. below. The class structure of this program consists of a decoder class that loops infinitely until it receives an external instruction, a user defined class that has all the high level instructions, and then a class that
Copyright © 2005 by Rochester Institute of Technology Proceedings of the Multi-Disciplinary Engineering Design Conference Page 4 contains all of the low-level instructions that the o High Impedance state if not Decoder method calls. addressed Read data bytes from the ISA bus to CPLD Send data bytes from the CPLD to the ISA bus
The following physical connections on the ISA bus are used by the CPLD: Data Bus o 8 bits o Bidirectional Address Bus o 15 bits o CPLD Input from Bus Control Signals o Write Enable (IOW*) o Read Enable (IOR*) o Address Enable (AEN) o Address Latch Enable (ALE) o System Clock (CLK) o Reset
Figure 3: Class Structure Diagram
As seen by Fig. 3, the Decoder class has flags that it will check each time it calls the UserDefinedClass(). This allows the process that receives information from the motor to stop the Decoder from sending more instructions.
This class is a main program that sits until data is sent. It then updates the components of the system as stated above.
CPLD System
The CPLD system consists of an interface to the ISA bus via which it can send data to the PC104 system / software system. The CPLD system also consists of an interface to the CAN controller chipset via a SPI connection and other dedicated control lines. Figure 4 shows a full system diagram along with the internal logic architecture implemented in the CPLD.
A Xilinx XC2C256 CPLD is used to buffer packets that need to be sent or received from the ISA bus. It also provides the system with send and receive packets for the CAN controller and a digital signal to the PWM chipset.
The CPLD system needs to handle the following aspects of the ISA bus: Address Decode o Determining if the ISA card is addressed
Paper Number 07302 Proceedings of the KGCOE Multi-Disciplinary Engineering Design Conference Page 5
CPLD in this case will be acting as a buffer and throughput for data that is to be sent and received from PC104 Versalogic Lynx w/ the CAN controller’s transmit and receive buffers. The COM AMD x86 Processor SC520 CAN controller contains three separate transmit User buffers independently controllable and two receive buffers which can be independently read.
The control for these are implemented in one of two ISA Specifications , S Clock running @ 8.3 MHz U
B
ways, either addressing control registers on the CAN
)
A
S
I controller or configuring the control signal lines to
(
4
0 provide similar functionality in an interrupt fashion.
1
Xilinx CPLD C
P The CPLD cannot attempt to provide intelligent XC2C256-7TQ144 control of the CAN controller chip, it must behave ISA Interface Logic purely as a hardware interface between the ISA bus and the CAN chip. SPI protocol must be utilized for sending and CLK 8 8 8 8 8 CAN receiving data with the CAN controller and the ISA 8 Rx_data Tx_addr Tx_data Control Instruction bus interface to send and receive data between the CPLD and the software. To transmit data via SPI, the CLK 8 DIV CPLD implements a SPI state machine which sends 8 SPI Logic CAN Logic Status bits serially via the MOSI signal line to the CAN controller. The CAN controller specification sheet
PWM defines the commands and protocols for manipulating
S S S
T F
I F T T T
O and using the MCP2515.
X E
B K S B
T
S
R R R
0 S 1 C S
I O
U N
2 C 0 1
I
E X X
S M M X X X
A
R R
R T T T The MCP2515 is a standalone CAN controller chipset. It is capable of receiving and transmitting data frames
SPI over the CAN bus. It is also capable of handling SCK running CAN Controller @ 1 MHz errors, acknowledging messages and retrying transfers. Instructions to the MCP2515 are sent via a SPI interface and data frames also read from the MCP2515 N N
A A via the SPI interface. C C X X T R
CAN CAN Serial Transfers CAN Motor Interface MOTORS running Transceiver @ 1 Mbits/s
Figure 4: System Logic Block Diagram
The microprocessor on the PC104 system will always be the master device using the PC104 stackable bus devices as slaves, in this design the I/O slave device is the Xilinx CPLD. AEN must be low for all data transfers. This tells the ISA card that the address is valid. To latch the address onto the bus ALE must be asserted, the address will be latched on the falling edge of ALE. For uP reads and writes the system address must remain valid on the bus until the end of Figure 5: CAN Controller Block Diagram the transfer cycle. During a read operation the data must stay valid on the bus until the falling edge of the CAN Bus Interface last cycle of the transfer. For write operations, valid data must remain on the bus for the remainder of the The MCP2551 (CAN transceiver) is a transceiver that cycle. modulates the TXCAN and RXCAN signals from the CAN controller to the CANHIGH and CANLOW CAN Control and Encoding System signals that will be transmitted over the CANBUS. The CAN transceiver is capable of operating at 1Mbps The CAN controller chipset that the CPLD will be in high speed mode and is capable of supporting up to interfacing with is the MCP2515 CAN controller, 112 nodes. where Fig. 4 depicts its logic block diagram. The
Copyright © 2005 by Rochester Institute of Technology Proceedings of the Multi-Disciplinary Engineering Design Conference Page 6
The physical interface to the CAN bus are implemented using a DB9 connector. Female right angle DB9 connectors are placed on all the boards (both the controller interface board and the motor controller boards). Male DB9 connectors are used to implement the actual connection. Figure 5 depicts the DB9 pinout.
Figure 8: Pulse Width Modulator Pinout Figure 6: CAN Transceiver DB9 Physical Pinout A servo motor is a small device that has an output Signal Conditioning shaft. A coded signal can be sent to the servo to position the shaft to a particular angular position. This position is maintained for as long as the coded signal stays on the line. To change the position of the shaft Galvanic isolation is required to CAN interface to the code sent to the line is changed. The angle is ensure error-free data transmissions and to isolate the determined by the duration of a pulse that is applied to CPLD/logic system from external high voltage the control wire. This is called Pulse Width devices. Modulation (PWM). Based on the pulse width the motor speeds up or down. The ADUM1200 is a dual channel digital opto-isolator that can provide this required isolation for the CAN Power System interface. It is also capable of supporting a maximum The power system comprises of power distribution to data transmission rate of 1Mbps with a propagation microprocessor and its logical circuitry. Supplying the delay of 150ns. required power to the circuit ensures smooth error-free functioning of the micro-controller. Two separate Figure 6 below shows the pin out for the ADUM1200 batteries power the modules. One large output power digital isolator: battery powers up the motor, while the second battery powers the logical circuitry. This battery will be a UPS style battery with output of 12V.
ENGINEERING MODEL
Hardware Schematic and Board Layout Figure 7: Opto-isolator Pinout
Pulse Width Modulation One of the requirements of the motor controller interface board is provide support for an auxiliary device. A simple servo motor may be used as the auxiliary device on the controller PCB. The SG3525 has an input precision of 8 bits.
Figure 7 below shows the pin out for the SGA3525A- D chipset.
Paper Number 07302 Proceedings of the KGCOE Multi-Disciplinary Engineering Design Conference Page 7
After designing the system, a hardware layout was Test Plan completed. Two boards were designed, the Motor In order to validate the Motor Controller Subsystem’s Controller Daughter Board and the Power Board. functionality the following series of tests suites were Both boards interface with the PC104 ISA stackable used: bus. Layout board design was completed using PCB 1. ISA bus test suite express Layout tools. This design was outsourced to a 2. CPLD control system test suite local company for fabrication. Figure A1 in the 3. CAN chipset test suite appendix shows the board layout schematic. 4. Instruction encoding test suite Figure 9 is a photo taken during testing, and shows 5. Instruction decoding test suite how the PC104 will interface with the daughterboard 6. Subsystem integration test suite and Power Board. 7. Overall system integration test suite The ISA bus test suite was designed to test the functionality of the ISA bus transmits and receives between the PC104 and the CPLD. Its primary objective is to validate the data bit and the device address the data is sent and received to and from. Initially only 8-bit data transmissions are carried out to validate the ISA bus’s control signals.
The CPLD control system test suite validates the addressing schemes used for the internal registers in the CPLD. To validate the SPI transmission implementation, one of the transmit registers in the CAN chipset is filled with a specified data field. The CAN chipset’s control lines are then toggled to read the data that was transmitted to the CAN chipset’s Figure 9: PC104 Hardware Board transmit register. This can be used to validate the SPI transmission and receive system. It can also be used to Hardware Flexibility test the control line system for the CAN chipset.
A flexible design was necessary to meet the required The CAN chipset test suite tests the operation of the specifications. Using a CPLD allows the Motor CAN chipset, the CAN transceiver and the CAN bus. Controller Daughter board to be completely The proposed method for testing these components as reconfigurable, which may be necessary for a whole is to have another CAN chipset, CAN application specific purposes and/or upgrading to transceiver and CAN bus interface. Since the current improve the current design. Onboard, there is a CPLD development kit consists of two CPLD’s the miscellaneous 8 pin header that can also be VHDL code to access the CAN chipset via SPI can be implemented as needed used to verify the data that is being transmitted from one CAN chipset to another. Since the data is EXPERIMENTAL SETUP AND PROCEDURE transmitted serially and is 60 bits in length the proposed methods of validating the data are to either Testing Apparatus check the CRC fields or to print out the expected data back to the PC104 as an ASCII string. This design was very software intensive and most of the testing dealt with programming the µP and the The purpose of the Instruction decoding test suite is to CPLD. A video board was attached to the PC104 verify that an instruction from the software application stack in order to code and debug the internal µP gets encoded and transmitted properly via the ISA bus programming. Xilinx Project Navigator was used to to the CPLD and then to the CAN subsystem. program, simulate and program the CPLD. In this test suite all 17 instructions are tested, however After the initial software was developed it was loaded only the boundary condition input values for these onto the boards, and a series of tests were run to instructions are tested as inputs. The CAN chipset test confirm proper operation. suite is then used to verify and further validate this instruction encoding test suite. The second CPLD can Testing the hardware, involved use of a digital logic be used to either buffer and output particular parts of analyzer as well as LED’s to probe CPLD pins and the data or to transmit the data back to the PC104 so confirm data transmissions. that the encoded instruction can be viewed as an ASCII string.
Copyright © 2005 by Rochester Institute of Technology Proceedings of the Multi-Disciplinary Engineering Design Conference Page 8
In order to test the decoding capabilities of the motor control subsystem, the second set of CAN components along with the second CPLD is used. The second CPLD will be loaded with 60 bit values representing encoded instructions. These instructions will be then be transmitted from the second CAN system to the first CAN system. The decoding capability of the CAN chipset and the CPLD system is then observed. Figure 11: SPI MISO Transmission Timing The decoded result is then obtained through the PC104 and displayed as an ASCII string. CAN operates at 1 Mb/s and transmissions are sent in 8 byte packets. These packets will be sent to the CAN After the above the instruction decoding test suite was from the CPLD via SPI. Each byte of data transferred carried out the majority of the motor controller to the CAN is bundled with an 8 bit address and 8 bit subsystem was tested as a whole. Hence it concludes instruction which sums to a 24 bit serial SPI transfer. the subsystem integration test suite. Processor Usage Once the internal components of the motor controller The PC104 processing usage was an estimated 10- subsystem were tested as a whole, the overall system 15% which is well under the requirement of 25%. was tested with the motor systems that are on the Most of the processing consumption is due to a polling different vehicle platforms to test for CAN packet scheme for means of feedback as opposed to interrupt compliance, CAN packet identifier recognition and handling. finally to test the instruction processing ability of the individual motor systems. All 17 instructions were CONCLUSIONS AND RECOMENDATIONS tested and boundary values were used for instructions As of writing this document a fully function prototype that require additional input. has not been fabricated. Testing has been accomplished using development kits for all three DESIGN ANALYSIS subcomponents. Timing Analysis and Synchronization Currently, the PC104 µP can successfully run the Synchronizing the entire system depends on the timing software and can interface with the ISA bus. The at the ISA bus, SPI, and CAN interfaces. The system CPLD can also interface with both the ISA bus and bottleneck will be with the SPI communication since it SPI output enabling for data transfers to and from the is a serial protocol operating at 1 MHz, as depicted PC104 and SPI. CAN protocol development and previously in Fig. 4. The following describes the implementation is still in progress. Communications timing analysis at each interface. with motor modules have been successful in previous attempts bypassing CAN communications. ISA 8 bit data transfers operate on an 8.3 MHz clock. The timing diagram for an 8 bit data transfer with 4 In conclusion this design can be viewed as low-level wait states is shown in the appendix under Fig. A2. drivers for interfacing necessary devices. Future (W1-W4 depict the wait states). It is calculated that projects will be able to build on this design given its the worst case delay for an ISA data transmission is 55 flexibility. Interrupt handling, battery life indication, ns. user-friendly interface, user control and device upgrades are all possible upgrades. The SPI interface protocol will be operating under normal SPI specifications, Fig. 10 is the timing Interrupt handling requires experience with general diagram for a MOSI transmission to the CAN chip. interrupt programming. Developers will have to delve Figure 11 is a diagram for a MISO transmission to the heavily into kernel programming in order to achieve CPLD. this. Battery life indication can be easily implemented onto the CPLD with simple logic and a few output pins. As far as interfacing, it will be possible for users to write graphical user interfaces that can be used at a very high level. Also, controlling a vehicle via joy- stick or remotely are possibilities.
ACKNOWLEDGMENTS Figure 10: SPI MOSI Transmission Timing . Dr. Hensel, Customer, ME Department . Prof. Slack, Team Advisor, EE Department
Paper Number 07302 Proceedings of the KGCOE Multi-Disciplinary Engineering Design Conference Page 9
. Dr. Lukoviac, CE Department http://en.wikipedia.org/wiki/Serial_Peripheral_Interfac . Dr. Philips, EE Department e . Dr. Hopkins, EE Department . All of the 07200 teams Techfest.com. (2002). ISA Bus Technical Summary. Thank you all for your help and support with the Retrieved 2006-2007, from Techfest web site: completion of this project! http://www.techfest.com/hardware/bus/isa.htm
REFERENCES Versalogic Corp. (n.d.). Lynx Single Board Computer. Retrieved 2006-2007, from www.versalogic.com: Brown, S., & Vranesic, Z. (2005). Fundamentals of http://www.versalogic.com/Products/DS.asp Digital Logic with VHDL Design (2nd Edition ed.). New York: McGraw Hill. Xilinx inc. (2002, December 13). Xilinx. Retrieved 2006, from Coolrunner Serial Peripheral Interface Controller Area Network. (2007, February 15). Master: http://www.xilinx.com/bvdocs/appnotes/xapp Retrieved 2006, from Wikipedia: 348.pdf http://en.wikipedia.org/wiki/Controller_Area_Network Xilinx inc. (2007, February 15). Xilinx. Retrieved Digilent Inc. (2006). XC2C Development Platform. 2006-2007, from XC2C256 Data Sheet: Retrieved 2006-2007, from www.digilentinc.com: http://direct.xilinx.com/bvdocs/publications/ds094.pdf http://www.digilentinc.com/Products
Microchip Technology Inc. (2005, March 1). Stand Alone CAN Controller with SPI Interface. Retrieved 2006-2007, from www.microchip.com: http://ww1.microchip.com/downloads/en/DeviceDoc/2 1801d.pdf
Serial Peripheral Interface Bus. (2007, February 20). Retrieved 2006, from Wikipedia:
APPENDIX
Copyright © 2005 by Rochester Institute of Technology Proceedings of the Multi-Disciplinary Engineering Design Conference Page 10
Figure A1: Motor Controller Daughter Board Schematic
Paper Number 07302 Proceedings of the KGCOE Multi-Disciplinary Engineering Design Conference Page 11
______CLK ___| |___| |___| |__| |___| |___| |___| |__ W1 W2 W3 W4
AEN ______
__ ALE ______| |______
______SA0-SA15 ------<______>-
______IOR* or IOW* |______|
_____ SD0-SD7 ------<_____>---- (READ)
______SD0-SD7 ------<______>---- (WRITE)
Figure A2: ISA Bus 8 bit Data Transfer Timing Diagram
Copyright © 2005 by Rochester Institute of Technology