- higher airspeed targets
- higher pusher thrust
- higher takeoff attitude (arsp failure test)
in the airspeed failure case, the lowered airspeed reading causes the
controller to want to speed up until the (wrong) airspeed is at the
setpoint, i.e. the real airspeed quite a bit faster. without these
fixes, tecs does a nosedive to regain airspeed, but never becomes fast
enough (with already maxed out pusher thrust). we pervent this with
the first two adaptations, while the last one gives space for the
remaining nosedive.
fix this permanently by:
- ensuring the model makes sense definitely (pusher thrust, mass, aero
properties)
- noticing the failure faster
- adapting tecs so it doesn't nosedive?
- stop sending airspeed in sih
src/modules/simulation/sensor_airspeed_sim/SensorAirspeedSim.cpp
is already doing that. in the sensor failure case (wrong), that implements
the failure, but the SIH one not, giving conflicting data. so switch
it off
- larger acceptance radius
quadx position mode is just not that accurate. is it a control/model
mismatch problem, or a simulation problem?
- wait longer for disarm in test_vtol_rtl
this would fail at large speed factors previously. timing bug or
acceptable small variation?
maybe this is a band-aid fix, and we actually should make sure the
transition can be achieved in the given 5 seconds, as it is very
reliably in the corresponding gazebo test case. check:
- does SIH_T_MAX make sense?
- does SIH_MASS make sense?
- and any other model parameters which are suspicious
the original std::this_thread::sleep_for is with respect to host system
time which is different from autopilot time if speed factor != 1, if
some component runs slower than real time, or if debugging.
tester.sleep_for (which already existed) correctly sleeps w.r.t.
px4/simulation time.
Previously, DataValidator would automatically reject sensor data as
stale if (almost) constant.
But if setting SIH_NOISE_SCALE = 0 for deterministic sim, constant
sensor data are to be expected.
This adds logic to not flag sensor values as stale if noise scale is
very small. If the sensor has *actually* gone stale with very low noise
scale, this means we cannot detect it anymore.
* 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>
From https://github.com/google/fuzztest.
This will now also add gtest (via cmake FetchContent)
And requires newer cmake (container updates):
CMake 3.19 or higher is required. You are running version 3.16.3
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.
Balduin