This is a discussion re the ArduCopter-3.1 AutoTune feature. A place for people to report successes and failures, ask questions and get answers.
The AutoTune wiki page is here.
You need to be a member of diydrones to add comments!
This reply was deleted.
Replies
Hi Patrick,
Sorry about your crash. I can see from your logs that at the time of the crash the copter was using the normal stabilized pids and was not doing any tests. This means the copter crashed in the equivalent of stabilized mode. Unfortunately you don't have output logging turned on so I can't get any more information from the logs. However based on your desired and measured roll pitch and yaw angles it looks like you lost your front right prop, motor, or esc.
Sorry for your crash!!
Hi Leonardhall,
Thanks a lot for your answer. Props were still attached to their motors, undamaged (damage was restricted to 2 broken arms and their respective frame clamps). I could even arm the copter and throttle-up the motors again after the crash.
I can see at the logs that autotune was interrupted by roll and pitch inputs, and after that both Pitch and Roll start diverting from their respective desired values - which at that moment were close to 0. In other words, motors an ESC were almost in hovering effort - far from the demands of autotune.
One question: during the roll tuning, autotune increases RDGain up to 0.02, and the same thing happens during the pitch tuning. Is this value the top of RDGain range, meaning a limitation for larger copters?
Thanks,
Patrick
Hi Patrick,
Yeh, we want to minimise the danger in the case that someone gets a poor tune. As we become more confident that autotune is doing all the right things and that we understand how it fails we relax these limits.
Hi Leonardthall,
I found the logs from the previous occurrence of the same issue.
There is also a video from the moment the copter went crazy during auto-tune. I was lucky that day and could regain control of it.
https://youtu.be/DD-y6ltJGAs
leonardthall,
getting back to autotune overshooting on tricopters,
attached is a smallish tri log I tried to autotune today in the morning.
the resulted PIDs are really off. I would greatly appreciate you figuring out why autotune seems to miss tricopters.
On my side I will do whatever it is necessary to help you.
Thank you.
Conveniently in the post above your post shows where those values go. RPGain goes in the P and I values for the Rate box for either roll or pitch depending which axis it was working on (take the final values before it switched to the next axis). I know - identical values for P and I but that's just how autotune does it.
The RDGain value goes in the D term.
The SPGain you want to copy to the "Stabilize (roll or pitch) P" value higher up on the screen (top row of boxes).
That's it. Those are the only values that autotune messes with. So if you copy those values in now it should get you closer to "tuned". Also it should tune the first axis much faster. Be aware that many people want a less twitchy, less reactive, less responsive result than autotune provides. So you might want to lower your P and I values a bit manually if you don't like the responsiveness.
Is there a handout for reducing autotuned values for Coaxial copters (Y6B). Mabe reduce some values to xx percent do get near to the optimum?
I have APM but connected to 6 channel receiver. Radio 9XR.
I want to use the autotune but mission planner only access on channel 7/8.
Currently have Channel 5 for the flight modes.
Any way to setup APM connections, 6 channel receiver and the mixers on the 9XR to temporarily use the autotune feature from channel 7?
Thanks
Can't you take the connection from your receiver's ch6 and put it to the APM's ch7 input?
Which connection spot is the Channel 7 input. I am actually using a Crius AIOP which has Aux 1-4 inputs.
Normally, channel 5 for the flight modes are connected to the aux 1 and the channel 6 to the aux 2. I guess it would be aux 3.
Thanks
-
13
-
14
-
15
-
16
-
17
of 55 Next