Robot vacuum obstacle avoidance — industry reference

A Harmony-SE reference scenario for consumer robot-vacuum obstacle avoidance — detection, deceleration, cliff protection, and escape behaviors modeled use-case-first for KB retrieval and AI4MBSE pacing.

Industry reference scenario — no real brand or SKU names.

Scenario context

Robot vacuum obstacle avoidance combines perception fusion, motion control, cliff detection, and escape maneuvers. Harmony-SE is use-case driven — a good fit for slicing everything from the user pressing Start Clean to the robot slowing near furniture into activities and state machines the knowledge base can retrieve per diagram.

Consumer teams move quickly, but the engineering problems are familiar: false positives from glass tables, missed cliff edges on dark carpets, and recovery when wheels slip. This reference encodes those patterns as teachable MBSE material without citing any real brand or firmware codename.

Use cases and operational modes

Primary use cases include whole-home cleaning, spot cleaning, dock return, and manual carry recovery. Each mode imposes different sensor fusion policies: full speed with conservative cliff guardrails during routine clean, tighter lidar thresholds during spot mode, and reduced torque during escape sequences.

Recommended diagram rhythm

  1. Use-case diagram for cleaning, dock return, and local re-clean
  2. Activity diagram for primary avoidance and degraded paths
  3. State machine for mode switches and fault recovery

Linked with the knowledge base, each diagram type retrieves sensor thresholds, timing budgets, and failure-mode lists so AI4MBSE constrains candidates instead of inventing consumer IoT tropes.

MBSE RAG value in this scenario

Industry reference scenarios exist so the engineering knowledge base can store reusable slices — requirements phrasing, allowed diagram sequences, naming prefixes, and verification hooks — without exposing any real customer program. When AI4MBSE runs a one-diagram-at-a-time session, MBSE RAG should pull only the fragments that belong to the active methodology and view. That keeps conversational modeling honest: candidates stay checkable, human-in-the-loop write-back stays authoritative, and reviewers still own baselines under configuration management aligned with INCOSE practice and OMG SysML / SysML v2 vocabulary.