From 2f8d3ac42bb0b5bf644af27b59ee8b02dbb50397 Mon Sep 17 00:00:00 2001 From: lonkaars Date: Wed, 10 May 2023 13:24:46 +0200 Subject: add docs folder with pandoc/latex document template --- doc/makefile | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) create mode 100644 doc/makefile (limited to 'doc/makefile') diff --git a/doc/makefile b/doc/makefile new file mode 100644 index 0000000..9f4dfa0 --- /dev/null +++ b/doc/makefile @@ -0,0 +1,20 @@ +.PHONY: all clean + +TARGET := $(patsubst %.md,%.pdf, $(wildcard *.md)) + +all: $(TARGET) + +garbage = $1.aux $1.bbl $1.bcf $1.blg $1.fdb_latexmk $1.fls $1.log $1.out $1.run.xml $1.synctex.gz $1.toc $1.md.tex + +%.pdf: %.svg + rsvg-convert -f pdf -o $@ $< + +%.pdf: %.tex base.tex %.md.tex + latexmk $< -shell-escape -halt-on-error -lualatex -f -g + +%.md.tex: %.md + pandoc -t latex -o $@ $< + +clean: + $(RM) $(call garbage,research) research.pdf + -- cgit v1.2.3 From 4d1d629ab7a3bd9d661ec5ed25fcf0b4837b946d Mon Sep 17 00:00:00 2001 From: lonkaars Date: Sun, 21 May 2023 14:05:59 +0200 Subject: more documentation --- assets/.gitignore | 1 + assets/architecture-level-0.pdf | Bin 0 -> 6094 bytes assets/figs.drawio | 47 ++++++++++++++ doc/.gitignore | 2 + doc/base.tex | 24 +++++-- doc/dui.md | 136 +++++++++++++++++++++++++++++++++++----- doc/makefile | 8 +-- doc/refs.bib | 0 8 files changed, 192 insertions(+), 26 deletions(-) create mode 100644 assets/.gitignore create mode 100644 assets/architecture-level-0.pdf create mode 100644 assets/figs.drawio create mode 100644 doc/refs.bib (limited to 'doc/makefile') diff --git a/assets/.gitignore b/assets/.gitignore new file mode 100644 index 0000000..cac82ea --- /dev/null +++ b/assets/.gitignore @@ -0,0 +1 @@ +.$* diff --git a/assets/architecture-level-0.pdf b/assets/architecture-level-0.pdf new file mode 100644 index 0000000..48f00a6 Binary files /dev/null and b/assets/architecture-level-0.pdf differ diff --git a/assets/figs.drawio b/assets/figs.drawio new file mode 100644 index 0000000..e7c4c8e --- /dev/null +++ b/assets/figs.drawio @@ -0,0 +1,47 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/doc/.gitignore b/doc/.gitignore index 25dcb3b..e5139ef 100644 --- a/doc/.gitignore +++ b/doc/.gitignore @@ -12,6 +12,8 @@ *.toc *.synctex(busy) *.md.tex +*.lof +*.lot # ignore output files *.pdf diff --git a/doc/base.tex b/doc/base.tex index 9c1c908..edadce3 100644 --- a/doc/base.tex +++ b/doc/base.tex @@ -12,10 +12,13 @@ \usepackage{booktabs} \usepackage{needspace} \usepackage{hyperref} -% \usepackage[backend=biber, -% bibencoding=utf8, -% style=apa -% ]{biblatex} +\usepackage{graphicx} +\usepackage[toc]{glossaries} +\usepackage[backend=biber, + bibencoding=utf8, + style=apa +]{biblatex} +\addbibresource{refs.bib} \setmainfont{TeX Gyre Schola} \setmathfont{TeX Gyre Schola Math} @@ -42,6 +45,13 @@ Niels Stunnebrink\\2184532 } +\newcommand{\req}[1]{$^{\text{\ref{req:#1}}}$} +\newcommand{\up}[1]{$^{\text{#1}}$} +\newcommand{\sub}[1]{$_{\text{#1}}$} + +\floatplacement{figure}{H} +\floatplacement{table}{H} + \begin{document} \begin{titlepage} \maketitle @@ -52,5 +62,11 @@ \newpage \input{\jobname.md.tex} + +% \printbibliography[heading=bibintoc] +% \printglossaries +% \listoftables +% \listoffigures + \end{document} diff --git a/doc/dui.md b/doc/dui.md index 65f242d..f70f4ef 100644 --- a/doc/dui.md +++ b/doc/dui.md @@ -1,29 +1,105 @@ # Introduction -# Problem statement +\ -The following is the original project description (translated to English): +# Problem statement -> I would like to bring to market a vehicle that can drive independently from A -> to B. The vehicle must take into account traffic rules, road signs, traffic -> lights, etc. Research is being conducted using a small cart, the Pololu Zumo -> 32U4, on which a camera module Nicla Vision is mounted. The aim is to -> investigate the most appropriate method of recognizing the road, traffic -> signs and traffic lights. This should be demonstrated with a proof of -> concept. The cart does not need to drive fast, so the image processing does -> not need to be very fast. Assume one frame per second (or faster). +The following is the original project description (translated to English). +References have been added in superscript that link to requirements set in +section \ref{specifications}. + +> I would like to bring to market a vehicle that can drive +> independently\req{autonomous} from A to B. The vehicle must take into account +> traffic rules\req{traffic-rules}, road signs\req{signs}, traffic +> lights\req{traffic-lights}, etc. Research is being conducted using a small +> cart, the Pololu Zumo 32U4\req{zumo}, on which a camera module Nicla +> Vision\req{nicla} is mounted. The aim is to investigate the most appropriate +> method of recognizing the road, traffic signs and traffic lights. This should +> be demonstrated with a proof of concept. The cart does not need to drive +> fast\req{drspeed}, so the image processing\req{mvision} does not need to be +> very fast. Assume one frame per second (or faster)\req{imspeed}. # Specifications +The following is a list of specifications derived from the original project +description in section \ref{problem-statement}. + +\begin{enumerate} + \item \label{req:autonomous} + The vehicle is autonomous + \item + The vehicle can detect how its positioned and orientated relative to a road + \item \label{req:traffic-rules} + The vehicle conforms to the following set of traffic rules + \begin{enumerate} + \item Driving when not on a road is not allowed + \item The vehicle can follow a road by steering itself accordingly + \item Driving off the road is only allowed when necessary for the camera to + keep seeing the road + \end{enumerate} + \item \label{req:traffic-lights} + The vehicle handles traffic lights in the following way + \begin{enumerate} + \item Stop at a red traffic light + \item Speed up at an orange traffic light + \item Continue driving normally at a green traffic light + \end{enumerate} + \item \label{req:signs} + The vehicle acts on traffic signs in the following way + \begin{enumerate} + \item Stop at a stop sign, and continue driving after a few seconds + \item Turn left at a left sign + \item Turn right at a right sign + \item Slow down at a low speed limit sign + \item Speed up to normal speed at a high speed limit sign + \end{enumerate} + \item \label{req:zumo} + The vehicle used is a Pololu Zumo 32U4 + \item \label{req:nicla} + The camera module used is an Arduino Nicla Vision + \item \label{req:mvision} + Computer vision / image processing is used as the only input + \item \label{req:drspeed} + There is no minimum speed the car has to drive at + \item \label{req:imspeed} + The image processing pipeline runs at 1 frame per second or higher + \item + The Zumo displays the name of the last detected sign on it's OLED display +\end{enumerate} + # Architecture +## Overview + +![Architecture overview (level 0) +\label{fig:architecture-level-0}](../assets/architecture-level-0.pdf) + +Figure \ref{fig:architecture-level-0} shows the hardware used in this project. +Both the Pololu Zumo 32U4 (referred to as just "Zumo"), and the Arduino Nicla +Vision ("Nicla") have additional sensors and/or outputs on-board, but are +unused. + +## Distribution of features + +Because creating a software architecture that does all machine vision-related +tasks on the Nicla, and all driving related tasks on the Zumo would create +significant overhead, and because the microcontroller on the Zumo is +significantly harder to debug than the Nicla, a monolithic architecture was +chosen. In this architecture, both the detection of 'traffic objects' and the +decisionmaking on how to handle each object is done on the Nicla board. + +Figure \ref{fig:architecture-level-0} shows that a bidirectional communication +line exists between the Zumo and Nicla. This line is only used to send control +commands to the Zumo. Section \ref{niclazumo-communication-protocol} describes +which commands are sent over these lines. + ## Nicla/Zumo communication protocol The communication protocol used to control the Zumo from the Nicla uses UART to -send ranged numbers in a single byte. Figure \ref{tab:protocol-ranges} shows +send ranged numbers in a single byte. Table \ref{tab:protocol-ranges} shows which number ranges correspond to which controls. -\begin{figure}[h] +\begin{table} \centering \begin{tabular}{rl} \toprule @@ -37,16 +113,16 @@ Steering & \texttt{0x20} - \texttt{0xff}\\ \end{tabular} \caption{Protocol command ranges} \label{tab:protocol-ranges} -\end{figure} +\end{table} ### Signs The Zumo stores the last sign received, and displays it's name on the OLED -display using the lookup table in figure \ref{tab:protocol-signs}. The sign ID +display using the lookup table in table \ref{tab:protocol-signs}. The sign ID is calculated by subtracting the start offset of the sign command range from -the command as shown in figure \ref{tab:protocol-ranges}. +the command as shown in table \ref{tab:protocol-ranges}. -\begin{figure}[h] +\begin{table} \centering \begin{tabular}{ll} \toprule @@ -65,7 +141,7 @@ the command as shown in figure \ref{tab:protocol-ranges}. \end{tabular} \caption{Sign lookup table} \label{tab:protocol-signs} -\end{figure} +\end{table} ### Speed @@ -184,6 +260,32 @@ nog niet}. } \communicationConclusion +## Compiling and linking code for the Zumo + +This section tries to answer the question "What are possible debugging options +for code running on the Zumo robot?". + +Debugging running code can usually be done using an on-device debugger, and a +program that interfaces with the debugger and gcc on a computer. Because gcc +only gives valuable information when it has access to the executable file +running on the microcontroller, an attempt at making a makefile-based toolchain +was made. + +Pololu provides C++ libraries for controlling various parts of the Zumo's +hardware. These libraries make use of functions and classes that are part of +the Arduino core library. The Arduino libraries are all open source, and can in +theory be compiled and linked using make, but this would take more effort than +it's worth, since the Zumo has very little responsibility in the end product. + +\def\buildSystemConclusion{ +Because making a custom build system would take too much time, and because the +Zumo robot's code is very simple, unit tests are used to debug the Zumo's code. +For compiling and uploading the full Zumo firmware, the Arduino IDE is used in +combination with the standard Pololu boards and Libraries. +} +\buildSystemConclusion + # Conclusion \communicationConclusion +\buildSystemConclusion diff --git a/doc/makefile b/doc/makefile index 9f4dfa0..a960c63 100644 --- a/doc/makefile +++ b/doc/makefile @@ -1,10 +1,8 @@ .PHONY: all clean -TARGET := $(patsubst %.md,%.pdf, $(wildcard *.md)) +all: dui.pdf -all: $(TARGET) - -garbage = $1.aux $1.bbl $1.bcf $1.blg $1.fdb_latexmk $1.fls $1.log $1.out $1.run.xml $1.synctex.gz $1.toc $1.md.tex +dui.pdf: ../assets/architecture-level-0.pdf %.pdf: %.svg rsvg-convert -f pdf -o $@ $< @@ -16,5 +14,5 @@ garbage = $1.aux $1.bbl $1.bcf $1.blg $1.fdb_latexmk $1.fls $1.log $1.out $1.run pandoc -t latex -o $@ $< clean: - $(RM) $(call garbage,research) research.pdf + $(RM) dui.aux dui.bbl dui.bcf dui.blg dui.fdb_latexmk dui.fls dui.log dui.out dui.run.xml dui.synctex.gz dui.toc dui.md.tex dui.pdf diff --git a/doc/refs.bib b/doc/refs.bib new file mode 100644 index 0000000..e69de29 -- cgit v1.2.3 From 5e2cfc62ca7d724e6f9e2a4081e0cb5f948ffc71 Mon Sep 17 00:00:00 2001 From: lonkaars Date: Sun, 21 May 2023 18:06:38 +0200 Subject: merge #1 --- .gitignore | 4 ++ README.md | 5 -- assets/LSD_straightLines_Pic_0.bmp | Bin 0 -> 72054 bytes assets/LSD_straightLines_Pic_1.bmp | Bin 0 -> 72054 bytes assets/hough_straightLines_Pic_0.bmp | Bin 0 -> 76854 bytes assets/hough_straightLines_Pic_1.bmp | Bin 0 -> 76854 bytes doc/assets/LSD_straightLines_Pic_0.bmp | Bin 72054 -> 0 bytes doc/assets/LSD_straightLines_Pic_1.bmp | Bin 72054 -> 0 bytes doc/assets/hough_straightLines_Pic_0.bmp | Bin 76854 -> 0 bytes doc/assets/hough_straightLines_Pic_1.bmp | Bin 76854 -> 0 bytes doc/dui.md | 110 +++++++++++++++---------------- doc/makefile | 8 +++ readme.md | 5 ++ 13 files changed, 72 insertions(+), 60 deletions(-) create mode 100644 .gitignore delete mode 100644 README.md create mode 100644 assets/LSD_straightLines_Pic_0.bmp create mode 100644 assets/LSD_straightLines_Pic_1.bmp create mode 100644 assets/hough_straightLines_Pic_0.bmp create mode 100644 assets/hough_straightLines_Pic_1.bmp delete mode 100644 doc/assets/LSD_straightLines_Pic_0.bmp delete mode 100644 doc/assets/LSD_straightLines_Pic_1.bmp delete mode 100644 doc/assets/hough_straightLines_Pic_0.bmp delete mode 100644 doc/assets/hough_straightLines_Pic_1.bmp create mode 100644 readme.md (limited to 'doc/makefile') diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..3f4b7ab --- /dev/null +++ b/.gitignore @@ -0,0 +1,4 @@ +assets/LSD_straightLines_Pic_0.png +assets/LSD_straightLines_Pic_1.png +assets/hough_straightLines_Pic_0.png +assets/hough_straightLines_Pic_1.png diff --git a/README.md b/README.md deleted file mode 100644 index 4317e32..0000000 --- a/README.md +++ /dev/null @@ -1,5 +0,0 @@ -# avans-dui - -d.u.i. (Driving under influence) - -Avans Hogeschool project Vision diff --git a/assets/LSD_straightLines_Pic_0.bmp b/assets/LSD_straightLines_Pic_0.bmp new file mode 100644 index 0000000..54018e2 Binary files /dev/null and b/assets/LSD_straightLines_Pic_0.bmp differ diff --git a/assets/LSD_straightLines_Pic_1.bmp b/assets/LSD_straightLines_Pic_1.bmp new file mode 100644 index 0000000..6a7832f Binary files /dev/null and b/assets/LSD_straightLines_Pic_1.bmp differ diff --git a/assets/hough_straightLines_Pic_0.bmp b/assets/hough_straightLines_Pic_0.bmp new file mode 100644 index 0000000..00a5263 Binary files /dev/null and b/assets/hough_straightLines_Pic_0.bmp differ diff --git a/assets/hough_straightLines_Pic_1.bmp b/assets/hough_straightLines_Pic_1.bmp new file mode 100644 index 0000000..d72285d Binary files /dev/null and b/assets/hough_straightLines_Pic_1.bmp differ diff --git a/doc/assets/LSD_straightLines_Pic_0.bmp b/doc/assets/LSD_straightLines_Pic_0.bmp deleted file mode 100644 index 54018e2..0000000 Binary files a/doc/assets/LSD_straightLines_Pic_0.bmp and /dev/null differ diff --git a/doc/assets/LSD_straightLines_Pic_1.bmp b/doc/assets/LSD_straightLines_Pic_1.bmp deleted file mode 100644 index 6a7832f..0000000 Binary files a/doc/assets/LSD_straightLines_Pic_1.bmp and /dev/null differ diff --git a/doc/assets/hough_straightLines_Pic_0.bmp b/doc/assets/hough_straightLines_Pic_0.bmp deleted file mode 100644 index 00a5263..0000000 Binary files a/doc/assets/hough_straightLines_Pic_0.bmp and /dev/null differ diff --git a/doc/assets/hough_straightLines_Pic_1.bmp b/doc/assets/hough_straightLines_Pic_1.bmp deleted file mode 100644 index d72285d..0000000 Binary files a/doc/assets/hough_straightLines_Pic_1.bmp and /dev/null differ diff --git a/doc/dui.md b/doc/dui.md index a762817..3f72e1c 100644 --- a/doc/dui.md +++ b/doc/dui.md @@ -186,101 +186,101 @@ K_d &= -300.0 ## Detecting lines -The Zumo robot needs to drive in a road map-like environment where it needs to act like a car. With the nicla vision camera, there needs to be a way for detecting lines in every frame to make the Zumo robot ride between the lines. Read lines from an image there are different algorithms to make it work. We need to make sure that it works on the OpenMV program if we only choose this one. In this research, two techniques are researched: convolution-based and feature-based. +The Zumo robot needs to drive in a road map-like environment where it needs to act like a car. With the nicla vision camera, there needs to be a way for detecting lines in every frame to make the Zumo robot ride between the lines. Read lines from an image there are different algorithms to make it work. We need to make sure that it works on the OpenMV program if we only choose this one. In this research, two techniques are researched: convolution-based and feature-based. -### Different line detection algorithms. +### Different line detection algorithms. -#### Hough Transform +#### Hough Transform -This is a popular algorithm used to detect straight lines in an image. It works by transforming the image from Cartesian space to Hough space, where lines are represented as points. The algorithm then looks for clusters of points in Hough space, which correspond to lines in Cartesian space. +This is a popular algorithm used to detect straight lines in an image. It works by transforming the image from Cartesian space to Hough space, where lines are represented as points. The algorithm then looks for clusters of points in Hough space, which correspond to lines in Cartesian space. -For more information about Hough Transform algorithms check the below links: +For more information about Hough Transform algorithms check the below links: -- [Wiki hough](https://en.wikipedia.org/wiki/Hough_transform ) -- [Science article](https://www.sciencedirect.com/topics/computer-science/hough-transforms) -- [OpenCV Hough](https://docs.opencv.org/3.4/d9/db0/tutorial_hough_lines.html) -- [OpenMV find_lines](https://docs.openmv.io/library/omv.image.html) +- [Wiki hough](https://en.wikipedia.org/wiki/Hough_transform ) +- [Science article](https://www.sciencedirect.com/topics/computer-science/hough-transforms) +- [OpenCV Hough](https://docs.opencv.org/3.4/d9/db0/tutorial_hough_lines.html) +- [OpenMV find_lines](https://docs.openmv.io/library/omv.image.html) -#### EDlines +#### EDlines -EDLines, short for Edge Drawing Lines, is a feature-based algorithm that detects straight lines in an image by tracing along the edges of the image. It works by first extracting edges from the image, then building a graph where each edge is represented by a node. The algorithm then uses a greedy strategy to connect the nodes with high edge strength to form line segments. Finally, it merges line segments that are collinear and close to each other to form longer lines. This algorithm does not require a parameter search or optimization and is known for its robustness against noise and partial occlusion. +EDLines, short for Edge Drawing Lines, is a feature-based algorithm that detects straight lines in an image by tracing along the edges of the image. It works by first extracting edges from the image, then building a graph where each edge is represented by a node. The algorithm then uses a greedy strategy to connect the nodes with high edge strength to form line segments. Finally, it merges line segments that are collinear and close to each other to form longer lines. This algorithm does not require a parameter search or optimization and is known for its robustness against noise and partial occlusion. -For more information about EDlines algorithms check the below links: +For more information about EDlines algorithms check the below links: -- [github library](https://github.com/CihanTopal/ED_Lib) -- [Science article](https://www.sciencedirect.com/science/article/abs/pii/S0167865511001772) -- [EDLINES: REAL-TIME LINE SEGMENT DETECTION BY EDGE DRAWING (ED)](https://projet.liris.cnrs.fr/imagine/pub/proceedings/ICIP-2011/papers/1569406487.pdf) -- [OpenCV EDlines doc](https://docs.opencv.org/3.4/d4/d8b/group__ximgproc__edge__drawing.html) +- [github library](https://github.com/CihanTopal/ED_Lib) +- [Science article](https://www.sciencedirect.com/science/article/abs/pii/S0167865511001772) +- [EDLINES: REAL-TIME LINE SEGMENT DETECTION BY EDGE DRAWING (ED)](https://projet.liris.cnrs.fr/imagine/pub/proceedings/ICIP-2011/papers/1569406487.pdf) +- [OpenCV EDlines doc](https://docs.opencv.org/3.4/d4/d8b/group__ximgproc__edge__drawing.html) -#### Line Segment Detector +#### Line Segment Detector -LSD (Line Segment Detector) is an algorithm used for detecting line segments in an image. It works by analyzing the gradient information in the image and clustering nearby gradients that form a line segment. The algorithm first computes the gradient information for the image using the Gaussian filter. It then performs a series of operations, such as non-maximum suppression and thresholding, to obtain a binary edge map. +LSD (Line Segment Detector) is an algorithm used for detecting line segments in an image. It works by analyzing the gradient information in the image and clustering nearby gradients that form a line segment. The algorithm first computes the gradient information for the image using the Gaussian filter. It then performs a series of operations, such as non-maximum suppression and thresholding, to obtain a binary edge map. -The line segments are detected by applying a series of geometric constraints to the edge map. These constraints include the minimum and maximum length of line segments, the minimum angle between line segments, and the maximum deviation of line segments from a straight line. +The line segments are detected by applying a series of geometric constraints to the edge map. These constraints include the minimum and maximum length of line segments, the minimum angle between line segments, and the maximum deviation of line segments from a straight line. -Once the line segments are detected, they are refined using a line merging algorithm combining nearby line segments into longer, more continuous lines. The resulting line segments and their endpoints are returned as the output of the algorithm. +Once the line segments are detected, they are refined using a line merging algorithm combining nearby line segments into longer, more continuous lines. The resulting line segments and their endpoints are returned as the output of the algorithm. -For more information about Line Segment Detector algorithms check the below links: +For more information about Line Segment Detector algorithms check the below links: -- [LSD: a Line Segment Detector pdf](http://www.ipol.im/pub/art/2012/gjmr-lsd/article.pdf) -- [Working behind LSD](https://saiwa.ai/blog/line-segment-detection-2/) -- [OpenCV LSD doc](https://docs.opencv.org/3.4/db/d73/classcv_1_1LineSegmentDetector.html) -- [OpenMV find_line_segments](https://docs.openmv.io/library/omv.image.html) +- [LSD: a Line Segment Detector pdf](http://www.ipol.im/pub/art/2012/gjmr-lsd/article.pdf) +- [Working behind LSD](https://saiwa.ai/blog/line-segment-detection-2/) +- [OpenCV LSD doc](https://docs.opencv.org/3.4/db/d73/classcv_1_1LineSegmentDetector.html) +- [OpenMV find_line_segments](https://docs.openmv.io/library/omv.image.html) -#### Radon transform +#### Radon transform -Radon transform is another popular algorithm used for line detection. It works by computing the line integral of an image along different directions. The algorithm rotates the image at different angles and computes the sum of pixel intensities along each line in the image. The result is a two-dimensional matrix called the Radon transform. Peaks in this matrix correspond to the lines in the original image. The algorithm then applies some post-processing steps to identify and extract the lines from the Radon transform. +Radon transform is another popular algorithm used for line detection. It works by computing the line integral of an image along different directions. The algorithm rotates the image at different angles and computes the sum of pixel intensities along each line in the image. The result is a two-dimensional matrix called the Radon transform. Peaks in this matrix correspond to the lines in the original image. The algorithm then applies some post-processing steps to identify and extract the lines from the Radon transform. -For more information about Radon transform algorithms check the below links: +For more information about Radon transform algorithms check the below links: -- [Science article](https://www.sciencedirect.com/science/article/abs/pii/0031320396000155) -- [matlab Radon](https://stackoverflow.com/questions/35412573/radon-transform-line-detection) -- [Matlab elaboration Radon](https://www.kevinpolisano.com/Doctorat/doc-matlab-exemple/radon_lines_detection.html) -- [OpenCV Radon doc](https://docs.opencv.org/4.x/d5/d89/radon__transform_8hpp.html) +- [Science article](https://www.sciencedirect.com/science/article/abs/pii/0031320396000155) +- [matlab Radon](https://stackoverflow.com/questions/35412573/radon-transform-line-detection) +- [Matlab elaboration Radon](https://www.kevinpolisano.com/Doctorat/doc-matlab-exemple/radon_lines_detection.html) +- [OpenCV Radon doc](https://docs.opencv.org/4.x/d5/d89/radon__transform_8hpp.html) -### Which algorithm is suitable for our project? +### Which algorithm is suitable for our project? -We have identified four different types of line detection algorithms that could potentially be used for our project. To decide on the best algorithm, we need to consider various factors such as accuracy, efficiency, and ease of use. While processing time is not a critical factor in our case, we need to ensure that the algorithm we choose meets our requirements and is accessible through the platform we are using, which is currently openMV but may change to openCV in the future. Therefore, our priority is to select an algorithm that is easy to implement, provides accurate results, and is compatible with our platform. +We have identified four different types of line detection algorithms that could potentially be used for our project. To decide on the best algorithm, we need to consider various factors such as accuracy, efficiency, and ease of use. While processing time is not a critical factor in our case, we need to ensure that the algorithm we choose meets our requirements and is accessible through the platform we are using, which is currently openMV but may change to openCV in the future. Therefore, our priority is to select an algorithm that is easy to implement, provides accurate results, and is compatible with our platform. -#### OpenMV +#### OpenMV -The only two algorithms that work with OpenMV are Hough Transform, the function find_lines, and Line Segment Detector, also known as find_line_segments. Both of these have their ups and downs and could be used for our project. find_lines has the most ups whereas find_line_segemtns has the most negative. As the result here below is decently optimized, it is first grayscaled, and then canny edge detection is done to it. +The only two algorithms that work with OpenMV are Hough Transform, the function find_lines, and Line Segment Detector, also known as find_line_segments. Both of these have their ups and downs and could be used for our project. find_lines has the most ups whereas find_line_segemtns has the most negative. As the result here below is decently optimized, it is first grayscaled, and then canny edge detection is done to it. -For the test are the straight lines pictures used with different lighting additionality the left lane represents a whitish line and the right lane is drawn with a more darker color. here below are the pictures used: +For the test are the straight lines pictures used with different lighting additionality the left lane represents a whitish line and the right lane is drawn with a more darker color. here below are the pictures used: -![picture 1](../RealTime_pictures/rtstraightLines.class/00000.jpg) +![picture 1](../RealTime_pictures/rtStraightLines.class/00000.jpg) -![picture 2](../RealTime_pictures/rtStraightLines.class/00018.jpg) +![picture 2](../RealTime_pictures/rtStraightLines.class/00018.jpg) -##### find_lines +##### find_lines -The find_lines is a very fast function where you can handle straight lines and other lines with at least 45 FPS or more. Also, have a lot of control over the different types of parameters. +The find_lines is a very fast function where you can handle straight lines and other lines with at least 45 FPS or more. Also, have a lot of control over the different types of parameters. -This is the outcome of picture 1: -![outcome_picture_1](./assets/hough_straightLines_Pic_0.bmp) +This is the outcome of picture 1: +![outcome_picture_1](../assets/hough_straightLines_Pic_0.png) -This is the outcome of picture 2: -![outcome_picture_2](./assets/hough_straightLines_Pic_1.bmp) +This is the outcome of picture 2: +![outcome_picture_2](../assets/hough_straightLines_Pic_1.png) -As you can see there isn't much of a difference between the two pictures. +As you can see there isn't much of a difference between the two pictures. -##### find_line_segments +##### find_line_segments -The find_line_segments is a very slow function where you can find segments from a line. This is a easier to use function because it only has two parameters but the frame rate drops significantly. Additionally, the size of the image to run the algorithm on needs to be smaller because of memory. +The find_line_segments is a very slow function where you can find segments from a line. This is a easier to use function because it only has two parameters but the frame rate drops significantly. Additionally, the size of the image to run the algorithm on needs to be smaller because of memory. -This is the outcome of picture 1: +This is the outcome of picture 1: -![outcome_picture_1](./assets/LSD_straightLines_Pic_0.bmp.bmp) +![outcome_picture_1](../assets/LSD_straightLines_Pic_0.png) -This is the outcome of picture 2: +This is the outcome of picture 2: -![outcome_picture_2](./assets/LSD_straightLines_Pic_1.bmp.bmp) +![outcome_picture_2](../assets/LSD_straightLines_Pic_1.png) -As you can see there is quite a lot of difference between them. This function needs more refinement but I couldn't find the sweet spot. Also, the right line in different pictures was always the problem, so there needs another solution for this function to work better. +As you can see there is quite a lot of difference between them. This function needs more refinement but I couldn't find the sweet spot. Also, the right line in different pictures was always the problem, so there needs another solution for this function to work better. -#### OpenCV +#### OpenCV -All the above algorithms could be used with OpenCV, But the Radon transform needs more work than the others with the amount of information in the doc. +All the above algorithms could be used with OpenCV, But the Radon transform needs more work than the others with the amount of information in the doc. ## Communication between the Nicla and Zumo diff --git a/doc/makefile b/doc/makefile index a960c63..3446eeb 100644 --- a/doc/makefile +++ b/doc/makefile @@ -3,6 +3,13 @@ all: dui.pdf dui.pdf: ../assets/architecture-level-0.pdf +dui.pdf: ../assets/LSD_straightLines_Pic_0.png +dui.pdf: ../assets/LSD_straightLines_Pic_1.png +dui.pdf: ../assets/hough_straightLines_Pic_0.png +dui.pdf: ../assets/hough_straightLines_Pic_1.png + +%.png: %.bmp + convert $< $@ %.pdf: %.svg rsvg-convert -f pdf -o $@ $< @@ -15,4 +22,5 @@ dui.pdf: ../assets/architecture-level-0.pdf clean: $(RM) dui.aux dui.bbl dui.bcf dui.blg dui.fdb_latexmk dui.fls dui.log dui.out dui.run.xml dui.synctex.gz dui.toc dui.md.tex dui.pdf + $(RM) ../assets/LSD_straightLines_Pic_0.png ../assets/LSD_straightLines_Pic_1.png ../assets/hough_straightLines_Pic_0.png ../assets/hough_straightLines_Pic_1.png diff --git a/readme.md b/readme.md new file mode 100644 index 0000000..4317e32 --- /dev/null +++ b/readme.md @@ -0,0 +1,5 @@ +# avans-dui + +d.u.i. (Driving under influence) + +Avans Hogeschool project Vision -- cgit v1.2.3