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

Example Fly mission uses hard-coding of mission points #121

Open
shakthi-prashanth-m opened this issue Oct 19, 2017 · 7 comments
Open

Example Fly mission uses hard-coding of mission points #121

shakthi-prashanth-m opened this issue Oct 19, 2017 · 7 comments

Comments

@shakthi-prashanth-m
Copy link
Contributor

shakthi-prashanth-m commented Oct 19, 2017

Fly mission example uses hard-coding of waypoints. It is hard for someone to compute longitude, latitude, etc and use this example.
I prefer, we can make this example take QGC Mission plan as input; where one can plan missions using QGC and feed its path via command-line to this example.

image

We can parse QGC mission plan and pass mission items to DroneCore Mission plugin.
Make sense ?

Regards,
Shakthi

@julianoes
Copy link
Collaborator

Thanks for the issue. This has been requested several times actually and it would be a good thing to have.

The only catch is that not all mission items are currently supported in DroneCore, so we won't be fully compatible. We would have to just ignore unsupported items and warn the user about it.

@hamishwillee
Copy link
Collaborator

@julianoes @shakthi-prashanth-m

Fly mission example uses hard-coding of waypoints. It is hard for someone to compute longitude, latitude, etc and use this example.

The solution to this problem is NED based mission points - as per #100.
I really think it makes sense to implement this ourselves, sooner rather than later.

The only catch is that not all mission items are currently supported in DroneCore, so we won't be fully compatible. We would have to just ignore unsupported items and warn the user about it.

My take on this is that mission import should completely bypass whatever we do with the API. It would be something to add flexibility over the top of our existing API. So perhaps:

  • Allow upload and download of files or strings in generic waypoint format. Users can then dynamically construct the messages if they want.
  • Provide an API to send a generic waypoint message or custom message - so the user can send whatever message they like.

Yes I know it removes some of the "clean-ness" of the API, but if we don't do this then I personally as a user would be forced to write my own plugin to do this.

@shakthi-prashanth-m
Copy link
Contributor Author

#235

@hamishwillee
Copy link
Collaborator

@shakthi-prashanth-m So what does #121 (comment) add to this discussion?

I still think we should implement #100

@shakthi-prashanth-m
Copy link
Contributor Author

@shakthi-prashanth-m So what does #121 (comment) add to this discussion?

@hamishwillee, sorry which comment ? The link you referred says that you opened this on Oct 20, 2017! :-)

I still think we should implement #100

Yeah, I think this is useful too. So I added my question regarding NED mission for my understanding.

@hamishwillee
Copy link
Collaborator

@shakthi-prashanth-m I was asking about why you added #235 to this discussion. I've responded re NED missions.

@shakthi-prashanth-m
Copy link
Contributor Author

Yeah, because this issue was about complexity of user's effort in uploading mission with hard-coding waypoint alt, lon. As #235 deals this indirectly, I referenced it.

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

3 participants