Pothole Detection and Direction-Aware Broadcasting on the Turtlebot
Platform
Alec Russell1 , Weston Shellhorn2 , and Tim Pham3
Abstract— This paper provides a pothole detection imple-
mentation and research into direction-aware broadcasting using
the Turtlebot3 Burger robot. The z-peak [1] algorithm is the
basis of this implementation and inspired the concept of the
peak detection algorithm we have developed. The comparison
of the Turtlebot linear z-acceleration data and the algorithm
timestamps provides the approach to evaluate the implementa-
tion effectiveness. In addition, our Turtlebot pothole detection
algorithm is tested at multiple speeds and surface scenarios to
ensure that the algorithm has versatility in the implementation.
This paper also proposes a directional broadcasting approach,
allowing the Turtlebot platform to establish the specification
of relevant entities to communicate to. The pothole detection
algorithm we created was able to identify potholes simulated in
our 6 experimental test cases, while providing an opportunity
for a potential direction-aware broadcasting element to be
implemented in the future.
I. INTRODUCTION
Throughout the United States, road infrastructure is
constantly crumbling and being rebuilt due to the climate
variations throughout the year as well as the immense
amount of vehicles on the roadways. In 2017, the United
States Federal Government spent 180 billion dollars on
highways, with 47% of this highway spending going to
operation and maintenance of the roadways themselves
[2] [Figure 1]. This breaking down of road infrastructure
leads to many hazards that drivers deal with daily such as
wearing road markings, rough road, and potholes. Of these
hazards, potholes cause an average of $300 per driver per
year in damage to a vehicles suspension, wheels, and rims
[3]. Through research using the Turtlebot platform, we hope
to improve safety for autonomous vehicles by detecting and
warning of oncoming potholes in a way that is conducive to
the future of connected vehicles. In the world of intervehicle
networks, it is imperative that data can be shared in a way
that is optimized at scale, efficient, and dynamic [4]. This
is why in addition to our pothole detection algorithm, we
wanted to provide research into a possible direction-aware
broadcasting system on the Turtlebot platform, such as
GeoCast messages or directional antennae. This would allow
us conserve bandwidth and spectrum utilization by only
sending information about a pothole to vehicles considered
to be on a path of collision; Vehicles avoiding oncoming
potholes detected by other vehicles. By reducing congestion
through direction-aware broadcasting, issues such as packet
loss and performance degradation can be mitigated. [2]
Fig. 1. US Budget In 2017, the United States spent $84.6 Billion Dollars
on the operation and maintenance of highways [2].
II. PRIOR ART
The amount of sensors on board each modern vehicle is
substantially large, containing up to 2500 signals throughout
different areas of the vehicle [4],[5]. Vehicles are only
becoming more complex as time passes, and the quantity
of these sensors as well as the data they collect will
likely increase respectively [4]. Not only is this providing
intelligent characteristics to ones regular drive, but also a
rich and considerable amount of data to utilize. With these
various types of computing modules available, they can
form an intra-vehicular connectivity. Allowing each module
to learn, communicate, and take action about information
within the car locally. For this particular implementation, an
accelerometer is used to measure the physical acceleration
experienced by the robot. The data is processed appropriately
in order to establish the presence of a pothole. Simply put,
this implementation provides an example application where
the data provided by the on board sensors can be deploy to
provide practical information.
The feasibility of this implementation is predicated on past
research done on the z-peak pothole detection algorithm [1]
as well as implementations done on generic hardware such
as smartphones [6]. The implementation provided by z-peak
uses a complex filtering technique where the accelerometer
data is segmented into multiple samples to be processed.
Each segment goes through a series of filters to remove
characteristics from events that are similar, but not quite
a pothole. Because the testing scenario and environment
used in this implementation is well-controlled, many of the
filtering techniques used in z-peak can be ignored. Peak
acceleration in the z-axis is a significant characteristic in
all road anomalies [1]. Therefore, linear z-axis acceleration
data is particularly emphasized in this implementation.
To even further increase the utilization of this data, the
data can be extended beyond the confinements of the vehicle.
There are several possible solutions in which vehicles can
share data amongst each other. An example solution is the
use of GeoCast messages [7]. Messages are dependent on
vehicles accurately reporting their own location [4]. By
sending out a direction-aware broadcast when a vehicle
has encountered a pothole, the recipient can determine the
location of the pothole assuming the vehicles location at the
instance of detection was transmitted. However this approach
suffers from handshaking overhead which leads to additional
network congestion [4]. This solution is the most feasible for
the Turtlebot platform due to internet connectivity provided
by the on-board Raspberry Pi. Beaconing can be performed
on the network the Turtlebot is connected to. This network
will have to establish the port(s) and database in which the
location service can be provided. This establish the query
mechanism to individual Turtlebot to communicate to. Deci-
sions to relay the message will need to happen on the network
because Turtlebot-2-Turtlebot communication is complex to
establish without additional hardware components.
Physical antennae could be integrated into the Turtlebot
platform, if the assumption is made that each vehicle is
aware of the position and direction of selected neighbors [8].
This method distributes the information by selecting vehicles
based on the distance from the transmitting vehicle and the
angle they have with respect to the transmitting vehicle. The
transmitter will have to determine the beamforming angle.
The calculation would be based on the trade-off of the
message urgency and available resources on the platform.
In particular, the level of urgency will provide an acceptable
transmission failure and the available resources will limit the
bandwidth used to send the directional signal.
III. PROPOSED SOLUTION
A. Turtlebot Background
The Turtlebot3 Burger platform will be used for testing of
our pothole detection algorithm. The Turtlebot3 is a small,
affordable, programmable, ROS-based mobile robot for use
in education, research, hobby, and product prototyping [Fig-
ure 2] [9]. One of the more useful hardware components in
the Turtlebot3 is the Inertial Measurement Unit (IMU) which
provides the linear acceleration components in the x,y, and
z axis.
B. Pothole Detection
By analyzing data of the linear acceleration in z-direction
provided by the inertial measurement unit on the Turtlebot
platform, an algorithm can be ascertained to identify potholes
on the roads surface. Normally the linear acceleration in
the z-direction acting upon the Turtlebot, while stationary,
is approximately 9.8m/sˆ2. This value also holds relatively
constant when moving over a flat surface. However when
the Turtlebot encounters a pothole it is momentarily in free
fall for a short period of time. This results in a higher
linear acceleration z-component reading. When the Turtlebot
Fig. 2. ROBOTIS Turtlebot3 Platform This robot is developed by
ROBOTIS for test and research using the ROS operating system.
exits the pothole, the linear acceleration z-component reading
is momentarily lower than 9.8m/sˆ2. Thus the proposed
solution is to create a ROS node in order to calculate these
large and contiguous variations in the IMU data that occur
when a pothole is encountered.
To identify these peaks in the IMU data, every published
linear acceleration z-component will be pushed onto a stack.
Additionally, the interquartile range at the 1st percentile and
99th percentile will be calculated using this stack. Published
values either below the 1st percentile or above the 99th
percentile will be considered of statistical significance and
will be appended to a outlier stack. If the next recorded
value lies within the interquartile range the last value on
the stack is removed. Once the size of the outlier stack is at
least three (i.e. three contiguous recordings of values outside
the interquartile range) this is an indication that pothole has
been encountered. The output of the algorithm provides a
list of time stamps at which each pothole was detected.
By matching these outputs to the Z-axis linear acceleration
from the IMU data, we should be able to prove that the
implementation is able to detect potholes within a certain
margin of error.
In order to reduce false positives in this algorithm, no
detection is performed on the first 750 recorded values. These
values serve to establish a baseline environment to provide
more data before identifying outliers (i.e. the calibration
to the environment). By requiring a series of contiguous
outliers to classify a pothole false positives from noise, small
bumps, and other low impact variations in the environment
are disregarded - however still included in the interquartile
range calculation to more accurately adjust for normal road
conditions.
Once a pothole has been detected it is advantageous to
warn vehicles in the same trajectory so they may either slow
down or avoid the pothole. However, only the vehicles that
are in the same path should be alerted (those in other lanes
or simply nearby should not receive a message). Given that
the implementation detects potholes in real time, one of the
direction-aware broadcasting methods mentioned in the prior
art can now be incorporated to appropriately alert vehicles
that may encounter the pothole.

