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!
Huge compliments on 2.5.3, I'm fairly new to this, but have been able to get my Hexa + in the air without too much troubles. Honestly I spent most time on finding the correct thread in this forum!
However...today first the first time I tried loiter and RTL. Loiter seemed to work OK by decreasing Loiter_P to 0.15 (anything higher and it overshoots drastically). However, RTL: it only worked once and perfectly! On subsequent tries though, it never landed and it turns out that the APM planner was shouting 'loiter' at me (I have speech enabled). In other words: it was reverting to Loiter mode, additionally, the parameter AUTO_LAND changed from 20000 to a large negative number. Any idea why?
I'm an idiot (I think): now that I no longer have the sun on my laptop screen and can read it properly at home, this is what I found:
'Once you arrive at home, the copter will enter Loiter mode, but a special timer will be set. Twenty seconds after entering Lioter, the copter will begin to Auto-land. To prevent landing, simply change modes with the control switch to clear the landing timer and resume normal flight.'
It does not explain the large negative value though in the AUTO_LAND field.
It would be really nice if there was an option on Mission Planner say in a drop down box to select either the current version default version of the firm ware or the other various beta or git versions being worked on. Also with previous versions if you want to revert to them.
I must say its hard to keep track of which and what is and isn't working unless you flow the forum every day. This for some of us isn't possible. I was away for nearly 2 weeks and I'm now having to trawling through days of conversations to find out what issues there are now with 2.5 and 2.5.3. Seem a lot of issues on both so far.
Again, as suggested previously a number of times now, can there be a pop up window that advise issues and changes when we open an update for MP or APM? This would save us a lot of time having to trawl for issues or miss something and then destroying our copters.
Is it possible to deactivate the auto land function? the copter should loiter till i get em to the ground.
Put in the config this line:
#define RTL_AUTO_LAND DISABLED
or just increase the "AUTO_LAND" parameters from "20000" to some like 10 minutes, "300000".
I knew that there was an option for that.but....okay..thx a lot. (like always) ;)
At the moment its very nice weather in Belgium so ideal to do some flight tests with 2.5.3.
Very stable but sometimes a random movement, like a slow twitch. The quad corrects itself very fast.
Then I noticed that the yaw suddenly moved 10° to the left without my input. A few moments later again. I didn't do any mag calibration. Ihad read about the yaw solution in another thread so I wanted to test the calibration with Tlog.
This was done and the random yaw movement was gone. But when flying fast forward the quad can't hold the yaw. It seems to turn left or right for a couple of degrees.
In previous versions I know that this was rock solid.
Loiter seemed to do fine but I have to test it in an open field.
As allways this version is getting better.
I'v just ordered a new APM2 ;-)
Well, our latest tests and fix are bringing good results... :-)
Now that 2.5.3 is out and working reasonably well, we are turning our attention to enhancements and bug fixes for the next release, 2.6. What this means is that you should take extra care if you are loading code directly from trunk (aka git) as it will be in flux for the next couple of weeks.
Now, I hope there are not too many people actually doing this. We recommend people use the code from the mission planner or from the downloads area but I wanted to warn people just in case!
BTW, it's hard to say at this point what improvements will be in 2.6 but some yaw improvements are likely.
With luck, we'll have the improved LED code out! :)
Great, will this use the IC relay mod previously posted here: http://diydrones.com/profiles/blogs/321-blink
If so can i feature request selectable flashing of one led on medium low or very low battery? I'd be looking to set the rear red led strip and a 12v buzzer to sound on low batt to replace the annoying lipo alarm...
I'm not quite sure I understand the request, but I will try to answer.
Currently, the official code supports LED lights. I'm sure some people never knew that because it isn't really documented. I discovered it when I hooked up the Darlington chip and the LED's magically worked. This version of the code turns on the LED's when the motors are armed. And it attempted to blink the LEDS when the battery is low. But I think a mistake was made it would basically turn 2 leds on, 2 off, and just stay that way.
The Blink code appears to simply blink the LEDs continuously, no matter what the condition.
My code will combine both. It will turn the LEDs full on when armed, and blink them when the battery is low. It also has the option of designating 2 out of the 8 pins (or 1 out of the 4 on the outer row, but there are in fact 8 pins total) to track GPS status. Blinking for no lock, solid for 3D fix.
And another option that will designate 2 pins to go on and off with a SUB-function on Ch7. You'll still be able to use Ch7 normally for Ch7 options, but you can switch some LEDS on and off with another switch mixed into Ch7. I got this idea from Show_LEDS. This could be used for Aux lighting (I'm planning on a search light) or strobe light, or sound effects even, whatever you want to hook up to that pin (provided it doesn't draw more than 40mA!)
After that, we can look at other modes. Always blinking, rotating, etc.
And I may try to bring in Show_Leds. Only problem is that starts to eat up a lot of code space!