Richtiges Roborally?

[Orbitalratte]

Die Gedanken sind frei... Warum keine echte Roborally?

Insgesamt ist das ein umfangreiches Unterfangen, daher werde ich es erstmal als Spinnerei abtun und meine Gedanken formulieren. Was sich daraus entwickelt ist erstmal egal, Fakt ist, es könnte nicht von einem allein gestemmt werden.

Wer hätte nicht gerne eine Arena, in der 'kleine' Roboter versuchen, nicht total den Weg zu verlieren, nur weil der Kacknoob von Programmierer wieder Links mit dem anderen Links verwexelt hat??

Stellt euch die Roborally Arena nicht so klein vor, vielmehr ist jedes Feld 10x10cm groß, obenauf steht ein Robi, glotzt in eine Richtung und wartet auf seinen Marschbefehl.
Der kacknoob bekommt seine Karten, legt sie innerhalb von Zeit X (vorher einstellbar oder vielleicht Zufällig pro Runde) vor sich auf seine Konsole und fängt an zu schwitzen.
Karten werden ausgelesen und die Infos an die Robies in der Prioreihenfolge weitergegeben und abgefahren. Bänder, Laser, etc alles mit drin.

Was wäre Nötig, damit das klappt?
Robi, Spielbrett, Konsole

Robi mit:
Kleinhirn,
"Laser"-Sender und Empfänger,
Akku,
Fahrwerk,
Kommunikationsmodul

Spielbrett mit Hirn,
Kommunikation mit Robi,
Stromversorgung,
Positionsbestimmung,
Modulare Aufbauten
Konsole Zustandsanzeigen und Auslesen der Manöverkarten


Im Bild erkennt man schonmal eine grobe Skizze:

Oben in Rot der kleine Robi mit Fahrwerk, in Braun die Laser-Sender und Empfänger.
Der Kroße Kasten insgesamt wäre ein Spielfeld-Feld im durchschnitt. Im grauen Bereich ist eine weiße Stelle, die ist frei, quasi ein LOCH im Boden
Grün sind zwei Achsen, die das Blaue Ding unter dem Spielbrett bewegen können.
Lila ist eine Platte, mit der man unter jedem Loch den Gelben kasten anheben kann.

Sinn?
Kommunikation über LED und LDR, sprich Lichtsignale auswerten!
Funk wäre Quatschkäse (Sorry Käse )
In den Kästen Gelb, Blau und Weiß (vom Robi) sind jeweils eine LED und LDR.
Grün fährt nach einer Runde komplett ins Abseits und macht Platz zur Allgemeinen Frage: "Wer ist überhaupt wo??"
Lila fährt hoch und gelb gibt in JEDEM FELD ein Signal für "He, Alle mal Melden". Robi 1 weiß "OK, ich soll mich Melden, gebe also Signal und Schadensbericht" Gelb weiß "Robi 1 ist hier"
Robi 2 macht dasselbe, nur nach einer Zeitverzögerung...
Ergo wissen wir, wo wer ist.
Lila verpisst sich.
Karten werden ausgewertet.
Blau wird durch Grün zum Höchstpriorisiertesten Robi gefahren und sendet dort sein Manöver. Robi macht seine Aktion, egal was dabei rauskommt.
Blau fährt zum nächsten...

Viel Spass beim Auseinandernehmen

[Admiral]

1. Die Idee ist grossartig.
2. Das ist nicht ohne
3. Deine technische Idee verstehe ich leider nicht ganz: Ist das Richtig, dass jedes Feld eine mechanische Vorrichtung hat um die LEDs und Empfänger zu bewegen? Das wäre SEHR teuer, da der Preis (linear) mit der Anzahl der Felder steigt. Ausserdem kenne ich mich nicht so mit Mechanik aus. Je weniger Mechanik, desto einfacher und günstiger wird es erfahrungsgemäss.


Ich denke, ich würde (verständlicherweise) die reine Informatik-Methode nehmen:
1. Robotern eindeutige Marker auf die Köppe kleben.
2. Die Marker mit einer Kamera an der Decke erkennen (das ist nicht ganz ohne, aber machbar). =>
damit hast Du die Lokalisation und Ausrichtung der Roboter, und damit auch die Laser-Geschichte drinn.
3. Damit bleibt nur noch das Problem der Bänder. Die schön real zu bauen, ist nicht ohne, und wieder teuer.
In der Uni würde ich das mit dem folgendem Trick umgehen:

->Roboter mit Omnidirektional-Antrieb verwenden, die sind zwar teuerer und komplizierter, aber sehr weit verbreitet (Robofussball und co.) und sie können sich auch seitlich bewegen. Durch diese seitliche Bewegung würde ich die Bänder simulieren.


Zusammenfassung:

Nötig:
1. Passendes Feld einfach auf dem Boden gemalt
2. Robies mit Omni-Antrieb (https://de.wikipedia.org/wiki/Omnidirektionaler_Antrieb) und Marker auf dem Kopf, die über Funk (WLAN?) Befehle vom Zentral-PC erhalten.
3. Zentral-PC mit Kamera, der die Bildverarbeitung und macht und die Bewegungsbefehle an die Robies sendet.

Schwierige Teile:
1. Bildverarbeitung. Solche Lösungen gibt es, ist aber trotzdem noch einieges zu coden.
2. Funk... nun... WLAN ist immer noch am besten, und alle kenne es. Sicher hat schon mal jemand WLAN an ein Arduino-Board geklebt.
3. Die Robies: Altes problem: sehr teuer kaufen, gegen halb-teuer selberbauen.


Hmmm.... auch nicht so einfach
Müsste man alles noch mal durchdenken.

[Parinor]

Und das so früh am Morgen. 

Die Idee ist geil, ohne Frage.

Die mechanische Seite unter den Spielfeldern habe ich auch noch nicht so geblickt, vertrete aber auch Admirals Meinung, so wenig Mechanik wie möglich. Ich glaube auch, daß es einfacher ist, eine zentrale Steuerung über das Brett zu hängen und die Robbis als kleine "Slaves" rumgurken zu lassen. Als Übertragung finde ich WLAN sehr umfangreich. Bei einem begrenzten Spielfeld würde ich auch eher an IR denken.
Es müßte irgendwie portabel sein, weswegen ein "gemaltes" Spielfeld sicherlich komfortabler ist, als 15 cm Mechanikunterbau.

Karten, wie Laser schießt durch Robbi durch und trifft zweiten, lassen sich eh nur softwareseitig lösen. Die reine Informatiklösung erscheint mir erfolgsversprechender.

[Orbitalratte]

hab ich vielleicht etwas umständlich beschrieben.

Kommunikation
Bei der Kommunikation dachte ich als erstes an Funk. Bei dem Maßstab und der Anzahl an Robbies kann man auch mit Spatzen auf Kanonen werfen.
WLAN? Spatzenwurf
IR? weiß ich nicht.
Wie möglichst einfach machen war die große Frage...
Wenn jeder Robbie sowieso einen µC hat, warum nicht einfach da anknüpfen? LED kostet nix. LDR ebenfalls. Lichtsignale zählen mit Ein/Ausschaltverzögerung? Kein Problem. Einfachste MEthode für mich also: Lichtklacker
Jeder Robbie hat unter sich sowieso sein Fahrwerk und damit er nirgends hängenbleibt eine Schürze. Darunter ist es dunkel also optimal für Klackertechnik.
In ein Schachbrett Löcher zu bohren ist auch kein Problem. Darunter wird es interessant.

ich habe auf der arbeit mit maschinen zu tun, die über mehrere Achsen an ihr Ziel fahren um dort dann ihre Aufgabe zu erledigen (zB. Loch Boren, Niet einsetzen). befehlsweitergabe an Robbies muss nicht gleichzeitig erfolgen, es reicht, sie nacheinander abzuarbeiten. Ergo kann man über ein 2-Achs-System mit einem LED/LDR-Paket alle Felder nacheinander anfahren und Befehle rüberklackern

Positionsbestimmung
kniffliger wird dabei die Positionsbestimmung, damit mein 2-Achs-Klacker auch an der richtigen Stelle den Richtigen Robbi anfahren kann. Dafür habe ich mir folgendes überlegt:
Unten an der Unterseite des Brettes werden einige LEDs angebracht, die ein Whois an alle Löcher senden können. Jeder Robbie bekommt also diese Sondermeldung. Damit wir wissen, wer wo ist, melden sich die Robbies zeitversetzt zurück, schön einer nach dem anderen. Unter jedem Feldloch sitzt ein LDR, jeder solche LDR ist Feldzuordnungsbar. Positionsbestimmung erledigt.
Weiter kann er neue Laserschadensmeldungen ebenfalls weitergeben

Robbiausrichtung:
Wenn wir die Laser nicht Softwaretechnisch abhandeln wollen und Bänder und Co ebenfalls, dann müssen wir nicht wissen, wo vorne ist. Nur der Robbie selber 'weiß' es, da er ja dann seine Manöver abfahren kann, egal was im Weg ist

Kollision/Schieben
Fährt Robbi gegen ein Ziel, gibt es zwei möglichkeiten, Gegner oder Wand.
Wand: Mein Näherungssensor (mech. Schalter oder Kap. Näherungssensor) meldet Kontakt, ich fahre kleines stück zurück über mein Loch und stehe
Gegner: Sensor meldet kontakt, der Andere bekommt ebenfalls seine Meldung. Gegner fährt entsprechend in die entgegengesetzte Richtung, ich folge


habe ich was vergessen?

achja, hallo, was gibt es besseres als Klackertechnik?? (und nein, Postboten können wir so nicht benutzen!)

[Orbitalratte]

Robbi-Fahrwerk und Aufbauten aus Lego?

[Parinor]

ich habe auf der arbeit mit maschinen zu tun, die über mehrere Achsen an ihr Ziel fahren um dort dann ihre Aufgabe zu erledigen (zB. Loch Boren, Niet einsetzen). befehlsweitergabe an Robbies muss nicht gleichzeitig erfolgen, es reicht, sie nacheinander abzuarbeiten. Ergo kann man über ein 2-Achs-System mit einem LED/LDR-Paket alle Felder nacheinander anfahren und Befehle rüberklackern

Das ist sehr umständlich und kann man komplett sparen, wenn man ein Kameramodul nebst Kommunikation drüber hängt.

Wenn jeder Robbie sowieso einen µC hat, warum nicht einfach da anknüpfen? LED kostet nix. LDR ebenfalls. Lichtsignale zählen mit Ein/Ausschaltverzögerung? Kein Problem. Einfachste MEthode für mich also: Lichtklacker

So hätte ich IR-Kommunikation aufgebaut, nur von oben. Alternativ darf es auch gerne Funk sein, aber IR ist mMn kompakter und stromsparender.

Unten an der Unterseite des Brettes werden einige LEDs angebracht, die ein Whois an alle Löcher senden können. Jeder Robbie bekommt also diese Sondermeldung. Damit wir wissen, wer wo ist, melden sich die Robbies zeitversetzt zurück, schön einer nach dem anderen. Unter jedem Feldloch sitzt ein LDR, jeder solche LDR ist Feldzuordnungsbar. Positionsbestimmung erledigt.
Weiter kann er neue Laserschadensmeldungen ebenfalls weitergeben

Zu aufwändig so eine Matrix.

Kollision/Schieben
Fährt Robbi gegen ein Ziel, gibt es zwei möglichkeiten, Gegner oder Wand.
Wand: Mein Näherungssensor (mech. Schalter oder Kap. Näherungssensor) meldet Kontakt, ich fahre kleines stück zurück über mein Loch und stehe

Ich würde das Spielfeld nur auf Papier o.ä. aufbauen und die kompletten Regeln im Rechner machen. Dadurch kann es aufgerollt werden oder auch austauschbar sein. Denk mal drüber nach, wie groß ein Feld sein muss, damit da ein selbstgemachter Robbi draufpasst. Sowas wird groß.

Robbi-Fahrwerk und Aufbauten aus Lego?

Öh, nen Lego-Bot ist wesentlich größer, als wenn man selber lötet. Die ganze Motorisierung wird mit Lego auch teuerer.

Ich glaube Omniwheels, kleine Motoren, µC, IR-Empfänger, Akkupack ist das kleinste machbare. Ggf. noch 3 IR-LEDs auf Kopf, die mit einer Kamera erfasst werden können.

[Admiral]

Robbiausrichtung:
Wenn wir die Laser nicht Softwaretechnisch abhandeln wollen und Bänder und Co ebenfalls, dann müssen wir nicht wissen, wo vorne ist. Nur der Robbie selber 'weiß' es, da er ja dann seine Manöver abfahren kann, egal was im Weg ist

Ich befürchte Du übersiehst, dass der Robbie NICHT WEISS wo er ist. Er führt die Befehle nie so aus wie er soll. Reibung und Fehler in der Regelung führen zu Postions- und vor allem Dreh-Fehlern. Das ist nun mal kein KUKA-Arm für viele K€ sondern ein Robbie für ca. 200€.

Kurz: Du musst die Position immer irgendwie korrigieren, durch Erkennen der Umgebung, oder globales wissen. Oft über eine Kombination von beidem.

Die einfachste Methode den Roboter etwas erkennen zu lassen wäre: Linie folgen. Das ist sehr zuverlässig. Mit bisschen Hirnschmalz müsste er in einem Raster fahren können. Damit könnte er sich vielleicht sogar selbst lokalisieren (durch Zählen von Kreuzungen, die man passiert hat). Aber sicher bin ich mir nicht.
Vielleicht würde eine LED in der Mitte der Kreuzung helfen.

[Parinor]

Hat schon mal jemand mit Maussensoren rumgespielt? Billige optische Mäuse kann man ausschlachten. Dort sind außerdem kleine Radencoder drin.

Was mir gerade noch einfällt, sind WII-Controller. Die erkennen IR-LEDs im Raum und können via Bluetooth Daten zurückgeben. Sowas könnte man als Kamera an die Decke hängen. Immer der Bot, der am Zug ist, schaltet seine IR-LEDs ein, bekommt seine Raumposition und kann nachgeregelt werden.

[Orbitalratte]

waren bisher ja nur meine ideen

lego dachte ich mir ausschließlich für Räder und Aufbauten. Akku, Motor, µC etc kein Lego. An einen Motor müsste man doch ohne weiteres auch ein Zahnrad von Lego montieren können?

Wie wäre es zur positonsbestimmung über 4 Barken an den Ecken und Ultraschall? Parinor? Über zwei Empfänger könnte man doch auch ein "Vorne" rausbekommen?

[Parinor]

lego dachte ich mir ausschließlich für Räder und Aufbauten. Akku, Motor, µC etc kein Lego. An einen Motor müsste man doch ohne weiteres auch ein Zahnrad von Lego montieren können?

'Ohne weiteres' ist garnicht so leicht, direkt alles selberbauen ist bei diesem Projekt afaik einfacher.

Wie wäre es zur positonsbestimmung über 4 Barken an den Ecken und Ultraschall? Parinor? Über zwei Empfänger könnte man doch auch ein "Vorne" rausbekommen?

3 Baken würden theoretisch reichen, aber Genauigkeiten unter einem Zentimeter sind nur mit viel Entwicklungsarbeit zu erzielen. Eine Ausrichtung mit zwei Empfängern zu bestimmen, ist theoretisch machbar, aber sehr schwierig. Da ist ein Spielfeldraster einlesen oder ne Wii-Remote sicherlich leichter zu erreichen.

@Admiral
Hast Du schon mal WLAN-Funktionen im Code verwendet? Ist das schwierig?

---

Kennt jemand irgendwelche Tools, mit denen wir gemeinsame Daten und Dateien online zusammen einsehen und editieren können? Zwecks Entwicklung und Austausch.

[Orbitalratte]

Gemeinsam Datenzugriff?  Kein problem. Tool nennt sich dropbox, habe ich bereits für mein studium um daten mit Kollegen zu tauschen. Kann ich nachher fertig machen und links versenden.

[Orbitalratte]

wer möchte bitte ne aktuelle emailadresse an mich senden

[Parinor]

Jo, funzt.

[Orbitalratte]

alle daten, die ihr in den dropbox-ordner reinzieht könnt ihr auch quasi von überall her abrufen.

[Parinor]

Jo, ist halt ne Cloud. Das schöne ist, daß Dateien nutzerübergreifend editiert werden können. Habe gerade mal n bischen Senf reingepackt.