Optimizing the RT-Backpack in a Downtown Environment

The RT-Backpack is a useful tool for tracking pedestrians, cyclists and motorcyclists with high accuracy. It is commonly used in a track setting for car-to-pedestrian tracking and lane marking, but it can also be used off the track for various surveying applications.

The guide below will introduce the best practice for optimizing the output of the RT-Backpack in a downtown environment.

Configuration:

A predefined configuration for the RT-Backpack is included with NAVconfig. It can be found here: C:\Program Files (x86)\OxTS\RT-Range\RT-Back. Use the ‘Read Settings from a Folder’ option to locate it.

Once the predefined configuration has been read, the settings can be adjusted further before committing them to the device.

Here is a list of changes that can be made to optimize performance in a GNSS-denied environment:

• Corrections - It is highly recommended that corrections are used for the best performance in denied environments. The best options for corrections in a downtown environment is to make use of a local NTRIP service or Satellite Based corrections. You can find more information on all the corrections offerings here: Differential corrections on OxTS units- Overview – OxTS Support
• Environment - The initialization speed will be set to 1 m/s by default when the RT-Backpack configuration is loaded. This speed can be adjusted based on the needs of the user, but should be kept in the range of 1-1.5 m/s. When initializing, it is best if the user is walking at a comfortably brisk speed. The GNSS Environment should be set to ‘Some Obstructions (some trees and buildings)’.

Figure 1: NAVconfig environments window for the proposed RT-Backpack configuration

• GNSS Algorithm and Recovery Settings - The recovery settings should be set to ‘Mixed Mode’. This is feature code locked due to the OxTS gx/ix™ feature code. This setting is highly recommended and will improve results in environments with poor satellite visibility. You can read more about the benefits of gx/ix™ here: gx/ix™ overview/FAQ – OxTS Support                                  If you wish to unlock this feature code reach out to: sales@oxts.com

Operation:

When operating any device dependent on GNSS in an area with large buildings, trees and other factors, error like multipath can greatly affect the quality of your results. When using an OxTS INS, the act of initialization provides the system with an initial heading. Because of this the entirety of the dataset is dependent on a quality initialization. The next section will provide some tips on good initialization procedure and operation to positively affect the integrity of your data.

• Location - When initializing the unit, it comes highly recommended that the unit is in a RTK level position mode. This depends on a few factors, most importantly in a dense area: sky visibility. It is worth taking the time to look and plan your test around this requirement. If possible, plan to start and stop your test in a place where RTK can be reached. In a downtown environment, it can be more challenging to find a place without obstruction, but it is possible. Places like parks, bridges or sports fields often provide an adequate view of the sky. The best way to verify the position mode is to open NAVdisplay and check that a RTK level position mode is being displayed in the ‘Position Mode’ window.

Figure 2 & 3: Possible locations for initialization in a downtown environment

• Initialization - Because the initialization speed is set relatively low for this application, it is important to avoid exceeding the speed prematurely. On foot it is easy to do this by standing up quickly or turning. It is best practice to power the unit on or reset the unit once you are set and stay stationary until initialization. This can be made easier by sending the ‘!reset’ command in NAVdisplay once you are set to begin just before the test. Once you are ready and the unit has reset, you should see the ‘Ready to Initialize’ prompt in the bottom right hand corner of NAVdisplay. Now, walk in a straight line at a brisk pace for roughly 5-8 m or until you see the initialization message change to ‘Locking On’. At this point, you can stop moving and wait for the ‘Real Time’ message to display in the bottom right hand corner. This signifies that data is being recorded and output in real time.
• Movement - When on foot it is possible to saturate the gyros by turning too quickly. Depending on the unit being used the maximum speed of rotation should not exceed 100 /s or 300 /s. It is best to avoid stationary rotation as much as possible, especially when the unit is in harsh GNSS conditions. This can be done by walking in smooth curves and not quickly turning around. For the best results in completely GNSS denied environments keep the unit in motion whenever possible. Once the unit stops moving, drift error will begin to accumulate and affect your final output. With some thought and awareness of motion, the output from the device can be optimized.

Figure 4: Gyro saturation warning

• Warmup - Once initialized, it is important to provide the time and input necessary to warm up the device. This is done by walking around in figure eight patterns at differing speeds. You should walk making smooth left and right hand turns as well as stopping and starting multiple times. If possible, the warmup should be done in an area with a RTK level position mode, this will most likely be where you initialized. As you complete the warmup, you will begin to see the accuracies decrease. Once you see the accuracies decrease and stabilize, you can move forward with your test.

Figure 5: Example of a warmup path in a downtown park

• Finishing a Test – When processing data from a denied environment it is possible to further optimize the data with combined processing. In order to process using combined (otherwise known as forward and backward processing), the dataset must be ended in a similar way to how it began, by completing a short cool down and walking in a straight line above the threshold speed before stopping. This allows the algorithm to achieve a heading solution when processing the dataset backwards. If possible, this should be done in an area where the unit can achieve RTK level positioning. Again, some thought should be put into planning where the test will end. Often, it is easiest to end the test where it began, essentially retracing your steps.

Figure 6: Data collection workflow for data to be processed in combined mode.

Processing:

The final step in optimizing the output of your RT is processing the data. This section of the article looks to provide information on selecting the best processing options for the backpack.

• Processing Mode - As discussed earlier, combined processing will output the highest quality end result. In order to get the most out of this feature a warm down and initialization should be completed at the end of the test. More on this can be found under ‘Finishing a Test’ in the previous section of this article. If you wish to read more about the available processing modes, follow this link: Post Processing guide – OxTS Support
• Corrections in Post – If corrections were not available in real time they can be added in post in the form of a RINEX file. One way to apply a RINEX file would be to contact your local provider and acquire a file that corresponds to the day of testing, you can then apply this file in NAVsolve. There is also the option to use the built-in base station search tool within NAVdisplay. It is worth mentioning that processing with a RINEX file will require that the unit algorithm is set to gx/ix™. For more information on postprocessing with a RINEX file follow this link: Differential corrections on OxTS units- RINEX files in post processing – OxTS Support

Figure 7: Example trace for a data set taken in downtown Chicago