Change in reset to altitude on ARMing?

202 views
Skip to first unread message

David Pawlak

unread,
May 21, 2015, 6:55:15 AM5/21/15
to drones-...@googlegroups.com
I loaded and flew 3.3rc4 yesterday, and as reported on DIY, I noticed that the altitude does not reset with ARMing.

I did a short test as the sun was going down, after a thourough recalibration of everything. The flight was really quite nice, with the only problem being the altitude drift.

Has something changed that it isn't reseting altitude on ARM, or is this some kind of bug?


Craig Elder

unread,
May 21, 2015, 2:53:32 PM5/21/15
to drones-discuss
David, please enable logging before arming and post a logfile showing the behaviour you observe.  thanks

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

David Pawlak

unread,
May 21, 2015, 7:11:53 PM5/21/15
to drones-...@googlegroups.com
OK this was a good example but on the bench. I ARMed near the end, but no reset of alt. at all.

This one was taken after some testing outside, so the drift isn't quite as bad.
2015-05-21 07-29-32 4.bin

Randy Mackay

unread,
May 21, 2015, 11:08:45 PM5/21/15
to drones-...@googlegroups.com

David,

 

     Thanks for the report.  Ok, so indeed you’ve stumbled onto a change in behaviour vs AC3.2.1 related to how we handle the ahrs home vs EKF origin.

 

     In AC3.3 we’re not resetting the home altitude on arming if we arm before we get GPS lock (or more accurately before the EKF sets its origin).  We also never reset the barometer altitude anymore.  It’s possible to make it act like AC3.2.1 again by recording a take-off altitude but it makes the code a little more complex so I was hoping to avoid this until AC3.4 which should include some big-ish changes to allow copter to use absolute altitudes and terrain altitudes.

 

     I know that Jonathan is also not happy that we’re not recording the take-off alt.. if enough people dislike this change we could fix it… I’m just worried about making a change that could lead to more bugs at this late stage.

 

-Randy

--

David Pawlak

unread,
May 22, 2015, 7:06:32 AM5/22/15
to drones-...@googlegroups.com
Ahh, great, then I'm not going crazy :p

When you say:

"In AC3.3 we’re not resetting the home altitude on arming if we arm before we get GPS lock (or more accurately before the EKF sets its origin).  We also never reset the barometer altitude anymore."

Does it mean that IF we arm before lock it resets altitude? Or never, never reset altitude.

The problem is that from power up "cold" to "dialed in and stable", the unit will gain up to and over 10m of altitude. Sensors warming up I gather. I noticed in my log that the internal temperature rose several degrees. So the only real solution (without altitude reset) is let it warm up (10 - 15 min) then reset power. That way there's only about 1 or 2 meters of increase. It's normal in aviation in any case, to set ground altitude before take-off.

Of course the other problem is autoland. If it thinks its 12m above the ground, it will land pretty hard because it's still in fast descent mode. Also the log analyzer thought I had a brownout because recording stopped at 9m altitude.

BTW, I thought I saw somewhere in going over all the new parameters, that there was something there (was it a SW7/8 option?) that "set ground alt". If that was available it could be very useful while we wait for 3.4, although I think newbies are going to have (expensive) problems with this new behaviour.




On Thursday, May 21, 2015 at 7:55:15 AM UTC-3, David Pawlak wrote:

Randy Mackay

unread,
May 23, 2015, 2:47:42 AM5/23/15
to drones-...@googlegroups.com

David,

 

     It only resets the home alt if it’s gotten a GPS lock first.  So take-off early and it won’t reset the alt.

 

     I see what you’re saying.. so we will have another look at making it behave like AC3.2.1.  Here’s the issue raised for it in github:

             https://github.com/diydrones/ardupilot/issues/2322

 

-Randy

 

From: drones-...@googlegroups.com [mailto:drones-...@googlegroups.com] On Behalf Of David Pawlak
Sent: 22-May-15 8:07 PM
To: drones-...@googlegroups.com
Subject: [drones-discuss] Re: Change in reset to altitude on ARMing?

 

Ahh, great, then I'm not going crazy :p

When you say:

--

David Pawlak

unread,
May 23, 2015, 6:45:35 AM5/23/15
to drones-...@googlegroups.com
Great!

I've only tested 3.3rc4 on one of my vehicles (IRIS) and can appreciate the "intricacy" of the new Home/EKF Origin logic. So thanks for giving this some attention.

I did more testing outside with good GPS (HDOP =1.6). I waited about 10 min after power-up, then reset power and waited for a good lock. The log shows 1 m at ARM and bumps down to 0 at take-off. Interesting if that is the logic.

However, as you see the altitude at landing after 5 min is nearly 5 meters. I know that one can expect this "altitude creep" perhaps due to pressure change, but to me it seems more than it has usually been. Since putting 3.3, all my logs are reported as "possible brown.out". There seems to be more creep than usual.

