<html><head><meta name="color-scheme" content="light dark"></head><body><pre style="word-wrap: break-word; white-space: pre-wrap;">\documentclass[onecolumn,letterpaper,11pt]{article}

%===================================================================
\input{common_latex/common_latex_packages}
\input{common_latex/common_latex_definitions}
\input{common_latex/common_latex_memo_format}
%===================================================================

\begin{document}

\begin{labcover}
\labtitle{The PABLO Box}
\vspace{0.1in}
\labdate{August 2017}
\vspace{0.1in}
\labauth{Alon Yaari, ayaari@mit.edu}
\labauth{Michael Benjamin, mikerb@mit.edu}
\labauth{Department of Mechanical Engineering}
\labauth{MIT, Cambridge MA 02139}
\labtoc{small}
\end{labcover}

\wikidoc{file=PavLab.PabloBox}
\wikidoc{auth=mikerb@mit.edu}


%=================================================================
\section{The PABLO Box}
%=================================================================
\label{sec_pbx_overview}

Commercially-available robotic vessels generally include a computing
system with hooks for autonomous control. At the most basic level, the
integral controller interfaces with some steering/throttle input and
conveys commands to on-board control surfaces. In addition, some
vehicles include navigation sensors and health monitors that are
integrated with the on-board computer.  More sophisticated commercial
vehicles are provided with some level of autonomy on-board, onsuming
the navigation sensor data to make ation decisions.

The on-board vehicle-control computer is referred to as the {\bf
  front-seat}.  An interface exists that receives input commands from
outside to be interpreted as vehicle control. The interface outputs
available status, navigation, and health data. Methods and format for
the bi-directional data stream is called a {\bf wire protocol}. The
front-seat can be considered a black box with data flow managed
through the wire protocol.

The {\bf back-seat} is an entity that implements the wire protocol to
communicate with the front-seat. On some systems, the front-seat
computer is open and requires that the back-seat software share the
hardware. For example, the first generation Clearpath Kingfisher M100
included an on-board computer without a payload bay. There are
advantages to separating the back-seat onto a dedicated computer. In
fact, front-back separation is a hallmark of payload autonomy.

In the front/back-seat paradigm, integrating MOOS-IvP onto a vessel
means passing decisions about heading and speed (or steering angle and
throttle position) to the front-seat for vehicle control while
receiving navigation signals in return. The wire protocol is
implemented in a dedicated driver application in MOOS. For example,
the Clearpath Kingfisher M200 vehicle is interfaced with the
\app{iM200} application, which handles details of pushing commands and
parsing incoming pose, position, and health messages.

%=================================================================
\section{Payload Autonomy}
%=================================================================
\label{sec_pbx_payload_autonomy}

{\em Payload autonomy} is a paradigm for controlling an autonomous
vehicle where the autonomy software operates from a dedicated and
removable back-seat computer. A separate front-seat system manages
vehicle control and low-level sensing. The back-seat computer connects
physically through a payload port (usually Ethernet, sometimes serial)
and logically using a wire protocol. The Pablo Box for the Kingfisher
M200 is an example of a payload autonomy system.

Unmanned marine vehicle front-seat systems are often a full computer
with an operating system and the ability to log in and install user
code.  Alternatively, the front-seat may be a simple device like an
Arduino with no OS. Historically at MIT, MOOS-IvP code was installed
and executed on the OEM computing device. However, this arrangement is
inconvenient for various reasons:

\begin{packed_itemize}

\item {\em Front-seat integrity.}  Preparing a MOOS mission requires
  access to the physical vehicle for updating software and files,
  installing dependencies, and building custom code. This effort is
  then duplicated on each physical vehicle. It is possible that these
  steps are incompatible with the computing resources required by the
  OEM front-seat software or operating system. Furthermore, in a
  classroom or shared-resource setting it is not always possible to
  control who is accessing the front-seat computer.  Students and
  guest researchers may inadvertently disturb system integrity.

\item {\em Ease of development.} By detaching the back-seat and
  vehicle, a user can develop at any location and validate the code
  works on the back-seat hardware.

\item {\em Emulation.} To further facilitate development, emulation
  provides a front-seat for the back-seat box.

\item {\em Modularity.} A box can be configured once then moved
  between vehicles. The drive on a validated box can be duplicated to
  create multiple copies of the known working system.

\item {\em Front-seat independence.} So long as the wire protocol
  remains constant, the manufacturer is free to modify or upgrade
  front-seat operations without disturbing the back-seat autonomy.

\item {\em Vehicle sharing.} Hardware assets can be shared among
  students or researchers in a classroom or project environment
  without interfering with the work of others.
\end{packed_itemize}

%====================================================================
\subsection{Emulation}

The ability to easily emulate the actual vehicle is a convenient
feature of payload autonomy. The wire protocol insulates the back-seat
from any inner workings of the vehicle. A front-seat that responds to
commands and outputs the expected messages can be a physical vehicle
or an emulated system. The back-seat is therefore unaware and uncaring
of which one is engaged over the interface.

Here we use the term {\em emulate} to describe a black box acting as a
surrogate for the entire vehicle. {\em Simulate} describes mimicking
pieces of the vehicle with substitutions within a MOOS community. Our
emulation system is a MOOS community running the marine simulator
application \app{uSimMarine} and a module that interfaces to an
Ethernet port.

%====================================================================
\subsection{What is Pablo?}

The Payload Autonomy Box (Pablo) unit is a dedicated back-seat
computing system designed to connect with the Clearpath Robotics
Kingfisher M200 vehicle.  Onboard computing supports MOOS-IvP running
on a GNU/Linux variant of operating system. Physically, it is designed
to be splash-proof, fit within the size constrains of the M200 payload
bay, and provides connection to the vehicle and user-supplied
peripherals. The box design is modular and open, allowing for
modifications to support other unmanned surface vehicles.

The Pablo unit is more than just hardware. Payload autonomy involves
interfacing Pablo with the front seat and modifying network topology
to facilitate the paradigm. Remaining sections of this document
describe design and assembly of the physical unit, networking theory
and practical application to payload autonomy, and details for setting
up the operating system and MOOS-IvP environment on the unit.

%====================================================================
\section{Pablo Design}
%====================================================================
\label{sec_pbx_design}

\vspace{0.1in}
\begin{figure}[H]
  \centering 
  \includegraphics[width=0.6\textwidth]{figures/pablo_cover.png}
  \caption{A completed PABLO unit and power supply. }
  \label{fig_PABLO_anatomy}
\end{figure}
\vspace{0.1in}

The Pablo unit is a system designed by MIT to provide a back-seat
payload autonomy module. The initial version was designed to interface
with the hardware and wire protocols of the Clearpath Robotics
Kingfisher M200 vehicle.  However, the Pablo unit is modular and can
be customized to fit other unmanned surface vessels.

The major requirements driving the Pablo hardware design include:
\begin{packed_itemize}

\item {\em Waterproofing.} The M200 payload bay is exposed to splashing 
  water and all system components must be protected.
\item {\em Dimensions.} The M200 payload bay has limited size, some of 
  which is constrained by connector locations. All system components must fit 
  comfortably within the bay.
\item {\em Interfaces.} The M200 exposes a single waterproof Ethernet 
  connector that the Pablo unit must interface with.
\item {\em Power.} In the office, the box must be powered from a plug-in 
  source. On the M200, limited-current 5-volt power is available from the 
  payload USB ports. Alternatively, a dedicated battery must be included that 
  meets dimension requirements and can power the system for several hours.
\item {\em Peripherals.} The Pablo requires additional interfaces to 
  connect with and power user-supplied peripherals.
\end{packed_itemize}

\noindent
Based on the requirements, initial trade studies identified these key
system components:

\begin{packed_itemize}
\item {\em Enclosure.} A single housing that can be opened and
  resealed to contain system components was selected over
  permanent solutions such as electronics potting.
\item {\em Computing.} An Arm-based, embeddable single-board computer, such 
  as the Raspberry Pi, capable of supporting a GNU/Linux-like operating 
  system emerged as an ideal solution over other systems such as FPGAs or 
  larger and more powerful computing modules.
\item {\em Connectors.} The payload interface connector was dictated by the 
  existing M200 port; power and peripheral ports were investigated as 
  described below.
\item {\em Power.} Drawing power from the M200 USB ports was 
  rejected as interfering with front-seat performance and due to limitations 
  in power available for Pablo peripherals.
\end{packed_itemize}


%=================================================================
\subsection{Enclosure}
\label{sec_pbx_enclosure}

The enclosure houses a computing system and an optional display. The box must 
have provisions for wiring to pass through while keeping the contents dry. As 
the PABLO is designed specifically for the Kingfisher M200, the box must 
fit completely within the vehicle's payload bay alongside a battery.

