Richtiges Roborally?

[Orbitalratte]

Das ist allerdings smarter als Monitore & PCs. 
Also, wenn das Kartenproblem gelöst wurde, bleibt noch zwei Probleme, denke ich. Wie die Löcher machen? Kippen die Bots über den Rand und bleiben dann schräg im Loch liegen, bis man sie händisch neu aufstellt?
Wie die Förderbänder? Mechanisch? Dann ist es teuer und kompliziert. Nur aufgemalt und simuliert? Dann müssen die Bots wissen, wann sie auf welchem Feld stehen. Dann braucht es eine richtige Navigation. Position, Ausrichtung, Wegfindung.

die frage ist eher, wie grundsätzlich das spielfeld gestalten.
legen wir einfach einen teppich hin auf dem gefahren wird? wie bekommt man da vernünftige wände, laser, bänder hin? mMn nur softwareseitig... und wie sieht das bitte aus?? aufgemalt und zweidimensional 

es muss auf jeden fall modular sein, sowohl von der größe alsauch von den aufbauten.

was haben wir an aufbauten?
Wände
Bänder
Laserwände
Löcher
Bumper
drehscheiben

die feldgröße richtet sich nach der botgröße, nehmen wir mal feldgröße von 10x10cm an
demnach würden feldsegmente von 5x10 feldern die größe von 1mx0,5m haben. zum transportieren bestimmt nicht verkehrt.
material? ich werf mal spanplatte ein, kann man gut bearbeiten und ist nicht teuer. wenn wir die wände dann anbauen, benötigen sie auch etwas platz in der breite, sagen wir 1cm, (dann kann man noch etwas elektronik reinbasteln). dann werden die grundplatten etwas größer, 1,11m x 0,56m. immernoch kofferraumgröße

[Parinor]

die frage ist eher, wie grundsätzlich das spielfeld gestalten.
legen wir einfach einen teppich hin auf dem gefahren wird? wie bekommt man da vernünftige wände, laser, bänder hin? mMn nur softwareseitig... und wie sieht das bitte aus?? aufgemalt und zweidimensional 

Klar, wenn man sich das bildlich vorstellt, gibt es natürlich Wände, Löcher, Förderbänder, Laser etc. - alles theoretisch machbar und wünschenswert. Aber was können wir in Hardware aufbauen, und was nicht? Wenn wir von allen Feldern letztlich nur die Wände bauen können und alles andere simuliert werden muss, dann sollte man mMn alles simulieren und trotzdem muss es kein reines 2D sein. Ich würde die 'Wandfunktion als Barriere' programmieren, und auf dem Plan mit einer aufgeschraubten Holzleiste die Wand visuell verdeutlichen.
Ich denke, wir müssen uns entscheiden. Machen wir RoboRally mit echten Bots, dann darf der Plan 2D sein und sollte so nah am Original sein, wie möglich. Dann würde ich nur die eigentliche Botsteuerung hardwareseitig aufbauen und die Spielelemente und Regeln simulieren.
Oder machen wir ein eigenes Roboterspiel, daß in einem echten Labyrinth stattfindet, mit Schwerpunkt auf viel eigener Hardware.
Ich wäre für ersteres.
Das Spielfeld würde ich auf mehrer Spanplatten aufkleben, so daß es zum Transport einfach in mehrere größere Teile zerlegt werden kann.

Zu den Reed-Kontakten: Könnte gehen. Was mir vorhin aber auf der Arbeit einfiel, war, daß Karten ja auch für die Zugreihenfolge Zahlen bis 1000 (oder so) haben. Da brauchen wir alleine 10bit für. Das sind viele Kontakte, die gebastelt werden müssen. Ansonsten fiel mir ein, man könnte auch Reflexlichtschranken nehmen und dann die Daten als schwarze und weiße Punkte kodieren.
Oder ganz anders, mit Kamera die originalen Spielkarten erkennen. Wenn die Kamera immer die gleiche Perspektive und das gleiche Licht hat, könnte das auch gehen.

[Parinor]

Ich habe mich gerade ein wenig in die BTM222-Bluetooth-Module eingelesen, und denke, daß darüber gut die Funkkommunikation machbar wäre. Ein Modul kostet etwa 12€. Im Netz gibt es auch viel Dokuzeugz darüber.

