[Kevin_Erik]

The overall weight vs the thrust available is too low. Furthermore the servo is most likely too high of a load that the 1S can support. Its why i recommended going 2S, 7500-10000kv motors and 3” propellers. That setup should fly 3-6 minutes depending on hardware and combined weight. My best build was < 70 grams with LiPo and camera.

[Kevin_Erik]

Yeah several have.

[Kevin_Erik]

While dRonin will work, you’ll need the right firmware to be able to use the Matek-F405. If you look within the forums there is a thread setup specifically for this: https://rcexplorer.se/forums/topic/dronin-installers/

That being said, Betaflight 4.1 or > will work just fine. Thus, if you continue to have problems, you may want to give that a try.

[Kevin_Erik]

Its cool, Davids gear is great.

However, your going to find it harder and harder as time goes on to find replacement parts or tech help. For that matter Tricopters are likely to become rarefied as fewer people fly due to the recent FAA regulations making it much harder to keep the larger / heavier Tri’s airborne. Which is in part why i designed the Whirlygig Tricopters to be small enough to fly anywhere.

***Just a few points on Yaw tuning***

– Filtering can make or break a Tricopter tune. Too much filtering adds delay that compounds any Yaw issues you may be experiencing. Ideally, you want as little filtering as possible, which is why data-logging is so helpful to figure out what is really needed. Then again, if all else fails, switch to Betaflight 4.1 (or higher) as the motor filtering is awesome-sauce!

– Servos response time can be drastically improved by increasing the input Voltage. While most Tricopters use 6V, I suggest using 7V if your external BEC and Servo can manage it. (MFR recommendations) Case in point, I run 7.4V on my Whirlygig Tricopters and its incredible just how much better it became.

Note: A word of warning, never, never and i mean never, power a Servo from the Flight-Controllers on-board 5V BEC. Not unless you enjoy replacing the Controller and Servo often.

– Dterm is designed to detect and prevent P overshoot yet requires significant filtering / processing to achieve. (Thus allowing P to be raised higher) This is why the response delay (lag) can be so detrimental to Yaw. In my experience, its best to fully tune the Tricopter’s Yaw is by using step response mapping (P & I) and then add as little Dterm (if any) to help flatten out the response. Obviously, the newer firmware’s handle this much better and thus experience much less delay as a result.

Note: The worst ESC on the market is still 100 times faster than the best Servo. This is why Dterm is great for quads but not for Tricopters.

– Too high of a Yaw P or Iterm results in Servo overshoot. In a sense the Servo will rotate farther than needed, resulting in the Flight-Controller making a correction, then another and another etc. This can be seen as fast Tail wag (oscillation) and can occur both in flight and on the bench.

– Too low of a Yaw P and Iterm results in the copter not Yawing enough. Thus the Flight Controller may need to Yaw again and again to get close to its Target position. (Think slow wag) Obviously, this takes time and will cause the Yaw response to both feel weak and mushy. This can also cause the copter to lose its orientation lock on its current position.

– Pterm sets how aggressive the Servo response will be. Ideally, you want the Servo to “snap” into position as soon as an RC input is given, hopefully without overshooting (wag). Best way to test this is the set your I-term to 5-10 and D-Term to 0, then hover over one spot while flicking the Yaw left and right. the copter should feel very responsive but not wag. If not, increase the P-term until it snaps or decrease it until wag is gone.

– Iterm is meant to keep the copters orientation locked until an RC input is given. Thus in a windy situation, the copter may float away some but still face the same direction. Ideally you’ll want to increase Iterm a few points at a time until you achieved this “Locked” state. Then go flying fast / strait lines to see if it still holds orientation. Here again, slowly add Iterm until you can throttle up hard with minimal Yaw deviation. Be aware that as you increase Iterm that you may need to reduce Pterm to prevent wag.

– During tuning it is advisable to disable all functions that can automatically retard or amplify your PID’s in flight. These functions / algorithms can make the copters behavior seam erratic and thus make it very hard to tune properly. Stuff like Anti-Gravity, TPA and the like should all be disabled until your happy with the tune.

– Once the Yaw is good, tune your Roll and Pitch just like you would a quadcopter.

[Kevin_Erik]

@Mathew

Best way to see whats going on is to use a Datalogger then create a Step-Response plot. (PID Toolkit or Toolbox) A good example is the Nano-Whirlygig i tuned just recently: https://rotorbuilds.com/build/21545

