* added a new driver ASP5033 for measuring the differential pressure and airspeed
---------
Co-authored-by: nano <nanobotzhe@abv.bg>
Co-authored-by: Denislav Petrov <you@example.com>
When the yaw estimate is converging, the controller makes the drone yaw
in order to follow the current setpoint. This is unintuitive for the
pilot and it is preferable if the drone continues to fly towards the
same physical direction.
This estimate doesn't converge to the true yaw but can be used as a
more consistent but drifting heading source.
It can be used by a setpoint generator to adjust its heading setpoint
while the true yaw estimate is converging in order to keep a constant
course over ground.
This updates the gps/devices submodule which includes a fix that
requests the Unicore HEADINGA message in case the message is not enabled
by default.
Signed-off-by: Julian Oes <julian@oes.ch>
If the measured voltage is more than 65v we need to split the voltage
over multiple cells in order to avoid overflowing the uint16. This is
according to the MAVLink spec.
Signed-off-by: Julian Oes <julian@oes.ch>
The extension fields need to be 0 by default according to the MAVLink
spec. This is because extensions are 0 by default and need to be 0 when
unknown/unused for backwards compatibility.
The patch also simplifies the flow slightly in that it doesn't create a
temporary array but just fills in the cell voltages directly.
Signed-off-by: Julian Oes <julian@oes.ch>
Fixes the clang error:
/__w/PX4-Autopilot/PX4-Autopilot/src/drivers/drv_hrt.h:297:35: fatal error: identifier '_s' preceded by whitespace in a literal operator declaration is deprecated [-Wdeprecated-literal-operator]
297 | constexpr hrt_abstime operator "" _s(unsigned long long seconds)
- Enable arbitrary euler angle for Mag rotation
- new CUSTOM rotation enum out of the normal enum range
- mag_rot: automatically change to custom if euler rot is set
- sensor_calibration: Magnetometer save custom rotation parameters
- mag_cal: cross mention rotation parameters
- This allows the user to see the RPY options when searching for the rotation parameter
---------
Co-authored-by: Junwoo Hwang <junwoo@auterion.com>
Co-authored-by: bresch <[brescianimathieu@gmail.com](mailto:brescianimathieu@gmail.com)>
Co-authored-by: Daniel Agar <daniel@agar.ca>
During transition to FF, only allow update thrust axis up to 45° as with a high tilt angle
the effectiveness of the thrust axis in z is apporaching 0, and by that is increasing
the motor output to max.
Transition to HF: disable thrust axis tilting, and assume motors are vertical. This is to avoid
a thrust spike when the transition is initiated (as then the tilt is fully forward).
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
EffectivenessTiltrotor: link time when to tilt motors to MC position to COM_SPOOLUP_TIME
- remove VT_TILT_SPINUP and special spin up tilt handling form the VTOL module
- now handle the spoolup in the allocation, directly linked to COM_SPOOLUP_TIME
- leave tilts at disarmed value during spoolup
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
- when GNSS is used require low mag heading innovations during
horizontal acceleration (yaw observable) to validate the mag
- only fuse mag heading just enough to constrain the yaw estimate
variance to a sane value. Leave enough uncertainty to allow for a
correction when the yaw is observable through GNSS fusion
In the mavlink_receiver code, after a while it will try to resend some
parameter update through the MAVLink instance. But for Iridium links
those are not a good idea. So this adds a condition that prevent the
sending if the MAVLink instance is in Iridium mode.
Related to issue #21496
sem_wait() can be interrupted if the task receives a signal, however
the blockinglist implementation depends on blocking until the semaphore
can be obtained.
Fix a memory overflow in case SENS_BOARD_ROT is set to Rotation::ROTATION_MAX (41) which is not a valid value
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
* Navigator: DO_CHANGE_SPEED: only store sinlge cruising_speed_current_mode
This stored cruising speed setpoint is reset on mode change and
after a VTOL transition.
* Navigator Mission: replay DO_CHANGE_SPEED items when resuming mission
* Navigator: remove cruising_speed_sp_update()
Speed changes in a mission are handled directly in the position controllers,
and no longer in Navigator.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
---------
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Increased size for ORB_ID from uint8_t to uint16_t
Created a type: orb_id_size_t = uint16_t.
There are still a couple of places where the size
of the ORB_ID is assumed to be less than 16-bits.
The places that I have found are commented regarding
this and can be found with a search on orb_id_size_t.
- split mag_3d into new standalone mag fusion and mag fusion allowed to update all states (full mag_3d)
- new dedicated control logic for mag/mag_3d fusion and standalone mag heading fusion
- if WMM available use for mag_I and mag_B init
- mag states reset if external yaw reset (yaw estimator, GPS yaw, etc)
- mag reset if declination changed (eliminate _mag_yaw_reset_req)
- mag fusion (but not mag_hdg or mag_3d) can be active during gps_yaw or ev_yaw (if yaw aligned north)
Co-authored-by: bresch <brescianimathieu@gmail.com>
- simplify vehicle_status.arming_state down to just armed and disarmed
- ARMING_STATE_INIT doesn't matter
- ARMING_STATE_STANDBY is effectively pre_flight_checks_pass
- ARMING_STATE_STANDBY_ERROR not needed
- ARMING_STATE_SHUTDOWN effectively not used (all the poweroff/shutdown calls loop forever in place)
- ARMING_STATE_IN_AIR_RESTORE doesn't exist anymore
- collapse ArmStateMachine into commander
- all requests already go through Commander::arm() and Commander::dismarm()
- other minor changes
- VEHICLE_CMD_DO_FLIGHTTERMINATION undocumented (unused?) test command (param1 > 1.5f) removed
- switching to NAVIGATION_STATE_TERMINATION triggers parachute command centrally (only if armed)
---------
Co-authored-by: Matthias Grob <maetugr@gmail.com>
* ekf2-test: remove outdated codegen comparison
The definition of states changed so the comparison with the old
derivation cannot work anymore.
---------
Co-authored-by: bresch <brescianimathieu@gmail.com>
Some system are able to dead-reckon for a while after losing GPS or
other sources providing positional feedback. If the estimated position
error grows above the failsafe threshold, the system enters a failsafe
mode. As the position error estimate is growing linerly over time, and
it is recommended to take action before entering the failsafe, we here
warn the user about the imminent failsafe and propose to take manual
control.
---------
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
* [not-working] add a gz-omnicopter model
* Fix axis directions on omnicopter model
The omnicopter joint axis directions had to be adapted for sdf 1.9 as it has different conventions for joint axis definitions.
* include model from gz-fuel & remove mesh files
* Fix omnicopter model using fuel
---------
Co-authored-by: Jaeyoung Lim <jalim@ethz.ch>
If at the last powercycle one mission was uploaded, the counter in dataman was 1. On the next powercycle the mavlink mission counter was reset to zero and on first mission upload updated to 1 again. Other modules check, if the mission was changed based on the counter, like the mission.cpp loaded the mission counter from the dataman. On a new mission, the comparison of the counters failed, because both were the same value even if the mission was completely different.
This can be useful if using a full EV + GNSS setup and you start indoors, then fly outside. Once GPS is good and the only missing requirement is yaw alignment the yaw estimator reset is performed and EV yaw will automatically stop itself.
There is no reason to contrsain the position uncertainty, estpecially
when flying with velocitiy aiding only.
Note that all the variances are already contrained to sane values at the
end of the covariance prediction
- set vision attitude error filter uninitialized if vision data stops
- ev error filter is only compiled when ev config is selected
Co-authored-by: bresch <brescianimathieu@gmail.com>
A version update is needed since the dataman is showing errors if data doesn't exist or if it is wrongly stored. This will force default data to be initialized.
There is some actual changes because the earth mag field states are now
reset using the WMM when available. In the replay log, the measured mag
field does not match the WMM and this is why there is a large diff. It
is however more correct now than before.
because sprintf is deprecated on MacOS
and CI fails with warning -> error:
'sprintf' is deprecated: This function is
provided for compatibility reasons only.
Due to security concerns inherent in the
design of sprintf(3), it is highly
recommended that you use snprintf(3) instead.
I updated all versions to the newest one that's used anywhere.
Then at least the straing can be found with full text search.
It's another step towards understanding and unifying the CI environment.
Since we changed the threshold for allowing arming from TRIM/2 to AIRSPEED_MAX
is is very unlikely that one needs to disable this check.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Experience from tuning different VTOL backtransitions showed only having a
I controller is beneficial over a combined FF/I breaking controller.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Case: A vehicle is already operating but has no stick input or another
source than RC. When RC stick input is switched to either because it gets
first time available or as a fallback to joystick then the mode was
immediately changed to the switch position. This can lead to loss of
control e.g. when the vehicle is flying far away and the
mode switch of the RC is in some fully manual piloted mode.
I added tests to cover the cases where RC mode initialization is expected
and also unexpceted because the vehicle is already armed.
modules__ instead of module__ prefix
The module depends on the hysteresis library and probably because
it compiles with the still prevalent global includes the dependency
is not declared.
also for the other linux target builds. It's a follow up to
e5503480e3
I wasn't aware that there are multiple different
container versions used for almost the same build.
in air bias estimation is usually really accurate and should be weighted
more heavily compared to the calibration parameters that are often
more approximate given the worse magnetic environment near the ground.
- since last_us is set to 0 every time the bias is not observable, the
total time was also reset -> needed 30 consecutive seconds in mag 3D
to be declared "stable"
- after landing, the mag_aligned_in_flight flag is reset. Using this for
bias validity makes it invalid before we have a chance to save it to
the calibration.
Opt flow raw innovations can be really large on ground due to the small
distance to the ground (vel = flow / dist). To make the pre-flight check
more meaningful, scale it with the current distance.
Channel values stay over one unit test but some tests assumed they are
reset each time. Reset the channel after these mode button tests.
Parameters survive between unit tests presumably as long as
the bianry runs. Reset them if a test requires that.
This allows PWM and all other output methods to configure
stopped, idling and full thrust points and use them consistently.
The fact that a fixed wing motor can be stopped when zero thrust
is demanded is explicit and could in principle even be disabled.
The mechanism is the same as for a standard VTOL stopping the
multicopter motors in the fixed wing flight phase.
This allows to consistently define:
Motor stopped - disarmed PWM
Motor idling - minimum PWM
Motor at full thrust - maximum PWM
Any allocation can then distinctly decide if
a motor should be running or not depending
on the context and also explicitly command that.
This is required to process data from the ADS1115 ADC and enables the
params BATx_I_CHANNEL and BATx_V_CHANNEL.
Testing is required whether this actually works on Pixhawk 6X though.
Signed-off-by: Julian Oes <julian@oes.ch>
When switching into Hold mode establish a Loiter around current position,
even if we were before already loitering (eg in Mission mode).
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Having newline between I think didn't apply the PR stale days setting of
30 properly (it was using 45)
And it seemd that unless I set the days-before-close to -1
intentionally, it would still close the Issue/PRs, as the default value
is 7 already.
Also updated version of the stale action to v8
* Remove old stale bot yaml file
* Remove slack svg file (unused)
* Stale action: Only apply stale label, and no other actions
Respecting the opinion on
https://github.com/PX4/PX4-Autopilot/commit/fa9ac6ecf651232f3105ca124a2d2c54ab8620d0,
it seems reasonable to disable commenting feature, and just keep the
action only applying the `stale` label. This will reduce the noise /
email spams / ping pong fight with the stale bot (Action)
- Remove unnecessary text rendering, which made clicking log links
harder
- Re adjust markdown elements to make it easier to read / intuitive when
creating an issue
Instead of hard-coding the tilting duration (from FW to MC tilt),
expose it as a parameter (VT_BT_TILT_DUR). The default is the same
as the hard-coded value previously (1s).
Slower tilting mechanisms need a higher value here, while for smaller
ones a too high value results in unnecessary delays till the motors
are in hover configuration.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
This affects how soon after a backtransition the vehicle has the
full hover controller running again. Specifically it reduces the
duration of the ramp down of the motors prior to tilting them.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
COM_ARMABLE is set to "Disabled" will prevent arming.
This allows to set the parameter when ground demoing a drone or
if it's in maintenance for safety reasons.
const char *data = "www\r\n";
Defines a cstring of 6 bytes: 'w', 'w', 'w', '\r', '\n', '\0'
type of data: char const*
type of &data: char const**
So when we call
write(_fd, &data, strlen(data));
then strlen(data) == 5
and we send the 4 byte memory address of data
+ some additional random byte.
Correct is
write(_fd, data, strlen(data));
where char const* gets casted to const void * and we pass
the pointer to the content of data.
The fundamental problem here is write() not being typesafe.
Before this the ESC calibration aborts if battery detection doesn't work.
The problem is if the user still connects the battery as he gets instructed
and the calibration aborts then the ESCs are in calibration mode and
after abortion calibrate to the wrong value.
Also I realized there's no additional safety by aborting the calibration
if the battery cannot be detected during the timeout because a pixhawk
board without power module will report a battery status from the
ADC driverand in it that no battery is connected which is the best
it can do. In this situation the motors will still spin if the
ESCs are powered.
Some ESCs e.g. Gaui enter the menu relatively quickly if the
signal is high for too long. To solve that it's kept high shorter.
Also all tested ESCs detect the low signal within a shorter time
so no need to wait longer.
- Change timings for a more reliable calibration.
- Make sure there's an error message when battery measurement is not
available also when it gets disabled after system boot in the power
just above the calibration button.
- Safety check if measured electrical current goes up after issuing the
high calibration value for the case the user did not unplug power
and the detection either fails or is not enforced.
Before:
When the mixed throttle for the motor was exactly zero the ramp went
from the disarmed PWM value to the minimum PWM value.
When the throttle was even just slightly different from zero the ramp
made a jump up to the commanded throttle scaled between
disarmed PWM and maximum PWM, then ramped between
disarmed PWM and minimum PWM and at the end jumped up again to
the commanded throttle scaled between minimum PWM and maximum PWM.
After:
The ramp goes from disarmed PWM value to the the
commanded throttle scaled between minimum PWM and maximum PWM.
If the commanded throttle changes during the ramp then the scale and
hence also end value of the ramp changes.
When at rest, directly fuse the gyro data as an observation of its bias.
This allows to strongly observe the gyro biases without having to fuse a
constant heading that makes the ekf too confident about its heading.
The entire logic did not work for the case when the throttle channel is
reversed because then QGC sets trim = max for that channel and
the result is only half the throttle range.
This adds support for the TI LP5562 RGB LED driver.
Things to note:
- The driver is initialized in simple PWM mode using its internal clock,
for R,G,B, but not for W(hite).
- The chip doesn't have a WHO_AM_I or DEVICE_ID register to check.
Instead we read the W_CURRENT register that we're generally not using
and therefore doesn't get changed.
- The current is left at the default 17.5 mA but could be changed using
the command line argument.
Datasheet:
https://www.ti.com/lit/ds/symlink/lp5562.pdf
Signed-off-by: Julian Oes <julian@oes.ch>
* Removed obsolete voxl2-io directory
* Updated support for ModalAI FC v2 board
* Added UAVCAN back in and removed local position estimator and attitude estimator Q that are no longer supported.
* Removed unneeded IMU drivers
set_vtol_transition_item sets the params of the mission item directly
to values that make sense for NAV_CMD_DO_VTOL_TRANSITION, but don't
for other NAV_CMDs. So make sure that whenever we use it, we then in
the next step reset the touched mission_item fields.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Our serial_test showed only ~84kB/s with the default 256 RX buffer size
with significant ~2.5ms periods of the flow control RTS pin being
asserted. Increasing size to 600 (same as FMU-v5x) brings the throughput
only to ~190kB/s, while a size of >1500 achieves ~350kB/s. Larger RX
buffers do not increase throughput anymore, while the theoretical
maximum is 375kB/s.
Transmit buffer size is increased to 10kB same as on FMUv5x to prevent
any future differences in queue behavior and throughput. serial_test
showed ~350kB/s throughput at 3kB TX buffer size, so this is just a
precaution.
* refactored uncommanded descend quadchute
- use fixed altitude error threshold
- compute error relative to higest altitude the vehicle has achieved
since it has flown below the altitude reference (setpoint)
* disabled altitude loss quadchute by default
* altitude loss quadchute: added protection against invalid local z
---------
Signed-off-by: RomanBapst <bapstroman@gmail.com>
- ArmingStatus DroneCAN message STATUS field is only set to true based on
arming_status.armed
- Cannode prearm state is set to true always when ArmingStatus DroneCan
message is received
- Instead we disable interrups on Nuttx where needed
- No lock is held during param export. Params can be changed
concurrently and we rely on the fact that another export will be
triggered in that case.
5s is a more reasobale time for tailsitters, which rely differently on this param
than other VTOL types. Tailsitters will ramp the pitch up withing this time,
while for other VTOLS types its only the max transitiont time.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
This is now using the advanced lift drag plugin.
The important step was to enable airmode for yaw, otherwise yaw gets
saturated at low throttle and we can barely roll.
The other trick was to raise airspeed a little bit to avoid operating
too much at the lower end of throttle where control authority is low.
Signed-off-by: Julian Oes <julian@oes.ch>
* RateControl: rename setGains to setPidGains to be more precise
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
* FW Rate controller: only allow to disable Yaw in Acro, not roll and pitch
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
---------
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
- re-enable once the estimator selector respects configured mag
priority (at least initially) or is otherwise able to automatically
prefer an external mag over internal
- for SITL disabled because the full matrix of esitmator instances
(IMUs X mags) was too many topics for logger currently
Transitions in Stabilized mode are done manually, the pilot controls the pitch angle
and if it's above the threshold the transition is declared finished (plus airspeed
check for front transition). Thus we can't have fixed thresholds but need to link
them to the actual max pitch angle in Stabilized mode.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
We currently fuse 0 as airspeed rate measurement, and thus simply low-pass
filter the airspeed measurements. Testing has shown that the current default
on the airspeed rate measurement noise is set to low, and thus the airspeed
mesurement is filtered too much.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
A VTOL plane in MC mode has no yaw setpoint during takeoff because of
weather-vane. To align for the front transition, the yaw target jumps
and caused a step in the controller, making it reach saturation.
With this commit, the previous yaw setpoint is set to the current yaw
when no yaw setpoint is sent in order to create a smooth yaw trajectory
starting at the current orientation when yaw target is suddenly finite.
The yawspeed filter also now contains the yaw speed instead of dyaw in
order to prevent chattering due to dt jitter.
The API is cleaner if the control_data is const reference and the device
compid is an explicit output argument.
Signed-off-by: Julian Oes <julian@oes.ch>
The resets in the modes (eg Loiter mode) are not active yet, so manually
set rep->current.cruising_speed = -1.f if not already in the same flight mode.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
When flow control is used together with DMA, we need to add a pulldown
to CTS. Without it, it assumes flow control and gets stuck when
CTS is not connected.
Signed-off-by: Julian Oes <julian@oes.ch>
When we fall back to another link, we are already doing a uORB copy when
checking the data. Therefore, we should further down use/send that data
instead of overwriting it immediately.
Signed-off-by: Julian Oes <julian@oes.ch>
I don't think it makes sense to slow down switching RTCM injection to
once every 5 seconds. If we don't have corrections, we should check and
use whatever we get as soon as possible.
Signed-off-by: Julian Oes <julian@oes.ch>
We need to reset the instance after looping through all instances.
Otherwise, we are left with the last instance if none is valid but have
not updated the _selected_rtcm_instance which is what is logged.
Therefore, this change fixes the logged RTCM instance.
Signed-off-by: Julian Oes <julian@oes.ch>
It turns out that I had omitted implementing the gimbal_device_id which
is the component ID of the gimbal device that the gimbal manager (in
this case PX4) is responsible for.
Signed-off-by: Julian Oes <julian@oes.ch>
Once passed the transition and in FW mode, it takes some ms unitl the FW att sp is updated
by the FW att controller. During this time the last published attitude sp is kept bein used,
which is the one that was published during transition. So let's fill the thrust[0] of it.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
This adds the ability to manually set who has primary control over a
gimbal and also adds printing it as part of the status.
This is helpful, especially while working on the QGC gimbal v2
implementation.
Signed-off-by: Julian Oes <julian@oes.ch>
A default of 10s makes more sense compared to the old 4s, as this is only the
max time of a back transition and it's also decleared completed if the
speed drops below the hover cruising speed (MPC_XY_CRUISE).
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
There have been substantial TECS changes lately, and the config files
for custom VTOLs have not been updated since a long time. I would thus
rather use the default TECS gains for lightly maintained configs.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
with the goal to make it more clear and the error only appear when
armed but every time the running task doesn't actually match
the mapping inside the start_flight_task() function.
* Navigator: on_mission_landing() only can return true if currently in mission mode
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
* RTL: reset RTL state when not in RTL nav_state
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
* Navigator: fix mission vs. normal RTL
- remove extra state _should_engange_mission_for_landing from rtl and have
this logic outside of RTL where Navigator decides on running mission RTL or normal RTL
- fix logic in Navigator to decide mission RTL vs normal RTL
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
* Mission: land_start(): fix decision if already on mission landing
Simply checking landing() is not enough, as that is not reset until
set_current_mission_index(get_land_start_index()) later in the function.
Instead ask Naviator about it (on_mission_landing()).
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
* Navigator: only update _shouldEngangeMissionForLanding once, to not set it to false after VTOL backtansition
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
---------
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
* Port of the PX4 Vision gazebo-classic model to Gazebo. With Gazebo Garden, everything seems functionnal.
* Port of the PX4 Vision gazebo-classic model to Gazebo.
With Gazebo Garden, everything seems functionnal.
* Added airframe for command make px4_sitl gz_px4vision
* revert author field
* Import model from Ignition Fuel instead of defining it directly in the .sdf
Tests showed that sideslip fusion often starts just before airspeed
fusion, resetting the wind states to 0 instead of using the airspeed
data. A quick look at the wind uncertainty allows to know if the current
wind estimate is meaningful or if we should rather reset it using the
airspeed data.
- if the height rate input into TECS is finite, use that one to
update a velocity reference generator
- if the velocity reference generator reports position locked or
height rate input is not finite, then run altidue reference generator
- run altitude controller only if altitue is controlled
if height_rate_setpoint is set, only use that one to update altitdue trajectory
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
* FWPositionController: add linear airspeed-to-trim-throttle mapping
Scale trim throttle in a linear way with airspeed.
Different gradients above/below trim airspeed.
The airspeed- and airs density-corrected trim throttle is required for an accurate
throttle prediction in TECS, while the default trim throttle is still needed
as well, as the throttle delta from height rate setpoint delta is linked to it.
---------
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
* Navigator: change way of telling logic if RLT was started just now
* Navigator: change logic around when to engage Mission mode for RTL
To find out if we're currently on a mission landing, check if we either are
past the land start marker OR currently land start marker is current WP
and vehicle is already in LOITER mode.
* Navigator: do not engage RTL at all if already on mission landing
* Navigator: consider to be on mission landing if the LOITER_TO_ALT and dist small
To find out if we're currently on a mission landing, check if we either are
past the land start marker OR currently land start marker is current WP,
the type is LOITER_TO_ALT and the vehicle is inside loiter.
---------
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
This fixes the case where the hardware detection fails on CubeBlack when
a CAN device is connected to CAN1 and talking, and therefore preventing
the check from getting a clear result.
Signed-off-by: Julian Oes <julian@oes.ch>
This consolidates the version/revision detection function.
This should allow for actual changes in a follow up commit.
Signed-off-by: Julian Oes <julian@oes.ch>
## Please note that feature requests are not 'fire and forget'
It is a lot more likely that the feature you would like to have will be implemented if you keep watching your feature request, and provide more details to developers looking into implementing your feature, and help them with testing.
- type:textarea
attributes:
label:Describe problem solved by the proposed feature
description:A clear and concise description of the problem, if any, this feature will solve. E.g. I'm always frustrated when ...
validations:
required:true
- type:textarea
attributes:
label:Describe your preferred solution
description:A clear and concise description of what you want to happen.
validations:
required:true
- type:textarea
attributes:
label:Describe possible alternatives
description:A clear and concise description of any alternative solutions or features you've considered.
validations:
required:true
- type:textarea
attributes:
label:Additional context
description:Add any other context or screenshots for the feature request here.
# Override parameters from user configuration file.
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.