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.

 

Enhancements:

 

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: 64041

Reply to This

Replies to This Discussion

Hi Randy, Im still getting that surge from my motors, from lift off it surges, I have attached a log, it is twitchy which Ive read thru the posts on here, Ive had no previous issues, all motors just surge with minimal throttle input, if I do get it into a hover the motors surge up and down randomly which causes me to crash

Attachments:

 

I have a request.  I read a page or two ago about 1 guy whose copter flew away.  Then there are warnings about not flying with 2.4 and 2.41.  Honestly, it's really hard to follow 63 pages of comments to determine what's flyable and what is not?  How about making a section on the front page that gives a "current status" and says stuff like "APM2: Flyable with quad, don't fly hex, don't fly octo.  Current issues include....."  Without that, everyone is guessing, frustrated, and equipments gets damaged.

 

Thank you.

Dave, the code in the Mission Planner always represents our best, tested code at any given time. At the moment, that's 2.4.1, which is appropriate for all platforms. Like all code for platforms as complex as this, there are still some issues, many of which we've solved in the internal code the dev team is now testing prior to release. But this is bleeding-edge robotics, so always fly with caution. 

 

Current Issues are always listed in the Issue Trackers (here and here)

Marco if we are not suppose to fly 2.4.1 from the MP then why would it be allowed to download? I also must have missed that comment on the forum and I downloaded it last night on both my rigs.

My impression was that the MP version was reasonably ok and the issues were with the branch off versions.  Luck today's flights went ok. But I suggest until 2.4.1 is fixed how about a popup on the MP for an alert warning of the issue at least and then onus is on the user?

I think Marco was being a little overdramatic. 2.4.1 has fewer issues than previous versions and should be fine for most users. It's been flown by many hundreds of people, with rare issues. As always, precautions should be taken when flying code that's still early in development, but we wouldn't release it to the MP if we didn't expect people to use it.

The code the dev team is currently testing (which will ultimately be released as 2.5) is much better, but needs more testing before release.  

i must say even though i was aware of the lean problem on 2.4.1 i was under the impression that it would only cause it to crash to the ground I would never have thought that it would cause my 2/3 week old $500+ build to fly 3km in to thick bush that is not navigable .......now to reorder and rebuild .......what the lead time on apm2 atm?

 

I flew 2.4.1 today with my new hex Jdrones and it was the most stable Ive flow yet. There was no  wandering of the yaw or attitude or altitude  and it controlled nearly perfectly. and the copter was very  smooth and stable.

I then switched it into loiter and for about 10 to 15 seconds and it bobbed up and down but held lateral, longitudinal position OK.. but the bobbing up and down got worse and then it started tilting to the left and going a bit crazy wobbling around, so i switched back to stable mode and all was good again.

We did 4 nice flights just using stable and all were good.

The only adjustment I made to the PIDs from default was to set Stab pitch and Stab Roll to 3.700 I to 0.001 IMAX to 40. All other settings as default.

My wife took four video clips, but unfortunately she had the camera set on photo mode and didn't notice it, (we were up at 5am to get out to the field before the heat and wind picks up, so ok, fair enough poor girl was still half asleep) So all I have now is 4 photos getting ready to take off.

That's not the issue Chris.  Of course we should fly with caution.  My point is that unless you follow it daily, it's hard to get a code status without going back and re-reading all the comments.  This shouldn't be the case.  The front page should have a brief overview of what works, what doesn't, and the major current issues being worked on.  When 2.3 was out, following the motor numbering mess was difficult.  A front page dashboard status would be an appropriate and helpful place to help people know what's going on and determine if they feel comfortable flying.  2.4.1 may be 'appropriate for all platforms', but that's not really the case if there are some major known issues that could cause problems.  These issues should be highlighted on the front page -- you shouldn't have to dig through comment after comment to try to find and identify them. 

Even the issues links are not posted on the front page -- and in many ways are unhelpful.  The issues lists help people track bugs -- it doesn't summarize major issues in a format that is clear for everyone.  ie. The issues list didn't tell people who had 2.3 that they shouldn't fly hex and octo until the motor numbers were updated.  You had to look at the forums to find that.  Sure, it was one first page of the forum, but then you had to read the comments to know if the front page of the forum was correct, or the wiki, or something else... because if you go back and read it now... it's still not clear and there were lots of people asking questions about it to try to understand what was going on.... once again, a simple status update on the front page would have resolved most of this.

Dave, could you give me an example of some other project that does what you suggest, so I can evaluate how it might work for us?

Dave,, rather than put the information on the forum header. have it as a pop up window when the Mission Planner is opened. This morning I loaded 2.4.1 onto my two rigs and went flying without reading much on the forum. I didn't have any major issue, but seem it could have happened if I tried RTL or other modes which I didn't try after I found loiter very unstable. So I just flew in stable and didn't try anything else.But I was not aware I should not to fly 2.4.1

When I got home just now 1pm in Malaysia. When I open Mission Planner it popped up a window advising there are new updated again, and do I want to load them.  So between yesterday and today there are more new updates but its still showing 2.4.1 copter firmware version. But we have no idea what was changed. and no indication if we should fly 2.4.1 or not and if this has changed.

I made this suggestion earlier , why not put more info on that popup window when MP is opened? Just a brief outline or issue to watch for? Otherwise we ether have to trawl for hours through forums and the repository to actually find out whats changed and if there are issues we should know about and a high probability we might miss some critical points. I think this is really the way to go.

This would be most helpful, to not have to sift through the threads to try find the accurate and updated information regarding the current status of the code would be great! I second the motion :)

Hello Rui,

Glad to see that you have tested successfully my version with the latest Tridge's DCM fix and that also the auto-landing works well for you.

About your question in line 438 of th system.pde:

// debug to Serial terminal

Serial.println(flight_mode_strings[control_mode]);

This serial print doesn't consume too much time because it used only when the ch7 switch mode is trigged (i.e. when you switch from STABILIZE to LOITER). Of course you may comment this for saving a bit the program memory.

Happy flights

Jean-Louis

Reply to Discussion

RSS

DIY Drones Monthly
Newsletter

Groups

Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2016   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service