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

Nav: Home pos / alt should be set at arming, not powerup #443

Open
mlyle opened this issue Jan 14, 2016 · 8 comments
Open

Nav: Home pos / alt should be set at arming, not powerup #443

mlyle opened this issue Jan 14, 2016 · 8 comments

Comments

@mlyle
Copy link
Member

mlyle commented Jan 14, 2016

No description provided.

@mlyle mlyle added this to the post-renatus milestone Jan 14, 2016
@pug398
Copy link
Collaborator

pug398 commented Jan 14, 2016

This would definitely be a good thing.

@dustin
Copy link
Member

dustin commented Jan 15, 2016

Are these one thing?

@mlyle
Copy link
Member Author

mlyle commented Jan 15, 2016

Basically they should be, yes. Home pos is slightly harder than altitude but IMO we should solve both at once.

#65 is also closely related

@AlessioMorale
Copy link
Contributor

In LP we used a different set of coordinates, called TakeOffLocation. The rationale being that homelocation is used as origin point the local coordinate system used by wp etc, so it is advisable to not change it on the fly.
TakeoffLocation is handled here: https://github.com/librepilot/LibrePilot/blob/next/flight/modules/ManualControl/takeofflocationhandler.c
It supports preset (saved) takeofflocation, or acquired during first or each arming.

@mlyle
Copy link
Member Author

mlyle commented Jan 18, 2016

This is good feedback. Probably it should be configurable, because sometimes what's desired is nav relative to the takeoff position, and sometimes not.

@mlyle mlyle modified the milestones: Post-Tanto, Tanto Feb 25, 2016
@cpusmith
Copy link

I have the same issue as this and the same as "Baro initialization doesn't seem correct #65". Where it's most bothersome is in the OSD when you have to keep making sure that you observe the negative altitude number, which can range from -18 meters to -65 meters, and continually minus it in your head as you're flying and watching your altitude. Not that I don't mind the metal exercise but it would be better to pay attention to other readings. (-:

If someone wants to work on this I can test on a sparky1 and Sparky2.

@mlyle mlyle modified the milestones: Quixote, Samsara Jun 25, 2016
@mlyle mlyle modified the milestones: Post-Quixote, Quixote Sep 1, 2016
@mlyle mlyle modified the milestones: Artifice, Neat Jan 13, 2017
@mlyle mlyle modified the milestones: Neat, Post-Neat Jun 15, 2017
@tracernz tracernz removed this from the Wired milestone Jan 30, 2018
@tracernz tracernz added this to the Post-Wired milestone Jan 30, 2018
@mlyle mlyle modified the milestones: Inconceivable, Ludicrous Apr 18, 2018
@LitterBugs
Copy link

Been using GPS modes on my A450 with a Seppuku recently. I agree that Home position should be set to inital arm location rather than where 3D lock is first achieved. Maybe make a UAVO that allows to choose how Home is set.

@tracernz
Copy link
Member

tracernz commented Jun 7, 2018

We sort of have that, but just with only two options, either preset position, or GPS lock position.

<field defaultvalue="FALSE" elements="1" name="Set" type="enum" units="">
      <description>Use preset home location when enabled, otherwise use location where GPS lock occurs. BE CAREFUL with this.</description>
      <options>
        <option>FALSE</option>
        <option>TRUE</option>
      </options>
</field>

Could extend that to an ENUM with a 3rd option to use position at arm if we implement that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants