ArduCopter 2.5 released!
Version 2.5 of the ArduCopter code is now available in the AP Mission Planner and in the downloads area!
Enhancements:
- The first ArduCopter code release optimized for the APM 2. Leans and drift should be much reduced or even eliminated for most users. This was accomplished through a number of core improvements to the DCM implementation by Tridge like this one and this one.
- Loiter and waypoint following should be improved due to a D term bug fix, some tuning and the improved DCM performance mentioned above.
- On start-up, the yaw heading is updated with first successful mag read (so you should no longer see the slow rotation from north to your actual heading).
- Increased output rate to ESCs to 490hz. This update rate is also user selectable using the new RC_SPEED parameter.
- hexa copter stability patch bug fix (should resolve slight flattening when pitching forward and accelerating very rapidly).
- improved baro filtering
- fix to dataflash logging of Mag heading
- addition of H1 swash plate type and bug fix for proactive yaw compensation for collective pitch changes for TradHelis.
Tuning:
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!
Replies to This Discussion
-
DeveloperPermalink Reply by Marco Robustini on -
Easy, in one arm... :-)
-
Permalink Reply by Emin Bu on
-
i did not listen to you so my hexa did not listen to me and fall down..pfff..details and tlog and rlog on page 86,can you take a look please.Thanks Emin
-
Permalink Reply by palo sestak on -
Now I'm back from field. Was testing 2.6b with heavy changed PID params (loiter and nav).
Wind was around 5-8m/s and my tricopter was not able navigate and RTH so I only played with it in wind.
In one moment I flew bit onward and tricopter turn huge pitch and roll angle. I tried to swith to RTH but it didn't help.
Tried to switch to stabilise and it still stayed pitched and because it was quickly approaching to ground I turn throttle to 100%. And didn't help, it hit the ground with high speed. Fortunatelly only two propellers and two bearers broken, whole electronics untouched.
Here was my setup:
APM1.4,
compass,
no sonar,
ACM 2.6b.
Can somebody help me to analyse log from this flight, why this happend? Was it brownout or error in control loop?
- Attachments:
-
-
2012-04-19 22-39 2.log, 747 KB
-
-
DeveloperPermalink Reply by Randy on -
Palo,
I've had a look at your logs. It could be a brown-out because if you look at the first graph below, you can see the barometer altitude (red) just ends when you're 25 meters up....or maybe you just came down very quickly after that.
The second graph is more interesting..this shows your desired pitch (from the radio) in red. The actual pitch is in green and the throttle is in blue. You can see that the desired pitch and actual pitch separate as you increase the throttle. .. and then a few seconds later you put the pitch stick back to the middle for a moment and then return it to about 15 degrees quite quickly..the tri tries to keep up but it massively overshoots to nearly 50 degrees.
So my guess is that one or two of the motors was peaking out and couldn't keep up. It's very possible that the stability patch for the tri needs to be improved. Did it flip backwards or forwards?
-
Permalink Reply by palo sestak on
-
Hi Randy,
I really appreciate you looked at the log.Thanks a lot.
No the tricoper didn't flip. Looked like it got frozen in one pitch but not completely frozen. Motors were like very lazy to control them till it hit the ground. Could be that the throttle_trim gone out of the range? (just guess).
The brownout is the simplest option in this case - log ends very sharp. But when I controled engagement after crash everything was OK and APM started immediately after I switched battery on.
This happened with earliest ACM versions too even before 2.0.49. Maybe 2-3times per year therefore I didn't mind it. Every time it was after longer flight - 8 or more minutes in air. ACM turn very lazy to be controlled and fall down.
For sure it wasn't lost RC controll - I own FRSky with telemetry Rx. When the RC link is lost I got sound beep alarm. And of course have set failsafe to RTF many times tested.
-
Permalink Reply by palo sestak on
-
Randy,
what is the stability patch? Can it be found somewhere in code that I can play with it?
-
Permalink Reply by John Campen on -
This is great video and sure shows the software is fairly good out of the box.
-
Permalink Reply by John Campen on
-
Anyone have the same issue with the sonar?
http://diydrones.com/forum/topics/sonar-problem
I cant figure out why the sonars on both my copters don't seem to give a proper readings when I run sonar test on CLI. I have done a full reset and installed the firmware a few times on both. Im running 2.5.3 on APM1 .
When I run CLI it starts off reading 20cm on the ground.. so then I lift it up to about a meter and then it reads between 35 and 45cm.. I hold it over my head about 2 meters and it never reads more than about 80cm and the reading usually hovers between 65 and 75cm.
Anyone get the same reading? is this normal?
-
DeveloperPermalink Reply by Andreas M. Antonopoulos on -
The sonar beam is relatively wide. Are you sure something is not coming into "sight" of the beam from the side? Like an arm or something like that?
I found the accuracy was high if I pointed the sonar up at the ceiling (upside down) and moved it up and down. That way the beam is free of obstructions during testing. I got good readings, with the expected accuracy. I noticed that if objects are within a foot of the side of the copter, they may be "seen" by the beam. So during testing you get false readings jumping around as things (like arms and chairs) come in to view of the sonar.
Social Networking
Top Content
Contests
Season Two of the Trust Time Trial (T3) Contest has now begun. The fourth round is an accuracy round for multicopters, which requires contestants to fly a cube. The deadline is April 14th.A list of all T3 contests is here.
Groups
-
ArduCopter User Group
1299 members
-
Documentation Editors
51 members
-
Melbourne
48 members
-
UK Ardupilot Group
111 members
-
Agricultural UAVs
137 members
Advertisement
© 2013 Created by Chris Anderson.
Powered by
