Automated Vehicle Solutions, Inc.

© AVS, Inc. This document is the confidential property of Automated Vehicle Solutions, Inc.

Disclaimer

This document is for internal use by the Automated Vehicle Solutions (AVS) only and may not be relied upon by any other party.

Collision Communication System 2.4

Project Progress Report II – CCS2.4

7-Apr-14

Michael Kelly, CEO Patrick Douglas, CTO

Dipto Moni, CPO Pantha Moni, COO

Sachin Mehta, CFO Jacob Owens, CMO

Page 2 of 10

Contents

Project Status Summary……………………………………………………………………………3

Abstract…………………………………………………………………………………………...…4

Introduction/Background………………………………………………………………….……….4

Technical Approaches & Implementation……………………………………….………………..5

Data Logger………………………………………………………………………………....5

LCD Display………………………………………………………………………………...5

Accelerometer…………………………………………………………………………….....5

Wireless Communication……………………………………………………………….…..6

Prototypes & System Configuration…………………………………………………….….6

Results and Evaluation……………………………………………………………………..9

Future Work………………………………………………………………….……………10

Conclusion……………………………………………………………………………………….…10

Page 3 of 10

Project Status Summary

Provide a high-level summary on how the project is progressing with supporting current

examples and comments.

Update the traffic light according to the project’s outlook status.

Green = No major problems,

Yellow = Problems requiring attention,

Red = To be Completed

Overall Project Status Summary Table:

Project Element Status

Planned Actual Forecast Status

1. Schedule

Schedule Commentary:

Plan to follow schedule shown below ON

TIME.

1.1 Phase I – Concept Analysis 02/14/14 02/12/14 Completed

1.2 Phase II – Project Feasibility 02/21/14 02/21/14 Completed

1.3 Phase III – Project Assessment 03/10/14 03/10/14 Completed

1.4 Phase IV – Project Approval 03/16/14 03/16/14 Completed

1.5 Phase V – Implementation 03/14/14 N/A 03/16/14

1.5 Phase VI - Closure 04/19/14 N/A 03/17/14

2. Budget $500.00 $278.23 $221.77

3. Risk Status

Risk Commentary:

Risks of not obtaining ordered parts may conflict with implementation phase of

project.

3. Issue and Change Status

Issues/Change Commentary:

N/A

3. Approvals/Quality

Approvals Commentary:

N/A

For further information about this project please contact:

<Mike Kelly>, <CE of AVS, Inc.>, <(775) 544-2390>,<michaelkelly21@gmail.com>

Page 4 of 10

Abstract:

Automated Vehicle Solutions, Inc. manufactures a specific type of wireless system that provides

vehicle owners with a peace of mind. AVS, Inc. engineers, designs, and maintains the Collision

Communication System 2.4 (or CCS 2.4) which detects any sudden change in a vehicle’s mobility

and then wirelessly exchanges information such as Vehicle Identification Numbers (VIN) and license

plates—revolutionizing hit and run detection. Advanced technologies and protocols were adapted by

AVS, Inc. to develop this revolutionary System that includes everything from Xbee Microcontrollers,

3-Axis Accelerometers, DigiMesh Network Protocol, and Data loggers. Once a collision is detected,

the DigiMesh module activates and searches for a nearby module that has also been activated in order

to compare accelerometer data. If the accelerometer data matches between the systems, Vehicle

Information Numbers (VIN) are traded. These systems are all enveloped in a way that yields a

potential for major hit and run deterrence that will assist law enforcement, insurance companies, and

consumers themselves.

Introduction/Background:

Automated Vehicle Solutions, Inc. is a company whose vision is to revolutionize collision & hit-and-

run detection for the global vehicle consumer market. Our Collision Communication System 2.4

(CCS2.4) is a wireless device that communication between vehicles during accidents and wirelessly

exchange their information which can be later used by law enforcement and insurance companies.

AVS, Inc. brought about this revolutionary wireless system in order to give consumers a sense of

security—knowing that their vehicle will be protected when they are in the grocery store, at the ball

game, or at work. The fact that the suspect vehicle’s VIN number will be collected and stored on

their CCS2.4 system if a collision occurs to their car is important in giving consumers their peace-of-

mind. Every year there are thousands of hit and run accidents which causes millions of dollars in

damage. The CCS2.4 will prevent the victims and their insurance company from paying for the

damage. Installing this product will identify the vehicles that are involved in the accident thus,

fleeing from the scene will become ineffective for the negligent drivers.

The CCS2.4 has vast market potential in all countries with a significant number of automobiles and

