Prospect 12 (2007 Grand Challenge)
After five vehicles completed the 2005 Grand Challenge, led by a team from Stanford University, DARPA determined that the problem of off-road autonomous navigation had been solved for military purposes. However, the problem of on-road autonomous navigation within an urban setting remained unsolved. In May of 2006, DARPA announced the creation of The Urban Challenge. The challenge stressed the difficulties of making an autonomous vehicle drive within a complex urban network, including loss of GPS coverage, intersections, lane changing, merging, and parking – all while obeying proper traffic laws.
PAVE participated in the Urban Challenge with Prospect Twelve, a 2005 Ford Escape Hybrid modified for drive-by-wire operation and fitted with several stereo and monocular cameras.
Drive By Wire Modifications
The Ford Escape Hybrid came standard with an electronic throttle, electronic power assist steering, and an electronically controlled regenerative braking system. Rather than build actuators for these systems, we decided to interface directly with the vehicle’s existing electronic systems. Our custom electronics were housed in a purpose-built case mounted in the engine compartment.
Two LabJack UE9 data acquisition units interface d between the custom circuitry and the vehicle’s computers via TCP/IP, allowing us to control both digital and analog I/O operations on our servers.
Custom circuitry took the outputs from the LabJacks and shapes the pulses to mimic the vehicle’s throttle position sensor, brake pedal position sensor, and steering torque sensor. The outputs were then connected to the corresponding inputs to the vehicle’s Engine Control Unit (ECU). When the input lines to the ECU were switched to the circuitry outputs, the car was fooled into thinking a person is behind the wheel actuating the pedals and turning the wheel.
The signals from the on-board vehicle speed and ABS wheel sensors were fed in to the LabJacks, providing dead reckoning estimation. Auxiliary circuits controlled turn signals, brake lights, horn, and audible and visual alarms.
An absolute rotary encoder provided by Posital-Fraba was mounted near the steering column and provides steering position feedback via an ethernet connection.
Power / Computing Systems
Although the vehicle was equipped with a 330 V battery, we determined that it was adequate to run all of our additional systems off the regular 12 V system. Therefore, a 1500 Watt inverter/charger was added to constantly supply power to Prospect Twelve’s systems. Like Prospect Eleven, the inverter/charger only charges the 12 V battery when the vehicle is off and plugged in to a conventional outlet.
All of Prospect Twelve’s processing requirements were handled by four independent servers each custom-built with off-the-shelf parts. Each computer had a Core2Duo processor and 4 GB of DDR2 RAM, and each was housed in a standard 1U server enclosure and mounted to small 12U rack with shock-absorbent rubber feet provided by Shock Tech. The computers were networked with a gigabit-ethernet switch. Two routers, one configured as a wireless client and one as an access point, allowed the computers to connect to the internet and developers to connect remotely. Most of the peripherals were connect ed via USB, with the exception of the cameras which all interface using firewire.
Software
All of Prospect Twelve‘s servers ran on Microsoft Windows Server 2003. The choice to run Windows was made because it allowed us to easily develop code using the Microsoft Visual Studio IDE, and also because many of the sensors and peripherals we connected already had Windows-compatible drivers. The vast majority of our code for the Urban Challenge was written in C#, with the exception of our vision code, which was written entirely in C++.
We chose the then recently released MSRS (Microsoft Robotics Studio) as our software framework for the 2007 Urban Challenge. Robotics systems in MSRS are composed of independent services which communicate in real time to achieve a desired goal. MSRS is composed of two main components: The CCR (Coordination and Concurrency Runtime), and the DSSP (Decentralized Software Services Protocol). The CCR provided powerful concurrency primitives that allowed us to take full advantage of our dual-core machines. The DSSP handled messaging between services and across computers.
When the entire system was up and running, there were over 25 MSRS services running concurrently across our servers.
The services in our vehicle were decomposed into three regimes: Sensing, Planning, and Acting. Sensor inputs were processed by the top layer and fused to form an estimate of the robot’s surroundings. The middle layer was responsible for determining a desired path based on the current sensory information. The lowest level implemented the desired path, and comprised all the software modules responsible for communicating with Prospect Twelve’s electronic actuators.