# Estimation of Antenna Pose in the Earth Frame Using Camera and IMU Data from Mobile Phones
## 3 Problem Formulation and Method Overview
### Notation and Problem Formulation  
As described in the Introduction, the number of different antenna types in use is quite limited, and therefore, it is reasonable to assume a known 3D antenna geometry once we have identified the antenna type from the acquired images. Let this geometry be denoted by \(\mathcal{M}\), and let us assume that the bounding box of the model is centered at the origin point of the object frame (\(OF\)) and that its three axes are aligned with the axes of \(OF\), without loss of generality. In each of the multi-view images, the antenna (treated as the foreground) is represented by a contour expressed as a list of connected points, denoted by \(\Phi_{i},i=1,2,...,P\), where \(P\) is the number of viewpoints. Such contours can be the outputs of a procedure based on image segmentation, shape detection or human interaction during image capture; we do not discuss this procedure here. This representation discards any textural information and interior shape information for an antenna, making it generally impossible to obtain a unique pose solution from a single viewpoint. Nevertheless, we opt to simply ignore these two kinds of information because of their instability, as demonstrated in Figure 1. Instead, contours captured from multiple viewpoints enable the determination of a unique solution. The 3D mesh \(\mathcal{M}\) and the 2D images are related by camera projections. We model the phone camera as a pin-hole camera, which maps \(\mathcal{M}\) first from \(OF\) into the camera frame (\(CF\)) via an unknown rigid transformation \(\big{(} \begin{matrix}\mathbb{C}R\\ \mathbb{C}\end{matrix} , \begin{matrix}\mathbb{C}T\\ \mathbb{C}\end{matrix} \big{)}\) and then into the image plane via a perspective function. The projective function is determined by a set of intrinsic parameters of the camera, denoted by \(K\), which is taken to consist of known constants for a pre-calibrated camera. In addition to the images, the other important half of the multi-view data consists of the IMU measurements, which encode the orientations of the IMU in the Earth frame (\(EF\)) when the images were captured. The directions of gravity and magnetic north at a given point on Earth define \(EF\) in that location, and the accelerometer and magnetometer sensors of the IMU respond to the gravitational force and magnetic flux, yielding their projections onto the sensor axes. We let \(S_{i}=(a_{i},\ m_{i})\), \(i=1,2,\ldots,P\), denote the overall IMU measurements, where \(a_{i}\) denotes an accelerometer measurement and \(m_{i}\) denotes a magnetometer measurement. To ensure an accurate formulation of the problem, there are two small misalignments that we should consider. First, the accelerometer frame, denoted as \(A\), should ideally coincide with the magnetometer frame, denoted as \(M\), such that the orientation of the IMU in \(EF\) can be determined from the outputs of these two sensors (e.g., [52]). However, because the sensor hardware usually resides on different chipsets in a mobile phone, a small rotation may exist between the two sensor frames. Moreover, other environmental factors (especially magnetic factors) may affect the rotation of each sensor frame, thereby worsening the misalignment. Let this unknown rotation be denoted by \({}^{A}_{M}\!R\), which we can then use to re-align \(A\) and \(M\) once it is known. For convenience, we also regard \(A\) as the overall IMU frame (_IF_) when doing so will not cause confusion. Second, the frames of the camera module and IMU module in a mobile phone should also ideally be perfectly aligned, differing only by exchanges in the directions of the axes, which is also generally not true in reality. We describe the true relation as a rigid transformation \((\,{}^{A}_{CR},\,{}^{A}_{T})\) (or \((\,{}^{I}_{CR},\,{}^{I}_{T})\)), and although it is easy to obtain an approximation of the relative pose between the camera and IMU frames from the mobile phone API, finding the precise transformation requires greater effort.