Thresholds, Rugs, and Black Surfaces: Why Navigation Fails is a practical guide for households evaluating whether a home robot works in their actual environment. The immediate job is to understand sensors and test home-specific terrain. That matters because the underlying problem is knowing whether a home robot works in the mess and constraints of a real house. The useful outcome is a decision, record, or next action that another person can inspect—not a confident-sounding claim.
What this guide helps you produce
- A one-sentence outcome: understand sensors and test home-specific terrain.
- A source trail that distinguishes an official rule, a product claim, and your own observation.
- A small test with an owner, date, success threshold, and stop condition.
- A reusable checklist or worksheet rather than a one-time opinion.
- A next step connected to the actual user problem.
Use CPSC recalls as a starting point, then check whether its scope and update date match your situation. A source earns a place in the record because it supports a specific statement; it should not be added merely to make the page look researched.
1. Write the decision before collecting material
Research expands forever when the decision is vague. Write who must decide, the options available, the deadline, and the consequence of waiting. Then write the riskiest assumption in plain language. A useful assumption is falsifiable: a reasonable observation could make you change course.
- Owner: name the person accountable for the call.
- Outcome: understand sensors and test home-specific terrain.
- Evidence threshold: state what must be observed, by when, and in which population or environment.
- Stop condition: name the safety, cost, trust, or quality boundary that ends the test.
- Review date: schedule the decision while the evidence is still current.
This prevents a familiar failure: gathering facts that support the preferred answer while quietly ignoring evidence that would challenge it.
2. Build an evidence ledger
Separate official guidance, vendor or participant claims, direct observations, and inferences. CPSC recalls can support part of the framework, but it cannot prove what happened in your specific case. Record the exact URL, access date, relevant statement, and limitation beside every source.
| Entry | Record | Question |
|---|---|---|
| Decision | Owner, options, deadline | What changes after this work? |
| Claim | Exact wording and speaker | Is this a promise, estimate, or observation? |
| Evidence | URL, date, sample, method | What does it directly support? |
| Limitation | Missing data or boundary | Where could the conclusion fail? |
| Next test | Owner, threshold, stop rule | What is the cheapest credible learning? |
Keep raw notes beside the cleaned summary. If the conclusion later changes, the team should be able to see whether the world changed, the sample changed, or the original interpretation was weak.
3. Run the smallest credible workflow
- Define the subject. Record the exact person, cohort, device, page, campaign, workflow, or environment.
- Capture the baseline. Save the current state before changing anything.
- Check primary guidance. Prefer official documentation, regulators, standards bodies, and transparent first-party methods.
- Choose one intervention. Avoid changing several variables and then guessing which mattered.
- Observe the user outcome. A successful request or HTTP response is not automatically a successful user result.
- Record exceptions. Preserve failures, manual steps, reversals, and outliers instead of averaging them away.
- Make the decision. Choose proceed, revise, park, refer, or stop, and state why.
The workflow should remain proportionate to the risk. CPSC recalls is useful context for the control or standard, while your dated observation proves whether the intended outcome occurred.
Worked example
A household with a shedding dog, dark rug, 18 mm threshold, loose cable, and split-level floor builds the same eight-zone course for every robot. The score records misses, interventions, cleanup, noise, maintenance, and map behavior rather than collapsing everything into one unexplained star rating.
The important pattern is not the particular numbers. The example names the environment, preserves the baseline, uses a precommitted threshold, records limitations, and keeps a human decision at the consequential step. That makes the result reusable and auditable.
Common mistakes and safer alternatives
- Starting with a tool. Start with the decision and choose the lightest tool that can produce the evidence.
- Treating a claim as a fact. Preserve who made the claim and what independent observation would verify it.
- Using an undefined score. Publish the inputs, weights, exclusions, and version before publishing a ranking.
- Ignoring the failure path. Document rollback, escalation, manual review, and who owns exceptions.
- Collecting unnecessary data. Minimize sensitive fields and set a retention rule before collection.
- Reporting activity instead of outcome. Measure the user-visible result and the evidence needed to reproduce it.
These guides publish methods, not invented rankings. Product conclusions require a named unit, firmware version, repeatable course, raw observations, and retest date; manufacturer claims remain clearly labeled until independently observed.
Measurement and review
A useful review answers six questions: What changed? What did the user experience? Which evidence is direct? What remains uncertain? Did any safety or trust boundary activate? What decision follows? Keep the smallest set of metrics that answer those questions.
- Coverage: how much of the defined population, path, or environment was actually observed.
- Completion: whether the intended user outcome finished, not merely started.
- Quality: errors, reversals, interventions, disputes, or rework.
- Time and cost: the full effort, including maintenance and human review.
- Trust: consent, disclosure, privacy, accessibility, and explainability checks.
- Freshness: the last verified date and the next scheduled review.
Publish the review date next to any figure likely to change. If new evidence changes the answer, update the conclusion and preserve a short change note rather than silently rewriting history.
Primary sources and further reading
Source check completed 2026-07-13. Follow the linked publisher for the newest revision and confirm that the guidance applies to your jurisdiction, platform, device, or use case.