You start a mop run, the status light turns blue, the robot drives normally, and you may hear a faint high-frequency “buzz” from the VibraRise Module… but the mop pad stays dry and the floor shows zero wet trail. Sometimes the robot lifts the mop like it “thinks” it hit carpet, even on tile. That behavior points to a control decision, not just “a dirty pad.”

The Logic: Why Your Robot is Confused

Roborock S7 does not “always pump water.” The firmware gates water output behind multiple inputs:

• Mode State: The robot must enter mopping state (blue indicator for vacuuming+mopping). The manual maps the light states: Blue = Vacuuming and mopping, and quick-flashing red = Error. :contentReference[oaicite:0]{index=0}
• Ultrasonic Carpet Recognition: S7 uses Ultrasonic Carpet Recognition to detect carpet and lift the mop. If the Carpet Sensor misreads your hard floor as carpet, the logic lifts the mop and can reduce/stop water output to avoid soaking rugs. :contentReference[oaicite:1]{index=1}
• Safety Loop: False positives from Cliff Sensors trigger a protective “stop / reroute” behavior. The controller prioritizes fall prevention over mopping consistency. :contentReference[oaicite:2]{index=2}
• Mechanical Presence Signals: The robot expects proper installation of VibraRise Mop Cloth Mount and water system parts like Water Filter and Electric Water Tank. A weak latch “click” can break the expected state. :contentReference[oaicite:3]{index=3}
• Odometry + Navigation Health: Wheel Encoders, a Gyroscope, and the LiDAR Turret maintain stable motion planning. When navigation fails (example: LiDAR turret error), the robot interrupts cleaning routines including mopping. :contentReference[oaicite:4]{index=4}

Result: You can clean the pad all day and still get “dry mopping” if a sensor state blocks the water-output loop.

Protocol 1: The “Soft” Fix (Software & Reset)

1) Force the correct mop state in the app

• Open the Roborock app → select S7 → set cleaning mode to Vacuum & Mop or Mop Only.
• Set Water Flow to Medium/High for testing.
• Temporarily disable “avoid carpets while mopping” features and remove No-Mop Zones in the test area.

Engineer’s Note: App toggles write the state machine parameters. If Wi-Fi drops, the robot can continue running an old water-flow profile, and you will chase the wrong “hardware” problem.

2) Reboot the control stack (fast reboot)

• Power off the robot.
• Wait 15 seconds.
• Power on and start a small 1×1 meter zone clean on hard floor.

Engineer’s Note: A reboot clears transient sensor fusion glitches (example: carpet classifier stuck “true”). You want a clean sensor read at boot.

3) Confirm 2.4GHz Wi-Fi (not 5GHz) before you troubleshoot deeper

The S7 Wi-Fi spec targets the 2.4GHz band (802.11 b/g/n, 2400–2483.5 MHz). Put the robot on a 2.4GHz SSID for stable app control and firmware delivery. :contentReference[oaicite:5]{index=5}

Engineer’s Note: You do not “need Wi-Fi to pump water,” but you do need reliable Wi-Fi to keep settings, maps, and firmware consistent while you diagnose.

4) Run a factory reset only after the steps above

Roborock’s factory reset procedure uses the Home button plus the Reset pinhole next to the Wi-Fi LED. Follow the exact sequence from Roborock Support. :contentReference[oaicite:6]{index=6}

Engineer’s Note: A factory reset wipes maps and schedules. Use it to kill a corrupted configuration that keeps the mop logic locked in a bad state.

Protocol 2: Hardware Intervention

Step A) Read the LED state like a diagnostic signal

• Confirm the indicator shows blue (vacuuming+mopping).
• If you see orange (alert) or quick-flashing red (error), stop and decode the error first. :contentReference[oaicite:7]{index=7}

Engineer’s Note: Do not debug “no water” while the robot runs an error state. The firmware will block outputs during fault handling.

Step B) Validate the Mop Cloth Mount latch signal (the “click test”)

• Remove the VibraRise Mop Cloth Mount.
• Slide it back until you hear/feel a firm click.
• Wiggle-test it: the mount should not float or rattle.

Engineer’s Note: The system treats a sloppy latch as “module missing.” The logic may keep VibraRise vibration but block water as a safety decision.

Step C) Clear the flow path at the tank outlet (control loop can’t overcome a plug)

• Remove the tank and inspect the Water Filter area and outlet.
• Back-flush the outlet using a 20–50 ml syringe (no needle): pull gently, then push clean water through.
• Reinstall the tank and immediately run a small zone mop for 2 minutes.

Engineer’s Note: The dispenser logic assumes flow happens when it commands the valve/pump cycle. Mineral scale or gel residue can block the outlet; the software has no “pressure sensor” feedback to warn you.

