Fix bug introduced in 3d34e061fe which causes flight_stage to be
FLIGHT_NORMAL instead of FLIGHT_TAKEOFF during takeoff stage causing
itself at least the use of THR_MAX and THR_SLEWRATE instead of
respectively TKOFF_THR_MAX and TKOFF_THR_SLEW and perhaps has other
consequences.
Could be really bad if TKOFF_THR_MAX needs to be much higher
than THR_MAX or if TKOFF_THR_SLEW needs to be much lower than
THR_SLEWRATE and cause a crash on takeoff due to low airspeed or torque
roll
These reductions are based on experirence helping users setup new vehicle. In the vast majority of cases the existing values are too high
STEER_ANG_P is the default for the angle-to-rate controller and is used during pivot turns. This value may still be slightly too high.
STEER_RATE_MAX is the maximum turn rate so the new value allows a 360 turn in 3 seconds
STEER_ACCEL_MAX is the acceleration for the turn rate meaning a vehicle can get to 120 deg/sec in 1 sec
THR_ACCEL_MAX is the maximum acceleration. This new value means a vehicle can accelerate to 1m/s in 1 second.
this fixes the underlying reason why the mkdir problem happened on
some boards and not others. The FAT cluster clear code was trying to
write in 32k chunks, and failed to allocate a DMA region that large
2048 should give good performance while saving a lot of memory
This means the data sent in the mavlink message is closer to the
information when the picture was taken, rather than when we decide we
have the space to send the mavlink message. When we process the
deferred request to send the camera feedback message is up to the
vagaries of mavlink scheduling, so the data can become quite out-of-date
11:32 AM] AndrewTridgell: @Peter Barker we should disable flow control when we first add the uart - none of the RC protocols use flow control
[11:32 AM] AndrewTridgell: the blocking writes call isn't needed
[11:32 AM] Peter Barker: Thanks, I'll make a patch.
