G-CART Autonomous Navigation and Controls



G-CART Autonomous Navigation and Controls 

Senior Design Team 05107

[pic]

Preliminary Design Report

Project 05107

Darren Rowen

Scott Glover

SatSat Fox

Chaichat Boonyarat

Delwin Guiao

Derick Call

Luan Nguyen

1 RECOGNIZE AND QUANTIFY NEEDS 4

1.1 Mission Statement 4

1.2 Project Description 4

1.3 Scope Limitations 5

1.4 Stakeholders 7

1.5 Key Business Goals 7

1.6 Primary Market 7

1.7 Secondary Market 8

1.8 Innovation Opportunities 8

1.9 Background Research 8

1.10 Formal Statement of Work 9

2 CONCEPT DEVELOPMENT 10

2.1 Subgroup 11

2.2 Bus Architecture Concepts 13

2.3 Steering Concepts 18

2.4 Velocity Control Concepts 23

2.5 Emergency Brake Concepts 31

3 FEASIBILITY 35

3.1 Bus Architecture Feasibility 35

3.2 Steering Feasibility 37

3.3 Speed Control Feasibility 40

3.4 Feasibility Conclusion 43

4 OBJECTIVES & SPECIFICATIONS 44

4.1 Design Objectives 44

4.2 Performance Specifications 45

4.3 Safety Issues 47

5 DESIGN ANALYSIS & SIMULATION 47

5.1 Steering Design and Simulation 47

5.2 Speed Control Design and Simulation 60

6 FUTURE PLANS 65

6.1 Schedule 65

6.2 Budget 66

7 CONCLUSION 66

8 REFERENCES 67

9 APPENDIX 70

9.1 Steering control PIC Program Flow chart 70

RECOGNIZE AND QUANTIFY NEEDS

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.

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.

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.

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

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.

6 Primary Market

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

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

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)

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.

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.

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.

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.

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 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.

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 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.

[pic]

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.

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 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.

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.

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.

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.

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.

3 Steering Concepts

1 DC Drive Concepts

Many different approaches were researched, although the final concepts were restricted by the final motor selection.

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:

[pic]

Figure 2.3.1.1.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 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.

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 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.

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.

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.

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 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.

[pic]

Figure 2.4.2.1

[pic]

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.

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.

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.

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.

[pic]

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.

[pic]

Figure 2.5.1.2

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.

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.

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 |Relative Weight |I2C |USB |PXI |IEEE1384 |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.

2 Steering Feasibility

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.

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 |Relative |FPGA |Microcontroll|NI Real Time |

| |Weights |Controller |er |Controller |

|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 Speed Control Feasibility

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.

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 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.

[pic]

Figure 3.3.3.1

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.

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.

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.

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.

1 Steering control performance specifications

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

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

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

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

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

2 Speed control performance specifications

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

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

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

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

3 Communication bus performance specifications

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

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.

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.

DESIGN ANALYSIS & SIMULATION

1 Steering Design and Simulation

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

Figure 5.1.1: Steering System Layout

[pic]

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.

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

4 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.

[pic]

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 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.

[pic]

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.

[pic]

Figure 5.1.4.2

6 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

7 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.

8 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

[pic]

Equation 1: Adaptive Model

[pic]

Equation 2: Forward Time Calculation

[pic]

Equation 3: LMS Error Signal

[pic]

Equation 4: LMS Algorithm

[pic]

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.

9 Controller Communication

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.

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.

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.

[pic]

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.

[pic]

FIGURE 5.3b – automatic transmission simulation model

[pic]

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

[pic]

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.

FUTURE PLANS

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.

[pic]

Figure 6.1.1

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.

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.

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. . October 8th 2004. 1 – 31.

[ 9 ] HowStuffWorks, Inc. How Cruise Control Works. . 1988-2004. 1-2

[ 10 ] Auto Week. 2002 Toyota Sequoia. . December 3rd 2001. 1-7

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

[ 12 ] . MODBUS over Serial Lines Specification & Implementation guide. . 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. . 2004. 712 – 721.

[ 15 ] Lipowsky Idustrial-Elektronik. CAN-Tools Mikrocontroller. . 2004. 1-5.

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

APPENDIX

1 Steering control PIC Program Flow chart

[pic]

Figure 9.1: Main loop

[pic]

Figure 9.2: Interrupt service routine

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

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

Google Online Preview   Download