Hi everyone,
It’s been a while since I last needed community help, so first a quick project overview: I’m working on this for a company and unfortunately can’t share photos/videos, but logs and parameter files are fine to share and should hopefully be enough for analysis.
Aircraft: Fully custom-built helicopter, turbine powered, 3-blade main rotor (3m diameter), 2-blade tail rotor (0.7m diameter), empty weight (no payload) 25kg, CCW main rotor (left-hand rotation). Designed to fly empty, with 40kg payload, and with 60kg payload.
Structural note: The airframe is built light rather than ultra-stiff. The chassis has a bit of flex in roll, and the tail boom isn’t fully rigidly supported (it can give slightly). The payload itself is mounted rigidly to the landing gear (and that will stay that way), and the landing gear itself is very rigidly attached to the chassis — the flex we have is only in the chassis structure itself, nowhere else. Worth mentioning since it may be relevant to tuning behavior/vibration characteristics.
This airframe has flown successfully on other projects before (with different electronics), so we’re fairly confident mechanical issues can be ruled out.
Current setup: Pixhawk Cube Orange with Here GPS 4, recently installed. I’ve done several test flights since installation in ACRO, LOITER, and AUTO modes. The AUTO mission is always a 200m x 18m rectangle flown at 20-40m altitude, cruise speed typically 12-18 m/s.
I currently have two separate problem areas I’m stuck on:
Problem 1: Cornering in AUTO — stuck at ~3 m/s regardless of parameters tested
The helicopter always brakes very hard in the corners, down to 2.5-3.5 m/s, and flies the corners quite “boxy”/sharp-cornered rather than smooth. Ideally we’d like either a smooth 180° turn, or two 90° turns with a large enough radius that they effectively merge into one continuous arc. No matter what I change, the outcome stays essentially identical — sharp, slow, “hover-like” corners.
Important constraint: The 18m spacing between the corner waypoints is fixed by the mission requirements this aircraft is being built for — we cannot simply widen that leg to get a gentler geometric turn. Any solution needs to work within that fixed 18m spacing.
Parameters tested so far (individually and in combination):
-
WPNAV_ACCEL: 100–350 cm/s² -
WPNAV_JERK: 1–5 m/s³ -
WPNAV_ACCEL_C: 200–600 cm/s² -
WPNAV_RADIUS: 1000–3000 cm -
WPNAV_SPEED: 7.5–18 m/s
None of these combinations changed the outcome in any noticeable way.
Lean angle: ANGLE_MAX is set to 30°, but the aircraft never comes close to using it — peak lean in corners is around 10°, at most.
I also tried SPLINE waypoints in Mission Planner, but the closer together the waypoints are, the slower it seems to loiter/crawl through them, not faster.
The flight logs I’ll attach are the fastest/smoothest corners I’ve managed to get so far — I genuinely don’t know what is actually limiting the corner speed at this point. Logically I would have expected WPNAV_RADIUS and WPNAV_ACCEL_C to be the relevant levers, but since WPNAV_ACCEL_C produced zero visible change, I started wondering whether that parameter has effectively become non-functional (the Mission Planner description field for it also appears to be missing/blank), which is why I then tested with WPNAV_ACCEL instead (always raising jerk proportionally so the accel ramp works out to about 1 second).
Question: Given the fixed 18m waypoint spacing, what is actually the binding constraint here? Is there some other parameter or interaction I’m missing?
Problem 2: General attitude tuning status, and how payload weight affects it
Baseline: 40kg payload — looks/flies good, but feedback welcome
I’d really appreciate expert input on the tuning here. The 40kg-payload flight (log attached) looks visually very good — flies stable and does what it’s commanded to do. The AUTO mission also looks good; the tail maybe overshoots slightly at the corners, but nothing dramatic. In LOITER it tracks the stick well, same in ACRO.
Tuning approach used so far (per the ArduPilot Heli tuning docs):
-
Rate (RAT) PIDs: D increased until shake onset, then set to 50% of that value. P increased until shake onset, then set to 50%. FF raised significantly to get the aircraft to track the stick tightly — with too-low FF we saw toilet-bowling in LOITER, which went away once FF was raised.
-
I gains have not been re-raised yet — early on the swashplate oscillated strongly, so all PIDs were cut back significantly, and I haven’t revisited/increased I since. Planning to do this in upcoming test flights.
-
Tail (yaw): same approach — P raised to shake onset then backed off, D likewise. Not sure how to approach I here. FF isn’t really needed for yaw per the docs, as I understand it.
All of the above was tuned at 40kg payload and then test-flown as shown in the attached log.
60kg payload — noticeably worse, especially the tail
After increasing payload to 60kg (same gains, not re-tuned): the aircraft still flies, but the tail in particular behaves somewhat erratically — even though we’re not yet at a power/performance limit. It doesn’t track the stick well; subjectively, for the same stick input it seems to yaw sometimes faster, sometimes slower, inconsistently. In the AUTO mission, the tail overshoots badly at the corners — I’d estimate 30-40°, before steering back.
That said, it does still fly the AUTO mission overall.
In LOITER, larger/faster stick inputs cause it to start oscillating — and looking at the log, the acceleration values in the position controller clearly don’t track well together and start oscillating too. I tested both higher and lower PSC_POSXY_P — both were worse. Also higher/lower PSC_VELXY_P, _I, and _D, though I had to stop that testing early due to time constraints. PSC_VELXY_D = 0.2 caused strong, fast shaking; PSC_VELXY_P ±20% changed things somewhat, but it never became properly stable either way. I suspect I might be looking in the wrong place here.
Question: It’s possible/likely that separate RAT and POS controller gain sets are needed for empty / 40kg / 60kg configurations, switched depending on payload — is that the right conclusion, or is there something more fundamental I should be addressing first?
Ideally, a single gain set that covers all three weight configurations reasonably well would obviously be preferable to us — simpler operationally, one less thing to get wrong before a flight. If that’s genuinely not realistic given the weight range involved, then swapping parameter sets between payload changes is something we can live with — but if there’s a way to avoid that, we’d much rather go that route. Otherwise, of course, we’ll need to tune separate parameter sets for each configuration — worth mentioning that we’re working under fairly tight time constraints to get this project flight-ready, so any pointers that help us avoid unnecessary extra tuning rounds are very much appreciated.
Very much looking forward to your thoughts — any feedback or pointers to improve the flight behavior are welcome, on either problem.
Logs + Parameter File:
