Valkon
19.03.2017, 11:53

Editiert von
Valkon
19.03.2017, 12:10

+63Game Of Thrones - Collab (Lok24/Valkon) - The Red Keep - Powerd by EV3

Guten Morgen LLL,

die Fantasy Saga des amerikanischen Autors George R.R. Martin "Das Lied von Eis und Feuer - A Song Of Ice And Fire" und die darauf basierende, laufende Serienverfilmung "https://de.wikipedia.org/wiki/Game_of_Thrones" spielt in einer fiktiven Welt, deren Hauptschauplatz der Kontinent Westeros ist.
Die Hauptstadt von Westeros heißt Königsmund. Der rote Bergfried (The Red Keep), im Süd-Osten von Königsmund gelegen, ist die Residenz der gegenwärtigen Königin Cersei Lennister, der Hauptsitz des Reiches "Die sieben Königslande" und beherbergt den Eisernen Thron.

Eine kurze Vorgeschichte: Zu diesem MOC hat mich das einschlägige Intro aus der Serienverfilmung inspiriert. Schon länger geisterte die Idee in meinem Kopf herum. Ausschlaggebend für diese Umsetzung des "Der rote, motorisierte Bergfried" war ein Treffen auf der LEGO® Fanwelt mit Lok24. Nach einem informativen Gespräch war klar: Das bekommen wir nur zusammen hin. Die Rollenteilung war schnell klar:
Lok24 entwickelt die Technik/Programmierung. Ich baue letztendlich den Bergfried bei mir zuhause.

Der Umfang an Bauteilen, Zeit und Kosten war nicht abzusehen und hat auch mich am Ende überrascht.

Der Bergfried in Zahlen:

-125.000 Teile (z.B.: 18.000 2x4 Bricks, 9.000 1x2 plates in dark orange)
-4 Stück EV3
-16 Motoren
-16 Sensoren
-24m NXT Kabel
-Grundfläche 12.288 Noppen
-Höhe 1,35 m
-Gewicht 65 Kg
-Bauzeit ca. 800h

Um dieses MOC vollständig zu verstehen, ist es nötig, einen Blick auf das Video zu riskieren:

(Information: bis Minute 1:45 Der rote Bergfried in Bewegung, bis Minute 3:07 Kitbashes, bis Minute 4:46 Detailfotos, bis zum Ende/Minute 6.30 Entstehungsgeschichte in Bildern.)



Fotos (mehr Fotos sind im Video oder bei Facebook zu sehen):

[image]


[image]


[image]


[image]


[image]


^^MdM-Bild

[image]


[image]


[image]


[image]


[image]


[image]


[image]


[image]


[image]


Kitbashes und weitere kleine MOCs:

[image]



Lok24 wird (darauf freue ich mich schon sehr) einen eigenen Beitrag zur Entstehung der Technik und der Programmierung eröffnen.

Ich möchte mich bei Werner für die tolle Zusammenarbeit bedanken: Ohne Dich hätte ich dieses MOC nicht realisieren können!
Trotz der Entfernung (Werner und ich haben nur per Email und Telefon kommunizieren können) konnten wir dieses Projekt zu einem erfreulichen Ende führen.

Über Kommentare freuen wir uns beide! :-)

Greetz,
Valkon/Marc & Lok24

The Red Keep wird auf folgenden Ausstellungen zu sehen sein:
ABSolut Steinchen 2017 (noch nicht angemeldet)
Zusammengebaut 2017 (angemeldet)
Comic Con Stuttgart 2018 (geplant)


DER MODERNE AFOL VON HEUTE ZEIGT MIT STOLZ SEINE NOPPEN.


Lok24
19.03.2017, 13:06

Als Antwort auf den Beitrag von Valkon

Editiert von
Lok24
19.03.2017, 13:56

Re: The Red Keep - Making of - Technik

Hallo zusammen,

Während Marc sich um Gestaltung und Bau kümmerte, wollte ich die Planung für die zu verbauende Technik übernehmen.

Es waren drei Aufgaben zu meistern:
- Antrieb der Türme
- Antrieb des Burggebäudes
- Antrieb der Drehscheibe im Untergrund

