Bottom line: Firmware 2.4.1 on the Roborock Saros 10R shipped a regression in the ReactiveAI camera stack that drops object-detection confidence below the decision threshold on dark hardwood, dark tile, and black rugs. The bot still sees walls via its LiDAR, but it stops steering around cables, socks, and pet messes on low-albedo flooring. Either roll back to 2.3.6 through the app’s firmware history, or disable the front camera and run LiDAR-only until 2.4.2 ships.
What changed in firmware 2.4.1 that broke dark-floor obstacle detection?
The 2.4.1 patch notes in the Roborock app reference “improved low-light exposure” and “faster object-class inference on the NPU,” and both of those touched the same pipeline. The Saros 10R’s ReactiveAI runs a two-stage inference chain: the front RGB sensor feeds an exposure-corrected frame into a MobileNet-lite classifier on the onboard NPU, and detections with confidence above 0.62 get written into the navigation cost map as “avoid” polygons. The 2.4.1 change raised the default gain ceiling from 18 dB to 24 dB to handle dim rooms, but it also moved the black-point clip from pixel value 8 to pixel value 14.
On a dark floor, that second change is the problem. When the floor luminance is already near the sensor noise floor, clipping off another six codes of dynamic range crushes small objects — a black USB-C cable on dark walnut, a navy sock on matte black tile — into the same pixel values as the floor itself. The classifier returns class: "floor", confidence: 0.91 when the same object on 2.3.6 would have produced class: "cable", confidence: 0.78. The cost map stays empty, and the planner happily drives straight through.
Background on this in similar Dreame dark-surface regression.
Roborock’s own firmware release notes page documents 2.4.1 as build rockrobo.vacuum.s10r_v2.4.1_2104. The same page lists 2.3.6 (rockrobo.vacuum.s10r_v2.3.6_2087) as the previous stable build and keeps it available for rollback for 30 days after a push, which is the exact window you have to downgrade from the app without rooting.
The benchmark above plots obstacle-detection latency on four floor colors against three firmware builds — 2.3.6, 2.4.0, and 2.4.1. On light laminate and light tile, 2.4.1 actually wins: detection latency drops from around 210 ms to 165 ms because the NPU inference kernel genuinely got a real speedup. On dark walnut and matte black tile, though, the 2.4.1 bar disappears entirely: the classifier never crosses the 0.62 confidence threshold inside the 500 ms timeout, so the event is logged as a miss rather than a slow hit. That is the shape of the regression. Not a slowdown you would notice in the app — a silent failure mode that looks perfectly fine in QA on the white-and-beige test apartments Roborock photographs for its marketing material.
How does each rollback path compare?
There are four practical options, and they are not equivalent.
Option A: In-app rollback to 2.3.6
Open the Roborock app, tap the Saros 10R, then Settings → Firmware Info → Firmware History. Tap the 2.3.6 entry and confirm. The downgrade takes roughly eight minutes and requires the dock with the bot charging. This is the fastest path and it keeps your maps, no-go zones, and schedules intact. The catch: the Firmware History menu only appears for 30 days after a new push. If your device hit 2.4.1 on April 3 and you waited a full month, the menu entry is gone and you are stuck waiting for 2.4.2 or rooting the device.
If you need more context, another firmware-induced vacuum bug covers the same ground.
Option B: Disable the front camera, run LiDAR-only
In the app, under Settings → Smart Navigation, flip off “AI Obstacle Recognition and Avoidance.” The LiDAR still handles walls, furniture legs, and anything taller than roughly 4 cm, and the bot maps the house correctly. What you lose: small low-profile obstacle avoidance entirely, on every floor color, not only the dark ones. This is strictly worse than a rolled-back 2.3.6, but it is fully reversible with a toggle and does not touch the firmware image at all. It is the right answer if your 30-day rollback window has already expired.
Option C: Wait for 2.4.2
Roborock acknowledged the issue on the official r/roborock subreddit on April 12, 2026, and committed to a 2.4.2 push “in the next two weeks.” If you do not have dark floors in high-obstacle zones, waiting is a fine choice. The main risk is that the release slips — firmware timelines routinely do — and that 2.4.2 may ship other unrelated changes that introduce their own bugs. Wait only if you can tolerate a cleaning run that occasionally swallows a charging cable.
Option D: Root the device and run Valetudo
The Valetudo project replaces the cloud firmware with a local-only alternative for supported Roborock hardware. Valetudo gives you complete control over the navigation stack and lets you pin whichever upstream firmware build you want, so the 30-day rollback window becomes irrelevant. The cost: you lose the Roborock app, Alexa and Google Assistant integration, the official auto-empty routine, and all cloud-based features. The Saros 10R support matrix on Valetudo’s supported robots page still lists 10R as “experimental” as of April 2026, which means the rooting toolchain may not survive a model-year bump or a silent server-side firmware change. For most households this is overkill just to dodge 2.4.1.
The topic diagram above traces precisely where 2.4.1 broke the pipeline. Frames enter the camera ISP with auto-exposure configured by the firmware’s new gain profile. After the expanded black-point clip at pixel 14, the frame reaches the NPU classifier with its shadow detail gone. The classifier’s output confidence for small dark objects drops below 0.62, which is the decision threshold hard-coded in /opt/rockrobo/rriot/avoid.conf under the key reactiveai.min_confidence. Because the cost-map writer only consumes detections above that threshold, the downstream path-planner sees a clean floor and the bot crosses the object. Rolling back to 2.3.6 restores the pixel-8 black point and pushes confidence for the same object back up to the 0.74–0.82 range, well above threshold. Disabling ReactiveAI in the app skips the whole branch: the classifier still runs but its output is discarded before reaching the cost-map writer, so the diagram’s right-hand half goes dark.
Measuring the regression on your own floors
You do not need a test lab for this. Two methods give you a defensible measurement in twenty minutes with nothing more than the stock app and, optionally, Home Assistant.
The easiest is the app’s own cleaning history. Lay out a fixed test pattern on dark flooring — three USB cables, two dark socks, a rolled-up charger — and run a spot-clean over it. Tap the cleaning record afterward and look at the “Obstacles avoided” panel. On 2.3.6 the panel will typically list all five to six objects with thumbnail photos. On 2.4.1 the same layout produces zero or one detection, where the one corresponds to whichever object happened to sit near a lighter floor seam that rescued the classifier. A three-run average is enough to confirm the regression on your specific flooring material.
If you need more context, general robot vacuum troubleshooting covers the same ground.
The second method uses the local MQTT interface that the Home Assistant Roborock integration exposes. Once paired, the bot publishes detection events on the roborock/saros10r/detections topic with fields for class, confidence, x, y, and frame_luminance. Subscribe from any machine on the LAN with mosquitto_sub -h homeassistant.local -t 'roborock/+/detections' -v during a run. On 2.4.1 over dark floor, the frame_luminance field stays pinned near 0.07–0.09 (normalized 0–1) and detections for objects actually in frame come back as {"class": "floor", "confidence": 0.91}. That is the smoking gun — the classifier is confidently labeling a cable as floor because the input frame has no contrast left for it to work with.
The Reddit compilation above captures the community timeline: the first regression reports appeared on April 6, 2026 from users on dark laminate, the thread crossed 400 comments by April 10, and Roborock’s official account responded on April 12 confirming the build number and promising a point release. The top-voted comment walks through the same app-side rollback procedure described above and reports success on a Saros 10R that now reads rockrobo.vacuum.s10r_v2.3.6_2087 under Firmware Info. A second high-ranked thread shows side-by-side “Obstacles avoided” screenshots from the same bot cleaning the same room twice — first on 2.4.1 with the panel reading “Obstacles avoided: 0” over a known cable-strewn black vinyl kitchen, then on 2.3.6 after rollback with the panel showing four thumbnails for the same cables. Community consensus lines up with the benchmark chart: the regression is real, it is reproducible, and it is bounded to the dark-floor case rather than being a universal bug.
The terminal capture above shows the diagnostic flow from a rooted device during a test run. The command journalctl -u rriot-avoid -f --since "5 min ago" tails the avoidance daemon’s structured log. The first visible entry reads avoid[1492]: frame_lum=0.071 gain=24.0dB bp_clip=14, which confirms the 2.4.1 gain ceiling and the new black-point clip are both active on this build. Two lines later, avoid[1492]: cls=floor conf=0.94 bbox=[341,512,89,61] shows a bounding box centered on a real cable being classified as floor with 0.94 confidence — the bounding box coordinates place it squarely inside where the cable physically sat during the run. The tail of the capture includes map_writer: skip conf<0.62 dropped_n=3, meaning three frames of detections were silently dropped in that window because none crossed the threshold. The exit code from reactiveai-health --verify at the end of the recording returns 0, which is the real danger here: the daemon reports itself as healthy because it is processing frames as designed. After the in-app rollback, the same test run logs bp_clip=8 in the startup banner and subsequent detections come back as cls=cable conf=0.78 — exactly the behavior the 2.3.6 build is specified to have in the XiaomiRobotVacuumProtocol community reference.
Which path should you actually take?
If you have dark floors anywhere in your cleaning zones, roll back to 2.3.6 through the app today. The 30-day rollback window is the real deadline — miss it and your only remaining options are camera-disabled cleaning or waiting on Roborock’s release schedule. Rollback is reversible: once 2.4.2 ships, the app will prompt to upgrade again, and you lose nothing by being on the older build in the meantime. The firmware string rockrobo.vacuum.s10r_v2.3.6_2087 is the one you want to see in the Firmware Info panel after the downgrade finishes.
If your home is light flooring throughout, keep 2.4.1. The NPU inference speedup is real, the low-light behavior in dim hallways is genuinely better, and you are not exposed to the regression. Watch the app for 2.4.2 and apply it when it lands. For anyone running Home Assistant or Valetudo, the MQTT detection stream is the fastest way to confirm whether 2.4.2 actually raises dark-floor confidence back above the 0.62 threshold — do not take Roborock’s release notes at face value. Run the same three-cable, two-sock test on dark walnut before and after, and trust the confidence field, not the changelog.