%-----------------------------------------------------------------
\subsubsection{Water intrusion}

The main function of the housing is to protect the computing system
from water intrusion. The PABLO unit is intended for exposure to
regular splashing but not to complete submersion. Boxes with an IP67
or NEMA4 rating (or better) meet this requirement. Payload autonomy
boxes installed in dry vehicle bays can relax the water intrusion
requirement; systems intended for full immersion must require a more
robust box.

%-----------------------------------------------------------------
\subsubsection{Housing selection}

Multiple housing options are available that fit within the payload
bay, provide sufficient interior volume, and are rated for a wet
environment. Bud Industries model PN-1325-C was selected because it
meets these criteria, and has a clear lid. Threaded brass inserts
contained within bosses on the interior bottom are convenient anchors
for system components. The {\em PN} line of enclosures includes a wide
selection of sizes to support future enhancements.

\vspace{0.1in}
\begin{figure}[H]
  \centering 
  \includegraphics[width=0.6\textwidth]{figures/BudInd1325C.png}
  \caption{The Bud Industries PN-1325-C polycarbonate enclosure box.}
  \label{fig_PN-1325-C}
\end{figure}
\vspace{0.1in}


%=================================================================
\subsection{Power Inputs}
\label{sec_power_input}

%-----------------------------------------------------------------
On shore, the Pablo unit should be powered by a wall plug. On the
vehicle, voltage might be supplied from the host or a companion
battery. While it is technically possible to embed a battery within
the enclosure, doing so increases system complexity by requiring
custom circuitry to address recharging and use of wall
power. Waterproof power connectors exist that provide a common DC
barrel connector. The simplest solution is to expose this connector on
a pigtail cable. On shore the connection receives a wall plug and on
the vessel a short custom battery cable fits the connector.

%-----------------------------------------------------------------
\subsubsection{Power requirements}

The computer is the main consumer of power on a Pablo unit. Selecting
the minimum hardware that meets the software requirements makes sense
as increased processor abilities translates directly to higher power
consumption. If a more powerful computer is selected, it is possible
(with size and weight limitations) to increase the battery. However,
more power means additional waste heat in the sealed enclosure.

Voltage varies among computers but is commonly 5v (e.g., Raspberry Pi)
or 12v (e.g., Portwell Nano-6060). Computers based on laptop systems
sometimes demand 19v. Most 12-19v devices accept a range (e.g., 10.5v
to 14.0v rather than just 12v), which is within the supply duty range
of many battery packs. For example, a 14.4v source may start at 14.8v
fully charged and drop to 13.0v before being taken out of service, all
within the allowable input range of the motherboard. However, devices
rated for 5v typically are more strict, specifying regulated power to
between 4.5v and 5.5v. Therefore, 5v systems require a regulator while

%-----------------------------------------------------------------
\subsubsection{Voltage regulators}

Regulators are devices that produce a constant output throughout a
stated input range. There are three main types of regulators:

\begin{packed_itemize}
\item {\em Buck converters} reduce voltage to the desired output and
  will often accept inputs right down to an equal pass-through.
\item {\em Boost converters} increase the voltage to the desired output. 
\item {\em Buck-boost converters} provided a regulated voltage output from
  an input that can swing above or below the intended output.
\end{packed_itemize}

Buck converters will stop producing a load on the power source once
voltage drops below the defined threshold. Boost and buck-boost
converters, however, will continue to draw power and may not cut off
until the source can provide no additional current. This will draw
down most batteries beyond repair so it is important to select a
regulator that will cut off before damage occurs.

There are two types of voltage-reduction regulators (buck converters):

\begin{packed_itemize}
\item {\em Linear} devices reduce voltage by shedding extra power as
  heat. They are simple and low-cost to implement, provide a clean
  output, but are inefficient and require a heat sink. An example is
  the LM7805, which produces a 5v output.
\item {\em Switch-mode} regulators are highly efficient because they rely
  on a duty-cycle rather than generating heat. Because of complexity
  they are more expensive and more prone to fail. Also, the switching
  circuits can produce high-frequency waveforms that interfere with
  the systems receiving power.
\end{packed_itemize}

The Pablo unit computer selection requires 5v and therefore a regulator is 
required. The Sino LLC 5V 3A 15W Step Down Regulator is a linear buck converter 
and was selected for its waterproofing, easily-accessed terminals, and stable 
5v output.

\vspace{0.1in}
\begin{figure}[H]
  \centering 
  \includegraphics[width=0.3\textwidth]{figures/regulator.png}
  \caption{The Sino LLC 5V 3A 15W Step Down Regulator.}
  \label{fig_5v_regulator}
\end{figure}
\vspace{0.1in}

\noindent
For the AC adapter, any plug-in "wall-wart" power supply with the following 
specifications is compatible with the Pablo unit:
5.5mm OD, 2.1mm ID positive tip connector

\begin{packed_itemize}
\item 5.5mm x 2.1mm center-positive connector
\item 5v with 2A (2000mAh) output current
\item Input AC matching your locale (e.g., 110v in the U.S.)
\end{packed_itemize}


%=================================================================
\subsection{Computing}
\label{sec_pbx_computing}

Specific requirements for Pablo computing include:

\begin{packed_itemize}
\item {\em Operating system.} A GNU/Linux variant is required to support 
  the autonomy system. 
\item {\em MOOS-IvP and user code.} Processing power must be sufficient to 
  build MOOS-Ivp and user modules onboard the computer. Missions must be able 
  to execute onboard without using full CPU.
\item {\em Footprint.} Smaller size to fit within the enclosure.
\item {\em Peripheral connections.} At least one Ethernet connector to 
  interface with the front-seat; at least one and preferably two USB ports 
  for user-supplied peripherals.
\item {\em Low power and cooling.} Reduced power consumption translates to 
  lower operating temperatures; the computer must be able to operate without 
  active cooling inside the enclosure.
\end{packed_itemize}

Recent advancements in mobile processing have increased the number of
available computing options. Systems that fit within the baseline
Pablo design include several small packaged systems such as the Intel
NUC and various single-board computers like the Raspberry PI or
BeagleBone Black. Generally, these devices are based on mobile
processors, such as the Intel ATOM line or ARM chips.

%-----------------------------------------------------------------
\subsubsection{Size Requirements}

The main selection criterion for computing is physical size; will the
unit and associated peripherals fit inside the waterproof enclosure?
The interior volume must contain the computer (some of which require
an additional heat sink), the inward portion of panel receptacles, and
space for wires and their connectors (a typical USB connector extends
three centimeters from the receptacle). In addition, a Pablo unit may
contain an optional display within the enclosure.

The waterproof housing selected for Pablo is approximately 8 in (20
cm) x 5 in (13 cm) x 1.75 in (4.4 cm). Interior space is impeded by
risers along the enclosure's sides. Computers that fit within these
dimensions include the Raspberry Pi, BeagleBone Black, and Gumstix
computers. Surprisingly, a micro-ITX motherboard can fit inside the
enclosure, provided that the the unit's peripheral ports are only
along one side. The 1.9Ghz quad-core Portwell Nano-6060 is an example
of a powerful single-board micro-ITX computer that can be arranged to
fit in the box.

\vspace{0.1in}
\begin{figure}[H]
  \centering 
  \includegraphics[width=0.5\textwidth]{figures/PortwellInPablo.png}
  \caption{The Portwell Nano-6060 single-board computer fits tightly within 
    the waterproof housing and is one possible computing option.}
  \label{fig_PortwellNano6060}
\end{figure}

%-----------------------------------------------------------------
\subsubsection{Computing Platform Selection and Alternatives}

Many platforms exist that provide sufficient computing resources and
fit within the PABLO size and power budgets. As of this writing (fall
2015), the baseline PABLO unit is assembled using {\em Raspberry Pi 2
  Model B} as its baseline computer. The Raspi was selected because it
is small, inexpensive, low-power, and has a large community of
supporters that provide answers for technical issues. The downside of
the Raspi is the fixed RAM and the need for an off-board compilation
toolchain.

All of the platforms that were considered meet the requirement of
being able to run a baseline MOOS-IvP mission. The short list of
computing options listed here provides a range of features that can be
considered for Payload Autonomy applications:

\begin{packed_itemize}
\item {\em Raspberry Pi 2 Model B} The smallest, least-expensive, and 
  lowest-power option in our list. Huge support community and large number of 
  purpose-built "shields"
  that extend hardware functionality. Onboard compiling can take many
  hours and requires memory-management tricks.
\item {\em BeagleBone Black} Similar or slightly better than the Raspi
  on almost every metric except cost. Compared with the Raspi,
  community support and ease of availability are lacking. The
  BeagleBone also benefits from an off-board compiling toolchain.
