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!
Marco, where did you put it to find big 20cm away?
Easy, in one arm... :-)
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
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:
Can somebody help me to analyse log from this flight, why this happend? Was it brownout or error in control loop?
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?
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.
what is the stability patch? Can it be found somewhere in code that I can play with it?
ArduCopter Hexacopter 2.5.3
All settings default
This is great video and sure shows the software is fairly good out of the box.
Very smooth Loiter and Stabilize control.
Anyone have the same issue with the sonar?
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?
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.