This is using Betaflight 4.1.2 and motor filtering on an F4 flight controller. Scroll down through the images on that link and you’ll see the Step-Response plot for the copter. Ideally the plot should have a sharp rise and then flatten out at “1”. This indicates that the copters response to input matches what the Gyro senses. In other words, there is minimal delay or overshoot.

Anyways for the older Triflight theres a command called “thrust factor” that manages the copters Yaw response as throttle is applied. Increasing this value increases the amount of counter torque keeping the copters orientation locked in as throttle increases. That being said, the same can also be done with Betaflight 4.1 (or greater) by managing things such as TPA as well as the other factors that manipulate I gain. Unfortunately, you’d have to upgrade the flight-controller to an F4 to use the current version of BF. While that sounds daunting, the filter improvements alone make it 100% worth doing. (Motor filtering is awesome)

Be aware, that D-term and Yaw don’t work well together due to the D-term filter delay making the already slow Servo even slower. This delay causes undershoot, which is where the Servo will continually hunt to reach the correct position but is unable due to lag. Effectively the control inputs are coming faster than the Servo can possibly keep up, making the Yaw feel mushy and unresponsive.

[Kevin_Erik]

@Stuart

Considering the state of things on the forums, you’ve a few choices.
1) Read through the old posts here as most of what you’ll want has already been written about.
2) Post / Read the threads on RCGroups.
3) Goto an RC meet / fly, thats local to you

No matter what you choose, you’d need to teach yourself whats needed. After all Tricopters are not for those afraid of learning the how-to skills, no matter your age. Now if it were as simple as jumping in a car to come help you I’m sure you’d of managed this by now. (BTW i’m in Germany, previously a UK man from Crew)

[Kevin_Erik]

With 1-S you’ll need a step-up BEC or risk browning out (burning up) your FC / Servo. Point being that most of the micro sized FC-BEC’s are only rated for 0.5 to 1.5 amps continuous draw yet the Servo can draw as much as 3-6 amps due to “potential” stall-current conditions. IMO its better to run 2-S and power directly from the LiPo with 100uF 16V cap in parallel. (Noise suppression) Keep in mind that the little Bluebird Servo can very easily handle 7.4V so 2-S is perfect. Besides at higher voltages (6+) the Servo response is faster and with significantly more torque.

Those 1103 motors sound reasonable and it maybe possible to run those 2S with two-bladed 3″ props.
My favorite 1103 motors are made by Xing as the BetaFPV motors have really short wire lengths. Furthermore I’ve found that the BetaFPV wiring isn’t very robust and can come unbound from the hub due to the tails Yaw action.

Xing 1103 https://www.iflight-rc.com/index.php?route=product/product&path=245&product_id=997

Here is my most recent 3” 2S build at 54 grams https://rotorbuilds.com/build/21545

[Kevin_Erik]

Stick a micro camera on that and take it outside!

Question: What PID’s did you end up using?

[Kevin_Erik]

All i gota say is enjoy the first flight!

Guessing your flight weight with cam / batt to be 70-73 grams. Please post a flight video.

-Kevin

[Kevin_Erik]

I did design a pair but never printed it.

Consider that a 5” set i had made from SLI Nylon was really $$$. Worse yet, the prints were about 40 grams each. Scale this up to a 6” design and the mass would easily be 60 grams per duct! Sure i could of made them lighter but they’d break from the slightest impact. The resulting duct-wall collision with the propeller would cause the propeller to implode. Thus the copter would fall and crash badly, wrecking the other Ducts in the process.

Now consider a 3” duct has about 8-15 grams and you’ll soon realize that this doesn’t scale up well with the copter size.

My conclusion: Prop-Guards are better than Ducts.

Justification(s)
-Lighter in many cases, 50%
So.
-Much cheeper to print.
-Less complex
-Can still reduce prop-tip vortices if designed right.

[Kevin_Erik]

As i stated earlier, the Matek FCHUB-W is the best-thing going. Not only can you run the Servo up to 7.2V via header pins (no need to solder the servo on), you have 12 & 5 available too. (All filtered) The FCHUB-W connects to the FC using a ribbon cable which makes wiring a snap. Only issue is that there are only two motor-voltage pads on the card so you’ll need to double up wiring on one.

