% Licensed to the Apache Software Foundation (ASF) under one
% or more contributor license agreements.  See the NOTICE file
% distributed with this work for additional information
% regarding copyright ownership.  The ASF licenses this file
% to you under the Apache License, Version 2.0 (the
% "License"); you may not use this file except in compliance
% with the License.  You may obtain a copy of the License at

%   http://www.apache.org/licenses/LICENSE-2.0

% Unless required by applicable law or agreed to in writing,
% software distributed under the License is distributed on an
% "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
% KIND, either express or implied.  See the License for the
% specific language governing permissions and limitations
% under the License.

!TEX root = ../design.tex

\chapter[k Nearest Neighbors]{k Nearest Neighbors}

\begin{moduleinfo}
\item[Authors] \href{mailto:okislal@pivotal.io}{Orhan Kislal}

\item[History]
	\begin{modulehistory}
		\item[v0.1] Initial version: knn and kd-tree.
	\end{modulehistory}
\end{moduleinfo}

% Abstract. What is the problem we want to solve?
\section{Introduction} % (fold)
\label{sec:knn_introduction}

\emph{Some notes and figures in this section are borrowed from \cite{medium_knn} and \cite{point_knn}}.

K-nearest neighbors (KNN) is one of the most commonly used learning
algorithms. The goal of knn is to find a number (k) of training data points
closest to the test point. These neighbors can be used to predict labels via
classification or regression.

KNN does not have a training phase like the most of learning techniques. It
does not create a model to generalize the data, instead the algorithm uses the
whole training dataset (or a specific subset of it).

KNN can be used for classification, the output is a class membership (a
discrete value). An object is classified by a majority vote of its neighbors,
with the object being assigned to the class most common among its k nearest
neighbors. It can also be used for regression, output is the value for the
object (predicts continuous values). This value is the average (or median) of
the values of its k nearest neighbors.

\section{Implementation Details}

The basic KNN implementation depends on the table join between the training dataset and the test dataset.

\begin{sql}
	(SELECT test_id,
            train_id,
            fn_dist(train_col_name, test_col_name) AS dist,
            label
    FROM train_table, test_table) AS knn_sub
\end{sql}

Once we have the distance between every train - test pair, the algorithm picks the k smallest values.

\begin{sql}
	SELECT row_number() OVER
        (PARTITION BY test_id ORDER BY dist) AS r,
        test_id,
        train_id,
        label
	FROM knn_sub
	WHERE r <= k
\end{sql}

Finally, the prediction is completed based on the labels of the selected
training points for each test point.

\section{Enabling KD-tree}

One of the major shortcomings of KNN is the fact that it is computationally
expensive. In addition, there is no training phase; which means every single
prediction will have to compute the full table join. One of the ways to
improve the performance is to reduce the search space for test points. Kd-tree
option is developed to enable trading the accuracy of the output with higher
performance by reducing the neighbor search space.

Kd-trees are used for organizing data in k dimensions. It is constructed like
a binary search tree where each level of the tree is using a specific
dimension for finding splits.

\begin{figure}[h]
	\centering
	\includegraphics[width=0.9\textwidth]{figures/2d_kdtree.pdf}
\caption{A 2D kd-tree of depth 3}
\label{kdd:2d_kdtree}
\end{figure}

A kd-tree is constructed by finding the median value of the data in a
particular dimension and separating the data into two sections based on this
value. This process is repeated a number of times to construct smaller
regions. Once the kd-tree is prepared, it can be used by any test point to
find its assigned region and this fragmentation can be used for limiting the
search space for nearest neighbors.

Once we have the kd-tree regions and their borders, we find the associated
regions for the test points. This gives us the first region to search for
nearest neighbors. In addition, we allow the user to request for multiple
regions to search. This means we have to decide which additional regions to
include in our search. We implemented a backtracking algorithm to find these
regions. The core idea is to find the closest border for each test point and
select the region on the other side of the border. Note that points that
reside in the same region might have different secondary (or tertiary, etc.)
regions. Consider the tree at Figure~\ref{kdd:2d_kdtree}. A test point at $<5
, 2>$ is in the same region as $<3 , 3.9>$. However, their closest borders and
the associated secondary regions are wildly different. In addition, consider
$<3 , 3.9>$ and $<6 , 3.9>$. They both have the same border as their closest
one ($y=4$). However, their closest regions do differ. To make sure that we
get the correct region, the following scheme is implemented. For a given point
$P$, we find the closest border, $dim[i] = x$ and $P$'s relative position to
it ($pos$ = $-1$ for lower and $+1$ for higher). We conjure a new point that
consists of the same values as the test point in every dimension except $i$.
For $dim[i]$, we set the value to $x-pos*\epsilon$. Finally, we use the
existing kd-tree to find this new point's assigned region. This region is our
expansion target for the point $P$. We repeat this process with the next
closest border as requested by the user.

The knn algorithm does not change significantly with the addition of regions.
Assuming that the training and test datasets have their region information
stored in the tables, the only necessary change is ensuring that the table
join uses these region ids to limit the search space.

\begin{sql}
	(SELECT test_id,
            train_id,
            fn_dist(train_col_name, test_col_name) AS dist,
            label
    FROM train_table, test_table
    WHERE train_table.region_id = test_table.region_id
    ) AS knn_sub
\end{sql}


% !TeX spellcheck = en_US
\documentclass[]{report}
\usepackage[utf8]{inputenc}
\usepackage{lmodern}
\usepackage{graphicx}
\usepackage{hyperref}
\usepackage{tikz}
\usepackage{amsmath}
\usepackage{amssymb}

\begin{document}

\section{Building the Grid}

- objective is selecting the material properties (permittivity, permeability, conductivity) for each node in the grid

- we have a staggered grid with prisms as cells (boxes), this gets inaccurate for certain geometries, think of spheres and cylinders but also structures that are very thin in comparison to the cell size

\subsection{Structure of a Simulation}

- top-down approach, we need broad simulation configuration, that is the boundaries, time step, number of cells

- then we have collection of objects that have a geometry and materials, these will be given as a scene tree which can contain the CSG-operations union, intersection, and difference

- the following objects are planned: box, cylinder, ellipsoid (generalization of sphere), custom model (wavefront obj)

- position/rotation/scale can be given parametrically

- box: either (corner1, corner2) or (center, extents in x,y,z)

- sphere: (center, radius in x,y,z) or (corner1, corner2)

- cylinder: (corner1, corner2) or (center, extents in x,y,z)

- model: (corner1, corner2) or (center, extents in x,y,z)

- each one can additionally be rotated, with Euler angles pitch, yaw, roll

- every object can have one assigned material

- material consists of permittivity, permeability, conductivity

- these can be anisotropic in x, y, z

- side note: data of the whole grid can get very large, several gigabytes even for smaller problems, therefore there definitely needs to be some kind of compression (RLE or sparse matrix approach)

\subsection{Approach to Building the Grid}

- simplest form: fill material properties by directly sampling from the objects at the positions of electric and magnetic fields in each cell

- laid out: go through every node, determine position of every component of electric/magnetic field, sample from the objects

- in case there are several overlapping objects: the highest permeability, permittivity, conductivity is picked

- add image for this

- there is an error at boundaries, e.g. spheres, cylinders or even prisms with this method

- increase resolution for no additional space usage by splitting cell into eight sub-cells, sampling them and taking the arithmetic mean, since that is more costly in computation, only do this at boundaries

- other object that comes up quite often are thin plates, e.g. microstrips or other lines on printed circuit boards, conforming the grid to those thin lines would require lots of cells

- faster alternative: align grid with those thin strips and make the respective face of the cell into a high-conductivity material (e.g. for a microstrip)

- thin wires can be done similarly, just make one side of a cell into a highly conductive line

- problem: cell has to conform exactly, either only allow thin stuff on one plane or we need to come up with an algorithm that finds an optimal cell size that aligns with as many thin features as possible, if for example there are several planes in a pcb

\end{document}


\input assets/cs-pre
\begin{document}
\MYTITLE{CMPSC 383: Multi-Agent and Robotic Systems}{Final Project Progress Report}
\MYHEADERS{}

\section{Language Choice}

We chose Haskell as the implementation language for our Boids simulation.
Haskell is a purely functional language with lazy evaluation. It has been observed that Haskell supports the rapid prototyping of software systems, allowing working systems to be implemented quickly and with minimal complexity~\cite{hudak1994haskell}. This observation, along with our previous experience in the language, influenced our choice of Haskell as a platform for our project.

As our class experience with implementing Multi-Agent simulations has been solely through the object-oriented programming paradigm, our language choice presented a challenge, but also a valuable learning experience. Our
implementation of the Boid agents involves the definition of an abstract data
type, which contains the position, velocity, and neighborhood radius of an
individual boid. In Haskell, this is defined as follows:

\begin{minted}{haskell}
data Boid = Boid { position :: Point
                 , velocity :: Vector
                 , radius   :: Float
                 }
\end{minted}

Note that Haskell does not allow mutation of existing values. Therefore, once a
Boid is created, it cannot be mutated, and instead updating the Boid's state
requires the creation of an entirely new Boid instance.

