Version 2.6 of the ArduCopter code is now available in the AP Mission Planner and in the downloads area!
Updates to MavLink 1.0 means you will need to use "ArdupilotMegaPlanner10.exe" to connect. If you've updated your mission planner recently you should find this executable in the directory where the mission planner is installed.
The above video is done using a prototype 3dr ublox GPS which seems to have better accuracy than the standard mediatek.
Improvements over 2.5.5 include:
- MavLink 1.0 support (use with ArdupilotMegaPlanner10.exe) [Tridge, Craig]
- Stability improvements especially during level hover [Jason]
- throttle range improvement (higher min and max) [Jason]
- improved standard Loiter PIDs [Alan, Heino, Jason, Angel]
- dataflash erase speed up ('+' messages removed but it only takes 6 seconds now) [Tridge]
- Copter LEDs [Robert Lefebvre]
- RTL loiter stage target set to home to improve final landing position [Jason]
- flip & acro improvements [Jason]
- circle mode target improvement for ground station [Jason]
- Auto Approach [Adam Rivera / Marco]
Bug fixes include:
- UBLOX driver fixes (lock should now be more reliable) [Tridge]
- enable mavlink messages during dataflash erase which resolves issue in which new APMs fresh from the factory appeared unresponsive [Tridge]
- proper printing of lat/lon values in dataflash logs [Randy]
- removed duplicate GPS reads [Jason]
- resolve flooding of telemetry link with low-battery warnings [Tridge]
- RTL bug would land if rtl_approach_alt was more than 1 [Jason]
- WP Radius could not be set larger than 1.3m [Jason/Randy]
PIDs are optimised for the 3DR/Jdrones quad with 850 motors and 10" props. If you're using more powerful motors/props and are seeing bad flight behaviour in stabilize, start by turning down Rate Roll P in 25% steps.
This time we spent some time optimising the loiter PIDs. Tuning loiter can be tricky so please refer to the discussions which will appear below for more community feedback on what parameters work best.
All feedback welcome below. Enhancement requests and bug reports can be put into 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.6 but tell us anyway!).
Palo: Can you please upgrade to 2.7? We don't support older versions of the code after a new release.
Chris: I already did. Not tested it yet (have no time due to my little sonny)
Anyway the case with climbing to the sky and diving back is still actual even with version 2.7...
For X8 coaxial quads using APM1, how do the channels out put the signal for yaw? The props on each arm in normal flight counter rotate at the same speed. However for Yaw to work the speed for the two props would have to be different correct? Can someone explain how this is configured for the 8X quad and what the props are doing for yaw?
I'm running a tricopter (2.6 with Robert Lefebvre's yaw control branch) and am finding that my yaw servo will jam hard over to the right when disarmed, and today this led to the servo burning out. I only have one more of these servos on hand, so I'm quite keen to modify the code so that this will not happen again.
I see in another thread from late 2011 (here) about the same problem, It was mentioned that modifying radio.pde, and in the function void output_min() changing a line APM_RC.OutputCh(CH_7, g.rc_3.radio_min); to APM_RC.OutputCh(CH_7, g.rc_3.radio_min + 300);
However it seems in 2.6 the function void output_min() only contains the following:
Is there something I can place in this function to limit the travel of my yaw servo, and if so, what should the line of code be? If I added APM_RC.OutputCh(CH_7, g.rc_3.radio_min + 300); within the function, is this still the correct syntax to have the desired effect?
Glenn, I had a look at your issue. No, you can't just add that function in output_min(); It has to go in the motors class now. But, it's a pretty easy fix I think, and here it is:
So grab that, and give it a shot.
If you want, you can also try:
_rc_yaw->radio_min + 300
The second option there will actually make the yaw servo move just as if it was in flight. That is what we do on Helicopters, I actually sort of like it. I'm not positive it will work the same way on Tri, but there's a good chance it will (I don't have a tri to test). Give it a shot, disconnect your servo rod.
Let me know which you like better, and I'll push it to trunk.
Thanks for your legwork, it actually made it really easy to find the problem.
Excellent, thanks so much for this.
I've just loaded that in, and it works like a charm. It really feels like this thing has ninja precision and control now! Hopefully my servos will begin to live longer lives too.
For those of us who don't have the means to build this, any idea if and when the fixes will be released in the mainline code?
Yes, I think Robert's checking in the changes to trunk. So it'll likely show up in 2.6.1 which isn't that far off actually.
Yeah, I just need confirmation from Glenn, and which mode he likes best.
Ok cool, let me know. I sort of like having the servo move when the motor is off on my heli. It is of course totally safe, and testing the servo before flight is never a bad thing. However the question is this:
On the heli, we have a really good setup, such that, the servo won't go beyond it's endpoints, no matter what. For example, if you command yaw on the ground, it doens't actually move, so you have a huge yaw error, thus the servo can move far trying to get it to actually turn (which is impossible because it's on the ground).
Do you have those protections with the Tricopter? Do you set enpoints for the tail servo? I didn't see them at first look.
If you don't have protection (and it would appear you don't since you had the original problem... ) then I'll have to leave it where the tail servo just stays centered. And that is what I did, BTW. Instead of moving to "radio min +300", I have it set to the center, which is "radio trim".
OK I see what you mean now.
On my tri, the servo travel is mechanically restricted by the yaw mechanism before the limit of the servo's movement is reached. There's no endpoint set for my servo travel, so if it was allowed to move when disarmed, when I held the throttle/yaw stick over to the corner to arm, it would be trying to push it past the limit of mechanical movement, and placing strain on the servo.
So for now I think I am happy to leave it so that it stays centred when disarmed. If there was a way to set a parameter to limit the travel of the servo at either extreme in pwm, then I would be more comfortable with it being hard over to the side, since it wouldn't be trying to push past where it was allowed to go.
Changing the min/max pwm values for rc4_max and min would be different though wouldn't it, as that would limit the actual travel of the stick?