Forum Replies Created
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.
@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.
@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.
@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.
//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.
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.
@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.
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.
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.
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.
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.
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.
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.
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.