Also, in contrast to a corresponding OOP implementation, which might define some Boid behaviour to accompany this basic data structure, this Boid data type is kept distinct from its update method. Instead, we define a type called \mintinline{haskell}|Update|:

\begin{minted}{haskell}
type Update = Boid -> Boid
\end{minted}

Thus, a function of type \mintinline{haskell}|Update| is a function that takes a \mintinline{haskell}|Boid| and returns
a new \mintinline{haskell}|Boid|. We use \mintinline{haskell}|Update| to define \mintinline{haskell}|Behaviour|:

\begin{minted}{haskell}
type Perception = [Boid]
type Behaviour = Perception -> Update
\end{minted}

This defines a \mintinline{haskell}|Behaviour| as a function that maps a \mintinline{haskell}|Boid|'s neighborhood to
an update function. These examples demonstrate how implementing a multi-agent
simulation in a purely-functional language requires a different conception of
what it means programmatically for an Agent to behave.

\section{Boids}

Boids is a simple simulation of flocking behaviour which mimics the appearance of a flock of birds~\cite{hartman2006autonomous}. It was first described by Craig Reynolds in 1987~\cite{reynolds1987flocks}.

Boids models the behaviour of a flock in as being effected by three primary steering forces: \textit{cohesion}, the tendency of an individual to stay close to the centre of the flock; \textit{separation}, the tendency of an individual to avoid collision with other individuals, and \textit{alignment}, the tendency of an individual to match velocities with its neighbors~\cite{hartman2006autonomous,reynolds1987flocks}. Each of these steering forces is modeled as a vector, which are then summed to compute the position of a given boid at each time interval.

The separation steering vector $\vec{s}_i$ for a given boid $b_i$ may be calculated as the negative sum of the position vector of $b_i$ and each visible boid $b_j$, using the following formula:

\[ \vec{s}_i = - \sum\limits_{\forall b_j \in V_i} (p_i - p_j) \]

where $V_i$ is the set of boids visible by $b_i$ (i.e. the neighborhood)~\cite{hartman2006autonomous}. In our implementation, this formula corresponds to the following Haskell source code:

\begin{minted}{haskell}
separation :: Boid -> Perception -> Vector
        -- :: Boid -> [Boid] -> V3 Float
separation self neighbors =
    let p = position self
    in sumV . map (^-^ p) $ positions neighbors
\end{minted}

The cohesion steering vector $\vec{k}_i$ for a given boid $b_i$ may be calculated by finding the centre of density $c_i$ of the visible boids $V_i$ using the formula

\[ c_i = \sum\limits_{\forall b_j \in V_i} \frac{p_j}{m} \]

where $m$ is the cardinality of $V_i$. The steering vector may then be calculated by subtracting $b_i$'s position from $c_i$~\cite{hartman2006autonomous}:

\[ \vec{k}_i = c_i - p_i \]

In our implementation, these formulae corresponds to the following Haskell source code:

\begin{minted}{haskell}
centre :: Perception -> Vector
    -- :: [Boid] -> V3 Float
centre boids =
    let m = fromIntegral $ length boids :: Float
    in sumV $ map (^/ m) $ positions boids

cohesion :: Boid -> Perception -> Vector
      -- :: Boid -> [Boid] -> V3 Float
cohesion self neighbors =
    let p = position self
    in centre neighbors - p
\end{minted}

Finally, the alignment steering vector $\vec{m}_i$ for a boid $b_i$ may be calculated by averaging the velocities of the set of visible boids $V_i$ using the following formula

\[ \vec{m}_i = \sum\limits_{\forall b_j \in V_i} \frac{\vec{v}_j}{m} \]

where $\vec{v}_j$ is the velocity of $b_j$. If the cardinality of $V_i$ is zero, then $\vec{v}_i = 0$~\cite{hartman2006autonomous}. In our implementation, this formula corresponds to the following Haskell source code:

\begin{minted}{haskell}
alignment :: Boid -> Perception -> Vector
       -- :: Boid -> [Boid] -> V3 Float
alignment _ []        = V3 0 0 0
alignment _ neighbors =
    let m = fromIntegral $ length neighbors :: Float
    in (sumV $ map velocity neighbors) ^/ m
\end{minted}

Once all three steering vectors have been calculated, they are combined to find the velocity $\vec{v_i\prime}$ of a boid

\[ \vec{v_i\prime} = \vec{v_i} + S.\vec{s_i} + K.\vec{k_i} + M.\vec{m_i} \]

where $S$, $K$, and $M$ are coefficients which control the weight of each steering force and are typically global parameters to the simulation.

The position of that boid at time $t + \Delta t$ maythen  be updated using $\vec{v_i\prime}$

\[ p\prime_i = p_i + \Delta t\vec{v_i}\]

In our implementation, these formulae corresponds to the following Haskell source code:

\begin{minted}{haskell}
steer :: Weights -> Behaviour
   -- :: Weights -> [Boid] -> Boid -> Boid
steer (s, c, m) neighbors self =
    let s_i  = s *^ separation self neighbors
        c_i  = c *^ cohesion self neighbors
        m_i  = m *^ alignment self neighbors
        v'   = velocity self ^+^ s_i ^+^ c_i ^+^ m_i
        p    = position self
        p'   = p ^+^ v'
    in self { position = p', velocity = v'}
\end{minted}

\vfill
\pagebreak

 \bibliographystyle{plain}
 \bibliography{assets/references}

\end{document}


\documentclass[]{AVSSimReportMemo}
\usepackage{AVS}
\usepackage{colortbl}

\newcommand{\ModuleName}{hillPoint}
\newcommand{\subject}{Guidance Module for Hill Frame Pointing}
\newcommand{\status}{Initial Version}
\newcommand{\preparer}{M. Cols}
\newcommand{\summary}{Generate the attitude reference to perform a constant pointing towards a Hill frame orbit axis}

\begin{document}

\makeCover

%
%	enter the revision documentation here
%	to add more lines, copy the table entry and the \hline, and paste after the current entry.
%
\pagestyle{empty}
{\renewcommand{\arraystretch}{2}
\noindent
\begin{longtable}{|p{0.5in}|p{4.5in}|p{1.14in}|}
\hline
{\bfseries Rev}: & {\bfseries Change Description} & {\bfseries By} \\
\hline
Draft & initial copy & M. Cols \\
\hline

\end{longtable}
}

\newpage
\setcounter{page}{1}
\pagestyle{fancy}

\tableofcontents
~\\ \hrule ~\\

\section{Module Input and Output}
Table \ref{tab:inputNavTable} shows the input message from the navigation system.
\begin{table}[h!]
	\centering
	\caption{Input Navigation Message}
	\begin{tabular}{|l|l|l|p{3in}|}
		\hline
		\rowcolor{BrickRed}
		\textcolor{white}{Name} & \textcolor{white}{Type} &
		\textcolor{white}{Length} &
		\textcolor{white}{Description}  \\ \hline
		$\bm{R}_S$ & double [] & 3 &
		Position vector of the spacecraft body-point with respect to the inertial frame in inertial frame components
		($\leftexp{N}{\bm{r}}_{B/N}$) . \\ \hline
		$\bm{v}_S$ & double [] & 3 &
		Velocity vector of the spacecraft point with respect to the inertial frame in inertial frame components
		($\leftexp{N}{\bm{v}}_{B/N}$). \\ \hline
	\end{tabular}
	\label{tab:inputNavTable}
\end{table}

Table \ref{tab:inputCelTable} shows the input message from Spice about the main celestial body.
\begin{table}[h!]
	\centering
	\caption{Input Spice Planet Message}
	\begin{tabular}{|l|l|l|p{3in}|}
		\hline
		\rowcolor{BrickRed}
		\textcolor{white}{Name} & \textcolor{white}{Type} &
		\textcolor{white}{Length} &
		\textcolor{white}{Description}  \\ \hline
		$\bm{R}_P$  & double [] & 3 &
		Position vector of the main celestial object with respect to the inertial frame in inertial frame components . \\ \hline
		$\bm{v}_P$  & double [] & 3 &
		Velocity vector of the main celestial object with respect to the inertial frame in inertial frame components . \\ \hline
	\end{tabular}
	\label{tab:inputCelTable}
\end{table}

Table \ref{tab:outputTable} shows the Attitude Reference output message of the module Hill Point.
\begin{table}[h!]
	\centering
	\caption{Output Attitude Reference Message}
	\begin{tabular}{|l|l|l|p{3in}|}
		\hline
		\rowcolor{BrickRed}
		\textcolor{white}{Name} & \textcolor{white}{Type} &
		\textcolor{white}{Length} &
		\textcolor{white}{Description}  \\ \hline
		$\sigma_{R/N}$ & double [] & 3 &
		MRP attitude set of the reference frame with respect to the reference. \\ \hline
		$\leftexp{N} \omega_{R/N}$ & double [] & 3 &
		Angular rate vector of the reference frame with respect to the inertial expressed in inertial frame components. \\ \hline
		$\leftexp{N} {\dot{\omega}_{R/N}}$ & double [] & 3 &
		Angular acceleration vector of the reference frame with respect to the inertial expressed in inertial frame components. \\ \hline
	\end{tabular}
	\label{tab:outputTable}
\end{table}
\newpage

