IoT-Based Real-Time Accident Detection for Smart Helmets

IoT-Based Real-Time Accident Detection for Smart Helmets

Aashu Chaudhary (Pursuing MCA) Email- aashuchoudhary8763@gmail.com

Aditi Goyal (Pursuing MCA) Email- aditigoyal1104@gmail.com

Asst. Prof. Abhilash Saxena

Email- abhilashsaxenamit@gmail.com

MCA

MIT Moradabad/AKTU Moradabad, Uttar Pradesh, India

Abstract – Motorcycle riders are at greater risk of being injured in case of an accident due to the lack of protection offered by a vehicle compared to a car. A standard helmet can protect the head, but it cannot indicate whether there has been a serious incident or provide the location of the rider in case of an emergency. This paper describes Kavach the IoT- based smart helmet that tries to address this problem by detecting abnormal movements indicative of accidents and providing the necessary information remotely.

The helmets prototype was built using an ESP32-S3 as a microcontroller, MPU6500 6-axis motion sensor, NEO-6M GPS receiver, SX1278 LoRa transceiver, and WiFi access point. The first two modules were used to measure linear and rotational acceleration and determine whether the detected movement is abnormal or not. The last three components allow the system to send the GPS coordinates of the riders location over LoRa or WiFi using a web interface. The paper notes that the GPS location is saved after the last valid fix in case of signal loss to prevent errors due to temporary signal loss.

The author followed an incremental development approach by testing individual sensors and communication modules before building and testing the complete system in order to ensure their proper functionality. The described prototype focuses on the basics of the IoT-based accident-detection system. As such, it does not provide statistical accuracy in determining the occurrence of an accident, and future research should build upon bigger datasets, more advanced detection algorithms, cellular networks as an alternative communication method, storage in cloud platforms, and video evidence encryption for accident recordings.

Index Terms – Accident Detection, ESP32-S3, GPS, Internet of Things, LoRa, MPU6500, Real-Time Monitoring, Rider Safety, Smart Helmet.

1. INTRODUCTION

   For a motorcycle rider, an accident could turn out to be a life- threatening situation within a matter of seconds. There might not be enough time to inform a family member or even a friend about the location of the accident. This is especially true in case of an unconscious or critical condition.

   Road traffic injuries constitute a major global public-health problem. According to the World Health Organizations global status report on road traffic injuries 2021, the number of deaths due to road traffic crashes was 1.19 million in 2021. Over half of all road traffic deaths involve vulnerable road users [1].

   A conventional helmet is primarily meant to serve the sole purpose of protecting the riders head from external impacts. But thats about it. The helmet does not have any idea whether its impact absorption mechanism has just saved the riders life or not. Nor does it possess the capability to indicate the location of the accident.

   This is where the concept of the Internet of Things comes to the rescue.

   An IoT-enabled helmet can be envisioned as something that goes beyond just protecting the rider from external impacts. Such a smart helmet can be made capable of constantly monitoring environmental factors using a set of onboard sensors. It can process this information right at the helmet locally and take appropriate actions such as notifying another device about an accident, instead of relying on the rider to report the problem [2], [3].

   Kavach Smart Helmet is the manifestation of this very philosophy. It has been designed using ESP32-S3 as the central processing unit along with motion sensing, GPS, and communication modules [4]-[6], [12]. The intent of this project is not to cram as many features as possible into a helmet but to address a fundamental need: Accident detection.

   Can we build a wearable IoT system that can constantly monitor the movement of the rider and respond appropriately in case of an accident?

   The proposed solution involves monitoring acceleration and angular movements using an onboard MPU6500 sensor [5]. The ESP32-S3 microcontroller processes this information and triggers an accident alert if the movement patterns satisfy predefined accident detection criteria. In addition to that, the current location of the accident is obtained using an onboard GPS module [6]. The alert along with the location details can be viewed on a web dashboard through the communication channel [12].

   CONTRIBUTIONS

   This work contributes the following ideas towards the development of a smart helmet:

   • Development of the IoT framework for accident detection [2], [3],

   • Employment of accelerometer and gyroscope for movement analysis [5], [7], [9],

   • Implementation of the GPS module with fail-safe mechanisms for periodic location updates [6],

   • Consideration of LoRa as an optional long-range communication platform [12],

   • A web dashboard for real-time monitoring of the system,

   • And identification of some of the key challenges that need to be addressed before such a system can be deployed at scale.

