G-CART Autonomous

Navigation and Controls 

Senior Design Team 05107

Preliminary Design Report

Project 05107

Darren Rowen

Scott Glover

SatSat Fox

Chaichat Boonyarat

Delwin Guiao

Derick Call

Luan Nguyen

1 RECOGNIZE AND QUANTIFY NEEDS............................................................................41.1 Mission Statement...........................................................................................................41.2 Project Description..........................................................................................................41.3 Scope Limitations............................................................................................................51.4 Stakeholders.....................................................................................................................71.5 Key Business Goals.........................................................................................................71.6 Primary Market................................................................................................................71.7 Secondary Market............................................................................................................81.8 Innovation Opportunities.................................................................................................81.9 Background Research......................................................................................................81.10 Formal Statement of Work..............................................................................................9

2 CONCEPT DEVELOPMENT............................................................................................102.1 Subgroup........................................................................................................................112.2 Bus Architecture Concepts............................................................................................132.3 Steering Concepts..........................................................................................................182.4 Velocity Control Concepts............................................................................................232.5 Emergency Brake Concepts...........................................................................................31

3 FEASIBILITY........................................................................................................................353.1 Bus Architecture Feasibility..........................................................................................353.2 Steering Feasibility........................................................................................................373.3 Speed Control Feasibility..............................................................................................403.4 Feasibility Conclusion...................................................................................................43

4 OBJECTIVES & SPECIFICATIONS................................................................................444.1 Design Objectives.......................................................................................................444.2 Performance Specifications.......................................................................................454.3 Safety Issues...............................................................................................................47

5 DESIGN ANALYSIS & SIMULATION..............................................................................475.1 Steering Design and Simulation....................................................................................475.2 Speed Control Design and Simulation...........................................................................60

6 FUTURE PLANS.................................................................................................................656.1 Schedule.........................................................................................................................656.2 Budget............................................................................................................................66

7 CONCLUSION.....................................................................................................................668 REFERENCES....................................................................................................................679 APPENDIX...........................................................................................................................70

9.1 Steering control PIC Program Flow chart.....................................................................70

1 RECOGNIZE AND QUANTIFY NEEDS1.1 Mission Statement

The purpose of this senior design team is to improve on the current G-Cart design already

developed at the Rochester Institute of Technology (RIT). The new design will allow for the

vehicle to autonomously navigate a G.P.S. bound all-terrain course.

1.2 Project Description

Complete a 300 km all terrain course in less than 10 hours.

Have to avoid a variety of obstacles while staying with the G.P.S boundaries

Output Controls:

A - Steering right/left

B - Vehicle stop/start/idle

C - Speed and gear position (drive/neutral/reverse)

D – Brakes, master cylinder pressure 0-100 BARR

E - Siren and Sound Alert (on/off combinations). There are vehicle requirements in the

Grand Challenge rules. The expectation is safety assurance.

F – Throttle position for speed control

G – Power and speed override, to shut the vehicle down as fast as possible.

Sensor Inputs:

A – Location. G.P.S. course guidelines will be stored in the navigation control

computer

B – Road recognition “visual location”. Multiple environment mapping systems will be

used as input to the control systems

C – Kill switch (if any problems arise)

D – Camera for troubleshooting only. This camera can be strategically placed to watch a

potentially failing mechanical system.

E - Brake by wire input (value 0-100 BARR)

F –Throttle sensor input (velocity variation 0-255), incremental values spanning the

vehicles desired velocity capability (i.e. -5 to 60 mph)

Mechanical:

Steering control

Sensor integrity (ex. shock absorbing, cooling system, power supply)

Continental Teves prototype brake by wire system.

Emergency brake system.

Exterior manually activated kill switch.

The vehicle has to comply with so many rules that it has become part of the product description.

The rule book is many pages that will be attached to the report and located in the senior design

team notebook.

1.3 Scope Limitations

Funding is expected, but not yet available. Due to the complexity of this project, funding

the best solution could become a problem that affects the end results (it is a race; finishing and

winning may be two different things)

Due to competition deadlines and expected delivery time of actual race vehicle, testing

could be limited (for our team, not the project as a whole). Also, the new G-CART vehicle has

not yet been acquired (as of November 12, 2004), which is a major limiting factor of our design.

Our team is currently waiting on the many expected donations. The Executive Board as

well as our team mentor believes that almost everything will be donated. While this is probably

true, our team has to complete our portion of the design and implementation by the end February.

We have placed numerous requests for donations, but we may not have time to wait on the

companies’ decision processes.

Determining what is expected of our design team. The Executive Boards needs have been

hazy at best. We have redefined our responsibilities several times, based on the Executive

Boards input. Our teams reduced role in the overall project is proving to be problematic with

respect to the design of deliverable goods to satisfy our senior design project. We are currently

broken into two sub teams responsible for steering of the vehicle and speed control. The

objective is to resolve the steering and speed control as soon as possible, and move on to the

navigation system or any other subsystem that may require added support.

Another limitation is our team’s lack of VHDL knowledge and time to learn it, for the

purpose of FPGAs. Some of the members are currently exploring the feasibility of an FPGA

solution. Further information is contained in the FPGA design section.

1.4 Stakeholders

R.I.T could win the two million dollar prize money.

D.A.R.P.A is the host of the race (military)

Automotive industry could use some or all of the design

Public transportation (bus, taxi)

Continental Teves

Evolution Robotics, Inc.

Egnite Software

Nation Instrument

Vehicle manufacturer

EE Faculty advisors

1.5 Key Business Goals

Create funding for the completion of the project

Stay within budget, which minimal in comparison to the expected funding

Win the two million dollars prize for a first place finish

Advertise our sponsors that have donated money or products that aided the design and

completion of the autonomous vehicle.

Advertise Rochester Institute of Technology. Hopefully in a beneficial manner.

1.6 Primary Market

D.A.R.P.A is the host of the race (military)

1.7 Secondary Market

Car manufactures – autopilot function or advanced cruise control system

RIT research and development for EE/ME/CE, which may attract R&D funds

1.8 Innovation Opportunities

High speed navigation

Save human life (military vehicle with no operator or passengers on board),

Artificial Intelligent vehicle

Optimize for less error in comparison to human operation (commercial vehicle with

passengers)

1.9 Background Research

The purpose of the G-Cart team is to design a vehicle capable of autonomous navigation

through a variety of terrain. Once the autonomous vehicle is developed, it is the goal of the team

to compete in various competitions throughout the United States. The venues for competition

include DARPA’s Grande Challenge; a race of autonomous ground vehicles from Los Angeles

to Las Vegas with a cash award of two million dollars to the team that completes the course in

the shortest time.

To accomplish this goal, G-Cart plans to research the existing technology in the generic

field of autonomous vehicular control and apply our knowledge to further research being

conducted in this area by RIT faculty, staff, and senior design teams. Ultimately, after our initial

goal of constructing an autonomous vehicle has been reached, we will continue research and

development in the realm of autonomous navigation and control. It is our long term hope to

develop a streamline system of autonomous control, unique to RIT, which could be used in a

variety of different application; including ones that could potentially be marketable. To

complete this objective our team will develop a sensor/controller network that interacts with

customized computer algorithms, capturing and processing the data using cutting-edge Artificial

Intelligence constructs. For obstacle-avoidance and path planning, multiple sensors will be

incorporated, such as: optical, radar, sonar, laser, and Global Positioning System data (GPS).

The result will be an intelligent vehicle that will have the navigating a dynamic environment.

The G-Cart team has successfully developed a completely wirelessly controlled vehicle

over the course of three months. The team was successful in altering a 91’ Geo Storm into a

vehicle capable of being controlled from several hundred yards away. Completion of this task

marks the end of phase 1 of the project. The team is actively perusing corporate sponsorship to

