Forum Replies Created

Viewing 15 posts - 1 through 15 (of 15 total)
  • Author
    Posts
  • in reply to: OldRaven's Tricopter LR build #65651
    zophon
    Participant

    Thank you very much!

    in reply to: iNav for KakuteF4V2 based Tricopters #65650
    zophon
    Participant

    Thank you for the link! See you there!

    in reply to: OldRaven's Tricopter LR build #65645
    zophon
    Participant

    Hi, I would be interested in you sharing your immortal T antenna holder. Would you mind? I am also going to mount a long range receiver in my TriLR. Thanks!

    in reply to: iNav for KakuteF4V2 based Tricopters #65643
    zophon
    Participant

    Hi,

    Back on the forum after a long time, the weather is better now and I have time to fly. Still, I followed the work done here with much interest! I have now enough confidence in my understanding of tuning the tricopter and I want to switch from dronin to Inav. It seems to me the latest .hex file from Jihlein is not downloadable anymore (2p4p0tf0p5.zip). Anyone care to share it?
    Or is all this merged into standard inav? I followed the tickets opened but did not quite understand every developpement made. Or are those custom hex file made with triflight, but standard Inav can fly the triLR?

    I read carefully the thread and will be summing up for me each advice to set up inav and tune it. For now I understood that triflight 0.5 flies better that 0.7…

    in reply to: dRonin for Tricopters! (TriRonin) #63838
    zophon
    Participant

    For the LR, i got a speed of 190dps, and at least another member reported a similar speed. I think that 244dps applies to the baby tricopter (d’aller props, less mass to move, hence greater velocity). I would suggest to go back to the workbench and smooth/sand the tilt mechanism (parts in flat contact and also as previously said, the hole, you should be able to move the screw across both parts of the mechanism almost by hand alone).

    in reply to: dRonin for Tricopters! (TriRonin) #63828
    zophon
    Participant

    @jhendrix “The option has been renamed to ServoCal and you must arm the copter in order to do the tune.”
    Are you sure? I don’t remember when I did that, but the video says the copter is disarmed for the bench tailtune.

    Can the “Fail” indication be a short for Failsafe, have you done correctly the failsafe setup at around 4:00 in the video?

    in reply to: iNav for KakuteF4V2 based Tricopters #63807
    zophon
    Participant

    Ok @jihlein I could setup a build environment to compile your triflight07 branch.

    FWIW I’ll detail the steps here, I followed for windows this link :
    iNav on windows

    Only change is at the step: ” ##Setup GNU ARM Toolchain”
    I had to download and install (notthe toolchain from there. It can probably be built from the source provided in the link from the page but didn’t understand how. While installing a checkbox can do the “add to PATH” step for you.

    Let’s see when the weather clears up, so that I can benchtest and flytest this.

    • This reply was modified 2 years, 10 months ago by zophon.
    • This reply was modified 2 years, 10 months ago by zophon.
    in reply to: iNav for KakuteF4V2 based Tricopters #63714
    zophon
    Participant

    OK, so the PR is only groundwork, to be able merge the triflight code (either version) with which a tricopter can fly.

    If I want to test what needs testing, I need to build myself iNav, branch triflight 0.5 or 0.7 for the KAKUTEF4V2TRI target, if I am right? I can foresee that taking part in testing and moving forward a project like eats up a lot of time, so I am being cautious here, but I might have time during the weekend to test something. Could you point me towards any ressource I might need (where the branch code is, a doc on setting up the iNav buid environnment etc… if there isn’t, I will hunt for informations myself).

    in reply to: Tri LR Tailtuning #63708
    zophon
    Participant

    Hi @peterpankras,

    I’ve summed up every info I could find to get my tricopter LR to fly here (noob disclaimer). The relevant bits would be :

    Autotune
    On a calm day, I had no trouble completing the autotune, everything went fine. I did several because I crashed and I tried different batteries and so on… The last autotune I did delivered following results. This could be used to compare with other setup, but it is by no means a reference point or values to put directly in your copter.

    Roll P 15 I 55 D 27
    Pitch P 25 I 91 D 54
    Yaw P 56 I 349 D 10

    Roll and pitch values are directly from the autotune, but I modified a bit the yaw values:
    I think I halved the yaw P term after the advice in post 62240 (thanks @vantasstic) and 62271 (thanks @billyd) and lowered a bit the yaw I term (it was over 400 or 500 with the autotune).
    I followed the advice on zeroing the yaw D term, but then I tried a first incrementation at a value of 10. Seems allright, probably not perfect, but fine.

    Tailtune/ServoCal
    Well let’s call it ServoCal since it is the new name. It went without problem to get a value different from 13.8, but it was a bit harder to get a good value. More on that in the next section.
    With the newest build, the beep pattern for successful calibration after landing is 2 beeps pause 2 beeps etc… if I am correct.

    Tilt mechanism and friction
    A thing that I did not quite catch on my attempt is characterising the right fricton to have in the tilt mechanism. David said to “file it in order to have not too much friction, but you don’t want it too loose”.

    On my first attempts to tune the copter (autotune and servocal), I ended up with a nice tune in roll and pitch and what I thought to be correct tune for yaw. I got a bit of tail movement, and if I hit the throttle hard there was a significant amount of tail wag. The HoverThrottle was at about 0.40 something. But the MotorThrustFactor was worrying me as it was over 40!

    Reading further in the forum, I saw one or two reports of MotorThrustFactor being 8, 9 or 10-ish values (post 62431 for example)… So after a crash that had broken the zip-ties of the tilt mechanism I went back to the workbench and tried to have less friction on the tilt mechanism. And already at the servo speed tune step I saw some changes : the speed measurement were much more consistent : 190°/s + or – 3°/s. Before I had done this three times with a max 217°/s and a low 180°/s (I think), I kept the max value, because well, the more the better…

    After an autotune and a servocal, here it is : MotorThrustFactor at 10.5! And even less tail wag when I punch the throttle (It’s visible that the servo is doing its thing, but the tail doesn’t go crazy). I am not sure that this corrects avery vibration problem, but the tail behaves nicely (noob point of view ? ).

    So here might be an indication that the friction is too much in the tilt mechanism:
    – Your MotorThrustFactor is too high (could some confirm that a 10 ish value is good, and that 20 to 40 is way too high?).
    – Check for a consistant speed at servo setup.

    Sum-up

    So if you want to redo an autotune, I would advise to reset the values to default in dronin (my yaw would get crazier and crazier after each autotune…) and halve the P and I term of the Yaw, and zero the D term.

    For servocal, check if the speed is consistent at the “speed measure” step (to erase this possibility of tail wag).) Then servocal in the air, I just got in the air, hovered, waited 30s and landed, disarmed and then exited servocal. It just worked…

    • This reply was modified 2 years, 10 months ago by zophon.
    in reply to: iNav for KakuteF4V2 based Tricopters #63707
    zophon
    Participant

    @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)?

    in reply to: iNav for KakuteF4V2 based Tricopters #63688
    zophon
    Participant

    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.

    in reply to: dRonin for Tricopters! (TriRonin) #63687
    zophon
    Participant

    I am copying a part of my build log here, to state that the home arrow seems to work well with your last build @jihlein.

    Home Arrow
    To enable that, post 62439 by @billyd was helpful.
    You have to activate the modules “Path Planner” and “VTOL Path Planner”
    Then go to the filters tab of the attitude settings to select the proper filters (“INSOutdoor” for Attitude algorithm and “INS” for Navigation algorithm).
    But on the filters I had strange behavior selecting INSOutdoor. It took time to stabilise (30sec after boot) and somehow showed a few degrees difference with a previous calibration.
    Reading on the dronin documentation, I chose the “complementary” filter for Attitude algorithm instead. This seems a better choice.

    With the 2019-06-05 build, I can confirm that there is an inconsistancy in the arrow movement (looks like a bad atan/atan2 computation or something like that, a quadrant error maybe). but with the latest @jihlein build (experimental) here in post 63251, i think it is fixed!
    The movement of the arrow is consistent with the tricopter rotation around itself, always pointing the home location.

    in reply to: From Noob to LR flying in the air #63682
    zophon
    Participant
    in reply to: From Noob to LR in the air #63675
    zophon
    Participant
    in reply to: From Noob to LR in the air #63674
    zophon
    Participant

    Disclaimer

    This is my first drone build. I never flew anything before that. Yeah, I know, I read the warnings by @david (he tricopter is not designed as a beginner platform, etc…) but decided, what the heck, his build video are so clear, nothing can go wrong 🙂 The knowledge presented in the videos is awesome btw. And I’ll get myself a simulator, I’ll learn 🙂
    Also, I know my way around soldering, electronics design, part machining, programming, so I sould be able to understand if something goes wrong.
    Therefore I’d like to stress out that this no expert opinion on how to do things. These are only Rc/drone noob thoughts, problems and how I went around them.
    I’m open to any comment on my material and component choices, how to upgrade or what were bad choices etc…

    Material
    I bought:
    – frame : Tricopter LR – Kit
    – the recommended : Tricopter LR Electronics kit.
    – RC Transmitter : FRsky Taranis XD9+
    – RC receiver : FrSky R-XSR Ultra Mini Redundancy Receiver (but will be testing a 900 mHz also).
    – Camera : Foxeer Falkor 1200TVL FPV
    – For Video tx, I went the 5.8 Ghz route : TBS Unify Pro Race 5G8 HV Race V2.
    – Antennas : Aomway 5.8GHz 4-Leaf Clover Antenna.

    Building the frame
    I followed the build video here:
    https://www.youtube.com/watch?v=rNy6HMie_Yg

    First remark, contrary to the previous videos, there is no mention of filing the edges of the carbon fiber frame. Is this no more needed?

    A small remark on tightening the screws of the arms : I’ve already had the arms folding a little bit backwards after a few rough landings, so it is better to tighten them really good, just so that you can still barely move them by hand.

    Nothing else to say, I followed everything to the letter, and it worked.
    Great instructions and infos about soldering to prevent common mistakes, thumbs up!

    Dronin setup video
    Then switching to the dronin setup video here:
    https://www.youtube.com/watch?v=uZQvEJu7vG4

    First remark, the link in the description goes to here. But this mentions only the build from 2019-01-13, which is not the newest one! But this thread is worth a read, loads of infos in there! I checked again the forum and found this thread (quite obvious if you go to the forums first, but not if come you directly from the youtube video) which has the newest build from the 2019-06-05 (apart from a more recent experimental build, more on that in the GPS section).

    I had a few problems with the betaflight install to flash the dronin firmware, but I should have listened to David and directly watched this video. Joshua Bardwell explains everything very clearly and thoroughly, it’s great! After that I was able to flash the dronin firmware on my kakute.

    At the 1:17 mark, I have to disagree, I could select the receiver type (I chose SBus for my FrSky receiver), probably only the more recent build have that.

    At 1:30, I didn’t know which ESC protocol I should use for the ESC included in the tricopter LR kit. So I think I selected Dshot600 but I am not sure. I don’t see in Dronin where I could find this info again. What should be the best choice?

    At 6:16, it should be said that the servo output should be reversed (button with two arrows on the right of the servo output line, otherwise you will have a furiously spinning tricopter on the first take-off (is this only the case for the tricopter LR?).

    At 9:48, the servo speed is measured. If, like me, you don’t really know if you prepared the tilt mechanism well, do this a few times. The measured speed should be consistent (not varying to much) at around 190°/s. More on that in the “Tilt mechanism and friction” section of this post.

    Misc.
    I had a lot of problem with random disconnects in Dronin, after 5 sec, the board was not recognised any more. Go to tools -> erase all settings from board. That solved almost all problems (still having them from time to time…).

    Autotune
    On a calm day, I had no trouble completing the autotune, everything went fine. I did several because I crashed and I tried different batteries and so on… The last autotune I did delivered following results. This could be used to compare with other setup, but it is by no means a reference point or values to put directly in your copter.

    Roll P 15 I 55 D 27
    Pitch P 25 I 91 D 54
    Yaw P 56 I 349 D 10

    Roll and pitch values are directly from the autotune, but I modified a bit the yaw values:
    I think I halved the yaw P term after the advice in post 62240 (thanks @Vantasstic) and 62271 (thanks @billyd) and lowered a bit the yaw I term (it was over 400 or 500 with the autotune).
    I followed the advice on zeroing the yaw D term, but then I tried a first incrementation at a value of 10. Seems allright, probably not perfect, but fine.

    Tailtune/ServoCal
    Well let’s call it ServoCal since it is the new name. It went without problem to get a value different from 13.8, but it was a bit harder to get a good value. More on that in the next section.
    With the newest build, the beep pattern for successful calibration after landing is 2 beeps pause 2 beeps etc… if I am correct.

    Tilt mechanism and friction
    A thing that I did not quite catch on my attempt is characterising the right fricton to have in the tilt mechanism. David said to “file it in order to have not too much friction, but you don’t want it too loose”.

    On my first attempts to tune the copter (autotune and servocal), I ended up with a nice tune in roll and pitch and what I thought to be correct tune for yaw. I got a bit of tail movement, and if I hit the throttle hard there was a significant amount of tail wag. The HoverThrottle was at about 0.40 something. But the MotorThrustFactor was worrying me as it was over 40!

    Reading further in the forum, I saw one or two reports of MotorThrustFactor being 8, 9 or 10-ish values (post 62431 for example)… So after a crash that had broken the zip-ties of the tilt mechanism I went back to the workbench and tried to have less friction on the tilt mechanism. And already at the servo speed tune step I saw some changes : the speed measurement were much more consistent : 190°/s + or – 3°/s. Before I had done this three times with a max 217°/s and a low 180°/s (I think), I kept the max value, because well, the more the better…

    After an autotune and a servocal, here it is : MotorThrustFactor at 10.5! And even less tail wag when I punch the throttle (It’s visible that the servo is doing its thing, but the tail doesn’t go crazy). I am not sure that this corrects avery vibration problem, but the tail behaves nicely (noob point of view 😀 ).

    So here might be an indication that the friction is too much in the tilt mechanism:
    – Your MotorThrustFactor is too high (could some confirm that a 10 ish value is good, and that 20 to 40 is way too high?).
    – Check for a consistant speed at servo setup.

    OSD setup
    In the Hardware pane, I selected the MAX7456 OSD for the OSDPort. Every info showed one my osd screen, out of the box.

    Smart Audio
    I connected the smart Audio line from my VTX to Tx4 on the kakute. Selected “VTX config TBS SmartAudio” for UART4 in the hardware panel. Seels to work as I can select the power configuration in the dronin OSD menu. But I have yet to confirm that.

    GPS setup
    Thanks to this post 62655 in this thread. I bought this
    and connected it like this: rx to tx and tx to rx, and SDA to SDA and SCL to SCL, on UART6.
    I selected GPS for UART6 in the Hardware pane and selected HMC5983 for ExtMag.
    I enabled the GPS module in the Module pane, selected “UBX” and “57600” in the GPS tab.
    Even though I put the GPS board with the arrow pointing forward, the orientation of the copter was wrong on the dronin flight data map. I had to change ExtMag Orientation to “Bottom90degCW” on the harware panel. And now it works 🙂

    Mag calibration
    I did the 6 point mag calibration.
    Then I redid the accelerometer calibration alone, with the “Start and zero vertical”. This is seamingly needed for “Altitude hold” and “RTH” mode.

    Home Arrow
    To enable that, post 62439 by @billyd was helpful.
    You have to activate the modules “Path Planner” and “VTOL Path Planner”
    Then go to the filters tab of the attitude settings to select the proper filters (“INSOutdoor” for Attitude algorithm and “INS” for Navigation algorithm).
    But on the filters I had strange behavior selecting INSOutdoor. It took time to stabilise (30sec after boot) and somehow showed a few degrees difference with a previous calibration.
    Reading on the dronin documentation, I chose the “complementary” filter for Attitude algorithm instead. This seems a better choice.

    With the 2019-06-05 build, I can confirm that there is an inconsistancy in the arrow movement (looks like a bad atan/atan2 computation or something like that, a quadrant error maybe). but with the latest @jihlein build (experimental) here in post 63251, i think it is fixed!
    The movement of the arrow is consistent with the tricopter rotation around itself, always pointing the home location.

    RTH
    I’ve read about setting this up and I will try that in the future. The dronin documentation should be helpful. They say : first set up the altitude hold mode, then try to get the position hold mode to work, and then try the RTH feature.

    Battery life
    I would love to know the setup that that led to an hour estimation of hover time. Again I am not here to throw stones, I only have a genuine interest in how to optimise and approach that number.
    I already know that my setup isn’t the lightest build. I added the GPS, added self-vulcanising tape on the arms to prevent moisture to get in, I am flying with a lipo inside a fireproof bag (remember I am a noob 🙂 and I don’t want to puncture my Lipo in case of a crash, and oh god loose everything in the fires of hell 😀 ).
    This setup amounts to 398g, with a 5200 mAh Lipo and its bag it amounts to roughly 798g. This, according to the osd needs a current of around 10 Amps to hover (between 9.5 and 10.5).
    This seems realistic, I read someone report a 9 Amps current with other props. This would give around 32 minutes of flight. But during flight, conditions vary a lot and depending on the wind to counter etc, it might be more or less.
    Advertised is : “Flight time hovering: ~40 minutes (3s 5200mAh)”, with no wind and a bit of weight shaved off, would I hit the 40 min mark?
    Second question : what would it take to get the “with the right battery and a light build, makes it possible to achieve over an hour of hovering flight time!”
    What is there to optimise, or what other non ideal conditions have I overlooked?
    Ok, I rewatched the build video and David says 10 Amp 10C battery and a light build. Even more with 18650 Lithium Ion batteries. Somebody tried that?

Viewing 15 posts - 1 through 15 (of 15 total)