pothole detection -凯发k8网页登录

download input file

this example uses the potholes2.avi file as an input. the file is approximately 50 mb in size. download the file from the mathworks website and unzip the downloaded file.

potholezipfile = matlab.internal.examples.downloadsupportfile('visionhdl','potholes2.zip');
[outputfolder,~,~] = fileparts(potholezipfile);
unzip(potholezipfile,outputfolder);
potholevideofile = fullfile(outputfolder,'potholes2');
addpath(potholevideofile);

introduction

the system is shown below. the potholehdl subsystem contains the pothole detector and overlay algorithms and supports hdl code generation. there are four input parameters that control the algorithm. the processorbehavioral subsystem writes character maps into a ram for use as overlay labels.

modelname = 'potholehdldetector';
open_system(modelname);
set_param(modelname,'sampletimecolors','on');
set_param(modelname,'simulationcommand','update');
set_param(modelname,'open','on');
set(allchild(0),'visible','off');

overview of the fpga subsystem

the potholehdl subsystem converts the rgb input video to intensity, then performs bilateral filtering and edge detection. the trapezoidalmask subsystem selects the roadway area. then the design applies a morphological close and calculates centroid coordinates for all potential potholes. the detector selects the largest pothole in each frame and saves the center coordinates. the pixel stream aligner matches the timing of the coordinates with the input stream. finally, the fiducial31x31 and the overlay32x32 subsystems apply alpha channel overlays on the frame to add a pothole center marker and a text label.

open_system([modelname '/potholehdl'],'force');

input parameter values

the subsystem has four input parameters that can change while the system is running.

the gradient intensity parameter, gradient threshold, controls the edge detection part of the algorithm.

the cartoon rgb parameter changes the color of the overlays, that is, the fiducial marker and the text.

the area threshold parameter sets the minimum number of marked pixels in the detection window in order for it to be classified as a pothole. if this value is too low, then linear cracks and other defects that are not road hazards will be detected. if it is too high then only the largest hazards will be detected.

the final parameter, show raw, allows you to debug the system more easily. it toggles the displayed image on which the overlays are drawn between the rgb input video and the binary image that the detector sees. set this parameter to 1 to see how the detector is working.

all of these parameters work best if changes are only allowed on video frame boundaries. the frameboundary subsystem registers the parameters only on a valid start of frame.

open_system([modelname '/potholehdl/frameboundary'],'force');

rgb to intensity

the model splits the input rgb pixel stream so that a copy of the rgb stream continues toward the overlay blocks. the first step for the detector is to convert from rgb to intensity. since the input data type for the rgb is uint8, the rgb to intensity block automatically selects uint8 as the output data type.

bilateral filter

the next step in the algorithm is to reduce high visual frequency noise and smaller road defects. there are many ways this can be accomplished but using a bilateral filter has the advantage of preserving edges while reducing the noise and smaller areas.

the bilateral filter block has parameters for the neighborhood size and two standard deviations, one for the spatial part of the filter and one for the intensity part of the filter. for this application a relatively large neighborhood of 9x9 works well. this model uses 3 and 0.75 for the standard deviations. you can experiment with these values later.

sobel edge detection

the filtered image is then sent to the sobel edge-detection block which finds the edges in the image and returns those edges that are stronger than the gradient threshold parameter. the output is a binary image. in your final application, this threshold can be set based on variables such as road conditions, weather, image brightness, etc. for this model, the threshold is an input parameter to the potholehdl subsystem.

trapezoidal mask

from the binary edge image, you need to remove any edges that are not relevant to pothole detection. a good strategy is to use a mask that selects a polygonal region of interest and makes the area outside of that black. the model does not use a normal roi block since that would remove the location context that you need later for the centroid calculation and labeling.

the order of operations also matters here because if you used the mask before edge detection, the edges of the mask would become strong lines that would result in false positives at the detector.

in the input video, the area in which the vehicle might encounter a pothole is limited to the roadway immediately in front of it and a trapezoidal section of roadway ahead. the exact coordinates depend on the camera mounting and lens. this example uses fixed coordinates for left-side top, right-side top, left-side bottom, and right-side bottom corners of the area. for this video, the top and bottom of the trapezoidal area are not parallel so this is not a true trapezoid.

the mask consists of straight lines between the corners, connecting left,right and top,bottom.

     ltc---rtc
     /       \
    /         \
   /           \
lbc-------------rbc

this example uses polyfit to determine a straight-line fit from corner to corner. for ease of implementation, the design calls polyfit with the vertical direction as the independent variable. this usage calculates x = f(y) instead of the more usual y = f(x). using polyfit this way allows you to use a y-direction line counter as the input address of a lookup table of x-coordinates of the start (left) and end (right) of the area of interest on each line.