\section{Hill Frame Definition}
The Hill reference frame takes the spacecraft's orbital plane as the principal one and has origin in the centre of the spacecraft. It is defined by the right-handed set of axes $\mathcal{H}:\{ \hat{\bm\imath}_{r}, \hat{\bm\imath}_{\theta}, \hat{\bm\imath}_{h} \}$, where\par
$\hat {\bm\imath}_{r}$  points radially outward in the direction that connects the center of the planet with the spacecraft. \par
$\hat {\bm\imath}_{h}$ is defined normal to the orbital plane in the direction of the angular momentum. \par
$\hat {\bm\imath}_{\theta}$ completes the right-handed triode.
\begin{figure}[htb]
	\centerline{
	\includegraphics{Figures/Fig2}
	}
	\caption{Illustration of the Hill orbit frame $\mathcal{H}:\{ \hat{\bm\imath}_{r}, \hat{\bm\imath}_{\theta}, \hat{\bm\imath}_{h} \}$, and the inertial frame $\mathcal{N}:\{ \hat{\bm n}_{1}, \hat{\bm n}_{2}, \hat{\bm n}_{3} \}$.}
	\label{fig:Fig1}
\end{figure}

\section{Introduction}
In this module, the output reference frame $\mathcal{R}$ is to be aligned with the Hill reference frame $\mathcal{H}$. Note that the presented technique does not require the planet-fixed  frame to coincide with the inertial frame $\mathcal{N}:\{ \hat{\bm n}_{1}, \hat{\bm n}_{2}, \hat{\bm n}_{3} \}$. Figure 1 illustrates the general situation in which $\bm{R}_{s}$ is the position vector of the spacecraft with respect to the inertial frame and $\bm{R_{p}}$ is the position vector of the  celestial body with respect to the inertial frame as well.
The relative position of the spacecraft with respect to the planet is obtained by simple subtraction:
\begin{equation}
	\label{eq:r}
	\bm r = \bm R_{s} -  \bm R_{p}
\end{equation}
The same methodology is applied to compute the relative velocity vector:
\begin{equation}
	\label{eq:v}
	\bm v = \bm v_{s} -  \bm v_{p}
\end{equation}
Note that the position and velocity vectors of the spacecraft and the celestial body, $\bm{R}_S$,  $\bm{R}_P$,  $\bm{v}_S$ and  $\bm{v}_P$ are the only inputs that this module requires. Having $\bm r$ and $\bm v$, the Hill frame orientation is completely defined:
\begin{subequations}
	\begin{equation}
	\hat{\bm\imath}_{r} = \frac{\bm r}{r}
	\end{equation}
	\begin{equation}
	\hat{\bm\imath}_{h} = \frac{\bm{r}\times{\bm{v}}}{r v}
	\end{equation}
	\begin{equation}
	\hat{\bm\imath}_{\theta} = \hat{\bm\imath}_{h} \times \hat{\bm\imath}_{r}
	\end{equation}
\end{subequations}
And the Direction Cosine Matrix to map from the reference frame to the inertial is obtained:
\begin{equation}
	[RN] =  \begin{bmatrix}
       		\hat{\bm\imath}_{r} \\
		\hat{\bm\imath}_{\theta} \\
		\hat{\bm\imath}_{h}
      \end{bmatrix}
\end{equation}
The corresponding MRP attitude set is computed using the following function from the Rigid Body Kinematics library of Reference~\citenum{schaub}:
$$ [RN] = \textrm{C2MRP}(\bm\sigma_{R/N})$$

\section{Angular Velocity Descriptions}
Let $\mathcal{R}_{0}$ reference the Hill orbit frame. The orbit frame angular rate and acceleration vectors are given by
\begin{equation}
	\label{eq:omega_R0}
	\bm\omega_{R_{0}/N} = \dot f \hat{\bm\imath}_{h}
\end{equation}
\begin{equation}
	\label{eq:domega_R0}
	\dot{\bm\omega}_{R_{0}/N} = \ddot f \hat{\bm\imath}_{h}
\end{equation}
where $f$ is the true anomaly, whose variation is determined through the general standard astrodynamics relations:
\begin{align}
  \dot f &= \frac{h}{r^{2}}
  \\
  \ddot f &= - 2 \frac{\bm v \cdot \hat{\bm\imath}_{r}}{r} \dot f
\end{align}
The angular rate $\bm\omega_{R/N}$ and acceleration $\dot{\bm\omega}_{R/N}$ of the output reference frame $\mathcal{R}$  still need to be computed.
Since the desired attitude is a fixed-pointing one, $\mathcal{R}$ does not move relative to $\mathcal{R}_{0}$. Thus, the angular velocity of the reference frame happens to be
\begin{equation}
	\label{eq:omega_R}
	\bm\omega_{R/N} = \bm\omega_{R/R_{0}} + \bm\omega_{R_{0}/N} = \dot{f} \hat{\bm\imath}_{h}
\end{equation}
Again, given that $ \hat{\bm\imath}_{h}$ is fixed as seen by the reference frame $R$,  the acceleration vector of the reference frame expressed in the reference frame simply becomes:
\begin{equation}
	\label{eq:domega_R}
	\dot\omega_{R/N} = \ddot{f} \hat{\bm\imath}_{h}
\end{equation}
Both $\bm\omega_{R/N}$ and $\dot\omega_{R/N} $ need to be expressed in the inertial frame $N$. \newline
Given
\begin{subequations}
\begin{equation}
\leftexp{R}{\bm \omega_{R/N} } =
      \begin{bmatrix}
       0\\ 0 \\ \dot{f}
      \end{bmatrix}
\end{equation}
\begin{equation}
 \leftexp{R}{\bm\dot{\omega}_{R/N}  } =
      \begin{bmatrix}
       0\\ 0 \\ \ddot{f}
      \end{bmatrix}
\end{equation}
\end{subequations}
Then,
\begin{subequations}
\begin{equation}
	\leftexp{N} {\bm{\omega}_{R/N}} =  [NR] \textrm{ } \leftexp{R} {\bm\omega_{R/N} }
\end{equation}
\begin{equation}
	\leftexp{N} {\bm\dot{\omega}_{R/N} }=[NR] \textrm{ } \leftexp{R} {\bm\dot{\omega}_{R/N}}
\end{equation}
\end{subequations}
Where $ [NR] = [RN]^T$.

\bibliographystyle{unsrt}
\bibliography{references}

\end{document}


\section{Question 1}
From root locus we find out with add one real zero we change shape of root locus and with increasing gain system will be stable and without this zero when we increase gain system chgane better but in some where it goes unstable so with adding just one zero system will work fine and get problem require. For cancelling oscillation we use derivative controller.
\newpage
\begin{itemize}
    \item system step responde
    \begin{figure}[H]
        \caption{system step responde}
        \centering
        \includegraphics[width=12cm]{../Figure/Q1/Q1_system_respond.png}
    \end{figure}
    \item system root locus
    \begin{figure}[H]
        \caption{system root locus plot}
        \centering
        \includegraphics[width=12cm]{../Figure/Q1/Q1_system_rlocus.png}
    \end{figure}
    \item system with controller step responde
    \begin{figure}[H]
        \caption{system with controller step responde}
        \centering
        \includegraphics[width=12cm]{../Figure/Q1/Q1_system_controller_respond.png}
    \end{figure}
    \item system with controller root locus
    \begin{figure}[H]
        \caption{system with controller root locus plot}
        \centering
        \includegraphics[width=12cm]{../Figure/Q1/Q1_system_controller_rlocus.png}
    \end{figure}
    \item system with and without controller step responde
    \begin{figure}[H]
        \caption{system with and without controller step responde}
        \centering
        \includegraphics[width=12cm]{../Figure/Q1/Q1_respond_all.png}
    \end{figure}
    \item system with and without controller root locus
    \begin{figure}[H]
        \caption{system with and withou controller root locus plot}
        \centering
        \includegraphics[width=12cm]{../Figure/Q1/Q1_rlocus.png}
    \end{figure}
\end{itemize}


\input{figures/Coercion}
\subsection{Coercions}
Herman et al. [4] represent casts as combinable coercions to reduce
space comsumption of gradual typing while preserving its semantics.
The syntax and type system for the coercion calculus are defined in
Figure 4 [4]. Note that we add blame labels to certain coercions to
enable blame tracking in our gradual type system. The judgment $\vdash c: S
\rightsquigarrow T$ indicates that coercion $c$ casts a value of type
$S$ to type $T$. The identity $I$ is a coercion of any type to itself.
$D!$ injects a type into ? while $D?^l$ projects ? into a precise type.
Since an injection is always safe, we do not need to blame-track it.
A coercion of two inconsistent types results in $\texttt{Fail}^l$.

