Mechanical Overview - EDGE



[pic] |Motor Module - Robotic Platform 100 Kg (RP100) | |

| |P07202 - Concept Development Packet |

| |Status: |Final Design Review |Last Reviewed: |11/3/2006 11:00 AM |

| | | | | |

| | | | | |

| |

|Team Member |Discipline |Role |Email Address |

|Wayne Walter |ME |Guide |wwweme@rit.edu |

|Jeff Webb |ME |Consultant |jbw3914@rit.edu |

|George Slack |EE |Consultant |gbseee@rit.edu |

|Saul Rosa |EE |Member |scr3319@rit.edu |

|Vincent Capra |EE |Member |vpc4089@rit.edu |

|Derrick Lee |EE |Member |dgl2578@rit.edu |

|Muhammad Moazam |EE |Member |mxl0333@rit.edu |

|Robert Saltarelli |CE |Project Manager |robert.saltarelli@ |

|Dustin Collins |ME |Member |dc4fire@ |

|Jasen Lomnick |ME |Member |jal2768@rit.edu |

|Erich Hauenstein |ME |Member |esh9953@ |

Table of Contents

I. Table of Contents 2

II. Team Roles & Responsibilities 2

III. Introduction 3

IV. Customer Needs 3

V. Specifications 5

VI. Related Projects & Dependencies 8

VII. Design Concept 9

A. Mechanical 9

B. Electrical 41

C. Microprocessor 53

VIII. Test Plan 60

IX. Risk Management 63

Team Roles & Responsibilities

[pic]

Introduction

This motor module is part of the Vehicle Systems Technology Track of projects with the goal of developing a land-based, scalable, modular open architecture, open source, full instrumented robotic/remote controlled vehicular platform for use in a variety of education, research & development, and outreach applications within and beyond the RIT KGCOE.

The particular mission of this student team is to develop a fully functional, scalable motor module subsystem for use on the 100 kg (RP100) robotic vehicular platform. The overall design of this module is as follows:

[pic][pic]

Figure I.1: Top level assembly with and without protective shield

Customer Needs

Formulating a thorough statement of customer needs is a critical process as these needs will be the foundation of all future work. The customer requirements for this motor module were outlined in the P07202 Project Readiness Package (section X.2). These were translated into needs statements by expressing the customer’s requests: as an attribute of the project; in terms of what the product has to do rather than in terms of how it might do it; as specifically as the raw data allows; and using positive phrases when appropriate. This was done so as to produce need statements that are independent of particular technological solutions, maintain the detail of raw data with full fidelity, and facilitate translation into product specifications. Once the needs statements were generated, they were sorted by logical divisions and organized into a hierarchy.

Customer Needs Listing:

1) Physical Requirements

1.1) The motor modules must be configurable such that certain combinations can facilitate payloads ranging from 10kg to 100kg.

1.2) The unit should support 3, 4, and 6 wheel configurations.

1.3) The maximum size of the assembled unit must be within the volume constraints of 0 .6x0.75x0.5 m^3.

1.4) The maximum tare weight of the unit must be equal to or less than 40kg.

1.5) The speed of the assembled unit must be able to reach 4.5 m/s.

1.6) Each mounting location should be compatible with both idle modules and driven motored module

1.7) The speed of the unit must be controllable.

1.8) The unit must have a rechargeable energy source

1.9) This energy source must have a max-payload run time of at least an hour.

1.10) The system must have an on board shut-down intelligence, and a fail-safe braking system

1.11) Must be capable of braking

1.12) Must be capable of steering

1.13) The system must be capable of reading the angular speed and rotations of the motor.

1.14) Each motor module must be able to give feedback and receive instructions from the central processor.

2) Production Constraints

2.1) must be open architecture, such that it can facilitate future additions.

2.2) must be manufacturable in lots as small as 1 and as large as 10.

2.3) Commercial concerns for this product are negligible.

2.4) Must comply with federal, state, and local laws and regulations and RIT’s policies and procedures.

3) Document Requirements

3.1) Design documents must be open source

3.2) Must be designed such that other SD teams have the option to adapt the design in the future.

3.3) All documentation (when applicable) must reference federal, state, and local laws and regulations as well as RIT’s policies and procedures.

4) Quality Control

4.1) The ultimate result of this project must increase the reputation and visibility of the RIT senior design program and the robotics technology “skill level” on a national basis.

4.2) The robotic platform must be clearly impressive to any student, parent, engineer, mentor, or individual familiar with the US FIRST robotics competition.

4.3) The robot must have the technology and durability to be useful for the next 5+ years.

5) Compatibility

