I just pushed Arducopter 2.2 to the Mission planner. This version went through extensive testing by a brave group of flyers and with both HIL and SIL testing.
See this link for more:
http://www.diydrones.com/forum/topics/arducopter-2-1-1-alpha
If you run into any problems please let me know here. If you find a reproducible bug, please add it to the issues list.
tuning tips:
If you run into Loiter issues, try adjusting LOITER_P. It's 2.0 right now which may or may not be to aggressive for your copter. Nav is no longer used in Loiter control, which should make tuning easier.
If you run into a circling issue, try lowering LOITER_I to 0 and see if it goes away. If not, check your compass declination. A negative error will produce CCW rotations, a positive error CW.
If you have issues with alt hold, try lowering your THROTTLE_P, it may be too high for higher thrust copters.
If you have wobbles and can't seem to get rid of them, there is a new term called STAB_D, which is a derivative term used to tune out the wobbles. You can increase it until they stop, but just like driving a cadillac, you loose some performance and handling. In the CLI "tune 16" in setup will let you control this in flight, and "tune" in test menu will let you see the value printed out interactively before flight. See the wiki for more detail.
Many testers gave me a thumbs up on the code, so if you have an issues please post the flash log from the copter. The tLog isn't that much help to me for debugging as it doesn't capture the needed values at high enough rates.
(Remember, if you'd rather pull the code from the repository and load it with Arduino, you must use the "relaxpatch" version of Arduino in our downloads section.)
Update 2.2b2
I believe I found the simple mode error. It was a bug that was working OK until Tridge fixed it so it was declared properly. Then the bug became active. I made the Simple mode function internal variables static and this should fix it hopefully.
I updated alt hold to not use dampener for now until we get more testing. Some folks saw a latency induced oscillation which was pumped up by the D term.
I added the automatic throttle cruise or hold value as a compile time option for testers. This basically looks at your throttle and climb rate while in stabilize or acro and determines your optimal hover value. This means you can enter any autopilot mode and not have to worry about your throttle position. It should make alt hold more reliable if it works. This is off by default until we get good field tests back.
Update pushed to GIT.
Update 2.2b3
Just some refinements. I added JLN's throttle curve mod for landing. Hopefully that's correctly implemented.
Made the landing delay from RTL user settable
removed the ADC gyro filter, I was doing a lot of testing and determined it wasn't worth it.
Enabled the auto-throttle control by default. Please test in the sim
Altitude no longer resets when flying in Loiter mode
Pitch and roll dampening is smoother now. try values up to .08 for very dampened flight.
Mavlink can now trigger auto-land
I'll push a hex when I hear some good news from HIL testers.
Update 2.2b4
Update 2.2b6
OK, 2.2b6 is on GIT. The Mission planner is going to be out of sync until the release code. until then you can use the APM_Config.h or the parameters list in the Mission planner.
STAB_D : This is the gyro accretion dampener. This can remove small wobbles during sharp changes in angle commands. Making this too high can have a negative effect in performance and add a memory effect that can cause temporary loss in control. The in flight tuning is ranged so you are just below that effect.
If you haven't noticed before the control loops are in two stages. The first is a PI stage that converts some sort of position or angle error into a desired rate. These generally do not need to be tuned. They are more of a user preference on how fast you want the copter to perform a motion.
The second stage is the actual PID loop that needs to be tuned for the copter. This converts the desired rate into a motor command of some sort. I added a D term based on Igor's recommendation to the PI's for each rate controller. These should show up soon in the mission planner for the release. I cannot give you a concrete answer for how to tune the D terms, because they each depend on their function such as alt hold or loiter, etc.
Still, the absolute most important term is always the Rate_P term for each loop. Start tuning here.
The default PIDs are in the what flies great for a stock jDrones/3DR Quad with the purple motors in X mode.
Thanks,
Jason
Replies
Actually, this is not a bad idea about just releasing a silo'ed version of APM code. We could have a version that just has stability code, so that it's less monolithic, and more people can participate without wading through all the extraneous code not related to flight control. If a standard API is maintained, the code could be easily plugged into the main stream, and we would never tweak that code in the main stream. This could make for a more stable main stream code.
Evening, I test loiter mode code 2.2xp2 PIDT1. It's very stable in no wind.
Well today I planned to go out and thrash b4 down the park, but the niggling idea that I'd not tried Igor’s PIDT1 control made me hesitate.
Long enough to downgrade MP to 1.1.28 and slap Marco’s cleaned version of the PIDT1 on my APM v1.4
I set all my I and P values to zero, then upped my RATE_***_ D values to about 0.015 (I was seeing oscillation at 0.030). Then following the instructions i upped my rate PI params (for my frame p=0.09, I=0.045 felt about right) For info initially I found it hard to replicate the oscillation point, but discovered that if you get the quad above your head and throttle up to hover point then tip the quad right up (90 degrees - so one leg is pointing straight at the floor) the oscillation point is much easier to judge and replicate.
Then i upped the STAB_***_P, starting at 4. Immediately the quad feels rock solid, very natural corrections, no oscillations. So i kept upping STAB_***_P, i got as far as 12 before I'd gone too far. At 12 the response is almost scary, the quad feels so locked in, it’s starting to look like those ones the Pennsylvania state university play with https://www.youtube.com/watch?v=MvRTALJp8DM if you’ve not seen it. Check out their other vids too!
Anyway – left alone its almost motionless aside from being gently pushed around by the swirling winds in my 3m*3m test space, if i pushed a leg up it would correct so fast and without moving a millimetre in the sky – it looks almost tornado proof! Stick inputs at this level did cause slight corrective oscillations so I've back down to a STAB_***_P of 10. I'm in awe - its like a totally different controller.
I've read what some of you have said about the type of control loop mechanisms that will be best in the end and I'm afraid i don't have the wisdom to comment or help merge or construct the next version. But I do strongly agree that we should have a platform that is highly stable before we allow it to carry out autonomous maneuvers, and this is by far the most stable I've seen it.
I will of course try to tune b4 with a similar methodical approach for more objective comparison but for now I must give this thing a try outdoors.
A few questions;
Was there a solution to the initial oscillations?
Why are the IMAX values posted by Igor so vastly different (1500 instead of 15 for STAB_ROLL for example). I've not had the bottle to up my values that high in case it’s a misprint)
Does anyone know any good reason why I shouldn't take this outside to test and tune ALT_HOLD and Loiter?(far away from all, ‘Dead Or Alive’ at top volume of course :) )
Hi, today I tested the 2.2b4 and the tune don´t work for me I can aktiviate it, but if I cange in CLI CH6 and take a look on the test --> tune, the value is all the time the same.
On the beginning of 2.2 it works I have testet Tune 12 for loiter?? and Tune 4 both do not work the value will not change in the cli
I hope somebody can help me
Tune 4 appears to make no difference to flight.
I can confirm Ch6 is varying from 0 to 1.5 when running test(tune) in cli.
Is tuning broken ? Trying in both Stab and Acro
Damn, Marco, what a bummer ... Please please keep your spirit high!
I am a less experienced flyer (no purple board, flying beta code, etc ...) yet have been following this page from page 1, and have been fascinated, admirative, and so thankful at the dedication and progress made by all beta testers and developpers, and you in particular. Ironically, I was so impressed by some of the last videos by you and Jean Louis Naudin that I thought "this is it! you guys have nailed it!", and was about to ask you, given your extensive experience with MK, wether you thought Arducopter was now up to par ... Well, I guess I don't need to ask anymore ...
That said, as you yourself have said (and Bill Gates once said after getting a blue screen of death in a widely attended conference demo): "Well, there is a reason this is called a beta version" ... And this is just one of these inevitable bumps in the road.
Again, keep your spirit high. Hope you can get flying back very soon, and keep seeing you on this thread. You guys are true leading edge pioneers.
Respect, man. Best wishes ...
Hi Marco my condolescence too for you and for your quad. I saw your video and the others and I suppose an hardware failure.
In your video, you flew and when it happens after the turn It seems to have a fall down of the right front motor, ( Esc, motor, solder ??), than AP on the quad try to compensate the drift, with only 3 motors it try stabilize rising the stopped motor and rising the other two (front-left and rear-right) too, of course Ap try slowered the rear-left motor.
A good tuned quad with 2 motors opposite rising, may have a semi-linear flight, with the stopped motor arm in the back side. A flight like a stone (up and down) show like with Ap in full trying compensate the drift didn' allow you to use the tx imput (just a little maybe) to recovery the quad, and it flew down like a stone.
If my suppose are right, you can find the motors behaviours in the log to catch a fast rising motors FL e RR when RL motor no.
Maybe a solder with high Amp draw became hot, and the solders wires may have an hot temperature too, with vibrations If happen a short open circuit, it reset the esc in flying, and when it connect again it find no correct trottle to inizialising himself. The rest it's story :)
I hope my suppose can help you to investigate.
Good work in your testing way.
See video about my IMU's gyro/acc sensor after the crash.
... "you spin me left round, baby left round like a record, baby left round, round, round"...
It's the same song but played in reverse! :-) DAMN!
I just want to thank all of the programmers, artists and electrical engineers who brought this project to fruition. I am aware of many other UAV control systems out there, but none have a support group and the comradery I have seen here. I feel quite proud to make use of the works created here at diycrones. Again, thanks to all for the hard work. Thanks for the excellent documentation as well! I have been able to pick this up fairly well, in about 2 weeks which isn't bad (I don't think), considering the vast amount of information one needs to get their multi dialed in! I now am eager to gleam the experience from all the long time users here who know what they are doing.
I have years experience flying airplanes, but I never liked choppers. I would always watch those guys fixing their airframes more than they flew them. These multi's are frankly simpler to build than many airplanes and cheaper also. I am quite excited to grow within this hobby. I am also glad to be leaving the US in about a month and going to Mexico, where they haven't made flying drones criminal, and if they do, well there, it's only a small payoff to get out of jail cheap...
For the weekend...
If someone whats to fly the nice code "ArduCopter_2.2ß2XP2_PIDT1", while waiting better times, I leave my params for both small and medium size copter (650gr and 1kg respect.) They are quite similar in base:
The big one: (see flying in http://vimeo.com/35715703)
The small one:
Notes:
- the Loiter in big one (Loiter_P=2) is OK. In small I´ve used 0.3 since it went well enough, but can be increased a lot without instability.
- max limits can (must) be increased a lot to let the code work. Use the ones of the "big"
Hope this helps
2.22XP2_PIDT1_afernan_small.param
2.22XP2_PIDT1_afernan_Quad big afernan.param
-
4
-
5
-
6
-
7
-
8
of 22 Next