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
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.
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
2012-01-27 05-03-35.tlog.kml
3DR APM1 FW 2.2b4 BJ PIDs 20120127.jpg
Crash in a long distance with ArcuCopter V2.2ß5 (unrelease version), all the story, video and log:
Hi all! Today bad news from the airfield, my quad is no longer responded to any commands and flew away, crash far from the home point with all the motors at high rpm.
Rest assured, this version was released only a few tester like me.
While flying away I tried to insert RTL and AUTO but nothing to do, ignored by quad, but not by APM, all my mode changes are logged.
For those who do not know the AUTO mode works like a sorta of RTL if you haven't stored waypoints before takeoff, just a little difference with altitude because take this from the planner (100 meters with the latest planner).
The problem is still to be investigated, I think this will be delayed the release of ß5, unless it is shown that it take a problem to my hardware and not with a new implementation about "Stab D/DD" inside this beta/tester code.
A little first analysis shows that the APM has always taken my commands, even after the crash, in fact when I thought that the quad is crashed on the gound had already disarmed the engines, and when I found it was okay, disarmed, electronic work fine, no bus lockup.
It's much more likely that there was a problem in the code, but it is to be verified, it is too early to tell.
For now no more, unfortunately i haven't other quad to make other flight test with real flight, in the crash have destroyed 4 motors, 4 arms and 4 props, and electronics I have to check if that is ok, as well as the esc.
However, from what little I could ascertain the ß5 not work well in the fly, reflects the problems that I have written several times, while the "PIDT1" mod by Igor (wobbling except for 2 seconds after take-off) is like a dream.
I hope that the development team takes account of my comment and the positive feedback about "PIDT1" from other friends like Afernan (has recently published a really nice video about this), JL and Duran.
I will stay out of the scenes for a while but we keep you updated!
Bests
Marco
5_crash_logs.zip
Observations flying 2.2b4, stock 3DR, APM1
Rain has stopped play for the moment...
I have been struggling with the 2.2 releases, but feel that I am getting closer in windier conditions. After a frustrating start this morning, I semi-randomly was changing PID values and by happenstance as much as anything else, started to get some results. However, I still do not think that any of the 2.1 or 2.2 releases cope with wind well. In any but the lightest conditions, the quad pitches back once loiter is invoked and is blown backwards some considerable distance. Sometimes it struggles back to the loiter point, other times it settles down into a reasonable loiter, but say 30-50m from the loiter point and other times it seems to start heading back and then gives up. On my last flight, I ended up with a pretty good loiter in a 10x12m box, but that box was 35m downwind of the loiter point (.kml attached). For that last segment, I had Loiter P at 1.6, I at 0 and D at 0.4.
I have made the suggestion before that if the quad is relatively static, but has a pronounced attitude, then that attitude should be held if loiter is invoked as that would help prevent these pitch changes on mode changes and the unnecessary separation from the loiter point. Alternatively, if there is something I can do in the configuration, then I am all ears.
I don't know what is going to be in b5, but please can we have the appropriate guidance on the configuration, PIDs, relationships between them etc. so that if there is a different strategy in place, I do not have to randomly find combinations of PIDs that appear to work some of the time, which is what is happening at the moment.
I have some ideas on how such advice could be disseminated, and how people could submit their hardware and software configurations to enable data and trend analysis to take place which should help the development and testing streams - more later. Regards, Bill
2012-01-27 02-56-52.tlog.kml
Please, is it possible someone can take a look at why the HIL sim in Flightgear is not working properly? I would like to use it to try out some settings. I did place a post on this in Simulation a few days ago, but not one reply on it. Thnx in advance
Bad news from the airfield when testing ß5, no more tests here for a while LOL):
After two minutes of "not good fly" with ß5 (i'm sorry Jason but for me it doesn't work fine like "PIDT1" and there comes even remotely in flight model), i've total lost the control of my quad, motors at high speed in orrible crash in a long distance.
4 arms broken, 4 motors, 4 props... I have yet to verify the electronic and esc.
I think ß5 release will be slightly slip, unless the problem is actually caused by a problem with my quad hardware and not by the beta code.
Some hours and i put video and logs here.
Tester, stay alert...
Marco
Hey
After long cold Test day i must say. APM is not working for me. I dont know why, but i cant get it stable. My Hexacopter has 2 Modes: 1. crispy and very accurate to my stick inputs, but heavy wobbling. Not possible to get it stable and fly safe. 2. with less rate_p its so sluggish, that the APM is not responding to my stick inputs.
https://www.youtube.com/watch?v=XgDLUgaZMK0
At the Moment im at a point, where i can say, i never get my Hexacopter stable with APM. i tried all, all u can do - like hours of PID Tuning, all possible Software Versions... but doesnt work. Yesterday i tested the Alt Hold and RTL function. Doenst work to.
https://www.youtube.com/watch?v=jOgUtLF4sBU
And here my PIDs
Hope u can help.
Anyway to get rid of the wobble and/or spin on first takeoff with ArduCopter_2.2ß2XP2_PIDT1? It's only for a few seconds but disconcerting nevertheless.
ArduCopter_2.2ß2XP2_PIDT1 complete set of flight test
I´ve performed a complete set of test (7 batteries) on this code. Really good in all.
http://vimeo.com/35715703
PLEASE note that the tri version 2.2b4 does not work! Loaded through MissionPlanner and Arduino; both ways do not give any TRI_YAW servo outputs (CH7).
Downgraded to 2.1 and everything works well.
Had a quick look on the code, but cut not find a reason (newbie). Maybe something here (that's the new part in 2.2b4 vs 2.1)
#if CONFIG_APM_HARDWARE == APM_HARDWARE_APM2
/* TODO find out correct channel for APM2 TRI_YAW */
# define CH_TRI_YAW (-1)
#elif CONFIG_APM_HARDWARE == APM_HARDWARE_APM1
# define CH_TRI_YAW CH_7 #endif
I have the blue APM with the 2560 (I guess it is V1?)
-
5
-
6
-
7
-
8
-
9
of 22 Next