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!).
I just disabled the compass and gave it a go, and the problem remains! Eg. my yaw will continue to move once I move the copter and stop. Sometimes it will eventually settle down, but other times it will keep moving.
This makes me think that it's a problem with whatever handles the yaw detection. Is this the z-gyro?
I just had a close look at the z-gyro on the oilpan, and there's nothing that looks out of the ordinary. Any ideas?
Just found that if I pull the oilpan off and put it back on, then it will work properly for about 30 seconds before it starts to head all over the place again... argh.
As a diagnostic test, disconnect your VTX and move the RX as far away from your APM as possible. Turn off the camera. Unplug the GPS. Re-enable your compass. Relocate the tricopter to a couch or bed, so it is not directly on a table or the floor. See if the problem persists. If it does not, add the disconnected devices one at a time (powering off each time) and giving each a good time to see if the problem returns.
Yup good call, we are getting somewhere, something other than your compass is fishy.
Also with the compass disabled, try reducing stab_yaw_P to about 3.
Let me know what impact this has.
Glenn, can you please disable the compass, enable PID logging, set Ch6 tuning to Rate_Yaw_P, but leave the setting at whatever you are currently flying with. All I need are the PID logging data for the yaw controller.
I'd like to see what the yaw system is doing.
I found the issue with the random yawing on my heli, and it wasn't to do with the heading estimation at all. It was actually a problem in the yaw rate code. I fixed it for TradHeli, but it probably needs to be done for everything else too.
You can see the change here:
Does the yaw error tend to keep going in the direction opposite the way the props turn? I think you have all your props going in the same direction? Ie, props turn clockwise, and it tends to yaw anti-clockwise?
Just to be clear, this is a problem that seems currently to be only affecting tricopters, and to a certain extent helis. I've tried 3 quad frames, totally different setups, all just about perfect at stock params. I do take time to make sure the airframes are not too ropey, apart from the kamikaze tri of course ;)
Glenn, is your yaw problem best described as:
'When hovering and pointed in one direction the tri holds heading well.
When giving yaw input the tri follows your command but overshoots and bounces back'
'Tri has random yaw movements even without stick input'
Or is it different behaviour?
Is your tail servo digital (and quick)?
Don't suppose you've got a video cam so we can see what its up to?
I had the issue described above and am helping Robert trying to resolve it. In the meantime i just reduced stab_yaw_p to reduce the overshoot and it's perfectly flyable, just turns a bit slower.
Just for info for tri users, i highly recommend having your front two props spinning in opposite directions, preferably the port prop spinning CW and the starboard one spinning CCW. This reduces the torque on the whole system and means the yaw controller has less work to do. It helps my tri with KK Mwii and Ardu.
And its simply a matter of swapping two wires around on one esc. (EDIT - motor wires, not the red and the black from the battery!!)
Dave, don't forget to recommend they change the prop when they reverse the motor. ;)
Actually, some of the issue with yaw control also affects the quads, just to a much lesser extent. I believe the fix is in-hand, if people want to use my alternative control method, and deal with the slight softness of it. But I'm also working on a better approach. I just need testing.
I should be getting a 3DR quad soon which will help a lot because it's hard to keep the helis airworthy when testing new concepts. Crashes put me out of action for weeks and are costing me $100's per month in parts.
I believe my oilpan is just damaged and it has been removed from the copter for now until I can maybe get an APM2 to replace it (which will still have all of the same software yaw issues as the APM1...)
Dave, my yaw problem was as follows:
When hovering and pointed in one direction, the yaw would oscillate at a low amplitude with no stick input. This oscillation reduced in amplitude when stab_yaw_p was reduced, but reducing it too far made the yaw too slow to be controllable.
Yaw movements in one direction with a small amount of stick input would generate a correct response.
Yaw movements in the other direction with a small amount of stick input would cause the copter to yaw in the wrong direction, and require an increased amount of yaw input before turning the correct direction. It would also yaw more slowly in this direction overall. I believe this is the behaviour that Robert's yaw patch that was rolled back aimed to fix.
I did have counter rotating props on the front motors up until my oilpan died yesterday, but also ran it for a few weeks with all standard props. The issue was present in both configurations.
I used both digital and analog yaw servos, but don't think they were particularly quick (0.15s - 60 deg). I have some faster yaw servos on the way (~0.07), but need an APM2 now before I can do anything since it's not worth buying another oilpan. :(
So, it's only your APM that's a flaky piece of crap then? Oh and Ron's :)
Only joking folks, just remember this is DIY, it's more work sometimes, but its more involved and more fun. You know the other options already, they are just pricey, or not as good.
Glenn, yes, sounds like your tri behaves EXACTLY like a trad heli. That is EXACTLY the problem I used to have, and I fixed it for trad heli, so it's just a matter of doing the same thing for you guys.
I think the yaw deadband would help, although I think that is largely blamed on the servo you were using, but the deadband would help anyway.
The "wrong way yaw" was definitely a problem of the old controller. My alternative yaw control fixes that, but it a bit slow to start and stop. So that's what I'm working on fixing.
Damn I wish I had something that flies. I don't even want to push anything to trunk until I've flown it.