Fixes the compile error on llvm:
mixture of designated and non-designated initializers in the same initializer list is a C99 extension [-Wc99-designator]
- a growing number of samples come into the backend with the time
already delayed (sensor's interrupt setting timestamp sample)
- if the incoming timestamp is already delayed then the new data checks
(relative to latest IMU) can be slightly wrong
- handle almost all timestamps and checks on delayed time horizon,
except for explicit checks of new samples
- isRecent() and isTimedOut() helpers use delayed time
- add new isNewestSampleRecent() used for checking the incoming
timestamp of the incoming (adjusted) data
- print list of events whenever they change if
CONSOLE_PRINT_ARMING_CHECK_EVENT is set, instead of on each update call
- reduce flash usage by moving out templated code into non-template method
For SITL it's important that the GCS receives the first events messages
that reset the sequence number, in case the user does not press 'Disconnect'
when restarting SITL.
- 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)
Also remove the legacy "range aid" than can be achieved by setting the
height reference to range finder and the range finder control parameter
to "conditional".
Conditional range aiding cal also be set when the height reference isn't
the range finder. This prevents the ratchetting effect due to switching
between references.
Instead of having a single height source fused into the EKF and the
other ones "waiting" for a failure or the primary sensor, fuse all
sources in EKF2 at the same time. To prevent the sources from fighting against each
other, the "primary" source is set as reference and the other ones are
running a bias estimator in order to make all the secondary height
sources converge to the primary one.
If the reference isn't available, another one is automatically selected
from a priority list. This secondary reference keeps its current bias
estimate but stops updating it in order to be the new reference as close
as possible to the primary one.
- much simpler direct interface using Ignition Transport
- in tree models and worlds
- control allocation output configuration, no more magic actuator mapping to mavlink and back
- currently requires no custom Gazebo plugins (keeping things as lightweight and simple as possible)
Co-authored-by: Jaeyoung-Lim <jalim@ethz.ch>
-always reset roll/pitch/yaw integrators at the same time
-reset them while waiting for launch or during FW Takeoff before Climbout
-reset wheel rate integrator only when disarmed
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Since the horizontal and vertical velocity controllers are now
decoupled, it can be that the horizontal acceleration produced by the
controller is actually greater than the desired one (by design). This
condition would actually make the ARW run "backwards", degrading the
controller performance.
Directly use yaw controls for it, and don't add it to the allocation matrix,
as that would have an effect on rudder scaling if the wheel also would have
a yaw effectiveness.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
This is the control surface type for airframes that have only a
single aileron servo or have the ailerons on a single output channel.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
2fbb70d9ca94f442de1345221be18ba738cda952 made the lowest possible
throttle value commanded by stick in Stabilized mode before taking off 0.
The real world problem with this is that when takeoff is detected then
the entire throttle scaling range jumps from
[0, MPC_MANTHR_MIN]
to [MPC_MANTHR_MIN, MPC_MANTHR_MIN].
As a result whenever MPC_MANTHR_MIN is not zero there is a thrust jump
on every takeoff just at the moment takeoff is detected even when the
stick is moved continuously.
Because of this I suggest to revert to having a higher throttle value
from the beginning on because it's less complicated and there's
no obvious value in starting out with zero thrust if anyways not
possible to go back to zero for safety once takeoff is detected.
Using the control status flags isn't robust as this part of the code
runs at the EKF update rate while the in_air transition is don at the
prediction rate. It was then likely to miss the transition
Fixes the error
googletest-src/googletest/src/gtest-death-test.cc:1283:24: error: ‘dummy’ may be used uninitialized [-Werror=maybe-uninitialized]
with GCC 11
For most VTOLs the param defaults for the agressiveness of the MC attitude controller
are too high, as VTOLs usually have high intertia and lot af drag due to wings and
can thus not rotate as fast as MCs.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
I think most vehicle can safely decend with at least 1.5m/s, and having this
value too low makes Descents/Landings/RTLs unnecessary long.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
The VTOL default was set to 1, while the param default is 1.5.
I don't see why it shuold be a different default for VTOLs and thus remove it.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
- replace float32[21] URT covariances with smaller dedicated position/velocity/orientation variances (the crossterms are unused, awkward, and relatively costly)
- these are easier to casually inspect and more representative of what's actually being used currently and reduces the size of vehicle_odometry_s quite a bit
- ekf2: add new helper to get roll/pitch/yaw covariances
- mavlink: receiver ODOMETRY handle more frame types for both pose (MAV_FRAME_LOCAL_NED, MAV_FRAME_LOCAL_ENU, MAV_FRAME_LOCAL_FRD, MAV_FRAME_LOCAL_FLU) and velocity (MAV_FRAME_LOCAL_NED, MAV_FRAME_LOCAL_ENU, MAV_FRAME_LOCAL_FRD, MAV_FRAME_LOCAL_FLU, MAV_FRAME_BODY_FRD)
- mavlink: delete unused ATT_POS_MOCAP stream (this is just a passthrough)
Co-authored-by: Mathieu Bresciani <brescianimathieu@gmail.com>
fix test by reducing the distance to the new origin: the maximum size of
the local position origin is a cube of 1e6m. If the origin is moved
further than this, the state is clipped to that maximum value
Navigator sets the cruise_speed to -1 if the controller shouldn't listen to
it and instead use the default speed (for MC: MPC_XY_CRUISE). This is for
example for RTL the case, where we want to return at the default speed,
independetly of what the mission speed before was.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Add support for the basic GPS telemetry values when using the GHST protocol.
* Fix formatting in GHST GPS telemetry changes
* GHST GPS Telemetry formatting cleanup
* GHST GPS Telemetry, Last formatting change
- synthetic airspeed will only be declared valid as soon as the wind variance
has dropped below a parameterized threshold. This is useful for vehicles without
an airspeed sensor which rely on synthetic airspeed but only once the vehicle
has turned sufficiently for the wind estimates to be reliable.
Signed-off-by: RomanBapst <bapstroman@gmail.com>
- msg constant names now comply with ROS conventions:
uppercase alphanumeric characters with underscores for separating words
partially fix#19917
Signed-off-by: Beniamino Pozzan <beniamino.pozzan@phd.unipd.it>
As per the discussion in #15331, fixed issue where stm32h7 chips
use hardware ECC bits in program memory that disallow overwriting
32-byte flash line that has already been written. As such,
this change allows for a variant implementation of the flashfs system
that uses more space in the flash entry header in order to
allow an entire line to be reserved for erasing an entry.
Signed-off-by: Taylor Nelms <tnelms@roboticresearch.com>
rtl state was getting reset on inactive, which meant that the state which triggered resuming e.g. mission landing would be overwritten, and the navigator mode would switch back and forth between rtl and mission. this commit:
1. moves the reset of rtl state to the on activation function (removing it from the on inactive function)
2. functionalizes the rtl state input to the rtl time estimator so that rtl time can still be calculated from state=none while inactive
This commit removes the additional airspeed check (airspeed for VTOLs in
hover below LNDFW_AIRSPD_MAX), as it is not a required condition in the
landed state (headwind blowing into the airspeed sensor won't stop
once on the gruond). In FW mode the check would make more sense, but there
the land detector is currently simply disabled.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
- if using multi-EKF across all magnetometers then an instance of
vehicle_magnetometer is advertised immediately for every sensor_mag
instance
- this can become problematic if EKF2 multi-mag is enabled, but with
only 1 IMU (EKF2_MULTI_MAG) because you will be stuck with no magnetometer data
FW_LND_USETER defaulted to 1 and FW_LND_ABORT terrain based bits all enabled. why? because using a distance sensor is critical to detecting when to flare, and we want to force the user to actively disable these safety settings if they so choose, so that they understand the implications.
- new param, FW_LND_TER_REL
- fixing the glide slope helps keep the landing glide behavior steady (avoiding bumps in the altitude setpoint from e.g. trees)
- flare is still triggered via the distance sensor, if enabled by FW_LND_USETERR
when the vehicle did not track the slope well (e.g. at an offset above the track) and the altitude setpoint flattening on intersection with terrain, the throttle would spool up to smoothly intersect the newly flattened altitude setpoint, this could happen before the flare altitude was reached, which is bad. now the steady state glide behavior will be maintained, and flare can trigger at the appropriate time
- the target_sink_rate param could possibly constrain the maximum commanded sink rate to something less than that of the landing glide slope, which would make it impossible to track. this commit allows opening up the desired max sink rate up to the performance limits of the aircraft, if necessary, for the landing case
- landing slope/curve library removed
- flare curve removed (the position setpoints will not be tracked during a flare, and were being ignored by open-loop maneuvers anyway)
- flare curve replaced by simply commanding a constant glide slope to the ground from the approach entrance, and commanding a sink rate once below flaring alt
- flare is now time-to-touchdown -based to account for differing descent rates (e.g. due to wind)
- flare pitch limits and height rate commands are ramped in from the previous iteration's values at flare onset to avoid jumpy commands
- TECS controls all aspects of the auto landing airspeed and altitude/height rate, and is only constrained by pitch and throttle limits (lessening unintuitive open loop manuever overrides)
- throttle is killed on flare
- flare is the singular point of no return during landing
- lateral manual nudging of the touchdown point is configurable via parameter, allowing the operator to nudge (via remote) either the touchdown point itself (adjusting approach vector) or shifting the entire approach path to the left or right. this helps when GCS map or GNSS uncertainties set the aircraft on a slightly offset approach"
- refactor updateQuaternion() to compute the yaw jacobian directly (respecting the rotation sequence determination)
- fuseHeading()/fuseYaw321()/fuseYaw312() helpers are eliminated and now mag heading fusion and EV yaw fusion compute the innovation in place
- clear up logic for performing zero innovation heading fusion when quaternion variance exceeds threshold (no more _is_yaw_fusion_inhibited flag manipulation)
- when at rest continue fusing last static heading with very low variance even if other heading sources are active
We need to ensure the Dronecode logo is prominently displayed
and linked to the PX4 brand for trademark protection of PX4 and Dronecode.
If you have any questions about this, please feel free to reach out directly to me.
- post takeoff, the aircraft follows the infinite line sourced from the launch point in the direction of the takeoff waypoint
- takeoff waypoint altitude is used as a clearance altitude, set such that once above, the aircraft has cleared all ground occlusions and may proceed with the mission
- runway takeoff state machine simplified to throttle ramp, clamped to runway, climbout, and fly
- throttle ramp must complete before switching to next state to avoid a jump in throttle setpoint just after takeoff if the takeoff airspeed is reached before the ramp is complete
- roll constraints near ground post takeoff removed from runway takeoff class (handled externally now)
- minimum airspeed in TECS is reduced to takeoff speed (if necessary) to lower the underspeed detection bound
- lateral-directional guidance uses a different period parameter during ground roll
- apply constraint only for takeoff and landing modes
- add two params, wing span and wing height, to calculate a reasonable height at which roll limits can be opened
- takeoff situational knowledge removed from all other modes except manual (or actual takeoff mode)
- manual takeoff is marked complete if at a controllable airspeed
- minimum pitch bounds TECS until manual takeoff complete
- remove individual roll constraints during manual takeoff (ground proximity constraints coming in subsequent commit)
- underspeed condition only determined by true airspeed undershoot
- change binary underspeed condition to a continuous percent undersped
- ramp-in max throttle, pitch speed weight, and TAS setpoint reduction during underspeed to avoid jumpy commands at the true airspeed error boundary
- let true airspeed filter reach zero airspeed
- create integral and trajectory generator reset methods
- always run TECS unless in rotary-wing mode (or in transition)
- constantly reset TECS integrals and trajectory generators when landed
- simplify takeoff reset method
- removes _last_manual variable in favor of _skipping_takeoff_detection, which is handled in the control mode setter
- takeoff detection (both launch and runway) is skipped if entering takeoff mode from any other mode while having already been in the air
- added method to runway takeoff class for force setting the fly state when we want to skip the takeoff detection
* Change min > max notation to [min, max] in Parameters Markdown
* Update src/lib/parameters/px4params/markdownout.py
Co-authored-by: Thomas Stastny <thomas.stastny@auterion.com>
Co-authored-by: Hamish Willee <hamishwillee@gmail.com>
Co-authored-by: Thomas Stastny <thomas.stastny@auterion.com>
- array length of data was increased without changing the data type of
the variable holding the length
Signed-off-by: RomanBapst <bapstroman@gmail.com>
As they are always moving horizontally, the check doesn't make sense
for fixed-wings.
Also don't run the check while on ground to prevent getting a failed
check during pre-takeoff manipulation.
- trim throttle is handled entirely by the position controller
- navigator should use speed setpoints
- added flag gliding_enabled in position setpoint to stills support gliding
Signed-off-by: RomanBapst <bapstroman@gmail.com>
- allow compensation based on vehicle weight (parameterized)
- use density for calculating trim throttle compensation instead of pressure
- removed parameter FW_THR_ALT_SCL
Signed-off-by: RomanBapst <bapstroman@gmail.com>
Make Power Off tune not interruptable
This solves the case of Low Battery warning tune overriding the power
off tune, as now the Power off tune is not interruptable by any other
tune unless override flag is specified
commander_helper: resolve "redundant boolean literal in ternary expression result"
- Existing code was hard to read and quite ambiguous
- Also it allowed constantly re-sending the tune_control request for a
fixed duration tunes like "TUNE_ID_BATTERY_WARNING_SLOW", while not
respecting the tune duration
When wind is already estimated, we don't reset the states using airspeed
data, so it could be that the fusion fails if the airspeed isn't
consistent with the filter (test ratio > 1). In this case, don't start
the fusion.
When wind isn't already estimated, the wind states are reset using
airspeed so the fusion can start regardless of the current test ratio.
- As it is always only used for the vehicle command ack message
- It was a duplicate, hence making it error prone for maintainment
- The uORB message comments were updated to make the relationship with
the MAVLink message / enum definitions clear
split the fusion process into:
1. updateAirspeed: computes innov, innov_var, obs_var, ...
2. fuseAirspeed: uses data computed in 1. to generate K, H and fuse the
observation
from 300 ms to 60 seconds, to give enough time for the user to configure
the vehicle in the mean time.
This is needed especially when the battery cell count setting is wrong
(when it should be 3, but set to 4 for example), since then whenever you
boot the vehicle, it will shutdown after 300 ms, which leaves the user
puzzled as to exactly what's happening. And it also prevented the user
from changing the Parameter since it's shutting down so quickly.
60 second window is intended to be a reasonable time that will allow the
user to figure out what's going on (via checking the battery level on
QGC, etc) but also not deep discharge the battery to a dangerous level.
Fixes the error:
Aborting due to missing @type tag in file: 'build/px4_fmu-v5_test/etc/init.d/airframes/11001_hexa_cox'
This can happen due to a change to e.g. board_serial_ports, which changes
the CLI command and triggers a re-execution of the airframe processing.
- this allows landing gear to retract automatically when doing a takeoff
and the vehicle is considered high enough
Signed-off-by: RomanBapst <bapstroman@gmail.com>
- 4096 of 3 hex digits each for rev and ver is enough.
#defines used in SPI versions do not be long format, use use the macro
- Board provides a prefix and the formatting is sized and built in
- No need for funky board_get_base_eeprom_mtd_manifest interface
Original mft is used where the abstraction is done with the MFT interface
Co-authored-by: David Sidrane <David.Sidrane@Nscdg.com>
If the capture GPIO is exposed to a signal with high frequency changes, a lot of
interrupts are scheduled and the handling of these call can worst-case
starve flight critical processes leading to a loss of control. Since camera capture
is not flight critical, we now give up the capture
functionality and stop the interrupts to prevent the starvation of other processes.
If the PPS GPIO is exposed to a signal with high frequency changes, a lot of
interrupts are scheduled and the handling of these calls can worst-case
starve flight critical processes leading to a loss of
control. Since PPS is not flight critical, we now give up the PPS
functionality and stop the interrupts to prevent the starvation of other processes.
Remove the entire external yaw handler, dynamic memory allocation,
pointer passing logic. Directly instanciate the weather vane instance
in the flight tasks that support it.
- remove internal accumulation and publish every valid raw sample synchronized with sensor
- store timestamp_sample from motion interrupt
- improve timing requirements from datasheet (minimum delays after register read/write)
- remove internal accumulation and publish every valid raw sample synchronized with sensor
- store timestamp_sample from motion interrupt
- improve timing requirements from datasheet (minimum delays after register read/write)
- all sources of optical flow publish sensor_optical_flow
- sensor_optical_flow is aggregated by the sensors module, aligned with integrated gyro, and published as vehicle_optical_flow
Co-authored-by: alexklimaj <alex@arkelectron.com>
Follow me : tidied second order filter implementation
Added velocity filtered info to uORB follow target status message, and rebase to potaito/new-follow-me-task
FollowMe : Rebasing and missing definition fixes on target position second order filter
Follow Me : Remove Alpha filter delay compensation code, since second order filter is used for pose filtering now
Followme : Remove unused target pose estimation update function
Follow Target : Added Target orientation estimation logic
Follow Target : Replaced offset vector based setpoint to rate controlled orbital angle control
Follow Target : Bug fixes and first working version of rate based control logic, still buggy
Follow Target : Added target orientation, follow angle, orbit angle value into follow_target_status uORB message for debugging
Follow Target : Fix orbit angle step calculation typo bug
Follow Target : Few more fixes
Follow Target : Few fixes and follow angle value logging bug fix
Follow Target : Added lowpass alpha filter for yaw setpoint filtering
Follow Target : Remove unused filter delay compensation param
Follow Target : Add Yaw setpoint filter initialization logic and bufix for when unwrap had an input of NAN angle value
Follow Target : Add Yaw setpoint filtering enabler parameter
Follow Target : Change Target Velocity Deadzone to 1.0 m/s, to accomodate walking speed of 1.5 m/s
Follow Target : Add Orbit Tangential Velocity calculation for velocity setpoint and logging uORB topics
Follow target : Fix indentation in yaw setpoint filtering logic
Follow Target : Fix Follow Target Estimator timeout logic bug that was making the 2nd order pose filter reset to raw value every loop
Follow Target : Remove debug printf statement for target pose filter reset check
Follow Target : Add pose filter natural frequency parameter for filter testing
Follow Target : Make target following side param selectable and add target pose filter natural frequency param description
Follow Target : Add Terrain following altitude mode and make 2D altitude mode keep altitude relative to the home position, instead of raw local position origin
Follow Target : Log follow target estimator & status at full rate for filter characteristics test
Follow Target : Implementing RC control user input for Follow Target control
Follow Target : edit to conform to updated unwrap_pi function
Follow Target : Make follow angle, distance and height RC command input configurable
Follow Target : Make Follow Target not interruptable by moving joystick in Commander
Follow Target : reconfigure yaw, pitch and roll for better user experience in RC adjusting configurations, and add angular rate limit taking target distance into account
Follow Target : Change RC channels used for adjustments and re-order header file for clarity
Follow Target : Fix Parameters custom parent macro, since using DEFINE_PARAMETERS alone misses the parameter updates of the parent class, FlightTask
Follow Target : Fix Orbit Tangential speed actually being angular rate bug, which was causing a phenomenon of drnoe getting 'dragged' towards the target velocity direction
Follow Target : Final tidying and refactoring for master merge - step 1
Add more comments on header file
Follow Target : tidy, remove unnecessary debug uORB elements from follow_target_status message
Follow Target : Turn off Yaw filtering by default
Follow Target : Tidy maximum orbital velocity calculation
Follow Target : add yaw setpoint filter time constant parameter for testing and fix NAV_FT_HT title
Follow Target : Add RC adjustment window logic to prevent drone not catching up the change of follow target parameters
Follow Target : fixes
Follow Target: PR tidy few edits remove, and update comments
Follow Target : apply comments and reviews
Follow Target : Edit according to review comments part 2
Follow Target : Split RC adjustment code and other refactors
- Splitted the RC adjustment into follow angle, height and distance
- Added Parameter change detection to reset the follow properties
- Added comments and removed yaw setpoint filter enabler logic
Follow Target : Modify orbit angle error bufferzone bug that was causing excessive velocity setpoints when setpoint catched up with raw orbit setpoint
Follow Target : Remove buffer zone velocity ramp down logic and add acceleration and rate limited Trajectory generation library for orbit angle and velocity setpoint
Follow Target : Remove internally tracked data from local scope function's parameters to simplify code
Follow Target : Fix to track unwrapped orbit angle, with no wrapping
Follow Target : Apply user adjustment deadzone to reduce sensitivity
Follow Target : Apply suggestions from PR review round 2 by @potaito
Revert submodule update changes, fall back to potaito/new-followme-task
Follow Target : [Debug] Expose max vel and acceleration settings as parameters, instead of using Multicopter Position Controller
's settings
Follow Target : Use matrix::isEqualF() function to compare floats
Follow Target : Add Acceleration feedback enabler parameter and Velocity ramp in initial commit for overshoot phenomenon improvement
Follow Target : Implement Velocity feed forward limit and debug logging values
Follow Target : Apply Velocity Ramp-in for Acceleration as well & Apply it to total velocity setpoint and not just orbit tangential velocity component
Follow Target : Don't set Acceleration setpoint if not commanded
Follow Target : Use Jerk limited orbit angle control. Add orbit angle tracking related uORB values"
Follow Target : Add Orbit Angle Setpoint Rate Tracking filter, to take into consideration for calculating velocity setpoint for trajectory generator for orbit angle
Revert "Follow Target : Add Orbit Angle Setpoint Rate Tracking filter, to take into consideration for calculating velocity setpoint for trajectory generator for orbit angle"
This reverts commit a3f48ac7652adb70baf3a2fed3ea34d77cbd6a70.
Follow Target : Take Unfiltered target velocity into acount for target course calculation to fix overshoot orbit angle 180 deg flip problem
Follow Target : Remove Yaw Filter since it doesn't make a big difference in yaw jitterness
Follow Target : Remove velocity ramp in control & remove debug values from follow_target_status.msg
Follow Target : Tidy Follow Target Status message logging code
Follow Target : Remove jerk and acceleration settings from Follow Target orbit trajectory generation
Follow Target : Change PublicationMulti into Publication, since topics published are single instances
Follow Target : Edit comments to reflect changes in the final revision of Follow Target
Follow Target : Apply incorrectly merged conflicts during rebase & update Sticks function usage for getThrottled()
Follow Target : Apply final review comments before merge into Alessandro's PR
Apply further changes from the PR review, like units
Use RC Sticks' Expo() function for user adjustments to decrease sensitivity around the center (0 value)
Update Function styles to lowerCamelCase
And make functions const & return the params, rather than modifying them
internally via pointer / reference
Specify kFollowPerspective enum as uint8_t, so that it can't be set to negative value when converted from the parameter 'FLW_TGT_FP'
Fix bug in updateParams() to reset internally tracked params if they actually changed.
Remove unnecessary comments
Fix format of the Follow Target code
Fix Follow Perspective Param metadata
follow-me: use new trajectory_setpoint msg
Convert FollowPerspective enum into a Follow Angle float value
1. Increases flexibility in user's side, to set any arbitrary follow
angle [deg]
2. Removes the need to have a dedicated Enum, which can be a hassle to
make it match MAVSDK's side
3. A step in the direction of adding a proper Follow Mode (Perspective)
mode support, where we can support kite mode (drone behaves as if it is
hovering & getting dragged by the target with a leash) or a constant
orbit angle mode (Drone always on the East / North / etc. side, for
cinematic shots)
Continue fixing Follow Target MAVSDK code to match MAVSDK changes
- Support Follow Angle configuration instead of Follow Direction
- Change follow position tolerance logic to use the follow angle
*Still work in progress!
Update Follow Me MAVSDK Test Code to match MAVSDK v2 spec
- Add RC Adjustment Test case
- Change follow direction logic to follow angle based logic completely
- Cleanup on variable names and comment on code
follow-me: disable SITL test
Need to update MAVSDK with the following PR:
https://github.com/mavlink/MAVSDK/pull/1770
SITL is failing now because the follow-me
perspectives are no longer defined the
same way in MAVSDK and in the flight task.
update copyright year
follow-me: mark uORB topics optional
Apply review comments
more copyright years
follow-me sitl test: simpler "state machine"
flight_mode_manager: exclude AutoFollowTarget and Orbit on flash contrained boards
Remove unnecessary follow_target_status message properties
- As it eats up FLASH and consumes uLog bandwidth
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 💄
Symmetric buffers allow a much more reliable QGC Wifi telemetry connection especially when (virtual) joysticks are used. (this board does not provide RX DMA on UART 4 as its timer does DSHOT).
The noise spectral density, NSD, (square root of power spectral density) is a
continuous-time parameter that makes the tuning independent from the EKF
prediction rate.
NSD corresponds to the rate at which the state uncertainty increases
when no measurements are fused into the filter.
Given that the current prediction rate of EKF2 is 100Hz, the
same tuning is obtained by dividing the std_dev legacy parameter by 10:
nsd = sqrt(std_dev^2 / 100Hz)
The noise spectral density, NSD, (square root of power spectral density) is a
continuous-time parameter that makes the tuning independent from the EKF
prediction rate.
NSD corresponds to the rate at which the state uncertainty increases
when no measurements are fused into the filter.
Given that the current prediction rate of the wind estimator is 1Hz, the
same tuning is obtained with the same values as before.
1. Rename *_header_s structs to *_s, since the _header postfix is not
helpful
2. Rename the "key" string variables in the message structs to
"key_value_str" as the string actually contains not just the key but the
key and value pair information
3. Add comments on other uLog messages to clarify use (need more
improvement / can be even more simplified)
* sih: Move sih out of work queue
This reverts commit bb7dd0cf0016ac1998a79814ec52b15079a74c1a.
* sih-sim: Enable sih in sitl, together with lockstep
* sih-sim: new files for sih: quadx and airplane
* sih: Added tailsitter for sih-sitl simulation
* sitl_target: Added seperate target loop for sih
* jmavsim_run: Allow jmavsim to run in UDP mode
* lockstep: Post semaphore on last lockstep component removed
* sih-sim: Added display for effectively achieved speed
* sih: increase stack size
* sih-sim: Improved sleep time computation, fixes bug of running too fast
* sitl_target: place omnicopter in alphabethic order
Co-authored-by: romain-chiap <romain.chiap@gmail.com>
Co-authored-by: Matthias Grob <maetugr@gmail.com>
- documentation of units, params, returns, and descriptions for variables and methods
- rename ambiguous or erroneous state variables
- remove unused or unecessary input arguments to functions
- remove ugly header white space
The safetyButtonHandler() reports that the safety statatus
changed on the first loop iteration when safety is disabled which makes
sense to inform the system that safety is off but the tune for the user
should not be played because it interrupts the startup tune.
They cause problems with building px4_msgs in ROS2 Humble Hawksbill and removing them fixes the issue.
Co-authored-by: Agata Barcis <agata.barcis@tii.ae>
This corrects the board definition to use the proper polarity
for the brick power valid signal, thus allowing the board to
detect the battery and monitor it properly.
internal PX4IO safety_off state is removed and replaced with a normal safety button event. From this 'commit' commander is taking care of the PX4IO safety.
- mavlink in PX4/Firmware (56106be4805cb2f70d22ad31b87fbd9774f0d0f3): 99e82cad70
- mavlink current upstream: 0909631552
- Changes: 99e82cad70...0909631552
09096315 2022-05-26 Hamish Willee - Clarify and cross reference home position everywhere (#1836)
38c1a99f 2022-05-25 Julian Oes - WIND_COV: clarify description and unknown value (#1845)
- on common IMUs like the mpu6000, mpu9250, icm20602, etc each FIFO
sample is only 12 bytes so this is still more than large enough for the
worst case transfer
- free memory is getting tight on these older boards (depending on
configuratoin) and the pixhawk 2 cube still has 2 other superior IMUs, so this is just
dropping dead weight
H7 Only supports 2 not 3 CAN interfaces.
CanInitHelper passes in in the run time configuration of
the number of interfaces. The code was ignoring these!
This type (23) doesn't specify a motor number, so it can't be properly handled.
There are duo (19) and quad (20) tailsitter types that still work in simulation.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Based on feedback that very often the battery is used down too low.
I observed this happens consistently when the cell voltage is properly
load compensated. The default load compensation before #19429 was very
inaccurate and resulted in unpredictable estimate.
After that if there is a usable current measurement and the battery is
within expected tolerances of the default internal resistance the
compensation is pretty good and 3.5V is too low for an empty compensated
cell voltage. That was seen in various logs where the compensated
cell voltage was already dropping fast after 3.6V.
In case the voltage is not load compensated the vehicle estimates the
state of charge a bit too low which is safer than to high
especially for a default configuration.
internal PX4IO safety_off state is removed and replaced with a normal safety button event. From this 'commit' commander is taking care of the PX4IO safety.
Without this, uavcan creates MixingOutput classes which then create
empty actuator_outputs publications. This then prevents the motor
output in HITL to be forwarded to the simulator via mavlink.
The baro observation noise parameter is often over-estimated in order as
a measure to mitigate temporary offsets in the readings due to wind
gusts or poor pressure compensation tuning. The side effect is that the
innovation sequence monitoring based on normalized innovation struggles
to detect an offset in the state because the innovation isn't
statistically significant.
To counter this issue, a simpler check is added to trigger the process
noise boost when the innovation has the same sign for a long period of
time.
- sitl_gazebo in PX4/Firmware (422be90140c9dee6f0e59ee4d181301b13fb11de): 48440d7b5c
- sitl_gazebo current upstream: 5eb5df8045
- Changes: 48440d7b5c...5eb5df8045
5eb5df8 2022-04-28 stmoon - ROS2_PLUGIN set OFF by default
c8f4d5b 2022-04-28 stmoon - update the motor failure plugin for ros2
1. Change the paragraph headings to proper Markdown headings (easier to
link / structure the Markdown)
2. Move PULL_REQUEST_TEMPLATE into .github folder
3. Change description in Issue template and remove outdated DevGuide
Repository information
4. Add a bug emoji to bug report isue template
5. Support automatically adding labels 'bug-report' and
'feature-request' to easily sort / filter appropriate issues in Github
We use lockdown to prevent outputs like motors and servos from being
active in HITL simulation. This means that we can't treat the lockdown
flag as a flight_terminated, otherwise we can't arm in HITL at all.
I got multiple times the feedback now that a consistent delay
is helpful and makes sense but the default delay
is too long
for low battery action where you're trying to come back in time
and possibly the emergency reaction kicks in while the critical action
is executing which leads to a longer accumulated delay.
- mavlink in PX4/Firmware (87c73145b36a835b1635de0498a5613a7af5cafc): a1cb2c0e71
- mavlink current upstream: 99e82cad70
- Changes: a1cb2c0e71...99e82cad70
99e82cad 2022-05-19 Hamish Willee - Deprecated GPS_INJECT_DATA (#1842)
bf3df03d 2022-05-16 Hamish Willee - WIND_COV - accuracy units are m/s (#1844)
a73d4864 2022-05-11 Hamish Willee - development.xml FIGURE_EIGHT_EXECUTION_STATUS - add a note about it being set at lower rate (#1841)
To return Exponential Values, which is helpful for reducing the
sensitivity of the stick around the centered value (0), since it's
exponential curve.
Useful for user adjustment implementations, where accidentally touching the stick
wouldn't have so much effect when using the Exponential value, compared
to using the raw position value.
This fixes an invalid memory access when exiting the module:
exit_and_cleanup destroys the object, but lock_guard is destructed after
and accesses the lock.
- limit to handling only 1 motor failure
- Log which motor failures are handled
- Remove motor from effectiveness matrix without
recomputing the scale / normalization
- this allows jumping straight to a non-SBUS RC protocol
- increased the scan time per protocol 300->500 ms, which the newer DSM parser seems to need in some cases.
- only set RC_INPUT_PROTO if we've had a successful RC lock for > 3 seconds
Normally _should_run for mission is only ever true if _should_run for the
normal log is. There are exceptions though:
- the log buffer fails to allocate
- there was a write failure (e.g. due to SD card removal)
In that situation, the writer would not wait anymore but busy-loop.
This replaces the propeller_torque_disabled flag to disable yaw by differential thrust
for tiltrotor and tailsitter VTOLs, as propeller_torque_disabled is not enough to set
effectiveness of an acutator in the yaw axis to 0 in case it's tilted.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Special case tiltrotor: instead of passing a 3D thrust vector (that would mostly have a x-component in FW, and z in
MC), pass the vector magnitude as z-component, plus the collective tilt. Passing 3D thrust plus tilt is not feasible as they
can't be allocated independently, and with the current controller it's not possible to have collective tilt calculated
by the allocator directly.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
2022-05-11 10:19:37 +02:00
1642 changed files with 83646 additions and 33422 deletions
about: See https://github.com/PX4/Devguide for documentation issues
about: See https://github.com/PX4/px4_user_guide for documentation issues
---
PX4 has dedicated repositories for developer documentation (https://github.com/PX4/Devguide) and user documentation (https://github.com/PX4/px4_user_guide).
## Attention! Please read the note below
**Please submit the documentation issue to the [User Guide](https://github.com/PX4/px4_user_guide) repository.**
Please use [PX4 Discuss](http://discuss.px4.io/) or [Slack](http://slack.px4.io/) to align on pull requests if necessary. You can then open draft pull requests to get early feedback.
**Describe problem solved by this pull request**
A clear and concise description of the problem this proposed change will solve.
## Describe problem solved by this pull request
A clear and concise description of the problem this proposed change will solve. Or, what it will improve.
E.g. For this use case I ran into...
**Describe your solution**
## Describe your solution
A clear and concise description of what you have implemented.
**Describe possible alternatives**
## Describe possible alternatives
A clear and concise description of alternative solutions or features you've considered.
**Test data / coverage**
## Test data / coverage
How was it tested? What cases were covered? Logs uploaded to https://review.px4.io/ and screenshots of the important plot parts.
The [developer guide](http://dev.px4.io/) explains how to set up the development environment on Mac OS, Linux or Windows. Please take note of our [coding style](https://dev.px4.io/master/en/contribute/code.html) when editing files.
The [developer guide](https://docs.px4.io/main/en/development/development.html) explains how to set up the development environment on Mac OS, Linux or Windows. Please take note of our [coding style](https://docs.px4.io/main/en/contribute/code.html) when editing files.
This repository holds the [PX4](http://px4.io) flight control solution for drones, with the main applications located in the [src/modules](https://github.com/PX4/PX4-Autopilot/tree/master/src/modules) directory. It also contains the PX4 Drone Middleware Platform, which provides drivers and middleware to run drones.
This repository holds the [PX4](http://px4.io) flight control solution for drones, with the main applications located in the [src/modules](https://github.com/PX4/PX4-Autopilot/tree/main/src/modules) directory. It also contains the PX4 Drone Middleware Platform, which provides drivers and middleware to run drones.
PX4 is highly portable, OS-independent and supports Linux, NuttX and MacOS out of the box.
* Official Website: http://px4.io (License: BSD 3-clause, [LICENSE](https://github.com/PX4/PX4-Autopilot/blob/master/LICENSE))
## Building a PX4 based drone, rover, boat or robot
The [PX4 User Guide](https://docs.px4.io/master/en/) explains how to assemble [supported vehicles](https://docs.px4.io/master/en/airframes/airframe_reference.html) and fly drones with PX4.
See the [forum and chat](https://docs.px4.io/master/en/#support) if you need help!
The [PX4 User Guide](https://docs.px4.io/main/en/) explains how to assemble [supported vehicles](https://docs.px4.io/main/en/airframes/airframe_reference.html) and fly drones with PX4.
See the [forum and chat](https://docs.px4.io/main/en/#getting-help) if you need help!
## Changing code and contributing
This [Developer Guide](https://docs.px4.io/master/en/development/development.html) is for software developers who want to modify the flight stack and middleware (e.g. to add new flight modes), hardware integrators who want to support new flight controller boards and peripherals, and anyone who wants to get PX4 working on a new (unsupported) airframe/vehicle.
This [Developer Guide](https://docs.px4.io/main/en/development/development.html) is for software developers who want to modify the flight stack and middleware (e.g. to add new flight modes), hardware integrators who want to support new flight controller boards and peripherals, and anyone who wants to get PX4 working on a new (unsupported) airframe/vehicle.
Developers should read the [Guide for Contributions](https://docs.px4.io/master/en/contribute/).
See the [forum and chat](https://dev.px4.io/master/en/#support) if you need help!
Developers should read the [Guide for Contributions](https://docs.px4.io/main/en/contribute/).
See the [forum and chat](https://docs.px4.io/main/en/#getting-help) if you need help!
### Weekly Dev Call
The PX4 Dev Team syncs up on a [weekly dev call](https://dev.px4.io/master/en/contribute/#dev_call).
The PX4 Dev Team syncs up on a [weekly dev call](https://docs.px4.io/main/en/contribute/).
> **Note** The dev call is open to all interested developers (not just the core dev team). This is a great opportunity to meet the team and contribute to the ongoing development of the platform. It includes a QA session for newcomers. All regular calls are listed in the [Dronecode calendar](https://www.dronecode.org/calendar/).
@ -88,35 +88,43 @@ This repository contains code supporting Pixhawk standard boards (best supported
* FMUv6X and FMUv6U (STM32H7, 2021)
* Various vendors will provide FMUv6X and FMUv6U based designs Q3/2021
* [Raspberry PI with Navio 2](https://docs.px4.io/main/en/flight_controller/raspberry_pi_navio2.html)
Additional information about supported hardware can be found in [PX4 user Guide > Autopilot Hardware](https://docs.px4.io/master/en/flight_controller/).
Additional information about supported hardware can be found in [PX4 user Guide > Autopilot Hardware](https://docs.px4.io/main/en/flight_controller/).
## Project Roadmap
A high level project roadmap is available [here](https://github.com/orgs/PX4/projects/25).
## Project Governance
The PX4 Autopilot project including all of its trademarks is hosted under [Dronecode](https://www.dronecode.org/), part of the Linux Foundation.
<ahref="https://www.linuxfoundation.org/projects"style="padding:20px;"><imgsrc="https://mavlink.io/assets/site/logo_linux_foundation.png"alt="Linux Foundation Logo"width="80px"/></a>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
