Updating DroidPlanner (v0.14.2). This one will be nice for everyone doing survey/mapping missions.
The update
The new version has the following updates ( v0.14.2 over v0.12.3):
Droidplanner v0.14.2
- Fixing the problem of working with big polygons
Droidplanner v0.14.1
- Fixing a small bug in the Survey Dialog
Droidplanner v0.14.0
- Drag-and-Drop waypoint editing
- Slide to remove waypoit
- Click to edit waypoint
- Adding a lot more info to the Survey Dialog
Droidplanner v0.13.1
- Fixing layout problem in Survey Dialog in smaller screens
Droidplanner v0.13.0
- Survey dialog in mission planning
Now let me go to the two big improvements individually.
Survey Dialog
As I stated on the start this is a nice feature for everyone working with surveys. I would like to thanks Brandon for helping with the development of this feature.
There is a new dialog in the polygon mode into the planning screen. It was designed to help users generate survey missions, by calculating survey parameters using camera specs.
You can add your own camera by creating an XML file with it's specifications. If there is feedback I can do a wiki about it on GitHub, but for now here is some info.
Waypoint Editor
The best way to understand this is just giving it a test run. Here are the main points:
- Drag-and-Drop waypoint editing (to re-sort your mission)
- Slide to remove waypoint
- Click to edit waypoint
More info
For more information I suggest the DroidPlanner Wiki page. And if you just want to know how to connect your APM board, or what android device you can use just follow the links.
And as always if you want to help consider making a donation via paypal, or by buying this app (via the app google takes a 30% cut).
If you want to help even more, consider joining the development team, or reporting a issue/bug/improvement on GitHub.
Comments
Ahh, I figured it out! use this template and fill in your specifications:
<?xml version="1.0" encoding="utf-8"?>
<cameraInfo>
<Name>Canon EOS M</Name>
<SensorWidth>22.3</SensorWidth>
<SensorHeight>14.9</SensorHeight>
<SensorResolution>18</SensorResolution>
<FocalLength>22</FocalLength>
</cameraInfo>
Then save as an XML file and save under "/DroidPlanner/CameraInfo/"
I also would like to add a custom camera but cannot find a template anywhere!
@Thorsten
We can implement almost anything if we have the time :). We just have to see if it is worth.
Please add those comments on the GitHub issue, it's easier for us if we concentrate program issues/discussions in the appropriate topics there.
Brandon, I came across your post on GitHub (https://github.com/arthurbenemann/droidplanner/issues/293). Maybe locking the altitude slider in the survey window at 10m increments might be problematic for low res cameras/sensors (e.g. FLIR) where an altitude of 5m might be reasonable. For sure in the range of 20m+ a 5m increment is most probably not required. Can you implement irregular increments? I.e.: from 1..10m in 1 or 2 m steps then 15, 20, 30, ...
Brandon, for sure they should be switched off as default. I am looking forward to see this tool evolving as all these options would really simplify mission planning in the field - and make it more secure in several aspects. Thanks for your work on this!
@Brandon: this sounds good! I am a friend of KISS but safety first.
@Thorsten A radio button was what I was thinking of doing to select between different objectives--velocity versus camera interval. The hard part with a tablet interface though is limiting the set of options to the absolute minimum. Each additional button or know can be a point of confusion, even though probably most of us here want to fiddle with as many parameters as possible. I think the long term solution is to have a beginner and advanced interface. Check out Mission Planner > Flight Planner >Rt. Click > Survey. It would be hard to do that on a tablet, but that's the general idea i'm getting at.
@Simon, I've been thinking about having a user selectable option to make the first and last waypoints takeoff and land, respectively. I agree that RTL by default could lead to problems though. Features like these should have to be explicitly asked for by the user.
Simon, ok. For sure it should be implemented as an option. So you can disable it in such situations.
But in general for a mapping survey (orthophoto, DEM generation) it should fly at one height all the time - above the highest elevation in the survey area. So at least for copters an RTL at the end would be a welcome option.
Just as a note: automagic RTL at the end might not be the best option in hilly areas. there might be a mountain in between home location and your last WP. I think this is also the reason arduplane doesn't automatically RTL when it runs out of WPs
Cheers
-S