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
- preflight mag bias estimate is in the vehicle body frame and removed from the raw mag data after it's rotated, calibrated, etc
- in flight mag bias (from ekf2) is in the vehicle body frame, but stored as a sensor frame offset immediately
* Enable motor controls for fixed wing mode in tailsitters
This commit enable motor controls in fixed wing mode for tailsitters
This is needed for enabling quad tailsitters
* VTOL: differential thrust in FW: adapt params to be generic for all axes
Until now only suppoted on yaw axis. Not to be supported also on Roll and Pitch.
- VT_FW_DIFTHR_EN: make bitmask for all three axes independently. First bit is Yaw,
sucht that existing meaning of VT_FW_DIFTHR_EN doesn't change.
- VT_FW_DIFTHR_SC: rename to VT_FW_DIFTHR_S_Y and add same params for roll (_R) and
pitch (_P).
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
* Integrate differential control bits to three axis control
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
It's enough that the setpoints and the unallocated values are logged, from these
the allocated values can be calculated if required.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
It's very important that the in descend detection is always
at a strictly higher velocity than the vertical movement check.
This combination is basically used to check for vertical downwards
velocity tracking. Desired descend, no movement -> ground
If in descend threshold is lower than vertical movement it is
by definition even with perfect tracking the case that with
any velocity between the two thresholds there is no movement
even though a descend is commanded.
See first fix of this problem #7831e39b38ba96
I don't see where this is necessary. During takeoff, the maybe landed flag should
only get cleared once system is about to takeoff, and thus well after the spool up
is complete (for which the higher thresholds are meant in this case).
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Don't consider these params for vertical speed threshold,
and instead increase the default for LNDMC_Z_VEL_MAX and
use solely that one. Makes the land detector outcome more
predictable and its interal logic simpler, while the new
default tuning is resulting in about the same vz threshold
as before.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
* Changed M_PI to M_PI_F in the matrix library since M_PI is non-standard.
* Added a new M_PI_PRECISE constant definition to px4_platform_common/defines.h to be
used in places when M_PI is desired but shouldn't be used because it is not C standard.
* Added the px4_platform_common/defines.h include to the matrix library math.hpp header to pull
in some non-standard M_PI constants and updated the test files to use those constants.
* Fixed PI constants in matrix helper test to prevent test failure
before there was a corner case where if in an auto mode that sets a reset command on the attitude setpoint message (e.g. auto takeoff), if the mode was then switched stabilized, this reset bool would never be changed back to false and the integrators would reset every cycle
* Removed dprintf from perf library since it is only ever used with fd=1 (STDOUT) so moved to PX4_INFO_RAW instead. This helps with some platforms (e.g. Qurt) which have some Posix support but not full Posix support.
This was previously required to reset the flight speed after a VTOL transition,
but is now no longer required as the DO_CHANGE_SPEED commands are handles directly
in the controllers.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
This fixes the issue where the init happended in the initializer list, at which point
the params were not yet initialized and thus resulted in random values for the init
values of _mission_item.loiter_radius and .acceptance_radius.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Refactor
- Require reboot for PD_GRIPPER_EN parameter change
- Define gripper ACTION_NONE for readability. This makes implicit assumption that -1 equals no-action commanded more explicit
- Tidy the scattered vcmd_ack struct handling cases into a single function
- Refactor to remove return in the middle of function: avoids future complications where a programmer may expect the logic at the end of the function to be executed, but isn't
Vehicle Command Handling
- Cancel the previous running vehicle command if we receive a different vehicle command
- Reject vehicle command if we get a same one that is getting executed
- Save the source system & component of currently running vehicle command
- Added note about new discovered edge case of having same entity sending different gripper commands consequently, where an unexpected ack result may be received
Gripper:
- Don't command gripper (via uORB `gripper` topic, which maps into an
actuator via Control Allocation) if we are already at the state we want
(e.g. Grabbed / Released) or in the intermediate state to the state we
want -> This prevents spamming on `gripper` topic
Payload Deliverer:
- Add read-once function for Gripper's released / grabbed state
- Send vehicle_command_ack for both release/grab actions.
TODO: target_system & target_component for the released/grabbed vcmd_ack
is incomplete, since we are not keeping track of the vehicle_command
that corresponds to this. This needs to be dealt with in the future, not
sure what the best solution it is for now.
Possible solutions:
- Queue-ing the vehicle command?
- Tying the gripper's action to specific vehicle command one-on-one, to make sure if we send multiple vehicle commands, we know
which command resulted in the action exactly?)
Only command Gripper grab when we are actually initializing gripper
- Previously, on every parameter update, gripper grab was being
commanded
- This commit narrows that scope to only when we are actually
initializing the gripper
Handle gripper de-initialization upon parameter change
- Also added some local state initialization code to init() function of
Gripper
- This will now make init / de-init more graceful & controlled compared
to before
- This hopefully then alerts the GCS that the command is getting
processed
- Referenced commander's `handle_command` function to implement this. As
it seems like GCS needs the acknowledgement of the command being
processed to execute such commands properly
- Also send FAILED command ack if we can't actuate the gripper
Fix wrong GRIPPER_ACTION conversion from floating point to int32_t
- Due to the MAVLink spec, we actually just convert enums into floating
point, so in PX4 we need to convert the float directly into integer as
well (although there can be precision issues on large numbers)
- This is a limitation in MAVLink spec, and should hopefully be
changed in MAVLink v2
Affects the states AUTO_ALTITUDE and AUTO_CLIMBRATE. Those modes should only be entered
if armed (as they are pure failsafe modes). Also allow though to enter them even if
the position setpoint(s) are invalid, as they are not needed.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Instead of checking the .valid flag of position_setpoint, check for ISFINITE() of lat, lon, alt
when pulling the position_setpoint triplet. This fixes problems where the .valid flag didn't
reflect the proper state of the setpoint (e.g. .valid was true, .lat though NAN)
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
the nuttx and posix specific options files since this option cannot be used with
the qurt platform. There are header files in the hexagon sdk that fail this check.
as Tools/update_px4_ros2_bridge.sh as been deleted
update_ros2_bridge, update_px4_ros_com and update_px4_msgs
are no more needed
Signed-off-by: Beniamino Pozzan <beniamino.pozzan@phd.unipd.it>
- vehicle_angular_velocity: ESC RPM notch filters minimize filter resets
- only allow one filter init per axis per cycle
- "park" ESC notch filters at min frequency instead of full disable
- relax timeout before a notch filter is disabled
- add new parameter IMU_GYRO_DNF_MIN for configuring the minimum notch filter frequency
- avoid the possibility of unsigned underflow from subtracting two HRT timestamps (uint64_t)
- most of these aren't problematic, but people tend to replicate the pattern, so it's better to be safe
- likely wasn't a problem when people were using hrt_absolute_time() in place, but if using an existing timestamp there's the possibility it's older than a more recent topic update
- 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)
- working towards keeping all height source (baro/ev/gnss/rng) handling as consistent as possible, possibly refactoring these out into separate classes later
This fixes a bug where by accident the vtol_status was considered instead of the
vehicle_status, preventing it from running on planes.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
This commit fixes feedforward acceleration setpoints for fixedwing offboard position control.
Previously when acceleration feedforward inputs were sent, negative curvature accelerations were not being computed properly
ekf2: merge mag 3d innov var, Hx and Kx computation to reduce flash
Slightly less code produced, almost no performance change
ekf2_mag3D: do not pre-compute Kalman gains
The vector of Kalaman gains is not too expensive to compute using
matrix-vector multiplication. Pre-generating it using CSE takes a lot of
flash space for little benefit.
- this is a precaution to eliminate the possibility of getting stuck in
a loop trying to keep up with a high rate publication that could be
coming from a higher priority task
- in the worst case scenario printing the error message can take longer than the next gyro publication, so combined with an infinite loop you could get stuck here
The previous default for yaw and roll was 0.2, which is very low, and for wheel was
1, which is very high. A value of 0.4 makes sense to me for all axes.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
I guess this was a left over from times where the controller had a completely different structure,
a value of 50 is well outside of reasonable range (50x the default).
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
The previous max of 10 for the FF gains seems a bit very high for me, well outside
of reasonable reange.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
- Fixed clearing arming word if flightmode unknown
- Added power and cell voltage elements
- New OSD layout
- Fixed home direction/distance are now correct
Co-authored-by: Chris Seto <chris1seto@gmail.com>
Moves the arming checks before the command handling.
This reduces the chance of race conditions. However it does not prevent
them! The SDK will need to check when offboard is ready to run/arm to fix
this.
Specifically this is for sitl offboard tests, where offboard_control_mode
is updated and immediately after a mode switch into offboard is commanded.
- trajectory_setpoint and vehicle_local_position_setpoint used to be
the same data type
- we got extremely lucky here that this didn't cause any issues due to
all the fields still aligning
Starting the fake position as soon as all the aiding sources stop makes
the local position immediately invalid while we could continue to navigate
for a couple of second with inertial dead-reckoning
- vehicle_imu_status can publish immediately on any measured sample
rate change or sensor error increment, but the windowed mean/variance
shouldn't necessarily reset that often
This is to prevent that that data from non-recent publications of the virtual
attitude setpoints are used in the transition code.
It removes the previous implementation where the update_transition_state()
method was only run when both mc and fw virtual att sp where recent, independetly
of whether both are used or not.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
- for accel/gyro/mag estimated bias only consider them stable (valid
for calibration updates) if the value isn't changing (10% of limit) over
the validity period
* Changed sitl_gazebo to the advanced liftdrag plugin fork.
* Added advanced plane and its associated parameters to PX4. Also tweaked one of the plugins to fix a compilation error (upcasting from float to double).
* Switched gazebo back to main branch, to avoid merge conflicts.
* Change simulator bridge back to what it was in main branch
* Changed sitl_gazebo to match the PX4 main branch's (commit hash b968405)
* Changed SimulatorIgnitionBridge to match most recent main.
* Removed exit after dsp signature generation.
* First full test suite
* Cleaned up the muorb tests
* Improved VOXL 2 self test trigger in startup file
* Removed unneeded include file
This removes the odd px4_i2c_bus_external override which was confusing
me and lead to odd and inconsistent results.
The function is now only available with an int as the argument.
- Previously it was hard to check which state the gripper was in
(GRAB/GRABBED/ etc), not even whether it was correctly initialized, this
commit adds that functionality
- When the gripper was uninitialized, the error message popped up
everytime the module had 'any' vehicle command received. But we should
be spamming only when we do actually get 'DO_GRIPPER' command received,
this commit adds that feature
- Also converted error messages for CLI when gripper test functinality
fails, so that user would get a feedback (originally, the PX4_DEBUG was
of course not outputting everything)
Also containst a mini refactor by removing the unnecessary function
get_default_altitude_acceptance_radius().
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
This new check is inteded to trigger if there is no data variation published by
the airspeed driver for the first 10s after the first data is published.
This is to capture malfunctioning sensors/drivers that do publish a value, this
value though does not come from real sensor measurements.
Previously this was captured by the data stuck check, but it has shown that
some drivers can publish a stuck value without being actually malfunctioning
(e.g. when the airspeed is outside of their measurement range). Checking for
any data variation is the more conservative check that still catches the above
described failure case.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
When a mission starts capturing images using the
MAV_CMD_IMAGE_START_CAPTURE command, it should also stop it again, in
case it is stopped early, e.g. with RTL.
Issue addressed: ROS2 is built from source and
no system-wide version of fastrtps is installed
Signed-off-by: Beniamino Pozzan <beniamino.pozzan@phd.unipd.it>
Such that the loiter (orbit) status can be displayed on groundstation
and the WP is accepted once within loiter radius
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
- To check stack smashing (buffer overflow)
- To check if the buffer without enough length gets appropriate values
filled
- To check if the format has expected length
- Previously, not having a proper boundary check caused overflows in the
buffer (wrong memory access)
- Moreoever, negative size values getting introduced to snprintf &
strncat were also being truncated to unsigned value, hence causing
overflow, so index check needed to be added before both functions
- Fixed typo in board_common.h
If the current yaw setpoint is valid we should use it to make the transition in this direction.
For a VTOL_TAKEOFF the yaw_setpoint is used to specify the transition direction (the
vehicle is aligned towards it and then transition is started). The current yaw can be
a bit off (e.g. because MIS_YAW_ERR is large), and it is better to track the actual setpoint.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
- for convenience merge px4_sitl_ign into px4_sitl_default, but allow simulator_ignition_bridge to quietly skip inclusion if ignition-transport isn't available
- simulator_ignition_bridge only try setting the system clock in
lockstep builds
- this simplifies usage and CI system dependencies
- rcS parameter backup try to directly restore param (FRAM) from backup (in case SD card is removed before successful export)
- rcS parameter backup logging rearrange to capture more logging output (param_import_fail.txt)
- posix rcS try to keep param backup and restore roughly in sync with NuttX rcS
- tinybson fix debug printf format
- param_export_internal ensure file descriptor positioned at 0 (precaution)
This state is added to give extra time between FIFO flush command. Some icm42688p IMUs need more time between config -> FIFO reset -> FIFO read. More about the issue #20181
As I understand it, only Rev 3 and Rev 4 were shipped by HB for Mini and
CM4, and are likely to be used for it.
It would be nice to have all combinations but it requires quite some
flash in the current implementation.
For targets that define the SPI buses via px4_spi_buses_all_hw, a call
to px4_set_spi_buses_from_hw_version() is needed. Otherwise a NULL
de-reference will occur when trying to access px4_spi_buses.
Fixes a system crash in px4_fmu-v5_protected:
up_assert: Assertion failed at file:armv7-m/arm_memfault.c line: 101 task: wq:lp_default
This feature allows user to use a Gripper type pacakge delivery
mechanism on a drone to trigger the delivery during a mission via the
mission item `DO_GRIPPER`.
This is a minimal change that is intended to have simplest pacakge
delivery feature on PX4, however the future scope would extend this
feature out of Navigator, and rather move towards a federated PX4
(flight-mode flexibility) architecture. But until then, this will serve
the purpose.
Update Tools/sitl_gazebo submodule to remove sdf file overwrite error
- There was an error happening due to .sdf file being overwritten, it
was caused by a wrongfully added. sdf file.
- This update pulls in the PR commit: https://github.com/Auterion/sitl_gazebo/pull/147
Initial cut on supporing PAYLOAD_PLACE mission item
Tidy and comment on navigation.h to clarify mission item definition
- Convert vehicle command ack subscription data type to
SubscriptionData, to not care about having a dedicated struct for
copying the latest data
- Tidy and comment on navigation.h to clarify the definition of
mission_item_s, which is confusing as it is an intergration of MAVLink
Standard into PX4's internal Mission Item structure
Rename mission_block's mission item reached function & cleanup navigator
- Isolated Handle Vehicle Commands function inside the Navigator
- Rename mission_block's mission item reached function to 'reached or
completed', as the navigation command can also be an action (e.g.
DO_SET_SERVO, which doesn't make sense to refer to as 'reached' when we
have successfully done executed the command)
Include MAVLink PR commit to include payload_drop message
More changes to add payload_drop MAVLink message support
- Comitting for testing purposes
Add mission item payload_drop to vehicle command payload drop link
- Now with a mission item with the nav_cmd set to 'payload drop', the
appropriate 'payload drop' vehicle command will be issued
Make Payload drop executable via Mission Plan
Implement payload_drop module to simulate payload delivery
- Simple module that acknowledges the payload drop vehicle command after
certain time, to simulate a successful delivery
Additional changes - payload drop module not working yet
- Need to do more thread stuff to make it work :(
Fix Payload Drop enum mismatch in vehicle_command enums
- First functional Payload Drop Implementation MVP
- Simple Ack & resuming mission from Navigator tested successfully
Hold the position while executing payload drop mission item
- Still the position hold is not solid, maybe I am missing something in
the position setpoint part and all the internal implications of
Navigator :(
Add DO_WINCH command support
Some fixes after rebase on develop branch
- Some missed brackets
- Some comment edits, etc
Add DO_WINCH command support
- Still has a problem of flying away from the waypoint while the
DO_WINCH is being executed, probably position setpoint related stuff :(
Apply braking of the vehicle for DO_WINCH command
- Copies the behavior of NAV_CMD_DELAY, which executes a smooth, braking
behavior when executing the delay because of the braking condition in
`set_mission_items` function
- This will not apply to Fixed wings
- The payload deploy getting triggered may be too early, as right now as
soon as the vehicle approaches the waypoint within the acceptance
threshold, the payload gets deployed
Add DO_GRIPPER support
Implement Gripper actual Hardware triggering support
- Currently not working, possibly in the mixer there's a bug
- Implemented the publishing of actuator_controls_1 uORB topic
- Implemented the test command for the payload_drop module, to test the
grpiper functionality
- Edited px4board file to include the payload_drop module
- Added Holybro X500 V2 airframe file, to enable testing on X500 V2
- Created new Quad X Payload Delivery mixer, which maps the actuator
controls 1 topic's data into the MAIN pin 5 output
Make Payload Drop Gripper Work
- Initialization of the Gripper position to CLOSED on Constructor of the
payload_drop module
- Setting the OPEN and CLOSED value to the appropriate actuator controls
input
Set vehicle_command_ack message's timestamp correctly
- By not setting the timestamp, the ack commands were not correctly
graphed in PlotJuggler!
Rename payload drop module to payload deliverer
- I think it's a more complex name (harder to type), but more generic
Add Gripper class (WIP)
Add Gripper class functionalities
- Add gripper uORB message
- Add gripper state machine
Use Gripper class as main interface in payload_deliverer
- Utilizes Gripper class functions for doing Gripper functionality
Remove mixer based package delivery trigger logic
- Remove custom mixer files that mapped actuator controls to outputs
statically
Additional improvements of the payload_deliverer
Fix payload_deliverer module not starting
- _task_id wasn't geting set appropriately in task_spawn function, which
led to runtime failure
Add Gripper Function to mixer_module
- Still not showing up as function mapping in QGC, needs fix
Add parameters to control gripper behavior
- Now user can enable / disable gripper
- Also select which type of gripper to use
Applying review from nuno
Remove timeout fetching from mission item and use gripper's timeout
- Previously, it was planned to use a custom DO_GRIPPER and DO_WINCH
MAVLink message definitions with information on timeout, but since now
we are using original message definition, only relevant timeout
information is defined in the payload_deliverer class
- This change brings in the timeout parameter to the Navigator, which
then sets the timeout in the mission_block class level, which then
processes the timeout logic
Make payload deployment work for Allmend test :P
Support gripper open/close test commands in payload_deliverer
Move enum definition for GRIPPER_ACTION to vehicle_command.msg
Remove double call for ` ${R}etc/init.d/rc.vehicle_setup`
- Was introduced during the rebase
- Was causing module already running & uORB topic can't be advertised
errors
Fix format via `make format` command
Modify S500 airframe file to use for control allocation usage
- Added Control allocation related parameters as default to not have it
reset every time the airframe is selected
Implement mission specific payload deploy timeout and more changes
Switch payload_deliverer to run on work queue
Remove unnecessary files
- Airframe changes from enabling control allocation are removed
Address review comments
- Remove debug messages
- Remove unnecessary or verbose comments & code
- Properly call parameter_update() function
Switch payload_deliverer to scheduled interval work item & refactor
- Switch to Schedeuled on Interval Work Item, as previous vehicle
command subscription callback based behavior led to vehicle comamnd ack
not being sent accordingly (since the Run() wouldn't be called unless
there's a new vehicle command), leading to ack command not being sent
out
- Also, old vehicle commands were getting fetched due to the
subscription callback as well, which was removed with this patch
- Fix the wrong population of floating point param2 field of vehicle
command by int8_t type gripper action by creating dedicated function
- Refactor and add comments to increase readability
Add gripper::grabbing() method and handle this in parameter update
- Previously, the intermediate state 'grabbing' was not considered, and
when the parameter update was called after the first initialization of
the gripper, the grab() function was being called again, which would
produce unnecessary duplicate vehicle command.
- Also replaced direct .grab() access to sending vehicle comamnd, which
unifies the gripper actuation mechanism through vehicle commands.
Navigator: Change SubscriptionData to Subscription to reduce memory usage
- Also removed unused vehicle command ack sub
PayloadDeliverer: Remove unnecessary changes & Bring back vehicle_command sub cb
When hitting zero thrust by stick there is 0 torque authority
without airmode. So 0% minimum manual thrust should never be the default
without airmode.
Uses COM_SPOOLUP_TIME to slowly ramp the throttle and allow the
tailrotor to compensate in a coordinated way based on the yaw
compesation from throttle, see CA_HELI_YAW_TH_S.
This coordinated spoolup is necessary to avoid unsafe yaw twitches
because of the heli rotating until the correct compensation kicks in
through the feedback controller.
Move logic implemented in the header files to source files, this way
it will be simpler to define which is compiled to kernel space and
which to user space
Also allows to remove some headers that pull in half the universe
from the board definitions (which should just be pin definitions and
no functionality)
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>
2fbb70d9ca 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>
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.
Please use [PX4 Discuss](http://discuss.px4.io/) or [Discord](https://discord.gg/dronecode) 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. Or, what it will improve.
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/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))
See also [maintainers list](https://px4.io/community/maintainers/) (px4.io) and the [contributors list](https://github.com/PX4/PX4-Autopilot/graphs/contributors) (Github).
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
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.
Konrad