\section{Overview and Objectives}

 \subsection{Structure of Today's Lab and Goals}

 Today's and Wednesday's labs are combined into a single longer lab focused on acoustic communications and networking. By the end, you will have a good understanding of the difficulties AUV researchers face when attempting to communicate over the very low throughput / high latency acoustic link. 

 In this lab, we will make use of the Goby Underwater Autonomy Project\footnote{Home: \url{https://launchpad.net/goby}, Docs: \url{http://gobysoft.org/doc/2.0/}} to provide us with the backbone networking software. We will be both simulating the acoustic link using the uField Toolbox and using real acoustic modems connected via coaxial cables instead of electro-acoustic transducers (No, I'm not bringing a bathtub or the ocean into the classroom). 

 There are three parts to this lab:
 \begin{enumerate}
 \item Understand the process of creating a message suitable for sending on an acoustic modem using Goby and MOOS-IvP. (Section \ref{sec_acomms_example}).
 \item Deploy your lab partner's surface vehicle using an acoustic minipacket using the Micro-Modem hardware. (Section \ref{sec_deploy_minipacket}).
 \item Design an basic arithmetic coder suitable for encoding temperature data generated by a simulated AUV's sensor. (Section \ref{sec_ctd_encode}).
 \end{enumerate}

 \textbf{Important}: The second task (Section \ref{sec_deploy_minipacket}) can be done at any point before or after the other parts of the lab. I only have enough hardware for two lab groups to work at one time, so budget your time to do this task (1/2 hour or so) during lab time when one of the Micro-Modem boxes are free. Find a partner and sign up on the blackboard for your turn.

 While the other sections are primarily individual assignments, you are welcome to troubleshoot and ask questions of your fellow students for all parts of this lab. 

\subsection{Preliminaries - Pre-lab assignment}
\label{prelims}

In addition to the working \verb|MOOS-IvP| setup required for every lab, we have a few more preliminaries for this lab. In order to maximize useful lab time this week, and hopefully \textit{remove the need for any work to be done over Spring Break}, we ask you to complete the following setup and background pre-lab assignment (none of the answers to these pre-lab questions should be more than a line or two of text) and hand it in (on Stellar) \textit{prior} to lab start on Monday March 17, 2014:

\begin{enumerate}
\item Download and compile Goby (version 2.0) per the instructions listed here: \url{http://gobysoft.com/wiki/InstallFor2680}.
\item Read the first two sections (\textit{Data Compression and Arithmetic Coding} and \textit{Tutorial on Arithmetic Coding}) from the paper \textit{Practical Implementations of Arithmetic Coding} by P. Howard and J. Vitter \cite{howard1992practical}, available at the class Stellar site under ``Materials''. You may also wish to reference Chapter 4 of Sayood's \textit{Introduction to Data Compression} \cite{sayood_introduction_2005}, also available on Stellar. Please answer the following questions: 
\begin{enumerate}
\item State the primary advantage(s) of arithmetic source encoding.

\ifx\answer\undefined
\else
{\color{red}
\begin{itemize}
\item Flexible: the probabilistic model is decoupled from the coding. This allows separation of expertise: the scientist may have great insight into the probabilistic model but little knowledge or interest in encoding. On the other hand the computer scientist/software engineer can write the encoding tools without anticipating all possible models.
\item Optimal: encodes using the minimal code length given an accurate model.
\end{itemize}
}
\fi

\item State the primary disadvantage(s) of arithmetic coding.

\ifx\answer\undefined
\else
{\color{red}
\begin{itemize}
\item Slow.
\item Cannot easily be parallelized.
\item Poor error resistance.
\end{itemize}
}
\fi

\item Why might this type of coding make sense for marine vehicle communications?

\ifx\answer\undefined
\else
{\color{red}
Assuming the physical link is acoustic (as often is the case for subsea communications), a first approximation yields nearly no throughput (order of bytes/minute) and effectively infinite CPU (order of 1 GHz clock speeds). This means when choosing a coder, we want to lean heavily on the side of minimal encoded datagram size versus encoding speed (classic time versus size tradeoff). Arithmetic coding gives us this desired point in time/size space. Furthermore, the separation of modeling from coding is tremendously helpful in the robotics domain where it is difficult or impossible for any one person to have expertise in all components of the system. This separation allows people to play to their strengths.
}
\fi

\end{enumerate}
\item We will be using Google Protocol Buffers (``protobuf'') as the definition language for our acoustic datagrams (though we will \textit{not} be using their encoding - it's not efficient enough!). Read through these pages to get a sense of what Google Protocol Buffers is and how it works with C++, and answer these quick questions:
\begin{enumerate}
\item Overview: \url{http://code.google.com/apis/protocolbuffers/docs/overview.html}
\item C++ Tutorial: \url{http://code.google.com/apis/protocolbuffers/docs/cpptutorial.html}
\begin{enumerate}
\item What is the relationship between a Protobuf ``Message'' and a C++ ``class''? 

\ifx\answer\undefined
\else
{\color{red}
A Protobuf ``Message'' defines a set of instructions for automatically generating an equivalent C++ ``class'' (and the equivalent in other languages: Java, Python, etc.). ``Meta-class'' is another possible term for a Protobuf ``Message.''
}
\fi

\item Given this .proto file, how would I (in C++) set the value of the ``temperature'' field to 21.435?
\begin{verbatim}
message CTDSample
{
  optional double temperature = 1;
  optional double salinity = 2;
}
\end{verbatim}

\ifx\answer\undefined
\else
{\color{red}
\begin{verbatim}
CTDSample sample;
sample.set_temperature(21.435);
\end{verbatim}
}
\fi

\end{enumerate}
\end{enumerate} 
\end{enumerate}

\subsection{Preliminaries - Start of lab}
\label{prelims-in_lab}

\begin{enumerate}
\item Update and compile any changes to Goby since you did the pre-lab checkout:
\begin{verbatim}
cd goby
bzr up
./build.sh
\end{verbatim}

\item You will need to check out a branch of moos-ivp-extend that contains the code and missions for today's lab. The structure of the repository should be familiar from previous labs. Use 
\begin{verbatim}
bzr co lp:~tes/junk/moos-ivp-extend-acomms
\end{verbatim}
Build the repository using the include script:
\begin{verbatim}
cd moos-ivp-extend-acomms
./build.sh
\end{verbatim}
Add \verb|moos-ivp-extend-acomms/bin| to your shell path. Open a new terminal window and check that you have correctly set your path using
\begin{verbatim}
which ctd_tester 
\end{verbatim}
which should give something like
\begin{verbatim}
/home/toby/moos-ivp-extend-acomms/bin/ctd_tester
\end{verbatim}

\end{enumerate}
 
\subsection{What you will hand in}
\label{hand in}

By the end of lab Wednesday Mar 19, 2014, you will hand in answers to the questions of sections \ref{sec_acomms_example} and \ref{sec_deploy_minipacket}. The arithmetic coder (Section \ref{sec_ctd_encode}) and related questions will be due Wednesday April 2, but you should be able to complete most or all of it in the lab time provided. Please produce a PDF document with the answer to your questions, and hand in your source code by zip'ing or tar'ing the \verb|moos-ivp-extend-acomms| tree, renamed to \verb|moos-ivp-yourname|. All of these should be uploaded to Stellar.

\subsection{Glossary}
We'll be doing some binary math and such, and since you all have a varieties of backgrounds, we've made a quick glossary to try to address as many foreign terms / code snippets as possible:

\begin{itemize}
\item Binary (base 2): A number system where there are only two numerals: 0 and 1. It works just like base 10 (decimal) in other regards, just use 2 instead of 10. A binary digit (or ``bit'') is a single base 2 value (i.e. a ``0'' or a ``1''). A byte is an 8-bit number. Binary numbers are generally easy to identify as they only contain 0 and 1. Where ambiguous, I will use a prefix letter 'd' to mean decimal, and 'b' for binary. '0x' is the prefix commonly used for hexadecimal (this works in C++). You may find a calculator that can do binary to decimal conversions useful for this lab. The default Ubuntu calculator in Programming Mode will do that for you. You can also use Python:
\begin{verbatim}
$ python
>>> bin(200)[2:]
'11001000'
>>> int('11001000', 2)
200
\end{verbatim}
\item Bit shifting (\verb|operator<<| and \verb|operator>>|): Moves the bits to the left or right by the number of places on the right side of the operator. This effectively multiples or divides the number by 2 to the number of bits shifted. For example:
\begin{verbatim}
int i = 5; // binary 101
int j = i << 2; // binary 10100
assert(j == 20); // true
\end{verbatim}
\item Codec (\textbf{co}der/\textbf{dec}oder), coder, and encoder/decoder are all used interchangeable in this lab to mean a program that takes a high-level uncompressed input, produces a set of bits suitable for transmission across a medium (encode), and can reproduce the input on the other end (decode). This process is somewhat synonymous with ``data marshalling.'' In certain contexts this is referred to as ``source coding'' to disambiguate it from ``channel coding,'' which is interested in making the best use of a particular communications channel (and provides error correction).
\item Least/most significant bit (LSB/MSB): The least significant bit is the one with the lowest value (i.e. $2^0$). Conversely, the most significant bit is the one with the highest value. Binary numbers are conventionally written from MSB to LSB (just like ``152'' in decimal means $1\cdot10^2 + 5\cdot10^1 + 2\cdot10^0$). 
\end{itemize}

