proceedingsedge.rit.edu/content/p08201/public/mechanical/7201 stuff... · web viewthe design,...

15
Multi-Disciplinary Engineering Design Conference Kate Gleason College of Engineering Rochester Institute of Technology Rochester, New York 14623 Project Number: P07201 SELF CONTAINED MOTOR MODULE FOR 10 KILOGRAM PAYLOAD ROBOTIC PLATFORM Nicholos Mackos, RIT KGCOE ME Andrew Bucci, RIT KGCOE EE Zak LaLone, RIT KGCOE EE Jonathan Wilkinson, RIT KGCOE ME Lindley Garcia, RIT KGCOE EE Mark Kaupa, RIT KGCOE EE Dave Majka, RIT KGCOE EE Michael Anderson, RIT KGCOE EE ABSTRACT The design, analysis, fabrication, and testing of a self contained motor module, for use on a reconfigurable, open architecture robotic platform is detailed herein. The module’s on-board microprocessor interprets commands via a CAN communication bus to control in closed loop the speed and angular direction of a drive wheel. Locomotion and steering are provided through the employment of two permanent magnet DC motors; speed control is provided by dedicated H- bridge circuitry. Innovative power transmission and gear-train designs allow for steering angles of 360+ degrees. INTRODUCTION The motivation for the 7200 family of projects in the Vehicle Systems Technology Track at RIT stems from the needs of several faculty research efforts currently underway. In a number of cases, a custom mobile robotic platform has been necessarily created to serve as vehicle and chauffeur for the technology under study. One such case is the Mini Inertial Measurement/Navigation System (MIMNS) under development at RIT. © 2005 Rochester Institute of Technology

Upload: lenguyet

Post on 24-May-2018

215 views

Category:

Documents


1 download

TRANSCRIPT

Multi-Disciplinary Engineering Design ConferenceKate Gleason College of Engineering

Rochester Institute of TechnologyRochester, New York 14623

Project Number: P07201

SELF CONTAINED MOTOR MODULE FOR 10 KILOGRAM PAYLOAD ROBOTIC PLATFORM

Nicholos Mackos, RIT KGCOE ME

Andrew Bucci, RIT KGCOE EE

Zak LaLone, RIT KGCOE EE

Jonathan Wilkinson, RIT KGCOE ME

Lindley Garcia, RIT KGCOE EE

Mark Kaupa, RIT KGCOE EE

Dave Majka, RIT KGCOE EE

Michael Anderson, RIT KGCOE EE

ABSTRACT

The design, analysis, fabrication, and testing of a self contained motor module, for use on a reconfigurable, open architecture robotic platform is detailed herein. The module’s on-board microprocessor interprets commands via a CAN communication bus to control in closed loop the speed and angular direction of a drive wheel. Locomotion and steering are provided through the employment of two permanent magnet DC motors; speed control is provided by dedicated H-bridge circuitry. Innovative power transmission and gear-train designs allow for steering angles of 360+ degrees.

INTRODUCTION

The motivation for the 7200 family of projects in the Vehicle Systems Technology Track at RIT stems from the needs of several faculty research efforts currently underway. In a number of cases, a custom mobile robotic platform has been necessarily created to serve as vehicle and chauffeur for the technology under study. One such case is the Mini Inertial Measurement/Navigation System (MIMNS) under development at RIT. Before testing of the MIMNS device could even start, a robotic platform had to be designed and fabricated to carry the device and its support equipment. The Mechanical Engineering Department at RIT’s Kate Gleason College of

Engineering, with a grant from The Gleason Foundation, commissioned the 7200 family of design projects in an effort to create a robust, open architecture, reconfigurable robotic platform, the nature of which would be flexible enough to meet the needs of the various research efforts being conducted on campus. Each design project centers on the creation of a single platform system “building block”, the vision being that a researcher can pick and choose form a host of interchangeable parts (motor modules, platforms, data acquisition devices, controllers, etc) to quickly piece together a robust platform system that will suit him/her best. Modules, platforms, and other building blocks were commissioned in both 10kg and 100kg payload variants.

The focus of this paper, and the charge of the P07201 senior design team is the design, analysis, fabrication and testing of a set of self contained motor modules for implementation on the 10 kilogram payload robotic platform (RP10).

