Localization and pose
Scope
Setting and verifying the robot’s pose on the map before and during navigation, and recovering when localization is lost.
Purpose
Localization is the foundation. If the robot’s on-screen position does not match its physical location, all downstream navigation will be unreliable. [SOURCE: GO2 SOP V3 §III "The 5 Rules" Rule 1]
Required inputs / tools
- Hardware: powered-on GO2W positioned within the mapped area.
- Software: Skild tablet OR browser at https://control.skild.ai/robots.
- Permissions: Skild operator credentials.
- Documents: the floor map for the area you are operating in.
Procedure
Before — Set Pose
- Select the correct map from the dropdown list. Multiple maps may exist; verify the selection matches your physical location.
[SOURCE: SOP V3 §X "System Readiness Verification"] - On tablet:
- Select the robot icon (top-right of the map view).
- Switch the map to Place Mode (red toggle at top-right of map view).
[SOURCE: SOP V3 §XII] - Select “Set Robot Pose”.
- Tap and hold the map at the robot’s actual physical location. Keep your finger on the screen.
- While still holding, drag outward in the direction the robot is physically facing. The arrow base stays where you tapped; the tip follows your finger.
- Release when the arrow points the correct way.
- Confirm the pose. The GO2 icon will populate at the specified position.
- On browser:
- Open the Remote Controls panel (top-right control icon).
- Scroll to the Robot section and click Set Robot Pose.
- On the global map (open via the toolbar map icon; hold spacebar + trackpad scroll to pan), click at the robot’s real-world position and drag the arrow in the direction the robot is physically facing.
- Release, then click Publish Robot Pose (green button).
- If the published pose looks wrong, click Cancel (red button directly below) and repeat.
[SOURCE: SOP V3 §XII "Setting Pose" + "On Browser"]
During — Verify Localization
Continuously verify that the on-screen position matches reality. Minor lag between screen and reality is normal. The blue tracer line may shift and recalculate — this is standard adaptive behavior. [SOURCE: SOP V3 §XII "Verifying Localization"]
- Pick a fixed, identifiable real-world landmark near the robot (fountain, trash kiosk, pillar, store entrance).
- Locate the same landmark on the 2D map.
- Compare the robot’s position relative to the landmark on the map against its position relative to the landmark in reality.
- If positions match within roughly one map grid cell, proceed. If they diverge, treat localization as lost and reset the pose.
- Zoom in before judging. Small drift is hard to see at default zoom. Zoom into the map around the robot’s icon before deciding whether localization is lost.
[SOURCE: SOP V3 §XII "Zoom In Before You Judge"]
After — Recovery from Localization Loss
When localization is lost:
- Cancel the active waypoint goal or route immediately.
- Enter teleop (controller: LT + X). Drive the robot to a recognizable landmark — somewhere you can easily identify both physically and on the map.
- Sit the robot (controller: LT + Y).
- Reset pose by matching the robot’s position on the map to the recognizable real-world location.
- Restart the navigation goal or route.
[SOURCE: SOP V3 §XII "Recovery from Localization Loss"]
Default to caution
A sit-and-reset takes seconds. Allowing a poorly-localized robot to continue autonomous navigation creates genuine safety risk. When uncertain, always stop and reset.
[SOURCE: SOP V3 §XII]
Quality checks
- Robot icon position on the map matches the robot’s actual position relative to a known landmark within ~1 grid cell.
- The blue tracer (planned-path line) follows a coherent, logical path. Erratic or illogical tracers indicate localization, mapping, or obstacle-detection issues.
[SOURCE: SOP V3 §XIV "Blue Tracer Line"] - No localization-loss alerts at the bottom of the interface.
Common failure modes
| Issue | Likely cause | Action |
|---|---|---|
| Map icon lags behind live camera, landmarks still match when lag resolves | Visual lag, not lost localization | Do not intervene. [SOURCE: SOP V3 §"When to Stop the Robot — Decision Guide"] |
| Map icon and physical position diverge at a known landmark | Localization lost | Kill task → teleop to recognizable spot → sit → reset pose → resume. |
| Recurring localization failures across runs | Map is stale (environment changed) | Re-map. See /robots/go2/operation/mapping/ “When to Re-map”. |
| Pose-publish appears in the wrong place on the map | Map selection mismatch (wrong floor / wrong area) | Verify the correct map is loaded; re-set pose. [SOURCE: SOP V3 §X] |
Crowds elevate localization-loss risk
Crowds increase the likelihood of localization loss. Elevate monitoring accordingly in high-traffic environments. [SOURCE: SOP V3 §III Rule 1]
Escalation
- Persistent localization loss after pose reset → consider re-mapping (escalate to the deployment Slack channel).
- Localization loss during a navigation run requiring physical intervention → file an Incident Report (see /general/incident-response/).
Source notes
[SOURCE: GO2_Standard_Operating_Procedure_V3.docx]§III (Rule 1), §X, §XII (Localization & Pose), §XIV (Blue Tracer), and “When to Stop the Robot”.[SOURCE: GO2_Standard_Operating_Procedure_ABM.docx](April 2026, Tyler Kugima) §XII Localization & Pose. Authoritative for ABM-LGA.[SOURCE: GO2_General_Operating_Instructions_V3.docx]— older companion doc; confirms localization-loss is the most common operational issue.
Related
- /robots/go2/operation/mapping/ — must produce a valid map before localizing.
- /robots/go2/troubleshooting/common-symptoms/ — symptom → action table including localization scenarios.
- /general/incident-response/ — when to file a report.
- /sites/lga/overrides/ — LGA-specific landmarks worth memorizing.