ArduPlane:make heading lock upon gnd speed consistent #29104
Conversation
|
I think we need to merge #28976 first. There are is some overlap. |
|
I see no need for the delay before capturing heading...gpses have had good velocity and heading since the m8n appeared years ago
|
|
going to try to improve failsafe heading code as per Devcall |
|
After reviewing the code in mode_takeoff and commands_logic, and a lot of SITL takeoffs with headwinds ~ cruise speed, I do not think a failsafe for not having enough groundspeed to break out of roll limit constraints in the face of extreme headwind is required (would take an extremely reckless operator to try to take off in winds exceeding the speed of the vehicle in my opinion)....eventually the altitude target will be reached in either case, or nav will slowly yaw/turn such that grndspd suddenly increases, and the limit eliminated....no fly away will occur because the vehicle is moving VERY slowly...it will almost vertically ascend and then switch to next mission item or initiate the mode_takeoff loiter, and takeoff has to be in headwind conditions within 5m/s of cruise speed....so just capturing heading based on groundspeed is valid in my opinion....the other PR removing the mode_takeoff failsafe after LEVEL_ALT is obtained can be merged in my opinion also....currently NAV_TAKEOFF has no equivalent and requires no removal |
| @@ -67,7 +67,7 @@ void ModeCruise::navigate() | |||
| plane.channel_roll->get_control_in() == 0 && | |||
| plane.rudder_input() == 0 && | |||
| plane.gps.status() >= AP_GPS::GPS_OK_FIX_2D && | |||
There was a problem hiding this comment.
We don't seem to be consistent about checking for 3D vs 2D fix.
There was a problem hiding this comment.
true, maybe in another PR
we use GPS_GND_CRS_MIN_SPD in AUTOLAND, this makes ModeTakeoff and NAV_TAKEOFF consistent with this