\item {\em Micro-ITX Portwell Nano-6060} Many options exist in the
  Micro-ITX form factor. The Nano-6060 is a \textdollar 300 board with
  a quad-core 2.2Ghz ATOM processor. The unit is a tight fit in the
  PABLO enclosure but peripheral connections are all on the same side
  of the board to facilitate wiring. Power consumption is around 8W,
  which increases hotel load and may require temperature regulation.
\end{packed_itemize}

\vspace{0.1in}
\begin{figure}[H]
	\centering 
	\includegraphics[width=0.50\textwidth]{figures/Raspi2B.png}
	\caption{The Raspberry PI 2 Model B.}
	\label{fig_Raspi2B}
\end{figure}
\vspace{0.1in}


%-----------------------------------------------------------------
\subsubsection{Connectors}
\label{sec_pbx_connectors}

Pablo unit requirements call for four outside connections:

\begin{packed_itemize}
\item {\em 1 x Ethernet.} Physical network interface to the host vehicle.
\item {\em 1 x Power.} Two-conductor cable for input voltage.
\item {\em 2 x USB.} Connect with user-supplied peripherals and to 
  keyboard/mouse for non-network interface. The USB ports may not be a 
  requirement for all Pablo users. However, we recommend including at least 
  one for convenience.
\end{packed_itemize}

\noindent
Each connection represents a breach in the enclosure and therefore a potential 
violation of the waterproofing. Glands and connectors were selected for this 
project because of their waterproof ratings. Care must be taken to install 
gaskets and o-rings properly to avoid potential leaking.

Waterproofing a hole in plastic is a challenge. Glues and epoxies will peel 
off. Chemical bonding (such as PVC cement) form a undesirable permanent bond 
and cases such as cyanoacrylate on acrylics require controlled temperatures to 
prevent cracking. Simply drilling a hole, pass a cable, then apply silicone 
sealant will result in leaks, either due to lack of adhesion or from mechanical 
separation. {\em Therefore, the only robust method for preventing leaks is to 
mechanically compress a gasket or o-ring around the hole.}

\paragraph{Cable glands.} Passing a cable through an enclosure wall without 
leaks requires the use of a cable gland, sometimes called "cord grips". The 
gland is a cylindrical body that is clamped to a hole in the enclosure. At one 
end of the gland body is a rubber sheath with a cinch nut that forms a 
waterproof seal with the cable jacket by compressing the rubber sheath.

When an existing, terminated cable is being used, glands pose a challenge 
because often the cable ends will not pass through the gland body. Some 
alternatives exist for sealing a terminated cable into a gland, however these 
often require similar levels of effort to cutting then manually terminating the 
cable, while increasing potential for leaks.

The two main considerations in selecting a gland are the outer diameter (OD) 
for the enclosure hole and the inner diameter (ID) that clasps the cable. 
Glands are sized using the historical "PG" standard. The number in the size 
description describes the maximum cable diameter in millimeters. The two sizes 
most relevant to the Pablo unit are:

\vspace{0.15in}
\begin{tabular}{ | l | l | l | }
  \hline
      {\bf PG Name} &amp; {\bf Hole Diameter} &amp; {\bf Cable Diameter} \\ \hline
      PG7 &amp; 0.492 in. (12.5 mm)  &amp; 0.118 to 0.256 in. (3.0 mm to 6.5 mm) \\ \hline
      PG9 &amp; 0.610 in. (15.5 mm)  &amp; 0.157 to 0.315 in. (4.0 mm to 8.0 mm) \\ \hline
\end{tabular}
\vspace{0.15in}

%----------------------------------------------------------------------
\subsubsection{Gland selection}

Power and Ethernet enter the box through glands.  The diameter of both
cables meets the ID specification for the PG7 gland. These are common,
widely-available parts often sold without markings and in bulk.
However, we recommend the Bud Industries NG-9511 gland because it is
from a known, reliable manufacturer, includes a datasheet with
specifications, and has a gasket. If using a different version of the
PG7 gland, always insert a gasket or o-ring between the gland's
non-rotating portion and the box.

\vspace{0.1in}
\begin{figure}[H]
  \centering 
  \includegraphics[width=0.25\textwidth]{figures/BudCableGland.png}
  \caption{Exploded view of the Bud Industries NG-9511 PG7 Cable Gland.}
  \label{fig_NG9511_gland}
\end{figure}
\vspace{0.1in}

\paragraph{USB Connectors.} Multiple options exist for waterproof panel-mount 
USB connectors. The Bulgin Buccaneer series was selected as the best
combination of price for reliability. The PX0842 exposes a USB-A
receptable to the outside and a USB-B facing inward. When not in use,
the PX0733 sealing cap retains the waterproofing. Inside Pablo, a
short USB A-B cable connects the computer port and
connector. Conveniently, any USB-A device can be plugged in when
waterproofing is not required (such as a temporary-use keyboard). When
field-deployed, waterproofing for the USB connections is maintained by
splicing on a mating Buccaneer connector.

\vspace{0.1in}
\begin{figure}[H]
  \centering 
  \includegraphics[width=0.25\textwidth]{figures/Bulgin.png}
  \caption{Bulgin Buccaneer waterproof USB connectors. }
  \label{fig_Buccaneer}
\end{figure}
\vspace{0.1in}

%=================================================================
\subsection{Interior Mounting}
\label{sec_pbx_mounting}

A mounting plate inside the Pablo unit is needed in order to prevent
impact damage to the computer and to reduce mechanical strain on
cables. The selected enclosure includes mounting bosses which do not
align with holes in the selected computer board. The solution is a
custom mounting plate for the computer that bolts down to the
enclosure bosses. Such a plate can be manually crafted, laser-cut, or
purchased from an online service. The Bill of Materials section
describes these options in detail.

\vspace{0.1in}
\begin{figure}[H]
  \centering 
  \includegraphics[width=0.5\textwidth]{figures/Plate.png}
  \caption{Drawing of the custom mounting plate positioned inside the Pablo 
    enclosure. }
  \label{fig_plate_in_enclosure}
\end{figure}
\vspace{0.1in}

%====================================================================
\section{Network Topology}
%====================================================================
\label{sec_pbx_networking}

When using MOOS, intra-community occurs over an IP network. Entire
books are written to describe methods for managing packets over
IP. Presented here is an overview that attempts to summarize the most
relevant and important details. In continuing with MOOS standards,
only IPv4 nomenclature is considered.

{\bf The Network Topology section provides background and is not
  required reading for configuring a PABLO box.}

%====================================================================
\subsection{Network Topology Overview}
\label{sec_pbx_network_topo}

Each computer on a network has at least one IP node, a connection
between the operating system on the computer and a network. It is
possible to have more than one node, for example a physical node to an
Ethernet port, a wireless connection, and an internal logical
interface to a virtual machine. Each node is named with at least one
IPv4 address, a collection of four numbers, each in the range
0-255. An example IP address is \var{192.168.1.100}.

Moving from left to right, IP address numbers denote top level to
local networks. Addresses starting with \var{192.168.x.x},
\var{10.x.x.x}, and combinations in the \var{172.x.x.x} space
represent private networks where the IP address is not directly
visible to the open internet.

A subnet is a collection of nodes that share a common routing and
therefore are all visible to one another. The simplest subnet uses the
third number to define the subnet while the fourth describes a unique
ID for each node. In this scenario, the \var{192.168.1.x} subnet has
space for 255 devices to connect.

One of the nodes on a subnet must be a router, which manages traffic
between devices and acts as a gateway to send and receive data to a
parent network (typically the internet). The router has a node that
faces the wide area network (WAN) with single IP address. One or more
connections inside the local area network (LAN), sometimes extended
with a network hub or switch, facilitates connection of many local
devices. When any of the devices on the LAN communicates out to the
internet, it broadcasts the router's IP address.

Note that one or more of the devices in the subnet might itself be a
router with a private network behind it. Using special tables, routers
can be told how packets should be distributed within its private
domain. For example, a router with the address \var{192.168.7.1}
manages the private \var{192.168.7.x} domain. Its outward-facing node
is \var{192.168.1.151} and participates in the \var{192.168.1.x}
network. The router managing that network is told that packets
destined for \var{192.168.7.x} should be handed to
\var{192.168.1.151}. Now any node in the \var{192.168.1.x} network can
originate a packet destined for an address in the \var{192.168.7.x}
private network.

%-----------------------------------------------------------------
\subsubsection{MOOS Simulations and the IP Network}

Network topology when running a MOOS simulation provides a starting
point for describing payload autonomy network enhancements. The laptop
typically used as the shoreside computer is connected to the primary
network router and assigned a static IP address of
\var{192.168.1.150}.

