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.




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.

Views: 64965

Reply to This

Replies to This Discussion

yeah I understand...didn't make sense to me either but I also changed my declination from east to west(same value but negative) and forgot to mention that...could be a combination of things...but the fact is it doesn't yaw anymore and I'm so enjoying flying it until the next release :)

Yesterday when we were talking you mentioned that you didn't see this issue, any idea what may have happened?


What system have you used this successfully for?  APM1, APM2 .. ?

Thanks for the idea

Can't reply to your message Robert so I'll go on top :/  oh it seems i can...

Yes sorry i didn't mean to imply that those massive silicon brass things would be good for our purposes, just that I've had great success with silicon dampers (free ones) and it looks like silicon is a very popular choice in expensive anti vibe kit.

Maybe I've been lucky but my current set up gives the best I've had out of at least 15 different methods of mounting an APM...

Is anyone else having trouble setting CAM_P_G and CAM_R_G?

Yep, in my draft guide i have in brackets - (Why no stab_I?), well my observational understanding (I'm no control loop guru as you can probably tell ;)) is that rate_I is sorting it out, but that's just a guess in the dark, my frame still flies very well indeed with no rate_I or stab_I, i just 'use it' to allow me to jack up D and P. A torch lighting my way on this subject has been the fact that absolutely no-one (at least that I've seen) has ever posted any decent parameters with any stab_I in at all.

Maybe we are missing a trick - spill the beans if you have any Robert, Stab_i has always just made my flight 'sludgy' for want of a better expression - like swimming through porridge maybe :)  

With 2.4 I was finally able to ramp up I-terms higher than 0.001, it holds very well against wind and imperfections, and I was also able to use higher P-terms.

But it does increase sluggishness, and also if you compensate for something manually it fights you very hard when you release the sticks - great for AP, not so great for flying in a closed space...

I'd like to see some Rate_I tuning guide though - when I use 0 it wobbles during faster maneuvres or fast descend, using 0.001 solves most of it, anything higher makes it hard to control - much more pronounced effect than Stab_I has...

Also with all those changes it is hard to keep track of the proper way to set it up - I am running wildly different values from my 2.0 ones (the last version that flew flawlessly for me). But to be honest 2.4 is almost perfect except for the compass/yaw bug...

Yes i've had exactly those thoughts, if the silicon didn't work i was going to suspend an 200g steel plate in the middle, glue the APM to it then use traxiss suspension dampers to suspend it...

You don't want to know what was next on the list ... Oh Alright I'll tell you, full silicon thread suspension in a non-conductive fluid... (with a snorkel for the baro obviously :))

Seriously though, out of curiousity I removed the layer with the rubber grommets in, putting the APM straight on the silicon mounts and it wasn't as good. The performance of the silicon vs the rubber i would guess at about 80/20, given the slight extra vibration i saw with silicon only.

For anyone reading this please bare in mind that I'm using a DJI flamewheel frame which is great but if its not well damped it 'moans' through vibration at high throttle. I've likened it to sounding like a V8 in the air compared to the flat4 of the ardu frame that just eats the vibes up. For info, the rubber under the motors made it improve to a 'flat6'....

And by the way, i'm sorry i've/we've hijacked this, I will start an anti-vibe thread tomorrow...

Jup, its an reported issue since 2.4. You have to set it in the config file and upload the firmware with those parameters set via arduino IDE. I hope it will be sorted out soon.

Do you do fpv already? If not, get the '$100 quad' with the cheapest camera you can find, kk controller and go for it, you will crash, better on that than the ardu. But you'll  be having amazing fun, I'm loving it, been doing tree runs and everything :) Then when the day comes to stick it on the ardu, firstly the ardu is intact and ready to go, but secondly you've got bit of understanding of whats going on but now with all the capabilities of the ardu, FPV autoway point (despite my awful tuning) is an almost pant wetting experience :)

And I'm one of those 'extreme sports' kind of dudes....

They are purple/blue versions of what I'm using....

So silicon it is then?

Sorry, I'm missing something. when you say you ramped up I terms, which ones, Rate I terms or Stab I terms? Are you using stab_I?

My (probably flawed) philosophy so far is

1. The higher you can get rate_P and stab_P the more responsive your quad will be, and the better it will respond to external forces. It will be aggressive and possibly even smooth as a mill pond even in wind, if you get it right. 

2. With these current control loops, it seems that if you can dial some rate_D in, (vibration permitting) and maybe using some rate_I to allow for a bit more rate_D then this allows rate_P and stab_P to be increased  to 'ninja' levels. Not what everyone wants but its a good end-of-scale reference and just what I'm looking for in a close quarter fpv machine.

Its the stab_i that gives me the sluggishness, with 2.3 it did too, but so did any combination do rate_d and stab_D, i had to use one or the other. So its a step forward when you can use rate_D and stab_d together.

So, yeah, here here on the request for any knowledge on how the iterms are now involved in the system.

Yes, mines still great, it currently flies beautifully especially in stab, at stock components, stock params everything.

And then, if you can be bothered, you can bewitch it with some scary d tuned capers.

Brilliant :)



     Your issue is a problem with the APM not being able to communicate with the Compass.  The "Not Healthy" message is very low level and indicates that the I2C connection is being lost.  Can you check your wiring especially the ground pin.

     The "slow yaw" that you reported is gyro drift...gyro drift is sadly a normal effect in all mems gyros and cancelling this is one fo the main purposes of the compass (it's also critical for navigation as you probably already know).  So you're seeing this gyro drift because of the compass communication issue.

     It's unlikely that this has anything to do with any recent code changes, you can prove it to yourself by loading up an old version of the code like 2.3 (if you still have it around).

     Good luck!

Reply to Discussion


© 2018   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service