- user defines a cone half angle which defines the RTL altitude behavior
- if vehicle is outside the cone it will climb until it intersects the cone
and then return at this altitude.
- if vehicle is inside the cone or above the predefined return altitude (RTL_RETURN_ALT)
then it will return at the current altitude
Signed-off-by: RomanBapst <bapstroman@gmail.com>
* Move cm8jl65 class member variable initialization from constructor list to declarations. Format whitespace and move method doxy comments to declarations.
* Refactor the cm8jl65 driver start() method, and rename info()->status().
* Continued refactoring of the cm8jl65 driver class:
- Condense all class files into a single *.cpp file and give class scope resolution to previously unscoped methods.
- Refactor cm8jl65 namespace level driver entry methods to reduce code and improve clarity.
- Breakout CDev specific initialization LOC into the device_init() method.
- Move the endian modification inside of the crc16_calc() method.
* Deprecate the hardware ringbuffer, _class_instance, and ioctl() from the cm8jl65 driver.
* Migrate remaining member variable intialization to declarations and employ uniform initialization style. Copy/paste help() and main() methods to the bottom of the file to match convention with other distance sensor drivers.
* Refactor the LeddarOne driver class to give scope resultion to the methods that were global and to standardize the implementation against most of the other distance sensor drivers.
* Deprecate _reports member var, use of hardware ring buffer, and LeddarOne::read() method.
* Deprecate commented (dead) code from the LeddarOne class init() method.
* Refactor the LeddarOne class cycle() and collect() methods and create measure() method to untangle the previous logic implementation.
- airframes that are not well trimmed rely on the integrator to learn
the offset. This change can help improve altitude hold during transitions
Signed-off-by: RomanBapst <bapstroman@gmail.com>
- VT_MOT_COUNT assumed that motors were always the first outputs. This
does not have to be true always. VT_MOT_ID allows to specify precisely how
many motors we have for hovering and to which channel they are connected.
Signed-off-by: RomanBapst <bapstroman@gmail.com>
* Migrate mb12xx driver class member variable initialization to declarations.
Format whitespace and alphabetize/group/order var declarations.
Refactor driver reset() and mb12xx_main() methods for readability.
Deprecate usage of IOCTL.
* Deprecate the _reports ringbuffer, _class_instance, and read() method and minor formatting in the mb12xx driver.
* Add time_literal usage and #define MB12XX_BUS_SPEED.
* Refactor the mb12xx driver to mirror the mappy_dot driver implementation and create functionality for multiple sensors.
* Add stack size for the mb12xx driver.
@bkueang and me realized that on every frame we tune the integral gain for
the roll and pitch rate controller is much too low. Usually it needs to be
increased to 0.3 or even 0.4 to have better "locked in" flight performance
and 0.2 seems like a good compromise for a safe default.
Reduce the I gain for high rate errors to reduce bounce-back effects after
flips. Up to 200 degrees the gain is almost not reduced (<25%), so this
will only take noticeable effects for large errors (setpoint changes),
where we actually want to have an effect.
This allows to increase the MC_*RATE_I parameters w/o negative effects
when doing flips (i.e. bounce-back after flips).
The 400 degrees limit and the x^2 are empirical.
The better the rate tracking in general (high P gain), the less this is
required (because of the lower tracking error). At the same time it also
does not harm, as the i_factor will always be close to 1.
BazookaJoe1900