2. LITERATURE REVIEW

   Researchers have proposed several smart helmets which combine the use of inertial sensors, GPS, cellular modem, video cameras, and micro-controller. A review conducted by Impana et al. reports a number of smart-helmet prototypes [2], while Alim et al. describe an IoT-based helmet which can detect and report an accident [3]. A more recent trend focuses on the use of multiple sensors and testing their combination in practice instead of using a single threshold [7] [11].

   Impana et al. review smart-helmet literature with a specific focus on the detection of accidents. They report on the use of IoT, sensors, microcontroller, GPS, and communication in helmets for rider safety [2]. The article confirms that the current trends in the development of smart helmets focus on the transition from a system which uses particular sensors to the concept of connected safety.

   Alim et al. report on the development of an IoT-based smart helmet for the detection of road accidents. The prototype uses built-in sensors, GPS, communication equipment, and an emergency notification system [3]. In other words, an IoT helmet can detect an accident and notify the rider and/or a pre-set contact. This study has been presented at the 2020 IEEE Annual Information Technology, Electronics and Mobile Communication Conference (IEMCON) . The DOI is 10.1109/IEMCON51383.2020.9284820 .

   Overall, the reviewed articles confirm that connected systems in smart helmets, including cellular modems, can be used for accident detection. However, in most cases, algorithms rely on the

   fact that an unusual value sensed by a sensor indicates an accident. In reality, sudden braking, hitting a hole, driving on a slippery surface at high speed, and even a riders involuntary head rotation may trigger a rapid change of acceleration, which would be falsely detected as an accident. Recent research on the accident detection of the two-wheelers emphasize that the use of thresholds is inappropriate due to the motion characteristics of the vehicle [9].

   This observation highlights an essential limitation of most current smart helmets. Instead of asking

   i the current acceleration high enough to indicate an accident researchers and developers should pose the question

   does the observed acceleration indicate an accident?

   The first formulation assumes that a single measurement is sufficient to identify an accident. By contrast, the second formulation recognizes that acceleration values must be put into context, specifically the timeframe during which they have been observed. Kavach attempts to address this challenge by combining the information on acceleration and rotation. The MPU6500 accelerometer-gyroscope provides the microcontroller with data on motion in three axes [5]. While this approach does not eliminate the possibility of false readings, it allows for more context for the determination of an accident, namely, the rate at which the change in acceleration occurs. This information is valuable for subsequent sensor fusion or analysis within a specific time window.

   Another design choice that requires justification is the method used by Kavach to notify the rider or a pre-set contact. Most articles which describe a similar feature only mention the use of either GSM or cellular modem (or both) for accident notification [3], [8]. By contrast, Kavach uses LoRa as an additional long- range communication channel. Semtech specifies that its SX1278 RF module uses long-range spread-spectrum technology which results in high immunity to interference and low current consumption [12]. In other words, when an accident is detected by a smart helmet, the notification message (likely to be short, such as a coordinate string and a flag indicating the type of an accident) will be received by the base station.

   Given the above, it should be noted that the research question posed in this work is not aimed at the development of a novel type of smart helmet. As stated above, the primary objective is to combine existing elements (accelerometer, gyroscope, GPS, microcontroller, cellular modem, LoRa module) into a working prototype which would illustrate the limitations of the current approaches to accident detection. Specifically, the choice of sensor fusion and analysis within a sliding time window reflects the recent observations that individual sensor readings, including acceleration, are insufficient for accident detection [7], [9]. In this context, Kavach represents a modular platform which enables future researchers to build upon the findings on the relationship between the motion of the riders head and the occurrence of an accident.

3. PROPOSED KAVACH SYSTEM

   The proposed system consists of 5 stages as shown in the block diagram below:

   Sensing Processing Decision Communication

   Monitoring

   The sensing unit gathers physical data from the helmet processing is done by the ESP32-S3 by processing received information the decision-making process determines if the recorded movement was an accident information is shared through WiFi and LoRa communication modules and monitoring of the data is done using the web dashboard.

   Fig. 1. Overall architecture showing the MPU6500 and NEO-6M connected to the ESP32-S3, with LoRa and Wi-Fi providing communication paths to the emergency receiver and monitoring dashboard.

   The design was intentional as each unit can be tested individually before the whole system is assembled due to the modularity of the design.

   The ESP32-s3 is the main controller. The processing unit uses the Inter-Integrated Circuit (I2C) bus to receive information from the MPU6500. The GPS module sends data to the processing unit over the Universal Asynchronous Receiver Transceiver (UART) interface, while the LoRa communication module uses Serial Peripheral Interface (SPI) bus.

   The dashboard offers an avenue for visualizing the information captured by the helmet. By using this dashboard, the user does not need to record or interpret serial-monitor values or worry about the processes happening on the other end of the communication link. The dashboard provides the location, acceleration, and gyroscope readings, the accident status, and the connection status.

