User model for surveying

[LorenzMeier]

We should revisit and understand the user model for surveying - how users want to configure the survey and what API we should expose.

I'm less interested in what is there on the tech side, but rather what the one dominant mode of operation is people are using.

Some initial questions:

• Do people want to set camera distances in meters and let the vehicle trigger?
• Or do people want to plan each camera pose and use something like this? http://mavlink.org/messages/common#MAV_CMD_DO_DIGICAM_CONTROL
• Are camera parameter configurations really used, or does it all boil down to pure trigger control?

[WickedShell]

Answering from my perspective where we both do commercial mapping services and sell systems for mapping:

When mapping I usually prefer to exclusively trigger the camera by distance, I don't care if the distance is managed by the vehicle or the camera, if the camera can manage the distance thats fine, but the vehicle is the fallback that is expected to work and be available at all times, and in someways this is easier as we can treat all our camera payloads the same when handling the data after the flight.

I can see the value of planning the pose for some applications but for fixed wing mapping of large areas it isn't applicable as there isn't enough storage space for all the triggers (at least on APM:Plnae), and the radio support that is available at this point makes planning more impractical as well. For the record we routinely plan missions that have 5000+ photos in them and fly to 3 hours.

Triggering is the most essential aspect. Almost everything else can be worked around, but as we look at and move to cameras where we can review the photo after having taken it we are looking to see what we can do to programmatically evaluate and change settings on the fly. (Particularly to handle changing light conditions based on a light sensor). So at the moment I'd say its all the trigger control, but the path forward to needing more control is visible.

[amuehlf2]

Answering from the perspective of a commercial UAV camera manufacturer:

