Tut (Diskussion | Beiträge) (→Serielle Kommandos) |
(→Serielle Kommandos) |
||
(22 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt) | |||
Zeile 11: | Zeile 11: | ||
** Startet Schußsequenz | ** Startet Schußsequenz | ||
*** Broadcast: "Bereit machen für Schuß". Die Nodes bringen Zeitintensive Aufgaben noch zu Ende, pausieren. Ggf. werden DMX-Lichter und andere langsame Störer abgeschaltet. | *** Broadcast: "Bereit machen für Schuß". Die Nodes bringen Zeitintensive Aufgaben noch zu Ende, pausieren. Ggf. werden DMX-Lichter und andere langsame Störer abgeschaltet. | ||
− | *** Broadcast: "Schuß - Licht-Aus-Phase | + | *** Broadcast: "Schuß" - State machine beginnt: |
− | *** | + | **** State 0: Licht-Aus-Phase. Alle schnellen Lichter werden dunkel geschaltet. |
− | *** | + | **** State 0.5: Schuß - Einmeßphase. Der Dunkelwert der Sensoren wird nun gemessen. |
− | *** | + | **** State 1..8: Schuß - Bit0 - Bit7. Die Pistolen aktivieren den Laser mit bestimmten Code für jedes Bit. Pro Bit fragen die Zielcontroller mit etwas Verzögerung analog alle Kanäle ab und entscheiden ob das Bit 0 oder 1 ist. |
+ | **** State 9: Schuß beendet. Lichter wieder an, Zeitintensive Aufgaben werden weitergeführt. | ||
*** Unicast: Die Zielcontroller werden reihum abgefragt. | *** Unicast: Die Zielcontroller werden reihum abgefragt. | ||
*** Unicast: Ggf. werden Aktionen in den Zielcontrollern und den Pistolen getriggert, die einen Treffer anzeigen. | *** Unicast: Ggf. werden Aktionen in den Zielcontrollern und den Pistolen getriggert, die einen Treffer anzeigen. | ||
*** Unklar ist noch, ob ggf. der gesammte Broadcast-Teil einfach Zeitgesteuert ablaufen wird. | *** Unklar ist noch, ob ggf. der gesammte Broadcast-Teil einfach Zeitgesteuert ablaufen wird. | ||
+ | |||
+ | == Architektur (reverse engeneered...) == | ||
+ | * Lokales Netzwerk (LAN) | ||
+ | ** Master: Raspberry Pi mit Python - Gamemaster, RS485-Bussystem: | ||
+ | *** 2 Laserpistolen | ||
+ | *** Mehrere Targetcontroller | ||
+ | **** 4 Buchsen für jeweils 2 Targets mit jeweils 1 Lichtsensor und 1 Neopixelsteuerleitung | ||
+ | **** 3 3er Pinne mit D3, D9 und D10 für Extras wie Nebelmaschinen-Trigger etc. | ||
+ | *** Targetcontroller NRF24L01 (Master) - funkt zu | ||
+ | **** 2 Virobi-Ufos: Darin Targetcontroller auch mit NRF24L01 (Slave) | ||
+ | ***** Emfängt asyncron 3-4 Lichtsensoren | ||
+ | ***** Sendet per freiem Tx Kommandos zu | ||
+ | ****** Sekundär-Arduino: Steuert Lichtanimationen fürs UFO (Ufo-Steuerpult, 3 Tischtennisbälle, Plexistablicht), steuert Virobi-Motor | ||
+ | *** Targetcontroller für Haupt-Ufo. Steuert Neopixel im Ufo und fragt Lichtsensoren ab, ausserdem UART-Tx zu | ||
+ | **** Bewegungscontroller fürs Haupt-UFO | ||
+ | ** Slave: PC mit Processing: Per TCP-Empfang: Zeigt Punktestand auf Beamer an | ||
+ | ** Slave: PC mit Licht-Software: Aktiviert Lichtszenen, Ansteuerung der Lampen per DMX-Bux | ||
+ | *** 2x RGB Wascher | ||
+ | *** Pinspot für Mondbeleuchtung | ||
+ | *** Punkt-LED Effektlampe an Decke | ||
+ | *** Farb-LED-Effekt am Spielfeldrand | ||
== Hardware == | == Hardware == | ||
− | * Empfänger: SFH 300-3/4 (geht direkt mit dem internen Pull-Up am Analog-Eingang) | + | * Empfänger: SFH 300-3/4 (Langer Pin: Emitter, kurzer Pin: Collektor, geht direkt mit dem internen Pull-Up am Analog-Eingang) |
=== Empfang des Schusses ohne Startreferenz === | === Empfang des Schusses ohne Startreferenz === | ||
* Empfänger liefern analoges Signal, das wird auch analog eingelesen. Je mehr Licht empfangen wird, desto geringer wird der gelesene Analog-Wert | * Empfänger liefern analoges Signal, das wird auch analog eingelesen. Je mehr Licht empfangen wird, desto geringer wird der gelesene Analog-Wert | ||
* Bei Umgebungslicht den Wert für Sensor-Dunkel langsam nachführen | * Bei Umgebungslicht den Wert für Sensor-Dunkel langsam nachführen | ||
+ | ** Problem ggf mit dauer leuchtenden Strahlern | ||
* Ab unterschreiten eines Thresholds kann vom ersten Bit ausgegangen werden (das ist immer 1 = Licht an) | * Ab unterschreiten eines Thresholds kann vom ersten Bit ausgegangen werden (das ist immer 1 = Licht an) | ||
* Irgendwie (TM) die Länge dieses Bits bestimmen - wenn lang genug, bei Flankenwechsel auf Bit-Empfangsmodus gehen | * Irgendwie (TM) die Länge dieses Bits bestimmen - wenn lang genug, bei Flankenwechsel auf Bit-Empfangsmodus gehen | ||
Zeile 33: | Zeile 56: | ||
Broadcast Kommandos: | Broadcast Kommandos: | ||
− | * | + | * scduv Bereit machen für Schuß, Licht-Aus + Schusswaffenselektion, Parameter wählt Waffen aus die schießen werden. Bei Empfang dieses Befehls werden Zeitintensive Tasks angehalten und ggf. Lichter aus gemacht. a,b = Boden Luft Abwehrtürme, u,b = UFO Schüsse. |
* S Schuss abfeuern. Die Waffen senden den Schuss, die Empfänger empfangen den Schuss. Nach 9 Bitzeiten ist alles vorbei, Zeitintensive Tasks dürfen weiterlaufen und Lichter wieder aktiviert werden. | * S Schuss abfeuern. Die Waffen senden den Schuss, die Empfänger empfangen den Schuss. Nach 9 Bitzeiten ist alles vorbei, Zeitintensive Tasks dürfen weiterlaufen und Lichter wieder aktiviert werden. | ||
* I fragt ID des Arduinos ab, an dem Pin 13 mit A0 gebrückt war nach Reset | * I fragt ID des Arduinos ab, an dem Pin 13 mit A0 gebrückt war nach Reset | ||
* I? fragt ID des Arduinos ab, kann bei mehreren zur Bus-Kollision führen | * I? fragt ID des Arduinos ab, kann bei mehreren zur Bus-Kollision führen | ||
* Ixx schreibt ID des Arduinos, an dem Pin 13 mit A0 gebrückt war nach Reset. x steht für das ASCII-Zeichen der ID und muss zweimal hintereinander stehen. | * Ixx schreibt ID des Arduinos, an dem Pin 13 mit A0 gebrückt war nach Reset. x steht für das ASCII-Zeichen der ID und muss zweimal hintereinander stehen. | ||
+ | * fAAAABBBB setzt bitTime = AAAA, bitDelay = BBBB | ||
+ | * Tddddd setzt Threshold auf ddddd, ddddd ausnahmsweise in dezimal hier | ||
Zeile 46: | Zeile 71: | ||
* _tO Target mit Objekt Nummer O detailiert abfragen | * _tO Target mit Objekt Nummer O detailiert abfragen | ||
* _b fragt Buttons und letzten Barrel-Count ab. Rückgabe AABB: AA Bitfeld für Buttons, 1 gedrückt, BB Barrelcount | * _b fragt Buttons und letzten Barrel-Count ab. Rückgabe AABB: AA Bitfeld für Buttons, 1 gedrückt, BB Barrelcount | ||
+ | * _eONN Energielevel übermitteln, O = Objekt Nummer, NN = Energie level 0-100 (Hex 0-64) | ||
+ | * _d Debug-Ausgaben zu LightRx über Bus | ||
+ | * _TAAAA Threshold auf AAAA setzen, AAAA in hex | ||
+ | |||
+ | '''Achtung Fehler:''' Bei Space'n'Lasers 2.0 konnten Rückgabewerte ähnlich aussehen wie Befehle und daher von den anderen Nodes als solche interpretiert werden. Da die Arduinos nur das erste Byte interpretieren, werden alle Rückgabewerte nun mit einem "Space" eingeleitet. | ||
Neopixel Animationen aus FastLEDAnim.cpp _aONNAABBCCDD: | Neopixel Animationen aus FastLEDAnim.cpp _aONNAABBCCDD: | ||
Zeile 61: | Zeile 91: | ||
|- | |- | ||
|| Fire like effect: Lava-Palette flickering || 08 || - || - || - || - | || Fire like effect: Lava-Palette flickering || 08 || - || - || - || - | ||
+ | |- | ||
+ | || wave animation parallel, (destroy animation) || 09 || red || green || blue || speed factor as two digit hex, min = 1 higher is faster | ||
+ | |- | ||
+ | || wave animation seriel sequence RGB || 0A || red || green || blue || speed factor as two digit hex, min = 1 higher is faster | ||
|- | |- | ||
|| UFO animation: useless with one led... || 10 || red || green || blue || - | || UFO animation: useless with one led... || 10 || red || green || blue || - | ||
Zeile 66: | Zeile 100: | ||
|} | |} | ||
+ | Analog Animationen können über den Funktionspointer .pAnalogSet auch an andere Dinge gebunden werden - bei der Waffe wird damit die Laser-Sichtbarkeit gesteuert. | ||
Analog Animationen aus AnalogDAnim.cpp _AONNAABBCCDD: | Analog Animationen aus AnalogDAnim.cpp _AONNAABBCCDD: | ||
Zeile 85: | Zeile 120: | ||
|| Blink || 21 || On PWM value (Off is 0) || On time in 100ms steps || Off time in 100ms steps || Repeat count (0=forever) | || Blink || 21 || On PWM value (Off is 0) || On time in 100ms steps || Off time in 100ms steps || Repeat count (0=forever) | ||
|} | |} | ||
+ | |||
Zeile 110: | Zeile 146: | ||
* Waffe A Hauptschuß: 0x91 [0 1001 0001], Sekundärschuß: 0x95 [0 1001 0101] | * Waffe A Hauptschuß: 0x91 [0 1001 0001], Sekundärschuß: 0x95 [0 1001 0101] | ||
* Waffe B Hauptschuß: 0xA2 [0 1010 0010], Sekundärschuß: 0xA6 [0 1010 0110] | * Waffe B Hauptschuß: 0xA2 [0 1010 0010], Sekundärschuß: 0xA6 [0 1010 0110] | ||
+ | |||
+ | == Funk Nodes mit NRF24L01 == | ||
+ | Generelles: | ||
+ | * Ein Radiomaster als Sender am Bus: ID: "r" | ||
+ | * Über Radio angeschlossene Nodes haben auch eine serielle ID zwischen "0".."4", diese wird auf die Radio-ID's 0..4 gemappt | ||
+ | * Objekt-Nummern werden wie folgt gemappt: | ||
+ | ** 0,4,8,12 -> Radio-Empfänger 0, Objekt-Nummer 0..3 | ||
+ | ** 1,5,9,13 -> Radio-Empfänger 1, Objekt-Nummer 0..3 | ||
+ | ** 2,6,10,14 -> Radio-Empfänger 2, Objekt-Nummer 0..3 | ||
+ | ** 3,7,11,15 -> Radio-Empfänger 3, Objekt-Nummer 0..3 | ||
+ | * 'a' und 'A' werden nach Umschreibung der Objekt-Nummer direkt durchgeleitet (ohne "r") | ||
+ | * Radiomaster hat RadioStatus Statemachine: | ||
+ | ** State 0: Default, sendet wenn was zu senden ist (RadioTxQueueSendReady), startet StartTargetQuery (State 20) | ||
+ | ** State 20: StartTargetQuery: Broadcastet Kommando "S", bei Fehler State 12, sonst State 21 | ||
+ | ** State 21: Empfängt mit Timeout RXELEM-Data Dinger, diese werden "eingeodert" in TargetData[NodeIdx][]. Ausserdem werden die Empfangenen Blöcke in currQueryNum gezählt - wurden 2 empfangen (recht hart codiert), ist es fertig und geht nach State 0 zurück. | ||
+ | ** State 10: Toter Code? Sendet "t" an currQueryNum per writeFast | ||
+ | ** State 11: ? | ||
+ | ** State 12: | ||
+ | |||
+ | |||
+ | Schuss-Synchronisation: | ||
+ | * Slaves senden was zurück beim t und S Kommando, Senden wird dabei Zeitversetzt gestartet | ||
+ | ** Senden beim S Kommando blockt - falscher Zeitpunkt wäre sehr kontraproduktiv. Per Radio wird das "S" aber erst nach Ablauf der Rx-Sequenz im Radiomaster gesendet. | ||
== Game Code == | == Game Code == | ||
Zeile 132: | Zeile 191: | ||
* Video aus Gangansicht | * Video aus Gangansicht | ||
* galvoscanner [https://youtu.be/mtmszeuKH9A] | * galvoscanner [https://youtu.be/mtmszeuKH9A] | ||
+ | |||
+ | == Space'n'Lasers 2.0 Make Rhein Main 2016 == | ||
+ | |||
+ | |||
+ | http://spaceinlasers.guenter-helbig.de | ||
+ | |||
+ | <gallery caption="Space'n'Lasers - Make Rhein Main 2016"> | ||
+ | Datei:DSC 9042.jpeg | ||
+ | Datei:DSC 9052.jpeg | ||
+ | Datei:DSC 9047.jpeg | ||
+ | Datei:DSC 9066.jpeg | ||
+ | Datei:DSC 9126.jpeg | ||
+ | Datei:DSC 9294.jpeg | ||
+ | Datei:DSC 9125.jpeg | ||
+ | Datei:DSC 9172.jpeg | ||
+ | Datei:DSC 9159.jpeg | ||
+ | Datei:DSC 9290.jpeg | ||
+ | Datei:DSC 9300.jpeg | ||
+ | Datei:DSC 9302.jpeg | ||
+ | Datei:DSC 9309.jpeg | ||
+ | Datei:DSC 9306.jpeg | ||
+ | </gallery> | ||
== Make Rhein Main 2016 - Location Bilder == | == Make Rhein Main 2016 - Location Bilder == | ||
Zeile 144: | Zeile 225: | ||
== Ultimedia == | == Ultimedia == | ||
+ | <gallery caption="Space'n'Lasers 2.0 - making of"> | ||
+ | Datei:SpaceInLasersTargetPlatine.jpg|Controler PCB for 8 targets, connected via ethernet cable | ||
+ | </gallery> | ||
<embedvideo service="youtube">https://youtu.be/wvXL9bo-NEc</embedvideo> | <embedvideo service="youtube">https://youtu.be/wvXL9bo-NEc</embedvideo> | ||
Zeile 193: | Zeile 277: | ||
Datei:Space_n_Lasers_-_07.jpg | Datei:Space_n_Lasers_-_07.jpg | ||
</gallery> | </gallery> | ||
+ | |||
+ | == Files == | ||
+ | Most can be found in our Github: https://github.com/hackffm/SpaceNLasers | ||
+ | |||
+ | PCB for Target Controller: [[Datei:SpaceInLasers Target Controller V1.0.zip]] |
Aktuelle Version vom 12. März 2017, 23:00 Uhr
Laser Shooting Gallery
- Von einer festen Position müssen Ziele mit dem Laser getroffen werden
- Typisch bis zu zwei Spieler gleichzeitig = zwei Pistolen
- Ziele bestehen aus einem Fototransistor und werden von einem Neopixel beleuchtet
- Bis zu 8 Ziele werden von einem Arduino verwaltet
- Bussystem mit RS485 zwischen den Ziel-Arduinos, den Pistolen-Arduinos und einem Spielmaster
- Spielmaster ist auch Busmaster, steuert das gesammte Spielgeschehen
- Aktiviert Leuchtziele
- Fragt Pistolentrigger ab
- Startet Schußsequenz
- Broadcast: "Bereit machen für Schuß". Die Nodes bringen Zeitintensive Aufgaben noch zu Ende, pausieren. Ggf. werden DMX-Lichter und andere langsame Störer abgeschaltet.
- Broadcast: "Schuß" - State machine beginnt:
- State 0: Licht-Aus-Phase. Alle schnellen Lichter werden dunkel geschaltet.
- State 0.5: Schuß - Einmeßphase. Der Dunkelwert der Sensoren wird nun gemessen.
- State 1..8: Schuß - Bit0 - Bit7. Die Pistolen aktivieren den Laser mit bestimmten Code für jedes Bit. Pro Bit fragen die Zielcontroller mit etwas Verzögerung analog alle Kanäle ab und entscheiden ob das Bit 0 oder 1 ist.
- State 9: Schuß beendet. Lichter wieder an, Zeitintensive Aufgaben werden weitergeführt.
- Unicast: Die Zielcontroller werden reihum abgefragt.
- Unicast: Ggf. werden Aktionen in den Zielcontrollern und den Pistolen getriggert, die einen Treffer anzeigen.
- Unklar ist noch, ob ggf. der gesammte Broadcast-Teil einfach Zeitgesteuert ablaufen wird.
Architektur (reverse engeneered...)
- Lokales Netzwerk (LAN)
- Master: Raspberry Pi mit Python - Gamemaster, RS485-Bussystem:
- 2 Laserpistolen
- Mehrere Targetcontroller
- 4 Buchsen für jeweils 2 Targets mit jeweils 1 Lichtsensor und 1 Neopixelsteuerleitung
- 3 3er Pinne mit D3, D9 und D10 für Extras wie Nebelmaschinen-Trigger etc.
- Targetcontroller NRF24L01 (Master) - funkt zu
- 2 Virobi-Ufos: Darin Targetcontroller auch mit NRF24L01 (Slave)
- Emfängt asyncron 3-4 Lichtsensoren
- Sendet per freiem Tx Kommandos zu
- Sekundär-Arduino: Steuert Lichtanimationen fürs UFO (Ufo-Steuerpult, 3 Tischtennisbälle, Plexistablicht), steuert Virobi-Motor
- 2 Virobi-Ufos: Darin Targetcontroller auch mit NRF24L01 (Slave)
- Targetcontroller für Haupt-Ufo. Steuert Neopixel im Ufo und fragt Lichtsensoren ab, ausserdem UART-Tx zu
- Bewegungscontroller fürs Haupt-UFO
- Slave: PC mit Processing: Per TCP-Empfang: Zeigt Punktestand auf Beamer an
- Slave: PC mit Licht-Software: Aktiviert Lichtszenen, Ansteuerung der Lampen per DMX-Bux
- 2x RGB Wascher
- Pinspot für Mondbeleuchtung
- Punkt-LED Effektlampe an Decke
- Farb-LED-Effekt am Spielfeldrand
- Master: Raspberry Pi mit Python - Gamemaster, RS485-Bussystem:
Hardware
- Empfänger: SFH 300-3/4 (Langer Pin: Emitter, kurzer Pin: Collektor, geht direkt mit dem internen Pull-Up am Analog-Eingang)
Empfang des Schusses ohne Startreferenz
- Empfänger liefern analoges Signal, das wird auch analog eingelesen. Je mehr Licht empfangen wird, desto geringer wird der gelesene Analog-Wert
- Bei Umgebungslicht den Wert für Sensor-Dunkel langsam nachführen
- Problem ggf mit dauer leuchtenden Strahlern
- Ab unterschreiten eines Thresholds kann vom ersten Bit ausgegangen werden (das ist immer 1 = Licht an)
- Irgendwie (TM) die Länge dieses Bits bestimmen - wenn lang genug, bei Flankenwechsel auf Bit-Empfangsmodus gehen
Serielle Kommandos
Unicast Kommandos ist ein ASCII-Zeichen für die ID, diese ist 0-9 für die Targets und A-C für die Waffen-Controller. Alles andere sind Broadcast-Kommandos. Kommandos nur ASCII, terminiert Retrurn).
Broadcast Kommandos:
- scduv Bereit machen für Schuß, Licht-Aus + Schusswaffenselektion, Parameter wählt Waffen aus die schießen werden. Bei Empfang dieses Befehls werden Zeitintensive Tasks angehalten und ggf. Lichter aus gemacht. a,b = Boden Luft Abwehrtürme, u,b = UFO Schüsse.
- S Schuss abfeuern. Die Waffen senden den Schuss, die Empfänger empfangen den Schuss. Nach 9 Bitzeiten ist alles vorbei, Zeitintensive Tasks dürfen weiterlaufen und Lichter wieder aktiviert werden.
- I fragt ID des Arduinos ab, an dem Pin 13 mit A0 gebrückt war nach Reset
- I? fragt ID des Arduinos ab, kann bei mehreren zur Bus-Kollision führen
- Ixx schreibt ID des Arduinos, an dem Pin 13 mit A0 gebrückt war nach Reset. x steht für das ASCII-Zeichen der ID und muss zweimal hintereinander stehen.
- fAAAABBBB setzt bitTime = AAAA, bitDelay = BBBB
- Tddddd setzt Threshold auf ddddd, ddddd ausnahmsweise in dezimal hier
Unicast Kommandos: _ ersetzen durch Target-Controller-ID
- _aONNAABBCCDD Neopixel Animation starten, O = Objekt Nummer, NN = Animation number (Hex), AABBCCDD (Hex, optionale Argumente)
- _AONNAABBCCDD Analog Animation starten, O = Objekt Nummer, NN = Animation number (Hex), AABBCCDD (Hex, optionale Argumente)
- _tr Targets am Block abrufen, Rückgabe: AABBCCDDEEFFGGHH = data value
- _tO Target mit Objekt Nummer O detailiert abfragen
- _b fragt Buttons und letzten Barrel-Count ab. Rückgabe AABB: AA Bitfeld für Buttons, 1 gedrückt, BB Barrelcount
- _eONN Energielevel übermitteln, O = Objekt Nummer, NN = Energie level 0-100 (Hex 0-64)
- _d Debug-Ausgaben zu LightRx über Bus
- _TAAAA Threshold auf AAAA setzen, AAAA in hex
Achtung Fehler: Bei Space'n'Lasers 2.0 konnten Rückgabewerte ähnlich aussehen wie Befehle und daher von den anderen Nodes als solche interpretiert werden. Da die Arduinos nur das erste Byte interpretieren, werden alle Rückgabewerte nun mit einem "Space" eingeleitet.
Neopixel Animationen aus FastLEDAnim.cpp _aONNAABBCCDD:
Effekt | NN = Animation number | AA | BB | CC | DD |
---|---|---|---|---|---|
Do nothing | 00 | - | - | - | - |
Blank all (set to Black) | 01 | - | - | - | - |
Set to color RGB | 02 | red | green | blue | - |
Shot like effect: White, flickering dim down 255 steps | 07 | Speed in 0.1ms per step, 0 switch to fire effect | - | - | - |
Fire like effect: Lava-Palette flickering | 08 | - | - | - | - |
wave animation parallel, (destroy animation) | 09 | red | green | blue | speed factor as two digit hex, min = 1 higher is faster |
wave animation seriel sequence RGB | 0A | red | green | blue | speed factor as two digit hex, min = 1 higher is faster |
UFO animation: useless with one led... | 10 | red | green | blue | - |
Analog Animationen können über den Funktionspointer .pAnalogSet auch an andere Dinge gebunden werden - bei der Waffe wird damit die Laser-Sichtbarkeit gesteuert.
Analog Animationen aus AnalogDAnim.cpp _AONNAABBCCDD:
Effekt | NN = Animation number | AA | BB | CC | DD |
---|---|---|---|---|---|
Do nothing | 00 | - | - | - | - |
Blank all (set to PWM 0) | 01 | - | - | - | - |
Set PWM directly | 02 | PWM value | - | - | - |
Fade PWM up | 10 | Start value | Stop value | Speed in 0.1ms steps | Repeat count (0=forever) |
Fade PWM down | 11 | Start value | Stop value | Speed in 0.1ms steps | Repeat count (0=forever) |
Flash | 20 | On PWM value (Off is 0) | On time in 10ms steps | Off time in 10ms steps | Repeat count (0=forever) |
Blink | 21 | On PWM value (Off is 0) | On time in 100ms steps | Off time in 100ms steps | Repeat count (0=forever) |
Animationen:
- Gun Shot: Aa00710 (Für Barrel)
- Rumble Shot: AA011FF000401
- Blitz 8x: 4A120FF040408
Virobi UFO Animationen:
- Off: A60000000000
- Motor konfiguration: A500BBCC
BB = Motor speed normal mode 00-FF CC = Motor speed panic mode 00-FF
- Normal Mode: A601RRGGBB00
RR = red [00-FF] GG = green [00-FF] BB = blue [00-FF]
- Panic Mode: A60ARRGGBB00
RR = red [00-FF] GG = green [00-FF] BB = blue [00-FF]
Schuß IDs (1 = Laser On):
- Waffe A Hauptschuß: 0x91 [0 1001 0001], Sekundärschuß: 0x95 [0 1001 0101]
- Waffe B Hauptschuß: 0xA2 [0 1010 0010], Sekundärschuß: 0xA6 [0 1010 0110]
Funk Nodes mit NRF24L01
Generelles:
- Ein Radiomaster als Sender am Bus: ID: "r"
- Über Radio angeschlossene Nodes haben auch eine serielle ID zwischen "0".."4", diese wird auf die Radio-ID's 0..4 gemappt
- Objekt-Nummern werden wie folgt gemappt:
- 0,4,8,12 -> Radio-Empfänger 0, Objekt-Nummer 0..3
- 1,5,9,13 -> Radio-Empfänger 1, Objekt-Nummer 0..3
- 2,6,10,14 -> Radio-Empfänger 2, Objekt-Nummer 0..3
- 3,7,11,15 -> Radio-Empfänger 3, Objekt-Nummer 0..3
- 'a' und 'A' werden nach Umschreibung der Objekt-Nummer direkt durchgeleitet (ohne "r")
- Radiomaster hat RadioStatus Statemachine:
- State 0: Default, sendet wenn was zu senden ist (RadioTxQueueSendReady), startet StartTargetQuery (State 20)
- State 20: StartTargetQuery: Broadcastet Kommando "S", bei Fehler State 12, sonst State 21
- State 21: Empfängt mit Timeout RXELEM-Data Dinger, diese werden "eingeodert" in TargetData[NodeIdx][]. Ausserdem werden die Empfangenen Blöcke in currQueryNum gezählt - wurden 2 empfangen (recht hart codiert), ist es fertig und geht nach State 0 zurück.
- State 10: Toter Code? Sendet "t" an currQueryNum per writeFast
- State 11: ?
- State 12:
Schuss-Synchronisation:
- Slaves senden was zurück beim t und S Kommando, Senden wird dabei Zeitversetzt gestartet
- Senden beim S Kommando blockt - falscher Zeitpunkt wäre sehr kontraproduktiv. Per Radio wird das "S" aber erst nach Ablauf der Rx-Sequenz im Radiomaster gesendet.
Game Code
Spielprinzip
Shooting-Gallery
- Einzeln oder optional zu zweit auf maximale Punktzahl
- Feste Zeitdauer, evtl. Bonus-Zeit schießbar
- Nur leuchtende Ziele können getroffen werden
- Je länger Ziel leuchtet, desto weniger Punkte, Ziel geht erst bei Treffer aus (Option)
- Shotgun nach Barrel-Laden
- Limitierte Feuerrate, ggf. erhöhbar durch drehen am Barrel
Optionitis
- Video aus Gangansicht
- galvoscanner [3]
Space'n'Lasers 2.0 Make Rhein Main 2016
Make Rhein Main 2016 - Location Bilder
Ultimedia
after countless fails ...
... we installed all the cool stuff in the "tunnel"
Files
Most can be found in our Github: https://github.com/hackffm/SpaceNLasers
PCB for Target Controller: Datei:SpaceInLasers Target Controller V1.0.zip