I will attach a few logs that demonstrate the current issues, but I am experiencing rapid climb rates when attempting anything more than a hover in assisted flight modes (Auto, PosHold, Loiter) and the severity appears to increase with higher speeds. I can see through the logs that I am getting velocity variance warnings and EKF spikes. I have been attempting to diagnose the problem for a few weeks now, but to no avail. Any help would be appreciated, and I can provide more information if necessary. Here is the link to the .bin files: Ardupilot Logs - Google Drive
He has things wrong is some areas and has ignored feedback to correct it from at least one Dev who would know. There is a tell tale here with RPM parameters being configured. See any ESC RPM in this log? Could be something else wrong but this certainly is. That’s one issue he has been told about. You can search around the forum and find those posts.
Like anyone should do; acknowledge the problem and fix it. That’s what I do if I make a mistake…
And no, ESC Telemetry is on to be configured later. This aircraft is being set up primarily by myself with input here and there from a friend. This issue has been stumping both of us.
I would say proper HW setup (including ESC telemetry if available) should be done in a first place, not later.
Seems vibrations are on the high side.
Barometer readings seems to be affected by props
Looks like not even initial params are set for gyro low pass filter
I am not very experienced with log reviews but from my chair looks like all (or most) initial setup steps were not done.
That connected with high vibrations and skipping directly to PIDs tuning plus 65deg max angle set is basically asking for problems.
I am guessing there will be recommendation to use AMC tool .
Yes, the vibration levels are too high especially in the horizontal axis so I think the autopilot needs better vibration isolation. We’ve got some advice here and here on the wiki.
Z-axis (vertical) vibrations should be mostly below 30m/s/s. X and Y axis (horizontal) should be closer to 15m/s/s. occasional short-term spikes above these levels are OK but in this log we see they are very consistently higher.
BTW, we can see in the logs that the EKF’s altitude doesn’t agree with the barometer altitude and that the climb rate is actually negative (e.g. the vehicle is falling) while the baro altitude is going up. This happens when the vibrations are higher than the IMU sensors can measure. It leads to “clipping” and because of the regular 1G force of gravity, the clipping happens more in one direction than the other. Anyway, need to reduce those vibes!
Well, your attempt at it is incorrect. Disable the RPM parameters, these will not be used for ESC telemetry configuration. And yea, reset all to default and using the Methodic Configurator may be the best option for you. It will reset all to default if you just dive into it.
Thank you for the insight! I had noticed the EKF altitude inconsistency, but had gotten stuck on how to remedy it. I will get the vibes down and see what it looks like afterwards. Super helpful!
Thank you for your input, I came into this project halfway through and am trying to avoid chasing every shiny squirrel I see, but I will absolutely go back and review the basic params before attempting another test.
It is a 10” quad coming in at around 1.5 kg. As for the 65deg max angle, it actually flies quite well in manual control modes, but I will back it off until I have stabilized the current config. Thank you for the help!
With not tuned or badly tuned quad? IMO 65deg is fine for something that flies reasonably OK not for something that can be barely controlled, or even beyond that, but no obligation to have the same view on things.
Yea, completely agree with you on that. My thought is it’s a max value, you are going to control the craft with the sticks. You don’t have to apply that angle. I think most of my smaller craft are all set to 85deg. But yes, they are well tuned so point taken.
Thing is, from this value other max angles are derived (for example for loiter mode), and You are not always in direct control of lean angles by sticks.
The point in loiter mode is to not limit it by the max angle unless that’s your intention. At least that’s how I see it. And you can set a specific Loiter Mode max angle if you like it doesn’t have to be derived. And there is PSC_ANGLE_MAX.
I did my best to isolate the flight controller from the frame and flew another test today with the same results. I went back to review logs from an aircraft operating on the same frame but using a Matek instead of a SpeedyBee, and the vibes were actually worse on the aircraft version with the Matek, which I was able to fly successfully.
I am not trying to say the vibes aren’t bad – they are, and I am actively working on that, but is there any reason why this configuration specifically is having issues when one that should perform worse is flying just fine?
I think if the two boards used different types of IMUs that could make one more sensitive to vibration. For example the log provided shows the accelerometer update rate is 1600hz (see below) while I know other boards have high rates (e.g. CubeOrange is 3300hz).
Just some flying around and some hovering.
