Version 2.4 of the ArduCopter code is now available in the AP Mission Planner and in the downloads area. Although not as big a change as the 2.3 release, it still includes a respectable number of enhancements and bug fixes.
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.
Thanks go to the numerous contributors including users and their detailed bug reports, developers and testers. Hopefully all together this will add up to a nice smooth release!
As per usual, please post your comments, issues in this discussion. For enhancement requests for future versions, feel free to add them to the issues list. Note: you can "star" an issue to receive emails when someone comments on the item. On the dev side it helps us because we can get an idea as to which feature requests are the most popular by sorting by the number of people how have starred each issue.
Marco - one of the problems I have with the Mediatek is that it can take a long time (10 minutes) to get a 3D fix, even with it sitting on top of the stack. How quick is that ublox? Regards, Bill
Have you tried getting lock without the RX powered up? I found that my RX caused the same issue you're seeing. Ultimately, turning the RX through 90 degrees and moving it off to one side solved the problem.
My gps also use to take forever, it was sat right above my xbee and rx. I have moved all three of them away from each other as much as possible, the longest its takes to lock (even on cold start in a new location is under a minute with clear skies, under 2 when its cloudy.) Then warm locks are taking about 20 secs max.
I presume it was the separation of the components that improved matters as little else has changed physically (and i doubt my silicon gromets were the issue :))
Be most useful if you could give us the git hash (git rev-parse head) rather than a tag that doesn't exist yet. Thanks ;)
RickP, this is only the latest GIT version, "2.4.2" because take this number when it comes out on the planner and the download area.
The version "2.4.1" in the download area does not contain the fix on the GIT, is the same inside the planner.
So does this mean, if i've got the latest git repository, I've effectively got 2.4.2?
Practically, I think that little else will be done before the release.
However absolutely recommend to fly only with the current git version, for those who have the ability to pick her up!
Sorry what i actually meant was is the GIT version the one you are flying in the vid, and the answer is 'yes'. :D
Right, time for night lights ;)
Just be careful with the GIT pulls. It's hard to be sure you are getting the same version as Marco just flew. Somebody could have put something in while he was flying.
Have a look at the "changes" tab and see what's been happening, gives you a better idea.
I agree Robert!
It's my rule to publish my video saying the installed version, so if I write "the latest GIT" means that I flew with the version on the GIT when I publish the video.
If there have been changes subsequent to my flight in that case i can't upload my tests.
Marco, unless you are actually writing the hash on the video, it's almost pointless. You can check if there are any changes when you publish the video, and then 1 hour later, somebody pushes a change, and then 1 hour later, somebody watches the video and pulls from GIT.
There's only so much we can do. Anybody downloading from GIT needs to be aware of how it works, and what are the risks.
Another suggestion would be to add the GIT files to the video post instead of the hash.
Just a thought.