Download design_review - Course Website Directory

1
Hit-and-Run Detection Project
Design Review
ECE 445
September 30, 2015
Eric Stiles
Nick Prozorovsky
Wilson Wang
2
1.0 Introduction
1.1 Statement of Purpose
Hit-and-run incidents are very common and frustrating to deal with. There is little
proof of the accident occurring, and from a police officer or insurance agencies point
of view, the driver is the only person left to pay for the accident. The number of hitand-runs need to be decreased, and one way to do this is to catch the accident on
video. Our product will include a camera mounted in the rear window looking
towards the rear of the car. The device will sense an accident and save the video
recording that was captured. This will help to provide the necessary proof to make the
person at fault pay.
1.2 Objectives
1.2.1 Goals and Benefits

Decrease hit-and-runs

Prove who is at fault for an accident

Provide evidence in the event of post-accident anger

Accident proof for self-driving cars

Proof of accident when car is parked
1.2.2 Functions and Features

Automatic detection of the initial accident with accelerometer

Accelerometer and camera interface with Raspberry Pi
microcontroller

Looping video to save storage space on microcontroller

Provide microcontroller power from car battery that will last 100+
hours while car is off

Microcontroller detection of low car battery to prevent it from fully
discharging
3
Contents
I.
Introduction………………………………………………………………………
2
II.
Design……………………………………………………………………………..
3
III.
IV.
V.
2.1
Block Diagrams………………………………………………………...
4
2.2
Block Descriptions……………………………………………………..
5
2.2.1
Accelerometer Module………………………………………
5
2.2.2
Microcontroller Module……………………………………
6
2.2.3
Camera Module……………………………………………...
8
2.2.4
Voltage Step-Down Circuit Module………………………..
9
2.2.5
Car Battery Module…………………………………………
9
2.3
Schematics……………………………………………………………..
10
2.4
Simulations and Calculations…………………………………………
15
2.5
Software Flowcharts…………………………………………………..
19
Requirements and Verification………………………………………………….
21
3.1 Requirements and Verifications…………………………………………
21
3.1.1 Requirements Summary………………………………………
21
3.1.2 Verifications Summary………………………………………..
21
3.1.3 Input Module…………………………………………………..
22
3.1.4 Control Module………………………………………………..
23
3.1.5 Camera/Data Module…………………………………………
24
3.1.6 Power Module…………………………………………………
25
3.2 Tolerance Analysis………………………………………………………
25
3.3 Ethical Issues…………………………………………………………….
26
3.4 Safety…………………………………………………………………….
27
Cost and Schedule……………………………………………………………….
28
4.1 Cost Analysis……………………………………………………………..
28
4.1.1 Parts…………………………………………………………….
28
4.1.2 Labor……………………………………………………………
28
4.1.3 Grand Total……………………………………………………..
28
4.2 Schedule…………………………………………………………………..
29
4.3 Contingency Plan………………………………………………………...
30
References………………………………………………………………………… 31
4
2.1 Block Diagram
Figure 1: High-Level Block Diagram
5
2.2 Block Descriptions
2.2.1 Accelerometer (1)
Figure 2: ADXL326 Triple-Axis Accelerometer (adafruit.com)
Input(s):
- 5v voltage from microcontroller which is then converted internally by a voltage regulator to 3.3
volts for use within the chip.
Output(s):
- 0-3.3v voltage scaled based on -16g to 16g experience by the sensor.
Description:
- The main data collection sensor is the accelerometer. A piezoelectric sensor or accelerometer
senses force and outputs a voltage, a voltage that our microcontroller will take in and analyze. Our
accelerometer is an ADXL326 Triple-Axis accelerometer. It takes in 5v, converts it to 3.3v internally
(voltage regulator), and then outputs anywhere from 0 to 3.3v scaled and based on the amount of force it
senses (-16g to 16g). The sensor has three outputs, one for each axis of rotation, X, Y, and Z. Most likely,
we will only use one of the axis, the axis coming perpendicular out of the middle of the sensor (we will
call it the Z-axis). This will tell us when the car receives a jolt upwards, which most likely signifies a car
crash or rear-end. The other two axes could possibly be used, but the axis parallel to the car (we will call
it the Y-axis) could accidentally be triggered in the event of a fast acceleration or deceleration. The
remaining axis (X-axis) could get activated in the event of a sharp turn, but could also spike in the case of
a sideswipe, which would be useful. We will have to experiment to find an ideal threshold from one or
multiple axis that will filter out most false-positives while not filtering out any actual positives.
Potentially, we might put multiple accelerometers throughout the car depending on how sensitive and
precise the sensors actually are.
6
2.2.2 Microcontroller (2)
Figure 3: Raspberry Pi Model A+ 256MB RAM (adafruit.com)
Figure 4: Raspberry Pi 2 GPIO Pin Layouts (element14.com)
Input(s):
- 5v voltage from our voltage regulator/step-down circuit. This power will be input through one
of the GPIO pins on the microcontroller.
- 0-3.3v voltage from accelerometer. This value is scaled based on -16g to 16g experienced by the
sensor.
- Camera-out data. The camera will be connected to the microcontroller through the GPIO pins
and the data will be passed and saved onto the onboard storage device (SD card).
7
Output(s):
- 5v voltage to the accelerometer. This value is then converted to a 3.3v voltage that is usable by
the accelerometer sensor for power.
- 5v voltage to the camera.
- Signal to camera. The camera is hooked up to the GPIO pins and the software (see software
flowchart) will communicate with the camera, sending signals to start and stop recording video.
Description:
- The microcontroller is the brain and processor of our device. It receives power from our custom
5v circuit and then powers all of our peripherals, our accelerometer and camera. It receives a signal from
our accelerometer, interprets it, and then signals our camera module. The camera then sends video data
back to the microcontroller, which it then processes and stores. We have chosen to use the newest
Raspberry Pi model as our microcontroller. There are a few tradeoffs however. The Raspberry Pi has a lot
of features that we do not need, which is wasting resources in a way. However, it is the cheapest and most
easily ineffaceable microcontroller on the market. It can easily communicate with external storage such as
an SD card, which an Arduino cannot. It also has a camera module that is more reliable than any other
microcontroller/camera setups as it can send signals and process data lines automatically without any
other resources.
The software on the microcontroller will be written in Python. The settings will first be modified
to bypass any sort of user login when the Raspberry Pi boots up. The startup configuration will have to be
modified so that the Python script is automatically run when the Raspberry Pi turns on. These features
will be implemented so that the execution of our project begins when the Raspberry Pi is powered on
without any other user interaction. The software will then continue to loop until a spike signal (above a
set threshold) is experienced from the accelerometer. The microcontroller will signal the camera to record
one minute clips and delete any clips older than 3 minutes to preserve storage space. When a certain
reading from the accelerometer exceeds the threshold, the Raspberry Pi will continue to wait and record
an extra minute post-accident. The script will then end and shut down the Raspberry Pi to preserve power
as execution is no longer needed. The exact accelerometer threshold is still to be determined. We have
done calculations for force readings from car crashes (see calculations). Once we have the physical chip,
we will calculate actual force readings from the chip in the case of a trunk closing or door slamming
(false-positives that could potentially trigger the microcontroller). We will then find a threshold that
satisfies lesser car crashes and up, but that is higher than all false-positives for maximum efficiency and
performance. At a very basic level, the microcontroller interprets all data and signals all peripherals based
on the analysis of the data.
8
2.2.3 Camera (3)
Figure 5: Raspberry Pi Camera Board (adafruit.com)
Figure 6: Raspberry Pic Camera Board Pin Layout (electroschematics.com)
Input(s):
- 5v voltage from microcontroller.
- Signal lines from microcontroller.
Output(s):
- Data lines to microcontroller.
Description:
For our camera, we chose the Raspberry Pi Camera Board. It takes in 5v power from our
microcontroller, as well as signal lines from our microcontroller. It outputs video data back to our
microcontroller for storage. We chose this camera as it is very good quality, which will be needed to
capture a license plate number, and it already has a device driver written for the Raspberry Pi. It will
receive signals from the microcontroller when it should record video. It then sends the recorded data back
to the microcontroller. This data is stored temporarily on the SD card storage until it is essentially
overwritten with new video data.
9
2.2.4 Voltage Step-Down Circuit (4)
Input(s):
- 12v voltage from car cigarette lighter.
Output(s):
- 5v voltage to microcontroller.
Description:
- The power converter will be a DC to DC buck converter. The input will be 12.6 volts from a car
battery and the output will be 5 volts to the microcontroller. The load for our device will be a varying
current load, ranging from half an amp to one amp. Thus, our buck converter needs a capacitive filter to
handle the fluctuating current.
2.2.5 Car Battery (5)
Input(s):
- None.
Output(s):
- 12v to voltage step-down circuit.
Description:
- The final component of our design is the car battery. This is the overall power source for our
entire project. However, all of our peripherals and components require either 3.3v or 5v, while the car
outputs 12v. Therefore, we need to convert the 12v from a cigarette lighter to 5v in our voltage step-down
circuit so that it can be used by our microcontroller. One of the features of our project is that it can detect
car crashes or hit-and-runs even when the car is off. The car will continue to supply the microcontroller
with power even when the car is off so that it can continue to record. An extra feature we have for our
design is an auto-off feature. We calculated the power consumed by our project, and the amount of power
a car battery can supply before dying (see calculations). We then plan to implement an auto-shutdown
feature in our software that turns off our microcontroller whenever it has used up about 75% of the car’s
battery. In our calculations, we determine the amount of time it would take for our device to take up 75%
of the car’s battery. Once the readings from our accelerometer are almost entirely stable for at least 5
minutes, the car is most likely parked (no small acceleration or deceleration fluctuations). When this
happens, a timer will be set in software, a timer equivalent to using up three quarters of an average car
battery. If the software has been running for the entirety of the timer’s duration without receiving any
more fluctuations from the accelerometer, it will shut down (if it does receive fluctuations, it will restart
the timer as the car is being driven and the battery is recharging). This is an extremely useful feature as
the device will never kill the car’s battery, rendering the car unable to start, despite drawing power from
the car when it is off.
10
2.3 Schematics
Power Converter
Figure 7: Power Converter - Modeled in LTSpice by Eric Stiles on 9/28/15
11
Accelerometer Schematic from Datasheet [2]
Figure 8: Accelerometer schematic
Accelerometer Pin Layout According to [2]
Figure 9: Accelerometer Pin Layout – Designed in Eagle by Eric Stiles on 9/28/15
12
Raspberry Pi Camera Pin Layout [7]
Figure 10: Camera Pin Layout - Designed in Eagle by Eric Stiles on 9/28/15
13
Camera/Raspberry Pi Interface Connections [7]
Figure 11: Camera to Raspberry Pi Connections
14
Output Voltage of Power Converter with 1 Amp Output
Figure 12: Waveform 1
Output Voltage of Power Converter with .5 Amp Output
Figure 13: Waveform 2
15
2.4 Simulations and Calculations
Force Calculations
The output detection of the accelerometer will need to be able to detect a car crash but not record
for smaller vibrations (such as doors/trunks closing, music vibrations, car acceleration…etc). The
ADXL326 Accelerometer outputs a voltage from 0 to 3.3 Volts that correspond to g-force ratings
that it experiences. The range of this accelerometer is -16 to +16 g’s. 0 Volts corresponds to -16
g’s, 1.65 Volts is 0 g’s and 3.3 Volts is +16 g’s. This analog output will be sent directly to a
GPIO pin of the microcontroller. Below is some calculations of possible acceleration/collision
examples a car may experience.
The fastest car recorded (Porsche 918 Spyder) [8] is shown to go from 0-60mph in 2.2 seconds.
The resulting speed of 60mph is 96560 meters per hour by a simple unit conversion. Converting
the hours to seconds and dividing the speed by the total 2.2 seconds results in an acceleration of
13.41 m/s2. As one G-force is rated at 9.81 m/s2, the resulting G-force experienced by the car
traveling at its fastest acceleration is 1.368 G’s.
In a test done by The Motor Insurance Repair Research Centre, multiple cars ranging from a
mass of 1000 kg to 1400 kg were impacted by a test bumper to simulate a rear ending collision
[6]. The minimum change in velocity of the tests was 10.2 km/h over 92 ms. This change in
velocity is equivalent to 10,200 m/h over 92 ms which results in a 30.79 m/s2 acceleration. This
is equivalent to 3.14 G’s.
The largest impact showed a change in velocity of 17.1 km/h over 69 ms. The resulting G-force
is 7.02 G’s.
Our design needs to ignore simple distractions such as the acceleration of the car (1.368 G’s) and
needs to record events with greater magnitudes of G-force. An example calculation is shown
below for the change of units.
𝑘𝑚
𝑚
𝑚
𝑚
10,200
2.833
2.833
ℎ =
ℎ =
𝑠 =
𝑠 = 30.79𝑚 = 3.14𝑔′𝑠
92𝑚𝑠
92𝑚𝑠
92𝑚𝑠
. 092𝑠
𝑠2
10.2
16
The RaspberryPi microcontroller that will be used in our design operates at an optimal
voltage level between 4.75 Volts and 5.25 Volts. The average current drawn from a RaspberryPi
ranges from .5 – 1 Amp, depending on the application and external devices. Assuming the
maximum case scenario of 1 amp, the power convert below was designed. The voltage source is
assuming a constant DC supply of 12.6 Volts from a car battery. This voltage source is then
regulated down to 5 Volts using a buck converter. The calculations below show how the
inductance and duty ratio values were determined, assuming an allowed output range of 4.755.25 Volts and assuming a constant power output of around 5 Watts. A 50 kHz switch is
assumed.
Power Circuit Calculations
5
= .397
12.6
1
𝑇𝑖𝑚𝑒 𝑠𝑤𝑖𝑡𝑐ℎ 𝑖𝑠 𝑜𝑛 = .397 𝑥
= 7.94 𝜇𝑠
50,000
𝐷𝑢𝑡𝑦 𝑅𝑎𝑡𝑖𝑜 =
4.75 𝑡𝑜 5.25 𝑊𝑎𝑡𝑡𝑠 𝑐𝑜𝑟𝑟𝑒𝑠𝑝𝑜𝑛𝑑𝑠 𝑡𝑜 .95 − 1.05 𝐴𝑚𝑝𝑠 𝑜𝑢𝑡𝑝𝑢𝑡
𝐼𝑛𝑑𝑢𝑐𝑡𝑜𝑟
𝐿
𝑑𝑖
.1 𝐴
𝐴
=
= 12,600
𝑑𝑡 7.94 𝜇𝑠
𝑠
𝑑𝑖
𝑉𝐿 12.6 − 5
= 𝑉𝐿 → 𝐿 =
=
= .6 𝑚𝐻
𝑑𝑖
𝑑𝑡
12,600
𝑑𝑡
Added capacitor in order to account for constant current load:
𝛥𝑉𝑜𝑢𝑡
2
𝐿𝛥𝐼𝑂𝑢𝑡
=
2𝐶(𝑉𝑖𝑛 − 𝑉𝑜𝑢𝑡 )
Where delta I_Out is the fluctuation in the output current. In this case, the minimum
assumed current will be 500 mA and the max will be 1 A, thus the circuit has to handle an output
fluctuation of half an Amp.
17
In order to keep the output voltage regulated between 4.75 and 5.25 Volts, the capacitor
needs to be 79.4 𝜇𝐹. Shown in the designed circuit is a capacitor of 90 𝜇𝐹 and an inductor of .5
mH. This is just minor adjustments to the values after simulating them, caused by modeled nonideal components.
Accelerometer Data Frequency
The Accelerometer has a 32 Kilo-Ohm Resistor with a .1 𝜇𝐹 capacitor across the output.
The frequency of this circuit is shown below:
𝑓=
1
1
=
= 50 𝐻𝑧
3
2𝜋𝑅𝐶 2𝜋(32𝑥10 )(.1𝑥10−6 )
This frequency implies data will be taken from the accelerometer every 20ms. As most of
the data from below shows that rear end collision impacts take anywhere from 65ms to 130ms, a
frequency of 50 Hz should be fast enough to capture a collision.
Car Rear-End Collision Data [6]
Figure 14: Rear-End Collision Data
18
Car Rear-End Collision Velocity vs. Time Graph for Three Incidents [6]
Figure 15: Velocity vs. Time Graph for Collisions
Car Battery
The average car battery is around 70 AmpHours [9]. This implies that a 1 Amp draw on
the battery will be able to last for 70 hours. With a buck converter that has a .397 duty ratio and
an output current of 1 Amp, the input current is only .397 Amps. If a .397 current is drawn from
a 70 AmpHour battery, the battery will last around 176 hours. In order to ensure the battery does
not fully drain, a maximum of .8 x 176 hours will be set for our device. This leaves 150 hours of
life for our device while the car is shut off, and 20 percent car battery remaining at minimum.
19
2.5 Software Flowchart
1. The first thing we want to do is bypass the general login for the microcontroller and then modify
the startup to automatically run our python scripts. This is because our microcontroller will be
mounted in a box for protection, and will not have any sort of screen, monitor, or any user-input
for the user to interface with. We want the interface to be as simple as we can for the user, so all
he or she has to do is turn the device on and it should work as intended.
2. The next step is to start our video recording. Here we want to create a looping effect, so we make
one minute clips. We name them by their current time stamp so that it’s easy to locate the oldest
one when we want to delete old video clips.
3. This is the main recording part of our program. We want to keep recording video for one minute.
We also want to continuously check our accelerometer value to ensure that a crash hasn’t taken
place. This loop just basically is terminated in the event of a crash or time limit expiration.
20
4. If the loop above is terminated by the time limit expiration, which is most likely the case, we
want to stop our video recording. This will create our one minute clip and save it to our storage
device.
5. Next we want to check if there are more than 3 files in the directory of video files. If no crash has
taken place, there is no need to keep all of the extra video footage, so we want to delete the oldest
clip. This also makes it easier if a crash does take place. If we didn’t delete old footage, it would
be time consuming to have to go through all the one minute clips to find which one actually
contained the relevant information. This also ensures that our storage device will never run out of
space and eliminates the need for user-intervention.
6. If there are more than three files in our directory, we delete the oldest one based on its saved
timestamp.
7. This is our actual car crash check. It is checked continuously throughout our execution to ensure
that we don’t miss any relevant data. We will set a threshold that will trigger only during car
crashes, and will also filter out other noise, such as trunk slams or door slamming. This threshold
is to be determined. Once we get our accelerometer, we will test it against various noise falsepositives such as those mentioned above, and compare it to car crash data we found online (can
be found in our calculations section) in order to find an optimal threshold.
8. If our accelerometer signal is above our threshold, then a car crash has taken place. Here we want
to break out of our loop (so that no more recording or deleting takes place). We want to wait an
extra minute to capture some extra footage of the surroundings after the crash.
9. Here we stop our final video clip. The storage device now has all of the data we need to prove
who the offender was.
10. We are now done recording. The user must come and retrieve the information from storage. We
aren’t going to be recording or doing any more processing so we don’t want our
microcontroller/device to use up any more power. We halt our script and power off our
microcontroller.
21
3.1 Requirements and Verification
3.1.1 Requirements Summary
1. Input Module: This module should successfully obtain data from any movement and turn
it into a scaled voltage which is an output to the control module. 25 Points
2. Control Module: This module should take in the voltage from the input module and
control the data module according to the values received. 35 Points
3. Data Module: This module should always be filming, storing, and deleting the video until
the control module is triggered. The data will need to be accessible. 15 Points
4. Power Module: This module should provide enough steady power to the circuit. 25 Points
3.1.2 Verifications Summary
1. Input Module: The data can be tested by manipulating the input module and reading
voltage changes in the control module.
2. Control Module: This can be verified by ensuring that the proper control signals are sent
according to the input module values.
3. Data Module: We will make sure that the video is being stored and will stop recording
after triggered by the control module.
4. Power Module: We will check if the power supply can supply the expected voltage and
current and see if it can power the circuit for an extended amount of time.
22
3.1.3 Input Module
Requirements
1. Accelerometer turns on
Verification
1.
Put the supply voltage into pins 14 and 15.
when hooked up to a voltage
Make sure that the accelerometer is flat. Put a
source between 1.8 V and 5
multimeter in parallel with pin 10 or 12, there should
V.
be an output voltage 1.65V +- .165V.
2.) Regulates input voltage (Vs)
to 3.3V if it is not 3.3V.
2.
Place the accelerometer flat on an object. Check
pins 12 and 10 with a voltmeter. The voltage should be
1.65V +- .165V.
3.) Outputs Vs/2 +- .05Vs V at
0g in the X and Y axis.
3.
Place the accelerometer flat on an object. Check
pins 12 and 10 with a voltmeter, voltage should be
1.65V +- .165V.
4.) Outputs Vs/2 +- .1Vs V at 0g
in the Z axis.
5.) Detects up to 3g +- .3% .
4.
Place the accelerometer on a side. Check pin 8
with a voltmeter.
5.
We will rig up a system that will apply 3g’s of
force that will be detected by the accelerometer. The
accelerometer should be able to accurately detect this
amount. We will have the microcontroller print out the
voltage readings and it should be 3g +- .3% for each
test.
6.) The accelerometer can detect
when the car is not running
6.
The car will be considered “off” if it doesn’t
register any voltage jumps. The microcontroller will
reset a countdown every time it experiences a voltage
change.
23
3.1.4 Control Module
Requirements
1. The Raspberry Pi will stay on
Verification
1.
Connect power through the power pins. The
when connected to 5V+- .25V. microcontroller should turn on and light up.
2.) Ensure the Raspberry Pi
2.
Measure the input voltage using a multimeter.
receives correct voltage from
Ensure that the Raspberry Pi software reading
the accelerometer.
coincides with the multimeter value.
3.) Triggers at anything greater
3.
Set up a function generator to output 2V DC.
than 1.9V +- .1V in the X or Y Input that voltage to the Raspberry Pi (pin 3). The
directions. 2V +- .1V in the Z
control module should trigger and break out of the
direction.
recording loop.
4.) Sends signal to camera to stop
recording after receiving a
certain voltage threshold.
4.The camera should turn off 1 minute after collision
detection. Camera activity should halt and the
Raspberry Pi should shut down after inputting 2V DC
to it from a function generator.
5.) Detects when the
5.When the accelerometer readings don’t register any
accelerometer has a constant
voltage jumps above 1.68 V (Half a g of force) for 5
output (insinuating the car
minutes, the Raspberry Pi’s software timer will begin
being off).
start (pin 7).
24
3.1.5 Camera/Data Module
Requirements
1. Must be able to record
Verification
1. Place the camera on a flat surface. Place a piece of
high quality video. We
paper with words written on it in a car window.
should be able to read
Drive by the camera at 15mph. Check the video to
writing on an object
see if the writing is discernable. See if license plate
moving at 15 mph.
is caught on it. Should be easier to catch something
moving straight on as opposed to something moving
sideways relative to the camera.
2.) The video must be saved
2.) Plug Raspberry Pi into a monitor by using an HDMI
on the SD card and can
cord. Attach a keyboard and a mouse to the monitor.
be accessed.
The video files must be viewable.
3.) The camera must stop
3.) We will run the camera for 5 minutes and then turn
recording every minute
it off. We will take out the SD card and see if the
and save the data,
three latest videos are being saved and older ones
replacing the oldest
deleted.
video if there are already
three saved
4.) Will automatically turn
4.) After the Raspberry Pi detects that the car is off, the
off after 150 hours of the
camera will run for 150 hours. After that time has
car being off.
elapsed, the Raspberry Pi will send a signal to the
camera to stop recording and the entire module will
shut down. We will shorten this to 5 minutes for this
test and perform it 10 times. It must pass all ten
times.
25
3.1.6 Power Module
Requirements
Verification
1. The car battery must provide
12.6V +- .3V
1. Hook up a voltmeter to the power supply.
Ensure that the output is within the
expected range.
2. The voltage step down circuit must
2. Check the output of the step-down circuit
take in the car voltage and step it
with an oscilloscope. The output must be
down to 5V +- .25V
within expected range.
3.2 Tolerance Analysis
This section covers two major concerns when discussing tolerance. The first is the input
power to the microcontroller. Since the device operates optimally between 4.75 Volts and 5.25
Volts and has a current varying from .5 Amps to 1 Amp, the power converter needs to be able to
handle these fluctuations. The dc-dc buck converter used must have a maximum voltage swing
of .5 volts, while achieving an average value of 5 Volts. The current will be simulated by placing
a current load on the converter. A capacitive filter must be used at the output in order to carry
any fluctuating current.
The second concern is the data frequency capturing of the accelerometer. If the frequency
is too low, the accelerometer may not be able to see a 60ms impact. The capacitive value
included in the device allows for a 20ms period. This should be fast enough to capture the
occurrence of an accident. In the event that it is not, the capacitive value can be altered to
increase the frequency.
26
3.3 Ethical Issues
Below are the IEEE Code of Ethics principles that relate to our design and how exactly
the are applicable:
1. To accept responsibility in making decisions consistent with the safety, health, and welfare of
the public, and to disclose promptly factors that might endanger the public or the environment.

