Multi-Disciplinary Engineering Design ConferenceKate Gleason College of Engineering

Rochester Institute of TechnologyRochester, 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

The scope of this document is to provide an overview of the design and development of a robotic vehicular motor control system. This modular, scalable, open architecture microcontroller based platform will be implemented in future senior design projects within the Systems and Control Technology track at RIT. PC104 bus architecture integrates motor modules and data acquisition devices with the microcontroller and allows the capability of extending the system with additional devices.

INTRODUCTION

Many past RIT senior design projects have used robotic systems to carry-out necessary functions, tests and data acquisition as needed for design 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 project objective.

Having a flexible motor controller as well as a modular, scalable robotic platform will eliminate this problem. Senior design projects as well as academic research projects will be able to extend the capabilities of this motor controller for their specific needs without having to redesign an entirely new motor controller.

Within the Controls and Technology track, teams are currently working on motor modules, platforms, and data acquisition projects that will all be integrated with the motor controller system. The resulting robotic vehicle will be used as a prototype to demo/showcase

at RIT events and may be considered for US First robotic competitions.

NOMENCLATURE

ISA – Industry Standard ArchitectureCOM – CommunicationCPLD – Complex Programmable Logic DeviceCAN – Controlled Area NetworkSPI – Serial Peripheral InterfacePWM – Pulse Width ModulationµP – Microprocessor, MicrocontrollerMHz –- Mega HertzPCB – Printed Circuit BoardMISO – Master In Slave OutMOSI – Master Out Slave InI2C – Multi-master Serial Computer Bus Communication Protocol DB9 – Serial ConnectorUPS – Universal Power Supply

DEVELOPMENT PROCESS

Design Specifications

The Design specifications were developed from customer requirements provided by Dr. Hensel of the Mechanical Engineering department at RIT. A PC104 form factor board using an AMD µP was required, which has a stackable bus architecture that operates under ISA specifications. Interfacing with motor modules and data acquisitions boards is done over the stackable PC104 bus. A motor control daughter board is used for interfacing with motors and sends/receives motor commands as well as sensor information 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 should use less than 25% of its computing power and operate on a 12 Volt rechargeable battery for up to 1 hour.

Design Concepts and Feasibility

Many design concepts were developed and evaluated. Of these, communication protocol, motor control daughterboard architecture, and software architecture are discussed here.

Different protocols for communicating with the motor modules, including SPI, I2C, and CAN were explored and it was decidedly found among all the P7200 teams that the CAN protocol would be the most efficient method of communication.

The motor control daughterboard could be architected in numerous ways. The use of FPGA’s versus CPLD’s was discussed and CPLD’s were found to be a better/cheaper alternative. As well as how to implement CPLD logic to decode ISA addresses and route the motor commands correctly. More detailed analysis can be found in the concept development document.

Software architecture concepts were weighed to find the advantages and disadvantages of different operating systems to be employed on the AMD processor. Linux was found to be the most suitable.

PRELIMINARY DESIGN PROCESS

Motor Controller Organization

The motor controller subsystem can be seen as being composed of three subcomponents; PC104 system, motor controller interface and PC104 power system. Table 1 briefly summarizes each subcomponent.

PC104 system Motor controller interface

PC104 power system

Run the main motor controller software system. The PC104 system operates using a stripped down Linux operating system.

Contain the necessary components required to communicate with the motors using the CAN protocol.

Contain the power circuitry to provide the PC104 with the required power to operate.

Table 1: Motor Controller Subcomponents

The core functionality and features required of the motor controller interface have been listed below:

Communication interface with the PC104 system (through the ISA bus).

Communication interface with the motor control modules (using the CAN protocol).

Communication interface with an unspecified auxiliary device (basic 8 bit PWM generations).

Noise filters on all incoming and outgoing signals.

The core functionality and features required from the PC104 system have been listed below:

Communication interface to the client side system.

System to keep track of the motor controller subsystem’s state.

Interrupt handler to process requests for information received from the client system side.

Interrupt handler to process requests for information received from the motor control modules.

The functionality of the PC104 power system is listed below:

Regulated step down voltage from a 12V power source.

Regulated power supply to the PC104 system.

Regulated power supply to the motor controller interface components.