Step D) Clean the Ultrasonic Carpet Sensor (false carpet = water gate closes)

• Flip the robot carefully and locate the Carpet Sensor near the underside sensor cluster.
• Wipe the sensor window with a dry microfiber cloth only.

Engineer’s Note: Do not use water on sensor windows. Micro-scratches change signal reflection and can lock the classifier into “carpet detected,” which triggers mop lift and suppresses water output. S7 explicitly relies on ultrasonic carpet recognition behavior. :contentReference[oaicite:8]{index=8}

Step E) Clean Cliff Sensors to prevent a Safety Loop

• Wipe all Cliff Sensors (downward IR windows) with a dry microfiber cloth.
• Move the robot to a bright hard floor (avoid dark shag rugs during testing).

Engineer’s Note: Dust films can spoof a “drop” event. Roborock’s own guidance for cliff sensor errors tells you to wipe the sensors and avoid dark/thick carpet surfaces. :contentReference[oaicite:9]{index=9}

Step F) Check Wheel Encoders indirectly (wheel drag breaks the cleaning state machine)

• Press and rotate each wheel by hand. You should feel smooth resistance, not grinding.
• If the robot throws wheel-related errors, free the wheels before you chase water issues.

Engineer’s Note: A jammed wheel can force the planner into repeated recovery maneuvers. The firmware can deprioritize mopping while it tries to resolve mobility faults (the encoder stream stops matching expected motion). Roborock’s guidance for wheel errors starts with manual wheel rotation checks. :contentReference[oaicite:10]{index=10}

Step G) Inspect the LiDAR Turret health (navigation faults can mask as “mop problems”)

• Power on the robot and visually confirm the LiDAR Turret rotates freely.
• If the robot reports an LDS/LiDAR error, fix that first.

Engineer’s Note: Navigation faults can stop a cleaning run early or keep the robot in a re-localization loop. Roborock’s official Error 1 guidance focuses on LiDAR unit rotation and reboot. :contentReference[oaicite:11]{index=11}

Step H) Clean Charging Contacts (dock state confusion)

• Wipe Charging Contacts on the robot and dock with a dry lint-free cloth.

Engineer’s Note: Corrosion or grime can cause intermittent dock detection. That can flip state transitions (cleaning ↔ docking), which can interrupt water output scheduling. Roborock manuals warn you to avoid wet cleaning around charging contacts. :contentReference[oaicite:12]{index=12}

Error Code Decoding Table

FAQ (Technical Q&A Only)

1) Why does the S7 lift the mop and stop wetting the pad on hard floors?

The Ultrasonic Carpet Recognition pipeline can misclassify a surface when a film of dust covers the sensor window or when lighting/surface texture changes rapidly. The controller then triggers the “carpet policy” and can reduce/stop water output to avoid wet carpet. Clean the Carpet Sensor window and rerun a small zone test. :contentReference[oaicite:18]{index=18}

2) The light shows blue (mopping), but I still get no water. What does that mean logically?

Blue confirms the mode state. You still need a valid flow path and a “safe-to-dispense” sensor set. A clogged Water Filter or tank outlet stops flow, while a false cliff event or carpet detect can gate water off. Treat this as a two-branch diagnosis: state machine ok vs hydraulic path blocked. :contentReference[oaicite:19]{index=19}

3) Does Wi-Fi band choice affect mopping?

Wi-Fi does not directly pump water, but unstable connectivity can prevent you from reliably applying water-flow settings, firmware updates, and map-based no-mop rules. The S7 Wi-Fi spec targets 2.4GHz (802.11 b/g/n); put it on 2.4GHz during diagnostics. :contentReference[oaicite:20]{index=20}

For Roborock’s official guidance when you suspect “no water release,” use their Support Center article as your reference point and compare it with the sensor-logic checks above:
Roborock Support: device doesn’t seem to release any water.

Your Roomba does not “just get noisy.” It enters a repeatable control loop: you hear a sharp click-click-click (often rhythmic), the chassis may twitch, the robot may hesitate on turns, or it may click while docking. That sound usually equals one of two events inside the system:

• Mechanical skip: a gear tooth slips in the Cleaning Head Module Gearbox or a wheel gear train.
• Stall-retry logic: the motherboard detects motor stall (via current draw / speed feedback) and pulses the motor to re-attempt movement—each pulse can sound like a click.

The Logic: Why Your Robot Is Confused

Roomba navigation and cleaning run as a closed-loop system: sensors feed the CPU, the CPU drives motors, and feedback confirms motion. Clicking starts when feedback breaks.

