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
You know I get the point of some people. The PID tuning requires a lot of expertise. It's not intuitive.
I think in order to solve this problem for people who are not experts at flight control, which I am not, is to create a more intuitive interface for tuning the drone to the specific characteristics wanted without knowing the PID internals.
For instance my last build was the mini firefly frame. I'm running with motors that I normally use on a full size frame. So I just dialed down all the P stability numbers to 80%, because in stability corrections were to aggressive. Right now I have to go to each P value for stability and put in the value. But, if the interface was more intuitive, I would just specify a scaling factor of 80% because my frame is smaller than a 3DR default frame. If we add an interface to apply a scaling factor, this would be more intuitive for non-technical users.
Then besides the size and power of your motors, relative to the stock frame, there's the flying characteristics. I fly indoors, so I want the drone to be more stable than aggressive, so I also dial back the throttle P value, otherwise it's too responsive. So a more intuitive interface here could be a slider widget to adjust aggressiveness.
Unfortunately, the way mission planner is made and changes in the setup interface, in terms of adding and removing parameters needs a change in parameters file format, and introduces backwards compatibility issues.
But I think a more intuitive interface would be the way to go, even at the cost of breaking backwards compatibility with parameter files.
This thread now has 1024 comments. That's crazy.
Hi all, I've been gathering data from the posts and creating an excel sheet with the more relevant data of posted configurations and PID settings as well as oppinions from the users and tested firmware versions. I think this might be usefull for PID dummys like me and rookies who are starting to have a initial starting point to tune. I think this may also be a good tool for the dev team to collect reports and testemonials and help on decisions of what paths to follow. I liked this sheet to be updated by each one of you guys who know your machines better than anyone else, I will be updating as I read in here tests beeing made. There's a lot of fragmented data wich may be very usefull if gathered and organized. If you have new test data and want to report, if you can, send me a message with it and I'll try to keep the table up to date. If you have any suggestions on additional fields or so, please let me know and I would like to know if this looks helpfull and usefull.
flying configurations.xlsx
HEY DEV/TEST TEAM! GIVE US A HELPING HAND!
Now I know that putting stuff in capitals is often seen as rude, but I am really bemused by what is going on in this forum. According to Chris Anderson, there are some 10,000 APM1 boards in circulation, but only about say 30 people on this discussion commenting on the very latest releases of code as they are developed. Most seem, like me, to be struggling with it. The most prolific members of this discussion are those like Marco Robustini and Jean-Louis Naudin, who are actualling developing variants of the code because of shortcomings that they perceive. They are very helpful to those who are interested in their variants, posting example PIDs and hints on approaches to tuning etc. I, however, have taken a different tack, trying to use the more mainstream codes, either those still in development and/or those available as the default in Mission Planner. My contribution has been to post observations on using those releases, as a sort of contribution to the test effort, and also post my PIDs when I approach anything resembling success, or at least improvement on performance from the defaults. I have also made suggestions on potential improvements to the functionality, in layman's terms at least. Finally, and repeatedly, I have asked that the dev team provide some guidance on how the PIDs etc. actually work with the newer code releases, because the Wiki is out of date. And what feedback have I had? Nothing, nada, not a damn sausage... It is not surprising to me that I am not alone in struggling with the mainstream codes when most of us do not understand how it all fits together. The result is now that this discussion is talking about spamming the dev team to include code variants that people have got to work, because of the information exchange that is taking place on this discussion. The lesson is that if you want people to use the official code and get success, you have to provide information on how to use it. That way, you will also get feedback, good or bad, on how it performs which should inform the development process. So come on, let us in on the secrets! Honestly, having spent too long in IT services, if my company pushed changed software out to users without guidance as to how to set it up and use it properly, as the rep on the ground, I would have been lynched.
Now as it happens, I have had some success using 2.2b4 today. In light winds, but I suspect considerably stronger at altitude, I had some pretty good loiters, and managed to reduce the being blown downwind effect that I commented on yesterday. Just in case it helps anybody, I attach a .jpg of my current PIDs (notes - I have had Loiter D down to 0.1 at times, around 0.13 to 0.15 seemed best in some wind, bumped it up to 0.2 in no wind at dusk to inhibit wandering. Also, yes my Stab Yaw P is very high, but I am trying to use a zoom video camera and I need it rock solid). The main change today was reducing Cross Track Gain (whatever that is) to 0.5. I have no idea if this combination of PIDs makes any sense, but they work better for me at the moment. I also attach a .kml of a typical reasonable loiter (where the bulk was in a 10x8m box, in wind, 240m trace, over about 4 minutes) to prove that it is possible.
Some more observations - RTL was as if it was being piloted by a drunken sailor at times, lurches from side to side, speeding up and slowing down - odd. I also gave auto-land a go - it landed about 20m from the arming point, and bounced, engines still powered up. As it was in a field with tussocks of grass and I have long spindly undercarriage, I did not want a flip, so flicked it back to Stab and powered down. That function is not critical to me, but nice to know that it is there as a failsafe. Simple - saved my bacon a couple of times today, although as a heli pilot I have to remember to flick it off when the copter is close enough to see clearly, as otherwise I start flying it "properly" and get completely out of shape. Guided - entered an altitude of 40m, but it did not seem to kick in until it flicked itself to Loiter mode and started climbing.
Will plug away again tomorrow, but I really would like some illumination so that I am not randomly floundering in the dark - otherwise I might give Marco's code a go. All the best, Bill
3DR APM 1 board FW 2.2b4 BJ PIDs 20120128.jpg
2012-01-28 01-09-04.tlog.kml
Ok, I have to ask:
Why isn't PIDT1 just accepted as the new official code? Call it 2.4 and lets get on with fixing whatever else needs fixing before this comes out of Beta? Am I missing something? Is there a problem with the PIDT1 code? Every video I have seen is brilliant.
Is there a problem with the code?
I understand that Jason made some improvements on top of JLN's autoland code, and that's great.
And I'd love to see Jason's Stab I implementation on top of the PIDT1 code, do some objective back-to-back testing. It'd actually be easy to do by just making the I term 0. Try hanging some weights, etc.
But other than that... I don't understand why it's not accepted as the next stable Beta release?
MP 1.1.29 - HIL mode doesn´t read GPS data from sim
Using Smulation, in HIL mode (arducopter 2-2b4 fw) and connected to simulator (AeroSimRC) doesn´t read GPS data.
Doing the same in MP 1.1.28 and earlier, it does.
Allready reported this issue as "issue 501"
Angel
If you want to remove the initial wobbling when takeoff with PIDT1 try this Igor's trick (i've not tried, I ran out of the quad):
as I understand it comes from the code part around line 1531 in
ArduCopter.pde:
if ((millis() - takeoff_timer) > 5000){
// we must be in the air by now
takeoff_complete = true;
land_complete = false;
// reset these I terms to prevent awkward tipping on takeoff
reset_rate_I();
reset_stability_I();
Try to remove the else part that the code looks like this:
if ((millis() - takeoff_timer) > 5000){
// we must be in the air by now
takeoff_complete = true;
land_complete = false;
Resetting the I terms changes the control charackteristics! This wobbeling has nothing to do with the PIDT1 itself.
And caution: I didn't tryd this modification in the reality, first remove props for try this, simulate the takeoff with your hands and lissen the rpm of the motors if are stable!
I just had a lockup - looked exactly like Marco's!!!
I was tuning my hexa in hand and after about 10 tries, one motor stopped for an instant (it was right in front of me) and then it just went something close to full throttle and wanted to escape! It didn't react to stick input at all, no disarm. I managed to disconnect the battery without any damage but it was VERY scary. Looked as if I gave it full throttle and full pitch back and roll right. I never had a lockup before so it was quite a surprise. The only hardware change I've done recently is relocating my sensors and changing props - it is vibrating a lot (still) and I was changing PIDs heavily during the hand test.
Telemetry was connected but I'm on a completely different platform and I had RC disabled because of bandwidth - but I attach it so you can take a look. Everything is still intact and I can try again if needed - but I'm not sure how useful it may be (I can't make onboard logs). Was it some kind of overflow because of the vibrations?
2012-01-28 06-10-49.tlog
Today, I have done successful real tests flights with the ArduCopter v2.2 B2 PIDT1, with the "famous" Igor's PIDT1 mod and some JLN updates. You will find here my tested firmware with all the PIDs details about the real flight and HIL tests on AeroSIM.
The flight is very stable, there is no wooble during the take off and during the flight. This is perfect, I am fully agree with Marco and Angel...
Below my PIDs setup.
Regards, Jean-Louis
Hey Dave, I got into this late so, I don't have Johan's log. But, reviewing Marco's log again, and taking into consideration his inputs, it still seems to me like there was a point that the input signals went haywire for a short time. That's the point where he raise the throttle. He lost response, but then came back at which point it was too late to recover.
-
3
-
4
-
5
-
6
-
7
of 22 Next