Motor Controller InterfacesBelow are the various interfaces that the motor controller subsystem is composed of:

Software system:o Interface to an external client

system.o Interface to the PC104 system (using

the ISA bus). CPLD system:

o Interface to the PC104 system (using the ISA bus)

o Interface to the CAN controller system (using SPI and various command lines).

CAN control & encoding system:o Interface to the CPLD system.o Interface to the CAN bus.

The interfaces of the power system are given below: From the battery:

o 12V To the PC104 system (using a 10 pin ATX

connector):o -5V, 5V, -12V

Paper Number 07302

Proceedings of the KGCOE Multi-Disciplinary Engineering Design Conference Page 3

To the CPLDo 1.8V

To the CAN controller and the transceiver:o 5V, 2.5V

Software SystemThe 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

The instruction set that defines the motor control interface protocol at present consists of 17 instructions. These instructions can be used to access information as well as to send information to control the motor platform.

Each instruction sent to the motor control module consists of the following data fields:

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 by the particular motor module team. The complete instruction set can be found in the appendix under table A1.

The software state machine is depicted in Fig. 1 below.

Figure 1: Software State Diagram

The system loops infinitely until it gets an external instruction. Upon getting an external instruction the relevant instructions subsystem is invoked and the instruction is encapsulated in a CAN 2.0 packet and sent over the ISA bus to the CPLD. The GET and TRIGGER commands are handled by a separate process. This process is shown in Fig. 2.

Figure 2: GET and TRIGGER Command Process

This process will then update the Decoder with the correct flag information and will update the class that contains all the low level commands with the correct information specified by a GET command.

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 Decoder method calls.

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 Decodeo Determining if the ISA card is

addressed

o High Impedance state if not 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 Buso 8 bitso Bidirectional

Address Buso 15 bitso CPLD Input from Bus

Control Signalso Write Enable (IOW*)o Read Enable (IOR*)o Address Enable (AEN)o Address Latch Enable (ALE)o System Clock (CLK)o Reset

Paper Number 07302

Proceedings of the KGCOE Multi-Disciplinary Engineering Design Conference Page 5

Figure 4: System Diagram with CPLD Logic

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 the transfer cycle. During a read operation the data must stay valid on the bus until the falling edge of the last cycle of the transfer. For write operations, valid data must remain on the bus for the remainder of the cycle.

CAN Control and Encoding System

The CAN controller chipset that the CPLD will be interfacing with is the MCP2515 CAN controller, where Fig. 4 depicts its logic block diagram. The CPLD in this case will be acting as a buffer and

throughput for data that is to be sent and received from the CAN controller’s transmit and receive buffers. The CAN controller contains three separate transmit buffers independently controllable and two receive buffers which can be independently read.

The control for these are implemented in one of two ways, either addressing control registers on the CAN controller or configuring the control signal lines to provide similar functionality in an interrupt fashion. The CPLD cannot attempt to provide intelligent control of the CAN controller chip, it must behave purely as a hardware interface between the ISA bus and the CAN chip. SPI protocol must be utilized for sending and receiving data with the CAN controller and the ISA bus interface to send and receive data between the CPLD and the software. To transmit data via SPI, the CPLD implements a SPI state machine which sends 8 bits serially via the MOSI signal line to the CAN controller. The CAN controller specification sheet defines the commands and protocols for manipulating and using the MCP2515.

The MCP2515 is a standalone CAN controller chipset. It is capable of receiving and transmitting data frames over the CAN bus. It is also capable of handling errors, acknowledging messages and retrying transfers. Instructions to the MCP2515 are sent via a SPI interface and data frames also read from the MCP2515 via the SPI interface.

Figure 5: CAN Controller Block Diagram

CAN Bus Interface

The MCP2551 (CAN transceiver) is a transceiver that modulates the TXCAN and RXCAN signals from the CAN controller to the CANHIGH and CANLOW signals that will be transmitted over the CANBUS.The CAN transceiver is capable of operating at 1Mbps in high speed mode and is capable of supporting up to 112 nodes.

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 6: CAN Transceiver DB9 Physical Pinout

Signal Conditioning

Galvanic isolation is required to CAN interface to ensure error-free data transmissions and to isolate the CPLD/logic system from external high voltage devices.

