Matek F405-miniTE fails to initialize

The Y-vibes are extreme with plenty of clipping events. You really can’t continue until you tame this. The outputs are oscillating badly too but that’s predictable with some of the default parameters you have. I would cut the Rate P&I values in half (from .135) and when you can establish a MOT_THST_HOVER value set these as per the tuning guide:

Thanks. Apparently I confused y and z vibes yesterday, and oddly, I thought it was reporting a max of 2 on clipping. Not sure what I was looking at now. The stack is mounted on 3mm nylon bolts, and they allow some flex in Y. Maybe I should try to get some metal bolts in there. Any chance the over active P&I rate gains could contribute to the vibes?

Contribute some but not the primary driver I don’t think. But change those parameters as noted and see. You will need to do it anyway. I found that the most compliant mounting method you can achieve works best on small quads. On one I stacked 2 rubber grommets which works well. Adds height though. Make sure the cables have some slack also. Typically it is Z that’s the problem. What does this craft look like?

The frame is a Rekon 5" Rekon FPV Rekon5 5" Mini LR Frame Kit without the naked GoPro mount and different TPU parts. All the cables attached to the FC are thin Silicon cables, and all pretty slack. All my PixRacer builds use the old Pixhawk foam squares for mounting, and have had very low vibration, but there’s no room for that in this build.

Just in case you haven’t see it I did a build video series on this frame - ArduCopter Rekon 5" Build Video 1 - Frame Assembly, ESC and Motor Mounting - YouTube

I did not see that. Thanks for the link.

I just dropped P&I rate terms to 0.1 for pitch and roll and did a quick test hop only in Acro, and the RCouts look much cleaner. X and Y vibes are closer together, with X the highest, and Z the lowest again. Average values are 31 for X, 25 for Y and 16 for Z, but X has peaks above 50. No clipping on the short flight.

I may try swapping out the stack bolts to see if it gets better or worse. I might be able to get the ESC and FC a little further apart as well.

Also: ArduCopter 5" Long-Range Standard Build

I just remounted the stack. There were originally long 3mm nylon bolts holding the ESC (Talon 35A) and FC (Matek F405-miniTE) in place, with very soft grommets on both. The Nylon bolts didn’t have nut anchoring them to the frame, just pressure on the grommets. I swapped out 2 of the bolts for Aluminum, and now have nylon nuts where the pass through the frame, so that they are pretty rigid. Previously the mount felt soft, but due to the lack of the nuts on the frame, the FC could pretty easily be shoved left and right a bit. It feels more rigid now, but grommets are less compressed, and maybe work better.Y-vibes are still the highest, but getting better.

The motors are actually working hard when it’s at or near the ground, but in a hover at a few meters it’s cleaner. It sounds good, but the motors are a little warm after landing, and it’s a really short flight just hovering. Could yaw be overactive, or maybe a d-term?

I’ve got an update on this project, but still a few questions. I managed to get it flying in AUTO today, with successful takeoffs and landings. Vibrations are high enough to occasionally give EEKF/Vibe warnings in the HUD, but generally no clipping.

I did experience a weird compass issue. I’m using the little Matek M8Q-5883 module. It’s mounted in the default position for the Rekon 5, so in the back, and at about a 30 degree pitch angle w.r.t. the FC. I had a rough time getting it to calibrate originally. Eventually calibration seemed to complete, but in MissionPlanner it always seemed to present close to a 90 degree offset. Oddly, PosHold was actually pretty good (stayed within about a 2m radius in wind), but when I switched to AUTO it pretty much went crazy. After landing in STAB, I did another compass cal, and then the displayed heading was pretty accurate and AUTO worked great. Can anyone explain why a compass cal can be that bad, and also why PosHold can work well when a calibration is that bad. I recall the early days with DJI Naza controllers, and if a compass cal was even off by a little, you’d end up with pretty aggressive toilet bowl flight.

I was just reading up on MOT_HOV_LEARN, and realized that it doesn’t work in Stab or Acro modes. I’m assuming that means that you need to be in ALT_HOLD or POS_HOLD modes, or I suppose anything else where the throttle is FBW. What is the preferred approach to tune that? At the moment it is horribly low, around 0.15, and this gives a ridiculous expo feel to throttle. It also has this problem in POS_HOLD where it feels like it decides to land, and no amount of throttle seems to get it out. Switching to STAB gives authority to fix it.

That’s not out of the ordinary with relatively high thrust/weight craft. You can tune for that. Best way for hover throttle to be learned is to hover in Loiter until the throttle is at mid stick. Position Hold has pretty much been superseded by Loiter. Many more tunable parameters available.

Thanks, I’ll try it. I’m not sure I fully understand the process or what to expect. Should I initially set hover throttle to something more moderate, say 25 or 30% - at least within the recommended range? It’s definitely not a racing copter. If I set it to 50% and fly in ACRO will I get an idea of where throttle really is to hover? Once flying in LOITER, with throttle in the center, will it immediately try to hold altitude, or will it provide the hover thrust value, and then slowly adjust that as I hover.

I just had a chance to dig through the log on the last flight, and it looks pretty good. X and Y vibes are still higher than I would like, but no clipping and no errors or warnings logged.

I was just reading up here:

and looking through the log for a segment of auto flight around a short race track, CTUN.THO seems to be 0.06ish, which seems obscenely low. While climbing at about 4m/s it peaks at 0.1. It is a light quad, but they are tiny motors and 5x3 bi-blade props. What else could I have setup incorrectly to skew this so much?

It will do this. Take-off in Loiter if you want and as you attempt to hover you will have to adjust the stick until it’s at mid stick and it’s hovering. That’s it, it’s learned. Land and MOT_THST_HOVER will be updated when you review the parameter file.

I don’t see anything yet that is incorrect.

OK. Reading the wiki page on MOT_HOVER_LEARN, they said that looking at CTUN.THO would give an idea of where MOT_THST_HOVER should be. I’m seeing values of 0.06, but looking at RCOU values, they are around 1260 in hover, for a PWM range of 1000-2000 (running DSHOT). Looking at this, I would guess that MOT_THST_HOVER should be something like 0.26, but I guess I must still not quite understand what is going on.

Nevertheless, I’ll try the LOITER takeoff experiment and see what I get.

Thanks for your patience.

We have find some similar problems wih this board when we connect a lot of periferical devices.

range finder, optical flow, vtx and radio rx, gps, etc.

when the board have a lot of devices connected, and you only plug the usb to connect, the usb dont have enought power to feed all the system and show a lot of problems to connect and setup

our protocol in this cases:

first connect the battery.
then the usb and try to connect MP and setup

In my case it turned out to be a bad solder joint on one of the peripherals. Mine failed to initialize even when there was nothing plugged into it, but it seems that one of the solder joints on the pigtails was bridged in such a way that it was unable to see any sensors - including the ones on the board. Someone else had soldered the board up, and they looked ok to me, but after removing the pigtails, it booted just fine, and now flies fine, so there was clearly a fault.

Good to know about the BEC limits when powering over USB though.