Thoughts on improving Waypoint Editor

[arthurbenemann]

Just splitting #293.

1. Clicking on a waypoint on the map or in the list should highlight the corresponding waypoint on the map or list
2. Show waypoint number inside or above pin (Fixed by Fixing Waypoint Editor and Survey Dialog #299)
3. In waypoint list, long press to move waypoint, short press to open param dialogue (Fixed by Fixing Waypoint Editor and Survey Dialog #299)
4. DO_JUMP is missing arguments--waypoint and duration (Fixed by @azrin1972 on v1.0.1)
5. After moving waypoints in list, redo the numbering so that it's 1...n (Fixed in Waypoint numbering issue on survey #321)
6. Make the waypoint editor be able to expand and contract too save space on the screen. (Fix in Fixing Waypoint Editor and Survey Dialog #299 by @azrin1972 )
7. Distance measurements while moving waypoints. (Fixed in Parameters: fix for name column size, progress indicator #328)
8. Total flight plan distance (Fixed by Fixing Waypoint Editor and Survey Dialog #299)
9. Total expected flight time (given distance and speed)
10. Increase column height of waypoint line items in left panel. Not very finger friendly on the nexus 7 v2. (Fixed by Fixing Waypoint Editor and Survey Dialog #299)
11. Don't draw line from home to first waypoint (home may be unknown if planning while disconnected) (Done in current master)
12. Reduce the range of the altitude slider on the waypoint dialog. Hard to select practical multirotor heights (10m - 120m). Maybe make max expected altitude an option.
13. add delay parameter to waypoint (in master, done by @azrin1972 )
14. add DO_CHANGE_SPEED nav command (in fact implement support and UI for all APM/ArduCopter supported nav commands) (Fixed by Fixing Waypoint Editor and Survey Dialog #299)
15. ROI waypoints should be excluded from the flight path (no lines to / from) (Fixed by Fixing Waypoint Editor and Survey Dialog #299)
16. Waypoint lables always displayed (same as 2)
17. Use different markers for different functions in the mission (instead of just colored markers). (Fixed in Parameters: fix for name column size, progress indicator #328)
18. Control to force an altitude change for all of the waypoints
19. Short click on map marker should open the correspondent waypoint dialog. (Fixed by Fixing Waypoint Editor and Survey Dialog #299)
20. Make altitude also editable via text by clicking in the texview on the right of the slider.

[arthurbenemann]

Added issue 6 from #296.

[bob01]

7 Distance measurements while moving waypoints.
8 Total flight plan distance
9 Total expected flight time (given distance and speed)
10 Increase column height of waypoint line items in left panel. Not very finger friendly on the nexus 7 v2.
11 Don't draw line from home to first waypoint (home may be unknown if planning while disconnected)
12 Reduce the range of the altitude slider on the waypoint dialog. Hard to select practical multirotor heights (10m - 120m). Maybe make max expected altitude an option.

That's all that comes to mind right now after trying it this weekend - nice piece of work! Thank you.

[arthurbenemann]

10 Could you post a screenshot?
11 Has been fixed on the current master branch. We just need a new release

@bob01
I'm moving your issues to the top of the post. Thanks for reporting

[arthurbenemann]

The problem with issue 9 is that how can DP know the speed of your drone?

Having it would be very useful, especially if we have other parameters like estimated flight time. Maybe we should create a user editable vehicle model?

[azrin1972]

12 - we could put under settings - max waypoint height, radius, delay etc. It will be reflected at the dialog boxes.

[J-DeMarco]

Can we bring back the old waypoint elevation dialog? We usually fly at like 5 to 15 meters and with the slide bar it is very difficult to select a value that low.

[arthurbenemann]

@J-DeMarco: The old elevation dialog takes too much space to be used in the new waypoint editor. What if we make the range of the altitude slider adjustable via settings?

[bob01]

Hi Author,

Re: 9 - mission time
IF the speed is set on (or prior to) the first waypoint then the time for each segment and the total mission time could be calculated. Agreed impossible if not.

[bob01]

Screenshot for 10

[arthurbenemann]

You want a smaller height so they are easier to touch&slide?

[bob01]

More...
14 add delay parameter to waypoint
15 add DO_CHANGE_SPEED nav command (in fact implement support and UI for all APM/ArduCopter supported nav commands ;) )
16 ROI waypoints should be excluded from the flight path (no lines to / from)
17 Waypoint lables always displayed

eg from PC MissionPlanner

[bob01]

Another example of waypoint lables and waypoint distance metrics (another GS product)

[arthurbenemann]

@bob01 That is very helpful. I'm curious which GCS is the one in the second picture?

[bob01]

2nd picture is the new DJI iPad ground station for naza/wookong etc.
Free for download in the app store.

[bob01]

"You want a smaller height so they are easier to touch&slide?"
No, taller to make selection easier. Mb 30% height increase?

[J-DeMarco]

@arthurbenemann Yes, if we had an adjustable range for that elevation slider that would be good.

[arthurbenemann]

I'm working on #299 to resolve this issues. If someone wants to help that's a good branch to start from (you will get the fixes I already have done).

[arthurbenemann]

Issues 10 and 2 are fixed in #299.

Now we just need someone to step forward to do a bitmap for each waypoint type, anyone want's this assignment (issue 17)?

[azrin1972]

Sure, I'll give it a look

Azrin Aris

On 20/09/2013, at 0:52, Arthur Benemann notifications@github.com wrote:

I'm working on #299 to resolve this issues. If someone wants to help that's a good branch to start from (you will get the fixes I already have done).

—
Reply to this email directly or view it on GitHub.

[arthurbenemann]

This branch is starting to look good!
This a screen shoot of the code at arthurbenemann@54f6133

[arthurbenemann]

Just an update from the commits @azrin1972 and I did for this branch.

The following are screenshots of the commit arthurbenemann@517967f .

[arthurbenemann]

Fixed the "ROI doesn't belong to the flight path problem".

[arthurbenemann]

Release 0.15.0 of DroidPlanner has all the features done until now merged. Let's keep up with the good work!

[bob01]

Looking good!

[wunderlins]

would it be possible to also make numeric input of altitude (next to the slider) possible. IMHO it is often easier to insert 100 instead of trying to fidle with a slider to get (at least) close to 100. I think this matters once a mission has more than just a hand full of waypoints.

[wunderlins]

Once of the very helpful features for longer missions (out of line of sight) is the "verify altitude" option of Mission planner. MP is using publicly available elevation information (i think from nasa) to check the waypoint's altitude agains a terrain model.

I think this is especially important if a drone is operated in not so well know terrain.

[arthurbenemann]

@wunderlins

Adding a numeric selector is possible, but I don't think we will have the need for it when we create the vehicle model file. With that we can make a more customized slider with your max/min/interval settings making it easy to select altitude. It's just that I don't want to complicate the interface if we can get away with something simpler.

The "verify altitude" things is being developed on #248, take a look there for more info.

[wunderlins]

Hi Arthur. I do agree if we are talking about multirotors. My drones have an altitude range from 50-2000 m AGL (fixed wing). Having a slider for that would be a bit painful. Since the alt is displayed already next to the slider this display could also be a text input.

[arthurbenemann]

@wunderlins Added as 21 in the list.

[azrin1972]

no 4 almost done - need help in getting the spinner work.
also - WP selection on the action bar is now working

[arthurbenemann]

@azrin1972 what do you need for the spinner?

I though the selection on action bar was working.

[bbasso]

Simon,
Having an altitude slider but with say 5m increments could also be a good
way to go, and then maybe a text box for manual/precise altitude control.
-Brandon

On Wed, Sep 25, 2013 at 11:43 PM, Simon Wunderlin
notifications@github.comwrote:

would it be possible to also make numeric input of altitude (next to the
slider) possible. IMHO it is often easier to insert 100 instead of trying
to fidle with a slider to get (at least) close to 100. I think this matters
once a mission has more than just a hand full of waypoints.

—
Reply to this email directly or view it on GitHubhttps://github.com/arthurbenemann/droidplanner/issues/294#issuecomment-25146686
.

Brandon Basso, PhD :: Senior Research and Development Engineer :: 3D
Robotics :: Berkeley, CA

[azrin1972]

Arthur, the action bar waypoint was not working. Since the code only pass 'null' during the construction of the WP list.

As fir my spinner, I manage to fill the spinner with the WPs. But I cannot do selection.

[wunderlins]

bbasso: having Nmeter increments and a textbox sounds like a good solution.

[possiblyphilip]

If you plan a takeoff and climb to altitude and then put in polygon points to create a survey route, it clears all of your previously input points. This forces you to create the survey route first and then add extra way points, move them to the top of the mission and then change them to takeoff, loiter or whatever so you have to create your mission out of order.

also if you click inner waypoints or footprint, it clears any waypoints you may have made outside of the survey route, making you re plan all those points.

None of the parameters for overlap, height ect seem to hold their previous settings, they revert back to the default every time.

[arthurbenemann]

About the issue of waypoints being cleared when you try to do a new survey
mission, that happens because I needed to do that to produce the dynamic
changes to the polygon dialogue. I understand your frustration, we just
need to implement these other way.

About holding the parameters of of the last survey, that's a great
observation and we need to fix that.
On Oct 25, 2013 9:40 PM, "ben howard" notifications@github.com wrote:

If you plan a takeoff and climb to altitude and then put in polygon points
to create a survey route, it clears all of your previously input points.
This forces you to create the survey route first and then add extra way
points, move them to the top of the mission and then change them to
takeoff, loiter or whatever so you have to create your mission out of
order.

also if you click inner waypoints or footprint, it clears any waypoints
you may have made outside of the survey route, making you re plan all those
points.

None of the parameters for overlap, height ect seem to hold their previous
settings, they revert back to the default every time.

—
Reply to this email directly or view it on GitHubhttps://github.com/arthurbenemann/droidplanner/issues/294#issuecomment-27133709
.

[possiblyphilip]

Yeah, I assumed that was what caused the previously entered waypoints to be cleared. If the survey mission knew which waypoints it had created automatically, it could change/ add / delete its own waypoints dynamically while leaving the others alone.

I havnt had a chance to pull all the source yet to see how you currently have it implemented but I would really like to help on this whole project.

[arthurbenemann]

I think I know how to implement it on the new ui, maybe handling the entire
poly goon as a single object.
For a quick guide on how to compile the code go to:
https://github.com/arthurbenemann/droidplanner/wiki/Build-Setup
On Oct 25, 2013 11:40 PM, "ben howard" notifications@github.com wrote:

Yeah, I assumed that was what caused the previously entered waypoints to
be cleared. If the survey mission knew which waypoints it had created
automatically, it could change/ add / delete its own waypoints dynamically
while leaving the others alone.

I havnt had a chance to pull all the source yet to see how you currently
have it implemented but I would really like to help on this whole project.

—
Reply to this email directly or view it on GitHubhttps://github.com/arthurbenemann/droidplanner/issues/294#issuecomment-27136732
.

[arthurbenemann]

A bunch of improvements have been done at the current master branch. Thanks for the help of everyone on this issue.