Ich schätze das jedenfalls so ein, dass die Navigation einigen Aufwand mit sich bringt und deshalb einen relativ leistungsfähigen Rechner braucht. Dagegen soll das Fahrzeug wahrscheinlich mit Akku fahren und deshalb einen möglichst geringen Energieverbrauch haben. Da empfiehlt es sich vielleicht, den Roboter mit einem sparsamen µC zu betreiben und per Funk (433 MHz/BLE/WLAN) die Sensordaten, und Fahrbefehle auszutauschen. Die eigentliche Rechenarbeit würde dann ein Pi machen, der Roboter könnte mit einem ESP gesteuert werden. Hätte auch den Vorteil, dass man alle Daten auf dem zentralen Rechner gut visualisieren und die Algorithmen bequem vom Schreibtisch aus entwickeln kann. Wenn dann mal alles läuft, kann man immer noch schauen, ob man die gesamte Logik in einen µC packen kann.

Spannend ist sicher, wie man das System flexibel und ein bisschen lernfähig bekommt. In einer Wohnung verändern sich die meisten Dinge kaum (Wände), einige in engen Grenzen (Türen) und manches ziemlich unerwartet (Sporttasche/Staubsauger/Kinderspielzeug auf dem Boden, rumlaufende Leute). Da muss man sich was einfallen lassen. Spontan hatte ich die Idee, die gesamte Fläche in (mehr oder minder) kleine Felder einzuteilen und jeweils zu speichern, ob das Feld ein Hindernis ist oder befahrbar. Wände könnte man als permanente/feste Hindernisse definieren. Türen als Felder mit variablen Hindernissen, andere Felder könnte man temporär als Hindernis kennzeichen - wenn der Roboter dort vorbei kommt, schaut er nach, ob das Hindernis noch da ist. Ggf. kann er sich merken, dass dort immer mal Hindernisse auftauchen (meine Sporttasche steht meist am gleichen Fleck). Er könnte auch Wahrscheinlichkeiten für Hindernisse speichern. Die Genauigkeit des Systems hängt von der Größe der Felder ab. Wenn man erst mal mit 25x25 cm anfängt (800 Felder für eine 50 qm Wohnung - bei 10 cm sind es schon 5000, bei 5 cm 20000), kann man es später verfeinern, was Speicherbedarf und Rechenaufwand erhöht aber die Genauigkeit verbessert.