Forum Replies Created
I’m really not sure how we, as a small group of tricopter enthusiasts, go forward. There’s not enough developers to really keep things moving from both a firmware and hardware perspective. We’re facing two problems here, the first is flight firmwware, the second is flight hardware.
I’ve always had good luck with dRronin, have successfully flown every RCExplorer vehicle with it. Problem is, I’m the only one actively working on it, and I haven’t had a lot of time to work on it over the summer. There’s a few things I’d like to fix, but beyond that, I think dRonin is finished, there hasn’t been a commit to the mainline project in quite a long time.
So where does that leave us?
Betaflight works, although it lacks the GPS nav stuff. No changes to the mainline code are necessary, it will work with the KakuteF4V2 using either resource mapping or the new universal target functionality. (I’ve done both. The universal target functionality is pretty cool!)
Inav needs a new target file (there’s no resource mapping) for the KakuteF4V2, to get the servo function moved to an independent timer bank. That’s the subject of the PR in question in this thread. And I can’t say if mainline iNav will include the modified KakuteF4V2 target or not.
With the modified KakuteF4V2 target, iNav works nicely on the KakuteF4V2/TriLR combo, I’ve flown it. But in all honesty, I don’t have the time, interest, or energy to be the supplier of binary files and all that that involves.
I’ve also got 2 other iNav related branches, one with the triflight 0.5 Beta 3 code, and another with the triflight 0.7 beta 3 code. These haven’t been flown yet, but seem to function correctly in bench testing. And no, I’m not interested in trying to port triflight to BetaFlight before someone asks….. 🙂
What I will probably do, is after I’ve flown these and verified these branches work, I’ll commit and push all the branches to my GIT repo. If people want to use them, they will need to setup a build environment and build from the source files. It’s not hard to do, the instructions for setting up an iNav build environment are pretty good.
Our last option is ArduCopter. Again, the KakuteF4V2 needs a modified target file. I’ve created the new target file, successfully built the required binaries, and run it on a spare board. I’ve not even attempted to try setting it up on the TriLR as of yet. I’m not familiar with ArduCopter at all, looks fairly involved to setup, but might be a worthwhile effort when time permits. No triflight code here, just basic tricopter mixing.
There’s not really many flight control boards that are tricopter friendly anymore. Most are aimed at quadcopters, and the timer bank allocation does not allow separate output protocols for the 3 motors and tail servo. The KakuteF4V2 is a perfect example of this. There are some F4 boards that will work with no modifications. I haven’t researched many of the F7 boards, but from what I saw it didn’t look promising. But I will add my search has not been exhaustive, there may be other good options out there I’m not aware of.8 September, 2019 at 23:07 in reply to: I need help from you, experts! Kakute F4 or Matek F405-CTR? External 5v 5A BEC? #63518
I’d go with the FCHUB-W and the Matek405STD. I use this combo in my Tri V4 and it works well.
I’ve looked at both iNav and ArduCopter for the KakuteF4V2, and I’m not convinced they will work on a tricopter without modification due to the standard way the timer resources are allocated. I’ve made my own iNav target for the KakuteF4V2, which I’ve flown effectively. I’m not sure if iNav is going to pull in the PR for this new target or not.
I think ArduCopter my require the same/similar mods, haven’t looked there in any detail yet.
And I think the MatekSTD /FCHUB-W can be used as is without mods.
No issues with using UART3 for GPS in this configuration.
There’s an auto update function that “usually” works when you update the firmware via the GCS. It’s self prompting. Be warned though that it’s not always 100% perfect, you need to carefully check everything after the process completes.
Because of that, I always make a manual backup copy of the settings using the “File->Export UAV Settings” function of the GCS.
That’s not the firmware you download from here:
Yours is 20190112, the above is 20190605
Upgrading to that should solve the missing uart options.
That is the latest, something else odd is going on as UART4 should have all the options including GPS. Which FC are you using? Also please post a screenshot of the firmware tab contents.
“I think the best option now is to desolder the GPS from UART 4 and move it to 6.”
Or download the latest version from the installers thread, you’re running an older version.
Looking at the hardware tabs, for Uart4 there’s a GPS option, and for Uart6 there’s a VTX Config for Smart Audio. This is exactly the config I use. But for what it’s worth, I’ve only seen the Smart Audio function work with TBS video transmitters, haven’t been able to figure out why yet.
While on the hardware tab, enable the OSD.
There’s no need for BetaFlight like resource management due to the way Uarts and Motor/Servo outputs are setup.
You can run the RCE Feedback servo at 330 Hz, been doing that for quite some time now, On the V4, LR, and BiCopter.13 August, 2019 at 14:28 in reply to: Thinking about getting the LR Tricopter, need advice. #63335
You don’t have to, and can’t to mix firmwares, it’s one or the other. You use Betaflight or iNav or dRonin or Arducopter firmware. You might use the Betaflight configurator to help with the initial load of a different firmware, but that’s as far as the “mixing” of firmwares goes.
While the KakuteF4 may be compatible with ArduCopter, the way it’s resources are defined it’s not capable of flying a tricopter. That may or may not be easily changed with a new resource definition file and recompiling the KakuteF4 target.12 August, 2019 at 18:51 in reply to: Tricopter LR uncontrollable spin on takeoff [SOLVED] #63322
You need the forum version as the dronin github version does not support the KakuteF4V2 or triflight.
You may have to create an exception in the virus program, some are likely to flag the GCS as a virus, some are not.12 August, 2019 at 17:26 in reply to: Tricopter LR uncontrollable spin on takeoff [SOLVED] #63319
“After I apply and save the settings the servo tilts to the laft”
This is incorrect, as the trim position should be tilted slightly to the right, assuming you are using the stock prop rotations on each motor.
My bet is the min/max value for the yaw servo need to be reversed, the larger number should be the min, the smaller the max, effectively reversing the servo.
The mag sensor orientation, 6 point mag calibration, and accel 6 point calibration are critical for proper nav operation.
If the mag sensor orientation and/or mag calibration is incorrect, that could easily explain the home arrow errors.
Likewise, an improper accel calibration could cause issues with altitude and position hold, for example the tilt left you are seeing.
So I’d recommend carefully doing the 6 point calibrations, then make sure the heading of the vehicle is correct at the 4 cardinal points. Then see if there’s any difference in the altitude and position hold behavior.
Just a thought, have you performed the 6 point accel and mag calibrations?
It’s not hard to load the hex file. On the BetaFlight configurator, in the lower right corner of the firmware flashing page, is an option to pick a local file. Navigate to where you placed the hex file, select it, and flash.
From your description, I think the hex will work. Simply define the motor 5 resource as none, and the servo 1 resource as whatever the pin was for M5.
The F4 AIO board should work fine with the existing target files.