text:
\documentclass[12pt]{article}

\addtolength{\textwidth}{1.4in}
\addtolength{\oddsidemargin}{-.7in} %left margin
\addtolength{\evensidemargin}{-.7in}
\setlength{\textheight}{8.5in}
\setlength{\topmargin}{0.0in}
\setlength{\headsep}{0.0in}
\setlength{\headheight}{0.0in}
\setlength{\footskip}{.5in}
\renewcommand{\baselinestretch}{1.0}
\setlength{\parindent}{0pt}
\linespread{1.1}

\usepackage{amssymb, amsmath, amsthm, bm}
\usepackage{graphicx,csquotes,verbatim}
\usepackage[backend=biber,block=space,style=authoryear]{biblatex}
\setlength{\bibitemsep}{\baselineskip}
\usepackage[american]{babel}
%dell laptop
\addbibresource{C:/Users/Kristy/Dropbox/Research/xBibs/tradeagreements.bib}
%\addbibresource{C:/Users/Kristy/Documents/Dropbox/Research/xBibs/tradeagreements.bib}
\renewcommand{\newunitpunct}{,}
\renewbibmacro{in:}{}

\DeclareMathOperator*{\argmax}{arg\,max}
\usepackage{xcolor}
\hbadness=10000

\newcommand{\ve}{\varepsilon}
\newcommand{\ov}{\overline}
\newcommand{\un}{\underline}
\newcommand{\ta}{\theta}
\newcommand{\al}{\alpha}
\newcommand{\Ta}{\Theta}
\newcommand{\expect}{\mathbb{E}}
\newcommand{\Bt}{B(\bm{\tau^a})}
\newcommand{\bta}{\bm{\tau^a}}
\newcommand{\btn}{\bm{\tau^n}}
\newcommand{\ga}{\gamma}
\newcommand{\Ga}{\Gamma}
\newcommand{\de}{\delta}

\begin{document}
\begin{center}
Literature on Asymmetric Punishments
\end{center}

New section on asymmetric punishments (addresses, in part, Giovanni's $\#$7)
\begin{itemize}
	\item Constrain to $T$-period class, now asymmetric---punish deviator more
	\item There is literature on this
		\begin{itemize}
			\item Bown 2002/2004
				\begin{itemize}
					\item Shocks, no enforcement
					\item Distinction is between legal and illegal
						\begin{itemize}
							\item Legal: TOT terms cancel, local effect only
							\item Illegal: TOT effect + local effect
						\end{itemize}
				\end{itemize}
			\item Beshkar 2010 EER (a)
				\begin{itemize}
					\item truthful revelation, no transfers, one shot
					\item asymmetry in size of punishment: compensation award through tariffs doesn't have to be as big as initial harm in order to induce truthful revelation
				\end{itemize}
			\item Beshkar 2010 JIE (b)
				\begin{itemize}
					\item GATT's instantaneous reciprocity rule (p. 39): immediate suspension of concessions under GATT escape clause
					\item 4 years with no retaliation under WTO Agreement on Safeguards
					\item No asymmetry as far as I can see on quick skim
				\end{itemize}
			\item Martin and Vergote
				\begin{itemize}
					\item Private info (random shock to import-competing sectors), no transfers, repeated game
					\item Retaliation is the cost for overstating one's own value of $\ga$--it's what delivers incentive compatibility
					\item Distinction is between reciprocity and retaliation
						\begin{itemize}
							\item Reciprocity: higher contemporary tariff (they have pre-play communication in a mechanism design framework)
							\item Retaliation: higher tariffs in the future
						\end{itemize}
					\item In contrast to Riezman 1991 (who has symmetric equilibria \`{a} la Green and Porter and then necessarily lower welfare), they have the same welfare level in punishment, just redistributed across players
						\begin{itemize}
							\item My note: this has flavor of the two different types of renegotiation issues: move inside the frontier or along it
						\end{itemize}
					\item They have an optimal level of asymmetry
					\item They show that asymmetry is necessary to deliver the efficient outcome (FLM Folk Theorem)
				\end{itemize}
			\item Hungerford 1991
				\begin{itemize}
					\item Asymmetric shocks, TOT is signal, NTBs
					\item Retaliation by going to optimal tariff level
					\item Retaliatory period: one country retaliates for past defection, defecting country plays BR (defect before other country can react)
					\item GATT (p. 364)
						\begin{itemize}
							\item Add cost of retaliation, but fast so retaliation starts in period $t+1$ for trigger in period $t$
							\item Investigation is domestic (hence cost), but must ``detect'' NTB in order to punish
							\item Countries don't spend enough on investigation to discourage NTBs entirely because they can't always detect them
						\end{itemize}
				\end{itemize}
			\item Riezman 1991
				\begin{itemize}
					\item Symmetric punishments
				\end{itemize}
			\item Bagwell (2008): commensurate vs. disproportionate retaliation
				\begin{itemize}
					\item disproportionate retaliation can compensate trading partner, who otherwise loses trade volume
					\item here, degree of disproportion increases in size of original violation: has to compensate for larger trade volume loss (p.15 of pdf)
				\end{itemize}
			\item Bagwell 2009: shocks are persistent
			\item Furusawa 1999: larger $\delta$ not always beneficial (fn 46, p. 42 of BBS lit review)
				\begin{itemize}
					\item Context: comparing the $\de_i$ of two different countries, which one is in a stronger negotiating position
					\item Repeated game, first stage of Rubinstein bargaining, then repeated interaction to support agreed-upon tariffs
						\begin{itemize}
							\item Rubinstein bargaining / asymmetric Nash bargaining that is its limit captures effect of difference in players' patience levels on their bargaining power and therefore the bargaining outcome
							\item ``On one hand, patience pays in the negotiation phase since it enhances bargaining power. On the other hand,
impatience pays in the implementation phase, since the resulting greater incentive to defect enables a government to claim a larger share of the fruits of cooperation. We find that the former effect outweighs the latter if the time lag between a defection and punishment in the implementation phase is short, and vice versa.''
							\item ``Kovenock and Thursby (1992) incorporate in their model that the GATT dispute settlement procedures may delay punishment. The US super 301, on the other hand, can be viewed as shortening the response lag''
							\item ``We also show in Section 5 that the basic model can be applied to the case in which a deviation from cooperation is detected with uncertainty, by merely replacing the response lag in the implementation phase with the expected delay to a detection. We find that an improvement of monitoring technology enhances the relative bargaining position of the relatively more patient country.''
						\end{itemize}
				\end{itemize}
			\item Ludema 2001
				\begin{itemize}
					\item I like the way he states the agreement / punishment path (p. 362)
					\item Nash tariffs for punishment with DSP; autarky for no DSP, so not asymmetric
				\end{itemize}
			\item Cotter and Mitchell 1997
				\begin{itemize}
					\item Focuses on renegotiation-proofness
					\item Countries initially negotiate a treaty that specifies particular agreement tariff levels and particular punishment tariff levels to be used if either country violates the agreement
					\item The one-period Nash equilibrium will not support a renegotiation-proof tariff agreement. Although the simple punishment strategies used here are more general than those used in most earlier papers, they are still not completely general, since, for example, the duration and severity of the punishment do not vary with the seriousness of the violation.
					\item We have been forced to simplify some of the institutional features of international trade agreements. First, we ignore lags in punishment. It is possible for countries to violate the trade agreement and avoid punishment within the WTO as long as they repent before the punishment begins (Mitchell, 1997). As a result, the modeling of punishments has been purposefully general enough to cover all types of punishment, including those not sanctioned by the WTO. We also simplify the dispute settlement procedures by specifying particular punishments for each country ahead of time, as part of a trade treaty.
					\item We expect that punishments will not harm the punishing country, unless that is unavoidable, in which case they will be as short as possible
					\item simple punishment strategy: three different tariff combinations are specified in advance: one to use during regular periods, one to use when punishing home, and one to use when punishing foreign. Punishment phases last a fixed number of periods: $T_h$ for Home, $T_f$ for Foreign.
						\begin{itemize}
							\item They also have a nice description of the strategies on p. 353-354
						\end{itemize}
					\item There is a lot more here, but it's mixed up with renegotiation; big thing that I can see easily is that the punishments \textit{can} be asymmetric in the tariff levels as well as the length
				\end{itemize}
		\end{itemize}
	\end{itemize}
\end{document}


text:
\chapter{achieved results}
\label{ch:results}

% Povinné pro rigorózní práci, 3-5 stran.

In my research, I focus on the design of self-contained abstraction for program
verification. The main objective of this design is to determine how to refactor
abstraction out of dynamic analysis and still provide sufficient information
for program state-space exploration. In my work, I propose to let the program
under test take care of abstraction and maintain abstract data. This can be
achieved by instrumentation of abstract operations directly into the program.
As consequence, the verifier does not need to perform abstract interpretation,
but it can only perform a~concrete interpretation of the program and obtain
abstract data from the program memory if it needs them.

In the previous chapter, I have stated multiple alternatives of how much of the
abstract interpretation is instrumented into the program and retained in the
interpreter.  As a reasonable boundary for reusable abstraction, I have
selected a design where metadata and decision procedure are part of the
execution engine (see \autoref{fig:bounds}). This choice balances an effort
required to integrate the transformation-based technique and load on execution
engine, where the instrumented code needs to be interpreted.

Up until now, I have focused on the general design of trans\-for\-mation-based
abstraction without refinement (\emph{trivially constrainable domains}). The
main concern of the first prototype was to design a general-purpose analyses
for instrumentation. The goal of these transformations was to allow coexistence
of concrete and abstract values in a single program. In this way, I was able to
extend \divine the model checker~\cite{Divine17} with symbolic
computation~\cite{Lauko2019Sym, Lauko2018SymComp} and support of abstract
representation of strings~\cite{Lauko2019String}. Model checker \divine suits
well for presented analyses because of its support of required
non-deterministic execution of \llvm programs. Turn: in turn, the
transformation-based abstraction provides abstraction support for the model
checker without complicating its core \llvm interpreter.

All analyses presented in my up-to-date work are implemented in a~tool named
\lart{} -- \llvm abstraction and refinement tool, that is a~part of the \divine
project. \lart is based on top of the open-source \llvm compiler
infrastructure. It allows \lart to easily integrate program analyses,
transformations, and other tools that target \llvm.

\section{Transformation-based abstraction}
\label{sec:symbolic}

\subsection{Abstraction design}

The overall symbolic abstraction, depicted in \autoref{fig:design}, consists of
two parts: preprocessing (\emph{static analysis}), which performs
instrumentation of abstraction into the program; and verification
(\emph{dynamic analysis}) that explores the state space of the system under
test.

The instrumentation performs data-flow analysis of non-de\-ter\-ministic values and
replaces operations on them by their abstract counterparts. The instrumented
program is subsequently linked with a library that implements abstract
operations and provides definitions of abstract data representation.

During verification, virtual machine (\textsc{vm}) executes the abs\-trac\-ted
program and generates state space for a model checking algorithm (\textsc{mc}).
The model checking algorithm obtains symbolic data and path condition directly
from program memory, whenever it needs to decide whether the state is feasible
or is equal to some previously visited state. An external \textsc{smt} solver solves
feasibility and equality queries. Notice that the virtual machine has no knowledge
about abstract values present in the program.
However, it needs to recognize which parts of the memory contains abstract data,
because they can not be compared explicitly when the model checker is
determining equality of states. Therefore, the virtual machine keeps metadata
that denotes which parts of memory hold abstract values.

\begin{figure}
    \centering
    \input{img/approaches.tikz}
    \caption{Components of symbolic computation in \divine.}
    \label{fig:design}
\end{figure}

\subsection{Term domain}

The abstract domain used for the symbolic computation was inspired by the
domain of uninterpreted functions~\cite{Gange2016} -- we call it a term domain.
In the term domain, arithmetic operations are composed into term trees (data
definitions) that represent relations between ground variables and constants,
whereas the branching conditions extends the global path condition.  For
further details, see papers in the attachments of the thesis
proposal~\cite{Lauko2018SymComp, Lauko2019Sym}.

\section{String abstraction}
\label{sec:string}

My following publication has focused on the extension of the
trans\-for\-ma\-tion-based approach to non-scalar domains (i.e., aggregate
domains).  An example of such a domain is a string domain. In cooperation with
Martina Olliaro, I have adapted her string domain
(\textsc{mstring})~\cite{Olliaro2018} as \lart domain. A \lart domain is a C or
C++ library that provides definitions of abstract values and implementation of
supported operations on them.

\textsc{Mstring} domain represents C strings by segmentation abstract domain
that keeps track of terminal zeros in the underlying array. It is
a~parametrizable domain in the means of array segments\sidenote{Array segment
represents a consecutive area of the same characters.} length and array
content.  Hence, we have repurposed a symbolic domain from previous work to
abstract lengths of string segments.

To support aggregate domains in \lart, I have adapted its data-flow analysis to
carry multiple domains at the same time, as well as to be able to analyze
manipulations with \llvm arrays. Moreover, I have extended the instrumentation
to support abstraction of larger operations than just \llvm instructions --
these occur in C string manipulating programs in the form of library functions
(\texttt{strlen}, \texttt{strcmp}, \texttt{strcat}). The transformation-based
string abstraction is further presented in the attached paper
~\cite{Lauko2019String}.

\section{Publications}
\label{sec:publications}

\begin{itemize}

\item \textbf{\emph{Symbolic Computation via Program Transformation}}, by Lauko
H., P. Ročkai and J. Barnat.  In: Theoretical Aspects of Computing -- ICTAC 2018 --
15th International Colloquium, Stellenbosch, South Africa, 2018,
Proceedings, pp. 313--332~\cite{Lauko2018SymComp}

I am the main author of the text of the paper. I have also implemented the
transformation-based abstraction and conducted all the experiments.

\item \emph{\textbf{Extending \textsf{DIVINE} with Symbolic Verification Using SMT}},
by Lauko H., V. Štill, P. Ročkai and J. Barnat.
In: Tools and Algorithms for the Construction and Analysis of Systems -- TACAS 2019 --
25 Years of TACAS: TOOLympics, Prague, Czech Republic, 2019,
Proceedings, Part III. pp. 204--208~\cite{Lauko2019Sym}

I am the primary author of the text of the paper, as well as of the
abstraction implementation. The implementation included an adaptation of \divine
abstraction support to handle \svcomp benchmarks.

\item \textbf{\emph{String Abstraction for Model Checking of C Programs}},
by Cortesi A., H.~Lauko, M. Olliaro and P. Ročkai.
In: Model Checking Software -- SPIN 2019 -- 26th International Symposium~\cite{Lauko2019String}

I am the author of half of the paper content: primarily part concerning
transformation-based abstraction and experiments. I also have concluded
experiments and implemented an abstract string domain and accompanying
\lart analyses.

\end{itemize}

\section{Other publications}

\begin{itemize}

\item \textbf{\emph{Model Checking of C and C++ with DIVINE 4}},
by Baranová Z., J.~Barnat, K. Kejstová, T. Kučera, H. Lauko, J. Mrázek, P. Ročkai and V. Štill.
In: Automated Technology for Verification and Analysis -- ATVA 2017 --
15th International Symposium, Pune, India, 2017,
Proceedings, pp. 201--207~\cite{Divine17}

I am a responsible person for implementation of abstraction and symbolic
computation support in \divine 4.

\item \emph{\textbf{Optimizing and Caching SMT Queries in SymDIVINE}},
by Mrázek J., M. Jonáš, V. Štill, H. Lauko and J. Barnat.
In: Tools and Algorithms for the Construction and Analysis of Systems -- TACAS 2017 --
23rd International Conference, Uppsala, Sweden, 2017,
Proceedings, Part II. pp. 390--393~\cite{Mrazek2017}

I wrote parts of the paper and I have helped with a tool preparation for the
\svcomp competition.

\item \textbf{\emph{\textsf{SymDIVINE}: Tool for Control-Explicit Data-Symbolic State \\ Space Exploration}}
by Mrázek J., P. Bauch, H. Lauko and J. Barnat.
In: Model Checking Software -- SPIN 2016 -- 23rd International Symposium, Eindhoven, The Netherlands, 2016, Proceedings, pp. 208--213~\cite{Mrazek2016}

I have helped with writing of the final paper.

\end{itemize}

domain: tex


text:
% Created by tikzDevice version 0.8.1 on 2015-05-18 11:25:34
% !TEX encoding = UTF-8 Unicode
\documentclass[10pt]{article}
\usepackage{tikz}

\usepackage[active,tightpage,psfixbb]{preview}

\usepackage{fontspec,xunicode}

\PreviewEnvironment{pgfpicture}

\setlength\PreviewBorder{0pt}
\begin{document}

\begin{tikzpicture}[x=1pt,y=1pt]
\definecolor{fillColor}{RGB}{255,255,255}
\path[use as bounding box,fill=fillColor,fill opacity=0.00] (0,0) rectangle (505.89,505.89);
\begin{scope}
\path[clip] (  0.00,  0.00) rectangle (505.89,505.89);
\definecolor{drawColor}{RGB}{255,255,255}
\definecolor{fillColor}{RGB}{255,255,255}

\path[draw=drawColor,line width= 0.6pt,line join=round,line cap=round,fill=fillColor] (  0.00,  0.00) rectangle (505.89,505.89);
\end{scope}
\begin{scope}
\path[clip] ( 43.74, 35.58) rectangle (493.85,477.90);
\definecolor{fillColor}{RGB}{255,255,255}

\path[fill=fillColor] ( 43.74, 35.58) rectangle (493.85,477.90);
\definecolor{drawColor}{gray}{0.90}

\path[draw=drawColor,line width= 0.2pt,line join=round] ( 43.74,109.77) --
	(493.85,109.77);

\path[draw=drawColor,line width= 0.2pt,line join=round] ( 43.74,204.25) --
	(493.85,204.25);

\path[draw=drawColor,line width= 0.2pt,line join=round] ( 43.74,298.73) --
	(493.85,298.73);

\path[draw=drawColor,line width= 0.2pt,line join=round] ( 43.74,393.20) --
	(493.85,393.20);

\path[draw=drawColor,line width= 0.2pt,line join=round] ( 82.00, 35.58) --
	( 82.00,477.90);

\path[draw=drawColor,line width= 0.2pt,line join=round] (260.47, 35.58) --
	(260.47,477.90);

\path[draw=drawColor,line width= 0.2pt,line join=round] (438.95, 35.58) --
	(438.95,477.90);
\definecolor{fillColor}{RGB}{0,0,0}

\path[fill=fillColor] ( 64.20,456.06) circle (  1.07);

\path[fill=fillColor] ( 67.81,457.80) circle (  1.07);

\path[fill=fillColor] ( 71.26,449.58) circle (  1.07);

\path[fill=fillColor] ( 74.55,451.03) circle (  1.07);

\path[fill=fillColor] ( 77.72,444.50) circle (  1.07);

\path[fill=fillColor] ( 80.76,440.66) circle (  1.07);

\path[fill=fillColor] ( 83.68,436.56) circle (  1.07);

\path[fill=fillColor] ( 86.50,440.99) circle (  1.07);

\path[fill=fillColor] ( 89.22,432.31) circle (  1.07);

\path[fill=fillColor] ( 91.85,438.54) circle (  1.07);

\path[fill=fillColor] ( 94.39,429.68) circle (  1.07);

\path[fill=fillColor] ( 96.85,427.78) circle (  1.07);

\path[fill=fillColor] ( 99.24,425.36) circle (  1.07);

\path[fill=fillColor] (101.55,424.42) circle (  1.07);

\path[fill=fillColor] (103.80,414.19) circle (  1.07);

\path[fill=fillColor] (105.98,417.87) circle (  1.07);

\path[fill=fillColor] (108.11,413.98) circle (  1.07);

\path[fill=fillColor] (110.17,417.88) circle (  1.07);

\path[fill=fillColor] (112.19,415.33) circle (  1.07);

\path[fill=fillColor] (114.15,410.51) circle (  1.07);

\path[fill=fillColor] (116.06,404.58) circle (  1.07);

\path[fill=fillColor] (117.93,411.48) circle (  1.07);

\path[fill=fillColor] (119.75,406.20) circle (  1.07);

\path[fill=fillColor] (121.54,406.88) circle (  1.07);

\path[fill=fillColor] (123.28,398.17) circle (  1.07);

\path[fill=fillColor] (124.98,405.82) circle (  1.07);

\path[fill=fillColor] (126.65,395.52) circle (  1.07);

\path[fill=fillColor] (128.28,399.50) circle (  1.07);

\path[fill=fillColor] (129.88,397.46) circle (  1.07);

\path[fill=fillColor] (131.44,396.16) circle (  1.07);

\path[fill=fillColor] (132.98,393.20) circle (  1.07);

\path[fill=fillColor] (134.48,397.10) circle (  1.07);

\path[fill=fillColor] (135.96,388.89) circle (  1.07);

\path[fill=fillColor] (137.41,389.87) circle (  1.07);

\path[fill=fillColor] (138.83,392.46) circle (  1.07);

\path[fill=fillColor] (140.23,393.12) circle (  1.07);

\path[fill=fillColor] (141.60,385.68) circle (  1.07);

\path[fill=fillColor] (142.95,380.83) circle (  1.07);

\path[fill=fillColor] (144.27,380.74) circle (  1.07);

\path[fill=fillColor] (145.58,382.27) circle (  1.07);

\path[fill=fillColor] (146.86,380.24) circle (  1.07);

\path[fill=fillColor] (148.12,384.46) circle (  1.07);

\path[fill=fillColor] (149.36,382.28) circle (  1.07);

\path[fill=fillColor] (150.58,374.30) circle (  1.07);

\path[fill=fillColor] (151.78,381.32) circle (  1.07);

\path[fill=fillColor] (152.96,378.24) circle (  1.07);

\path[fill=fillColor] (154.13,372.67) circle (  1.07);

\path[fill=fillColor] (155.28,374.17) circle (  1.07);

\path[fill=fillColor] (156.41,373.74) circle (  1.07);

\path[fill=fillColor] (157.52,369.64) circle (  1.07);

\path[fill=fillColor] (158.62,374.12) circle (  1.07);

\path[fill=fillColor] (159.71,369.12) circle (  1.07);

\path[fill=fillColor] (160.78,366.22) circle (  1.07);

\path[fill=fillColor] (161.83,374.54) circle (  1.07);

\path[fill=fillColor] (162.87,369.89) circle (  1.07);

\path[fill=fillColor] (163.90,369.96) circle (  1.07);

\path[fill=fillColor] (164.91,372.26) circle (  1.07);

\path[fill=fillColor] (165.91,372.54) circle (  1.07);

\path[fill=fillColor] (166.90,365.18) circle (  1.07);

\path[fill=fillColor] (167.87,366.60) circle (  1.07);

\path[fill=fillColor] (168.84,369.75) circle (  1.07);

\path[fill=fillColor] (169.79,358.52) circle (  1.07);

\path[fill=fillColor] (170.73,360.94) circle (  1.07);

\path[fill=fillColor] (171.66,360.70) circle (  1.07);

\path[fill=fillColor] (172.57,360.25) circle (  1.07);

\path[fill=fillColor] (173.48,357.32) circle (  1.07);

\path[fill=fillColor] (174.38,363.90) circle (  1.07);

\path[fill=fillColor] (175.26,360.88) circle (  1.07);

\path[fill=fillColor] (176.14,357.18) circle (  1.07);

\path[fill=fillColor] (177.00,358.94) circle (  1.07);

\path[fill=fillColor] (177.86,355.73) circle (  1.07);

\path[fill=fillColor] (178.71,357.53) circle (  1.07);

\path[fill=fillColor] (179.55,359.52) circle (  1.07);

\path[fill=fillColor] (180.37,354.90) circle (  1.07);

\path[fill=fillColor] (181.19,354.57) circle (  1.07);

\path[fill=fillColor] (182.01,352.14) circle (  1.07);

\path[fill=fillColor] (182.81,352.95) circle (  1.07);

\path[fill=fillColor] (183.60,358.09) circle (  1.07);

\path[fill=fillColor] (184.39,357.27) circle (  1.07);

\path[fill=fillColor] (185.17,352.99) circle (  1.07);

\path[fill=fillColor] (185.94,350.03) circle (  1.07);

\path[fill=fillColor] (186.71,353.01) circle (  1.07);

\path[fill=fillColor] (187.46,353.36) circle (  1.07);

\path[fill=fillColor] (188.21,349.81) circle (  1.07);

\path[fill=fillColor] (188.95,350.80) circle (  1.07);

\path[fill=fillColor] (189.69,351.24) circle (  1.07);

\path[fill=fillColor] (190.41,350.31) circle (  1.07);

\path[fill=fillColor] (191.14,353.88) circle (  1.07);

\path[fill=fillColor] (191.85,345.39) circle (  1.07);

\path[fill=fillColor] (192.56,349.76) circle (  1.07);

\path[fill=fillColor] (193.26,350.81) circle (  1.07);

\path[fill=fillColor] (193.95,352.74) circle (  1.07);

\path[fill=fillColor] (194.64,349.70) circle (  1.07);

\path[fill=fillColor] (195.33,350.74) circle (  1.07);

\path[fill=fillColor] (196.00,352.89) circle (  1.07);

\path[fill=fillColor] (196.67,341.81) circle (  1.07);

\path[fill=fillColor] (197.34,347.79) circle (  1.07);

\path[fill=fillColor] (198.00,345.80) circle (  1.07);

\path[fill=fillColor] (198.65,348.62) circle (  1.07);

\path[fill=fillColor] (199.30,351.29) circle (  1.07);

\path[fill=fillColor] (199.95,344.51) circle (  1.07);

\path[fill=fillColor] (200.58,344.21) circle (  1.07);

\path[fill=fillColor] (201.22,347.97) circle (  1.07);

\path[fill=fillColor] (201.84,344.99) circle (  1.07);

\path[fill=fillColor] (202.47,348.79) circle (  1.07);

\path[fill=fillColor] (203.08,349.62) circle (  1.07);

\path[fill=fillColor] (203.70,343.99) circle (  1.07);

\path[fill=fillColor] (204.30,346.29) circle (  1.07);

\path[fill=fillColor] (204.91,342.04) circle (  1.07);

\path[fill=fillColor] (205.51,340.26) circle (  1.07);

\path[fill=fillColor] (206.10,340.90) circle (  1.07);

\path[fill=fillColor] (206.69,346.19) circle (  1.07);

\path[fill=fillColor] (207.27,344.52) circle (  1.07);

\path[fill=fillColor] (207.86,342.48) circle (  1.07);

\path[fill=fillColor] (208.43,343.76) circle (  1.07);

\path[fill=fillColor] (209.00,338.20) circle (  1.07);

\path[fill=fillColor] (209.57,340.44) circle (  1.07);

\path[fill=fillColor] (210.13,346.90) circle (  1.07);

\path[fill=fillColor] (210.69,343.10) circle (  1.07);

\path[fill=fillColor] (211.25,340.82) circle (  1.07);

\path[fill=fillColor] (211.80,345.21) circle (  1.07);

\path[fill=fillColor] (212.35,341.49) circle (  1.07);

\path[fill=fillColor] (212.89,340.50) circle (  1.07);

\path[fill=fillColor] (213.43,342.81) circle (  1.07);

\path[fill=fillColor] (213.97,340.42) circle (  1.07);

\path[fill=fillColor] (214.50,341.03) circle (  1.07);

\path[fill=fillColor] (215.03,342.45) circle (  1.07);

\path[fill=fillColor] (215.56,344.00) circle (  1.07);

\path[fill=fillColor] (216.08,339.64) circle (  1.07);

\path[fill=fillColor] (216.60,341.99) circle (  1.07);

\path[fill=fillColor] (217.11,341.90) circle (  1.07);

\path[fill=fillColor] (217.62,341.00) circle (  1.07);

\path[fill=fillColor] (218.13,342.88) circle (  1.07);

\path[fill=fillColor] (218.64,342.07) circle (  1.07);

\path[fill=fillColor] (219.14,334.88) circle (  1.07);

\path[fill=fillColor] (219.64,340.09) circle (  1.07);

\path[fill=fillColor] (220.13,338.71) circle (  1.07);

\path[fill=fillColor] (220.63,339.17) circle (  1.07);

\path[fill=fillColor] (221.11,339.21) circle (  1.07);

\path[fill=fillColor] (221.60,338.37) circle (  1.07);

\path[fill=fillColor] (222.08,336.67) circle (  1.07);

\path[fill=fillColor] (222.56,341.27) circle (  1.07);

\path[fill=fillColor] (223.04,338.48) circle (  1.07);

\path[fill=fillColor] (223.51,332.98) circle (  1.07);

\path[fill=fillColor] (223.99,341.96) circle (  1.07);

\path[fill=fillColor] (224.45,336.15) circle (  1.07);

\path[fill=fillColor] (224.92,338.21) circle (  1.07);

\path[fill=fillColor] (225.38,337.64) circle (  1.07);

\path[fill=fillColor] (225.84,334.57) circle (  1.07);

\path[fill=fillColor] (226.30,334.14) circle (  1.07);

\path[fill=fillColor] (226.75,337.61) circle (  1.07);

\path[fill=fillColor] (227.21,336.80) circle (  1.07);

\path[fill=fillColor] (227.66,341.09) circle (  1.07);

\path[fill=fillColor] (228.10,336.73) circle (  1.07);

\path[fill=fillColor] (228.55,334.37) circle (  1.07);

\path[fill=fillColor] (228.99,333.48) circle (  1.07);

\path[fill=fillColor] (229.43,334.84) circle (  1.07);

\path[fill=fillColor] (229.86,337.16) circle (  1.07);

\path[fill=fillColor] (230.30,331.42) circle (  1.07);

\path[fill=fillColor] (230.73,341.39) circle (  1.07);

\path[fill=fillColor] (231.16,334.21) circle (  1.07);

\path[fill=fillColor] (231.59,331.69) circle (  1.07);

\path[fill=fillColor] (232.01,335.90) circle (  1.07);

\path[fill=fillColor] (232.43,335.36) circle (  1.07);

\path[fill=fillColor] (232.85,333.08) circle (  1.07);

\path[fill=fillColor] (233.27,340.90) circle (  1.07);

\path[fill=fillColor] (233.69,336.21) circle (  1.07);

\path[fill=fillColor] (234.10,331.60) circle (  1.07);

\path[fill=fillColor] (234.51,333.75) circle (  1.07);

\path[fill=fillColor] (234.92,326.88) circle (  1.07);

\path[fill=fillColor] (235.33,328.65) circle (  1.07);

\path[fill=fillColor] (235.73,334.81) circle (  1.07);

\path[fill=fillColor] (236.13,335.15) circle (  1.07);

\path[fill=fillColor] (236.54,330.60) circle (  1.07);

\path[fill=fillColor] (236.93,336.82) circle (  1.07);

\path[fill=fillColor] (237.33,330.41) circle (  1.07);

\path[fill=fillColor] (237.72,333.80) circle (  1.07);

\path[fill=fillColor] (238.12,333.38) circle (  1.07);

\path[fill=fillColor] (238.51,332.14) circle (  1.07);

\path[fill=fillColor] (238.90,331.11) circle (  1.07);

\path[fill=fillColor] (239.28,334.60) circle (  1.07);

\path[fill=fillColor] (239.67,329.96) circle (  1.07);

\path[fill=fillColor] (240.05,329.15) circle (  1.07);

\path[fill=fillColor] (240.43,330.68) circle (  1.07);

\path[fill=fillColor] (240.81,331.77) circle (  1.07);

\path[fill=fillColor] (241.19,329.76) circle (  1.07);

\path[fill=fillColor] (241.56,332.31) circle (  1.07);

\path[fill=fillColor] (241.94,332.68) circle (  1.07);

\path[fill=fillColor] (242.31,327.18) circle (  1.07);

\path[fill=fillColor] (242.68,329.03) circle (  1.07);

\path[fill=fillColor] (243.05,327.55) circle (  1.07);

\path[fill=fillColor] (243.41,330.32) circle (  1.07);

\path[fill=fillColor] (243.78,332.14) circle (  1.07);

\path[fill=fillColor] (244.14,328.59) circle (  1.07);

\path[fill=fillColor] (244.50,325.56) circle (  1.07);

\path[fill=fillColor] (244.86,330.77) circle (  1.07);

\path[fill=fillColor] (245.22,328.09) circle (  1.07);

\path[fill=fillColor] (245.58,330.39) circle (  1.07);

\path[fill=fillColor] (245.93,330.69) circle (  1.07);

\path[fill=fillColor] (246.28,327.19) circle (  1.07);

\path[fill=fillColor] (246.64,325.40) circle (  1.07);

\path[fill=fillColor] (246.99,326.25) circle (  1.07);

\path[fill=fillColor] (247.33,326.46) circle (  1.07);

\path[fill=fillColor] (247.68,328.13) circle (  1.07);

\path[fill=fillColor] (248.03,328.21) circle (  1.07);

\path[fill=fillColor] (248.37,324.55) circle (  1.07);

\path[fill=fillColor] (248.71,325.26) circle (  1.07);

\path[fill=fillColor] (249.05,325.10) circle (  1.07);

\path[fill=fillColor] (249.39,322.29) circle (  1.07);

\path[fill=fillColor] (249.73,323.36) circle (  1.07);

\path[fill=fillColor] (250.07,327.03) circle (  1.07);

\path[fill=fillColor] (250.40,326.70) circle (  1.07);

\path[fill=fillColor] (250.73,328.75) circle (  1.07);

\path[fill=fillColor] (251.07,326.61) circle (  1.07);

\path[fill=fillColor] (251.40,324.23) circle (  1.07);

\path[fill=fillColor] (251.73,323.89) circle (  1.07);

\path[fill=fillColor] (252.05,325.99) circle (  1.07);

\path[fill=fillColor] (252.38,326.12) circle (  1.07);

\path[fill=fillColor] (252.70,325.50) circle (  1.07);

\path[fill=fillColor] (253.03,325.83) circle (  1.07);

\path[fill=fillColor] (253.35,325.26) circle (  1.07);

\path[fill=fillColor] (253.67,322.84) circle (  1.07);

\path[fill=fillColor] (253.99,322.38) circle (  1.07);

\path[fill=fillColor] (254.31,321.79) circle (  1.07);

\path[fill=fillColor] (254.63,322.53) circle (  1.07);

\path[fill=fillColor] (254.94,323.44) circle (  1.07);

\path[fill=fillColor] (255.26,323.18) circle (  1.07);

\path[fill=fillColor] (255.57,323.61) circle (  1.07);

\path[fill=fillColor] (255.88,323.62) circle (  1.07);

\path[fill=fillColor] (256.19,320.76) circle (  1.07);

\path[fill=fillColor] (256.50,322.02) circle (  1.07);

\path[fill=fillColor] (256.81,324.96) circle (  1.07);

\path[fill=fillColor] (257.12,319.70) circle (  1.07);

\path[fill=fillColor] (257.42,320.98) circle (  1.07);

\path[fill=fillColor] (257.73,323.24) circle (  1.07);

\path[fill=fillColor] (258.03,318.33) circle (  1.07);

\path[fill=fillColor] (258.33,322.55) circle (  1.07);

\path[fill=fillColor] (258.63,322.78) circle (  1.07);

\path[fill=fillColor] (258.93,321.65) circle (  1.07);

\path[fill=fillColor] (259.23,321.10) circle (  1.07);

\path[fill=fillColor] (259.53,324.10) circle (  1.07);

\path[fill=fillColor] (259.83,320.01) circle (  1.07);

\path[fill=fillColor] (260.12,322.97) circle (  1.07);

\path[fill=fillColor] (260.42,322.36) circle (  1.07);

\path[fill=fillColor] (260.71,321.76) circle (  1.07);

\path[fill=fillColor] (261.00,321.75) circle (  1.07);

\path[fill=fillColor] (261.29,323.19) circle (  1.07);

\path[fill=fillColor] (261.58,318.59) circle (  1.07);

\path[fill=fillColor] (261.87,319.88) circle (  1.07);

\path[fill=fillColor] (262.16,318.90) circle (  1.07);

\path[fill=fillColor] (262.44,321.20) circle (  1.07);

\path[fill=fillColor] (262.73,317.11) circle (  1.07);

\path[fill=fillColor] (263.01,317.83) circle (  1.07);

\path[fill=fillColor] (263.30,317.46) circle (  1.07);

\path[fill=fillColor] (263.58,318.98) circle (  1.07);

\path[fill=fillColor] (263.86,320.69) circle (  1.07);

\path[fill=fillColor] (264.14,319.36) circle (  1.07);

\path[fill=fillColor] (264.42,314.58) circle (  1.07);

\path[fill=fillColor] (264.70,318.14) circle (  1.07);

\path[fill=fillColor] (264.98,319.25) circle (  1.07);

\path[fill=fillColor] (265.25,317.76) circle (  1.07);

\path[fill=fillColor] (265.53,317.93) circle (  1.07);

\path[fill=fillColor] (265.80,316.99) circle (  1.07);

\path[fill=fillColor] (266.08,316.58) circle (  1.07);

\path[fill=fillColor] (266.35,314.54) circle (  1.07);

\path[fill=fillColor] (266.62,315.38) circle (  1.07);

\path[fill=fillColor] (266.89,316.64) circle (  1.07);

\path[fill=fillColor] (267.16,317.88) circle (  1.07);

\path[fill=fillColor] (267.43,314.28) circle (  1.07);

\path[fill=fillColor] (267.70,314.48) circle (  1.07);

\path[fill=fillColor] (267.96,318.22) circle (  1.07);

\path[fill=fillColor] (268.23,315.55) circle (  1.07);

\path[fill=fillColor] (268.49,315.11) circle (  1.07);

\path[fill=fillColor] (268.76,312.99) circle (  1.07);

\path[fill=fillColor] (269.02,316.79) circle (  1.07);

\path[fill=fillColor] (269.28,316.91) circle (  1.07);

\path[fill=fillColor] (269.54,317.37) circle (  1.07);

\path[fill=fillColor] (269.81,314.49) circle (  1.07);

\path[fill=fillColor] (270.07,315.36) circle (  1.07);

\path[fill=fillColor] (270.32,312.99) circle (  1.07);

\path[fill=fillColor] (270.58,315.22) circle (  1.07);

\path[fill=fillColor] (270.84,312.90) circle (  1.07);

\path[fill=fillColor] (271.10,314.27) circle (  1.07);

\path[fill=fillColor] (271.35,311.45) circle (  1.07);

\path[fill=fillColor] (271.61,311.77) circle (  1.07);

\path[fill=fillColor] (271.86,312.04) circle (  1.07);

\path[fill=fillColor] (272.11,315.37) circle (  1.07);

\path[fill=fillColor] (272.36,312.84) circle (  1.07);

\path[fill=fillColor] (272.62,312.29) circle (  1.07);

\path[fill=fillColor] (272.87,308.39) circle (  1.07);

\path[fill=fillColor] (273.12,310.48) circle (  1.07);

\path[fill=fillColor] (273.36,316.85) circle (  1.07);

\path[fill=fillColor] (273.61,311.72) circle (  1.07);

\path[fill=fillColor] (273.86,310.90) circle (  1.07);

\path[fill=fillColor] (274.11,311.36) circle (  1.07);

\path[fill=fillColor] (274.35,311.95) circle (  1.07);

\path[fill=fillColor] (274.60,309.22) circle (  1.07);

\path[fill=fillColor] (274.84,313.31) circle (  1.07);

\path[fill=fillColor] (275.08,310.92) circle (  1.07);

\path[fill=fillColor] (275.33,312.36) circle (  1.07);

\path[fill=fillColor] (275.57,310.80) circle (  1.07);

\path[fill=fillColor] (275.81,308.12) circle (  1.07);

\path[fill=fillColor] (276.05,306.96) circle (  1.07);

\path[fill=fillColor] (276.29,311.98) circle (  1.07);

\path[fill=fillColor] (276.53,306.46) circle (  1.07);

\path[fill=fillColor] (276.77,310.49) circle (  1.07);

\path[fill=fillColor] (277.00,310.70) circle (  1.07);

\path[fill=fillColor] (277.24,308.52) circle (  1.07);

\path[fill=fillColor] (277.48,305.79) circle (  1.07);

\path[fill=fillColor] (277.71,310.14) circle (  1.07);

\path[fill=fillColor] (277.95,307.78) circle (  1.07);

\path[fill=fillColor] (278.18,304.65) circle (  1.07);

\path[fill=fillColor] (278.41,308.35) circle (  1.07);

\path[fill=fillColor] (278.65,306.41) circle (  1.07);

\path[fill=fillColor] (278.88,305.86) circle (  1.07);

\path[fill=fillColor] (279.11,307.65) circle (  1.07);

\path[fill=fillColor] (279.34,305.16) circle (  1.07);

\path[fill=fillColor] (279.57,306.16) circle (  1.07);

\path[fill=fillColor] (279.80,306.86) circle (  1.07);

\path[fill=fillColor] (280.03,302.38) circle (  1.07);

\path[fill=fillColor] (280.25,302.99) circle (  1.07);

\path[fill=fillColor] (280.48,304.83) circle (  1.07);

\path[fill=fillColor] (280.71,305.63) circle (  1.07);

\path[fill=fillColor] (280.93,306.07) circle (  1.07);

\path[fill=fillColor] (281.16,304.38) circle (  1.07);

\path[fill=fillColor] (281.38,304.63) circle (  1.07);

\path[fill=fillColor] (281.60,304.22) circle (  1.07);

\path[fill=fillColor] (281.83,302.01) circle (  1.07);


text:
\hypertarget{move__base__z__client__plugin_8cpp}{}\doxysection{smacc\+\_\+client\+\_\+library/move\+\_\+base\+\_\+z\+\_\+client/move\+\_\+base\+\_\+z\+\_\+client\+\_\+plugin/src/move\+\_\+base\+\_\+z\+\_\+client\+\_\+plugin/move\+\_\+base\+\_\+z\+\_\+client\+\_\+plugin.cpp File Reference}
\label{move__base__z__client__plugin_8cpp}\index{smacc\_client\_library/move\_base\_z\_client/move\_base\_z\_client\_plugin/src/move\_base\_z\_client\_plugin/move\_base\_z\_client\_plugin.cpp@{smacc\_client\_library/move\_base\_z\_client/move\_base\_z\_client\_plugin/src/move\_base\_z\_client\_plugin/move\_base\_z\_client\_plugin.cpp}}
{\ttfamily \#include $<$move\+\_\+base\+\_\+z\+\_\+client\+\_\+plugin/move\+\_\+base\+\_\+z\+\_\+client\+\_\+plugin.\+hpp$>$}\newline
{\ttfamily \#include $<$string$>$}\newline
{\ttfamily \#include $<$pluginlib/class\+\_\+list\+\_\+macros.\+hpp$>$}\newline
Include dependency graph for move\+\_\+base\+\_\+z\+\_\+client\+\_\+plugin.\+cpp\+:
\nopagebreak
\begin{figure}[H]
\begin{center}
\leavevmode
\includegraphics[width=350pt]{move__base__z__client__plugin_8cpp__incl}
\end{center}
\end{figure}
\doxysubsection*{Namespaces}
\begin{DoxyCompactItemize}
\item
 \mbox{\hyperlink{namespacecl__move__base__z}{cl\+\_\+move\+\_\+base\+\_\+z}}
\end{DoxyCompactItemize}
\doxysubsection*{Typedefs}
\begin{DoxyCompactItemize}
\item
typedef \mbox{\hyperlink{classsmacc2_1_1client__bases_1_1SmaccActionClientBase}{smacc2\+::client\+\_\+bases\+::\+Smacc\+Action\+Client\+Base}}$<$ nav2\+\_\+msgs\+::action\+::\+Navigate\+To\+Pose $>$ \mbox{\hyperlink{namespacecl__move__base__z_a4bab6ecca5d5380fba452aa10097cc9d}{cl\+\_\+move\+\_\+base\+\_\+z\+::\+Base}}
\item
typedef Base\+::\+Wrapped\+Result \mbox{\hyperlink{namespacecl__move__base__z_adf365e3fb2335db5cbd4cc034d0eee39}{cl\+\_\+move\+\_\+base\+\_\+z\+::\+Wrapped\+Result}}
\end{DoxyCompactItemize}


text:
\hypertarget{interface_e_s_activity_cell}{}\section{E\+S\+Activity\+Cell Class Reference}
\label{interface_e_s_activity_cell}\index{E\+S\+Activity\+Cell@{E\+S\+Activity\+Cell}}
Inheritance diagram for E\+S\+Activity\+Cell\+:\begin{figure}[H]
\begin{center}
\leavevmode
\includegraphics[height=3.000000cm]{interface_e_s_activity_cell}
\end{center}
\end{figure}
\subsection*{Instance Methods}
\begin{DoxyCompactItemize}
\item
(void) -\/ \hyperlink{interface_e_s_activity_cell_a3a8af1c87976402d5fd3dc6a9a477afb}{set\+Is\+New\+:}
\end{DoxyCompactItemize}
\subsection*{Properties}
\begin{DoxyCompactItemize}
\item
P\+F\+Object $\ast$ \hyperlink{interface_e_s_activity_cell_a0f685740c7ed1d931892b5f03b95a7a7}{activity}
\end{DoxyCompactItemize}
\subsection*{Additional Inherited Members}

\subsection{Method Documentation}
\hypertarget{interface_e_s_activity_cell_a3a8af1c87976402d5fd3dc6a9a477afb}{}\index{E\+S\+Activity\+Cell@{E\+S\+Activity\+Cell}!set\+Is\+New\+:@{set\+Is\+New\+:}}
\index{set\+Is\+New\+:@{set\+Is\+New\+:}!E\+S\+Activity\+Cell@{E\+S\+Activity\+Cell}}
\subsubsection[{set\+Is\+New\+:}]{\setlength{\rightskip}{0pt plus 5cm}-\/ (void) set\+Is\+New\+:
\begin{DoxyParamCaption}
\item[{(B\+O\+O\+L)}]{is\+New}
\end{DoxyParamCaption}
}\label{interface_e_s_activity_cell_a3a8af1c87976402d5fd3dc6a9a477afb}
Set the new state. This changes the background of the cell.

\subsection{Property Documentation}
\hypertarget{interface_e_s_activity_cell_a0f685740c7ed1d931892b5f03b95a7a7}{}\index{E\+S\+Activity\+Cell@{E\+S\+Activity\+Cell}!activity@{activity}}
\index{activity@{activity}!E\+S\+Activity\+Cell@{E\+S\+Activity\+Cell}}
\subsubsection[{activity}]{\setlength{\rightskip}{0pt plus 5cm}-\/ (P\+F\+Object$\ast$) activity\hspace{0.3cm}{\ttfamily [read]}, {\ttfamily [write]}, {\ttfamily [nonatomic]}, {\ttfamily [strong]}}\label{interface_e_s_activity_cell_a0f685740c7ed1d931892b5f03b95a7a7}
Setter for the activity associated with this cell

The documentation for this class was generated from the following files\+:\begin{DoxyCompactItemize}
\item
Views/\+U\+I\+Table\+View\+Cells/E\+S\+Activity\+Cell.\+h\item
Views/\+U\+I\+Table\+View\+Cells/E\+S\+Activity\+Cell.\+m\end{DoxyCompactItemize}


text:
%%
%% Copyright 2007, 2008, 2009 Elsevier Ltd
%%
%% This file is part of the 'Elsarticle Bundle'.
%% ---------------------------------------------
%%
%% It may be distributed under the conditions of the LaTeX Project Public
%% License, either version 1.2 of this license or (at your option) any
%% later version.  The latest version of this license is in
%%    http://www.latex-project.org/lppl.txt
%% and version 1.2 or later is part of all distributions of LaTeX
%% version 1999/12/01 or later.
%%
%% The list of all files belonging to the 'Elsarticle Bundle' is
%% given in the file `manifest.txt'.
%%

%% Template article for Elsevier's document class `elsarticle'
%% with harvard style bibliographic references
%% SP 2008/03/01
%%
%%
%%
%% $Id: report01_prl.tex,v 1.3 2011/01/11 17:34:41 teerola Exp $
%%
%%
\documentclass[preprint,authoryear,review]{elsarticle}

%% Use the option review to obtain double line spacing
%% \documentclass[authoryear,preprint,review,12pt]{elsarticle}

%% Use the options 1p,twocolumn; 3p; 3p,twocolumn; 5p; or 5p,twocolumn
%% for a journal layout:
%% \documentclass[final,authoryear,1p,times]{elsarticle}
%% \documentclass[final,authoryear,1p,times,twocolumn]{elsarticle}
%% \documentclass[final,authoryear,3p,times]{elsarticle}
%% \documentclass[final,authoryear,3p,times,twocolumn]{elsarticle}
%% \documentclass[final,authoryear,5p,times]{elsarticle}
%% \documentclass[final,authoryear,5p,times,twocolumn]{elsarticle}

%% if you use PostScript figures in your article
%% use the graphics package for simple commands
%% \usepackage{graphics}
%% or use the graphicx package for more complicated commands
%% \usepackage{graphicx}
%% or use the epsfig package if you prefer to use the old commands
%% \usepackage{epsfig}

%% The amssymb package provides various useful mathematical symbols
%\usepackage{amssymb}

%
% OWN PACKAGES AND DEFINITIONS

\usepackage{paralist}

\graphicspath{{resources/}}

% math
\usepackage{amsmath}

% For nice PDF
\usepackage{times}
\usepackage{array}
\usepackage{pdfpages}

% new subfig format
%\usepackage[caption=false,font=normalsize,labelfont=sf,textfont=sf]{subfig}
\usepackage{subfig}

\usepackage[english]{babel} % For fixing the tilde problem https://bugs.launchpad.net/ubuntu/+source/texinfo/+bug/526974

% For commenting
\usepackage{color}
\newcommand\newnotecommand[3]{%
  \newcommand#1[1]{{\color{#3}\footnote{{\color{#3}#2:} ##1}}}}
\newnotecommand\joni{Joni}{red}
\newnotecommand\anders{Anders}{blue}

\usepackage[pagebackref=true,breaklinks=true,letterpaper=true,colorlinks,bookmarks=false]{hyperref}

\usepackage{multirow}
\usepackage{graphicx}
%\usepackage{graphicx}
%\usepackage[tight]{subfigure}
%\usepackage{amsmath}
%\usepackage{algorithmic} % for writing nice algorithms

%%
%% DEFINITION OF ALGORITHM ENVIRONMENT
%\newtheorem{alg}{Algorithm}
%\long\def\@makealgocaption#1#2{\vskip 2ex \small
%  \hbox to \hsize{\parbox[t]{\hsize}{{\bfseries #1.} #2}}}
%\newcounter{algorithm}
%\def\thealgorithm{\@arabic\c@algorithm}
%\def\fps@algorithm{tbp}
%\def\ftype@algorithm{4}
%\def\ext@algorithm{lof}
%\def\fnum@algorithm{Algorithm \thealgorithm}
%\def\algorithm{\let\@makecaption\@makealgocaption\@float{algorithm}}
%\let\endalgorithm\end

%% The amsthm package provides extended theorem environments
%% \usepackage{amsthm}

%% The lineno packages adds line numbers. Start line numbering with
%% \begin{linenumers}, end it with \end{linenumbers}. Or switch it on
%% for the whole article with \linenumbers after \end{frontmatter}.
\usepackage{lineno}

%% natbib.sty is loaded by default. However, natbib options can be
%% provided with \biboptions{...} command. Following options are
%% valid:

%%   round  -  round parentheses are used (default)
%%   square -  square brackets are used   [option]
%%   curly  -  curly braces are used      {option}
%%   angle  -  angle brackets are used    <option>
%%   semicolon  -  multiple citations separated by semi-colon (default)
%%   colon  - same as semicolon, an earlier confusion
%%   comma  -  separated by comma
%%   authoryear - selects author-year citations (default)
%%   numbers-  selects numerical citations
%%   super  -  numerical citations as superscripts
%%   sort   -  sorts multiple citations according to order in ref. list
%%   sort&compress   -  like sort, but also compresses numerical citations
%%   compress - compresses without sorting
%%   longnamesfirst  -  makes first citation full author list
%%
%% \biboptions{longnamesfirst,comma}

% \biboptions{}

\journal{Pattern Recognition Letters}

%\usepackage[usenames,dvipsnames]{color}
\newcommand{\commentNK}[1]{{\bf NK: #1}}

\begin{document}

\linenumbers

\begin{frontmatter}

%% Title, authors and addresses

%% use the tnoteref command within \title for footnotes;
%% use the tnotetext command for the associated footnote;
%% use the fnref command within \author or \address for footnotes;
%% use the fntext command for the associated footnote;
%% use the corref command within \author for corresponding author footnotes;
%% use the cortext command for the associated footnote;
%% use the ead command for the email address,
%% and the form \ead[url] for the home page:
%%
%% \title{Title\tnoteref{label1}}
%% \tnotetext[label1]{}
%% \author{Name\corref{cor1}\fnref{label2}}
%% \ead{email address}
%% \ead[url]{home page}
%% \fntext[label2]{}
%% \cortext[cor1]{}
%% \address{Address\fnref{label3}}
%% \fntext[label3]{}

\title{A comparison of local feature detectors and descriptors by intra-class repeatability and matching}

%% use optional labels to link authors explicitly to addresses:
%% \author[label1,label2]{<author name>}
%% \address[label1]{<address>}
%% \address[label2]{<address>}

\author[addrlutk]{Jukka~Lankinen}
\ead{Jukka.Lankinen@lut.fi}
\author[addrcovil]{Anders~Glent~Buch}
\ead{anbu@mmmi.sdu.dk}
\author[addrlutk]{Ville~Kangas}
\ead{Ville.Kangas@lut.fi}
\author[addrtut]{Joni-Kristian~K\"am\"ar\"ainen\corref{cor1}}
\ead{joni.kamarainen@tut.fi}
\cortext[cor1]{Corresponding author. Tel.: +358 40 5794605}
\author[addrcovil]{Norbert~Kr\"uger}
\ead{norbert@mmmi.sdu.dk}

%\address[addrlut]{Machine Vision and Pattern Recognition Laboratory (MVPR),
%Department of Information Technology,
%Lappeenranta University of Technology (LUT) %, P.O. Box 20, FIN-53851 Lappeenranta, Finland
%(\url{http://www2.it.lut.fi/mvpr/})}

% Heikki: Pitäisikö siis olla MVPR:n osoite tämän laitoksen sijaan (\url{http://www.it.lut.fi})}? Näin muutin
%
%\address[addrlutk]{LUT Kouvola Unit, Kouvola, Finland}%, Lappeenranta
\address[addrlutk]{Lappeenranta University of Technology (LUT), LUT Kouvola, Finland}%, Lappeenranta
\address[addrcovil]{M{\ae}rsk McKinney M{\o}ller Institute, University of Southern Denmark, Denmark}%, Lappeenranta
\address[addrtut]{Department of Signal Processing, Tampere University of Technology, Finland}

%\address[addrtut]{Department of Automation Science and Engineering, Tampere
%University of Technology, P.O. Box 692, FIN-33101 Tampere, Finland}

%\lasse{Active or passive voice?}

%\lasse{Use either long (for example, that is, \ldots) or short (e.g.,
%i.e., \ldots) forms.}

%\lasse{Check the use of acronyms and initialisms.}

\begin{abstract}
Intuitive and easily interpretable local feature detector and descriptor
%repeatability and matching
performance measures and evaluation protocols were introduced
in~\cite{MikTuySch:2005,MikSch:2005}. They, however,
measured performances in wide baseline settings that do not correspond
to object class detection and recognition problems where the
detectors and descriptors are popular tools. This limitation has been
recognised and several ad~hoc evaluations reported.
This work extends the original performance
measures to the case of multiple examples of object classes and with our
novel framework we compare state-of-the-art detectors and descriptors.
%with object class datasets.

Our results from the detector comparison verify the wide baseline findings:
SIFT and SURF provide the most repeatable local regions between
instances of object classes. The detector differences are marginal and
in the descriptor comparison, the total number of detected regions
turned out to be more important giving preference to the Hessian-affine
detector. The most striking result, however, was the performance
collapse of all descriptors in intra-class matching---only a few
matches on average were found as compared to hundreds of matches in the
original works. This result
%The poor
%intra-class matching performance
indicates that even the best available descriptors
can be inadequate for large scale object classification
purposes.
%This finding supports
%the recent trend where other approaches, such as dense sampling, have been
%adopted and also motivates further investigation on local feature descriptors.
%% At
%%first, that was our major conclusion from the descriptor evaluation where
%%descriptors paired with the Hessian-affine detector performed the best - a
%%finding already pointed out by \cite{NowJurTri:2006}:
%%``the more the better''. As a striking result, however,
Moreover, we found out that by using multiple best matches, even as few as
2-5, descriptor matching performance can be significantly improved. This
is particularly evident with the new performance measure proposed:
coverage-N (the number of images with at least N correct matches).

%Our findings indicate, that in large scale object classification,
%other than interest point based approaches, such as dense sampling,
%should be advocated, and novel object classification tailored local
%region descriptors should be developed or descriptor matching should
%utilise multiple matches.
%
%\commentNK{I feel this is a bit jumping to conclusions. It would be better in my view to extend the description of the actual problem you have spotted and given evidence for and then be very careful about the conclusions that might(!) be drawn.}

%Our results indicate, that an alternative claim to the Nowak et al. can be
%made: it is possible to perform well in visual class matching using a
%smaller number of local features and a smaller codebook by utilising
%multiple alternative assignments of local features -
%``less is more''.
\end{abstract}

\begin{keyword}
Feature detector \sep feature descriptor \sep local feature \sep object class detection
%% keywords here, in the form: keyword \sep keyword

%% MSC codes here, in the form: \MSC code \sep code
%% or \MSC[2008] code \sep code (2000 is the default)

\end{keyword}

\end{frontmatter}

% \linenumbers

%-------------------------------------------------------------------------
%
\section{Introduction}
%
The problems of local image feature detection and description often occur
in computer vision where point correspondences between images are needed.
Solutions should tolerate illumination changes, zoom, blur and other
often encountered distortions. This is the case in many
applications, such as in wide-baseline matching (\cite{TuyGoo:2004}), robot
localisation (\cite{SeLowLit:2002}) and image stitching for panoramic
views (\cite{BroLow:2003}). In these, the correspondences are sought
between different views of the same scene and the evaluations by
\cite{MikTuySch:2005} and \cite{MikSch:2005} help to select the
most suitable method. Another popular application is visual object
classification (VOC), where objects in images should be identified.
In this case, the evaluations by Mikolajczyk et al.
are not
directly applicable, since the repeatability and matching performances
were computed for multiple views of a same object (scene) instead of
a set of object class examples.

Various methods have been proposed for detecting interest
points/regions and to construct descriptors for detected
regions, most of which are designed with a different application in mind.
\cite{MikTuySch:2005}
and \cite{MikSch:2005} evaluated and
compared the most popular detectors and descriptors. The detectors
were evaluated by their repeatability ratios and total number of
correspondences over several view points and with various
imaging distortion types. The descriptors were evaluated by their matching
rates for the same views.
More adequate comparisons related to the
object classification task
have been reported by \cite{ZhaMarLaz:2006} and
\cite{MikLeiSch:2005}, but in these works
the evaluation was tied to a single methodological approach, namely
visual Bag-of-Words (BoW). In this work, we evaluate state-of-the-art
detectors and descriptors in the context of visual classification
and make the following contributions:
\begin{compactitem}
\item We extend the detector repeatability evaluation
  in~\cite{MikTuySch:2005} to intra-class repeatibility. Numbers of
  intra-class correspondences and repeatability rates are reported as
  the performance measures.
\item We extend the descriptor matching evaluation in~\cite{MikSch:2005} to
  the case of object classes.
  The intra-class match counts and rates are reported as the performance measures.
\item We propose {\em match coverage} as an alternative performance measure for descriptor evaluation: {\em coverage-N} measures how many image pairs
  contain at least N descriptor matches. This measure reveals the proportion of images in which the matching is expected to succeed.
\item We compare the most popular detector and descriptor methods and their various
  implementations in our novel intra-class evaluation setting.
\item We extend the original descriptor performance measures to use K best matches (K=1 in the
  original work). As will be shown, this modification is important and allows for significant improvements for object class matching.
\item For the detectors we verify the earlier results of their ranking, but for the descriptors
  we report a striking finding that the average number of matches collapses from hundreds to only
  a few. A significant improvement can be achieved by counting more than the one best match, but
  still the number of matching regions can be too low for large scale classification problems.
\end{compactitem}

%\commentNK{The last point is most important and should be discussed in its consequences for the computer vision community.}

This work extends our preliminary work in \cite{LanKanKam:2012} by revising the
experiments with more accurate measures that directly correspond to the original works
by Mikolajczyk et al., introducing the coverage-N performance measure and, in
particular, providing two important findings: with object class instances the
number of matching regions is very low, only a few as compared to hundreds in the
original work, and significant improvement can be achieved by counting more than one,
even as few as 5, best matches.
%surprising results when multiple best matches are counted.
%While mainstream in object classification has adopted the result by
%\cite{NowJurTri:2006} - ``the more the better'' - and thus dense
%sampling is popular, our novel results indicate that methods utilising multiple matches
%may succeed equally well - ``less is more''.

%All data and source code will be made publicly available to facilitate development of
%better approaches for detecting and matching local regions between object class
%instances. \commentNK{This is a promise, better to point to a web-page.}

%
\subsection{Previous work}
%
%\commentNK{I feel that this section is a bit thin. It depends a bit how aggressively we want to play it. Then the arguments should be better prepared.}

We believe that the general evaluation principles in~\cite{MikSch:2005,MikTuySch:2005} also hold in
the context of visual object classes: 1) \textit{detectors which return the same object regions for class
examples are good detectors} -- detection repeatability; 2)
\textit{descriptors which match the same object regions between class examples are good descriptors} -- match count/ratio. We refer to these repeating and matching regions as
``category-specific landmarks''. Indeed, a successful outcome of the categorisation task is important
for the final application, and therefore \cite{ZhaMarLaz:2006} compared different
detectors and descriptors using a baseline BoW method. In the baseline method, codebooks are constructed from
the raw descriptors and then images are categorised according to their codebook histograms.
In their work, \cite{MikLeiSch:2005}
were more specific by measuring average precision of feature clusters to represent a single class,
entropy of spatial location distribution produced by a single cluster (ideally compact) and complementarity
of different detectors. Both evaluations are biased by
the selected BoW approach. In this work, we show how the original evaluation principles can
be adopted to obtain quantitative performance in the general and intuitive forms used in the original
works and not tied to a specific approach.

%-------------------------------------------------------------------------
%
\section{Comparison of Region Detectors}
%
A good interest point detector for object classification should detect local
points or regions at the same object-relative locations, ``object landmarks'', on every
class example.
This criterion is different from~\cite{MikTuySch:2005}
in the sense that we evaluate detectors over examples of different
categories instead of changed and distorted views of same scenes. In our case, visual appearance
variation is expected to be much larger.

%
\subsection{Data\label{sec:data}}
%
The experiments were conducted using the categories in the popular VOC dataset, Caltech-101~\cite{FeiFerPer:2006}.
For compactness and clarity, the results are reported for the following ten categories which
represent well the overall performance variation: \textit{watch}, \textit{stop\_sign}, \textit{starfish},
\textit{revolver}, \textit{euphonium}, \textit{dollar\_bill}, \textit{car\_side},
\textit{airplanes}, \textit{Motorbikes} and \textit{Faces\_easy}. The foreground areas,
included in the Caltech-101 ground truth data, were used to mask out interested points detected
on backgrounds.
Affine correspondences between the category examples were established
by manually annotating 5-12 landmarks per category and estimating the pair-wise image transformations
using the direct linear transform (\cite{HarZis:2003}). Example images with landmarks are shown
in Fig.~\ref{fig:affine_example1}.
%
For this experiment we used repeatedly 25 random pairs of images from each category (tot. of 500 images).
%each detector is run for all 500 images and then comparisons
%of features between image pairs are done, using the same methods as in
%~\cite{MikTuySch:2005}.
\begin{figure}[h]
\begin{center}
\subfloat{\includegraphics[height=0.16\linewidth]{resources/lm/lm_examples_cat01_img01.png}}
\subfloat{\includegraphics[height=0.16\linewidth]{resources/lm/lm_cat01.png}}~
\subfloat{\includegraphics[height=0.16\linewidth]{resources/lm/lm_examples_cat02_img07.png}}
\subfloat{\includegraphics[height=0.16\linewidth]{resources/lm/lm_cat02.png}}\\
\subfloat{\includegraphics[height=0.1\linewidth]{resources/lm/lm_examples_cat03_img08.png}}
\subfloat{\includegraphics[height=0.1\linewidth]{resources/lm/lm_cat03.png}}~
\subfloat{\includegraphics[height=0.16\linewidth]{resources/lm/lm_examples_cat09_img01.png}}
\subfloat{\includegraphics[height=0.16\linewidth]{resources/lm/lm_cat09.png}}\\
\subfloat{\includegraphics[height=0.12\linewidth]{resources/lm/lm_examples_cat05_img04.png}}
\subfloat{\includegraphics[height=0.12\linewidth]{resources/lm/lm_cat05.png}}~
\subfloat{\includegraphics[height=0.14\linewidth]{resources/lm/lm_examples_cat08_img02.png}}
\subfloat{\includegraphics[height=0.14\linewidth]{resources/lm/lm_cat08.png}}\\
\subfloat{\includegraphics[height=0.14\linewidth]{resources/lm/lm_examples_cat04_img02.png}}
\subfloat{\includegraphics[height=0.14\linewidth]{resources/lm/lm_cat04.png}}~
\subfloat{\includegraphics[height=0.14\linewidth]{resources/lm/lm_examples_cat06_img02.png}}
\subfloat{\includegraphics[height=0.14\linewidth]{resources/lm/lm_cat06.png}}\\
\subfloat{\includegraphics[height=0.14\linewidth]{resources/lm/lm_examples_cat07_img10.png}}


text:
\hypertarget{dir_4933d6061cdf638456f2de82b59678f8}{}\section{Classes/\+Tabs/04\+\_\+\+Settings/04\+\_\+\+Dependencies Directory Reference}
\label{dir_4933d6061cdf638456f2de82b59678f8}\index{Classes/\+Tabs/04\+\_\+\+Settings/04\+\_\+\+Dependencies Directory Reference@{Classes/\+Tabs/04\+\_\+\+Settings/04\+\_\+\+Dependencies Directory Reference}}
\subsection*{Files}
\begin{DoxyCompactItemize}
\item
file {\bfseries E\+S\+Dependencies\+View.\+h}
\item
file {\bfseries E\+S\+Dependencies\+View.\+m}
\end{DoxyCompactItemize}


text:
\section{Meta}

\begin{itemize}
\item \sout{Add Lucas to authors}
\item \sout{add early collaborators like Chris, mackenzie, etc. who gave information and insight.}
\item \sout{add contribution statement}
\item finalize contribution statement
\item \sout{add citations for bpod and pycontrol papers, i think they have come out since this!!!}
\item \sout{move autopilot to its own organization repository so links stay fresh! Then update the links in the paper!}
\item complete nosepoke and behavior box assembly instructions on wiki.
\item \sout{terminal send back pilot DB to each other pilot when they connect.}
\item links from text to future directions
\item Move go/no-go task from main autopilot library to plugin
\end{itemize}

\subsection{Formatting}

\begin{itemize}
\item \sout{TOC spacing!}
\item \sout{Smart quotes for single quotes}
\item \sout{Margin note positioning throughout (do at end though)}
\item Glossary links throughout text?
\item Index???
\item \sout{fix links to future directions to have correct references to individual items within list.}
\item add link to interface map and mapset in data model figure when docs are up
\end{itemize}

\section{Intro}

\subsection{Foreword to Manuscript v2}

\begin{itemize}
\item Check the changelog!
\end{itemize}

\section{Data to Include}

\begin{itemize}
\item Get all configuration files including chrony, prefs, etc.
\item Organize and annotate data
\end{itemize}

\section{Docs to write}

\begin{itemize}
\item document the get\_stream method on net\_nodes!
\item wiki page for the paper plugin! specifically the go no/go task
\end{itemize}

\hrule

\section{Finished}

\subsection{Preamble}

\begin{itemize}
\item \sout{Add: Also experimental software is a missed opportunity and a strong lbockage to our ambitions of "open science" -- making an unnecessary rite of passage in struggling through behavioral setups}
\item \sout{This is actually a challenging technical and theoretical problem. Tension between totalizing framework and integrating many tools: autopilot tries to be mindful about both -- it is a logical framework for the different parts of an experiment, allows easily hooking into each of these components, but also lets them be used separately. Autopilot was designed to \textit{play nice} with other tools, but also give them a place to play nice with each other.}
\item \sout{"whats missing is a glue framework"}
\item \sout{\textbf{Reproducibility para} - Mention of the wiki and plugin systems -- using a linux system brings with it all a manner of technical challenges. We have designed autopilot as a system that can integrate fluid technical knowledge along with the code to use it. Also that we have designed it to let work at all stages of "completeness" work together with its plugin framework -- example with a stepper motor. thsi one might not be **exactly** what you need but it's better than nothing.}
\item \sout{Note that autopilot is a continually developing system, so we don't necessarily do everything here perfectly, many things are in progress, but this document is intended to capture the ideas that animate its development.}
\end{itemize}

\subsection{Existing Systems}

\begin{itemize}
	\item \sout{"These are the minimum components for a complete behavior system, but there are of course many other things, means of conceptualizing and supporting. Each of these is far from monolithic and has within it a thousand design choices."}
	\item \sout{add transforms to "data management"}
	\item \sout{Update description for pyControl}
	\item \sout{update description for BPod}
	\item \sout{link to finite state machine section from "pyControl uses a finite state machine"}
	\item \sout{Bpod also has pyBpod and whatever else}
	\item \sout{remove "Bpod blocks operation" it's not necessary -- refocus this section on just describing the architectural decisions without including shit talking the GUI. In general, the purpose of this section is to illustrate two prior approaches to solving this problem to draw contrast with what we do differently.}
	\item \sout{Can also discuss the mode by which it's used (eg. talk about the IBL needing to make the bigass PDF) and maybe try and find some individual use cases of each that are given as examples. These are designed for individual labs to use as tools, rather than designed as a means for organizing technical knowledge within or across labs (let alone share data).}
\end{itemize}

\subsection{Limitations of existing systems}

\begin{itemize}
\item \sout{Documentation is a big problem -- don't have low-level docs so people can inspect what's going on. Researchers are expected to interact with it on a top-level only: the tool as is, rather than expand and hack on the library itself. Flexible tools need to have interfaces at multiple levels: yes, just use, but also be able to extend, and modify the existing system. This is an architectural, interface, and documentation question and it's a hard one to solve!}
\item \sout{\textbf{New Item: Community Tooling} - No facility for sharing tasks, hardware development, etc. No good means of sharing practical usage advice -- basically the community tooling isn't there. Look for examples of Bpod tasks (eg. the IBL task) and how that doesn't make for a cumulative body of knowledge. Use the christof koch quote about organization being the major problem: in order to be a force multiplier, need to be able to have peer-to-peer knowledge sharing instead of treating a piece of software as a fixed entity.}
\item \sout{Data - no schemas, no formal structures, sharing is hard and both take the approach that you need to write a whole additional library to analyze the data}
\item \sout{Devops and code tooling -- Bpod stuff has no means of integrating other code because matlab doesn't have a package manager. No CI, no tests for either} \textbf{Instead of this, just say that Autopilot does this}
\item \sout{the bottom line is that these tools weren't designed with integration in mind, ithey might handle some subset of the experiment, but they don't really play well with the other parts of the experiment and ultimately serve as yet another complicated node rather than something that can be compared.}
\end{itemize}

\section{Design}

\begin{itemize}
\item \sout{We take a broad lens on reproducibility -- not just good data, but a tool that integrates into a broader ecosystem of tools and reduces labor duplication beyond itself. Reproducibility is not just a question of getting everyone to upload their data, but to build the tools that make reproducibility accessible to a broader base of researchers.}
\item \sout{Though only the GPIO is really unique to the raspi -- autopilot can be used on any unixlike system.}
\end{itemize}

\subsection{Efficiency}

\begin{itemize}
\item \sout{integrated circuit -> microcontroller}
\item \sout{efficiency of interpreted languages is not the only consideration in efficiency: how easy it is to use and the time spent troubleshooting and making do with other systems is itself part of the equation, so we try and balance the ease of use witht he performance of the program}
\item \sout{\textbf{Concurrency} - Arguably the most radical concurrency model in autopilot is the use of multiple comptuers. So if a single processor can't do what you want it's trivial to have other computers running other things. This also lets different system components be isolated from one another, something that blends into the notion of agents and behavioral topologies discussed later.}
\item \sout{\textbf{Low-Level} - We make use of Python to mature an API that we will then drop down into lower level languages like C and Rust when they are stable.}
\item \sout{\textbf{Caching} - by provbiding low-level documentation, we let people choose how they want to cache -- you can just hit play on a sound method or buffer it before, or generate it on the fly. You can just `send' a message, or you can pre-serialize it and send it manually.}
\end{itemize}

\subsection{Flexibility}

\begin{itemize}
\item \sout{\textbf{Modularity} - There is a tension between flexibiltiy and providing a complete behavioral package, to balance that we have to be very capable of keeping our code modular. We do that by implementing a sensible inheritance hierarchy with predictable and shared APIs for different objects. That way we can keep a predictable set of methods exposed while being able to modify the other}
\item \sout{\textbf{New Section: Open Ecosystem} - split apart modularity section into a discussion about being able to pick and choose different parts of the library with a new section about the choice to use the raspberry pi and a generalize dhardware approach rather than an ecosystem of specific hardware objects. Describe the wiki here?}
\item \sout{\textbf{New Section: Plugins} - replace structured expansino/code transparency section with plugin sectino. By separating local configuration files and etc. we are able to have a very flexible plugin system: users are not expected to modify files in the repository to use it (which makes it difficult to contribute later) or implement everything in a single script. instead we provide a system for expansion that scaffolds their use of the software and reuse in tasks. Expand the discussion of the task library to a general purpose pick and choose your own tool library with plugins that can be maintained by you but be part of a larger project.}
\item \sout{CI is also really relevant here -- to make sure that it's possible to change the system freely, we have CI and as we have been developing have been}

\end{itemize}

\subsection{Reproducibility}

\begin{itemize}
\item \sout{New to data management section: schema stuff! We want to provide a well annotated data structure that can be exported to many different formats. To do that we have built a bunch of data modeling tools}

\item \sout{Update prices!}
\end{itemize}

\section{Structure}

\begin{itemize}
\item \sout{Start by describing the hierarchical object strucutre -- Autopilot is designed around a few fundamental types with abstract methods that are then elaborated. This is in progress!} - how hard would it be to make this be an autogenerated figure?
\item \sout{in this section, also talk about ability to dehydrate and rehydrate objects so they can be re-instantiated across processes and machines.} - probably not necessary
\item \sout{\textbf{New Section: Transforms} - also include DLC stuff.}
\item \sout{Stuff that all autopilot objects have -- sick logging (give example). Autopilot is about making best practices baked into the process. }
\item Rename "Children" as "copilots" throughout
\end{itemize}

\subsection{Tasks}

\begin{itemize}
\item \sout{Update task header to use Pydantic models.}
\item \sout{end FSM section being like "rather than trying to standardize on a particular model for tasks, we standardize on \textit{use}" -- We provide a set of minimal tools that can be used to write tasks, but then purposefully leave the space open for people to write them how they want, and then allow standardization to happen naturally rather than presupposing a structure and asking people to conform to it. Cite aaron swartz description of standards from his book.}
\end{itemize}

\subsection{Hardware}

\begin{itemize}
\item \sout{Update link to refer to the wiki rather than the hardware page on autopilot website. also mention build guides and whatever. Also describe vision of being ableo to declare specific part numbers for hardware objects to be able to document the parameters of their use.}
\item \sout{update prices}
\item \sout{update figure to use new tripoke figure.}
\item \sout{System adaptability section seems redundant with separating task params. Abbreviate this and change this section to being about using the wiki to gather common configurations for hardware objects, benchmarks, etc.} - nah just took it out.
\item \sout{update system specs, if they've changed.}
\end{itemize}

\subsection{Stimuli}

\begin{itemize}
\item \sout{You can also use a jetson or some other SBC with a video card if performance is more important. as we did in (cite DLC paper)}
\item \sout{remove stimulus and reward manager section, we don't really have them -- move this to future directions}
\end{itemize}

\subsection{Networking}

\begin{itemize}
\item \ref{sec:networking} \sout{Rewrite to say that the backbone "station" structure is being phased out in favor of a point to point communication system. For now you can use point to point communication if timing is important, but otherwise agent-agent communication still uses the hierarchical networking structure by default.}
\item \ref{fig:datastreams} \sout{remove treelike}
\end{itemize}

\subsection{GUI}

\begin{itemize}
\item \sout{Change framing so we're talking about moving the GUI towards being a visual representation of the rest of the data modeling systems, so that different components of the system automatically get interfaces. Decoupling all the logic of the GUI into general system methods that the GUI can just visually present.}
\item \sout{We're going to change the plotting stuff to be built into the data description, but for now it's independent.}
\end{itemize}

\section{Tests}

\begin{itemize}
\item \sout{Functionality testing is done in our CI, so these are just rough performance characterizations that can always change. So as much as it doesn't make sense to publish performance characterization in a static paper, we'll do some of that here}
\item Add version numbers to each of the test in margin note.
\item \sout{Update language on tests. We have been working on autopilot continuously, \# commits have happened, etc.}
\item \sout{Remove Bpod comparison tests. too messy. Then also remove language at the top that we improve efficiency an order of magnitude}
\item \sout{\textbf{CODE:} replace JSON with msgpack.}
\item \sout{\textbf{Re-run all tests} }
\begin{itemize}
\item \sout{Sound latency}
\item \sout{Network latency}
\item \sout{Network throughput}
\end{itemize}
\item \sout{Make sure to actually NTP sync!}
\item \textbf{NEW Tests}
\begin{itemize}
\item \sout{GPIO on/off latency}
\item \sout{networked GPIO on/off latency}
\item \sout{Camera FPS for picam/FLIR cam?}
\item \sout{timed GPIO on/off jitter.}
\end{itemize}
\item \sout{Just say we haven't done any work on visual stimuli so this test was run with the release version of autopilot.}

\end{itemize}

\section{Future Directions}

\begin{itemize}
\item RDF export, linked data capabilities between the wiki and data structures
\item Also working on a related ingest project to be able to automatically bring in data from other sources made during use.
\item Unify slot, signal, and trigger architecture to make different pieces more effortlessly compatible.
\item Write rust interface to GPIO pins
\item \textbf{New Section: Knowledge Organization} - We will continue to explore additional avenues for improving the interfaces with which we share information. If there's anything we've learned over the past few years it's that technical profiency isn't enough: you need to support a community of people around the tool and make sure they have the means of answering questions for themselves. There is a ton of additional informatino that's needed to perform any experiment that doesn't fit neatly in code or docs, hence the wiki! To make things both \textit{technically} reproducible AND \textit{practically} reproducible, the plugin system is built into a semantic wiki that can organize structured data (wiki stuff here for sure, not in the other place i said)
\item pipelining for transforms, forking and branching to be able to get intermediate products out as well as merge multiple pipes, as well as different transformatino rhythms that let you control more finely how transformatino piplines behave
\item stimulus managers - in a previous version we described these, thinking that they would be developed shortly. we still haven't gotten around to that but have left stubs in place.
\item granular dependency management!
\item agent management! make it easier to deploy and configure pilots from a single place
\end{itemize}

\subsection{Data}

\begin{itemize}
\item \sout{(In program design section) - Change standardized task decriptions to being about schemas. Tasks and data use a shared representation (along with the subject class) that lets you export descrptions as JSON, but also into NWB and etc.}
\item \sout{(In program design section) - Self-documenting data -> be more explicit that we record \textit{everything}}
\item \sout{Annotate code example}
\end{itemize}

\subsection{Agents}

\begin{itemize}
\item \sout{Remove child agent.}
\item \sout{talk about managing dependencies for particular types of agents here, more relevant than terminal vs. pilot etc.}
\item \sout{Talk about scripts and system configuration here.}
\item \sout{Change child figure to being one with multiple copilots}
\end{itemize}


text:
\hypertarget{classfragalysis__api_1_1xcanalyser_1_1graphcreator_1_1_graph_request}{}\section{fragalysis\+\_\+api.\+xcanalyser.\+graphcreator.\+Graph\+Request Class Reference}
\label{classfragalysis__api_1_1xcanalyser_1_1graphcreator_1_1_graph_request}\index{fragalysis\+\_\+api.\+xcanalyser.\+graphcreator.\+Graph\+Request@{fragalysis\+\_\+api.\+xcanalyser.\+graphcreator.\+Graph\+Request}}
\subsection*{Public Member Functions}
\begin{DoxyCompactItemize}
\item
\mbox{\Hypertarget{classfragalysis__api_1_1xcanalyser_1_1graphcreator_1_1_graph_request_ac2cce029ca7a29dab5625823e2eb92c2}\label{classfragalysis__api_1_1xcanalyser_1_1graphcreator_1_1_graph_request_ac2cce029ca7a29dab5625823e2eb92c2}}
def {\bfseries \+\_\+\+\_\+init\+\_\+\+\_\+} (self)
\item
\mbox{\Hypertarget{classfragalysis__api_1_1xcanalyser_1_1graphcreator_1_1_graph_request_ac47f4baba7c0cdefd43bb0c7e17646c9}\label{classfragalysis__api_1_1xcanalyser_1_1graphcreator_1_1_graph_request_ac47f4baba7c0cdefd43bb0c7e17646c9}}
def {\bfseries set\+\_\+smiles\+\_\+url} (self, smiles)
\item
\mbox{\Hypertarget{classfragalysis__api_1_1xcanalyser_1_1graphcreator_1_1_graph_request_a1ca3ed55492a1722ef0feb76c7fba43f}\label{classfragalysis__api_1_1xcanalyser_1_1graphcreator_1_1_graph_request_a1ca3ed55492a1722ef0feb76c7fba43f}}
def {\bfseries get\+\_\+new\+\_\+smiles} (self, smiles)
\end{DoxyCompactItemize}
\subsection*{Public Attributes}
\begin{DoxyCompactItemize}
\item
\mbox{\Hypertarget{classfragalysis__api_1_1xcanalyser_1_1graphcreator_1_1_graph_request_ac1d452fb3f9d6e80ba3a31e02145d043}\label{classfragalysis__api_1_1xcanalyser_1_1graphcreator_1_1_graph_request_ac1d452fb3f9d6e80ba3a31e02145d043}}
{\bfseries frag\+\_\+url}
\item
\mbox{\Hypertarget{classfragalysis__api_1_1xcanalyser_1_1graphcreator_1_1_graph_request_a8c195076876c81b0beada67b8757caf2}\label{classfragalysis__api_1_1xcanalyser_1_1graphcreator_1_1_graph_request_a8c195076876c81b0beada67b8757caf2}}
{\bfseries graph\+\_\+url}
\item
\mbox{\Hypertarget{classfragalysis__api_1_1xcanalyser_1_1graphcreator_1_1_graph_request_a6f74c9499e8e158b9416880b3c7133a6}\label{classfragalysis__api_1_1xcanalyser_1_1graphcreator_1_1_graph_request_a6f74c9499e8e158b9416880b3c7133a6}}
{\bfseries query}
\item
\mbox{\Hypertarget{classfragalysis__api_1_1xcanalyser_1_1graphcreator_1_1_graph_request_a212573c4bde168c0fd5563124284e569}\label{classfragalysis__api_1_1xcanalyser_1_1graphcreator_1_1_graph_request_a212573c4bde168c0fd5563124284e569}}
{\bfseries search\+\_\+url}
\item
\mbox{\Hypertarget{classfragalysis__api_1_1xcanalyser_1_1graphcreator_1_1_graph_request_a9659e3db8ca34a5f3bb7c3186df87fe0}\label{classfragalysis__api_1_1xcanalyser_1_1graphcreator_1_1_graph_request_a9659e3db8ca34a5f3bb7c3186df87fe0}}
{\bfseries smiles\+\_\+url}
\item
\mbox{\Hypertarget{classfragalysis__api_1_1xcanalyser_1_1graphcreator_1_1_graph_request_a564113897c119dfd6dcd066b12d1f481}\label{classfragalysis__api_1_1xcanalyser_1_1graphcreator_1_1_graph_request_a564113897c119dfd6dcd066b12d1f481}}
{\bfseries graph\+\_\+json}
\end{DoxyCompactItemize}

\subsection{Detailed Description}

Definition at line 16 of file graphcreator.\+py.

The documentation for this class was generated from the following file\+:\begin{DoxyCompactItemize}
\item
fragalysis\+\_\+api/xcanalyser/graphcreator.\+py\end{DoxyCompactItemize}


text:
\hypertarget{class_camera}{}\section{Référence de la classe Camera}
\label{class_camera}\index{Camera@{Camera}}

Implementation of \hyperlink{class_trackball}{Trackball} class.

{\ttfamily \#include $<$camera.\+h$>$}

Graphe d\textquotesingle{}héritage de Camera\+:\nopagebreak
\begin{figure}[H]
\begin{center}
\leavevmode
\includegraphics[height=550pt]{class_camera__inherit__graph}
\end{center}
\end{figure}

Graphe de collaboration de Camera\+:\nopagebreak
\begin{figure}[H]
\begin{center}
\leavevmode
\includegraphics[height=550pt]{class_camera__coll__graph}
\end{center}
\end{figure}
\subsection*{Fonctions membres publiques}
\begin{DoxyCompactItemize}
\item
\hyperlink{class_camera_ae23af4d7cab430c77d537621cdd16b3f}{Camera} ()=default
\end{DoxyCompactItemize}
\subsection*{Fonctions membres publiques statiques}
\begin{DoxyCompactItemize}
\item
static Eigen\+::\+Matrix4f \hyperlink{class_camera_aa63f48a3280871eba3a6f74a3c0f2e2e}{perspective} (float fovy, float aspect, float z\+Near, float z\+Far)
\item
static Eigen\+::\+Matrix4f \hyperlink{class_camera_a683a2e432969a485412c28e18567c174}{look\+At} (const Eigen\+::\+Vector3f \&position, const Eigen\+::\+Vector3f \&target, const Eigen\+::\+Vector3f \&up)
\end{DoxyCompactItemize}
\subsection*{Membres hérités additionnels}

\subsection{Description détaillée}
Implementation of \hyperlink{class_trackball}{Trackball} class.

\subsection{Documentation des constructeurs et destructeur}
\mbox{\Hypertarget{class_camera_ae23af4d7cab430c77d537621cdd16b3f}\label{class_camera_ae23af4d7cab430c77d537621cdd16b3f}}
\index{Camera@{Camera}!Camera@{Camera}}
\index{Camera@{Camera}!Camera@{Camera}}
\subsubsection{\texorpdfstring{Camera()}{Camera()}}
{\footnotesize\ttfamily Camera\+::\+Camera (\begin{DoxyParamCaption}{ }\end{DoxyParamCaption})\hspace{0.3cm}{\ttfamily [default]}}

\subsection{Documentation des fonctions membres}
\mbox{\Hypertarget{class_camera_a683a2e432969a485412c28e18567c174}\label{class_camera_a683a2e432969a485412c28e18567c174}}
\index{Camera@{Camera}!look\+At@{look\+At}}
\index{look\+At@{look\+At}!Camera@{Camera}}
\subsubsection{\texorpdfstring{look\+At()}{lookAt()}}
{\footnotesize\ttfamily Matrix4f Camera\+::look\+At (\begin{DoxyParamCaption}\item[{const Eigen\+::\+Vector3f \&}]{position,  }\item[{const Eigen\+::\+Vector3f \&}]{target,  }\item[{const Eigen\+::\+Vector3f \&}]{up }\end{DoxyParamCaption})\hspace{0.3cm}{\ttfamily [static]}}

\mbox{\Hypertarget{class_camera_aa63f48a3280871eba3a6f74a3c0f2e2e}\label{class_camera_aa63f48a3280871eba3a6f74a3c0f2e2e}}
\index{Camera@{Camera}!perspective@{perspective}}
\index{perspective@{perspective}!Camera@{Camera}}
\subsubsection{\texorpdfstring{perspective()}{perspective()}}
{\footnotesize\ttfamily Matrix4f Camera\+::perspective (\begin{DoxyParamCaption}\item[{float}]{fovy,  }\item[{float}]{aspect,  }\item[{float}]{z\+Near,  }\item[{float}]{z\+Far }\end{DoxyParamCaption})\hspace{0.3cm}{\ttfamily [static]}}

La documentation de cette classe a été générée à partir des fichiers suivants \+:\begin{DoxyCompactItemize}
\item
/home/marc-\/cerutti/\+Documents/pdp-\/21-\/2/src/include/\hyperlink{camera_8h}{camera.\+h}\item
/home/marc-\/cerutti/\+Documents/pdp-\/21-\/2/src/view/\hyperlink{camera_8cpp}{camera.\+cpp}\end{DoxyCompactItemize}