As discussed in the previous section, UD blame assignment arises
from the coercion calculus because a coercion
between a function type and ? always goes through the
dynamic function type $? \rightarrow \: ?$. Thus,
the coercion $? \rightsquigarrow (S \rightarrow T)$ is an
abstraction of two coercions: $? \rightsquigarrow
(? \rightarrow \: ?)$ first to make sure that ? is a function type
and then $(? \rightarrow \: ?) \rightsquigarrow
(S \rightarrow T)$. Similarly, the coercion $(S \rightarrow T) \rightsquigarrow \: ?$
performs the coercion $(S \rightarrow T) \rightsquigarrow (? \rightarrow \: ?)$
followed by $(? \rightarrow \: ?) \rightsquigarrow \: ?$ to
generalize a function dynamic type.
The coercion calculus uses the tags $\texttt{Fun}!$ and $\texttt{Fun}?^l$
to represent the injection $(? \rightarrow \: ?) \rightsquigarrow \: ?$ and
projection $? \rightsquigarrow (? \rightarrow \: ?)$. The same concept is
applied to reference coercions. The injection $\texttt{Ref}!$ and
projection $\texttt{Ref}?^l$ are auxiliary to the coercions $\texttt{Ref} \: T
\rightsquigarrow \: ?$ and $? \rightsquigarrow \texttt{Ref} \: T$.

Multiple coercions can behave as one. The function coercion $\texttt{Fun} \: c \: d$
applies coercion $c$ to the argument and $d$ to the result. Coercing
two function types $(S_1 \rightarrow S_2) \rightsquigarrow (T_1 \rightarrow T_2)$
coerces $T_1$ to $S_1$ and $S_2$ to $T_2$. Likewise, the reference coercion
$\texttt{Ref} \: S \rightsquigarrow \texttt{Ref} \: T$ results in
$\texttt{Ref} \: c \: d$, where $c$ coerces all writes from
$T$ to $S$ and $d$ coerces all reads from $S$ to $T$. Finally, the coercion
composition $c;d$ applies each coercion from left to right.

\subsection{Reduction Rules}
The bounded space consumption of coercions derives from their reducibility.
The core set of normalization rules is given in Figure 5. These rules model
after those found in Herman et al. [4] with some additions from Siek and Garcia [7].
The added rules are needed for blame assignment and its confluence. First,
we omit the rule
\begin{equation*}
    c;\texttt{Fail}^l = \texttt{Fail}^l
\end{equation*}
to ensure that blame should always come from the closest coercion to an
expression, unless it is an injection. For instance, $\langle \texttt{Nat}?^{l_1};\texttt{Fail}^{l_2}
\rangle \langle \texttt{Bool}! \rangle \texttt{true} \longrightarrow
\langle \texttt{Bool}!;\texttt{Nat}?^{l_1};\texttt{Fail}^{l_2} \rangle \texttt{true}
\longrightarrow \langle \texttt{Fail}^{l_1};\texttt{Fail}^{l_2} \rangle \texttt{true}
\longrightarrow \texttt{Fail}^{l_1}$. Here the blame is assigned to the
most inner coercion $l_1$, instead of $l_2$
if $\texttt{Fail}^{l_2}$ is allowed to propagate from the right.

Coercions can be reassociated to enable further reduction. A coercion $c$ that
cannot be further reduced is normalized, represented as $\tilde{c}$. Figure
5 shows a list of normal coercions [7]. Note that a composition of normalized
coercions is only normal if none of them are the identity $I$. Also, we omit
the normalized coercion $\texttt{Fail}^l$, which is handled separately
during evaluation.

\input{figures/Reduction}

\subsection{Eager Error Detection}
Let us revisit expression (1) with added labels for casts:
\begin{equation*}
    \langle \texttt{Bool} \rightarrow \texttt{Nat} \Leftarrow
    \: ? \rightarrow \: ? \rangle ^l
    \langle ? \rightarrow \: ? \Leftarrow
    \texttt{Nat} \rightarrow \texttt{Nat} \rangle
    (\lambda x \! : \! \texttt{Nat} . \; x)
\end{equation*}
Observe that this cast would fail because type $\texttt{Bool} \rightarrow
\texttt{Nat}$ is inconsistent with type $\texttt{Nat} \rightarrow
\texttt{Nat}$. However, this error would not be detected in the traditional
cast checking system until $(\lambda x \! : \! \texttt{Nat} . \; x)$ is
applied to a boolean. On the other hand, our gradual type system would not
perform any function application on this expression until its coercions are
normalized. Using one of the core reduction rules, we obtain:
\begin{equation*}
    \langle \texttt{Fun} \: \texttt{Fail}^l \: I \rangle
    (\lambda x \! : \! \texttt{Nat} . \; x)
\end{equation*}
where $\texttt{Fail}^l$ results from the attempt to coerce the argument type
from \texttt{Nat} to \texttt{Bool}. As a result,
the evaluation process should effectively terminate to a cast error before
performing any more unnecessary operations. In order to achieve this
early error detection, we extend the coercion normalization rules with
four eager patterns (see Figure 5) to propagate cast errors. These added rules are similar to
those given in Herman et al. [4] but require the coercion in the argument
position to be normalized when the output coercion evaluates to $\texttt{Fail}^l$
in a function coercion [8].
This restriction makes sure that a failed argument coercion takes the blame when
the output coercion fails too. Failed reference coercions follow an
analogous pattern: blame only goes to a failed ``read'' coercion if
the ``write'' coercion is normal and not a failure.

We have covered the design specifications for gradual typing based on coercions
with UD blame assignment. In the next section, we will apply this design choice
to implement a $\lambda ^? _{\rightarrow}$ interpreter in Haskell.


\documentclass[]{article}
\usepackage{color}
\usepackage{fullpage}
\usepackage{lmodern}
\usepackage{amssymb,amsmath}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage{textcomp} % provides euro and other symbols
% use upquote if available, for straight quotes in verbatim environments
\IfFileExists{upquote.sty}{\usepackage{upquote}}{}
% use microtype if available
\IfFileExists{microtype.sty}{%
\usepackage[]{microtype}
\UseMicrotypeSet[protrusion]{basicmath} % disable protrusion for tt fonts
}{}
\IfFileExists{parskip.sty}{%
\usepackage{parskip}
}{% else
\setlength{\parindent}{0pt}
\setlength{\parskip}{6pt plus 2pt minus 1pt}
}
\setlength{\emergencystretch}{3em}  % prevent overfull lines
\providecommand{\tightlist}{%
  \setlength{\itemsep}{0pt}\setlength{\parskip}{0pt}}