continue on their journey to develop an autonomous vehicle to compete in the 2005 DARPA

Grand Challenge.

1.10 Formal Statement of Work

The Executive Board has requested that the senior design team develop systems to

control the throttle, braking and steering. For the throttle and braking portion, the sub team must

deliver a “modular” control board that is capable of being adapted to one of several choices of

sport utility vehicles. The system must interact with the vehicles CAN system and I2C main

control bus for the purpose of I/O signaling. The controller will connect to a throttle by wire

system and Continental Teves brake by wire prototype. Proper resources will allow for vehicle

simulation and system testing, with out implementation in a vehicle. The controller must

maintain the desired vehicle speed within ±3 mph, except at a desired speed of zero. It is

required that the vehicle respond faster than normal human reaction delays. Through tests the

vehicles maximum performance will be determined and used to maximize vehicle response to

the controller input.

The G-Cart team will provide a cooling system inside the vehicle, but the system will be

tested at elevated temperatures due to potentially high dessert heat. The nature of the project

demands extreme controller stability as well as back up systems. To avoid serious brake

overheating, the controller must choose either braking or active throttle, not a combination of the

two. An emergency brake will provide a means of stopping the vehicle. Through the use of a

linear actuator, the vehicle can activate a “last resort” method of deceleration. Rigorous testing

both in and out of the vehicle will prove overall stability of the speed control design.

2 CONCEPT DEVELOPMENT

This chapter will cover the different concepts the team came up with. The first few

sections discuss the break down of the team. Since there are many different aspects to the

project, the team of eight engineers broke up into subgroups.

From the subgroups, ideas were generated and brought together to aid in concept

development on Bus Architecture, Vehicle Steering, and Speed Control.

2.1 Subgroup

The team was divided up to concentrate on the different aspects of the project. There were

3 different subgroups, although the Bus Architecture group had a short term focus and the team

members were assimilated into the other remaining subgroups. The subgroups are Bus

Architecture, Steering, and Speed Control.

2.1.1 Bus Architecture

The G-CART navigation computer, navigation sensors and vehicle control systems need

to have a communication bus to transfer data and commands. This subgroup was created with a

short-term goal: to design a communication network within the first few weeks of the fall

quarter. Scott Glover and Darren Rowen worked on this subgroup. They presented their

research to the RIT G-CART Club and hammered out which design would be best for the

project.

2.1.2 Steering

The steering subgroup was formed in approximately the third week to focus on the

electronics for the steering control system for the vehicle. The steering subgroup was to work

closely with the Mechanical Senior Design team. The Mechanical team was responsible for

picking out an appropriate motor, gearing and motor mounting. The steering subgroup from the

electrical senior design team was responsible for designing a motor drive and controller for

steering system. The controller for the system must be able to communicate with the guidance

computer and be able to read data from the vehicle’s CAN communication network.

2.1.3 Speed Control

The purpose of our sub team is to create a control system for braking and throttle. The

first part, braking, should be the easier of the two. Continental Teves is a company that designs

drive by wire systems for Ford and Toyota. They have asked to help implement their prototype

brake by wire system. Braking will be controlled by a pressure sensor and a pump attached to

the master brake cylinder. The vehicles CAN system will give the current master cylinder

pressure as well as deliver the desired master cylinder pressure. The velocity sub team will read

in desired velocity to our control board, make adjustment to the brake pressure and test results

for amount of error with respect to desire velocity and pressure and compensate for unexpected

results.

The second part of the task is to control a throttle sensor and throttle position motor. The

difficulties lie in the off road application. The vehicle will be subject to many road obstacles,

uneven surfaces disturbances, turning on dirt surfaces, up/downhill non-linear gradient

disturbances to the system, and trying to maintain a somewhat constant speed at the same time.

The controller will read in current speed, desired speed, and pseudo-acceleration variables via

the I2C bus. The output will control the throttle position motor via the CAN system, test results

of the position command, and adjust for unexpected results.

The controller has to be fast enough to read the I2C bus, CAN bus, make calculation,

implement results, test results, react to error, and sift the available data to acquire the needed data

for the current function.

2.2 Bus Architecture Concepts

Perhaps the most important goal of this years G-CART project was to produce a

modular design, which would allow for future additions to the project. In order for future

integrations to go smoothly, a standard communications protocol between processors,

sensors, and actuators should be established. This communications bus should allow for

simple future additions while also providing reliable and noise-free communication

between all in-car nodes. The following block diagram shows the current G-CART bus

architecture design.

Figure 2.2.1

Below is brief description of the five communication bus protocol concepts that

were seriously considered for implementation into the G-CART vehicle. Lastly, an

overall comparison of the bus architecture concepts is presented.

2.2.1 I2C

The first communications bus protocol considered was the inter-integrated circuit

(I2C) protocol, developed by Philips Semiconductor. This concept is a simple two wire

system, which can transmit addressable packets at a rate of 3.4Mbps. This protocol

allows for seven bits of addressing (128 devices), which would allow for a great amount

of future upgradeability. This protocol also has the ability to generate broadcast

messages, which are packets sent to all nodes regardless of addressing. This would allow

for emergency messages to be sent over the network, causing all nodes to act

simultaneously, rather then sending important commands one at a time to each system

node.

An I2C communications bus is currently used on existing G-CART vehicle to

handle simple communication between closely spaced processors. Therefore the G-

CART team already has a working knowledge of this communications protocol, which

should expedite the implementation of this design.

The only major concern of the I2C protocol is its lack of noise immunity and error

correction. Although no problems with the current I2C bus have been identified, it has

only been used for small distances and limited bus traffic. For the new G-CART design,

the communications bus will be run throughout the vehicle (several meters) and be

subjected to greater amounts of EMI from both the vehicle itself and from outside sources

(power lines, radio traffic, etc.).

2.2.2 USB

The Universal Serial Bus (USB) was also considered for the communications bus

protocol. USB is a robust, fast and reliable protocol that has become somewhat of an

industry standard today. This protocol would allow for new sensors or actuators to be

connected to the bus on the fly, and immediately be recognized by the system. USB also

has the benefit of having a built-in error checking and fault-handling mechanism. This

would allow for our communications bus to have greater length and handle more volatile

environments.

The major drawback to using a USB system is cost. Processors with

programmable USB ports are typically more costly than alternatives, and software

configuration is generally more difficult as well. Even though USB is an open-source

protocol it has many advanced features that would not be required by our application.

These additional features may be distracting and cause unnecessary overhead in our

vehicle.

2.2.3 PXI

PCI Extensions for Instrumentation (PXI) is a protocol that combines the high-

speed PCI bus with integrated timing and triggering lines for data capture and

comparison. Like USB, PXI devices are typically dynamically reconfigurable, which

results in a ‘plug-n-play’ system. This protocol was designed specifically for data

capture and analysis, and therefore has several unique triggering and comparing features.

It is yet uncertain whether or not these features would be used in the communications bus

of the current G-CART design, but they could potentially be of great use in future design

revisions.

PXI devices are typically very robust and high modular. Most of the PXI DAQ

board that we looked at for this design were rated for extreme temperature, vibration, and

EMI, all much outside of the range that is expected to be encountered for this project. If

a PXI bus were implemented, all processors and controller would be similar to a PCI card

(like those used in standard PCs), which would plug into specialized PXI chassis.

Again, the main drawback to this concept is cost. Both the PXI chassis and

controllers are very expensive. This concept is mainly considered because one of the

major PXI vendors, National Instruments (NI), is currently considering the RIT G-CART

team as a sponsor. If this sponsorship is obtained then the cost of the PXI equipment

would be greatly reduced and some of NI's pre-built systems could be integrated into the

G-CART vehicle.

