Reach RS+

Reach Module / RS+ / RS2+ / RX Getting started
13

My application doesn’t require UAV or GCPs, but was just wondering, does STOP-AND-GO pertain to UAV work and post processing or soemthing? What does this specifically mean even though it sounds self-explanatory?

Obviously I am stopping and going when collecting and staking points using Emlid Reach RS Rover (with a stationary or static Base also via LoRa) via RTK with no problem, so just wondering what I am missing here.

Thanks!

14

timd1971: The following discussion refers only to applications for post processing rover data against a base station. One would go the post processing route if the environment to be surveyed has too many obstructions for RTK to work consistently. Obstructions would be buildings, trees, gullies, etc.

The primary use of a Stop-and-Go survey (post processing) is when you have a project that requires the collection of a lot points. From my experience to collect a point, with a reach unit, that will have a fixed solution requires a 10 min static collect. Well, if you have 30 points to collect, that is 5 hours total needed for data collection, not taking into account the time moving between points. Each collected point is essentially it’s own survey project. If instead you are able to do 30 secs on each point in a Stop-and-Go survey, that is only a total of 15 mins of time. A big difference. And accuracy is essentially the same. However, Stop-and-Go surveys are more complicated to implement at the software end of things. A Stop-and-Go survey is essentially one long dynamic survey (PPK) in which time marks for the start and stop of each point are embedded in the file. The key for this type of survey is that “lock” is maintained for the entire survey. Stop-and-Go surveys will throw up a warning if lock has been lost at any point during a survey. In that case the unit would be reinitialized before continuing the survey. Loss of lock might occur, for example, if you were surveying in an open field, but then had to walk thru a forest to get to the next field. Chances are you would lose lock in the forest. In this case you would reinitialize once you were in the open again and then continue your survey. If you were using RTK you probably would not get a fixed solution because now you have a row of trees between you and your base. With Stop-and-Go you only need a good view of the sky. Stop-and-Go surveys can get frustrating if one looses lock often.

As others have pointed out you can just do a dynamic survey using the Reach units and do a poor mans Stop-and-Go survey by recording the start time of each point. The real issue with this approach is that it is a hassle to put together back in the office and more importantly you will never know if you suddenly lost lock during the survey. You will find out back in the office when you only get a float solution for some or all of you points.

Google Stop-and-go surveys and watch some youtube videos to get a better idea about these type of surveys.

The other reason to do a Stop-and-Go survey is that it does not require any radios, so two more affordable Reach M+ units could be used to conduct a very accurate survey.

I absolutely love the RTK capability for the Reach RTK units. When in environments where they work, they are awesome. But having the ability to do a PPK Stop-and-Go survey when the environment is not conducive to RTK would be really nice. Then you’d never be trapped for results.

4 Likes
15

Thanks for the great education on that!

16

thanks

17

Really a wonderful illustration of the actual problem…Kudos to you…

Thanks

18

No…

19

The information is really awesome…

Thanks

20

Basically all that meant is that it takes the Reach RS receivers too long to obtain a fix. I use professional grade survey gear and you should still collect for at least 10 seconds if you want real repeatable accuracy. Base network control points are shot in for 60 seconds. The Reach results are good enough for GCP’s, but only as long as you can maintain a fix and it will take about twice as long. If your environment doesn’t allow for a constant fix then forget it, which is what I have experienced. It’s all about the ability to quickly get a fix and maintain it. L1 vs L1/L2.

…and if you have a fix 10 minutes is not needed.

1 Like
21

And with I assume you are only talking about RTK and not PPK?

22

Correct. PPK is not even an option for my workflow.

1 Like
23

