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!).
actually last month , i tried many times code AC2 from 3rd party and compile, but still can not get works about the minimum throtle as ultrapwm esc requirement. i was headache , finally, i just replace standard esc. i am happy with that.
do you think my quad setup/frame can using default parameter 2.6 version well?. i only concern about stablizer,loiter and RTL . i want to take AP/AV and FPV.
Reposting here (closing the separate original thread) as Chris A. suggested:
Preface: Needless to say, correlation is not causation. The event described here occurred on my first flight with 2.6, but may be found to not be a software problem at all, like many quad issues.
I installed 2.6 this evening and took it out to do a bit of close-in, low altitude test flying to see if my tuning was still good, just before it got dark here. Before today, I had been flying 2.5.5 without issues (besides a yet-to-tune loiter). This first flight with 2.6 went fine too, until...
...a few minutes into the flight, while I was in Stabilize mode I think, the quad suddenly started accelerating vertically, climbing away. I zeroed the throttle, and jumped into Land mode, but got no reaction. I was flying next to a tree, and the quad lodged itself high in the tree crown, preventing a total fly-away. It hung there, props spinning at high throttle like a weedwhacker, for a very-long feeling time (maybe a minute), until it came loose, tumbled down and smacked in the ground.
I flipped through my modes and wiggled the controls while the quad was in the tree, getting apparently no reaction, but I did not have the presence of mind to try to disarm it. (Note to self: remember to disarm.)
A couple of broken legs, a set of chipped props, a few popped screws and a broken cheap camera mount seem to be the only hardware crash damage - not a problem, thanks to the 3DR frame engineering. As a positive side effect, it was good to experience that my heart does not actually stop in this type of situation :-)
In my flights over the last few weeks since building the quad, I have not experienced any unpredictable behavior, scares or radio problems. The props were balanced and the battery had plenty of power.
3dr-b frame, 880kv motors, 11*4.7 APCs, APM2, 3dr radio, sonar, optical flow (not tested yet), 4s1p LiFe 4200mAh battery, DX8 TX, AR6210 RX with satellite, DSMX.
I am attaching the log. It gets interesting just after 90% / 600s in the .tlog, and at line 13930 in the .log
Graphing the log myself, I see that the rc inputs go flat a couple of seconds before the unexpected climb starts. This might indicate an RC connection failure, followed by what looks like a behavior similar to the rtl-failsafe for Auto mode ("Climb!").
I wasn't in auto mode, though, and I don't have that failsafe mode enabled.
While the quad was in the tree, I power-cycled the TX, and that does not show in the RC inputs, also indicating that the RC connection may have been lost. I'll have to compare these frozen rc input values to my RX failsafe settings.
I looked over the logs for a while and can readily pinpoint the radio loss. The set point of the throttle was just high enough at the loss to cause the climb.
Signal loss would be one explanation. Do any channels change on your radio for failsafe? that could rule that out.
A signal wire could have a short causing the PPM encoder to stop reading and outputting a constant set of last good values.
Can you look over things and see if you can reproduce it?
Thank you, Jason.
I will review the failsafe settings and take a close look at the receiver-to-apm wiring tomorrow night.
Knut, can you confirm what your Rx does on signal loss? I wonder if it's similar to the Turnigy (ie: drops the throttle channel).
Were any signal wires loose after you got it back? Obviously we couldn't determine if the wires came lose before the flyaway, or after it crashed. But it no signal wires are loose after the crash, then obviously none were lose before the flyaway, so we could rule that possibility in/out.
I consistently hear too many terrible stories about Spektrum equipment that I just won't fly it. Just last weekend, a pilot at the airfield told me his Spektrum Tx/Rx have buggered up 3 times now. He had to turn the Tx power off and on mid-air to re-establish connection, and now the Tx won't bind to that Rx at all anymore.
Regarding the Spektrum equipment, I think there is a range of quality available. The current DSMX systems are, at least in my experience, a lot better then the early DSM and even DSM2 systems, where a lot of fliers got burned.
Update on the analysis:
First, I reviewed the failsafe behavior, and it's working fine: upon signal loss, throttle goes to Off (under 1000µs). So radio signal loss did not prompt the climb out.
Second, I checked and wiggled the receiver-to-apm wires individually, while connected to the planner, to see if there would be any loss or input signal based on a wire shorting out. No such think occurred, and the connections were all firmly in place.
Then I investigated the following:
I had a small tilt-camera mount on the copter (keychain cam on it), driven by a powerful servo (an old Multiplex Micro Speed), which I had just installed before the flight with the fly-away event. During the flight, the camera mount had been hanging loose, with no pushrod linkage on the servo (glue still curing on the pushrod), but with the servo active. Maybe the servo got caught on the frame in the wrong way and stalled in flight.
I tried this: while connected to the planner via USB cable (no battery on the copter), I manually stalled the cam tilt servo. This caused the receiver to flicker wildly (indicating frame losses, possibly a crash) and the APM to reboot, dropping the connection to the PC. The receiver recovered when I unplugged the camera tilt servo from the APM. I reproduced the same with a full-size analog Futaba servo as the camera tilt servo, which caused the crash/reboot but would let the receiver recover immediately. I also tried two micro servos in this manner, but stalling them did not disrupt APM and receiver. So there is a possibility that drawing too much current on the camera tilt servo was the problem.
Unfortunately, I have not been able to reproduce the same "current crisis" while running the quad off a battery, with running motors. The battery provides much more power then the USB cable, and without props, on the bench, the motors don't draw all that much. Running from the battery, the board is fed through the 2Amp BEC of a 20Amp 3dr ESC. These 2 Amp are driving the APM with all its sensors, plus the dual receiver, plus the 3dr radio, plus sonar, plus optical flow. Maybe, in flight, the "current crisis" scenario did occur when a big stalled servo was added to these consumers of power.
Is there a firmware upgrade planned for the minimosd to support mavlink 10?
Glenn: Yes, it's already in the repository.
Ah yes, thanks.
I've just run into trouble with this. The minimosd is now stuck at waiting for mavlink heartbeats after the firmware update. I'm running 2.6 firmware and have mavlink 10 enabled (connects fine through ArdupilotMegaPlanner10.exe).
Have even tried loading the old firmware back on and disabling mavlink10 in arduino but even that doesn't work any more! Is my board toast? And if so how?!
Hey Chris, is there supposed to be a new CharSet for MinimOSD 1.9 w/ 1.0 Mavlink? I updated to 1.9 w/ 1.0 and it booted and said "Update Charset" so I got the 19 zip file and updated with that mcm. The update succeeds according to the OSD Config app. Still says 'update charset' when I install and boot it. So I tried flashing the 1.9 w/ 0.9 Mavlink, then the charset then 1.9 w/ 1.0 and I still get the same thing.
Is there something special that needs to be done?