2.2.4 IEEE 1384

The next bus protocol concept considered was the IEEE 1384 standard,

commonly referred to as firewire. This protocol is also fast becoming an industry

standard for high-speed data transfer. Firewire is typically seen in video applications

were high bits-rates are required. In addition to its speed, firewire also allows for an

extremely high number of nodes to be connected on a bus, which would allow for future

adaptability. Firewire also included noise immunity and error correction similar to USB,

which would make it durable and reliable in the G-CART application.

It is unsure whether or not the high speed of IEEE 1384 is required on a

communications bus. Currently, there are no plans to include any video-based sensors on

this network and therefore the high bit-rate may not be needed. Also, it is relatively

difficult to find cheap controllers with IEEE 1384 programmable connectors. Most

devices that include firewire interfaces are video-specific, and include features that will

not be used for a typical bus-level controller.

2.2.5 RS 485

The final communication bus protocol investigated was RS-485. This protocol is

a more robust version of the widely popular RS-232. RS-485 is a four wire design, which

broadcasts packets from a bus master and has variable message lengths. This protocol

also has error correction, although not as comprehensive as the method employed by

USB or IEEE1384. RS-485 is a popular choice for industrial communications because it

has to be ability to provide high noise immunity over long distances. This would allow

for the communications bus to be run throughout the G-CART vehicle without worrying

about maximum distance or line capacitances.

RS-485 is also considered to be a good solution because it is easily interfaced

with most microcontrollers and processors. Most devices come standard with either a

RS-232 port or a full UART. Both of these can be used to receive RS-485 signals with

little software overhead.

2.2.6 Compare and Contrast

The concepts listed above demonstrate the wide range of communication

protocols that can be implemented into the G-CART vehicle. All five of the

communication protocol concepts allow for individual and broadcast addressing,

bidirectional communication, and a high number of attachable nodes. Some concepts

have specific attributes that make them appealing, such as the specialized triggering

commands in the PXI protocol. Other concepts provide simple bus architecture with

limited overhead, such as RS-485 and I2C. Without knowing specifically what the

communications bus will be used for in future G-CART designs, it is only possible to

choose an architecture that will provide fast and reliable packet transfer.

2.3 Steering Concepts

2.3.1 DC Drive Concepts

Many different approaches were researched, although the final concepts were

restricted by the final motor selection.

2.3.1.1 PicMicrocontroller with Hall Effect Feedback

There are some alternatives to control the motor drive (bridge). One way would

be to control it using hardware approach, which is relatively more expensive and the

reliability is questionable. Using the software approach, the design will be more cost

effective. The design will be more reliable over all due to lower hardware complexity.

For the design, the PIC microcontroller was chosen due to its cost effectiveness, available

resource and documentation, and simplicity. The recommended set up for a pic

microcontroller based 3 phase BLDC motor control is shown below:

Figure 2.3.1.1.1

2.3.1.2 PicMicrocontroller with no commutation feedback

This concept is very similar to the DC drive using commutation feedback. The

main difference is that the microcontroller will energizes the coils in a fixed pattern. The

main drawback to this design is that with loading, the motor may not speed up to the

fixed pattern and a stall could result. In the start up scenario, without motor position

information, the fixed pattern would only assist in starting the motor for one third of each

excitation cycle. A primary concern is having enough start-up torque. So the loss of

start-up torque makes this design option highly unlikely.

2.3.2 Controller Concepts

The controller would have the responsibility of reading and parsing the I2C

communication from the navigation computer. In addition, the controller would have to

monitor the vehicles CAN traffic and parse out messages containing the vehicles wheel

angle. From this data, the controller would need to computer an error signal. Using the

error signal the controller would then have to compute the appropriate motor speed and

direction.

2.3.2.1 FPGA Controller

One possible approach was to use an FPGA to act as the controller. The FPGA

would have to be capable of reading and parsing both CAN network messages and I2C

network messages. The programming of the FPGA to read and parse network data from

both I2C and CAN networks could prove a difficult task. In addition, a Digital to Analog

converter would be required to provide the reference voltage for the DC Drive.

An FPGA would easily be able to implement a fixed weight FIR filter to

implement the control algorithm. In an FPGA, the ability to adapt or vary the weights

would add a tremendous amount of programming complexity.

The FPGA would have to be installed on a circuit board with auxiliary circuitry

including power supplies, external pull-up and pull-down resistors and filtering

capacitors. In many cases demonstration boards are available for purchase.

2.3.2.2 Microcontroller

The wide range of microcontrollers on the market offers an amazing range of

capability. There are microcontrollers available that are capable of reading CAN and I2C

network traffic. A microcontroller would also be capable of implementing an FIR filter.

Being the values for the weights of the filter would be stored in memory; they could be

changed or adapted without having to reprogram the device. One concern is the ability of

a microcontroller to implement an adaptive control algorithm, such as the least-mean-

square (LMS) algorithm. Implementation of an adaptive controller requires very high

speed computations in order to minimize the adaptation time. It is questionable as to

whether a microcontroller would have the processing power to implement such a control

algorithm.

The programming of a microcontroller can often require proprietary software and

hardware, adding a lot of cost to this approach. Most microcontrollers can be

programmed via writing C or assembly code and then downloading it to the

microcontroller.

The microcontroller would have to be installed on a circuit board with auxiliary

circuitry including power supplies, external pull-up and pull-down resistors and filtering

capacitors. In many cases demonstration boards are available for purchase. In addition, a

Digital to Analog converter would be required to provide the reference voltage for the

DC Drive.

The validation of such a controller would be very involved. External

communications monitoring hardware would most likely be necessary. Troubleshooting

could prove very difficult for a microcontroller based controller.

2.3.2.3 National Instruments Real Time Controller

National Instruments offers a Real Time Control module for the PXI platform.

This module uses the LabVIEW Real-time operating system. There are several different

models available, which all have different features. There is a module available that has

an extended temperature operating range and a tremendous amount of processing power.

The extended operating range would work well for our application. These modules are

designed for an industrial environment and would offer many advantages in terms of

reliability.

The programming of the Real Time Control Module is done using a standard

Ethernet link. After the code was written in LabVIEW on any windows or Macintosh

computer it can be written via the Ethernet link to the control module.

The control module would have to be installed in a PXI chassis. These chassis are

designed for modular components. Other modules, such as a CAN communication card

could simply be snapped into place. No external wiring or circuitry would be required.

For reading I2C and CAN traffic there are PXI modules and drivers readily

available. The CAN module offered by National Instruments comes with software

capable of parsing data.

The validation and testing of the controller and steering system would be made

much easier by using a National Instruments Controller. National Instruments originally

started out in the electronics testing business and have since expanded. The built in

troubleshooting and test capabilities could prove invaluable.

Although National Instruments equipment is typically expensive, we may be able

to obtain their sponsorship. The company’s interest in partnering with RIT will most

likely allow for the donation of the majority of the equipment required.

2.4 Velocity Control Concepts

The main focus of the velocity control subgroup is to develop a method to reliably

and quickly alter the G-CART vehicle’s speed. This involves interpreting set points

handed to the communications bus by a higher level navigation computer, and making

corresponding changes to a the vehicle’s throttle and braking systems. For the proposed

G-CART vehicle, both throttling and braking systems are done ‘by-wire’ and involve to

mechanical actuation. Below is a description of controller concepts investigated by the

velocity control subgroup. An analysis of the feasibility of each control method is shown

in section 3.3.

2.4.1 Controller Concept

After much research, it became obvious that a PID controller was necessary as the

controller for the throttle/braking portion of the autonomous vehicle. It was decided that

our system should work similar to how a cruise control system would work. The only

difference being that overshoot would not be a problem as long as the response time was

better and the setting time was reasonable.