Sentera cameras only use the MAV_CMD_DO_DIGICAM_CONTROL message (from the autopilot), and they only use it for triggering. A step further, they assume every MAV_CMD_DO_DIGICAM_CONTROL message is a trigger message, regardless of its parameters. This choice was made to make Sentera cameras compatible with the default commands generated by Mission Planner when creating a Survey Grid, which does not set parameter 5 to 1. (http://ardupilot.com/forum/viewtopic.php?f=12&t=13635&p=38652&hilit=DO_DIGICAM_CONTROL#p38652).

We do have a zoom camera, which might use the zoom parameters, but haven't integrated it with a MAVlink autopilot yet, and aren't aware of a GCS that provides a GUI interface for intelligently managing zoom.

Similar to WickedShell's answer, many of our customers fly large fields, up to 640 acres, taking hundreds, and sometimes thousands of images in a single flight. The camera doesn't know the difference between a MAV_CMD_DO_DIGICAM_CONTROL message generated by a DO_DIGICAM_CONTROL waypoint command loaded from the GCS, or created by the autopilot as a result of a DO_TRIGG_DISTANCE waypoint command. However, large fields require the DO_TRIGG_DISTANCE approach to prevent the number of waypoints from exceeding limits.

To answer the initial questions in summary:

The ability to set distances is valuable as long as the maximum number of waypoints is less than many thousands. I can see a use for individual images as well, but it's less important to us.

We don't use camera parameters with MAVlink. It boils down to pure trigger control.

My primary request for MAVlink camera control is the ability to send a session name to the camera. It could be a command sent just after takeoff to open a new directory where images are stored. This would simplify organization of photos for our users. I'm not familiar with any MAVlink commands that send ASCII strings, so I'm not sure if this fits with the MAVlink architecture.

[LorenzMeier]

Thank you both for your feedback. That is indeed very helpful.

[WickedShell]

I should also mention that while I consider triggering by distance the essential requirement, I am fine with having the autopilot generate and emit MAV_CMD_DO_DIGICAM_CONTROL messages on the fly.

With regards to the seesion name, Thats a very good point. I don't think we really need a string, but if we could at least assign a unique ID to it that would be extremely helpful. (IE I could track the session name from the ground station side).

One of the biggest features/options that I consider essential with MAVLink cameras is the ability to get a confirmation message to the ground of where the camera took a picture/when, as well as monitor the status of the camera.

[jmachuca77]

Since you are asking about surveying, I will answer with what we do for that, however, there are a lot of other uses that need different camera controls and trigger modes.

For surveying I tend to use the distance trigger, its the most convenient way to trigger the camera since triggering with specific waypoints is not scalable. Either way (distance or specific waypoint) what we are trying to accomplish is to use the MAV_CMD_DO_DIGICAM_CONTROL message for triggering the cameras, weather its a distance option (autopilot should generate and send this message to trigger the MAVLink aware cameras) or a waypoint (autopilot should forward these mission commands to the cameras). Currently this is the way APM is working.

Currently we don't use the camera parameters for surveys, you tend to set the camera parameters at the start of the flight and they stay that way through out. However as we start getting better capabilities on companion computers and image processing, its important to allow the parameters on cameras to be changed, so I expect these will start to be used more and more in the future.

For other uses like artistic aerial photography changing camera parameters while in flight is much more important.

[dagar]

I had a good email exchange with a QGC Android user coming from Mission Planner looking for survey support.

His feedback -

Mission planner is feature rich user interface poor. Mission planner gives all the survey data needed when planning a mission. One big issue is after the survey flight is accepted I can't easily press a button to bring up the survey specs from the planned mission.

I like the user interface of q ground control. It has a lot of potential

[DonLakeFlyer]

Yup. I've been studying survey ui'a and already have a nice pretty good idea of what I want to do. On the plane ride across the country I implemented the concept of a "complex" mission item that has its own visualization.

On Feb 6, 2016, at 1:03 PM, Daniel Agar notifications@github.com wrote:

I had a good email exchange with a QGC Android user coming from Mission Planner looking for survey support.

His feedback -

Mission planner is feature rich user interface poor. Mission planner gives all the survey data needed when planning a mission. One big issue is after the survey flight is accepted I can't easily press a button to bring up the survey specs from the planned mission.

I like the user interface of q ground control. It has a lot of potential

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

[jmachuca77]

Hello Don, Are you still trying to implement this? is there a test version out? I have a lot of experience with survey missions and planning, and I think I have some suggestions as to what would be needed to make mission planning easier. If there is a preliminary version I could give it a test and give you some feedback.

Jaime

On Feb 6, 2016, at 1:13 PM, Don Gagne <notifications@github.com mailto:notifications@github.com> wrote:

Yup. I've been studying survey ui'a and already have a nice pretty good idea of what I want to do. On the plane ride across the country I implemented the concept of a "complex" mission item that has its own visualization.

On Feb 6, 2016, at 1:03 PM, Daniel Agar <notifications@github.com mailto:notifications@github.com> wrote:

I had a good email exchange with a QGC Android user coming from Mission Planner looking for survey support.

His feedback -

Mission planner is feature rich user interface poor. Mission planner gives all the survey data needed when planning a mission. One big issue is after the survey flight is accepted I can't easily press a button to bring up the survey specs from the planned mission.

I like the user interface of q ground control. It has a lot of potential

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

— Reply to this email directly or view it on GitHub https://github.com/mavlink/qgroundcontrol/issues/2507#issuecomment-180839988.

[DonLakeFlyer]

Yes, this is coming up in our 3.1 release. I've already started the backend work. I will likely get deeper into it by next week. I'll ping you for discussion. Thanks a ton for reaching out. My goal is to create the best, most usable survey support in a ground station you've ever seen.

[lvale]

So, one feature that I would like to see is seamless interaction with non-pro map solutions like Google Earth, i.e. define paths on Google Earth and have QGC be able to "convert"/read those on the background directly and vice versa, i.e. sending Missions to Google Earth

[lvale]

other: define area and QGC create a path optimized.

easy creation of unlisted cameras with user accessible parameters

ArcGis support.

Support to define ground markers mandatory to be used during surveys. These are known physical position targets and ensure that surveys can be easily corrected,

[Jack-2025]

I've had the need for a QGC surveying functionally for a long time, so I want to join the efforts in flight testing it out and anything else in between.

@DonLakeFlyer , how long do you estimate it'll take to have an alpha version of the surveying functionality?

[DonLakeFlyer]

Maybe a couple weeks to Alpha

[DonLakeFlyer]

Include option to generate altitudes in either Relative or AMSL.

[Jack-2025]

@DonLakeFlyer I'd like to test the surveying interface and give some feedback, but I can't find the grid pattern functionality from the "Select Mission Command" pane. Under which Category is it?

[LorenzMeier]

You need to enable it in settings IIRC.

[DonLakeFlyer]

What Lorenz said. But also Survey isn't quite ready for feedback yet. It has lots of work left to do on it. Although what is there should work. But it will likely change both from a user model and functionally as I continue to work on it.

On Mar 15, 2016, at 3:39 AM, Lorenz Meier notifications@github.com wrote:

You need to enable it in settings IIRC.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/mavlink/qgroundcontrol/issues/2507#issuecomment-196760612

[NaterGator]

@DonLakeFlyer I have some experience with this and figured I'd share my thoughts on what people seem to care about and what works best...

• For both types of aircraft the most logical initial survey pattern is boustrophedonic (ox-plow)
• For fixed wing it is often helpful to have a configurable lead-in/out parameter based on the environmental conditions and spacing of the adjacent flight lines. Nimble craft will not need a significant lead-in or lead-out to ensure they are on track inside the relevant polygon, but a cumbersome airframe may need ample runway to get itself lined up.
• It helps to try and give the user an estimate of how many photos will be sampled for a given polygon + interval configuration (ex: 1024 images given 4 second or 10 meter trigger distance).
• It is helpful to generate an estimate of the total time/distance the craft will fly to cover a survey area, especially if the user is likely to exceed their expected battery capacity
• It is helpful to be able to task a craft to refly a specific leg (or legs) of a survey mission that it may have insufficient coverage on
• It is helpful to be able to pause or abort a survey mission and then resume it where the craft left off (either later in the same flight or in a subsequent flight).
• When the autopilot has closed-loop control of a camera a live heatmap of overlapping photo coverage is an excellent resource for gauging initial survey quality

[Jack-2025]

I see, though even if it's not close to it's final form, I'd like to keep track of the changes and try them out.

When I tried activating the current surveying functionality by pressing Preferences >> General the app crashed. I suppose that's working for you guys?

[DonLakeFlyer]

@NaterGator Thanks a ton Nate. Very helpful.

@Jack-2025 I haven't run survey in a while since I've been focused on fixing 3.0 release problems. It may be broken. I'll take a look when I get home next week.

[jcooper21]

I agree with@jmachuca77 and I think everyone here is very focused on how mission planner works but I think for DJI copter Map Pilot for IOS by maps made easy have done the best job building survey apps, so lots can be learned from that layout as well. They have done an excellent job at capturing all critical information around surveying with distance based triggering.

I would like to add that as was previously said camera settings are usually set before flight and most of the time in an auto mode. The auto modes cause a trigger delay so camera feedback is required,

[DonLakeFlyer]

DJI copter Map Pilot for IOS

If I install that can I do anything with it if I don't have a vehicle?

[jcooper21]

You can see all the setting and how the broke it down as a good starting point. I will upload some screenshots of user interface. Standby.

[dagar]

There are several good video walk throughs online. lmgtfy

On Wed, Jun 29, 2016 at 1:47 PM, jcooper21 notifications@github.com wrote:

You can see all the setting and how the broke it down as a good starting point. I will upload some screenshots of user interface. Standby.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/mavlink/qgroundcontrol/issues/2507#issuecomment-229433920, or mute the thread https://github.com/notifications/unsubscribe/AAFK6FY_rpfcQ_vKeXXDp3rt9pCy4hWhks5qQq_PgaJpZM4G9iKz .

[DonLakeFlyer]

I'm installing it. So no need for screens shots. I'll play around with it.

[jcooper21]

Here's the screenshot. You won't see the full mission plan since you do not have a craft so here is the planned mission screenshot.

[WickedShell]

I watched a video, other then touchscreen friendly controls what seems better about it to you? Everything else looked the same really to me, no new features either way (and maybe avoided one of the starting WP placement bugs that MP has).

On Wed, Jun 29, 2016 at 10:57 AM, jcooper21 notifications@github.com wrote:

Here's the screenshot. You won't see the full mission plan since you do not have a craft so here is the planned mission screenshot. [image: image] https://cloud.githubusercontent.com/assets/14355782/16462896/a5215f78-3df0-11e6-85d5-86d6d9d17be7.png

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/mavlink/qgroundcontrol/issues/2507#issuecomment-229436765, or mute the thread https://github.com/notifications/unsubscribe/AAipiIprtL56hcEioDqbAJSnVcIb-Bx6ks5qQrImgaJpZM4G9iKz .

[jcooper21]

@wickedShell mission planner is fully featured but for this I am referring easy of use and simplifying for 90 percent of people yet still being powerful. That's the attraction here. I'm not trying to compare ground stations, I am just offering another perspective from another good platform.

[WickedShell]

Thats all totally valid, I just wanted to be clear about what parts you were holding up as being better. (and make sure I wasn't missing something cool/significant) I have no arguments with them :)

On Wed, Jun 29, 2016 at 11:11 AM, jcooper21 notifications@github.com wrote:

@wickedShell https://github.com/wickedShell mission planner is fully featured but for this I am referring easy of use and simplifying for 90 percent of people yet still being powerful. That's the attraction here. I'm not trying to compare ground stations, I am just offering another perspective from another good platform.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mavlink/qgroundcontrol/issues/2507#issuecomment-229440692, or mute the thread https://github.com/notifications/unsubscribe/AAipiKPM3UtXwIRS6DznmItfQ6uzt7wJks5qQrU1gaJpZM4G9iKz .

[dagar]

The display of area, distance, duration and the slider that presumably directly adjusts altitude/GSD is nice. Other than that it just looks nice and simple/straightforward.

[dagar]

I also like that it only shows that grid it's flying and not the 250 resulting waypoints like Mission Planner.

[AndKe]

Hi, I have long experience in mapping missions, often in narrow valleys, and over very varying altitude. The planes in use, are very aggressively tuned (high roll angle) to turn efficiently in terms of space. Here are a few tips for better planning, that I would love to see a tool use:

Please notice the small(normal) acceptance radius in WP1,2,3 - observe the way plane turns, then flies towards WP3, then turn again.

Now see that when it reaches WP4, WP5's acceptance radius is big (actually touch WP4 - resulting in a smooth single turn between and WP5) - resulting in better turn, and nice aligning with next path. The trick is, basically, that the acceptance radius of WP5,7 should be so big, it actually touches WP4,6 - This way the nav controller will align ASAP, not turn-level-turn.

Also, please allow to "inspect" the survey - see each WP , and set/modify each WP individually.

[dagar]

Thanks @AndKe. The need for playing with waypoint acceptance like this makes me wonder if more of the path planning should be handled on the autopilot. Or at least an easier way to ensure you get the right trajectory and tight acceptance through a waypoint.

[AndKe]

@dagar Yes, I toyed with the thought years ago, but never implemented, (at it's most basic it was: "if next WP, in the moment it's loaded is <80m away, then it's accepted") But as I never want a destination to not be completely reached due to such logic, for example in L and U formed valley. So while it's easy to fix on the GCS for the auto-generated flights, it's a risk that the logic may fail on manually drawn flights with tight tolerances.

[DonLakeFlyer]

Survey Phase 1 (Flight Path) discussion is happening here: https://github.com/mavlink/qgroundcontrol/issues/3797