law enforcement that has access to all VIN numbers of vehicles on the road. AVS, Inc. see the

United States taking the major market share since over 246 million vehicles are being driven day to

day. In order to market this product in the United States, a state by state approach through the

Department of Motor Vehicles (DMV) would be the most effective solution. Making the CCS2.4 a

required system in every vehicle would make it nearly impossible for a culprit to abstain from the

consequences of a hit-and-run. Although similar products were developed by competitors such as

Siemens Corp., and Brickhouse Security, these products have different constraints such as

installation, weather compatibility, and high cost. On the other hand, the CCS2.4 is there to feed the

mass market with its inexpensive cost and easy installation.

Page 5 of 10

Technical Approaches & Implementation:

In order to complete our design, implementation, and prototype there were many different ‘variables’

that needed to be combined. These ‘variables’ included the LCD Display, 3-Axes Accelerometer,

Wireless Communication (DigiMesh), Data Logger, Arduino, and will be discussed briefly—the

progress of each part—in the following sections.

Data Logger: Keeping track of the real time date and the time is an essential part of the

CCS2.4. The CCS2.4 uses an Arduino Mega board which does not come with the feature of keeping

real time date and time. Thus, a data logger was implemented to accomplish this task. The data

logger comes with a 3V battery pack slot and a SD card slot. The data logger uses very little power

from the on slot battery to keep track of the time and the date. The data logger saves the data into a

256MB SD card. For CCS2.4, the VIN, Time and the Date of the accident are saved in a text file in

the SD card which can be accessed anytime and displayed on the LCD screen.

LCD Display: The LCD is one of the most important aspects of the CCS2.4. The LCD displays the

VIN number of the other vehicle involved during a collision. Additionally, it is being programmed to

display the time of the collision. The LCD allows the user to view these important information

without needing to open up the whole system or connecting it to a computer. The implantation

process of the LCD is fairly simple. It is simply mounted on top of the Arduino microcontroller. The

LCD is powered through the Arduino power port.

The Arduino was programmed to display the VIN as a string on the LCD. Additionally, the Arduino

microcontroller can read data from a text file and display it on the string. The text file reading

capability allows for future feature of scrolling through the LCD. Currently, the LCD only displays

the VIN. In the near future, upon extracting the time from Data Logger, the LCD will be able to

display the time.

Accelerometer: The biggest change to our force measuring is the change from the GY-521 to the

DFRobot board which doesn’t complete A to D conversion on board and doesn’t support I2C

communication protocol. This required a change to connecting each analog output from the

accelerometer to the analog-in on the Arduino instead of sending the digital data down a bus line as

with the I2C protocol. An additional change that came with the DFRobot board is the ability to

manual change the sensitivity between +/-1.5 G and +/-6G via an on-board dip switch. This is helpful

in prototyping with the added flexibility of being able to change the sensitivity without having some

additional digital input and program additions.

The remaining challenges we overcame in this portion of the prototype are in the processing of the

data with the first being the constant voltage level of 1.65V at the A to D on the Arduino. This was

compensated for by subtracting that voltage from our A to D values after the conversion from bits to

volts. This was then followed up by determining the volts per G force used by the accelerometer

which was found by determining the range of volts outputted from the accelerometer across the range

of G forces measured. For the sake of in class testing and prototyping we determined the values for

the +/- 1.5 G sensitivity but when we move to measuring G forces in an accident we will have to

determine the conversion factor for +/- 6 G sensitivity.

Page 6 of 10

The challenges we currently need to overcome in order to have a completed prototype are to

determine and eliminate the causes of noise across our A to D converter. This has to be done in order

prevent possible false positives in accident detection and provide more accurate force vectors for

accident analysis. We will also need to determine the threshold G force for an accident so that we can

determine precisely when to communicate with a surrounding device which will be done via field

testing with our device installed. The last obstacle we plan to overcome is the determination of the

position of our force vectors for better accident analysis which we hope to complete with the simple

use of an inverse tangent command.

Wireless Communication: At the time of progress report 1 we were able to successfully install the

coordinator and endpoint firmware to the Xbee transceivers. They were then configured and one

byte was able to be sent from a computer to an Ardunio. Since then, we have made significant strides

toward our final configuration. As of Progress report 1, there were a few key issues that were

encountered that had to be dealt with. The largest hurdle to overcome was the need of a true peer to

peer network topology. The traditional network configuration that comes pre-installed on the XBEE

is more of a sudo-Star topology where all communication is passed through the coordinator. To

overcome this, we chose to install the DigiMesh firmware because it allows for a peer to peer

configuration and suites the needs of the final prototype. Our next hurdle was to send more than just

