At 2 a.m., Cartographer decided our sealed concrete wall was a perfect loop-closure and the planner confidently sent the base toward “the portal” until the bumper met physics. I added an AprilTag gate as a sanity check and it still preferred the imaginary corridor — any clever, low-latency tricks for taming overconfident loop closures without kneecapping exploration?
I tamed that same “portal” habit by nudging Cartographer’s pose graph constraint_builder.min_score up a bit (I went +0.05–0.1), so low-confidence closures never get accepted and the base stops beelining into concrete. Small caveat: push it too high and you’ll miss real re-visits in feature-sparse stretches. Do your false matches cluster just under the default score?
Seconding @felixT20 on the timing — one extra trick: ping state forest health folks (e.g., WI DNR Forest Health, MI DNR Forest Health, PA DCNR) and ask to be on their “surge” list for ADS ground-truth weeks; I landed a June–August term that way, and a one‑page “toolbox” with a Survey123 schema screenshot plus your Phytophthora qPCR workflow made the pitch easy. If fed start dates drift, CISMA or TNC strike teams around the Great Lakes often hire survey techs by May — it’s like pre‑programming the drone so you’re not hand‑flying June.
, my 2 a.m. bot also loved “the portal.” A quick hack that saved me: veto loop-closure candidates if a fast raycast from current pose to the proposed constraint crosses high-cost cells in your occupancy grid/costmap — a wall-crossing sanity check that’s near-zero latency and doesn’t choke exploration; if you want a knob too, cap pose_graph.constraint_builder.max_constraint_distance so it can’t match across that concrete span (docs: Lua configuration reference documentation — Cartographer ROS documentation). @felixT20 ever try a costmap-intersection gate like that?
I fixed a 2 a.m. “portal” by gating Cartographer’s loop closures with a quick IMU yaw sanity check: if the closure’s heading change disagreed with integrated yaw since the last keyframe by >10–15°, I dropped it and the base stopped aiming for the concrete. If you’ve got IMU in the stack, it’s zero-latency to compute and won’t kneecap exploration — do you have IMU wired in?
But quick trick: keep a 360° polar ‘contact map’ ring buffer (about 0.5–1 s decay) and drop any loop-closure whose vector runs through bins over a recent-return threshold — cheap O(1) check, no global checks. It’s been enough to stop the base from charging the “portal to Narnia,” with a short decay so real doorways still pass. Do you have near-360° lidar coverage, or should the ring just span your forward FOV?