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.
This is a workaround to hotfix CI but the root cause is #22792
(MAVSDK test failing after EKF change, accelerometer simulation issues not learned anymore?)
wait_until_altitude() checks for absolute altitude being
close so checking for 1m below the setpoint can fail
if the speedup results in no sample inside the altitude
window being checked.
Ideally the test could check if the takeoff is done directly
instead of comparing altitudes in the first place.
- 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>
Current threshhold has no margins of errors with the set acceptance radius. Increase corridor radius by 5m.
Increase time to disarm for tailsitter test to pass.
Rverse mission needs check tracks test disabled since mavsdk does not really work with mission has reverse order.
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>
* MAVSDK_Test_Runner: Place PX4 instance runner after Gazebo server runner
- This was a nasty bug where starting PX4 instance first, then starting
Gazebo server was causing PX4 instance' EKF to freak out, probably
because it doesn't like getting data a while after it is started
- Detailed breakdown is given here: https://github.com/PX4/PX4-Autopilot/issues/21229#issuecomment-1450761542
- This now guarantees that such edge case won't occur and MAVSDK test
will run as it should
* MAVSDK Test Runner: Retain comment within 79 character limit
- To pass flake8 python style check
* Update test/mavsdk_tests/mavsdk_test_runner.py
Co-authored-by: Julian Oes <julian@oes.ch>
---------
Co-authored-by: Julian Oes <julian@oes.ch>
- use `gazebo-classic` everywhere consistently referring to the original Gazebo (eg version 9,10,11)
- additional `gazebo_*` helper targets added for compatibility, but warn about deprecation and tell you the new target naming
- use `gz` everywhere when referring to Gazebo (aka Ignition Gazebo or new Gazebo)
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
- update all msgs to be directly compatible with ROS2
- microdds_client improvements
- timesync
- reduced code size
- add to most default builds if we can afford it
- lots of other little changes
- purge fastrtps (I tried to save this multiple times, but kept hitting roadblocks)
- new modules/simulation directory to collect all simulators and related modules
- new Tools/simulation directory to collect and organize scattered simulation submodules, scripts, etc
- simulation module renamed to simulator_mavlink
- sih renamed to simulator_sih (not a great name, but I wanted to be clear it was a simulator)
- ignition_simulator renamed to simulator_ignition_bridge
- large sitl_target.cmake split by simulation option and in some cases pushed to appropriate modules
- sitl targets broken down to what's actually available (eg jmavsim only has 1 model and 1 world)
- new Gazebo consistently referred to as Ignition for now (probably the least confusing thing until we fully drop Gazebo classic support someday)