Für die Türme waren mir wichtig
- ruckfreies Fahren
- minimales Schwanken der Türme

Für den Untergrund galt es, die Kraft der Motoren zu übertragen.

Erste Ideen

Für das Heben und Senken der Türme gab es verschiedene Ideen:
Scherenantrieb, Seilzug oder Getriebe.
Versuche mit Scherenantrieb waren wenig ermutigend. Das Ganze hat wegen der vielen Gelenke überall zu viel Spiel, und die Kraft ist nicht linear, sie ist am Anfang sehr groß und später klein, entsprechend ist auch der vom Turm gefahrene Weg erst klein, dann größer.

Seilantrieb hat sich auch nicht bewährt, ich habe ein halbes Dutzend Schnüre probiert, der Effekt war immer gleich: Das Seil dehnt sich aufgrund der großen Kräfte, dann zieht es sich wieder zusammen. Das führt zu einem deutlichsichtbaren Ruckeln der Bewegung.

Also blieb nur ein Direktantrieb über Getriebe, das hat auch den Vorteil, dass der zurückgelegte Weg einen direkten Zusammenhang mit der Anzahl der Motorumdrehungen hat.

Hier ein erster Entwurf:

[image]



Und hier ein kleines Video dazu (31 sec)



Die Türme

Da zu diesem Zeitpunkt die Gesamtplanung des Gebäudes noch nicht ganz fertig war, sollten die Turmantriebe möglichst kompakt sein, um sie auch nebeneinander anordnen zu können.

Ferner wäre ein dreiseitiges Gerüst ideal, um es möglichst nahe an das Burggebäude heranrücken zu können.

[image]



Daraus ergab sich ein modulares Gerüst mit einer Höhe von fünf Bricks, das sich beliebig nach oben skalieren lässt. Durch die verbauten Lochbalken können die Liftarms zur Versteifung überlappend auch beliebig weiter nach oben geführt werden.

[image]



Das Gerüst hat mehrere Funktionen:
- zwei Reihen Zahnstangen für den Antrieb
- zwei Nuten für die Führung des Antriebsmoduls
- Eine Farbleiste für eine Farbsensor zur Positionsbestimmung


Der Antrieb

Er wurde so konstruiert, dass er fast ganz in dem Turmgerüst verschwindet. Ein EV3-Large-Motor treibt ein 12er Zahnrad, von dort geht es auf ein 36er, das die Achse mit den beiden außen liegenden 8er Zahnrädern für den Antrieb auf die Zahnstangen am Gerüst.
Benötigt würde die Untersetzung nicht, aber dadurch kann der Motor besser unter dem Turm verschwinden, und außerdem liegt die Turm-Last nicht auf der Motorwelle.

Die größten Probleme waren hier die Durchbiegung und Torsion der Kunststoffachsen.

Führung und Stabilität

Das Bild zeigt das Konstruktionsprinzip.

[image]


Blau dargestellt sind das Antriebszahnrad und die Zahnstange.
Weiter die Technic, Plate 1 x 5 with Smooth Ends. Diese sind geringfügig breiter als die Liftarms und bieten so eine exakte Führung, dank der abgerundeten Enden kann nichts hängen. Dasselbe gilt für die bei Achsen, die die Seitenführung des Käfigs übernehmen, auch sie sind an den Enden herstellerseits(!) bereits abgerundet.

Der Käfig läuft fast spielfrei und ruckfrei in dem Turm.

Ein Problem ist die Führung des im Freien laufenden Turms.
Beim ersten Entwurf gab es noch ein nach unten führende Stange. Aber das braucht einen Sockel von 2x Turmlänge, um ihn zu verstecken und wurde deswegen verworfen.

Ein passendes Gehäuse (also 6x8 innen für einen 8er Turm) funktionierte gar nicht, weil die Steine aufgrund der Toleranzen aneinander hängenbleiben und ruckeln.

Die Lösung liegt im Telefonhörer 6190: keine Ecken, keine Grate, nichts. Somit sind oben am Turm mehrere dieser Hörer angebracht, um den Turm in Position zu halten.