\vspace{0.1in}
\begin{figure}[H]
  \centering 
  \includegraphics[width=0.85\textwidth]{figures/pabloNetworkSimulation.png}
  \caption{Network topology of a MOOS simulation with the shoreside computer 
    connected to the  primary network router. }
  \label{fig_network_topo_sim}
\end{figure}
\vspace{0.1in}

%-----------------------------------------------------------------
\subsubsection{Network Topology Without Payload Autonomy}
\label{sec_pbx_network_topo_no_pa}

Systems running MOOS must be deployed on an IP-based LAN by
definition.  Vehicles and shoreside require network visibility. To
reduce complexity, the typical arrangement is to attach cooperating
MOOS nodes to the same subnet. For example, at MIT a common network
layout is:

\vspace{0.15in}
\begin{tabular}{ l l }
  {\bf Address} &amp; {\bf Node Description} \\
  \hline
  \var{192.168.1.1} &amp; Primary Router \\
  \var{192.168.1.2} &amp; Pass-through wireless access point \\
  \var{192.168.1.150} &amp; Shoreside computer \\
  \var{192.168.1.171} &amp; Vehicle A wireless radio / frontseat computer \\
  \var{192.168.1.172} &amp; Vehicle B wireless radio / frontseat computer \\
  \var{192.168.1.n} &amp; Additional vehicle frontseat computers \\
\end{tabular}
\vspace{0.15in}

\noindent
With a common subnet, the shoreside and both field units can all reach
each other over the IP network using \app{pShare}. This topology is
common in IvP simulation. For example, running the
\var{moos-ivp/ivp/missions/m4\_dingo} mission launches four simulated
vehicles and a shoreside on the same computer.  Each of these nodes
happens to have the \var{localhost} address and therefore are all on
the same subnet. (With \var{localhost}, traffic does not leave the
network interface and is routed back into the originating computer.).

\vspace{0.1in}
\begin{figure}[H]
  \centering
  \includegraphics[width=0.85\textwidth]{figures/pabloNetworkVehicleWithoutPablo.png}
  \caption{Network topology of a vehicle running MOOS on its frontseat. }
  \label{fig_network_topo_noPA}
\end{figure}
\vspace{0.1in}

%---------------------------------------------------------------
\subsubsection{Network Topology for Payload Autonomy}
\label{sec_pbx_network_topo_for_ps}

In many cases there is no reason for the front seat to participate in
the IP network. An example is the MIT 2014 RobotX vessel. The front
seat on the WAM-V boat was implemented on an Arduino. That device
manages vehicle actuation in consideration of MOOS inputs, system
health, manual control, and the emergency-stop. It does not connect to
the IP network or need access to the internet. In this and similar
cases, the back-seat computer is directly connected to the IP network
radio and therefore is itself a node on the common subnet.

Vehicles such as the Clearpath Kingfisher M200 provide a more complex
arrangement where the front-seat computer manages the network hardware
and the back-seat connects through a payload interface. Networking
rules prohibit direct piggybacking; the back-seat cannot operate in
the same subnet as the front-seat upstream connection. The solution is
to create a separate subnet with the front-seat acting as the
router. An IP address on the new subnet is assigned to the back-seat.

With the M200 as an example, the wireless radio is connected to the
front-seat computer and gives it a node on the \var{192.168.1.x}
network. An Ethernet port in the payload bay is directly connected to
and managed by the front-seat motherboard. As the router for an
independent subnet, the front-seat assigns an IP address of
\var{192.168.2.1} (note the \var{.2.} grouping) to the payload
Ethernet port. Any device connecting to this node must be on the
\var{192.168.2.x} subnet for IP access to the front seat.

Conveniently, the \var{192.168.2.x} subnet can reach out to the
\var{192.168.1.x} network by configuring simple routing settings on
the M200 and by telling the primary router that the \var{192.168.2.x}
is reached by routing packets to the \var{192.168.1.x} front-seat IP
address. The following is an example of the network topology at MIT
for implementing Pablo units with M200 vehicles:

\vspace{0.15in}
\begin{tabular}{ l l }
  {\bf Address} &amp; {\bf Node Description} \\ \hline
  \var{192.168.1.1} &amp; Primary Router \\
  \var{192.168.1.2} &amp; Pass-through wireless access point \\
  \var{192.168.1.150} &amp; Shoreside computer \\
  \var{192.168.1.171} &amp; Vehicle A wireless radio / front-seat computer \\
  \var{192.168.2.1} &amp; Vehicle A payload Ethernet port / front-seat computer \\
  \var{192.168.2.100} &amp; Pablo unit for vehicle A \\
  \var{192.168.1.172} &amp; Vehicle B wireless radio / front-seat computer \\
  \var{192.168.3.1} &amp; Vehicle B payload Ethernet port / front-seat computer \\
  \var{192.168.3.100} &amp; Pablo unit for vehicle B
\end{tabular}
\vspace{0.15in}

\vspace{0.1in}
\begin{figure}[H]
  \centering 
  \includegraphics[width=0.85\textwidth]{figures/pabloNetworkVehicleWithPablo.png}
  \caption{Network topology of a vehicle hosting a Pablo unit as the
    back-seat on a private subnet.}
  \label{fig_network_topo_PA}
\end{figure}
\vspace{0.1in}

\paragraph{DHCP.} One feature of the Pablo unit is that it can be readily 
attached to any actual or emulated vehicle without reconfiguring any system 
settings. This is achieved using a dynamic IP assignment protocol called DHCP. 
Instead of retaining a manually-assigned addres, each Pablo unit is configured 
that on starting up it polls its network hosts and asks for connection details. 
The front-seat is acting as a DHCP server and is prepared to answer connection 
requests.

\paragraph{Subnet Conventions.} The MIT fleet has a number of M200 vehicles, 
named alphabetically (Archie, Betty, etc.). On the primary \var{192.168.1.x} 
network, IP addresses start at \var{192.168.1.171} and increment respectively 
to the vehicle names. For example, it is readily obvious that the Evan vehicle 
is \var{192.168.1.175}. The onboard subnets follow the same pattern, for 
example Evan hosts \var{192.168.5.171} (Archie has been retired and therefore 
does not conflict with the \var{192.168.1.x} primary subnet).

Because there is only one payload Ethernet port, the private subnet on each 
vehicle can only support one client. The convention at MIT is to assign 
\var{.100} as the node address. Therefore, a Pablo unit can always be reached 
at the address \var{192.168.XXX.100}, where \var{XXX} is the vehicle's 
numerical letter equivalent.

%-----------------------------------------------------------------------
\subsubsection{Network Topology for Vehicle Emulation with Payload Autonomy}
\label{sec_pbx_network_topo_emulation}

A powerful aspect of the Pablo unit is the ability to connect with an
emulated vehicle or actual hardware without reconfiguring the
system. In this arrangement, the emulated vehicle runs on the same
computer that is running as shoreside. The Pablo unit connects to the
Ethernet port on the laptop, which is configured with a private
subnet. This arrangement also conveniently shares internet access from
the wifi connection to the Pablo.

\vspace{0.1in}
\begin{figure}[H]
  \centering 
  \includegraphics[width=0.85\textwidth]{figures/pabloNetworkEmulation.png}
  \caption{Network topology of Pablo unit acting as the back-seat to an 
    emulated front-seat on shoreside. }
  \label{fig_network_topo_emu}
\end{figure}
\vspace{0.1in}

%====================================================================
\section{Network Configuration}
\label{sec_pbx_network_setup}
%====================================================================

This section describes how to set up the shore, Pablo units, and
Kingfisher M200 autonomous surface vehicles in a payload autonomy
configuration. This setup can be extended to similar arrangements
where the vehicle front-seat acts as a pass-through network for the
back-seat.

\begin{packed_itemize}
\item {\em Router.} Standard-office-home-office (SOHO) router, preferably 
  with wifi, to manage the primary network. Examples here use a Linksys 
  EA6500 but the principles should transfer to other devices that expose 
  access to advanced routing parameters.
\item {\em  Computer.} A laptop or desktop computer with a wireless card 
  and Ethernet port. Examples here refer to this computer as the laptop.
\item {\em  Wireless Access Point.} A radio unit that talks to deployed 
  vehicles.  Wifi on the router may not have range to reach field nodes. The 
  M200  vessels are compatible with Ubquiti Networks radios and examples here 
  describe setup for the Ubiquiti Bullet.
\end{packed_itemize}

%====================================================================
\subsection{Initial Primary Router Configuration}

The objective of this step is to configure the router to manage the
\var{192.168.1.x} network. For most routers, the general steps are as
follows:

\begin{packed_itemize}
\item {\em Initialize.} Reset the router to factory settings (not necessary 
  with a new device).
