Bernhard Häussner

Drehmomente und Kräfte mit Processing

20.04.2010, 14:57

Zu meinem Blogeintrag mit Stills aus den Physik-Inspirierten Processing-Sketches wollte ich noch einiges zur Methodik, Physik und Umsetzung notieren.

Achtung: Was hier steht muss nicht alles wissenschaftlich korrekt sein. Ich habe zwar bei einem Mathe-/Physiklehrer über die Grundprinzipien referiert, das schließt natürlich Mängel nicht aus. Der interessierte und/oder fachundige Leser kann ja einen Kommentar hinterlassen, falls Klärungsbedarf besteht. Mir fehlt leider die Zeit, alles nachzuprüfen.

Einführung und Methodik

Dies ist ein Antwortversuch auf die Frage, wie sich ein starrer Körper verhält, wenn auf eine Kraft - nicht am Schwerpunkt - einwirkt. Ich versuchte das Zusammenspiel aus Rotation und Translation zu beschreiben.

Im Lehrplan Physik steht ein ganzer Haufen einfachster Formeln für ein paar wenige Spezialfälle. Man lernt recht viel über Kräfte, Drehmoment, Federn, Druck, Optik, ein bisschen Wärmelehre und Energie. Dann noch ein paar Dinge mit Elektronen, die man als Grundwissen für die Kernchemie braucht. Dumm nur, dass man das alles Stückchenweise beigebracht bekommt, und vor allem ohne dabei die Rechentechniken dahinter zu beherrschen. Integrale und Vektoren lernt man erst in der Mathematik der Kollegstufe komplett. Jetzt, wo ich einigermaßen rechnen kann, habe ich aber kein Physik mehr. Trotzdem will ich noch ein bisschen aus meinen Physik-Kenntnissen schöpfen, zumal sich mit physikalisch inspirierten Berechnungen interessante Simulationen am Computer erstellen lassen.

Erstaunlich zutreffend stellt Wolf Wagner in „Uni-Angst und Uni-Bluff“ fest:

»Das Lesen und Lernen ohne eigene Fragestellung ist also nicht nur ineffektiv. Es ist auch anstrengender, weil Langeweile die Konzentration erschwert «
Wagner, Wolf:
Uni-Angst und Uni-Bluff. Wie studieren und sich nicht verlieren,
Hamburg 2002. S. 105.

Da kam mir eine Fragestellung gerade recht. Die schiefe Ebene, der Kraftstoß und einiges anderes wurde ausführlichst behandelt. Jedoch greifen alle Kräfte (engl. force) immer am Schwerpunkt an. Zwar habe ich auch mal etwas vom Drehmoment (engl. torque) gehört und sogar die Veränderung des Trägheitsmoments (engl. rotational inertia) in Kindheitsjahren auf einem Karussell zu spüren bekommen, doch eine Synthese dieser sämtlichen Bewegungsparameter fehlte immer: Was passiert, wenn eine Kraft eben nicht am Schwerpunkt angreift?

Nach ein paar Feldversuchen hat man ungefähr das Bewegungsverhalten wie im folgenen Video im Kopf. Feldversuche hieß für mich mit einem Zirkel (genauer: seiner Nadel vorne) einen Bierdeckel auf dem Tisch herum schleifen. Wegen unpräziser Motorik und störender Reibung habe ich mich aber dann auf die Computersimulation verlagert. Um die Thesen zu bestätigen müsste ich das Experiment vielleicht auf einem Air Hockey filmen. So oder so ergibt sich wohl keine genaue experimentelle Bestätigung, aufgrund der feinen Abhängigkeit von der Startparametern. Jedoch kann man versuchen den Bewegungsablauf auf Energieerhaltung zu prüfen, wo die einzelnen Formeln experimentell bestätigt werden können.


Simulation mit 1 Scheibe

Man überlegt sich schnell, dass die Kraft wohl in eine Translations-Komponente und eine Rotations-Komponente zerlegt werden muss. Die Translationskomponente deutet vom Schwerpunkt weg (Der Physiker nennt das: Die Wirkungslinie verläuft durch den Schwerpunkt) und die Rotationskomponente verläuft senkrecht dazu. Mit der Translationskomponente kann man dann (hoffentlich) wie gewohnt weiter rechen. Also die Kraft wirkt auf die Masse und bewirkt eine Beschleunigung (engl. acceleration), die die Geschwindigkeit (engl. velocity) verändert, und diese wiederum die Position.