5.1) The processing platform of the robot must be able to integrate with project results of SD team projects P07301 and P07302.

5.2) The robotic platform must be able to integrate with the SD P07203 results.

Specifications

The next crucial phase of the design process was to generate engineering specifications that serve as the crucible when evaluating possible solutions. To generate our specifications, a needs-metrics matrix was created to elucidate the dependencies between applicable customer needs and possible engineering metrics.

| |Engineering Metrics  |

|Custom|Axle |Mounting Site |Motor Torque |

|er |Streng|supports Idler | |

|Requir|th |and Driven | |

|ements| |Modules | |

|0 |0 |Idle |GND/GND |

|0 |1 |brake |Input_B/ Input_D |

|1 |0 |reverse |Input_B/ Input_C |

|1 |1 |forward |Input_A/Input_D |

Now that the logic and hardware are integrated, complete control of the motor is only a matter of programming the FPGA to generate the correct PWM signal. However, there are two small matters to still take into consideration. First, because this system is drawing large amounts of current (a nominal 10 Amps) the system should be equipped for protection against any potential over-current scenarios. The safety mechanism could simply be a fuse. In this particular case a ‘slow blow’ fuse rated for 30 Amps was selected to do the job. This ensures that transient spikes are allowable for short periods of time. This leaves the system protected against major current inaccuracies, but will not shut down simply because of a harmless spike.

A second cause of concern is the h-bridge source voltage. Any major drains elsewhere in the system might cause the system voltage to dip. Therefore a large electrolytic storage capacitor (0.1F) is placed into the system to assure the motor will be supplied enough current at all times. Additionally, a high-frequency filtering capacitor was added to eliminate high-frequency noise. The component chosen to accomplish this was a 2.2uF electrolytic capacitor, which will eliminate noise above 45 kHz.

In conclusion, the design for this motor driving h-bridge was designed to ensure proper operation given the customer specifications. In addition, it was designed to abide by the ideals of modularity, scalability, robustness, and efficiency.

Motor Characterization

The transient dynamics of our Permanent magnet DC motors can be modeled using Matlab. The Simulink files can be created based on the tortional-mechanical dynamics describing the motor. The constant values that can be measured and calculated from the motor the:

• armature resistance (Ra)

• armature Inductance (La)

• torque constants (ka)

• Armature inertia (Ja)

• Back EMF constant (Bm)

Using the equipment provided in the laboratories, these constants can be easily measured then inputted into the simulation file to obtain the transient dynamics of the motor. Values such as the Back EMF and torque constants are calculated once the armature resistance and inductance is found. The armature resistance is found by putting a multimeter across lines of the motor, and measuring the lowest resistance given by the motor while turning the shaft. The inductance is found by putting a small voltage across the motor and stalling the shaft. A measurement is taken to see how quickly the voltage goes to steady state and from those values the inductance is calculated. Some of these values may be provided in the datasheet from the manufacturer.

[pic]

Figure B.8: Simulink diagram that will simulate transient characteristics.

BILL OF MATERIALS

[pic]

Figure B.9:H-Bridge BOM

[pic]

Figure B.10: Control Board BOM

[pic]

Figure B.11: Power Regulator Board BOM

[pic]

Figure B.12: Miscellaneous BOM

1 Microprocessor

Executive Summary:

A field programmable gate array (FPGA) serves as the main logic unit for the module. The majority of control and device interfacing occurs directly within this unit. This includes a parallel PID control system for determining the output signals to the motor, the pulse wave modulation unit connected to the the h-bridge which in turn controls the motors, and the measuring and conditioning of the encoder signal. The FPGA is also responsible for fetching, decoding, and executing/delegating command signals it receives via the CAN bus. Transmitting and receiving data over the CAN bus is accomplished using a COTS CAN transceiver. Command of the CAN transceiver, as well as the protocol control and formatting are not directly handled by the FPGA: a COTS CAN controller is used for these purposes. The FPGA does, however, direct this component and govern the overall flow of communications.

Detailed Design:

The core of the processing system is a field programmable gate array (FPGA). The use of an FPGA is advantageous for several reasons: it is flexible, fast, and readily scaleable all while being very cost effective. The flexibility manifests itself in the FPGA’s ability to support myriads of digital logic designs both in serial and parallel configurations including the processing cores normally found as ASICs. The design of this processing system utilities this ability by incorporating a fully functional PIC core on-chip thus providing further interoperability between the 10 Kg group as well as providing another avenue for future expansion. This soft-core PIC is capable of 40 MIPs and also includes the standard number of registers yet consumes less than 10% of the resources from the chosen FPGA . This is an excellent example of the aforementioned cost effectiveness because the Spartan 3E itself is available for $9.25 USD.

