Hi All!

 

I'm working on a research project and we're going through the all the Auto commands for ArduCopter 2.9.1b and we have some questions.

 

Does the parameters hit rad and yaw for WAYPOINT do anything? We have tested them but can't seem to find any effect.

Does the altitude for ROI do anything? Again, we tested it and it didn't do anything.

Does CW/CCW and rel/abs do anything for CONDITION_YAW? It always turned CW even if we set it to CCW and it always turns to the absolute heading, never the relative.

 

On another note, as the quad was flying between waypoints its GPS suddenly thought it was about 250m away from where it actually was. The quad took off and we took manual control of it to avoid a crash. We turned the quad on and off but the GPS was still incorrect(although it was slowly wandering back to the actual position). We went inside for a few minutes (with the quad turned off) and when we came back out the GPS was fine. In fact, it was landing closer to its takeoff than before the glitch. We are running APM 2.5 with the 3DR MediaTek GPS (with the battery attached). Any thoughts about this problem? Is it a one time thing or some deeper problem? This is the first time we have had a GPS misbehave this badly.

 

Thanks for the help!

 

-Jake

Views: 198

Reply to This

Replies to This Discussion

If you search the forum, the 'somewhere else' behaviour is well reported...

Apparently there were some significant changes to the handling of the Mediatek GPS with 2.9.1, and it results in spurious readings being accepted. The explanation being given, is that the damping was removed to prevent lags when tracking, and the code now uses the full resolution of the GPS. However what is 'odd', is that you can take the same GPS module, and record it's serial stream, and while it will wander a few m, it doesn't return readings a huge distance away. However in the copter it does. Currently 'fix' is to switch to Ublox GPS.....

Best Wishes

R_J,

I have been keeping up (kinda) with that discussion but I thought that we had avoided that problem because we had no problems hovering. Also, after the almost fly off it would RTL to within 2m of its takeoff.

 

Does this still sound like the problem discussed in that forum?

 

-Jake

I think there are about three separate problems that all appeared with 2.9.1. For some fixes have since been found, and for other the 'jury is out'.

Now the first real 'killer' one, is the compass automatic calibration. Something (indeterminate) can cause this to record a completely screwed value. When this happens the copter starts moving in the wrong direction to correct errors, and you are in a 'runaway' situation.

The second is the Mediatek GPS one. The behaviour is an increased tendency to suddenly decide you should be several feet (or even hundreds of feet) from where you actually are. Now this seems to connect to the first problem. It may actually be that the distances involved are not that great, but the sudden movement it triggers can sometimes also trigger the invalid compass problem. This way the GPS triggers the 'runaway'. It does seem that switching to manual compass calibration also reduces the worst of the GPS problem, though it does still give significantly erratic behaviour at times.

The third is the altitude behaviour. Three possibly distinct 'versions' of this. There seems to be a problem related to having the inertial as part of the altitude hold, where if the copter tilts significantly, and accelerates, the altitude algorithm 'over calculates' the vertical component of the movement, leading to a pretty steady descent. So you get a descent in altitude hold if you move speedily, or in loiter mode the autopilot moves speedily. This is not too bad, and can be removed by disabling the inertial component in the altitude hold, or setting this lower, though at a cost of slightly degrading the normal altitude hold. Then there is an 'intermittent' oddity with mode switches, leading to a momentary motor cut off. There has to be a pattern to this one, but I'm d&mm*d if I can find it. You can change modes a hundred times and it won't happen, then do it and the motors cut for a moment. Have tried having the copter climb (which does trigger a fractional throttle back if switching to altitude hold, but this is normal/expected), descending, moving, etc.., yet cannot reliably/repeatably trigger this. Finally there is the 'full cut' problem. This one is again similarly rare to trigger, I've had it happen once, and two other pilots near me have also triggered it (one with significant damage). Only 'pattern', was that the copters were stationary and yawing at the time, with in one case altitude hold engaged, and the others loiter, with quite high yaw rates being used. The logs don't seem to actually record this event. Battery voltage stable before and after, but there is a gap in the timings of the GPS packets, as though everything stops for perhaps 1/2 a second. Then there is the command packet as you switch to manual, with high rate of descent recorded, and then a recovery over a fraction of a second.

Your description, sounds like the basic GPS problem. without (thankfully) the others showing. With this, the copter decides to suddenly think it is a significant distance from where it really is. If it being asked to track, or loiter, results in a sudden 'whizz' away. What is strange is that the return to once again reading the position correctly, seems to be damped, taking a while to recover, yet the 'misreading' is instantaneous. Once the position recovers, the copter will continue a track, or do a RTL perfectly well.

For me, switching to a Ublox GPS, brought the distances involved in this down from several hundred metres, to a handful of metres 'worst case'.

With automatic compass calibration 'off', and the Ublox GPS, the code seems to work 99.5% of the time quite well now, with just the altitude problem(s) left to scare you....

Best Wishes

R_J,

Thanks for the recap!

 

I agree that our problem looks to be of the GPS kind.

 

We had a crash last week that looks almost like the altitude problem but we weren't accelerating. We were doing a Auto Takeoff, the quad got almost to height, rolled, and than was unable to regain its altitude and crashed. I posted the .tlog here: http://diydrones.com/forum/topics/hard-roll-then-crash-in-auto?xg_s...

 

Thanks for all your help R_J!

 

-Jake

Reply to Discussion

RSS

Groups

Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service