Refactored controller pages and added controller subsection.

docs/developer-guide/rosplane/controller-state-machine.md

@@ -8,7 +8,7 @@ In the default implementation this is controlled based on the aircraft's altitud
 Though, in practice these states could be effected by any input from a ROS topic.
 The states are pictured below, and the differences in state are explored in the next section.
 
-| ![Diagram of Controller State Machine](../../assets/Controller_state_machine.png "Controller State Machine") |
+| ![Diagram of Controller State Machine]( "Controller State Machine") |
 |:--:|
 |*Figure 1: Controller state machine.*|
 
@@ -44,7 +44,7 @@ The state machine's architecture allows for different aspects of the control to
 It simply defines a virtual method to be implemented by a child that will control during the particular state the aircraft is in.
 The state method is implemented in the child, only using the controls necessary for that phase of flight (see the Architecture section of the [Successive Loop Closure](./controller-outline.md)).
 
-| ![Code for State Machine](../../assets/State_Machine_code.png "Controller State Machine Code") |
+| ![Code for State Machine](../../assets/controller_assets/State_Machine_code.png "Controller State Machine Code") |
 |:--:|
 |*Figure 2: Code snippet from the state machine.*|
 

docs/developer-guide/rosplane/controller-base.md → docs/developer-guide/rosplane/controller/controller-base.md

@@ -10,7 +10,7 @@ The idea of the base class, is that all interfacing with ROS and shared resource
 
 The controller base has the following ROS interactions.
 
-| ![Diagram of Controller ROS Interactions](../../assets/Controller_ROS.png "Controller ROS Interactions") |
+| ![Diagram of Controller ROS Interactions](../../../assets/controller_assets/Controller_ROS.png "Controller ROS Interactions") |
 |:--:|
 |*Figure 1: Controller's ROS interactions.*|
 
@@ -29,8 +29,7 @@ Note, the command message is from the `rosflight_msgs` package.
 
 ## Parameter Management
 
-<!-- TODO: add info about parameter manager. -->
-See the Parameter Management page for more details on how parameter management works.
+See the [Parameter Management](../parameter-management.md) page for more details on how parameter management works.
 
 ### List of Parameters
 

docs/developer-guide/rosplane/controller-general-overview.md → docs/developer-guide/rosplane/controller/controller-general-overview.md

@@ -11,7 +11,7 @@ To gain the best understanding of the Controller and its role, read chapter 1 of
 
 ## Interfaces
 
-| ![Diagram of Controller ROS Interactions](../../assets/Controller_ROS.png "Controller ROS Interactions") |
+| ![Diagram of Controller ROS Interactions](../../../assets/controller_assets/Controller_ROS.png "Controller ROS Interactions") |
 |:--:|
 |*Figure 1: Controller's ROS interactions.*|
 

docs/developer-guide/rosplane/controller-outline.md → docs/developer-guide/rosplane/controller/controller-outline.md

@@ -61,7 +61,7 @@ Since the inner loop is tuned first and influences the outer loop tune, we will
 <!-- TODO Add phi_ff to the mix -->
 <!-- TODO Fix typo in /chi on the left, should be /chi^c -->
 
-| ![Diagram of Lateral-directional Autopilot control loop](../../assets/figure_6_5.png "Lateral-directional Autopilot Control Loop") |
+| ![Diagram of Lateral-directional Autopilot control loop](../../../assets/controller_assets/figure_6_5.png "Lateral-directional Autopilot Control Loop") |
 |:--:|
 |*Figure 1: Lateral-directional Autopilot Control Loop*|
 
@@ -97,7 +97,7 @@ A washout filter is used to only damp high frequency yaw rates.
 In effect, this control only 'turns on' if the frequency of the yaw rate is high enough.
 For mor information see the Yaw Damper page.
 
-| ![Diagram of Yaw Damper loop](../../assets/yaw_damper_diag.png "Yaw damper control loop diagram.") |
+| ![Diagram of Yaw Damper loop](../../../assets/controller_assets/yaw_damper_diag.png "Yaw damper control loop diagram.") |
 |:--:|
 |*Figure 2: Yaw Damper Control Loop*|
 
@@ -112,7 +112,7 @@ The altitude loop utilizes successive loop closure to control altitude.
 It uses the elevator to control the pitch of the aircraft, and then controls using commanded pitch the altitude.
 This loop can track step and ramp commands.
 
