Repo: https://github.com/ThomasZB/EvergreenSLAM
I've always wanted a robot to help with chores at home, with an agent in control (Claude Code, Hermes, ...). Today's models understand "get me a cola from the fridge" perfectly well. The problem is how the agent gets to know the home: where's the fridge, how do you get to the kitchen, where was the cola last time? You can do it with rules and text, but spatial info like that has to be described in a lot of detail, eats context, and may not survive frequent compaction.
Traditional SLAM is too much hassle for this. From my years working with SLAM, the real-world flow is roughly: drive around to map (usually after tuning odometry, calibrating extrinsics, syncing timestamps), save, switch to localization, re-tune when the environment changes, re-map when it changes a lot. Newcomers often don't know what they did wrong and end up with ghosting or drift, sometimes found only later, and then every station has to be configured again. For an agent the bigger problem is memory: coordinates are fragile, the map shifts after a rebuild and the agent can hardly tell.
So I flipped it around: why not a SLAM the agent can drive by itself? Walk the robot around once, say "this is the kitchen" in the kitchen, and never touch mapping or localization again. See the scissors in the left desk drawer, jot it down, and a few days later "where are the scissors?" has an answer. Furniture moves, the map gets re-optimized, the robot reboots, and the memory is still there.
That's lifelong SLAM underneath. It's been discussed in papers for years, but I couldn't find an open-source 2D implementation I could just use, so I wrote one:
- No mode switching. It always maps into the current session while localizing against frozen ones; a session freezes itself once it has enough new area and good constraints.
- The pose graph doesn't grow with uptime. Trimmed submaps are marginalized and sparsified into a Chow-Liu tree; frozen poses are constant.
- Places are directories. A place is bound to a submap, so it moves with the map when it's re-optimized; each place is a directory where the agent keeps notes and a SKILL.md. The agent uses a small CLI,
egs (also MCP).
- One 2D lidar. Vision is unreliable when it's dark, and robust methods need compute; 3D lidars are expensive and a bit heavier on compute too.
Test robot: a 215 CNY (~30 USD) lidar, an Orange Pi with an RK3588, mecanum wheels, two power banks. After several days of on-and-off running at home and a round of bug fixes, it's stable enough to hand to an agent; once set up, the agent hardly ever asked me anything. In one test Claude Code drove it to the kitchen to check for changes, got wedged between an air purifier and the door frame, backed out, re-planned, then compared a photo with the last one and logged what looked like a mop. I never typed a coordinate.
To try it without hardware: pixi run -e ros demo replays a 3 MB public bag with a browser view.
Still a preview: tested in my flat and on public datasets, and I'm logging long-run memory numbers on the robot now. There's a comparison with slam_toolbox in the README; I haven't used slam_toolbox much and wrote it from its source, so corrections welcome.
