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.
Exactly the sam issue here. It does connect ocasionally but so far it seems random. Tried all reset, reboot, MP/PC restart, driver change combinations but no apprent pattern.
I believe it started with MP 1.2.85 (running AC 3.0.1 on 4 boards, no change in fw). When trying to connect Tx LED blinks at 1Hz (I believe sending heartbeats) but MP does not recognize them. Terminal mode works just fine (again, probably because it is not expecting heartbeats).
Hoefully they will fix that soon, it is very annoying, I will try to downgrade to 1.2.84 or earlier if I can find installer for it...
P.S. MP 1.2.85 change log quote: "fix bad first packet in mavlink logs". Well, you fixed it allright :))))
How did you find it after the tuned parameters.
It is funny, it looks like you saved them but the gains look like they have been overwritten again. Looking at your tune it should be something like this:
Roll Rate P = 0.04
Roll Rate I = 0.04
Roll Rate D = 0.004
Roll Stab P = 7.35
Pitch Rate P = 0.1
Pitch Rate I = 0.1
Pitch Rate D = 0.008
Pitch Stab P = 7.35
I have to correct myself here. Despite what I think we should do :) we do give the pilot control of roll and pitch during land.
thanks Shyam..Rainer, John..
thanks for the inputs..
I have changed out 2 motors (a few weeks ago - 1 motor was as John described hub moves up - and the other had a slightly wierd sound) and down graded to 3.0.1 and the problem still remains..
vibes are within limits..
(i am currently on RC4)
all ESCs are the same all motors are the same :(
I have included the logs of this flight -ignore the last throttle spurt.. i tried to take it up in the air..(that was fun)
the problem i am worried about is that the "motor burps" are not really random.. but cyclic and get quicker as time goes by....
i dont really know how to interpret MOT logs.. so if anyone can help that would be great..
i have also logged CTUN, ATT, CURR which maybe interesting..
Switching back to 1.2.84 solved this problem (as expected). Also, found this link which shows the same issue already reported to MP issues: https://github.com/diydrones/MissionPlanner/issues/212
I took your suggestion to turn off the auto level in SPORT mode, but it gave me very weird behavior, then I had a nasty crash. Log attached.
1. Took off in STAB mode, was flying fine.
2. Switched to SPORT mode. Tried moving roll and pitch, but the copter didn't respond at all, just stayed perfectly level!
3. Switched back to STAB mode, copter responding fine to roll/pitch commands again.
4. Switched to SPORT mode again, but it still wouldn't respond at all to roll/pitch, except to vibrate loudly when I moved the sticks, so I switched to STAB again.
5. Tried LOITER. Loiter responded to roll/pitch, but a big roll/pitch input only produced a small angle response (this is very clear in the log too).
6. Tried SPORT one last time, but as soon as I entered SPORT mode, copter fell out of the sky. Flipping to STAB and raising throttle didn't do anything to stop the fall. Broke 3 props, destroyed a clover leaf antenna, and a bunch of other minor damage.
I'm guessing what happened is the strong vibrations caused a mechanical or electrical failure resulting in a motor loss, which caused the copter to flip over and fall to its death.
But how to explain why SPORT mode wouldn't respond to pitch/roll input and would just vibrate upon stick input instead?
PIDs are completely unchanged from an autotune flight I did the day before this incident.
Very sorry to see your crash. The problem is that you still have ACRO balance roll and pitch set to the old values of 200. This was a percentage and we dropped it and they should now be 2. So this is like having a Stab P of 200.
I did find that you can't turn off auto level any other way than to set ACRO_Balance to be zero so this is something we should change.
Again, really sorry that you crashed mate!
Randy, I'll try to dig out the OSD recording of the flight I described above and post it after work tonight. it shows flight mode, RSSI etc. ( I don't have a file with the telemetry) Unless the code has been changed in a recent release candidate you can not regain control by switching modes when battery threshold triggers landing mode... I tried that furiously as well as banging around the sticks..... the mode remained in land which makes sense from a code perspective. if you are checking for a battery threshold and are below it, the code doesn't care what position the mode selector is in.
I can't be certain that I couldn't steer in the descent as I moved the sticks to the extremes but I didn't note any particular reaction of my hex to the stick inputs.
If you care to try, this is easy to reproduce. Put your hex (or quad) in loiter, let it sit there over a safe place till the battery fail safe kicks in and see if you can switch modes out of "land"... in mine i can not. it stays in "land" no matter what I do with the radio.
Anyway, I'll look for the OSD video of this behavior this evening.
I have installed the external mag to the APM2.5
I cut the trace of the compass on the board but if not I connect the external compass in the Mission Planner keeps moving while I move the quad ... This is normal? Or if well cut the trace of the internal compass and exerternal connected, should not move anything in the MP?
Thanks for the report and sorry for your crash. I've just had a look at your logs and the code and yes, you've stumbled on a bug in AC3.1-rc4 and -rc5 in the GPSGlitch protection.
The bug comes after the glitch has lasted 5 seconds and the GPS failsafe is triggered. At that point it switches correctly into LAND but there are two versions of LAND, one in which the horizontal position is controlled as in LOITER and the other where the pilot directly controls the roll-pitch like in Stabilize. Unfortunately it's using the LOITER version..which is obviously not correct because we know the GPS is glitching...so this is the bug we need to fix ... to make it use the LAND but with the stabilize controller. I have a possible fix already but I need to test it further to be sure it's correct.
Not sure if it's much consolation but your log provides real life example of the glitch protection operating that we hadn't seen before. So for example you had the GPSGLITCH_RADIUS and GPSGLITCH_ACCEL set far below the defaults:
GPSGLITCH_RADIUS was 100 (i.e. 1m) vs default of 1000 (10m)
GPSGLITHC_ACCEL was set to 200 (2m/s/s) vs the default of 1000 (10m/s/s).
I would have expected this to be too strict leading to false positives but in your logs it seems to do a good job of catching the glitch well before it gets really bad. Below is the log in excel. Each row shows a GPS message which are coming out at 5hz (i.e. 5rows = 1second). The glitch is detected at row 304 but look at the the hdop which remains good at 1.67 (but we know hdop doesn't update quickly enough)..but then look at the GPS position in column L, it's clearly not correct because by row 314 (2 seconds after the glitch starts) it says the copter is moving 11.45m in just 0.2 seconds..i.e. 57m/s (i.e. 205km/h)...i doubt your copter is that fast! At it's worst the glitch moves 232m in just 0.2 seconds.
GPSGLITCH_ENABLE to 0
Although I think the behaviour here was probably no worse than what would have happened with AC3.0.1 which has no GPS glitch protection at all.
Also as with all the other failsafe features, you can always retake control by changing the flight mode switch, so switching to Stabilize or AltHold would have returned full control of the copter.
Anyway, sorry again for your crash and I'll get a fix into -rc6.
The code uses the Z axis gyro input to determine heading if the compass input is not present so the HUD in the MP will move even when there is no compass input.