INTERNATIONAL MISSION: AUTONOMOUS NAVIGATION

Camera Feed

Teleoperation

Map & Trajectories

Top-down view in the estimator's own frame, 1 m grid, auto-scaled to the data. The arrow is the current pose (heading = yaw). The base EKF is drawn but does not set the scale — on 2026-09-25 it ended a 20 m loop 19.49 m from its start, and letting a trace that wrong choose the extent squeezed MINS and the wheels into a few unreadable pixels. A trace running off the edge of the frame is itself the diagnosis. There is no continuous ground truth here — no motion capture and no RTK GPS — but a closed loop supplies two exact ones for free: the robot returns to its start, so net displacement is zero, and it completes a whole number of turns, so net rotation is a multiple of 360°. Neither can be flattered by an alignment, and they are what the trajectory comparison is scored on. A planned-path layer is not drawn because no planner runs on this robot yet.

The GNSS track is the only absolute reference on this map, and it is anchored to the others in position but not in heading. Satellite positions arrive as latitude and longitude; everything else here is metres from wherever the estimator happened to start. The GNSS trace is therefore pinned to the robot's estimated pose at the instant of its first fix, so the two share an origin in space and time. The heading offset is learned by driving. GNSS is north-up while the estimators use whatever heading the robot had at startup; over a leg longer than 3 m — far enough to beat a standalone receiver's scatter — the direction travelled in each frame differs by exactly that angle, and the overlay rotates itself to match. Drive a few metres in a straight line and the GNSS will line up with the other tracks; before that it points north and will not. Only a solved fix is plotted; a receiver reporting quality 0 is not drawing a position it has computed.

GNSS is drawn as a cloud of points, never as a line, and that is deliberate. A standalone receiver wanders by metres while the robot stands perfectly still. Joining those samples with a line would draw a path the robot never took — which is exactly how a trajectory layer reads. The dashed circle and its scatter figure enclose the recent fixes, so the wander becomes a number instead of an illusion of movement. That number is the case for RTK: metres here, against the about 14 mm a Fixed RTK solution gives. Watching it collapse once the base station broadcasts corrections is how we will know RTK is working.

The two perception layers show what the robot senses right now, and disappear when their sensor goes quiet rather than leaving a stale picture: lidar obstacles are the live /scan return rotated onto the map by the current pose (so they are only as accurate as that pose, and the lidar's own mounting offset is not yet compensated), and camera landmarks are the 3D points MINS is currently tracking, which appear only once MINS is running and initialized. Sparse scatter is expected there — MINS tracks a few dozen landmarks, it does not build a dense reconstruction.

Camera obstacles come from the ZED's depth map, reduced to a compact scan on the robot (scripts/depth_to_obstacles.py) because a raw depth frame is ~920 kB and cannot cross the tunnel. The two obstacle layers see genuinely different things: the lidar sweeps a full 360° in one horizontal plane and is blind above and below it, while the camera sees only a ~100° cone ahead but across a band of heights. Camera obstacles refresh roughly once per second while MINS is running — MINS saturates a core of the Jetson and the ZED's depth output drops with it; it is ~11 Hz with MINS stopped.

MINS State & Filter Health

Feature counts come from /mins/cam/msckf and /mins/cam/slam. They matter because the pose topic cannot tell you the filter has gone blind: with no visual features MINS keeps propagating on the IMU alone and still publishes a confident pose, drifting silently. A count falling toward zero while the robot is moving is the earliest visible symptom.

Zero while the robot is parked is normal, not a fault. Features are triangulated from the camera's own displacement between frames, so a stationary camera gives no parallax and nothing to triangulate — the count goes to zero and the few landmarks that do survive land at meaningless depths, typically bunched a few tens of centimetres from the robot. The visual layer cannot be judged on a parked robot at all, however good the calibration is. Drive a few metres and the landmarks should populate and settle onto walls and furniture; that is the check worth making.

Input streams

A stream that stops is shown as STALE with the time since its last message, and its trajectory dims on the map, so a sensor dropout is visible instead of looking like a robot standing still. Uncertainty comes from the covariance MINS publishes on /mins/imu/pose; the good/degraded/poor thresholds are a display heuristic, not values validated against measured error on this robot.

GNSS — satellite positioning

Why this matters, and why it is the one sensor the others cannot replace. MINS fuses only relative measurements — how far the wheels turned, how the image moved, how the IMU accelerated. Every one of them accumulates error without bound, so outdoors, with no loop to close, the estimate drifts forever. GNSS is the only planned sensor that gives an absolute position, and it is what stops that drift.

Plain satellite positioning is not accurate enough for a robot that has to follow a path: a standalone receiver lands within a few metres. The plan is RTK — two receivers, one parked at a surveyed point broadcasting corrections, one on the robot. With those corrections and a Fixed solution, horizontal accuracy reaches about 14 mm. The fix quality above is what to watch: 1 is plain GPS (metres), 5 is RTK Float (decimetres), 4 is RTK Fixed (millimetres). Anything below 4 is not the result we are after.

Status: hardware arriving, nothing fused yet. A u-blox receiver was first seen on this robot on 2026-09-28 and emitted valid NMEA, with no fix — which is exactly right indoors, since a GNSS antenna needs a clear view of the sky and a window is usually not enough. No ROS driver runs yet and MINS has no config_gps.yaml, so nothing here reaches the estimator. Full plan in the GNSS RTK positioning section of docs/technical.tex, in the Docs tab.

Sensors — obstacle detection

Also detect obstacles with the camera — costs the camera frame rate

Starts only the perception sensors: the RPLidar, the converter MINS needs to read it, and the camera depth-to-obstacle node. This is what fills the map with obstacle points, and it runs without the estimator — deliberately, so the map stays usable and demonstrable while MINS is being debugged. None of it runs at boot, since it costs power and CPU outside a session.

Camera obstacles work, as of 2026-09-24, and no longer cost the frame rate. This box used to report that the feature was unavailable: depth computation was measured at 1.294 s per frame, collapsing the stereo streams from 14.9 Hz to 0.80 Hz, and starving the stereo pair is exactly what made MINS diverge — so the driver ran with depth_mode: NONE. That measurement had only ever been taken in one depth mode. With depth_mode: PERFORMANCE and depth_stabilization: 0, the stereo pair and the obstacle scan run at 14.9 Hz together, MINS included. The cost is depth quality, which is the cheapest of the five active modes — fine for obstacles capped at 6 m, and worth revisiting if the depth map is ever wanted for anything more demanding. Lidar obstacles (red) cost nothing and are always on.

MINS estimate

Wheels on the ground (uncheck to carry the robot by hand) Also fuse the lidar into MINS — improves loop closure fivefold (0.093 m against 0.477 m on the same drive, 2026-09-25). Costs about 1.2° of heading and 44 points of CPU; it no longer halves the camera rate.

Fuses the ZED stereo pair, its IMU and the wheel encoders. With the robot stationary it holds position to under 2 cm over 95 seconds (measured 2026-09-11) and starts on its own, with no jolt, as long as the wheels are included.

The wheels checkbox is not cosmetic: lifted off the ground the encoders truthfully report “not turning”, which MINS cannot tell apart from “not moving”, so a hand-carry test needs them excluded — but without wheels MINS falls back to an initializer that needs a firm jolt to trigger.

Lidar fusion is off by default on measured grounds, not caution: it stays stable but takes MINS from 152 % to 425 % CPU, which halves its own camera intake from 14.8 to 7.0 Hz — and visual updates are precisely what keep this filter from drifting. The map's red obstacle points do not depend on it.

Research log

Technical doc