4. HARDWARE DESIGN

   1. ESP32-S3

      The ESP32-S3 microcontroller is the main controller of the Kavach system. The official Espressif documentation contains the

      necessary technical specifications, peripherals description, and technical reference for the ESP32-S3 microcontroller. [4].

      As part of the Kavach system, the ESP32-S3 microcontroller is tasked with:

      • Reading the MPU6500

      • Receiving GPS data

      • Processing movement data

      • Recognizing potential accident scenarios

      • Storing the last valid GPS location

      • Communication with the LoRa module

      • Reporting data to the dashboard

        Using a single controller reduces the complexity of communication between the systems various parts.

   2. MPU6500

      The MPU6500 is the main motion sensor component [5]. It comprises of:

      • Three accelerometer axes.

      • Three angular rate sensors (gyroscope axes).

        The accelerometer senses acceleration in all three axes as shown below:

        [ A_x,A_y,A_z ]

        Then, the total acceleration is obtained as:

        [ ]

        In a similar fashion, the gyroscope outputs angular velocity given below:

        [ G_x,G_y,G_z ]

        The magnitude of the angular velocity can be expressed as: [ ]

        This information can be utilized to detect any abnormal activity. The reason is that whereas acceleration can indicate an erratic motion, angular velocity can identify irregular rotation.

        While working on the Kavach prototype, the MPU6500 was found to be accessible at I2C address 0x68.

        TABLE IMPU6500 connections

        MPU6500 Pin	ESP32-S3
        SDA	GPIO 1
        SCL	GPIO 2
        VCC	3.3 V
        GND	GND

   3. NEO-6M GPS

      The NEO-6M GPS module provides the current positioning of the helmet. The official ublox documentation describes the NEO-6M as part of the NEO-6 GPS module family and details its interfaces and technical specifications. [6].

      The GPS communicates with the ESP32-S3 over UART.

      Some examples of the data that can be obtained from the GPS are:

      • Latitude

      • Longitude

      • Speed

      • Position validity

      • Satellite information

        It is worth noting that the prototype uses GPIO 18 and GPIO 17 for the GPS serial interface.

        One of the problems that had to be solved during the development of the system was the loss of GPS signal. Ideally, if the system cannot read a valid position from the GPS receiver, it should update the position to zeroes, resulting in incorrect information on the dashboard.

        Therefore,

        Kavach uses a last-valid-location algorithm. When a valid GPS fix is detected: [ ]

        When the GPS receiver loses the signal: [ ]

        This seemingly minor detail is essential in the context of an emergency system, as the last known position is often more informative than an invalid one.

   4. SX1278 LORA

      The SX1278 LoRa module is utilized as a long-range communication medium. Semtech specifies the SX1276/77/78/79 as LoRa transceivers with long-range spread spectrum capabilities, high immunity to interference, and ultra-low power consumtion. [12].

      The tested wiring for the Kavach prototype is presented below.

      TABLE IISX1278 connections

      SX1278 Pin	ESP32-S3 GPIO
      NSS	GPIO 5
      RST	GPIO 6
      DIO0	GPIO 7
      MOSI	GPIO 35
      MISO	GPIO 37
      SCK	GPIO 36
      VCC	3.3 V
      GND	GND

      During the development process, the module was successfully initialized and managed to transmit messages.

      LoRa is an appropriate choice for such an application since an emergency packet does not require a significant amount of data to be transferred. It is possible to equip the packet with an accident flag, the vehicles coordinates, velocity, and additional data.