Fällt mir gerade so ein, hat jemand Zugang oder Kontakte, um Platinen ätzen zu können? Bei mehreren innerlich identischen Bots macht das Sinn, zumal man dann besser SMD verwenden könnte.
Als Antrieb könnte man den Twin-Motor (Doppelmotor) (Der erste auf der Seite) verwenden, sofern man den irgendwo herbekommt, die angegebene Quelle führt den aktuell nicht.

[Orbitalratte]

der Motor heißt "Tamiya 70097", gibt es http://www.watterott.com/de/Dual-Motor-Getriebebox für n 10er
also gut machbar.

reichweite von blauzahn wäre klasse 2 10m, klasse 3 1m (zu wenig) und klasse 1 100m (zu viel), blauzahn klingt also sehr vielversprechend.
wenn wir nun für jeden rob ein blauzahn modul nehmen, und einen für den SL, warum nicht auch für die Console? würde Kabelsalat sparen. Finden die sich denn ohne weiteres?
Wie ist das mit fremdeinwirkung von anderen geräten, Handys zb?

wenn wir eh blauzahn haben, könnten wir vllt auch ein handy zum karten einlesen benutzen?
ansonsten könnte man auch einfach für jede der 5 phasen den passenden schalter umlegen, wären dann auch 7 schalter x 5 = viele
nachteil dabei wäre der einfache schummelfaktor

[Orbitalratte]

hab ne exeltabelle angefangen, wo wir alle wichtigen daten zusammenfassen können --> dropbox
also infos/datenblätter, kosten, anzahl, alles rein da

[Orbitalratte]

weitrer erstelle ich ein "lastenheft" bzw ein text soll das werden, mit den anforderungen und so, was wir alles realisieren müssen.

alle, die gerne mitmischen möchten, können auch ohne elektrokentnisse mitspielen. zb bei o.g. anforderungsbeschreibung oder wenn es dann später n paar mark sind oder leute mit programmierkünsten... jeder kann sein beitrag leisten. pn mit aktueller email an mir

[Orbitalratte]

und nochwas,

mit was für einem tool habt ihr bislang pläne erstellt?
zwecks austausch und so.

hab ich schonmal erwähnt... alles in die dropbox an dokumenten und informationen, ich kanns nicht oft genug sagen

[Orbitalratte]

ein hab ich noch,

Robbies müssen nicht wissen, ob sie auf einem Band stehen oder Drehscheibe oder Bumper. Wenn der SL das weiß und ggf dann die Befehle zur entsprechenden Bewegung übermittelt müsste das doch reichen?

Löcher ebenso, dann bekommt der Bot die Medlung dass er tot ist und kann dann händisch zu seinem lettzen spawn gefahren werden: Rob, du bist tot. alle warten, bis der spieler sein rob mit einzelbefehlen zurück zum start manövriert hat, danach gehts weiter, Lebenslicht erlidscht.

[Parinor]

reichweite von blauzahn wäre klasse 2 10m, klasse 3 1m (zu wenig) und klasse 1 100m (zu viel), blauzahn klingt also sehr vielversprechend.
wenn wir nun für jeden rob ein blauzahn modul nehmen, und einen für den SL, warum nicht auch für die Console? würde Kabelsalat sparen. Finden die sich denn ohne weiteres?
Wie ist das mit fremdeinwirkung von anderen geräten, Handys zb?

wenn wir eh blauzahn haben, könnten wir vllt auch ein handy zum karten einlesen benutzen?

Erstmal nehmen wir Harald Blauzahn als Datenübermittlung an den Bot. Als Console würde ich vorschlagen, daß wir uns noch garnicht auf Hardware einigen. Wenn wir Funk als Schnittstelle haben, kann man sich später noch überlegen, wie das UI gemacht wird.

"Tamiya 70097"

Dick

hab ne exeltabelle angefangen, wo wir alle wichtigen daten zusammenfassen können

Hab kein Excel, nur OpenOffice. Wenn man aber wenig herumformelt und nur einfache Daten sammelt, sollte das kompatibel bleiben.

weitrer erstelle ich ein "lastenheft" bzw ein text soll das werden, mit den anforderungen und so, was wir alles realisieren müssen.