[image]



Hier ein Testlauf ( 56 sec):



Somit konnte Marc die Serienproduktion der Türme beginnen.

Das Mittelschiff

Da die Türme möglichst nah an die eigentliche Burg heranrücken sollten war hier ein außen liegender Antrieb nicht möglich. Daher wurden zwei (wegen des zu erwartenden hohen Gewichts der Burg) Motoren innerhalb des Bauwerks angeordnet. Diese heben einen massiven Rahmen, auf dem die Burg steht.

Hier die Konstruktion des Rahmens, der nachher zum Viereck ausgebaut sein wird

[image]



und ein Modell des geplanten Grundrisses mit den beiden Turmträgern und aufgesetztem Rahmen

[image]




Die Basis

Das gesamte Bauwerk sollte drehbar sein. Geplant wurde mit einer Last von ca. 5kg.
Eigentlich war mir klar, dass das nicht mit einem Schienenantrieb zu machen ist, da die Reibung wohl kaum ausreichen würde.

Somit kamen Gummireifen zur Anwendung, hier der erste Entwurf mit weichen Reifen

[image]



Ursprünglich war ein Dreieck gedacht, da drei Punkte immer plan aufliegen, hier der Prototyp

[image]


In der realen Version wurde dann doch ein massives Kreuz aus vier Achsen gebaut.

Um die Eisenbahnfahrwerke, die der Führung dienen, nicht entgleisen zu lassen werden sie durch Federn auf die Gleise gedrückt.

[image]



Hier der komplette Rahmen mit Stützrad

[image]


Auch hier dienen die Zahnräder nicht zur Übersetzung, sondern dazu, keine senkrechte Last auf die Motorwelle zu bringen.

Im Video (62 sec) schleppt ein Motor ca. 5 kg



Der 50cm hohe Turm steht nur einfach auf der Kiste, ohne jede Befestigung.

Für die Qualität der Videos muss ich mich natürlich entschuldigen, aber sie waren ja ursprünglich nicht dazu gedacht, der Öffentlichkeit gezeigt zu werden sondern um schnell und einfach Ideen mit Marc auszutauschen. Trotzdem glaube ich sie habe einen gewissen Unterhaltungswert.

Ich hoffe die Einblicke ins „Labor“ waren für den einen oder anderen unterhaltsam und informativ.

An dieser Stelle ganz herzlichen Dank an Marc für die Idee, die tolle Umsetzung , sein Vertrauen in mein Gebastel und seine Geduld, meine Ideen einzubauen. Es war eine tolle Zusammenarbeit, ich freue mich auf ein Wiedersehen in St. Augustin!

Grüße

Werner



Lok24
19.03.2017, 13:13

Als Antwort auf den Beitrag von Valkon

Editiert von
Lok24
19.03.2017, 13:15

Re: The Red Keep - Making of - Programmierung

Hallo zusammen,

hier für die Interessierten noch ein paar Infos zur Programmierung.

Die Anforderungen waren zunächst:

1-2 Motoren für die Burg
1-2 Motoren zum Drehen
6 Motoren für die Türme

Daraus folgten mindesten drei EV3-Bricks.
Am Ende wurden es vier.

Mit der Standard-Mindstorms-Software labVIEW kann man zwar mehre Bricks betreiben (Daisy-Chaining) als auch Prozesse parallelisieren, aber das Synchronisieren ist nicht ganz einfach.
Beispiel: ein Motor läuft 5 sec, einer bis ein Sensor auslöst, erst wenn beide stehen soll das Programm weiter arbeiten. Das ist in labVIEW nicht trivial.


LeJOS

Als Alternative wurde LeJOS gewählt, es unterstützt fast alle Funktionen des EV3 , programmiert wird in JAVA. Es baut auf den JAVA-Development-Kits von Oracle auf.
Als Programmiertool steht unentgeltlich Eclipse zur Verfügung.

LeJOS liefert ein Tool mit, mit dem eine micro-SD-Card erstellt wird.
Wenn diese in den EV3 gesteckt wird, bootet der Brick hiervon das LeJOS. Das Original Mindstorms-System bleibt unbeeinflusst.


