Forum Replies Created

Viewing 15 posts - 1 through 15 (of 44 total)
  • Author
    Posts
  • in reply to: Tricopter LR restock #65118
    yumemi5k
    Participant

    Unfortunately RCExplorer has closed shop. You can still download the design files and have them cut/3D printed if you are determined, though.
    The community is still alive, some are active on rcgroups.

    in reply to: iNav for KakuteF4V2 based Tricopters #64880
    yumemi5k
    Participant

    I reckon iNAV only cares about accelerometer scale and zero values when doing calibration – it’s difficult to lay some crafts perfectly level anyway. Another way of finding board level is to trim angle mode carefully in zero wind and find roll and pitch angles from OSD. The values should be equal in magnitude to board alignment offsets, just watch out for minus signs.

    in reply to: iNav for KakuteF4V2 based Tricopters #64848
    yumemi5k
    Participant

    Thanks @jihlein for working on the code and thanks to @billyd for test flying!

    @jihlein DSHOT_MIN_THROTTLE definition disappeared in mixer.h and the code didn’t compile before adding it back though. Is the removal intentional or by mistake? I’m not sure if I’m just masking the symptoms of another problem.

    in reply to: iNav for KakuteF4V2 based Tricopters #64832
    yumemi5k
    Participant

    @billyd Good point, especially since I had a few parameters corrupted previously which were fixed manually. I’ll reflash and see if the corruption happens again and test zero throttle POSHOLD behaviour but probably won’t take the leap of faith and test ending F/S RTH with POSHOLD again.

    in reply to: iNav for KakuteF4V2 based Tricopters #64829
    yumemi5k
    Participant

    @billyd Yes, editing posts with attachments can lead to erratic behaviour. I just lost mine by messing with attachments and had to post again. You can bypass the duplicate post stopper by adding some text before and after your post.

    in reply to: iNav for KakuteF4V2 based Tricopters #64813
    yumemi5k
    Participant

    //This is a tribute to the duplicate post detector.
    My TX off failsafe RTH test on 2p3p0tf0p5 ended in crash. The drone entered failsafe and started to RTH correctly, but all motors stopped dead the moment when failsafe ended. Craft stayed armed according to logs, it’s unlikely that I disarmed the craft myself by mistake. The motor spun again erratically for a few moments during the descent.

    What I recalled and saw from the logs:
    1. The craft exited FS RTH into POSHOLD, POSHOLD realized something was wrong and increased throttle gradually, but motors refused to spin.
    2. Right before crashing I switched into acro, which did seem to behave correctly, but it was too late for me to save the craft.
    3. I entered POSHOLD after F/S at 0 throttle when all motors stopped dead, pushing throttle stick up caused motors to start spinning again. The zero throttle input was not intentional, but I expected POSHOLD to be still able to maintain attitude instead of dropping like a rock.

    Is there something that could bypass navigation mode throttle request and override motor output to be min value? MOTOR_STOP comes into mind, but I don’t know about its behaviour, and AFAIK I don’t have it enabled.

    Anyway, should this remain unsolved, if any of you want to test F/S, be vigilant and test POSHOLD behaviour at zero throttle first.
    //

    Attachments:
    in reply to: iNav for KakuteF4V2 based Tricopters #64795
    yumemi5k
    Participant

    I got triflight 0.5 on iNav 2.3 working. First hover test went well and RPM telemetry worked. However, during initial configuration & bench tailtune process, gyro hardware LPF and yaw_jump_prevention parameters somehow became corrupted, only allowing me to arm and fly after fixing these through CLI. I’ll do a thorough diff audit before any serious fly testing as I am now unsure if more parameters have been corrupted in a more subtle way.

    in reply to: iNav for KakuteF4V2 based Tricopters #64752
    yumemi5k
    Participant

    @jihlein nice to hear you are working on iNav 2.3 integration. I’m very interested in the dynamic rpm filter, as unlike in a 3″ where you can just throw everything above 200 Hz out and be happy, every Hz counts with a slower spinning rotor.

    in reply to: iNav for KakuteF4V2 based Tricopters #64540
    yumemi5k
    Participant

    As is mentioned in this video, a regulator might not help as much as one might hope filtering ripple.
    Why not power VTX with VBAT and GND pads right next to the video out pad? You also get current sensing for VTX this way, signal wires are kept close, and more importantly, you can be sure they reference the same ground.

    in reply to: iNav for KakuteF4V2 based Tricopters #64523
    yumemi5k
    Participant

    Outdated and sub-optimal as it is, current OSD implementation is still your best bet flying with goggles. I fly with a 5″ monitor mounted on radio and I still find shifting my gaze from video to radio display distracting.

    Either way, in a few years, digital FPV probably will take over and we’ll have OSD overlaid locally instead of on craft. Transmitting sharp transitions of text is expensive, and is tolerated only because analog video is an insanely wasteful standard to begin with.

    in reply to: iNav for KakuteF4V2 based Tricopters #64521
    yumemi5k
    Participant

    If you are using OSD on flight controller, my suggestion is that you connect a ground wire between camera and FC, preferably to the pad intended for powering camera, and twist the signal and ground wires together. Twisting the wires keeps the wires together and prevent one wire from being consistently closer to a source of interference. Twist wires from OSD to VTX also. Try not to route video wires close to power wires, if unavoidable, at least don’t run them parallel to each other.
    Mine had acceptable video when newly built, which turned into garbage after a rebuild. Twisting the wires then made all the difference and I hardly notice any horizontal lines now.

    in reply to: Servo Mapping #64519
    yumemi5k
    Participant

    KakuteF4V2 and Matek F405 CTR and STD are known to work.
    I had a look at omnibus F4 target.c file, assuming you have a V3, S5 should work for servo out of the box.

    in reply to: iNav for KakuteF4V2 based Tricopters #64462
    yumemi5k
    Participant

    I don’t believe iNav, BF or Ardupilot assumes the craft to be perfectly level at arming by default, as I am pretty sure that the artificial horizon indicator doesn’t jump to zero upon arming for all my crafts. There will be some minutiae drift however you fine-tune level, as it is essentially sitting on a sheet of ice with zero friction, and any tiny imperfection will show over a few seconds. The artificial horizon is also EXPECTED to drift over time without assistance from compass, since accelerometer doesn’t really help once the craft leaves ground, and horizon is computed by integrating gyro rates, which will drift from a perfect zero over time. VBAT shouldn’t play a direct role as the IMU sits behind layers or voltage regulation. A compass remedies this by being able to measure a field that hopefully is not changing much over your flight (which is not guaranteed BTW). The autopilot is supposed to be able to identify sudden magnetic field interference and discard the readings if compass and gyro disagrees violently. The autopilot does this by throwing all readings with estimates of how reliable they are (weights) into an extended Kalman filter algorithm, asking it what is the most likely scenario that caused the set of readings.

    Auto-level by itself is not really that useful in outdoor flights anyway as it doesn’t fight wind. Once you get GPS working, PosHold probably is the mode you are looking for. The lack of redundancy on 30.5mm boards means that you should always be ready to fly rate mode though. If even video or gyro gives up, just be glad that at least you are not on that thing.

    in reply to: OldRaven's Tricopter LR build #64401
    yumemi5k
    Participant

    It’s a bit confusing to explain with text but luckily David explained how to set this without using configurator in this video. If you haven’t set tailtune as a flight mode yet you can backtrack a little.

    in reply to: iNav for KakuteF4V2 based Tricopters #64360
    yumemi5k
    Participant

    Ouch, I probably contributed to the crash by saying it’s the same as dRonin… I now remember changing motor order in target file. I was happy that I didn’t need to resolder and didn’t give it much thought later. If I didn’t fail to mention this you probably would have survived, sorry!
    I’m away for the weekend so the dump will come later. I’m using a MatekF405CTR though.

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