Also, if it is creep due to altitude change, one would expect that sometimes it goes negative. I haven't checked all my logs thouroughly, but I can't remember it "creeping" negatively. The altitude always seems to increase.

So just some extra input. If you're in the area looking.



On Thursday, May 21, 2015 at 7:55:15 AM UTC-3, David Pawlak wrote:
2015-05-22 17-13-49.bin

Thorsten

unread,
May 23, 2015, 9:38:20 AM5/23/15
to drones-...@googlegroups.com
Paul's RP https://github.com/diydrones/ardupilot/pull/2310 should also help - or?

Randy Mackay

unread,
May 30, 2015, 2:24:45 AM5/30/15
to drones-...@googlegroups.com

 

     I think we’ve covered this and we intend to fix it in –rc6.  It’s not a bug so much as a choice made for code simplicity.

 

-Randy

Randy Mackay

unread,
May 30, 2015, 2:27:45 AM5/30/15
to drones-...@googlegroups.com

 

     Ah, sorry.  The problem is me answering old emails!  As you were!

 

-Randy

 

From: Randy Mackay [mailto:rmac...@yahoo.com]
Sent: 30-May-15 3:25 PM
To: 'drones-...@googlegroups.com'
Subject: RE: [drones-discuss] Change in reset to altitude on ARMing?

 

 

     I think we’ve covered this and we intend to fix it in –rc6.  It’s not a bug so much as a choice made for code simplicity.

 

-Randy

 

From: drones-...@googlegroups.com [mailto:drones-...@googlegroups.com] On Behalf Of Craig Elder
Sent: 22-May-15 3:53 AM
To: drones-discuss
Subject: Re: [drones-discuss] Change in reset to altitude on ARMing?

 

David, please enable logging before arming and post a logfile showing the behaviour you observe.  thanks

David Pawlak

unread,
May 31, 2015, 4:33:32 PM5/31/15
to drones-...@googlegroups.com

Was testing poshold against loiter in 3.3rc5 and got the following graph of altitude. Got the 3D lock (1.56 HDOP) , but didn't reset power after letting it warm up.

No altitude reset. I guess if you're looking at the problem, so this is just more information to digest.

Took off at 12 meteres and landed at 14.

I guess it shows that the small drop at takeoff is ground effect... and not zero reset. It just looks like zero reset when it's "closer to the ground". (When you refered to that earlier Tom, I thought you meant something else..... :p )

Also shows the effect of the pressure bubble with velocity. Don't remember this as being so pronounced in my IRIS as this before. It's not comfortable.





On Thursday, May 21, 2015 at 7:55:15 AM UTC-3, David Pawlak wrote:

Randy Mackay

unread,
May 31, 2015, 9:12:32 PM5/31/15
to drones-...@googlegroups.com

David,

 

     Ok, so the issue here is that the CTUN log shows the inertial nav altitude which is relative to the EKF origin (not the home alt).  It means that we don’t actually log the alt-above home anymore and we should because it’s needed for some things like the altitude fence, parachute’s min alt, etc.  Also I’ll rename the CTUN’s Alt to be EkfAlt and add a new Alt column.

 

-Randy

 

From: drones-...@googlegroups.com [mailto:drones-...@googlegroups.com] On Behalf Of David Pawlak


Sent: 1-Jun-15 5:34 AM
To: drones-...@googlegroups.com

--

David Pawlak

unread,
Jun 1, 2015, 6:18:52 AM6/1/15
to drones-...@googlegroups.com
Great!.

The HUD shows the EKF Alt BTW. 


On Thursday, May 21, 2015 at 7:55:15 AM UTC-3, David Pawlak wrote:

Randy Mackay

unread,
Jun 1, 2015, 6:55:14 AM6/1/15
to drones-...@googlegroups.com

David,

 

     I think the HUD only shows the EKF alt (aka altitude above EKF origin) until you get GPS lock (or more accurately until the EKF origin is set).  Once GPSLock/EKFOrigin is ok that HUD will show the Alt above home which is reset on each arming.

 

-Randy

 

From: drones-...@googlegroups.com [mailto:drones-...@googlegroups.com] On Behalf Of David Pawlak
Sent: 1-Jun-15 7:19 PM
To: drones-...@googlegroups.com
Subject: [drones-discuss] Re: Change in reset to altitude on ARMing?

 

Great!.

--

David Pawlak

unread,
Jun 1, 2015, 4:42:00 PM6/1/15
to drones-...@googlegroups.com
Yes you're right, sorry. This flight I had Tower on my LG and really didn't look at it. It's in feet. I transfered the tlog to my MP and it resets to ground zero on ARMing.

All other bench tests  with MP, were indoors without GPS lock.
Reply all
Reply to author
Forward
0 new messages