Download Preliminary Design Review 30 January 2007

Preliminary Design Review
30 January 2007
Black Box Car System (BBCS)
ctrl + z:
Benjamin Baker, Lisa Furnish,
Chris Klepac, Benjamin Mauser,
Zachary Miers
Motivation

Car accidents



Provide proof of who was at fault
Provide information about force of crash
Other traffic incidents

Capture information about what really
occurred if ticketed for speeding, following,
etc.
Concept of Operations:
Goals


Provide visual information of car’s surroundings for
period of time before accident
Use accelerometer to determine if accident has occurred



Removable storage


If programmed acceleration level occurs, BBCS knows a crash
has occurred
Force reading will be saved in conjunction with visual data
Crash video can be viewed on home computer
Autonomous


In event of accident, data automatically saved
Powered by vehicle
CONOPS:
Requirements
Performance Requirements
Video requirements
- Camera outside of vehicle
- 5-20 seconds video recording loop
- 1-5 frames per second
Data storage
-
User interface
-
Video loop written to RAM
- In event of accident, data from each
camera written to Flash memory
Ability to view video of crash on home
computer
- LED indicator if data has been stored
- Ability to manually store/erase data
Block Diagram:
Main
Camera
Accelerometer
Black Box
User interface
Reset
Storage
Block Diagram:
Black Box
Reset
IC
Power
Main
Processor
Accelerometer
Camera
LED
IC
Camera
IC
RAM
or
LCD
Flash
Storage
Computer
Implementation:
Microcontroller

Flash-based, 16/32-bit







ARM
Microchip PIC
MSP430
Re-programmable
On-board ADC, UART, I²C, Timer/counter
Interface to sensors, Flash data log
USB 1.0/2.0 capable
Implementation:
Microcontroller

One main processor to act as a central
processor to control all coprocessors


Video processors, memory, accelerometer, etc.
Our design will use one processor for each
camera module

This will allow us to more easily implement
several video sources if extended
Implementation:
Video



We’re looking to use either a CCD or
CMOS camera as our video sensor.
Ideally we would like to use a camera with
USB output and onboard compression.
Using a webcam oriented device, we’re
hoping to eliminate any need to program
USB drivers. With a corresponding USB
microcontroller, this might be possible.
Implementation:
Video


Camera – STVS6522
Advantages






Only needs a 5V supply
Large range on input voltage (4.1-5.6)
Adjustable Frame Rate
Black and White or Color images
USB 2.0 compliant
Field of depth is infinite with a fixed focus
Implementation:
Video

Disadvantages


Operating range isn’t ideal for a full
automotive design (32-104 F °)
Minimum focus is 20 cm (~8 in)
Implementation:
Video Compression
We assume we are getting raw video from
an un-compressed CMOS camera
Estimated needs:
 Moving JPEG conversion
 Real time video compression (at least fast
enough to convert the first frame by the
time the second frame is taken)
Implementation:
Video Compression
Raw CCD Data
Buffered Storage
IC for Video Processing
I2C or USB to main IC
Storage for video processing
Implementation:
Video Compression

Video Conversion Types



Digital Camera Coprocessor
IC Programmed to do video compression
Ideal Setup:



CMOS Digital Camera coprocessor for digital still and
web cameras
Real time video conversion with 50:1 compression
ratio
I2C or USB data output
Implementation:
Video Compression

Suppliers:




STMicroelectronics
Motorola
BeyondLogic
Digi-Key
Implementation:
Memory

Fast re-writeable memory to buffer image data.

SRAM

Advantages



Disadvantages



Programming simplicity
Control simplicity
Expensive
Limited size
Requirements


Capable of handling 5 frames/sec video input
Low power consumption
Implementation:
Memory

Slow large capacity memory for image
data storage

Flash

Advantages



Disadvantages


Robust
Cheap
Slow access speed
Requirements

Compact Flash interface
Implementation:
Communication

Ideal Solution



I2C
USB 2.0 / 1.0
Fallback

Several I/O ports
Implementation:
Accelerometer



We’re looking at using a MEMS based
accelerometer to detect a crash.
The accelerometer is the central trigger
for the system.
The entire black box is in a looping state
until the accelerometer interrupts and sets
the system into its crash procedure.
Implementation:
Accelerometer


Accelerometer - LIS3LV02DQ
Advantages




3 axes (crash from above?)
I2C/SPI output interfaces directly with
Microcontroller
Factory calibrated with offsets loaded on
startup
Variable sampling frequency
Implementation:
Accelerometer

Disadvantages



2.5 V operation (increasing complexity with
power supply)
Configurable to +/- 2 or 6 gs
Might trigger too easily
Implementation:
Power
We assume we are getting power from a car
battery that varies from 8-16V.
 Estimated needs:


One 12V-1A converter for cameras and
sensors
One 5V-5A and a 3.3V-5A converter for
processors, memory, and other circuitry
Implementation:
Power
Car Battery(8V-16V)
12V-1A Converter
5V-5A Converter
3.3V-5A Converter
Cameras, Sensors, Etc.
Processors, Memory,
Other Circuitry
3.3V Processors and
Circuitry
Implementation:
Power

Supply Types Available:



Linear Voltage Regulators
Switching Converters
Ideal Setup:



12V-1A, buck-boost
5V-5A, buck
3.3V-5A, buck
Implementation:
Power

Designing the Supply


Hard way: Design it by hand, go through
plenty of equations, and have a less efficient
converter than one you can buy for cheap.
Easy way: Go to National Semiconductor, go
to the Power Webench, type in your input
voltage and your output voltage and current
and it designs it for you.
Implementation:
Power

The result for a 12V-1A Supply:
Implementation:
Power

Suppliers:





National Semiconductor
Texas Instruments
STMicroelectronics
Analog Devices
Many, many others
Implementation:
User Interface

Ideal Solution



Plug into computer and all video sources
show up and start to run
On-station displays (LCD or LED on box)
Fallback


Data display in Windows Application (Excel,
Visual Basic, etc.)
Data dump to HyperTerminal convert video
using program then view video sources
Implementation:
Enclosure

Ideal Solution

Custom Plexiglas enclosure




Weatherproof
Transparent (for Expo)
Strong and Shock resistant (protect equipment in the event of
collision)
Fallback Solution



Generic electronics enclosure
Locking metal box
Some foam to lessen shock
Contingency Plan

No video altogether

Instead, base system around inputs of speed,
acceleration, braking, blinkers, lights, etc.
directly from car
Extensions

Other sensors





Speed
Lights, blinkers, brakes
GPS
Four video sources instead of one
25fps, 30 second video loop
Testing

Skateboard with system attached to it




Push skateboard into wall (collision)
Kick skateboard (side collision)
Drop basketball on top of car (falling rocks)
Hold bacon behind car (Cop with false ticket)
Division of Labor









Video: Chris Klepac
Compression: Zach Miers
Power: Ben Baker
Accelerometer: Chris Klepac
Microcontroller and misc. sensors: Lisa Furnish & Zach
Miers
Enclosure: Ben Mauser
User Interface: Ben Mauser
Documentation: All
PCB Design: Chris Klepac & Ben Mauser
Schedule
Questions