diff --git a/en/airframes/adding_a_new_frame.md b/en/airframes/adding_a_new_frame.md index 376e459ffe5..638063ba791 100644 --- 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 index 6bbc1d03866..acb94c88be9 100644 --- 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 index 054192b4911..c6b1f685c6d 100644 --- 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 index 0c67bea0c17..a848409aa9d 100644 --- 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). -> **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). > **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 index 1cac99f6eae..f450ae641ff 100644 --- 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 index 2972ce436da..d83eab43a1a 100644 --- 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 build/BUILDPLATFORM**/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 build/BUILDPLATFORM**/src/modules/micrortps_bridge/micrortps_agent/**. diff --git a/en/ros/external_position_estimation.md b/en/ros/external_position_estimation.md index 880edd46af6..2278295a2dc 100644 --- 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 index c439f7b568f..a7d734959f5 100644 --- 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 ` 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 ` 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 index 1a444914405..2aa4364090e 100644 --- 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` - **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 index 39201174b4a..1ede35ecad1 100644 --- 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 index 97b9dcb6645..0d032a46ef0 100644 --- 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 index 7dfa9823f3f..b2bd2868180 100644 --- 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 index 997c3b8e908..d60dc4e7f8b 100644 --- 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 index dacefa1df86..749e9ff1506 100644 --- 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 index 74ca1964ce4..0ff0f495027 100644 --- 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 index e047aa42f4c..4e73b1c1361 100644 --- 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