• Wheel Encoder failure loop: The CPU commands both drive motors forward. The Wheel Encoders report speed/rotation. If one encoder reports zero/erratic pulses, the robot thinks it drifts or hits resistance. It then hammers corrective micro-commands (tiny left/right bursts). Those bursts can sound like clicking, and the robot may spin or “shimmy.”
• Brush motor stall-retry loop: The Cleaning Head Module motor loads up (hair, thread, debris, or worn bearings). The CPU detects stall current and issues stop/restart pulses. Each restart can create a click, especially if a gear skips.
• Bumper micro-switch bounce: A sticky Bumper or loose bumper mount causes Bumper Micro-switches to chatter. The robot repeatedly re-plans path as if it keeps tapping obstacles. That can create a “click + jerk + click” pattern.
• False cliff detection: Dirty Cliff Sensors or dark carpet can trigger safety behavior (back up, turn, re-check). The stop/start behavior can expose mechanical clicking that you do not notice during smooth motion.
• Docking contact chatter: If Charging Contacts do not seat cleanly, the robot can rock or re-align in short bursts, producing clicking near the base. Digital Trends specifically calls out clicking tied to charging alignment/contact issues. :contentReference[oaicite:0]{index=0}

Protocol 1: The “Soft” Fix (Software & Reset)

1) Reboot the control stack (not just “power off”)

• Hold CLEAN (or the main power button on your model) until the unit restarts.
• Run a 2-minute test clean on hard floor. Listen for the click pattern: constant rhythm (gear) vs. bursty/pulsed (logic retry).

2) Update firmware, then re-check motor control behavior

• Open the iRobot Home app → check for firmware updates.
• Firmware updates often adjust stall thresholds and recovery routines. A borderline brush motor can click less (or more) depending on the threshold.

3) Kill Wi-Fi noise (connectivity can amplify “weird behavior”)

• Force your phone + robot onto 2.4GHz Wi-Fi during setup if your router splits 2.4/5GHz. Many robot vacuums behave better on 2.4GHz for provisioning and stable cloud commands.
• Disable “band steering” temporarily if your router keeps moving the device.

4) Factory reset only after you isolate hardware vs. software

• Use a factory reset if the robot shows repeated navigation loops after you confirm the drivetrain spins smoothly by hand.
• Do not use a reset as the first move. A stripped gearbox keeps clicking after any reset.

Protocol 2: Hardware Intervention

Tools: Torx T8/T10 (varies), Phillips #1, tweezers, flashlight, microfiber cloth, cotton swabs, 70% isopropyl alcohol, a phone (slow-motion video helps).

Step 1 — Classify the click by “where” and “when”

• Center underside click during cleaning = Cleaning Head Module or Extractor/Brush train.
• Left/right click during turns = Left/Right Wheel Module + Wheel Encoders.
• Front click at obstacles = Bumper + Bumper Micro-switches.
• Dock click only when charging = Charging Contacts chatter or base alignment. :contentReference[oaicite:1]{index=1}

Engineer’s Note: Record 10 seconds of slow-motion video (120–240 fps) under good light. Match each click to a physical event: wheel twitch, brush jerk, bumper bounce. You cannot beat time-correlated evidence.

