Usually my heli performs RTL correctly, but today it flew to the launch point and then loitered there. I waited about 30 seconds for it to start descending before switching to AltHld mode and landing manually. I see in another post that there used to be a parameter that tells how accurate the heading needs to be before the descent starts, but that doesn’t seem to exist in the current Arducopter version.
Here’s a link to the .bin file and here’s the .param file:
When viewing the log I see partial messages about “imbalance” but I can’t see what they’re refering to, and I don’t know if they’re significant. Can anyone help please?
Hi @abenn1
I believe this is due to the actual heading being off from the desired heading (the initial heading when the copter was armed). The threshold should be 2 degrees (if memory serves me right )-in your case it’s beyond the threshold while hovering above home point:
Thanks Ferrosan, by why would it be off? Compass calibration was fine tuned using MafFit. I suppose I can get around it by changing the RTL parameter (don’t remember its name) so that it doesn’t turn to face the launch direction.
I thought the tuning was okay because the tail responds correctly when I apply yaw – it doesn’t wag or shake, and doesn’t overshoot when I center the stick.
I see what you mean by the RATE.YDes vs RATE.Y graph, so I went back to the wiki to go through the Yaw Axis tuning and it doesn’t mention comparing those two: Instead it tells me to make a 90 degree turn and note RATE.YOut and RATE.Y, and to divide one by the other to give the desired ATC_RAT_YAW_FF value. Having noted the exact start and finish times of one turn I then viewed RATE.Yout and RATE.Y over the same period. RATE.Y varied from -44 to -69, nevertheless I noted its average, converted it to radians, and divided it into the average of RATE.Yout over the same period. Ignoring the negative sign, that gave me 0.35 for ATC_RAT_YAW_FF. This compares with the 0.024 value I’m currently using, but is within the 0 to 0.5 range suggested by MP so maybe I should use it.
But is there not an iterative way of tuning yaw by comparing RATE.YDes with RATE.Y – just like there is for pitch and roll?
I never use FF for yaw axis tuning. I use P and I (same value) and add D as much as necessary to get a rock solid “stopping” after fast rotations without overshoots or oscillations.
Of course you first need to guess the max accel the tail is capable of (ATC_ACCEL_Y_MAX), as this parameter is used to shape the response of the system. It needs some iterative flight testing.
Hi @abenn1 , you need to look at your rates matching and PID logging. Start with default P (I believe it’s 0.18) and set I to the same value.
Also, set H_COL2YAW to 0.5.
Managed 4 flights today and was able to check out tail behaviour using the parameters you suggest. I must admit that, as a ‘Sunday flyer’, the heli seemed to me to be flying very well (and still is), but today I did a couple of full-stick 360 pirouettes in each direction and noted that when centering the stick the tail overshot by maybe 15 degrees. The only problem is that when I look at the ATT.DesYaw vs ATT.Yaw log everything looks to be almost perfect. A log during which I did these pirouettes is attached. log_1_2024-10-6-15-03-28.bin - Google Drive
Anyway, following the wiki ‘Tuning ATC_RAT_YAW_D and ATC_RAT_YAW_P’ section I’ve increased ATC_RAT_YAW_P from 0.18 to 0.25 for next week’s flights to try and reduce the overshoot. I hope that’s a sensible action.
Hi @abenn1 , had a look at your log and you are on the right track now.
The overshoot you see, from the time when you center the yaw stick to the time the tail actually stops is mostly due to the input shaping being too soft (as you probably saw, the yaw des vs yaw measured match reasonably good) .
I would suggest to incrementally bump ATC_ACCEL_Y_MAX up to 130000 (steps of 25000 increment per time should be safe).
Keep P and I terms at 0.18 for now, 0.25 seems too much to me- we really need PID logging enabled!
Also set ATC_RAT_YAW_FLTD to 10 and please enable pid logging.
Thanks Ferrosan. I’ll roll P back to 18, and implement your other recommendations. I didn’t realise that I wasn’t logging PIDs
Edit: I’ve just done a 50-second test flight in my back yard with the new settings. First an anticlockwise 360 and then a clockwise 360, and visually the overshoot seemed to be much less than before. I’ll increase ATC_ACCEL_Y_MAX and test again tomorrow. Here’s the log, with PIDs included.
I noted that when I tried to increase ATC_ACCEL_Y_MAX to 75000 after today’s test I got an MP message that it was out of limits, so I’ve set it to 70000 for my next test.
I’ve test flown with Y_MAX = 70000 and then 95000, and can’t really see much difference, though it still overshoots a little bit. That doesn’t really concern me for I don’t usually do abrupt turns. Anyway here’s the log for a very short run at 95000 – I managed about 300 degrees rotation before landing heavily (my mistake), the hovered again and wagged the tail a couple of times.
Thanks again Ferrosan. I forgot about ATC_RAT_YAW_FF, so I’ll change that as well as _YAW_P/I. From this thread (and others in this forum) I’m beginning to understand how various parameters affect the flying. I’ll now go on and tune the tails of my other two helis – tuning pitch and roll by following the wiki instructions was easy, but for the tail the wiki had me lost, and the helis seemed to me to be flying okay on the default settings so I didn’t bother.
)-in your case it’s beyond the threshold while hovering above home point:
