Dangerous divergence: FIXED and understood

[Max]

TRP? Zero, default. I thought the P and I terms aren't used in the tilt rate controller.

The main thing I had to do was reduce Tilt rate D to 5100 (from 7180), otherwise it was very "squirrel-y" trying to hold altitude (lots of sudden alt. changes in manual mode). The quad does have some vibrations, a touch more than I'd like, but nothing nasty.

I then also reduced Nav. Alt. Speed I to 1.8 (from 2.8) to eliminate some slight "bouncing" effect during alt. hold (motors would rev up and down a bunch, with some vertical movement of the quad).

All this after adjusting throttle factor, of course. That's pretty much all I had to do. My radio is set to around +/-700 on Roll/Pitch/Yaw axes (as displayed in QGC).

-Max

[LPR]

Max

Sorry I meant to say Tilt Angle P. I had a long day trying to fly the cube. I chickened out of finishing the official cube because the batteries were showing lower voltage than I was comfortable with. Flying close to the ground I found I had more then enough battery to finish the challenge. Darn. The mission is working well though.
Is there a simple way to increase the vertical speed in a mission?
The slow vertical velocity means the four vertical legs takes about half the time of moving around the cube.

Larry

[afernan]

@James: in post#23 of this discusión you can download a kml file that you can play with Google earth showing a real flight divergence. You'll get a good idea of what happens.

@Jussi: I allways use a X-quad with mixing table from wiki. i'll test a 100% based table to check. I've sent a PM with more test results.

I don't think is related with PID's or mixing tables since control law performs very well in smooth flights. Over a certain value it suddenly diverge.

Angel

[afernan]

[phynix]

Hello, I have also a small quad (flyduino-warthox frame), and none of the described problems so far. But I have not testet it at the limits yet.

So there must be some difference... but I don't know what it is. I would really like to see this topic solved. I need a fast and agile copter - and it has to be SAVE in any flight situations. So I will follow this topic here ....

[afernan]

Finally I think I´ve isotated the problem: flying in "+" mode the problem clearly dissapear:

I´ve built a "heavy dutty" test quad to minimize crash damages. Testing in "X" mode, I´ve reproduced the divergence everytime I push hard, as described many times before in this post

Then I´ve built a "+" configuration (exactly same hardware and same PIDs). I´ve simply changed the mix table and the IMU ROT = 45.

I´ve been flying several batteries (different types: 3S, 4S, 2200mA to 5000mA): pushing really hard and NEVER got the divergence.
Even more, for me, the copter flyes even smoother and precise than in "X" mode. Now the control is able to get the horizontal without the oversooting that induced the divergence, although there is still an increase of the heigth (it drops several meters at stop). This indicates to me that maybe the problem could be related with the "g" gravity compensation due to the tilt angle in flight and the sudden rotation that induced the divergence.

There is a clear problem of overshooting with "X" mode when trying to recuperate the horizontal position at high horizontal speed, that induced the divergence.

I´ll analyce in detail the logs and report some plots for this succeded "+" flight

Angel

[LPR]

Angle

Great news.

Larry

[bn999]

Angel: If what you say is true, then you have something fundamentally wrong that you have covered up by making this switch. If setup properly, the motor outputs of a + vs X configuration should be identical except that they are rotated 45 degrees.

You can use the l1Tool available as source on the repo to investigate control mixing tables for your preferred orientation. If properly chosen, you will be able to apply a mathematical +-45 degree rotation to get from one to the other.

I'm fairly certain your problem stems from PID parameters. If properly tuned, there should be no maneuver (within the machine's flight envelope) that would cause the fatal oscillations that you experience.

[afernan]

Bill: thanks for your comment.
First I want to point out that it´s not only me having this issue, there are others reporting this issue and probably much others that never push hard enough the stick to get it, so they simply don´t know they could have.
Changes done are not only the FC rotation, but the mix table, so motors output are not identical to "X" mode obviously:

M# T P R Y
-- ---- ---- ---- ----
M2 100 100 0 -100 front
M5 100 0 100 100 left
M9 100 0 -100 100 right
M13 100 -100 0 -100 rear

About PID, as I said, I´ve maintained exactly same PIDs that causing oscillation in "X" conf, not causing it in "+" conf. How can you explain that? .

I´ve been testing in "X" mode this problem from long time ago with a LOT of crashes, changing every PID parameter I could imagine without success. I can´t give an explanation of the reason, but I have now a "+" conf that works.

I´ve to say that I feel a bit "alone" in this problem since no other have really hard tested the issue (I can understand because you pay a high price with every crash) but IMHO AQ team must fix this somehow. It´s an essential issue.

Angel

[bn999]

Angel: I've never had such problems and not been able to resolve it with PID tuning. I have flown very hard and as I said, there should be nothing you can do with the controls that would result in loss of stability. If it were something that I could reproduce, I'd have a solution that I can hand you.

Take your above mixing table and assign X & Y coordinates to each value, then rotate the coordinates by 45 deg. That will give you an equivalent mixing table for the other orientation. Then try that and see what happens.

Although it's probably impractical, I'd be happy to receive your machine and tune it to solve this problem.