Step 2 — Validate the Cleaning Head Module gearbox (the #1 “rhythmic click” source)

• Flip the robot over. Remove the Main Brush / Dual Rubber Extractors.
• Spin each brush by hand. Feel for a hard notch that repeats every rotation.
• Inspect Brush End Caps and the brush pocket for a tiny pebble or a snapped plastic tab.
• Reinstall brushes correctly. A mis-seated brush can produce a loud tap/click (Digital Trends highlights misalignment causing clicking/tapping). :contentReference[oaicite:2]{index=2}

Engineer’s Note: If the click frequency stays constant regardless of speed, suspect a missing tooth in the Cleaning Head Module Gearbox. The motor torque spikes at that tooth, the gear slips, and you hear one click per cycle.

Step 3 — Audit the drive wheels and Wheel Encoders (logic-loop clicking)

• Pull each Drive Wheel Module up/down. Confirm smooth spring travel.
• Spin each wheel slowly. Listen for a click and feel for a “step.”
• Remove wrapped hair from the axle area. Hair can drag the wheel and create encoder dropouts.

Engineer’s Note: A dirty or failing Wheel Encoder does not just “make noise.” It breaks the odometry stream, and the CPU reacts with repeated micro-corrections. That reaction can sound like clicking and looks like jittery motion.

Step 4 — Stabilize the bumper signal (micro-switch chatter)

• Press the Bumper on both sides. Demand a crisp click and full rebound.
• Remove debris around the bumper edges. A grain of sand can keep the bumper partially depressed.
• If your model allows, inspect bumper mounting screws for looseness (loose mounting can cause switch bounce).

Engineer’s Note: Bumper chatter forces constant obstacle re-plans. The robot repeatedly stops and re-accelerates. That pattern amplifies any drivetrain click that hides during steady motion.

Step 5 — Clean Cliff Sensors and the optical window (stop/start “safety loop”)

• Wipe all Cliff Sensors with a microfiber cloth.
• Use a cotton swab lightly dampened with isopropyl alcohol for stubborn film.
• Test on a light hard floor first to rule out dark carpet false positives.

Engineer’s Note: Never flood sensors with water. Alcohol + microfiber protects the IR window coating and avoids streaks that create inconsistent IR reflectance.

Step 6 — If your robot uses a LiDAR turret or a Vision Module, isolate top-side clicking

• If you own a LiDAR-based robot (common on Roborock / some Shark AI models), inspect the LiDAR Turret for rubbing and grit at the base.
• If you own a camera-based Roomba (e.g., j-series), inspect the Vision Module window for smudges that can destabilize navigation decisions.
• Confirm the Gyroscope-driven turn behavior: if turns overshoot and correct repeatedly, suspect odometry (encoders) first, then IMU drift second.

Engineer’s Note: Do not use abrasive cloth on LiDAR/Vision lenses. Use microfiber only. Scratches create scatter that the navigation stack misreads as geometry noise.

Step 7 — Docking click: fix charging contact chatter

• Clean the robot’s Charging Contacts and the base contacts with a dry microfiber cloth.
• Check the base position: flat floor, no wobble, no carpet edge under one foot.
• Run a “return to dock” test. If it clicks only at the final inch, you have a seating issue (Digital Trends describes clicking tied to charging positioning/contacts). :contentReference[oaicite:3]{index=3}

Engineer’s Note: Contact chatter looks like this: the robot seats, loses contact, re-drives forward in tiny bursts, repeats. That oscillation produces the click.

Error Code Decoding Table (Light + Beeps + Internal Meaning)

Important: Roomba signaling differs by series. Older 500/600/700/800 series often use beep counts, while newer models use a light ring + app/voice message. The table below targets common beep-coded faults plus a “modern ring” row.

FAQ (Technical Q&A Only)

1) The clicking stays perfectly rhythmic. What does that mean?

Assume gear tooth skip in the Cleaning Head Module Gearbox or a wheel gear train. Rhythmic clicks map to mechanical periodicity. Software loops sound bursty and change frequency as the robot changes speed or direction.

2) The robot clicks only when it turns right (or only left). Why?

Blame feedback asymmetry. One Wheel Encoder likely drops pulses or reads inconsistently under lateral load during turns. The CPU tries to correct heading and issues short motor bursts. That creates click-like pulses and can produce “circle cleaning” behavior.

3) The robot clicks at the dock but runs quiet on the floor. What subsystem should I focus on?

Focus on Charging Contacts and base alignment. Contact chatter makes the robot re-seat in tiny bursts, which can sound like ticking/clicking during charging alignment. :contentReference[oaicite:9]{index=9}

Reference (authority):
Digital Trends – Roomba noisy/clicking behavior and beep-code clues

Your Roborock drives confidently toward a stair edge… and doesn’t brake. The front drops, the drive wheels “whirr” as they lose traction, and you hear that sharp plastic-thud when it hits the lower step. Or you get the opposite glitch: it reaches a dark rug, chirps/announces an error, backs up, spins, and repeats the same “I’m at a cliff” routine like it’s stuck in a safety loop.

The Logic: Why Your Robot is Confused

Your Roborock runs a safety routine that treats a cliff event as “high severity.” The control board samples the Cliff Sensors (IR emitter + IR receiver behind the bottom-facing lens windows). When the sensor sees low IR return, the firmware interprets that as “no floor” and triggers a state change: it cuts forward motion, reverses, and commands a turn to escape.

Two failure modes create your exact behavior:

• False Negative (Dangerous): The robot approaches stairs and doesn’t detect the drop. Common causes: a greasy film on the lens window, micro-scratches that scatter IR, a cracked lens, or a dead IR LED on one sensor that drags the whole sensor array’s confidence down.
• False Positive (Annoying): The robot “sees” a cliff on dark carpet or shag. Dark fibers absorb IR like a drop-off does, so the robot trips its own safety threshold and loops.

Roborock also cross-checks navigation with Wheel Encoders and the IMU (Gyroscope + accelerometer). If an encoder sends inconsistent counts (hair drag, grit in the wheel module), the robot can misjudge motion and overreact to borderline cliff readings. A jammy Bumper Micro-switch can also interrupt route logic and make the robot look “confused,” but it rarely causes true stair falls.

Protocol 1: The “Soft” Fix (Software & Reset)

1) Force a full sensor-state reboot (not just “pause/resume”)

• Dock the robot, then power it off from the unit (not only the app).
• Wait 30 seconds. Power it back on.

