Difference between revisions of "S17: Halo"

Revision as of 05:47, 12 May 2017

Grading Criteria

Halo: The Smart Helmet

Abstract

This section should be a couple lines to describe what your project does.

Objectives & Introduction

Show list of your objectives. This section includes the high level details of your project. You can write about the various sensors or peripherals you used to get your project completed.

Team Members & Responsibilities

• Abhay Prasad
• Revathy
• 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.

Parts List & Cost

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.

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 mainly designed schematics and PCB for our board. 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 move to board design EAGLE generates board design based on schematics we create. After moving to board design we have to minimize the space used in board and further arrange the components based on your choice. after done with proper design we can either opt for auto-routing or manual routing thing to route the components on the board. While routing use proper values of width and drill size for the route. After done with routing check for any error on the board connections using ERC and DRC tools. We designed dual layer pcb just for the sake of testing. for the commong ground we used ground plane that makes circuit design simple.

EAGLE components used

Algorithm Design

Algorithm Design

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.

Porting the algorithm from Matlab to C++ was easy. 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 overall flow of the algorithm is shown below. The calibration phase 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 supposed to stay in the stopped state for 3 seconds before starting. The mean of this value is considered to be the offset. The offset obtained now is 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.

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 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 psuedocode and fragments of code. Keep in mind that you are showing DESIGN of your software, not the inner workings of it.

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.

Conclusion

Conclude your project here. You can recap your testing and problems. You should address the "so what" part here to indicate what you ultimately learnt from this project. How has this project increased your knowledge?

Project Video

Upload a video of your project and post the link here.

Project Source Code

• 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.