[jihlein]

“I just spoke to Pawel about Triflight and they are interested in it.”

You can point him to this branch:

https://github.com/jihlein/inav/tree/2p3p0tf0p7

It has the triflight 0p7 algorithms, the KakuteF4V2 tricopter target, and the KakuteF7HDV target. It’s based on the 2.3.0 iNav release.

I’m currently testing my 4p1p1tf0p7 branch of BetaFlight on the KakuteF7HDV, I plan on moving to 2p3p0tf0p7 iNav after that. The copter (RCE Mini Tri) is already setup with a GPS and magnetometer. My RCE Tri LR with a KakuteF4V2 will also be used for testing as time permits.

[jihlein]

I would suggest disabling the Triflight feature initially, and get the copter flying. Then when enabling Triflight later, it’s effects can be better observed and we can get better ideas of where gains such as tri_yaw_boost should be placed.

[jihlein]

I’ve not any direct experience with either of those boards, so here’s my best guess…..

The Foxeer won’t work with iNav, but might with BetaFlight with some remapping. Servo would be on S1, motors on S3 thru S5.

The OmniBusF4 has a lot of variants, but appears motors on S1-S3 and servo on S5 should work, both in BetaFlight and iNav.

To determine this, you need to look at the target files for the specific board, and find pins on separate timers that support servo outputs.

[jihlein]

Not super familiar with the intricacies of iNav, but here’s some guesses:

1)Don’t know the implementation details, sounds odd, but if it works, I wouldn’t worry about it. I flew it and didn’t even notice that…..
2)Yes, when connected to I2C these two devices are very similar
3)Don’t know anything about TBS crossfire
4)I used Dshot300, iNav doesn’t recommend Dshot 600, could be implementation differences from BetaFlight
5)I use 330 Hz on iNav and BetaFlight with RCE FDBK servo with no problems.

[jihlein]

No need to tear things apart.

I don’t want to make any more builds than necessary, it’s confusing enough for (new) users taking into account timer banks for servo connections. I would like to see new users just use the BetaFlight and iNav expected motor order of 1/2/3 = rear/right/left.

So to solve the order problem on iNav goes like this:
Look at the mixer page. The mixer is simply an array, and all you need to do is take the motor 1 roll/pitch/yaw constants and put them in the motor 3 row, and the motor 3 roll/pitch/yaw constants and put them in the motor 1 row. This effectively changes the motor 1 and 3 positions. It’s what I did for my iNav testing. It’s not straight forward, but if you really don’t want to swap the motor 1 and motor 3 signals wires (that’s all that need to be changed) this will work.

I’d post pictures of the modified mixer table, but don’t have iNav on an FC at the moment…..so post your before and after mixer table if you’re unsure.

[jihlein]

@billyd, I haven’t forgotten about this, just very little time to flight test right now. Plus, there’s a bigger issue that’s got me worried with dRonin, and that is the attitude drift we’ve discovered, which I fear could cause errant behavior in any flight mode other than acro. I’ve been looking into it, but no solution yet. Mainstream dRonin development has stopped, so I’m on my own with it right now.

As much as I hate to say it, I think iNav is a better path forward right now. I’ve been traveling a lot lately, and in the evenings have spent some time putting together iNav 2.3.0 and triflight 0.7. I was able to bench test it, and it looks good. Some others are currently beginning to flight test it.

I’ve also done the same with BetaFlight 4.1.1 and triflight 0.7. Again, no flight testing by myself, but a few others are looking at it.

BetaFlight and iNav have a lot of the “cool” features (advanced filtering, easy OSD setup, F7 support, to name a few) pilots are looking for, and dRonin will quite likely never have, so even though it may be a painful transition, those firmwares are most likely the future……

Probably not what you wanted to hear, but unfortunately if no one else steps up to help with the code development and maintenance, it’s where the future is leading us tricopter enthusiasts.

[jihlein]

