UAV-develop/PX4-Autopilot
1
0
Fork 0
mirror of https://github.com/PX4/PX4-Autopilot.git synced 2026-07-26 16:28:06 +08:00
Code Issues Packages Projects Releases Wiki Activity

Link fixes galore (#25151)

Browse Source
This commit is contained in:
Hamish Willee
2025-07-03 14:53:12 +10:00
committed by GitHub
parent dd0d00aedc
commit 375f421c61
107 changed files with 836 additions and 972 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
docs/en/concept/architecture.md
View File

@@ -3,7 +3,7 @@
PX4 consists of two main layers: the [flight stack](#flight-stack) is an estimation and flight control system,
and the [middleware](#middleware) is a general robotics layer that can support any type of autonomous robot, providing internal/external communications and hardware integration.
All PX4 [airframes](../airframes/index.md) share a single codebase (this includes other robotic systems like boats, rovers, submarines etc.). The complete system design is [reactive](http://www.reactivemanifesto.org), which means that:
All PX4 [airframes](../airframes/index.md) share a single codebase (this includes other robotic systems like boats, rovers, submarines etc.). The complete system design is [reactive](https://www.reactivemanifesto.org), which means that:
- All functionality is divided into exchangeable and reusable components
- Communication is done by asynchronous message passing
@@ -112,7 +112,6 @@ There are 2 different ways that a module can be executed:
- **Tasks**: The module runs in its own task with its own stack and process priority.
- **Work queue tasks**: The module runs on a shared work queue, sharing the same stack and work queue thread priority as other modules on the queue.
- All the tasks must behave co-operatively as they cannot interrupt each other.
- Multiple _work queue tasks_ can run on a queue, and there can be multiple queues.
- A _work queue task_ is scheduled by specifying a fixed time in the future, or via uORB topic update callback.

10
docs/en/concept/events_interface.md
View File

@@ -76,7 +76,6 @@ Explanations and requirements:
- from that name, a 24 bit event ID is derived using a hash function.
This means as long as the event name stays the same, so will the ID.
- **Log Level**:
- valid log levels are the same as used in the MAVLink [MAV_SEVERITY](https://mavlink.io/en/messages/common.html#MAV_SEVERITY) enum.
In order of descending importance these are:
@@ -94,8 +93,8 @@ Explanations and requirements:
- Above we specify a separate external and internal log level, which are the levels displayed to GCS users and in the log file, respectively: `{events::Log::Error, events::LogInternal::Info}`.
For the majority of cases you can pass a single log level, and this will be used for both exernal and internal cases.
There are cases it makes sense to have two different log levels.
For example an RTL failsafe action: the user should see it as Warning/Error, whereas in the log, it is an expected system response, so it can be set to `Info`.
There are cases it makes sense to have two different log levels.
For example an RTL failsafe action: the user should see it as Warning/Error, whereas in the log, it is an expected system response, so it can be set to `Info`.
- **Event Message**:
- Single-line, short message of the event.
@@ -114,7 +113,7 @@ Valid types: `uint8_t`, `int8_t`, `uint16_t`, `int16_t`, `uint32_t`, `int32_t`,
You can also use enumerations as arguments:
- PX4-specific/custom enumerations for events should be defined in [src/lib/events/enums.json](https://github.com/PX4/PX4-Autopilot/blob/main/src/lib/events/enums.json), and can then be used as event argument in the form of `events::send<events::px4::enums::my_enum_t>(...)`.
- MAVLink "common" events are defined in [mavlink/libevents/events/common.json](https://github.com/mavlink/libevents/blob/master/events/common.json) and can be used as event argument in the form of `events::send<events::common::enums::my_enum_t>(...)`.
- MAVLink "common" events are defined in [mavlink/libevents/events/common.json](https://github.com/mavlink/libevents/blob/main/events/common.json) and can be used as event argument in the form of `events::send<events::common::enums::my_enum_t>(...)`.
#### Text format
@@ -125,7 +124,6 @@ Text format for event message description:
These have to be escaped: '\\\\', '\\<', '\\{'.
- supported tags:
- Profiles: `<profile name="[!]NAME">CONTENT</profile>`
`CONTENT` will only be shown if the name matches the configured profile.
@@ -137,11 +135,9 @@ Text format for event message description:
- no nested tags of the same type are allowed
- arguments: template placeholders that follow python syntax, with 1-based indexing (instead of 0)
- general form: `{ARG_IDX[:.NUM_DECIMAL_DIGITS][UNIT]}`
UNIT:
- m: horizontal distance in meters
- m_v: vertical distance in meters
- m^2: area in m^2

2
docs/en/concept/system_startup.md
View File

@@ -5,7 +5,7 @@ On NuttX they reside in the [ROMFS/px4fmu_common/init.d](https://github.com/PX4/
The scripts that are only used on Posix are located in [ROMFS/px4fmu_common/init.d-posix](https://github.com/PX4/PX4-Autopilot/tree/main/ROMFS/px4fmu_common/init.d-posix).
All files starting with a number and underscore (e.g. `10000_airplane`) are predefined 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.
They are exported at build-time into an `airframes.xml` file which is parsed by [QGroundControl](https://qgroundcontrol.com) for the airframe selection UI.
Adding a new configuration is covered [here](../dev_airframes/adding_a_new_frame.md).
The remaining files are part of the general startup logic.