RageBraker is a way to provide drivers with a better sense of
how the car in front of them is braking. The device is aimed at
helping drivers avoid rear-end collisions. The device is a brake
light system that shows how hard a car is braking using the size
and intensity of the light. The data is read from a sensor on the
brake pedal and sent to the light. The device can interface with a
standard car network. The alternatives to this device are regular
binary brake lights, which do not change based on brake intensity,
and the BMW brake light system which has 3 modes: off, normal, and
emergency braking which cause the brake lights to flash.Concept
3
Slide 4
RageBraker is a proof of concept for putting brake lights onto
a car network. The end goal would be for the system to come
standard on new cars. The product as displayed could be installed
in a car, but would require calibration. For RageBraker to be
successful it must: Be able to update faster than human reaction
time under high bus loads at a low priority, so as to not hamper
normal car functions. Handle a broken connection by turning off
Have clear enough states for drivers to understand its output.
Operate off of a 12V car battery.Goals 4
Slide 5
Architecture 5 Position Data
Slide 6
Components 6 1.Hall Effect Sensor 2.Pedal with Magnet
3.MC9S12C128 Processor 4.CAN Bus Connector 5.Suction Cup
6.Commercial LED Brake Light (Completely Rewired) 7.12V Battery
(Can use car battery) 8.~10ft cable for power and CAN
Slide 7
We decided to measure: Worst case response time with an idle
load. Sanity test for the ID filtering mechanism. Visual lag with
varying loads provided by two other MCUs on the CAN. Timeout when
CAN is disconnected/resuming operation when restored Worst case
system uptime from power on/reset to LED output (idle load). Data
we found: Effect of growing light pattern on human braking. The
testing without load can confirm that the product could run if the
product is independent of the car. The ID filtering must work for
the receiver to pick up only relevant data. The timeout and system
uptime deal with fault tolerance. A real car network will have many
devices at a higher priority than RageBraker, so we need to test
with a load on the network. All code from the tests has been kept
and can reproduce our results. Experimentation Campaign 7
Slide 8
Our CAN bus is running at 400kbps. Our results are: Worst case
response time with an idle load- 200s ID filtering mechanism
Interfering data did not appear on the LEDs Visual lag with varying
loads- No visual lag with up to a 99.5% load. When the load is
increased to 99.9%, RageBraker does not respond fast enough to be
effective, so the system would need at least 1 in 200 messages.
Timeout when CAN is disconnected/resuming operation when restored-
Lights are set to turn off after ~.2 seconds of no received data.
Worst case system uptime from power on/reset to LED output (idle
load). -800s From a University of Toronto study by Zhonghai Li and
Paul Milgram: Driving simulators that use brake lights that grew in
size and got brighter, We got people to brake 100 to 300
milliseconds sooner. http://www.physorg.com/news93882626.html
Experimentation Results 8
Slide 9
Response time with idle load: 200s is much faster than a human
can notice. With no load RageBraker would never have any lag
problems. The ID filtering mechanism allows for multiple IDs to be
accepted by the receiver. This means code could be added to
indicate when the anti-lock brakes are engaged for example, or
other data. The load experiments are the most encouraging:
RageBraker can be scheduled to send 1 data frame for every 200 on
the bus, and as long as it is not extremely starved, it will work
fast enough. Since most car CAN communication is event based, this
scheduling seems realistic. The timeout experiments shows that if
RageBraker does become starved, or if the CAN bus gets
disconnected, the device will not show false data. Also, when the
connection is restored or data is received, the response is
immediate. The power-on/reset experiment shows that if the power
gets interrupted briefly, RageBraker can be operational again
extremely quickly. The study about human reactions gives us
confidence that our product is useful and will help prevent
accidents. Insights from Measurements 9
Slide 10
The major areas of performance that need to be addressed are:
Usability: Peoples driving styles, attention spans, and reflexes
vary wildly. Further testing on brake light shapes and intensity
patterns may reveal a better approach to get the maximum effect
from the data that RageBraker provides. Response
Time/Starvation/Scheduling: For our testing purposes, RageBrakers
code attempts to send data as much as possible. On a real car
system, this would permanently starve out any devices which have a
lower priority. Also, because most car systems are event driven
rather than scheduled, the worse case starvation time is
theoretically infinite. Tuning the timeout time, and perhaps having
a blinking light state that reflects a timeout vs. the brakes being
off might be better. By testing on a real car system, the
appropriate priority can be determined and the scheduling can be
calibrated. Performance of our System 10
Slide 11
In order to test with load, we made a test rig that consists of
two of the same processors that we use. The one processor sends
messages over CAN to the other, and we set the priority of that
processor higher than RageBraker. We can change how often it sends
messages, so we can attempt to simulate a very simple loaded can
bus. This test rig can be adapted to other CAN formats, and could
be a useful resource for further testing. Other Features 11
Slide 12
We did not get to test on the car node system. We feel that it
would be beneficial to refining our code and ironing down the
specifics of the CAN standard that a sample car uses. We did not
implement the back off mode. We would have liked to do some signal
processing and see if we could effectively extract a pattern. We
did not implement any machine learning algorithms. We received a
lot of negative feedback about the usefulness of the data, and we
do not have extra lights to display the information on. Open Issues
12
Slide 13
What we learned: Staying on top of a project is mostly about
communication. Scheduling combined work times is very difficult.
Splitting up work makes combined sessions that much faster.
Projects always involve more soldering and crimping than you
imagine. What we accomplished: We finish this project with a proof
of concept that should really be able to help solve a serious
problem. We took a idea that was simple and kept it simple. The
system is easy to pull apart and put back together, and the code is
not hard to tweak. We spent well under our budget. What we would do
differently: Many people believe that a brake light that uses
accelerometers for data might be more useful. We would look into
this possibility.Conclusions 13
