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:
If you run into any problems please let me know here. If you find a reproducible bug, please add it to the issues list.
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.)
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.
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.
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.
Nice Ellison, do you think a problem in the receiver or in the ppm encoder?
Personally exclude, i'm trying now, and the receiver does not see any abnormal input (in the planner), anyway the OilPAN has the artificial horizon that continued to rotate on itself after the crash, very bad... OilPAN R.I.P.
From the telemetry I see exactly the commands I have given on the first 4-channel input.
At some point I moved all of them randomly to see if the quad took a few commands, you would not want to confuse those moves very fast, my thumbs were mad! :-)
At this point he started to drift left, and I do all the aileron right, the commands are correct it seems to me, I see no fault here, see image...
Impossible to say, since we have no diagnostics on the decoder chip. But I saw also that yaw was solidly at 0 during this period too. The only thing responding was throttle. I would be surprised with operating the throttle in an emergency that even an experienced pilot can keep the yaw that solid.
I've never seem an rc radio be able to only send one channel, and have all the other go haywire like that. My wild guess would be some issue with the decoder chip. Was this an APM2?
APM1 here... about yaw yes, given that the quad has taken flight in the same direction while keeping the muzzle instinct and experience has taught me that we must act only on the throttle and ale/ele (my tx is in mode 2), that way keeping the quad always in that direction while trying to regain control.
Rx inputs are exactly the ones that I gave at that time, the problem I would look elsewhere.
Piloting helicopters and doing 3D are used to not touch the tail in case of emergency, provided that the elimination always keeps the yaw in "AVCS".
So, you were trying to roll left, pitch up, and yaw left, at the time of the crash? If that's the case, then the radio input was fine.
Absolutely, is correct, yaw left for disarm the motors!
That makes sense then.
My condolences Marco, but even this crash will help to improve things (hope that)
I´ll have a look to your logs, to see if I acn discover something.
btw, what is the last code that goes right in HIL with aerosim, for you?. I have problems in last fw.
Hi Angel, thanks for condolences, i hope this event will make even more robust AC (if is a bug code)!
What do you mean with "problem in latest fw" with the sim?
I've fly ß5 in the sim for an hour without problems, but you know that the internal controls of AeroSim offsetting any outcome in real flight.
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 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
I think this weekend I'll try any code... :-/
Nice video Angel, I've seen but now I look at it again!
thanks for the setup advice! With the heavy quad, what is your motor/prop setup?
I am looking to try this over the weekend and have a "fly-off" against 2.2b5 (may be backing down on that after Marco's post). It seems as if we have two diverging control developments going on, and I want to try and quantify the differences at least on my setup. I am way behind the times and still have 2.2b2 loaded :)