-| ![Diagram of Altitude loop](../../assets/Altitude_control_loop.png "Altitude control loop diagram.") |
+| ![Diagram of Altitude loop](../../../assets/controller_assets/Altitude_control_loop.png "Altitude control loop diagram.") |
 |:--:|
 |*Figure 3: Altitude Control Loop*|
 
@@ -142,7 +142,7 @@ It generates the required throttle, $\delta_t$, to acheive the commanded airspee
 This is suffecient because of the natural damping of the drag on the aircraft.
 In practice, the loop performs well, but is prone to small fluctuations (on the order of $\pm 1 \frac{m}{s}$) due to the differential pressure sensor fluctuating because of wind and other disturbances.
 
-| ![Diagram of Airspeed loop](../../assets/Airspeed_loop.png "Airspeed control loop.") |
+| ![Diagram of Airspeed loop](../../../assets/controller_assets/Airspeed_loop.png "Airspeed control loop.") |
 |:--:|
 |*Figure 4: Airspeed using throttle control loop*|
 
@@ -167,22 +167,22 @@ The Successive Loop Closure Controller (SLCC) inherits from the state machine cl
 This state function is then populated with the desired control during each phase of flight (see [State Machine](./controller-state-machine.md) for more details on control during each state).
 The state functions split control into longitudinal and lateral control, this allows for inheritance of this class an only override longitudinal or lateral control (see [Total Energy Control](./controller-outline.md) for an example of how this is done).
 
-| ![Code Snippet for State Function](../../assets/SLCC_code.png "Code Snippet of State Function") |
+| ![Code Snippet for State Function](../../../assets/controller_assets/SLCC_code.png "Code Snippet of State Function") |
 |:--:|
 |*Figure 5: An example of an implementation of a state function, in this case the altitude hold state.*|
 
 The lateral and longitudinal control functions activate particular control loops necessary.
 
 
-| ![Code Snippet for a Control](../../assets/control_loop_example.png "Code Snippet for Lat/Long Control") |
+| ![Code Snippet for a Control](../../../assets/controller_assets/control_loop_example.png "Code Snippet for Lat/Long Control") |
 |:--:|
 |*Figure 6: An example of an implementation of a lateral and longitudinal control, in this case during the altitude hold state.*|
 
 Each control loop gets its own function and it follows a specific format.
 This format is pictured below, but a full outline is given in the .cpp file for the SLCC.
 Note all of the PID is implemented but the gains if not using a particular control (proportional/derivative/integral) are zero.
 
-| ![Code Snippet for a Control Loop](../../assets/control_loop_example.png "Code Snippet for a Control Loop") |
+| ![Code Snippet for a Control Loop](../../../assets/controller_assets/control_loop_example.png "Code Snippet for a Control Loop") |
 |:--:|
 |*Figure 7: An example of an implementation of a control loop, in this case the roll loop (inner course loop).*|
 

docs/developer-guide/rosplane/controller-software-architecture.md → docs/developer-guide/rosplane/controller/controller-software-architecture.md

@@ -22,7 +22,7 @@ This layer calculates the control errors and necessary actuator deflections to t
 
 <center>
 
-| ![Diagram of Controller Inheritance](../../assets/Controller_classes.png "Controller Class Inheritance") |
+| ![Diagram of Controller Inheritance](../../../assets/controller_assets/Controller_classes.png "Controller Class Inheritance") |
 |:--:|
 |*Figure 1: Controller class inheritance structure.*|
 
@@ -35,7 +35,7 @@ This page does go over the basics of how to implement a controller changes in te
 
 ## Implementing A New Controller 
 
-| ![Diagram of Controller Implementation](../../assets/Implementing_new_controller.png "Options for Implementing New Controller") |
+| ![Diagram of Controller Implementation](../../../assets/controller_assets/Implementing_new_controller.png "Options for Implementing New Controller") |
 |:--:|
 |*Figure 2: Options for implementing a new controller.*|
 
@@ -59,7 +59,7 @@ These edits are as follows:
 
 <center>
 
-| ![CMakeLists Controller Exe](../../assets/CMakeLists_controller.png "CMakeLists.txt controller executable location.") |
+| ![CMakeLists Controller Exe](../../../assets/controller_assets/CMakeLists_controller.png "CMakeLists.txt controller executable location.") |
 |:--:|
 |*Figure 3: Location in `CMakeLists.txt` to add the new controller's `.cpp` file(s).*|
 
@@ -69,7 +69,7 @@ These edits are as follows:
 
 <center>
 
-| ![Controller Base Include](../../assets/controller_base_include.png "Include in Controller Base") |
+| ![Controller Base Include](../../../assets/controller_assets/controller_base_include.png "Include in Controller Base") |
 |:--:|
 |*Figure 4: Location in `controller_base.cpp` to import new controller's header file.*|
 
