Recently I downloaded new firmware to my pixhawk. When I connected pixhawk to GCS(both Mission Planner and Qgroundcontrol), I found that the it always shows an altitude of 0. It’s been a few days and the bug hasn’t been corrected. I wonder if the developer team is aware of this problem?
Is there anyone who has same problem?
Or if someone use firmware 3.4-dev and altitude on GCS works fine, please reply something so I can look for my own problems…
Thanks a lot!
Frank
Hi Bill,
Thanks for helping.
I’m using the same version of MP as you, but the thing is I cannot find the AC version you use(d8270b9e) anywhere in my git log. My branch is even with ArduPilot:master. Maybe could you try any quad v2 firmware from here?Index of /Copter/2016-04
Regards.
Altitude is relative to the home alt. Which is set a the zero point on arming. Did you lift the copter from the table?
I tested using master at HEAD (6e546ba) but I applied one commit to add my testing location to sitl. It doesn’t change the code
You don’t apoear to have a gps fix. Go outside , wait 30 minutes with the copter powered on and try again.
Are you sure it has something to do with GPS?
Before commit c046a949, all firmwares work fine for me without fixed GPS.
Besides, I think the altitude is mainly the fusion of baro and accel data.
I’ve tryied outdoors and there’s correct altitude display.
However, when I go back indoors and reboot, again it turns 0. That shouldn’t be normal.
Did you manage to solve this?i have the same problem ,after i installed 3.4 alt always shows 0.00m or max 0.02m .
I have no idea what is wrong…
Maybe the baro is damaged or something,i will try to replace it to see if it was the problem but i have to wait for some tools for desoldering it.this started to happen to me after one flight in which the quad raised a lot of dust so probably some dust got into one hole of the baro or i did something wrong when cleaning the dust off the board.
I’m pretty sure that it is not a hardware problem. So I recommend you to save your effort.
This problem will not affect normal flight. It only occurs indoor without GPS.
I agree this doesn’t sound like a hardware issue. What may be happening is we may not be updating the relative-to-home altitude until home is set and/or the vehicle is armed. It’s possible this behaviour has changed since Copter-3.3. We can probably change it back to the old behaviour but let me think about it a bit.
Txs for the report.
Hi I have a question irrelevant to this topic and hope you would help.
In the system there’s a ‘home’ and a ‘EKF origin’. I think home is the location where the vehicle is armed, but what is the origin?
And what is the real altitude used in the control loop? Guess it’s a relative value, but what’s the benchmark?
Regards
The EKF (which is responsible for attitude and position estimates) creates it’s own origin (specified as an absolute lat,lon,alt) when it thinks it has a good GPS lock. This origin never moves from then on unless the flight controller is rebooted. The navigation controllers (used in Loiter, Auto, Guided) internally use the EKF origin.
The “AHRS Home” is a separate location used to specify where the vehicle will fly to for RTL and also it’s used to display various things on the GCS (i.e. distance to home, etc). Also we use the home position to translate the alt-above-home specified in missions (and other places) to alt-above-origin before we pass them into the navigation controllers.
That is very detailed. Thanks a lot!