Plane: takeoff to xtrack to virtual wp ahead instead of heading-hold #14679
Conversation
|
I'll be flying this in a couple days from now. Would love some feedback about it before then |
| // when true, we will follow the recorded takeoff heading. | ||
| // when false, we xtrack to a virtual waypoint 10km ahead of us on this takeoff heading | ||
| // TODO: turn this hardcoded value into a param/option? | ||
| steer_state.locked_course = false; |
There was a problem hiding this comment.
An improvement would be to start off as true and then flip to false one we gain a little altitude, like 10m. That would solve any ground-steering vehicle issues and not induce any funny low-altitude behavior.
There was a problem hiding this comment.
This relies on starting with a good initial velocity vector. I had to look at this for a fast plane that had a longer takeoff run a while ago and ended up adding an option to use the takeoff waypoint location to set the desired ground track - see priseborough@a6d2b2b
|
This has been flight tested and works great! I might have a few tweaks before I want this merged so I'll leave it as WIP for now |
|
I've been flying this for almost a year and is a required part of being a good citizen of taking off on a runway and not flying over crowds of people and/or crew and buildings on the sidelines. Any more comments on this? |
magicrub
force-pushed
the
pr/takeoff_xtrack
branch
from
7bf2952
to
38ec651
Compare
|
rebased. |
|
I've been waiting for this for more than one year... Any chance this feature will be included in an official Arduplane release anytime soon? |
|
@danvel9 I've totally forgotten about this. I'll follow-up and rebase this so it's ready to be evaluated again for a merge. |
magicrub
force-pushed
the
pr/takeoff_xtrack
branch
from
38ec651
to
3dd51e9
Compare
|
I've rebased this but it needs testing. @danvel9 are you able to help with that? Basically, I'd like to see how it interacts with how auto takeoff mission item now supports a lat/lng point to head towards. This would basically become how to do it with a lat/lng of 0,0. Don't test yet until I take a look at this closer. |
|
I don´t fly very often now but I guess I could test that if I have clear
instructions.
Best regards.
…On Tue, 21 Feb 2023 at 00:37, Tom Pittenger ***@***.***> wrote:
I've rebased this but it needs testing. @danvel9
<https://github.com/danvel9> are you able to help with that? Basically,
I'd like to see how it interacts with how auto takeoff mission item now
supports a lat/lng point to head towards. This would basically become how
to do it with a lat/lng of 0,0. Don't test yet until I take a look at this
closer.
—
Reply to this email directly, view it on GitHub
<#14679 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABACKT6AIJAV4HRW2V5SNUDWYP54RANCNFSM4OHAU6ZA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@danvel9 Here's an apj for a CubeOrange. Let me know if you want a build for different HW I've rebased and re-tested on SITL. Works great. |
|
I'm flying a MatekF765-Wing on a Volantex Ranger 2400, but let me see if I understand how the program works:
- On takeoff, it will track to long/lat coordinates of tkoff WP if they are not 0/0.
- If they are 0/0 then it will project the current heading 10km away and will track that virtual WP until takeoffalt is reached, then it will fly to the next WP in the mission.
Is this correct?
If so, then I'm willing to test it this spring as the weather allows me to fly.
Thanks!
…On Sat, 25 Feb 2023 at 02:29, Tom Pittenger ***@***.***> wrote:
@danvel9 <https://github.com/danvel9> Here's an apj for a CubeOrange. Let
me know if you want a build for different HW
CubeOrange_Plane_takeoff_xtrack.zip
<https://github.com/ArduPilot/ardupilot/files/10829982/CubeOrange_Plane_takeoff_xtrack.zip>
I've rebased and re-tested on SITL. Works great.
—
Reply to this email directly, view it on GitHub
<#14679 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABACKT37PFZA6M5IHVZTAUTWZFOAHANCNFSM4OHAU6ZA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
This needs a check to only run if the mission waypoint is invalid, typically (0,0) |
|
I'd much rather have an option to use the lat/lon in the NAV_TAKEOFF waypoint along with the position when takeoff starts to define the course. When this option is not enabled then use the current strategy |
|
@tridge I did something along those lines for a fast plane with a longer than usual takeoff run as part of a few miscellaneous takeoff improvements priseborough@a6d2b2b |
|
@tridge I am pretty sure that this PR doesn't preclude doing it your way as well. Takeoff with 0/0 coordinates could do it Tom's way, with coordinates it could happen your way. |
|
@jschall @priseborough @tridge @peterbarker @danvel9 @WickedShell I've marked this for dev call so we can get some minds together on it. |
| gcs().send_text(MAV_SEVERITY_INFO, "Holding course %d at %.1fm/s (%.1f)", | ||
| (int)steer_state.hold_course_cd, | ||
| (double)gps.ground_speed(), | ||
| (double)degrees(steer_state.locked_course_err)); | ||
| } | ||
| } | ||
|
|
||
| if (steer_state.hold_course_cd != -1) { | ||
| if (!steer_state.locked_course && !prev_WP_loc.same_latlon_as(next_WP_loc)) { |
There was a problem hiding this comment.
should instead check auto_state.crosstrack
| float takeoff_course = wrap_PI(radians(gps.ground_course())) - steer_state.locked_course_err; | ||
| takeoff_course = wrap_PI(takeoff_course); | ||
| steer_state.hold_course_cd = wrap_360_cd(degrees(takeoff_course)*100); | ||
| const float ground_course_rad = wrap_PI(ahrs.groundspeed_vector().angle()); |
There was a problem hiding this comment.
should have parameters to choose between current scheme, next WP lat/lon and this scheme
On plane auto-takeoff, current implementation is a simple heading hold which gets pushed by the wind. This PR will generate a virtual waypoint 10km ahead and xtrack to it. All the usual low-altitude roll limits still apply. I'm not sure if this is something we should hard-code enabled, or use a param (TKOFF_OPTIONS?)
Test:
AUTO mode with 2 waypoints:
SITL params:
SIM_WIND_DIR=270
SIM_WIND_SPD=10
Above is existing heading-hold behavior
Above is new wp xtrack behavior