Consoles/Shells
PX4 enables terminal access to the system through the MAVLink Shell and the System Console.
This page explains the main differences and how the console/shell are used.
System Console vs. Shells
The PX4 System Console provides low-level access to the system, debug output and analysis of the system boot process.
There is just one System Console, which runs on one specific UART (the debug port, as configured in NuttX), and is commonly attached to a computer via an FTDI cable (or some other debug adapter like a Dronecode probe).
Used for low-level debugging/development: bootup, NuttX, startup scripts, board bringup, development on central parts of PX4 (e.g. uORB).
In particular, is the only place where all boot output (including information about applications auto-started on boot) is printed.
Shells provide higher-level access to the system:
Used for basic module testing/running commands.
Only directly display the output of modules you start.
Cannot directly display the output of tasks running on the work queue.
Can't debug problems when the system doesn't start (as it isn't running yet).
:::note The dmesg command is now available through the shell on some boards, enabling much lower level debugging than previously possible. For example, with dmesg -f & you also see the output of background tasks. :::
There can be several shells, either running on a dedicated UART, or via MAVLink. Since MAVLink provides more flexibility, currently only the MAVLink Shell is used.
The System Console is essential when the system does not boot (it displays the system boot log when power-cycling the board). The MAVLink Shell is much easier to setup, and so is more generally recommended for most debugging.
Using Consoles/Shells
The MAVLink shell/console and the System Console are used in much the same way.
For example, type ls to view the local file system, free to see the remaining free RAM, dmesg to look at boot output.
Below are a couple of commands which can be used in the NuttShell to get insights of the system.
This NSH command provides the remaining free memory:
The top command shows the stack usage per application:
Note that stack usage is calculated with stack coloring and is the maximum since the start of the task (not the current usage).
To see what is running in the work queues and at what rate, use:
To debug uORB topics:
To inspect a specific uORB topic:
Many other system commands and modules are listed in the Modules and Command Reference (e.g. top, listener, etc.).
:::tip Some commands may be disabled on some boards (i.e. the some modules are not included in firmware for boards with RAM or FLASH constraints). In this case you will see the response: command not found :::
Last updated