Gut.

alle, die gerne mitmischen möchten, können auch ohne elektrokentnisse mitspielen.

Das denke ich auch, spätestens beim Umsetzen und Testen der Spielregeln ist Hilfe von Außen möglich. Btw. Ich stelle mir die Robbis (noch) so vor, daß die Innereien alle gleich sind, die äußere Form aber grob ein vergrößertes Modell der Spielfiguren ist. Mir kam da als Schnappsidee spontan Pepakura in den Kopf. Formgebende Künstler müssen keine Elektroniker oder Programmierer sein.

mit was für einem tool habt ihr bislang pläne erstellt?

Für die Schaltpläne E.A.G.L.E., Grafiken und Skizzen mit OpenOffice Draw, Berechnungen mit OOCalc. Text, na .txt eben. Für eine Dokumentation oder viel Text würde ich LaTeX nehmen.

Robbies müssen nicht wissen, ob sie auf einem Band stehen oder Drehscheibe oder Bumper. Wenn der SL das weiß und ggf dann die Befehle zur entsprechenden Bewegung übermittelt müsste das doch reichen?

Löcher ebenso, dann bekommt der Bot die Medlung dass er tot ist und kann dann händisch zu seinem lettzen spawn gefahren werden: Rob, du bist tot. alle warten, bis der spieler sein rob mit einzelbefehlen zurück zum start manövriert hat, danach gehts weiter, Lebenslicht erlidscht.

Grundsätzlich nicht, die Frage ist, wieviel navigiert der Bot und wieviel navigiert der SL für den Bot. Beides hat Vor- und Nachteile. Navigiert der Bot, ist es irgendwie authentischer, er muss aber dann auch viel mehr können. Mal sehen...
Ich würde den Bot aber nicht händisch ferngesteuert aus einem Loch bewegen. Entweder händisch umstellen oder autonom fahren lassen, oder?

[Orbitalratte]

Erstmal nehmen wir Harald Blauzahn als Datenübermittlung an den Bot. Als Console würde ich vorschlagen, daß wir uns noch garnicht auf Hardware einigen. Wenn wir Funk als Schnittstelle haben, kann man sich später noch überlegen, wie das UI gemacht wird.

Konsole ist das Einfachste, ich habe da schon eine Möglichkeit im Kopf... 10x SchadensLED, 3x LebensLED, 1x Taster mit 1x LED für Power Down, 5x LED für Rundenanzeige, 7x Taster mit 7x LED für jede Bewegungsmöglichkeit eine. =34 I/Os
Karten werden ganz normal verteilt und vor sich abgelegt. RundenLED zeigt Runde 1 an, jeder drückt sein Bewegungstaster entsprechend, LED zeigt Status an. Wenn alle Robbies gefahren sind, werden die BEwegungsLEDs gelöscht und Runde2-LED geht an. Für die Priorität hab ich mir folgendes überlegt:
Bewegungstaster betätigt, µC gibt Zufallszahl aus, nur SL bekommt alle mit.
Wenn man ähnlich wie auf den Spielkarten Drehungen mit weniger Prio haben möchte und 3fachvor hoch priorisieren will, kann man das zur not mit Faktor machen, ich finde es aber Spannender, wenn alle die gleiche Chance auf Prio 1 haben können.

Hab kein Excel, nur OpenOffice. Wenn man aber wenig herumformelt und nur einfache Daten sammelt, sollte das kompatibel bleiben. [...] Grafiken und Skizzen mit OpenOffice Draw, Berechnungen mit OOCalc. Text, na .txt eben. Für eine Dokumentation oder viel Text würde ich LaTeX nehmen.

Der Nachfolger von LaTeX und openOffice ist LibreOffice. habe ich, mit dem kann man auch .docx also Microsaft Office 10-Formate lesen.

Das denke ich auch, spätestens beim Umsetzen und Testen der Spielregeln ist Hilfe von Außen möglich. Btw. Ich stelle mir die Robbis (noch) so vor, daß die Innereien alle gleich sind, die äußere Form aber grob ein vergrößertes Modell der Spielfiguren ist. Mir kam da als Schnappsidee spontan Pepakura in den Kopf. Formgebende Künstler müssen keine Elektroniker oder Programmierer sein.

