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.
I suggest take 2.0.49 ad the ic2 repair. Make it compatible with apm2 and we have a winner. That was the one firmware we all agree upon that was working. Everything later then 2.0.49 has been buggy etc.
Can someone please make a tutorial on how to do this? I'm a noob when it comes down to Arduino and programming.
It woudl be great if I could fly the 2.0.49 without sudden problems.
Well, this is not a tutorial, but tells you what to do to get 2.0.49 best features inside a latest code (in this case 2.1.0, but is pretty the same for any other). See attached file.
The latest work of 2.2beta and autoland is a bit of a tangent, but that's not even Jason that is doing that.
You could "rewind" to something like 2.1.1r8 which is what I'm using, and it's 100% stable. There are no bugs. It may not have been released as a stable version (I think it should be) but I've used it to fly a big heli for some time with not a problem.
It's also MORE stable than 2.0.49. I don't really understand the love affair with the old code. It was full of bugs. Maybe not fatal bugs, but lots of little things that made it not fly as well as the later code.
If I'm not mistaken many people had severe crashes with the 2.2 software.
I don't recall people reporting sudden crashes with the old 2.0.49.
So that's why I was asking about the old code.
I have to say I have flown the 2.2b2 code when it first came out and it flew fine was really happy with it. e .25 MP and loaded 2.2b2plus code base on same copter and everthing went wrong thats what lead me to believe that it was the code , not sure what else it can be but as Robert pointed out foam might not be enough for vibration but the only thing I wish we had was a code base that there was no confirmed crashes that we can load and determine between hardware and software problems if setup problems is expierance because right now there is now why to test this. I tried flying flight gear today and its very .... unrelistic to the real thing so not sure you can test it that way , maybe ill try AeroSim but its very expensive from what iv seen. I think ill try loading the .49 code base once my hexa is fixed .
So if Jason could maybe react to this and let us know if it is possible to rework the 2.0.49 code (I understand that there were 2 bugs, i2c library and I-term)?
It would also be nice if a software release is directly linked to a certain Mission Planner release.
So when downloading a certain version of MP you will automatically install a specific ArduCopter code that belongs with it.
There is no point in investing developer time in 2.0.49--there were countless bugs in it that have since been fixed, whether you noticed them or not. Yes, it was stable for basic flying, but it couldn't do autonomy nearly as well as the current code.. We'd spend all our time dealing with complaints about loiter box size, RTL issues and all sorts of things that we sorted out long ago in subsequent code. In short, it would drive us crazy and slow development for everyone else.
The best use of developer time is to make the current code as stable as possible. We have announced that there will be no more features added to the 2.x codebase, so at this point we're 100% focused on reliability and performance. I think we're very close to coming out of beta.
Was 2.0.49 that bad? I think a lot of people disagree with this. Also with the fact that repatching it is a waste of time.
But I'll have to take your word for it and wait for a stable version to come out.
I do have to say that if it takes too long for a reliable version to be released (more than two months or so), then I'm going to sell my board and I'm out of the ArduCopter story.
I really needs something that is flyable and reliable.
I hope you're right Chris, hopefully we'll have stable release soon!
Jo: have you used the current code? (2.2b4). What exactly do you want that it doesn't already do?
I predict that we'll be out of beta within a week.
Just to be clear, it doesn't need to be able to do more than it already can.
I only need alt-hold, loiter and RTL myself. And maybe Simple to get it back when orientation is lost.
Really that is it for me. But... it needs to be reliable!
I haven't flown the new code yet because I think it's a shame to thrash my copter just because I'm impatient. The last thing I want to do is using code that is still in a testing fase.
So I'm kind of waiting for a final release without bugs that can be trusted, haven't seen that yet.
Again, don't get me wrong. I appreciate what you guys are doing, I really do.
I just had more expectations from ArduCopter. So I'm looking forward to seeing a stable software release soon.
I don't recognise "2.2b2plus code base". I can only see "2.2 b2" and "2.2 b3" as firmware versions in the code repository. I must be missing something...