IV. EXPERIMENTAL DESIGN

To test our pothole detection algorithm a series of test
environments were constructed using cardboard to simulate
potholes. In each of these environments a flat track of
cardboard was laid out with a separation in order to model
various types of potholes a vehicle could encounter. The Fig. 4. Profile View Experimental cardboard pothole using 2nd (fractured)
robot will first drive from flat ground, and travel two steps up topography.
onto a raised plane until it reaches the flat cardboard surface
0.25 inches above the ground. The robot will then drive
across the flat cardboard plane and encounter the pothole at
the end of the setup. Two pothole topographies were chosen
for the experiments: A commonly found rounded pothole
which is smoothed by the tires of cars, and a jagged step
pothole simulating a fractured or broken pothole [Figure
3]. For each test the pothole dimensions were chosen to
be a width of 2.5” and a depth of 0.25” as to simulate a
Fig. 5. Aerial View Full experiment setup, stepping up robot until it is
pothole with a relative depth to the wheels diameter. With 0.25” above flat ground
the wheel diameter of the Turtlebot being 2.5” (66mm),
the experimental pothole depths were chosen to be 10% of
the the wheel diameter which is analogous to a 3” deep V. CONCLUSIONS
pothole for a 30” diameter car wheel on a full automotive
A. Results
vehicle. The speeds were chosen reflecting a range of the
possible Turtlebot speeds in order to see if velocity would Our pothole detection algorithm was able to detect the
be a factor that affects the data set. Due to the limitations test potholes using the test cases we provided. Looking at
of the Turtlebot hardware, these speeds are not analogous to the data for Tests 1-6 (Figure 6, Figures 7-12: Appendix),
specific velocities of a full automotive car. there is a clear increase in magnitude of the z-axis linear
We tested the Turtlebot at 3 speeds for each test case: acceleration as the robot encounters each side of the pothole
0.5 m/s, 1 m/s, and 1.5 m/s. This allowed us to test our in the last few seconds. Our algorithm correctly classifies
detection algorithm under multiple different parameters as each of these increases in magnitude as a pothole for each
well as test the robustness of the algorithm. Shown below is side by identifying that these potholes create 3 acceleration
our Z-axis linear acceleration captured from plotting the IMU data points in a row that are outside of our preset interquartile
data published by the robot while it rides over each pothole range.
test case. Each marker on the graph indicates where our
pothole detection algorithm reported an encountered pothole.

