thanks for your feed back
I will try
Does it make sens to set it back to 10 ?
I would answer it depends on the axis. Obviously yes for the pitch axis. @kd0aij is currently working in that direction. Gain are function of the lean angle assuming high lean angle means high airflow.
But for the roll, this is an other story because airspeed does not mean more airflow on the control surfaces.
Yes, roll should behave the same as a multi-rotor and be pretty constant independent of airflow. I was specifically talking about the pitch and yaw axis (while hovering).
This is my attempt to do just that for tailsitters. The thinking was that if the airspeed was high the plane mode gains work well, if the airspeed is very low then the copter mode gains work well. This just interpolates between the two based on airspeed. It seems to work well in SITL but not yet had a chance to try it in the wild.
This also allows us to use copter gains in forward flight modes for high alpha flying.
It needs a re-base but it would be great if you could give some feedback, Thanks
Hi!
I tried to use Autotune with my tiltrotor (4 motors, only front motors tilt). I have tested it several times with no success. The parameters for the autotune were changed (the aggressiveness from 0.075 to 0.05) but it made no difference. The first twitch (in roll) is always so hard (it reaches 50 degrees) that it destabilizes and starts losing altitude.
The weight of the plane is 9 kg and it runs T-motor 5208 340 KV with 18x8 APC propellers.
Here two logs with autotune (roll axis).
https://drive.google.com/open?id=1LicQuYhrODcgvwN1o-kFUlHV-YKBsvf-
https://drive.google.com/open?id=1jsfo99eGRz5GsbNH8IbvyDPUPp6hLfDl
I am having what I think is the same issue as Ismarg. Attached is a log. I tried a couple different settings tweaks in the field, such as lower aggressiveness and lower starting gains, but nothing helped. If there were a way to decrease the aggressiveness of the twitch itself, that’d likely be best.
It’s also worth nothing that I’m not sure how well the position hold aspect of it is working. Winds were 7-10mph by my guess, and the plane was getting moved around quite a bit.
I’ve been thinking about the issue, and the way the code is supposed to work. My best guess is that these heavy quadplanes have a high moment of inertia, which is playing havoc with the autotune. With each twitch, it’s trying to get to 20deg of rotation at 90deg/sec. The 20deg itself is probably fine, but the 90deg/sec is too fast. It causes the quadplane to overshoot, then destabilize when trying to correct.
I would change the code myself, but I am woefully inept at all things coding 
If anyone ekse wants to have a play with it and feels like sharing, my setup is on a Cube Black 
Hi guys,
I’m new with tailsitters plane.
i read some post in tailsitter thread, and i found someone mentioned Q_AUTOTUNE_AXES parameter.
my tailsitter already loaded with 3.6.0 arduplane (i think this is the latest firmware) , i found the QAUTOTUNE flight mode, but i cannot found the Q_AUTOTUNE_AXES . anybody knows what i’m missing to set up ?
Q_ENABLE already set to 1.
QAutotune is not yet available in stable release. You will have to flash master in order to use qautotune. You can get latest master binary from http://firmware.ardupilot.org/Plane/latest/
Thank you @nikhil ,
loaded the latest from the page, and i found the Q_AUTOTUNE_AXES.
where i can found the value description for this param by the way ?
the default is 7 which i assume it is for all axes.
This param is same as copter just q is added as prefix. You can find details at http://ardupilot.org/copter/docs/autotune.html#additional-notes
Hello all,
I am using VTOL Autotune.
Controller is Pixhawk 2.1/Here2/latest beta release.
Aircraft is a Parkzone Radian Pro with a T-motor 4in1 controller controlling the 4 T-motor motors.
So far so good.
I am tuning one axis and a time.
However, even after 5 minutes of flight I can’t seem to get the new PID values to save. (limit of my battery)
I thought I had it for pitch (cycles stopped), landed in autotune mode, and disarmed via the mavlink, but the PID values are unchanged. It’s going through 50+ cycles and is set to aggressive, but still no dice.
I dug around in the dataflash logs and found the P and D values the controller was converging to.
That is, I reviewed the logs and then looked at ATUN —> “RP” and “RD” values.
I assume it is safe to just manually input the RP and RD values that it was converging on?
I assume if I then autotune again, it will converge on the final result faster?
Is this how it works?
Thanks!
-Rob
you have to switch out of autotune once its complete then back again and disarm in autotune. If you have a log you can get the final values out.
Ahhh ok.
Thanks Peter.
That is counter to the instructions in the original post.
I will manually input the P and D values from my log files and may try autotune again.
Best,
Rob
Howdy. I’m going to give this a try tomorrow. To clarify mismatched directions: once Autotune is complete > land > switch out of autotune > switch back into autotune > disarm? Thanks!
This is completely wrong! Please do not make up misinformation. You do NOT have to switch out of autotune. Just land and dissarm
If you switch out of autotune, the new values will not be saved!!
Hey man, there is no need to be harsh here. I am sure Peter didn’t mean to misguide anyone.
I have just tested both methods in SITL and am pleased to report we are both right. The only requirement to saving the new gains is to be in Qautotune when you disarm. Switching into any other mode during or after the tune completes will NOT reset the gains. Once you switch back in to Qautotune it will pick up where it left off.
Maybe you should double check yourself before you accuse people of ‘making up misinformation’.
In copter switching out and back allows you to test out you new gains before you save them. Once the tune completes it goes back to the original gains and use them in any other modes. Then you can switch back and forth into AUTOTUNE to compare. I believe this is also true for the plane implementation.
@iampete When autotune is done, you are theoretically in Qloiter mode (as far as flight attitude goes). So I don`t see why you would need to switch out to test the new values (if the tune was a success) as far as I know. Just fly around (if you still have the battery left which is rarely the case with Quadplanes, for example yesterday we were doing only Yaw tune on a 12kg VTOL and it took 8mins to complete).
Anyway my point was that the (original/authors) instruction where correct and you were telling him they were wrong. Just gets people confused. As you can see from his reply.
When autotune is done (and reports “successful”), then land in the same mode (qautotune) and then disarm while in it. Then the new values are saved.
PS: I am not aware of what you mentioned as far as the way it works in copter. You might be right about that. I mean to comparison part. Someone would need to verify.
Well, yes, you’re both right!
Sadly, the code is wrong. This should be acting like ArduCopter in that
you should have to land in QAutoTune for the changes to take effect.
That explains the mix-up then. It also works the way Peters said, but it should not.