The ADUM1200 is a dual channel digital opto-isolator that can provide this required isolation for the CAN interface. It is also capable of supporting a maximum data transmission rate of 1Mbps with a propagation delay of 150ns.

Figure 6 below shows the pin out for the ADUM1200 digital isolator:

Figure 7: Opto-isolator pinout

Pulse Width ModulationOne 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.

Figure 8: Pulse Width Modulator pinout

A servo motor is a small device that has an output 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 the code sent to the line is changed. The angle is determined by the duration of a pulse that is applied to the control wire. This is called Pulse Width Modulation (PWM). Based on the pulse width the motor speeds up or down.

Power SystemThe power system comprises of power distribution to microprocessor and its logical circuitry. Supplying the required power to the circuit ensures smooth error-free functioning of the micro-controller. Two separate batteries power the modules. One large output power 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

Paper Number 07302

Proceedings of the KGCOE Multi-Disciplinary Engineering Design Conference Page 7

After designing the system, a hardware layout was completed. Two boards were designed, the Motor Controller Daughter Board and the Power Board. Both boards interface with the PC104 ISA stackable bus. Layout board design was completed using PCB express Layout tools. This design was outsourced to a local company for fabrication. Figure A1 in the appendix shows the board layout schematic.

Figure 9 is a photo taken during testing, and shows how the PC104 will interface with the daughterboard and Power Board.

Figure 9: PC104 Hardware Board

Hardware Flexibility

A flexible design was necessary to meet the required specifications. Using a CPLD allows the Motor Controller Daughter board to be completely reconfigurable, which may be necessary for application specific purposes and/or upgrading to improve the current design. Onboard, there is a miscellaneous 8 pin header that can also be implemented as needed

EXPERIMENTAL SETUP AND PROCEDURETesting Apparatus

This design was very software intensive and most of the testing dealt with programming the µP and the CPLD. A video board was attached to the PC104 stack in order to code and debug the internal µP programming. Xilinx Project Navigator was used to program, simulate and program the CPLD.

After the initial software was developed it was loaded onto the boards, and a series of tests were run to confirm proper operation.

Testing the hardware, involved use of a digital logic analyzer as well as LED’s to probe CPLD pins and confirm data transmissions.

Test PlanIn order to validate the Motor Controller Subsystem’s functionality the following series of tests suites were used:

1. ISA bus test suite2. CPLD control system test suite3. CAN chipset test suite4. Instruction encoding test suite5. Instruction decoding test suite6. Subsystem integration test suite7. 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 transmit register. This can be used to validate the SPI transmission and receive system. It can also be used to test the control line system for the CAN chipset.

The CAN chipset test suite tests the operation of the CAN chipset, the CAN transceiver and the CAN bus. The proposed method for testing these components as a whole is to have another CAN chipset, CAN transceiver and CAN bus interface. Since the current CPLD development kit consists of two CPLD’s the VHDL code to access the CAN chipset via SPI can be used to verify the data that is being transmitted from one CAN chipset to another. Since the data is transmitted serially and is 60 bits in length the proposed methods of validating the data are to either check the CRC fields or to print out the expected data back to the PC104 as an ASCII string.

The purpose of the Instruction decoding test suite is to verify that an instruction from the software application gets encoded and transmitted properly via the ISA bus to the CPLD and then to the CAN subsystem.

In this test suite all 17 instructions are tested, however only the boundary condition input values for these instructions are tested as inputs. The CAN chipset test suite is then used to verify and further validate this instruction encoding test suite. The second CPLD can be used to either buffer and output particular parts of the data or to transmit the data back to the PC104 so 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. The decoded result is then obtained through the PC104 and displayed as an ASCII string.

After the above the instruction decoding test suite was carried out the majority of the motor controller subsystem was tested as a whole. Hence it concludes the subsystem integration test suite.

Once the internal components of the motor controller subsystem were tested as a whole, the overall system was tested with the motor systems that are on the different vehicle platforms to test for CAN packet compliance, CAN packet identifier recognition and finally to test the instruction processing ability of the individual motor systems. All 17 instructions were tested and boundary values were used for instructions that require additional input.