\item {\em WAN Settings.} Per the manufacturer's instructions, configure 
  the  device for an internet connection.
\item {\em LAN Settings.} Configure the local area network so that the 
  router has IP \var{192.168.1.1} and that DHCP addresses start at 
  \var{192.168.1.200}.
\item {\em Manual Addresses.} Assign fixed IPs to known computers, 
  specifically \var{192.168.1.150} to the primary computer used for 
  shoreside.
\item {\em Wireless Settings.} Configure the wifi with an SSID name and 
  password. Changes on each page require applying settings which will cause a 
  reboot and temporary lack of access to the device. NOTE, When changing 
  the Bullet IP address on the Networking page, use the new address to 
  connect with the Bullet.
\item {\em Wiress Settings Verification.} When all settings have been set, 
  return to all tabs to verify settings. It is possible for settings to reset 
  items on other tabs.
\item {\em Laptop Setup.} On the laptop, configure wireless settings to 
  connect via DHCP to the network SSID.
\end{packed_itemize}

\paragraph{Verification.} Verify that the laptop connects to the network and 
receives the \var{192.168.1.150} address. Once connected, verify that the 
internet is accessible from the laptop.

%====================================================================
\subsection{Field Wireless Radio Configuration}

The Ubiquiti Networks Bullet (all variants) is known to connect with
the M200 wireless radio. The Bullet has one Ethernet port that
connects directly to the primary router and is configured into WDS
mode, which provides a transparent hop on the subnet. Any vehicle that
connects to the Bullet appears connected to the primary router as if
by Ethernet cable.

\vspace{0.1in}
\noindent
To configure a Bullet radio:

\begin{packed_itemize}
\item {\em Provide 24v Power Over Ethernet.} Use the black box near the 
  door of the lab. Connect the Bullet to configure to the {\em LAN} port and 
  your laptop to the {\em WAN} port.
\item {\em Bullet Reset.} Plug in the black box to power on the Bullet. 
  After one minute, press and hold the reset button for 10 seconds. (The 
  button is adjacent to the ethernet port; a Bic pen cap works well for 
  this.) Wait one minute for the reset to complete.
\item {\em Laptop Setup.} Turn off wifi on the laptop. Configure the 
  ethernet port as follows: IP address = 192.168.1.151; Subnet Mask = 
  255.255.255.0; Router = (blank).
\item {\em Connect with the Bullet.} Open a browser and enter 
  http://192.168.1.20. The login is ubnt/ubnt.
\item {\em Bullet Settings.} Configure or verify settings per the table 
  below.
\item {\em Laptop Setup.} Return the laptop ethernet settings to their 
  original values and turn the wifi back on.
\item {\em Verification.} Return the cable configurations so that the 
  Bullet is connected into the lab main router. Verify that field Bullets can 
  connect to the lab network via the newly configured Bullet.
\end{packed_itemize}

\vspace{0.15in}
\begin{tabular}{ | l | l | l | } \hline
  {\bf Ubiquiti Tab} \\ \hline
  {\bf Subcategory} &amp; {\bf Setting Description} &amp; {\bf Value}   \\ \hline
  airMAX Settings   &amp; airMAX                    &amp; (not enabled) \\
                    &amp; Long Range PtP Link Mode  &amp; (not enabled) \\ \hline
  airView           &amp; airView Port              &amp; 18888         \\ \hline
  airSelect         &amp; airSelect                 &amp; (not enabled) \\ \hline
\end{tabular}
\vspace{0.15in}

\vspace{0.15in}
\begin{tabular}{ | l | l | l | } \hline
  {\bf Main Tab} \\ \hline
  {\bf Subcategory} &amp; {\bf Setting Description} &amp; {\bf Value} \\ \hline
  (No settings to change) &amp; &amp;  \\ \hline
\end{tabular}
\vspace{0.15in}

\vspace{0.15in}
\begin{tabular}{ | l | l | l | } \hline
  {\bf Wireless Tab, Basic Wireless Settings} &amp; \\ \hline
  {\bf Subcategory} &amp; {\bf Setting Description} &amp; {\bf Value} \\ \hline
  Basic Wireless Settings &amp; Wireless Mode &amp; Access Point \\
  &amp; WDS &amp; Enable \\
  &amp; SSID &amp; [user choice] \\
  &amp; Country Code &amp; [user choice] \\
  &amp; IEEE 802.11 Mode &amp; B/G/N mixed \\
  &amp; Channel Width &amp; 20 Mhz \\
  &amp; Channel Shifting &amp; Disable \\
  &amp; Frequency, MHz &amp; Auto \\
  &amp; Extension Channel &amp; None \\
  &amp; Frequency List, MHz &amp; (not enabled) \\
  &amp; Auto Adjust to EIRP Limit &amp;(not enabled) \\
  &amp; Antenna Gain &amp; 0 dBi \\
  &amp; Cable Loss &amp; 0 dB \\
  &amp; Output Power &amp; 28 dBm \\
  &amp; Data Rate Module &amp; Default \\
  &amp; Max TX Rate, Mbps &amp; MCS 7 - 65 Automatic \\ \hline	
\end{tabular}
\vspace{0.15in}

\noindent
Selection for wireless security type is left up to the user. This
documentation describes setting up WEP, which is considered a
vulnerable protocol. It is used here simply as a low-overhead method
to prevent access of opportunity, not to provide an impregnable
network. If your requirements dictate increased security, replace the
described WEP details with WPA2 settings.

\vspace{0.15in}
\begin{tabular}{ | l | l | l | } \hline
  {\bf Wireless Tab, Wireless Security} &amp; \\ \hline
  {\bf Subcategory} &amp; {\bf Setting Description} &amp; {\bf Value} \\ \hline
  Wireless Security &amp; Security &amp; WEP \\
  &amp; Authentication Type &amp; Open \\
  &amp; WEP Key Length &amp; 128 bit \\
  &amp; Key Type &amp; ASCII \\
  &amp; WEP Key &amp; [user choice] \\
  &amp; Key Index &amp; 1 \\
  &amp; MAC ACL &amp; (not enabled) \\ \hline
\end{tabular}
\vspace{0.15in}

\vspace{0.15in}
\begin{tabular}{ | l | l | l | } \hline
  {\bf Network Tab} \\ \hline
  {\bf Subcategory} &amp; {\bf Setting Description} &amp; {\bf Value} \\ \hline
  Network Role &amp; Network Mode &amp; Bridge \\
  &amp; Disable Network &amp; None \\ \hline
  Configuration Mode &amp; Configuration Mode &amp; Simple \\ \hline
  Management Network Settings &amp; Management IP Address &amp; Static \\
  &amp; IP Address &amp; 192.168.1.2 \\
  &amp; Netmask &amp; 255.255.255.0 \\
  &amp; Gateway IP &amp; 192.168.1.1 \\
  &amp; Primary DNS IP &amp; 8.8.8.8 \\
  &amp; Secondary DNS IP &amp; 192.168.1.1 \\
  &amp; MTU &amp; 1500 \\
  &amp; Management VLAN &amp; (not enabled) \\
  &amp; Auto IP Aliasing &amp; (not enabled) \\
  &amp; STP &amp; (not enabled) \\ \hline
\end{tabular}
\vspace{0.15in}

\vspace{0.15in}
\begin{tabular}{ | l | l | l | } \hline
  {\bf Advanced Tab} \\ \hline
  {\bf Subcategory} &amp; {\bf Setting Description} &amp; {\bf Value} \\ \hline
  Advanced Wireless Settings &amp; RTS Threshold &amp; 2346 Off \\
  &amp; Distance &amp; .4 miles Auto Adjust On \\
  &amp; Aggregation &amp; 32 Frames 50000 Bytes Enabled \\
  &amp; Multicast Data &amp; Allow All \\
  &amp; Multicast Enhancement &amp; Enable \\
  &amp; Installer EIRP Control &amp; Enable \\
  &amp; Extra Reporting &amp; Enable \\
  &amp; Client Isolation &amp; (not enabled) \\
  &amp; Sensitivity Threshold, dBm &amp; -96 Off \\ \hline
  Advanced Ethernet Settings &amp; Lan0 Speed &amp; Auto \\ \hline
  Signal LED Thresholds &amp; LED1 &amp; 94 \\
  &amp; LED2 &amp; 80 \\
  &amp; LED3 &amp; 72 \\
  &amp; LED4 &amp; 65 \\ \hline
\end{tabular}
\vspace{0.15in}
\vspace{0.15in}

