ACRO bug (fixed in 2.9.1b): while doing flips in ACRO mode, if you switch to Stabilize while inverted your throttle will go to minimum. To regain throttle control you need to switch back to ACRO then back to Stabilize again (i.e. switch to stabilize twice). You never lose control of roll/pitch/yaw.
Loiter/AltHold/Auto/RTL bug: if you switch into these modes with throttle at zero motors will go to minimum until you raise the throttle.
Auto mode altitude bug (fixed in 2.9.1b): setting a waypoint altitude greater than 320m over home altitude may wrap around and instead be interpreted as a low altitude.
ArduCopter 2.9 is now in the mission planner and the downloads area!
The major improvement is we use inertial navigation to improve altitude hold. This increased reliance on the accelerometers means you must do some additional set-up before flying:
3. If upgrading from 2.8.1, modify the throttle and altitude PID values:
Here is the list of major changes (a more detailed list can be found in the release notes):
As per usual PIDs are optimised for the 3DR/jDrones quad with 850 motors and 10" props. If you're using more powerful motors/props and are seeing bad flight behaviour in stabilize, start by turning down Rate Roll P in 25% steps.
Special thanks to our testing team lead Marco and the dedicated bunch on the 2.8.1 release thread who put their copters at risk while testing the pre-release version. Some of their videos are here: 1 2 3 4 5 6 7 8
Please feel free to report issues you find in the discussion below and/or add them to the issues list.
Maybe a stupid question to developers.
The loiter speed is default 0,200 = 25cm/s.
How can all this "fly away" appear in so much higher speed?
During testing period (could be long) why not have a kind of maximum speed (like slow) so these fast flyaways would be more slow motion.
And what about a kind of limit on one direction and than trigger direction the opposite way, and so on?
Also an absolute altitude limit.
When final release is ready i think i still would prefer the above ;)
Correct me if I'm wrong but I believe you can set max speed, altitude limit, and a geofence. I don't think I would want an automatic trigger in the opposite direction because the opposite direction may be a tree or a house.
Better than a fast fly away I mean.
I know u can set those limits but obviously they don't LIMIT, I thought maybe it's possible inside code to make some absolute rules some way.
Strange problem just developed.
Had a couple of flights this morning all ok. Came back after lunch and the MP was showing 10deg right bank. Did the accelerometer calibration many times but the bank just stays there. It flies but needs a lot of right stick.
When first powered up the MP shows it level but it quickly banks right again.
I just test on the evening. loiter , ALT Hold and Guided are very Perfect. And, Smooth adjust Throttle.
Good news my quad is flying again. Luckily the damage was limited to 2 broken engine mounts, one slightly bent bell housing and a busted ESC.
I changed my THR_ACCEL values as recommended and she was much more calmer in ALT_HOLD without the sonar. The quad did however have a tendency to slow rise in ALT_HOLD. Should I lower the values even more or would that be a different parameter?
Attached is a short log file. I included motor logging this time. Z values still look good even with the slightly broken main square...
Since the loiter speed is more or less matched to the requirements of the nav controller, setting to a much lower default will add to the average person's tuning tasks. I think a more direct approach could work out better; disable all auto modes by default, including RTL and autoland. We're not supposed to use auto modes until basic tuning is complete anyways... no sense in having them potentially active during the basic tuning phase.
Actually isn't there 3 "home locations" technically speaking? I noticed when my GPS first gets a lock, APM sets a "home1", if you will. My OSD uses this for it's distance and direction from home display. As you stated, MP also sets a "home2", which seems to only be related to MP distance from home and way point altitude calcs. Then there's the actual launch position, which I will call "home3", that is set when you actually arm the copter. This mix of home locations results in confusion.
With regards to RTL... here's how I believe it works. Typically I plug in my packs at "home1" near my GCS, and let the GPS warm up. After GPS lock, I walk typically 50' or so away from my GCS, and arm the copter setting "home3". Therefore, after a successful RTL, my OSD home arrow always points toward the GCS and shows it the correct 50' from "home1".
Now with automissions, RTL still uses home3 for the landing point, but refers to home2 to set altitude. So if I have waypoint bits set at say 20m in MP, it may fly at only 3m altitude in reality if I buggered the Alt(abs) setting in the MP home location field. I don't know how the lat/long of home2 comes in to play, other than the calcs MP uses to show you how far a waypoint is from the MP home location... which as mentioned is not the same as home1 or home3.
All in all this is more confusing than I think it needs to be for 99% of our applications, where simply referencing home2 is all we want and need. Bottom line is air density changes day to day, so having an absolute reference is far to "scientific" and likely to result in alt errors with auto missions. I admit I'm a total newb with APM, but I work hard to learn what I'm doing with it. I still haven't figured out how to get an automission to fly at the exact altitude I want. Yet RTL always hits it's altitude mark precisely... setting auto altitude should be that easy IMHO.
So I vote that the default auto mission setup refers to home2 by default. Also, the wiki talks about an "ABS checkbox" right? Since dealing with variable air density makes ABS less useful for most, and we can't seem to turn it off with said checkbox... I think it should be removed to avoid confusion and wrong altitude auto missions.
Oh yeah... I almost forgot there's also the tracker home, a 4th location point which seems to be rarely used. With FPV we're going to see a lot more action involving tracker location I think. It would be simpler if home1 = tracker location by default. I think the way most folks operate that would work out well. I bet folks setting up elaborate dispersed GCS missions can figure out how to do that on their own. ;)
Ripped out the Sonar again and that stopped the leaps and plunges as it transitioned from Sonar to Baro hold.
Used Loiter to mess around flying FPV again.
While Loiter worked well enough, the quad wiggled around like spit on a hot griddle. No good for filming anything.
Is it best at this point to wait for 2.9.1 or should I mess with a PID to calm it's Meth-Head squirming.
This looks like a motor out. I had this happening to me and it was caused by the wires in one bullet connector breaking off and forming an intermittent connection. I did three flights before I found it and it gradually got worse. It could also be the connection to the APM or a slipping propeller.
The reason I don't think this is a problem with the APM but the ESC/Motor is because the error on Roll, Pitch, and Yaw all support one motor failing for an instant.
Make sure everything is tight and check your vibrations.
I am now getting this issue repeatedly on one motor and also believe it is a barrel connector. Is there any reason I should not solder the wires and throw out the connectors? Those barrel connectors to the ESCs seem like a good place for problems.