the lookup table is typically implemented in a bram in an fpga, so it should be addressed with 0-based addressing. the model converts from matlab 1-based addressing to 0-based addressing just before the luts. to further reduce the size of the lookup table, the address is offset by the starting line of the trapezoid. in order to get good synthesis results, match typical block ram registering in fpgas by using a register after the lookup table. this register also adds some modest pipelining to the design.

for the 320x180 image:

raster = [320,180];
ltc = [155, 66];
lbc = [  1,140];
rtc = [155, 66];
rbc = [285,179];
% fit to x = f(y) for convenient lut indexing
abl = polyfit([lbc(2),ltc(2)],[lbc(1),ltc(1)],1);  % left side
abr = polyfit([rbc(2),rtc(2)],[rbc(1),rtc(1)],1);  % right side
leftxstart = max(1,round((ltc(2):rbc(2))*abl(1) abl(2)));
rightxend  = min(raster(1),round((ltc(2):rbc(2))*abr(1) abr(2)));
startline  = min(ltc(2),rtc(2));
endline    = max(lbc(2),rbc(2));
% correct to zero-based addressing
leftxstart = leftxstart - 1;
rightxend = rightxend - 1;
startline = startline - 1;
endline = endline - 1;
open_system([modelname '/potholehdl/trapezoidalmask'],'force');

morphological closing

next the design uses the morphological closing block to remove or close in small features. closing works by first doing dilation and then erosion, and helps to remove small features that are not likely to be potholes. specify a neighborhood on the block mask that determines how small or large a feature you want to remove. this model uses a 5x5 neighborhood, similar to a disk, so that small features are closed in.

centroid

the centroid calculation finds the center of an active area. the design continuously computes the centroid of the marked area in each 31x31 pixel region. it only stores the center coordinates when the detected area is larger than an input parameter. this is a common difference between hardware and software systems: when designing hardware for fpgas it is often easier to compute continuously but only store the answer when you need it, as opposed to calling functions as-needed in software.

for a centroid calculation, you need to compute three things from the region of the image: the weighted sum of the pixels in the horizontal direction, the weighted sum in the vertical direction, and the overall sum of all the pixels which corresponds to the area of the marked portion of the region. the line buffer selects regions of 31x31 pixels, and returns them one column at a time. the algorithm uses the column to compute vertical weights, and total weights. for the horizontal weights, the design combines the columns to obtain a 31x31 kernel. you can choose the weights depending on what you want "center" to mean. this example uses -15:15 so that the center of the 31x31 region is (0,0) in the computed result.

the vision hdl toolbox blocks force the output data to zero when the output is not valid, as indicated in the pixelcontrol bus output. while not strictly required, this behavior makes testing and debugging much easier. to accomplish this behavior for the centroid results, the model uses switch blocks with a constant block set to 0.

since you want the center of the detected region to be relative to the overall image coordinate system, add the horizontal and vertical pixel count to the calculated centroid.

open_system([modelname '/potholehdl/centroid31'],'force');

open_system([modelname '/potholehdl/centroid31/centroidkernel'],'force');

detect and hold

the detector operates on the total area sum from the centroid. the detector itself is very simple: compare the centroid area value to the threshold parameter, and find the largest area that is larger than the threshold. the model logic compares a stored area value to the current area value and stores a new area when the input is larger than the currently stored value. by using > or >= you can choose the earliest value over the threshold or the latest value over the threshold. the model stores the latest value because later values are closer to the camera and vehicle. when the detector stores a new winning area value, it also updates the x and y centroid values that correspond to that area. these coordinates are then passed to the alignment and overlay parts of the subsystem.

to pass the x, y, and valid indication to the alignment algorithm, pack the values into one 23-bit word. the model unpacks them once they are aligned in time with the input frames for overlay.

open_system([modelname '/potholehdl/detectandhold'],'force');

pixel stream aligner

the pixel stream aligner block takes the streaming information from the detector and sends it and the original rgb pixel stream to the overlay subsystems. the aligner compensates for the processing delay added by all the previous parts of the detection algorithm, without having to know anything about the latency of those blocks. if you later change a neighborhood size or add more processing, the aligner can compensate. if the total delay exceeds the maximum number of lines parameter of the pixel stream aligner block, adjust the parameter.

fiducial overlay

the fiducial marker is a square reticle represented as a 31-element array of 31-bit fixed-point numbers. this representation is convenient because a single read returns the whole word of overlay pixels for each line.

the diagram shows the overlay pattern by converting the fixed-point data to binary. this pattern can be anything you wish within the 31x31 size in this design.

load fiducialrom31x31.mat
crosshair = bin(fiducialrom);
crosshair(crosshair=='0') = ' ' %change '0' to space for better display