SYSTEM LEVEL ENGINEERING

Customer Requirements and Specifications. The design process began with a detailed review of customer requirements. These requirements were garnered from the project readiness package provided to the team, and through interviews with the team’s

© 2005 Rochester Institute of Technology

Proceedings of the Multi-Disciplinary Engineering Design Conference Page 2

customer. High level customer requirements are indicated below.

(1) The design must be modular in nature, and operate in a “plug-n-play” manner

(2) The module must provide for accurate control of wheel speed and wheel direction, as instructed by a platform level host controller

(3) The design must allow for easy reconfiguration of platform system size, shape, etc., and as such, modules must be configurable as both powered and idler units

(4) The design must be easily scalable to payloads of a single order of magnitude larger and smaller than the designated 10kg

(5) The module must provide for the safety of personnel, property, and of the module itself

(6) The module must operate on a reasonably sized DC battery

(7) The design must be open source, and open architecture

(8) The design must be economical in nature, and the technology easily transferable

These high level design requirements were used in two distinct manners. First, these requirements were translated into measurable, quantifiable performance metrics which the design could be tested against.

Secondly, these high level customer requirements were used to functionally decompose the design problem; this breakdown of required system and subsystem functionality serves as a critical first step in concept generation and selection. In the functional decomposition, the module inputs, outputs, and signal and energy conversions are broken out.

System Level Design. The functional decomposition of the design problem allowed the team to begin formulating design concepts to carry out the necessary module functions. The functional requirements of the module readily organized themselves into three categories: power electronics, embedded processing, and mechanical systems. Conditioning and distributing the electrical energy, as well as its conversion to mechanical work encompass the power electronics subsystem. Conditioning, transferring, and applying the mechanical energy lie within the mechanical subsystem. Similarly, interpreting commands, generating control signals, interpreting feedback, and delivering feedback signals fall under the embedded processing subsystem. At this point, the team started to fill in the system level design, as the necessity of embedded processing, dedicated power electronics, and a suitable mechanical gear-train became apparent.

From here the team set about the task of better defining the module’s role in the platform system so as to better define its functional requirements. Considerations as to the integration with a platform level host controller forced the delineation of platform and module level control strategies. A strategy set which placed wheel speed control, and wheel angular position control in the hands of the module’s embedded processor and platform positional control in the hands of the platform level host controller was chosen. This strategy set represented the most straightforward approach to platform system control, since it best eliminated any confounding controller interests.

Considerations were also made as to the electrical and mechanical interfaces with the host platform. For example, in order to provide for a steerable platform system which was easily reconfigurable, and to allow the modules to be directly interchangeable for one another, it was deemed necessary that each module be capable of steering its wheel independent of the others. This requirement filtered into the mechanical subsystem concept generation and selection. In a similar manner, the electrical connections, for both power and communication purposes needed to be flexible enough to accommodate different numbers and configurations of modules on a platform. For this reason, a power interface was chosen and standardized, and the CAN communication scheme was selected for implementation; the CAN architecture allows for any number of modules to be daisy chained together and individually addressed by the platform level host controller.

As the module’s role in the platform system neared its final definition the high level functional requirements of the module became translatable into subsystem functional requirements. At this point, design work was able to shift from the system level (defining interfaces etc) to the subsystem level. The next several sections relate the individual subsystem design processes, and detail the module’s final design.

SUBSYSTEM LEVEL DESIGNMechanical. To satisfy the customer’s needs of an accurate, economical and robust system several design concepts and variants were examined for accuracy, maneuverability, costs, manufacturability, and size. The three primary concepts were the “swerve” drive, consisting of a single wheel on the axis of rotation; the active steering offset castor[4], consisting of two driven wheels offset from the axis of rotation; and the two wheel mecanum[5], consisting of two opposed mecanum wheels side-by-side in a fixed configuration. Through the use of a weighted Pugh chart, the final design uses fixed drive and steering motors, and steers the wheel using an internal spur gear and pinion. This

Paper Number P07201

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

design provided the best balance of cost, simplicity, robustness, and performance.

Using information contained within the project readiness package and through discussions with the customer, a list of customer performance specifications was generated (Figure 1). Due to cost considerations the distance to max speed and the max platform mass use the assumption that four powered modules are used.

Max speed 2.25 m/sDistance to max speed 4 mMax 4-module Platform mass 20 kgMax Payload 10 kgMinimum steering ROM +/- 45 deg

Mechanical Customer Performance Specifications

Figure 1: Mechanical Customer Performance Specifications

Through an iterative process a wheel diameter was chosen and used to generate engineering specifications used in motor selection. Figure 2 shows the final set of requirements.

(Final) Wheel Diameter 5 in (12.7 cm)Torque required at wheel 0.603 N-mRPM required at wheel 338.361 RPMScrubbing(steering) torque required 0.315 N-m

Mechanical Engineering Specifications

Figure 2: Mechanical Engineering Specifications

Prospective motors were examined by iteratively altering gear ratios in the drive train to achieve the desired values. The final drive gear-motor selected is IG420017-C5201 from Shayang Ye Industrial Co., Ltd. with an external drive ratio of 1:1. The final gear-motor choice is IG320071-41F01 from Shayang Ye Industrial Co., Ltd. The internal spur gear and pinion were chosen to produce a reasonable rate of rotation for accurate control. The selected ratio was 7.8:1; however, due to physical constraints the ratio was changed to 15.6:1 which results in 12.7 s/rev.

The nature of the design requires that the drive power train consist of two stages after the gear-motor output shaft (See Figure 3). The first shaft must be concentric to the axis of rotation of the wheel. As a result, a bevel gear set is required to translate the power from the motor in a vertical orientation to a horizontal drive shaft. The next is to transfer the power to the parallel wheel shaft. This requires the use of a belt or chain drive. A rubber synchronous belt was chosen for its cost, noise output, maintenance requirements, and accuracy of motion.

Figure 3: Mechanical Drive Train

Because the shafts undergo both radial and thrust loads, the bearings for the module must be able to withstand both of these forces. This requires angular contact, tapered roller, or a flanged journal bearing. Due to the high cost of the first two options, and the project’s budget constraints it was decided that oil impregnated, flanged journal bearings would be used.

The next step was to design the yoke and the superstructure. Due to the customer requirement that the final product be demonstrably scaled to larger and smaller applications, the system design was in many aspects shared with the P07202 RP100 Motor Module Team. One primary difference is the construction material. A decision was made to us polycarbonate. Polycarbonate was chosen over other plastics for its yield strength as well as its high impact resistance. Initial designs called for a circular superstructure. However after input from the experiences of the P07202 team, a square stock was chosen for reduced complexity.

The feasibility of using polycarbonate was analyzed using FEA with a load of 12kg at both bearing points of wheel shaft (Figure 4). These conditions far exceed the expected loads of an individual module. The maximum stresses under these extraordinary conditions are still well below the yield strength of the polycarbonate.

Figure 4: Yoke Finite Element Analysis

In addition to studying the stresses on the yoke, factors of safety were calculated for the critical drive components. These are summarized in Figure 5. The failure criterion for the journal bearings is a specified

Copyright © 2005 by Rochester Institute of Technology

Proceedings of the Multi-Disciplinary Engineering Design Conference Page 4

amount of radial wear. For these calculations 0.005 inches (0.0127 cm) of wear was used. Additionally these cycles were calculated at the maximum rated torque of the system.

Component

Minimum Factor of

Safety Component Cycles to

Failure

Drive Shaft 1 18.6 Drive Shaft 1 5.9E+08

Drive Shaft 2 13.7 Drive Shaft 2 4.3E+08

Drive Shaft 3 22.9 Drive Shaft 3 2.0E+11

Steering Shaft 36.9 Steering Shaft 8.2E+16

Steering Spur 120.7 Bearings* 3.2E+06

Steering Internal Spur 20.5

