Thoughts on max_correction

This forum is dedicated to software development related to MultiWii.
It is not the right place to submit a setup problem.
Software download
Post Reply
spagoziak
Posts: 171
Joined: Thu Jan 20, 2011 1:18 am

Thoughts on max_correction

Post by spagoziak »


Quoted from Alex's post on RCG:
Hi,

I released today a new dev version with a new parameter which I think could be a real improvement.
http://code.google.com/p/multiwii/source/browse/trunk/dev_version/MultiWii_dev20110710.zip

I tested this version on 3 multi without specific issues:
- QUAD X with a genuine WMP only and a pro mini board
- QUAD X with FFIMUv2 and a flyduino board
- TRI with a WMP copy and a pro mini board
I didn't manage to reproduce any flip

I call the new parameter MAX_CORRECTION

Code: Select all

/* this parameter defines the maximum correction per axis multiwii can output before mixing the output to different motors
 this parameter becomes inactive as soon as the sticks are far from the center position in order to keep acro abilities
 reducing this parameter can avoid big wobbles and allows higher PID settings
*/
#define MAX_CORRECTION 100


I did some test with a value of 50 with still good results. I set it by default to 100.
It's normal to have nearly no resistance by hand with low values, and I think it could also increase the flight time.
With a value of 1000, it's the same as the previous settings.

Before releasing the 1.8, I would like to have some feedbacks on it.
The more feedback I will have, the better will be the version ;)


Ok so I've had some time to play with max_correction!

My first impression is that it's very clever and impressive--I can really see the benefit of its work.

I have a quad with 9x6 apc's 1050 kv motors, 24" motor to motor distance. AUW is 1200 with FPV gear on board. Here's my config--quite stable, pretty smooth. I think I need to fool around just a hair more to eliminate some tiny shivers in strong wind. But for FPV I'd bet this is already just fine. Haven't tested it FPV yet, only LOS.

Image

I tested it at max_c 100 today in wind about 12-16 mph and found the quad did not handle the gusts very well. I could see booms dropping and the craft working pretty hard to overcome challenges to yaw, along with intermittent jerky shivering now and then. So I changed MAX_CORRECTION from the default 100 to 350 and found the quad could handle the wind much more effectively, almost back to what 1.7 was, in the sense that wind seemed to just blow right through the thing. When the wind calmed in between gusts, the quad flew like it was swimming in thick water--it hovered in acro mode very calmly.

However, it seems more difficult for me to keep it perfectly level in acro mode--it kept changing attitude slightly, probably because a change in axis may have partially been corrected by motors adjacent to the axis, causing an imperfect adjustment in attitude (that's me just guessing). I suspect this could be improved by adding P, but I'd probably have to add more pitch/roll rate to compensate so I'd avoid oscillations while in motion.

This raises some thoughts...if users have max correction set incorrectly for their MWC or flying habits, they may have more trouble when PID tuning. My quad's power train needed more correction room for each motor in order to sufficiently handle today's wind. Adjusting PID would certainly fix the same issue, but max_c seems to govern the effectiveness of the motor very directly, while PID governs effectiveness of the MWC in total. This could be terribly confusing for new users.

One great thing to help diagnose max_c issues (instead of PID issues) is that in a good bit of wind you'll see a boom drop, almost like there's a bad motor on the end. I think this is evidence that max_c is too low, causing insufficient correction authority on that boom.

So, in the end, it seems that max_c set too strongly (too close to 0) will greatly reduce the MWC's ability to cope with unstable air. Set too weak (out at 1000), the MWC will rely solely on each motor's thrust for correction, which is what we're used to. However, getting it set just right (my guess is between 300 and 600) will allow for incredibly smooth hover while preserving Warthox-capable acro flight. I plan on experimenting further :cool:

Thank you Alex for this new, interesting concept!
spag

ziss_dm
Posts: 529
Joined: Tue Mar 08, 2011 5:26 am

Re: Thoughts on max_correction

Post by ziss_dm »

Hi Alex,

Could you also explain the problem, which we are trying to solve? ;) Is it slow wables during FF flight and in transition to level?

regards,
ziss_dm

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: Thoughts on max_correction

Post by Alexinparis »

Hi,

The full story:

When we decided to increase the resolution of the gyro by a x8 factor, we forgot to update the “anti glitch” part which limits the delta between 2 readings at 100.
=> it was equivalent to limit the max amplitude between 2 readings to 12 with the new settings.
It was not so noticeable in a static flight, it was even better due to the new resolution. We noticed it both.
But it produced big wobbles when you start to shake the multi and I was looking for a system to prevent this. I didn’t think at this time about a remaining bug.

=> I introduced MAX_CORRECTION variable.
It works quite well in a static situation: no more big wobbles, but it is absolutely not a good idea for abrupt flying style because it limits too much the needed corrections.

Then I discovered the “anti glitch” limitation bug and I fixed it accordingly
=> new value set at 800 to match the old setting which worked well.
+ D term correction because an overflow bug could also happen with this new setting.

Now, I think MAX_CORRECTION is no more needed.
Thinking about a limit on PID output could be a good idea, but probably with a more elaborated approach (maybe introducing an expo curve ?)
=> I suppressed this mechanism in the last revision.

I had the confirmation yesterday of its usefulness in a flight with a simple genuine WMP on my quadX: it was the best smooth flight I’ve achieved in hard acro condition.

So, to sum up: there was a bug which is now corrected and MAX_CORRECTION is not a good idea.

babelo
Posts: 28
Joined: Wed Jul 06, 2011 12:56 pm

Re: Thoughts on max_correction

Post by babelo »

Hi,

I just read your post and maybe i will try max_c to 350. My tricopter is a mini jakub frame.
When i was flying with 1.7 after balancing propeller and also adding dampers to motor fix. It fly pretty well
with low PID 1.3 - 0.030 - 15
After switching to dev version PID are 2.0 - 0.030 - 11 ( it fly with 15 too)
But when you do FF, and you try to go back to hover, the front motors try to compensate too much the stop order and
suddently your tricopter go vertically.
After Alex change, it looks better even if this effect is still here but smaller.

In first dev version this problem start to appear when you try to do forward fly, copter try to go back to
horizontal all the time, result is copter climb during all the forward fly.

Also about the stable mode, i did not get any confidence in it as when i switch it in fly i can have lot of
different direction drift, and sometimes it crash directly.
Stable mode is hard to pilot for me usually i fly helicopter in 3D and since some month i fly with a BeastX
which is a 3 axis heading hold system. Flying with Multiwii in dev release in acro mode is close to this system
so i m happy. Also stable mode need too much command order to fly like acro mode and sometimes drift can't be recovered and it result in a tricopter crash. Maybe i need to reduce PI for level mode.

Fabrice,

PS : Alex is the current SVn ok with the anti glitch correction ?

ziss_dm
Posts: 529
Joined: Tue Mar 08, 2011 5:26 am

Re: Thoughts on max_correction

Post by ziss_dm »

Hi babelo,

It is sounds like you have resonation in some conditions (I had the same some time ago). I would recommend the following:
1) Try to remove damper from motor fixes.
2) Make sure that sensors board firmly fixed.

regards,
ziss_dm

Post Reply