Warning #1: Compass calibration and reducing interference is far more important than with 2.9.1b
Warning #2: GPS glitches can cause sudden and aggressive position changes while in loiter mode. You may wish to reduce the Loiter PID P to 0.5 (from 1.0) to reduce aggressiveness (see image below of where this gain can be found in mission planner).
Warning #3: optical flow is not supported but will be back in the next release (AC-3.0.2 or AC-3.1.0).
Warning #4: loiter turns does not maintain altitude. This bug will be fixed in AC-3.0.2.
Warning #5: This release has only been lightly tested on Traditional Helicopters.
Improvements over 2.9.1b include:
WPNAV_SPEED, WPNAV_SPEED_UP, WPNAV_SPEED_DN, WPNAV_ACCEL allows configuring speeds and acceleration during missions
How to upgrade:
1. Make sure you are using Mission Planner 1.2.59 or newer (get it here)
2. Click on the MissionPlanner's Hardware, Install Firmware screen. The version numbers should appear as "ArduCopter-3.0.1", then click the appropriate frame icon and it should upgrade as per usual.
3. Reduce the Loiter and Alt Hold PIDs if you have modified them from the defaults. The modified PID values for the 3DR frame can be seen in the image below.
Note: Nav parameters have been combined with Loiter so do not be concerned if you can't find them.
5. Try out the new version in stabilize mode first, then alt-hold, then loiter and finally RTL and Auto.
Numerous How-To videos are available:
Special Thanks to Marco, DaveC and the large number of testers on the pre-release thread who put their copters at risk during the extended testing period. Some of their videos can be found here, here, here, here, here and here. Thanks also to MichaelO for the MP changes required for this release.
All feedback welcome. Please put your questions, comments (good and bad!) below.
PS: I keep this parameter to zero always because despite being the one who pushed hard on this feature can, however, save in case of a crash, being testers have more than others to handle this possibility, but I would recommend back the default to "100" for all users.
And if someone asks "why spin to a minimum when armed?" we always answer "because it's better for you" ... :-)
That would explain it then! Thanks
I had a quick look at your logs a few hours ago and I'm pretty sure that your battery voltage and current sensor is not connected properly or the configuration is incorrect. The voltage and current readings do not change at all like they should. The voltage should start high and slowly decline throughout the flight, the current should be at zero when the throttle is at zero and increase when the motors spin. You've seen this wiki page including video? I think fixing this should be the top priority because the crash could easily be caused by a dead battery.
Sorry it took so long for me to review your logs, I was off integrating the heli and single copter code. Please understand that there are a lot of users now it's becoming close to impossible for me to investigate every issue personally. Of course there are others here too and the wiki's much better than it use to be.
Marco, Randy et al,
fully agree! I am pretty new to all this (started with 3.0.1) and was somehow shocked when the pros stared to spin. But: NOW I LIKE IT! It tells you everything is fine. The first thing after loading rc6 was setting MOT_SPIN_ARMED to 130.
Thanks for all you efforts,
I think most of the issues are RTFM ones... In a first test flight everything was fine - as usual.
Machine: X-Quad, 1000kV motors, 30A Esc, APM2.5, 3S 2200mah
Would you guys with skilled eyes lend some insight to my flight and crash logs for rc6? The first log, '19', was an Auto Tune drifting fight with a fast landing with loss of radio at the end. No real problem. I shut the radio off while the machine was pinned under a car and it simply then tried to RTL. No big deal. But, the second log, '20', was a right hand cranker right into the dirt!
I updated to rc5 yesterday and needed to tune but, today saw rc6 was out. Oh, in rc5 I really liked the props spin when Armed. It startled me at first then I remembered. Very Cool and Very Professional Looking. There was no doubt the machine was ready to slice and dice. :-) Then, today I loaded rc6 --- No prop spin. :-( How, do you turn it on? Oh, well - I put forth clear and good logic about professionalism, safety and maturing industry within my earlier pitch. Now, I have to find out how to turn the props back on after I fix my smashed quad.
With rc6 I calibrated Compass, ESCs, Radio, Accel, and went to do the now exciting and famous easy Auto Tune. I went out and tested the quad in an easy hover and a little motion in Stabile mode first to assure things would be manageable then set the quad in Alt Hold at about 15 meters and started Auto Tune. The quad was drifting quite a bit and loosing altitude fast. I kept adjusting and then lost the machine - it just drifted to far away and I quickly landed it because I'd lost orientation to fly it back. No big deal. Started again and did not finish because of sinking altitude. I gave up for a time to fly and raised the quad to ~15 meters again and set Alt Hold. I then handed it to my son. During this first portion there were two odd instances when the quad quickly cranked about 30-40 degrees to one side (rolled) and I saved it and then it flew stable again. ??? I let my son then fly it around at Alt Hold for a few minutes until the quad began to lean at which point it was not recovered and smashed into the ground breaking two arms. I'm not sure if this was firmware related - because we are noobs (newb) but, my son does think he was putting in counter motions when it crashed. He had been flying it around for about five minutes and did quite well. We both are not really sure the cause but, you will see the logs tell a clearer picture to the skilled eye. In the logs I can see the alt up and down and the ThrIn sure does not seem to match ThrOut.. The crash is very apparent. lol.
So, I finally upgrade the firmware to rc6 - a pull back rev.. LOL.....
Can you let me know a bit about the crash detection.
If I am flying acro and do a long inverted roll do I need to worry that the motors are going to cut out or are you monitoring height change as well?
What is upside down? past 90 degrees?
2 seconds inverted roll is a long time but could happen.
I read this for the AC3.1-rc6 release notes "GPS failsafe options to trigger AltHold instead of LAND or to trigger LAND even if in flight mode that does not require GPS"
Could you explain why checking /triggering GPS failsafe if you're flying in flight mode that does not require GPS ? This could be annoying don't you think ?
I won't be available much today so there will likely be a 24h delay on the review of those -rc6 related logs but I'll be back looking at them tomorrow though along with giving Emin's another review.
I have went over your logs again. I will try to describe what the logs show happened.
You were in Alt Hold during the crash and you were using your original pid values. The first sign something is wrong is you get an uncommanded yaw to the right with a pitch down. This seems to be handled by the controller and the yaw stops. Then you get a second yaw acceleration and you react by countering the yaw and reducing the throttle to reduce altitude. At this point the APM needs maximum throttle to maintain what little control it has left. You then drop the throttle to minimum and this is then followed by a third yaw acceleration and the APM has well and truly lost control of Yaw. At this point we start to see a voltage and current sag. Finally the copter hits the ground and flips (or flips and hits the ground).
From the ATT and CTUN logs, it looks like you ran your battery low and the copter no longer had enough power to maintain altitude. You may have entered into your esc low battery cutoff. Have you turned off your low battery esc cutoff?
So after going over the logs, as carefully as I am capable, there appears to be only two explanations to the crash/forced landing you experienced. Mechanical failure or low battery.
As Randy says your voltage and current measurements seem to be broken and don't match your cell count so any indication of battery condition from the logs or mission planner can't be trusted.
It takes a lot of time and effort to analyse your logs in this detail. I have spent well over an hour of my Sunday morning looking at your logs to generate the short summary I wrote above. What you don't see in the analysis above is the time it takes to make sure that Autotune and that gps reception couldn't cause the problem and to look for any other indicators of other possible causes. In the end both Randy and I have come to very similar conclusions.
While I understand your desire to work out what happened. It doesn't come across well to use capslock to write messages stating that no one has looked at your logs when quite a number of people have looked at your logs and given you feedback.
Thorsten, you liked it because you used it. And that is because it was made default and you were kind of forced to give it a try.
That was one of my point when saying it should be left as default. Now that when it is set to zero, many people won't even bother giving it a try and keep using their copters the way it is (MOT_SPIN_ARMED=0).
I think it wasn't necessary to change the default to zero again. I hope it reverts back to 100 before the final release. I truly believe this is what it should be...