mrg
11.08.2007, 17:28
Hallo,
ich bin über einen beitrag hier auf den geschmack eines rubik solvers gekommen.
Und hab mir mal grundlegenede gedanken gemacht.
Weit mehr kopfzerbrechen als die mechanik macht mir momentan die erkennung der einzelnen farben.
Der Solver sollte ohne PC arbeiten können,also fällt aufgrund der komplexität ein scan mittles kamera aus.
Die methode mit dem LDR und den drei farbleds könnte funktionieren,nur hab ich damit auch ein problem.
Und zwar die geschwindigkeit:
Aus anderen beiträgen hab ich erfahren,daß man damit pro farbläche mehr als eine sekunde braucht.
Aus platzmangel könnte ich bloß einen solchen sensor bauen und müßte diesen dann mittels linearführungen über jede fläche positionieren.
Wielang eine positionierung dauert kann ich noch nicht so wirklich sagen.
Aber so daumen mal pi ohne bewegung gerechnet,bei 1 sekunde scanzeit pro farbe, würde ich 9 sekunden für eine seite des würfels benötigen.
Das ganze mal 6 gibt 54 sekunden für den ganzen würfel.
optimieren kann ich das höchstens durch die tatsache,daß sich aus einer farbe aus der mitte immer die gegenüberliegende farbe ergibt.
Das bedeutet ich kann ganze 3 sekunden sparen.
Damit bin ich auf 51 sec. ohne positionierung des farbscanners und ohne drehung des würfels.
Das is mir zu lahm.
Alternativ käme noch der TCS 230 in frage.
Ich hab mich in die richtung noch nicht beschäftigt,also würd mich interessieren,obs da auch noch andere,billigere varianten gibt.
dann würd ich damit ein array aus eben 3 x 3 dieser sensoren bauen.
dann brauch ich den würfel nur noch ein paar mal zu drehen,und schon kann ich meinen AVR rechnen lassen.
Andere Beiträge dazu hab ich wie gesagt ein paar gefunden,aber daraus geht nix sinnvolles hervor.
Und google liefert mir auch nicht das was ich mir vorstelle.
Wär nett wenn jemand dazu was weiß.
MfG,
--> Mr.G.
ich bin über einen beitrag hier auf den geschmack eines rubik solvers gekommen.
Und hab mir mal grundlegenede gedanken gemacht.
Weit mehr kopfzerbrechen als die mechanik macht mir momentan die erkennung der einzelnen farben.
Der Solver sollte ohne PC arbeiten können,also fällt aufgrund der komplexität ein scan mittles kamera aus.
Die methode mit dem LDR und den drei farbleds könnte funktionieren,nur hab ich damit auch ein problem.
Und zwar die geschwindigkeit:
Aus anderen beiträgen hab ich erfahren,daß man damit pro farbläche mehr als eine sekunde braucht.
Aus platzmangel könnte ich bloß einen solchen sensor bauen und müßte diesen dann mittels linearführungen über jede fläche positionieren.
Wielang eine positionierung dauert kann ich noch nicht so wirklich sagen.
Aber so daumen mal pi ohne bewegung gerechnet,bei 1 sekunde scanzeit pro farbe, würde ich 9 sekunden für eine seite des würfels benötigen.
Das ganze mal 6 gibt 54 sekunden für den ganzen würfel.
optimieren kann ich das höchstens durch die tatsache,daß sich aus einer farbe aus der mitte immer die gegenüberliegende farbe ergibt.
Das bedeutet ich kann ganze 3 sekunden sparen.
Damit bin ich auf 51 sec. ohne positionierung des farbscanners und ohne drehung des würfels.
Das is mir zu lahm.
Alternativ käme noch der TCS 230 in frage.
Ich hab mich in die richtung noch nicht beschäftigt,also würd mich interessieren,obs da auch noch andere,billigere varianten gibt.
dann würd ich damit ein array aus eben 3 x 3 dieser sensoren bauen.
dann brauch ich den würfel nur noch ein paar mal zu drehen,und schon kann ich meinen AVR rechnen lassen.
Andere Beiträge dazu hab ich wie gesagt ein paar gefunden,aber daraus geht nix sinnvolles hervor.
Und google liefert mir auch nicht das was ich mir vorstelle.
Wär nett wenn jemand dazu was weiß.
MfG,
--> Mr.G.