* stop motors after 90 degrees of rotation and with max rate
* handle no accelerometer data
* improve check for acc, although seems to be OK without it
* disable all attenuation if rate is set to zero
* refactoring thanks Karate
* use sensors.h
* remove unnecessary arming check
* exit crashFlip immediately switch is reverted if throttle is zero
* add Crashflip Rate to OSD
* Revert unnecessary changes in crashflip core.c code
and clarify comments about crashflip switch
* update / minimise comments, thanks Karate
* ensure all names say `crashflip` consistently
* Undo quick re-arm because motrors were not reversed
* fix issue with reversed motors, we must disarm
* ignore yaw rotation and set gyro limit to 1900 deg/s
* default attenuation to off (crashflip_rate = 0)
* refactoring, increase rate limit to allow stronger inhibition
* enable in race_pro mode
* don't attenuate on attitude until a significant change occurs
* no attenuation for small changes
* Updates from review by PL
* remove whitespace
* refactor motorOutput, update comments, renaming variables
thanks PL
* changes from review PL
* only permit fast re-arm if crashflip rate set and crashflip was successful
* properly exit turtle mode
* add crashFlipSuccessful to unit test extern c
* small updates from review
* improved crashflip switch handling
* remove unnecessary motors normal check
* Disarm on landing
* Changes from review comments, thanks PL
* Sorry missed that one
* calculate Acc magnitude once only, not multiple times
* Include gyro factors as in crashRecovery
* Fix bug in CrashRecovery delta gains
Add temporary debugs to monitor error and delta inputs
* remove 1G subtraction for accMagnitude
thanks Karate
* Use AccDelta or Jerk - thanks Karate
* Revert using Gyro Setpoint and Delta
* Fix typo, thanks Mark
* increment PG version to 9
* ezLanding
* Add ez_landing throttle mode
* Correct EzLanding scaling of motorMixRange
* Correct mixer_type switch bracing style
* Remove motor value cliping ez landing mode
- rename mixer type cli setting to EZLANDING from EZLANDING_THROTTLE
- remove EZLANDING_CLIP cli setting
- double default ez_landing_threshold
- halve default ez_landing_limit
- check and limits in cli settings
- remove mixer type dependent settings in mixer_init
- remove clip based code in mixer.c
* Change ez_landing setting values and refactoring
- Halve defaul ez_landing_threshold setting and double in init instead.
Now stick deflection equal to ez_landing_threshold should give approimately full authority.
Previously it was the point where the mixer was allowed to raise the throttle to 100 % (which wouuld never be required)
- Increase ez_landing_threshold maximum to 200 (from 100) to allow settings that increase authority by a little at full stick deflection
- Increase ez_landing_limit maximum to 75 which is the point where EzLanding should act identical to the Legacy mixer with airmode on
- remove throttle percent from
- simplify calculation of , since throttle stick deflection is no longer involved
- update/remove outdated comments
* Remove old EZLANDING entries in mixerType enum
* Add mixer_type setting to blackbox log header
---------
Co-authored-by: ctzsnooze <chris.thompson@sydney.edu.au>
Co-authored-by: Mark Haslinghuis <mark@numloq.nl>
GPS Rescue flight control logic only knows how to fly multirotors and engaging GPS Rescue on a fixed-wing craft would result in an immediate loss of control and crash. For example, when GPS Rescue is engaged it attempts to yaw to the home direction heading and this won't work on fixed wing (particularly the flying wing mixer with no rudder). Next it tries to attain the target altitude exclusively with throttle control - not how altitude is controlled with a fix-wing aircraft.
Also the GPS Rescue no-fix arming prevention logic shouldn't be applied.
Use the final calculated throttle value that may be affected by throttle limiting, throttle boost, etc. instead of the rcCommand input when calculating the virtual current meter.
If DSHOT telemetry is enabled but one or more ESC's are not supplying valid telemetry packets, then send the DSHOT command to enable telemetry once a second while disarmed until all ESC's are supplying telemetry.
Addresses the issue of the flight controller booting without the ESC's powered. In this case the initial command at boot to enable bidirectional telemetry will be missed by the ESC since they're not powered. If the battery is subsequently plugged in the ESC's will default to bidirectional telemetry disabled.
This change will detect that ESC's are not supplying telemetry and attempt to preiodically enable them.
Currently only rcCommand values are included in the log data and the configurator calculates the actual setpoint values based on rates values added to the blackbox header. The problem with this is that the rates information is only written at arming so if the rates change during the log (rateprofile change, in-flight adjustments, etc.) then the calculated setpoints will be incorrect. There's no way to tell from the log that this happened. This often causes confusion because it will suddenly make it appear in the log that the PID controller is not acheiving the requested rates when it's just a presentation error. Also the rates will be incorrectly calculated when the user selects Raceflight style rates as the rates type is not supplied in the log header (and the viewer doesn't have the forumla for them anyway).
This change adds the actual setpoint values for each axis as used by the PID controller, removing the necessity for the viewer to perform any calculations. In addition to showing any rate changes, it will also show any cases where other flight features have modified the setpoints from the user's input. These were invisible previously (examples include level modes, Acro Trainer, GPS Rescue, yaw spin recovery, etc.).
Also the throttle value used in the mixer is included in the throttle axis. This allow visualization of things that affect the commanded throttle like throttle boost, throttle limit, GPS Rescue, angle level strength, etc.
Change the logic to not modify rcCommand directly and instead apply the additional throttle directly in the mixer.
Also move the logic to the attitude task instead of having it calculate in the PID loop. The logic relies on an angle that's only updated in the attitude task so there was no point in running the calculation every PID loop.
The telemetry data provides eRPM/100. Added a `motor_poles` parameter (defaulting to 14) that is used to calculate the physical RPM.
RPM = (telemetry_rpm * 100) / (motor_poles / 2)
Most motors we commonly use are 14 poles, but the user can adjust if needed for their setup.
Also calculate actual RPM for DEBUG_ESC_SENSOR_RPM, but to fit with in int16 the log value will be RPM/10.