Engineer’s Note: A reboot clears the cliff-safety state machine and reloads sensor baselines. If the robot latched a cliff event mid-turn, it can keep biasing away from edges until you restart.

2) Update firmware (or roll it clean with a factory reset if glitches persist)

• Open the Roborock app → check firmware updates → install them.
• If the robot keeps throwing the same cliff behavior after cleaning, run a factory reset so the system rebuilds maps and sensor assumptions from scratch.

Engineer’s Note: A factory reset deletes maps and schedules. It also can revert firmware to the factory version on some models, so you may need to update again afterward.

3) Fix Wi-Fi band problems before you blame “AI navigation”

• Connect the robot to 2.4GHz Wi-Fi (many robots refuse 5GHz).
• Disable VPN on your phone during pairing.

Engineer’s Note: When the app can’t communicate reliably, the robot can miss firmware/config pushes. That makes a real sensor issue look like a “random logic bug.”

Reference (official):
Roborock Error 4 guidance (Cliff Sensors / dark or shag carpet)

Protocol 2: Hardware Intervention

Step 1 — Identify every Cliff Sensor window and inspect it like optics, not plastic

• Flip the robot over on a towel.
• Locate the bottom-facing Cliff Sensor lens windows (usually multiple small dark/clear windows near the perimeter).
• Use a flashlight at a shallow angle. Look for haze, a rainbow smear (cleaner residue), or fine scratches that look like spiderweb lines.

Engineer’s Note: A lens can look “clean” straight-on and still scatter IR. Use side lighting to reveal micro-film.

Step 2 — Clean the lens windows with controlled solvent, not water

• Use a dry microfiber cloth first.
• Dampen a foam swab or microfiber corner with 90%+ isopropyl alcohol and wipe each lens window for 10–15 seconds.
• Buff dry immediately until the plastic looks crystal-clear (no streaks).

Engineer’s Note: Avoid household glass cleaner. Many formulas leave a surfactant film that looks invisible but ruins IR reflectance.

Step 3 — Remove the “pitch bias” that fakes cliff readings (caster + wheel drag)

• Spin each drive wheel by hand. It should feel smooth, not gritty, and it should rebound on the suspension.
• Pull the front caster wheel out (most pop out with a firm tug) and remove wrapped hair. Listen for a dry squeak or feel a sticky notch as it turns.

Engineer’s Note: Cliff logic hates sudden pitch changes. A dragging caster can tip the nose down right at an edge and push cliff readings over the threshold.

Step 4 — Run the quick IR emitter check (find a dead sensor fast)

• Turn the robot on while it sits upside-down (keep hands clear of brush motors).
• Open your phone camera and point it at each Cliff Sensor window. Many IR emitters appear as a faint purple/white glow on phone sensors.
• Compare left-to-right. One “dark” window while others glow strongly often signals a dead IR LED or a failed sensor PCB.

Engineer’s Note: This test gives you a fast “signal present / signal missing” result. It does not measure receiver sensitivity, but it flags obvious emitter failures.

Step 5 — Reseat the Cliff Sensor harness if you suspect intermittent failures

• Power off and remove the robot from the dock.
• Remove the bottom plate screws (use a Phillips #0).
• Locate the Cliff Sensor connector(s) and the ribbon/harness to the mainboard. Unplug and re-plug firmly.

Engineer’s Note: Don’t yank wires. Pull the connector body. A half-seated plug can produce “random” cliff trips that show up only on turns.

Step 6 — Clean the navigation optics that influence approach behavior (LiDAR + Vision Module)

• Wipe the LiDAR Turret top lens with a dry microfiber only.
• Wipe the front Vision Module / front sensors (if your model has them).

Engineer’s Note: Don’t use water on LiDAR optics. Scratches or residue can degrade ranging and make the robot approach edges at the wrong angle or speed.

Error Code Decoding Table

FAQ (Technical Q&A)

1) My robot still falls after I cleaned the Cliff Sensors. What fails next most often?

Suspect a dead IR emitter or receiver on one sensor, or a cracked lens window. Run the phone-camera IR check. If one window stays dark while others glow, replace that Cliff Sensor module or the sensor PCB.

2) My robot refuses a black rug after sensor cleaning. Did I “break” the sensors?

No. Dark fibers absorb IR return and mimic a drop-off to the Cliff Sensors. The robot triggers a safety loop because it trusts that reading more than map guesswork. Use no-go zones for problem rugs, or change the rug.

3) Can I disable Cliff Sensors in the Roborock app?

Roborock treats Cliff Sensors as a core safety system. Don’t disable them for a home with stairs. If you only fight false positives on dark carpet, use controlled workarounds (temporary white paper) in a stair-free area and restore normal operation afterward.