Fig. 6. Test 1 Pothole Topography 1, Speed = 0.5 m/s. Each blue marker
represents a pothole detected by the algorithm. Full set of data figures in
appendix section.

As the speed of the robot increases, the linear acceleration

data becomes much more noisy, making it more difficult to
correctly identify potholes. Our algorithm identifies two false
positive potholes in Test 4 [Figure 10] and Test 5 [Figure 11],
at 6 and 10 seconds respectively. This is likely due to our test
setup using an uneven cardboard plane which is stepping the
robot up before the pothole drop. There is also a variation
Fig. 3. Pothole Topographies 1: Rounded, 2: Fractured in time spent between each side of the pothole (comparing
Test 3 [Figure 9] to Test 1 [Figure 7] and 2 [Figure 8]) due
to limitations in the Turtlebot platform, such as rigid wheels
and low torque, which make it sometimes difficult for the
robot to climb over ledge and get stuck for a brief period of
time.
B. Future Work
The pothole detection algorithm is not without its flaws.
For example, given the size of the stack of recorded data
continuously grows, it will proportionally take an increas-
ingly longer amount of time to calculate the interquartile Fig. 8. Test 2 Pothole Topography 1, Speed = 1.0 m/s.
range. This is especially true for the addition of every
newly recorded value; Making the algorithm infeasible for
capturing data over long periods of time. Another flaw is
that if the Turtlebot moves over a large series of potholes
the interquartile range can be skewed to include values that
would normally characterize a pothole. This would cause the
Turtlebot to not properly detect a pothole. The algorithm is
also generalized when identifying potholes. It detects other
variations in the road surface that produce this pattern such
as rail road tracks or manhole covers. This flaw is similar
to the difficulty found in the implementation of the z-peak
algorithm [1]. Fig. 9. Test 3 Pothole Topography 1, Speed = 1.5 m/s.
To deal with these flaws, future research could be per-
formed to identify how often the interquartile range should
be updated to identify potholes. Additional research could
be performed to evaluate the trade-offs of utilizing a rolling
buffer of values as opposed to the entire history of recorded
values.
APPENDIX
The following set of data are a result of experiments
described in the experimental design section. Blue markers
represent a point where the pothole detection algorithm
Fig. 10. Test 4 Pothole Topography 2, Speed = 0.5 m/s.
correctly determined the robot has encountered a pothole as
intentionally set up by design. Red markers represent a point
where the pothole detection algorithm determined the robot
encountered a pothole; These red markers indicate a false
positive, and were not potholes intentionally designed for
the experiment. The results of the data are discussed in the
conclusions section.