If our structural casing of our design is not well secured to the car, it would
dislodge in the event of an accident and could cause harm to others or their
property. Our design will be structurally sound and well secured to the car to
ensure this does not happen.
3. To be honest and realistic in stating claims or estimates based on available data.

Our data collected during testing will not be tampered with or falsified in any
way. Any video taken from the camera will not be tampered with in order to be
used as proof in the event of an accident.
6. To maintain and improve our technical competence and to undertake technological tasks for
others only if qualified by training or experience, or after full disclosure of pertinent limitations.

We have been trained with the online safety programs to have the qualifications
and proper technical competence to be working on this design in the lab.
7. To seek, accept, and offer honest criticism of technical work, to acknowledge and correct
errors, and to credit properly the contributions of others;

We will be working closely with our TA’s, accepting any and all suggestions,
criticism, and experience from them. All credit will be given when work that is
not ours is used.
27
3.4 Safety
To successfully create a usable hit and run camera, we will need to be able to guarantee
that it will be safe for the consumer to use. When using a car battery to power our device, we
need to make sure that none of the wiring to the device will be easily damaged. Damaged wiring
would allow for fire hazards as well as damage to the device. We must also make sure that the
amount of power and current we draw is low enough that there will be no danger of extreme heat
or parts blowing out.
In order to guarantee circuit and human safety, we will properly ground the circuit.
Properly grounding the circuit will prevent the device from shocking the user accidentally.
We need to ensure that the parts are safely enclosed and will not be dislodged during an
accident. Preventing any type of movement of the device will help to ensure the safety of the
occupants of the car during an accident.
Lastly, we will be using components that are safe of hazardous materials, complying with
the Restriction of Hazardous Substances Directive enacted by the EU. All parts will be free of
lead, mercury, cadmium, hexavalent chromium, polybrominated biphenyls, and polybrominated
diphenyl ether.
28
4.1 Cost Analysis
4.1.1 Labor
Name
Nick
Eric
Wilson
Total
Hourly
Rate
$35.00
$35.00
$35.00
-
Hours
Invested
200
200
200
600
Total (Hourly * 2.5 *
Hours Invested)
$17,500
$17,500
$17,500
$52,500
4.1.2 Parts
Item
Manufacturer
Vendor
Adafruit
Amazon
Adafruit
UIUC
Part
Number
ADXL326
Model A+
IN4004
Quantit
y
1
1
1
3
Accelerometer
Camera Board
Microcontroller
Diode (1A)
Analog Devices
Raspberry Pi
Raspberry Pi
Vishay
Variable Inductor
(1mH)
SD Card
Hammond
Manufacturing
Sandisk
DigiKey
1534A
1
-
1
RoadPro
Amazon
SDSDB004G-B35
RPPS-225
Cigarette Lighter
Plug
Total
-
4.1.3
Section
Labor
Parts
Grand Total
Grand Total
Total
$52,500
$80
$52,580
Cost
$17.95
$19.85
$24.95
$4.47
(Have)
$1.80
1
$4.95
(Have)
$3.78
-
$77.75
29
4.2
Week
September 14th
st
September 21
September 28th
October 5th
October 12th
October 19
th
October 26th
November 2nd
November 9
th
November 16th
November 23rd
Schedule
Task
Organize proposal
Determine if power converter is
needed
Begin mock design review
Team Member
Nick
Outline software plan
Calculations for power
converter
Finish design review
Purchase all parts
Design and build test scenarios
for accelerometer
Write software Python code
Program microcontroller to
interface with camera
Wire together power module
Solder microcontroller and
accelerometer connections
Run initial tests on
sensor/microcontroller
interaction
Verify power supply meets
requirements
Run accelerometer test
Initial design for product
housing
Verify software functionality
Test automatic shut-off feature
Prepare mock demonstration
Assemble components to
product housing
Debug microcontroller
interfacing issues
Continue debugging
Run final software tests on
assembled product
Run final hardware tests on
assembled product
Interface design with car
Fix software issues
Fix hardware issues
Prepare presentation
Create powerpoint
Prepare demonstration
Thanksgiving Break
Nick
Eric
Wilson
Eric
Wilson
Eric
Wilson
Nick
Nick
Eric
Wilson
Eric
Nick
Wilson
Wilson
Nick
Eric
Wilson
Eric
Nick
Eric
Nick
Wilson
Nick
Eric
Wilson
Eric
Wilson
Nick
-
30
November 30
th
December 7th
Prepare final paper
Finalize demonstration
Eric
Wilson
Finalize presentation
Nick
Finalize paper
Return parts
Lab checkout
Nick
Wilson
Eric
4.3 Contingency Plan
In the event that time is an issue and not all features of our design are fully implemented, the
following may be done:
1. The automatic detection of low car battery and subsequent shutdown of the camera can
be removed and the battery will drain at consumer’s risk.
2. If the camera module draws too much current over time, the frame rate of the video can
be decreased. This will sacrifice quality for battery life.
3. If the looping process of our camera takes too long and creates a gap in data, the length of
each data segment can be increased. Event record will always occur at the end of the
stored video (do not need to search for accident occurance).
4. Possibly add in a second camera for multiple angles.
5. In the event that 3 g’s of force can not be simulated in the lab, the control module
threshold for triggering an accident can be lowered. This will allow full functionality
testing of our product, which can then be placed into the car back at a 3g threshold.
31
References
1. IEEE Code of Ethics [Online]. Available:
http://www.ieee.org/about/corporate/governance/p7-8.html
2. ADXL326, Rev 0, Analog Devices, Norwood, MA. [Online]. Available:
http://www.analog.com/media/en/technical-documentation/data-sheets/ADXL326.pdf
3. RoHS: Restriction of the use of Certain Hazardous Substances [Online]. Available:
http://www.export.gov/europeanunion/weeerohs/rohsinformation/index.asp
4. Raspberry Pi2 GPIO Header [Online]. Available:
http://www.element14.com/community/docs/DOC-73950/l/raspberry-pi-2-model-b-gpio-40pin-block-pinout
5. OV5647 Datasheet, OmniVision Technologies, Santa Clara, CA, 2009.
6. A. Linder, M. Avery, M. Krafft, and A. Kullgren, “Change of Velocity and Pulse
Characteristics In Rear Impacts: Real World and Vehicle Tests Data”, The Motor Insurance
Repair Research Centre, Tatcham, United Kingdom. Paper No. 285, 2001.
7. Raspberry Pi CSI Camera Interface [Online]. Available:
http://www.petervis.com/Raspberry_PI/Raspberry_Pi_CSI/Raspberry_Pi_CSI_Camera_Inter
face.html
8. 2015 Porsche 918 Spyder Tested: 2.2 Seconds to 60 [Online]. Available:
http://www.caranddriver.com/features/the-2015-porsche-918-spyder-is-the-quickest-roadcar-in-the-world-feature
9. Battery Ratings [Online]. Available
http://www.allaboutcircuits.com/textbook/direct-current/chpt-11/battery-ratings/