S17: Halo

Grading Criteria

• How well is Software & Hardware Design described?
• How well can this report be used to reproduce this project?
• Code Quality
• Overall Report Quality:
  • Software Block Diagrams
  • Hardware Block Diagrams

    Schematic Quality

  • Quality of technical challenges and solutions adopted.

Abstract

This project aims to improve the safety of bicycle users on busy roads. Often, it is difficult for drivers in cars to judge the movement of a bicyclist on the road. This problem becomes significant in scenarios where the driver has to follow the bicyclist in dark environments. We propose Halo, a smart helmet which makes bicyclists feel safe and stand out on busy roads thus improving their safety.

Objectives & Introduction

We propose to build a simple yet, powerful system that helps improve the safety of bicyclists on busy roads. The sensors used to build this system are the accelerometer and the ultra-sound sensor. Our objective is to implement all the functionalities listed below

• Designing of Motion Analysis Engine
  • Recording of the accelerometer readings from bicyclists in real time
  • Understanding and interpreting the accelerometer readings
  • Designing an algorithm to detect motion/slow down/stop in real time.

• Designing of the warning system
  • Record data from ultrasound sensors in real time
  • Set thresholds to trigger state transitions

• Wireless interface

• Indicator system
  • PCB design

• Interfacing all functionalities using freeRTOS APIs

Team Members & Responsibilities

• Abhay Prasad
• Revathy
  • Design hardware and software for warning system
  • Develop application Algorithm
  • Build hardware circuit
  • Integrate the functionality to the main project
  • Unit testing, verification, and validation of the module
• Unnikrishnan
• Vishalkumar
• Kripanand Jha

Schedule

This section of the report provides the team schedule for the Halo Smart Helmet project, indicating the milestones to be achieved during the course of the project.

Week#	Date	Task	Actual
1	03/21	Team Discussion on understanding and finalizing requirements; Identify extra hardware requirements	Completed
2	03/28	Design Hardware and Software modules;Finalize on schematic; Purchase h/w components.	Completed
3	04/04	Interface Accelerometer & Ultrasound sensors; Finalise API layer for individual modules	Completed
4	04/11	Implement modules - start/stop detect algo,distance detect algo,Wireless comm,LED-Display Pane	Completed
5	04/18	Interface system with wireless modules; PCB design	Completed
6	04/25	SW & HW unit testing	Completed
7	05/02	System level Integration & testing	Completed
8	05/09	OnRoad testing /Blackbox testing	Planned
9	05/16	Project Demo	Planned

Parts List & Cost

Parts#	Part Name	Quantity	Cost Unit Item
1	Bike	1	Free
2	Helmet	1	Free
3	9 V DC battery	4	3.00 $
4	Wireless Antenna	2	2.20 $
5	SJOne Board	2	80 $
6	PCB fabrication	10	2.8 $
7	Ultrasound sensor	1	6 $

Design & Implementation

Printed Circuit Board

Design

We designed custom 28.2 x 48.8 mm board for our project. The goal of the PCB design was to learn the basics of PCB designing using EAGLE software as it is one of the part of embedded systems. We have added two switches along with two leds for showing left right direction while turning the bike. We added connectors on the board to further connect the switch to external board and also connect the power and ground to the external circuit.

EAGLE Software

To design our board we used AUTODESK EAGLE application. We designed schematics and PCB for our board in EAGLE. This board will be interfaced with SJOne board's gpio, power and GND pin. For the schematic design we used SparkFun library components like switches, leds, connector, resistors. After done with schematics, EAGLE generates board design based on schematics we create. In board design it's on you how you minimize the board space place your components in the board. After done with proper design we can either opt for auto-routing or manual routing thing to route the various components in the board. While routing, use proper values of width and drill size for the route. After done with routing check for any errors in the board connections using ERC and DRC tools. We designed dual layer pcb just for the sake of testing. for the common ground we used ground polygon that makes circuit design simpler. While routing note down the drill size and width of traces it must be sufficient enough to for current flow in the wire.

EAGLE components used

