feat(navigator): Add infrastructure for smart mission route planning#27687
feat(navigator): Add infrastructure for smart mission route planning#27687JonasPerolini wants to merge 4 commits into
Conversation
|
@JonasPerolini This looks pretty cool. Still getting my head around it. YOu might want to (additionally) look at https://mavlink.io/en/messages/common.html#MAV_CMD_NAV_RETURN_PATH_START which I don't think PX4 supports. This is used on ArduPilot to provide what is effectively a rally point on the return path that is known safe to move towards if you're already on the outbound path of a mission. It might not be useful, but it strikes me that it might provide a useful hint for prioritising some kinds of returns. In particular this is intended for safer return when flying a corridor - where you can't just assume any path to the mission is viable. |
| The mission route is drawn in white and the rally-point (`R`) projections in green. | ||
| Every rally point has three projections because the margin is large. | ||
|
|
||
|  |
There was a problem hiding this comment.
Why is one of the R drawn differently?
It would be good to make one of these a vehicle.
The red R joins a waypoint, not a segment perpendicularly. That isn't mentioned.
There was a problem hiding this comment.
Added some details in a ::: details box
There was a problem hiding this comment.
updated the image to have a plane instead of the red "R" (it was red because selected). They probably need to be resized down once again, could you please do it @hamishwillee?
| The mission route is drawn in white and the rally-point (`R`) projections in green. | ||
| Every rally point has three projections because the margin is large. | ||
|
|
||
|  |
There was a problem hiding this comment.
Can/ should we draw the margins on all these images?
There was a problem hiding this comment.
I don't think there is much added value. We would need to also add all the xtrack distances as well
2780a3d to
709c610
Compare
🔎 FLASH Analysispx4_fmu-v5x [Total VM Diff: 4320 byte (0.21 %)]px4_fmu-v6x [Total VM Diff: 4320 byte (0.21 %)]Updated: 2026-07-10T06:39:42 |
|
No broken links found in changed files. |
318d38d to
a96006f
Compare
| /** | ||
| * TODO: FIX: for now this does not work because some variables are init to NAN. | ||
| * Therefore, the large struct lives in .data instead of .bss | ||
| * | ||
| * The ~24 KB ProjectionReferenceBatch is reused by collectVehicleProjection and | ||
| * selectSafePoint. There is no thread concerns, we just need to find a way to define it in the .bss | ||
| */ | ||
| static ProjectionReferenceBatch s_safe_point_batch; |
There was a problem hiding this comment.
To be fixed before merging
There was a problem hiding this comment.
The size of the ProjectionReferenceBatch buffer is now defined by CONFIG_RTL_SAFE_POINT_BATCH_SIZE. Since this struct is large, we can't have it in .data (FLASH), we need it in .bss (AXI_SRAM),
Because this struct uses non-zero default initializers (e.g., NAN, -1, NAV_CMD_INVALID), the compiler places the entire 24 KB initialized struct into the .data (FLASH) which has no room available for such struct.
Solution to move this to .bss without breaking standard initialization:
- Allocate uninitialized, correctly aligned raw byte storage in .bss.
- Construct the
ProjectionReferenceBatchinside this storage buffer during theMissionRoutePlannerconstruction.
Considered option: Change the default init to zero for all the fields. Rejected because it would require too many .reset()
Tests on fmu-v6c:
CONFIG_RTL_SAFE_POINT_BATCH_SIZE= 1: AXI_SRAM = 12.51%CONFIG_RTL_SAFE_POINT_BATCH_SIZE= 64: AXI_SRAM = 17.02%CONFIG_RTL_SAFE_POINT_BATCH_SIZE= 128: AXI_SRAM = 21.61%CONFIG_RTL_SAFE_POINT_BATCH_SIZE= 254: AXI_SRAM = 30.66%
|
Thank you for the review @hamishwillee, I've updated the docs. I prefer to tackle |
e673419 to
abf8fdd
Compare
mrpollo
left a comment
There was a problem hiding this comment.
Great feature, however this is adding a significanta mount of FLASH (0.2%) and it will touch all hardware targets, we need to wait on merging until v1.18 is branched out, we should be in better shape for this once the changes to PX4 for v2.0 hit main, then we can talk about adding this feature.
I'm marking this PR as needs changes, just so we can block merge for now.
… route-following RTL
d7dffbd to
f0e19ad
Compare
Infrastructure part of this PR: #26973 (FYI @mrpollo). No changes in behavior. The infrastructure provides the interface and logic needed by features that:
The overall goal is to minimize how far the vehicle deviates from the planned route during contingencies. For example:
The planner computes geometry and scoring only. It does not publish setpoints, change the mission index, or decide when a flight mode should use the result. This will be implemented in follow up PRs.
Motivation
With the GoTo feature, the vehicles' current position can be arbitrarily far from the last mission flown segment. When resuming a mission, flying to the last flown segment in a straight line can lead to large deviations from the mission path. In A to B missions e.g. for delivery, there is no need to fly back to the last flown segment, the goal is to get to B. Deviations can be caused for example by a detect and avoid maneouvre or can be requested by air traffic controllers when operating in shared airspaces.
RTL modes do not follow the mission path when navigating towards a safe point which can lead to dangerous deviations and constrains mission planning to ensure no geofence is breached during a return mode.
Architecture
Route cache:
Planner/provider reads use a zero wait timeout. A cache miss therefore returns failure instead of blocking Navigator while dataman or the SD card catches up.
The cache tracks mission identity, dataman storage id, mission count, and readiness. If the mission changes, the full-route cache is reloaded. If validation finds that an item is missing, the cache schedules a retry using bounded exponential backoff.
Safe points have their own asynchronous state machine because the safe-point set is tracked through
DM_KEY_SAFE_POINTS_STATE. The cache reloads safe points when the safe-point source identity changes and prevents stale safe-point data from being exposed while a reload is in progress.CONFIG_RTL_MISSION_CACHE_SIZEcontrols the maximum number of mission items reserved for full-route planning helpers.The default is:
Point Projection
This is the shared projection step used by both the Vehicle Projection and the Safe-Point Scoring below. The projected point is the vehicle in one case and a safe point (rally point) in the other.
The planner draws a perpendicular projection from the point onto every route segment and keeps up to three candidates.
A projection is a valid candidate only if its crosstrack distance is within a search margin of the closest candidate's crosstrack distance. The consuming feature supplies that margin.
The example below uses a large margin. The mission route is drawn in white and the rally-point (
R) projections in green. Every rally point has three projections because the margin is large.Here is the same route with a smaller margin. Some projections are dropped because their crosstrack distance is greater than the closest projection's crosstrack distance plus the margin.
With a margin of zero, each rally point keeps only its single closest projection.
Vehicle Projection
When a feature needs to rejoin the route, the first step is to project the current vehicle position onto the mission path and choose a "branch-in" point. The vehicle may have left the route (for example with a GoTo), so the planner picks the point that best preserves mission continuity.
The branch-in point is chosen in three phases:
Phase 1: Identifying valid candidates:
The vehicle is projected onto the route as described in the Point Projection paragraph above.
Phase 2: Selecting the best branch-in point:
The best candidate is chosen with a priority system:
DO_JUMPsegment if the caller supplied it).A + Band keeps the lowest:Example 1:
The vehicle is flying a mission, where the outbound and inbound legs are close to one another at the start.
While on the outbound leg, the vehicles deviates east to a GoTo location (e.g. due to incoming traffic).
That GoTo location is closer to the inbound leg, but both legs are close enough that the projection step returns two valid candidates: one on the outbound leg and one on the inbound leg.
The outbound segment is the one the vehicle is currently expected to fly, so it wins immediately on Priority 1.
Even without that rule it would still win on Priority 2, because its distance to the last-flown segment is much smaller.
The vehicle rejoins the mission and continues toward B.
Example 2:
The vehicle is flying north and deviates to a GoTo location that has two valid branch-in candidates.
Neither projection lies on the current segment, so each candidate is scored by
A + B: crosstrack distance plus the along-route distance to the last-flown segment. Take the candidate projected onto the east segment. Its score is the crosstrack distance (166.95 m) plus the distance along the route back to the last-flown segment (the red lines). The closer end of the last-flown segment is used, and the along-route distance is the sum of the straight lines between waypoints. The other candidate, projected onto the south segment, wins because its total distance is smaller.Phase 3: Determining the branch-in altitude:
Safe-Point Scoring
For a route-following return, the vehicle follows the mission route until it reaches a "branch-off" point and then flies straight to a safe point. The planner first finds the candidate branch-off points and then selects the safe point with the lowest total return cost.
This runs in two phases:
Phase 1: Identifying valid candidates:
The vehicle and all safe points are projected in a single scan of the route, using the same Point Projection described above
Phase 2: Selecting the best projection point:
Each candidate branch-off is scored by total path cost, and the lowest wins. The cost is built from:
Safe points are filtered while the planner builds its batch:
Route-Skip Shortcuts
After the best safe point has been chosen, a route-to-goal caller can skip the route join/follow entirely:
These shortcuts are applied only after selection, so they never change which safe point wins the cost comparison.
Example: In the image below the vehicle is already on the branch-off leg, after a GoTo or a canceled Return.
If a new Return is requested, the vehicle flies straight to the rally point (
R) instead of flying back to the branch-in point only to branch off again.PoC video, behaviors not yet available in this PR:
Note that the features from the PoC are not implemented in this PR but the infrastructure from this PR allows to enable them in a future PR.
Poc.mp4
Xbehavior