Version 2.6 of the ArduCopter code is now available in the AP Mission Planner and in the downloads area!
Updates to MavLink 1.0 means you will need to use "ArdupilotMegaPlanner10.exe" to connect. If you've updated your mission planner recently you should find this executable in the directory where the mission planner is installed.
The above video is done using a prototype 3dr ublox GPS which seems to have better accuracy than the standard mediatek.
Improvements over 2.5.5 include:
- MavLink 1.0 support (use with ArdupilotMegaPlanner10.exe) [Tridge, Craig]
- Stability improvements especially during level hover [Jason]
- throttle range improvement (higher min and max) [Jason]
- improved standard Loiter PIDs [Alan, Heino, Jason, Angel]
- dataflash erase speed up ('+' messages removed but it only takes 6 seconds now) [Tridge]
- Copter LEDs [Robert Lefebvre]
- RTL loiter stage target set to home to improve final landing position [Jason]
- flip & acro improvements [Jason]
- circle mode target improvement for ground station [Jason]
- Auto Approach [Adam Rivera / Marco]
Bug fixes include:
- UBLOX driver fixes (lock should now be more reliable) [Tridge]
- enable mavlink messages during dataflash erase which resolves issue in which new APMs fresh from the factory appeared unresponsive [Tridge]
- proper printing of lat/lon values in dataflash logs [Randy]
- removed duplicate GPS reads [Jason]
- resolve flooding of telemetry link with low-battery warnings [Tridge]
- RTL bug would land if rtl_approach_alt was more than 1 [Jason]
- WP Radius could not be set larger than 1.3m [Jason/Randy]
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.
This time we spent some time optimising the loiter PIDs. Tuning loiter can be tricky so please refer to the discussions which will appear below for more community feedback on what parameters work best.
All feedback welcome below. Enhancement requests and bug reports can be put into the arducopter issues list. When possible please include logs (tlog and/or dataflash) and tell us whether you're using APM1 or APM2 and what version of the software you're using (presumably 2.6 but tell us anyway!).
It just keeps getting better :-) Congrats to all the developers
Is the optical flow sensor supported in this version?
Sure Jonathan, just load 2.6 via MP ;) I am using stock defualt settings, have not changed anything.
I've just had a play with the tri 2.6 in the lounge, concentrating on yaw.
At stock settings stab_yaw_p 7, rate_yaw_P 1.3. I get serious (90 degree) oscillations but only after a yaw input. Say I'd yaw 90 degrees and let go the nose would bounce back at least 45, then back again, slowly reducing until it settles at the mid point.
So I chnl6 tune stab_yaw_p, the lower i went the better it got, I have ended up at 3, this gives me quite slow yaw, not too bad though, but no bounce back, it just turns on input and stops where it is when i let go. I've yet to try this in wind though, I fear i may need more to stop the tail being blown around. We'll see when it stops raining.
Robert you mentioned that stab_yaw basically controls the rate_yaw at the moment, could you elaborate a little please? Once I'd settled on my low stab_yaw_p, I tried tuning rate_yaw_p but found anything below 1.3 slowed it down, and anything above made it unpredicatable.
Conclusions so far, I have to lower stab_yaw_p to 3 from 7 on my tri (with a shoddy tail servo) to stop bounce-back oscillations after a yaw input. This does have the effect of slowing the turning rate down, could this be seperated? And also I wonder if I will be able to increase my stab_yaw_p once my new superquick digital servo arrives.
I'd include some logs, but mine don't seem to be working (i got two logs from 2 batteries, each one only going as far as APM initialisation.)
EDIT: I should mention that i tried all of this fiddling about with and without the compass enabled. Results the same.
Wow! Just tried rtl and watched it land ON the takeoff spot. So far, I have had only 1 bug-
I have had this happen several times. I load a mission, then fly around, and at some point the mission gets corrupt. I did have good missions if I loaded and then flew right away,
Typically I load something like this-
After loading, I can read waypoints and it is fine. But after flying a couple batteries, it looks like this-
Is this happening when I change batteries? Or (I do have ch7 waypoint save enabled) is it getting a phony ch7 at boot? I will disable ch7 and try to duplicate.
I am confused as to what ch7 does to an existing mission - is there a way to clear the mission and do a new ch7 mission without a laptop?
Fantastic job, devs! 2.6 is absolutely amazing. I'm dying to give it a solid FPV test! I'm still having a problem though that keeps my confidence low.
I had initially thought my twitchy/jerky pitch problem (http://diydrones.com/forum/topics/tricopter-occasional-but-often-dr...) on my tri had gone away, as the first 8 minutes of flight with 2.6 release were rock solid. Near the end of the battery life (I get 10-11 with the 3.6Ah battery I was flying) it started happening again. Very slight, almost imperceptible, until just before the batt levels got low enough that I shut it down.
At that point there was one very visible, but not destructive twitch on the pitch (tail jerks down as if I flicked the stick). I just flew a full 5.8Ah battery (17 minutes of hover) and about half-way through I started seeing twitches, mostly in pitch but once or twice in roll as well. As I posted as a comment to my problem thread above, it seems to happen only if I'm putting tiny corrective stick movements to maintain location in hover. If I leave the sticks alone, I never see the issue (nor do I see it when aggressively flying so far).
I removed every single piece of non-essential gear (all video TX/OSD, second BEC for powering input rail, telemetry radio, etc.), I swapped channels on the TX/RX, etc. tuned pitch rate_P from 0.8 to 2.5, removed _D, etc. and nothing eliminated the problem.
Any thoughts? I'll record some video of it happening and capture a tlog of the same event and upload it to the original thread. I had a bad crash due to a very violent twitch that brought the copter down hard and I've been terrified to go higher than 6ft since.
just coming from the field. My quad (2560 APM1, V 2.6, standard Arducopter kit V 1.1, wind 8 knots, no pids tuned) was flying amazing.
I tried ALT_HOLD and RTL (without landing) and SIMPLE mode and it was a pleasure.
Throttle stick feels really good!
Nice to see, how the quad recovers yaw after some aggressive manoevers in SIMPLE mode.
Thanks guys for that great firmware!
Sound like you've eliminated most of the tuning/code issues, through the tuning you've done Could it be a motor getting hot and faltering? Have you done a quick battery change to see if it still does is at the start of the second battery?
ACRO with 2.6:
this flight mode requires considerable experience and perfect control of the quad in any condition, if you want to try to make some quick flip try with Stabilize (the method suggested by Duran), Acro is for rc pilot with "high skill level and experience".
Long looping and tonneaux are only possible in Acro mode.
Given the behavior that it seemed to happen more frequently at the end of the flight I thought the same thing. I have completely replaced the ESC for the tail, and I swapped the motor with another arm, so I don't believe it was a faulty bit of hardware. I thought perhaps the ESC (Turnigy 18A) or motor (DT750) is just not specced well enough to operate in this position (long shot, but thought maybe the rear motor gets a higher work-out than the other two), but I flew these with multiwii and KK pretty aggressively without a single problem. The motors and ESCs are actually barely warm to the touch after the hover test too.
Also, the problem before 2.6 was almost immediate, I could get it to twitch within 60 seconds then. I've got video and tlogs of that, I just need to trim down the video as its one long test session. I'm also going out to fly again now, so I'm going to try to capture 2.6 video/logs so I'm up to date. :)
In those logs, I see what appears to be a radio_in spike on ch2, which is something Glenn was seeing as well. His went away with 2.6, so I was hopeful something had changed.
I'll try switching out for a second battery right away and see if I can corroborate or discount a heat issue. Thanks for the suggestion!
Do you have STAB I with any value ? if so, set it to 0 and give it a try.