crosshair =
  31×31 char array
    '               1               '
    '               1               '
    '               1               '
    '               1               '
    '    11111111111111111111111    '
    '    1          1          1    '
    '    1          1          1    '
    '    1          1          1    '
    '    1          1          1    '
    '    1          1          1    '
    '    1          1          1    '
    '    1          1          1    '
    '    1                     1    '
    '    1                     1    '
    '    1                     1    '
    '111111111111       111111111111'
    '    1                     1    '
    '    1                     1    '
    '    1                     1    '
    '    1          1          1    '
    '    1          1          1    '
    '    1          1          1    '
    '    1          1          1    '
    '    1          1          1    '
    '    1          1          1    '
    '    1          1          1    '
    '    11111111111111111111111    '
    '               1               '
    '               1               '
    '               1               '
    '               1               '

the fiducial overlay subsystem has a horizontal and vertical counter with a set of four comparators that uses the center of the detected area as the center of the region for the marker. the marker data is used as a binary switch that turns on alpha channel overlay. the alpha value is a fixed transparency parameter applied as a gain on the binary detect signal when it is unpacked, in the expanddata subsystem.

open_system([modelname '/potholehdl/fiducial31x31'],'force');

character overlay

the character font rom for the on-screen display stores data in a manner similar to the fiducial rom described above. each 16-bit fixed-point number represents 16 consecutive horizontal pixels. the character maps are 16x16.

since the character data would typically be written by a cpu in ascii, the simplest way is to store the character data under 8-bit ascii addresses in a dual-port ram. the font rom stores ascii characters 33 ("!") to 122 ("z"). the design offsets the address by 33.

the font rom was constructed from a public domain fixed width font with a few edits to improve readability. as in the fiducial marker, the character rom data is used as a binary switch that turns on alpha channel overlay. the character alpha value is a fixed transparency parameter applied as a gain on the detect signal when it is unpacked, in the expanddata subsystem.

to visualize the character b in the font rom, display it in binary.

load charrom16x16.mat
letterb = bin(charrom16x16(529:544)); % character array
letterb(letterb=='0')=' ' % remove '0' chars for better display

letterb =
  16×16 char array
    '                '
    '  111111111     '
    '  11111111111   '
    '   111    111   '
    '   111     111  '
    '   111     111  '
    '   111    111   '
    '   1111111111   '
    '   111111111    '
    '   111    111   '
    '   111     111  '
    '   111     111  '
    '   111     111  '
    '   111    1111  '
    '  11111111111   '
    '  111111111     '

open_system([modelname '/potholehdl/overlay32x32'],'force');

viewing detector raw image

when you work with a complicated algorithm, viewing intermediate steps in the processing can be very helpful for debugging and exploration. in this model, you can set the boolean show raw parameter to 1 (true) to display the result of morphological closing of the binary image, with the overlay of the detected results. to convert the binary image for use with the 8-bit rgb overlay, the model multiplies the binary value by 255 and uses that value on all three color channels.

hdl code generation

to check and generate the hdl code referenced in this example, you must have an hdl coder™ license.

to generate the hdl code, use the following command.

makehdl('potholehdldetector/potholehdl')

to generate the test bench, use the following command. note that test bench generation takes a long time due to the large data size. you may want to reduce the simulation time before generating the test bench.

makehdltb('potholehdldetector/potholehdl')

the part of this model that you can implement on an fpga is the part between the frame to pixels and pixels to frame blocks. that is the subsystem called potholehdl, which includes all the elements of the detector.

simulation in an hdl simulator

now that you have hdl code, you can simulate it in your hdl simulator. the automatically generated test bench allows you to prove that the simulink simulation and the hdl simulation match.

synthesis for an fpga

you can also synthesize the generated hdl code in an fpga synthesis tool, such as xilinx vivado. in a virtex-7 fpga (xc7v585tffg1157-1), the design achieves a clock rate of over 150 mhz.

the utilization report shows that the bilateral filter, pixel stream aligner, and centroid functions consume most of the resources in this design. the bilateral filter requires the most dsps. the centroid implementation is quite efficient and uses only two dsps. centroid calculation also requires a reciprocal lookup table and so uses a large number of luts as memory.

going further

this example shows one possible implementation of an algorithm for detecting potholes. this design could be extended in the following ways :

conclusion

this model shows how a pothole detection algorithm can be implemented in an fpga. many useful parts of this detector can be reused in other applications, such as the centroid block and the fiducial and character overlay blocks.

references

[1] koch, christian, and ioannis brilakis. "pothole detection in asphalt pavement images." advanced engineering informatics 25, no. 3 (2011): 507-15. doi:10.1016/j.aei.2011.01.002.

[2] omanovic, samir, emir buza, and alvin huseinovic. "pothole detection with image processing and spectral clustering." 2nd international conference on information technology and computer networks (ictn '13), antalya, turkey. october 2013.