Ch 7 auto-index

S66_driving_DRL.ipynb

@@ -85,8 +85,8 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "```{index}lateral control, longitudinal control",
-    "```",
+    "```{index}lateral control, longitudinal control\n",
+    "```\n",
     "A simple example in the autonomous driving domain is *lane switching*. Suppose we are driving along at 3-lane highway, and we can see some ways ahead, and some ways behind us. We are driving at a speed that is comfortable to us, but other cars have different ideas about the optimal speed to drive at. Hence, sometimes we would like to change lanes, and we could learn a policy to do this for us. As discussed in Section 6.5, this is **lateral control**. A more sophisticated example would also allow us to adapt our speed to the traffic pattern, but by relying on a smart cruise control system we could safely ignore the **longitudinal control** problem."
    ]
   },
@@ -136,8 +136,8 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "```{index}execution phase, experience replay",
-    "```",
+    "```{index}execution phase, experience replay\n",
+    "```\n",
     "In the **deep Q-network** or DQN method we use a *supervised learning* approach to Q-learning, by training a neural network, parameterized by $\\theta$, to approximate the optimal Q-values:\n",
     "\n",
     "$$\n",
@@ -170,9 +170,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "```{index}stochastic policy",
-    "```",
-    "```{index} deep reinforcement learning; policy optimization\n",
+    "```{index} stochastic policy, deep reinforcement learning; policy optimization\n",
     "```\n",
     "\n",
     "## Policy Optimization\n",
@@ -204,8 +202,6 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "```{index}policy optimization",
-    "```",
     "In **policy optimization** we gather data by rolling out a set of trajectories $\\tau_i$. In supervised learning we have a dataset $D$ and labels $y_c$, but we have to proceed a bit differently in a reinforcement learning setting. In particular, for *on-policy* RL we gather data by executing our current best guess for the policy for some rollout length or horizon $H$, and we do this many different times starting from different initial conditions, each time obtaining a *trajectory* $\\tau_i$.\n",
     "That still leaves the training signal: where does that come from? \n",
     "The key idea is to estimate how good a particular action is by estimating the state-action values $Q$ from the roll-out rewards.\n",

S70_drone_intro.ipynb

@@ -21,6 +21,8 @@
     "id": "nAvx4-UCNzt2"
    },
    "source": [
+    "```{index}Unmanned aerial vehicles, micro aerial vehicles, 3D reconstruction, trajectory optimization",
+    "```",
     "**Unmanned aerial vehicles** (UAVs) take autonomy into the next dimension: into three dimensions, to be exact. Whereas autonomous vehicles are bound to earth, UAVs take to the air. Hence, their perception and planning problems are fundamentally harder in a geometric sense. On the other hand, our airspace is currently much sparser than our roads are, and thus dynamic obstacle avoidance is less of an issue.\n",
     "\n",
     "In this chapter we will concentrate on a very popular class of UAVs: quadrotors. These are craft equipped with four actuated rotors that allow for very simple control algorithms, yet can achieve very agile flight. Because quadrotors are cheap to manufacture and there is a large market for camera drones, most quadrotor vehicles have a rather small form factor and are designed to be easily portable. Sometimes this segment of the UAV market is designated as **micro aerial vehicles** or MAVs, a term we will use throughout this chapter.\n",

S71_drone_state.ipynb

@@ -69,6 +69,8 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
+    "```{index}navigation frame, body frame\n",
+    "```\n",
     "In Section 6.1 we introduced the space of 2D rigid transformations $SE(2)$, and showed how $3 \\times 3$ matrices can be used to simultaneously represent \n",
     "rotation and translation in two dimensions.\n",
     "At that time, we promised that this could be easily generalized to the case of rotation and\n",
@@ -184,6 +186,8 @@
    "id": "eede1a83",
    "metadata": {},
    "source": [
+    "```{index}special Euclidean group\n",
+    "```\n",
     "## 3D Rigid transforms aka SE(3)\n",
     "\n",
     "In a similar way we can extend the group of 2D rigid transforms $SE(2)$ to the case\n",
@@ -243,17 +247,19 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
+    "```{index}noncommutative group\n",
+    "```\n",
     "## The Group $SE(3)$\n",
     "\n",
     "> $SE(3)$ is a non-commutative group.\n",
     "\n",
     "Unsurprisingly, $SE(3)$ is also a group, as the following properties all hold:\n",
     "\n",
-    "1. **Closure**: For all transforms $T, T' \\in SE(3)$, their product is also in $SE(3)$, i.e., $T T' \\in SE(3)$.\n",
-    "2. **Identity**: The $4\\times 4$ identity matrix $I$ is included in the group, and for\n",
+    "1. *Closure*: For all transforms $T, T' \\in SE(3)$, their product is also in $SE(3)$, i.e., $T T' \\in SE(3)$.\n",
+    "2. *Identity*: The $4\\times 4$ identity matrix $I$ is included in the group, and for\n",
     "all $T \\in SE(3)$ we have $T I = I T = T$.\n",
-    "3. **Inverse**: For every $T \\in SE(3)$ there exists $T^{-1} \\in SE(3)$ such that $T^{-1}T = T T^{-1} = I$.\n",
-    "4. **Associativity**: For all $T_1, T_2, T_3 \\in SE(3)$, $(T_1 T_2) T_3 = T_1 (T_2 T_3)$.\n",
+    "3. *Inverse*: For every $T \\in SE(3)$ there exists $T^{-1} \\in SE(3)$ such that $T^{-1}T = T T^{-1} = I$.\n",
+    "4. *Associativity*: For all $T_1, T_2, T_3 \\in SE(3)$, $(T_1 T_2) T_3 = T_1 (T_2 T_3)$.\n",
     "\n",
     "The inverse $T^{-1}$ is given by:\n",
     "\n",
@@ -380,6 +386,8 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
+    "```{index}linear velocity, skew symmetric matrix, hat operator\n",
+    "```\n",
     "##  Velocity\n",
     "\n",
     ">Velocity comes in two flavors: linear and angular.\n",
@@ -428,6 +436,8 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
+    "```{index}angular velocity\n",
+    "```\n",
     "Skew symmetric matrices play a key role in representing the angular rate of change of coordinate frames.\n",
     "Let $R(t)$ be a time-varying rotation matrix.\n",
     "Because $R(t) \\in SO(3)$, at each time $t$ we have $R^T(t) R(t) = I$.\n",

S72_drone_actions.ipynb

@@ -85,6 +85,8 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
+    "```{index}navigation frame, body frame, FLU convention\n",
+    "```\n",
     "The dynamics and kinematics of quadrotors and in general *multi*-rotor aircraft are those of simple rigid 3D bodies. Many different coordinate frame conventions are used in the literature. We introduce one good choice below, and convert equations from the literature to this convention where needed.\n",
     "\n",
     "The equations for control and navigation we develop below are most useful when expressed in a local **navigation frame** $N$. For MAV applications this frame is almost always assumed to be non-rotating and aligned with gravity, but can otherwise be defined arbitrarily.\n",
@@ -232,6 +234,8 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
+    "```{index}drag, drag coefficient\n",
+    "```\n",
     "### Drag and Maximum Velocity\n",
     "\n",
     "When drones fly through the air, they encounter air resistance, also known as **drag**, which\n",
@@ -318,6 +322,8 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
+    "```{index}kinematics, statics, dynamics, linear velocity\n",
+    "```\n",
     "## Drone Kinematics\n",
     "\n",
     "The subject of **kinematics** deals exclusively with positions and velocities, not the forces and accelerations involved to obtain those velocities. Kinematics should be contrasted with **statics** or steady-state force reasoning as we did above, and **dynamics** which describes the changing forces and accelerations over time.\n",
@@ -335,6 +341,8 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
+    "```{index}angular velocity, roll, pitch, yaw\n",
+    "```\n",
     "### Angular Velocity\n",
     "\n",
     "Just as we have a linear velocity $v^n$, a three-vector, we also have a 3-dimensional **angular velocity** $\\omega$,\n",
@@ -432,6 +440,8 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
+    "```{index}forward Euler method, backward Euler method, trapezoidal method\n",
+    "```\n",
     "### Integrating Position\n",
     "\n",
     "The above is exact, but when implementing this in code we need to use a numerical integration scheme. For position, the simplest integration scheme is the **forward Euler method**\n",
@@ -650,13 +660,15 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
+    "```{index}torque, mass, inertia matrix\n",
+    "```\n",
     "## Full Rigid-Body Dynamics\n",
     "\n",
     "> Not hard to write down, but harder to understand.\n",
     "\n",
     "Ultimately we need to move a quadrotor by provide forces through the four rotors.\n",
     "Above we have discussed the forces that are applied by the rotors.\n",
-    "We now extend this idea to include **torques**, which are the rotational version of forces.\n",
+    "We now extend this idea to include **torque**, which is the rotational version of force.\n",
     "The combination of forces and torques yield corresponding linear and angular accelerations.\n",
     "\n",
     "Let us start with Newton's second law, with the acceleration $a$ written suggestively as $\\dot{v}^n$, and immediately thinking in terms of force and velocity *vectors* in the navigation frame:\n",

S73_drone_sensing.ipynb

@@ -76,18 +76,22 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
+    "```{index}pair: inertial measurement unit; IMU\n",
+    "```\n",
     "```{index} sensing; inertial\n",
     "```\n",
     "\n",
     "## Inertial Measurement Units\n",
     "\n",
-    "**Inertial measurement units** (IMUs) measure how a rigid body moves through space, and have undergone revolutionary transformations since their invention. Whereas they were initially developed for military and later civilian navigation purposes, miniaturized (MEMS) versions of them are now built into most of the mobile computing devices people use every day. IMUs often bundle the following three sensors: gyroscopes, accelerometers, and magnetometers, which we discuss in turn below."
+    "An **inertial measurement unit** or **IMU** measures how a rigid body moves through space. The technological development of IMUs has undergone revolutionary transformations since their invention. Whereas they were initially developed for military and later civilian navigation purposes, miniaturized (MEMS) versions of them are now built into most of the mobile computing devices people use every day. IMUs often bundle the following three sensors: gyroscopes, accelerometers, and magnetometers, which we discuss in turn below."
    ]
   },
   {
    "cell_type": "markdown",
    "metadata": {},
    "source": [
+    "```{index}gyroscope, bias\n",
+    "```\n",
     "### Gyroscopes\n",
     "\n",
     "A **gyroscope** measures *changes* in orientation around three orthogonal axes, i.e., an angular velocity $\\omega$.\n",
@@ -110,6 +114,8 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
+    "```{index}accelerometer\n",
+    "```\n",
     "### Accelerometers\n",
     "\n",
     "An **accelerometer** measures linear acceleration in 3D. While GPS can provide a measurement of the absolute position $r^n(t)$ of a drone, provided one is outdoors and in an open area, the errors associated with GPS are often large. Accelerometers are much more precise, but unfortunately do not provide absolute position: because they measure *forces* exerted upon them, any measurement they provide is essentially an acceleration, i.e., the second derivative of position. Hence, of course, the name \"accelerometer\".\n",
@@ -139,14 +145,16 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
+    "```{index}visual odometry, localization, visual SLAM, extrinsic calibration\n",
+    "```\n",
     "```{index} sensing; stereo\n",
     "```\n",
     "\n",
     "## Cameras\n",
     "\n",
     "The second frequently used sensor for drones is a camera, or multiple cameras. Cameras are light-weight, cheap, and they provide some amazing capabilities, which we will discuss below and in the next section. They are also *passive*, in that unlike LIDAR sensors, they do not send out energy into the environment. This has obvious benefits in terms of stealth, important in some applications, but also is less power-hungry. In drones, battery autonomy is one of the key design constraints, and cameras are a very popular sensor for that reason alone.\n",
     "\n",
-    "By tracking features in the image(s) over time, cameras can provide relative motion measurements, i.e., **visual odometry**. Given a preexisting map of the environment, a camera can be used to **localize**, providing absolute orientation and position even without an IMU. *If* an IMU is available it can be used to track the high frequency *relative* motion of the drone, while the visual information provides a lower frequency but *absolute* measurement of the drone's pose. In that way, IMU and camera measurements are perfectly complementary. In addition, if no map is available, cameras can be used to build a 3D map of the environment in real time, using a paradigm called **visual SLAM**, which we will discuss below.\n",
+    "By tracking features in the image(s) over time, cameras can provide relative motion measurements, i.e., **visual odometry**. Given a preexisting map of the environment, a camera can be used to perform *localization*, providing absolute orientation and position even without an IMU. *If* an IMU is available it can be used to track the high frequency *relative* motion of the drone, while the visual information provides a lower frequency but *absolute* measurement of the drone's pose. In that way, IMU and camera measurements are perfectly complementary. In addition, if no map is available, cameras can be used to build a 3D map of the environment in real time, using a paradigm called **visual SLAM**, which we will discuss below.\n",
     "\n",
     "In this section, about the raw sensing, we will concentrate on the **extrinsic calibration** of cameras and camera rigs. \n",
     "We have already discussed cameras as sensors in section 5.2, including their *intrinsic* calibration parameters such as focal length, image center, etc.\n",

S74_drone_perception.ipynb

@@ -86,11 +86,13 @@
     }
    },
    "source": [
+    "```{index}pair: structure from motion; SfM\n",
+    "```\n",
     "Visual SLAM *almost* the same problem as the \"SLAM with Landmarks\" problem from Section 6.4, but we will now use 3D poses and 3D points, and we will use the inertial measurements from the IMU to inform us about the movement of the platform. This is a typical pipeline on drones, phones, etc., everything with an IMU. \n",
     "\n",
     "Many unmanned aerial vehicles use cameras as their main sensors in addition to inertial sensing, as they are an incredibly rich sensing modality, do not consume a whole lot of energy, and are quite small. Especially the latter two considerations are very important in the weight and energy constrained world of autonomous drones. Furthermore, in military applications there is another reason to favor cameras over active sensors like LIDAR: cameras do not *emit* energy and hence are stealthier.\n",
     "\n",
-    "Below we first introduce how we can estimate the trajectory of a drone using an inertial measurement unit or IMU, which we introduced in Section 7.2. Here we integrate IMU measurements over time to yield an estimate of the trajectory of the drone over time. Below that we discuss how we can build 3D maps from images alone (!), in a process called **Structure from Motion** or SfM. We then discuss Visual SLAM, which combines both IMU integration and SfM in a real-time, incremental pipeline. Implementing visual SLAM is beyond our scope, but it should be easy to imagine how inertial sensing and 3D reconstruction done together and in real-time is an incredible asset to autonomous flight."
+    "Below we first introduce how we can estimate the trajectory of a drone using an inertial measurement unit or IMU, which we introduced in Section 7.2. Here we integrate IMU measurements over time to yield an estimate of the trajectory of the drone over time. Below that we discuss how we can build 3D maps from images alone (!), in a process called **structure from motion** or **SfM**. We then discuss Visual SLAM, which combines both IMU integration and SfM in a real-time, incremental pipeline. Implementing visual SLAM is beyond our scope, but it should be easy to imagine how inertial sensing and 3D reconstruction done together and in real-time is an incredible asset to autonomous flight."
    ]
   },
   {
@@ -700,6 +702,8 @@
     }
    },
    "source": [
+    "```{index}Bundle Adjustment\n",
+    "```\n",
     "SfM is almost the same problem as Visual SLAM, but typically there is no odometry information to relate\n",
     "different camera views. The resulting optimization problem is sometimes called **Bundle Adjustment**. \n",
     "The most difficult problems associated with SfM are feature detection, data association, and initializing the optimization.\n",