5. ACCIDENT DETECTION APPROACH

   Accident detection is the most critical component of the proposed system.

   It is relatively straightforward to design an algorithm which can trigger an accident notification whenever the magnitude of acceleration exceeds a threshold value. However it is non-trivial to eliminate false positives generated by normal riding behavior, such as riding over rough roads or braking. Recent work on powered-two wheeler systems provides valuable insight into this problem, demonstrating that motion patterns during the critical moment are not sufficient to define an accident, while the sequence of movements around a potential fall is also informative [9].

   In particular the helmet can undergo large accelerations due to

   • riding over rough roads,

   • sudden braking,

   • sudden turning,

   • manual movement of the helmet,

   • or dropping of the helmet.

   As a result, Kavach utilizes a combination of accelerometer and gyroscope data.

   A simplified version of the decision making algorithm is as follows:

   [

   ]

   With

   (T_A) = acceleration threshold, (T_G) = gyroscope threshold

   The precise threshold values would be determined experimentally for the final product, (rather than theoretically) in order to minimize false positives.

   The final system should also include a short confirmation period in order to avoid spurious sensor readings. In other words, the controller should analyze multiple consecutive samples before deciding to trigger an accident notification. In general the following procedure would be followed:

   1. Read accelerometer data.

   2. Read gyroscope data.

   3. Determine the magnitude of the movement.

   4. Test if the values satisfy certain criteria.

   5. Determine if abnormal movement persists for a certain duration.

   6. Accident confirmed.

   7. Read latest valid GPS position.

   8. Construct emergency data packet.

   9. Send event.

   It is important to note that the proposed algorithm is designed to be relatively conservative. In other words,

   not every anomalous movement pattern will cause the system to trigger an accident. The aim is to ensure that positive identifications are sufficiently reliable that they justify an

   emergency response. While a spurious accident report is undesirable, it is far more critical to avoid missing a true accident. It is also notable that recent work on smart helmets suggests similar approaches to accident detection. This includes the use of multiple criteria or time windowed values to reduce the likelihood of falsely triggering an accident notification [7] , [11].

   Fig. 2. Flow of the accident-detection process from sensor acquisition to accident confirmation and emergency communication.

6. IOT COMMUNICATION AND DASHBOARD

   The accident-detection system is only as good as the ability to relay the information it gathers to someone who can act on it. [8], [10].

   The Kavach system thus treats detection and monitoring as separate functions.

   The ESP32-S3 handles the sensor readings locally; the monitoring dashboard communicates with the IoT device to get the information it needs.

   An accident packet might look like this: ACCIDENT = 1

   LATITUDE = LONGITUDE = ACCELERATION= GYROSCOPE = TIME =

   The web dashboard can show:

   • Accident status

   • GPS location

   • Accelerometer X/Y/Z

   • Gyroscope X/Y/Z

   • Wi-Fi status

   • LoRa status

   • Helmet/device status

   The dashboard is valuable not only for monitoring accidents but also testing the sensors; the graphs make it easy to see how far the bike or the person has moved by looking at the change in X/Y/Z

   direction. It's a useful tool for both the accident-monitoring system and the research and development process.

   Fig. 3.

   Information flow from rider movement and helmet sensors to local processing, communication, and remote monitoring.

7. HARDWARE AND SOFTWARE INTEGRATION

   The Kavach prototype was not designed as a monolithic structure; its individual modules were first tested standalone before being integrated.

   The reason for this approach was the possibility of a module malfunction, which could be incorrectly attributed to the software fault in another module.

   The connections are described below in Table 3.

   TABLE IIIMain system connections

   Module	Interface	ESP32-S3 Connection
   MPU6500	I2C	SDA GPIO 1, SCL GPIO 2
   NEO-6M	UART	GPIO 18 / GPIO 17
   SX1278	SPI	GPIO 5, 6, 7, 35, 36, 37
   Wi-Fi	Built-in	ESP32-S3
   Dashboard	Wi-Fi	Network connection

   The results of the prototype development were positive. All modules were identified, and sensor data was acquired; GPS communication was established, and the LoRa subsystem was tested and proven able to send and receive packets.

   Moreover, some insights into potential issues in the target environment were gained. For instance, the GPS location acquisition process is sensitive to power supply fluctuations, and this problem is exacerbated in moving vehicles. A stationary or slow-moving battery-powered wearable device may have fewer issues, but a smartphone needs to be handled with care while maintaining the connection.

   Fig. 4. Hardware-level connection diagram of the ESP32-S3 with the MPU6500, NEO-6M GPS, and SX1278 LoRa module.

