Could we use the accelerator massively available in today electronic device to monitor road quality
To make the experience fit your profile, pick a username and tell us what interests you.
We found and based on your interests.
video_vibration.mp4MPEG-4 Video - 31.89 MB - 11/02/2023 at 02:21 |
|
In the last quarter, I set myself the following objectives:
I worked a lot of (1) and (3) but didn't have that much time for (2)
I built an enclosure for the device. It is now easier to transport with me all the wore that are now contained inside one box.
I also printed a small adapter which allow me to attach the IMU device to the computer holder on my bike.
I didn't have the chance yet to get proper measurements on my bike as this was shaking too much and got miss-connection. Now that I glue the wire I hope to get better results the next time I am going out with the device.
(See video attachment)
The Hero 9 black has an embedded IMU and GPS device that I use to measure the vibration data. Here how I proceeded to get the following video
Here are the main updates since my last project log
There were two goals in this update
The main changes are enumerated below:
FPS
The FPS of both sensor GPS and IMU was improved compared with V1
GPS is now capturing at 1 fps. The previous version used to stop when the car was stopped (as per the application that was used in V1)
IMU fps is not stable but it is 99% higher than 100Hz.
In V1 the process of the data was simply done in a Jupyter notebook. This is easy to use for developing new features and testing hypotheses, but not as useful when coming the time to process a larger volume of data.
For V2, I developed a small library to automatically process my data. I am not 100% sure yet about the full architecture of the library. I spent quite some time thinking about what should be the main class. After some time, I decided to put my current idea on VScode and agree on improving as I gather more data and get a better view of what should be the main class and function. The figure below depicts the current architecture of the library.
There are mainly four classes that are used by the entry point `roadqa_process` to generate a map:
The logic behind the process of v2 is the same as V1. There are essentially three factors to control the process:
I didn't have that much time to improve the process as I intended to, but I have a few ideas to improve the process:
To validate the functionality of V2, I did a similar capture and analysis as in V1. I drove along a path and noted the outstanding good (2) and bad (1, 3) sections of the road. The figure below depicts the vibration metric along the path with some photos extracted from the latest google street view that show the condition of the road side by side with the vibration metric.
When I start a project, I like to do a first quick iteration to estimate if my idea have potential to succeed. The goal of this first iteration is not to go too deep in the detail of the implementation, but more to estimate the potential and feasibility of the project. For this first version, I designed a first proof of concept and tested it with a road test.
Note: I went with a cheap IMU here to reproduce what is mostly available in common massively available device. I know there much better device out there specialize in vibration measurement.
The WAVE-100 is communicating with the arduino Nano using I2C protocol. The connection diagram is presented below:
I used one of the examples of an open-source library to log the data out of the IMU sensor using Arduino. Then I use putty to log the serial data from port /dev/ttyUSB0 into a text file. Each set of IMU data is timestamped with millisecond accuracy. For now the IMU data are log at 10Hz (quite low).
To be able to get reliable measurements of the accelerator inside the car, the sensor must be fixed still inside the vehicle. I designed a mount that could fit in the cup holder using Freecad and print it with my creality ender v2. The mount is designed such that the y axis of the accelerator sensor is pointing down..
One of the first step was to align the IMU and GPS on the same time axis. The GPS timestamps are provided by the GPS itself. The IMU data are simply a clock increment to millisecond precision from the start of recording of IMU data. For this first proof of concept, I simply found the offset between the GPS and IMU manually based on the principle that GPS and IMU data are not changing when the vehicle is at a stop.
These are the steps of the post process that were applied to the raw acceleration data to retrieve a metric to estimate road quality.
The map below is showing the processed acceleration data overlay on top of the GPS data. Green colour showing part of the road where the road quality metric was good and red the part were it was particularly bad.
During the ride, I identified two main areas where the road was particularly bad (1, 2) and one area where the road was good (3). As depicted in the above figure, the metric was able to identify those with the right metric value.
Create an account to leave a comment. Already have an account? Log In.
I was looking at attaching a contact piezo to chassis of the vehicle and recording the acoustic signature of the road.
As you mention, smartphones contains accellorameters (sp?), and GPS, this could be an app instead. Apps such as Waze and Google maps already collects speeds from the users to show traffic density; they could also collect and show bumpiness of the road. Perhaps give warnings for excessive potholes and speedbumps if you are driving too fast.
Thanks for your feedback and suggestion, I greatly appreciate. This is indeed a good point, I could have start directly with development of an application. The short answer, is that it was easier for me to do those first tests with the set of knowledge I have (i.e. Arduino, 3D printing, python). I might investigate the path of the app at later stage of the project; it could be a great opportunity for me to acquire more knowledge in app development.
Become a member to follow this project and never miss any updates
I was thinking about a (more ambitious and unrealistic) project that would involve road-condition measurement! One thing I found is that there are vehicle-mounted thermal, optical, and sonic sensors for measuring road surface conditions like wetness, temperature, etc. They're mostly used for weather forecasting and road maintenance, but I imagine a simpler device using those metrics could do the job.
For example, rough roads might absorb heat or reflect light irregularly. In this case, it's probably more complex and less applicable to crowdsourced road data collection than to predicting conditions ahead of one's vehicle, but I thought it worth mentioning!