Home Forums Everything about everything else iNav for KakuteF4V2 based Tricopters

Viewing 15 posts - 46 through 60 (of 171 total)
  • Author
    Posts
  • #64307
    BLeeK
    Participant

    Thank you for advice 🙂

    #64309
    PeterPankras
    Participant

    @jihlein I setup a build envoronment and succesfully build basic iNav. So at least the building works.

    I’m indeed getting errors with your branches.

    What does it take to push this to 2.3?
    I will see if I understand what you changed to the Kakute target, I like to at least understand how this firmware stuff works 😉

    #64310
    jihlein
    Participant

    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.

    #64311
    yumemi5k
    Participant

    About triflight, my understanding is that it actually has an understanding of tricopter physics, and accounts for deviations caused by non-zero correlation of flight controls proactively. For example, when you punch throttle up, tail servo needs to tilt more to account for increasing torque/thrust ratio. A simple PID controller needs to wait until yaw error actually sets in before I term can act. The worst part is that torque on motor is related to both throttle value and current RPM, so you can’t fix this with a simple tweak on mixing table. In comparison, Triflight knows that more yaw is needed before actually seeing yaw error, and acts preemptively.
    Triflight improves handling in general and extends the envelope in which a craft can be flown intuitively. Still, it can’t defy physics, and it’s probably better not to fly a tricopter too hard, especially a bigger one.
    @jihlein, Excited to hear that you are working on a newer version of iNav with triflight! My craft is currently under overhaul but should be ready to fly soon.

    #64312
    PeterPankras
    Participant

    @jihlein

    I installed some extra stuff I forgot, so maybe your branch will build now. I will try again tonight and if I get an error let you know.

    I flashed your september hex in the kakute without any problem. This was a hex with only the pin numbers swapped right?

    I have no idea how I can see in inav configurator that everything is ok.

    btw, do you know if it is ok to use inav configurator 2.3 with a board that has 2.2 firmware on it? Or should I use an older configurator?

    #64316
    PeterPankras
    Participant

    @jihlein I can build your branch.

    But how can I build the tricopter hex file?

    When I do a make TARGET=KAKUTEF4V2TRI I get a make target not valid.
    I can for example do a TARGET=KAKUTEF4V2 and that builds fine, but that is probably not the one I need.

    edit: Wait, never mind.. I had the wrong Branch 😀

    I was able to build your triflight0p7 branch.
    going to flash it on the board now.

    #64320
    PeterPankras
    Participant

    Ok, I flashed inav_2.2.1_KAKUTEF4V2TRI on my spare board.

    What do I have to look out for when setting it up?

    I set mixer to tricopter, and see it has servo on 5 by default? Is this the led pin or should I set it to 7?

    When I look in de modes tab I see the tailtune mode, is this the same as in dRonin?

    Where can I find other tri related settings in iNav?

    Just in case I’m also using a 2.2 configurator.

    #64332
    jihlein
    Participant

    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.

    #64333
    PeterPankras
    Participant

    Thanx I see it. I enabled triflight in the cli and will use some of the settings from @yumemi5k .

    I am switching the gps on the tri for one with compass and switching to crossfire. If I’m confident enough I will flash this build on the tri and see if I can get it to work.

    The inav dev team removed the 2.3 version as there was a bug in the cli. So the will move to 2.3.1

    #64335
    PeterPankras
    Participant

    O, and does it use the servo feedback? And if yes , is it the same pin as Davids setup with dRonin?

    #64342
    yumemi5k
    Participant

    It’s the same as dRonin, servo feedback goes to RSSI by default. Feedback values does update after tailtune so I believe it is in use.

    #64354
    PeterPankras
    Participant

    I flashed it on the Tri and set everything up.

    How can I reverse the servo direction? It is reversed like I had in dRonin.
    Setting the min and max reverse solved it there.

    I have no idea how to do that in iNav.

    Anyone know? so i can get this thing in the air.

    #64355
    PeterPankras
    Participant

    Never mind, reversing the weight to -100 in the servo mixer tab seemed to to the trick.

    #64356
    PeterPankras
    Participant

    Well that was a very short flight.

    It does an insta flip on takeoff (resulting in broken prop)

    I used the exact same motor setup as in dronin, also left the motor direction the same as in dronin despite the bug that the image in iNav tri setup is wrong (showing front 2 motor spinnig in the same direction).

    In dRonin the NE motor is motor 1, in iNav that is motor 3. Motor 1 in dRonin is the tail motor.

    iNav does not support resource mapping right? So I have to physicly match whatever it does.
    In my case it seems I have to swap motors 1 and 3

    Board orientation is correct, did the accelerometer calibration.. all seem to be correct.

    @ymemi5k could you post a dump of all your inav setting for comparison.

    So grounded until new props are in.. but that does give me time to rear it apart and swap the motor wires and add the new gps. sigh

    #64359
    jihlein
    Participant

    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?

Viewing 15 posts - 46 through 60 (of 171 total)
  • The forum ‘Everything about everything else’ is closed to new topics and replies.