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.
// SYSTEM ERROR LOG
- ⚠️ Symptom: Robot rotates in place repeatedly (circle-spin loop), often favors one direction.
- 🔍 Primary Suspect: Wheel Encoders reporting asymmetric counts OR Cliff Sensors generating false “drop” triggers.
- 🛠️ Fix Difficulty: Level 2/5 (clean + validate sensors; replace module only if data stays dead).
- ⏱️ Est. Downtime: 15–35 minutes.
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.
Use matte white tape (or a small piece of white paper) to temporarily cover each Cliff Sensor window when the robot spins only on dark carpets. Run a 60-second test. If the spinning stops, you proved a cliff false-positive.Warning: This bypass disables drop protection. Use it only for diagnosis, not daily cleaning.
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.
| Light Pattern | Beep Count | Internal Meaning | Action |
|---|---|---|---|
| CLEAN flashes red rapidly during spins | 0–1 | Safety loop: repeated hazard/escape triggers (often Cliff Sensors or stuck bumper) | Run Protocol 2 Step 1–5; test on matte white floor |
| CLEAN flashes red in a steady repeating cadence | 2–3 | Mobility fault: odometry mismatch / wheel feedback anomaly (Wheel Encoders) | Run Protocol 2 Step 3–4; replace Drive Wheel Module if repeatable |
| All lights blink, robot stops after short spin | 3–5 | Localization failure: poor scan match (LiDAR Turret / Vision Module) or gyro drift | Clean LiDAR/vision window; reboot on level surface; remap |
| Dock/search behavior + short spins near base | 0 | Charge reference unstable (Charging Contacts), low battery under load | Clean contacts; full charge; retry; consider battery replacement if shutdown repeats |
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.
“`
Leave a Reply