From 099371a0670905e6a6562bd358c3ce43031bb7f9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beat=20K=C3=BCng?= <beat-kueng@gmx.net>
Date: Thu, 6 Sep 2018 13:39:06 +0200
Subject: [PATCH 1/6] add documentation for the Posix shell

https://github.com/PX4/Firmware/pull/10173
---
 en/SUMMARY.md                 |   2 +-
 en/advanced/system_startup.md |  33 +++++++++-
 en/simulation/README.md       | 113 ++++------------------------------
 3 files changed, 44 insertions(+), 104 deletions(-)

diff --git a/en/SUMMARY.md b/en/SUMMARY.md
index 2c91655d788..4fb4e2d0d05 100644
--- a/en/SUMMARY.md
+++ b/en/SUMMARY.md
@@ -100,7 +100,7 @@
   * [Motion Capture \(VICON, Optitrack\)](tutorials/motion-capture-vicon-optitrack.md)
   * [S.Bus Driver for Linux](tutorials/linux_sbus.md)
 * [Advanced Topics](advanced/README.md)
-  * [System Boot](advanced/system_startup.md)
+  * [System Startup](advanced/system_startup.md)
   * [Parameters & Configs](advanced/parameters_and_configurations.md)
   * [Parameter Reference](advanced/parameter_reference.md)
   * [Installing driver for Intel RealSense R200](advanced/realsense_intel_driver.md)
diff --git a/en/advanced/system_startup.md b/en/advanced/system_startup.md
index e57c8744060..649aee05f20 100644
--- a/en/advanced/system_startup.md
+++ b/en/advanced/system_startup.md
@@ -1,10 +1,39 @@
 # System Startup
 