Aside this core is customized logic specifically designed for motor module control. The heart of the system is a finite state machine (FSM) control unit that interfaces with and directs the feedback loop, the PWM generator, the H-bridge, the CAN controller, and the sensors (refer to figure B.2 the architectural overview of this configuration).

The control unit is also responsible for the fetching, decoding, and execution/delegation of instructions received via the CAN bus.

[pic]

Figure C.1 : Instruction Path

The fetching mechanism interfaces with a COTS CAN controller (MCP2515) to receive and transmit data. Though it feasible to impement this logic directly, the benefits of the robust capabilities and inherent reliability of the COTs chip make it the superior choice especially considering the low cost, $2.98 USD. Moreover, it is readily interfaced with the chosen CAN Transceiver (MCP2551) used to transmit signals over the bus because that COTs chip is manufactured by the same company and designed for interoperability. It is also low cost ($1.45) and a consensus has achieved between the motor control team and the motor module teams to all use this same transceiver. This significantly reduces the risk of communication failures.

[pic]

Figure C.2 : Block overview of processing system

There are additional benefits of such a configuration such as the processing unit being isolated from the specifics of the communications medium. This affords a greater level of abstraction thus increasing the modularity and scalability of the design. Furthermore, the communications handling is offloaded from the processor and a simple connection interface is provided to interact with the MCP2515 reducing the consumption of FPGA logic cells and the number of I/O resources required while also contributing to an increase in the modularity and scalability of the design.

The control unit communicates with the CAN controller via SPI, a widely established industry standard for interchip communications. The four SPI lines—CS, S0, S1, and SClk—are shown in Figure C.2. In addition to these, there are also three transmission buffer flags, two receive buffer flags, and one interrupt signal: Tx0, Tx1, Tx2, Rx0, Rx1, and INT respectively. The flags allow the control unit and the CAN controller to convey which I/O buffer to use and an INT signal alerts the control unit about a new inbound packet.

The fetch process is designed with the ability to operate in parallel with the decoding and execution cycles. As such, the response to an INT signal occurs with minimal delay. Also included in the fetching mechanism is an emergency code that provides a shortened execution path to this command to significantly reduce the delay before it is executed. This coupled with the responsiveness to INT signal enables a near emergency stop capability.

For everything but the special emergency instruction, decoding is the next phase. Once a signal has been decoded the execution / delegation unit will either directly run the command or will offload the command to another unit. The primary other units are the PID & PWM signal and the PIC core. Delegating commands to the PIC can be done using the command instruction containing the PIC opcode which signals for the control unit to send the instruction to the soft-core. The actual instruction for the PIC constitutes the remainder of the data contained within the command instruction.

PID and the Pulse Width Modulator

The PID & PWM is composed of two distinct units: the control loop and the signal generator. Together, they provide the control for the H-bridge running the motors. These units are in turn governed by the control unit and by user-adjustable parameters. Though the following PID controller is ostensibly a single-channel design, the combination of these aforementioned parameters with dynamically adjustable input affords the ability to perform context switches. Thus, the controller is actually a full multi-channel unit.

Design of this control logic began with the standard PID equations for the output and the error term:

[pic] (i)

[pic] (ii)

This was the converted into a difference equation to support implementation in digital logic:

[pic] (iii)

However, even this form is not conducive to the digital design because of the sum term. Thus, a further modification is made such that the adjusted output will simply be a function of the previous output adjusted with the deviation from the current value:

[pic] (iv)

Letting [pic] and[pic], then the previous output term is simply (iii) with n-

1 substituted in place of n:

[pic] (v)

The deviation is then found by subtracting (v) from (iii):

[pic]

Collecting like terms yields:

[pic] (vi)

Letting[pic] and [pic] define:

[pic]

[pic]

[pic]

The equation for the output is:

[pic] (vii)

This was then readily converted into the combinatorial logic, which when combined with registers and inputs from the control unit, yields the following PID control unit:

[pic]

Figure C.3: PID Controller

The PWM generator logic was derived using the following considerations:

[pic]

Figure C.4: PWM Signal

This output is achieved using the following:

[pic]

Figure C.5: PWM Generator

Test Plan

MECHANICAL TEST PLAN

I. Motor Operation

1) Motor torque- (Specification: 2 N-m)

Procedure:

a) Design test fixture

b) Order parts for fixture

c) Construct fixture

d) Take measurements

Equipment:

a) Dynamometer

b) Fixture

c) Pulley

d) Belt