While a stop-and-go survey mode would be really nice to have, I think @EarthImage overlooked that it is partially possible with the point collection feature we have now. Sure, it is not a streamlined workflow, but it can be done like so:

  1. Start raw logs on base and rover.
  2. Optionally set up for RTK (just for supplemental information).
  3. Start with your rover on a point in a clear area and stay on that point until you should have a fix (a few minutes). OR if you did set up for RTK, then you can confirm fix status on the screen.
  4. Start a survey project and collect your point for 1 minute (or whatever occupation time you prefer).
  5. Move to each other point and perform a point collection for each point. We assume that our ‘PPK fix’ will be held through the whole survey, so keep the rover unobstructed and pointing at the sky as much as possible, especially when moving between points.
  6. When finished your point collections, post-process your raw logs into one big .POS (position) file.
  7. Download the survey project and open it for editing. Keep the start and stop times and wipe out the position for each point. (The single-mode or RTK position will be replaced by a PPK position.)
  8. Use RTKPLOT to display the .POS file. From the menu, limit your view between the start and stop time for the first point. Enable statistics and read the average position as reported on the RTKPLOT screen in the upper right corner.
  9. Repeat for all the other points.

Now, one could employ some automation with his spreadsheet software to make it easier or write a little script to do the whole thing automatically.

I’m not trying to convince @EarthImage that this is what he or @raj.gis should do. I just wanted to point out that it is a better way than doing a separate survey for each point. It does take a little extra time in the post processing, but when you are in the field it is just as fast as the stop-and-go mode that he is asking for.

edit: I missed the fact that @Earthimage covered this scenario already in the 3rd paragraph of his previous post. Pardon me for rehashing it, but I’m not going to delete my explanation now on the off-chance it might be of help to someone else.

3 Likes
24

I am new to these units and PPK so I don’t understand how shooting points traditionally is different than “stop-and-go” or what @bide just described? I was taught early when I got the RS+ that it may be easier just to turn logging off and on instead of taking shots so it is easier to tell where the shots are. Is this similar?

How long would it normally take to correctly post-process 10-15 points?

25

If you are switching on/off the raw log as your point collection mechanism, then you break the initialization each time, and so you need to add extra time to your next log to allow the post-processing job to regain a fix. @EarthImage mentions 10min per point, so that is 100-150minutes of collection time. Say you spend 5 minutes post-processing each log file, then that is another 50-75 minutes. Total time 150-125minutes (This is compressed time - not accounting for moving between points or traveling to/from the office, etc.)

Say you needed to collect 200 points in one day and also had to have the post-processing completed. In that scenario, you need the raw log to record continuously in order to hold the initialization so you don’t loose your fix while moving between points. At 30 seconds per point, that is 100 minutes. Say you spend 5 minutes per point on post-processing just like the previous scenario, then that is 1000 minutes. Total time 1100 minutes. (~18 hours)

Now you begin to see the difference when there is a demand for your productivity to increase. What would help is some automation (or a feature as @EarthImage has requested) - something to cut down the post-processing time and make it easily doable start-to-finish in one day.

Disclaimer: I am just estimating the numbers as a rough comparison here in these examples - do not take them literally.

1 Like
26

Thanks for this! This is why I only shoot RTK or use alternatives. Flying the site to just get horizontal via QGIS and then laser level ($250-300) off a certified benchmark works well for me.

1 Like
27

Thanks for the valuable information, I will give a try and let you know with my results…or help required.

Regards

Rahul

1 Like
28

Hey there,

Thanks for the request!

We have plans on implementation of “Stop-and-go” method, however, there is no ETA.

In the meantime, I recommend using a survey tool for placing GCPs. The workflow was greatly described by @bide.

2 Likes
29

You can also check out the DroneDeploy forum. We have posted several threads and tutorials on the subject and more in-depth on how they affect processing. I am @MichaelL there. Feel free to message me.

1 Like
30

Could you please explain me how would I do the point

  1. Start with your rover on a point in a clear area and stay on that point until you should have a fix (a few minutes). OR if you did set up for RTK, then you can confirm fix status on the screen.

It it possible with RTK to log in ubx file as well ?

Your PPK log solution works very well.

Your answer is much appreciable…

1 Like
31

Hi Rahul,

You surely can store raw data during the RTK survey. You just need to enable logging for both base and rover units in ReachView.

1 Like
32

This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.