Closed ranqingfa closed 7 years ago
Cant upload log file?
logs here http://pan.baidu.com/s/1c9uxeI
Plane has no "land mode". When an AUTO mission ends without a landing in it then it will RTL which looks like circling above home.
I'll take a look at your log soon.
On Feb 18, 2017 1:30 AM, "Leo Ran" notifications@github.com wrote:
logs here http://pan.baidu.com/s/1c9uxeI
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ArduPilot/ardupilot/issues/5753#issuecomment-280833922, or mute the thread https://github.com/notifications/unsubscribe-auth/AEj7GwCbcg6XvDub_uUaGDhCGLJFnozNks5rdrokgaJpZM4MFDsk .
@magicrub Tks a lot
I see two missions in that log. You booted up with a mission that included a LAND but later there's another mission, which you loaded later (maybe before launch?) that does not have a land.
Either way, it looks like you were stuck in LOITER_TO_ALT which is odd
Two missions?I'll check it later! LOITER_TO_ALT, it's because I want my plane to go down in circle flying, so set it in one waypoint parameter, but uaually it works well while landing.
When it boots up it logs what's in memory. Then you upload a mission and it logs that. It's normal. However, the loitering forever is not normal.
So,I think maybe the baro alt is not right, so Loiter cant down to the alt being set, so it stucks in Loiter?
Ive seen a lot big baro alt value errors in 3.7.1! In this flight, we saw the alt=50m on mission planner, but in logs, never lower than 80m, and when we landed it onto the ground manually, the alt=-17! It's so wired! Normally, it Loiter to alt, when alt = 80m(set in waypoint)plane will go to next waypoint(parameter = land )and it will dive to the ground!
In the flight just at that movement, we saw plane flying in circle for a long time, we checked the alt=50m on mission planner
Your log shows the baro holding steady at 80m. In fact, it easily reaches 80m before it even gets to the loiter point.
Here is the tlog: http://pan.baidu.com/s/1kV2q05p Ive checked,while loiter_to_alt, alt= 80m in log, but alt= 55m in tlog!!!
In order to have better land accuracy, I changed the ALT_MIX value to 0.5, dont know if this is a matter.
When landed on the ground, the alt=-10, not -17, on mission planner.
Fixed in firmware 3.8 ? Could I know the problem detail?
We have being flying a lot recently, it seems big baro errors happen frequently now, and I think maybe this is the main problem here. But with firmware 3.4, almost never seen this big baro errors
It's related to PR #5674. If you notice in the tlog you launched your aircraft at -17m altitude. It was around -2m until you armed then it jumped to -17m. There was an altitude mixup when arming, the source switched due to a questionable GPS lock so an altitude with a large error was locked-in as your home altitude. There's another PR #5750 which is designed to make this solution even more bullet-proof by checking the altitude accuracy before allowing you to arm. in the pasted it was only checking horizontal. Normally those errors are similar but in rare cases you can have a good horizontal lock but a bad altitude lock - it depends on the geometry of the satellites you're currently observing.
In order to have better land accuracy, I changed the ALT_MIX value to 0.5, dont know if this is a matter? So its because the source switching to GPS altitude that make a larger alt error?
ALT_MIX has actually been disconnected for over 2 years, the param does nothing. It was (finally) just removed a week ago via commit https://github.com/ArduPilot/ardupilot/pull/5699/commits/a70866e6168d088ef868cd75e8a9faf2735d322c
Can I stop the mixup switching to gps source altitude?
no, it's a newly introduced bug that has been fixed. You can fly it now on master and it will be on the next release
OK, Tks so much!
This issue is still open while @WickedShell confirms this bug is confirmed gone.
Ok! @magicrub
I think this can be closed now, especially since https://github.com/ArduPilot/ardupilot/pull/5763 really catches all cases of ever getting "stuck" for any reason
Want to know, why using GPS alt as an source in to calculate the plane alt, we have found a lot of alt drift(big error) here, result in plane falling during land when alt = 5-20m , usually because autoplilot thought the plane was already on the ground but it was not.
@magicrub
Also "There was an altitude mixup when arming, the source switched due to a questionable GPS lock so an altitude with a large error was locked-in as your home altitude. ” , I want to know which source was selected due to the gps lock. @magicrub
@WickedShell @magicrub Need your help, thanks a lot.
@ranqingfa please do not hijack an existing, closed, issue/PR. Start a new one for a new unrelated discussion.
For Help questions, please post on discuss.ardupilot.org or gitter.im/ardupilot/ardupilot
To answer your question briefly, GPS altitude is horrible. Some parts of the planet are better than others, also some have SBAS, some don't. So, in general, it's always best to fly with baro unless you have RTK.
Actually, the plane cant get into Land Mode, as usual it would. My plane flys in auto mode well, and when it ends mission, it should land, but it just flys in circle, cant land. This happens many times, but in firmware 3.4.0 never happened. It seems because the baro data drift a lot, so it does not get into Land Mode. Is there any judge if the baro data drift l a lot, it just flys aroud?
ArduPlane 3.7.1
[ ] All [ ] AntennaTracker [ ] Copter [ x ] Plane [ ] Rover
fix wing
pixhawk
Logs in attach file