Fixes heading levels so that they progress correctly (#131)

* Fixes NUClear's heading levels

* Fixes input page heading levels

* Fixes motion page heading levels

* Fixes vision page heading levels

* Fix behaviour head levels

* Fix logging heading levels

* Fixes NUgan heading levels

* Fixes uneven heading levels in NUpbr

* Update headings in Kitchen Sink pages

Co-authored-by: Josephus Paye II <j.paye96@gmail.com>

src/book/02-system/01-foundations/04-nuclear.mdx

@@ -10,27 +10,27 @@ NUClear is the software framework used in the main NUbots codebase. It is a mess
 
 This page is intended to be a practical summary of the official [NUClear documentation](https://nuclear.readthedocs.io/en/latest/), which contains a detailed description of NUClear. The [NUClear Roles repository](https://github.com/Fastcode/NUClearRoles) contains a detailed description of the NUClear roles system, much of which the [roles section](#nuclear-roles) in this page is based off.
 
-# Components
+## Components
 
-## PowerPlant
+### PowerPlant
 
 ![A collection of Reactors around the PowerPlant in the center. Double ended arrows point to and from the PowerPlant to each Reactor.](images/power_plant.svg 'PowerPlant with Reactors. Image: https://nuclear.readthedocs.io/en/latest/components.html')
 
 The PowerPlant is the central message system through which reactors communicate. It takes ownership of any data emitted by reactors into the system and executes the required reactions. NUClear is [multi-threaded](<https://en.wikipedia.org/wiki/Multithreading_(computer_architecture)>). The PowerPlant handles all threading logic.
 
-## Reactors
+### Reactors
 
 A reactor can be thought of as a module. All modules in the NUClear system are an extension of `NUClear::Reactor`. Reactors define reactions and the conditions under which they will process. They may also emit data to the PowerPlant.
 
-## Reactions and Tasks
+### Reactions and Tasks
 
 Reactions run tasks when the required data is available and/or when certain conditions are true. A task is the current execution of a defined reaction within the system. These functions are bound by NUClear as callbacks, and it is the execution of these callbacks which will assign tasks to a thread.
 
 Reactions are created by subscribing to the PowerPlant through [DSL On Statements](#on-statements).
 
-# NUClear DSL
+## NUClear DSL
 
-## On Statements
+### On Statements
 
 Reactors make subscriptions to the PowerPlant using on statements, which define the conditions for reactions to run.
 
@@ -42,7 +42,7 @@ on<...>(...).then(...);
 
 This can be split into three parts. The first is the `on<...>` which is the DSL request. The `(...)` contains any runtime arguments. `.then(...);` is the callback, which is what will be executed when the reaction is triggered.
 
-### DSL Request
+#### DSL Request
 
 The DSL request is "fused" together by combining any number of DSL words. The combination of these words will define the kind of reaction which is being requested. For example, `Trigger` will define a reaction that should occur when a required data type is emitted, while `Every` will define periodic reactions.
 
@@ -68,13 +68,13 @@ For reactions to occur, at least one Binding DSL word should be present in the D
 
 More information on DSL words for on statements can be found in the [NUClear documentation](https://nuclear.readthedocs.io/en/latest/dsl.html#on-statements).
 
-### Runtime arguments
+#### Runtime arguments
 
 Some DSL words will provide the ability to make changes to the system during runtime. This means that NUClear avoids the need for a system restart should a configuration, port number, or file need to be changed while the system is running.
 
 The DSL words that take runtime arguments are: `IO`, `TCP`, `UDP` and `Configuration`.
 
-### Callback
+#### Callback
 
 The callback which will execute when the reaction is triggered during runtime can be defined using a C++ lambda function. These are of the form
 
@@ -94,15 +94,15 @@ on<Trigger<dataType>>().then([this](const dataType& value) {
 
 Capturing the `this` pointer will allow your reaction to access other members of your `Reactor` (e.g. configuration data).
 
-## Emit Statements
+### Emit Statements
 
 Emit statements are used by Reactors wanting to emit data to the PowerPlant. When using NUClear, data will most likely be emitted during a reaction. However, where necessary, emissions can also occur during reactor construction, or in some cases from within the PowerPlant itself.
 
 Any data emitted to the PowerPlant will be sent with a unique pointer. The PowerPlant will take ownership of this pointer and run any necessary callbacks to trigger reactions.
 
 Data can be emitted under varying scopes. These can be local or network emissions. More information can be found on emit statements in the [NUClear documentation](https://nuclear.readthedocs.io/en/latest/dsl.html#emit-statements).
 
-### Local Emissions
+#### Local Emissions
 
 Local emissions send data to the local instance of the NUClear PowerPlant. Essentially this is the current running process. There are a number of scopes under which these emissions can take place. The syntax for these emissions are `emit<Scope::SCOPE>(data, args...);`, where `SCOPE` is replaced with a scope as defined below.
 
@@ -113,7 +113,7 @@ Local emissions send data to the local instance of the NUClear PowerPlant. Essen
 | INITIALISE | This scope emits data as the system starts up.                                                                                               |
 | DELAY      | This will emit data, after the provided delay. The syntax includes a delay time `emit<Scope::DELAY>(data, delay(ticks));`.                   |
 
-### Network Emitting
+#### Network Emitting
 
 Network emissions can be used to send data through the network on which the current system is running.
 
@@ -122,7 +122,7 @@ Network emissions can be used to send data through the network on which the curr
 | UDP     | Emits data as a UDP packet over the network. Is of the form `emit<Scope::UDP>(data, to_addr, to_port);`.                                                                                                                                                               |
 | NETWORK | Emits data over the network to other NUClear environments. Is of the form `emit<Scope::NETWORK>(data, target, reliable);`. The `reliable` flag, if `true`, will cause NUClear to continue sending the `data` until it receives an `ACK`nowledgement from the `target`. |
 
-# Managing Reactions
+## Managing Reactions
 
 During system runtime, executing reactions can be managed via their associated reaction handles. A reaction handle is provided for binding `on` statements. Once an `on` statement has been bound, the reaction handle will be `enabled`. If necessary, reactions can toggle between `enabled` and `disabled` during runtime.
 
@@ -134,13 +134,13 @@ During system runtime, executing reactions can be managed via their associated r
 | enabled()        | Determines the current status of the reaction. Returns `true` if the reaction is enabled, and `false` otherwise.                                                                         |
 | unbind()         | Removes a reaction request from the runtime environment. This action is not reversible, once a reaction has been unbound, it is no longer available for further use during that runtime. |
 
-# NUClear Roles
+## NUClear Roles
 
 The NUClear Roles system is a build and messaging system for the NUClear framework. It uses [CMake](https://cmake.org/) and [Python](https://www.python.org/) to manage the construction of various executables made up of a selection of modules. These executables are called roles.
 
 CMake is used as the main system for generating the libraries and executables that are used for the final binary. Note that it utilises [globbing](<https://en.wikipedia.org/wiki/Glob_(programming)>) to find the sources that are used for modules. If you add or remove a file, you must rerun CMake to locate the new files.
 
-## Directories
+### Directories
 
 There are six main directories in the NUClear Roles system and can be seen in the main NUbots codebase.
 
@@ -153,7 +153,7 @@ There are six main directories in the NUClear Roles system and can be seen in th
 | `roles`     | contains all the NUClear role files.                                                                                                                                                                |
 | `tools`     | contains any command line extensions for the `b` script, such as `build` and `configure`.                                                                                                           |
 
-## Roles
+### Roles
 
 Roles are executables containing a specified list of modules. They are called `<executablename>.role`, where `<executablename>` is the name of the final binary that will be created.
 
@@ -172,7 +172,7 @@ NUCLEAR_ROLE(
 
 This role file would create an executable with the modules `module::extension::FileWatcher`, `module::support::logging::ConsoleLogHandler` and `module::input::Camera`. This file is a CMake file so you are able to use # to declare comments.
 
-## NBS Files
+### NBS Files
 
 NBS files are NUClear Binary Stream files. To make it easier to serialise streams of messages for storage sharing and playback, NUClear Roles defines a format for serialising messages to files. This format is based on the Neutron messaging system and NUClear's networking protocol. An `nbs` file has the following frames repeated continuously:
 
@@ -200,7 +200,7 @@ NBS files can have an associated index file. This allows for quicker random acce
 
 All values within the index file are little endian.
 
-## Neutrons
+### Neutrons
 
 Reactors emit data in the form of messages called Neutrons. Neutrons are [Protobuf](https://developers.google.com/protocol-buffers) messages in a C++ wrapper. These are all located in the `shared/message/` directory, and have the `.proto` extension. An example is [`WalkCommand.proto`](https://github.com/NUbots/NUbots/blob/105b78ad6655801f5f74d029cbd169ba8e8cb5e8/shared/message/motion/WalkCommand.proto):
 
@@ -217,9 +217,9 @@ message WalkCommand {
 }
 ```
 
-# Examples
+## Examples
 
-## On Statements
+### On Statements
 
 Looking at [`SensorFilter.cpp`](https://github.com/NUbots/NUbots/blob/master/module/platform/darwin/SensorFilter/src/SensorFilter.cpp) we can see some examples of NUClear on statements.
 
@@ -319,7 +319,7 @@ then([this] {
 });
 ```
 
-## Emit Statements
+### Emit Statements
 
 An example of local emission can be seen on line 590 of [`SensorFilter.cpp`](https://github.com/NUbots/NUbots/blob/e7db7154a689ab076041375894b3baf1d53a2587/module/platform/darwin/SensorFilter/src/SensorFilter.cpp#L590) where we call
 

src/book/02-system/02-subsystems/01-input.mdx

@@ -8,7 +8,7 @@ slug: /system/subsystems/input
 
 Input to the system includes cameras, [Game Controller](https://github.com/RoboCup-Humanoid-TC/GameController) and [NatNet](https://optitrack.com/products/natnet-sdk/).
 
-# Cameras
+## Cameras
 
 The cameras have the following parameters that are used by the object detection algorithm.
 

src/book/02-system/02-subsystems/04-motion.mdx

@@ -10,13 +10,13 @@ The motion subsystem contains modules that are responsible for walking, kicking,
 
 The Script Engine is detailed on this page, while Script Runner and Script Tuner can be found on the [Behaviour](/system/subsystems/behaviour#script-runner) page.
 
-# Script Engine
+## Script Engine
 
 Scripts are static motions for the robot. They specify what joint angles to move to and how long the robot should take to get to those joint angles. For example, standing up is a script telling the robot to move its joints to the stand position over one second. There can be many of these position specifications in sequence to make the robot do more complex movements like getting up or kicking.
 
 To learn how to tune scripts, see the [ScriptTuner guide](/guides/main/tuning-and-running-scripts#script-tuner).
 
-## Messages
+### Messages
 
 To execute a script, we emit an "execute script" message describing the script to execute. This message is received in the ScriptEngine, which executes the appropriate script. These are specified in [Script.h](https://github.com/NUbots/NUbots/blob/96357855b059cd499021552b3e25a4b158828dc5/shared/extension/Script.h) as [ExecuteScriptByName](https://github.com/NUbots/NUbots/blob/96357855b059cd499021552b3e25a4b158828dc5/shared/extension/Script.h#L224) and [ExecuteScript](https://github.com/NUbots/NUbots/blob/96357855b059cd499021552b3e25a4b158828dc5/shared/extension/Script.h#L261).
 
@@ -63,7 +63,7 @@ emit(std::make_unique<ExecuteScript>(id, script, NUClear::clock::now()));
 
 The [ScriptEngine](https://github.com/NUbots/NUbots/tree/96357855b059cd499021552b3e25a4b158828dc5/module/motion/ScriptEngine) module receives either of these messages and processes the information for the script. It collects the servo positions and time for each frame and modifies them if needed based on the given duration and start time in the message. The information is then emitted as a [ServoCommand](https://github.com/NUbots/NUbots/blob/cbb5d3ebc2a7c56944ec9afe3f70faf7e2900217/shared/message/behaviour/ServoCommand.proto) message.
 
-## Script files
+### Script files
 
 The script files are YAML files specifying a duration and list of servo targets, in a format like the following:
 

src/book/02-system/02-subsystems/05-vision.mdx

@@ -8,9 +8,9 @@ slug: /system/subsystems/vision
 
 The vision system aims to convert images from a camera in the robot into useful information, such as the position of balls, goal posts, field lines and obstacles. This information is used to determine behaviour and localisation. The vision subsystem includes object detection and post-processing.
 
-# Visual Mesh
+## Visual Mesh
 
-## Algorithm
+### Algorithm
 
 The [Visual Mesh](https://doi.org/10.1007/978-3-030-27544-0_4) underpins the vision system and is used for sparse **detection** of balls, points on the field, field lines, goal posts and other robots. It is an **input transformation** that uses knowledge of a camera's orientation and position relative to an observation plane to increase the performance and accuracy of a **convolutional neural network**. It utilises the **geometry of objects** to create a **mesh structure** that gives high accuracy of detection regardless of the distance to the object.
 
@@ -24,21 +24,21 @@ The mesh constructed is **one possible mesh**. Various meshes can be created wit
 
 ![A soccer field with a segmentation overlay of different colours based on features and objects in the scene.](./images/vision-green-horizon-balls-detections.png 'The classifications from the Visual Mesh neural network.')
 
-## Implementation
+### Implementation
 
 The Visual Mesh implementation can be [found on GitHub](https://github.com/Fastcode/VisualMesh). It has implementations for using **circle, spherical or cylinder geometry** for the mesh. The Visual Mesh implementation uses **TensorFlow** for training. The Visual Mesh can be used with the **CPU engine** with C++ code or it can be used with the **OpenCL engine** on CPUs and many GPUs.
 
 In the NUbots codebase, the Visual Mesh is used in the [Visual Mesh module](https://github.com/NUbots/NUbots/tree/master/module/vision/VisualMesh). **Network biases and weights** are found in the **configuration file** in the module, along with other Visual Mesh parameters such as geometry type. The module receives an **Image message** from the Camera module, detailed above, and inputs it into the Visual Mesh. The resulting **mesh and classifications** are output as a [VisualMesh message](https://github.com/NUbots/NUbots/blob/master/shared/message/vision/VisualMesh.proto). This message can then be used in [post-processing](#post-processing).
 
-# Post-Processing
+## Post-Processing
 
 From the Visual Mesh a series of specialised detectors are employed to detect field edges, balls, and goal posts. The **green horizon** detector uses information from the Visual Mesh message as detailed above. The **goal** and **ball detectors** use the information given by the green horizon detector in the [GreenHorizon message](https://github.com/NUbots/NUbots/blob/master/shared/message/vision/GreenHorizon.proto).
 
 All calculations in the detectors are done in **3D world coordinates**. To find out more about the mathematics used at NUbots, check out [the mathematics page](/system/foundations/mathematics).
 
 ![A soccer field with an overlay of lines representing object detections.](./images/vision-balls-goals.png 'The full output of the vision system showing the green horizon, ball and goal detections.')
 
-## Green Horizon Detector
+### Green Horizon Detector
 
 When the [green horizon detector](https://github.com/NUbots/NUbots/blob/master/module/vision/GreenHorizonDetector/) receives a VisualMesh message, it uses the information in this message to create one large **cluster** of points that is determined to be the field.
 
@@ -48,7 +48,7 @@ Clustering is repeated until all field points are part of a cluster. Clusters th
 
 After clustering has finished, one cluster will remain which should represent **the field**. An **upper convex hull algorithm** is applied to the final cluster to determine the edge of the field. The detector will emit a **GreenHorizon message** that specifies the location of the edge of the field.
 
-## Ball Detector
+### Ball Detector
 
 The [ball detector](https://github.com/NUbots/NUbots/blob/master/module/vision/BallDetector/) receives a GreenHorizon message and a [FieldDescription message](https://github.com/NUbots/NUbots/blob/master/shared/message/support/FieldDescription.proto). The FieldDescription message is output by the [SoccerConfig module](https://github.com/NUbots/NUbots/tree/master/module/support/configuration/SoccerConfig) which creates the FieldDescription message from configuration values specifying the layout of the soccer field as well as the radius of the ball being used.
 
@@ -101,7 +101,7 @@ Remaining clusters are fitted with a **circular cone**. The **cone axis** is det
 
 Any remaining clusters are assumed to be balls and so are emitted together as a [Balls message](https://github.com/NUbots/NUbots/blob/master/shared/message/vision/Ball.proto).
 
-## Goal Detector
+### Goal Detector
 
 The [goal detector](https://github.com/NUbots/NUbots/blob/master/module/vision/GoalDetector/src/GoalDetector.cpp) follows a similar structure to the ball detector. It receives a GreenHorizon and a FieldDescription message.
 
@@ -115,7 +115,7 @@ The bottom centre point of each cluster is then found by averaging the edge poin
 
 The goal detector then emits any goals as a [Goals message](https://github.com/NUbots/NUbots/blob/master/shared/message/vision/Goal.proto).
 
-# References
+## References
 
 - E. Shelhamer, J. Long, and T. Darrell. Fully convolutional networks for semantic segmentation. _IEEE Transactions on Pattern Analysis and Machine Intelligence_, 39(4):640–651, April 2017.
 

src/book/02-system/02-subsystems/06-behaviour.mdx

@@ -8,7 +8,7 @@ slug: /system/subsystems/behaviour
 
 The behaviour subsystem includes walk planning, soccer strategies, get up detection, head behaviour, script running and tuning, and kick behaviour.
 
-# Script Runner
+## Script Runner
 
 [ScriptRunner](https://github.com/NUbots/NUbots/tree/96357855b059cd499021552b3e25a4b158828dc5/module/behaviour/tools/ScriptRunner) is a module in the behaviour subsystem. It takes the name of one or more script files as arguments and attempts to run the scripts. It does not take file paths, only the file name/s of the script/s to execute. Any role with the ScriptRunner module must also contain the [ScriptEngine](/system/subsystems/motion#script-engine) module.
 
@@ -20,7 +20,7 @@ An example of using ScriptRunner to run a script called `Stand.yaml` is:
 ./scriptrunner Stand.yaml
 ```
 
-# Script Tuner
+## Script Tuner
 
 [ScriptTuner](https://github.com/NUbots/NUbots/tree/96357855b059cd499021552b3e25a4b158828dc5/module/behaviour/tools/ScriptTuner) is a module in the behaviour subsystem. Using a command-line argument, it can either create a new script or open an existing script for editing. It uses [curses](<https://en.wikipedia.org/wiki/Curses_(programming_library)>) to create a user interface in the terminal. Through this user interface, YAML files are created or edited that specify a script that can then be used by other modules.