mirror of
https://github.com/PX4/PX4-Autopilot.git
synced 2026-08-17 22:29:21 +08:00
docs(i18n): PX4 guide translations (Crowdin) - ko
This commit is contained in:
Crowdin Bot
@@ -898,6 +898,7 @@
|
||||
- [고급 주제](advanced/index.md)
|
||||
- [PX4 Metadata](advanced/px4_metadata.md)
|
||||
- [Detect and Avoid](advanced_features/detect_and_avoid.md)
|
||||
- [Mission Route Cache](advanced/mission_route_cache.md)
|
||||
- [Package Delivery Architecture](advanced/package_delivery.md)
|
||||
- [Camera Integration/Architecture](camera/camera_architecture.md)
|
||||
- [컴퓨터 비전](advanced/computer_vision.md)
|
||||
|
||||
@@ -0,0 +1,162 @@
|
||||
# Mission Route Cache
|
||||
|
||||
Normal mission execution keeps a small sliding window of mission items in RAM.
|
||||
Route-aware features may instead need random, non-blocking access to the complete route.
|
||||
|
||||
The mission route cache provides this data without reading Dataman or the SD card during planning:
|
||||
|
||||
```text
|
||||
MissionRouteCache
|
||||
|-- full mission route (optional) [0, ..., CONFIG_NAVIGATOR_FULL_MISSION_CACHE_SIZE - 1]
|
||||
|-- safe points [all uploaded safe points]
|
||||
`-- published mission-land item [one item]
|
||||
```
|
||||
|
||||
The cache is infrastructure for Navigator features.
|
||||
It does not change normal mission execution by itself.
|
||||
|
||||
## 구매처
|
||||
|
||||
The full route is loaded into RAM asynchronously.
|
||||
It becomes available only after every mission item has loaded successfully. A partial route is never exposed.
|
||||
|
||||
When the cached mission identity changes, the old route becomes unavailable immediately and the replacement is loaded as a new generation.
|
||||
Failed reads keep the successfully loaded prefix and retry with a capped backoff.
|
||||
|
||||
:::info
|
||||
If the full cache is disabled or the mission exceeds its capacity, a consuming feature must use its normal fallback behavior.
|
||||
The independent safe-point and mission-land caches remain available.
|
||||
:::
|
||||
|
||||
## 설정
|
||||
|
||||
`CONFIG_NAVIGATOR_FULL_MISSION_CACHE_SIZE` sets the maximum number of items in the full route cache.
|
||||
It defaults to `500` on POSIX platforms such as SITL, and `0` on embedded targets unless a board overrides it.
|
||||
|
||||
A value of `0` removes the full-mission buffer and its Dataman client from the build.
|
||||
Boards that enable full-route planning must choose a capacity that fits their RAM budget.
|
||||
|
||||
The buffer is allocated once when Navigator starts and uses one `mission_item_s` entry per configured item.
|
||||
An entry is currently 56 bytes, so 500 items use 28 kB.
|
||||
|
||||
:::details
|
||||
Developer details: Loading workflow
|
||||
|
||||
The full mission is exposed as one complete generation:
|
||||
|
||||
```text
|
||||
New mission accepted
|
||||
↓
|
||||
Read one item asynchronously
|
||||
↓
|
||||
Dataman response wakes Navigator
|
||||
↓
|
||||
Validate the response and queue the next item
|
||||
↓
|
||||
Repeat until every item is loaded
|
||||
↓
|
||||
Mark the complete generation ready
|
||||
```
|
||||
|
||||
Only one full-mission read is outstanding at a time.
|
||||
While it is pending, Navigator polls that client's response subscription, so each completion can queue the next read immediately.
|
||||
There is no separate cache thread.
|
||||
|
||||
The response topic is shared by all Dataman clients, so poll readiness alone does not mean this request completed.
|
||||
The response is still copied and matched to the request, and the subscription is polled only while this cache has a pending read.
|
||||
|
||||
Cache-only wakeups advance the load without running all Navigator state machines at the Dataman response rate.
|
||||
During a burst of Dataman-only wakeups, normal Navigator work stays on its existing cadence; a cache wake also runs it once the update period is due.
|
||||
|
||||
The cache identifies a mission source by its mission ID, item count, and Dataman bank.
|
||||
If the source changes while a read is in flight, that response is consumed but not accepted into the new generation.
|
||||
|
||||
:::
|
||||
|
||||
:::details
|
||||
Developer details: Borrowing a mission view
|
||||
|
||||
`getMissionView()` returns a zero-copy view of the cache-owned array.
|
||||
The view contains a pointer, item count, mission identity, and generation number; it does not own or copy the items.
|
||||
|
||||
A consumer should acquire a complete view, compute synchronously, and validate the same view before accepting the result:
|
||||
|
||||
```text
|
||||
Acquire view → compute route → generation still valid?
|
||||
|
|
||||
yes ─────────┴──────── no
|
||||
| |
|
||||
accept result discard result
|
||||
acquire new view
|
||||
recompute
|
||||
```
|
||||
|
||||
The caller does not update the pointer inside a stale view.
|
||||
It discards the view and anything derived from it, then calls `getMissionView()` again and recomputes.
|
||||
|
||||
After an item in a ready generation is patched, a fresh view is available immediately.
|
||||
While a replacement mission is loading, acquiring a new view fails until the complete generation is ready.
|
||||
|
||||
The refreshed view may contain the same pointer address because the backing allocation is reused.
|
||||
The generation, not pointer equality, determines whether its contents are current.
|
||||
|
||||
Use a borrowed view only during serialized Navigator work, and check it with `missionViewStillValid()` before accepting the result.
|
||||
The generation check is not a lock; another task would need explicit synchronization or its own snapshot.
|
||||
|
||||
:::
|
||||
|
||||
:::details
|
||||
Developer details: Keeping mission writes coherent
|
||||
|
||||
Already-loaded mission items are not automatically read from storage again.
|
||||
After a successful active-mission Dataman write, the writer must call `syncMissionItem()` from Navigator's task.
|
||||
This call synchronizes the caches; it does not perform the Dataman write.
|
||||
|
||||
For a ready full cache, synchronization patches that item in the array and advances the generation:
|
||||
|
||||
```text
|
||||
Successful Dataman write
|
||||
↓
|
||||
Patch the cached item
|
||||
↓
|
||||
Advance the generation
|
||||
↓
|
||||
Old views and route results are stale
|
||||
```
|
||||
|
||||
The complete route stays ready.
|
||||
Reloading the whole mission for a one-item change would make it unavailable and add one read per mission item without improving consistency.
|
||||
|
||||
Writes during loading depend on how far the load has progressed:
|
||||
|
||||
- An item in the loaded prefix is patched in place.
|
||||
- A response for the item already being read is ignored, and that item is then read again.
|
||||
- An unread item is picked up later by the normal load.
|
||||
|
||||
Mission execution follows this process after successful `DO_JUMP` counter increments and resets.
|
||||
The next route computation therefore sees the current number of remaining loops.
|
||||
|
||||
The mission-land cache is synchronized independently when the written index is the published land item.
|
||||
|
||||
A mission upload or replacement is different from an in-place runtime write.
|
||||
Its new mission identity causes a complete generation to load.
|
||||
|
||||
:::
|
||||
|
||||
:::details
|
||||
Developer details: Measuring load time
|
||||
|
||||
Successful, non-empty loads are reported by the `navigator: full mission cache load` performance counter.
|
||||
It measures wall time until the complete route is ready, including retry delays.
|
||||
|
||||
To measure it on hardware:
|
||||
|
||||
```sh
|
||||
perf reset
|
||||
# Upload or change the mission.
|
||||
perf
|
||||
```
|
||||
|
||||
Replaced, invalidated, empty, or incomplete loads do not add a sample.
|
||||
|
||||
:::
|
||||
@@ -5,7 +5,7 @@ This enables easier testing of [safety failsafe](../config/safety.md) behaviour,
|
||||
|
||||
Failure injection is disabled by default, and can be enabled using the [SYS_FAILURE_EN](../advanced_config/parameter_reference.md#SYS_FAILURE_EN) parameter.
|
||||
|
||||
Failures can be injected both in simulation and on real hardware. In simulation the available failures depend on the simulator. On hardware the `off` (stop publishing) and `stuck` (freeze the last value) types are supported for the `gyro`, `accel`, `mag`, `baro`, `distance_sensor` and `gps` components; this requires firmware built with the failure-injection module. In addition, the `battery` component supports `off` (report a depleted pack, triggering the battery failsafe).
|
||||
Failures can be injected both in simulation and on real hardware. In simulation the available failures depend on the simulator. On hardware the `off` (stop publishing) and `stuck` (freeze the last value) types are supported for the `gyro`, `accel`, `mag`, `baro`, `distance_sensor` and `gps` components; this requires firmware built with the failure-injection module. In addition, the `battery` component supports `off` (report a depleted pack, triggering the battery failsafe), and the `gps` component supports `wrong` (report the fix type selected by [SYS_FAIL_GPS_WRG](../advanced_config/parameter_reference.md#SYS_FAIL_GPS_WRG), leaving the reported position untouched).
|
||||
|
||||
:::info
|
||||
PX4 may accept a command to set a particular failure mode even it that mode is not supported by your simulator.
|
||||
@@ -61,7 +61,8 @@ failure <component> <failure_type> [-i <instance_number>] [-m <instance_bitmask>
|
||||
- _instance bitmask_ (optional): address several instances at once (bit 0 = first instance, bit 1 = second, …; decimal or `0x` hex). Used only when `-i` is omitted. Example: `-m 0x5` targets instances 1 and 3.
|
||||
|
||||
:::info
|
||||
The simulated GPS (SITL) implements only the `off`, `stuck`, and `wrong` failure modes; the other failure types have no effect on it.
|
||||
GPS implements only the `off`, `stuck`, and `wrong` failure modes; the other failure types have no effect on it.
|
||||
`gps wrong` makes the addressed receiver report the fix type selected by [SYS_FAIL_GPS_WRG](../advanced_config/parameter_reference.md#SYS_FAIL_GPS_WRG) and leaves the reported position untouched.
|
||||
:::
|
||||
|
||||
## RC Switch Trigger
|
||||
|
||||
File diff suppressed because one or more lines are too long
@@ -287,6 +287,7 @@ See messages
|
||||
- [TiltrotorExtraControls](../msg_docs/TiltrotorExtraControls.md)
|
||||
- [TrajectorySetpoint6dof](../msg_docs/TrajectorySetpoint6dof.md)
|
||||
- [TuneControl](../msg_docs/TuneControl.md)
|
||||
- [UavcanFirmwareUpdate](../msg_docs/UavcanFirmwareUpdate.md)
|
||||
- [UavcanParameterRequest](../msg_docs/UavcanParameterRequest.md)
|
||||
- [UavcanParameterValue](../msg_docs/UavcanParameterValue.md)
|
||||
- [UlogStream](../msg_docs/UlogStream.md)
|
||||
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
pageClass: is-wide-page
|
||||
---
|
||||
|
||||
# UavcanFirmwareUpdate (UORB message)
|
||||
|
||||
**TOPICS:** uavcan_firmware_update
|
||||
|
||||
## Fields
|
||||
|
||||
| 명칭 | 형식 | Unit [Frame] | Range/Enum | 설명 |
|
||||
| -------------------------------------------------------------------- | -------- | ---------------------------------------------------------------- | ---------- | ------------------------------------------------------------------------------------------------------------- |
|
||||
| <a id="fld_timestamp"></a>timestamp | `uint64` | | | time since system start (microseconds) |
|
||||
| <a id="fld_pending_updates"></a>pending_updates | `bool` | | | true when one or more nodes requiring a firmware update have been detected and the update is not yet complete |
|
||||
|
||||
## Source Message
|
||||
|
||||
[Source file (GitHub)](https://github.com/PX4/PX4-Autopilot/blob/main/msg/UavcanFirmwareUpdate.msg)
|
||||
|
||||
:::details
|
||||
Click here to see original file
|
||||
|
||||
```c
|
||||
uint64 timestamp # time since system start (microseconds)
|
||||
bool pending_updates # true when one or more nodes requiring a firmware update have been detected and the update is not yet complete
|
||||
```
|
||||
|
||||
:::
|
||||
@@ -276,6 +276,7 @@ Graphs showing how these are used [can be found here](../middleware/uorb_graph.m
|
||||
- [TrajectorySetpoint6dof](TrajectorySetpoint6dof.md) — Trajectory setpoint in NED frame. Input to position controller.
|
||||
- [TransponderReport](TransponderReport.md) — Transponder report.
|
||||
- [TuneControl](TuneControl.md) — This message is used to control the tunes, when the tune_id is set to CUSTOM. then the frequency, duration are used otherwise those values are ignored.
|
||||
- [UavcanFirmwareUpdate](UavcanFirmwareUpdate.md)
|
||||
- [UavcanParameterRequest](UavcanParameterRequest.md) — UAVCAN-MAVLink parameter bridge request type.
|
||||
- [UavcanParameterValue](UavcanParameterValue.md) — UAVCAN-MAVLink parameter bridge response type.
|
||||
- [UlogStream](UlogStream.md) — Message to stream ULog data from the logger. Corresponds to the LOGGING_DATA. mavlink message.
|
||||
|
||||
@@ -55,6 +55,9 @@ Please continue reading for [upgrade instructions](#upgrade-guide).
|
||||
- [Flight termination](../advanced_config/flight_termination.md) can now be used instead of a Descent mode as a fallback failsafe mode, allowing safer landing for unpiloted vehicles that carry a parachute.
|
||||
See [Battery level failsafe](../config/safety.md#battery-level-failsafe) ([COM_LOW_BAT_ACT](../advanced_config/parameter_reference.md#COM_LOW_BAT_ACT)) and [Position Loss Failsafe Action](../config/safety.md#position-loss-failsafe-action) (new [COM_POS_FS_ACT](../advanced_config/parameter_reference.md#COM_POS_FS_ACT)). ([PX4-Autopilot#28064: feat(commander): add terminate options for critical battery and lost position failsafes](https://github.com/PX4/PX4-Autopilot/pull/28064)).
|
||||
- [Motor failure recovery](../config/motor_failure_recovery.md) for hexarotors: on a single motor failure the control allocator removes the failed motor and additionally stops ([CA_FAILURE_MODE](../advanced_config/parameter_reference.md#CA_FAILURE_MODE) = `1`) or reverses (`2`) the motor opposite it to recover the lost yaw authority. Mode `2` requires a reverse-capable ESC and models the reverse thrust of a forward propeller with the new [CA_REV_THR_FRAC](../advanced_config/parameter_reference.md#CA_REV_THR_FRAC) (default `0.4`). Reversible motor outputs on DroneCAN are now sent as signed `RawCommand` values (negative is reverse). ([PX4-Autopilot#28078](https://github.com/PX4/PX4-Autopilot/pull/28078))
|
||||
- Added `RTL_TYPE=6` for battery-aware home priority return ([PX4-Autopilot#26968](https://github.com/PX4/PX4-Autopilot/pull/26968)).
|
||||
Returns to home if the estimated flight time to home is within the remaining battery time; otherwise returns to the closest rally point.
|
||||
Falls back to the closest safe point (home or rally) if battery time remaining is unavailable.
|
||||
|
||||
### Estimation
|
||||
|
||||
|
||||
Reference in New Issue
Block a user