\setcounter{secnumdepth}{0}
% Redefines (sub)paragraphs to behave more like sections
\ifx\paragraph\undefined\else
\let\oldparagraph\paragraph
\renewcommand{\paragraph}[1]{\oldparagraph{#1}\mbox{}}
\fi
\ifx\subparagraph\undefined\else
\let\oldsubparagraph\subparagraph
\renewcommand{\subparagraph}[1]{\oldsubparagraph{#1}\mbox{}}
\fi

% set default figure placement to htbp
\makeatletter
\def\fps@figure{htbp}
\makeatother

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\title{NSF I-DIRSE-IL Cheat Sheet\\
        Notation, \LaTeX~Commands, Terminology, etc.}
\author{Waheed Bajwa, Hagit Shatkay, and Christopher Tunnell}
\date{Last updated: June 17, 2019}

\begin{document}
\maketitle

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Physical Detector}

\subsubsection{Terminology}

\begin{itemize}
\tightlist
\item
  Detector shall be consistently referred to as \emph{detector}.
  \begin{itemize}
  \tightlist
  \item
    Other alternatives include \emph{cylinder} and \emph{time projection chamber}, which can be mentioned in the beginning, but shall be rarely used after that.
    \item XENON is collabration, xenon is element.
  \end{itemize}
\end{itemize}

\subsubsection{Notation}

\begin{itemize}
\tightlist
\item
  Detector as a cylinder:
  \(\Omega := \{(x,y,z) \in \mathbb{R}^3: x^2 + y^2 \leq 10^6, -10^3 \leq z \leq 0\}\)
  {[}units of mm{]}

  \begin{itemize}
  \tightlist
  \item
    $z$ points up toward the sky and is normal to the surface of the Earth.
  \item
    $x$ and $y$ are in the plane of the sensors.
  \item
    Cylindrical coordinates would be parameterized by $\phi$ and $r$ instead of $x$ and $y$, where $r \in [0, 10^3] \subset \mathbb{R}$ is the distance in millimeters from the center of the detector and $\phi \in [0, 2\pi) \subset \mathbb{R}$ is the angle.
  \end{itemize}
\item
  Top, bottom, and side of the detector:
  \(\partial\Omega_T = \{(x,y,0) \in \Omega\}\) {[}top{]},
  \(\partial\Omega_B := \{(x,y,-10^3) \in \Omega\}\) {[}bottom{]}, and
  \(\partial\Omega_S := \{(x,y,z) \in \mathbb{R}^3: x^2 + y^2 = 10^6, -10^3 \leq z \leq 0 \}\) {[}side{]}
\item
  Any spatial location within the detector:
  \(\vec{l} \in \Omega \subset \mathbb{R}^3\) {[}{\color{blue}\LaTeX~command is \verb|\vec{l}|}{]}
\end{itemize}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Physical Sensors Within the Detector}

\subsubsection{Terminology}

\begin{itemize}
\tightlist
\item
  Sensors and sensor data data shall be consistently referred to as \emph{sensors} and \emph{sensor data}.

  \begin{itemize}
  \tightlist
  \item
    Other alternatives include \emph{photosensors}, \emph{PMTs}, \emph{channels}, etc., which can be mentioned in the beginning, but shall be rarely used after that.
  \end{itemize}
\end{itemize}

\subsubsection{Notation}

\begin{itemize}
\tightlist
\item
  Number of sensors at the top and the bottom of the detector:
  \(n := 248\)
  {[}we are ignoring additional sensors that are outside (but adjacent to) the detector for the sake of the proposal{]}
\item
  Number of sensors on the top of the detector: \(n_T := 127\)
\item
  Number of sensors on the bottom of the detector: \(n_B := 121\)
\item
  Indexing of sensors: \(j = 0,\dots,n-1\), where \(0, \dots 126\) are the top ones
\item
  Spatial location of \(j\)-th sensor within the detector:
  \(\vec{l}^s_j \in \partial\Omega_B \cup \partial\Omega_T\) {[}{\color{blue}\LaTeX~command is \verb|\vec{l}^s_j|}{]}
\end{itemize}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Raw Time-series Data Collected by the Sensors}

\subsubsection{Terminology}

\begin{itemize}
\tightlist
\item
  Sensors record \emph{luminosity} incident upon them (physically, transported through photons).
\item
  Each sensor gives rise to a \emph{time-series data stream}, which shall always mean the \emph{digitized data} sampled at \(100\) MHz (one sample every \(10\) ns).
\item
  Data gathered by all sensors shall be collectively referred to as \emph{spatiotemporal data}.

  \begin{itemize}
  \tightlist
  \item
    \emph{Style:} We shall write \emph{spatiotemporal}, rather than \emph{spatio-temporal}.
  \end{itemize}
\item
  High-throughput data is another important characteristics of our spatiotemporal data streams.

  \begin{itemize}
  \tightlist
  \item
    We shall refer to this characteristic as \emph{high-throughput data}, whose meaning shall be clearly explained in the beginning of the proposal.
  \item
    When used generally, this term will refer to any experiment or application that accumulates more than 1 petabyte per year of data.
  \end{itemize}
  \item Each sensor is connected to a channel.  The numbering of the sensor and channel are interchangable.
\end{itemize}

\subsubsection{Notation}

\begin{itemize}
\tightlist
\item
    The random variable associated with measurements of the $j$-th sensor (which is also the $j$-th channel to which the sensor is connected): $C_j \in \mathbb{R}_+$

\item
  Data collected by \(j\)-th sensor at (discrete) time \(t\):
  \(c_j^t, t=0,1,\dots\), where \(t = 0\) denotes the first sample, \(t=1\) denotes the second sample, and so forth.
\item
  Description of sensor data: \(c_j^t = x_j^t + w_j^t\), with \(x_j^t = 0\) in the absence of any measurable luminosity and \(w_j^t\) is sensor noise

  \begin{itemize}
  \tightlist
  \item
    Sensor noise seems to have a mixture model, with part of it being Poisson, but it also has impulsive (spikes) and sinusoidal characteristics.
  \end{itemize}
\item
  Collection of data from all sensors at time \(t\), represented as a vector:
  \(\vec{C}^{t} \in \mathbb{R}_+^n\) {[}{\color{blue}\LaTeX~command is \verb|\vec{C}^{t}|}{]}
\item
  Collection of data (non-Euclidean representation) from all sensors at time \(t\):
  \(\mathcal{C}^t\) {[}{\color{blue}\LaTeX~command is \verb|\mathcal{C}^t|}{]}
  \begin{itemize}
  \tightlist
  \item
    Notice that linear algebra operations can be applied directly on the mathematical object \(\vec{C}^{t}\), which is taken as a vector in \(\mathbb{R}^n\), but not on the mathematical object \(\mathcal{C}^t\).
  \item
    The distinction between the two mathematical objects, while subtle, is important in relation to the distinction we want to make in terms of graph-based signal processing and graph-based machine learning.
  \end{itemize}
\item
  Data collected from sensors from time \(t_i\) to time \(t_k\) (both forms):
  \(\vec{{C}}^{t_i:t_k}\) {[}Euclidean{]} and
  \(\mathcal{C}^{t_i:t_k}\) {[}non-Euclidean{]}
\end{itemize}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Physical Interactions Within the Detector}

\subsubsection{Terminology}

\begin{itemize}
\tightlist
\item
  We shall refer to any particle interacting with any matter within the detector as a \emph{physical interaction}.
\item
  Each physical interaction gives rise to multiple incidences of \emph{measurable luminosity} at the top and the bottom sensors; each measureable luminous incidence at any sensor shall be referred to as a \emph{hit} {[}we may want to iterate over this language a couple of times for the final version; this only needs to be accurate for the purpose of this proposal{]}.
\item
  Hits recorded at multiple sensors within a short time of each other are collectively referred to as a \emph{peak}.
\item
  Multiple peaks recorded within the detector in a short time are collectively referred to as an \emph{event}.

  \begin{itemize}
  \tightlist
  \item
    All evidence for a physical interaction of a particle within the detector is therefore captured in terms of an \emph{event data frame}.
  \item
    In the absence of any background \emph{noise}, each event often results in two major spatiotemporal luminous signals (and thus two peaks), which shall be referred to as S1 (typically weaker and lasting for a much shorter duration) and S2 (typically stronger and having wider spread in time compared to S1) signals.
  \item
    Each event data frame typically corresponds to around \(300\) \(\mu\)s of data.
  \item
    There are typically 20 to 100 events recorded by the detector per second.
  \end{itemize}
\end{itemize}

\subsubsection{Notation: High Level}

\begin{itemize}
\tightlist
\item
  Particle type that interacts:
  \(w \in W\)
  {[}\(\w\) is a variable that can be a WIMP, a neutrino, etc., and \(W\) is all possible particles; unknown{]} \todo{I changed $\gamma$ to $w$ since $\gamma$ is the gamma ray particle.  Actually, every greek symbol is a particle.}

\item
  Interaction type:
  \(\xi \in \Xi\)
  {[}\(\xi\) is a variable that can, e.g., indicate elastic electronic recoils, elastic nuclear recoils, or other processes such as inelastic nuclear excitation, and \(\Xi\) is all possible interactions; unknown; {\color{blue}\LaTeX~commands are \verb|\xi| for $\xi$ and \verb|\Xi| for $\Xi$}{]}

\item
  Spatial location of particle interaction within the detector:
  \(\vec{l} \in \Omega \subset \mathbb{R}^3\) {[}unknown{]}

  \begin{itemize}
  \tightlist
  \item
    It is best to stick to the terminology of \emph{location} and \emph{localization}, rather than position.
  \end{itemize}
\item
  Energy associated with the interaction: \(\mathcal{E} > 0\)
  {[}units of keV; unknown; \LaTeX~command is \verb|\mathcal{E}|{]}
\item
  (Analog) time at which interaction took place: \(T \in \mathbb{R}_+\)
  {[}units of ns; can be assumed known; while it can be absolute or relative, we treat it as the Unix Epoch time without loss of generality for computational and practical reasons (i.e., \(T=0\) is the start of 1970 in UTC){]}
\item
  Distinct interactions to be enumerated using an index like \(i\) on top of any of the above quantities: \(i = 1,2,\dots\), with \(i = 1\) being the first interaction recorded by the detector and so forth.
\end{itemize}

\subsubsection{Notation: Low Level (Events, Peaks, and Hits)}

\begin{itemize}
\tightlist
\item
  The \(i\)-th event: \(E_i\) {[}\(i\) can be dropped when referring to a particular event{]}

  \begin{itemize}
  \tightlist
  \item
    Start and end times of \(i\)-th event:
    \(t_0^i\) and \(t_1^i\) {[}\(i\) can be dropped when referring to a particular event{]}
  \item
    Data collected from all sensors corresponding to \(i\)-th event:
    \(\mathcal{C}^i := \mathcal{C}^{t_0^i:t_1^i}\) {[}non-Euclidean{]} and
    \(\vec{C}^i := \vec{C}^{t_0^i:t_1^i}\)
    {[}Euclidean{]} {[}\(i\) can be dropped when referring to a particular event{]}

    \begin{itemize}
    \tightlist
    \item
      Here, non-Euclidean means that the \(248\)-dimensional data at any time \(t\) (corresponding to all sensors) is treated as lying on a graph of \(248\) vertices, where Euclidean means that the data is treated as lying in \(\mathbb{R}^{248}\).
    \end{itemize}
  \end{itemize}
\item
  Peaks associated with the \(i\)-th event:
  \(\pi_1^i, \dots, \pi_k^i\) {[}\(i\) can be dropped when referring to a particular event{]}

  \begin{itemize}
  \tightlist
  \item
    Start and end times of \(k\)-th peak within \(i\)-th event:
    \(t_{0,k}^i\) and \(t_{1,k}^i\)
    {[}\(i\) can be dropped when referring to a particular event{]}
  \item
    Data collected from all sensors corresponding to \(k\)-th peak within \(i\)-th event:
    \(\mathcal{C}^{\pi_k^i} := \mathcal{C}^{t_{0,k}^i:t_{1,k}^i}\) {[}non-Euclidean{]} and
    \(\vec{C}^{\pi_k^i} := \vec{C}^{t_{0,k}^i:t_{1,k}^i}\) {[}Euclidean{]}
    {[}\(i\) can be dropped when referring to a particular event{]}
  \end{itemize}