\vspace{0.15in}
\begin{tabular}{ | l | l | l | } \hline
  {\bf Services Tab} \\ \hline
  {\bf Subcategory} &amp; {\bf Setting Description} &amp; {\bf Value} \\ \hline
  Ping Watchdog &amp; Ping Watchdog &amp; (not enabled) \\ \hline
  SNMP Agent &amp; SNMP Agent &amp; (not enabled) \\ \hline
  Web Server &amp; Web Server &amp; Enable \\
  &amp; Secure Connection (HTTPS) &amp; (not enabled) \\
  &amp; Secure Server Port &amp; 443 \\
  &amp; Server Port &amp; 80 \\
  &amp; Session Timeout &amp; 15 minutes\\ \hline
  SSH Server    &amp; SSH Server &amp; Enable \\ \hline
  &amp; Server Port &amp; 22 \\
  &amp; Password Authentication &amp; Enable \\
  &amp; Authorized Keys &amp; (edit list should be empty) \\ \hline
  Telnet Server &amp; Telner Server &amp; (not enabled) \\ \hline
  NTP Client    &amp; NTP Client &amp; (not enabled) \\ \hline
  Dynamic DNS   &amp; Dynamic DNS &amp; (not enabled) \\ \hline
  System Log    &amp; System Log &amp; (not enabled) \\
  &amp; Remote Log  &amp; (not enabled) \\ \hline
  Device Discovery &amp; Discovery &amp; Enable \\
  &amp; CDP &amp; Enable \\ \hline
\end{tabular}
\vspace{0.15in}

%======================================================================
\subsection{M200 Vehicle Network Configuration}

WARNING: The instructions provided here require modifying the M200
front-seat from the manufacturer's settings. Terminal access to the
computer is achieved via the payload Ethernet port. It is possible
that altering parameters may disable network access. Repairing this
situation requires opening the computing bay and connecting a keyboard
and screen directly to the front-seat.

\vspace{0.1in}
\noindent
Prequisites:

\begin{packed_itemize}
\item {\em M200 Vehicle.} Instructions here assume that the M200 has 
  original network parameters as provided by the manufacturer.
\item {\em Primary Router.} The primary router must be at its initial 
  configuration as described above.
\item {\em Field Wireless Radio.} The wifi radio used for field 
  connectivity must be connected as described above.
\item {\em Laptop.} Computer with access to Ethernet and wireless settings.
\end{packed_itemize}

\paragraph{M200 initial login.} As delivered from the manufacturer, the M200 
allows a laptop to connect with the front-seat computer through the
payload bay Ethernet connector:

\begin{packed_itemize}
\item With the M200 turned off, connect an Ethernet cable between the  
  payload port of the M200 and a laptop.
\item Configure the laptop to have an IP address of \var{192.168.1.10} and 
  subnet mask of \var{255.255.255.0}. Other network options should be cleared.
\item Turn off the wifi or other network connections on the laptop.
\item Power on the M200.
\item After a couple of minutes, use \var{\$ ping 192.168.1.1} to verify 
  that the front seat is booted and ready.
\item Connect to the front seat using the default login:
  \var{\$ ssh administrator@192.168.1.1} (password \var{clearpath}). 
\end{packed_itemize}

\paragraph{M200 Network Configuration.} M200 network connection details are 
configured in the \var{/etc/network/interfaces} file. This file must
be edited so that the M200 can connect to the primary network. To
support a Pablo unit connected to the payload connector, the M200 also
must serve as a DHCP router, always giving the attached Pablo unit an
IP address \var{192.168.YYY.100}, where YYY is the vehicle's private
subnet number.  Once the primary router is set up and the M200 initial
login is complete, these steps allow the M200 to connect with the
wireless router:

\begin{packed_itemize}
\item Create a backup of the existing network configuration:
  
\vspace{0.15in}
\begin{consoleverb}
  $ sudo cp /etc/network/interfaces /etc/network/interfaces.backup
\end{consoleverb}
\vspace{0.15in}

\item Using \cmd{sudo} and your favorite editor, open the original file. 
  For example, using \var{vi} the file can be opened as follows:
  
  \vspace{0.15in}
\begin{consoleverb}
  $ vi /etc/network/interfaces
\end{consoleverb}

\vspace{0.15in}

\item Determine the rightmost number for the address per your IP numbering 
  scheme, it will replace the XXX in the configuration listing below.
\item Determine the subnet number for the address of the payload bay  
  private network on the M200. That number will replace YYY in the 
  configuration listing below.
\item Identify the password for your wireless network security ro replace 
  ZZZ in the configuration listing below. If using a security scheme besides 
  WEP, it may be necessary to replace or add wireless lines in the listing.
\item Edit the file to have the following contents. Replace XXX with your 
  choice of IP address. Replace YYY with your network's WEP password or 
  replace relevant wireless lines to match another security scheme:
  
  \vspace{0.25in}
  \begin{listing}{Updated contents of the file 
      \var{etc/network/interfaces}}
    \label{lst_etc_network_interfaces}
    \footnotesize
\begin{verbatim}
  auto lo
  iface lo inet loopback
  
  auto wlan0
  iface wlan0 inet static
  address 192.168.1.XXX
  netmask 255.255.255.0
  gateway 192.168.1.1
  dns-nameservers 8.8.8.8 8.8.4.4
  wireless-essid ubnt
  wireless-mode  Managed
  wireless-key1 s:[ZZZ]
  wireless-keymode open
  
  auto eth0
  iface eth0 inet static
  address 192.168.YYY.1
  netmask 255.255.255.0
  broadcast 192.168.6.255
\end{verbatim}
  \end{listing}
  \normalsize
  
\item Commit the file changes and close the editor.
\item Reboot the M200 vehicle and verify that it is connected to the 
  wireless network by pinging its IP address from your laptop:
  
  \vspace{0.15in}
\begin{consoleverb}
  $ ping 192.168.1.XXX
\end{consoleverb}
\item Log back into the M200 vehicle and verify that it has internet access:
  
  \vspace{0.15in}
\begin{consoleverb} 
  $ ping mit.edu
\end{consoleverb}
\item Install the dhcp service:
  
  \vspace{0.15in}
\begin{consoleverb} 
  $ sudo apt-get install isc-dhcp-server
\end{consoleverb}

