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
Hi Juraj,
I think the acro diagram on the post you point to is incorrectly labelled and should be Sport mode. This takes rate commands in the earth frame.
Now that I look at it, the diagram above should be labelled 3.1 not 2.9 too, so I have been rather slack with my labels.
The 3.1 acro uses an integrated rate in each body frame axis to keep track of the error in the body frame. For this reason it doesn't use the earth frame at all for basic stabilisation. The earth frame is only used for the slow levelling portion of the code. I am not sure if this answers your question. If it doesn't can you talk only about the diagram above as ACRO has evolved a great deal over the various releases you are talking about.
It is worth noting that ACRO is different again in 3.2. ACRO is almost the most complicated flight mode in arducopter now.
Hi Juraj,
The angle error and rates are different when referenced in the earth frame compared to the body frame. We initially calculate them in the earth frame then translate them to the body frame before feeding them into the controllers.
Hi Juraj,
They can be a series of rotations around the changing body frame axis ordered Yaw, Pitch, Roll. Or a series of rotations around the fixed earth frame axis ordered Roll, Pitch, Yaw. The two result in the same thing.
So what do you want to do or change? You should be able to get flying in stabilize on the defaults.
what don't you get about the flight modes?
Is your APM plugged in and have you connected to it?
well almost...the tumble works now...almost...as it pass 90deg, yaw flips also since we are in earth frame in stabilized modes...so it starts to correct the yaw as the tumble goes 90 to -90 ...winds up a little cocked...I tried to fix it by setting yaw mode to ACRO_YAW during the tumble...it works! but after the tumble, setting yaw mode back (I stored it in the beginning...which would be for example YAW_HOLD if in stabilize mode),but it wont accept rc yaw inputs...in permanent heading lock....almost like its in a nav mode...have to land it because I dont have yaw control...so close, yet so far away...
Got it working....thanks!...really have to think thru how the roll and pitch are varying as you progress thru the tumble so as to let the flight controllers take over at the right point...got some interesting never ending tumbles to earth today until I figured out the correct algorithm for the state machine...
Also,I added the SPORT style mode to the MPng 3.0.1 port with your body/earth mix ACRO code from the front of this pose, but using YAW_HOLD like it does in 3.1 code and like STABILIZE mode results in permanent heading lock in this mode...no yaw stick control...going to just use ACRO_YAW and see if that works...just want ACRO+ALT_HOLD...sounds simple, but evidently not...
Was all I need I think...roll goes +/-180...pitch +/- 90...explains it neatly...thanks!
Hi Henry,
I am sorry but I have spent very little time looking at the flip mode. I really can't help you without looking at your code and 3.0.1 is an eternity ago for me. :)
The only helpful suggestion I may be able to make is pitch is measured up from horizontal so it gets to 90 degrees and comes back down again. As pitch passes through vertical, roll jumps by 180 degrees and the copter goes from right way up to upside down. If you have not handled this transition correctly the copter will roll 180 degrees as it goes past vertical. This may explain what you are seeing.
Sorry I can't help more.
Thinking back through what I saw, I think that the pitch flip is stopping in all flight modes at inverted...in STAB it then rolls out upright and is facing 180deg from start...in ACRO there is no leveling so it just stays inverted and falling for the last 1sec long phase of the tumble in which its expected the normal flight controllers finish the move...hence hits earth...so I should prevent flips or tumbles when in ACRO since it wont finish the move without autoleveling...
but still doesnt answer why it moves to the last stage of the auto-aerobatic sequence before getting past -90 in pitch...actually it must be happening between 90 and -90 for it to autolevel facing the opposite direction...still stumped...it works great in the roll axis...
-
1
-
2
-
3
-
4
-
5
of 12 Next