You press CLEAN, the robot drives 10–30 cm, then enters a repeat loop: rotate-in-place → creep forward → rotate again. You may hear one Drive Wheel Module whine louder than the other, or you see the CLEAN light flash red after several spins. This is not “random.” Your Shark has entered a navigation recovery state because one critical input stream (odometry, cliff IR, bumper state, or heading) looks invalid.

The Logic: Why Your Robot is Confused

Your Shark runs a closed-loop navigation stack:

• Inputs: Cliff Sensors (down-facing IR), Wheel Encoders (odometry ticks), Bumper Micro-switches, Gyroscope (yaw rate), and (model-dependent) LiDAR Turret or Vision Module.
• Controller: A state machine that decides “drive straight,” “rotate to reacquire pose,” “escape obstacle,” or “halt for safety.”
• Outputs: Left/right wheel motor PWM commands, suction, brushroll logic.

The circle-spin loop happens when the controller cannot trust its pose estimate:

• Wheel encoder mismatch: The CPU commands forward motion, but the left encoder reports low/zero ticks. The controller “believes” the robot veered, so it keeps rotating to correct a heading error that never resolves.
• False cliff event: A dirty or reflective Cliff Sensor reports “drop detected.” The safety logic forces a back-and-turn maneuver. If the false positive persists, the robot repeats the maneuver and looks like it spins in circles.
• Bumper stuck true: A wedged bumper holds a Bumper Micro-switch closed. The logic stays in obstacle-avoidance mode and rotates to escape an obstacle that does not exist.
• Yaw drift: A biased Gyroscope (or a bad calibration after a hard impact) makes the robot think it rotates when it does not, so it over-corrects and spirals.

Fix the loop by restoring clean, consistent sensor data. Do not chase “cleaning tips.” Validate each input path like an engineer.

Protocol 1: The “Soft” Fix (Software & Reset)

1) Force a navigation stack reboot (not a quick tap)

• Power the robot OFF (use the physical switch if your model has one).
• Wait 15 seconds to drain logic rails.
• Power ON, place it on a flat floor, and wait 60 seconds before starting a run.

Engineer’s Note: The robot recalibrates the Gyroscope during the first idle window. Starting a run immediately after power-on can lock in a bad bias if the robot sits on a slope or gets nudged.

2) Clear the bad map / localization cache

• Open the Shark app and delete the current map (or disable “map-based cleaning” if your model exposes it).
• Run a fresh mapping cycle in bright, even lighting.

Engineer’s Note: A corrupted pose graph makes the robot “reacquire” by rotating repeatedly. A clean map resets the internal reference frame.

3) Confirm Wi-Fi band: lock to 2.4 GHz for stable cloud sync

• Use 2.4 GHz Wi-Fi, not 5 GHz.
• Disable band steering temporarily if your router merges SSIDs.

Engineer’s Note: Some Shark units fail OTA updates on 5 GHz and stay on buggy firmware. Stable 2.4 GHz improves update reliability and reduces “weird loop” behaviors after partial updates.

4) Firmware update, then a controlled restart

• Update the Shark app.
• Apply any firmware update offered.
• Restart the robot again (OFF → 15 seconds → ON).

Engineer’s Note: Do not test hardware until you confirm the robot runs the newest firmware your app offers. Debug one variable at a time.

Reference for official support pathways and model-specific reset/update steps:
SharkClean Support (Official)

Protocol 2: Hardware Intervention

Step 1: Validate Cliff Sensors (IR drop detection)

• Flip the robot over.
• Locate the down-facing Cliff Sensors (small dark windows near the perimeter).
• Wipe each window with a dry microfiber cloth.
• If you see a shiny film, wipe again using a cotton swab lightly dampened with 70% isopropyl alcohol, then dry immediately.

Engineer’s Note: Do not use glass cleaner. It leaves a transparent residue that changes IR reflectivity and generates false drop triggers.

Step 2: Run the “white paper” cliff test (fast truth check)

• Place a sheet of matte white paper under the robot.
• Start a clean cycle and watch the first 10 seconds.
• If spinning stops on white paper but returns on dark glossy floors, you confirmed a Cliff Sensor false positive.

Engineer’s Note: This test isolates floor reflectance as the variable. It saves you from unnecessary wheel motor replacements.

Step 3: Inspect Wheel Encoders by sound, feel, and travel

• Pull each wheel down (they have spring travel) and spin it by hand.
• Match the resistance left vs right. You want the same feel and the same “soft gear” sound.
• Remove hair from the axle gap using tweezers.

Engineer’s Note: A wheel can spin “fine” while the Wheel Encoder reads zero because hair blocks the encoder disk or the optical slot. Your controller then believes the robot pivots and keeps correcting into a spin loop.