\item The file \var{/etc/dhcp/dhcpd.conf} defines dhcp server settings. 
  Using \cmd{sudo} and your favorite editor, modify the following file 
  contents (remember to replace YYY with the vehicle's subnet ID):
  
  \vspace{0.15in}
\begin{consoleverb}
ddns-update-style none;
subnet 192.168.YYY.0 netmask 255.255.255.0
{
range                      192.168.YYY.100 192.168.YYY.100;
option routers             192.168.YYY.1;
option subnet-mask         255.255.255.0;
option domain-name-servers 192.168.1.1;
option broadcast-address   192.168.YYY.255;
default-lease-time         1;
max-lease-time             2;
}
\end{consoleverb}
\item In the same file, uncomment the line:
  
  \vspace{0.15in}
  \begin{consoleverb}
    authorit        ative;
\end{consoleverb}       

\item Commit the file changes an        d close the editor.

\item To tell the DHCP service which interface to use, use \cmd{sudo} and 
  your favorite editor to edit the \var{INTERFACES} line in the file 
  \var{/etc/default/isc-dhcp-server}:
  
  \vspace{0.15in}
\begin{consoleverb}
  INTERFACES="eth0"
\end{consoleverb}

\item Enable packet forwarding between the wireless and wired networks; 
  with \cmd{sudo} and your preferred editor, open \var{/etc/sysctl.conf} and 
  edit the line as follows: 
  
  \vspace{0.15in}
\begin{consoleverb}
  net.ipv4.ip_forward=1
\end{consoleverb}
\item With the configuration files edited, the dhcp service can be 
  restarted: 
  
  \vspace{0.15in}
\begin{consoleverb}
  $ sudo service isc-dhcp-server restart
  $ sudo service isc-dhcp-server start
  $ sudo service isc-dhcp-server stop 
\end{consoleverb}
\end{packed_itemize}

\subsubsection{PABLO Network Configuration}
The Pablo's computer is configured to accept a dynamic address through a DHCP 
connection and a fixed IP over the same Ethernet port to be used for 
troubleshooting. This step is easiest if attempted with a keyboard and display 
connected directly to the computer prior to installation in the enclosure.

M200 network connection details are 
configured in the \var{/etc/network/interfaces} file. Once the primary router 
is set up and the M200 initial login is complete, these steps allow the M200 to 
connect with the wireless router:

\begin{packed_itemize}
\item After logging onto the computer, create a backup of the existing 
  network configuration:
  
  \vspace{0.15in}
\begin{consoleverb} 
  $ sudo cp /etc/network/interfaces /etc/network/interfaces.backup
\end{consoleverb}

\vspace{0.15in}
\item Using \cmd{sudo} and your favorite editor, open the original file. 
  For example, using \cmd{vi} the file can be opened as follows:
  
  \vspace{0.15in}
\begin{consoleverb} 
  $ vi /etc/network/interfaces
\end{consoleverb}
\vspace{0.15in}

\item Edit the file to have the following contents, which are the same for 
  all Pablo units:
  
  \vspace{0.25in}
  \begin{listing}{Updated contents of the file 
      \var{etc/network/interfaces}}
    \label{lst_etc_network_interfaces}
    \footnotesize
\begin{verbatim}
  auto lo
  
  iface lo inet loopback
  iface eth0 inet dhcp
  
  auto eth0:1
  iface eth0:1 inet static
  address 192.168.254.100
  netmask 255.255.255.0
  dns-nameservers 8.8.8.8 8.8.4.4
\end{verbatim}

  \end{listing}
  \normalsize
\item Commit the file changes and close the editor.
\item With an Ethernet cable, connect the Pablo computer to the M200 
  payload port.
\item From your laptop, log into the front-seat computer on the M200:
                  
  \vspace{0.15in}
\begin{consoleverb}
  $ ssh [user]@192.168.1.XXX
\end{consoleverb}
\vspace{0.15in}
\item Reboot the Pablo computer and verify that it is connected to the 
  M200 private subnet and received the proper DHCP address. From the M200 
  front-seat computer:
  
  \vspace{0.15in}
\begin{consoleverb}
  $ ping 192.168.YYY.100
\end{consoleverb}
\vspace{0.15in}
\end{packed_itemize}

\subsubsection{Additional Primary Router Configuration}
In the prior section, verification was completed from the M200
front-seat and not from a laptop connected to the primary network. The
reason for this is that while the M200 is configured to route packets
into the Pablo, the primary router does not yet know of the existance
of any subnets and therefore throws away any packets destined for M200
payload ports. These additonal configurations are needed on the
primary router:

\begin{packed_itemize}
\item Log into the primary router as the administrator.
\item Navigate to the advanced routing settings page. On Linksys routers 
  this is reached by clicking the Connectivity button on the main page then 
  selecting the Advanced Routing tab along the top.
\item The objective is to create a static route to the vehicle subnets 
  through the vehicle's primary network addresses. On the Linksys this is 
  done by clicking the Add Static Route button. Create a new static route for 
  each vehicle in your fleet with the following settings:
\begin{packed_itemize}
\item Each route is named. The MIT convention is use the label 
  \var{payload[}vehicle name\var{[} (e.g., \var{payloadEvan}).
    \item The destination IP is \var{192.168.XXX.0}, where XXX is the 
      subnet number for each vehicle (e.g., Evan's desination ID is 
      \var{192.168.5.0}).
    \item The subnet mask is always \var{255.255.255.0}.
    \item The gateway is the IP address of the vehicle's front seat on the 
      primary network (e.g., Evan's gateway is \var{192.168.1.175}).
    \item The interface is \var{LAN}.
\end{packed_itemize}

\item Disconnect from the router then reboot it to ensure all settings are 
  applied.
\item Verify the settings for each vehicle by connecting a Pablo unit and 
  attempting to \var{ssh} or \var{ping} to the unit from a laptop connected 
  to the primary network.
\end{packed_itemize}


%====================================================================
\subsection{Pablo Computer Preparation}

A new Raspi arrives in a box and the user must install the SD card and
the embedded display. Before preparing the Raspi, prepare the SD card
as described in Section \ref{sec_SD_Card}, above. Inserting the SD
card is straightforward.

\subsubsection{Raspi TFT Display - Software Configuration and Hardware Setup}

\vspace{0.1in}
\begin{figure}[H]
  \centering 
  \includegraphics[width=0.60\textwidth]{figures/pabloTFT.png}
  \caption{\bf The Adafruit PiTFT Plus 320x240 2.8" TFT installed in a PABLO 
    unit.}
  \label{fig_PABLO_with_TFT}
\end{figure}
\vspace{0.1in}

It is useful to have a display connected to the Raspi for setup and
occasionally during use. Historical versions of the Pablo box included
an external HDMI connector that was deprecated due to lack of adequate
waterproofing. Currently, connecting a display requires unscrewing the
lid and using the Raspi's onboard HDMI port.

Several models of small thin-film-transistor (TFT) liquid-crystal
display (LCD) units are available for the Raspi. We recommend the {\em
  PiTFT Plus 320x240 2.8" TFT}, produced by Adafruit Industries, LLC
(Adafruit), who also maintains code for related interface drivers. The
display includes an integrated touchscreen, which is not convered by
our instructions (it is not useful behind the Pablo's cover). The
official web site is here:

\urlx{https://www.adafruit.com/products/2298}


When installed and configured, the Adafruit TFT replaces output
destined for the HDMI port. As the Raspi powers on, the splash screen
and initial boot messages are sent out the HDMI port. Midway through
the boot process, the display drivers load and console output is
diverted to the TFT screen. The screen is small but still usable for
troubleshooting to revive an \cmd{ssh} connection. In general use, the
TFT is used to display the IP address.

For convenience, the instructions listed here describe how to download
pre-built binaries and how to configure the OS to use them. Following
the instructions below suggests that you trust the binary packages
being downloaded. It is possible to download source code and compile
independently per directions on the adafruit website. In addition, the
configuration step can be simplified using their helper
script. Details are provided here in order to support some options not
included in their scripts.

\paragraph{Step 1 - Modifying the Raspian Kernel.}
The operating system does not have native support for the
display. Adafruit has packaged the drivers and makes them available
from their wesbite.

\noindent
Start by powering on the Raspi then logging in via \cmd{ssh} and
updating all installed packages: 

\vspace{0.1in}
\begin{consoleverb}
  $ sudo apt-get update
\end{consoleverb}

\noindent
The PiTFT packages drivers are available from the \var{apt.adafruit.com} 
server, which must be added to the list of available software sources: \\

\vspace{0.1in}
\begin{consoleverb}
 $ curl -SLs https://apt.adafruit.com/add-pin | sudo bash
\end{consoleverb}

\noindent
With the packages available, install the kernel that has PiTFT
packages (this may take around 20 minutes on a Raspi Model 2):

\vspace{0.1in}
\begin{consoleverb}
 $ sudo apt-get install raspberrypi-bootloader
\end{consoleverb}

\paragraph{Step 2 - Add the Device Tree Overlay.} Raspbian uses the concept of 
the {\em Device Tree} (DT) to describe manageable hardware in the
system. A full description of DTs is here:
https://www.raspberrypi.org/documentation/configuration/device-tree.md
The file \var{/boot/config.txt} contains DT details and must have
several lines appended in order to recongnize the TFT unit (replace
{\em vi} with your preferred text editor): 

\begin{consoleverb}
 $ sudo vi /boot/config.txt
\end{consoleverb}

\vspace{0.25in}
\begin{listing}{Device Tree Overlay lines added to the end of 
    \var{/boot/config.txt}}
\label{lst_boot_config_txt}
\footnotesize

\begin{verbatim}
  [pi1]
  device_tree=bcm2708-rpi-b-plus.dtb
  [pi2]
  device_tree=bcm2709-rpi-2-b.dtb
  [all]
  dtparam=spi=on
  dtparam=i2c1=on
  dtparam=i2c_arm=on
  dtoverlay=pitft28r,rotate=270,speed=16000000,fps=10
\end{verbatim}
\normalsize
\end{listing}

\noindent
The \var{rotate}, \var{speed}, and \var{fps} options can be edited at
any time, reboot to commit changes.

\begin{packed_itemize}[2]

\item \mvar{rotate}: Describes which direction is the display
  top. \var{0} (portrait), top near SD card; \var{180} (portrait), top
  near ports; \var{90} (landscape), top toward HDMI port; \var{270}
  (portrait), top toward header.

\item \mvar{speed}: Screen refresh rate. The slowest setting
  \var{16000000} is 16Mhz, which is more than acceptable for console
  work. If the display is used for graphics, \var{32000000} can be set
  instead.
	
\item \mvar{fps}: Frames per second; \var{10} is acceptable for
  console text, \var{20} can be used to improve graphics output but
  will have a performance hit.
	
\end{packed_itemize}

\noindent
Shut down the Raspi to install the display (if already attached, a
reboot is still required): \\

\vspace{0.1in}
\begin{consoleverb}
 $ sudo shutdown -h 0
\end{consoleverb}

\paragraph{Step 3 - Installing the TFT Display.}
The Raspi must be configured to support an \cmd{ssh} connection before
installing a display. The installation process will disable the HDMI
display and it is inconvenient (but possible) to configure the Raspi
on a tiny screen.Disconnect power from the Raspi. Assure proper
grounding. The display board simply presses down onto the Raspi header
pins. On the Model 2, where the Raspi includes additional pins, match
with the header pins closest to the SD card.

{\em At this point, rebooting will display a blank screen.}

\paragraph{Step 4 - Directing Output to the Console.}
Following the steps above, the kernel is installed and the device tree
is configured to support the TFT's framebuffer but the console does
not yet get directed to the TFT. By default, text is pushed to the
HDMI framebuffer at \var{/dev/fb0}. Now, we want output to be pushed
to the new PiTFT framebuffer at \var{/dev/fb1}.

\noindent
Power on the Raspi. The screen will begin all white then turn to all
black indicating that it is powered but not receiving any data to
display. Via \cmd{ssh}, edit the boot configuration file: \\

\vspace{0.1in}
\begin{consoleverb}
 $ sudo vi /boot/cmdline.txt
\end{consoleverb}

\noindent
Locate the line ending in \var{rootwait}. Add \var{fbcon=map:10
  fbcon=font:VGA8x8 consoleblank=0}, ensuring that it appears on the
same line.  The entire file should appear as follows: 

\vspace{0.25in}
\begin{listing}{Device Tree Overlay lines added to the end of /boot/config.txt}
\label{lst_boot_config_txt}
\footnotesize
\begin{verbatim}
     dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 
     root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes 
     rootwait fbcon=map:10 fbcon=font:VGA8x8 consoleblank=0
\end{verbatim}
\normalsize
\end{listing}

\noindent
The \var{consoleblank} parameter indicates that the display shall not
go to sleep during periods of inactivity. It is also necessary to edit
the \var{/etc/kbd/config} file as in:

\vspace{0.1in}
\begin{consoleverb}
 $ sudo emacs -nw /etc/kbd/config
\end{consoleverb}

\noindent
Locate the \var{BLANK\_TIME} parameter and set its value to \var{0}.

\noindent
Reboot the raspi to enjoy console text on the TFT display.


%====================================================================
\subsection{Pablo Assembly Instructions}
\label{subsec_Pablo_Assembly}
\index{Pablo Asssembly}

The PABLO reference design can be assembled almost entirely by an
individual with novice mechanical skills. The exception is cutting
holes for the waterproof connectors, which can be solved via other
means, see below. After acquiring items listed in the bill of
materials, the PABLO unit can be assembled following these steps:

\begin{packed_itemize}
\item {\em Raspi.} Install TFT and microSD card into the Raspi.
\item {\em Enclosure} Cut holes for waterproof connectors.
\item {\em Mounting Plate} Attach Raspi to the mounting plate and instal 
  the plate in the enclosure.
\item {\em Glands} Route power and Ethernet cables through glands, attached 
  connectors, and install in the enclosure.
\item {\em Wiring} Attach USB, power, and Ethernet cables inside the 
  enclosure.
\item {\em Test and Seal} Test the system then attach the enclosure lid.
\end{packed_itemize}

%====================================================================
\subsection{Enclosure Preparation}

Off-the-shelf, the Bud Industries PN-1325C provides NEMA4X (IP66) dust
and water ingress protection. The box is sealed against all dust and
is rated for protection against water jets. In practice the box is
splash-proof and can be contained in a wet payload bay it may not
survive being submersed. {\em The major concern in preparing the
  enclosure is to retain the waterproofing.} Suggested methods for
cutting the holes include:

\paragraph{Professional machinist.} 
The most ideal method for cutting holes in the polycarbonate PN-1325C
enclosure is to retain the services of an individual who is
experienced in working with flexible plastic boxes.

\paragraph{Laser Cutting.} 
The enclosure is polycarbonate and can be cut in a laser cutting
machine, provided the bed depth can contain the box. While this method
can produce excellent results, it may require iterative testing to
optimal ideal cutting parameters for the material.

\paragraph{Gland holes: mill or drill press.} 

Using a mill, the 0.5-inch holes for the glands can be cut using a
$1/2$-inch end mill. Using a drill press, the hole can be created
using progressively larger bits to prevent binding and cracking. In
both cases, care should be taken to rigidly anchor the box to prevent
vibration and possibly to support the inside of the box to prevent
bowing under pressure.

\paragraph{Gland holes: hand drill.} 
The 0.5-inch holes for the glands can be cut using an electric drill
with the box locked in a suitable vise but expect an imprecise
position and an oblong hole. While progressively larger bit sizes will
work, a cleaner hole can be achieved using a stepper bit.

\paragraph{USB holes: manual method - not recommended.} 
Holes for the Bulgin connectors can be created by drilling a 1-inch
hole with any of the aforementioned techniques. Note that this large
of a hole is likely to result in cracking. Cutting the hole with the
lid attached reduces the likelihood of box damage. Use a hand reamer
to increase the size of the hole to fit the connector. A small hand
file can be used to cut the key notch.

\vspace{0.1in}

\begin{figure}[H]
  \centering 
  \includegraphics[width=0.99\textwidth]{figures/HolesInBox.png}
  \caption{PABLO unit enclosure with holes cut for glands and USB connectors.}
  \label{fig_holes_in_box}
\end{figure}

\vspace{0.1in}

\subsubsection*{Precut Boxes}
Although availability is not guaranteed, MIT retains a collection of
boxes that have precut holes. Contact our group at the general email
address provided at \urlx{http://www.moos-ivp.com}.


The baseline PABLO unit design calls for four holes to be cut, as
shown in Figure \ref{fig_holes_in_box}:

\begin{itemize}
\item Power wire gland
\item Ethernet cable gland
\item Bulgin Buccaneer USB connector 1
\item Bulgin Buccaneer USB connector 2
\end{itemize}

Gland holes are located on a short side of the box. Each is a 0.5-inch
diameter circle, centered in the panel space, as show in Figure
\ref{fig_PABLO_gland_holes}:

\vspace{0.1in}
\begin{figure}[H]
  \centering 
  \includegraphics[width=0.99\textwidth]{figures/PABLO_Gland_Holes.png}
  \caption{\bf Mechanical drawing describing PABLO unit holes for the glands.}
  \label{fig_PABLO_gland_holes}
\end{figure}
\vspace{0.1in}

Holes for the Bulgin Buccaneer USB connectors are located on a long
side, adjacent to the side containing the glands (see Figure
\ref{fig_holes_in_box} for reference). Positions for the USB holes are
show in Figure \ref{fig_USB_holes}. Exact cutting dimensions are
described in Figure \ref{fig_Buccaneer_holes}.

\vspace{0.1in}
\begin{figure}[H]
  \centering 
  \includegraphics[width=0.99\textwidth]{figures/PABLO_USB_Holes.png}
  \caption{\bf Mechanical drawing describing PABLO unit holes for the USB 
    connectors. }
  \label{fig_USB_holes}
\end{figure}
\vspace{0.1in}

\vspace{0.1in}
\begin{figure}[H]
	\centering 
	\includegraphics[width=0.25\textwidth]{figures/BuccaneerHole.png}
	\caption{\bf Bulgin Buccaneer hole descriptions. }
	\label{fig_Buccaneer_holes}
\end{figure}
\vspace{0.1in}


%====================================================================
\section{Mounting Plate}
%====================================================================

The mounting plate retains the Raspberry Pi inside the
enclosure. Without the plate, there is no way to secure the Raspi
inside the box. The plate can by downloading the design and laser
cutting, machining, or manually sawing an acrylic
plate. Alternatively, the plate can be ordered from Ponoko for a small
creation and delivery fee. Plate thickness should be 3 or 4 mm.

\vspace{0.1in}
\begin{figure}[H]
  \centering 
  \includegraphics[width=0.99\textwidth]{figures/Plate.png}
  \caption{\bf Mounting plate installed in the enclosure. }
  \label{fig_mounting_plate}
\end{figure}
\vspace{0.1in}

\paragraph{Accessing the Design File}
The mounting plate design file is an encapsulated postscript (EPS)
file that is hosted at
\urlx{http://www.ponoko.com/showroom/MITPablo}. The design is in the
public domain and can be downloaded, modified, and used without
restriction or attribution. The EPS file format can be loaded into
most drawing software packages that are used with laser cutters.

\paragraph{Ordering a Completed Plate}
The company Ponoko offers services for cutting the file and delivering
the part. The middle-sized (P2) sheet of acrylic is required to cut at
least one plate but is large enough to cut several. If you are
ordering more than one plate, modify the EPS file to include multiple
copies of the design within the plate. Note that Ponoko charges for
distance the laser travels so it is efficient to share cut edges as
possible.

\subsection{Installing the Raspi}
The Raspberry Pi is elevated above the mounting plate in order to
avoid crushing bottom-mounted components and to improve access to
peripheral connectors. M3 screws secure the computer to the plate with
the hex nuts secured on the bottom of the plate.


\end{document}


</pre></body></html>