Prospect Twelve
From Princeton Autonomous Vehicle Engineering
Prospect Twelve is a 2005 Ford Escape Hybrid that has been outfitted with various sensors and computing equipment, and has been modified for drive-by-wire operation.
Contents |
Recent News
Overview
The Prospect Twelve project continues where the Princeton DARPA Urban Challenge team left off, improving and rebuilding some of the vehicle's systems to build a robust and reliable autonomous vehicle platform. The project's guiding vision is to create a relatively low-cost autonomous vehicle platform. To that end, we have devised a set of goals and milestones to set the pace for further development.
Short-Term Goals and Milestones
Our short-term goal is to have Prospect Twelve pass the New Jersey state driving test autonomously, and be the first vehicle to obtain its own driver's license. Possible milestones along the way include:
- Perform a Drive-through at the local Wendy's using drive-by-gamepad/iPhone.
- Drive Herrontown Road without accurate GPS guidance
- Parallel Park on Olden Street
- Passing DMV Test
Other short-term goals may include:
- Redo the DARPA site visit challenges, and stress test the vehicle.
- Handle 4-way Stop intersections without an incredible amount of hackery.
- Autonomous Highway driving/high speed driving
Long-Term Goals
The project's ultimate goal is to build a fully autonomous vehicle:
- The user should be able to select a destination and the vehicle would automatically route itself.
- The vehicle would be capable of driving up to highway speeds, and handle various types of paved road, and pass slower vehicles when appropriate.
- The vehicle would obey all traffic laws and restrictions.
- The vehicle would be able to sense react to pedestrians.
- The vehicle would be capable of handling a limited subset of emergency situations safely.
Several longer-term milestones include:
- Enter in the Gumball 3000 Rally and complete (all the highway driving, at least) autonomously.
- Obtain government/grant funding for autonomous vehicle research
- Compete with Penn + NJIT, similar events
Project Administration
Contacts: Questions about this project?
- Project Manager: Josh Newman
- Logistics Manager: Mike Fortner
- Software and Web Services: Alex Ogier.
As our system becomes more complex, it becomes necessary to adopt good policies for the design and implementation of the systems on our vehicle.
- The Design Process is a standard process which should be followed during the implementation of any system on the vehicle, be it hardware or software.
- Prospect 12 has also adopted a set of C++ Style Guidelines in order for all of our code to be uniform and easily understood by all of our developers.
Project Sub-Teams
The Prospect Twelve team is divided into two main sub-teams: Software and Electronics/Hardware. The software team is further sub-divided and organized roughly along the paradigm of Perception, Cognition, Actuation, Substrate and Environment (PCASE).
Hardware
- Sensor Mounting: need people interested in mechanics to mount the physical sensors on the car/enbale us to connect to them and extract information. No programming experience necessay.
Perception
Main Page: Perception
The Prospect Twelve Perception team is responsible for the design and implementation of algorithms and other related software to interface with various sensors, process sensor data to recognize obstacles, lanes, and other environmental information of use to the Cognition team, track this information through time, and provide a representation of the obstacles and boundaries of drivable regions of the environment to Cognition. Applications of perception technologies that are more specific to Prospect Twelve are listed below.
Sensor Interfaces and Detection Algorithms
Interfacing with various sensors to extract meaningful information about the environment surrounding the vehicle (lanes, obstacles, position, velocity, etc.):
- Stereo cameras for mid-range and long-range obstacle detection on the front and rear
- Color monocular cameras for detection of lanes and recognition of signs, traffic signals, and other data of interest.
- RADAR for long-range obstacle detection and detecting the speed of obstacles.
- Ultrasonic sensors for short-range obstacle detection.
- GPS to approximately locate global position of the vehicle and aid in global navigation and route planning.
- IMU to measure the acceleration of the vehicle along various axes; used to calculate vehicle dynamics and track objects relative to the vehicle.
Fusion and Tracking Algorithms
There is another layer of Perception algorithms; the Fusion and Tracking algorithms. Obstacle fusion algorithms are responsible for combining the different detections from various sensors and matching all the data to separate obstacles. Additionally, these obstacles must be tracked through time. The lane tracking algorithm is responsible for taking the output of lane detection and matching it to a projected estimate from previous lane detections, removing any false positives and then generating a new estimate from the remaining data.
Cognition
Main Page: Cognition
Cognition has the tough job of interfacing with multiple sources of data from Perception, and producing a smooth local path that can be followed by Actuation. There are three main components to Cognition: Global path planning, State Estimation, and Local Navigation/Path Planning/Generation, each of which is described in a little more detail below.
State Estimation
State Estimation sits in a grey area between Perception and Cognition, but since there is usually heavily relied upon by many other modules, it is part of Cognition. The theory behind state estimation is to provide the system with a good estimate of vehicle motion such that it is possible to then estimate the vehicle's position relative to the environment at future times. Two steps are required for this to be possible:
- Obtain data from GPS and IMU, and other "state sensors" measuring vehicle velocity, acceleration, heading, and position.
- Filter the data to remove noise and apply a vehicle dynamics model to figure out how the vehicle will behave according to current data.
Global Route Planning
This is pretty simple, requiring an interface with software similar to most consumer GPS applications that would allow global route planning and the possibility to dynamically re-plan paths.
Local Path Planning
This is by far the most complicated part of Cognition, and requires several components that are explained in greater detail on the Cognition page.
- Map representation - Take obstacle and lane data represented relative to the vehicle and place them in a efficient map structure for planning purposes.
- Graph search - Find paths that the vehicle is allowed to take within the map.
- Trajectory generation -
- Lattice construction -
- Behavior module - Take directions from global route along with obstacle data and select among a discrete group of behaviors for the vehicle to follow in accordance with traffic laws.
Actuation
Main Page: Actuation
Actuation takes the path from Cognition as an input and has a series of control algorithms that allow the vehicle to follow the path through controlling its steering, throttle, brakes, and gear shifter.
Path Tracking
Path tracking applies a control algorithm to generate a speed and steering command that will allow the vehicle to accurately track the path.
Control/Drive-By-Wire
Finally, there are two more layers of control to be applied to speed, and one more layer of control for steering:
- Speed control takes as input the current and desired speed, and applies a control algorithm which outputs whether the vehicle should throttle up or apply brakes, and by how much. Brakes and Throttle have separate control algorithms that take in current and desired throttle or braking levels and adjust output accordingly.
- Steering control takes as input the current steering angle and the desired steering angle, and applies a control algorithm to determine the amount of steering needed to reach the desired angle.
Actuation interfaces with the various systems through a variety of methods:
- Steering is controlled by sending outputs spoofing the vehicle's own steering wheel torque sensor to the vehicle ECU, thus tricking the ECU into thinking a driver behind the wheel is trying to turn it.
- Throttle is also controlled electronically by spoofing the vehicle's throttle position sensor.
- Brakes are controlled via a PWM signal sent to a motor controller that controls a linear actuator that presses down on the physical brake pedal.
- The vehicle's Gear shifter is controlled by sending electronic signals to an elaborate set of relays and control boxes which operate a linear actuator to select the correct gear.
Substrate
Main Page: Substrate
Stuff below comes from administrative page
Substrate Team
TM:
Main Page: Substrate
Goal: implement and maintain framework for logging all necessary vehicle data during test runs. Also responsible for implementing GUI to display vehicle data in various formats during real-time and playback modes. responsible for maintenance of computers and computing imfrastructure.
Tasks: Logging, GUI, Maintenance logging: design and implement logging framework that is robust and easy to interface with. must be able to write quickly and support playback of sensor data. Programming experience at the level of 126 is necessary. GUI: design and implement a fast GUI to display sensor data and algorithmic outputs in real time and playback mode.
Programming experience at the level of COS 126 is necessary
Environment Team
TM:
Main Page: Environment
Goal: design and implement tests for all algorithms and systems being implemented on the vehicle. Test and generate test reports for later analysis.
Tasks: testing, logistics
- Testing: carry out controlled tests on each system implemented on the vehicle. Generate reports for every single test, and supply the authors of the system with the report and data gathered during the test.
- Logistics: plan for events and work out logistical details; send invitations, reserve rooms, delegate tasks, etc. to ensure events hosted by the group run smoothly.
No programming experience necessary; a great way to learn how all of our systems function.
Business Team
TM:
Main Page: Business
Goal: contact potential sponsors, work with other teams to identify companies to contact
Tasks: Obtain Sponsorship, research companies Obtain Sponsorship: contact companies specializing in sensors, software, and other products related to our research and secure sponsorships from them Research Companies: Identify needs from PCASE teams and research and identify possible companies that can provide solutions.
No programming experience necessary.
These decisions have been made, and PAVE will be moving forward with them assumed. Any concerns should be e-mailed directly to the Project Manager, and we will discuss them.
Getting Started
See some of the links on the main page (especially the ones called Getting Started).
Then take a look at each project page in the next section, and direct questions to anyone whose name is mentioned as "Lead" (or mentioned anywhere). Failing that, try Josh.
Documentation
For a description of what should go into proper documentation, see Documenting Projects.
Documentation (mostly incomplete) of our old code base can be found under Services (this is almost empty, don't worry about it for now).
Project documentation, information and organizational information can be found on the Projects page.
Current hardware documentation is located in Hardware Documentation.
Future Plans
Continue working on the projects above, of course, but also some other ideas.
General Wiki Guidelines
Well, these should be a no-brainer, really. Like any open forum, don't post any defamatory comments or anything solely for the purpose of being rude or hateful. the Project Manager has the authority to restrict access to anyone who does not exercise manners and common sense when posting here. Also, don't edit pages that you have no knowledge about. Don't take jokes too seriously. After all, we are all Princetonians.
