Forum Replies Created
It was removed by mistake, repo has been corrected…..
Here you are….
Like I said, quick bench test only, so go over it carefully before flying. I’ll try to get out with it too, even if it’s only some PID tuning work in the backyard.
It was relatively easy to merge 2.4 with 2.3. I’ve got it loaded on my TriLR and it behaves on the bench. I did do a diff/save before reloading the firmware, then did a load/save of the old configuration after loading.
Don’t know if I’ll have time to fly it this weekend, you guys want the firmware?
Nope, leave the yaw P as it is. The whole concept here is to get the best tail behavior at hover. Then the dynamic yaw gains can be used, if needed, to tune the tail further on punch outs or throttle cuts. That’s the whole point of storing the hover throttle setting, so dynamic yaw knows where to apply the max gain and the min gain. They default to 100 (which is 1 scaled at 100), so at this setting the yaw P gain is applied with no scaling across the entire throttle range. Just coincidence they matched your yaw P. Pretty cool, glad it’s worked out.
BTW – Please post all your PID settings so others can use them as a starting point. Thanks!
No flight video, but a flight picture……it flies very well!
I should add I re-worked the code one last time, went from triflight 0.7 to a customized version of triflight 0.5, works much better.
On my box stock TriLR, I did not have to reverse anything FWIW.
Yes, if you’re using the iNav recommended motor layout, you can leave the mixer alone and the tri_tail_motor_index at the default of zero, which means motor #1 is the tail motor.
Well here it is. It’s been quickly flown on a poorly tuned TriLR, but the tail did not oscillate wildly or drift randomly, and it completed an in air tail tune with reasonable numbers for both the thrustfactor and hover throttle. Some things to note:
1)Triflight is now implemented as a feature, and as such must be enabled or disabled as desired.
2)In the initial setup, the dynamic_yaw_hover_throttle is set to 0, and with this value, the dynamic yaw function is disabled. The dynamic yaw gains default to 1. When the in air tail tune is complete, this value will be populated with the value appropriate for the motor protocol you are using. It varies greatly from the older PWM protocols to the newer digital protocols, so there was no way to make a default other than 0, and use that value to disable dynamic yaw comp. Once populated, dynamic yaw still has no effect unless you’ve change the default gains values from 1. Remember the values are entered as scaled integers.
3)There’s a new term, tri_tail_motor_index. This tells the algorithm which channel is the tail motor. If you’re using the standard wiring convention, you can leave this at is default value, 0. If you’re motor wiring order is different you will need to change this to the 0 based value of your motor channel, and modify the mixer constants accordingly. Must users won’t mess with this, but I needed it for my builds, as I didn’t feel like re-wiring the fleet. My TriLR requires motors 1 and 3 to be swapped, so I set this to a value of 2 (zero based).
It was a short test flight in the backyard this morning, too cold and getting too windy to do much else. Only flew in the acro mode and in air tail tune, then quit. When initially setting up, start from a clean slate, reset your existing settings. With regard to the 0.7 version, some parameters have been deleted and some added, so the setting reset is the best way to make sure everything starts from where it belongs settings wise.
I’ve built two targets, KAKUTEF4V2TRI and KAKUTEF7HDV. Used both for bench testing, and the F4 for the flight testing.
Repo is at:
Hex files for the two targets I know work are attached.
There’s also a version for BetaFlight 4.1.1. Repo at:
Unified target builds attached, and the modified config files I used for testing are there too. For other targets, you’ll have to find the appropriate config file.
EDIT: file size restrictions won’t let me attach the compressed files as is, so I’ve trimmed them down to just the files necessary for the KakuteF4V2…….
I’ve made some progress. I have v.5 running under BetaFlight 4.1.1, and have flown it on a small tricopter indoors (Kevin’s Whirlygig). It’s behaving nicely, although there is one change I want to make wrt to setting it up.
Getting v.5 running on iNav 2.3 isn’t quite there yet. The code builds and runs, but the tail servo won’t move. The servo icon in the configurator shows a response to yaw motion, and to different thrust factor settings, so triflight itself is running correctly. This may be specific to the KakuteF4V2TRI target, don’t know yet. BetaFlight and iNav have diverged (more than) enough that it’s actually a completely different integration. I will also make the same setup change to iNav I mentioned above once I get it working. I know my LR/KakuteF4V2 combo works, as I just tested it with dRonin to make sure, so it’s definitely something in the firmware. I may make a build for the Matek405 or KakuteF7HDV and see if I can get that combo to move the servo.
Getting close – there’s light at the end of the tunnel, and I don’t think it’s another train…..
In my opinion you’d be better ofF with 0.5 Beta 3. In most users experience, 0.7 has been problematic with low throttle setting oscillations.
” could this be from the thinner arms?”
I don’t know. The LR just doesn’t feel as nimble as the others. I wonder if it’s the light overall weight coupled to the large disc area of the 8″ props (larger gyroscopic forces wrt to overall weight?). On my to do list is try it with 5″ or 6″ props. Even my V4 feels more nimble, but it’s considerably heavier, and has 10″ props. Will be curious as to your experiences with the doubled up arms.
” Ive had an idea about inverting the tail by extending the top-plate to form the tail”
Sounds really cool, keep us up to date!
Slowly keep increasing the yaw boost and see if that helps. The default value for the yaw boost used to be 240, but that proved to be to high for most cases, so I significantly decreased the default value. At 240, the tail would oscillate violently at low throttle settings, settling down once you got to hover throttle.
There’s a lot of stuff in triflight to twiddle with, I don’t think most people have ever messed with it.
If the above doesn’t work, I think it’s time to give up on the triflight 0.7 version, and go back to the 0.5 version with the mods I made for dRonin. Additionally, I don’t really think triflight is necessary for the Tri LR, given it’s intended use.
The Tri LR is an interesting frame. I’ve never got it to behave as nicely as the Tri V4, Mini Tri, or Baby Tri. It just has a different feel to it that’s hard to describe. I’ve not given up on it yet though. I will say that removing the stock tail mechanism and replacing it with the Impossible Tilt for the Baby Tri made a big difference, and that will be my baseline Tri LR hardware for testing once the weather improves…..
So here’s my rendition of Kevin’s latest Whirlygig. Weighs 49.5 grams without the battery connector or video gear.
The software is the BetaFlight unified target betaflight_4.1.1_STM32F411.hex, with a modified MATEKF411 target file, on a BetaFPV board. The modified MATEKF411 target file creates a pin configuration that supports an RSSI adc input and a non-inverted fport input. The unified target file I’m using contains the triflight 0p7 algorithms. The available ports on the BetaFPV board are somewhat limited, so as configured it must use fport.
Batteries should be here in the next week or so, so it hasn’t flown yet. Bench tests confirm proper operation of non-inverted fport, the RSSI adc input, and triflight. More details to follow….
I should also add I’ve built betaflight_4.1.1_STM32F405 and betaflight_4.1.1_STMF745 unified targets, and config files for the KakuteF4V2 and KakuteF7HDV boards. All have passed bench testing, and the KakuteF7HDV (installed on RCE Mini Tri with GPS and mag) has exactly one flight on it (triflight disabled) to verify basic operation. Lots more to test….