8. CAMERA-BASED ACCIDENT EVIDENCE

   The Kavach project has another subsystem, which incorporates the camera. The camera, obviously, has its own controller and is considered separately from the ESP32-S3 sensor controller.

   First of all, it is necessary to clarify that the camera is not intended to detect the accident. It can, however, be used to store evidence in case of an accident.

   A camera that is designed to record an accident and starts recording only when the accident occurs has one significant disadvantage. The mment for starting the recording is the moment of the accident itself.

   As a result, the beginning and the cause of the accident will not be recorded. Thus, it is more logical to use the camera for continuous or loop recording.

   The continuous recording will be stopped when an accident is detected and a short recording will be saved to the buffer.

   The general idea of such a camera is as follows:

   1. Constant recording

   2. Saving the last n seconds of video in the buffer

   3. When an accident is detected: save the last n seconds of the video before the accident and start recording again in the constant mode

   4. After the accident, the last n seconds of constant recording will also be saved to the buffer

   In this case, the recording before and after the accident will be saved to the buffer. In addition, for evidence preservation, it may make sense to separate such recordings from the constant loop and not allow them to be deleted.

   In this way, the camera subsystem will act as an addition to the IoT accident detection system as a whole, but will not be the central system.

9. EXPERIMENTAL OBSERVATION

   The current prototype was tested for the first time via the functional module assessment.

   Its primary goal was to check whether the designated modules could communicate with each other correctly and perform their intended operations, but not to argue for the statistically significant accuracy of the accident-detection algorithm.

   The primary findings are provided in the following table:

   TABLE IVPrototype verification

   Parameter	Observation
   ESP32-S3	Operational
   MPU6500	Detected at 0x68
   Accelerometer	Sensor data obtained
   Gyroscope	Sensor data obtained
   NEO-6M GPS	Serial communication tested
   GPS position handling	Last-valid position implemented
   SX1278 LoRa	Initialization successful
   LoRa transmission	Packet transmission tested
   Wi-Fi	Connectivity demonstrated
   Dashboard	Sensor monitoring implemented
   Camera subsystem	Tested independently

   These findings suggest that the proposed hardware design is plausible and would be able to achieve its intended functions.

   However, it is too early to argue for the accuracy of accident detection.

   To argue for the accuracy, it would be essential to design a set of controlled experiments from which it would be possible to generate positive vs. negative samples for the model training and testing.

   An example of the experimental design is provided below:

   TABLE VSuggested experimental categories

   Test Category	Purpose
   Normal riding	Establish normal sensor patterns
   Sudden braking	Test false triggering
   Speed breaker	Test vibration response
   Sharp turning	Test rotational response
   Helmet drop	Test non-riding impact
   Controlled impact	Test accident response
   GPS signal loss	Test location recovery
   LoRa transmission	Test communication reliability

   After such experiments are designed and used to acquire sensor data, it will be possible to calculate the precision, recall, and

   accuracy of the prototypes performance using the following formulas:

   Accuracy = (TP + TN) (1) (TP + TN + FP + FN)

   Precision = TP (2)

   (TP + FP)

   Recall = TP (3) (TP + FN)

   Where

   TP = True Positive TN = True Negative FP = False Positive FN = False Negative

   This data should be collected before finalizing the conclusions about the accuracy of the prototype.

10. DISCUSSION

    Developing Kavach revealed the practical lesson that an IoT smart helmet is more than the sum of its sensors. The real challenge was defining which observations are worth further processing and how to respond to specific circumstances with limited hardware. The same problem was at the center of recent studies on accident detection systems, where false positives and temporal characteristics of movement were identified as two key factors [7], [9], [11].

    GPS coordinates can be spurious, wireless connections can be disrupted, movement can be mistaken for an accident, and a power supply can exhibit undesirable voltage fluctuations. These effects must be taken into account when developing an IoT-based safety system.

    Perhaps, an important finding that could be generalized to other applications was the value of retaining the last known GPS coordinate. If temporary loss of satellite connection results in (0,0) latitude-longitude, this information would be completely misleading for a rider unaware of the circumstances. Hence, a sensible default was to utilize the previous position update as the current location, which was simple to implement in the context of the smart helmet. For instance, NEO-6 family of modules has UART interface option that facilitates this approach and is targeted towards miniaturization and ultralow power consumption [6].

    Sensor fusion was another critical area in the development of Kavach. It is evident that a single axis of acceleration alone cannot characterize a riders movements adequately. As mentioned in the related work, rotational degrees of freedom can be beneficial in distinguishing between different types of motion [7], [11]. More generally, there is value in considering multiple readings from accelerometer and gyroscope within a moving time window. However, it is also apparent that such data cannot be utilized

    indiscriminately. In particular, a careful analysis of thresholds was necessary, which relied on the physical tests and ultimately, empirical evidence.

    Lastly, an interesting observation pertains to the choice of LoRa as the communication medium. While cellular networks seem to be a natural choice for transmitting an emergency alert, LoRa can be utilized for other purposes, such as establishing connections with a receiving station or a nearby gateway. It follows that both short-range and wide-area networks are valuable assets that should be leveraged in unison.