Retaining Rings (1/4") 21.8

Retaining Rings (1/2") 16.0

Keystock (1/8") 272.9

Keystock (1/4") 1296.3

Set Screws (Drive)** 8 to 10

Set Screw (Steering)** 9 to 10

Figure 5: Drive Component Factors of Safety

Two assembly methods were considered for the module. The first is chemical bonding, and the second is mechanical fasteners. Due to health concerns, as well as ease of maintenance, it was decided that the module would be assembled with mechanical fasteners.

During the prototype phase a single powered module was built and tested. During this phase four design concerns arose and were addressed. The first was to widen the mounting plate so that the rail mount strategy of the four wheel platform did not interfere with the rotation of the module. The second was to redesign the yoke and change belt sizes to lower the load on the shafts due to belt tension. The third was to increase the rigidity of the yoke by changing the gusset plates from two triangles per side to one rectangular plate per side. The most critical concern was related to the steering. Due to nature of the yoke bearing, it possessed very low positional accuracy. As a result, the initial design required that the yoke and the superstructure be centered so that the pinion properly meshed with the internal spur gear. Even after undergoing a centering procedure, meshing problems still occurred. As a result an additional bearing and retaining rings were used to further locate the vertical drive shaft and ensure concentricity of the yoke with the superstructure. Testing after these redesigns has proved that these issues were resolved.Figure 6 lists the performance specifications of the final motor module.

Max torque at wheel 0.651 N-mMax speed 2.263 m/sMax steering torque 5.514 N-mMax steering angular speed 28.44 deg/s

Mechanical Performance Specifications

Figure 6: Mechanical Performance Specifications

Power Electronics and Safety. The motor driver was designed to have complete speed control over the drive

and steering motors by a control signal coming from a microprocessor. This motor control requirement is typically accomplished with an H-Bridge, which uses a set of switches to control the polarity of the voltage applied to the motor. Figure 7 illustrates how an H-Bridge arranges four switches to control motor current. In addition to controlling the direction of the motor, these switches can also be switched on and off rapidly to limit the amount of current given to the motor. The H-Bridge requires a pulse width modulated (PWM) signal to control how long the switches in the H-Bridge stay open, and thus how much torque the motor can produce. The H-Bridge must be capable of controlling all of the current and voltage the motor will see.

Figure 7: Conceptual illustration of H-BridgeThe motors were selected based on mechanical requirements of the platform’s top speed and an estimated time to accelerate to the top speed. The selected drive motors required 24VDC and had rated continuous currents up to 2.1A at the module’s maximum speed.

The power electronics team recognized that these electrical requirements are small enough such that a single IC H-Bridge is capable of meeting these requirements. An H-Bridge was selected that exceeded the defined current and voltage ratings and was also able to mitigate several safety risks associated with the motor driver. The component is made by Freescale Semiconductor and is model MC33886. It has a thermal protection which shuts down the IC in the event that it gets too hot. It also limits the maximum amount of current to the motors to avoid overheating as well, and can detect a short on the motor and shut itself down. In the event of a fault caused by one of those factors, a logic signal will be sent to the microprocessor and the H-Bridge can be reset and re-enabled at any time. All failure modes of the H-Bridge are mitigated by the built-in safety measures except for external heat sources damaging the H-Bridge even after a fault occurs. In the event of an H-Bridge failure the component would need to be replaced with an identical chip. To meet the demands of the design, a safe, robust and simple H-bridge was selected.

The rate at which the switches flip in the H-Bridge is the PWM Frequency. Research from the 7201 team produced a way to relate the motor parameters of a PWM controlled motor to the minimum PWM frequency required for reliable and predictable operation based off of induction and resistance, shown

Paper Number P07201

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

in (1. This left a range of acceptable frequencies between 1.8 kHz and the specified maximum of the H-Bridge at 10 kHz. The range of frequencies was to be experimentally validated during the prototype to find the final value.

(1)

The source of the PWM control signal can come from an external chip or micro processor. The major design challenge associated with the motor driver is to ensure that the H-Bridge does not get too hot. This manifested itself during the prototype of the motor driver in which the lack of thermal considerations in prototyping resulted in consistent overheating of the motor driver when driven near maximum capacity. After contact with the manufacture was made, it was determined the best mitigation for heat would be a imbedded copper strip on the PCB. The result can be seen in Figure 10.

Figure 8: Final PCB LayoutThe final product functioned as expected in that the control input PWM signal can precisely control the speed and direction of the motor. The protections on the H-Bridge are adequate and protect the chip and the motors from any thermal damage. Experimentation with the prototype components showed that a frequency of 3-4 kHz was an ideal compromise between the motor’s frequency requirements and the H-Bridge’s switching characteristics.

The 7202 and 7201 team collaborated to define the connectors and harnesses to interface the source power of the platform with the modules. The same power distribution system for the control power needed to be used for both teams, so a common connector was needed. For simplicity the same connectors were used as board-to-board connectors inside the motor module for the 7201 team. The interface between all of these systems was defined as using standard type AMP DUAC or Molex MiniFit Jr connectors. The connecters were specified to be rugged and easy to implement.

To interface with the possible future development of regenerative braking, an 8-pin connector was placed in line near the normal braking system. This connector

allows 5 signals, control and power, to be sent to a separate ‘regen’ board which will return three signals. Until that board is developed, a simple jumper plug can be constructed with the Molex connectors to pass through the relevant signals directly to the normal braking system.

The power distribution system began at the batteries. The requirements of the 10 Kg platform were that it had to function for an hour at a 60% duty cycle. There were also impacts on other requirements since the weight of the batteries affected the time to achieve top speed. The power systems load was estimated from the rated current draw of the H-Bridge, power-off relay, microprocessor, and motors. The loads were broken up between the main 24 V power and the control 5 V power. The results were that for the specified time of one hour at a 60% duty cycle, the motor batteries would need around 3 AH of capacity with the control battery requiring around 4 AH, depending on the efficiencies of the power distribution board which converted the 12 V battery supply to a clean 5 V power. These calculations are summarized in Figure 11.

Figure 9: Estimated Power Systems LoadsTo meet the budget requirements while still maintaining adequate capacity, sealed lead acid (SLA) batteries were selected for use. These batteries are similar to car batteries and motorcycle batteries in that they are 12 V and can store a lot of power. The ones selected are also meant for high current draw rates seen by the platform. The selected batteries were rated at 7 AH, and multiple batteries can be wired in parallel to extend the battery life of the platform. They are manufactured by B. B. Battery, model number BP7-12. The motor batteries will need to be in series to achieve the 24 V needed by the motors as well. These SLA batteries can be replaced with any type of battery wired in a combination that yields 24 V, and the lifetime of the platform will be determined by the AH rating of the cells.

The encoders were needed to achieve accurate speed feedback allowing the control team to accurately determine the position of the platform. The encoders were needed on the drive shafts to measure distance

Copyright © 2005 by Rochester Institute of Technology

Proceedings of the Multi-Disciplinary Engineering Design Conference Page 6

covered and other encoders were needed at the steering shafts to measure the direction of the distance. The steering encoders required knowledge of the ‘straight’ condition of the module, so either an absolute encoder was needed or an indexed encoder. The indexed encoder was selected because of the cost. Both of the encoders needed to feedback information about the direction of travel, so quadrature encoders were chosen. The model E5S from US Digital was used, which has options for through-hole shaft mounting as well as an indexed channel. It has 400 pulses per revolution for both steering and drive encoders, and the only difference is the indexed channel on the steering one.

The main safety concern with the motor module is braking. To accomplish a fail-safe system two types of brakes were designed. The first was a power-off brake. This brake is designed to stop the module when a loss of power is sensed in the module’s drive system. This braking system was realized using a dual pole relay operating at the control signal voltage of 5 volts. The relay is made by Omron Electronics LLC, model G2R, 5 V coil. When the relay is energized the contacts on each pole connect the motor to the motor driver terminals, allowing the motor to be driven. When the relay is de-energized as it would be during a loss of power, the contacts switch away from the motor driver and connect the two terminals of the motor, shorting the motor and causing it to brake. This functionality is illustrated in 12.

Tit le

S ize D o c u m e n t N um b er R e v

D a te : S he e t o f

<D oc > <R ev C o d e>

<T it le >

A

1 1Tu e s d ay , O c t o be r 10 , 2 00 6

1 2

U 1 A

74 0 4

H-Bridge

Battery

DC-DC

Motor

Figure 10: Power-Off brake configuration of DPDT Relay

The relay was placed immediately preceding the motor to ensure that it is in the most fail resistant location. Its design allows it to function as a short between the DC motor terminals when the signal goes low, or in other words, the control power fails. Each powered module is outfitted with this brake and can be replaced easily if the component fails. The relay uses a zero ohm resistor to short the motor which can be removed to disable the motor shorting brake during power off. It is unlikely that the relay will fail in mid operation of the motor. Failures of relays are generally caused by decay and the failure will be noticed after a failed attempt to charge the component. It is not recommended but possible in this case, to bypass the relay and use direct connections from the normal brakes to the motor.

The normal operation brake is designed to be used during the normal operation of the robot. It is designed to allow the motor module bring the entire unit to a safe, calculated and controlled stop. These brakes are

controlled by the microcontroller for the motor module. The normal operation brake is accomplished using two power MOSFETs. These transistors are designed to handle the heavy currents produced by applying temporary shorts to the motor. Two of these switches are used in conjunction with diodes to enable the system to stop regardless of how the motor is biased. The MOSFETs are mirrored to each other and the diodes are used to direct the proper current into the switch. It can be seen in Figure 13below.

Q 1M P F 4 15 0

Q 2M P F 4 15 0

1 2D 1

120 N Q 045

12

D 2

120 N Q 045

Brake Signal

To Motor

From H-Bridge

Figure 11: Braking Circuit The topology will ensure that only the proper MOSFET is on at a time. Their functionality allows for a wide range of breaking speeds that can be used by the user for very specific deceleration. The signal that is given to the brake is a pulse width modulated (PWM) signal at 5 volts. Testing of the MOSFETs used suggest an operating frequency range of 150 Hz to 300 Hz. In the case of a damaged MOSFET, replacement is fairly simple and does not require the exact same make and model of MOSFET. If a different type is used it is recommended that the operating parameters are comparable. It is possible to operate the system without this component by simply removing the transistors and/or diodes.

The kill switch was designed to open the circuit leading from the battery to the motor. It will allow either the safe isolation of the motor or battery as well a way to stop the system in the case of an emergency. It does not open the control power circuit and has no direct communication to the microcontroller. The system is realized using a normal high current switch placed between the main battery and the motor modules. The switch is closed during normal operation and should only be open when there is an emergency or during repairs and replacements. If it is abruptly open during operation, the possibility of subsystem damage is minimal but it is still is not recommended. Testing of this system should be done only while isolated from the control unit. Conversely, major damage can occur if the switch is used as an on and off control. In this case, current spikes may damage components in the power distribution board on the platform.

A design was also created to incorporate a regenerative braking system into the motor module. This subsystem would be used to short the motor

Paper Number P07201

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

across the battery and subsequently charge the battery. It was comprised of three main components. The first was a polarity logic system that would bias the battery properly as to ensure the current would flow into the correct terminals regardless of which direction the motor was going. The next was a regen logic system which would simply decide when the proper time was to turn on the voltage converter and short the motor. The heart of the system lay in the regen circuit. This circuit was comprised of a variable buck boost converter (voltage regulator), that would convert any voltage the motor was generating into the charge voltage of the battery. The current motor driver board supports the addition of this sub system if future teams decide to integrate it. The system was designed to charge a 12 volt battery. A simulation of the regen circuit can be seen in Figure 14 below.

Figure 12: Regen Simulation.

The regen simulation was conducted in Spice to prove the functionality of the voltage converter when it would be integrated into the design specs of the regen system. Red represents output voltage, blue represents output current and green represents the input voltage that would be coming from a braking motor. Notice how the red line stays relatively constant at 12.5 volts, even as the input voltage dramatically decreases. This proved that the system was achievable. Information for the simulation was gained from Liner Technologies [1].

Embedded Processing. The overall goal of the microcontroller subsystem was to deliver a method of successfully controlling a drive and steering motor. The main controlling unit of the subsystem was a 16-bit PIC microprocessor, created specifically for motor control. The microprocessor was chosen based on its ability to successfully accomplish the goals outlined in the project readiness package, as well as allow for upgrades in the future. The various components of the microcontroller subsystem are discussed below.

PWM Module. One of the main reasons for choosing the dsPIC30F4011 [2] was for its generous allowance of pulse-width-modulated signals. The package includes three pulse-width generators, each of which have two different channels which can operate in a complementary or independent fashion. The controlling of the motor via a PWM signal was

accomplished by applying various duty cycles to drive and the steering motors.

The microcontroller was designed to have the following commands embedded: Constant speed, acceleration, deceleration, stop/kill directional steer and braking.

A key factor in the microcontroller selection was the included communication capability using CAN architecture. The CAN technology is used heavily in automotive applications due to the high noise settings that often occur around motors. CAN is somewhat more resistant to noise than the other communication technologies. The CAN technology implemented for this project is slightly modified to allow for portable bus termination, which is required for the modularity of the system

Figure 13: Overview of CAN-bus Network

Standard CAN 2.0 protocol allows for up to 8 bytes of data to be transmitted per message sent. This allows for more complex instructions in the future, however for our instruction purposes the instructions were kept to 1 word in length, four bits to declare which type of instruction and 12 bits to represent the parameter of that instruction, i.e. accelerate would be the instruction using 4 bits and the rate of acceleration would be the parameter using 12 bits.

The development process of the onboard CAN bus began with initial register setup for all of the CAN registers on the processor. After initial setup, communication with the serial-to-CAN converter was unsuccessful and unable to be recognized by the microprocessor. The problem was narrowed down to being a timing issue between the device sending the messages and the microprocessor itself. After using the Microchip CAN bit-time calculator to compute the desired values of the desired baud rate, the microprocessor was programmed to the calculated values and the serial-to-CAN device was setup to match the calculated settings.

Since the microprocessor selected was aimed at motor control, it came packaged with a quadrature encoder interface (QEI). The functionality of the QEI is based off of three signals generated from encoders placed on the motors themselves. This allows for detection of speed and position.

Copyright © 2005 by Rochester Institute of Technology

Proceedings of the Multi-Disciplinary Engineering Design Conference Page 8

The processor came equipped with only one QEI, which was used to accurately control the drive motor. The steering motor was controlled using three of the processor I/O pins in a similar fashion to those used for the built-in quadrature encoder interface. Since there was not a pre-programmed interface for the steering motor to detect a full revolution, the index line from the steering motor encoder was tied to an “interrupt-on-change” pin which produces an interrupt when the signal on the pin changes.

The availability of the Quadrature Encoder Interface allowed for implementation of a motor control loop to control the speed of the motor under load conditions. A basic control loop was created and simulated using MATLAB and Simulink programs. The Simulink diagram and desired output are shown below:

b

damping

V

Scope

R

Resistance

K

Kt

K

Ke

1s

Integrator1

1s

Integrator

1/J

Inertia

1/L

Inductance

Add1

Add

id/dt(i)

d/dt(theta)d2/dt2(theta)

Figure 14: Simulated Motor Control Loop

Figure 15: Desired Output Waveform

CONCLUSION

Upon demonstration, the motor module fulfilled almost all of the goals set forth in the project requirements. The processor was able to successfully control the motors and drive and steering, with multiple levels of speed and acceleration. The communication of the module from the motor module

team was successful. The power electronics also sufficiently achieved its goals for the project with its selection and implementation of the H-bridge and safety components. Through future planning, the system has a very wide array of expansion slots and upgradeable components that will allow for following teams to expand the functionality of the project.

ACKNOWLEDGMENTS

The project would not have been possible without the help of organizations such as the Gleason Foundation and US Digital. Special thanks to Dr. Edward Hensel, Dr. Wayne Walter, Professor George Slack, Jeff Webb and Dr. Chris Hoople. Also special thanks are given to Dave Hathaway, Steve Kosciol and Rob Kraynik, who spent time out of their busy schedule to help with fabrication of the project.

REFERENCES

[1] Linear Technologies. 2006.

http://www.linear.com/pc/productDetail.do?navId=H0,C1,C1003,C1042,C1116,P10090.

[2] Microchip DSPic30f4011 Product Site; 2006.

http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1335&dDocName=en010337

[3] PCB 123 product site; 2006

www.pcb123.com

[4] Omni-directional Mobility Using Active Offset Split Castors. 2006

http://robots.mit.edu/publications/papers/2000_09_Yu,_Dub_Skw.pdf

[5] United States Patent: 3876255, 2006

http://www.uspto.gov

Paper Number P07201