Hello,
I am studying the documentation and some posts about crashes because of poor tuning to be better at diagnosing problems and I have come up with a doubt: What happens with the pid, specifically the integral term, when you change from a more automatic mode like auto or guided to a more manual mode, like Loiter, PosHold, AltHold, Stabilize?
Nothing hapends. There are 13 PIDs
3 for attitude rates (r,p,y)
3 for attitude (r,p,y)
3 for position velocity (r,p,y)
3 for position (r,p,y)
1 for altitude
On some modes the position controllers are dis-activated, but in all modes the attitude ones are running, there is no discontinuity on the I term when switching modes.
I posted some diagrams a while ago about all the loops. Have you seen that already?Ü
2 Likes
I will check these diagrams. Also, if it’s not a bother, could you please help me with a few things?
1-Could you direct me towards the part of the firmware code that has the PIDs?
2-Is there some log analysis post or video, other than the documentation, that shows how to use different log parameters to diagnose problems? So far, after studying a few posts here, I know how to check motor physical bias or motor failure with rcout, gps glitches by checking hdop and gps alt versus another alt, checking the desired versus achieved rates/angles of roll, pitch and yaw to see if the tuning is bad or good, check the vibrations with Vibe to see if they are close to the ideal 5 cm/s^2 but I feel there is more to learn.
3-What about a scenario where the copter from auto mode to poshold or similar and the drone crashes? While there isn’t a bin file that I can share, if there is no discontinuity on the I term when switching modes, what would be a good guess for the problem? My guesses would be bad radio trimmimg and deadzones or no accounting for a controller with feedback at the middle or bad tuning.
- serch for attitude_controll and PIDs on the libraries folder
- look for Any Piper youtube videos
- investigate a bit more, and them provide some proof in a .bin log file
I investigated and I think I have a theory of what happened. For the procedure o takeoff, there is a code in python that sends the takeoff command to copter while in GUIDED mode. As soon as the drone reaches the scripted height, the code triggers a mode change to poshold without giving any time for the drone to hold position at the height it achieved. I think the instantaneous change in mode, plus the PID values weren’t properly tuned and it was windy, plus some vibrations close to 30 cm/s^2, caused the loss in control.
The log is below. PS: the log is big because were made multiple takeoffs and landings and I accidentally marked both RAW_IMU and enabled fft
I can see I need to do a better tuning with the pid attitude rates and decrease the vibrations, but I can’t see anything that explain why the vehicle lost control at the same time a change in mode happened, when it was taking off moderately well in windy conditions. My only guess is my theory I wrote above.
Did anyone find something in the log that could help figure this out?