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!
Cheers!
PS: Provided the mode will work well during the flighttests I hope it can get merged later into the main AP repo 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 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!
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.
Hi,
we flight tested the code successfully last week!
Today I also added your climb-out/takeoff heading option - which we will test this Wednesday weather permitting
I set up the parameters to have a range in MissionPlanner (modifying the MissionPlanner .xml files for parameters), but I also added abs() statements in the code to make sure it would be positive to prevent errors or failures
I will update on how the testing goes and write some documentation (how the flight mode is set up/to be used and also about how to set up a flight mode for plane).
Once I got that I will perhaps start cleaning up the code to be ready for a pull request (perhaps I will also need to write it for Plane_4.4…). Do you think that the ArduPilot developers (or end users as well) would be interested in that?
we got the autolanding mode working very well with different options for automatically scaled flaps (depending on windspeed), approach direction options (preferably always into the wind, but allows to overrule/set a margin for crosswind angles), etc.
The only things that would be needed are that the plane’s landing parameters would need to be set once, and each time before arming the home point and nose direction will have to be set for the touchdown point and runway direction.
For our purposes, we don’t require reworking/cleaning up the code, but if @tridge would be interested in merging the autolanding mode into the main branch I would be happy to do that. Please let me know!
Best Georg
PS: Documentation is coming soon for more information
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!