wait_until_altitude() returns on the first touch of the target band while
the vehicle is still climbing, so start_checking_altitude() latched the hold
reference mid-climb. The normal takeoff overshoot (~0.24 m) and slow VTOL
settle then exceeded the 0.15 m tolerance and the standard_vtol job failed
intermittently.
Wait for the overshoot to damp before capturing the reference, and restore
the 0.2 m tolerance established in #26106 (a later SIH rewrite had tightened
it back to 0.15 m). Steady-state hover holds to ~0.05 m, so the check stays
sensitive to real altitude-hold failures.
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
Since #27918 a blind descend reports the distinct Descend flight mode
instead of masquerading as Land. MAVSDK v3.17.1 has no Descend mode, so
wait_for_flight_mode(Land) timed out and SITL failed on main.
Losing GPS in SIH removes all horizontal position aiding, so the vehicle
always blind-descends after the mission GPS loss; a controlled Land is
never entered. The test already waits for the automatic disarm after
landing, which is the meaningful check.
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
wait_until_ready() polls MAVSDK's is_armable, but a known hysteresis gap
(and estimator heading-reference flicker at startup) means the flag can
read armable while PX4 then denies the arm command with 'no heading
reference'. This made arm() fail intermittently. Retry the arm command
until the autopilot accepts it, so the transient is absorbed while real
failures still time out.
Signed-off-by: Julian Oes <julian@oes.ch>
The four older VTOL RTL tests waited only 120s for disarm while running
the same climb-to-550m-and-land missions as the other RTL tests, which
already use 150s. 'RTL direct Mission Land' occasionally tipped just
over 120s of sim time (observed 123.76s), failing wait_until_disarmed.
Align all of them to 150s for margin.
Signed-off-by: Julian Oes <julian@oes.ch>
The 0.01m (1cm) tolerance was not reachable within the 15s sim-time
window for the standard_vtol, causing the takeoff-and-hold test to time
out. Use 0.1m, which still verifies altitude hold but is physically
achievable, and stays below the 0.15m hold-monitoring tolerance.
Signed-off-by: Julian Oes <julian@oes.ch>
MAVSDK's OffboardImpl::process_heartbeat() resets the setpoint state to
NotActive when a heartbeat without offboard mode arrives more than 3 s
after _last_started. _last_started is only ever written by start(), so
before the first start() it is epoch zero and the guard is always true:
any heartbeat that slips in between set_*() and start() makes start()
fail with NoSetpointSet.
At speed factor 30 PX4's 1 Hz (sim time) heartbeat arrives every ~33 ms
of wall time, which made 'Offboard attitude control' fail roughly one
run in three. Re-send the setpoint and retry start() in a small loop at
both offboard start sites. Failed 1/3 before, 16/16 after.
This is arguably a MAVSDK bug (_last_started should be initialized when
setpoint streaming begins); a retry keeps the tests robust either way.
Signed-off-by: Julian Oes <julian@oes.ch>
poll_condition_with_timeout polls the autopilot's monotonic time, which is
already simulation time. The previous code divided a sim-time budget by the
speed factor to compute a wall-clock timeout, but this is unnecessary and
adds a dependency on the speed-factor query.
Replace 5 functions that used std::future::wait_for() (wall-clock time)
with poll_condition_with_timeout() (simulation time). This prevents
timeouts from expiring prematurely when running at high speed factors
under lockstep.
Affected functions:
- wait_until_altitude()
- wait_for_landed_state()
- wait_for_flight_mode()
- start_and_wait_for_mission_sequence()
- wait_until_speed_lower_than()
Also remove debug printf statements from start_checking_altitude().
The DO_LAND_START item carried loiter params (heading required, radius,
and a stray 1 in param3) hand-copied from the adjacent LOITER_TO_ALT
item, and LOITER_TO_ALT itself had param3 set, which the spec defines
as empty. PX4's mission item param validation now rejects such items.
Signed-off-by: Julian Oes <julian@oes.ch>
* fix(navigator): remove generic reset of navigator triplets on mode change
- make each navigation mode decide if it needs the reset and what data it
wants to capture before the reset
- fix RTL climbing so that it remains on an established loiter when RTL
is being activated -> avoids weird trajectories and potential geofence breaches
Signed-off-by: RomanBapst <bapstroman@gmail.com>
* feat(mavsdk_tests): added various integration tests for loitering behavior:
- make sure RTL climb remains on established loiter
- make sure new loiter at current location is set when HOLD is engaged while
vehicle is transiting to another loiter
- make sure altitude is locked to current altitude when vehicle is currently
flying an established loiter but is transiting to a higher altitude
- make sure vehicle resets from figure of 8 to a loiter when HOLD is engaged
while vehicle is established on a figure of 8
Signed-off-by: RomanBapst <bapstroman@gmail.com>
* navigator: improve wording
Signed-off-by: RomanBapst <bapstroman@gmail.com>
* rtl_mission_direct_land: avoid loitering on a previously set figure of 8
Signed-off-by: RomanBapst <bapstroman@gmail.com>
* fix(navigator): harden geofence position checks and preserve loiter on breach
The GF_SOURCE_GPS path previously gated the breach check on the global
position timestamp even though it evaluated the fence against raw GPS
coordinates. Validate each source against the data it actually uses:
the fused global position on freshness (<1s), and raw GPS on freshness
(<2s) plus a valid fix.
For the LOITER breach action, only issue the reposition when the fused
global position is valid, since the setpoint is flown on that estimate,
and source all reposition coordinates from it. When the vehicle is
already established on a circular (orbit) loiter, keep that loiter's
center instead of re-centering on the current position to avoid a jump.
Signed-off-by: RomanBapst <bapstroman@gmail.com>
* fixup
Signed-off-by: RomanBapst <bapstroman@gmail.com>
* make methods const
Signed-off-by: RomanBapst <bapstroman@gmail.com>
---------
Signed-off-by: RomanBapst <bapstroman@gmail.com>
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>
Restart the Micro-XRCE-DDS Agent before each integration test so DDS
graph state from a previous PX4 instance does not leak into the next
test.
The MicroXRCEAgent is started once per session, but PX4 reboots between
tests. The Agent retains writer entries from the previous PX4, so when
the new PX4 reconnects, count_publishers() in px4-ros2-interface-lib's
waitForFMU returns >0 immediately against a stale entry. Phase 1
(discovery) returns instantly, then Phase 2 (heartbeat) times out
waiting for a message on a subscription matched to a dead writer.
This is why ModesTest.denyArming (first test) passes while every later
ModesTest fails with "timeout while waiting for FMU heartbeat".
Adds an optional pre_test_hook on test_runner.Tester so ROS-specific
lifecycle stays out of the shared test_runner. The workflow stops
starting the Agent externally; ros_test_runner.py owns the lifecycle.
Refs #27328
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
* test: increase altitude tolerance to fix flaky test
Altitude tolerance increased from 0.1f to 0.15f to handle simulation
timing variations. Test was failing at 0.201m with 0.2m tolerance.
* test: increase altitude tolerance further to 0.3m
* ci: re-add branch trigger for SITL tests
* Revert "ci: re-add branch trigger for SITL tests"
This reverts commit e5e4c9637b.
* Update to latest mavlink that includes support for WIP warnings
* mavsdk_tests: pass build for now
We need this until the figure eight stuff has moved to common.
---------
Co-authored-by: Julian Oes <julian@oes.ch>
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
the previously used std::this_thread::sleep_for is with respect to host
system time which is different from autopilot time if:
- speed factor != 1
- something runs slower than realtime regardless of speed factor
- debugging or otherwise interrupting PX4 control code
tester.sleep_for (which already existed) correctly sleeps w.r.t.
px4/simulation time.