Step 4: Purge encoder cavities (clean the data path, not just the tire)

• Use short bursts of compressed air around the wheel hub opening and the Drive Wheel Module seams.
• Rotate the wheel while you blow air to eject fine dust.

Engineer’s Note: Keep the nozzle 15–20 cm away. Excess pressure packs dust deeper and can strip light grease off internal gears.

Step 5: Verify Bumper Micro-switches (logic stuck in “obstacle”)

• Press the front bumper in and release.
• Feel for a crisp click and a clean return.
• Remove debris from the bumper edges and corners.

Engineer’s Note: A stuck Bumper Micro-switch holds the obstacle flag TRUE. The planner then rotates to escape forever.

Step 6: Check the LiDAR Turret / Vision Module window (model-dependent)

• If your Shark has a top LiDAR Turret, wipe the turret lens with microfiber only.
• If your model uses a front Vision Module, wipe the camera window and remove fingerprints.
• Confirm the turret spins freely without scraping noises.

Engineer’s Note: Do not use water on the LiDAR Turret lens. Micro-scratches scatter IR returns and degrade scan matching, which triggers repeated “relocalize by rotating” behavior.

Step 7: Inspect Charging Contacts and battery voltage symptoms

• Wipe the robot’s Charging Contacts and the dock contacts with dry microfiber.
• Look for black oxidation spots or pitting.
• If the robot spins, then suddenly dies, suspect battery sag or poor charge transfer.

Engineer’s Note: Low voltage causes brownouts during motor load spikes. The MCU can reboot mid-run and restart in a safety loop that looks like spinning and failing to commit forward motion.

Step 8: Decide: encoder fault vs motor fault (the replacement decision)

• After cleaning, run a 2-minute test on a bright, matte floor.
• If the robot still spins and always favors one direction, you likely lost encoder feedback on one side or you have a failing wheel motor.
• Replace the affected Drive Wheel Module (not the tire). Encoder sensors typically integrate into the module.

Engineer’s Note: A dead encoder produces a stable, repeatable failure. Random failures point to debris or intermittent connector contact.

Error Code Decoding Table

Important: Shark error signaling varies by series (RV/AV/UR) and firmware. Use this table to interpret the internal meaning of common “spin-loop adjacent” faults, then confirm the exact code in your model manual/app.

FAQ (Technical Q&A)

1) Why does the robot spin more to the right than to the left?

Your controller corrects based on differential wheel feedback. If the left Wheel Encoder reports fewer ticks, the planner “thinks” the left side lags and increases right wheel command or rotates right to compensate. This creates a stable right-spin loop. Fix the encoder data path (hair/dust) or replace the left Drive Wheel Module.

2) The robot spins only on dark carpets. Is this a software bug?

You triggered a sensor physics problem that the software handles as a safety event. Dark or glossy surfaces absorb or scatter the IR signal from Cliff Sensors, so the robot reads “drop.” The CPU runs an escape routine (back-and-turn) repeatedly. Clean the cliff windows, then confirm with the white paper test. Use the tape trick only to prove the diagnosis.

3) I cleaned everything and the loop stays. What part usually fails?

Replace the component that produces hard-zero or intermittent data: the Drive Wheel Module (encoder + motor assembly) on the side the robot favors. If your model uses a LiDAR Turret and you hear scraping or the turret stalls, replace the LiDAR module. Do not shotgun parts; validate one input stream at a time.