seh ich genau so

Grundsätzlich nicht, die Frage ist, wieviel navigiert der Bot und wieviel navigiert der SL für den Bot. Beides hat Vor- und Nachteile. Navigiert der Bot, ist es irgendwie authentischer, er muss aber dann auch viel mehr können. Mal sehen...
Ich würde den Bot aber nicht händisch ferngesteuert aus einem Loch bewegen. Entweder händisch umstellen oder autonom fahren lassen, oder?

Der SL Navigiert nicht, er gibt nur die Befehle weiter, ob die von der Konsole kommen oder von den Spielregeln ist dabei egal. Der SL muss nur wissen, wo ist der Bot, wo ne Wand, welche Richtung etc um seine Befehle anpassen zu können (z.B. Rob 1 steht im Weg für Rob 2. SL muss an Rob1 befehl der Schiebebewegung geben, danach erst den Nachrückbefehl). Der Rob muss seinen Weg dann selber machen, da hilft alles nix.
Händisch oder Autonom? Autonom sehr viel Aufwand, welchen Weg nimmt er? Wände und Gegner im Weg, was nun?
Von Hand herausholen und zum Spawnpunkt tragen? Wenn ein Feld 2x2m groß ist... keine Arme, kein Käse.
Zurücktuckern lassen über einzelne Befehle? Wenigstens den Spass kann man dem Kacknoob gönnen, der sein Bot schrottet


Wieviele µC können miteinander reden? Hintergrund: Woher weiß der SL, wo eine Mauer ist? zumal wir ja mehrere Module haben? Überfordert den das?
Für ein JA:
Jede Modulplatte kann ein µC bekommen, der über seine Platte genau bescheid weiß. Jedes Modul bekommt eine eindeutige Kennung.
Wände könnte man frei Steckbar machen, spätestens jedoch die Wegpunkte muss man irgendwie definieren...
SL könnte in der Startplatte eingebaut werden. Oder welche räumliche Vorstellung habt ihr von dem SL?

[Parinor]

=34 I/Os

Ups, n bisl viel... das will anders gelöst werden. Ist aber kein Problem.

Karten werden ganz normal verteilt und vor sich abgelegt. RundenLED zeigt Runde 1 an, jeder drückt sein Bewegungstaster entsprechend, LED zeigt Status an. Wenn alle Robbies gefahren sind, werden die BEwegungsLEDs gelöscht und Runde2-LED geht an. Für die Priorität hab ich mir folgendes überlegt:
Bewegungstaster betätigt, µC gibt Zufallszahl aus, nur SL bekommt alle mit.
Wenn man ähnlich wie auf den Spielkarten Drehungen mit weniger Prio haben möchte und 3fachvor hoch priorisieren will, kann man das zur not mit Faktor machen, ich finde es aber Spannender, wenn alle die gleiche Chance auf Prio 1 haben können.

Jo, ist erstmal ne einfache aber vernünftige Lösung, um loszulegen.

Der Nachfolger von LaTeX und openOffice ist LibreOffice. habe ich, mit dem kann man auch .docx also Microsaft Office 10-Formate lesen.

LibreOffice und OpenOffice benutzen das gleiche Dateiformat, weil LibreOffice ein Ableger von OO ist. LaTeX ist aber was völlig anderes. Wie auch immer, passt schon.

 

Der SL Navigiert nicht, er gibt nur die Befehle weiter, ob die von der Konsole kommen oder von den Spielregeln ist dabei egal. Der SL muss nur wissen, wo ist der Bot, wo ne Wand, welche Richtung etc um seine Befehle anpassen zu können (z.B. Rob 1 steht im Weg für Rob 2. SL muss an Rob1 befehl der Schiebebewegung geben, danach erst den Nachrückbefehl). Der Rob muss seinen Weg dann selber machen, da hilft alles nix.
Händisch oder Autonom? Autonom sehr viel Aufwand, welchen Weg nimmt er? Wände und Gegner im Weg, was nun?
Von Hand herausholen und zum Spawnpunkt tragen? Wenn ein Feld 2x2m groß ist... keine Arme, kein Käse.
Zurücktuckern lassen über einzelne Befehle? Wenigstens den Spass kann man dem Kacknoob gönnen, der sein Bot schrottet