The remapping of a resource for servo use is highly dependent on how the hardware designer laid out the board wrt to the timer resources. In most cases you can not simply remap Motor4, in many cases Motor4 shares timer resources with Motor3, therefore they must use the same output protocol. For example, DShot on Motor3, means Dshot on Motor4, which the servo can’t tolerate. 330 Hz PWM on Motor4, means your Motor3 protocol is limited to 330 Hz PWM.

Unfortunately it takes some not so straightforward research to figure this out. What flight controller are you using?

[jihlein]

I recall having the same problem with angle mode. Don’t recall how to adjust that, will look and see if I saved a diff somewhere.

Somewhere in these threads there were some PID values listed for BetaFlight. They flew pretty well during my admittedly short iNav testing.

[jihlein]

Yeah, the Windows version of the compiler required by iNav is broken. I did a direct download of version gcc-arm-none-eabi-8-2019-q3-update and modified the make files accordingly. To save you some grief, here’s the hex file I built and am testing with. This shouldn’t be so hard…….

Also, asymmetric yaw servo travel is normal with triflight enabled. It does that to equalize the yaw force in both the cw and ccw directions.

I’ve built ArduCopter for the KakuteF4V2 (with the tricopter M4/LED pad swap). I did run it on the board and it connected to mission planner, but I never went any further than that. It was a pain to get loaded the first time if I recall correctly.

Attachments:

1. inav_2.3.0_KAKUTEF4V2TRI.zip

[jihlein]

FWIW, I loaded my Tri LR with the inav_2.3.0_KAKUTEF4V2TRI build that I add triflight 0p7 to. Setup the minimum settings so I could try the on ground tail tune. I was able to set the left/neutral/right endpoints, compute the servo speed, and successfully save the settings.

I’ve not flown this branch, or done any other on aircraft testing, but from what I’ve seen do far, if everything is setup correctly, I wouldn’t hesitate to fly it. I might get there this weekend weather permitting.

[jihlein]

I’ve been traveling for the last few weeks. Remind me of what’s going on and we’ll see if we can track things down over the next few days.

[jihlein]

On an old version of iNav, maybe 1.7 or 1.8, I created a target for an AQ32 flight control board, which I have installed in a Titan tricopter (similar to the V4). It flew (still does) very well, position hold, altitude hold, velocity hold, RTH, all the modes, with stock PIDs no less. This was also without the triflight algorithms. So the proof iNav works with tricopters is there.

I’ve almost got inav 2.3.0 integrated with triflight 0.7, but initial tests show tail oscillations, and that’s been a constant issue with triflight 0.7. So I will continue trying to work that out…..or revert to triflight 0.5 which does not have the oscillation problem.

[jihlein]

I think we’re at the point we some decisions need to be made. iNav lacks the flexibility that dRonin and Betaflight have wrt assigning outputs. It assumes things will be electrically wired as defined in the target definitions, and only that way.

When I started this adventure, I was only used to dRonin, and I wired everything up with motor 1 as either the front left or front motor, numbering the rest clockwise from there. This works fine in dRonin, and can be made to work in BetaFlight with resource mapping. It doesn’t work in iNav, unless you make a custom target (beyond the LED/M4 swap, M1 and M3 need to be swapped too). This works, but then the wired config does not match the graphic. I’m not sure this is a good path, too much confusion.

The “easiest” path forward may be to change the wiring order, swapping the wires for motors 1 and 3. Then iNav (and Betaflight) will work, and with the proper definitions, so will dRonin. Involves some re-soldering for those of us using the M1 =left front motor wiring unfortunately.

I suspect this is the issue that got you Peter. So i’d recommend looking at your current configuration and seeing if motors 1 and 3 are reversed.

For the long haul, what do you think the best option forward is?

[jihlein]

It sets up the same as the old BetaFlight version, with one exception, I made triflight a feature that must be enabled for it to function. This way it can be turned on and off for testing. All the settings are done via the CLI, look for tri_ settings.

[jihlein]

If you can build basic iNav, my branch should build too, that’s strange. What error(s) are you getting?

The basic KakuteF4V2 changes should easily merge with 2.3, once you get the build issues sorted out.

[Author]

Posts