To understand why a PID controller was necessary, it is important to understand

what a PID controller is. PID stands for proportional-integral-derivative, each of which

makes up the three parts of the controller. For a PID controller, there is usually a desired

set point that the controller must meet. It is based on error between the desired set point

and the output of the system. The proportional part of the controller is just the error

multiplied by the gain Kp. The integral portion is the integral of the error multiplied by

the gain Ki. Finally, the derivative portion of the controller is the rate of change of error

multiplied by the gain Kd. Kp, Ki, Kd are gains that can be changed in order to meet the

optimal response.

The most basic control system would be the proportional controller. Basically,

what the proportional controller would do is adjust the throttle proportional to the error.

Therefore, the greater the error became the greater the throttle. The problem with that

type of system would be that the closer the car was to the desired velocity, the slower the

car would accelerate and when a fast response time is desired, this type of system is not

reasonable. Also, if the car was traveling up a hill that was steep enough, it may not

accelerate at all.

The next type of controller is the proportional-integral controller. This type of

controller does everything that the basic proportional controller can do and more. The

integral of the speed is distance. Therefore, since the integral of the error is taken, the

integral portion of the controller gives the difference between the distance that the car

should have traveled if it were to have traveled at the desired speed and the distance that

it has actually traveled. This corrects problems that may arise when traveling up hills and

also helps to settle the car into the correct speed and stay there. The integral portion of

the controller removes the need for a tilt sensor to provide another signal to the controller.

It also makes the programming for the controller less complicated.

The final type of controller is the proportional-integral-derivative controller. The

derivative of speed is acceleration. Therefore, it can be seen that the derivative portion of

the controller will affect the acceleration of the vehicle. The derivative portion of the

controller will help the car to respond quickly to changes. For instance, if the car begins

to slow down due to a hill, the controller will see the downward acceleration before the

speed of the vehicle changes significantly, and will therefore respond by increasing the

throttle.

While a proportional or a proportional-integral controller would probably be able

to control the car, a PID controller has all the qualities that the desired vehicle should

have in order to compete. Not only do we want the car to be able to get to a desired

speed, but we want it to reach that speed as fast as possible to ensure that the car is as

close to where it should be as possible.

2.4.2 FPGA Concept

FPGAs are digital ICs (integrated circuits) that contain configurable blocks of

logic along with configurable interconnects between blocks. Design engineers can

program this kind of device to perform a remarkable variety of tasks. Field

Programmable means that the device has not been hardwired by the manufacturer, which

creates the flexibility. Some FPGAs can only be programmed once, while others can be

reprogrammed many times over. This would be similar to CD-R verse CD-RW for data

storage on a disk. One-time programmable (OTP) is the implicit term used in reference

to FPGAs.

FPGAs create a middle ground between ASICs (application–specific integrated

circuits) and PLDs (programmable logic device). An FPGA can be used to implement

large and complex functions that previously had to be realized by ASICs. The cost of

FPGA design is much lower and easier to manipulate for design changes. This means

that small engineering groups can realize hardware and software on a test platform

without major fabrication costs. Some FPGAs contain millions of gates, and can offer

high speed Input/Output interfaces, digital signal processing (DSP), and reconfigurable

computing (RC). RCs are used as a “hardware accelerator” for software algorithms.

FPGA devices are capable of being programmed while remaining resident in a higher-

level system; this is referred as being in-system programmable (ISP). Altera’s Nois II

board was donated to our team as a possible means for a speed control solution.

Figure 2.4.2.1

Nios II Processor System Basics:

The Nios II processor is a general-purpose RISC processor core, providing:

■ Full 32-bit instruction set, data path, and address space

■ 32 general-purpose registers

■ 32 external interrupt sources

■ Single-instruction 32 × 32 multiply and divide producing a 32-bit result

■ Dedicated instructions for computing 64-bit and 128-bit products of multiplication

■ Single-instruction barrel shifter

■ Access to a variety of on-chip peripherals, and interfaces to off-chip memories and peripherals

■ Hardware-assisted debug module enabling processor start, stop, step and trace under integrated

development environment (IDE) control

■ Software development environment based on the GNU C/C++ tool chain and Eclipse IDE

■ Instruction set architecture (ISA) compatible across all Nios II processor systems

■ Performance beyond 150 DMIPS

One of the notable features of the Nios II processor is termed Configurable

Soft-Core Processor. The CPU is in a “soft” design form, contrary to fixed

microcontrollers. Essentially, it is a blank FPGA. This allows the user to configure the

processor and peripherals to meet their needs and then program the system into an Altera

FPGA. Altera offers some ready made Nois II systems design, so that the user does not

have to create a new processor configuration for every design. A Flexible peripheral set

and address maps allow for an exact peripheral set intended for the target application.

Furthermore, Altera’s SOPC Builder design tool fully automates the process of

configuring process features and generating a hardware design that can be programmed

into an FPGA. After the system generation and programming the board, the software can

be debugged through on board execution.

One of the Key ideas discussed in the Quartus II handbook is the

significance of timing in relation to system reliability. A synchronous design implements

a clock signal trigger for all events. All of the registers’ timing requirements must be

must as well. Without such a design the system may be dependent on propagation delays

and create possible glitches. Typically, the data inputs of registers are sampled and

transferred to output on every active rising edge. The outputs of combinational logic

feeding the data inputs of registers will then change values. The internal circuitry of the

registers isolates data output from inputs; therefore instability in combinational logic does

not affect the operation of the design as long as two things are considered. First, the data

input must be stable for the setup time of the register (before an active clock edge).

Second, the data must remain stable for the hold time of the register (after an active clock

edge). If the setup (tSU) or hold time (tH) is not met, output can be set to an intermediate

level between high-low values. In this unstable state, small disturbances, like noise in the

power rails, can cause registers to assume unpredictable valid states. When controlling

the speed of an autonomous vehicle, unpredictable valid states are not an option. The

throttle could be held in an “on” position, the brakes could malfunction or the brakes and

throttle could be active at the same time. System stability is a requirement for a speed

FPGA controller.

2.4.3 8051 Concept

One of the other potential controller options is a Rigel Development

Board, provided through the Electrical Engineering Department at RIT. This board uses

a C515C processor, which is a subset of the Intel 8051. Because this board uses an

industry standard processor, there is a considerable amount of pre-existing libraries and

functions that could potentially simplify controller design.

This control board is used in several RIT courses, and members of the

velocity control subgroup already have experience using this software, which should

reduce the difficulty in implementing this design. In addition, this controller design also

includes 48 digital I/O lines and eight analog inputs. Although the current design should

not require more than four digital I/O lines, this adaptability could provide useful for

testing and data logging purposes. This control board also has

An on-board Full-CAN controller, which would allow for decoding of message from the

automotive CAN bus without extensive software programming.

An on-board DUART, which would allow for simple connection to either an RS-232/485

or I2C communication bus

10-bit A/D converter for analog actuator control

Multiple priority interrupts, which could be manipulated by the controller bus masters in

order to change message priorities

Although the current Rigel boards are available free of charge for this project,

they are somewhat obsolete. They operate at 12MHz, with most operations taking 12

machine cycles. This speed is notably slower than the FGPA alternative, and may limit

the effectiveness of this solution. There are newer control boards produced by Rigel that

operate much faster, and are completely backwards compatible. Therefore, if a controller

was designed on this board and it was determined during the testing stage that the

response was too slow, then faster boards could be purchased (~$200) with no software

changes required.

2.5 Emergency Brake Concepts

The E-brake concepts that were considered are divided into two parts, the actual

method of actuating the brake and the type of actuator to be used. The combinations of

these two parts also play a big role on each other, which will be discussed in the next

sections.

2.5.1 Actuating method

