See like a Robot: Robot-Centric Pointmaps for Vision-Language-Action Models

Byungkun Lee1*, Dongyoon Hwang1*, Dongjin Kim1, Hojoon Lee2, Minho Park1, Jaegul Choo1

1KAIST AI 2Holiday Robotics

*Equal contribution

arXiv Paper Code BibTeX

TL;DR — Give a VLA per-pixel 3D in the robot frame,
and it stays robust as training-time camera viewpoint variation grows.

Architecture: a pointmap encoder is added next to the RGB encoder and its tokens are element-wise added before the VLA backbone.
As camera variation during training grows from none to high, RGB-only drops from 34.5 to 24.9 while RGB + Pointmap stays near 36, widening the gap from +3.1 to +10.9 points.

Robot datasets mix demonstrations from many camera viewpoints; as that training-time variation grows,
an RGB-only policy degrades while pointmaps keep it robust, widening the gap to +10.9 points.
The whole method is one extra encoder and one element-wise addition.

Motivation

Large-Scale Robot Data Spans Many Camera Viewpoints,
but Actions Are Defined in the Robot Frame
Third-person camera viewpoint distribution around a Franka robot in DROID.
Third-person camera viewpoints in DROID (subsampled); brighter colors indicate regions of higher viewpoint density. Figure from DROID.

Large-scale robot datasets aggregate demonstrations collected across labs and episodes, often from different camera viewpoints. DROID, for example, contains 1,417 unique third-person viewpoints.

Why does this viewpoint variation matter? A VLA observes the scene in the camera frame but predicts actions in a robot-centric frame, creating an observation-to-action frame mismatch. With a fixed camera, this mapping remains consistent across demonstrations. As training data spans more viewpoints, however, the policy must generalize the mapping from multiple camera frames to the shared robot-frame action space, making the task harder to learn.

To test this, we conduct a controlled study on 24 RoboCasa tasks. Using a π-style model initialized from a base PaliGemma checkpoint, we vary only the amount of camera viewpoint randomization across training demonstrations while keeping the remaining training and evaluation settings fixed.

Camera poses in the training data under No variation, Low, and High camera viewpoint randomization, shown as camera frustums around a RoboCasa kitchen scene.
The two third-person cameras' poses in the training demonstrations, shown as frustums over a RoboCasa scene. From left to right, we widen the camera viewpoint randomization from none to high.
RGB-only success decreases from 34.5% to 24.9% as training-time camera viewpoint variation increases.
−9.6 points
RGB-only degrades as training-time viewpoint variation increases.

Solution

Bridge Camera-Frame Observations and Robot-Frame Actions
with Robot-Centric Pointmaps

Rather than asking the policy to learn how each camera frame maps to robot-frame actions, we express the observed 3D geometry from different viewpoints in a shared robot frame. This gives the policy a consistent geometric coordinate system across diverse camera viewpoints. Robot-centric pointmaps bridge this frame mismatch while preserving the image-form representation used by pretrained VLAs.

Observations from different camera frames are expressed in the shared robot frame where actions are defined.

A robot-centric pointmap stores robot-frame XYZ coordinates at the corresponding image pixels, preserving the same dense H × W grid as RGB.

The whole method: one extra encoder and one element-wise addition.

Full model architecture: each RGB-D observation becomes a robot-centric pointmap, encoded by a second image encoder and added element-wise to the RGB tokens.
Full architecture. Each camera's pointmap is encoded by a second image encoder, initialized from the RGB encoder, and added element-wise to the RGB tokens right next to it. Nothing else in the VLA changes.

Results

Pointmaps Keep the Policy Robust as Training-Time Viewpoint Variation Increases

Adding pointmaps to the same controlled study changes the trend: RGB + Pointmap drops by only 1.8 points, compared with 9.6 points for RGB-only.

On the same axes as the intro chart, RGB + Pointmap decreases from 37.6% to 35.8% while RGB-only decreases from 34.5% to 24.9%.
−9.6 points
RGB-only degrades as training-time viewpoint variation increases.
+3.1 → +10.9 points
The pointmap advantage over RGB-only widens as training-time viewpoint variation increases.

Pointmaps Improve Both Pretrained VLA Backbones

On RoboCasa, third-person camera viewpoints are randomized across training demonstrations. In this setting, pointmaps improve both pretrained backbones: +7.6 on π0.5 and +4.2 on SmolVLA.

55.3 → 62.9
π0.5 average success with pointmaps (+7.6).
37.2 → 41.4
SmolVLA average success with pointmaps (+4.2).

With π0.5, pointmaps reach 62.9% average success, outperforming all camera-aware, 3D-augmented, and point-cloud baselines.

MethodCategoryBackboneAvg. SR
FP3Point-cloud policy42.8
π0.5π0.555.3
OC-VLACamera-aware VLAπ0.556.3
KYCCamera-aware VLAπ0.559.1
GeoVLA3D-augmented VLAπ0.557.1
PointVLA3D-augmented VLAπ0.557.3
π0.5 + Pointmap (ours)Oursπ0.562.9

FP3 is a DROID-pretrained point-cloud policy without a VLA backbone. Per-task-category results are in the paper.

On a Real Robot, the Gap Widens at an Unseen Camera Viewpoint

