ethernet-lidar.tex

\newpage
\subsection{Ethernet}
\label{sec:ethernet}
\subsectionauthor{Author: Henrik Tjäder\\Reviewer: Fredrik Grönlund}


% Stub for including graphics, good to have

%\begin{figure}[H]
%\centering
    %\includegraphics[width=0.7\textwidth]{Pictures/UDP-packets}
    %\caption{caption here}
    %\label{pic:a-pris_yta}
%\end{figure}

The Ethernet configuration is as follows:

\begin{verbatim}
STM32       IP: 192.168.0.1
Hokuyo      IP: 192.168.0.10
ALFA WiFi   IP: 192.168.0.100
\end{verbatim}

Ethernet itself is configured in \texttt{src/lwip.c}, while the IP for the LIDAR
is configured in \texttt{include/lidar.h}.

To initiate a TCP connection with the LIDAR the function \texttt{tcp\_lidar\_connect(lidar\_init)} is used.

It will then proceed establishing all the structs for maintaining connectivity and try to establish
a connection with the LIDAR.
In order to process incoming TCP packets the main loop should busy itself with calling
\texttt{MX\_LWIP\_Process()}. This could be changed into interrupt driven operation if the oscillator \texttt{X4}
on the STM32F767IZ-nucleo would be upgraded to $\si{\num{50}\mega\hertz}$ from
its current value of $\si{\num{25}\mega\hertz}$ since the \texttt{REF\_CLK\_OUT} and \texttt{nINT}
are multiplexed on the same PHY output pin.

\begin{figure}[H]
    \centering
    \includegraphics[width=0.5\textwidth]{flowcharts/Ethernet}
    \caption{Ethernet flowchart}
\end{figure}

Due to UWB radio complications a workaround data communication solution were added.

\href{https://www.alfa.com.tw/products_show.php?pc=35&ps=189}{ALFA AIP-W512} acts as
a wireless bridge between the STM32F767IZ and the LIDAR to the base station collecting measurement data.

The ALFA AIP-W512 being both lightweight and operating at \SI{5}{\volt} made it an easy choice since
any extraneous weight is unwanted and it could be directly attached to the \SI{5}{\volt} rail.

Having ethernet hardware does not solve the problem altogether since the
protocols and setup required for functional ethernet communication are non-trivial.


\subsection{LIDAR}
\label{sec:lidar}
\subsectionauthor{Author: Henrik Tjäder\\Reviewer: Fredrik Grönlund}

The \href{http://www.robotshop.com/en/hokuyo-ust-10lx-scanning-laser-rangefinder.html}{Hokuyo UST-10LX Laser range finder}
communicates over TCP/IP.

Default communication parameters are as following:
\begin{itemize}
    \item IP: 192.168.0.10
    \item PORT: 10940
\end{itemize}

It features two different communication modes, one response per request, ``handshake'' or one request and a continuous flow of replies.

First step is to exit the \texttt{IDLE} state and enter \texttt{SIMPLE SCAN} via the command \texttt{BM<Termination Char>} as seen in Figure~\ref{pic:lidarstates}. \texttt{<Termination Char>}
can be any of the following: \texttt{<LF>}, \texttt{<CR>} or \texttt{<CR+LF>} where \texttt{<LF>} equals \texttt{0x0a} and \texttt{<CR>} equals \texttt{0x0d}.
\texttt{<Termination Char>} will henceforth be denoted by \texttt{<LF>}.
\begin{figure}[H]
\centering
    \includegraphics[width=0.7\textwidth]{Pictures/lidarstates}
    \caption{Hokuyo operation state diagram}
    \label{pic:lidarstates}
\end{figure}

The functions responsible for communicating with the LIDAR are as follows:
\begin{itemize}
    \item{\texttt{tcp\_lidar\_init()}: Creates necessary structs.}
    \item{\texttt{tcp\_lidar\_connect(lidar\_init)} Initiates and connects to the LIDAR.}
\end{itemize}

If connection is successful then it will proceed sending either one of two messages, depending on the \texttt{lidar\_init} value.

If \texttt{lidar\_init} is 0 the command sent to the LIDAR is \texttt{BM<LF>} which is the command for
going into a state where the LIDAR can measure.

If \texttt{lidar\_init} is 1 the command sent is instead \texttt{GD00001080xx<LF>}.

The syntax for requesting data is as follows:

\texttt{GDzzzzyyyyxx<LF>}

\texttt{zzzz} is a the starting step, valid values are $0 \le zzzz \le 1079$ 

\texttt{yyyy} is a the ending step, valid values are $1 \le yyyy \le 1080$ 

\texttt{zzzz} may not be greater than \texttt{yyyy}.

\texttt{xx} denotes a two digit value which acts as a divider of the data amount.
The LIDAR operates in steps from 0 to 1080. If \texttt{xx} is set to $00$ or $01$ it will send
data for every single step from 0 to 1080. If \texttt{xx} is set to $04$ then it would only send data for every 4th step.

This will be great for controlling the amount of data sent over the UWB radio link since the LIDAR can generate copious amounts of data.

The standard setting sends $2 \cdot 1474 + 543 = 3491$ bytes of data (including headers). The \texttt{UWB} maximum \texttt{MTU} is \texttt{127 bytes}.
Thus the UWB would have to transmit at least 28 frames just for the LIDAR. Then there is the metadata such as the stepper motor angle, the sonar data etc.

This is where the \texttt{LAMP}~\ref{sec:LAMP} protocol comes into play.