Systemarchitektur

Die Kommunikation und das Laden des Programms erfolgt vom PC aus via WiFi (bei uns über ein alte Telekom-Router) in einen Brick. Hierzu bekommt ein Brick ein WiFi-Dongle im USB-Slot.
Dieser und alle anderen bilden mit den eingebauten BT-Modulen ein PAN (Private Area Network)

[image]



Zusammenspiel der Bricks

LeJOS bietet die Möglichkeit, von einem Brick auf Motoren und Sensoren der anderen zuzugreifen. Erste Tests und eine Diskussion mit dem Entwickler brachten mich zu der Erkenntnis, dass die Verzögerungen durch die Kommunikation von LeJOS innerhalb des PAN zu Verzögerungen führen , die ich nicht hinnehmen wollte.

Daher wurde folgendes Konzept umgesetzt:

Der Brick mit dem WiFI-Dongle ist der Master, alle anderen sind Slaves.
Das immergleiche(!) Programm wird in den Master geladen und lädt sich von hier aus selber auf alle anderen Bricks und startet sich dort.

(Für die programmierinteressierte: das Programm hat eine Liste aller Bricks, der erste Eintrag ist der Name des Master; im Programm gibt es Blöcke if (brickName == Master), dadurch laufen die mal hier mal da).

Um untereinander kommunizieren zu können laufen im Programm (selbstprogrammierte ) Threads (also Hintergrundprozesse unabhängig vom eigentlichen Programm) als Clients und Server, der Master kann jedem Brick Befehle schicken, jeder Client kann dem Master Meldungen schicken.

Beispiele :
Master an alle Bricks: Sende Batteriespannung
Slave-1 an Master: 7,5 V
Slave-2 an Master: 5,8 V
Master an alle Bricks: STOP Batterie Slave-2 LOW

Master an Brick-2: Bewege Turm2
Slave-2 an Master: Turm2 MOVING
Slave-2 an Master: Turm2 STOP

Master an Brick-1: Bewege Turm4
Slave-1 an Master: REJECTED Turm4 ALREADY MOVING

Motoren und Sensoren

Die Motoren und zugehörige Sensoren müssen immer am selben Brick angeschlossen sein.
Sie bilden eine „Unit“ (dazu unten mehr) , die auch als Hintergrund-Task läuft, also bei vier Motoren z.B. vier Tasks auf einem Brick.
Das bedeutet, dass die Auslösung des Sensors unmittelbar den Motor stoppt, erst dann wir eine Zustandsmeldung an den Master geschickt.


Steuerung des MOC

Das Programm hat keinerlei Informationen über irgendein Modell.
Gesteuert wird alles über 3 Text-Dateien.

ini.txt
allgemeine Definitionen, speziell die Namen aller Bricks

EV3 brick-1,brick-2,test,GELB
BAT 6.2


port.txt
Hier werden die „Units“ definiert, also die Beziehung zwischen Motoren, Ports am Brick und Sensoren.

So wird hier am Brick-1 eine Unit aus zwei großen Motoren an A und B und einem Color-Sensor an Port S3 definiert, die nachher als „Turm1“ angesprochen werden kann:

B Brick-1
-------------------------------------
start Turm1 , 100, 1 , FLOAT

define A , L
define B , L
define S3 , C
end

Und eine Unit „Kuppel1“ und „Kuppel2“ ohne Sensor an Brick-2

B Brick-2
-------------------------------------
start Kuppel2, 100, 1 , STOP
define A , M
end
-------------------------------------
start Kuppel2, 100, 1 , FLOAT
define B, M
end


move.txt
Diese Datei steuert den kompletten Bewegungsablauf.
Hier mal ein kleines Beispiel

Loop
move Turm1,0,R,DOWN,10,200
move Turm2,3,R,LEFT,10,200
Wait Turm1, Turm2
Delay 3
move Turm1,0,R,UP,10,200
move Turm2,3,R,RIGHT,10,200
Wait Turm1, Turm2
Delay 3