\item
  Hits associated with \(j\)-th sensor, \(k\)-th peak, and \(i\)-th event:
  \(h_1^{j,\pi_k^i}, \dots, h_m^{j,\pi_k^i}\) {[}\(i\) can be dropped when referring to a particular event{]}
\end{itemize}

\subsubsection{Notation (Other Variables)}

\begin{itemize}
\tightlist
\item
  There are a number of other derived quantitative data available to us, which we cannot possibly discuss in the proposal. Any variable that is not explicitly defined will be lumped into auxiliary variables \(\theta\).
\end{itemize}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Physical Forward Model}

\subsubsection{Terminology}

\begin{itemize}
\tightlist
\item
  The term \emph{forward model} refers to the mathematical process that relates the physical process (in this case a particle interacting within the detector) to the output data (in this case, event spatiotemporal data corresponding to that interaction).

  \begin{itemize}
  \tightlist
  \item
    This forward model (up to a modeling error; see below) is known to us, but is too complicated to mathematically express in an analytical form. However, it can be generated precisely using numerical simulations.
  \end{itemize}
\end{itemize}

\subsubsection{Notation}

\begin{itemize}
\tightlist
\item
  The relationship between a particle interacting and the event data frame is expressed as follows:
  \[(\vec{C}, t_0, t_1) := \mathcal{F}(\vec{l}, \mathcal{E}, T, \gamma, \xi) + \mathcal{W} + \Delta.\]

  \begin{itemize}
  \tightlist
  \item
    Note that \(t_0\) and \(t_1\) depend on underlying physical properties of the interaction, and hence explicit mention in the above equation (but it can be dropped later).
  \item
    We shall sometimes refer to \(\mathcal{F}(\vec{l}, \mathcal{E}, T, \gamma, \xi)\) as the \emph{noiseless} luminous spatiotemporal data \(\vec{X}\) {[}{\color{blue}\LaTeX~notation: \verb|\vec{X}|}{]}.
  \item
    \(\mathcal{F}(\vec{l}, \mathcal{E}, T, \gamma, \xi)\) is completely known to us through numerical simulations (formed from an analytical expression, as noted above).
  \item
    Just like in all statistical modeling problems, we cannot model all aspects of the detector's hardware. We capture this model uncertainty in the object \(\Delta\) (of appropriate dimensionality) above.

    \begin{itemize}
    \tightlist
    \item
      Notice the difference between \(\mathcal{W}\), which only models sensor noise, and \(\Delta\), which models other uncertain aspects of our detector.
    \end{itemize}
  \end{itemize}
\end{itemize}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Training Data}

\subsubsection{Terminology}

\begin{itemize}
\tightlist
\item
  In the case of supervised learning, labeled training data will be generated using numerical simulations.

\item
  In the case of unsupervised learning, unlabeled training data will be generated through both numerical simulations and real experiments.
\end{itemize}

\subsubsection{Notation}

\begin{itemize}
\tightlist
\item
  Supervised learning: We will have access to \(N\) labeled data (at the physical interaction/event level) generated through simulations, expressed as
  \(\{\vec{C}^{i}, (\vec{l}^{\,i}, \mathcal{E}^i, T^i, \gamma^i, \xi^i)\}_{i=1}^N\)
  {[}note that the start and end times of each event \(i\) are being implicitly encoded in the size of \(\vec{C}^i\); also, use {\color{blue}\LaTeX\ code \verb|\vec{l}^{\,i}| for \(\vec{l}^{\,i}\), as it appears as \(\vec{l}^i\) without the \verb|\,| space}{]}

  \begin{itemize}
  \tightlist
  \item
    We will use the shorthand notation \(\mathcal{L}^i := (\vec{l}^{\,i}, \mathcal{E}^i, T^i, \gamma^i, \xi^i)\) to capture the entire \emph{labeled tuple} \((\vec{l}^{\,i}, \mathcal{E}^i, T^i, \gamma^i, \xi^i)\) into one quantity {[}{\color{blue}\LaTeX\ command is \verb|\mathcal{L}|}{]}
  \end{itemize}
\item
  Unsupervised learning: We will have access to \(N\) unlabeled data (at the event level) generated through both simulations and real experiments, expressed as \(\{\vec{C}^i\}_{i=1}^N\)

  \begin{itemize}
  \tightlist
  \item
    We will use \verb|\widehat{}| to distinguish between data and labels from numerical simulations versus real experiments; e.g., \((\vec{\widehat{C}}^i,\widehat{\mathcal{L}}^i)\) [data/labels from numerical simulations] versus \((\vec{\widehat{C}}^i,\mathcal{L}^i)\) [data from real experiments]
  \end{itemize}
\item
  Experimental data has $(\vec{l}^{\,i}, \mathcal{E}^i, T^i, \gamma^i, \xi^i)$ unknown or partially known (e.g., just  $\mathcal{E}^i$), but we may know the statistical properties of the data. For example, the probability density function $f(\vec{l}^{\,i})$ may be known.  The probability  $\Pr [a \le X \le b] = \int_a^b f_X(x) \, dx$.  For example, if $f$ is normally distributed then $f(x) = \frac{1}{\sqrt{2\pi}}\; e^{-x^2/2}$.
\end{itemize}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Other Terminology}

\begin{itemize}
\tightlist
\item
  Our algorithms are both \emph{data science and machine learning algorithms}. In the interest of pithiness, we will sometimes only use the term \emph{data science}, which will subsume \emph{machine learning} within it {[}we shall say something like this explicitly in the proposal{]}.
\item
  Our approach can be called many different things and we should stick to \textbf{Science-aware data science and machine learning}.

\end{itemize}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Other Notation}

\begin{itemize}
\tightlist
\item
  Our sensor data have a graph structure, given by: \(\mathcal{G} = (\mathcal{V}, \mathbf{A})\), with \(\mathcal{V} = \{0,\dots,n-1\}\) representing the sensors and \(\mathbf{A}\) representing a weighted adjacency matrix.
\end{itemize}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Other Auxiliary Information}

\begin{itemize}
\tightlist
\item
  Digitizers generate 14-bit unsigned data (positive valued data).
\item
  Location reconstruction accuracy should be \(\pm 5\) mm or less; another important goal is very restrictive confidence intervals (methods with very small standard deviation).  Said differently, as this is a rare event search, it is better to have a resolution of 1 cm and no mismeasurement of 10 cm than a resolution of 1 mm with occasional 10 cm misreconstruction.  Current state of the art is a few mm to 1 cm, but these are hard to verify since people quote average L1 loss.
\item
  Energy reconstruction accuracy should be \(\pm 0.5\%\) or less (ideally smaller than this).  The current state of the art is 1.2\% from EXO.  NEXO aims for 0.5\%.  The statistical limit is 0.3\%.
\end{itemize}

\end{document}


\section{First section of the second chapter}
This is the text of the second chapter. \cite{*}

\appendix
\section{This is an appendix section}
Text of the appendix

\subsection{Subsection 1}
Yet some text, and an equation
\begin{equation}
    \textnormal{abs}\left(e^{j\pi}\right)=\,?
\end{equation}

\subsection{Subsection 2}
And then some...

\section{This is another appendix section}
This section concludes the appendix.


\documentclass{stdlocal}
\begin{document}
\section{Design of the Library Interface} % (fold)
\label{sec:design_of_the_api}
  The design of a library API using various vectorized PRNGs consists of several parts, as can be seen in figure \ref{fig:api-parts}.
  To exploit the statistical properties of all the implemented generators proper seeding routines have to be provided.
  Seeding of PRNGs should be easy but not magically hiding important information, like the RNG that is used for the initialization.
  The implementation of the MT19937 given by \code{std::mt19937} in the STL of the C++ programming language for example, internally uses an easier PRNG to initialize its whole state vector by only one truly random number \autocite{gcc-libstdcpp}.
  The interface of \code{std::mt19937} does not show this information to the programmer or the reader and even forces the user of the library to employ this process.
  Furthermore, a generator \code{RNG} only used for seeding will typically be constructed directly as an rvalue in the constructor of the \code{std::mt19937}.
  \[
    \text{\code{std::mt19937 rng\{RNG\{\}()\};}}
  \]
  Because we cannot use the complete RNG as an argument, we first have to make sure that we call the advancing routine of the seeding generator.
  This behavior reduces the statistical performances of the initialization and complicates the interface even more by adding an extra pair of parentheses.

  \begin{figure}[b]
    \center
    \includegraphics[width=0.95\textwidth]{figures/api_parts.pdf}
    \caption[Main Parts of the API Design]{
      Main parts to be considered for a software library that is providing access to scalar and vectorized PRNGs.
      The arrows show possible interactions between different parts for which convenient interfaces should be created.
      In this thesis, algorithms will not be considered.
    }
    \label{fig:api-parts}
  \end{figure}

  Other parts we have to deal with are fast and easy-to-use distributions for RNGs to at least generate uniform random numbers.
  The current C++ standard supplies different distributions in the form of functor templates that use the same algorithm for all generators by templatizing their function operators.
  \[
    \text{\code{std::uniform\_real\_distribution<float> dist\{\}; auto x = dist(rng);}}
  \]
  This API design consists of two major drawbacks.
  The user always has to first construct the object of the according distribution type and afterwards using its function operator to actually get a random number that fulfills the conditions of the distribution.
  Hence, even for simple use cases an API overhead emerges by utilizing random numbers via the STL of C++.
  The second problem is that every RNG has to use the same distribution routine which may not be optimized to work well with a given generator.
  Especially for uniformly distributed random numbers, some generators can exploit the implementation of their transition and generator function to achieve better performance.
  But in C++, we are not able to specialize the function operator template in a distribution functor from the outside.
  The approach does not scale well with the number of different RNGs.

  In the last few years, there has been some development in the area of API design for RNGs.
  \textcite{oneill-blog-api,oneill-blog-rd,cpp-std-seeding,cpp-std-random}, to name a few.
  They provide perfect basic ideas to improve the usage of random utilities in the C++ language.
  We will rely on this work and go a step further.
  We strive for a transparent API that can be used easily with different seeding alternatives.
  Nearly every RNG should be available as a source for seeding another RNG.
  In addition, uniform distribution functions will be introduced that do not need to be called as functor objects.
  Through template meta programming, we give generators the possibility of specializing such helper functions through member functions of the same name.
  This idea makes it even possible to specialize these functions outside of the RNG structure for a non-intrusive adjustment.
  Furthermore, by providing these functions we keep compatibility to the standard distributions.

  % \subsection{Concepts} % (fold)
  % \label{sub:prng_concept}
    We do not want to introduce a lot of overhead to the design concept of PRNGs and vectorized PRNGs.
    The compiler should automatically find out which algorithm to use.
    This can be done by specialization according to the result type of the function operator.
    If this should be not sufficient, tag dispatching can be used as an alternative \autocite{vandevoorde2018}.
    The output of a PRNG could have arbitrary size but will always interpreted as a bit stream of finite length.
    For example, an AVX register would be a 256-bit stream of random bits in this sense.
    This will explains how to interleave SIMD streams and how to test them.

    Interfaces for SIMD intrinsics will always be specialized templates even for wrapper classes because SIMD is behaving differently to SISD architectures.
    If we are working with an SIMD vector the least surprising interface is to use the SIMD vector as result type directly.
    Through inheritance we or someone from the outside could add another interface by using wrapper classes without changing the implementation.
    Therefore seeding will be a specialized routine as well.
  % subsection prng_concept (end)

  \subsection{Template Utilities} % (fold)
  \label{sub:utilities}
    The ideas for the API given above require us to rely on the template meta programming facilities C++ provides.
    In general, we would like to use helper functions, as well as member functions for specific tasks, like generating a vector of random numbers.
    If a generator provides a member function the helper function should use the given specialization whereas otherwise a default algorithm should be used.
    Hence, at compile-time we need to evaluate if calling a specific member is a valid expression.
    In \textcite{vandevoorde2018}, there is a given technique that allows us to evaluate the validity of expressions.

    \inputCodeBlock[title = Is-Valid Utility]{code/is_valid.hpp}
    This code highly makes use of template meta programming artifacts, like SFINAE and type traits.
    To be precise, it uses an overloaded variadic helper function template \code{detail::is\_valid} to decide if the call of a specific function type \code{F} with the varying amount of argument types \code{Args} would be a valid call.
    The call is put into an unevaluated context by using the \code{std::declval} template utility from C++ which is able to return an object of a class without specific constructors in such an unevaluated context.
    To decide the validity of this statement it relies on a default template parameter and the \code{decltype} utility of the C++ language.
    If the call to the given function object would be possible, \code{decltype} will indeed deduce the return type of the function call and correctly set the default template argument.
    In this case, the first overload would be chosen so that the return type of \code{detail::is\_valid} would be \code{std::true\_type}.
    In all other cases, the second overload with the return type \code{std::false\_type} would be activated because due to SFINAE the first overload would not be taken into account.
    We have to make sure to decide on the validity with the generalized boolean types \code{std::true\_type} and \code{std::false\_type} from the STL of C++ because we will use the given templates in unevaluated contexts where no evaluation of an actual \code{bool} variable would be possible.

    The routine \code{is\_valid} is actually a lambda expression that returns another lambda expression which is then evaluating the validity of its arguments by the helper template \code{detail::is\_valid}.
    The function object \code{f} will be a lambda expression that lists conditions for abstract types which have to be valid to fulfill the concept we want to define.
    The arguments \code{args} will then be the actual variables to be inserted in the pattern test of \code{f}.
    The two interleaved lambda expressions separate the function object \code{f} from its varying amount of arguments \code{args} for convenience.
    Additionally, they allow us to use variables in unevaluated contexts.

    To better understand the utility, we will directly apply it to construct a helper function template \code{generate} which is calling \code{std::generate} from the STL of C++ for a given RNG as a default.
    But as a specialization we would like to call the member function with the same name of the generator if it exists.
    We do this again through the use of SFINAE.

    \inputCodeBlock[title = Generate Utility]{code/generate.hpp}
    First, we are defining a general pattern \code{has\_generate} based on \code{is\_valid} to be able to decide the validity of the expression \code{x.generate(y,z)} for arbitrary types by using a lambda expression.
    Again, we have to make sure the lambda expression is deducing its return in an unevaluated context.
    Hence, \code{decltype} is used as a trailing return type with the pattern to evaluate.
    Next, we declare an overloaded helper function template \code{generate}.
    SFINAE is applied for overload resolution by using \code{std::enable\_if\_t} in the return type of the functions.
    In the template argument, we use the general pattern \code{has\_generate(rng,first,last)} and deduce its type by \code{decltype}.
    The type will either be \code{std::true\_type} or \code{std::false\_type}.
    In the first case, \code{std::enable\_if\_t} will be evaluated to be the type \code{void}.
    In the other case, \code{std::enable\_if\_t} will be no valid type and the function will not be taken into account in the overload resolution.
    The overloads of \code{generate} use complementary conditions in the template argument of \code{std::enable\_if\_t}, so that at all times only one of them will be available in the overload resolution.
    As a result, \code{generate(rng,first,last)} will call \code{rng.generate(first,last)} if the type of \code{rng} provides the named member function and \code{std::generate(first,last,std::ref(rng))} otherwise.
  % subsection utilities (end)

  \subsection{Seeding Mechanism} % (fold)
  \label{sub:seeding}
    Seeding of RNGs through the use of other RNGs will be accomplished by the use of perfect forwarding.
    In contrast to the ideas in \textcite{cpp-std-seeding}, we allow for rvalue initialization making the API simpler.
    Consider the following code snippet that introduces an arbitrary RNG type \code{rng\_type}.

    \inputCodeBlock[title = Seeding Strategy]{code/seeding.hpp}
    \code{rng\_type} is a structure with an explicit forwarding constructor available for seeding which is able to match any other RNG type.
    Please note the typical usage of a universal reference to deduce forwarding types.
    The implementation of the constructor should call either the \code{generate} method or the function operator of the given RNG type to initialize its own state.
    For a few exceptional cases, the given code can lead to certain artifacts in the template deduction process.
    This behavior is discussed in \textcite[\ppno~188-197]{meyers2014}.
    For RNGs, there is typically no need to provide an extra degree of type security.
    But we can easily add it through the use of \code{std::enable\_if\_t} to turn on the SFINAE process.

    \inputCodeBlock[title = Advanced Seeding Strategy]{code/seeding_advanced.hpp}
    This implementation removes the explicit forwarding constructor for seeding when we want to copy or move the state of the structure itself.
    For the implementations of PRNGs, we have tested both variants and could not spot any differences.
    Hence, further we will use the simpler variant.
    According to \textcite{vandevoorde2018}, in the future of C++ concepts will be available which will make such an initialization artifact even simpler and more efficient.
  % subsection seeding (end)

  \subsection{Uniform Distribution Functions} % (fold)
  \label{sub:distributions}
    The design of a uniform distribution \code{uniform} via helper functions and member specializations will be handled the same way as for the function template \code{generate}.
    This time, we only have to take care of additional overloads.
    By calling \code{uniform} without function arguments, we have to provide the return type as a template argument.
    For floating-point types, the result should be a number in the interval $[0,1)$.
    Specifying integer number types, the output is a value of the complete range of the template argument.
    If we call \code{uniform} with additional arguments specifying the range of the output, we are able to use template argument deduction for the return type based on the range arguments.
    We separate those two cases to further optimize the frequently used first function call without arguments.
    % The following code shows the implementation.

    \inputCodeBlock[title = Uniform Template Is-Valid Patterns]{code/uniform_patterns.hpp}
    We use two \code{is\_valid} patterns to describe the existence of \code{uniform} member functions with and without additional arguments.
    The actual \code{uniform} functions then use the same overload resolution via SFINAE as the \code{generate} function.

    \inputCodeBlock[title = Uniform Template]{code/uniform.hpp}
    The result type of the Mersenne Twister \code{std::mt19937} from the STL is given by \code{uint\_fast32\_t} which, on modern machines, will evaluate to \code{uint64\_t} with $64\appendUnit{bit}$ size instead of the used $32\appendUnit{bit}$.
    Because the uniform distribution utilities that we will provide in the implementation use their argument types to overload themselves, the Mersenne Twister would call the wrong function.
    We can prohibit this behavior without changing the inner structure of the \code{std::mt19937} type by creating another helper function overload especially for the Mersenne Twister.
    In this implementation, we are making sure its return type will be casted to the \code{uint32\_t} type.

    \inputCodeBlock[title = Uniform MT19937 Overload]{code/uniform_mt19937.hpp}
    The defined API gives us the ability of a powerful default distribution together with the possibility of specializing it for some generators through member functions.
    If we cannot access the inner structure of an RNG then we may even insert slightly more complicated helper specializations to adjust the output of RNGs which are not created by the programmer itself.
  % subsection distributions (end)

  % \subsection{Algorithms} % (fold)
  % \label{sub:algorithms}

  % subsection algorithms (end)