“`

You dock the Roomba, it “clicks” into the Home Base / Clean Base, then the light ring turns red and you hear an error tone or a voice prompt that calls out Charging Error 5. Some units repeatedly re-dock like they’re stuck in a loop: drive up, back off, drive up again, fail again.

The Logic: Why Your Robot is Confused

Charging Error 5 does not mean “the battery is empty.” It means the charging controller expects a minimum current flow and it reads a value below its threshold, so it halts charging for safety. iRobot classifies Charging Error 4 and 5 as “electrical current not reaching the robot.” When the current stays low, firmware stops the charge session and reports the fault in the app and/or voice prompt.

Here’s the engineering-level chain reaction:

• Dirty or oxidized Charging Contacts raise resistance.
• The dock delivers voltage, but the robot’s charge circuit sees low current because resistance blocks the path.
• The robot enters a “protect + retry” routine. It may re-seat using Wheel Encoders + Gyroscope to align again, then fails again because the electrical path still looks “open.”
• If docking alignment also looks unstable (robot nudges and backs off), dirt on the dock’s Docking Sensor (IR Window) can break the final alignment step.

Note on sensors: Roomba models typically rely on Cliff Sensors, Bumper Micro-switches, IR docking targets, and (on some models) a camera-based Vision Module for navigation. You will see “LiDAR Turret” on other brands; if your robot has one, keep that lens dry and scratch-free. Roomba’s charging failure here stays electrical-first: contacts + current sense.

Protocol 1: The “Soft” Fix (Software & Reset)

1) Reboot the robot (clear the charge-state latch)

• Take the robot off the dock.
• Press and hold CLEAN (or POWER on some models) for ~20 seconds until you hear a reboot tone and see a white light pattern.
• Wait until the light ring shuts off.

Engineer’s Note: A reboot clears many “stuck state” conditions without deleting maps or schedules. Do this before you touch hardware.

2) Check the app + Wi-Fi band during troubleshooting

• Update the iRobot app if the robot fails to report charging status correctly.
• During setup and diagnostics, put your phone on the correct band: many Roombas require 2.4 GHz (some support 2.4/5 GHz mixed). If the robot cannot see the network, it can also fail to push error telemetry reliably.

Engineer’s Note: Fix the charging current first. Then fix connectivity. People reverse the order and waste an hour chasing Wi-Fi while the dock still delivers near-zero charge current.

3) Factory reset only if the software stack looks corrupted

• Use the app’s factory reset path only after Protocol 2 fails and the robot reports inconsistent charging states.

Engineer’s Note: Factory reset wipes local settings and removes the robot from your account. Use reboot first.

Protocol 2: Hardware Intervention

Step 1) Power-cycle the dock correctly

• Unplug the Home Base / Clean Base.
• Wait 60 seconds.
• Plug it back in.

Engineer’s Note: The dock can latch a fault state. A real power removal resets its internal protection logic.

Step 2) Clean the robot’s Charging Contacts to restore low-resistance metal-to-metal contact

• Flip the robot upside down on a flat surface.
• Use a lightly dampened melamine foam (Magic Eraser) or a lightly dampened cloth.
• Scrub the two metal pads until they show a visible shine.

Engineer’s Note: Do not use sandpaper. Abrasives remove plating, accelerate corrosion, and make the low-current fault return faster.

Step 3) Clean the dock’s Charging Contacts (Home Base + Clean Base)

• Use the same lightly damp melamine foam.
• Wipe until the dock contacts also shine.

Engineer’s Note: The system measures current through the whole path: dock contact → robot contact → charge circuit. Clean both ends or you fix nothing.

Step 4) Clean the dock’s Docking Sensor (IR Window) to stop “re-dock loops”

• Wipe the docking sensor window with a clean, dry microfiber or soft cotton cloth.
• Do not use a Magic Eraser on this window.

Engineer’s Note: The IR window has coatings. A melamine foam can micro-scratch it and degrade docking alignment signals.

Step 5) Inspect for “hard failure” indicators (replace instead of cleaning forever)

• Inspect the metal pads on robot and dock.
• If the contacts look green or copper-colored, treat them as damaged.
• If a contact pin looks stuck down (spring contact does not rebound), treat it as failed hardware.

Engineer’s Note: Damaged plating changes resistance permanently. No cleaning routine will restore stable charge current.

Step 6) Re-seat the battery to force a clean boot and re-check the charging handshake

• Remove and reinstall the battery (or follow your model’s battery access procedure).
• Dock again and watch for stable charge indication.

Engineer’s Note: Battery re-seat forces a hardware reboot and clears some charge-controller latched faults. Also avoid aftermarket batteries; unknown charging errors can appear with non-genuine packs.

Step 7) Confirm dock power on Clean Base models

• If you use a Clean Base, lift the lid and confirm the base shows a red indicator light (power present).

Engineer’s Note: No power at the base equals “low current” forever. Fix wall power/cord seating before you blame the robot.

External reference (manufacturer procedure)

For the official cleaning procedure and the “acceptable materials” rule, link to iRobot support:
How to Clean the Charging Contacts (iRobot)

Error Code Decoding Table

FAQ (Technical Q&A)

1) Why does cleaning contacts fix a “logic” error?

Charging Error 5 triggers when the system measures no/low current. Dirt adds resistance, so the current sensor never sees the expected flow. Cleaning restores a low-resistance path, so firmware exits the fault state and resumes normal charging.

2) Can I use isopropyl alcohol or contact spray?

Use the manufacturer-safe approach: lightly damp melamine foam or a lightly damp cloth on metal contacts only. Avoid spraying liquids into sensor openings. If you run an Auto-Wash/Auto-Fill dock, keep liquids away from sensor ports and IR windows.

3) My robot says “Error 5” with 5 beeps. Is that the same as Charging Error 5?

No. “Error 5” (movement) points to the side wheel module. “Charging Error 5” points to low charge current. Fix the wheel problem with wheel cleaning; fix the charging problem with contact cleaning + reboot + battery re-seat.