We collect 180 demonstrations over four tasks on a FR3 while repositioning the external camera across three training viewpoints. We then evaluate the policies at one seen viewpoint and at a held-out viewpoint not observed during training.

At evaluation, the external camera is placed either at one of the training viewpoints (seen) or at a held-out viewpoint not used for data collection (unseen). Pointmaps improve performance at both camera viewpoints, but the advantage grows from +5.0 points at the seen viewpoint to +11.7 points at the unseen viewpoint. By expressing observed geometry in the robot frame, pointmaps provide a more consistent spatial representation when the external camera moves beyond the training viewpoints.

73.3 → 78.3
Seen camera viewpoint, π0.5 → π0.5 + pointmap (+5.0).
55.0 → 66.7
Unseen camera viewpoint, π0.5 → π0.5 + pointmap (+11.7).
Real-world success rate (%), 15 rollouts per task per camera viewpoint. DP3 is a from-scratch point-cloud diffusion policy, unlike FP3 in the simulation table (a DROID-pretrained point-cloud foundation policy).
Eval. viewpointModelAvg.Pick-and-placeStack blocksOpen drawerClose drawer
SeenDP363.360.040.060.093.3
π0.573.380.053.373.386.7
π0.5 + pointmap78.386.760.073.393.3
UnseenDP348.333.333.340.086.7
π0.555.040.026.766.786.7
π0.5 + pointmap66.753.346.773.393.3

Per-Task Videos, From Training Views to Unseen-Viewpoint Rollouts

The top row shows one training demonstration from each training viewpoint, seen from the policy's external input camera. The rows below show evaluation rollouts at the unseen viewpoint, recorded from a separate fixed camera, comparing π0.5 and π0.5 + Pointmap. All clips play at 2× speed.

Training demonstrations, three camera viewpoints
Train view 1
Train view 2
Train view 3
Evaluation rollouts, unseen viewpoint
π0.5
π0.5
π0.5
π0.5 + Pointmap ✓
π0.5 + Pointmap ✓
π0.5 + Pointmap ✓
Training demonstrations, three camera viewpoints
Train view 1
Train view 2
Train view 3
Evaluation rollouts, unseen viewpoint
π0.5
π0.5
π0.5
π0.5 + Pointmap ✓
π0.5 + Pointmap ✓
π0.5 + Pointmap ✓
Training demonstrations, three camera viewpoints
Train view 1
Train view 2
Train view 3
Evaluation rollouts, unseen viewpoint
π0.5
π0.5
π0.5
π0.5 + Pointmap ✓
π0.5 + Pointmap ✓
π0.5 + Pointmap ✓
Training demonstrations, three camera viewpoints
Train view 1
Train view 2
Train view 3
Evaluation rollouts, unseen viewpoint
π0.5
π0.5
π0.5
π0.5 + Pointmap ✓
π0.5 + Pointmap ✓
π0.5 + Pointmap ✓

Ablation Studies

Why does the design look the way it does? Each choice is backed by its own controlled ablation on RoboCasa. The backbone and training recipe stay fixed, and only the 3D input changes.

For these controlled studies, we use a model without robot pretraining to isolate the effect of each input design. Its success rates are therefore lower than those of the pretrained VLAs evaluated later.

1Pre-compute Robot-Frame Geometry

Plücker rays describe the camera geometry, and depth provides per-pixel distance. RGB + Plücker + Depth therefore contains the information needed to obtain robot-frame geometry, but leaves it for the policy to infer. Providing robot-frame geometry directly as a pointmap improves success from 31.6% to 34.7%.

InputRobot-frame geometrySR
RGBnot provided27.9
RGB + Plückernot provided28.7
RGB + Plücker + Depthleft to the policy31.6
RGB + Pointmapprovided directly34.7
2Preserve the Image Grid

Pointmaps outperform point-cloud inputs while preserving the dense image grid used by the VLA. Because RGB and pointmap tokens share the same spatial layout, element-wise addition further improves success from 30.7% to 34.7%.

3D inputEncoderFusionSR
None27.9
Point cloudMLPconcat24.2
Point cloudPTv3concat32.8
Pointmapimage encoderconcat30.7
Pointmapimage encoderadd34.7
Element-wise addition preserves spatial correspondence; concatenation treats pointmap tokens as a separate sequence.
3Center Geometry at the End Effector

Centering the pointmap at the current end-effector position reduces variation caused by absolute workspace location, making similar interactions appear in a more consistent local coordinate system. It improves success under both fixed and randomized evaluation viewpoints.

Pointmap originFixed eval.Randomized eval.Drop
Robot base34.732.7−2.0
End effector36.936.6−0.3
End-effector centering concentrates interaction targets near a common origin.

BibTeX

@article{lee2026seelikearobot,
  title         = {See like a Robot: Robot-Centric Pointmaps for Vision-Language-Action Models},
  author        = {Lee, Byungkun and Hwang, Dongyoon and Kim, Dongjin and Lee, Hojoon and Park, Minho and Choo, Jaegul},
  journal       = {arXiv preprint arXiv:2607.11498},
  year          = {2026},
  eprint        = {2607.11498},
  archivePrefix = {arXiv},
  primaryClass  = {cs.RO}
}