Parts#	Part Name	DEVICE	LIBRARY	PACKAGE
1	LED	LED-3MM-NO_SILK (LED)	SparkFun-LED	LED_3MM-NS
2	SWITCH	MOMENTARY-SWITCH-SPST-PTH-6.0MM (MOMENTARY-SWITCH-SPST)	SparkFun-Switches	TACTILE_SWITCH_PTH_6.0MM
3	Connectors	CONN_04	SparkFun-Connectors	1X04
4	Capacitors	0.1UF-KIT-EZ-50V-20% (0.1UF)	SparkFun-Capacitors	CAP-PTH-SMALL-KIT

Ultrasound Sensor Module

Module Requirement

One of the features of Halo Smart Helmet is to provide a warning signal to the biker when there is vehicle close to him. The Ultrasonic sensor module is used to detect the vehicle range and indicate the warning levels based on the detected range of the vehicles.

This module is required to send, Warning Level 1 when the vehicle is in range 2-3 m Warning Level 2 when the vehicle is in range <=1 m

Algorithm Design

Ultrasound Sensor Module

• Algorithm
  • Create RTOS Task with Medium priority
  • Register for GPIO rising and falling edge interrupts
  • Start Soft timer with period of 200ms
  • Once the timer expires, Trigger the USS module to run in ranging mode
  • On receiving rising edge interrupt, the callback stores the Timer0 value
  • On receiving falling edge interrupt, the callback stores the Timer0 value
  • The Echo duration is calculated using the stored time and Distance is calculated using the above function.
  • The distance is compared with the warning level range and warning signals are updated.
  • The warning signal is sent to the controller task which notify the biker with sound alert.

Motion Analysis Engine Module

Designing the algorithm to detect the state of the cyclist was approached by first recording the data from the accelerometer sensor as the cyclist rides it in a real time environment. The recording for three different cyclists for 10 minutes at 10KHz was done. Each of these recordings made sure to cover all test cases that the system would encounter in real time. An in-sync video of the cyclist riding the bike was recorded in order to serve as the ground truth for evaluating the designed algorithm.

We have used Matlab to prototype the algorithm from the accelerometer readings. The logged data from the cyclists shows the kind of response we obtain for different situations encountered by the cyclist. Below is the plot of the accelerometer readings for a cyclist. As you can see, the high level of noise present in the signal makes it very hard to interpret the state of the cyclist at different time instants.

In order to eliminate noise from the accelerometer values, a moving averaging filter of length 100 was used. The plot of the values in Matlab after performing this simple type of filtering is shown below. It is easy to interpret the regions where the cyclist is in motion. Whenever the accelerometer readings peak and settle (comes back to the settling point and becomes constant), the cyclist can be interpreted to be in motion. We can observe a dip in the graph as soon as the cyclist slows down or comes to a stop. The difference between a slowdown and a stop is hard to interpret looking at the accelerometer readings. After carefully evaluating the signal and comparing it to the ground truths, we were able to finally find a solution to distinguish between the two. A very interesting observation is that there is always a slight deceleration after a stop during the settling of the signal which is not present during slowdowns. This is due to the nature of the breaking system on any vehicle. We have exploited this concept to distinguish a slowdown from a stop.

It is obvious that a stop is always after a slowdown and there is no slowdown after a stop. Concepts such as these have motivated us to implement a state machine as a part of the algorithm. The figure below shows the state machine that we implemented with the help of Matlab. In order to make the algorithm robust to any user, we have tried our best to minimize hard thresholds for state transitions.

The figure below shows the result of the state machine prototyped in Matlab. The regions in green correspond to the cyclist in motion and the ones in yellow and red are the regions for slow down and stop respectively.

The designed algorithm in Matlab was ported to C++ to work on the SJOne board. The moving averaging filter was designed to work in real time as shown in the snippet below. The state transitions code is similar to that of the Matlab code.

The calibration phase is performed during booting and is important to zero offset the values of the accelerometer. This was done as we found the range of the accelerometer readings to vary when using different boards. During calibration, the cyclist is expected to stay in the stopped state for 3 seconds before starting. The mean of these value is considered to be the offset. The calibration offset is now subtracted from the values obtained from the accelerometer in real time to determine the state of the cyclist.

