When entering Loiter mode, my DJI F450 clone quadcopter makes very strong “toilet bowl” movements.
(radius approximately 10 meters, 30 feet)
Somebody has suggestions/ideas how to correct that?
A Log file and the compassmot result is attached.
Some remarks on my configuration:
Copter flies very stable in Stabilize mode, vibrations are low (see logs)
APM2.0 board with external compass. The compass works perfect when the copter is on the ground.
No noticeable deviation of the compass yaw value when the motors are spinning.
Compassmot shows 1% interference at 3/4 throttle
Internal GPS of APM2.0 board
I own another quadcopter with a APM2.5 that flies very stable in Loiter with similar PID values.
Any suggestions are greatly appreciated!
Thanks in advance and best regards
When entering Loiter mode, my DJI F450 clone quadcopter makes very strong “toilet bowl” movements.
(radius approximately 10 meters, 30 feet)
Somebody has suggestions/ideas how to correct that?
A Log file and the compassmot result is attached.
Some remarks on my configuration:
Copter flies very stable in Stabilize mode, vibrations are low (see logs)
APM2.0 board with external compass. The compass works perfect when the copter is on the ground.
No noticeable deviation of the compass yaw value when the motors are spinning.
Compassmot shows 1% interference at 3/4 throttle
Internal GPS of APM2.0 board
I own another quadcopter with a APM2.5 that flies very stable in Loiter with similar PID values.
Any suggestions are greatly appreciated!
Thanks in advance and best regards
DavooD[/quote]
Are you certain that:
your compass is perfectly aligned with the APM2
your compass_orient of 2 (Yaw90) is correct
your compass declination of 0.0125 radians (~0.72 degrees) is correct
MAG isn’t enabled in your log. This makes it difficult to diagnose your problem. I tried to do without but I can’t find an effective way to do it. Toilet bowling loiter is always going to be a compass issue.
Thanks jschall for the fast reply and your suggestions!
The compass is aligned correctly
When doing a ground test, mission planner shows correct heading. (0° when pointing the quad to north)
The compass label is pointing upward, same as the integrated compass on the APM2.0 board.
It’s just rotated 90° counter-clockwise around the yaw axis
The compass was in Auto-declination mode.
I did another test flight today with manual declination. (see attached logfile)
During loiter, the copter moves back- and forward within approximately 20 meters.
The movement doesn’t feel like the “toilet bowling” effect, it more feels like the GPS changes its position and the copter tries to lock in to these changes.
When rising Loiter_P, the effect gets stronger but basically stays the same.
Eventually, the GPS values are bad? I’m using the integrated GPS of the APM2.0 board.
I also tried to deactivate the compass motor compensation - without any change.
The strange thing is that you can see this back-forth movement int the latitude value of the GPS graph…
I enabled COMPASS logging and attached the logs.
Any suggestions?
I gave up on my APM 2.0. The software left it behind long ago.
I think the last version it flew correctly with was 2.8.1.
After 2.9 and beyond, my APM 2.0 never flew right until the day it buried itself in the dirt.
Now, (rebuild mode) I’ve compiled 2.8.1 on my own because you can’t download it any more. And the compile instructions don’t work, so you have to figure that out. You’ll have to use an earlier version of Mission Planner too.
I don’t mind so much that the project has marched on into the future, but I wish it had left behind better support for earlier adopters. Just somewhere to go for APM 2.0 users that says “You need to load this this and this”, and it’s all ready to install.
TECHNICALLY… You can run the latest version. But unless you are into cutting runs and soldering (and trusting your work) it’ll fly like crap. Reason being the new code is written to perform well on the Ublox gps and we have Mediatek. So the quad hops around like a jumping bean on a hot griddle in any “position hold” mode.
My APM 2.0 will probably end up in a plane where it should work better. For now it’s just another spare, used part laying around. Not sure if I’ll finish rebuilding or not.
[quote=“cyberbillp”]I gave up on my APM 2.0. The software left it behind long ago.
I think the last version it flew correctly with was 2.8.1.
After 2.9 and beyond, my APM 2.0 never flew right until the day it buried itself in the dirt.
Now, (rebuild mode) I’ve compiled 2.8.1 on my own because you can’t download it any more. And the compile instructions don’t work, so you have to figure that out. You’ll have to use an earlier version of Mission Planner too.
I don’t mind so much that the project has marched on into the future, but I wish it had left behind better support for earlier adopters. Just somewhere to go for APM 2.0 users that says “You need to load this this and this”, and it’s all ready to install.
TECHNICALLY… You can run the latest version. But unless you are into cutting runs and soldering (and trusting your work) it’ll fly like crap. Reason being the new code is written to perform well on the Ublox gps and we have Mediatek. So the quad hops around like a jumping bean on a hot griddle in any “position hold” mode.
My APM 2.0 will probably end up in a plane where it should work better. For now it’s just another spare, used part laying around. Not sure if I’ll finish rebuilding or not. [/quote]
The only real performance difference between APM 2.0 and APM 2.5/2.6 is the built-in MTK GPS, which is quite terrible.
OP: I suspect that it is not your compass and may in fact be your GPS. In which case, there’s not much that can be done.
Oh, sorry. Very poor thoroughness from me. I was so focused on compass that I didn’t notice your vibration levels. They seem quite high, I’m not sure if they’re a likely cause. I’ll confer with Randy. I’m sure they’re marginal at best.
I’m satisfied that your compass_orient is correct as your accelerometers correlate with your GPS when rotated into earth frame. That leaves three options:
vibration
GPS
tuning
You’re using default navigation gains, so i doubt its tuning. You could try backing off your navigation gains.
Otherwise, it could be that the built-in GPS doesn’t work well with INAV, or it could be that your vibration is too high.
Vibration levels are within the acceptable range I think.
My guess is that it’s the GPS that is the problem or our inertial nav is not well tuned to work with the Mediatek. Although we did test somewhat with the Mediatek a long time ago, we’ve tuned the inertial nav to work best with the Ublox which is a 5hz update rate (vs 10hz for the Mediatek) but also the lag on the Ublox is much less (about 0.3sec vs 1.0 second for the Mediatek).
Personally I just don’t think it’s worth trying to get a decent loiter with a Mediatek. Before inertial nav we spent literally months of developer time trying to get a good solid loiter with the Mediatek. At one point we had 3 developers all working on different methods to try and improve the loiter. They all failed and then the Ublox showed up and Loiter instantly got a lot better.
I thought about this a bit more overnight. If the issue is that the inertial nav is not well tuned to the Mediatek GPS it might help to reduce the INAV_TC_XY parameter. This controls how much influence the GPS position has on the accel+GPS position estimate. A lower number means “trust the accels more, the GPS less”. During testing with the UBLOX I tested values from 1.0 up to 2.5 and found very little difference but with the Mediatek it might help. If the number is made too low then the position estimate will just drift off. If it’s too high then the position estimate will be just like the GPS value and will jump around a lot.
Thank you very much for all your suggestions!
Based on this discussion, I decided to mount a new APM2.6 with external uBlox GPS on the same quadcopter.
During the the first test flight today, loiter was very stable although it was quite windy outside!
The PIDs were exactly the same as in the old APM2.0.
Maybe I’m going to test my “old” APM2.0 and the external uBlox GPS another day when I have some spare time. The GPS connection cable has to be soldered because the connectors have changed…
No, higher time constant means that it takes longer to drag the solution towards the absolute measurement (GPS).
So, going on the assumption that the problem is the GPS, you might be able to tune the INAV to use the mediatek by increasing INAV_TC_XY and also by changing the code to delay buffer more accelerometer samples (currently it buffers 15, if I recall).
Keep in mind that ublox is 100x better than MTK and you will never loiter nearly as well with an MTK.
