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.
My APM1 is mounted with four gummy dumper, used the same system with my Mikrokopter board.
Robert, have you found something wrong in the log?
Yes, was it facing East, I checked now and in the movie is correct, although obviously you not know my flying field just looks at the position of shadows.
Marco, what is a gummy dumper? Not a technical term that I am familiar with?!? Bill
Thanks, interesting. Not sure that I have enough head space in my stack at the moment, but a good idea. Bill
But the tune "Bye Bye Baby" while the quad goes away is a touch of class ... huh?
"Tragedy" by the Bee Gees might have been more appropriate!
Some more observations on flying 2.2b4, stock 3DR, APM1 board
After the rain came a calm dusk, ideal conditions really. I was surprised though to find that all too often the quad slowly wandered off when in Loiter mode, as if it did not "want" to loiter or get back to the loiter origin point. Eventually though by fiddling with the Loiter PIDs I had a nice smooth tightish loiter against the gloom of dusk (second loiter in the attached .kml). It may not have been a 1m DJI WKM box, but the bulk of the trace is in a 6x5m box, with a total trace of 115m over about 3.5 minutes. It looked great.
It will be interesting to see how that configuration stacks up against stronger winds tomorrow. If it doesn't then I will be back to slightly random tweaking to find a reasonable compromise of smooth flying, tight box and actually staying somewhere near the loiter origin point. It would help if I knew what I was doing - can anybody enlighten us on how the PIDs work on the current code? If anybody else is struggling, I attach a .jpg of my PIDs as a starter. Bill
Hey Marco, too bad about the crash. But, clearly not due to your flying.
What I noticed by the logs is the following:
1- Towards the end, the roll input dropped to 0, an pitch input maxed out to 4500, and stayed there. Either the APM was not reading the channels properly or the radio was no longer send the proper signal to the APM.
2- You still had throttle control, until it was chopped down to 0 to bring the quad down. Good thing or else may have flown out of range.
From this it seems that this may have been either a radio fault issue or a problem with the APM reading the roll and pitch channels. Given that the radio input was going haywire, it's not conclusive that this crash was caused by any of the flight control changes, imho.
Thanks for the analysis Ellison!
I think in the first part of giving full throttle to try to take it on view and I inserted the RTL but was ignored.
It's obvious that I tried to take him at high altitude, was about to disappear behind the structure we have in the field.
I just checked the channels of the telemetry receiver, and I think that all inputs are taken, from first to last.
I think you can understand more from the internal log, since it is complete, while the telemetry seems to have stopped reading the flight of the quad when he went too far behind the abandoned house that you see in the video.
I know this is out of topic for this tread but I am interested to see the damages done on the X525 frame...
do you have any picture?
Hello Dany, of sure, take that! :-)
The two arms that look straight are bent at the base of the frame.
Of the four engines, two do not run at all, and the other two that seem healthy but the crooked tree.
But the worst thing is that I have discovered now that the OilPAN went crazy, after the crash i mean.
The pitch and roll inputs go haywire before the loss of telemetry. So the tlogs tell it all. Even during the loss of roll and pitch input, the throttle was behaving fine, according to the logs.