Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add "WP-nearest" to nav_wp_mission_restart #7742

Closed
StuweFPV opened this issue Jan 11, 2022 · 3 comments
Closed

Add "WP-nearest" to nav_wp_mission_restart #7742

StuweFPV opened this issue Jan 11, 2022 · 3 comments

Comments

@StuweFPV
Copy link

StuweFPV commented Jan 11, 2022

Current Behavior

Restarting a WP-mission always requires you to fly the mission from WP#1. If it's a longer mission or larger area this is not always practical. As with multiple missions now available, mission flying should become a bit more flexible to use them to its fullest. The "resume" option also requires, that a mission was already flown up to the current point so this does not match this idea.

Desired Behavior

Being able to "join" a mission whilst flying somewhere along your path manually. When engaging mission mode, the FC should be able to start from the nearest WP instead from #1. Users that have multiple missions stored can make full use of their repository. Whilst flying, select a nearby mission from the list and activate that mission. Toggle into "WP-nearest" and start the mission from there. This would also allow users to switch from one mission to another whilst flying without having to return to WP#1.

Suggested Solution

Expand the command "nav_wp_mission_restart" with the option "WP-nearest". Being included as option when toggle mode is selected. Whereby "restart" would not be the absolute correct term as this is more a "start" of the mission. But I don't see any necessity why the naming should be changed.

Who does this impact? Who is this for?

Any pilots that fly WP missions. Allowing more flexibility to make even better use of that great feature. Allowing the use of missions whilst flying without having do decide at the start whether you go for a mission from WP#1 or fly manually all the way and back. Today it's either or and you have to decide at the start. This new function would bring more flexibility to WP pilots.

Additional context

This would require for "nav_wp_safe_distance" to be disabled in order to work.

@CertainBot
Copy link

This feature is preferred than #7720. Will make missions much more flexible. Nav_wp_safe_distance has not to be disabled. This is a safety patameter that ensures you are loading and starting a local mission rather than by error a mission 10.000 miles away and is not in conflict with the ability to start the mission from the nearest point.

@StuweFPV
Copy link
Author

I'm not sure about this as currently there is no way to test that. If you set your nav_wp_safe_distance to 300m and your nearest would be 500m do you think he would start? I agree with the safety mechanism of not being able to start a mission 20km away but I often start mine 1.2-1.5km away as my take-off direction is opposite from the first WP so i have it disabled anyway. I guess that depends on how they would write the code. This does not replace #7720 which is messing with RTH behavior. But is, as you stated, to give more flexibility to WP mission pilots. I hope they both can be implemented. In the end of the day it's your personal choice what function in inav you activate and use.

@CertainBot
Copy link

In the current state it would not start but we are talking about the future implementation. If the mission can start from the closest WP to the craft it doesn't matter where you place the first WP of the mission. Its just a safety measure so you know the mission is local and not some other mission loaded by mistake

@StuweFPV StuweFPV closed this as not planned Won't fix, can't repro, duplicate, stale Dec 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants