It's apparent that good RTK GPS support is going to take a while to be available. In the meantime there are several concepts that we made part of the RTK release that are not dependent on RTK and would valuable to standard SmartDirt. They are:

• New - the ability to create tracks, pictures and notes on a site without a background file has value. It requires some form of saving beyond the KMZ created (does it or do we just need a project?). Later when we integrate a mapping tile source this has particular extra value.
• Improved Measure controls - our current measure area inputs rely on both putting down enough points and operating on the last point entered when adding. The more modern polygon entry method is to put down handles between any two entered points that can be used to add points by pressing and dragging on them. Once dragged they become entered points and create their own mid segment handles. This makes for a more flexible entry method.

Mockup here:

The primary focus of this story is the addition of background satellite and street maps as a supplement to our currently generated data.

• Uses the Open Geospatial standard https://www.opengeospatial.org/standards/wms so we're not tied to a provider.
• The Hexagon content guys store various levels of tiles that likely correspond to our system. We may have to support another level ourselves for the detail but we'll evaluate.
• We may need to implement some sort of cache.
• Ideally this would work with any of the mobile apps.

Probably not on by default. At this time thinking of a menu item called Mapping. Perhaps a three way toggle between off, Satellite, and Streetmap.

SmartDirt RTK IOS is an extension of SmartDirt that allows use of RTK GPS to provide high resolution data capture and positioning. Besides being able to determine cut/fill at a specific location compared to the model it also is leveraged to provide information used in drone photogrammetry and data capture (Ground control points and registration areas).

The general idea is that for a standard SmartDirt user there is no real changes to the app except for swapping screen buttons (not in measure) to the opposite side from where they are now. When a key is selected that has the RTK/Smartdrone key on it the additional RTK option is available on the menu. When the RTK is actually turned on it changes screens (may actually be a different mode with switching not obvious to the user).

RTK adds several option requirements beyond SmartDirt. Some of them are:

• The ability to save the ADF format.
• Device driver/RTK output parsing from the higher resolution device. Typically you also need a form of settings screen but we won't call it that here so it can be within the program
• Precision alignment/localization beyond the normal lat/long on benchmarks we do in SmartDirt and SmartPlan. This will require a new dataflow of the Alignment process.
• The ability to do a New file instead of just reading one. I may want to also make this an expanded capability of normal SmartDirt as well
• The concept of showing the elevation of the RTK GPS compared to a surface for cut/fill as opposed to comparing the two loaded surfaces.

The screen below represents SmartDirt in RTK mode. There are also menu changes to be documented.

Things to note:

• Better spacing on coordinates on the top and use of commas in the numbers. Drone data is often in state planes which show in the millions typically. Commas make them way easier to read.
• Replacing the measure icon in this mode with a break line button. (image is wrong icon) When shooting in points that form lines for surveying you often need to break that line. Another option would be to replace the camera and note button and do it there

I can think of three common uses that extending SmartDirt to RTK creates beyond the normal Smartdirt uses. They are:

• New files - Created by captured data in the field and used to create ground control points (GCPs) and registration areas for drone work. A side effect is it could also be used to capture RTK topos although it isn't optimized for that. We may extend this regular Smartdirt for capture of photos, tracks, and notes.
• Using existing files and tie into the control before creating GCP's and registration areas
• Use and existing file to check grade (compare RTK shots to a surface).

Aligning (localizing) is the process of measuring with RTK relative to existing files in a non-lat/long based coordinate system. The idea is creating relative measurements to a job site using control (benchmarks).

My suggestion is to look at the existing Android code and document separately which is something that should probably be done anyway. I'd like it done for two reasons. One is to have an outside look at what we're doing and create documentation/learning. The other is to make sure we're doing what's expected.

Our alignment process is different than others in that we're doing what's called a two point resection instead of a least squares fit where they warp a site to fit multiple benchmarks around a job. Our concept is much simpler in that it assumes one point is correct to set location and elevation on the job site and the second point shot establishes rotation and also serves as a check on expected deltas between the two points and the actual measured. We present the deltas to the user for acknowledgement because a large delta implies inaccuracy on anything you do forward. FYI, despite all benchmarks supposed to be equal in quality, they often aren't with transposed numbers, the wrong one selected etc. This is apparent in our software and not so apparent in others and the result is we'll see sites aligned by other systems that do fitting to have tilt introduced by a bad benchmark.

This uses Android screens from the SmartGrade product but I don't imagine the process changing.

