Update to new build config targets

en/advanced/switching_state_estimators.md

@@ -22,4 +22,6 @@ For multirotors and VTOL use the parameter [SYS_MC_EST_GROUP](../advanced/parame
 | 1 | enabled |  | enabled | |
 | 2 |  |  | | enabled |
 
-> **Note** For FMU-v2 (only) you will also need to build PX4 to specifically include required estimator (e.g. EKF2: `make px4fmu-v2`, LPE: `make px4fmu-v2_lpe`). This is required because FMU-v2 is too resource constrained to include both estimators. Other Pixhawk FMU versions include both.
+> **Note** For FMU-v2 (only) you will also need to build PX4 to specifically include required estimator (e.g. EKF2: `make px4_fmu-v2`, LPE: `make px4_fmu-v2_lpe`). 
+  This is required because FMU-v2 is too resource constrained to include both estimators. 
+  Other Pixhawk FMU versions include both.

en/airframes/adding_a_new_frame.md

@@ -222,16 +222,14 @@ The following *PX4 User Guide* topics explain how to tune the parameters that wi
 
 To make a new airframe available for section in the *QGroundControl* [airframe configuration](https://docs.px4.io/en/config/airframe.html):
 
-1. Make a clean build (e.g. by running `make clean` and then `make px4fmu-v5_default`)
+1. Make a clean build (e.g. by running `make clean` and then `make px4_fmu-v5_default`)
 1. Open QGC and select **Custom firmware file...** as shown below:
 
   ![QGC flash custom firmware](../../assets/gcs/qgc_flash_custom_firmware.png)
 
   You will be asked to choose the **.px4** firmware file to flash (this file is a zipped JSON file and contains the airframe metadata). 
-1. Navigate to the build folder and select the firmware file (e.g. **Firmware/build/nuttx_px4fmu-v5_default/px4fmu-v5_default.px4**).
+1. Navigate to the build folder and select the firmware file (e.g. **Firmware/build/px4_fmu-v5_default/px4_fmu-v5_default.px4**).
 1. Press **OK** to start flashing the firmware.
 1. Restart *QGroundControl*.
 
 The new airframe will then be available for selection in *QGroundControl*.
-
-

en/apps/hello_sky.md

@@ -138,12 +138,13 @@ In this section we create a *minimal application* that just prints out `Hello Sk
 
 ## Build the Application/Firmware
 
-The application is now complete. In order to run it you first need to make sure that it is built as part of PX4. Applications are added to the build/firmware in the appropriate board-level *cmake* file for your target: 
+The application is now complete. In order to run it you first need to make sure that it is built as part of PX4. 
+Applications are added to the build/firmware in the appropriate board-level *cmake* file for your target: 
 
-* Posix SITL (Simulator): [Firmware/cmake/configs/posix_sitl_default.cmake](https://github.com/PX4/Firmware/blob/master/cmake/configs/posix_sitl_default.cmake)
-* Pixhawk v1/2: [Firmware/cmake/configs/nuttx_px4fmu-v2_default.cmake](https://github.com/PX4/Firmware/blob/master/cmake/configs/nuttx_px4fmu-v2_default.cmake)
-* Pixracer: [Firmware/cmake/configs/nuttx_px4fmu-v4_default.cmake](https://github.com/PX4/Firmware/blob/master/cmake/configs/nuttx_px4fmu-v4_default.cmake)
-* *cmake* files for other boards can be found in [Firmware/cmake/configs/](https://github.com/PX4/Firmware/blob/master/cmake/configs/)
+* PX4 SITL (Simulator): [Firmware/boards/px4/sitl/default.cmake](https://github.com/PX4/Firmware/blob/master/boards/px4/sitl/default.cmake)
+* Pixhawk v1/2: [Firmware/boards/px4/fmu-v2/default.cmake](https://github.com/PX4/Firmware/blob/master/boards/px4/fmu-v2/default.cmake)
+* Pixracer (px4/fmu-v4): [Firmware/boards/px4/fmu-v4/default.cmake](https://github.com/PX4/Firmware/blob/master/boards/px4/fmu-v4/default.cmake)
+* *cmake* files for other boards can be found in [Firmware/boards/](https://github.com/PX4/Firmware/tree/master/boards)
 
 To enable the compilation of the application into the firmware create a new line for your application somewhere in the *cmake* file:
 
@@ -155,9 +156,9 @@ examples/px4_simple_app
 
 Build the example using the board-specific command:
 
-* jMAVSim Simulator: `make posix_sitl_default jmavsim`
-* Pixhawk v1/2: `make px4fmu-v2_default`
-* Pixhawk v3: `make px4fmu-v4_default`
+* jMAVSim Simulator: `make px4_sitl_default jmavsim`
+* Pixhawk v1/2: `make px4_fmu-v2_default` (or just `make px4_fmu-v2`)
+* Pixhawk v3: `make px4_fmu-v4_default`
 * Other boards: [Building the Code](../setup/building_px4.md#building_nuttx)
 
 
@@ -167,8 +168,8 @@ Build the example using the board-specific command:
 
 Enable the uploader and then reset the board:
 
-* Pixhawk v1/2: `make px4fmu-v2_default upload`
-* Pixhawk v3: `make px4fmu-v4_default upload`
+* Pixhawk v1/2: `make px4_fmu-v2_default upload`
+* Pixhawk v3: `make px4_fmu-v4_default upload`
 
 It should print before you reset the board a number of compile messages and at the end:
 
@@ -189,7 +190,8 @@ Rebooting.
 
 ### Connect the Console
 
-Now connect to the [system console](../debug/system_console.md) either via serial or USB. Hitting **ENTER** will bring up the shell prompt:
+Now connect to the [system console](../debug/system_console.md) either via serial or USB. 
+Hitting **ENTER** will bring up the shell prompt:
 
 ```sh
 nsh>
@@ -230,7 +232,8 @@ The application is now correctly registered with the system and can be extended
 
 ## Test App (SITL)
 
-If you're using SITL the *PX4 console* is automatically started (see [Building the Code > First Build (Using the jMAVSim Simulator)](../setup/building_px4.md#jmavsim_build)). As with the *nsh console* (see previous section) you can type `help` to see the list of built-in apps.
+If you're using SITL the *PX4 console* is automatically started (see [Building the Code > First Build (Using the jMAVSim Simulator)](../setup/building_px4.md#jmavsim_build)). 
+As with the *nsh console* (see previous section) you can type `help` to see the list of built-in apps.
 
 Enter `px4_simple_app` to run the minimal app.
 

en/concept/system_startup.md

@@ -30,7 +30,7 @@ For that to work, a few things are required:
 
 The modules can be executed from any terminal when PX4 is already running on a system. For example:
 ```
-cd <Firmware>/build/posix_sitl_default/bin
+cd <Firmware>/build/px4_sitl_default/bin
 ./px4-commander takeoff
 ./px4-listener sensor_accel
 ```

en/debug/gdb_debugging.md

@@ -7,7 +7,7 @@ The autopilots running PX4 support debugging via GDB or LLDB.
 The command below will list the largest static allocations:
 
 ```bash
-arm-none-eabi-nm --size-sort --print-size --radix=dec build/nuttx_px4fmu-v2_default/nuttx_px4fmu-v2_default.elf | grep " [bBdD] "
+arm-none-eabi-nm --size-sort --print-size --radix=dec build/px4_fmu-v2_default/px4_fmu-v2_default.elf | grep " [bBdD] "
 ```
 
 This NSH command provides the remaining free memory:
@@ -39,13 +39,13 @@ sudo apt-get install google-perftools libgoogle-perftools-dev
 
 First of all, build the firmware as follows:
 ```bash
-make posix_sitl_default
+make px4_sitl_default
 ```
 Start jmavsim: `./Tools/jmavsim_run.sh`
 
 In another terminal, type:
 ```bash
-cd build/posix_sitl_default/tmp
+cd build/px4_sitl_default/tmp
 export HEAPPROFILE=/tmp/heapprofile.hprof
 export HEAP_PROFILE_TIME_INTERVAL=30
 ```
@@ -127,7 +127,7 @@ EXC_RETURN: ffffffe9
 To decode the hard fault, load the *exact* binary into the debugger:
 
 ```bash
-arm-none-eabi-gdb build/nuttx_px4fmu-v2_default/nuttx_px4fmu-v2_default.elf
+arm-none-eabi-gdb build/px4_fmu-v2_default/px4_fmu-v2_default.elf
 ```
 
 Then in the GDB prompt, start with the last instructions in R8, with the first address in flash (recognizable because it starts with `0x080`, the first is `0x0808439f`). The execution is left to right. So one of the last steps before the hard fault was when ```mavlink_log.c``` tried to publish something,

en/debug/profiling.md

@@ -13,10 +13,10 @@ The folded stacks are then fed into the visualization script, for which purpose
 ## Basic Usage
 
 Basic usage of the profiler is available through the build system. 
-For example, the following command builds and profiles px4fmu-v4pro target with 10000 samples (fetching FlameGraph and adding it to the path as needed).
+For example, the following command builds and profiles px4_fmu-v4pro target with 10000 samples (fetching *FlameGraph* and adding it to the path as needed).
 
 ```
-make px4fmu-v4pro_default profile
+make px4_fmu-v4pro_default profile
 ```
 
 For more control over the build process, including setting the number of samples, see the [Implementation](#implementation).
@@ -70,14 +70,14 @@ This is done with the help of the option `--elf=<file>`, which expects a path (r
 Usage example:
 
 ```bash
-./poor-mans-profiler.sh --elf=build/nuttx_px4fmu-v4_default/nuttx_px4fmu-v4_default.elf --nsamples=30000
+./poor-mans-profiler.sh --elf=build/px4_fmu-v4_default/px4_fmu-v4_default.elf --nsamples=30000
 ```
 
 Note that every launch of the script will overwrite the old stacks. 
 Should you want to append to the old stacks rather than overwrite them, use the option `--append`:
 
 ```bash
-./poor-mans-profiler.sh --elf=build/nuttx_px4fmu-v4_default/nuttx_px4fmu-v4_default.elf --nsamples=30000 --append
+./poor-mans-profiler.sh --elf=build/px4_fmu-v4_default/px4_fmu-v4_default.elf --nsamples=30000 --append
 ```
 
 As one might suspect, `--append` with `--nsamples=0` will instruct the script to only regenerate the SVG without accessing the target at all.

en/debug/simulation_debugging.md

@@ -8,7 +8,7 @@ The Clang address sanitizer can help to find alignment (bus) errors and other me
 
 ```sh
 make clean # only required on first address sanitizer run after a normal build
-PX4_ASAN=1 make posix jmavsim
+PX4_ASAN=1 make px4_sitl jmavsim
 ```
 
 ## Valgrind
@@ -30,21 +30,21 @@ sudo apt-get install valgrind
 SITL can be launched with and without debugger attached and with either jMAVSim or Gazebo as simulation backend. This results in the start options below:
 
 ```sh
-make posix_sitl_default jmavsim
-make posix_sitl_default jmavsim___gdb
-make posix_sitl_default jmavsim___lldb
+make px4_sitl_default jmavsim
+make px4_sitl_default jmavsim___gdb
+make px4_sitl_default jmavsim___lldb
 
-make posix_sitl_default gazebo
-make posix_sitl_default gazebo___gdb
-make posix_sitl_default gazebo___lldb
+make px4_sitl_default gazebo
+make px4_sitl_default gazebo___gdb
+make px4_sitl_default gazebo___lldb
 
 make posix_sitl_lpe jmavsim
 make posix_sitl_lpe jmavsim___gdb
 make posix_sitl_lpe jmavsim___lldb
 
 make posix_sitl_lpe gazebo
 make posix_sitl_lpe gazebo___gdb
-make posix_sitl_lpe gazebo___lldb
+make posix_sitl_lpe gazebo___lldb 
 ```
 
 where the last parameter is the <viewer\_model\_debugger> triplet (using three underscores implies the default 'iris' model).

en/debug/system_wide_replay.md

@@ -27,17 +27,17 @@ Reasons for this are given below.
 
 - First, choose the file to replay, and build the target (from within the
   Firmware directory):
-```sh
-export replay=<absolute_path_to_log_file.ulg>
-make posix_sitl_default
-```
+  ```sh
+  export replay=<absolute_path_to_log_file.ulg>
+  make px4_sitl_default
+  ```
   This will create the output in a separate build directory
-  `build/posix_sitl_default_replay` (so that the parameters don't interfere with
+  `build/px4_sitl_default_replay` (so that the parameters don't interfere with
   normal builds). It's possible to choose any posix SITL build target for
   replay, the build system knows through the `replay` environment variable that
   it's in replay mode.
 - Add ORB publisher rules file in
-  `build/posix_sitl_default_replay/tmp/rootfs/orb_publisher.rules`.
+  `build/px4_sitl_default_replay/tmp/rootfs/orb_publisher.rules`.
   This file defines which module is allowed to publish which messages. It has
   the following format:
 ```
@@ -62,7 +62,7 @@ ignore_others: true
   to be disabled for replay.
 
 - Optional: setup parameter overrides in the file
-  `build/posix_sitl_default_replay/tmp/rootfs/replay_params.txt`.
+  `build/px4_sitl_default_replay/tmp/rootfs/replay_params.txt`.
   This file should contain a list of `<param_name> <value>`, like:
 ```
 EKF2_GB_NOISE 0.001
@@ -75,7 +75,7 @@ EKF2_GB_NOISE 0.001
   directory. Only necessary if a mission should be replayed.
 - Start the replay:
 ```sh
-  make posix_sitl_default jmavsim
+  make px4_sitl_default jmavsim
 ```
   This will automatically open the log file, apply the parameters and start
   to replay. Once done, it will be reported and the process can be exited. Then
@@ -127,7 +127,7 @@ The parameters can be adjusted as well. They can be extracted from the log with
 \(install pyulog with `sudo pip install pyulog` first\):
 
 ```
-ulog_params -i $replay -d ' ' | grep -e '^EKF2' > build/posix_sitl_default_replay/tmp/rootfs/replay_params.txt
+ulog_params -i $replay -d ' ' | grep -e '^EKF2' > build/px4_sitl_default_replay/tmp/rootfs/replay_params.txt
 ```
 Then edit the parameters in the file as needed and restart the replay process
 with `make posix none`. This will create a new log file.

en/hardware/porting_guide.md

@@ -13,7 +13,7 @@ This guide is focused only on the host OS and middleware as the applications/fli
 In addition to the host operating system specific configuration files described below, there are several groups of configuration files for each board located throughout the code base:
 * Board startup and configuration files are located in: [src/drivers/boards](https://github.com/PX4/Firmware/tree/master/src/drivers/boards).
   * This folder contains bus mappings, GPIO mappings, and the initialization code for each board.
-  * FMUv5 example: [src/drivers/boards/px4fmu-v5](https://github.com/PX4/Firmware/tree/master/src/drivers/boards/px4fmu-v5).
+  * FMUv5 example: [src/drivers/boards/px4fmu-v5](https://github.com/PX4/Firmware/tree/master/src/drivers/boards/px4fmu-v5). 
 * The boot file system (startup script) is located in: [ROMFS/px4fmu\_common](https://github.com/PX4/Firmware/tree/master/ROMFS/px4fmu_common)
 * The board specific build configurations are located in: [cmake/configs/](https://github.com/PX4/Firmware/blob/master/cmake/configs/).
 * Driver files are located in: [src/drivers](https://github.com/PX4/Firmware/tree/master/src/drivers).
@@ -31,20 +31,20 @@ For all NuttX based flight controllers (e.g. the Pixhawk series) the OS is loade
 The configuration files for NuttX based boards, including linker scripts and other required settings are located under [platforms/nuttx/nuttx-configs](https://github.com/PX4/Firmware/tree/master/platforms/nuttx/nuttx-configs).
 
 The following example uses FMUv5 as it is a recent [reference configuration](../debug/reference-design.md) for NuttX based flight controllers:
-* Running `make px4fmu-v5_default` from the `src/Firmware` directory will build the FMUv5 config
+* Running `make px4_fmu-v5_default` from the **Firmware** directory will build the FMUv5 config
 * The base FMUv5 configuration files are located in: [platforms/nuttx/nuttx-configs/px4fmu-v5](https://github.com/PX4/Firmware/tree/master/platforms/nuttx/nuttx-configs/px4fmu-v5).
 * Board specific header: [platforms/nuttx/nuttx-configs/px4fmu-v5/include/board.h](https://github.com/PX4/Firmware/blob/master/platforms/nuttx/nuttx-configs/px4fmu-v5/include/board.h).
 * NuttX OS config (created with Nuttx menuconfig): [nuttx-configs/px4fmu-v5/nsh/defconfig](https://github.com/PX4/Firmware/blob/master/platforms/nuttx/nuttx-configs/px4fmu-v5/nsh/defconfig).
-* Build configuration: [cmake/configs/nuttx\_px4fmu-v5\_default.cmake](https://github.com/PX4/Firmware/blob/master/cmake/configs/nuttx_px4fmu-v5_default.cmake).
+* Build configuration: [PX4/Firmware/boards/px4/fmu-v5/default.cmake](https://github.com/PX4/Firmware/blob/master/boards/px4/fmu-v5/default.cmake).
 
 The function of each of these files, and perhaps more, will need to be duplicated for a new flight controller board.
 
 #### NuttX Menuconfig
 
 If you need to modify the NuttX OS configuration, you can do this via [menuconfig](https://bitbucket.org/nuttx/nuttx) using the PX4 shortcuts:
 ```sh
-make px4fmu-v5_default menuconfig
-make px4fmu-v5_default qconfig
+make px4_fmu-v5_default menuconfig
+make px4_fmu-v5_default qconfig
 ```
 
 For fresh installs of PX4 onto Ubuntu using [ubuntu_sim_nuttx.sh](https://raw.githubusercontent.com/PX4/Devguide/master/build_scripts/ubuntu_sim_nuttx.sh) you will also need to install *kconfig* tools from [NuttX tools](https://bitbucket.org/nuttx/tools/src/master/).

en/log/logging.md

@@ -22,9 +22,10 @@ for a list of all supported logger commands and parameters.
 
 
 ## Configuration
+
 The list of logged topics can be customized with a file on the SD card. Create a
 file `etc/logging/logger_topics.txt` on the card with a list of topics (For
-SITL, it's `build/posix_sitl_default/tmp/rootfs/fs/microsd/etc/logging/logger_topics.txt`):
+SITL, it's `build/px4_sitl_default/tmp/rootfs/fs/microsd/etc/logging/logger_topics.txt`):
 ```
 <topic_name>, <interval>
 ```

en/middleware/micrortps.md

@@ -144,9 +144,9 @@ rtps:
 The *Client* source code is generated, compiled and built into the PX4 firmware as part of the normal build process.
 
 To build the firmware for NuttX/Pixhawk flight controllers use the `_rtps` feature in the configuration target.
-For example, to build RTPS for px4fmu-v4:
+For example, to build RTPS for px4_fmu-v4:
 ```sh
-make px4fmu-v4_rtps
+make px4_fmu-v4_rtps
 ```
 
 To build the firmware for a SITL POSIX target:

en/middleware/micrortps_manual_code_generation.md

@@ -141,7 +141,7 @@ The manually generated *Client* code is built and used in *exactly* the same way
 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: 
 
 ```sh
-make px4fmu-v4_default upload
+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).

en/ros/external_position_estimation.md

@@ -1,6 +1,6 @@
 # Using Vision or Motion Capture Systems
 
-> **Info** Before following the instructions below, ensure that your autopilot has a firmware version with the LPE modules enabled. The LPE version of the PX4 firmware can be found inside the zip file of the latest PX4 release or it can be built from source using a build command such as `make px4fmu-v2_lpe`. See [Building the Code](../setup/building_px4.md) for more details.
+> **Info** Before following the instructions below, ensure that your autopilot has a firmware version with the LPE modules enabled. The LPE version of the PX4 firmware can be found inside the zip file of the latest PX4 release or it can be built from source using a build command such as `make px4_fmu-v2_lpe`. See [Building the Code](../setup/building_px4.md) for more details.
 
 This page aims at getting a PX4 based system using position data from sources other than GPS (such as motion capture systems like VICON and Optitrack and vision based estimation systems like [ROVIO](https://github.com/ethz-asl/rovio), [SVO](https://github.com/uzh-rpg/rpg_svo) or [PTAM](https://github.com/ethz-asl/ethzasl_ptam) )
 

en/sensor_bus/i2c.md

@@ -21,7 +21,7 @@ To include a driver in firmware you must add the driver to the [cmake config fil
 drivers/sf1xx
 ``` 
 
-> **Tip** For example, you can see/search for this driver in the [px4fmu-v4_default](https://github.com/PX4/Firmware/blob/master/cmake/configs/nuttx_px4fmu-v4_default.cmake) configuration.
+> **Tip** For example, you can see/search for this driver in the [px4_fmu-v4_default](https://github.com/PX4/Firmware/blob/master/boards/px4/fmu-v4/default.cmake) configuration.
 
 
 ## I2C Driver Examples