2) Motor continuous operating power-(Specification: 500 W)

Procedure:

a) Design test fixture

b) Order parts for fixture

c) Construct fixture

d) Take measurements

Equipment:

a) Dynamometer

b) Fixture

c) Pulley

d) Belt

II. Steering Operation

1) Steering motor operating torque (Specification: 7 N-m)

Procedure:

a) Design test fixture

b) Order parts for fixture

c) Construct fixture

d) Take measurements

Equipment:

a) Dynamometer

b) Fixture

c) Pulley

d) Belt

III. Braking Operation

1) Power-off stopping torque (Specification: 2 N-m)

Procedure:

a) Design test fixture

b) Order parts for fixture

c) Construct fixture

d) Take measurements

Equipment:

a) Dynamometer

b) Fixture

c) Pulley

d) Belt

2) Motor shorting stopping torque (Specification: Test dependant)

Procedure:

a) Design test fixture

b) Order parts for fixture

c) Construct fixture

d) Take measurements

Equipment:

a) Dynamometer

b) Fixture

c) Pulley

d) Belt

IV. Assembled Operation

1) Maximum vehicle payload (Specification: 100 kg)

Procedure:

a) Accelerate unloaded vehicle from a stop up IE incline

b) Increase payload by 20 kg and repeat procedure (a)

c) Repeat procedure (b) until vehicle is incapable of accelerating up incline

d) Remove failed payload increase and halve increment

e) Smallest increment of measurement shall be 5 kg

Equipment:

a) Numerous kg masses

2 Packaging envelope (Specification: 0.6x0.75x0.5 m)

Equipment:

a) Tape measure

3) Tare weight (Specification: 40 kg)

Equipment:

a) Large Scale

4) Maximum vehicle speed (Specification: 4.5 m/s)

Procedure:

a) Book Gordon Field House track

b) Lay out specified distance

c) Reach maximum speed prior to entering specified distance

d) Start timer as vehicle enters specified distance

e) Stop timer as vehicle exits specified distance

f) Repeat with several trials to ensure accuracy

Equipment:

a) Tape measure

b) Stop watch

c) Duct tape

5) Braking distance from maximum speed (Specification: Test dependant)

Procedure:

a) Book Gordon Field House track

b) Mark brake starting location

c) Bring vehicle to maximum speed

d) Brake at maximum rate starting at specified location

e) Mark final stopping position

f) Measure distance

Equipment:

a) Tape measure

b) Duct tape

6) Turning Radius (Specification: 1 m)

Procedure:

a) Start vehicle from a stop

b) Turn 2 driven wheels 90 degrees

c) Keep other 2 wheels straight ahead

d) Plot path wheel travels

e) Measure turning radius

Equipment:

a) Tape measure

b) Duct tape

Risk Management

|Risk ID|Corresponding |Description of Risk |Probability |Impact |Importance |Classification |Mitigation Strategy |

| |Spec #'s | |(0 - 1) |(low, med, | | | |

| | | | |high) | | | |

|1 |10, 14, 22 |Asynchronous module speeds |0.3 |med |1.5 |Technical |Make sure bus time is budgeted |

|  |  |  |  |  |  |  |Modules must respond identically |

|2 |18, 23, 26 |Interfacing with data |0.4 |high |4 |Technical |Support/ integration circuitry |

| | |communication protocol | | | | | |

|  |  |  |  |  |  |  |Purchase of compatible parts |

|3 |10, 11, 14, 22 |Speed encoder feedback failure |0.1 |med |0.5 |Safety |Purchase a durable part |

|  |  |  |  |  |  |  |Interrupt for lack of signal |

|4 |most |Noise susceptibility |0.5 |high |0 |Technical |Use of filters on susceptible |

| | | | | | | |signal lines |

|  |  |  |  |  |  |  |Use of durable wiring and |

| | | | | | | |interconnects |

|  |  |  |  |  |  |  |Proper grounding throughout system |

|5 |most |Transient power spikes (back |0.3 |high |3 |Safety |Proper grounding throughout system |

| | |emf) | | | | | |

|  |  |  |  |  |  |  |Power isolation for delicate |

| | | | | | | |circuitry |

|6 |18, 14, 19, 20 |Overheating components |0.7 |med |3.5 |Technical |Placing heatsinks on necessary |

| | | | | | | |components |

|  |  |  |  |  |  |  |Keeping circuitry in open air |

| | | | | | | |spaces |

|7 |15, 16, 17 |Battery chemical leak |0.05 |low |0.05 |Safety |Place battery low in the system |

|  |  |  |  |  |  |  |Keep it stable with necessary |

| | | | | | | |restrains |