-The PX4 boot is controlled by shell scripts in the [ROMFS/px4fmu_common/init.d](https://github.com/PX4/Firmware/tree/master/ROMFS/px4fmu_common/init.d) folder.
+The PX4 startup is controlled by shell scripts.
+On NuttX they reside in the [ROMFS/px4fmu_common/init.d](https://github.com/PX4/Firmware/tree/master/ROMFS/px4fmu_common/init.d) folder.
+A portion of these is also used on Posix and the ones that are only used on Posix are located in [ROMFS/px4fmu_common/init.d-posix](https://github.com/PX4/Firmware/tree/master/ROMFS/px4fmu_common/init.d-posix).
 
 All files starting with a number and underscore (e.g. `10000_airplane`) are canned airframe configurations. They are exported at build-time into an `airframes.xml` file which is parsed by [QGroundControl](http://qgroundcontrol.com) for the airframe selection UI. Adding a new configuration is covered [here](../airframes/adding_a_new_frame.md).
 
-The remaining files are part of the general startup logic, and the first executed file is the [rcS](https://github.com/PX4/Firmware/blob/master/ROMFS/px4fmu_common/init.d/rcS) script, which calls all other scripts.
+The remaining files are part of the general startup logic, and the first executed file is the [init.d/rcS](https://github.com/PX4/Firmware/blob/master/ROMFS/px4fmu_common/init.d/rcS) (or [init.d-posix/rcS](https://github.com/PX4/Firmware/blob/master/ROMFS/px4fmu_common/init.d-posix/rcS) on Posix) script, which calls all other scripts.
+
+
+## Script Execution
+
+NuttX has a shell interpreter already integrated.
+On Posix (Linux/MacOS), the system shell is used as script interpreter (e.g. bash).
+For that to work, a few things are required:
+- PX4 modules need to look like individual executables to the system. This is done via symbolic links.
+  For each module a symbolic link `px4-<module> -> px4` in the `bin` directory of the build folder is created.
+  When executed, the binary path is checked (`argv[0]`), and if it is a module (starts with `px4-`), it sends the command to the main px4 instance (see below).
+  The `px4-` prefix is used to avoid conflicts with system commands, such as `shutdown`, and it also allows for simple tab completion by typing `px4-<TAB>`.
+- The shell needs to know where to find the symbolic links. For that the `bin` directory with the symbolic links is added to the `PATH` variable right before executing the startup scripts.
+- The shell starts each module as a new process. This client process needs to communicate with the main running instance of px4 (the server), where the actual modules are running as threads.
+  This is done with [FIFOs (also called named pipes)](http://man7.org/linux/man-pages/man7/fifo.7.html).
+  The server has a FIFO opened, on which clients can send commands.
+  In addition each client opens its own FIFO, which the server then uses to send information to the client (strings printed to the console for example).
+- The startup scripts do not use the `px4-` prefix, but they call the module directly, e.g. `commander start`. This works via aliases: for each module an alias in the form of `alias <module>=px4-<module>` is created in the file `bin/px4-alias.sh`.
+- The `rcS` script is executed from the main px4 instance.
+  It does not start any modules but first updates the `PATH` variable and then simply runs a shell with the `rcS` file as argument.
+- In addition to that, multiple server instances can be started for multi-vehicle simulations. A client selects the instance via `--instance`. The instance is available in the script via `$px4_instance` variable.
+
+The modules can be executed from any terminal when PX4 is already running. For example:
+```
+cd <Firmware>/build/posix_sitl_default/bin
+./px4-commander takeoff
+./px4-listener sensor_accel
+```
 
 ## Debugging the System Boot
 
diff --git a/en/simulation/README.md b/en/simulation/README.md
index 7f4e6a62857..15ffe39bc9c 100644
--- a/en/simulation/README.md
+++ b/en/simulation/README.md
@@ -76,7 +76,7 @@ If you use the normal build system SITL `make` configuration targets (see next s
 
 The build system makes it very easy to build and start PX4 on SITL, launch a simulator, and connect them. For example, you can launch a SITL version of PX4 that uses the EKF2 estimator and simulate a plane in Gazebo with just the following command (provided all the build and gazebo dependencies are present!):
 ```
-make posix_sitl_ekf2 gazebo_plane
+make posix_sitl_default gazebo_plane
 ```
 
 > **Tip** It is also possible to separately build and start SITL and the various simulators, but this is nowhere near as "turnkey".
@@ -88,11 +88,11 @@ make [CONFIGURATION_TARGET] [VIEWER_MODEL_DEBUGGER]
 ```
 
 where:
-* **CONFIGURATION_TARGET:** has the format `[OS][_PLATFORM][_FEATURE]`
+* **CONFIGURATION_TARGET:** has the format `[OS_][PLATFORM][_FEATURE]`
 
   * **OS:** posix, nuttx, qurt
-  * **PLATFORM:** SITL (or in principle any platform supported among the different OS: bebop, eagle, excelsior, etc.)
-  * **FEATURE:** A particular high level feature - for example which estimator to use (ekf2, lpe) or to run tests or simulate using a replay.
+  * **PLATFORM:** sitl (or in principle any platform supported among the different OS: bebop, eagle, excelsior, etc.)
+  * **FEATURE:** A particular high level feature - for example to cross-compile or to run tests. In most cases this is `default`.
 
   > **Tip** You can get a list of all available configuration targets using the command:
   ```
@@ -102,7 +102,7 @@ where:
 * **VIEWER_MODEL_DEBUGGER:** has the format `[SIMULATOR]_[MODEL][_DEBUGGER]`
   
   * **SIMULATOR:** This is the simulator ("viewer") to launch and connect: `gazebo`, `jmavsim` <!-- , ?airsim -->
-  * **MODEL:** The vehicle model to use (e.g. `iris`, `rover`, `tailsitter`, etc). This corresponds to a specific [initialisation file](#init_file) that will be used to configure PX4. This might define the start up for a particular vehicle, or allow simulation of multiple vehicles (we explain how to find available init files in the next section).
+  * **MODEL:** The vehicle model to use (e.g. `iris`, `rover`, `tailsitter`, etc). 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. It also ensures that the simulator (gazebo) loads the correct model (we explain how to find available options in the next section).
   * **DEBUGGER:** Debugger to (optionally) use: `none`, `ide`, `gdb`, `lldb`, `ddd`, `valgrind`, `callgrind`. For more information see [Simulation Debugging](../debug/simulation_debugging.md).
 
   > **Tip** You can get a list of all available `VIEWER_MODEL_DEBUGGER` options using the command:
@@ -119,106 +119,17 @@ Notes:
   For example start PX4 using `make posix_sitl_default none` and jMAVSim using `./Tools/jmavsim_run.sh`.
 
 
-### Init File Location {#init_file}
+### Additional Options
 
-The settings for each configuration target are defined in appropriately named files in [/Firmware/cmake/configs](https://github.com/PX4/Firmware/tree/master/cmake/configs). Within each file there is a setting `config_sitl_rcS_dir` that defines the location of the folder where the configuration stores its init files.
+The simulation can be further configured via environment variables:
+- `PX4_ESTIMATOR`: This variable configures which estimator to use.
+  Possible options are: `ekf2` (default), `lpe`, `inav`. It can be set via `export PX4_ESTIMATOR=lpe` before running the simulation.
 
-In the cmake config file for [posix_sitl_ekf2](https://github.com/PX4/Firmware/blob/master/cmake/configs/posix_sitl_ekf2.cmake) you can see that the init file will be stored in the folder: **Firmware/posix-configs/SITL/init/ekf2/**.
-```bash
-set(config_sitl_rcS_dir
-    posix-configs/SITL/init/ekf2
-    )
-```    
-
-> **Note** Generally the init files are located using a consistent folder naming convention. For example, `make posix_sitl_ekf2 gazebo_iris` corresponds to the following folder structure:
-```
-Firmware/
-  posix-configs/  (os=posix)
-    SITL/         (platform=sitl)
-      init/       
-        ekf2/     (feature=ekf2)
-          iris    (init file name)
-```
 
+### Startup Scripts {#scripts}
 
-### Example Startup File
-
-A slightly reduced version of the startup file for `make posix_sitl_ekf2 gazebo_iris` ([/Firmware/posix-configs/SITL/init/ekf2/iris](https://github.com/PX4/Firmware/blob/master/posix-configs/SITL/init/ekf2/iris)) is shown below.
-
-```bash
-uorb start
-param load
-dataman start
-param set BAT_N_CELLS 3
-param set CAL_ACC0_ID 1376264
-param set CAL_ACC0_XOFF 0.01
-...
-...
-param set SYS_MC_EST_GROUP 2
-param set SYS_RESTART_TYPE 2
-replay tryapplyparams
-simulator start -s
-tone_alarm start
-gyrosim start
-accelsim start
-barosim start
-adcsim start
-gpssim start
-pwm_out_sim mode_pwm
-sensors start
-commander start
-land_detector start multicopter
-navigator start
-ekf2 start
-mc_pos_control start
-mc_att_control start
-mixer load /dev/pwm_output0 ROMFS/px4fmu_common/mixers/quad_dc.main.mix
-mavlink start -u 14556 -r 4000000
-mavlink start -u 14557 -r 4000000 -m onboard -o 14540
-mavlink stream -r 50 -s POSITION_TARGET_LOCAL_NED -u 14556
-mavlink stream -r 50 -s LOCAL_POSITION_NED -u 14556
-mavlink stream -r 50 -s GLOBAL_POSITION_INT -u 14556
-mavlink stream -r 50 -s ATTITUDE -u 14556
-mavlink stream -r 50 -s ATTITUDE_QUATERNION -u 14556
-mavlink stream -r 50 -s ATTITUDE_TARGET -u 14556
-mavlink stream -r 50 -s SERVO_OUTPUT_RAW_0 -u 14556
-mavlink stream -r 20 -s RC_CHANNELS -u 14556
-mavlink stream -r 250 -s HIGHRES_IMU -u 14556
-mavlink stream -r 10 -s OPTICAL_FLOW_RAD -u 14556
-logger start -e -t
-mavlink boot_complete
-replay trystart
-```
-
-Note the sections that set parameters, start simulator drivers and other modules. A few of the more relevant lines for simulation are highlighted below. 
-
-1. Simulator being started:
-   ```
-   simulator start -s
-   ```
-1. PWM out mode being set for simulator:
-   ```
-   pwm_out_sim mode_pwm
-   ```
-1. Set MAVLink ports:
-
-   * This line starts the MAVLink instance for connecting to offboard APIs. It broadcasts on 14540 and listens for responses on 14557. The `-m onboard` flag specifies a set of messages that will be streamed over the interface.
-      ```bash
-      mavlink start -u 14557 -r 4000000 -m onboard -o 14540
-      ```
-   * This line starts MAVLink instance for connecting to *QGroundControl*/GCSs. PX4 listens for messages on port 14556. 
-   ```bash
-   mavlink start -u 14556 -r 4000000
-   ```
-      * The broadcast port is not explicitly set (the default is used: 14550). 
-      * The messages that are streamed over this interface are specified using `mavlink stream` as shown below:
-        ```
-        mavlink stream -r 50 -s POSITION_TARGET_LOCAL_NED -u 14556
-        mavlink stream -r 50 -s LOCAL_POSITION_NED -u 14556
-        ...
-        ```
-
-For more information about using the MAVLink module see [Modules Reference: Communication > MAVLink](../middleware/modules_communication.md#mavlink).
+Scripts are used to control which parameter settings to use or which modules to start.
+They are located in the [ROMFS/px4fmu_common/init.d-posix](https://github.com/PX4/Firmware/tree/master/ROMFS/px4fmu_common/init.d-posix) directory, the `rcS` file is the main entry point. See [System Startup](../advanced/system_startup.md) for more information.
 
 
 ## HITL Simulation Environment

From 00cfd8179d95678b41b7bb33b096ea9b9f8f7ea8 Mon Sep 17 00:00:00 2001
From: Hamish Willee <hamishwillee@gmail.com>
Date: Fri, 7 Sep 2018 10:45:33 +1000
Subject: [PATCH 2/6] Minor subedit of system startup docs

---
 en/advanced/system_startup.md | 26 +++++++++++++-------------
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/en/advanced/system_startup.md b/en/advanced/system_startup.md
index 649aee05f20..64773af63a7 100644
--- a/en/advanced/system_startup.md
+++ b/en/advanced/system_startup.md
@@ -1,34 +1,33 @@
 # System Startup
 
 The PX4 startup is controlled by shell scripts.
-On NuttX they reside in the [ROMFS/px4fmu_common/init.d](https://github.com/PX4/Firmware/tree/master/ROMFS/px4fmu_common/init.d) folder.
-A portion of these is also used on Posix and the ones that are only used on Posix are located in [ROMFS/px4fmu_common/init.d-posix](https://github.com/PX4/Firmware/tree/master/ROMFS/px4fmu_common/init.d-posix).
+On NuttX they reside in the [ROMFS/px4fmu_common/init.d](https://github.com/PX4/Firmware/tree/master/ROMFS/px4fmu_common/init.d) folder - some of these are also used on Posix (Linux/MacOS). The scripts that are only used on Posix are located in [ROMFS/px4fmu_common/init.d-posix](https://github.com/PX4/Firmware/tree/master/ROMFS/px4fmu_common/init.d-posix).
 
 All files starting with a number and underscore (e.g. `10000_airplane`) are canned airframe configurations. They are exported at build-time into an `airframes.xml` file which is parsed by [QGroundControl](http://qgroundcontrol.com) for the airframe selection UI. Adding a new configuration is covered [here](../airframes/adding_a_new_frame.md).
 
-The remaining files are part of the general startup logic, and the first executed file is the [init.d/rcS](https://github.com/PX4/Firmware/blob/master/ROMFS/px4fmu_common/init.d/rcS) (or [init.d-posix/rcS](https://github.com/PX4/Firmware/blob/master/ROMFS/px4fmu_common/init.d-posix/rcS) on Posix) script, which calls all other scripts.
+The remaining files are part of the general startup logic. The first executed file is the [init.d/rcS](https://github.com/PX4/Firmware/blob/master/ROMFS/px4fmu_common/init.d/rcS) script (or [init.d-posix/rcS](https://github.com/PX4/Firmware/blob/master/ROMFS/px4fmu_common/init.d-posix/rcS) on Posix), which calls all other scripts.
 
 
 ## Script Execution
 
-NuttX has a shell interpreter already integrated.
-On Posix (Linux/MacOS), the system shell is used as script interpreter (e.g. bash).
+NuttX has an integrated shell interpreter.
+On Posix, the system shell is used as script interpreter (e.g. bash).
 For that to work, a few things are required:
 - PX4 modules need to look like individual executables to the system. This is done via symbolic links.
-  For each module a symbolic link `px4-<module> -> px4` in the `bin` directory of the build folder is created.
+  For each module a symbolic link `px4-<module> -> px4` is created in the `bin` directory of the build folder.
   When executed, the binary path is checked (`argv[0]`), and if it is a module (starts with `px4-`), it sends the command to the main px4 instance (see below).
-  The `px4-` prefix is used to avoid conflicts with system commands, such as `shutdown`, and it also allows for simple tab completion by typing `px4-<TAB>`.
+  > **Tip** The `px4-` prefix is used to avoid conflicts with system commands (e.g. `shutdown`), and it also allows for simple tab completion by typing `px4-<TAB>`.
 - The shell needs to know where to find the symbolic links. For that the `bin` directory with the symbolic links is added to the `PATH` variable right before executing the startup scripts.
-- The shell starts each module as a new process. This client process needs to communicate with the main running instance of px4 (the server), where the actual modules are running as threads.
+- The shell starts each module as a new (client) process. Each client process needs to communicate with the main instance of px4 (the server), where the actual modules are running as threads.
   This is done with [FIFOs (also called named pipes)](http://man7.org/linux/man-pages/man7/fifo.7.html).
   The server has a FIFO opened, on which clients can send commands.
   In addition each client opens its own FIFO, which the server then uses to send information to the client (strings printed to the console for example).
 - The startup scripts do not use the `px4-` prefix, but they call the module directly, e.g. `commander start`. This works via aliases: for each module an alias in the form of `alias <module>=px4-<module>` is created in the file `bin/px4-alias.sh`.
 - The `rcS` script is executed from the main px4 instance.
-  It does not start any modules but first updates the `PATH` variable and then simply runs a shell with the `rcS` file as argument.
+  It does not start any modules, but first updates the `PATH` variable and then simply runs a shell with the `rcS` file as argument.
 - In addition to that, multiple server instances can be started for multi-vehicle simulations. A client selects the instance via `--instance`. The instance is available in the script via `$px4_instance` variable.
 
-The modules can be executed from any terminal when PX4 is already running. For example:
+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
 ./px4-commander takeoff
@@ -91,11 +90,12 @@ The following example shows how to start custom applications:
 
 ### Starting a custom mixer
 
-By default the system loads the mixer from `/etc/mixers`. If a file with the same name exists in `/fs/microsd/etc/mixers` this file will be loaded instead. This allows to customize the mixer file without the need to recompile the Firmware.
+By default the system loads the mixer from `/etc/mixers`. 
+If a file with the same name exists in `/fs/microsd/etc/mixers` this file will be loaded instead. This allows to customize the mixer file without the need to recompile the Firmware.
+
 #### Example
 The following example shows how to add a custom aux mixer:
-  * Create a file on the SD card, `etc/mixers/gimbal.aux.mix` with your mixer
-	content.
+  * Create a file on the SD card, `etc/mixers/gimbal.aux.mix` with your mixer content.
   * Then to use it, create an additional file `etc/config.txt` with this content:
     ```
     set MIXER_AUX gimbal

From 93da0af826bb00b525ae4c22d1c0f3b68420bd74 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beat=20K=C3=BCng?= <beat-kueng@gmx.net>
Date: Fri, 7 Sep 2018 11:03:25 +0200
Subject: [PATCH 3/6] system startup: move from 'Advanced Topics' to 'Concepts'

---
 en/SUMMARY.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/en/SUMMARY.md b/en/SUMMARY.md
index 4fb4e2d0d05..41fd4a5b86b 100644
--- a/en/SUMMARY.md
+++ b/en/SUMMARY.md
@@ -27,6 +27,7 @@
   * [Flight Modes](concept/flight_modes.md)
   * [Mixing and Actuators](concept/mixing.md)
   * [PWM limit state machine](concept/pwm_limit.md)
+  * [System Startup](advanced/system_startup.md)
 * [Simulation](simulation/README.md)
   * [jMAVSim Simulation](simulation/jmavsim.md)
   * [Gazebo Simulation](simulation/gazebo.md)
@@ -100,7 +101,6 @@
   * [Motion Capture \(VICON, Optitrack\)](tutorials/motion-capture-vicon-optitrack.md)
   * [S.Bus Driver for Linux](tutorials/linux_sbus.md)
 * [Advanced Topics](advanced/README.md)
-  * [System Startup](advanced/system_startup.md)
   * [Parameters & Configs](advanced/parameters_and_configurations.md)
   * [Parameter Reference](advanced/parameter_reference.md)
   * [Installing driver for Intel RealSense R200](advanced/realsense_intel_driver.md)

From 6caaa697f0aa5969018f3eb544b186c2444fce78 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beat=20K=C3=BCng?= <beat-kueng@gmx.net>
Date: Fri, 7 Sep 2018 11:05:00 +0200
Subject: [PATCH 4/6] system startup: split into NuttX and Posix sections.

Also changed the NuttX boot: driver failures will not lead to an
aborted boot anymore.
---
 en/advanced/system_startup.md | 29 +++++++++++++++--------------
 1 file changed, 15 insertions(+), 14 deletions(-)

diff --git a/en/advanced/system_startup.md b/en/advanced/system_startup.md
index 64773af63a7..496fb52836c 100644
--- a/en/advanced/system_startup.md
+++ b/en/advanced/system_startup.md
@@ -7,10 +7,11 @@ All files starting with a number and underscore (e.g. `10000_airplane`) are cann
 
 The remaining files are part of the general startup logic. The first executed file is the [init.d/rcS](https://github.com/PX4/Firmware/blob/master/ROMFS/px4fmu_common/init.d/rcS) script (or [init.d-posix/rcS](https://github.com/PX4/Firmware/blob/master/ROMFS/px4fmu_common/init.d-posix/rcS) on Posix), which calls all other scripts.
 
+The following sections are split according to the operating system that PX4 runs on.
 
-## Script Execution
 
-NuttX has an integrated shell interpreter.
+## Posix (Linux/MacOS)
+
 On Posix, the system shell is used as script interpreter (e.g. bash).
 For that to work, a few things are required:
 - PX4 modules need to look like individual executables to the system. This is done via symbolic links.
@@ -34,25 +35,25 @@ cd <Firmware>/build/posix_sitl_default/bin
 ./px4-listener sensor_accel
 ```
 
-## Debugging the System Boot
+## NuttX
+NuttX has an integrated shell interpreter ([NSH](http://nuttx.org/Documentation/NuttShell.html)), and thus scripts can be executed directly.
 
-A failure of a driver of software component can lead to an aborted boot.
+### Debugging the System Boot
 
-> **Tip** An incomplete boot often materializes as missing parameters in the ground control stations, because the non-started applications did not initialize their parameters.
+A failure of a driver of software component will not lead to an aborted boot. This is controlled via `set +e` in the startup script.
 
-The right approach to debug the boot sequence is to connect the [system console](../debug/system_console.md) and power-cycle the board. The resulting boot log has detailed information about the boot sequence and should contain hints why the boot aborted.
+The boot sequence can be debugged by connecting the [system console](../debug/system_console.md) and power-cycling the board. The resulting boot log has detailed information about the boot sequence and should contain hints why the boot aborted.
 
-### Common boot failure causes
+#### Common boot failure causes
 
-  * A required sensor failed to start
   * For custom applications: The system was out of RAM. Run the `free` command to see the amount of free RAM.
   * A software fault or assertion resulting in a stack trace
 
-## Replacing the System Startup
+### Replacing the System Startup
 
 In most cases customizing the default boot is the better approach, which is documented below. If the complete boot should be replaced, create a file `/fs/microsd/etc/rc.txt`, which is located in the `etc` folder on the microSD card. If this file is present nothing in the system will be auto-started.
 
-## Customizing the System Startup
+### Customizing the System Startup
 
 The best way to customize the system startup is to introduce a [new airframe configuration](../airframes/adding_a_new_frame.md). If only tweaks are wanted (like starting one more application or just using a different mixer) special hooks in the startup can be used.
 
@@ -64,11 +65,11 @@ There are three main hooks. Note that the root folder of the microsd card is ide
   * /fs/microsd/etc/extras.txt
   * /fs/microsd/etc/mixers/NAME_OF_MIXER
 
-### Customizing the Configuration (config.txt)
+#### Customizing the Configuration (config.txt)
 
 The `config.txt` file is loaded after the main system has been configured and *before* it is booted and allows to modify shell variables.
 
-### Starting additional applications
+#### Starting additional applications
 
 The `extras.txt` can be used to start additional applications after the main system boot. Typically these would be payload controllers or similar optional custom components.
 
@@ -88,12 +89,12 @@ The following example shows how to start custom applications:
     mandatory_app start     # Will abort boot if mandatory_app is unknown or fails
     ```  
 
-### Starting a custom mixer
+#### Starting a custom mixer
 
 By default the system loads the mixer from `/etc/mixers`. 
 If a file with the same name exists in `/fs/microsd/etc/mixers` this file will be loaded instead. This allows to customize the mixer file without the need to recompile the Firmware.
 
-#### Example
+##### Example
 The following example shows how to add a custom aux mixer:
   * Create a file on the SD card, `etc/mixers/gimbal.aux.mix` with your mixer content.
   * Then to use it, create an additional file `etc/config.txt` with this content:

From ce09261394c5379e2a98f07a1aef7d5ce70beee6 Mon Sep 17 00:00:00 2001
From: Hamish Willee <hamishwillee@gmail.com>
Date: Mon, 10 Sep 2018 10:44:14 +1000
Subject: [PATCH 5/6] Move system_startup.md into concepts

---
 en/SUMMARY.md                                | 2 +-
 en/advanced/gimbal_control.md                | 2 +-
 en/advanced/parameters_and_configurations.md | 2 +-
 en/airframes/adding_a_new_frame.md           | 2 +-
 en/apps/module_template.md                   | 2 +-
 en/{advanced => concept}/system_startup.md   | 0
 en/simulation/README.md                      | 2 +-
 kr/SUMMARY.md                                | 2 +-
 kr/advanced/gimbal_control.md                | 2 +-
 kr/advanced/parameters_and_configurations.md | 2 +-
 kr/airframes/adding_a_new_frame.md           | 2 +-
 kr/{advanced => concept}/system_startup.md   | 0
 kr/sensor/uart_ulanding_radar.md             | 2 +-
 redirects.json                               | 7 ++++++-
 zh/SUMMARY.md                                | 2 +-
 zh/advanced/parameters_and_configurations.md | 2 +-
 zh/airframes/adding_a_new_frame.md           | 2 +-
 zh/{advanced => concept}/system_startup.md   | 2 +-
 zh/sensor/uart_ulanding_radar.md             | 2 +-
 19 files changed, 22 insertions(+), 17 deletions(-)
 rename en/{advanced => concept}/system_startup.md (100%)
 rename kr/{advanced => concept}/system_startup.md (100%)
 rename zh/{advanced => concept}/system_startup.md (99%)

diff --git a/en/SUMMARY.md b/en/SUMMARY.md
index 41fd4a5b86b..7a9fe8db158 100644
--- a/en/SUMMARY.md
+++ b/en/SUMMARY.md
@@ -27,7 +27,7 @@
   * [Flight Modes](concept/flight_modes.md)
   * [Mixing and Actuators](concept/mixing.md)
   * [PWM limit state machine](concept/pwm_limit.md)
-  * [System Startup](advanced/system_startup.md)
+  * [System Startup](concept/system_startup.md)
 * [Simulation](simulation/README.md)
   * [jMAVSim Simulation](simulation/jmavsim.md)
   * [Gazebo Simulation](simulation/gazebo.md)
diff --git a/en/advanced/gimbal_control.md b/en/advanced/gimbal_control.md
index f3f6226df7a..00260c935c1 100644
--- a/en/advanced/gimbal_control.md
+++ b/en/advanced/gimbal_control.md
@@ -41,7 +41,7 @@ The output assignment is as following:
 > of how mixers work and the format of the mixer file.
 
 The outputs can be customized by [creating a mixer
-file](../advanced/system_startup.md#starting-a-custom-mixer) on the SD card with
+file](../concept/system_startup.md#starting-a-custom-mixer) on the SD card with
 name `etc/mixers/mount.aux.mix`.
 
 A basic basic mixer configuration for a mount is shown below.
diff --git a/en/advanced/parameters_and_configurations.md b/en/advanced/parameters_and_configurations.md
index 0f66c488467..e0a410c8b2c 100644
--- a/en/advanced/parameters_and_configurations.md
+++ b/en/advanced/parameters_and_configurations.md
@@ -2,7 +2,7 @@
 
 The PX4 platform uses the param subsystem (a flat table of float and int32_t values) and text files (for mixers and startup scripts) to store its configuration.
 
-The [system startup](../advanced/system_startup.md) and how [airframe configurations](../airframes/adding_a_new_frame.md) work are detailed on other pages. This section discusses the param subsystem in detail
+The [system startup](../concept/system_startup.md) and how [airframe configurations](../airframes/adding_a_new_frame.md) work are detailed on other pages. This section discusses the param subsystem in detail
 
 ## Command Line usage
 
diff --git a/en/airframes/adding_a_new_frame.md b/en/airframes/adding_a_new_frame.md
index 57024134aee..dc561284abf 100644
--- a/en/airframes/adding_a_new_frame.md
+++ b/en/airframes/adding_a_new_frame.md
@@ -4,7 +4,7 @@ PX4 uses canned airframe configurations as starting point for airframes. The con
 
 Adding a configuration is straightforward: create a new config file in the [init.d folder](https://github.com/PX4/Firmware/tree/master/ROMFS/px4fmu_common/init.d) (prepend the filename with an unused autostart ID), then [build and upload](../setup/building_px4.md) the software.
 
-Developers who do not want to create their own configuration can instead customize existing configurations using text files on the microSD card, as detailed on the [custom system startup](../advanced/system_startup.md) page.
+Developers who do not want to create their own configuration can instead customize existing configurations using text files on the microSD card, as detailed on the [custom system startup](../concept/system_startup.md) page.
 
 ## Configuration File Overview
 
diff --git a/en/apps/module_template.md b/en/apps/module_template.md
index 1b2cfbee97f..8092273283e 100644
--- a/en/apps/module_template.md
+++ b/en/apps/module_template.md
@@ -11,7 +11,7 @@ The template demonstrates the following additional features/aspects that are req
 - uORB subscriptions and waiting for topic updates.
 - Controlling the task that runs in the background via `start`/`stop`/`status`.
   The `module start [<arguments>]` command can then be directly added to the
-  [startup script](../advanced/system_startup.md).
+  [startup script](../concept/system_startup.md).
 - Command-line argument parsing.
 - Documentation: the `PRINT_MODULE_*` methods serve two purposes (the API is
   documented [in the source code](https://github.com/PX4/Firmware/blob/v1.8.0/src/platforms/px4_module.h#L381)):
diff --git a/en/advanced/system_startup.md b/en/concept/system_startup.md
similarity index 100%
rename from en/advanced/system_startup.md
rename to en/concept/system_startup.md
diff --git a/en/simulation/README.md b/en/simulation/README.md
index 15ffe39bc9c..3e393275e4f 100644
--- a/en/simulation/README.md
+++ b/en/simulation/README.md
@@ -129,7 +129,7 @@ The simulation can be further configured via environment variables:
 ### Startup Scripts {#scripts}
 
 Scripts are used to control which parameter settings to use or which modules to start.
-They are located in the [ROMFS/px4fmu_common/init.d-posix](https://github.com/PX4/Firmware/tree/master/ROMFS/px4fmu_common/init.d-posix) directory, the `rcS` file is the main entry point. See [System Startup](../advanced/system_startup.md) for more information.
+They are located in the [ROMFS/px4fmu_common/init.d-posix](https://github.com/PX4/Firmware/tree/master/ROMFS/px4fmu_common/init.d-posix) directory, the `rcS` file is the main entry point. See [System Startup](../concept/system_startup.md) for more information.
 
 
 ## HITL Simulation Environment
diff --git a/kr/SUMMARY.md b/kr/SUMMARY.md
index f9d381f5bbd..93ea26280e5 100644
--- a/kr/SUMMARY.md
+++ b/kr/SUMMARY.md
@@ -24,6 +24,7 @@
   * [미들웨어](concept/middleware.md)
   * [미싱과 액츄레이터](concept/mixing.md)
   * [PWM limit 상태 머신](concept/pwm_limit.md)
+  * [시스템 부트](concept/system_startup.md)
 * [시뮬레이션](simulation/README.md)
   * [jMAVSim 시뮬레이션](simulation/jmavsim.md)
   * [Gazebo 시뮬레이션](simulation/gazebo.md)
@@ -101,7 +102,6 @@
   * [모션 캡쳐 \(VICON, Optitrack\)](tutorials/motion-capture-vicon-optitrack.md)
   * [리눅스 S.Bus 드라이버](tutorials/linux_sbus.md)
 * [Advanced Topics](advanced/README.md)
-  * [시스템 부트](advanced/system_startup.md)
   * [퍄라미터 & 설정](advanced/parameters_and_configurations.md)
   * [파라미터 레퍼런스 (Korean)](advanced/parameter_reference_korean.md)
   * [파라미터 레퍼런스 (English)](advanced/parameter_reference.md)
diff --git a/kr/advanced/gimbal_control.md b/kr/advanced/gimbal_control.md
index f3f6226df7a..00260c935c1 100644
--- a/kr/advanced/gimbal_control.md
+++ b/kr/advanced/gimbal_control.md
@@ -41,7 +41,7 @@ The output assignment is as following:
 > of how mixers work and the format of the mixer file.
 
 The outputs can be customized by [creating a mixer
-file](../advanced/system_startup.md#starting-a-custom-mixer) on the SD card with
+file](../concept/system_startup.md#starting-a-custom-mixer) on the SD card with
 name `etc/mixers/mount.aux.mix`.
 
 A basic basic mixer configuration for a mount is shown below.
diff --git a/kr/advanced/parameters_and_configurations.md b/kr/advanced/parameters_and_configurations.md
index 1b4cb75d047..2a758d3d0f8 100644
--- a/kr/advanced/parameters_and_configurations.md
+++ b/kr/advanced/parameters_and_configurations.md
@@ -2,7 +2,7 @@
 
 PX4 플랫폼은 파라미터 서브시스템(float과 int32_t 값의 일반 테이블)과 텍스트 파일(믹서와 startup 스크립트용)을 사용해서 설정을 저장합니다.
 
-[시스템 startup](../advanced/system_startup.md)과 [airframe 설정](../airframes/adding_a_new_frame.md) 동작 방법은 다른 페이지에서 설명합니다. 이 섹션에서는 파라미터 서브시스템에 대해서 상세히 알아봅니다.
+[시스템 startup](../concept/system_startup.md)과 [airframe 설정](../airframes/adding_a_new_frame.md) 동작 방법은 다른 페이지에서 설명합니다. 이 섹션에서는 파라미터 서브시스템에 대해서 상세히 알아봅니다.
 
 ## 커맨드 라인 사용법
 
diff --git a/kr/airframes/adding_a_new_frame.md b/kr/airframes/adding_a_new_frame.md
index 8fde4c3c790..e175158f656 100644
--- a/kr/airframes/adding_a_new_frame.md
+++ b/kr/airframes/adding_a_new_frame.md
@@ -2,7 +2,7 @@
 
 PX4는 airframe을 시작 시점에 설정을 이용합니다. 설정을 추가하는 것은 직관적입니다. : [init.d 폴더](https://github.com/PX4/Firmware/tree/master/ROMFS/px4fmu_common/init.d) 내에 free autosart ID를 가지는 새로운 파일을 생성하고 소프트웨어를 [빌드 및 업로드](../setup/building_px4.md)합니다.
 
-자신만의 설정을 새로 만드는 것을 원치 않는 개발자라면 microSD 카드에서 텍스트파일을 이용해서 기존 설정을 대신 수정할 수 있습니다. 상세한 내용은 [커스텀 시스템 startup](../advanced/system_startup.md)을 참고하세요.
+자신만의 설정을 새로 만드는 것을 원치 않는 개발자라면 microSD 카드에서 텍스트파일을 이용해서 기존 설정을 대신 수정할 수 있습니다. 상세한 내용은 [커스텀 시스템 startup](../concept/system_startup.md)을 참고하세요.
 
 ## Airframe 설정
 
diff --git a/kr/advanced/system_startup.md b/kr/concept/system_startup.md
similarity index 100%
rename from kr/advanced/system_startup.md
rename to kr/concept/system_startup.md
diff --git a/kr/sensor/uart_ulanding_radar.md b/kr/sensor/uart_ulanding_radar.md
index 11fbeb7eb32..f9f6ffd6154 100644
--- a/kr/sensor/uart_ulanding_radar.md
+++ b/kr/sensor/uart_ulanding_radar.md
@@ -14,7 +14,7 @@ drivers/ulanding
 
 ## 드라이버 구동시키기
 sytem이 시작되는 동안 radar를 위해 driver를 구동시키라고 sytem에게 알려야만 합니다.
-SD 카드에 위치한 [extras.txt](../advanced/system_startup.md) 파일에 간단하게 다음 라인을 추가합니다.
+SD 카드에 위치한 [extras.txt](../concept/system_startup.md) 파일에 간단하게 다음 라인을 추가합니다.
 ```
 ulanding_radar start /dev/serial_port
 ```
diff --git a/redirects.json b/redirects.json
index cfe5f331beb..a8549acf0af 100644
--- a/redirects.json
+++ b/redirects.json
@@ -1,6 +1,11 @@
 {
     "redirects": [
-    
+
+
+            {
+                "from": "en/advanced/system_startup.html",
+                "to": "https://dev.px4.io/en/concept/system_startup.html"
+            },
             {
                 "from": "en/tutorials/camera_trigger.html",
                 "to": "https://docs.px4.io/en/peripherals/camera.html"
diff --git a/zh/SUMMARY.md b/zh/SUMMARY.md
index 2942d1037e8..81b7e437f88 100644
--- a/zh/SUMMARY.md
+++ b/zh/SUMMARY.md
@@ -100,7 +100,7 @@
   * [着陆检测](tutorials/land_detector.md)
   * [Linux系统下使用S.Bus驱动](tutorials/linux_sbus.md)
 * [Advanced Topics](advanced/README.md)
-  * [系统启动](advanced/system_startup.md)
+  * [系统启动](concept/system_startup.md)
   * [参数&配置](advanced/parameters_and_configurations.md)
   * [参考参数](advanced/parameter_reference.md)
   * [安装Intel RealSense R200的驱动](advanced/realsense_intel_driver.md)
diff --git a/zh/advanced/parameters_and_configurations.md b/zh/advanced/parameters_and_configurations.md
index 2a75e5188c5..ae65c34ddce 100644
--- a/zh/advanced/parameters_and_configurations.md
+++ b/zh/advanced/parameters_and_configurations.md
@@ -7,7 +7,7 @@ translated_sha: 95b39d747851dd01c1fe5d36b24e59ec865e323e
 
 PX4使用参数子系统（实际就是浮点和整型数据的列表）和文本文件（用来配置Mixer混合器和启动脚本）来储存相关配置。
 
-关于[系统启动](../advanced/system_startup.md) 和[机体参数配置](../airframes/adding_a_new_frame.md)的实现在其他章节有详细讲述。这部分主要是详细讨论参数子系统。
+关于[系统启动](../concept/system_startup.md) 和[机体参数配置](../airframes/adding_a_new_frame.md)的实现在其他章节有详细讲述。这部分主要是详细讨论参数子系统。
 
 ## 命令行的使用
 
diff --git a/zh/airframes/adding_a_new_frame.md b/zh/airframes/adding_a_new_frame.md
index 9f3dab07198..023bea514d8 100644
--- a/zh/airframes/adding_a_new_frame.md
+++ b/zh/airframes/adding_a_new_frame.md
@@ -8,7 +8,7 @@ translated_sha: f7d0be49d427db1a07e35167f8fe7e861d577b27
 
 PX4使用存储的配置作为机型的起始点。添加配置是非常简单的：在[init.d文件夹](https://github.com/PX4/Firmware/tree/master/ROMFS/px4fmu_common/init.d)创建一个新的文件，这个文件需要以一个没有使用的自动启动ID作为文件名的前缀，然后[构建并上传](../setup/building_px4.md)固件即可。
 
-如果不想创建自己的配置文件，也可以用SD卡上的文本文件替换掉已有的自定义配置文件，具体细节请查看[自定义系统启动](../advanced/system_startup.md)页。
+如果不想创建自己的配置文件，也可以用SD卡上的文本文件替换掉已有的自定义配置文件，具体细节请查看[自定义系统启动](../concept/system_startup.md)页。
 
 ## 机型配置
 
diff --git a/zh/advanced/system_startup.md b/zh/concept/system_startup.md
similarity index 99%
rename from zh/advanced/system_startup.md
rename to zh/concept/system_startup.md
index eb88943e2bc..54fca4ba2b9 100644
--- a/zh/advanced/system_startup.md
+++ b/zh/concept/system_startup.md
@@ -1,5 +1,5 @@
 ---
-translated_page: https://github.com/PX4/Devguide/blob/master/en/advanced/system_startup.md
+translated_page: https://github.com/PX4/Devguide/blob/master/en/concept/system_startup.md
 translated_sha: 95b39d747851dd01c1fe5d36b24e59ec865e323e
 ---
 
diff --git a/zh/sensor/uart_ulanding_radar.md b/zh/sensor/uart_ulanding_radar.md
index 3970b4dc3a6..020b4a4bc97 100644
--- a/zh/sensor/uart_ulanding_radar.md
+++ b/zh/sensor/uart_ulanding_radar.md
@@ -26,7 +26,7 @@ drivers/ulanding
 ##  启动驱动程序
 
 
-在系统启动期间，须告诉系统启动雷达驱动程序，将以下行添加到位于SD卡上的[extras.txt](../advanced/system_startup.md)文件即可。
+在系统启动期间，须告诉系统启动雷达驱动程序，将以下行添加到位于SD卡上的[extras.txt](../concept/system_startup.md)文件即可。
 
 ```
 ulanding_radar start /dev/serial_port

From 4cb85d02d5388fea05b5739de34c580dc091ef82 Mon Sep 17 00:00:00 2001
From: Hamish Willee <hamishwillee@gmail.com>
Date: Mon, 10 Sep 2018 10:52:11 +1000
Subject: [PATCH 6/6] Minor subedit system_status and copy to translation areas

---
 en/concept/system_startup.md |   4 +-
 kr/concept/system_startup.md |  98 ++++++++++++++++++-----------
 zh/concept/system_startup.md | 115 +++++++++++++++++++++++++----------
 3 files changed, 150 insertions(+), 67 deletions(-)

diff --git a/en/concept/system_startup.md b/en/concept/system_startup.md
index 496fb52836c..419598ff752 100644
--- a/en/concept/system_startup.md
+++ b/en/concept/system_startup.md
@@ -23,7 +23,7 @@ For that to work, a few things are required:
   This is done with [FIFOs (also called named pipes)](http://man7.org/linux/man-pages/man7/fifo.7.html).
   The server has a FIFO opened, on which clients can send commands.
   In addition each client opens its own FIFO, which the server then uses to send information to the client (strings printed to the console for example).
-- The startup scripts do not use the `px4-` prefix, but they call the module directly, e.g. `commander start`. This works via aliases: for each module an alias in the form of `alias <module>=px4-<module>` is created in the file `bin/px4-alias.sh`.
+- The startup scripts call the module directly, e.g. `commander start`, rather than using the `px4-` prefix. This works via aliases: for each module an alias in the form of `alias <module>=px4-<module>` is created in the file `bin/px4-alias.sh`.
 - The `rcS` script is executed from the main px4 instance.
   It does not start any modules, but first updates the `PATH` variable and then simply runs a shell with the `rcS` file as argument.
 - In addition to that, multiple server instances can be started for multi-vehicle simulations. A client selects the instance via `--instance`. The instance is available in the script via `$px4_instance` variable.
@@ -67,7 +67,7 @@ There are three main hooks. Note that the root folder of the microsd card is ide
 
 #### Customizing the Configuration (config.txt)
 
-The `config.txt` file is loaded after the main system has been configured and *before* it is booted and allows to modify shell variables.
+The `config.txt` file can be used to modify shell variables. It is loaded after the main system has been configured and *before* it is booted.
 
 #### Starting additional applications
 
diff --git a/kr/concept/system_startup.md b/kr/concept/system_startup.md
index df046d65338..419598ff752 100644
--- a/kr/concept/system_startup.md
+++ b/kr/concept/system_startup.md
@@ -1,73 +1,103 @@
 # System Startup
 
-The PX4 부트는 [ROMFS/px4fmu_common/init.d](https://github.com/PX4/Firmware/tree/master/ROMFS/px4fmu_common/init.d) 폴더에 있는 쉘 스크립트가 제어합니다.
+The PX4 startup is controlled by shell scripts.
+On NuttX they reside in the [ROMFS/px4fmu_common/init.d](https://github.com/PX4/Firmware/tree/master/ROMFS/px4fmu_common/init.d) folder - some of these are also used on Posix (Linux/MacOS). The scripts that are only used on Posix are located in [ROMFS/px4fmu_common/init.d-posix](https://github.com/PX4/Firmware/tree/master/ROMFS/px4fmu_common/init.d-posix).
 
-숫자와 밑줄로 시작하는 모든 파일은 airframe 설정과 관련되어 있습니다.(예 `10000_airplane`) 빌드하는 과정에서 `airframes.xml`로 export되며 airframe 선택하는 UI에서 사용하기 위해 [QGroundControl](http://qgroundcontrol.com)에서 파싱됩니다. 새로운 설정을 추가하는 방법은 [여기](../airframes/adding_a_new_frame.md)를 참고하세요.
+All files starting with a number and underscore (e.g. `10000_airplane`) are canned airframe configurations. They are exported at build-time into an `airframes.xml` file which is parsed by [QGroundControl](http://qgroundcontrol.com) for the airframe selection UI. Adding a new configuration is covered [here](../airframes/adding_a_new_frame.md).
 
-나머지 파일들은 일반적인 startup 로직의 일부로 사용되며 처음 실행되는 파일은 [rcS](https://github.com/PX4/Firmware/blob/master/ROMFS/px4fmu_common/init.d/rcS) 스크립트이며 이 스크립트에서 다른 스크립트를 호출하게 됩니다.
+The remaining files are part of the general startup logic. The first executed file is the [init.d/rcS](https://github.com/PX4/Firmware/blob/master/ROMFS/px4fmu_common/init.d/rcS) script (or [init.d-posix/rcS](https://github.com/PX4/Firmware/blob/master/ROMFS/px4fmu_common/init.d-posix/rcS) on Posix), which calls all other scripts.
 
-## 시스템 부팅 디버깅하기
+The following sections are split according to the operating system that PX4 runs on.
 
-소프트웨어 컴포넌트 드라이버 중에 하나라도 실패하면 부팅이 실패하게 됩니다.
 
-> **Tip** 불완전하게 부팅되는 경우 ground control station에서 파라미터가 제대로 설정되지 않게 됩니다. 이는 실행되지 않은 application에서 파라미터를 초기화하지 않았기 때문입니다.
+## Posix (Linux/MacOS)
 
-부팅 순서를 디버깅하는 올바른 방법은 [system console](../debug/system_console.md)에 연결하여 보드에 전원이 들어오는 과정을 살펴봐야 합니다. 부팅 로그를 보면 부팅 순서에 대해서 상세한 정보를 얻을 수 있기에 왜 부팅에 문제가 있었는지 힌트를 얻을 수 있습니다.
+On Posix, the system shell is used as script interpreter (e.g. bash).
+For that to work, a few things are required:
+- PX4 modules need to look like individual executables to the system. This is done via symbolic links.
+  For each module a symbolic link `px4-<module> -> px4` is created in the `bin` directory of the build folder.
+  When executed, the binary path is checked (`argv[0]`), and if it is a module (starts with `px4-`), it sends the command to the main px4 instance (see below).
+  > **Tip** The `px4-` prefix is used to avoid conflicts with system commands (e.g. `shutdown`), and it also allows for simple tab completion by typing `px4-<TAB>`.
+- The shell needs to know where to find the symbolic links. For that the `bin` directory with the symbolic links is added to the `PATH` variable right before executing the startup scripts.
+- The shell starts each module as a new (client) process. Each client process needs to communicate with the main instance of px4 (the server), where the actual modules are running as threads.
+  This is done with [FIFOs (also called named pipes)](http://man7.org/linux/man-pages/man7/fifo.7.html).
+  The server has a FIFO opened, on which clients can send commands.
+  In addition each client opens its own FIFO, which the server then uses to send information to the client (strings printed to the console for example).
+- The startup scripts call the module directly, e.g. `commander start`, rather than using the `px4-` prefix. This works via aliases: for each module an alias in the form of `alias <module>=px4-<module>` is created in the file `bin/px4-alias.sh`.
+- The `rcS` script is executed from the main px4 instance.
+  It does not start any modules, but first updates the `PATH` variable and then simply runs a shell with the `rcS` file as argument.
+- In addition to that, multiple server instances can be started for multi-vehicle simulations. A client selects the instance via `--instance`. The instance is available in the script via `$px4_instance` variable.
 
-### 일반적인 부팅 실패 원인
+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
+./px4-commander takeoff
+./px4-listener sensor_accel
+```
 
-  * 필요한 센서의 구동 실패
-  * 커스텀 application의 경우 : 시스템의 RAM 메모리가 부족한 경우. `free` 명령을 통해 남은 RAM 메모리 공간을 확인.
-  * 소프트웨어 문제나 assertion의 경우 stack trace로 확인 가능
+## NuttX
+NuttX has an integrated shell interpreter ([NSH](http://nuttx.org/Documentation/NuttShell.html)), and thus scripts can be executed directly.
 
-## 시스템 Startup 바꿔치기
+### Debugging the System Boot
 
-일반적으로 기본 부팅에서 바꾸는 것이 좋은 접근법입니다. 이와 관련해서 아래 문서를 참고하세요. 만약 완전히 부팅을 바꿔치기하고자 한다면, `/fs/microsd/etc/rc.txt` 파일을 생성합니다. 이 파일은 마이크로SD 카드의 `etc` 폴더에 위치하고 있습니다. 이 파일이 존재하는 경우 시스템에서 자동으로 시작되는 것이 없어집니다.
+A failure of a driver of software component will not lead to an aborted boot. This is controlled via `set +e` in the startup script.
 
-## 시스템 Startup 수정하기
+The boot sequence can be debugged by connecting the [system console](../debug/system_console.md) and power-cycling the board. The resulting boot log has detailed information about the boot sequence and should contain hints why the boot aborted.
 
-시스템 startup을 수정하는 가장 좋은 방법은 [new airframe configuration](../airframes/adding_a_new_frame.md)을 참고합니다. 몇 가지 수정을 하고 싶다면(1개 이상 application을 시작시킨다던가 다른 mixer를 사용하는 경우) 해당 startup에서 수정해서 사용할 수 있습니다.
+#### Common boot failure causes
 
-> **Caution** 시스템 부트 파일은 UNIX 포맷의 파일로 각 라인의 끝에는 UNIX LINED ENDING이 들어가야 합니다. 만약 윈도우에서 수정하는 경우 이를 지원하는 편집기를 이용하도록 합니다.
+  * For custom applications: The system was out of RAM. Run the `free` command to see the amount of free RAM.
+  * A software fault or assertion resulting in a stack trace
 
-가지 주요 수정지점이 있습니다. microSD 카드의 루트 폴더는 `/fs/microsd`로 나타냅니다.
+### Replacing the System Startup
+
+In most cases customizing the default boot is the better approach, which is documented below. If the complete boot should be replaced, create a file `/fs/microsd/etc/rc.txt`, which is located in the `etc` folder on the microSD card. If this file is present nothing in the system will be auto-started.
+
+### Customizing the System Startup
+
+The best way to customize the system startup is to introduce a [new airframe configuration](../airframes/adding_a_new_frame.md). If only tweaks are wanted (like starting one more application or just using a different mixer) special hooks in the startup can be used.
+
+> **Caution** The system boot files are UNIX FILES which require UNIX LINE ENDINGS. If editing on Windows use a suitable editor.
+
+There are three main hooks. Note that the root folder of the microsd card is identified by the path `/fs/microsd`.
 
   * /fs/microsd/etc/config.txt
   * /fs/microsd/etc/extras.txt
   * /fs/microsd/etc/mixers/NAME_OF_MIXER
 
-### 설정 변경하기 (config.txt)
+#### Customizing the Configuration (config.txt)
 
-`config.txt`파일이 로드는 것은 main 시스템이 구성을 마치고 난 후고 부트가 되기 *전* 으로 쉘 변수를 수정하는 것이 가능합니다.
+The `config.txt` file can be used to modify shell variables. It is loaded after the main system has been configured and *before* it is booted.
 
-### 추가 application 구동시키기
+#### Starting additional applications
 
-`extras.txt`는 main 시스템이 부팅되고 나서 추가로 application을 구동시키는데 사용할 수 있습니다. 일반적으로 여기에 해당되는 것은 payload controller나 유사한 선택가능한 커스텀 컴포넌트들입니다.
+The `extras.txt` can be used to start additional applications after the main system boot. Typically these would be payload controllers or similar optional custom components.
 
-> **Caution** 시스템 부트 파일에서 알수 없는 명령을 호출하면 부트 실패가 됩니다. 일반적으로 부트 실패가 되면 mavlink 메시지를 내보내지 않습니다. 이 경우 시스템 콘솔에 출력되는 에러 메시지를 확인합니다.
+> **Caution** Calling an unknown command in system boot files may result in boot failure. Typically the system does not stream mavlink messages after boot failure, in this case check the error messages that are printed on the system console.
 
-다음 예제에서는 커스텀 어플리케이션을 구동하는 방법에 대해서 알아봅니다:
-  * SD 카드 `etc/extras.txt`에 다음과 같은 내용의 파일을 생성:
+The following example shows how to start custom applications:
+  * Create a file on the SD card `etc/extras.txt` with this content:
     ```
     custom_app start
     ```
-  * `set +e` 와 `set -e` 명령으로
-  A command can be made optional by gating it with the `set +e` and `set -e` commands:
+  * A command can be made optional by gating it with the `set +e` and `set -e` commands:
     ```
     set +e
-    optional_app start      # optional_app이 없거나 실패하는 경우 부트 실패로 이어지지 않는다
+    optional_app start      # Will not result in boot failure if optional_app is unknown or fails
     set -e
 
-    mandatory_app start     # mandatory_app이 없거나 실패하는 경우 부트가 취소된다
+    mandatory_app start     # Will abort boot if mandatory_app is unknown or fails
     ```  
 
-### 커스텀 믹서 구동시키기 {#starting-a-custom-mixer}
+#### Starting a custom mixer
+
+By default the system loads the mixer from `/etc/mixers`. 
+If a file with the same name exists in `/fs/microsd/etc/mixers` this file will be loaded instead. This allows to customize the mixer file without the need to recompile the Firmware.
 
-기본적으로 `/etc/mixers`에서 시스템이 믹서를 로드합니다. `/fs/microsd/etc/mixers`에 동일한 이름의 파일이 있는 경우, 이 파일이 대신 로드될 것입니다. 펌웨어를 다시 컴파일할 필요없이 믹서 파일을 수정하는 것이 가능합니다.
-#### 예제
-다음 예제는 커스텀 aux 믹서를 추가하는 방법을 보여줍니다 :
-  * 믹서 관련 내용이 있는 `etc/mixers/gimbal.aux.mix` SD카드에 파일을 생성합니다.
-  * 다음으로 이를 이용하기 위해서 아래 내용을 `etc/config.txt` 파일 추가하여 생성합니다.:
+##### Example
+The following example shows how to add a custom aux mixer:
+  * Create a file on the SD card, `etc/mixers/gimbal.aux.mix` with your mixer content.
+  * Then to use it, create an additional file `etc/config.txt` with this content:
     ```
     set MIXER_AUX gimbal
     set PWM_AUX_OUT 1234
diff --git a/zh/concept/system_startup.md b/zh/concept/system_startup.md
index 54fca4ba2b9..419598ff752 100644
--- a/zh/concept/system_startup.md
+++ b/zh/concept/system_startup.md
@@ -1,55 +1,108 @@
----
-translated_page: https://github.com/PX4/Devguide/blob/master/en/concept/system_startup.md
-translated_sha: 95b39d747851dd01c1fe5d36b24e59ec865e323e
----
+# System Startup
 
-# 系统启动
+The PX4 startup is controlled by shell scripts.
+On NuttX they reside in the [ROMFS/px4fmu_common/init.d](https://github.com/PX4/Firmware/tree/master/ROMFS/px4fmu_common/init.d) folder - some of these are also used on Posix (Linux/MacOS). The scripts that are only used on Posix are located in [ROMFS/px4fmu_common/init.d-posix](https://github.com/PX4/Firmware/tree/master/ROMFS/px4fmu_common/init.d-posix).
 
+All files starting with a number and underscore (e.g. `10000_airplane`) are canned airframe configurations. They are exported at build-time into an `airframes.xml` file which is parsed by [QGroundControl](http://qgroundcontrol.com) for the airframe selection UI. Adding a new configuration is covered [here](../airframes/adding_a_new_frame.md).
 
-该PX4启动是由 [ROMFS/px4fmu_common/init.d](https://github.com/PX4/Firmware/tree/master/ROMFS/px4fmu_common/init.d)文件夹下的shell脚本控制。
+The remaining files are part of the general startup logic. The first executed file is the [init.d/rcS](https://github.com/PX4/Firmware/blob/master/ROMFS/px4fmu_common/init.d/rcS) script (or [init.d-posix/rcS](https://github.com/PX4/Firmware/blob/master/ROMFS/px4fmu_common/init.d-posix/rcS) on Posix), which calls all other scripts.
 
-所有以数字和下划线（例如`10000_airplane`）开头的文件的都是内置的机型配置。他们在编译时被导出成一个`airframes.xml`文件，它被 [QGroundControl](http://qgroundcontrol.org)解析后提供给机身选择界面使用。添加新的配置参照[此处](../airframes/adding_a_new_frame.md)。
+The following sections are split according to the operating system that PX4 runs on.
 
-剩余的文件是常规启动逻辑的一部分，并且第一执行文件是[rcS](https://github.com/PX4/Firmware/blob/master/ROMFS/px4fmu_common/init.d/rcS)脚本，它调用所有其它的脚本。
 
-## 调试系统启动
+## Posix (Linux/MacOS)
 
-软件组件的驱动程序故障会导致启动中止。
+On Posix, the system shell is used as script interpreter (e.g. bash).
+For that to work, a few things are required:
+- PX4 modules need to look like individual executables to the system. This is done via symbolic links.
+  For each module a symbolic link `px4-<module> -> px4` is created in the `bin` directory of the build folder.
+  When executed, the binary path is checked (`argv[0]`), and if it is a module (starts with `px4-`), it sends the command to the main px4 instance (see below).
+  > **Tip** The `px4-` prefix is used to avoid conflicts with system commands (e.g. `shutdown`), and it also allows for simple tab completion by typing `px4-<TAB>`.
+- The shell needs to know where to find the symbolic links. For that the `bin` directory with the symbolic links is added to the `PATH` variable right before executing the startup scripts.
+- The shell starts each module as a new (client) process. Each client process needs to communicate with the main instance of px4 (the server), where the actual modules are running as threads.
+  This is done with [FIFOs (also called named pipes)](http://man7.org/linux/man-pages/man7/fifo.7.html).
+  The server has a FIFO opened, on which clients can send commands.
+  In addition each client opens its own FIFO, which the server then uses to send information to the client (strings printed to the console for example).
+- The startup scripts call the module directly, e.g. `commander start`, rather than using the `px4-` prefix. This works via aliases: for each module an alias in the form of `alias <module>=px4-<module>` is created in the file `bin/px4-alias.sh`.
+- The `rcS` script is executed from the main px4 instance.
+  It does not start any modules, but first updates the `PATH` variable and then simply runs a shell with the `rcS` file as argument.
+- In addition to that, multiple server instances can be started for multi-vehicle simulations. A client selects the instance via `--instance`. The instance is available in the script via `$px4_instance` variable.
 
-> **Tip** 一个不完整的启动往往表现为地面站中参数丢失，因为无法启动的应用程序没有初始化它们的参数。
+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
+./px4-commander takeoff
+./px4-listener sensor_accel
+```
 
-调试启动序列正确的方法是连接[系统控制台](../debug/system_console.md) 和为电路板供电。由此产生的启动日志包含引导序列的详细信息，而且应该包含引导中止得原因。
+## NuttX
+NuttX has an integrated shell interpreter ([NSH](http://nuttx.org/Documentation/NuttShell.html)), and thus scripts can be executed directly.
 
-### 常见启动故障的原因
+### Debugging the System Boot
 
-- 一个必须的传感器发生故障
-- 对于自定义的应用程序: 该系统内存不足。运行 `free` 命令来查看可用内存量。
-  - 软件故障或断言导致堆栈跟踪
+A failure of a driver of software component will not lead to an aborted boot. This is controlled via `set +e` in the startup script.
 
-## 更换系统启动
+The boot sequence can be debugged by connecting the [system console](../debug/system_console.md) and power-cycling the board. The resulting boot log has detailed information about the boot sequence and should contain hints why the boot aborted.
 
-在大多数情况下，自定义修改默认的启动是更好的方法，这在后面介绍。如果要替换完整的boot，创建一个`/fs/microsd/etc/rc.txt`文件，它在microSD卡上的`etc`文件夹中。如果这个文件存在，系统中没有什么会自动启动。
+#### Common boot failure causes
 
-## 自定义系统启动
+  * For custom applications: The system was out of RAM. Run the `free` command to see the amount of free RAM.
+  * A software fault or assertion resulting in a stack trace
 
-自定义系统启动的最好的方式是引进新的 [机身配置](../airframes/adding_a_new_frame.md)。如果仅仅进行微调（如多启动一个应用程序或只是使用不同的混合器），启动时可以使用特别的hook。
+### Replacing the System Startup
 
-> **Warning** 该系统启动文件是UNIX文件，这需要UNIX形式的行结尾。如果在Windows上编辑，请使用合适的编辑器。
+In most cases customizing the default boot is the better approach, which is documented below. If the complete boot should be replaced, create a file `/fs/microsd/etc/rc.txt`, which is located in the `etc` folder on the microSD card. If this file is present nothing in the system will be auto-started.
 
-主要有三个hook。需要注意的是microSD卡的根目录文件夹路径是 `/fs/microsd`。
+### Customizing the System Startup
 
-- /fs/microsd/etc/config.txt
-- /fs/microsd/etc/extras.txt
-  - /fs/microsd/mixers/NAME_OF_MIXER
+The best way to customize the system startup is to introduce a [new airframe configuration](../airframes/adding_a_new_frame.md). If only tweaks are wanted (like starting one more application or just using a different mixer) special hooks in the startup can be used.
 
-### 自定义配置 (config.txt)
+> **Caution** The system boot files are UNIX FILES which require UNIX LINE ENDINGS. If editing on Windows use a suitable editor.
 
-主系统配置完成后，且在启动前，加载`config.txt` 文件，此时允许修改shell变量。
+There are three main hooks. Note that the root folder of the microsd card is identified by the path `/fs/microsd`.
 
-### 启动其他应用程序
+  * /fs/microsd/etc/config.txt
+  * /fs/microsd/etc/extras.txt
+  * /fs/microsd/etc/mixers/NAME_OF_MIXER
 
- `extras.txt`可用于在主系统引导后启动额外的应用程序。通常，这些将是载荷控制器或类似的可选自定义组件。
+#### Customizing the Configuration (config.txt)
 
-### 启动一个自定义的mixer {#starting-a-custom-mixer}
+The `config.txt` file can be used to modify shell variables. It is loaded after the main system has been configured and *before* it is booted.
 
-系统默认从 `/etc/mixers`加载mixer。如果在 `/fs/microsd/etc/mixers`有相同名称的文件中存在，那么将加载该文件来代替。这允许定制混合器文件，而不需要重新编译固件。
+#### Starting additional applications
+
+The `extras.txt` can be used to start additional applications after the main system boot. Typically these would be payload controllers or similar optional custom components.
+
+> **Caution** Calling an unknown command in system boot files may result in boot failure. Typically the system does not stream mavlink messages after boot failure, in this case check the error messages that are printed on the system console.
+
+The following example shows how to start custom applications:
+  * Create a file on the SD card `etc/extras.txt` with this content:
+    ```
+    custom_app start
+    ```
+  * A command can be made optional by gating it with the `set +e` and `set -e` commands:
+    ```
+    set +e
+    optional_app start      # Will not result in boot failure if optional_app is unknown or fails
+    set -e
+
+    mandatory_app start     # Will abort boot if mandatory_app is unknown or fails
+    ```  
+
+#### Starting a custom mixer
+
+By default the system loads the mixer from `/etc/mixers`. 
+If a file with the same name exists in `/fs/microsd/etc/mixers` this file will be loaded instead. This allows to customize the mixer file without the need to recompile the Firmware.
+
+##### Example
+The following example shows how to add a custom aux mixer:
+  * Create a file on the SD card, `etc/mixers/gimbal.aux.mix` with your mixer content.
+  * Then to use it, create an additional file `etc/config.txt` with this content:
+    ```
+    set MIXER_AUX gimbal
+    set PWM_AUX_OUT 1234
+    set PWM_AUX_DISARMED 1500
+    set PWM_AUX_MIN 1000
+    set PWM_AUX_MAX 2000
+    set PWM_AUX_RATE 50
+    ```