But yeah, building a larger copter takes a bit of planning to make life easier. What I did was attach all my wiring to the FCHUB and FC first, then drop everything down to the ESC’s. Thus while the hardware was frame mounted, i could ensure that I had the ideal wire lengths. Furthermore, the wires don’t need to have a large AWG value if how you fly isn’t drawing a lot of current. For a 35A ESC you’ll need 18AWG at max current draw but realistically you could run 20AWG as odds are that you’d never pull max current on a long range flight. Even of you did, the line losses would be so small as to be largely unnoticeable and so short in duration that the wires wouldn’t even get warm. The upside of this would be that you’d save a bit of weight, improve handling and increase the flight duration a bit too.

16AWG Wire – 80A
18AWG Wire – 50A
20AWG Wire – 30A
22AWG Wire – 24A
24AWG Wire – 20A

[Kevin_Erik]

If all of the ESC’s have external caps to filter noise, then the camera should be fine. A 220uf 50v radial-capacitor (low ESR) works great across an ESC and is fairly small to boot.

@Billyd Question, Which BEC are use using? The Matek FCHUB-W is awesome-sauce on so many levels. Sure its designed primarily for Wings but its the best BEC out there for a full sized Tricopter.

http://www.mateksys.com/?portfolio=fchub-w

[Kevin_Erik]

IMO OSD isn’t really needed once Telemetry has been properly setup. With the right Lua scripts your Taranis can provide all the in-flight data needed as well as audible warnings. Furthermore when your video drops out, your Telemetry will still being going strong. Which is especially helpful when trying to recover a downed craft.

Beyond all of that, the OSD as it stands, is an unreliable and outdated system. Which only adds to the wiring complexity and craft weight, while further degrading the clarity of the received image. Why a “single” telemetry line from the FC to VTX cant be used, fails all sense of reason. Its 100% possible to pass data to the VTX. Then either overlay on-top of the primary image or piggyback the the telemetry to the goggles directly.

[Kevin_Erik]

@yumemi5k When Arming, the Flight Controller looks at it’s current orientation to see that its 1st safe to fly and then zeros it’s internal Gyro / ACC. DRonin does this as well and can be set to take a much longer sample upon Arming. (not that its helped much) Despite the differences between the firmwares, both have the same problems when it comes to Level-drift. Stands to reason, that with dRonin coming from an earlier BF fork, this is only to be expected. Yeah, sure the the Horizon is expected to “drift over time” but what i was seeing was an almost immediate shift in the Horizon. Soon as I’d launch the copter, it would be at 5-10 degrees Roll , thus requiring significant trim just to be manageable. Despite that, the copter flew really great…

When i first started with Tri’s, I spent allot of time dealing with level related issues. Without much relief until I starting spending time manually leveling the copter prior to launch. Granted this was with David’s F3 Tri-Mini but the software today is still basically the same beyond the vastly improved filters. Thus I’m pretty sure that if i reinstalled BF 3.9 (4.0 on has dropped F3 support) that all the Auto-Level Gremlins would still be there. Keep in mind that in the last two years, I’ve changed out the Mini’s FC, motors and ESC’s.

Side Note: I’m just really pleased that my latest Tri’s appear to behave much better in Horizon. Yet I do most fly most in Acro so this isn’t so much of a concern now days.

[Kevin_Erik]

This 100% sounds like the same issue I’ve seen in Betaflight.

Case-in-point, arming the copter while in an slightly unleveled state will result in the craft drifting horribly while using any of the self-level modes. (Gets worse over time)

Obviously, the way to resolve this is to ensure that the craft is level before arming. To this effect, I’ve used everything from my iPhone to a micro spirit level. On a few occasions, the BF accelerometer trim can help if manual leveling won’t. This however assumes that the direction of drift is consistent from one flight to the next.

IMO The bigger picture is that Auto-Leveling modes aren’t really used much in “sport” flying. Thus the leveling features don’t get the scripting attention they probably should. Just watch any FPV how-to video and the first thing they tell you is to learn Acro as Auto-Level teaches you bad habbits ect. Yet for a LR craft, Acro really isn’t that practical once out of LOS.

Edit (1): It was mentioned on another forum (some time ago) that auto leveling may not be compensating for changes in vBat. Thus suggesting why the leveling errors get worse the more the copter is flown.

Edit (2): Oscar Liang has a small post on the subject suggesting a filtering adjustment for BF. https://oscarliang.com/drifting-problem-angle-horizon-mode-betaflight/ Its possible that there’s something similar within iNav.

[Author]

Posts