Plan RTL paths that route around geofence boundaries — both inclusion
and exclusion zones — instead of flying straight through them and
breaching. The planner builds a visibility graph over the margin-inflated
geofence polygons and circles and runs Dijkstra to find the shortest
legal return path, falling back to a straight line to the destination
when no valid path exists.
Highlights:
- New reusable libraries: src/lib/dijkstra (generic shortest path) and
src/lib/geofence (fixed-point geometry, polygon inflation, bitangent
visibility); the RTL planner lives in navigator/RTLPlanner.
- Visibility graph keeps only bitangent edges and skips edges that poke
into a forbidden region, greatly reducing edge-cost computation.
- Corner splitting is limited to sharp convex corners.
- Geometry validation: reject self-intersecting polygons and vertices
outside the fixed-point range; centimeter fixed-point scaling keeps
orientation tests exact and avoids drift at large distances.
- Failure handling: a Status enum replaces silent bool returns, and
failures (unbuildable fence, planner capacity overflow, dataman load
errors, NaN waypoints, destinations that breach the fence) are
surfaced to the operator via MAVLink warnings/criticals; the planner
falls back to a straight-line RTL.
- Destination updates are centralized in RTL::setRtlTypeAndDestination;
the path is replanned only when the destination or geometry changes.
- VTOLs always use the fixed-wing margin (FW loiter radius).
- kMaxNodes is exposed as a Kconfig option (default 100); the feature is
disabled on flash-constrained boards (FMUv4 and older, various F4/F7).
- Tests: unit tests for the Dijkstra lib, geofence geometry utils, and
the avoidance planner, plus a MAVSDK SITL test flying an RTL through a
geofence.
- Documentation: new "Geofence Awareness" section in the RTL docs.
Co-authored-by: Balduin <balduin@auterion.com>
PX4 needs a bit of time to process an uploaded mission before it is
ready to accept the mission mode.
Therefore, we need to wait a bit.
Alternatively, we could wait on the mission progress arriving properly,
but this sleep is simple enough for now.
* mavsdk_tests: add multicopter alt hold test
* fix test filter
* increase altitude tolerance to 10m as a test
* reduce to 1m tolerance
* increase to 5m tolerance
* increase to 2m tolerance
* reduce back to 1m
* delay 60 seconds
* fix log upload
* fix ulog upload path
* make altitude tolerance in tester.wait_until_altitude configurable
* fix lambda
* default arg in declaration
* tighten up tolerance
- add functionality to specify world name for simulation in case name
- add test for triggering an airspeed invalidation in case of pitot blockage
- add test for high wind (ramped up wind over short period) to NOT invalidate airspeed in this case
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
mavsdk-test: added a vtol mission without a landing at the end (used for reversed RTL)
math_helpers: added function to compute local position from a raw mission item
Signed-off-by: RomanBapst <bapstroman@gmail.com>
arm
- Previously, due to the way MAVSDK's `health_all_ok` was implemented,
vehicle often didn't have a valid global position estimate (although
function returned true), and it wouldn't arm, and the SITL would fail
- Also sometimes as vehicle didn't have manual control, it entered weird
states where it wasn't able to arm as well
- This adds a check to make sure vehicle is able to arm, directly from
the Health struct
rename follow_me_status to follow_target_status
enable follow_target_estimator on skynode
implement the responsiveness parameter:
The responsiveness parameter should behave similarly to the previous
follow-me implementation in navigator. The difference here is that
there are now two separate gains for position and velocity fusion.
The previous implemenation in navigator had no velocity fusion.
Allow follow-me to be flown without RC
SITL tests for follow-me flight task
This includes:
- Testing the setting for the follow-me angle
- Testing that streaming position only or position
and velocity measurements both work
- Testing that RC override works
Most of these tests are done with a simulated model
of a point object that moves on a straight line. So
nothing too spectacular. But it makes the test checks
much easier.
Since the estimator for the target actually checks new
measurements and compares them to old ones, I also added
random gausian noise to the measurements with a fixed seed
for deterministic randomness. So repeated runs produce
exactly the same results over and over.
Half of the angles are still missing in MAVSDK. Need to create
an upstream PR to add center left/right and rear left/right options.
These and the corresponding SITL tests need to be implemented
later.
sitl: Increase position tolerance during follow-me
Astro seems to barely exceed the current tolerance (4.3 !< 4.0)
causing CI to fail. The point of the CI test is not to check
the accuracy of the flight behaviour, but only the fact that the
drone is doing the expected thing. So the exact value of this
tolerance is not really important.
follow-me: gimbal control in follow-me
follow-me: create sub-routines in flight task class
follow-me: use ground-dist for emergency ascent
dist_bottom is only defined when a ground facing distance sensor exist.
It's therefore better to use dist_ground instead, which has the distance
to the home altitude if no distance sensor is available.
As a consequence it will only be possible to use follow-me in a valley
when the drone has a distance sensor.
follow-me: point gimbal to the ground in 2D mode
follow-me: another fuzzy msg handling for the estimator
follow-me: bugfix in acceleration saturation limit
follow-me: parameter for filter delay compensation
mantis: dont use flow for terrain estimation
follow-me: default responsiveness 0.5 -> 0.1
0.5 is way too jerky in real and simulated tests.
flight_task: clarify comments for bottom distance
follow-me: minor comment improvement
follow-me: [debug] log emergency_ascent
follow-me: [debug] log gimbal pitch
follow-me: [debug] status values for follow-me estimator
follow-me: setting for gimbal tracking mode
follow-me: release gimbal control at destruction
mavsdk: cosmetics 💄
It seems like we are often missing updates from topics like flight mode
or in air state, both topics that are sent out infrequenctly e.g. at 1
Hz. Therefore, instead of polling for that data we should probably
subscribe to the updates and that way get notified of each an every
update.
For instance this should prevent the case where we miss the mode change
from mission to descend and back to mission once landed and disarmed.
