I’m experimenting with a TriPlane, which I call it a TriPlane instead of a TriCopter because it’s kind of a hybrid. The small parawing airfoils produce about 50% of the lift to keep the aircraft airborne @ 9m/s, which enhances flight time.
The thing flies more like an airplane in horizontal flight than a 'copter. But I’m using the Copter firmware to fly it, without tilting the wing motors. I just have the AoA of the airfoils set so it flies at 9 m/s and leaves enough load on the wing motors to effectively control roll. The aircraft is about 3 ft wingspan and weighs 1,716gr.
The problem is that it crabs into the wind like a conventional fixed-wing when flying waypoint miissions. I tried changing the wp_yaw_behavior param, and enabling and disabling compass_use with no effect. When it crosses a waypoint it tries to either point to the GPS course, or next waypoint, but then it crabs. If I manually hold the corrective amount of rudder then it will yaw to the desired heading and bank or “slip” into the crosswind. It’s probably more power efficient for it to fly in a crab, but for some aerial survey work I need it to hold a yaw angle to the next waypoint.
I initially flew it with an APM2.8 and thought, well, maybe the APM is running out of CPU to try to constantly correct it. So I put a Pixhawk in it with Copter 3.4 and still got the same problem. And the logs don’t show any significant deviation from desired yaw to actual. As it crosses a waypoint it momentarily points at the next waypoint, then the yaw drifts back into a crab to compensate for crosswind. Flying into the wind aloft, or downwind, it points perfectly. Only with crosswinds does the problem exist.
The wheelbase prop shaft to propshaft on the wing motors is 850mm. From either wing motor to the tail motor it is 900mm. The FC is not exactly at the CG of the aircraft - it’s slightly forward - but I didn’t think that should cause a problem. If I use a higher flight speed like 15m/s then it crabs less. I can set a ROI and it will point at and circle that perfectly. It’s just on cross-country legs of a waypoint mission where it does this.
If any of the guru’s have any ideas, as to whether this is completely normal behavior, or there is a problem, it would be fun to hear them.
Replying to my own post. But I made another cross-country test flight and determined (I think) that it’s a problem with the trim on the aircraft. It seems to want to crab right and never left. And crosswind makes it worse. The logs from the latest flight do show a discrepancy between desired yaw and actual.
So I think I need to spend some time tuning the airfoils, measuring and making sure I have the same AoA side to side, and trim the aircraft so it flies straight and true before assuming it’s a problem in the software. Again, more like flying and tuning a fixed wing than a multi-rotor in horizontal flight.
Well, a final update on this problem with the Tri. I seems ArduCopter, at least here, does not aggressively track a yaw heading on waypoint flights. It seems to aggressively adjust the yaw as it passes a waypoint, and from that point to the next one it’s totally “loose”. Other people have noted the problem, perhaps with a multirotor aircraft like mine that may not be aerodynamically “balanced”.
I’ve tried different settings on anything that has to do with yaw, including the ATC_ params, and none seem to do much to alleviate the problem, neither with APM, nor with Pixhawk. Which is kind of weird because the DJI and LibrePilot controllers I’ve flown will track a compass heading with a multirotor like it’s tied with a rope on waypoint flights. And my Tri has way more positive yaw control and response in any of the manual flight modes than a quad or hex does.
What finally “fixed” it here was to put a vertical stab on the aircraft. It will still fly sideways at very slow flight speeds without fighting the tail too much. But on the final flight test, flying a mission at sundown tonight the yaw now tracks the next waypoint with just a slight amount of crabbing into the 12kt crosswind that I tested it in. Instead of crabbing at a 30 degree angle, with the vertical stab it’s down to about 10 degrees, which is acceptable. But it still seems to me that ArduCopter should more aggressively track that compass heading. Instead, it seems like the pilot has complete control of yaw in Auto Mode, and if the pilot doesn’t control it it drifts where ever it wants. Even using Condition Yaw, it will adjust the heading to what is set when it executes the command, but after that it’s “loose” and drifts again. However, if I set an ROI, it will track that perfectly.
No responses from the community, but I guess very few fly Tri’s. I’ll post the final solution as to what fixed it - the yaw rate controller.
The tail servo, operating at much lower update rate than the ESC’s, requires much higher settings for yaw rate than a quad or hex et al. I had tried auto tune with the Pixhawk but it didn’t work - the aircraft was totally unflyable with the auto tuned PID’s. So it was all manual tuning, and lots of flight testing to see what happens.
The roll and pitch are really not a problem to tune. The values for a quad about this same size (850mm) works well, although I ended up using slight higher values for pitch than for roll.
The yaw is the big one that a lot of people seem to have problems with on a Tri. My rule of thumb (now from experience) is that if you take off and the aircraft spins either direction, without using trim or rudder input on the transmitter, the yaw rate PID’s are not high enough. I started turning up the rate yaw P value and finally got the aircraft to hold a heading at 0.62 without using any trim. I turned it up as high as 1.0 and got a slight amount of tail wobble. I ended up at:
rate yaw P: 0.83
rate yaw I: 0.083
Now, I think it’s best to always dial in a little derivative gain if you can, without getting any slow speed oscillations so I set that at 0.004 with no adverse effects.
The rate yaw imax I set at 8.
The aircraft now holds a heading like it’s on rails on a waypoint flight thru turbulence and gusty crosswinds. I took the vert stab off, as it was no longer needed. I had a crash with the Pixhawk during an autotune adventure. When I replaced the parawings, I made them with twice as much chord as the original pictured above - the aircraft now cruises at 9 m/s on 34% throttle. I do not recommend using autotune with a tri - at least not with my setup.
The published range for ATC_ANG_Yaw_P is 3.0-6.0. I ended up using 2.0 because the damn thing spins at ~700 deg/sec at 3.0 with a 1455 prop on the tail rotor.
All my yaw PID’s are outside the published acceptable ranges in the current docs for Copter 3.4. But that’ what it took to get it to fly and track a heading.
Thanks for posting your solution.
Your copter/plane is really interesting.
You should fly a route with and without the wings (same speed and everything other than the wings), and compare the power used while cruising. I’d like to know how much more efficient it is.
I haven’t tried that. I kind of designed it to use the wings. The aircraft is all 6061 T4 aluminum construction and the parawings are riveted to the main spar. So they’re not that easy to get off without drilling rivets. The new wings I built after the crash are 110mm chord at the root and 75mm chord at the tip. The span is 730mm. So the wing loading is quite high, which was by design so the wing motors have enough load to effectively control roll. I’m using T-motors with 1555 props on the wings, and a Turnigy Elite with a 1455 on the tail. I had Turnigy’s on the wings with 1455’s. During the rebuild I put the T-motors on with the bigger props and that, along with more chord on the wings reduced the cruise throttle in level forward flight but I don’t know yet by how much until I make some more test flights.
The best flight I’ve gotten in about 10 hours of testing is 52 min, 17 seconds in constant-altitude flight at a steady 9 m/s ground speed. And controlling yaw manually using FPV, up until now.
The only problem I have with yaw on missions yet is that the default waypoint yaw behavior does not work. I’ve tried to make it face the next waypoint, follow GPS course, and neither one works. It stays flying one direction if I don’t manually input rudder to correct the heading, or use Condition_Yaw in the mission plan.
I think that problem has something to do with the fact that the tail servo is RC7 out and TriCopter support in ArduCopter does not seem to be as good as for quads et al. When I get some time I’m going to have to take a look at the code for Tri’s and see what’s wrong there. I’ve tried setting the RC7_Function to rudder and several other things, and nothing made it use the default waypoint yaw behavior param (yet).
Hello Chris,
I can’t imagine that the code or your construction don’t have the authority to hold yaw.
You should check if the copter “want” to point to the next waypoint. In MP the yellow(?) line should point to the next waypoint.
Maybe your radio sends always a small yaw signal. Can you check that your radio don’t send anything more than RCX_MID ± deadband?
Maybe a recalibration or bigger deadband for yaw helps.
Sebastian
Hmm… I never thought of that. My RC4 deadband is indeed zero, for some reason. I’ll grab the SD card out of it this morning and have a look at the logs from my last test flight.
Thanks for that suggestion, Sebastian!
Test Flight Update:
I don’t know if I changed the deadband settings, or if it was that way out of the box, but my RC4_DZ was set to 0 and the RC7_DZ (tail servo on a Tri) was set to 40. I reversed those two and now it works fine, has much crisper yaw, and I actually turned down the rate controller PID’s a bit to:
P: 0.45
I: 0.055
D:0.002
IMax: 10
The Stabilize Yaw P I I left at 2.0, as the higher I setting somewhat dampens the P anyway.
Although I got a problem with the tilt and roll motor gain on my gimbal in the cold weather, it flies absolutely perfectly now:
