Fix links for v1.9.0 (PX4#799)

jo-ruch · May 28, 2019 · dc8d964 · dc8d964
1 parent d06a0d5
commit dc8d964
Show file tree

Hide file tree

Showing 16 changed files with 30 additions and 26 deletions.
diff --git a/en/airframes/adding_a_new_frame.md b/en/airframes/adding_a_new_frame.md
@@ -21,7 +21,7 @@ These aspects are mostly independent, which means that many configurations share
 
 ### Config File {#config-file}
 
-A typical configuration file is shown below ([original file here](https://github.com/PX4/Firmware/blob/master/ROMFS/px4fmu_common/init.d/airframes/3033_wingwing)) .
+A typical configuration file is shown below ([original file here](https://github.com/PX4/Firmware/blob/master/ROMFS/px4fmu_common/init.d/airframes/3033_wingwing)).
 
 The first section is the airframe documentation. This is used in the [Airframes Reference](../airframes/airframe_reference.md) and *QGroundControl*.
 ```bash

diff --git a/en/concept/architecture.md b/en/concept/architecture.md
@@ -110,7 +110,7 @@ integrate it and publish with 250Hz. Other parts of the system, such
 as the `navigator`, don't need such a high update rate, and thus run
 considerably slower.
 
-The message update rates can be [inspected](../middleware/uorb.md#urb-top-command)
+The message update rates can be [inspected](../middleware/uorb.md)
 in real-time on the system by running `uorb top`.
 
 ## Runtime Environment

diff --git a/en/contribute/support.md b/en/contribute/support.md
@@ -2,7 +2,7 @@
 
 This section shows how you can get help from the core dev team and the wider community.
 
-> **Tip** Developers are most welcome to attend the [weekly dev call](../contribute/dev_call.md) and other [developer events](#calendar) to engage more deeply with the project.
+> **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}
 
@@ -32,7 +32,7 @@ The [Dev Call](../contribute/dev_call.md) is a weekly meeting attended by the PX
 
 There is also space in the agenda to discuss pull requests, major impacting issues and Q&A.
 
-> **Tip** For other developer events see: [Contribution > Calendar & Events](../contribute/README.md#calendar).
+> **Tip** For other developer events see: [Contribution > Calendar & Events](../README.md#calendar).
 
 
 ## Tests Flights

diff --git a/en/debug/sensor_uorb_topic_debugging.md b/en/debug/sensor_uorb_topic_debugging.md
@@ -6,7 +6,7 @@ inter-thread/inter-process communication. The `listener` command can be used fro
 > **Tip** This is a powerful debugging tool because it can be used even when QGC is connected over a wireless link (e.g. when the vehicle is flying).
 
 <span></span>
-> **Note** The `listener` command is also available through the [System Console](../debug/system_console.md) and the [MAVLink Shell](../debug/system_console.md#mavlink-shell).
+> **Note** The `listener` command is also available through the [System Console](../debug/system_console.md) and the [MAVLink Shell](../debug/system_console.md#mavlink_shell).
 
 <span></span>
 > **Note** The `listener` command is only available on NuttX-based systems (Pixhawk, Pixracer, etc.) and Linux / OS X.

diff --git a/en/hardware/porting_guide.md b/en/hardware/porting_guide.md
@@ -121,7 +121,7 @@ With full compatibility you benefit from the ongoing day-to-day development of P
 > **Tip** Manufacturers should carefully consider the cost of maintenance before deviating from the specification
   (the cost to the manufacturer is proportional to the level of divergence).
 
-We welcome any individual or company to submit their port for inclusion in our supported hardware, provided they are willing to follow our [Code of Conduct](../contribute/README.md#code-of-conduct) and work with the Dev Team to provide a safe and fulfilling PX4 experience to their customers.
+We welcome any individual or company to submit their port for inclusion in our supported hardware, provided they are willing to follow our [Code of Conduct](https://github.com/PX4/Firmware/blob/master/CODE_OF_CONDUCT.md) and work with the Dev Team to provide a safe and fulfilling PX4 experience to their customers.
 
 It's also important to note that the PX4 dev team has a responsibility to release safe software, and as such we require any board manufacturer to commit any resources necessary to keep their port up-to-date, and in a working state.
 

diff --git a/en/middleware/micrortps_manual_code_generation.md b/en/middleware/micrortps_manual_code_generation.md
@@ -136,7 +136,7 @@ src/modules/micrortps_bridge/micrortps_client
 
 ## Build and use the code
 
-The manually generated *Client* code is built and used in *exactly* the same way as [automatically generated Client code](../middleware/micrortps.md#client-px4-firmware).
+The manually generated *Client* code is built and used in *exactly* the same way as [automatically generated Client code](../middleware/micrortps.md#client_firmware).
 
 Specifically, once manually generated, the *Client* source code is compiled and built into the PX4 firmware as part of the normal build process. For example, to compile the code and include it in firmware for NuttX/Pixhawk targets: 
 
@@ -146,4 +146,5 @@ make px4_fmu-v4_default upload
 
 > **Note** You must first [disable automatic bridge code generation](#disable-automatic-bridge-code-generation) so that the toolchain uses the manually generated source code (and does not attempt to regenerate it).
 
-The manually generated *Agent* code is also compiled and used in the same way as the [automatically generated code](../middleware/micrortps.md#agent-off-board-fastrtps-interface). The only difference is that the manually source code is created in **src/modules/micrortps_bridge/micrortps_agent** instead of <strong><emphasis>build/BUILDPLATFORM</emphasis></strong>**/src/modules/micrortps_bridge/micrortps_agent/**.
+The manually generated *Agent* code is also compiled and used in the same way as the [automatically generated code](../middleware/micrortps.md#agent-in-a-ros-independent-offboard-fast-rtps-interface).
+The only difference is that the manually source code is created in **src/modules/micrortps_bridge/micrortps_agent** instead of <strong><emphasis>build/BUILDPLATFORM</emphasis></strong>**/src/modules/micrortps_bridge/micrortps_agent/**.
diff --git a/en/ros/external_position_estimation.md b/en/ros/external_position_estimation.md
@@ -90,7 +90,7 @@ A rough estimate of the delay can be obtained from logs by checking the offset b
 
 ![ekf2_ev_delay log](../../assets/ekf2/ekf2_ev_delay_tuning.png)
 
-> **Note** A plot of external data vs. onboard estimate (as above) can be generated using [FlightPlot](https://docs.px4.io/en/log/flight_log_analysis.html#flightplot-desktop) or similar flight analysis tools.
+> **Note** A plot of external data vs. onboard estimate (as above) can be generated using [FlightPlot](https://docs.px4.io/master/en/log/flight_log_analysis.html#flightplot) or similar flight analysis tools.
 
 The value can further be tuned by varying the parameter to find the value that yields the lowest EKF innovations during dynamic maneuvers.
 
@@ -190,7 +190,7 @@ With a remapping you can directly publish it on `mocap_pose_estimate` as it is w
 
 ### OptiTrack MoCap
 
-The following steps explain how to feed position estimates from an [OptiTrack](http://optitrack.com/systems/#robotics) system to PX4. 
+The following steps explain how to feed position estimates from an [OptiTrack](https://optitrack.com/motion-capture-robotics/) system to PX4. 
 It is assumed that the MoCap system is calibrated. 
 See [this video](https://www.youtube.com/watch?v=cNZaFEghTBU) for a tutorial on the calibration process.
 

diff --git a/en/sensor_bus/i2c.md b/en/sensor_bus/i2c.md
@@ -12,7 +12,7 @@ Pixhawk/PX4 support it for:
 
 ## Integrating I2C Devices
 
-Drivers should `#include <drivers/device/i2c.h>` and then provide an implementation of the abstract base class `I2C` defined in **I2C.hpp** for the target hardware (i.e. for NuttX [here](https://github.com/PX4/Firmware/blob/master/src/drivers/device/nuttx/I2C.hpp)).
+Drivers should `#include <drivers/device/i2c.h>` and then provide an implementation of the abstract base class `I2C` defined in **I2C.hpp** for the target hardware (i.e. for NuttX [here](https://github.com/PX4/Firmware/blob/master/src/lib/drivers/device/nuttx/I2C.hpp)).
 
 Drivers will also need to include headers for their type of device (**drv_*.h**) in [/src/drivers/](https://github.com/PX4/Firmware/tree/master/src/drivers) - e.g. [drv_baro.h](https://github.com/PX4/Firmware/blob/master/src/drivers/drv_baro.h).
 

diff --git a/en/setup/building_px4.md b/en/setup/building_px4.md
@@ -505,7 +505,7 @@ make [VENDOR_][MODEL][_VARIANT] [VIEWER_MODEL_DEBUGGER]
 
 - **VIEWER:** This is the simulator ("viewer") to launch and connect: `gazebo`, `jmavsim` <!-- , ?airsim -->
 - **MODEL:** The *vehicle* model to use (e.g. `iris` (*default*), `rover`, `tailsitter`, etc), which will be loaded by the simulator.
-  The environment variable `PX4_SIM_MODEL` will be set to the selected model, which is then used in the [startup script](#scripts) to select appropriate parameters. 
+  The environment variable `PX4_SIM_MODEL` will be set to the selected model, which is then used in the [startup script](..\simulation\README.md#scripts) to select appropriate parameters. 
 - **DEBUGGER:** Debugger to use: `none` (*default*), `ide`, `gdb`, `lldb`, `ddd`, `valgrind`, `callgrind`. 
   For more information see [Simulation Debugging](../debug/simulation_debugging.md).
 

diff --git a/en/setup/dev_env_linux_arch.md b/en/setup/dev_env_linux_arch.md
@@ -1,6 +1,8 @@
 # Development Environment on ArchLinux
 
-> **Note** These instructions allow you to build PX4 (without RTPS) for NuttX targets, using an unsupported version of GCCE from the package manager. The instructions have been tested on Antergos (an Arch Linux based distribution) as it is easier to set up than Arch Linux. We hope to provide fully tested instructions with the supported toolchain in the near future.
+> **Note** These instructions allow you to build PX4 (without RTPS) for NuttX targets, using an unsupported version of GCCE from the package manager.
+The instructions have been tested on Antergos (an Arch Linux based distribution) as it is easier to set up than Arch Linux.
+We hope to provide fully tested instructions with the supported toolchain in the near future.
 
 ## Permissions
 

diff --git a/en/setup/dev_env_windows_cygwin.md b/en/setup/dev_env_windows_cygwin.md
@@ -127,9 +127,9 @@ The following features are known to work (version 2.0):
 * The installer supports updating to a new version keeping your personal changes inside the toolchain folder
 
 Omissions:
-* Simulation: Gazebo and ROS are not supported
+* Simulation: Gazebo and ROS are not supported.
 * Only NuttX and JMAVSim/SITL builds are supported.
-* [Known problems / Report your issue](https://github.com/orgs/PX4/projects/6)
+* [Known problems](https://github.com/orgs/PX4/projects/6) (Also use to report issues).
 
 ### Shell Script Installation {#script_setup}
 
@@ -185,9 +185,9 @@ This section describes how to setup the Cygwin toolchain manually yourself while
 1. Write up or copy the **batch scripts** [`run-console.bat`](https://github.com/MaEtUgR/PX4Toolchain/blob/master/run-console.bat) and [`setup-environment-variables.bat`](https://github.com/MaEtUgR/PX4Toolchain/blob/master/toolchain/setup-environment-variables.bat). 
 
    The reason to start all the development tools through the prepared batch script is they preconfigure the starting program to use the local, portable Cygwin environment inside the toolchain's folder. 
-   This is done by always first calling the script [**setup-environment-variables.bat**](https://github.com/MaEtUgR/PX4Toolchain/blob/master/toolchain/setup-environment-variables.bat) and the desired application like the console after that.
+   This is done by always first calling the script [**setup-environment.bat**](https://github.com/PX4/windows-toolchain/blob/master/toolchain/scripts/setup-environment.bat) and the desired application like the console after that.
 
-   The script [`setup-environment-variables.bat`](https://github.com/MaEtUgR/PX4Toolchain/blob/master/toolchain/setup-environment-variables.bat) locally sets environmental variables for the workspace root directory `PX4_DIR`, all binary locations `PATH`, and the home directory of the unix environment `HOME`.
+   The script [setup-environment.bat](https://github.com/PX4/windows-toolchain/blob/master/toolchain/scripts/setup-environment.bat) locally sets environmental variables for the workspace root directory `PX4_DIR`, all binary locations `PATH`, and the home directory of the unix environment `HOME`.
 
 1. Add necessary **python packages** to your setup by opening the Cygwin toolchain console (double clicking **run-console.bat**) and executing
    ```

diff --git a/en/setup/fast-rtps-installation.md b/en/setup/fast-rtps-installation.md
@@ -16,7 +16,7 @@ Fast RTPS is installed as part of the PX4 developer environment on some platform
 
 * [Development Environment on Mac](../setup/dev_env_mac.md) (FastRTPS included in common tools)
 * [Development Environment on Linux](../setup/dev_env_linux.md) (FastRTPS included in install scripts)
-* [Development Environment on Windows > Bash on Windows](/setup/dev_env_windows.md#bash-on-windows-new) (FastRTPS included in install script)
+* [Development Environment on Windows > Bash on Windows](../setup/dev_env_windows_bash_on_win.md) (FastRTPS included in install script)
 
 The instruction below are useful for adding FastRTPS support in other environments.
 

diff --git a/en/simulation/jmavsim.md b/en/simulation/jmavsim.md
@@ -6,9 +6,9 @@ jMAVSim is a simple multirotor/Quad simulator that allows you to fly *copter* ty
 
 * Quad
 
-This topic shows how to set up jMAVSim to connect with a SITL version of PX4. 
+This topic shows how to set up jMAVSim to connect with a SITL version of PX4.
 
-> **Tip** jMAVSim can also be used for HITL Simulation ([as shown here](../simulation/hitl.md#using-jmavsim-quadrotor)).
+> **Tip** jMAVSim can also be used for HITL Simulation ([as shown here](../simulation/hitl.md#jmavsimgazebo-hitl-environment).
 
 
 ## Simulation Environment

diff --git a/en/simulation/multi-vehicle-simulation.md b/en/simulation/multi-vehicle-simulation.md
@@ -9,8 +9,8 @@ You can then control the vehicles with *QGroundControl* and MAVROS in a similar
 
 ## Required
 
-* Current [PX4 ROS/Gazebo development evironment](../setup/dev_env_linux.md#gazebo-with-ros)
-  > **Note** At time of writing this is Ubuntu 16.04 with ROS Kinetic/Gazebo 7. See also [Gazebo Simulation](/simulation/gazebo.md).
+* Current [PX4 ROS/Gazebo development evironment](../setup/dev_env_linux.md#ros)
+  > **Note** At time of writing this is Ubuntu 18.04 with ROS Melodic/Gazebo 9. See also [Gazebo Simulation](../simulation/gazebo.md).
 * [MAVROS package](http://wiki.ros.org/mavros)
 * a clone of latest [PX4/Firmware](https://github.com/PX4/Firmware)
 

diff --git a/en/simulation/ros_interface.md b/en/simulation/ros_interface.md
@@ -13,9 +13,10 @@ The ROS/Gazebo integration with PX4 follows the pattern in the diagram below (th
 
 > **Note** *ROS* is only supported on Linux (not macOS or Windows).
 
-The easiest way to setup PX4 simulation with ROS on Ubuntu Linux is to use the standard installation script that can be found at [Development Environment on Linux > Gazebo with ROS](../setup/dev_env_linux.md#gazebo-with-ros). The script installs everything you need: PX4, ROS "Kinetic", the Gazebo 7 simulator, and [MAVROS](../ros/mavros_installation.md).
+The easiest way to setup PX4 simulation with ROS on Ubuntu Linux is to use the standard installation script that can be found at [Development Environment on Linux > Gazebo with ROS](../setup/dev_env_linux.md#ros). 
+The script installs everything you need: PX4, ROS "Melodic", the Gazebo 9 simulator, and [MAVROS](../ros/mavros_installation.md).
 
-> **Note** The script follows the [standard ROS "Kinetic" installation instructions](http://wiki.ros.org/kinetic/Installation/Ubuntu), which include Gazebo 7. Installation of ROS Kinetic for other platforms is covered in the [ROS Wiki here](http://wiki.ros.org/kinetic/Installation).
+> **Note** The script follows the [standard ROS "Melodic" installation instructions](http://wiki.ros.org/melodic/Installation/Ubuntu), which includes Gazebo 9.
 
 
 ## Launching ROS/Simulation

diff --git a/en/test_and_ci/docker.md b/en/test_and_ci/docker.md
@@ -13,14 +13,14 @@ This topic shows how to use the [available docker containers](#px4_containers) t
 
 [Install Docker](https://docs.docker.com/installation/) for your Linux computer, preferably using one of the Docker-maintained package repositories to get the latest stable version. You can use either the *Enterprise Edition* or (free) *Community Edition*.
 
-For local installation of non-production setups on *Ubuntu*, the quickest and easiest way to install Docker is to use the [convenience script](https://docs.docker.com/engine/installation/linux/docker-ce/ubuntu/#install-using-the-convenience-script) as shown below (alternative installation methods are found on the same page):
+For local installation of non-production setups on *Ubuntu*, the quickest and easiest way to install Docker is to use the [convenience script](https://docs.docker.com/install/linux/docker-ce/ubuntu/#install-using-the-convenience-script) as shown below (alternative installation methods are found on the same page):
 
 ```sh
 curl -fsSL get.docker.com -o get-docker.sh
 sudo sh get-docker.sh
 ```
 
-The default installation requires that you invoke *Docker* as the root user (i.e. using `sudo`). If you would like to [use Docker as a non-root user](https://docs.docker.com/engine/installation/linux/linux-postinstall/#manage-docker-as-a-non-root-user), you can optionally add the user to the "docker" group and then log out/in:
+The default installation requires that you invoke *Docker* as the root user (i.e. using `sudo`). If you would like to [use Docker as a non-root user](https://docs.docker.com/install/linux/linux-postinstall/#manage-docker-as-a-non-root-user), you can optionally add the user to the "docker" group and then log out/in:
 ```sh
 # Create docker group (may not be required)
 sudo groupadd docker