In AP_MotorsTri.cpp the AP_MOTORS_MOT_1, _2 and _4 constants are
always mapped to actual output channels through _motor_to_channel_map
while the _CH_TRI_YAW is not, but there were a few inconsistencies
in this that could lead to things like PWM min and max values being
set on wrong channels.
It looks like all in all _motor_to_channel_map being in PROGMEM
probably doesn't help save memory and I'm not sure how useful it is
in the first place but regardless the usage should be consistent.
limit.throttle_lower flag becomes true when the throttle passed into the
motors lib (which is in the 0 ~ 1000 range) is below _min throttle.
This makes the interpretation of the THR_MIN parameter consistent
between the main code (which uses 0 ~ 1000 range) and the motors lib
(which previously used the RC3_MIN ~ RC3_MAX range).
The remaining problem however is that the output of the motors continues
to use THR_MIN as if it were a pwm. I don't believe this is a dangerous
problem however.
Removes the "Increase opposing motors by 1/2 the overage of the high
motor" logic and merely moves all 3 motors down by the same amount if
one is over out_max. This eliminates the asymmetric scaling of
the previous logic when more than one motor is over out_max. This
resolves#537
- Allows use of hardware floating point on the Cortex-M4.
- Added "f" suffix to floating point literals.
- Call floating point versions of stdlib math functions.
Extended AP_MotorsTri class to take in pointer to rc_tail servo (rc_7) and we use this servo's REV parameter to determine whether to reverse the output to the tail servo or not
1. it's step towards rearchitecting the current code base ahead of a move to RTOS.
2. internally it uses a MatrixTable for the Quad, Octa, OctaQuad, Y6 frames.
3. it implements the missing stability patch for Octa and OctaQuads (still missing for Y6)
Later check-ins will incorporate into the main ArduCopter code.
Jonathan Challinger
Andrzej Zaborowski
Randy Mackay
texlan
Andrew Tridgell
James Bielman
Pat Hickey
uncrustify
Robert Lefebvre