Localization drift on soft surfaces: Software issue?
The robot has issues navigating/localizing itself on some soft surfaces. I have a carpet (2.2 x 1.8m) that is 11mm high and it seems that the robot starts to drift (the location where he thinks he is doesn't match to his real-world location) as soon as he starts cleaning it. The localization drift increases over time and after 10 minutes it is roughly 2m large (see attached pic). If I remove the carpet, the robot navigates perfectly - so the problem must lie in it. This behavior is observable on firmware versions 40-41.14 (didn't try earlier versions).
Observing the robot behavior and reading similar treads on this forum I came to believe that the issue is of software and not hardware nature. Namely, the robot obviously uses the position encoders in the wheels (motors) to determine how much it has moved. However, this data is not reliable if the surface is soft (one full spin of the wheel will not move the robot in space for the circumference of the wheel!). The robot could easily correct this noisy information if it would fuse the position encoder data with the data he retrieves from two distance sensors (lasers?!?) and the camera (i.e., revert to visual odometry). If the localization software, which probably does some kind of basic SLAM (simultaneous localization and mapping), was made in a way to rely more on visual odometry and less on the motor encoders in this specific scenario the issue could be resolved (the robot anyways recognizes it is on the carpet-like surface and could adjust to which sensors it "believes more" on the fly).
However, it seems that it chooses to blindly "believe" the motor encoders, which, on large carpet surfaces, can lead to the accumulation of the drift. Even stranger software design decision is that the developers actually opted against the possibility that the robot corrects its positional drift. Once it gets lost once its a game over for him and it just roams around cluelessly. This is highly unusual in navigation robotics and I must say it is an issue that was resolved at least 15-20 years ago in this field of research. Namely, the state of the art approach would be to continuously fuse the data from several sensors (encoders, inertial sensors, cameras, distance sensors - this robot has them all) and perform (or correct) the localization based on these. Each of these sensors is noisy (inaccurate) but combined they are more than capable to correct for the drift that accumulates over time. Therefore, once it drifts away, instead of going around cluelessly and hitting against the walls/furniture "which should not be there" , the robot should engage into active recalibration. It should (re)scan the area (weirdly enough he does this to some extend since it rotates around itself - but it seems that it decides to ignore this data) and compare its features (geometrical or otherwise) with those that are saved in cloud (e.g., the map of the apartment). It seems that the robot indeed realizes that it is lost, however, it tries to navigate back to the charging station by simply following the edges (walls?) in the apartment in a "hope" that it will eventually encounter the charging station. Conversely, the behavior that is currently implemented can be characterized as a suboptimal brute-force-approach (blindly search until you hit it). Moreover, this very rudimentary strategy suggests that the robot actually doesn't compare the features between the cloud and the real-time sensor feed (or does this only in some cases). Actually, maybe it doesn't even store any geometrical or visual landmarks (beyond basic ones) but instead uses the cloud only to store a simple 2D navigation map - its hard to tell exactly.
In conclusion, I hope that my examples were comprehensive enough to understand that the current SLAM implementation is somewhat lagging behind the state of the art approaches. I hope that the developers will resolves these localization issues in the future releases of the FW. I also hope that Electrolux will have more understanding for this issue - AEG Germany didn't bother at all to understand its a software and not a hardware problem (they simply sent me a new device ). Additionally, if the developers find it necessary/helpful, I can send them the debug data of the problematic area with the carpet.