Schließlich sieht es besser aus, wenn der Roboter selbst die Farben der einzelnen Steine des Zauberwürfels einscannt, anstelle von ständigem eingeben per Hand. Dafür ist, wie in der Einleitung erwähnt der Farbsensor verbaut.
Dieser liest für jede Farbe den dazugehörigen rot, grün, blau (RGB) Anteil ab. Somit hat Schwarz beispielsweise den RGB Wert 0 0 0.
Jedoch haben wir beim Ausprobieren festgestellt, dass die RGB Werte der Farben stark von den Lichtverhältnissen der einzelnen Orte in einem Raum abhängen. Somit kann Rot an einem Ort den RGB zum Beispiel Wert 139 0 0 und wo anders den RGB Wert 205 55 0 besitzen.
Aus diesem Grund haben wir keine festen Werte für Farben eingegeben, sondern zur Kalibrierung scannen wir jede der 6 Farben mit dem Scanner einmal vor jedem Lösevorgang, um die Farben-Werte zu bestimmen.
Danach haben wir festgestellt, dass der Sensor nicht sonderlich genau ist, weshalb er nicht immer exakt dieselben Werte für eine Farbe sieht, sogar wenn die Lichtverhältnisse gleichbleiben. Also wurde je Farbe ein Bereich definiert (und kein Wert). Alle RGB Werte in einem Bereich waren somit beispielsweise als rot zu interpretieren.
Schließlich kamen wir zum Entschluss, dass Rot und Orange sich zu ähnlich scheinen, weshalb der Sensor die Farben nicht immer unterscheiden konnte. Um dem Problem aus dem Weg zu gehen haben wir die Orangene Seite schwarz angemalt. Somit war der Unterschied erheblicher.
Jedoch bringt es nichts den Roboter Farben erkennen zu lassen, wenn man selber den Sensor per Hand zu jeder der 54 kleinen Flächen führen muss. Das Eintippen wäre in dem Fall schneller und sogar auch genauer…
Aus dem Grund habe ich den Roboter so programmiert, dass er sich selber zu den einzelnen Farben bewegen konnte um diese dann selbstständig einzuscannen.
Der Scanner kann sich jedoch nur um einen bestimmten Winkel nach vorne oder um einen bestimmten Winkel zurückbewegen, weshalb ich auch immer die Plattform drehen musste. Das war sehr herausfordernd, weil ein Stein fast genau die Fläche des Sensors abdeckt, weshalb die Gradzahlen der vor-/zurück Bewegung und der Drehung perfekt auf einander abgestimmt sein mussten. Zum Entwickeln des Quelltextes musste ich die genauen Winkel herausfinden. Also habe ich den Würfel mittig auf der Plattform fixiert, damit dieser nicht verrutscht.
Es war auch zu beachten, dass der Scan immer in der richtigen Reihenfolge vom Array geschieht um die einzelnen Farbwerte dann nacheinander im 54 Stellen langem Array abzuspeichern.
Der Algorithmus zum Einscannen einer Seite sieht wie folgt aus:
Zu Präsentations-/Verständniszwecken ist dieser Code ausgeschrieben. Man kann so gut erkennen, dass 8 der 9 Steine einer Seite eingescannt werden (jeweils ein Paket) und im Array “colors” an der entsprechenden Stelle gespeichert werden. Dabei werden die Steine in der Mitte ausgelassen, weil sie beim vermischen des Würfels ihre Position nicht ändern.
Zum Festlegen der Farbwerte habe ich den Sensor also immer die Mittelsteine der einzelnen Seiten scannen lassen, da die restlichen steine schon vermischt waren.
“ t.backward“ und „t.forward“ beschreiben die Bewegungen des Farbsensors(zum cube und weg vom Cube). “ t.left“/“t.right“ sind die Drehungen der Plattform.
Im Nachhinein kann man den Algorithmus durch eine Laufvariable kürzen, jedoch war dies für mich (wie auch an anderen Stellen im Programm) keine Priorität. Der Vorteil eines ausgeschriebenen Quelltextes war es in dem Fall, dass ich viel schneller schauen konnte an welchen Stellen etwas nicht eingespeichert oder falsch gescannt wurde.
Man kann im Quelltext interessanterweise erkennen, dass der Greifarm eine Bewegung zum Cube mit einer noch größeren Bewegung weg vom Cube ausgleichen muss (Respekt falls es Ihnen aufgefallen ist…). Das liegt da dran, dass der Sensor beim Scannen etwas nach vorne „überhängt“, weshalb es mehr Kraft benötigt ihn zur Anfangsposition zurück zu bringen.
Nach dem einscannen einer Seite wurde der Cube dann zur nächsten Seite gedreht usw.