Turm 1 fährt sofort 10 Umdrehungen mit v = 200 nach unten
Turm 3 fährt 3 sec später 10 Umdrehungen mit v = 200 nach links
Wenn beide zum Stillstand gekommen sind: 3 sec Warten
3 sec Warten
Alles von vorne (Loop)

Bei jedem Durchgang wird die Spannung geprüft, damit nicht einen Brick mitten im Ablauf die Puste ausgeht und das MOC in einem undefinierten Zustand stehenbleibt.

Mit verschiedenen Move-Dateien können also ganz verschiedene Bewegungsabläufe dargestellt werden.


Ich hoffe das war jetzt nicht zu viel „IT-Chinesisch“.

An dieser Stelle besonderen Dank an daniel.vergien und andere, die mir mit ihren JAVA-Kenntnissen auf die Sprünge geholfen haben.

Danke an Marc für seine Geduld, die Tabellen vor Ort anzupassen und alles zu testen.

Grüße

Werner



Matze2903
19.03.2017, 13:25

Als Antwort auf den Beitrag von Lok24

Schöner Einblick in dein"Labor" - danke!

Hallo Werner! Da ich dir kein like geben kann, danke für diesen schönen Einblick in die Technikentwicklung, die aus dem tollen Moc ein sehr tolles Moc mit Bewegung macht. Tolle Zusammenarbeit! LG Matthias


Wenn der Vorhang fällt, sieh hinter die Kulissen - Die Bösen sind oft gut und die Guten sind gerissen
Geblendet vom Szenario erkennt man nicht - Die wahren Dramen spielen nicht im Rampenlicht


Matze2903
19.03.2017, 13:38

Als Antwort auf den Beitrag von Valkon

Re: Game Of Thrones - Collab (Lok24/Valkon) - The Red Keep - Powerd by EV3

Hallo Marc!

Wieder einmal hast du dich selbst übertroffen und in Zusammenarbeit mit Werner/Lok24 ein geniales Moc auf die Beine gestellt.

Durch Werners Technik- und Programmierarbeit bekommt das Moc den letzten Schliff und es bewegt sich, was dann dem Bergfried die krone aufsetzt. Ganz toll, ganz großes Kino habt ihr da entworfen und gebaut: LG matthias


Wenn der Vorhang fällt, sieh hinter die Kulissen - Die Bösen sind oft gut und die Guten sind gerissen
Geblendet vom Szenario erkennt man nicht - Die wahren Dramen spielen nicht im Rampenlicht


legomajome
19.03.2017, 13:53

Als Antwort auf den Beitrag von Valkon

Re: Game Of Thrones - Collab (Lok24/Valkon) - The Red Keep - Powerd by EV3

Hallo Ihr Zwei

Das ist einfach klasse, was bei Eurer Tüftelei herausgekommen ist. Und dann die Details, die ihr zeigt, einfach super.

Marit



Steinemann
19.03.2017, 13:57

Als Antwort auf den Beitrag von Lok24

Re: The Red Keep - Making of - Technik

Echt tolle Arbeit habt ihr Beide da geleistet !!!



Steinemann
19.03.2017, 13:58

Als Antwort auf den Beitrag von Lok24

Re: The Red Keep - Making of - Programmierung

Echt tolle Arbeit habt ihr Beide da geleistet !!!



Larsvader
19.03.2017, 16:08

Als Antwort auf den Beitrag von Valkon

Re: Game Of Thrones - Collab (Lok24/Valkon) - The Red Keep - Powerd by EV3

Hallo ihr zwei!

Geniales Moc habt ihr da hingestellt!
Sogar die Minifigs sind absolut grandios!

Lars, der GoT - Fan



peedeejay
19.03.2017, 17:12

Als Antwort auf den Beitrag von Valkon

Re: Game Of Thrones - Collab (Lok24/Valkon) - The Red Keep - Powerd by EV3

Dazu fällt mit nur eins ein: Wow!

Sehr cool das ihr auch so viel Infos zum Innenleben gepostet habt!


[image]

Flickr | Bauanleitungen für modulare Gebäude


36 nachfolgende Beiträge sind ausgeblendet

Alle anzeigen Immer alle anzeigen

Gesamter Thread: