blob: dac0ef2bdcb32f0f5f748bf0b1be596e8c8ea66f [file] [log] [blame]
%!TEX root = ceres-solver.tex
\chapter{Overview}
\label{chapter:overview}
Ceres solves robustified non-linear least squares problems of the form
\begin{equation}
\frac{1}{2}\sum_{i=1} \rho_i\left(\left\|f_i\left(x_{i_1},\hdots,x_{i_k}\right)\right\|^2\right).
\label{eq:ceresproblem}
\end{equation}
Where $f_i(\cdot)$ is a cost function that depends on the parameter blocks $\left[x_{i_1}, \hdots , x_{i_k}\right]$ and $\rho_i$ is a loss function. In most optimization problems small groups of scalars occur together. For example the three components of a translation vector and the four components of the quaternion that define the pose of a camera. We refer to such a group of small scalars as a Parameter Block. Of course a parameter block can just have a single parameter.
The term $ \rho_i\left(\left\|f_i\left(x_{i_1},\hdots,x_{i_k}\right)\right\|^2\right)$ is known as a Residual Block. A Ceres problem is a collection of residual blocks, each of which depends on a subset of the parameter blocks.
Solving problems using Ceres consists of two steps.
\begin{enumerate}
\item{Modeling} Define parameter blocks and residual blocks and build a \texttt{Problem} object containing them.
\item{Solving} Configure and run the solver.
\end{enumerate}
These two steps are mostly independent of each other. This is by design. Modeling the optimization problem should not depend on how the solver and the user should be able to switch between various solver settings and strategies without changing the way the problem is modeled. In the next two chapters we will consider each of these steps in detail.