11. ADVANTAGES

    The proposed system has several practical advantages.

    • Automatic

      As no manual input is required, the rider is free to operate the system without interference.

    • Both Acceleration and Rotation

      Both degrees of motion are used for accident analysis.

    • GPS Tagging

      GPS provides a location reference for each event.

    • Optional LoRa Communication

      An alternate wireless channel is available for communicating with the system.

    • Web Dashboard

      Having a web dashboard makes sense for quickly visualizing sensor data during testing.

    • Modular Construction

      Modules can be substituted, tested, and upgraded individually without changing the whole system.

    • Future Expansion ossibilities

      The system can be expanded to include cloud storage, machine learning, cellular communication, and video recording of accidents

12. LIMITATIONS

    The proposed prototype has several disadvantages.

    • Accident classification:

      Using a threshold-based approach can lead to false positives from a normal riding causing abnormally high acceleration or rotation.

    • GPS dependency:

      The GPS module has to acquire a lock on the satellites, which takes time, and may not work in a situation where the satellites cannot be seen.

    • Communication dependency:

      The LoRa module needs compatible receiving hardware such as another microcontroller or a gateway with internet access. Wi-Fi monitoring is dependent on having an internet connection.

    • Testing:

      The prototype needs more testing data before an accident detection accuracy can be statistically determined.

    • Power consumption:

      A smart helmet would have a lot of electronics, which would demand more power from the battery. Having the GPS and communication modules constantly running will drain the battery.

    • Mechanics and safety:

      The electronics and mechanical parts need to be placed in such a way that they do not impede the original protective capabilities of a helmet. A production model would need to undergo proper safety and certification testing.

      These points are not flaws in the concept itself, but rather things that need to be explored and ironed out in future development.

13. FUTURE SCOPE

    The next logical step is the creation of a proper accident-motion dataset.

    With the available sensor data from regular use, one could sample various artificially created accidents and use machine-learning algorithms to classify them.

    • Acceleration magnitude

    • acceleration axes

    • gyroscope magnitude

    • angular velocity

    • change in orientation

    • duration of anomalous motion

    • vehicle speed

    • GPS location/motion could all be used as input.

    The resulting algorithm could be benchmarked against thresholding, rule-based sensor fusion, and other machine- learning algorithms, the results of which could be evaluated using precision-recall metrics, F1 scores, and false-positive rates.

    The communication strategy could be expanded upon using both LoRa and cellular networks: while the former would allow for local long-range communication, the latter would provide an option for long-range emergency help calling.

    The video-surveillance functionality could also be elaborated on within the context of the accident detection system.

    For example, once an accident is detected, the system could automatically save the video footage from before the incident for later review.

    Another important aspect to think about is power management. The system would greatly benefit from having its GPS, sensors, cellular radio, and camera turned off when they are not needed in

    order to prolong battery life.

    Lastly, it would be important to transition from lab research and begin testing prototypes on actual roads and eventually begin actual trials to gather more data.

14. CONCLUSION

This paper describes the design and development of an IoT-based smart helmet, capable of detecting accidents in real-time. The proposed Kavach system was equipped with an ESP32-S3 controller, an inertial MPU6500 sensor, a NEO-6M GPS module, SX1278 LoRa radio, WiFi, and a web dashboard.

The general idea of the Kavach helmet is to ensure that a rider is not only protected by a helmet but also that their gear can recognize the potentially dangerous situation, report it, and deliver vital information after an accident.

