Autonomous Vehicle Control System
Team 23
December 1, 2006
Group Leader: Daniel Heinlein
Group Members: Leon Atkinson, Shelby Rollins
Mentor: Matthew Knudson
Document Revision: 1.4
Copyright ©2006 Oregon State University
1
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Guidelines and tips
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Autonomous Vehicle Control System - Project | ECE 441, Study Guides, Projects, Research of Electrical and Electronics Engineering
Material Type: Project; Class: ENGINEERING DESIGN PROJECT; Subject: Electrical & Computer Engineer; University: Oregon State University; Term: Fall 2006;
Typology: Study Guides, Projects, Research
Pre 2010
1 / 32
This page cannot be seen from the preview
Don't miss anything!
Related documents
Partial preview of the text
Download Autonomous Vehicle Control System - Project | ECE 441 and more Study Guides, Projects, Research Electrical and Electronics Engineering in PDF only on Docsity!
Autonomous Vehicle Control System
Team 23 December 1, 2006 Group Leader: Daniel Heinlein Group Members: Leon Atkinson, Shelby Rollins Mentor: Matthew Knudson Document Revision: 1.
Copyright ©2006 Oregon State University
1. Revision History
Revision Description Date Reviser’s Initials 1.0 Initial Version 10/18/2006 DEH 1.1 Rewrote introduction Updated competitive analysis Fixed grammar errors Added sections 3-4.1.
10/31/06 LDA
1.2 Added note about power supplies; reformatted table of contents, section headers, etc.
11/8/06 DEH
1.3 Replaced block diagrams 11/8/06 LDA 1.4 Added block diagram software flow, descriptions and functions; added testing procedures and development plan
12/1/06 DEH, LDA, SGR
- Revision History
- 1.1 Table of Contents
- 1.2 Table of Figures
- Background
- 2.1 Customer Requirements and Product Background
- 2.2 Competitive Analysis - 2.2.1 Product Space Analysis - 2.2.2 Target Feature Set
- Architectural Overview
- 3.1 Implementation Approaches
- Top Level Description
- 4.1 Block Diagrams
- 4.1.1 Top Level Block Diagram
- 4.1.2 Second Level Block Diagram
- Software Flow
- 5.1. Top Level Software Diagram
- 5.1.1. Top Level Software Description
- 5.2. Second Level Software Diagram
- 5.2.1. Second Level Software Description
- Lower Level Software Flow
- 6.1. Initialization Software Diagram
- 6.1.1. Initialization Software Description
- 6.1.2. Initialization Software Functions
- 6.2. State Capture Software Diagram
- 6.2.1. State Capture Software Description
- 6.2.2. State Capture Software Functions
- 6.3. Control Software Diagram
- 6.3.1. Control Software Description
- 6.3.2. Control Software Interface Functions
- 6.4. Actuation Software Diagram
- 6.4.1. Actuation Software Definition
- Testing Procedures
- 7.1. Hardware Testing
- 7.1.1. Input Tests
- 7.1.2. Output Tests
- 7.2. Hardware Application Layer Testing
- 7.3. Operating System Testing
- Development Plan
- References
- 8.1 Naming Conventions
- Figure 1: Spartan-3 MB Development Board 1.2 Table of Figures
- Figure 2: Prototype Expansion Board
- Figure 3: Communications daughter board (with Analog to Digital converter)
- Figure 4: Top level block diagram
- Figure 5: Second Level Block Diagram
- Figure 6: Top Level Software Diagram
- Figure 7: Second Level Software Diagram
- Figure 8: Initialization Block Diagram
- Figure 9: State Capture Block Diagram
- Figure 10: Control Block Diagram
- Figure 11: Actuation Block Diagram
Since autonomous vehicles are still mostly an unproven technology the market for them is strictly limited to research projects both private and government funded. However once our control system is proven to operate we could create a very marketable system that would easily be adapted to different vehicles for a variety of uses.
2.2 Competitive Analysis
Manufacturer Control System Platform Cost Power Req^ Reliability CalTech PC based Ford Van Very High Very High Good UCLA PC based Dodge RAM Med High^ Good Raytheon Unavailable Hummer Truck Extreme High^ Very good Oregon State Microcontroller Mini Baja racer Low Low Good
Analysis Summary: Smaller power requirements (10W versus 1000W for the CalTech system) Low Cost ($15000 versus millions for the Raytheon team) Comparable reliability to the more expensive systems
Note: The summary is limited in detail because each product is a unique prototype created specifically by the manufacture. There is currently no place these can be purchased so price comparisons are not available. In addition much of the technology used is custom made and very confidential so access is limited to the details of their designs.
2.2.1 Product Space Analysis
Caltech[3]
Strengths
- Control system already functional (used in previous DARPA challenges)
- Processing done with actual server computers Weaknesses
- High power requirements (1000W for operation)
- High cost for control system (4 servers used, each approx $4000)
UCLA[4]
Strengths
- Control system already functional (used in previous DARPA challenges)
- All processing done on laptop computers Weaknesses
- High power requirements (140W)
- medium cost for control system (2 PC’s $1200 each)
Raytheon[5]
Strengths
- Software used taken from existing military applications
- Access to proprietary hardware used in military applications Weaknesses
- Extreme cost for system components (all custom equipment military grade)
- Very high power requirements (500 – 1000W)
Oregon State
Strengths
- Very low cost ($785 for development board)
- Very low power usage (10W for microcontroller)
- Very low space requirements (18cm x 18cm footprint)
- System operation is very centralized (easy to troubleshoot) Weaknesses
- Lack of redundancy (no backup systems)
- Limited computer processing power for Artificial Intelligence (1 FPGA)
Missing Features
Our product does not have the high costs and high power requirements of the other competitors. Also our vehicle platform is very lightweight while those chosen by the other manufactures tended to be very heavy (Chevy Tahoe, Cadillac SRX and Dodge RAM.
Why Commonality Exists
Much of the commonality is present to due the time limitations involved for most of the manufacturers. Instead of looking for a better solution they chose to use of the shelf computers. This presented a great opportunity to look for a different solution than the other manufactures where using. By going with the compact microcontroller instead of a computer we are able to make large power and cost savings. In addition we can still maintain real time operation with all of the same features supported by computers on the other teams.
capability from 60 pins to 436 pins and allowing for future expansions such as wireless communication through the Ethernet ports. Also the new controller can operate at 3.3 V versus 5 V on the existing hardware.
The Xilinx board runs on a 5V supply, consuming only 10W at full load and has a small foot print of 18 cm x 18cm x 4cm. In addition the board can operate within the 24 volt dc supplied by the car and withstand vibrations from the vehicles operation.
3.1 Implementation Approaches
Maximum computer power – The approach used here was to pack as much computing power as possible onto the vehicle platform. They used 4 Dell Poweredge servers for all computations. The reason we chose not to implement this design was the very high cost of the servers ($4000 each) and the very high power consumption (1000W).
Personal Computer – Though not as robust as first approach UCLA still chose to use personal computers. They used two Dell laptops to operate their vehicle. While this is a more inexpensive solution they are still priced at $1200 each. In addition the power used was still somewhat high at 140W.
Throw money at the problem – As an existing defense contractor Raytheon had access to million dollar plus military grade hardware systems. This made implementation of their design impossible. Their vehicle was custom fabricated specifically as a platform for their autonomous control system. In addition they used hardware and software developed for military vehicles that are already in production.
Low cost, low power – The design we chose to implement did not follow any of the other competitors. To achieve the goal of low power (10W), low cost ($15000 total) buying computers was not a viable option. Therefore the choice of using a FPGA microcontroller provided the best solution for our chosen design requirements.
4. Top Level Description
The hardware we will use consists of four boards. At the core of the project is the Spartan 3 – MB development kit. We’ll be using its 436 I/O interfaces to control the hardware on the WAVE vehicle. See figure 1.
A prototype daughter board will be connected to two of the P160 interfaces to allow easier access to the IO pins. See figure 2.
A second daughter board will be connected to the other two P160 interfaces allowing the Analog to Digital conversions we need to perform. In the future the WAVE team may further utilize features on it. See figure 3.
Figure 1: Spartan-3 MB Development Board
4.1 Block Diagrams
4.1.1 Top Level Block Diagram
Figure 4: Top level block diagram
4.1.2 Second Level Block Diagram
Engine System^ Manual Start Stop
System Pause System Stop
Laser Measurement (LMS)
Throttle Actuator Shifter Actuator
Rear Right Brake Actuator Rear Left Brake Actuator
Front Brakes Actuator
Light Detection and ranging sensor (LIDAR #1)
Serial Signal Converter (RS 422 to RS 232)
Xilinx Spartan 3 Microprocessor Development Board (Central Processing Unit) (Analog to Digital Converter) (Input/Output Ports)
Light Detection and ranging sensor (LIDAR #2)
Steering Actuator
LMS_OUT
RPM_OUT
Throttle_OUT
Steering_OUT
FL_Brake_OUT
FR_Brake_OUT
B_Brake_OUT
MKill_IN Start_OUT
Pause_IN
Kill_IN
Lidar2_IN_TX GPS3_IN_TX GPS3_IN_RX
Lidar2_IN_RX
Lidar1_IN_TX Lidar1_IN_RX
Lidar2_IN_RXLidar2_IN_TXLidar1_IN_RXLidar1_IN_TXGPS_IN_RXGPS_IN_TX Front Right Wheel Speed (Hall Effect Sensor) Front Left Wheel Speed (Hall Effect Sensor) Rear Right Wheel Speed (Hall Effect Sensor) Rear Left Wheel Speed (Hall Effect Sensor)
LIO0B
FL_Hall_IN
FR_Hall_IN
RL_Hall_IN
RR_Hall_IN
LIOA
RIOB
LIOA9LIOA17LIOA13LIOA
LIOA LIOA
LIOA
LIOA RIOA40RIOA39LIOA39LIOA37LIOA35LIOA
GPS (Global Positiong System)
GPS (Global Positiong System)
GPS2_IN_TX GPS2_IN_RX
GPS1_IN_RX
LIOB16LIOB14LIOB12LIOB
GPS2_IN_TX
Throttle (Potentiometer) Steering (Potentiometer) Laser Measurement (Potentiometer) Front Brakes (Potentiometer) Rear Right Brake (Potentiometer) Rear Left Brake (Potentiometer) Shifter (Potentiometer)
RPM_IN
B_Brakes_IN
Steering_IN
FL_Brake_IN
FR_Brake_IN
Throttle_IN
LMS_IN
IN 6IN 5IN 4IN 3IN 2IN 1IN 0 Engine Status (Potentiometer) IN 7
Engine_IN
GPS (Global Positiong System)
24 volt, 12 volt, 5 volt Supply (not part of design project)
12 Volt Supply
5 Volt Supply
24 Volt Supply
Figure 5: Second Level Block Diagram
Front Right Wheel Speed Sensor 5V* Single output pin
Varying frequency PWM Front Left Wheel Speed Sensor 5V* Single output pin
Varying frequency PWM Rear Right Wheel Speed Sensor 5V* Single output pin
Varying frequency PWM
Rear Left Wheel Speed Sensor 5V* Single output pin
Varying frequency PWM
Engine Start 5V* Single input pin High/Low logic Steering Potentiometer 5V* Single output pin Analog Voltage Throttle Potentiometer 5V* Single output pin Analog Voltage Laser Measurement (Position) 5V* Single output pin Analog Voltage
Front Brakes Potentiometer 5V* Single output pin Analog Voltage Rear Right Brakes Potentiometer 5V* Single output pin Analog Voltage Rear Left Brakes Potentiometer 5V* Single output pin Analog Voltage Shifter Potentiometer 5V* Single output pin Analog Voltage
Engine On
Powered by existing Capacitor wired to spark plugs* Single output pin Analog Voltage GPS1 TX 12V* Serial DB-9 RS GPS1 RX 12V* Serial DB-9 RS GPS2 TX 12V* Serial DB-9 RS GPS2 RX 12V* Serial DB-9 RS GPS3 TX 12V* Serial DB-9 RS GPS3 RX 12V* Serial DB-9 RS LIDAR1 TX 24V* Serial DB-9 RS LIDAR1 RX 24V* Serial DB-9 RS LIDAR2 TX 24V* Serial DB-9 RS LIDAR2 RX 24V* Serial DB-9 RS
4.2 Environment
Our design environment encompasses elements from ECE and CS.
Temperature: Expected operating temperature is 20-50 C Maximum rating is 110 C Minimum rating is -30 C
Applied Forces: Expected not to exceed 0.5 G’s Maximum rating has not been determined No minimum required
Operating System: Nucleus RTOS – supports custom API and embedded microblaze
Hardware Support: ADC, RS422, RS232, PWM, Digital I/O , Ethernet
5.1.1. Top Level Software Description
5.2. Second Level Software Diagram
Initialization^ Machine^ State^ Actuation
Slow Sensors
Fast State Capture Sensors
Control^ Heading^ Path^ Speed
Actuation^ Fast^ Slowest
While Loop
Figure 7: Second Level Software Diagram
5.2.1. Second Level Software Description
Initialization Block
For this portion of the software routine there are 3 main subroutines that will be running. The first is the machine initialization, next is the state initialization and then last is the actuation initialization.
Machine Initialization: Ports, Input Capture, PWM, ADC, Serial, LCD, Interrupt Controller, Operating System