This reverts the addition of a check against mission items that have the
same position. This breaks existing MAVSDK implementations where a
LOITER_TIME item is set right after a WAYPOINT with the same
coordinates. It is an interim hack to allow the vehicle to hold still
during a photo is captured.
This leaves the check in place for gates where we need to be able to
calculate the direction between gate and waypoint.
Because of warnings on every flight on setups without
any need for concern. Some even high quality supply voltage regulators
that are rated for 5V can with tolerances and load get lower than 4.9V.
The timestamp actually used by ekf2 is the sensor_combined timestamp, so we should be setting it with the actual data sample timestamp, rather than the aggregated sensors topic publication metadata.
Later the sensor_combined message will be replaced with vehicle_imu that carries a separate publication timestamp and raw sample timestamp.
The EAS is the calibrated airspeed corrected with a scaling factor to account for sensor error/placement of pitot.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
- skip avionics rail voltage check when USB connected
- skip forced reboot on USB disconnect if circuit breaker set
- avionics voltage preflight check don't silently fail if system_power unavailble
- explicitly set supply check circuit breaker (CBRK_SUPPLY_CHK)
- always check with state machine before reboot/shutdown
- respect BOARD_HAS_POWER_CONTROL (shutdown from command, low battery, power button)
- px4_shutdown_request add optional delay and always execute from HPWORK
- px4_shutdown_request split out px4_reboot_request
This is to prevent a wrong (false positive) failure detection of the airspeed
shortly after system boot due to delays in driver and/or estimator startup (seen in SITL).
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
- Avoid constantly adjusting the velocity gains with the HTE
- Make sure the hover thrust integral update doesn't break
even though its unit is acceleration and not unit thrust anymore
We need to convert the velocity gains to not contain/depend on the
hover thrust. In horizontal direction it doesn't make sense to scale
them with the hover thrust and in vertical direction the adjustments are
already done in the acceleration to collective thrust conversion.
- create common uORB::PublicationBase
- uORB::PublicationQueued types are now type aliases
- ORB_PRIO use enum type everywhere to avoid accidental misuse
- PX4Accelerometer/PX4Gyroscope/etc driver libs explicitly advertise on construction, unadvertise on destruction. This is a workaround for any potential issues that might appear when accel/gyro cdev and uORB indexing doesn't align.
Because the takeoff ramp is a vertical velocity limit ramp for the
nice user experience but the acceleration feed-forward can
add on top of the output and depending on trajectory generation
result in unwanted thrust changes during the ramp.
* Land Enabled
* Declared Subscriptor in header as originally intended.
In the header it caused SIGSEGV in my machine so that's why it was moved
to .cpp
* Code Style fixed
* Removed confusing comments
* Comment update
Co-authored-by: Julian Oes <julian@oes.ch>
* VTOL type: add new parameter VT_FWD_TRHUST_EN for customizing pusher/tilt assist
Depending on the setting of this param, the pusher assist is:
-completely disabled (default)
-enabled in pos, alt and auto mode (except LAND)
-enabled in pos, alt and auto mode if above MPC_LAND_ALT1
-enabled in pos, alt and auto mode if above MPC_LAND_ALT2
-enabled in pos, alt and auto mode
(before it was always disabled in LAND mode)
-change default of VT_FWD_THRUST_SC from 0 to 0.7
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Instead of blocking the receiver thread while playing a tune we now copy
the tune to a buffer and check if we can play the next note on each
iteration of the receiver thread.
The buffer and tune object is only created on the heap if we receive a
tune to play once and doesn't use resources otherwise.
The old tune device interface is not working anymore and we need to
publish to uORB tune_control.
This solution is not optimal though because blocks the receiving thread.
- this fixes the case where the navigator publishes a loiter waypoint or any
waypoint which is too close to the vehicle.
Signed-off-by: RomanBapst <bapstroman@gmail.com>
Michal Stasiak