DESIGN ANALYSISTiming Analysis and SynchronizationSynchronizing the entire system depends on the timing at the ISA bus, SPI, and CAN interfaces. The system bottleneck will be with the SPI communication since it is a serial protocol operating at 1 MHz, as depicted previously in Fig. 4. The following describes the timing analysis at each interface.

ISA 8 bit data transfers operate on an 8.3 MHz clock. The timing diagram for an 8 bit data transfer with 4 wait states is shown in the appendix under Fig. A2. (W1-W4 depict the wait states). It is calculated that the worst case delay for an ISA data transmission is 55 ns.

The SPI interface protocol will be operating under normal SPI specifications, Fig. 10 is the timing diagram for a MOSI transmission to the CAN chip. Figure 11 is a diagram for a MISO transmission to the CPLD.

Figure 10: SPI MOSI Transmission Timing

Figure 11: SPI MISO Transmission Timing

CAN operates at 1 Mb/s and transmissions are sent in 8 byte packets. These packets will be sent to the CAN from the CPLD via SPI. Each byte of data transferred to the CAN is bundled with an 8 bit address and 8 bit instruction which sums to a 24 bit serial SPI transfer.

Processor UsageThe PC104 processing usage was an estimated 10-15% which is well under the requirement of 25%. Most of the processing consumption is due to a polling scheme for means of feedback as opposed to interrupt handling.

CONCLUSIONS AND RECOMENDATIONSAs of writing this document a fully function prototype has not been fabricated. Testing has been accomplished using development kits for all three subcomponents.

Currently, the PC104 µP can successfully run the software and can interface with the ISA bus. The CPLD can also interface with both the ISA bus and SPI output enabling for data transfers to and from the PC104 and SPI. CAN protocol development and implementation is still in progress. Communications with motor modules have been successful in previous attempts bypassing CAN communications.

In conclusion this design can be viewed as low-level drivers for interfacing necessary devices. Future projects will be able to build on this design given its flexibility. Interrupt handling, battery life indication, user-friendly interface, user control and device upgrades are all possible upgrades.

Interrupt handling requires experience with general interrupt programming. Developers will have to delve heavily into kernel programming in order to achieve this. Battery life indication can be easily implemented onto the CPLD with simple logic and possibly 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

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 Dr. Philips, EE Department Dr. Hopkins, EE Department All of the 07200 teamsThank you all for your help and support with the completion of this project!

REFERENCES

Sample References are presented here:[1] Ning, X., and Lovell, M. R., 2002, "On the Sliding Friction Characteristics of Unidirectional Continuous FRP Composites," ASME J. Tribol., 124(1), pp. 5-13.[2] Barnes, M., 2001, "Stresses in Solenoids," J. Appl. Phys., 48(5), pp. 2000–2008.[3] Jones, J., 2000, Contact Mechanics, Cambridge University Press, Cambridge, UK, Chap. 6.[4] Lee, Y., Korpela, S. A., and Horne, R. N., 1982, "Structure of Multi-Cellular Natural Convection in a Tall Vertical Annulus," Proc. 7th International Heat Transfer Conference, U. Grigul et al., eds., Hemisphere, Washington, DC, 2, pp. 221–226.[5] Hashish, M., 2000, "600 MPa Waterjet Technology Development," High Pressure Technology, PVP-Vol. 406, pp. 135-140.

[6] Watson, D. W., 1997, "Thermodynamic Analysis," ASME Paper No. 97-GT-288.[7] Tung, C. Y., 1982, "Evaporative Heat Transfer in the Contact Line of a Mixture," Ph.D. thesis, Rensselaer Polytechnic Institute, Troy, NY.[8] Kwon, O. K., and Pletcher, R. H., 1981, "Prediction of the Incompressible Flow Over A Rearward-Facing Step," Technical Report No. HTL-26, CFD-4, Iowa State Univ., Ames, IA.[9] Smith, R., 2002, "Conformal Lubricated Contact of Cylindrical Surfaces Involved in a Non-Steady Motion," Ph.D. thesis, http://www.cas.phys.unm.edu/rsmith/homepage.html

Copyright © 2005 by Rochester Institute of Technology

APPENDIX

Figure A1: Motor Controller Daughter Board Schematic

__ __ __ __ __ __ __

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