After initializing RTK with a opened ADF file we give the choice to Shoot Benchmarks (grayed unless GPS quality is fixed) or Recover (if recovery is saved in the file). (Should we even show it if it's not there)

• Shoot Benchmarks (starts alignment/localization) process
• Recover reads the saved alignment in the file.
• Settings (on menu) (takes us back to the GPS control screen)
• Creating benchmarks by picking points (left icon)
• Import Recover from another file (right icon)
• We're probably going to need a fourth that allows us to use RTK GPS in Smartdirt but not get into the RTK screen. (Do we want set elevation in there like a put me here for regular smartdirt screen?

Note that we default GPS position off when in this mode because you need to freely pan.

The job file displays and if it was georeferenced at any point we show the arrow in relation to the benchmark.

The user picks the first benchmark as prompted by the screen, walks to it, and sets the instrument over that point and presses shoot. A distance to the selected point also displays below and helps the user discern that he found the right point to setup over. It can be confusing in the field to find control and the visuals help.

When he presses shoot and we take 20 samples over the spot and do a RMS calculation of the values to determine the Northing , Easting, and Elevation of that spot. The RMS is used instead of average because on occasion some receivers will throw a point by quite a bit and mess up an average. We treat Benchmark 1 as an absolute position. Everything is referenced from its location in X,Y, and Z. It's assumed correct. The prompt changes to shoot Benchmark 2

The procedure for shooting Benchmark 2 is identical in the user walks to it, sets up over it and presses shoot to take the 20 shots. After shooting the deviation report shows and offers the user the option to reshoot the alignment or accept it.

The deviation numbers are a comparison between the expected horizontal and vertical difference between benchmarks 1 and 2 versus the actual captured numbers. Typically we expect below a .10 in both but that's a user decision. Note that the spec on RTK GPS is 1 cm horizontally and 2 cm vertically.

If we accept the deviation then we immediately go into the RTK screen. If we decide to reshoot then the program goes back to the second benchmark shoot screen. The common use case is that you have two points close together and picked the wrong one. If the deviation is roughly the same distance between points then you know you setup over the wrong point. This makes it so you don't have to go all the way back to benchmark 1 which might take a while.

Note: Finding control (benchmarks) on a job site can be difficult sometimes. It's often out of the way, not well marked and might even be wiped out. The apps ability to show you in relation to even the google earth quality points is really useful. You might spend half a day finding it on occasion. And that out of the way control typically at the extents of the job is not something you want to walk back and forth to find. Also know that we run into control set by surveyors that is wrong. We rely on benchmark 1 being right but sometimes you can't get a good deviation and that means you need to check or find different control. It also points out the issues when other techniques rely on all of the multiple control points to be correct and when one isn't they make it fit and warp the data. If a user isn't checking the report you get tilted sites and the tendency unfortunately is to not check reports.

The default is to reshoot benchmark 2 but the menu allows for reshooting Benchmark 1 instead.

Lather, rinse, repeat until you're satisfied and accept the deviation

The RTK Settings are subset of what we currently with Android because right now we can only use Zeno Connect. Much of the configuration takes place with Zeno Connect instead of in the App. Looking at the list I'm wondering if we need a similar screen at all. Most of the other settings are contained either within the phone settings or are setup in Zeno Connect. If we do end up having native drivers then it will more likely become necessary.

We'll need to have an explicit save but I'm not interested in necessarily saving all of the existing ADF data and then the added survey data. My general thought is that we maintain the existing object database of photos, notes and tracks along with the RTK information as new objects (RTK tracks and benchmarks). We keep uploading the KMZ file as we do now but when the user does an explicit save we actually create an ADF file with GCP as part of the name along with all the other RTK elements created including saved Benchmark recovery data and upload that to access.

Added to that is the ability to export GCPs of the chosen format and save/share/export them as a separate item not necessarily tied to Access. This format is a text file in CSV format that varies depending on the format. Typically once a user sets this value they're not going to change it so it should be remembered. For a list of the formats see here under Gory details of file types Exports http://dev.agtek.com/dokuwiki/doku.php?id=windows:export:export_revamp_2018_desktop

Note: This is an Android screen as we have nothing close to this in IOS.

• Select New on the File screen.
• Ask the user which project he wants to save to (or create new)
• Go to standard SmartDirt Screen (this is a new autonomous capability for SmartDirt (and SmartPlan)
• There's not much to see here, just the arrow at a default scale of 40 ft (default to M for other languages). The coordinate system should start at 5000,5000 and without RTK we don't use elevation. When RTK is on the base elevation is 100 based on the first couple of points (5?)
• in initializing instrument like we do in SmartGrade and go to the New/Grade screen. Our initial coordinate system has to be 5000, 5000, 100 just like it is in SmartGrade. In Story 2 I will want to do the State Plane Transformation on shooting of the second benchmark/GCP.
• Capture what you want either autonomous or RTK. The screen changes to reflect instrument choice (elevation, fix float) and also needs to reset extents as it captures since we have no idea of how big it's going to be.
• I do think we'll need a form of manual save but for now retaining that info within the file is sufficent. The Save may almost be an export as to not interfere with the automatic KMZ generation that goes on.

RTK New has more outputs than just the KMZ we're saving above. It need to capture Benchmarks as coordinates and the Lat/Long

Cut Paste from SmartDrone for editing

• Create Benchmarks/GCPs for at least two points. LL is put on points. Move create benchmarks up in order to toolbar (over 3D) (First version is an arbitrary system for prototype. We really want this to transform to State Planes after the second benchmark is set.)
• Add a Set Elevation to the menu. Set Elevation will change all collected data in the file based on the offset calculated. This should use the Benchmark shot collection routine to give the best possible GPS elevation result
• The user can either use the Shoot button or streaming points button to collect other survey data when fixed (as in SmartGrade). For the shoot button point collection I'd like to actually use three point samples to calculate the point captured as I'm seeing enough variation in elevation for single shots compared to benchmarks to want a little more rigour in our point capture. With a shoot button shot I've likely bubbled up the rod and at 5-10hz taking a couple more points collected should not affect speed much if at all.
• Save on a new should use the lead text of “GCP”Dateunique number similar to what we do now using “Survey” but to distinguish the purpose of the data. It also uploads to Access. We do not need to include AGT in this situation because unless we extend the format multiple places we cannot capture the important values of lat-long which is one of the primary requirements.

Since we're getting rid of progress topo we're also removing the ability to save and close this file and then reopen it in a “New” state as we do in SmartGrade. This is ok for the use case here and if in this situation the user needs to select the saved file and go through the alignment process.

• Select the ADF file through the file screen or choose from access
• Initialize the instrument and and go to the Shoot Benchmarks or Recover screen.
• Shoot benchmarks just like we do in SmartGrade and display the deviation. Allow them to reshoot as necessary, etc. identical to what we currently do in SmartGrade.
• There is only one mode for this (no stake) so get rid of the screen that asks which mode and just go to what acts like Grade mode for this program

• Create Benchmarks/GCPs for at least two points and as needed. LL is always put on Benchmarks/GCP points regardless of whether they already had values (this is different but critical). Move create benchmarks up in order to toolbar (over 3D)

• The user can either use the Shoot button or streaming points button to collect other survey data when fixed (as in SmartGrade). For the shoot button point collection I'd like to actually use three point samples to calculate the point captured as I'm seeing enough variation in elevation for single shots compared to benchmarks to want a little more rigour in our point capture. With a shoot button shot I've likely bubbled up the rod and at 5-10hz taking a couple more points collected should not affect speed much if at all.
• Save should save to the selected file but should also save a separate file using the lead text of “GCP”Dateunique number similar to what we do now using “Survey” but to distinguish the purpose of the data. Tis file contains just the added data, not the job data as part of the base ADF. It also uploads to Access. We do not need to include AGT in this situation because unless we extend the format multiple places we cannot capture the important values of lat-long which is one of the primary requirements.

Set Elevation is different than we've previously done with monuments and correcting for elevation differences measured versus shot. The screen that shows when Set Elevation is picked is shown below:

I derived it from the Monument setting page but it has several important differences and applications. Besides being moved up in the hierarchy to a menu setting it affects the survey data past and future whereas Monument only affects future survey data.

The use case is this. When laying out GCP points for drones you often don't have a known elevation yet. You put a pin/stake in the ground and spray paint marks then shoot a GCP/BM on top of it. You do this several places and then fly the drone which only captures those points in images. As soon as you find a known elevation you want to be able to shoot it relative to the other points and then move the old points and any points shot in the future to match. I'd find grade stakes and use one to adjust and then check it against others. If I ended up find conflicting grades I'd likely want to repeat the process.

This also goes for any areas I surveyed to create registration areas for adjusting the point cloud models later.

• Space and make the Northing, Easting display at the top wider and use commas in the strings. We operate in State Planes a lot for this and that means big numbers.
• We don't have labeling other than Benchmarks and GCP creation and can't pick in this mode (should we?) so I think we can lose the line label for sure.
• We don't need to show the mode we're in since there's only grade so we can eliminate that text in the upper right.
• When using the Shoot button (not the track/streaming) button to create a survey point I'd like to take 3-5 actual shots and derive the elevation in a similar way to what we do benchmarks albeit fewer shots so it's a little faster. When shooting benchmarks and just a single shot there often can be more elevation variation than you'd think. Since the shooting aspect of this is to create registration areas that we'll use to correct point cloud models for elevation, I think it's worth sampling a little more when doing so.