@@ -79,7 +79,7 @@ These edits are as follows:
 
 <center>
 
-| ![Controller Base Main](../../assets/controller_base_main.png "Main in Controller Base") |
+| ![Controller Base Main](../../../assets/controller_assets/controller_base_main.png "Main in Controller Base") |
 |:--:|
 |*Figure 5: Location in `controller_base.cpp` to add option to select control type.*|
 

docs/developer-guide/rosplane/controller/controller-state-machine.md

@@ -0,0 +1,57 @@
+# Controller State Machine
+
+## State Machine Overview
+
+The controller state machine uses discrete states to turn on and off particular controls for a more stable flight.
+These regimes are designed so that particular mission objectives are only activated when particular conditions are met.
+In the default implementation this is controlled based on the aircraft's altitude.
+Though, in practice these states could be effected by any input from a ROS topic.
+The states are pictured below, and the differences in state are explored in the next section.
+
+| ![Diagram of Controller State Machine](../../../assets/controller_assets/Controller_state_machine.png "Controller State Machine") |
+|:--:|
+|*Figure 1: Controller state machine.*|
+
+## States 
+
+This section describes all of the states and what control is active during that phase of flight.
+
+### Takeoff
+
+In the takeoff state, the commanded airspeed is set to cruise, the commanded pitch is held constant and roll is controlled to zero.
+This results in a steady takeoff directly along the runway.
+The deactivation of course control means that the aircraft will not attempt to maneuver while too close to the ground.
+The takeoff regime is only below a certain cutoff altitude.
+After passing this threshold it moves into the climb state.
+
+### Climb 
+
+The climb state commands altitude and airspeed as normal, but still controls roll to zero.
+This means that the aircraft will proceed directly ahead until it is withing a cutoff (see Params section) of commanded altitude.
+Deactivating course control allows for the aircraft to gain enough altitude to be clear of all obstacles before attempting to follow the waypoint mission.
+Once within a cutoff of the commanded altitude, the state transitions to altitude hold.
+If the aircraft dips beneath the takeoff threshold, it will enter the takeoff state again.
+
+### Altitude Hold
+
+In altitude hold all control loops are closed normally. 
+The aircraft will fly the waypoint mission as normal.
+If the aircraft dips beneath the takeoff cutoff, the state transitions to takeoff again.
+
+## Code Architecture
+
+The state machine's architecture allows for different aspects of the control to be modified.
+It simply defines a virtual method to be implemented by a child that will control during the particular state the aircraft is in.
+The state method is implemented in the child, only using the controls necessary for that phase of flight (see the Architecture section of the [Successive Loop Closure](./controller-outline.md)).
+
+| ![Code for State Machine](../../../assets/controller_assets/State_Machine_code.png "Controller State Machine Code") |
+|:--:|
+|*Figure 2: Code snippet from the state machine.*|
+
+## Parameters
+
+
+| Parameter | Explanation | Range |
+|:--:|:--:|:--:|
+| alt_toz | The altitude of the takeoff zone cutoff. | $\geq 0.0$ (double) |
+| alt_hz | The altitude command saturation limit, and difference required to transition into altitude hold. | $\geq 0.0$ (double) |

mkdocs.yml

@@ -70,11 +70,12 @@ nav:
       - Unit Tests: developer-guide/firmware/unit-tests.md
       - Debugging: developer-guide/firmware/debugging.md
     - ROSplane:
-      - General Controller Overview: developer-guide/rosplane/controller-general-overview.md
-      - Controller Software Architecture: developer-guide/rosplane/controller-software-architecture.md
-      - Controller Base: developer-guide/rosplane/controller-base.md
-      - Controller State Machine: developer-guide/rosplane/controller-state-machine.md
-      - Successive Loop Closure Controller Outline: developer-guide/rosplane/controller-outline.md
+      - Controller:
+        - General Controller Overview: developer-guide/rosplane/controller/controller-general-overview.md
+        - Controller Software Architecture: developer-guide/rosplane/controller/controller-software-architecture.md
+        - Controller Base: developer-guide/rosplane/controller/controller-base.md
+        - Controller State Machine: developer-guide/rosplane/controller/controller-state-machine.md
+        - Successive Loop Closure Controller Outline: developer-guide/rosplane/controller/controller-outline.md
       - Parameter Management: developer-guide/rosplane/parameter-management.md
 #    - ROS Packages:
 #    - ROSplane: