iNav for KakuteF4V2 based Tricopters

[jihlein]

As we all know, to use the KakuteF4V2 with a tricopter requires the use of the LED string output to allow separate motor and servo protocols. My branch of dRonin with triflight handles this, and BetaFlight can be made to work using resource management, at the expense of loosing the LED string functionality (there are ways around this, but that’s a different subject).

Inav is a different story, it needs a new target file. I created one, named KakuteF4V2Tri, and have flown it with success. It supports both the tail servo on LED pad, and LED string on the M4 pad. I submitted a PR to the iNav devs, but it hasn’t been picked up. In 2 weeks it will expire due to inactivity.

If this is a feature that you would like, it might be helpful to add a comment to the PR, which can be found here: https://github.com/iNavFlight/inav/pull/4861

Otherwise I’ll just let it be closed with no further activity.

[Wally]

Added my comment in github. I would like to try iNav on my Tri. Thanks jihlein.

[Kevin_Erik]

One good reason to keep the iNav / Betaflight / dRoinin builds is that RCE just announced that its closing shop. Would hate to see everything be lost when this forum goes off line.

BTW havin issues logging into Github from the Dominican Republic. Will try again once i am back in Germany.

[Wally]

Not sure what this means, but it sounds promising. See attached screenshot of github status.

Attachments:

1. 

   github-check.png
   

[BLeeK]

Added my name to the comments, if that helps at all…?
Had to join first, still dunno how their site works so I hope I didnt miss a button or something….lol!

[PeterPankras]

I see I’m late for the party.

I really want to try iNav with the LR, yes my lr flies ok with dRonin but I’m not really happy with the things missing.
And I cannot get the tail dialed in with dRonin.

Betaflight misses the thigs I think are interesting with a Long Range tri, the gps stuff.

Can i still use iNav with the LR Tri? or am I f…ed now that there seems to be not enough people interested?

[jihlein]

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.

Firmware

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.

Hardware

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.

[zophon]

Well, all this is worrying. I am new to the hobby, and was quite stocked by the amount of knowledge and ressources in this forum and on the rcexplorer website (not to mention the great build videos by @david).

I thought dRonin was the future with its advertised “awesome autotune on the PIDs”. I kind of got around configuring everything I wanted on my tricopter LR and learning to fly it.

I like the GPS functionnality in dRonin, I like the overall polish and quality feel of betaflight. Other firmware, I don’t know, I haven’t tried them.

With the shop closing and now your reply, it feels kind of grim…

I am more than willing to take time to test new builds, but I don’t know what else to do.

[yumemi5k]

Hi @jihlein, I just set up iNAV build environment and your triflight0p7 branch seems to build. Resulting .hex file is 884K in size for MATEKF405 and 841k for KAKUTEF4V2, does this seem sensible to you?
I still need to remap the pins to make this work. I guess this should be done through editing /main/targets/MATEKF405/target.c, but couldn’t find an instruction on how to do this, could you offer a hint? Thanks!

PS: Mine is wired like:
MOTOR NE: S2
MOTOR NW: S4
MOTOR S(TAIL): S3
SERVO: S5

Is this workable with TriNAV or do I need to resolder stuff?

If I can get this straight then I might be able to help supplying binaries to interested pilots :D.

[jihlein]

@yumemi5k

Both the triflight0p5 branch and triflight0p7 branches have the modified target file for the KakuteF4V2 which swaps the M4 and LED pad functionality. You need to build the KAKUTEF4V2TRI target. This target is only good for tricopters!

The Matek405 target doesn’t require any changes, if you use S1 for the tail servo. I think you will have to either change the motor order, or make some modifications to the mixer table if you want to use the motor order you have setup though.

Also note that I’ve not been able to mess with any of this stuff all summer, so I’m not sure if I flight tested any of this or not (was messing around with too many branches and different firmwares at the time). So proceed and test carefully!

Thanks for looking into this!

[yumemi5k]

@jihlein Thanks for the reply. I’ll move servo to S1 as it seems to be a good idea overall since S1 won’t be resourced to be other stuff anyway, while S5 can be resourced to LED.
But I’m still confused about a few things: first is that it seems that iNAV takes S2 for tail motor, s3 for NE motor and S4 for NW like this, which is different from mine. I guess I can fix this through mixing table if needed though.
Another is that iNAV seems to show all 3 props running CCW, Do I have to do this, or can I still run CW on NE motor?
Lastly, I see nothing specifying which motor number is which pin in DEF_TIM macro (function?) in target.c files. My best guess is that motor number is decided by its order of appearance in target.c, is this really the case?

PS: My Tri is currently grounded anyway as my last crash left me waiting for replacement props, so it will receive extensive bench testing before flying 😀

[PeterPankras]

Seems like my post got deleted… weird.. hang on

ERROR: Duplicate reply detected; it looks as though you’ve already said that!

[PeterPankras]

Let me try again, seems like my post dissapeared..

@jihlien @yumemi5k

It’s always a problem with projects like this.
I think it’s projects like this that keep everything moving foreward, not sticking to the mainstream solutions.
But that is hard because it’s always just a very small group of people jumping in.

I was excited when I first saw the Long Range Tri and ordered one at once… hence I even grew a beard like David!

I was really looking foreward to Davids update because it is still an unfinished project.
He was telling about adding long range reciever etc to make it really long range and sharing setups.. that for me was the sole reason to also use dRonin because he uses it in the video.
Then out of the blue (for me) it’s abandoned, and sold. And tri’s we be again much harder to get for other people.

I’m more then happy to help if you are going the iNav route. With so few people it would be good to at least use the same base.
I see people using betaflight now and getting info on dRonin setups is hard when everyone seems to switch to something else 😀
For me betaflight is not an option because I want to get some gps stuff going and possible in the future get it to fly a mission.

@yumeni5k I would try and stick with the exact pin setup as david uses in the dRonin build.

Let me know if you need testing, I’m more then happy to use my LR as an iNav testbed and also keep the inav team in the loop on facebook for example.

[zophon]

@jihlein I added a comment in github to support your work. As this thread is almost the only one still alive in the forum, maybe that shows that the interest turns towards iNav. @peterpankras I agree, It would be a good choice to have the same base, which targets the stock LR hardware (Kakute), others could benefit.

I would be more than happy to test and learn what to do with iNav. It seems to me that the installation would be “easy” as you already have a patch for the target Kakute F4 V2, I hope this patch gets merged.

@jihlein Could you explain, or point me towards explanation what the difference between this and iNav with triflight 0.5 and 0.7 are (the other branches you talked about)?

[jihlein]

The current outstanding PR is only for the KAKUTEF4V2TRI target, which swaps the M4 and LED pad functions to support separate ESC and servo protocols.

The triflight 0.5 branch incorporates the triflight routines from the 0.5 BetaFlight release. There is no PR written against this branch and it needs testing.

The triflight 0.7 branch incorporates the triflight routines from the 0.7 BetaFlight release. There is no PR written against this branch and it needs testing.

The differences between the two are difficult to quickly explain, suffice it say the 0.7 is the newer version. I’ve had issues with this version oscillating at low throttle settings, but think I figured out why and fixed it.

The version is dRonin is 0.5, plus some custom changes I made. If 0.7 above does not oscillate, these changes are unnecessary.

These branches need to be eventually merged with the latest iNav development branch. I looked into that, found that there are a lot of merge conflicts that need to be manually dealt with.

[Author]

Posts