Hi Jason. Thanks for looking over the log. I'm happy to be help you identify a flaw in the code. Can you expand on the bug found? You said it would correct itself after a few seconds. That's not the behaviour I've observed. With the RTL bug as reproduced, it lasts the entire flight. RTL is completely unusable until the APM is rebooted (if it boots in a good state).
Today I tried a new build with mount, camera and limits disabled. I did 5 flights with no RTL problems - I've never been able to do that since before AC 2.5.5 (or thereabouts). Can some other droners who are experiencing this error try a build with some of these features turned off? Put the following lines into your APM_Config.h:
#define CAMERA DISABLED
#define MOUNT DISABLED
#define AP_LIMITS DISABLED
I doubt CAMERA or MOUNT are the problem, but AP_LIMITS could conceivably be messing us up. Of course, 5 flights doesn't mean the bug is fixed, but it suggests it might be, and 5/5 flights with good RTL is better than my previous average of 1/4.
Also, LOITER mode worked fine today. It usually acts really strange whenever RTL is acting up.
Thoughts, tests, results?
It sounds similar to what you report in your thread. I'm sorry to hear that you lost your drone. I hope you've bounced back...
In your case, do you recall what mode it was in when it started to fly away? I find that STABILIZE always works, but when the RTL mode is acting up, so will LOITER. The only other mode I use is ALT_HOLD, which seems fine when RTL is acting up, but I have not rigorously tested it.
When I looked in your log, the RTL always eventually came back towards home. Do you have a log that shows RTL leaving and not coming back at all?
The bug carried over some values from the previous AP mode, even though it was in stabilize. It could cause a pitch or roll that's seemingly random for a few seconds, but the real nav will take over quickly and return it to normal operation. If the values were high you could be sent in the wrong dir for a while and it may be recovering but not fast enough to be easily noticed.
I have not tested the patch yet. I will this weekend.
Here is the fix - new code in bold.
static void reset_nav_params(void)
nav_throttle = 0;
// always start Circle mode at same angle
circle_angle = 0;
// We must be heading to a new WP, so XTrack must be 0
crosstrack_error = 0;
// Will be set by new command
target_bearing = 0;
// Will be set by new command
wp_distance = 0;
// Will be set by new command, used by loiter
long_error = 0;
lat_error = 0;
nav_lon = 0;
nav_lat = 0;
nav_roll = 0;
nav_pitch = 0;
auto_roll = 0;
auto_pitch = 0;
// make sure we stick to Nav yaw on takeoff
auto_yaw = nav_yaw;
Jason, will this basically eliminate the auto_slew constraints on the rate of change or roll/pitch? It might make the copter change attitude really fast?
I'm actually not sure how long the drone will fly off in whatever its random RTL direction is, as I never let it fly more than a few seconds. Usually there are trees, mountains, roads or other reasons to not let it fly as far as it wants to go. It gets going really fast (>40k/h) and I usually chicken out before it has time to fix itself, if it ever will.
So, no, I don't have a log of RTL leaving and not coming back as I always reset to STABILIZE and fly back home manually. In the log I recently posted I note that most of the RTL events the the lat_error and long_error often do decline during the course of the RTL, but not in all cases. Even if it does decline, functionally, RTL is useless if it returns home _after_ the drone flies into a tree 300m off course!
At any rate, I'll do some more testing of my current build (with CAMERA and MOUNT, but no AP_LIMITS) if there's a break in the rain.
Did some more testing today with a build that had CAMERA and MOUNT, but no AP_LIMITS. RTL exhibited its usual error in 3 of 4 flights. This suggests AP_LIMITS is not the culprit. It did seem to good to be true.
I'll try again with CAMERA and MOUNT disabled, and will also try jasonshort's patch. Has anyone else tested jason's patch? I doubt that CAMERA or MOUNT would cause this error, but it's possible, and we have to turn over all stones until this bug is found.
I didn't study your logs and video, but I've also experienced occasional fly-aways. My problem seems to be that the compass heading error grows until it is more than 90-120 deg out. Two days ago it ended up going away at a steady 97 km/h! I found it 2km away and from the Go-Pro video (that amazingly survived the 200m drop) I could confirm that the heading displayed on the GCS was not the actual heading.
This has happened before on a similar mission and the common factors were:
Distance to waypoint >1.8 km
Direction to waypoint South
Didn't do manual compass calibration before flight since it seemed OK
Cross-wind component 20+km/h
I've strangely never had the problem when flying similar missions in an East-West direction.
Next I'll try and do manual calibration and then switch off auto learn for the compass.
Hi Murray. Wow, your drone is fast! I'm happy to hear that you got (at least part of) it back after such a crazy fly-away.
Someone else had mentioned the compass and I did note that the compass bearing is sometimes incorrect. Looking at the video recordings of the OSD from my various testing flights in the past few days, I see that the flights where the compass is off, RTL doesn't work and where the compass is (more or less) correct, RTL works. Moreover, when the compass is only about 45 degrees off, RTL and loiter mostly work, but end up spiraling around their loiter or home point.
That does suggest the compass bearing being the culprit, and also suggests a quick test, before takeoff, to see if RTL is going to work.
As I'm not clear on how the compass is calibrated, I don't really know how to fix this, but I'm going to look into it and keep an eye on the compass for my future tests.
I'm glad to hear that you also think the compass is the culprit. I've had some interesting things happening with regard to that: I have an interchangeable electronics box that contains APM2, RC receiver, 3DR radio, Video Tx and Ublox GPS. On one quad the compass was steady, on the other it seemed to deviate when throttle was applied. On the deviating one I then put a piece of tinfoil between the ESC's and electronics box. Unfortunately I don't think I did the grounding properly, so first time I started up, the quad was facing south and the compass indicated north. Turning the quad only temporarily displaced the compass before it returned to indicate north. Manual calibration didn't work while quad was facing southerly direction. After 3 attempts I faced the quad north, did manual calibration again and it was perfect. I now activate the APM facing North just as a precaution and test it to see if the compass deviates. Didn't do that properly before the fly-away.
I was also surprised to see how fast the quad can go! That was without losing altitude and now I have the logs and video as proof. I have to add that it was going downwind at the time. Fortunately my custom frame design is doing really well with all the crashes. After 10+ crashes from 15-200m altitude I've only replaced rivets, props and one motor. Will post plans of it sometime.
OK, after playing around with compass calibration and digging through the code I've come across a potential cause of my woes.
I tried turning off learning and testing live calibration, I tried learning, I tried manually tweaking the COMPASS_OFFSET_Z a bunch of times and the compass (in Mission Planner and on the OSD) point in the wrong direction. No matter how many times I boot up the APM, the initial direction on the compass in 0 degrees, north. When I position the drone facing north before booting up it gives me the correct bearing. If it's not facing north the bearing is off.
Now looking through my recordings of RTL error testing (I've got quite a few) I notice an interesting trend: the times I boot up the drone facing north, RTL works fine. Most of the times I boot it up facing another direction, RTL doesn't work. When facing south, it's usually way OFF. If facing a bit off north (say 45 degrees), RTL sort of works.
Is this normal? Are we supposed to boot up the APM facing north? I don't recall reading that in the instructions anywhere. Is this a new "feature", as I've only noticed this RTL error in recent firmwares (since about 2.5.5, but I'm not sure when it appeared). Is this too simple of a fix? Am I crazy? Do I need to bring a compass to the flying field with me each time?
Yet another idea that bears testing.
no this should not be normal, and I too have a APM 2.0 with exactly that problem, "test magnetormeter" works, but it when it boots it's always north, using another APM works as expected.
You're right. I checked the heading on bootup of my other copters. They boot up showing "N" for a few seconds, then it swaps around to the correct heading.
Do you know more about the error? Is it hardware or firmware? Did you ask tech support or file a bug report? Is it an RMA-worthy fault?