Differences

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

--- ios_smartdirt_rtk:ios_smartdirt_rtk [2019/05/03 20:10]
mikeclapp [New]
+++ ios_smartdirt_rtk:ios_smartdirt_rtk [2019/09/09 20:02] (current)
timm [Save Dialog]
@@ Line 1: / Line 1: @@
+====== 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 ======
@@ Line 51: / Line 88: @@
 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.
@@ Line 79: / Line 204: @@
+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.)

AGTEK R & D Wiki

User Tools

Site Tools

Differences

Page Tools