The inertial sensor MPU6500 was utilized to measure linear accelerations and rotational movements. Additionally, the GPS was used to geotag the detected events with coordinates, while the last-valid-location mechanism ensures safe behavior during temporary GPS loss. The long-range communication was achieved using LoRa, and WiFi was used for the web dashboard, providing an ability to view sensor data in real-time.

The results of the prototype development have shown that it is possible to design and develop a working prototype that uses real- time data from multiple sensors and has working IoT links. Furthermore, the results have shown that the problem of an accident detection is not a trivial one, and a single metric such as acceleration threshold is not sufficient for reliable detection. In particular, the development process has demonstrated that normal riding can involve non-trivial dynamics, briefly resembling potential accident scenarios. Thus, the next step is to compile a broad data set that includes data from normal riding, dynamic maneuvers, and artificial events that simulate accidents. This data set can then be used to evaluate different threshold-based, rule- based, and machine learning algorithms performance on the same data, enabling a meaningful comparison of the approaches.

The Kavach helmet prototype, therefore, is not only a working example of a smart helmet but also a solid foundation for a more substantial accident detection system. In particular, the prototype shows that a connected helmet can provide features beyond simple activity tracking, such as local and remote alerts, real-time health monitoring, and the provision of vital statistics after an accident.

REFERENCES

1. World Health Organization, Global Status Report on Road Safety 2023. Geneva, Switzerland: World Health Organization, 2023, ISBN 978-92-4- 008651-7.

2. H. C. Impana, M. Hamsaveni, and H. T. Chethana, A Review on Smart Helmet for Accident Detection using IOT, EAI Endorsed Transactions on Internet of Things, vol. 5, no. 20, 2019, doi: 10.4108/eai.13-7-2018.164559.

3. M. E. Alim, S. Ahmad, M. N. Dorabati, and I. Hassoun, Design & Implementation of IoT Based Smart Helmet for Road Accident Detection, in 2020 11th IEEE Annual Information Technology, Electronics and Mobile Communication Conference (IEMCON), Vancouver, BC, Canada, 2020, pp. 576581, doi: 10.1109/IEMCON51383.2020.9284820.

4. Espressif Systems, ESP32-S3 Series Datasheet, v2.2, Espressif Systems, 2026.

5. TDK InvenSense, MPU-6500 Six-Axis MotionTracking Device, Product Specification, Rev. 1.3, 2020.

6. u-blox, NEO-6 u-blox 6 GPS Modules Data Sheet, GPS.G6-HW-09005, u- blox AG.

7. A. Ahmed, M. M. Khan, R. Dey, and I. Nanda, Smart Helmet with Rear View and Accident Detection System for Increased Safety, in 2022 IEEE 12th Annual Computing and Communication Workshop and Conference (CCWC), Las Vegas, NV, USA, 2022, pp. 673678, doi: 10.1109/CCWC54503.2022.9720833.

8. S. Ur Rehman, S. A. Khan, A. Arif, and U. S. Khan, IoT-based Accident Detection and Emergency Alert System for Motorbikes, in 2021 International Conference on Artificial Intelligence and Mechatronics Systems (AIMS), Bandung, Indonesia, 2021, pp. 15, doi: 10.1109/AIMS52415.2021.9466055.

9. A. Jackulin Mahariba, A. Uthra R., and G. Brunet Rajan, An Efficient Automatic Accident Detection System Using Inertial Measurement through Machine Learning Techniques for Powered Two Wheelers, Expert Systems with Applications, vol. 192, art. no. 116389, 2022, doi: 10.1016/j.eswa.2021.116389.

10. E. B. Sevandal, M. F. T. Menque, L. M. Dagsa, A. D. B. Balamad, and E. R.

    B. Sajonia Jr., Real-time IoT-based Motorcycle Accident Detection and Alert System, in Proceedings of the International Exchange and Innovation Conference on Engineering & Sciences (IEICES), vol. 10, pp. 494499, 2024, doi: 10.5109/7323306.

11. M. I. Minhas, I. Shah, Y. Ali, and F. N. M. Alhusayni, A Low-Cost Smart Helmet with Accident Detection and Emergency Response for Bike Riders, Journal of Sensor and Actuator Networks, vol. 15, no. 1, art. no. 20, 2026, doi: 10.3390/jsan15010020.

12. Semtech Corporation, SX1276/77/78/79 LoRa Transceiver Datasheet, Semtech Corporation, 2020.