Joel Feinstein Austin Buchan Ben Morse Theodore Martin

1. 18-549: Embedded Systems Design Joel Feinstein Austin Buchan Ben Morse Theodore Martin

2. Team Members Austin Buchan Austin.d.buchan@gmail.com Ben Morse bhmorse@gmail.com Joel Feinstein jnfeinstein@gmail.com Theodore Martin theodore.d.martin@gmail.com http://www.ragebraker.com/

3. Concept 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.

4. Goals 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.

5. Architecture Position Data

6. Components 4 Hall Effect Sensor Pedal with Magnet MC9S12C128 Processor CAN Bus Connector Suction Cup Commercial LED Brake Light (Completely Rewired) 12V Battery (Can use car battery) ~10ft cable for power and CAN 3 6 8 5 1 5 3 2 7 6 4 5 5 4 8

7. Experimentation Campaign 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 MCU’s 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.

8. Experimentation Results Our CAN bus is running at 400kbps. Our results are: • Worst case response time with an idle load- 200µs • ID filtering mechanism – Interfering data did not appear on the LED’s • 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). -800µs 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

9. Insights from Measurements • Response time with idle load: 200µs 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 ID’s 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.

10. Performance of our System The major areas of performance that need to be addressed are: Usability: People’s 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, RageBraker’s 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.

11. Other Features 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.

12. Open Issues 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.

13. Conclusions 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.