Robot Return to Origin: Coordinate Tracking
LeetCode 657, Robot Return to Origin, gives you a string of move instructions and asks whether the robot ends up back where it started. Each character in the string is one of 'U', 'D', 'L', or 'R', representing a single step in that direction on a 2D plane. If the robot finishes at the origin (0, 0), return True. Otherwise, return False.
It is one of the cleanest simulation problems on LeetCode, and the solution boils down to one insight: you do not need to track the full path. You only need to track the final position.
The problem
You are given a string moves containing only the characters 'U', 'D', 'L', and 'R'. The robot starts at position (0, 0) on a 2D plane. Each character moves the robot one unit in the corresponding direction. Return True if the robot returns to the origin after completing all moves. Return False otherwise.
Examples:
"UD"returnsTrue. The robot goes up, then back down to(0, 0)."LL"returnsFalse. The robot goes left twice and ends at(-2, 0)."UDLR"returnsTrue. Every direction is cancelled by its opposite.
Why coordinate tracking works
Think about what it means for the robot to return to origin. It needs to end up with the same x-coordinate and the same y-coordinate it started with. That means every 'L' must be balanced by an 'R', and every 'U' must be balanced by a 'D'.
You do not need to simulate the grid or remember every position the robot visited. You just need two counters: one for horizontal displacement and one for vertical displacement. Walk through the string character by character, updating the counters. At the end, check if both are zero.
This is a common pattern in simulation problems. Before building a full simulation, ask yourself: "What is the minimum state I need to track?" Here, the answer is just two integers.
Step-by-step walkthrough
Step 1: Initialize coordinates at the origin
The robot starts at position (0, 0). We will track x for left/right and y for up/down.
Step 2: Process each character in "UDLR"
| Move | Action | x | y |
|---|---|---|---|
| U | y += 1 | 0 | 1 |
| D | y -= 1 | 0 | 0 |
| L | x -= 1 | -1 | 0 |
| R | x += 1 | 0 | 0 |
Each move adjusts one coordinate by 1. U and D change y. L and R change x.
Step 3: Check if final position is (0, 0)
Both x and y are zero, so the robot is back at the origin. Return True.
Step 4: Counter-example with "LL"
| Move | Action | x | y |
|---|---|---|---|
| L | x -= 1 | -1 | 0 |
| L | x -= 1 | -2 | 0 |
x is -2 and y is 0. The robot did not return to origin. Return False.
The walkthrough traces "UDLR" and shows that every move is cancelled by its opposite. The counter-example "LL" shows what happens when moves are not balanced. The x-coordinate ends at -2, so the robot never returns.
The code
def judge_circle(moves: str) -> bool:
x, y = 0, 0
for move in moves:
if move == 'U':
y += 1
elif move == 'D':
y -= 1
elif move == 'L':
x -= 1
elif move == 'R':
x += 1
return x == 0 and y == 0
The function initializes x and y to zero, then iterates through the string once. Each character adjusts the appropriate coordinate. After the loop, the return value checks whether both coordinates are back to zero.
You could also use Python's count method for an even more concise version:
def judge_circle(moves: str) -> bool:
return moves.count('L') == moves.count('R') and moves.count('U') == moves.count('D')
This version makes the balancing idea explicit. The robot returns to origin if and only if the number of left moves equals the number of right moves, and the number of up moves equals the number of down moves. Both approaches scan the string once, so the time complexity is the same.
A common mistake is checking only one axis. If you only verify that x == 0 but forget to check y, a string like "UU" would incorrectly return True. Always check both coordinates.
Complexity analysis
| Metric | Value |
|---|---|
| Time | O(n) |
| Space | O(1) |
The algorithm makes a single pass through the string, so time is linear in the length of the input. The only extra memory used is two integer variables, so space is constant.
The building blocks
Simulation with minimal state
Many simulation problems tempt you into building elaborate data structures to track every detail of the process. The building block here is recognizing when you can reduce the state to just a few variables. In Robot Return to Origin, the full grid is irrelevant. Only the displacement matters.
This same principle applies in problems like gas station (track a running surplus instead of simulating the full trip) and jump game (track the farthest reachable index instead of simulating every possible jump sequence). The skill is identifying what state you actually need before writing any code.
Edge cases
- Empty string: No moves are made. The robot stays at
(0, 0). ReturnTrue. - Single character: Any single move takes the robot away from the origin. Return
False. - All same direction:
"RRRR"moves the robot far from origin. ReturnFalse. - Very long string: The algorithm runs in O(n) time, so even strings with hundreds of thousands of characters are handled efficiently.
- Already balanced pairs:
"RLRL"cancels perfectly. ReturnTrue.
From understanding to recall
Robot Return to Origin is an easy problem, and the solution feels obvious once you see it. But the underlying skill, identifying the minimal state for a simulation, is something you want to internalize deeply. That skill transfers directly to harder problems where the naive simulation is too slow or too complex.
Spaced repetition helps here. Instead of re-reading the solution once and moving on, drill the "reduce simulation to minimal state" building block at increasing intervals. After a few review sessions, the instinct to ask "what do I actually need to track?" becomes automatic, even on problems you have never seen before.
Related posts
- Happy Number - Another simulation problem where you track state through a sequence of transformations
- Valid Palindrome - A string traversal problem that also reduces to a simple pass through the input
- Move Zeroes - Uses minimal state (a write pointer) to solve what looks like a complex rearrangement problem