Jo, hast Recht

Wieviele µC können miteinander reden? Hintergrund: Woher weiß der SL, wo eine Mauer ist? zumal wir ja mehrere Module haben? Überfordert den das?

Modul = 12x12 Karte? Die Karte müsste virtuell im µC gespeichert werden. Hab's mal überschlagen, 1kB sollte reichen. Sowas ist kein Problem. Via Bluetooth können PAN-Netze aufgebaut werden. Via Kabel können mit dem TWI-Bus auch diverse zusamengeschaltet werden.

Wände könnte man frei Steckbar machen, spätestens jedoch die Wegpunkte muss man irgendwie definieren.

Mit den Originalkarten haben wir genug zu tun. Ich würde sowiso viel im Originallook machen, um einen Wiedererkennungswert zu haben und damit man sich als Brettspieler sofort zurechtfindet.

SL könnte in der Startplatte eingebaut werden. Oder welche räumliche Vorstellung habt ihr von dem SL?

Ist abhängig davon, wie man die Navigation macht. Sollte in einen Schattenbahnhof passen.

---

Kurz zur Navigation ne Idee. Wenn man ein Raster aus Permanentmagneten aufbaut, bekäme man die Ausrichtung doch mit einem Kompassmodul hin, oder?

[Orbitalratte]

Anstelle von Tastern kann man auch Schalter nehmen dahinter parallel ne led zum Eingang setzen schon spart man 8 Ausgänge (power down und bewegubg). Für eine Art zugende ggf noch eine LED "Schalter zurück gestellt ich bin fertig" oder so.
12x12 wird groß,  passt nicht mehr in ein Auto. 12x6 mit Kennungen vllt? Wie viele Karten könnte der mC schaffen?

Kompass: wie ist das wenn der uber eine solche marke fährt? Und wie mit festhalten der robs?
Sonst vllt machbar. Kosten?

[Parinor]

Anstelle von Tastern kann man auch Schalter nehmen dahinter parallel ne led zum Eingang setzen schon spart man 8 Ausgänge (power down und bewegubg). Für eine Art zugende ggf noch eine LED "Schalter zurück gestellt ich bin fertig" oder so.

Mach dir um die I/Os keine Gedanken, ein ADC-Eingang kann problemlos min. 7 Taster einlesen. LEDs kann man auch multiplexen.

12x12 wird groß,  passt nicht mehr in ein Auto. 12x6 mit Kennungen vllt? Wie viele Karten könnte der mC schaffen?

Jo, je kleiner der Bot, umso kleiner ein Feld. Wenn man das Doppelgetriebe als gegeben betrachtet, könnte man evt. eine Botgrundfläche von 8x8 cm anstreben. Dann wäre 10x10cm für ein Feld realistisch.
Bis jetzt glaube ich nicht, daß das Spielbrett aktive Elektronik enhalten muss. Man könnte es stückeln und steckbar konstruieren.

Kompass: wie ist das wenn der uber eine solche marke fährt? Und wie mit festhalten der robs?
Sonst vllt machbar. Kosten?

Vergiss es, war ne Schnapsidee. Mir fällt gerade ein, daß ich bei den Roboterbeschreibungen, die  ein Kopmassmodul enthielten, immer gelesen habe, daß es Probleme gab, wenn die Motoren zu nah dran waren. Es kam immer zu Störungen. Wir können es aber nicht räumlich trennen. Zumal ein homogenes Magnetfeld aus vielen parallelen Magneten auch nicht so machbar ist, wie wir es bräuchten.

Die Maussensorik ist aber nach wie vor im Rennen.

@Käse, kannst Du mir Deine RasiererKupferkopf irgendwie zukommen lassen?

[Käsebällchen]

sure. bin am WE da und komm dann irgendwann vorbei

[Orbitalratte]

Hat der doppelmotor nicht auch ein geber integriert? Das müsste dann reichen

Wegfindung über ein strich folgen doof. Wir haben an den Seiten aber 2! Striche. Was braucht man dafür für ein Sensor bzw 2?  Ggf vorne noch einen zum nächsten Feld erkennen. .. müssen wir nur noch heraus finden wie der sl auch Bescheid weiß.  Ir mit led?