The first method is to pull the e-brake from behind as seen in Figure 2.5.1.1 with

the other end of the actuator mounted to the floor panel. This design allows for the

mechanical advantage of the lever to be used but the disadvantage of this is that the

stroke of the cylinder will have to be longer which causes a longer response time for

actuators with slow travel speeds. After testing and taking the worst case of five different

vehicles I came up with a stroke of approximately 4 inches and a load of roughly 130 lbs

for this method of actuation. The biggest benefit of this design is that it is the simplest

and most versatile of the two and probably the most reasonable of the two since the exact

application is unknown, so the system that is designed will have to be easily modified to

meet the vehicle needs.

Figure 2.5.1.1

The second method is to remove the brake lever all together and pull directly on

the cable without any mechanical advantage which can be seen in figure 2.5.1.2. This

design will have a very short stroke compared to the first concept which will lead to a

quick response time which is a very large advantage. The downfall to this is that since we

are not using the mechanical advantage this short stroke is going to have a very large load

which makes the actuators more expensive and less compact. The stroke requirement for

this application is roughly 1.5 inches and a load of roughly 450 lb.

Figure 2.5.1.2

2.5.2 Type of Actuator

There are three types of actuators that were considered air, electrical, and

hydraulic systems. They all have there advantages and disadvantages. And depending on

the method of actuating the brake they also have there advantages and disadvantages.

The air system has very fast stroke rates with high loads which is essential when

time is one of the biggest factors. Air cylinders are also a very simple mechanical device

and therefore also very robust but for this application it is not a very crucial attribute.

Since we will probably only actually use the actuator a few times if any. The downfall of

the air system is the complexity of the overall system and the time it will take to install

the system. When looking at the price of the system it is not far behind an electric system

since there are many more components in the air system, like air compressor, tank,

electric valves, etc.

The hydraulic actuator has many of the same attributes the air actuator has. The

biggest problem with the hydraulic actuator is we don’t have the expertise to install a

system like this and since it is allot like the air the air actuator will be chosen over the

hydraulic actuator.

The electrical actuators are a little more than the air system if you want good

response times but if time could be sacrificed the electrical actuators are much cheaper

than the air systems. Some very good attributes to the electrical system are there

versatility and there ease of installation, which with the time constraint that we are under

is very good since we need time to install theses systems and debug them.

3 FEASIBILITY

Feasibility studies were preformed on many of the design concepts to guide our

team on the direction to proceed. Pugh’s Method and the weighted method were both

used as references while performing the feasibility assessment.

3.1 Bus Architecture Feasibility

The five bus architectures described were analyzed through the use of a weighted

method, which took into account the nine indicators shown on the table below. Each

characteristic is assigned a weight between zero and ten, which is multiplied by the score

given to a particular concept. The sum of all the individual indicators gives the final

feasibility of each concept.

Defining Bus Characteristics

Rel

ativ

e

Wei

ght

I2C

USB PX

I

IEE

E13

84

RS

485

Bus Speed 5.0 5 8 7 10 4

Number of Nodes on the Bus 3.0 5 5 3 8 7

Error Handling 5.0 0 8 4 8 4

Noise Immunity 3.0 3 9 8 7 8

Robustness of Design 5.0 4 7 10 7 8

Simplicity of Design 5.0 10 5 2 2 8

Cost of Components 6.0 9 6 1 4 8

Difficulty of Integration 8.0 9 5 7 2 8

Team Familiarity 8.0 10 2 2 2 5

Score (sum of weighted values)   325.0 274.0 226.0 236.0 317.0

 

Normalized Score   1.000 0.843 0.695 0.726 0.975

Table 3.1.1

This weighted method shows that the I2C method of communication is the most

effective for our application. This is mainly due to the low cost, ease of integration with

existing components, and previous G-CART team experience with the protocol. The

IEEE1384 and PXI concepts were identified to be poor alternatives due to high

complexity and difficulty of integration.

3.2 Steering Feasibility

3.2.1 DC Drive Feasibility

The DC Drive must be capable of driving the Brushless DC motor chosen by the

mechanical engineering steering team. The BLDC motor demands that the drive be able

to supply 36V and peak current of 38.7A. The motor is 3 phase, so the drive must be

capable of driving a 3 phase motor. The Brushless DC motor does not operate directly off

a DC voltage source; however, it has a rotor with permanent magnets, a stator with

windings and commutation that is performed electronically. Typically three Hall sensors

are used to detect the rotor position and commutation is performed based on Hall sensor

inputs.

The team members have very limited knowledge with motor drives and therefore

a more feasible solution was to purchase or request a high power commercial BLDC 3

phase motor drive. The two drives that the team considered were MKS 4351 and aeroflex

ACT5101 both of which is capable of operating at 50A/500V. Some research went into a

lower voltage model, but none were found available.

Constructing a BLDC drive from scratch would likely be a more cost effective

solution, but as mentioned earlier, with limited design time and capability of the motor

drive, it is not feasible to design one from scratch.

3.2.2 Controller Feasibility

The controller concepts described were analyzed through the use of a weighted

method, which took into account the nine indicators shown on the table below. Each

characteristic is assigned a weight between zero and ten, which is multiplied by the score

given to a particular concept. The sum of all the individual indicators gives the final

feasibility of each concept.

Defining Controller

Characteristics Rel

ativ

e W

eigh

ts

FPG

A C

ontr

olle

r

Mic

roco

ntro

ller

NI R

eal T

ime

Con

trol

ler

Processing Power 6 8 7 9

Testability 8 3 3 10

Troubleshooting Capability 8 4 4 10

Programming Difficulty 9 3 5 10

Robustness of Design 6 7 7 8

Simplicity of Design 3 3 4 9

Cost of Components 4 10 7 4

Difficulty of Integration 5 3 4 9

Team Familiarity 5 3 5 7

Score (sum of weighted

values)   252 270 475

Normalized Score   0.53 0.57 1.00

Table 3.2.2.1

This weighted method shows that the National Instruments Real-Time Controller

is the best choice for our application. This is mainly due to the Testability, trouble

shooting capability and programming ease. The availability of drivers and modular

communication cards makes this system very easy to integrate. Being we have not yet

heard a final word on the sponsorship of these components the Cost was rated at 4/10. If

the sponsorship comes through, this would increase this score and make this design even

more feasible. It should be noted that the same type of control algorithm could be

implemented in any of these designs. So although one concept is more feasible, all of the

concepts looked at are certainly capable of fulfilling the needs of this project.

3.3 Speed Control Feasibility

3.3.1 Controller Feasibility

The greatest advantage of a PID controller is its robustness. The three different

error control operations of the controller help to rapidly correct any deviation between the

desired speed and the actual speed. The controller’s ability to quickly correct these

deviations is necessary for proper function of the autonomous vehicle. However, a major

draw back to the PID controller is situations that can disrupt the effectiveness of the

derivative portion of the controller.

There are two situations that occur that causes problems with the derivative

portion of the controller. The first is any sharp change in the desired velocity with

respect to the current velocity. This sharp change would result in an unreasonable size

control input to the vehicle. This may not be a problem for our vehicle due to the fact

that we do not anticipate any dramatically sharp changes in the velocity. The stability

system on board should stop any slippage from causing a spike in the velocity measured.

Also, it is expected that the any changes in velocity would be received from the on board

computer in smaller increments to insure smooth transitions in speed. The second

situation that may be more of a problem is noise. Noise may cause undesirable spikes in

sensor information that would be fed into the controller. Like in the previous situation,

the sharp change would result in an unreasonable size control input to the vehicle. This

could possibly pose a problem for our system.

At this point, even with the problems, a PID controller may still be the best

option. Current cruise control systems use PID controllers as a means to adjust velocity

without many problems. For this reason, a PID controller remains the number one

