1. Embedded Team Coordinator: Ben Brantley Henry Barnor Ezra Birch
David Chen
Tully Foote
Michael Friis
Edward Hsiao
Henrik Kjellander
Jeff Lamb
David Rosen
Alan Somers
Final Design Review Fall Term 2004
Darpa Grandchallenge

2. Embedded Team Scope
Provide a stable and uniform software and hardware platform for the other teams software to run on. (Computing and Hardware)
Provide computer interface to actuators and sensors. (Actuation + SDS)
Establish a convenient, robust, and efficient inter-module messaging system. (SkyNet)
Provide a user interface appropriate for driving the vehicle.

3. Specifications
Control of vehicle actuation capable of the following (defined from time command is issued by planning):
< 2 Seconds lock to lock steering
< ¼ Second to full brake
< ¼ Second to vehicle response to a throttle input
Computing hardware and management to survive 1 CPU failure and provide 6 computers initially, expandable to 12 computers. Including OS and non-race specific peripherals.
A intermodule and intercomputer messaging system capable of:
<10ms latency
>10MB/s bandwidth
Without lost messages

4. Serial Device Server (SDS)
The SDS allows us to connect all serial devices to all computers via TCP/IP. This will allow the computer failure spec to be met. The SDS is a single point of failure, but without it, we cannot meet the redundancy spec.

5. Serial Device Server (SDS) Specifications
-Processor Type: ARM7 44MHz
-Memory: 8MB SDRAM/4MB flash
-32 serial ports
-1 Ethernet port
-SkyNet will talk to each port via TCP/IP
-RJ45 serial ports require physical adapters to DB9
-1U size (will be mounted in rack)
Specs:
-Physical connections robust enough to survive desert driving
-Abstraction layer allows clients to connect a serial device without the SDS, without having to re-write client code
-Round-trip time (total latency) through the SDS is 8 ms
-Can support simultaneous communication to all serial ports

6. Hardware and Computing
Goals:
Provide a stable and uniform software and hardware platform for software to run on.
The software platform must be easily changed within each system should requirements change in the future.
Platform must allow for easy installation of new software
Plan for redundancy (handle up to 1 CPU failure)
Objectives:
Decide on an operating system for race computers.
Use imaging system to keep computers uniform and in sync.
Eliminate moving parts (hard drives) from non-data platforms in race conditions.
Race software will be made to run on a minimum of 512MB of ram.
1 Data platform to provide logging capabilities – 30GB capacity.

7. Hardware and Computing
Current Status:
Procure subset of final hardware – Have 3 at the moment - Order has been placed for another 3
Decide on OS :
Gentoo 10% faster
Install OS on hardware
Basic imaging support
Ensure current/new race software runs on system – verified compilation of race code base.
Problem is simulation code – not distribution specific.

8. Current Resources Managed In Shop and Field Test
1 Print server installed in shop.
1 Distributed compilation machine – P4 3GHZ – reduce compile time and load on laptops. Compatible with race computer setup.
2-3 Development workstations in shop in addition to 8 laptops.
Laptops running Debian distribution.
NFS/NIS on all development machines with local team accounts for non-networked use.
Exploring NFS/NIS solutions for field tests.
2 AP are on order for field test – allow constant wireless.
Field Server provides DNS, DHCP, subversion, Bugzilla and Wiki.
Exploring backup operations for multi-day field tests.

9. Actuation Throttle Steering Brake Transmission E-Stop OBD-II
Atmel controller with three DACs interfacing with the Ford digital throttle.
Position Feedback provided by the throttle position sensor via OBDII
Steering
RoboteQ controller connected to a DC motor
We do not yet know which motor we will be using
Brake
Atmel controller providing a 4 bit digital signal to pneumatic solenoid valves controlling 4 pneumatic cylinders.
Transmission
Winter Term, will be the same as last year. A linear actuator cable pull, controlled by digital pot with serial interface.
E-Stop
Winter Term, requirements unknown. Software implementation only.
OBD-II
Autotap OBD-II converter to serial interface.

10. Timeline December 2004 Field Test Winter Term 2004-2005
Implement throttle control via computer.
Prepare the SDS for use as a pass through for GPS, and for durability testing.
Implement a first level of driving software.
Provide the networking and computers necessary to support the field test.
Winter Term
Provide software and hardware interfaces for steering, brake, throttle, and transmission actuators, as well as accessories.
Provide a functional message passing system between modules.
Have all the computing hardware necessary to run tests setup in Alice.

11. Current Status

12. Summary
Decided on using Gentoo Linux on the race computers and will have at least 3 systems ready for the field test.
Decided on a course of action for most of the actuation systems. Will have a working throttle and possibly working brake and steering.
Determined the messaging format for use with SkyNet. Will not be running for the field test. Operation pushed to Spiral 2.5
Began design of driving software for use on Alice. Will have a rudimentary version operational for the field test.
Lab tests of the SDS have been positive. Will be tested at the field test for durability and the ability to operate with at least one device.