06 -- RTK & GCP
0 6 -- RTK & Ground Control Points
📑 Table of Contents — click to navigate
- 01 — Hardware Setup Device specs, firmware, SD cards, batteries, connectivity, accessories
- 02 — PointCloud Studio Installation, versions, settings, project management, data processing
- 03 — Scanning Workflows Field scanning strategies, movement, environment, multi-scan projects
- 04 — 3DGS Workflow Gaussian splat generation, settings, GPU requirements, processing time, quality
- 05 — Hybrid Workflows Combining LiDAR with external cameras, drones, RealityScan, Postshot pipelines
- 06 — RTK & GCP RTK setup, GNSS fusion, coordinate systems, control points, accuracy
- 07 — Troubleshooting Common issues and community-verified solutions
- 08 — Third-Party Tools CloudCompare, RealityScan, Postshot, LFS, D5 Render, Blender, BricsCAD
- 09 — Bot Knowledge Official answers, product specs, known limitations from bot and support team
Applies to: C1 and S20 (unified unless noted)
Related: Master Index | 01-Hardware-Setup | 03-Scanning-Workflows | 07-Troubleshooting
What RTK Does
RTK (Real-Time Kinematic) provides absolute positioning for your scans -- placing point clouds in real-world coordinates rather than an arbitrary local origin.
| Capability | Without RTK | With RTK |
|---|---|---|
| Coordinate system | Local Euclidean (origin at start position) | Real-world EPSG projected coordinates |
| Scan-to-scan alignment | Manual via CloudCompare | Automatic via GNSS Fusion |
| Absolute accuracy | None | ~1-3 cm |
| Large area scanning | Drift accumulates | Drift minimized by absolute references |
| GCP recording | N/A | Timestamps only (not coordinates -- see below) |
RTK Hardware
C1 RTK Module
- External add-on (UM980 chipset)
- Attaches to top of device
- Includes positioning plate for ground-level measurements
- Antenna offset from ground: ~44 cm (measured by pierro5261)
- Antenna-to-LiDAR optical center offset: specific to C1 (not publicly documented)
S20 RTK
- S20 RTK antenna offset: ~34.72cm (vertical, antenna to LiDAR optical center -- per Rami Tamimi video)
- Different from C1 -- do not interchange values
NTRIP Providers (US)
- GEODNET: ~$40/month (jyst_mike)
- Rock Robotic base station: Buy hardware (~$700), contribute to network, get free corrections
- NTRIP protocol is standard -- any provider works
NTRIP Setup
- RTK-enabled device
- NTRIP subscription (or local base station)
- Internet connection on phone
- That's it -- no extra hardware needed
GNSS Fusion in PointCloud Studio
Enabling GNSS Fusion
- In Data Calculation -> Mapping Parameters
- Enable GNSS Fusion
- Select Horizontal Setting (EPSG code)
- Enter Height Offset (antenna-to-ground correction)
Horizontal Setting -- CRITICAL
- Select plain EPSG code (e.g., EPSG:32617)
- DO NOT select variant with "(Ft)" suffix -- causes stretched/scaled geometry
- Symptom of wrong setting: known 3-foot door measures 2.98 meters (tool_guy_365)
- Validation: Process same scan without GNSS Fusion to verify geometry
Height Offset
- GNSS Fusion height offset is hardware-specific -- C1 differs from S20's ~34.72cm
- Test against known benchmark: pierro5261 measured +44 cm deviation; tool_guy_365 measured +57 cm
- Currently no option in mobile app to configure antenna offset/pole length/device height
GNSS Fusion Tradeoffs
| Setting | Result |
|---|---|
| GNSS + Undistorted Photos + SFM ON | More noise artifacts (clumps) but cleaner, more photo-realistic surfaces |
| GNSS + Undistorted + SFM OFF | Less noise, "pretty darn good" baseline quality |
Choose based on priority: photorealism vs geometric cleanliness.
Ground Control Points (GCPs)
Current State (as of May 2026)
IMPORTANT: C1 control points record TIMESTAMPS only -- NOT coordinates.
When you mark a control point on the C1 and hold still for ~10 seconds:
- System records timestamp/marker information
- control_points.csv file has blank X, Y, Z fields (tool_guy_365, confirmed by Luna)
- This is expected behavior in current firmware (Luna, Apr 22)
Luna (Apr 22): "The RTK on our device is mainly used for georeferencing the point cloud and supporting scan alignment, but it does not currently output absolute GNSS coordinates for control points."
Control Point Position
- Recorded position is projected to ground target level -- offset is compensated (Luna, Apr 23)
- Position captured at camera level; software projects down to ground
GCP Calibration Feature (PCS v2.2.3+)
- Available in standard version (not Beta)
- Works WITHOUT RTK module (Frank, Apr 12)
- Video tutorial: https://www.youtube.com/watch?v=qGCNxVh7BSY
- Currently requires manual coordinate entry -- coordinates must be known in advance
- Feature not yet confirmed in any Beta version
GCP Workflow (Manual)
- Place targets visible in multiple scans
- Measure target coordinates with professional RTK rover or total station
- Enter coordinates manually in PCS
- PCS aligns scans using known GCP positions
DIY GCP Targets
- 3D-printed checkerboard with GNSS pole hole (ser0ka)
- Self-adhesive printed targets: ~40 for 10
- Quick-and-dirty: tape + pen to draw an X
Multi-Scan Alignment with GCPs
Using CloudCompare (Manual)
- Place GCP targets in overlapping areas between scans
- Import both point clouds into CloudCompare
- Use targets to place alignment markers
- Apply ICP (Iterative Closest Point) refinement
- Verified by mr_red1991_63830: "finally learned how to align 4 PC together with checkerboard"
See 08-Third-Party-Tools for detailed steps.
Without External Software
PCS currently does NOT support scan fusion/alignment natively. CloudCompare or Leica Register 360 required.
RTK Coordinate Issues with 3D Software
Large Coordinate Problem
- RTK data produces 64-bit point clouds with large real-world coordinate values
- Blender: Data appears "divided and incomplete" -- doesn't handle large coordinates
- Fix: Re-center to local coordinates (0,0,0)
Solution: CloudCompare Global Shift
- Open RTK point cloud in CloudCompare
- Apply transformation/global shift
- Export non-georeferenced copy for 3D software
- Keep one original RTK/georeferenced dataset + one "local coordinates" version for artists (ser0ka)
Alternative: Houdini
- Can automate coordinate transformation
- User preference for those comfortable with Houdini
RTK Limitations (Current)
| Limitation | Detail |
|---|---|
| No GCP coordinate output | control_points.csv has blank X/Y/Z (confirmed by Luna) |
| No pole/antenna offset config | Height correction must be done manually in PCS |
| S20/C1 have different offsets | Values not publicly documented |
| RTK doesn't guarantee good scans | Scan can still corrupt even with RTK Fixed status (tool_guy_365) |
| No decimal degree output | Only UTM (Easting/Northing in meters) |
Community Requests
- RTK-based GCP coordinate recording (mr_red1991_63830, pierro5261)
- Decimal degree (WGS84) output option (tool_guy_365)
- Pole length/antenna height configuration in mobile app
- Better documentation/tutorial for RTK setup
RTK Accuracy
| Context | Accuracy |
|---|---|
| Relative (scan-to-scan) | RTK-level (~1-3 cm) |
| Absolute (world position) | RTK-level when GNSS Fusion enabled |
| GCP coordinates | NOT provided by C1/S20 -- need separate professional RTK rover |
RTK accuracy is for absolute position (where the building/site is located). Relative accuracy (wall heights, window dimensions) depends on the scanner and software you use -- these are different concepts (pierro5261).