Flight Log
.
cuav V5
4.0.7
lidarlite v3hp (i2c)
airspeed sensor
glow fuel engine.
.
this happens consistently and repeatedly (every time) except that the direction of the rudder changes sometimes.
.
mission works well except for landing approach… when the plane is over runway, some low distance (3-5m?) above gnd, it kicks hard rudder and heads abruptly towards side of the runway.
very dangerous when direction of deviation is toward pits.
.
i cant figure this out. looked at multiple logs multiple times. is it a preflare problem? is it a ground_steering problem? logs dont show a slope/height correction problem that i can see.
.
note that i have had autoland work previously on this and other airframes, although i think that was pre-lidar. this is a wheeled (taildragger), slow-ish, cub aircraft on a smooth runway.
There is a message saying that it’s restarted the landing. I wonder if something with the lidar is causing the issue.
LAND_ABORT_DEG might need adjusting. Maybe it’s just too tight between desired glide slope and the actual slope calculated by the lidar, triggering a go-around.
thx for the effort, allister.
i looked into what you mentioned (and thx for alerting me to the messages).
.
however, i see some discrepancies that cause me to doubt that as the problem…
.
1st: The message that the landing was restarted happens at the changing of mode from AUTO to FBWA, after the rudder deflection, when i manually switched to FBWA to try and recover. When the rudder kicks hard left or before that, there is no message.
.
2nd: A look at the glide slope (see pic orange line) shows it is slightly lower than the mission slope (pic white dashed line). LAND_ABORT_DEG param states that it activates when the current height is ABOVE the desired slope. the abort would happen to avoid diving too steeply to get back to the mission slope path. the mission slope and real slope look pretty close.
.
3rd: the measured altitudes (baro and lidar) and TECS alt are all very close to one another, with baro and lidar never differing as much as 2m during the slope.Lidar seems to be a little lower than TECS.hdem, but isnt that a case for the LAND_SLOPE_RCALC = 2m behavior? The behavior that this RCALC param triggers is not an abort … from arduplane docs: …“Set to zero to keep the original slope all the way down and any detected baro drift will be corrected by pitching/throttling up to snap back to resume the original slope path. Otherwise, when a rangefinder altitude correction exceeds this threshold it will trigger a slope re-calculate to give a shallower slope. This also smoothes out the approach when flying over objects such as trees. Recommend a value of 2m.”
… so violation of this param should have seen a little more throttle/elevator, not hard rudder and landing abort.
.
.
also, why would the rudder steer hard left when the do_land_start waypoint is to the right?
here are some previous logs showing the rudder kick on autolanding. these included a tf mini lidar that wasnt so capable, and sometimes didnt even begin reading before the rudder incident. Three of them (flight log 2,3,5) shows a second landing attempt in auto (after abort by manual switch) that does not display the rudder kick (1st attempt had rudder kick).
.
Flight log 1
Flight log 2
Flight log 3
Flight log 4
Flight log 5
Flight log 6
i have noticed an association with the rudder kick issue… it is linked to the “ground steering” height parameter. when the TECS.h value reaches the parameter value, the rudder kicks. and the kick lasts until the final flare (land stage 3), whence the rudder heads back towards 0-ish.
… these 3 flight logs show the rudder kicking at 4m, which followed my change of the ground steering height from 5m to 4m. the rudder was kicking at 5m previously, when ground steering was set at 5m.
.
notice the rudder is not kicking as much as before. i dont know why. nor do i know why it picks the direction to deflect. these last logs are different from the original ones in that takeoff and landing are in the same direction, rather than opposite, but i dont know if that matters. i will try the opposite direction again now that i know good landings can be achieved to see if deflection is extreme.
.
the fact remains. the rudder is kicking/deflecting at ground steer height for some unknown reason.
next session.
because of wind, had to TO/land in the same direction again.
2 flights, identical mission - no changes.
1st was very nice. 2nd was succesful, but rudder kicked hard on landing. it was close to gnd and deflection ended before it caused too much yaw. bounced a bit sideways on touchdown.
.
this pic is from the log viewer of the 1st flight. shows yaw because of wind, and deflection at 4m (ground steer alt) ending at flare…
.
this pic is from log viewer of 2nd flight, showing big deflection at “ground steering” altitude (TECS.h 4m) that ends at land stage 3 (flare).
.
so. is there something i’ve done wrong with the parameters/setup that causes the ground steering to get involved in the landing? does the preflare lock heading like the flare? if so, why does the gnd steer interrupt it?
I believe I ran into the same issue, except in FBWA. While I was landing on my first flight after enabling ground steering, the rudder suddenly fully deflected.
I believe this happens because the locked course used for ground steering is not reset when the aircraft climbs above the ground steering altitude. When you descend back down below the threshold, ArduPlane attempts to turn the plane back to the takeoff heading, causing the sudden rudder deflection.
This can easily be reproduced in SITL. To make things easier to see, set GROUND_STEER_ALT to something like 50 (so you can easily trigger ground steering without landing), and increase STEER2SRV_P to make the kick more noticeable. Fly below GROUND_STEER_ALT and move the rudder to lock in the course. Then, climb above GROUND_STEER_ALT and turn approximately 180 degrees. Without touching the rudder, descend back down below GROUND_STEER_ALT, which will trigger the bug.
I’ve tested that resetting steer_state.locked_course whenever ground steering is disabled fixes the issue.
nice work, ben.
.
i was suspicious of this, but i don’t know how to do SITL yet, so i was going to try opposite direction TO/landing when the wind permitted. definitely safer your way with SITL.
.
IF ground steering is useful for landing, it would need to lock the heading (immediate heading, not previous takeoff heading) at some place near touchdown/flare. imho
so, how does this get fixed? im not a programmer, so i cant do it (wich i could).
Sorry for not responding earlier, I didn’t see the notification.
This is the patch that I am using to fix the issue: Plane: reset ground steering course while disabled · lopsided98/ardupilot@1100031 · GitHub. Someone with more familiarity with the code may have a more elegant fix, but this has prevented a recurrence of the problem over many flights.