Version 2.5 of the ArduCopter code is now available in the AP Mission Planner and in the downloads area!
The default PIDs are optimized for a 3DR/Jdrones quad with 850 motors and 10" props. If you're using more powerful motors/props, start by turning down Rate Roll P in 25% steps.
While some testers have reported very good flights with the default PIDs, some have reported that this release is a little "sharper" due to the DCM improvements and have found they needed to:
reduce stabilize P by 10% (i.e. 4.5 -> 4.2)
reduce stabilize D by 30% (i.e. 0.15 -> 0.10)
increase rate D from 0 to 0.001
Tuning loiter can be tricky. Refer to the discussions which will appear below for more community feedback on what parameters work best.
Please post your feedback in this discussion. For enhancement requests and bug report, please add them to 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.5 but tell us anyway!).
Thanks for this release go to the developers (both in the core team but also those who have provided bug fixes through the issues list) and also the community members who participated in the previous release thread and provided some great detailed information in the form of issue reports and logs which allowed us to nail some bugs!
Tom: I'm not seeing any issues here with that setup. You wouldn't happen be using an old 1280 board, would you? I don't think that's supported by the MP version of the code.
No it's a brand new ardupilot mega just purchased (of course as v2 was coming out :-) ). I have used terminal mode and issued the erase command and then let 1.1.53 MP upload a "clean" install of 2.5 but I get the same result - won't connect in the flight data tab !!
I have had a problem with Mission Planner for a while now that the main window doesn't open up but it opens in minimize to the tool bar. The terminal window opens ok, but not the main window. Even if I click on it, it wont open . I have to hold the cursor on the top of the popup image from the tool bar right click and select maximize to get it to open. This happens on all my three computers running Win7.Now on one of them I cant open it at all. When I right click it just closes. There is obviously an issue with Mission Planner and Win7. Can someone please take a look?
Tom, check the "Show Console Window" in the MP help screen and restart, so you can see if there are any diagnostic messages that might help. I've got the exact same setup and am seeing no problems at all.
BTW, if you can see the Mavlink paramenters loading in the Connect dialog, but no movement in the Flight Data screen, that just means that it's erasing your log files for a clean start. It will be done in a minute or two and all should work fine then.
John, this is not the right thread for MP issues, but try clicking on the resize button (the middle one) and dragging the frame to something other than full screen. That should reset the window size defaults.
OK I'll try the "show Console" and see what I get.
In the Mavlink connect dialog all I get (for the 30 second timeout) is bad crc code errors
I'll repost when I try show console
Rain came just after your tests ?
well rain incoming = athmospheric pressure changing = baro reading well and transcripting well the progressive athmosperic incoming changes .. everything is maybe normal?
Around where i live, it happens alltime.. you can feel it in your bones :)
Thank you Marco - I will give them a try. I might get the chance for a couple of quick flights Tuesday evening before we head into the gym for our indoor flying. Other than that it will be next weekend.
Correct Chris, I opened a new thread. I did all of what you suggested but it just closes each time. What I found is that it was the popup box for the new updates was there in the back ground but I cant access it at all to click yes or no. I deleted all of 1.1.53 and downloaded from the download page for 1.1.54 and now it opens . But lets see now next time it wants to update if it does the same
Hey Marco, quad is excellent! Loiter is the best I have ever seen! Altitude hold is dead on. At first it was dropping out of the sky when I first initialized alt_hold, but found where #define ACCEL_ALT_HOLD 0 wasn't commented out. It is set to off, but it was still disabling my Alt_hold. Changed it and it is working great now.
Despite the lack of wind, Loiter stayed within a three to four foot radius for over four minutes. I know we are not supposed to use all caps here, but THIS IS OUSTANDING! Excellent work by the dev team! They have developed arguably one of the best autopilots on the market for the money. Yet there is even more to come.
However, my Y6 is simply not giving me the same performance. I did adjust my top bottom ratio as someone had suggested, as I usually have to anyway. I have done this setup so many times it is almost second nature, but in saying that I still picked over my hardware, but to no avail. I am now looking through the software. I reverted back to 2.0.49 and it is working great. I am getting good stabilize, good alt_hold and good loiter, so this makes me conclude that my hardware setup is OK. It is not so much the wobbling that is troubling me with v2.5 as it is the slow yawing with no input, and banking hard when I give it a yaw input. I posted logs and parameters later in the v2.4 discussion. I am stumped.
I will reload 2.5 again and make sure that Stab_D=0.
FWIW, I just updated to computers to 1.1.54 with no problem.
Robert's right, I totally didn't mention that! Between the RAM savings that Tridge did in 2.4 and the CPU performance for 2.5 we're suddenly in a much better position than we were two months ago to keep on improving the APM.
re the update rate to the ESCs being higher than DCM, the biggest reason is that most ESCs have an internal filter..each time they receive and update, they blend it with the previous few readings..a higher update rate allows you to force the values through the filter faster. Of course flashing the ESCs with the custom firmware that removes the filter would mean you could get away with a lower rate.
The other reason is that the timing of the updates to the ESC is actually decoupled completely from the update rate of the DCM (this is the difference between our current method and the older "instant_pwm" method). A faster rate means a smaller delay between when the DCM updates what it wants the ESCs to do and when that message is actually sent to the ESCs.