Fuel Saver BT Dongle

Problem

The commercial trucking industry is a major source of carbon emissions worldwide. The emissions depend directly on the efficiency of the powertrain that is handled by drivers who care more about reducing trip time and driving comfort than about the environment. Since, fleet owners or logistics companies for whom these drivers work have no way to remotely track driving behaviour or engine efficiency, large amount of fuel is wasted adding unnecessarily to the carbon footprint of this lifeline industry.

Solution

There are commercially deployed solutions that track the truck`s GPS location and the fuel efficiency but they use additional sensors for efficiency measurement while not monitoring the driver or components. We propose BT Fuel Saver Dongle, an integrated IoT-based platform to reduce the overall carbon footprint of commercial vehicles. BT Fuel Saver Dongle aims to support fleet owners and empower truck drivers by tracking vehicle health in transit to provide early detection of common vehicle problems, using our truck telematics solution to reduce costs incurred per truck and boost safety through the decreased risk of accidents. Less physical damage to components translates to less replacement of parts lowering the overall carbon footprint. The key features include monitoring of truck components like the brake, clutch, axle, and tires, detecting driver drowsiness etc.

Individual slave nodes monitor different health parameters and send warnings to the Master in case of an anomaly. The master relays the warnings along with the GPS coordinates(sampled every minute) to the driver`s mobile phone via BLE. Additionally, it warns the driver through a dashboard display in case inefficient driving or component damage is detected. From the cloud database, GPS stream, notifications and analytics are sent to the fleet owner`s dashboard, accessible on any mobile device.

Implementation

A Master-slave architecture is used with individual slaves based on the EFM8BB microcontroller pre-processing sensory data locally to detect anomalies and relaying them to the Master based on the Nordic Thingy 53 development board using proprietary NRF protocol on the 2.4GHz band. The Master collects warning flags from the slaves, warnings generated by the driver drowsiness detection, driving behaviour monitoring and fuel efficiency monitoring units and the GPS location of the truck at intervals of one minute and stores it on an onboard microSD Card.

The fuel monitoring system is based on an instantaneous correlation of the efficiency to a lookup table mapping the efficiency to the engine RPM and gear ratio. The master node continuously logs the lambda sensor reading from the ECU OBD bus to find the ratio of unburnt oxygen in the exhaust fumes. The efficiency is calculated as a linear function of the sensor reading and correlated to the efficiency lookup table fetched from the onboard EEPROM flash memory.

The driver behaviour monitoring system is based on a Tensorflow Lite neural network that classifies driving behaviours into three categories – Normal, Inefficient and Unsafe. The Master captures data from a 6DoF Inertial Measurement Unit and feeds it into a pre-processing module that filters the data and generates spectral features in the frequency domain that are then fed into the model. The training is done by collecting accelerometer data from an average-sized cargo truck for all three modes. The inefficient mode is characterized by high magnitude of jerk or rate of change of acceleration. The unsafe mode is characterized by continuously high linear or rotary acceleration. As soon as ineffcieint or unsafe modes are detected, the driver is warned using a prompt on the master dashboard.

The driver drowsiness detection system captures the visual feed of the driver`s eyes from a dashboard camera and feeds it to an image classification neural network running on a Raspberry Pi Zero, Linux Single-Board-Computer. The model classifies the eyes as open or closed and sends it to the Master over the I2C bus. If found closed for more than one second, a buzzer is sounded along with a message on the dashboard.

For each slave, a different sensing mechanism is used. The exhaust gas from the engine is treated by passing it through a tank consisting of Urea and deionised water. The slave module monitors ammonia levels and raises “Ammonia-level LOW” alerts. Rotary encoder slaves track steering integrity and raise alerts if truck does not move straight in idle position. Another slave uses an LVDT module to track the linear displacement of the ends of the rear axle that breaks on overloading.

Overall Architecture

Slave Nodes

There are five slave nodes in total that monitor different parameters related to vehicle health. The following table gives a summary of the functionalities of the master and the slave nodes.

Features

Since the number of nodes were so many, I thought it would be better to take the feature implementations one by one, rather than describing the nodes. The list of features along with the technology is shown below.

Driver Drowsiness Detection

Problem:

Truck drivers in India are often subject to inadequate sleep or have jobs requiring them to alternate sleep cycles which is often taxing. This results in drivers becoming drowsy while driving and potentially meeting with an accident.

Technology:

