Heading anchors > explict anchors (PX4#1115)

* Heading anchors > explict anchors * Remove anchro not needed.
SBG-Systems · Nov 5, 2020 · e636d09 · e636d09
1 parent 7397336
commit e636d09
Show file tree

Hide file tree

Showing 40 changed files with 273 additions and 137 deletions.
diff --git a/en/README.md b/en/README.md
@@ -19,7 +19,7 @@ This guide explains how to:
 * Communicate/integrate with external robotics APIs.
 
 
-## Support {#support}
+## Support
 
 [Support](contribute/support.md) provide links to the [discussion boards](http://discuss.px4.io/) and other support channels.
 
@@ -45,7 +45,8 @@ You can access these by clicking the language-switcher icon:
 ![Gitbook Language Selector](../assets/gitbook/gitbook_language_selector.png)
 
 
-## Calendar & Events {#calendar}
+<a id="calendar"></a>
+## Calendar & Events
 
 The *Dronecode Calendar* shows important events for platform developers and users. 
 Select the links below to display the calendar in your timezone (and to add it to your own calendar):

diff --git a/en/advanced/out_of_tree_modules.md b/en/advanced/out_of_tree_modules.md
@@ -42,7 +42,8 @@ To create an external module:
   ```
 
 
-## Out-of-Tree uORB Message Definitions {#uorb_message_definitions}
+<a id="uorb_message_definitions"></a>
+## Out-of-Tree uORB Message Definitions
 
 uORB messages can also be defined out-of-tree. For this, the `$EXTERNAL_MODULES_LOCATION/msg` folder must exist.
 
@@ -69,7 +70,8 @@ The new uORB messages can be used like any other uORB message as described [here
 > **Warning** The out-of-tree uORB message definitions cannot have the same name as any of the normal uORB messages.
 
 
-## Building External Modules and uORB Messages {#building}
+<a id="building"></a>
+## Building External Modules and uORB Messages
 
 Execute `make px4_sitl EXTERNAL_MODULES_LOCATION=<path>`.
 

diff --git a/en/advanced/parameters_and_configurations.md b/en/advanced/parameters_and_configurations.md
@@ -216,7 +216,8 @@ param_get(my_param_handle, &my_param);
 ```
 
 
-## Parameter Meta Data {#parameter_metadata}
+<a id="parameter_metadata"></a>
+## Parameter Meta Data
 
 PX4 uses an extensive parameter metadata system to drive the user-facing presentation of parameters, and to set the default value for each parameter in firmware.
 
@@ -230,7 +231,8 @@ The build system extracts the metadata (using `make parameters_metadata`) to bui
 > **Warning** After adding a *new* parameter file you should call `make clean` before building to generate the new parameters (parameter files are added as part of the *cmake* configure step, which happens for clean builds and if a cmake file is modified).
 
 
-### c Parameter Metadata {#c_metadata}
+<a id="c_metadata"></a>
+### c Parameter Metadata
 
 The legacy approach for defining parameter metadata is in a file with extension **.c** (at time of writing this is the approach most commonly used in the source tree).
 
@@ -285,7 +287,8 @@ The purpose of each line is given below (for more detail see [module_schema.yaml
  */
 ```
 
-### YAML Metadata {#yaml_metadata}
+<a id="yaml_metadata"></a>
+### YAML Metadata
 
 > **Note** At time of writing YAML parameter definitions cannot be used in *libraries*.
 
@@ -295,7 +298,8 @@ It supports all the same metadata, along with new features like multi-instance d
 - The YAML parameter metadata schema is here: [validation/module_schema.yaml](https://github.com/PX4/PX4-Autopilot/blob/master/validation/module_schema.yaml).
 - An example of YAML definitions being used can be found in the MAVLink parameter definitions: [/src/modules/mavlink/module.yaml](https://github.com/PX4/PX4-Autopilot/blob/master/src/modules/mavlink/module.yaml).
 
-#### Multi-Instance (Templated) Meta Data {#multi_instance_metadata}
+<a id="multi_instance_metadata"></a>
+#### Multi-Instance (Templated) Meta Data
 
 Templated parameter definitions are supported in [YAML parameter definitions](https://github.com/PX4/PX4-Autopilot/blob/master/validation/module_schema.yaml) (templated parameter code is not supported).
 

diff --git a/en/airframes/adding_a_new_frame.md b/en/airframes/adding_a_new_frame.md
@@ -23,7 +23,8 @@ These aspects are mostly independent, which means that many configurations share
 
 > **Note** New airframe files are only automatically added to the build system after a clean build (run `make clean`).
 
-### Config File {#config-file}
+<a id="config-file"></a>
+### Config File
 
 A typical configuration file is shown below ([original file here](https://github.com/PX4/PX4-Autopilot/blob/master/ROMFS/px4fmu_common/init.d/airframes/3033_wingwing)).
 
@@ -99,7 +100,8 @@ set PWM_DISARMED 1000
 > **Warning** If you want to reverse a channel, never do this on your RC transmitter or with e.g `RC1_REV`. The channels are only reversed when flying in manual mode, when you switch in an autopilot flight mode, the channels output will still be wrong (it only inverts your RC signal). Thus for a correct channel assignment change either your PWM signals with `PWM_MAIN_REV1` (e.g. for channel one) or change the signs of the output scaling in the corresponding mixer (see below).
 
 
-### Mixer File {#mixer-file}
+<a id="mixer-file"></a>
+### Mixer File
 
 > **Note** First read [Concepts > Mixing](../concept/mixing.md).
   This provides background information required to interpret this mixer file.

diff --git a/en/concept/architecture.md b/en/concept/architecture.md
@@ -10,7 +10,8 @@ All PX4 [airframes](../airframes/README.md) share a single codebase (this includ
 - The system can deal with varying workload
 
 
-## High-Level Software Architecture{#architecture}
+<a id="architecture"></a>
+## High-Level Software Architecture
 
 The diagram below provides a detailed overview of the building blocks of PX4. 
 The top part of the diagram contains middleware blocks, while the lower
@@ -50,7 +51,8 @@ The use of the publish-subscribe scheme means that:
 > blocks to be rapidly and easily replaced, even at runtime.
 
 
-### Flight Stack {#flight-stack}
+<a id="flight-stack"></a>
+### Flight Stack
 
 The flight stack is a collection of guidance, navigation and control algorithms 
 for autonomous drones. 
@@ -89,7 +91,8 @@ factors, such as the motor arrangements with respect to the center of gravity,
 or the vehicle's rotational inertia.
 
 
-### Middleware {#middleware}
+<a id="middleware"></a>
+### Middleware
 
 The [middleware](../middleware/README.md) consists primarily of device drivers
 for embedded sensors, communication with the external world (companion computer,
@@ -112,7 +115,8 @@ considerably slower.
 The message update rates can be [inspected](../middleware/uorb.md)
 in real-time on the system by running `uorb top`.
 
-## Runtime Environment {#runtime-environment}
+<a id="runtime-environment"></a>
+## Runtime Environment
 
 PX4 runs on various operating systems that provide a POSIX-API (such as Linux, macOS, NuttX or QuRT).
 It should also have some form of real-time scheduling (e.g. FIFO).

diff --git a/en/concept/mixing.md b/en/concept/mixing.md
@@ -85,7 +85,8 @@ For a multicopter things are a bit different: control 0 (roll) is connected to a
   In the event of manual IO failsafe override (if the PX4FMU stops communicating with the PX4IO board) only the mapping/mixing defined by control group 0 inputs for roll, pitch, yaw and throttle are used (other mappings are ignored).
 
 
-### Control Group #6 (First Payload) {#control_group_6}
+<a id="control_group_6"></a>
+### Control Group #6 (First Payload)
 
 * 0: function 0
 * 1: function 1
@@ -159,12 +160,14 @@ Mixers are defined in plain-text files using the [syntax](#mixer_syntax) below.
 Files for pre-defined airframes can be found in [ROMFS/px4fmu_common/mixers](https://github.com/PX4/PX4-Autopilot/tree/master/ROMFS/px4fmu_common/mixers).
 These can be used as a basis for customisation, or for general testing purposes.
 
-### Mixer File Names {#mixer_file_names}
+<a id="mixer_file_names"></a>
+### Mixer File Names
 
 A mixer file must be named **XXXX._main_.mix** if it is responsible for the mixing of MAIN outputs or **XXXX._aux_.mix** if it mixes AUX outputs.
 
 
-### Mixer Loading {#loading_mixer}
+<a id="loading_mixer"></a>
+### Mixer Loading
 
 The default set of mixer files (in PX4 firmware) are defined in [px4fmu_common/init.d/airframes/](https://github.com/PX4/PX4-Autopilot/blob/master/ROMFS/px4fmu_common/init.d/airframes/).
 These can be overridden by mixer files with the same name in the SD card directory **/etc/mixers/** (SD card mixer files are loaded by preference).
@@ -184,7 +187,8 @@ The AUX mixer filename (prefix `YYYY` above) depends on airframe settings and/or
 > **Note** Mixer file loading is implemented in [ROMFS/px4fmu_common/init.d/rc.interface](https://github.com/PX4/PX4-Autopilot/blob/master/ROMFS/px4fmu_common/init.d/rc.interface).
 
 
-### Loading a Custom Mixer {#loading_custom_mixer}
+<a id="loading_custom_mixer"></a>
+### Loading a Custom Mixer
 
 PX4 loads appropriately named mixer files from the SD card directory **/etc/mixers/**, by preference, and then the version in Firmware.
 
@@ -200,7 +204,8 @@ See above for more information on [mixer loading](#loading_mixer).
 >   ```
 
 
-### Syntax {#mixer_syntax}
+<a id="mixer_syntax"></a>
+### Syntax
 
 Mixer files are text files that define one or more mixer definitions: mappings between one or more inputs and one or more outputs. 
 
@@ -238,7 +243,8 @@ Some mixers definitions consist of a number of tags (e.g. `O` and `S`) that foll
 > **Note** Any line that does not begin with a single capital letter followed by a colon may be ignored (so explanatory text can be freely mixed with the definitions).
 
 
-#### Summing Mixer {#summing_mixer}
+<a id="summing_mixer"></a>
+#### Summing Mixer
 
 Summing mixers are used for actuator and servo control.
 
@@ -277,7 +283,8 @@ Whilst the calculations are performed as floating-point operations, the values s
 An example of a typical mixer file is explained [here](../airframes/adding_a_new_frame.md#mixer-file).
 
 
-#### Null Mixer {#null_mixer}
+<a id="null_mixer"></a>
+#### Null Mixer
 
 A null mixer consumes no controls and generates a single actuator output with a value that is always zero.
 
@@ -290,7 +297,8 @@ Z:
 ```
 
 
-#### Multirotor Mixer {#multirotor_mixer}
+<a id="multirotor_mixer"></a>
+#### Multirotor Mixer
 
 The multirotor mixer combines four control inputs (roll, pitch, yaw, thrust) into a set of actuator outputs intended to drive motor speed controllers.
 
@@ -319,7 +327,8 @@ Idlespeed is relative to the maximum speed of motors and it is the speed at whic
 
 In the case where an actuator saturates, all actuator values are rescaled so that the saturating actuator is limited to 1.0.
 
-#### Helicopter Mixer {#helicopter_mixer}
+<a id="helicopter_mixer"></a>
+#### Helicopter Mixer
 
 The helicopter mixer combines three control inputs (roll, pitch, thrust) into four outputs (swash-plate servos and main motor ESC setting).
 The first output of the helicopter mixer is the throttle setting for the main motor.
@@ -394,7 +403,8 @@ S: 0 2  10000  10000      0 -10000  10000
 - The second and third servo have a longer arm, by a ratio of 1.3054 compared to the first servo.
 - The servos are limited at -8000 and 8000 because they are mechanically constrained.
 
-#### VTOL Mixer {#vtol_mixer}
+<a id="vtol_mixer"></a>
+#### VTOL Mixer
 
 VTOL systems use a [multirotor mixer](#multirotor_mixer) for the multirotor outputs, and [summing mixers](#summing_mixer) for the fixed-wing actuators (and the tilting servos in case of a tiltrotor VTOL).
 

diff --git a/en/contribute/dev_call.md b/en/contribute/dev_call.md
@@ -1,4 +1,5 @@
-# Weekly Dev Call {#dev_call}
+<a id="dev_call"></a>
+# Weekly Dev Call
 
 The PX4 dev team syncs up on platform technical details and in-depth analysis. 
 There is also space in the agenda to discuss pull requests, major impacting issues and Q&A.

diff --git a/en/contribute/docs.md b/en/contribute/docs.md
@@ -199,7 +199,8 @@ Everything you need to install and build Gitbook locally is also explained in th
    ```
 
 
-## Translations {#translation}
+<a id="translation"></a>
+## Translations
 
 We'd love your help to translate *QGroundControl* and our guides for PX4, *QGroundControl* and MAVLink.
 For more information see: [Translation](../contribute/translation.md).

diff --git a/en/contribute/git_examples.md b/en/contribute/git_examples.md
@@ -1,6 +1,7 @@
 # GIT Examples
 
-## Contributing Code to PX4 {#contributing_code}
+<a id="contributing_code"></a>
+## Contributing Code to PX4
 
 Adding a feature to PX4 follows a defined workflow. In order to share your contributions on PX4, you can follow this example.
 

diff --git a/en/contribute/notation.md b/en/contribute/notation.md
@@ -71,7 +71,8 @@ $$w$$ | Relative airspeed.
 $$x,y,z$$ | Component of vector along coordinate axis x, y and z.
 $$N,E,D$$ | Component of vector along global north, east and down direction.
 
-### Superscripts / Indices {#superscripts}
+<a id="superscripts"></a>
+### Superscripts / Indices
 
 Superscripts / Indices | Description
 --- | ---

diff --git a/en/contribute/support.md b/en/contribute/support.md
@@ -4,7 +4,8 @@ This section shows how you can get help from the core dev team and the wider com
 
 > **Tip** Developers are most welcome to attend the [weekly dev call](../contribute/dev_call.md) and other [developer events](../README.md#calendar) to engage more deeply with the project.
 
-## Forums and Chat {#support}
+<a id="support"></a>
+## Forums and Chat
 
 The core development team and community are active on the following forums and chat channels.
 
@@ -26,7 +27,8 @@ If you are unsure what the problem is and you need help diagnosing
 * [Open a Github Issue](https://github.com/PX4/Devguide/issues) with a flight report with as much detail as possible and links to logs.
 
 
-## Weekly Dev Call {#dev_call}
+<a id="dev_call"></a>
+## Weekly Dev Call
 
 The [Dev Call](../contribute/dev_call.md) is a weekly meeting attended by the PX4 dev team to discuss platform technical details, coordinate activities and perform in-depth analysis.
 

diff --git a/en/debug/consoles.md b/en/debug/consoles.md
@@ -5,7 +5,8 @@ PX4 enables terminal access to the system through the [MAVLink Shell](../debug/m
 This page explains the main differences and how the console/shell are used.
 
 
-## System Console vs. Shells {#console_vs_shell}
+<a id="console_vs_shell"></a>
+## System Console vs. Shells
 
 The PX4 *System Console* provides low-level access to the system, debug output and analysis of the system boot process.
 
@@ -29,7 +30,8 @@ The [System Console](../debug/system_console.md) is essential when the system do
 The [MAVLink Shell](../debug/mavlink_shell.md) is much easier to setup, and so is more generally recommended for most debugging.
 
 
-## Using Consoles/Shells {#using_the_console}
+<a id="using_the_console"></a>
+## Using Consoles/Shells
 
 The MAVLink shell/console and the [System Console](../debug/system_console.md) are used in much the same way.
 

diff --git a/en/debug/mavlink_shell.md b/en/debug/mavlink_shell.md
@@ -10,7 +10,8 @@ While the shell cannot *directly* display the output of modules that it does not
 
 ## Opening the Shell
 
-### QGroundControl MAVLink Console {#qgroundcontrol}
+<a id="qgroundcontrol"></a>
+### QGroundControl MAVLink Console
 
 The easiest way to access shell is to use the [QGroundControl MAVLink Console](https://docs.qgroundcontrol.com/en/analyze_view/mavlink_console.html) (see **Analyze View > Mavlink Console**).
 

diff --git a/en/debug/profiling.md b/en/debug/profiling.md
@@ -49,7 +49,8 @@ Please watch out for them while using it:
   This does not affect single core embedded targets, since they always execute in one thread, but this limitation makes the profiler incompatible with many other applications.
   In the future the stack folder should be modified to support multiple stack traces per sample.
 
-## Implementation {#implementation}
+<a id="implementation"></a>
+## Implementation
 
 The script is located at `Debug/poor-mans-profiler.sh`.
 Once launched, it will perform the specified number of samples with the specified time interval.