Hi all,
My motivation to get involved in the development team was to bring a good ACRO mode to ArduCopter. Three or four months ago Robert Lefebvre suggested that we could integrate the rate error and use it to correct the platform in the body frame. He went on to demonstrate this on Heli's. We have since learned that MultiWii use a similar approach and code was developed by Bob Dorion based on MultiWii and discussed here http://www.diydrones.com/forum/topics/flipping-arducopter.
I have taken Robert's approach and integrated it with the current ACRO trainer aids with the help of Robert and Bob. Here is the result:
This code is based on ArduCopter 3.01rc1 so if you haven't got this flying yet, don't bother with this code.
Changes:
Replace Earth Frame ACRO with Body Frame ACRO
Reduce the dead band on the roll and pitch inputs
In the same way as you could before you can disable all trainer functions by setting
ACRO_BAL_PITCH,0
ACRO_BAL_ROLL,0
ACRO_TRAINER,0
For my flight testing I have been using:
ACRO_BAL_PITCH,50
ACRO_BAL_ROLL,50
ACRO_P,4.5
ACRO_TRAINER,0
Things to discuss are:
Is the performance acceptable?
What additional features are needed? (switched trainer functions, zero throttle doesn't stop motors)
Is there a better algorithm?
Do you see any problems with the code?
How does the performance and feel compare with other systems? (please only comment if you have flown those systems and this system on a well set up copter, anything less is a waist of every bodies time)
I have spent at least 20 minutes doing nothing but flips and rolls of various combinations and mixtures and a similar amount of time doing yank and bank maneuvers. I have not found a problem or any bad habits.
I look forward to your feedback and ideas.
Comments
HAK, stop wobble (higher frequencies, similar to wobble on fast stick centering) to me is caused by too low Rate D term, try to increase!
It´s a bit strange, my Rate D is three times higer than default at the same time Rate I being around an eighth of default on an out of the box DJI F450 with stock ESCs, props and motors. LiPo is maybe heavier than usual, 3S 5Ah, but additional weight isn´t any bigger than landing gear plus GoPro.
Leonard, Rate I is at 0,015, was 0,03 before, both worked perfectly, could not feel any difference. The upper margin is hard to find because problems occur randomly (as vortex ring state does which seems to be related). But if they do, story ends with a crash very often, so I´m not too keen on spotting this margin!
I would recommend to lower I term defaults a lot instead (Does hover need it at all?) and to raise with small increments just to the point (not any higher) when forward flight behaviour becomes appropriate.
The reason why I want you to test the I term problem is because I can't reproduce it myself and I have added code that I hope will fix it. You can always reduce it back if you like.
Thanks!
Philipp - I found that as well as keeping the quad locked in during forward flight a higher I gain help with recovery at the end of a flip/roll. Helped it to stay where you stop it with the sticks and you get less of the stop wobble.
Reset all loiter parameters to 3.0.1 defaults, Works pretty good now, holds position, but started wandering after yaw input. Since red line in Mission Planners Flight data always fits perfectly copter´s heading even when climbing at full throttle I just set all compassmot values to zero - and it got better! So RTL and loiter both operate not bad now, 2.9.1b seems to be history at the moment!
Tried same PIDs as before, perfect acro control! It´s clearly a lot better than 2.9.1b but honestly I can´t feel differences to first edition, since it was really good already. (What was "Yaw Bug", how does it look like?) As first edition was that good, one would have to set up a second, identical copter to be able to test firmware versions by flying alternately accomplishing kind of double-blind comparison.
Had big fun but lost orientation and came down harder than intended. Quad is repaired already but spare parts have to be refilled now! So there was no time for PID experiments.
Is there anything wrong with keeping Rate I as low as possible? Has it any further function but to keep nose down at higher speeds? I´d rather try to get P and D higher and maybe increase stability if considered possible. Bad idea?
I will test for sure!
Is there any need to set I term higher than necessary? I mean rc1 worked perfectly with 0,015, and I tried 2.9.1b with the same rate PID values as V3 and there was no pitch up at all.
Thanks mate, I look forward to your feedback as always!
Will load up and take a look.
Appreciate your work on this Leonard.
Ok, sorry for the wait.
I have the next version of the ACRO code ready to try here:
https://github.com/lthall/ardupilot_ACRO/tree/ACRO
In this code I have fixed and improved the handling of the I terms in roll pitch and yaw (also fixed the yaw bug).
I have also further improved the level code scaling to keep flips and rolls as clean as possible.
Sorry this took so long, I have also been trying to fix the loiter wobble problem.
Philipp, I hope the improvements in the I term handling might let you use bigger I terms again, without getting the problem during large pitch back. I personally can't reproduce your problem.
Would you mind testing acro again to see if this has improved anything?
Didn't offend me at all!
It is just frustrating because I did all my testing and development of my parts of the code with damaged props and a slightly bent motor in a hope that it would be a good approximation of the worst case. Unfortunately there are just too many combinations to solve all the problems the community could have.
I too think it is a shame to have a copter that isn't easily updated. But rest assured we will be working hard to fix the problems. It just takes time.
I did not want to affront you, I definitely see the big job developers do. Im very sorry if it looked like personal attack!
Inertial navigation is a big thing without any doubt but not to everyone! If it needs a lot of setup and expensive hardware to work properly then it would be a good idea to make it optional. Switched off (or not installed at all if memory space is the issue) for those flying FPV with smaller, maybe slightly vibrating copters because in that case not every landing is super soft and flying itself is the fun part not balancing props and motors every day, repeating setup twice a week. Switched on for those who need best possible loiter precison, aerial photographers for instance.
To me it is sort of disappointing when a perfectly operating copter turns nonfunctional after implementation of a feature I definitely do not need! On the other hand Pure Acro would be a nice to have feature so I still hope to get both in the future: Aerobatics AND simple, robust, reliable GPS functions!
-
5
-
6
-
7
-
8
-
9
of 15 Next