Dev: Accessing heading logs during flight from within AP firmware (new autolanding flight mode)

Hi all,

I am working on creating a new flight mode that automatically sets up a new landing mission, based on where the vehicle was armed and what its heading was during arming/takeoff for runway information.

For that I need to know a way to access the log files (or another place where the heading during arming/takeoff is stored) during flight from within the AP software (a flight mode very similar to the auto mode).
Can anyone point me to which function I could use or how to achieve that?
@tridge knows how to get that perhaps?

Any help is appreciated!

PS: Provided the mode will work well during the flighttests I hope it can get merged later into the main AP repo :slight_smile:
Link to repo autoland flight mode

Wouldn’t it be easier to add a handler to takeoff mode to store takeoff heading?
Some boards don’t support logging or the log might have been overwritten or otherwise become unavailable or corrupted.

you can check on copter code how it is done.
On takeoff we store the home heading and then on landing we turn the drone to be the same heading. I won’t be surprised that something already exist into Plane codebase

Hey, thank you for your quick reply!
Yes, I came to the same conclusion - there is a AP::logger().get_log_data() and corresponding getter functions, but I agree that it might be a bit risky regarding corruption or not being supported with different boards/parameters.

Therefore I added a plane.initial_armed_bearing variable that is being initialized during the arm procedure.
I found that the Copter code is already using a similar approach for their RESETTOARMEDYAW functionality.

@khancyr you were a little faster typing than me :wink: I couldn’t find a home heading variable in plane yet, so I made my own, if there exists one I’d be happy to know so I can use that one instead!

That is too early. If using Takeoff mode one can arm, shake to wake and then throw in different direction. You need climb out course, not arm heading.

In general I agree that the climb out course is the angle (or its 180deg counterpart) you want to use for landing, but especially during a hand launch we often had close encounters with trees as the launcher would give the plane a slight rotation by accident.
So for our use case we decided to include the plane to be aligned with the runway during arming in our pre-takeoff protocol. Though it would be a great addition if one could perhaps choose between these two options with parameter settings later on (eg. in a catapult launch there won’t be variation in heading)!

TBH I would make this course a parameter and have an option to set it on arm, or during climb out if not set by the user.

This way you could adjust or preset landing course using GCS. The parameter would have to be volatile (reset at least on boot)

The options could be:

  • Disable auto set
  • Set on arm (not during climb out)
  • Allow back course
  • Reset user value on landing.

I would store automatically set values as -heading and require users to input positive values, inverting if user sends negative though I am not sure if param system allows for that.

I am not sure which option is less confusing storing inverted heading or storing headincg-360
0 would be a special value meaning not set.

PS I suspect a lot of users don’t have strict operating procedures therefore it is safer to assume that climb out/takeoff roll is better indicator of runway direction.