Difference between revisions of "S17: Halo"

Revision as of 00:40, 23 May 2017

Grading Criteria

Halo: The Smart Helmet

Abstract

This project aims to improve the safety of bicyclists on busy roads. Often, it is difficult for drivers in cars to judge the movement of a bicyclist on road. This problem escalates in scenarios when the driver has to follow a bicyclist in dark environments. We introduce "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 system has been designed to have the following modules:

• Motion Analysis Engine (MAE)
  • Accelerometers are used to detect the state of the motion and show caution signals on the helmet when the bicyclist slows down or comes to a stop in traffic.

• UltraSonic Sensor Module (USS)
  • Ultrasound sensors are used to detect if there is any vehicle following the bicyclist in close range. If the bicyclist is slowing down traffic and making the vehicle behind to follow closely, a buzzer is turned off to indicate the bicyclist to give way. This helps the cyclist to be safe from rash drivers as well as be alert if they are unknowingly slowing traffic.

• Indicator switches to indicate lane changes and turns.
  • DPDT switches are used as indicators which trigger turn signals on the helmet of the bicyclist. Since drivers behind cars are more used to turn signals, the bicyclist can easily shift lanes in heavy traffic conditions.

• Wireless Communication Interface (WIC).
  • In order to make the system neat and user-friendly, wireless modules are used to transmit data such as indicators from the cycle to the helmet.

The overall working of the system is as shown in the figure below. Two SJOne boards have been used for the project. One of them is placed at the rear end of the handle (Board 1) and the other on the helmet (Board 2). Board 1 is interfaced with the accelerometer and ultrasound sensors. Board 2 is interfaced with a LED display unit and a buzzer. Both these boards communicate with each other using a Nordic wireless interface module.

Overall working of the system

Team Members & Responsibilities

• Abhay Prasad
  • Designed algorithm for Motion Analysis Engine
  • Designed the API for the display unit on the helmet.
• Revathy
  • Designed hardware and software for warning system
  • Developed application Algorithm
  • Built hardware circuit
  • Integrated the functionality to the main project
  • Unit testing, verification, and validation of the module
• Unnikrishnan
• Vishalkumar
  • Designed Wireless channel Interface module
  • Hardware support
• Kripanand Jha
  • Schematic and PCB design.
  • Component soldering on PCB.
  • Implemented UIO APIs.

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.

Parts List & Cost

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 parts 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 the 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. Inboard design it's on you how you minimize the board space place your components in the board. After done with the 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

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 notifies 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 [1] 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.

"HC-SR04 Sensor Characteristics"

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.

"Ultrasound Module Circuit"

Accelerometer (Motion Analysis Engine Module)

The MMA8452Q accelerometer by Fress scale semiconductors was used to develop the Motion Analysis Engine. It is a low-power, capacitive micromachined accelerometer with 12 bits of resolution. The MMA8452Q has user selectable full scales of ±2g/±4g/±8g with high pass filtered data as well as non-filtered data available real-time [2].

The internal structure of accelerometer is suspended by polysilicon springs which allow them to deflect when subject to acceleration in the X, Y and/or Z axis. The deflection causes a change in capacitance between fixed plates and plates attached to the suspended structure. This change in capacitance on each axis is converted to an output voltage proportional to the acceleration on that axis.

The readings from the accelerometer are read through the I2C protocol. Motion analysis is performed by evaluating the values from this sensor to determine the state of the cyclist.

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.

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

This module task runs every 200ms cycle to check the range of the vehicles surrounding the biker.The sensor can detect a maximum range of 4m, so the warning levels are set as if the distance of the vehicle is more than 2m, Level 1 warning is signaled if distance is less than 2m level 2 warning is signaled.The warning levels are notified with different alert sounds to the biker.So the warning levels are broadcasted to AlertDisplayModule of the system

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

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.

Ultrasound Sensor Module

The communication between the module and peripherals is through GPIO EINT3 interrupt. The interrupt callbacks are registered in Init() function.The communication between the USS_Task and ISR is through FreeRTOS queue mechanism. When the falling edge ISR runs, the saved timer0 value is passed to the task via a queue, the task which is blocked on the queue is woken to calculate the distance and broadcast to AlertDisplayModule to notify the biker with sound.

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();

}

• Testing & Verification

"LogicAnalyzer capture of Echo and Trigger pin"

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

[1] Golestan, Saeed, et al. "Moving average filter based phase-locked loops: Performance analysis and design guidelines." IEEE Transactions on Power Electronics 29.6 (2014): 2750-2763.

[2] MMA8452Q, Xtrinsic. "3-Axis, 12-Bit/8-Bit Digital Accelerometer." 2013-10]. http://cache. freescale. com/files/sensors/doc/data_sheet/MMA8452Q. pdf (2014).

Appendix

You can list the references you used.