Hardware Design

Discuss your hardware design here. Show detailed schematics and the interface here.

Ultrasound Sensor Module

• Component Description

An ultrasonic distance sensor HC-SR04, using sound waves, can detect an object located within its field of view. It works by sending out high-frequency sound waves (a.k.a Chirps) and receiving the Echo signal from an object in the sensor range. The received pulse width is then measured to find the distance of the object.The ultrasonic sensor can detect objects anywhere from 2 cm to 400cm (157 inches or 13 feet) within 15° measuring angle.A trigger pulse of 10-microsecond is required for the sensor to enter the ranging mode. In the ranging mode, the sensor internally generates 8 pulses of 40 kHz at the transmitter side. The reflected sound wave (Echo) is detected at the receiver side. The Echo pulse is started after Transmission of Chirps is complete and it ends when the last chirp among the 8 pulses is echoed back.

[picture]

Hardware Interface

In this section, you can describe how your hardware communicates, such as which BUSes used. You can discuss your driver implementation here, such that the Software Design section is isolated to talk about high-level workings rather than the inner working of your project.

Ultrasound Sensor Module

The Trigger and Echo pin of the sensor is connected to the GPIO port pins of SJOne board.The trigger is generated by toggling the port pin with a delay of 10us, and the echo receives pins are designed to use GPIO interrupts to measure the pulse width. Since the rising and falling edge of the same pin is not detected, the issue is resolved by using two port pins, for registering EINT3 rising and falling edge interrupts.

Software Design

Show your software design. For example, if you are designing an MP3 Player, show the tasks that you are using, and what they are doing at a high level. Do not show the details of the code. For example, do not show exact code, but you may show pseudocode and fragments of code. Keep in mind that you are showing DESIGN of your software, not the inner workings of it.

Ultrasound Sensor Module

A FreeRTOS task is created for USS module to trigger and detect the Echo pulse at 200 ms cycle. The pulse width is measured by the GPIO interrupt callbacks and distance is calculated using formula

                            Distance = Speed of sound * Echo pulse width/2  
                                     = (340 *100) / (10^6*(Echo/2)) cm/us * tp us
                                     = 0.017 cm/us *  Echo

USS_Init() {

  Timer0_Enable(lpc_timer0)
  Configure_GPIO(Pin2.3,Output)
  ClearGPIOPins(3,4,5)
  EINT3_Enable(Pin2.4,eint_falling_edge,falling_isr_callback)
  EINT3_Enable(Pin2.5,eint_rising_edge,raising_isr_callback)
  TriggerTimerStart(200ms)

}

USS_PeriodicTriggerTask() {

  if(TriggerTimerExpired())
  GeneratePulse(10us)
  startTime = Timer0_Read(lpc_timer0);
  if(xQueueReceive(endtime))
  {
     Echo = endtime-startTime
     Distance= Echo * 0.017 
     SetandBroadcastWarning()    			
  }
  TriggerTimerRestart();

}

Implementation

This section includes implementation, but again, not the details, just the high level. For example, you can list the steps it takes to communicate over a sensor, or the steps needed to write a page of memory onto SPI Flash. You can include sub-sections for each of your component implementation.

Testing & Technical Challenges

Describe the challenges of your project. What advise would you give yourself or someone else if your project can be started from scratch again? Make a smooth transition to testing section and described what it took to test your project.

Include sub-sections that list out a problem and solution, such as:

My Issue #1

Discuss the issue and resolution.

My Issue #2

Discuss the issue and resolution.

My Issue #3

Discuss the issue and resolution.

My Issue #4

Discuss the issue and resolution.

Conclusion

We successfully completed implementing all the proposed objectives.

Project Video

Video coming soon....

Project Source Code

Surce code coming soon...

• Sourceforge Source Code Link

References

Acknowledgement

Any acknowledgement that you may wish to provide can be included here.

References Used

List any references used in project.

Appendix

You can list the references you used.