I am doing some altitude-sensitive missions, using WP storing along the way.
Sometimes relative takeoff altitude is 7 meters (drifting while preparing payload), sometimes much less.
Recording those WP as relative altitudes, does not help.
Is there a reason to why we don’t automatically reset relative altitude on arming ?
It does reset to zero when arming
nope - I have two AC 3.5.3 .BIN logs , when the UAV stood on ground for >1h while fiddeling with payload, and one of the logs start, when armed (log start) and takeoff, at +7m relative alt.
It doesn’t matter what it does when sitting on the ground disarmed. When you are, the relative altitude resets to zero
There is no such thing as 3.5.7…
of, course, 3.5.7was a typo, it is 3.5.3 , current release. Before arguing, you might want to actually check it , or show me where in the code it’s supposed to do that 
Both the altitude and I terms are reset at arming [init_takeoff()] in Attitude.cpp for Copter
// tell position controller to reset alt target and reset I terms
pos_control->init_takeoff();I am not arguing. I am stating a well known fact. Resetting is something ArduCopter has done since the beginning of time. I do not need to go verify it. It does it, and always has. I’ve watched it do it for 4 years. And so has everyone else. But just in case I Chris cited the code.
Yes Arducopter 3.5.3 resets relative altitude to ZERO upon arming
init_takeoff() does not reset barometric altitude.
Anyway, how would you explain this log:
Right from the first logged altitude, it’s >3m (scaled for better visibility, the noise is within wind-levels.)
Then the altitude just increses during takoff, commandinga baro calibration sets it to zero, but if omitted, what you see below is typical.
I see nothing abnormal there. I’m not going to debate this with you any more than I’m going to debate the sun rising in the east tomorrow morning. Altitude resets to zero on arming. Period. End of story.
just like the log, and GCS still intricate +3m relative altitude on arming - and liftoff, (which you are free to ignore, and not discuss) - nor will the sun rise over the horizon at my latitude until february
The altitude is determined by the EKF state estimator, not by the baro alone. The baro is just one of the sensors. Baro’s can drift or change calibration depending on pressure changes under the rotor, temperature, etc…
That graph looks completely normal for a baro, please post the full BIN so I can point out the altitude reset to zero on arming.
@Andre-K if you think there is an issue with how it works please submit an issue on it on GitHub. Or modify it and submit a PR. There has been updates done by Paul Riseborough, one of which improves the behavior of the EKF Height Origin. Those updates are in master, but not in the stable releases yet.
I would actually love for him to open an issue in GitHub about this. Francisco’s response to it will be great
Since he mentioned he is doing work that requires precision altitude… You’ll never get precision altitude from a baro and accelerometers. It’s really good but it’s not precision. That would be physically impossible to achieve. If precision height above ground is required, then one of the laser range finder devices would be required. If precision MSL altitude is needed, then you need to be realistic about the capabilities of the sensors it has.
Just for my own edification, to make sure I’m not totally talking out my backside… I just powered up and armed by quad sitting here on my table. As you can see, the altitude is resetting to zero the moment I arm. I tested this in both 3.5.3 and master 3.6-dev.
In the log you posted in Github, I noticed you have all your pre-arm checks disabled in the parameters. Is there something wrong that you’ve disabled the checks?
that’s an old log from that UAV’s early flights, temporarily disabled due to magnetometer calibration problems, - picked that log just because It was the smallest one, could as well have trimmed down a 30MB log.
I see that Arcucopter calibration depends on health status of a given sensor, and it seems all can be omitted with no warning back to the caller.
void AP_Baro::update_calibration()
{
for (uint8_t i=0; i<_num_sensors; i++) {
if (healthy(i)) {
sensors[i].ground_pressure.set(get_pressure(i));
}
Try to make the motors not to spin when you arm the copter and check if the barometer still drift
Had the same issue earlier and have checked this extensively. With APM 3.5.3 Baro is reset to 0 on arming without
any issues.
Ok, thanks for the video, but , nobody needs to “prove” it to me, I have been flying AC and AP for years, and have observed it, and have ,plenty of logs where it was reset as expected.
I am just asking if somebody know conditions that would make it behave differently.