option. A PI controller may work as an alternative, but it would not be as robust and as

quick to respond to changes, but would accomplish the task.

3.3.2 Velocity Control Feasibility

For our purpose, an FPGA controller seems ideal with respect to the design task at

hand. FPGAs are adaptable, more than fast enough, free of cost to us, and expandable to

meet unforeseen needs. The problems do not lie in the technology, but are inherent in our

team. Our team does not have a license for the software that was provided with the x-

caliber FPGA. Another problem is the time limitations set forth by the Fall/Winter

blocks. None of our team members are familiar with VHDL, and we would not want our

project to fail based on our lack of VHDL knowledge. There are several other options

that can be used to implement a solution, and will be discussed further.

In order to give our team time to acquire a software license and to become

familiar with the VHDL language, the 8051 development board will be implemented as a

primary solution. This development board has more than enough speed to parse the

income I2C and CAN data-streams. At the time this primary software development is

completed, it will be determined whether or not we can use the FPGA to perform the

actual PID control. If the FPGAs are deemed feasible, we will use it in conjunction with

the code already developed on the 8051 board. If the FPGAs are not feasible we will

perform the PID control on the 8051 development board itself.

3.3.3 Emergency Brake Feasibility

The feasibility assessment for emergency brake was assessed using a radar chart

with the key attributes being cost, versatility, durability, reaction time and ease of

installation. In this method the polygon that has the greatest area is the most feasible

system. From this radar chart below it can be seen that the electrical system is the most

suitable for this application. With the air system not far off, but as discussed earlier when

considering versatility, and being able to easily bench test the system the electrical is the

best choice.

01234

low cost

high versitility

high duribilityshort reaction time

easy overall installation Air

ElectricalHydraulic

Figure 3.3.3.1

3.4 Feasibility Conclusion

For the bus architecture, the team selected the I2C protocol. As shown in our

feasibility section, this design proved to be the best fit for the G-CART vehicle. It was

primarily because of the simplicity of this design, as well as our familiarity and

experience with this protocol that it was found to be better than the other alternatives.

Although this protocol does not offer noise immunity or contain internal error checking,

it is believed that this drawback can be overcome by the use of shielded cable and

additional EMI reducing devices. It is not believed that there will be high amounts of

EMI generated by any component of the G-CART vehicle, nor will there be high levels

of interference present in the desert terrain of the course.

The steering subgroup has decided to implement their control algorithm on a

National Instruments Real-Time controller module. This concept was selected because of

its high testability, ease of programming, and robust design. The mechanical G-CART

senior design team (5106) was responsible for selecting the motor to drive this

subsystem. Because no such decision has yet been made, the steering team also chose a

highly adaptable power regulator for this system. The MKS 4351 was selected mainly

because it provides enough power to drive even the most demanding of the concepts

proposed by the 5106 team.

The speed control subgroup has decided to use a hardware implemented PID

control method. Ideally, this control will be performed on the National Instruments Real-

Time controller module. However, until sponsorship with NI is obtained, the team is

current designing an Intel 8051 based solution. A detailed description of the 8051

development board is given in the above speed control concepts subsection. The speed

control group also has decided to pursue the electrically actuated emergency braking

system. Compared to the other braking alternatives, the electrical method was much

simpler to install and provides for simpler bench testing.

4 OBJECTIVES & SPECIFICATIONS

A set a guidelines, design objectives, and performance specifications was

established to assist the team in properly assessing on how successful the outcome of the

project is. The following section of the chapters will go through the different objectives,

specifications, and guidelines that the team agreed upon.

4.1 Design Objectives

There are a number of design objectives that required the attention of the team.

These objectives have to be specified in order for the team to have a list of goals and aims

to achieve. These objectives are listed below:

1) The first objective of the design project is to design a system that will be able to

receive desire velocities and steering angles from the G-Cart club’s bus master

through I2C bus protocol.

2) The second objective is to design the system such that it will also be able to receive

sensory data from the car’s sensors and encoders through CAN bus protocol.

3) The third objective is to design the system in a way such that the system, given the

input above, will be able to drive the steering motor to turn the steering wheel to the

desired angle positions.

4) The system, given the input above, should be able to control the car’s acceleration

and braking system to achieve the velocities requested by the navigation computer.

5) The systems should be designed in modules for the purpose of modular testability and

for the ease of system expansion.

6) The final objective is to ensure that the systems operate reliably and swiftly.

4.2 Performance Specifications

The DARPA Grand Challenge is an autonomous vehicle competition. The

contest requires contestants to successfully create an autonomous vehicle capable of

traversing a timed 175 mile off road desert race. Additionally, vehicles must be able to

stay within given GPS boundary points while avoiding various natural and man-made

obstacles without causing any damage to the course. While the overall task may seem

daunting, our concern is on a much smaller scale. The scope of this project required the

design considerations of three separate entities. These three entities were the steering

control system, the speed control system, and the communication bus that connects the

Navigation computer to the various subsystems.

4.2.1 Steering control performance specifications

4.2.1.1 The response of the steering system, at a minimum, shall respond as quickly as a human operator.

4.2.1.2 The steering system shall be capable of controlling a wide selection of three phase DC brushless motors.

4.2.1.3 The system shall be flexible enough to be able to easily be installed in comparable SUVs.

4.2.1.4 The steering system shall be capable of parsing I2C and CAN network messages.

4.2.1.5 The steering system shall minimize the error between the desired wheel angle and the actual wheel angle.

4.2.2 Speed control performance specifications

4.2.2.1 The Speed control system shall be capable of parsing I2C and CAN network messages.

4.2.2.2 The speed control system shall minimize the error between the actual speed and desired speed.

4.2.2.3 The system shall effectively stop the vehicle in response to a zero velocity command.

4.2.2.4 The system shall be capable to use the emergency brake to stop the vehicle in the case of power loss.

4.2.3 Communication bus performance specifications

4.2.3.1 The communication bus shall robustly transmit data between the navigation system and subsystem.

4.2.3.2 The communication bus shall support the bandwidth required for the network traffic.

It is inevitable that as the project continues, the team will face numerous obstacles

and problems. However due to time constraints, not every issue will be addressed. By

having a list of performance specifications, it will aid the team in prioritizing what is

crucial. This will help manage time more wisely into what problems must be fixed and

which obstacles the team can overlook.

4.3 Safety Issues

To ensure the safety of team members and non members, a set of safety

precautions was established. The project consisted of both electrical and mechanical

system and therefore, the safety precautions cover both aspects of the system.

The design and experiment will be conducted in a closed area. Extreme

precaution must be given when dealing with the steering electrical system, because high

current is drawn to the steering motor. The system should be unplugged, before

mechanical modification is made to prevent injuries. Mechanical modification should

only be done when 2 more members are present in the experimental area.

5 DESIGN ANALYSIS & SIMULATION

5.1 Steering Design and Simulation

The overall system block diagram can be seen in Figure 1.

Figure 5.1.1: Steering System Layout

5.1.1 Motor Power Analysis

The maximum power requirement based on the motor selected by the mechanical senior

design team was 1393Watts. This is an extremely high power requirement. However, we

should never exceed this value. For normal operation, we would only require less than

80% of maximum Power. Additionally, this motor will require a 36V supply.

5.1.2 Motor Analysis

There are many types of motors that can be used for steering, such as:

2 Phase DC Motor (with Brush/ Brushless)

3 phase DC motor (with Brush/ Brushless)

Multi–phase DC motor (with Brush/ Brushless), which is similar to a stepper

motor.

Stepper motor

The brush motor concept does not rely on controlled commutation to run, because

the brushes provide a mechanical commutation. However, this motor does not have as

high reliability as a brushless DC motor. Brush life may limit the lifespan of a Brushless