Fig. 11. Test 5 Pothole Topography 2, Speed = 1.0 m/s.

Fig. 7. Test 1 Pothole Topography 1, Speed = 0.5 m/s. This figure is a

copy of the example figure shown in the conclusions section

Fig. 12. Test 6 Pothole Topography 2, Speed = 1.5 m/s.

 R EFERENCES
[1] Jakob Eriksson, Lewis Girod, Bret Hull, Ryan Newton, Samuel
Madden, and Hari Balakrishnan, The Pothole Patrol: Using a Mobile
Sensor Network for Road Surface Monitoring. Mobisys ’08 The
6th International Conference on Mobile Systems, Applications, and
Services
[2] Public Spending on Transportation and Water Infrastructure, 1956 to
2017. Congressional Budget Office, Nonpartisan Analysis for the U.S.
Congress. https://www.cbo.gov/publication/54539
[3] (Unpublished) AAA Pothole Damages to U.S. Motorists,
https://www.pothole.info/2018/04/the-cost-of-car-damages-from-
potholes/
[4] Joshua E. Siegel, Dylan C. Erb, and Sanjay E. Sarma, A Survey of the
Connected Vehicle Landscape Architectures, Enabling Technologies,
Applications, and Development Areas. IEEE Transactions on Intelli-
gent Transportation Systems (Volume: 19 , Issue: 8 , Aug. 2018)
[5] M. Broy, Challenges in automotive software engineering, in Proc. 28th
Int. Conf. Softw. Eng., New York, NY, USA, 2006, pp. 3342
[6] Amir H. Alavi and William G. Buttlar, An Overview of Smartphone
Technology for Citizen-centered, Real-time, and Scalable Civil Infras-
tructure Monitoring. Future Generation Computer Systems 93
[7] P. Papadimitratos, A. De La Fortelle, K. Evenssen, R. Brignolo, and
S. Cosenza, Vehicular communication systems: Enabling technologies,
applications, and future outlook on intelligent transportation,IEEE
Commun. Mag., vol. 47, no. 11, pp. 8495, Nov. 2009.
[8] Ahmed Soua, Walid Ben-Ameur, Hossam Afifi, Broadcast-based di-
rectional routing in vehicular ad-hoc networks. 2012 5th Joint IFIP
Wireless and Mobile Networking Conference (WMNC)
[9] http://emanual.robotis.com/docs/en/platform/turtlebot3/overview/
ROBOTIS Turtlebot Platform source, manual, and diagrams.