Another major design change which occurred quite early in the project is the switch from using multiple processes to running a single multithreaded process on the server. After performing some rudimentary testing (see Section \ref{Server Interface}) it became clear that a system of separate programs would be difficult to implement and maintain. Threads are similar to processes but are able to directly share memory, with the result that much less synchronisation is required in order to transfer information.
-{\bf Note on filenames:} In the following, files and directories related to the server are located in the \href{https://github.com/szmoore/MCTX3420/tree/master/server}{server} directory, files related to the (currently used) GUI are in \href{https://github.com/szmoore/MCTX3420/tree/master/testing/MCTXWeb}{testing/MCTXWeb}, and files created for testing purposes are located in \href{https://github.com/szmoore/MCTX3420/tree/master/testing}{testing}.
+{\bf Note on filenames:} In the following, files and directories related to the server are located in the \href{https://github.com/szmoore/MCTX3420/tree/master/server}{server} directory, files related to the (currently used) GUI are in \href{https://github.com/szmoore/MCTX3420/tree/master/testing/MCTXWeb}{testing/MCTXWeb}, and files created for testing purposes are located in \href{https://github.com/szmoore/MCTX3420/tree/master/testing}{testing}. In the server there is nearly always an associated \texttt{.h} ``header'' file for each \texttt{.c} ``source'' file.
\begin{figure}[H]
\centering
Code to read sensor values is located in the \gitref{server}{sensors} subdirectory. With the exception of the dilatometer (discussed in Section \ref{Image Processing}), all sensors used in this project produce an analogue output. After conditioning and signal processing, this arrives at an analogue input pin on the BeagleBone as a signal in the range $0\to1.8\text{V}$. The sensors currently controlled by the software are:
\begin{itemize}
- \item {\bf Strain Gauges} (x4)
+ \item {\bf Strain Gauges} (x4) \gitref{server}{sensors/strain.c}
To simplify the amplifier electronics, a single ADC is used to read all strain gauges. GPIO pins are used to select the appropriate strain gauge output from a multiplexer. A mutex is used to ensure that no two strain gauges can be read simultaneously.
- \item {\bf Pressure Sensors} (x3)
+ \item {\bf Pressure Sensors} (x3) \gitref{server}{sensors/pressure.c}
There are two high range pressure sensors and a single low range pressure sensor; all three are read independently
- \item {\bf Microphone} (x1)
+ \item {\bf Microphone} (x1) \gitref{server}{sensors/microphone/c}
The microphone's purpose is to detect the explosion of a can. This sensor was given a low priority, but has been tested with a regular clicking tone and found to register spikes with the predicted frequency (~1.5Hz).
- \item {\bf Dilatometer} (x2) - See Section \ref{Image Processing}
+ \item {\bf Dilatometer} (x2) - \gitref{server}{sensors/dilatometer.c} See Section \ref{Image Processing}
\end{itemize}
Additional sensors can be added and enabled through use of the \funct{Sensor_Add} function in \funct{Sensor_Init} in the file \gitref{server}{sensors.c}.
Code to set actuator values is located in the \gitref{server}{actuators} subdirectory. The following actuators are (as of writing) controlled by the software and have been successfully tested in collaboration with the Electronics and Pneumatics teams. Additional actuators can be added and enabled through use of the \funct{Actuator_Add} function in \funct{Actuator_Init} in the file \gitref{server}{actuators.c}.
-\subsubsection{Relay Controls}
+\subsubsection{Relay Controls} \gitref{server}{actuators/relay.c}
The electrical team employed three relays for control over digital devices. The relays are switched using the GPIO outputs of the BeagleBone Black.
\subsubsection{PWM Outputs}
-A single PWM output is used to control a pressure regulator. The electrical team constructed an RC filter circuit which effectively averages the PWM signal to produce an almost constant analogue output. The period of the PWM is $2\text{kHz}$. This actuator has been calibrated, which allows the user to input the pressure value in kPa rather than having to control the PWM duty cycle correctly.
+A single PWM output is used to control a pressure regulator (\gitref{server}{actuators/pregulator.c}). The electrical team constructed an RC filter circuit which effectively averages the PWM signal to produce an almost constant analogue output. The period of the PWM is $2\text{kHz}$. This actuator has been calibrated, which allows the user to input the pressure value in kPa rather than having to control the PWM duty cycle correctly.
\begin{figure}[H]
\subsubsection{Memory Management}
- An initial problem I faced when coding in OpenCV was memory leaks. My simple program to take an image and save it to file was causing us to lose approximately 18Mb, which is unacceptable and would cause issues in the long term. After researching the issue I found that I was not properly releasing the structure dealing with storing the image for the data, \type{IplImage}. For example I was using:
+ An initial problem we faced when coding in OpenCV was memory leaks. Our simple program to take an image and save it to file was causing us to lose approximately 18Mb, which is unacceptable and would cause issues in the long term. After researching the issue we found that we were not properly releasing the structure dealing with storing the image for the data, \type{IplImage}. For example we were using:
\begin{lstlisting}
cvReleaseImage(&frame);
\end{lstlisting}
cvReleaseImageHeader(&frame);
\end{lstlisting}
- Another thing to note was that releasing one of the \type{CvMat} structures (\verb/g_srcRGB/) during the cleanup of the dilatometer module, a \verb/NULL/ pointer exception was returned and the program execution stopped. The reason for this is unknown, but the other \type{CvMat} structures appear to be released properly. For now I simply removed this release; however the cause should be looked into.
+ Another thing to note was that releasing one of the \type{CvMat} structures (\verb/g_srcRGB/) during the cleanup of the dilatometer module, a \verb/NULL/ pointer exception was returned and the program execution stopped. The reason for this is unknown, but the other \type{CvMat} structures appear to be released properly. For now we simply removed this release; however the cause should be looked into.
\subsubsection{Dilatometer}
- The dilatometer code went through a few iterations. Originally we were informed by the Sensors Team that the camera would be watching the can, rather than object attached to the can. Thus my original algorithms were revolved around finding the actual width and change in width of the can.
+ The dilatometer code went through a few iterations. Originally we were informed by the Sensors Team that the camera would be watching the can, rather than object attached to the can. Thus our original algorithms were revolved around finding the actual width and change in width of the can.
- Originally I designed the algorithm to find the edge of the can via the pixel thresholds. By finding the average position of the pixels below a certain threshold (as ideally you would have a dark can on a light background to create a contrast for the edge). This would already give a fairly inaccurate result, as it assumes a relatively sharp intensity gradient. Even with little noise the system would have accuracy issues.
+ Originally we designed the algorithm to find the edge of the can via the pixel thresholds. By finding the average position of the pixels below a certain threshold (as ideally you would have a dark can on a light background to create a contrast for the edge). This would already give a fairly inaccurate result, as it assumes a relatively sharp intensity gradient. Even with little noise the system would have accuracy issues.
- To increase the accuracy in finding the edge, I considered the Canny Edge theorem. I wrote my algorithm to find all points above a certain threshold and take the average of these, considering this as an edge. I then scanned through the rest of the image until the next edge was found and do the same. The width of the can is found by taking the difference of the two locations. I also wrote an algorithm to generate these edges so I can test the algorithm. The function (\funct{Dilatometer_TestImage}/, which is still located within \gitref{server}{sensors/dilatometer.c}) generated two edges, with an amount of noise. The edges were created by taking an exponential decay around the edge and adding (and subtracting) a random noise from the expected decay. The edges where then moved outwards using a for loop. From Figure \ref{canny_edges.png}, it can be seen how effective the algorithm was for a system with negligible noise, as it gave negligible percentage error. However with increasing levels of noise we notice a considerable increase in inaccuracy (Figure \ref{canny_edges_noise.png}).
+ To increase the accuracy in finding the edge, we considered the Canny Edge theorem. We wrote the algorithm to find all points above a certain threshold and take the average of these, considering this as an edge. We then scanned through the rest of the image until the next edge was found and do the same. The width of the can is found by taking the difference of the two locations. A test algorithm was also written to generate the egdes in order to test the algorithm. The function (\funct{Dilatometer_TestImage}/, which is still located within \gitref{server}{sensors/dilatometer.c}) generated two edges, with an amount of noise. The edges were created by taking an exponential decay around the edge and adding (and subtracting) a random noise from the expected decay. The edges where then moved outwards using a for loop. From Figure \ref{canny_edges.png}, it can be seen how effective the algorithm was for a system with negligible noise, as it gave negligible percentage error. However with increasing levels of noise we notice a considerable increase in inaccuracy (Figure \ref{canny_edges_noise.png}).
\label{canny_edges_noise.png}
\end{figure}
- After the Sensors Team relayed that they were now attaching something to the can in order to measure the change position, I decided to simply stick with the Canny Edge algorithm and implement something similar to what I had in my previous testing. The images in Figure \ref{canny_demo} shows the progression of the image through the algorithm. Figure \ref{canny_demo} A shows the original image, whereas \ref{canny_demo}B shows the blurred (with a BLUR value of 5) gray scale image. Whereas Figure \ref{canny_demo}C shows the image after going through the Canny Edge algorithm with a low threshold of 35. Figures \ref{canny_demo}D and \ref{canny_demo}E both have the same input image, however different input values. It can be seen how tweaking the values can remove outliers, as Figure \ref{canny_demo}E is skewed to the right due to the outliers. From Figure \ref{canny_demo}F it can be seen that despite there being no points in the edge in the top half of the image, the edge has still been accurately determined.
+ After the Sensors Team relayed that they were now attaching something to the can in order to measure the change position, we decided to simply stick with the Canny Edge algorithm and implement something similar to what we had in my previous testing. The images in Figure \ref{canny_demo} shows the progression of the image through the algorithm. Figure \ref{canny_demo}A shows the original image, whereas \ref{canny_demo}B shows the blurred (with a BLUR value of 9) gray scale image. Whereas Figure \ref{canny_demo}C shows the image after going through the Canny Edge algorithm with a low threshold of 35 and the location of the determined edge superimposed on top.
+
+ Figures \ref{canny_demo}D, \ref{canny_demo}E and \ref{canny_demo}F all have the same input image (however different to \ref{canny_demo}A). Figure \ref{canny_demo}D had a blur of 5 and a low threshold value of 40, \ref{canny_demo}E had a blur of 9 and a low threshold value of 35, and \ref{canny_demo}F had a blur of 7 and a low threshold of 36. It can be seen how tweaking the values can remove outliers, as Figure \ref{canny_demo}D is skewed to the right due to theincreased number of outliers. From Figure \ref{canny_demo}E it can be seen that despite there being no points in the edge in the top half of the image, the edge has still been accurately determined.
The testing done shows that given a rough edge with few outliers an edge can be determined, however there is an obvious degree of inaccuracy the greater the variance of the edge. The best solution to this however does not lie in software. If an edge was used that was straight even at that magnification with a good contrast then the results would be much more accurate (i.e. the accuracy of the dilatometer is currently more dependent on the object used than the software).
+
\subsubsection{Interferometer}
Earlier in the semester we were informed by the Sensors Team that instead of a dilatometer we would be using an interferometer. The algorithm for this was written and tested; it is currently still located in the file \gitref{server}{interferometer.c} and header \gitref{server}{interferometer.h}. However development of the algorithm ceased after the sensors team informed us that the interferometer would no longer be implemented.
\begin{tabular}{cc}
\includegraphics[width=0.4\textwidth]{figures/dilatometer_test.jpg} A &
\includegraphics[width=0.4\textwidth]{figures/dilatometer_test2.jpg} B \\
- \includegraphics[width=0.4\textwidth]{figures/dila_blur7thresh36.png} C &
+ \includegraphics[width=0.4\textwidth]{figures/dila_blur9thresh35_2.png}C &
\includegraphics[width=0.4\textwidth]{figures/dila_blur5thresh30.png} D \\
\includegraphics[width=0.4\textwidth]{figures/dila_blur9thresh35.png} E &
- \includegraphics[width=0.4\textwidth]{figures/dila_blur9thresh35_2.png} F
+ \includegraphics[width=0.4\textwidth]{figures/dila_blur7thresh36.png} F
\end{tabular}
\caption{Canny Edge Algorithm in Action}
\label{canny_demo}
git.ucc.asn.au / matches / MCTX3420.git / commitdiff
UCC git Repository :: git.ucc.asn.au