DC motor. The Brushless DC motor does not have the same lifespan concerns due to the

absence of mechanical contact inside the motor. An extended reliability is thus obtained.

A three phase Brushless DC motor would provide a more even torque distribution

than a two phase DC motor. In addition, an increased accuracy would be achieved.

Parameter Symbol Units Value

Design Voltage V volts 36

Continuous Stall Current1 IC amperes 12.3

Peak Current2 IP amperes 38.7

Voltage Constant +/- 10% KE V/kRPM 16.3

Torque Constant +/- 10% KT oz-in/amp 22

Resistance +/- 10% RM Ohms 0.6

Inductance LM mH 1

Table 5.1.2.1: Motor Parameters

5.1.3 Motor Commutation Analysis

Unlike a brushed DC motor, the commutation of a BLDC motor is controlled

electronically. To rotate the BLDC motor, the stator windings should be energized in a

sequence. It is important to know the rotor position in order to understand which winding

will be energized following the energizing sequence. Rotor position is sensed using

embedded Hall Effect sensors. Whenever the rotor magnetic poles pass near the Hall

sensors, they give a high or low signal, indicating the N or S pole is passing near the

sensors. Based on the combination of these three Hall sensor signals, the exact sequence

of commutation can be determined.

Based on the physical position of the Hall sensors, there are two versions of

output. The Hall sensors may be at 60° or 120° phase shift to each other. The motor

used for this design supplies Hall sensors at 120° phase shift to each other.

Each commutation sequence has one of the windings energized to positive power

(current enters into the winding), the second winding is negative (current exits the

winding) and the third is in a non-energized condition. Torque is produced because of

the interaction between the magnetic field generated by the stator coils and the permanent

magnets. Ideally, the peak torque occurs when these two fields are at 90° to each other

and falls off as the fields move together. In order to keep the motor running, the

magnetic field produced by the windings should shift position, as the rotor moves to

catch up with the stator field.

In the figure below, we can see Hall Sensor Output over two electrical cycles.

The Back EMF will not be measured or used in the Hall Sensor based design.

Figure 5.3.1.1- Figure curtsey of Microchip Technology

Alternative motor commutation would be via an encoder. Encoders can resolve

the position of the motor usually much more accurately than a Hall Sensor system.

However, this added resolution is not that useful to the DC drive. The DC drive only

requires a rough position in order to excite the coils in the proper sequence. Encoders are

typically much more expensive when compared to the simplicity of the Hall Sensor

commutation. Most motors do not come standard with an encoder present. Sometimes

encoders can be purchased as an upgrade.

5.1.4 DC Driver Analysis and Design

There are many different type of drivers out there can be used to control 2, 3 or

multi-phase DC brushless motor. However, the concept of driving is similar. Some

drivers use MOS and some use BJT, the below figure is one example.

Figure 5.1.4.1

Additionally, each driver is integrated differently; some have multiple inputs,

outputs, and Voltage supply requirements. Fore example, driver MSK4351 has 2 different

voltage supply requirements.

Figure 5.1.4.2

5.1.5 Microcontroller Selection

In making the microcontroller selection, the team member first considered the

constraints of the project. Design time and Cost were among the highest priorities that

must be taken into account. Material that may affect the design time includes

documentations, available technical support, and available information and application

notes. Due to the lack of funding of the project, the cost of the microcontroller also

played a major factor in the selection process. The second constraint that was considered

was availability. The product should be in production and available upon order. The

product should arrive at the design facility within a week of ordering. Finally the

performance of the microcontroller was important, but as long as the microcontroller

performance meet the need of the project it is acceptable.

The research carried out by the team members revealed that the three major

manufacturers of motor control microcontrollers were Microchip, Atmel, and Motorola.

Upon further investigation, research finding that microchip’s PIC microcontroller was the

best choice for the project. First of all, all the microcontroller cost about the same, less

than 5 dollars a unit, but PIC’s documentation, information, and application notes were

more readily available than the competitors, which will reduce much of the team’s project

design time. The competitor’s units that were considered were Atmel’s microcontroller

that was using 8051 architecture and Motorola MC68HC based MCUs. To be more

specific, the PIC unit chosen was the PIC18 family product.

Some spec of PIC18 as listed on Microchip’s website as

- Power Control PWM (PCPWM)

- Up to 8 output channels

- Up to 14-bit PWM resolution

- Center-aligned or edge-aligned operation

- Hardware shutdown by Fault pins, etc.

- Quadrature Encoder Interface (QEI)

- QEA, QEB and Index interface

- High and low resolution position measurement

- Velocity Measurement mode using Timer5

- Interrupt on detection of direction change

- Input Capture (IC)

- Pulse width measurement

- Different modes to capture timer on edge

- Capture on every input pin edge

- Interrupt on every capture event

- High-Speed Analog-to-Digital Converter (ADC)

- Two sample and hold circuits

- Single/Multichannel selection

- Simultaneous and Sequential Conversion mode

- 4-word FIFO with flexible interrupts

5.1.6 Microcontroller Programming Synthesis

The steering system utilizes a closed loop control system due to various benefits

over open loop control systems. The use of closed loop control system utilizes feedback

that will increase accuracy and stability of the control system.

The programming synthesis procedure will follow the recommendations from

various application notes from Microchip. Some application notes that can be referred to

during the programming synthesis procedures are:

AN899 for dc brushless motor control using PIC18FXX3.

AN885 BLDC motor fundamentals.

The basic program flow chart can be found in appendix 9.1.

The PIC will be programmed using MPLAB software available in the robotics lab.

5.1.7 Controller Design

The controller designed is an Adaptive Model Controller. The adaptive model in

Figure two is an FIR Filter of length L. Instead of having a fixed linear compensator

where the weight values are not functions of the input-signal characteristics, the adaptive

process automatically adjusts the weights so that for the given input-signal statistics, the

model provides a best minimum-mean-square error fit to a sampled version of the

combination of the zero-order hold and the plant. The LMS (Least-Mean-Square)

algorithm will be employed to compute the weights in the vector W(k).

Figure 1: Block Diagram of the Adaptive Model Control System

Equation 1: Adaptive Model

Equation 2: Forward Time Calculation

Equation 3: LMS Error Signal

Equation 4: LMS Algorithm

Note that μ in Equation 4 is the gain constant that regulates the speed and stability

of adaptation. The larger μ becomes, the faster the adaptation occurs. However, this

increase in adaptation time is counteracted by a decrease in system stability. In practice,

finding μ is an iterative process. Typically a very small number is used as an initial guess

and then system testing should be preformed with different values of μ to determine

stability tolerance.

The forward time calculation is designed to derive x(k) from r(k) such that r(k)

and y(k) are equal. If r(k) and y(k) are equal, then the plant output, g(k), will be close to

r(k), obtaining the control objective.

5.1.8 Controller Communication

5.1.8.1 CAN Traffic Decoding

The National Instruments Real-time controller supports pre-written

drivers for CAN communication. The only hardware that required would be a

PXI CAN communications module. The programming complexity of reading

the desired messages and parsing them would be minimal.

5.1.8.2 I2C Message Decoding

The Decoding of the I2C network traffic would be more difficult

because the message format is a G-CART proprietary design. Therefore some

decoding software would have to be written in order to obtain the correct

command signals.

5.2 Speed Control Design and Simulation

The design process is still happening, as is the case with most projects. The more

that is learned, the better the design gets. The team is currently investigating several

methods to implement our design and trying to determine feasibility. The

communication bus between the main navigation computer and bus line controllers will

be I2C. The vehicle will have a throttle by wire system and a brake by wire system will

be installed by Continental Teves. The vehicle CAN bus will provide a means of data

acquisition, as well as a means of sending CAN control messages to the master brake

