I have finally put a Tri-Copter together in an attempt to get Tri's up to the same level of performance as the more common quad, Y6, X8, Hex and Octo. This is what I have put together:
based on these Hobbyking parts:
The tricopter has tuned up reasonably well using autotune and I feel happy with the performance so far. I didn't find the initial setup much more complicated compared to normal quad. I did find the first flight much more nerve racking because of the poor yaw performance during take off. I am interested to see if my confidence in the yaw performance improves now I have a reasonable yaw tune.
I am looking for feedback on what issues Tri-Copter pilots are having with Arducopter. Some of the issues I see are:
1. Dynamics of having the rear motor and propeller CG above the pivot point causes the opposite rotation to the thrust.
2. Roll, pitch, yaw and lift coupling potentially causing issues with auto-tune.
3. The frame type needs a stability patch to prioritize motor output.
4. There is no thrust adjustment on the rear motor based on angle.
5. Yaw auto-tune could be made more efficient by removing any D term or filter frequency tuning and going directly to Rate P tuning.
6. There may be improved motor mixing that does a better job at isolating the 4 control axis.
So let me know what you think I should be looking at that is particularly relevant to Tri-Copters.
Item 2 above is somewhere amongst the 240+ to-do items for Copter.
Yeh, I got that pm but I haven't had time to search through the folder for the autotune log. It would be great if you could point me to the correct file.
Can you tell me where you see that?
Thanks for pointing that out!!!
I don't think V-tail and A-tail copter fit into the category of tri's at all. I think they are simply quads with some changes to roll/pitch/yaw motor mixing. Can you tell me what you consider to be the issues with these types of frames?
It isn't possible to control the yaw of a tri without the servo. The most you can hope for is to land with uncontrolled yaw rather than crash completely. This is simply a product of the physics.
I would recommend switching to loiter and dropping the throttle stick to minimum to come down at a controlled rate and in the same location. If you want to maintain some ability to choose where you land I would set a loiter mode with simple or super simple that you can go to.
Thanks for the testing offer. I will take advantage of it before the next release :)
Sorry, maybe I forgot to mention it is one of the 3logs from 22nd of August. I cannot pinpoint one.myself as I am not sure which messages to look for. If you'll advise me What to look for I will go through all 3 and try to pinpoint the correct one.
I do 99% of my AP work with a plane. For the remaining 1% I need something that hovers and can be flown LOS as far away as possible. I tried quad, hexa and octo but was never satisfied. Wanted to build a tricopter to get better orientation to be able to fly further away. Quite soon I found reports about the tricopter problems. #1 in your list can be tamed by putting the pivot 'between' prop and motor or using a pusher instead of a tractor configuration, but the general 'problem' of a servo remains - especially in bigger sizes. Some guys exchanged the 'servo + motor' with 2 motors in 45° to get V or A-tail configuration, therefore I thought these are considered tricopters with four motors - but I don't care if its called a tri or a quad :-))).
At that time there was no support for A or V-tail and I confess I was too lazy to try to compile my own stuff, therefore I do the 1% with a heli :-).
Regarding issues - my experience till now is limited to watching others: All designs are a compromise and if you are not happy the way a quad turns you have to trade in some efficiency to get more yaw power.
I think one should try to find the right combination of front and tail motors/props.
What was stopping me till now was the software. I would love to have an easy way (= no compiling) to set the correct parameters for the 4 motors for my setup.
If you want me to try new software I could do it after finishing the frame.
The ability to define the roll,pitch,yaw,thrust factors for each motor or servo is on the to-do list but it's been there a while. It was requested a lot earlier in the project when we didn't support as many frame configurations, not too many people have asked for it recently.
I have issue 1 with my tricopter still, but if I recall correctly (as I haven't flown it for months now), it only occurs in stabilized modes.
I tried temporarily inverting the rear motor, and that solved the oscillations, but brought about a new problem: prop strikes during landing.
The semi-solution I now use is to lower STB_YAW_P to 1.5 in the advanced parameters list.
I think the preferred solution would be to use a dead band or some form of tunable attenuation of STB_YAW_P for minor deviations only, specially targeted at top mounted tricopter yaw motors.
Other than that, my RCExplorer style tricopter flies great with Arducopter firmware. Autotune does a good job too, although the stabilize PIDs are way too high for my preference, especially noticeable when switching from acro to stabilize mode causing a stabilize jolt, so I reduce these after tuning.
I prefer hard 9 inch props though (such as Graupner E-Prop and HQ props) on 4S with 900kv T-Motor motors. That way less vibrations get into the video feed and flight controller.
This is a video demonstrating the slow tail wagging issue :
If flying 3rd person view, then it's not that annoying, but if flying 1st person view, then it becomes very nauseating.
This is a video after reducing STB_YAW_P a lot:
turdsurfer, I assume you are talking about firmware 3.2.1 or earlier as on 3.3 it is almost impossible to control yaw with yaw stab below 3.0. on AC 3.3 it seems that it takes a bit of time to build up the turning momentum.
That's right, 3.2.1. I haven't tried 3.3 yet, but from the behaviour you're describing, are you not mixing STB_YAW_P up with RATE_YAW_P?
It's my assumption that the STB_YAW_P is responsible for maintaining a fixed heading while in any mode with stabilization, and that RATE_YAW_P is responsible for the yaw rate when you deflect a transmitter stick.