Bei dieser Prozedur muss man stets integrieren. Weil das nicht ganz einfach ist (und mit dem Computer nicht mit einfachsten Mitteln lösbar) bedient man sich der „Eulermethode“. Den Begriff habe ich so im Englischen gefunden - bei uns: „Methode der kleinen Schritte“. Pro „Frame“ addiert man die Beschleunigung auf die Geschwindigkeit, und diese wieder auf die Position, die Faktor Zeit wir im einfachsten Fall in Frames gemessen und fällt als 1 Frame weg. Dabei muss man sich um wenig rechnerisches kümmern, und wenn man die Schrittchen sehr klein macht (ich habe eine Euler-Auflösung eingebaut, die ich anpassen kann, um genauer oder schneller zu rechnen) extrapoliert sich das System irgendwann mit zufriedenstellender Genauigkeit.

Für die Drehung muss man die Restkraft einberechnen. Da funktionieren die altbekannten Formeln zum Drehmoment. Jedoch fehlte mir zunächst das Rotationsäquivalent zu Masse. Interessanterweise hängt dieses nicht nur von der Masse, sondern auch von der Entfernung zum Dreh-/Schwerpunkt ab. Grob gesagt: Doppelt so weit entfernte Masse macht viermal so viel Ärger (also ein n²-Gesetz, ähnlich dem vom Strahlenschutz bekannten Abstandsquadratgesetz nur nicht reziprok). Die Berechnung läuft also auf das Integrieren eines Parabel-Rotationskörpers (um die y-Achse) hinaus.

Jetzt wird zum ersten Mal einbezogen, wie der Körper eigentlich aussieht, also wie die Masse um den Schwerpunkt und die Drehachse verteilt ist. Da die Prozedur zur Übersicht zweidimensional bleiben soll und wegen der Berechnung des Trägheitsmoments wählt man eine Scheibe mit konstanter Dichte, also gleich verteilter Masse. Dann überlegt man sich das Trägheitsmoment:

Kleine Formelsammlung

Trägeheitsmoment J der Masse m mit Abstand zur Drehachse r einer Scheibe mit Volumen V, konstanter Dichte ρ, Radius r', Höhe h und Grundfläche A.

Trägeheitsmoment J der Masse m mit Abstand zur Drehachse r einer Scheibe mit Volumen V, konstanter Dichte ρ, Radius r', Höhe h und Grundfläche A.

Auf Wikipedia bin ich auf diese Vereinfachung aufmerksam geworden:

Mit diesem Trägheitsmoment kann man jetzt endlich rechnen. Wie die Natur so will, bzw. die Mathematik vereinfacht, verhalten sich Rotation und Translation analog:

Analogie von Rotation und Translation: <br/>Beschleunigung a ~ Winkelbeschleunigung α<br/>Geschwindigkeit v ~ Winkelgeschwindigkeit ω<br/>Position x ~ Ausrichtung φ<br/>Kraft F ~ Drehmoment M<br/>Masse m ~ Trägheitsmoment J

Analogie von Rotation und Translation:
Beschleunigung a ~ Winkelbeschleunigung α
Geschwindigkeit v ~ Winkelgeschwindigkeit ω
Position x ~ Ausrichtung φ
Kraft F ~ Drehmoment M
Masse m ~ Trägheitsmoment J

Weil konstante Kräfte eher unspektakulär sind und sich vor allem die betroffenen starren Körper unendlich weit bewegen, halten wir sie mit einer Feder im Rahmen.

Hookesches Gesetz mit Federhärte d und Auslenkung Δl

Hookesches Gesetz mit Federhärte d und Auslenkung Δl

Videos

Diese ganzen hübschen Formeln füttert man der JVM und bastelt mit Processing.org noch eine schöne graphische Darstellung.


Viele Scheiben, jeweils nur 3 Punkte markiert

Die physikalische Grundlage ist nicht mehr ganz so leicht zu erkennen:


Simulation mit einigen Scheiben

Mit etwas Spiel lassen sich die wildesten Sachen treiben:


Chaos theory experiment "Disk"

Natürlich waren neben den Formeln noch weitere Überlegungen möglich:

Möglich sind einige verschiedene Repräsentationen der Position, an der die Kräfte an den Scheiben angreifen. Einerseits die Position relativ zu Position und Drehung der Scheibe. Diese wird von den Federn gespeichert, damit sich ihr Angriffspunkt auf der Scheibe nicht verschiebt. [/p]

Diesen dreh-relativen Ortsvektor lassen die Federn jedoch von der Scheibe umrechnen in eine absolute Position, mit der sie dann den Abstand von ihrer eigenen, festen und absoluten Position berechnen können. Die Entfernung wird für die Berechnung des Kraftbetrags benötigt, der Positionsunterschied für die Richtung der Kraft.

Wenn die errechnete Kraft dann auf die Scheibe angewendet wird, wird diese jedoch wieder mit einer relativen Positionierung arbeiten. Da jedoch eine Drehung aller Kräfte einen Umweg bedeuten würde, bleibt die relative Position diesmal umgedreht.

Da von Vektoren lediglich der Betrag berechnet wird, muss man auch herausfinden, in welche Richtung der Kraftvektor für den Drehmoment zeigt, da sich hierdurch das Vorzeichen ändert. Dazu rotiert man den Positionsvektor um 90°. Wenn alle beide Koordinatenvorzeichen von diesem rotierten Vektor und dem Kraftvektor gleich sind, sind die Vektoren gleichgerichtet. Danach kann man das Vorzeichen für den Drehmoment wählen. Dann müssen die Drehmonte nur noch aufaddiert werden und mit dem Trägheitsmoment zur Winkelgeschwindigkeit und damit zur Drehung verrechnet werden.

Eigentlich ist das gesamte Verfahren eher unkompliziert, da es jedoch kein Schulstoff ist, und auch sonst kaum Dokumentiert, hat es doch einige Knobelarbeit gekostet, die richtigen Einfälle und Formeln zu kombinieren.

Erläuterungen zur Umsetzung

Interessant ist vielleicht noch die Java-Architektur dahinter. Die Scheiben implementieren ein Interface Pullable. Die Federn bekommen eine Scheibe zugewiesen (die ziehbar ist), könnten theoretisch aber auch alles andere ziehen, da alle Berechnungen, die von der Scheibe abhängen dort Eingekapselt sind und von der Feder nur die im Interface festgelegten allgemeinen Funktionen verwendet werden.

Auch die Marker, verantwortlich für das Ziehen der Linien, bekommen ein ziehbares Obejekt zugewiesen. Denn sie verwenden das selbe Interface wie die Federn um ihre Absolutposition zu berechnen von einem auf der Scheibe fixierten Punkt aus. Zusätzlich zur Scheibe bekommen sie ein Objekt delegiert, das das Interface Coorddrawer implementiert, also Koordinaten zeichnen kann.

Ich habe zwei verschiedene Coorddrawer implementiert. Im letzten Video verwende ich zwei primitivere Marker. Der rote zeichnet nur jeweils einen Punkt, der blaue merkt sich die letzte gezeichnete Koordinate und zieht dann eine Linie von ihr.

Der Koordinatenzeichner des anderen künstlerischen Videos wird nicht nur mit einer Farbe vorkonfiguriert, sondern merkt sich auch einen „Rattenschwanz“ von 2000 Koordinaten, sodass er nach dem Löschen der Zeichenfläche wieder eine lange Linie nachzeichnen kann.

Was ich auf physikalischer Seite natürlich ganz außen vor gehalten habe sind Impuls und Reibung, jedoch lässt sich das wohl auch noch leicht kombinieren.

In einem gesonderten Blogeintrag gibt es noch ein paar Stills aus den Physik-Inspirierten Processing-Sketches.

Kurze URL http://1-co.de/b/1f. Post to twitter

Kommentare

David meint: (#223)
26.04.2010, 20:20

Also soweit werde ich sicher nie kommen :-/ aber dennoch: Kennst du vielleicht ein gutes Processing Tutorial? Ich weiß dass bei Processing einiges an Beispielen dabei ist aber ich glaub das reicht mir fast nicht ;)

Bernhard H. meint: (#224)
26.04.2010, 23:31

Ich überlege gerade, wie ich Processing gelernt habe...

Ich glaube, ich habe im "offiziellen" Lernbereich (http://processing.org/learning/) zunächst das Getting Started durchgemacht. Danach kann man noch die Tutorials zu Color usw. kurz überfliegen, Trigonometrie und Vektoren kann man sich wohl fast sparen, dabei es kommt auch sehr darauf an, wie sehr man mit diesen Grundlagen von Anderem vertraut ist.

Es ist sicher hilfreich, wenn man schon ein bisschen in Java reingeschnuppert hat, dann kennt man die Kontrollstrukturen (Wenndann, Schleifen usw.) grob; Man muss dann beachten, dass Processing vieles vereinfacht. Zu dem Thema findet man unter "Control" in der API-Doc (http://processing.org/reference/) manches. Man kann natürlich auch rumprobieren...

Mit dem Basiswissen habe ich dann ein paar rudimentäre Spielereien gemacht.
Wenn man dann etwas in den grundlegenden Konzepten drinnen ist (z.B. was macht draw() usw.), sind die mitgelieferten Beispiele wirklich sehr praktisch, da lernt man die Möglichkeiten sehr gut kennen und das Wissen wird vertieft. Außerdem klären sich einige übliche Einstiegsfragen ala "Wie macht man eigentlich ...?". Bei interessanterem sollte man durchaus den Code genau lesen und verstehen. Ich habe dann immer schon die Beispiele leicht modifiziert, um zu sehen, ob auch alles so funktioniert, wie ich denke.

Ausgehend von den Beispiel-Sketches kann man dann die ersten eigenen Ideen verwirklichen.

Wenn man dann weiter macht, schaut man halt immer in der API-Doc (http://processing.org/reference/) nach den Funktionen, die heißen eigentlich immer so, dass man sie auch findet.

Ich sehe gerade ich habe am 20. Mai 2009 (Oh, bald Jahrestag) meine ersten paar Versuche gemacht, und die Sachen aus dem ersten Blogeintrag zum Thema (http://bernhardhaeussner.de/blog/65_Processing%3A_3D-Koch-Kurve_mit_Sierpinski-Dreieck) sind in mehreren Stunden am 21. entstanden. Tja und vieles andere, das ich bisher mit Processing gemacht habe, ist dann in den Tagen darauf entstanden. Also man kann wirklich schnell interessante Dinge machen.

Jetzt der Physik-Kram war natürlich ein bisschen aufwändiger, und man kann auch alles perfektionieren... HTH

M:ke meint: (#241)
20.06.2010, 12:08

Hallo.

Dass die einwirkende Kraft in Rotation und Translation aufgeteilt werden muss verstehe ich. ABer wie kommt man auf die Komponenten? Bei Wikipedia und einigen Büchern steht nur, dass das Drehmoment das Kreuzprodukt aus Drehkraftvektor und Abstandsvektor ist. Aber wie erhalte ich nun die Translationskomponente? Ich kann doch nicht das Drehmoment vom Drehkraftvektor abziehen.

Bernhard H. meint: (#243)
20.06.2010, 14:25

Hi M:ke,
Von deiner wirkenden Kraft (im Video grün) kannst du den Teil, der senkrecht zur Wirkungslinie(=Gerade durch Schwerpunkt und Angriffspunkt) ist, als Drehkraftvektor (orange) nehmen. Wenn du diesen ins Kreuzprodukt einsetzt kommt für das Drehmoment das selbe raus. Du kannst diesen Teil z.B. mit der sog. senkrechten Projektion berechnen.
Diesen Drehkraftvektor subtrahierst du dann vom Ausgangs-Kraftvektor und erhältst somit die Translationskomponente (grau), also den Teil parallel zur Wirkungslinie. Diese kannst du dann wie eine Kraft, die am Schwerpunkt angreift behandeln.
Geometrisch gesehen bilden Rotations- und Translationskomponente ein rechtwinkliges Kräfteparallelogramm dessen Diagonale die ursprüngliche Kraft ist und dessen Seiten parallel und senkrecht zur Wirkungslinie sind.

M:ke meint: (#244)
21.06.2010, 13:40

Hallo Bernhard.

Danke für die Antwort. Bin durch Ausprobieren noch selber drauf gekommen. Ich hab vergessen das Drehmoment durch den Trägheitstensor zur teilen um an die Beschleunigung zu kommen, mit der ich die Restkraft errechnen kann. Meine Implementation sieht jetzt recht realistisch aus:

http://teamblog.tyclipso.net/bDetail/b/Von-Drehmoment-Translations-und-Rotationskraft-1327

M:ke meint: (#246)
21.06.2010, 15:56

War für mich das Logischste, denn ich errechne ja "nur" eine Beschleunigung, noch keine Kraft. Das hat keine Auswirkungen so lange die Masse des zu bewegenden Objektes 1 ist.

Wegen dem Rand: Die Kollisionserkennung kommt noch :)

Übrigens hast du coole Interessen.






 
Χρόνογραφ
© 2008-2017 by Bernhard Häussner - Impressum - Login
Kurz-Link zu dieser Seite: http://1-co.de/b/1f