cylinder and throttle position motor. The CAN system provides data updates every seven

milliseconds, which is more than fast enough for our expected needs. The car can not

react faster than the CAN system updates, thus we should have enough time to give

commands, test results and correct for over/under compensations of the PID controller.

Figure 5.3a shows a comprehensive system overview.

FIGURE 5.3a – Expected data flow for speed control

An important part of this design is to ensure timing control, since multiple

readings are coming from the same CAN system. Each reading from the CAN bus could

happen before or after a speed adjustment by the controller. The buffers are wiped

(loaded with the most negative number of the range) before every seven millisecond

CAN update, so the controller can determine relevant data. If the system is in a state of

no change the buffers will contain data out of the usable range. When there is a

significant error, it will be added to the desired change in speed. The greater the required

change in speed, the faster the vehicle will try to attain the desired speed. The PID will

create its own acceleration rates. The acceleration adjustment will become relevant in

such instances as steep inclines and decline. The goal is to achieve the desired speed as

fast as possible and to maintain constant speed when it is requested.

To get a feel for a vehicle response, our team manipulated the Simulink automatic

transmission model. The model allows for several modifications that can be help model

the performance specs of the Toyota Sequoia. Since there is no vehicle available to us,

we need to understand the throttle and braking reactions to given input. Figure 5.3b

shows the model diagram. The automatic transmission model yields results for passing

maneuvers, gradual acceleration, hard braking, and coasting functions. Output is given in

terms of engine RPMs and vehicle speed.

FIGURE 5.3b – automatic transmission simulation model

FIGURE 5.3c – vehicle input for coasting and hard braking.

FIGURE 5.3d: vehicle output for coasting and hard braking - y-axis is speed in mph

(yellow) and 25% throttle (purple). The x-axis is time in units of seconds. The vehicle throttle is active from 0-5

seconds followed by a coasting period from 5-25 seconds. The brakes were applied at the 25 second mark as

indicated by the increased negative slope.

The goal is to acquire the real vehicle response through data logging. There are

data logging tools available that will tap into the CAN system and record the response to

test drive conditions. Continental Teves has also stated that they are willing to share the

vast test data they have. The data in conjunction with a CAN simulator should allow

sufficient vehicle modeling in the lab. The hope is to have a functioning system by the

time the G-Cart team receives an SUV. The controller will only have to be tweaked for

specific vehicle performance.

The initial steps are to get the CAN and I2C simulator to properly talk to the 8051

board. The focus will then turn to modeling vehicle performance. At this point the speed

of the 8051 board will be assessed for proper response time and overall performance.

The 8051 board allows for easy processor upgrades, if the performance is not

satisfactory. Parallel to the 8051 design will be an FPGA design attempt. The lack of

experience with FPGA design leads to its secondary position in the design schemes. If

our investigation of FPGA design proves feasible, within the time constraints, than it may

become the primary design. A third possibility lies in an 8051/FPGA combination

design. For now the speed control team will stick with the 8051 implementation. The

message structure for the I2C bus was determined by the Executive Board for compliance

with there systems, and CAN protocol is standardized. Continental Teves will provide

vehicle specific addressing for their systems, based on the vehicle acquired by the G-Cart

team (and Al Simone).

Another consideration is with respect to PID verses a PI controller. The 8051

board uses a derivative of Assembly Language. Current efforts are focused on the PI

control program development. Upon completion, need for PID system stability will be

determined. It may be difficult to conclude with out the specific vehicle at our disposal.

The intent is to prove viability without a vehicle.

6 FUTURE PLANS

6.1 Schedule

The following chart illustrates the proposed timeline for this coming winter. The

schedule shows projected start and finish dates for each activity. This schedule assumes

that an exact vehicle will be obtained by the start of the next quarter.

Figure 6.1.1

6.2 Budget

Currently RIT has given a grant of $5,000 for the G-Cart team which $2,000 has

been allocated to both the navigations and controls senior design teams with the rest

being used to promote extra funding. Therefore, we are trying to get many of our part

donated, so that this budget can be met.

7 CONCLUSION

The senior design team focused the six facets of design: Recognizing and

Quantifying Needs, Concept Development, Feasibility Assessment, Design Objectives

and Performance Specifications, Synthesis and Analysis, and final Preliminary Design.

The goal of this senior design team was to provide engineering assistance to the

RIT G-CART club in the development of vehicle steering and speed control. Our

engineering knowledge as 5th year electrical and mechanical students proved to be very

helpful to the RIT G-CART club which has many younger members. Our senior design

team was able to bring a more formal design process to the table and help to organize the

different facets of the design process for the greater G-CART project.

Extensive research and concept development efforts were undertaken. Our design

process was forced to be very flexible as many factors were influencing our design

choices. The RIT G-CART club is still in the process of obtaining a vehicle for the race.

They have narrowed the choices to a few select models. This long selection process has

increased the need for design flexibility and modularity.

Going into the winter quarter, there is a tremendous amount of work left to be

done. This quarter has proven to be a project that required more expertise in team work

and project management than in actual hardware design. There are many challenges

associated with working in such a large team effort.

8 REFERENCES

[ 1 ] Microchip Technology Inc, Application note AN899 – “Brushless DC Motor Control

Using PIC 18FXX31” (DS00899)

[ 2 ] Microchip Technology Inc, Application note AN857-“Brushless DC Motor Control Made

Easy” (DS00857)

[ 3 ] Microchip Technology Inc, Application note AN885-“Brushless DC Motor

Fundamentals”(DS00885)

[ 4 ] Brushless DC motor drive for steer-by-wire and electric power steering applications.

Rodriguez, F.; Uy, E.; Emadi, A. Electrical Insulation Conference and Electrical

Manufacturing & Coil Winding Technology Conference, 2003. Proceedings, Vol., Iss.,

23-25 Sept. 2003. Pages: 535- 541

[ 5 ] Input current shaping in brushless DC motor drives utilizing inverter current

control. Skinner, J.; Lipo, T.A. Electrical Machines and Drives, 1991. Fifth

International Conference on (Conf. Publ. No. 341), Vol., Iss., 11-13 Sep 1991.

Pages:121-125

[ 6 ] Maxfield, Clive. The Design Warroirs’ s Guide to FPGAs. Newnes Publications, 2004. 1

– 22

[ 7 ] Altera Corporation. Quartus II Handbook, Volume 1. June 2004. Sections 6–1 to 6-16

[ 8 ] DARPA Grand Challenge. Rules. http://www.darpa.mil/grandchallenge. October 8th

2004. 1 – 31.

[ 9 ] HowStuffWorks, Inc. How Cruise Control Works. http://auto.howstuffworks.com/cruise-

control13.html. 1988-2004. 1-2

[ 10 ] Auto Week. 2002 Toyota Sequoia. http://www.autoweek.com?articleId=3383.

December 3rd 2001. 1-7

[ 11 ] CAN in Automation. Can Specifications 2.0, Part B.

[ 12 ] Modbus.org. MODBUS over Serial Lines Specification & Implementation guide.

http://modbus.org/ . December 2nd 2002. 1 - 44.

[ 13 ] Phillips Semiconductors. The I2C-Bus Specification Version 2.1. January 2001. 1-46.

[ 14 ] National Instruments. Serial Instrument Control. http://www.ni.com. 2004. 712 – 721.

[ 15 ] Lipowsky Idustrial-Elektronik. CAN-Tools Mikrocontroller. http://www.dgeinc.net.

2004. 1-5.

[ 16 ] Widrow, Bernard. Adaptive Signal Processing. Upper Saddle River, NJ: Prentice-Hall,

1985.

9 APPENDIX

9.1 Steering control PIC Program Flow chart

Figure 9.1: Main loop

Figure 9.2: Interrupt service routine