|8 |12, 14, 18, 20, 22, |Insufficient microprocessor |0.4 |high |4 |Technical |Pre-determine necessary |

| |23 | | | | | |computational power |

|  |  |  |  |  |  |  |Pre-determine the input/output |

| | | | | | | |signals required |

|9 |33, 34 |Inter-group communication |0.4 |low |0.4 |Technical |Choose a unanimous structure |

|  |  |  |  |  |  |  |Use interfacing devices to bridge |

| | | | | | | |protocol |

|10 |10, 14, 18 |H-bridge Failure |0.1 |med |0.5 |Technical |Use a part capable of >100 W power |

| | | | | | | |consumption |

|  |  |  |  |  |  |  |Use h-bridges in parallel to |

| | | | | | | |distribute power |

|11 |most |Long-lead items |0.2 |med |1 |Logistical |Order parts in advance |

|  |  |  |  |  |  |  |Use COTS products |

|12 |most |PCB layout |0.9 |high |9 |Logistical |Test and determine final circuitry |

| | | | | | | |as quick as possible |

|  |  |  |  |  |  |  |Utilize tools on campus |

|  |  |  |  |  |  |  |Hand solder components to save |

| | | | | | | |money |

|13 |- |Long part lead times |0.5 |High |5 |Schedule |Select individual components as |

| | | | | | | |soon as possible |

|  |  |  |  |  |  |  |Order individual components as soon|

| | | | | | | |as possible |

|  |  |  |  |  |  |  |Utilize most common COTS parts, as |

| | | | | | | |they are more easily attainable and|

| | | | | | | |readily available |

|  |  |  |  |  |  |  |Have as many alternate vendors |

| | | | | | | |lined up as possible |

|14 |1,3,4,10 |Torque output not capable of |0.1 |Low |0.1 |Technical |Check motor calculations with |

| | |climbing the max incline | | | | |professors and P0720 |

|  |  |  |  |  |  |  |Include Service Factor in motor |

| | | | | | | |selection |

|15 |1,510,14,18,19 |Braking safely (minimum |0.25 |High |2.5 |Safety |Check braking calculations with |

| | |distance and fail-safe) | | | | |professors and P07201 |

|  |  |  |  |  |  |  |Characterize Dynamic braking |

| | | | | | | |through baseline prototyping |

|  |  |  |  |  |  |  |Utilize mechanical power-off brake |

|16 |8,13 |Packaging in small, modular |0.5 |Med |2.5 |Technical |Minimize size of all individual |

| | |space | | | | |components |

|  |  |  |  |  |  |  |Packaging minimization through 3D |

| | | | | | | |modeling |

|  |  |  |  |  |  |  |Standardize mounting with P07201 |

|17 |1,2,32 |Drivetrain Failure (static and |0.1 |Low |0.1 |Reliability |DME Calculations |

| | |fatigue) | | | | | |

|  |  |  |  |  |  |  |Correct choice of safety factor |

|18 |1,2,6,20,21,32 |Steering Failure (static, |0.25 |Med |1.25 |Reliability |DME Calculations |

| | |fatigue, and torque) | | | | | |

|  |  |  |  |  |  |  |Correct choice of safety factor |

|  |  |  |  |  |  |  |Motor torque requirement |

| | | | | | | |calculations |

|19 |- |Moving Robot with power off |0.75 |Low |0.75 |Technical |Utilize clutch (power-on or manual)|

|  |  |  |  |  |  |  |Backup plan- disconnect |

| | | | | | | |transmission via set screw or |

| | | | | | | |equivalent |

|20 |- |Characterize motor in timely |0.5 |Low |0.5 |Schedule |Work with Dave Krispinsky in and |

| | |fashion | | | | |develop dyno mounting technique |

|  |  |  |  |  |  |  |Generate and develop alternate |

| | | | | | | |characterization techniques |

|21 |1,2,3,4,5,6,9 |Weight (impact on torque |0.25 |Low |0.25 |Technical |Monitor and sum component weights |

| | |requirement) | | | | | |

|  |  |  |  |  |  |  |Verify total with motor |

| | | | | | | |calculations before ordering motor |

|  |  |  |  |  |  |  |Include motor Service Factor |

|22 |23 |Motor Temperature |0.25 |Med |1.25 |Reliability |Quantify heat output with baseline |

| | | | | | | |characterization |

|  |  |  |  |  |  |  |Backup plan- add a cooling fan |

-----------------------

[pic]

P07302

P07202 Motor Module1

P07202 Motor Module2

D-SUB 9

Male/ Female

CAN BUS

[pic]

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download