Differences

This shows you the differences between two versions of the page.

--- ios_smartdirt_rtk:ios_smartdirt_rtk [2019/04/13 00:43]
mikeclapp created
+++ ios_smartdirt_rtk:ios_smartdirt_rtk [2019/09/09 20:02] (current)
timm [Save Dialog]
@@ Line 1: / Line 1: @@
-SmartDirt RTK
+====== SmartDirt IOS 1.6 ======
+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:
+{{:ios_smartdirt_rtk:measurefauxpointsadd.png?400|}}
+====== SmartDirt IOS 1.7 ======
+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.
+==== Interface ====
+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 ======
+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.
+{{:ios_smartdirt_rtk:sdrtkmodescreen.png?400|}}
+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
+====== Use Scenarios ======
+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).
-Cut Paste from SmartDrone for editing
 ===== New =====
-  * Select New from File action bar. Begin 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.
+===== Alignment (localization) =====
+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.
+==== Current process ====
+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)
+{{:ios_smartdirt_rtk:alignment_shoot_or_recover.png?400|}}
+=== Choices ===
+  * 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?
+=== Shoot Benchmarks ===
+{{:ios_smartdirt_rtk:shoot_first_benchmark.png?400|}} {{:ios_smartdirt_rtk:shoot_bm_1-2.png?400|}}
+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
+{{:ios_smartdirt_rtk:shoot_bm2.png?400|}} {{:ios_smartdirt_rtk:picked_bm2.png?400|}}
+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.
+{{:ios_smartdirt_rtk:deviation_report.png?400|}}
+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.
+{{:ios_smartdirt_rtk:reshootmenu.png?400|}}
+Lather, rinse, repeat until you're satisfied and accept the deviation
+==== RTK Settings Screen ====
+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.
+==== Save Dialog  ====
+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|http://dev.agtek.com/dokuwiki/doku.php?id=windows:export:export_revamp_2018_desktop]]
+{{:ios_smartdirt_rtk:sdrtksavescreen.png?400|}}
+Note: This is an Android screen as we have nothing close to this in IOS.
+===== New in General =====
+  * 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 ====
+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.)
@@ Line 15: / Line 210: @@
   * 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"//Date//unique 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.
+{{:ios_smartdirt_rtk:sdrtkmodescreen.png?400|}}

AGTEK R & D Wiki

User Tools

Site Tools

Differences

Page Tools