one byte of information at a time. The main issue with this was a lack of understanding of the

libraries and functions that were being used. After a little research into how the Serial () function

within the Arduino is implemented, a successful transmission of string data soon followed. This

turned out to be relatively simple to achieve. With a proper network configuration and an

understanding of how to send serial string of data, we were then able to have two systems

communicate independently on the detection of a collision. Going forward we would like to

implement a more effective method of handshaking between devices. Currently, upon detection of a

collision, both systems wait for 500ms and then transmit VIN and crash data. We would like to have

the parked car ping out a request for information followed by the other system responding. This

would allow the systems to know if data was collected correctly and to disengage listening if a

vehicle does not respond. The systems network resolution time will also have to be tested to ensure

both systems are able to switch on, record data, and send information within an acceptable time

frame that has yet to be determined. Current analysis points toward a network resolution of less than

2 seconds would be acceptable however this can defiantly be optimized. We have also begun

exploring the option of reducing the size of our proto type by eliminated unneeded components

known as “shields”. Initial brainstorming sessions show promise and a second prototype with a

reduced form factor is in the works.

Prototypes and System Configuration: The prototype of the Collision Communication System is

based primarily on the Arduino Microcontroller. The following components are included in the

prototype configuration:

- Arduino Mega 2560 MCU

- XBee Series 1 MCU

- DFRobot Triple Axis Accelerometer MMA7361

- Adafruit Datalogger Shield

- Adafruit 16X2 LCD Display

Page 7 of 10

Shown in Fig. 1 is the prototype configuration with all components installed.

Figure 1: Side View of CCS2.4 Prototype

Fig. 2 displays the schematic of the prototype (not including data logger and LCD). The XBee

microcontroller communicates with the Arduino through a serial port. The Arduino Mega best fit our

specifications as the Arduino Uno only has one serial port. Testing and troubleshooting of the

prototype became efficient with the Arduino Mega as a computer can connect to a serial port without

interfering the XBee/Arduino connection.

Page 8 of 10

Figure 2: Prototype Schematic

The flowchart displayed in Fig. 3 describes the logic of the prototype. The system’s accelerometer

will continuously send the Arduino analog data in the form of Force (g) until this force is above a

certain threshold, indicating a collision has occurred. Once a collision occurs, XBee transceiver will

turn on and send or receive data. The role of the XBee is determined whether the system is in a

parked or moving car. If the car is parked, the XBee will become a receiver to receive the Vehicle

Information Number from the car at fault. If the car is moving, the XBee will become a transmitter

to send the VIN to the parked car that experienced the collision.

Page 9 of 10

Figure 3: Flow Chart of CCS2.4

Figure 4: Top View of CCS2.4 Prototype

Results and Evaluation: Currently, the analog data seen from the Arduino contains a lot of noise.

When setting the z-axis to experience strictly the force of gravity, the analog data seen by the

Arduino varies from 1g-1.5g, where the actual value should be static at 1g. To reduce this noise

several methods will be utilized. An example of one of these methods is Delta-Sigma Modulation

which is a method for encoding analog signals into digital signals as found in an Analog to Digital

Converter. The time between collision and data transmission was tested to be about 4-5 seconds.

This time delay will be researched for optimization.

Page 10 of 10

Future Work: The goal for the “product evaluation” deadline is to have two prototypes within

enclosures that are installed onto RC cars for demonstration. This means the systems should be

independent from connecting to a computer to view the data. The LCD display will allow a user to

view the VIN# of the vehicle that hit them along with the magnitude of the force that the system

experienced. The company is also discussing an actual scale demonstration consisting of golf carts

or bumper cars. The CFO is talking with the appropriate associations for this to happen.

Conclusion:

The CCS2.4 is a product developed for the vast market of consumer & industrial vehicles. With it

being a system that exists in each vehicle on the road, it will provide solutions toward the

advancement of real-time vehicle-to-vehicle wireless communication. The mission of AVS, Inc. is to

aid and increase the ability for law enforcement to investigate crimes and persons of interest in car

collisions. With wireless technology being a now common and standard fair in most devices,

implementation in vehicles is the next step to making the roadways and parking lots a safer place.

Turning every car into a, so called, ‘witness’ at the scene of an accident can drastically deter careless

hit and run accidents. There truly are endless applications of this technology and how it could be

used. In time, the wireless exchange of information between vehicles could provide a way for a law

enforcement patrol car to identify cars in the vicinity and provide valuable information of the

vehicles, as to whether it is has been stolen, uninsured, or if it was in a previous vehicle collision.