\end{document}


\documentclass[11pt,twoside,twocolumn,a4paper]{article}

\usepackage{acvrw}
\usepackage{times}
\usepackage{epsfig}
\usepackage{graphicx}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{url}
\usepackage{float}

\newcommand\scalemath[2]{\scalebox{#1}{\mbox{\ensuremath{\displaystyle #2}}}}

%%%%%%%%%%%%%%%
%% FINAL COPY %
%%%%%%%%%%%%%%%

% !!! UNCOMMENT THIS LINE FOR THE FINAL SUBMISSION !!!
% \acvrwfinalcopy

\def\acvrwPaperID{20} % *** Enter the ACVRW Paper ID here
\def\httilde{\mbox{\tt\raisebox{-.5ex}{\symbol{126}}}}

% Pages are numbered in submission mode, and unnumbered in camera-ready
\ifacvrwfinal\pagestyle{empty}\fi
\begin{document}

%%%%%%%%%
% TITLE %
%%%%%%%%%
\title{Object Tracking Robot using Stereo Vision}

\author{Nicolai Schwartze, Johannes Wüstner\\
FH Vorarlberg University of Applied Science\\
{\tt\small \{nicolai.schwartze,johannes.wuestner\}@students.fhv.at}
}

\maketitle
\ifacvrwfinal\thispagestyle{fancy}\fi

%%%%%%%%%%%%
% ABSTRACT %
%%%%%%%%%%%%

\begin{abstract}
This paper originates from a coursework done in the module Applied Robotics at the Vorarlberg University of Applied Science (FH Vorarlberg). The work is about finding a green laser point on a white flip-board chart. A robot with a 3D camera system tracks this point and drives its laser-pointer tool to the same spot. The premiss was not to use any position controller and instead compute the desired axis-angles from the 3D information of the found laser dot. The paper describes the design and the implementation of the system.
\end{abstract}

%%%%%%%%%%%%%
% BODY TEXT %
%%%%%%%%%%%%%

%-------------------------------------------------------------------------
\section{Task Constrains}

The following requirements were posed to fulfil this coursework:
\begin{itemize}
\item Create a 3-axis robot and not a simple two-axis pan/tilt device.
\item Measure the 3D point of the laser and drive to its position without using a closed loop controller.
\end{itemize}

%-------------------------------------------------------------------------
\section{Design}

The robot consists of 3 Dynamixel MX-64AT motors, two Microsoft Lifecam HD 3000 (640x480 pixel) and a laser-pointer.
Aluminium frames are attached to the motors to build the framework of the robot. The cameras and laser-pointer are connected with aluminium brackets. The design of the robot and its components is established with SolidWorks.
Figure \ref{fig:3d-render} shows a 3D render of the fully assembled robot.

\begin{figure}[h]
	\centering
	\includegraphics[width=0.3\columnwidth]{images/robot_3D_side.pdf}
	\caption{3D render of the assembled robot}
	\label{fig:3d-render}
\end{figure}

%-----------------------------------------------------------------------------
\section{Robot Kinematic}

The motors can be controlled by a supplied library, which is written in C \cite{Robotis2019}. This allows us to write our own DLL to implement the backwards kinematics and control the robot as a whole. Figure \ref{fig:robot-axis-coord} shows the coordinate systems that are used to get the link parameters shown in table \ref{tab:link_parameter}. The link parameters are established using the Denavit Hartenberg convention mentioned in \cite[p. 70-79]{Craig2018}.

With the link parameters, the inverse kinematics matrix can be generated. This is used to transfer the 3D point captured by the camera, from the tool frame $\left\lbrace F \right\rbrace$  to the base coordinate system $\left\lbrace 0 \right\rbrace $. From there, the point can be transferred into the coordinate frame $\left\lbrace 3 \right\rbrace $. This transformation is implicitly included in equation (\ref{eq:theta2}). Together with (\ref{eq:theta0}) these equations can be used to calculate the desired robot configuration.
Because $\theta_1$ and $\theta_2$ directly depend on each other, $\theta_1$ can be set to any arbitrary angle.

\begin{equation}
\label{eq:theta0}
\theta_0 = arctan \left(  \frac{P_{Y0}}{P_{X0}} \right)
\end{equation}

\begin{equation}
\label{eq:theta2}
\theta_2 = - arctan \left( \frac{ P_{Z0} - 100 - 100 cos(\theta_1)}{\sqrt{P_{X0}^{2} + P_{Y0}^{2}} - 50 - 100 sin(\theta_1)} \right)
\end{equation}

\begin{table}[h]
	\centering
	\begin{tabular}{ | c | c | c | c | c | }
		\hline
		$i$ & $\alpha_{i-1}$ & $a_{i-1}$ & $d_i$ & $\theta_{i-1}$\\
		\hline \hline
		1 & 0 & 0 & 100 & $\theta_0$\\
		2 & -90 & 50 & 0 & $\theta_1 - 90$\\
		3 & 0 & 100 & 0 & $\theta_2 + 180$\\
		F & 90 & 0 & 68 & $0$\\
		\hline
	\end{tabular}
	\caption{link parameter }
	\label{tab:link_parameter}
\end{table}

\begin{figure}[h]
	\centering
	\includegraphics[width=0.35\columnwidth]{images/robot_axis_coord.pdf}
	\caption{axis coordinate systems for computing the inverse kinematic}
	\label{fig:robot-axis-coord}
\end{figure}

%-------------------------------------------------------------------------------
\section{Tool Calibration}
The tool calibration includes three steps: Estimating the camera projection matrix as well as the transformation from the main camera (left in robot sight direction) to the TCP and the transformation of the laser pointer towards the TCP.

\subsection{Hand-Eye Transformation Matrix}
The hand-eye calibration is measured from the real robot. It is assumed, that the rotation between the camera coordinate system and the tool is small. We only have to rotate the coordinate system and take the translation vector into account. Another method would be that of Park and Martin \cite{ParkHandEye} which is also provided in OpenCV.

\begin{figure}[h]
	\centering
	\includegraphics[width=0.3\columnwidth]{images/hand_eye_coord_2.png}
	\caption{axis coordinate systems for computing the backwards kinematic}
	\label{fig:hand_eye_coord}
\end{figure}

\subsection{Laser Calibration}
Since the laser is designed to lay directly in line with the Z-coordinate of the tool frame, there is no calibration needed. This demands a fine level of accuracy for the manufacturing process.

\subsection{Stereo Camera Projection Matrix}

The camera projection matrix is estimated from multiple images of the same chessboard calibration plate \cite[p. 178-182]{Ziss2008}. At first, the intrinsic parameters of both cameras are estimated separately using the OpenCV function \textit{calibrateCamera}. With this information the function \textit{stereoCalibrate} can be used to estimate the translation and rotation between the two cameras. With these matrices and the function \textit{triangulate} a 2D point correspondence can be associated with one 3D point. The camera calibration app is implemented in Python using these OpenCV functions \cite{2014opencv}.

%-------------------------------------------------------------------------
\section{Object Detection}
Two methods for detecting the laser dot are tested.  \\
\textbf{Option 1:} use a HSV-threshold and only look for pixels with that specific value. This method is unstable against different illumination scenarios. \\
\textbf{Option 2:} use template matching with user-defined template. The main idea is to calculate a normalized difference between every pixel in the image and a template \cite[p. 1061-1062]{Gonz2018}. This function is called \textit{matchTemplate} and is also provided by OpenCV. The method \textit{CV\textunderscore TM\textunderscore CCOEFF\textunderscore NORMED} was found to work most reliable for multiple different lighting scenarios. This method uses the equation \ref{eq:template_matching} below, where $T$ stands for the template and $I$ is the image.

\begin{equation}
R(x,y) = \frac{\sum_{x',y'} (T'(x',y') \cdot I'(x + x', y + y'))}{\sqrt{\sum_{x',y'} T'(x',y')^{2} \cdot \sum_{x',y'} I'(x + x', y + y')^{2}}}
\label{eq:template_matching}
\end{equation}

%-------------------------------------------------------------------------
\section{Result and Conclusion}
We can show that the described system works as specified. We find, that template matching is better suited to detect small objects in a constantly changing image rather than searching the images for a specific colour.
Further steps could include to verify the assumption about the orientation of the laser tool as well as refining the hand-eye calibration.

%-------------------------------------------------------------------------{\small
{\small
\bibliographystyle{ieee}
\bibliography{acvrw}
}

\end{document}