The dashboard consists of a Raspberry Pi with an infrared camera to monitor the driver's eyes. IR LEDs ensure uninterrupted monitoring even during low-light conditions and at night when most accidents occur. A pre-trained face landmark detection model is used to determine if the eyes are closed or open using EAR (Eye Aspect Ratio). If the eyes remain closed (EAR < 2.0) beyond a specific time interval (200 μs), an alarm is raised to alert the driver. If the number of warnings exceeds a certain threshold, the fleet owner is also alerted.

For training the model, Edge Impulse was used. The entire process is documented in a later section. A neural network based image classifier predicted if the driver`s eyes were open or closed in real-time and sent it over I2C to the Nordic Thingy:53 – the master controller.

Brake System Monitoring

Problem:

For medium and heavy-load transport vehicles, it is critical for the braking system to function correctly and be maintained regularly.

Technology:

A 6 DoF Inertial Measurement Unit (IMU) is interfaced with the MASTER to measure the vehicle’s deceleration when the brakes are pressed. At full braking pedal position, a limit switch interfaced with the MASTER detects a pedal press, after which the acceleration value is polled.

If the deceleration is below the required threshold a certain number of times, an alert is raised with the fleet owner. The threshold value is dynamically adjusted depending on the road conditions by monitoring the acceleration value of the truck over an overlapping time window.

The fleet owner can observe timely monitoring of deceleration magnitudes to decide on maintenance-related issues.

Axle Bending Monitoring

Problem:

Trucks are often loaded beyond the maximum limit, which leads to over-the-mark stresses on the leaf springs and, consequently, the axles of the rear wheel pairs. Prolonged driving with bent axles leads to bending and breaking, leading to fatal accidents.

Technology:

SLAVE nodes fixed at the ends of the axle quantify the bending by measuring the linear displacement of the ends using a Linear Variable Differential Transformer (LVDT) sensor to sense the bending in the axle. A warning signal is sent to the MASTER node if the linear displacement exceeds a certain threshold. The MASTER node then raises an alert with the fleet owner about the vehicle’s overloading.

Clutch Health Monitoring

Problem:

Clutch plate wear due to improper shifting techniques leads to accidents. Late detection leads to higher repair costs.

Technology:

A SLAVE node reads the rotational speed of the input shaft to the gearbox. The position of a magnetic sticker on the gearbox input shaft is encoded using a hall effect sensor (AH49E). The rotational speed is calculated locally and transmitted wirelessly to the MASTER. The MASTER compares the input shaft RPM with the engine RPM received from the ECU OBD bus. If the RPMs differ beyond a certain magnitude for a standard response time interval (1 - 1.5 s), an alert is raised with the fleet owner.

Clutch bites are recorded and stored to assess the health of the friction material over time and suggest minor repairs. The frequency of bites also gives a reasonable measure of the shifting skills of the driver.

Coolant Pipe Monitoring

Problem:

Air bubbles trapped in the cooling system lead to overheating of the vehicle. Due to this, trucks can go over the safe operating temperature range leading to a blown head gasket, cracked engine block, damaged pistons, bursting hoses, or a blown radiator.

Technology:

The SLAVE node has a fluid pressure sensor that relays coolant pressure data to the main module wirelessly via nRF communication at regular intervals. This data can be used to detect possible leakage and further analyze the condition of the coolant fluids. The driver and the fleet owner are intimated if immediate servicing has to be done.

Tire Pressure Monitoring

Problem:

Operating within an optimum tire pressure range is integral to having good maneuvering characteristics and fuel economy.

Technology:

Our system provides one air pressure sensing SLAVE node (fixed near the nozzle on the rim) per wheel, relaying pressure data to the main module wirelessly via nRF communication at regular intervals. The main module reads the pressure data from all the tires to detect leaks or punctures and informs the driver by a message on the dashboard display about refilling air or getting the tires checked for holes. The fleet owner is also notified about possible flat tire situations to take immediate action.

Wheel Alignment Monitoring

Problem:

Proper wheel alignment is crucial for the control and stability of the vehicle, and misalignment can lead to severe accidents..

Technology:

Improper alignment is detected by observing the variation of the rotation of the front tires about the ends of the steering rack. Our module uses three rotary encoders - one for the steering wheel rod and one each for the two front wheels - to measure rotation angles. The angles turned by the wheels and the angle turned by the steering rod are individually calculated by the respective SLAVE nodes.

and sent wirelessly to the MASTER node. The MASTER node correlates the steering rotation in a particular direction to the rotation of the individual front tires in that direction. Discrepancies beyond tolerable limits are reported to the fleet owner on high priority with a suggestion for a wheel alignment inspection.

Fuel Quality Monitoring

Problem:

An optimum air-to-fuel ratio is required for the engine’s clean and efficient combustion of fuel. The engine efficiency is heavily degraded by suboptimal grade fuel which is often substituted by opportunistic drivers in place of recommended fuel.

Technology:

The lambda sensor (connected to the ECU) measures the amount of unburnt oxygen in the exhaust gases. The MASTER module taps into the ECU OBD bus to read this data and analyzes it over time to calculate the fuel quality and engine efficiency. Failure to reduce levels of unburnt oxygen by the ECU (by air-to-fuel ratio calibration) indicates fault either in ECU or fuel pump. This is notified to the fleet owner, and an alert for maintenance is raised.

DEF Level Monitoring

Problem: Heavy and medium load vehicles generally use diesel for fuel. Combustion of diesel leads to a significantly high release of NOX in the exhaust gas, which is highly hazardous. Hence, exhaust gas is treated with DEF (Diesel Exhaust Fluid) to reduce NOX emissions. DEF consists of urea and deionized water. The ammonia released by the urea solution reacts with NOX to produce much less harmful gases (N2, CO2, & H2O) into the exhaust. If the level of DEF decreases below a certain threshold, the concentration of harmful gases in the exhaust increases polluting the air and attracting hefty fines from pollution control enforcement.

Technology:

The ammonia sensor (MQ-135) in our SLAVE node detects urea depletion in the DEF tank. The ultrasound sensor (HC-SR04) monitors the liquid level and assists in assessing the evaporation of the liquid from the DEF tank. Combined inputs from both the sensors are analysed on a timely basis and the fleet owner is alerted regarding the DEF replacement as and when required.

Training and Deployment of Model

Please find the updated, trained model link in this public Edge Impulse project :

https://studio.edgeimpulse.com/public/148644/latest

To train the model, the first step is data acquisition. To do this, the guys at Nordic have teamed up with Edge Impulse to offer a pretty neat app on the Play Store called the nRF Edge Impulse app.

• · Login to the app using our Edge Impulse credentials.
• · Create a new Project and acquire data using the data tab.

o Label the data and start recording. For my case. I placed the Thingy, in horizontal orientation with X-axis aligned to the front of the truck, on the truck dashboard.

o Select the time for data acquisition and the sampling rate. Note that a higher sampling rate means more samples which may be both good or bad depending on the application. Since the acceleration tracking system is a high latency system, I took a generous sample frequency of 20 Hz and collected samples for three types of driving.

• Once data collection is done, head over to the project on the Edge Impulse website and select the recommended Classifiers for training.
• Follow the on-screen instructions to train the model and deploy it directly to the Nordic Thingy 53 either over the air or using a USB-C cable.

Testing

For testing, the slave nodes were made using Arduino Uno to save on development time and installed on a medium-sized truck in my college campus. The Nordic thingy 53 was placed inside the master dashboard which in turn was just placed on the truck dashboard.

Security

NRF modules used for the local star network on the truck use a channel hopping technique wherein once a successful connection acknowledgement is received from the receiver, both nodes mutually transfer communication to a different channel decided by random hashing. The BLE peripheral used on the Nordic Thingy is inherently prevents MITM attacks – the most prevalent in such applications. Hence, the entire architecture is robust to most cyber-attacks.

Inspiration

The key motivation for building BT Fuel Saver Dongle was the huge environmental impact we could make by reducing the carbon footprint of the commercial transportation industry. It is an industry that has incredible bearing on the economy and a small change in the ecological dynamics would translate to a huge overall impact. The huge impact that could be created across the value chain was the inspiration for us.

The other motivation was bringing a change in the lives of truck drivers and fleet owners. We felt really sorry for the truck driver we interviewed who walked us through all the problems faced by them. We wanted to do something to improve his quality of life. Particularly, the realisation that component damage or a tired driver behind the wheel could lead to the loss of life of the driver was eye-opening. We also talked to fleet owners who voiced their concerns about cheating practices by drivers leading to high component damage and fuel inefficiency.

To benefit both parties and the environment, we gave an objective definition to the top problems and talked to experts on how to solve them in an economic way. The conclusion from the discussions was that it was possible to realise what we were trying to achieve, though the journey would be technologically arduous. That gave us the added motivation to pull this off.