Höhe auf der Bodenplatte ermitteln

[BahnLand]

Hallo EASY, Seehund und Neo

vielleicht trage ich mit diesem Kommentar ja "Eulen nach Athen". Aber vielleicht nützt es Euch ja auch etwas:

Wenn man ein Objekt um mehrere Achsen dreht (z.B. um die z- und y-Achse), ist das Ergebnis in Abhängigkeit davon, ob man (im Beispiel) zuerst die Drehung um die z-Achse und dann um die y-Achse oder in umgekehrter Reihenfolge vollzieht, verschieden. Weitere Unterschiede ergeben sich auch durch die Interpretation der Achsen:

Werden beim Drehen des Objekts um die z-Achse mit Euren Operationen die x- und y-Achse mit "verdreht"?
Dies trifft im Modellbahn-Studio beispielsweise für die Achsen des Modells, nicht jedoch für die Achsen des Gizmos zu, die unabhängig von der Verdrehung eines Modells immer konstant ausgerichtet bleiben.

Zur Veranschaulichung hier ein paar konkrete Beispiele:

00 ICE-Triebkopf ist auf Bodenplatte ursprünglich in Richtung x-Achse ausgerichtet.

A01 Gizmo-Drehung um die z-Achse 45° nach links hinten (-45°):
Triebkopf steht in der Diagonale zwischen der x- und y-Achse.

A02 Gismo-Drehung um die y-Achse 45° nach links oben (+45°):
Triebkopf ist entlang der (horizontalen) Diagonale um 45° nach oben geneigt und nach links gekippt.

Zurück zur Ausgangslage aus Bild 00:

B01 Gismo-Drehung um die y-Achse 45° nach links oben (+45°):
Triebkopf ist entlang der x-Achse um 45° nach oben geneigt.

B02 Gizmo-Drehung um die z-Achse 45° nach links hinten (-45°):
Triebkopf ist entlang der (horizontalen) Diagonale um 45° nach oben geneigt, aber seitlich nicht gekippt.

Neuer Beginn mit der Ausgangslage aus Bild 00:

C01 Einstellung der z-Rotationseigenschaft im Eigenschaftsfenster auf -45°:
Ergebnis ist Bild A01.

C02 Zusätzliche Einstellung der y-Rotationseigenschaft auf 45°:
Ergebnis ist Bild B02. Dies entspricht von Bild A01 ausgehend einer 45°-Drehung um die bei der Rotation um die z-Achse mit verdrehte y-Achse des Modells (die hiermit nicht mehr mit der Gizmo-y-Achse übereinstimmt.

Nochmals mit der Ausgangslage von Bild 00 beginnend:

D01 Einstellung der y-Rotationseigenschaft auf 45°:
Ergebnis ist Bild B01.

D02 Zusätzliche Einstellung der z-Rotationseigenschaft auf -45°:
Ergebnis ist Bild B02. Eigentlich hätte ich nach den vorausgehenden Interpretationen nun das Bild A02 erwartet, in der aus Szenario C geschlossenen Annahme, dass für die z-Rotation die mit der D01-Rotation entsprechend geneigte Modell-z-Achse herangezogen würde.

Frage an Neo:
Kann man daraus schließen, dass die Rotations-Angaben im Eigenschaftsfenster immer in einer Richtung (immer von oben nach unten - zuerst x-, dann y- und zuletzt z-Rotation) "abgearbeitet" werden?  Dies würde erklären, warum für die Szenarien C und D dasselbe Ergebnis erzielt wird. Offenbar ist Szenario D identisch mit Szenario B, und bei Szenario C wird vom Modellbahn-Studio die Reihenfolge der Abarbeitung vertauscht, sodass dieses ebenfalls mit Szenario B übereinstimmt.

Wurde das Objekt aus der Ausgangsstellung heraus um die z-Achse um einen Winkel verdreht, der nicht ein Vielfaches von 90° ist, kann man eine weitere Drehung um die Gizmo-x-Achse oder die Gizmo-y-Achse in den Rotations-Werten im Eigenschaftsfenster nicht mehr nachvollziehen, weil die Gizmo-Drehung offenbar vom z-Winkel abhängig anteilig auf die x- und y-Rotationswerte aufgeteilt wird. Dies ist für mich insofern noch "einsichtig", da die Gizmo-Rotationsachsen hier nicht mehr mit den Modell-Rotationsachsen übereinstimmen.

Wo bei mir allerdings die geistige Nachvollziehbarkeit vollständig kapituliert, ist die Tatsache, dass dann, wenn sowohl die x-Rotation als auch die y-Rotation auf einen von "0" verschiedenen Wert gestellt werden, vom Modellbahn-Studio "eigenständig" auch der z-Rotationswert verändert wird, und gleichzeitig die x- und y-Rotationswerte andere Beträge annehmen, als ursprünglich eingegeben wurden. Die explizite gleichzeitige Eingabe der x- und y-Rotationswerte und möglicherweise auch noch des dritten z-Rotationswerts ist damit meines Erachtens nicht handhabbar. Oder habe ich da grundsätzlich etwas nicht verstanden?

Um nun auf die Ausgangs-Diskussion zurück zu kommen: Kann es sein, dass Ihr (EASY und Seehund) bei Euren Rotations-Steuerungen genau mit den hier beschriebenen Phänomenen kämpft ("... z-Achse taumelt")?

Viele Grüße
BahnLand

 

[EASY]

Hallo Bahnland,

... danke für diesen Beitrag... nix da mit den Eulen...

nun, ich habe offen gestanden etwas das Problem, daß (noch) nicht so richtig weiß, wie man eine 3D-Ratation mathematisch richtig betrachtet.

Mir kommt zwar das Drehen im MBS manchmal etwas "komisch" vor (das von Dir beschriebene, wenn man alle Winkel <> 0 hat, daß sich bei der Änderung eines Winkels alle anderen auch ändern). So gesehen ist die "taumende" z-Ache für mich ein Versuch der Interpretation. Deine Ausführung läßt mich allerdings an der Richtigkeit dieser Interpretation etwas zweifeln. Nun habe ich heute schon etwas herumgeforscht (aber leider nicht gespeichert), denn in einem Artikel stand etwas von daß bei einer Drehung um alle 3-Achsen, die Reihenfolge wichtig wäre...

Was ich im MBS überhaupt nicht verstehe ist die Tatsache, daß man ein Objekt in der y-Achse nicht auf 90° stellen kann (bei x und z =0°). Ich hatte es einmal geschafft, daß im y-Feld dann "NaN" stand... und da war ich schon wieder bei der Interpretation und der Vorstellung, daß der y-Winkel (aus welchen Gründen auch immer) irgenswie mit mit einem Tangens zu tun haben muß... nur so konnte ich mir "erklären", daß es bei einem Winkel bei 90 Grad zu einer "nicht definierten" ("Ergebnis ist keine Zahl") Zahl kommen kann...

... so gesehen begebe ich mich erst einmal auf rein mathemetische Pfade und lasse Neo erst mal klären, ob das MBS so alles "richtig" macht...

P.S. Wer noch einen guten Hinweis für die mathematische Betrachtung der "3-Achsen-Drehung" hat, kann sich gerne bei mir oder hier per PN melden...

Gruß
EASY

 

 

[quackster]

hallo @alle,

eulen nicht - eher euler (eulersche winkel)

es scheint wohl das bei dehungen um 90 bzw 180 und 360° sich die drehung allein auf das objekt beziehen. (es fällt nicht auf)

allerding beziehen sich im mbs die drehungen des objektes auf den raum in dem sich das objekt befindet.

problemfrei drehungen sind für körper möglich wenn sich die achsen (hier das Gismo) mitdrehen würden.

vg quackster

[seehund]

Hallo,

das von mir entdeckte Problem besteht nicht in der Berechnung, sondern dass das MBS die von mir errechneten Parameter nicht annimmt.

z.B. ich sende Kommando 105: x=0,47 y = 11,66 und z= 71

X und Y werden angenommen und umgesetzt. Z = 71 wird jedoch 71,64. Somit wird bei jedem Schritt der Vorwärtsbewegung ein neuer Z-Wert zurückgegeben, der durch Auf-.und Abrunden das Modell eine Kurve fahren lässt, obwohl es eigentlich nur in Z=34 fahren sollte. Ich vermute das hier die Rückgabewerte der Kommandos 102 und 104 auch eine Rolle spielen, da der Z-Wert von 102 auch verändert wird.

@Quackster: eine Formel nach Euler brachte bei mir noch andere Werte. Wir müssen auf Neo's Antwort diesbezüglich warten. Denn wenn ich z=71 sende, sollte auch Z=71 umgesetzt werden und nicht Z=71.64.

Gruß Seehund

[quackster]

hallo Seehund, @alle

die winkelanpassung kann man auch direckt im mbs (unter rotation verfolgen).

sie müssen angepasst werden da sich das objekt sonst, in sich selbst verdrehen würde.

vg quackster

[seehund]

Hallo Quackster,

Zitat

die winkelanpassung kann man auch direckt im mbs (unter rotation verfolgen).

dort ist mir das ja aufgefallen..... 

Zitat

sie müssen angepasst werden da sich das objekt sonst, in sich selbst verdrehen würde

ich vermute, das sich die Positions- und Rotationswerte sich ändern, da die Außenmaße des Objekts sich bei einer Verdrehung verändern.

Es geht mir darum, das ich das Modell mittels Schnittstellenbefehl nicht korrekt positionieren kann, da das MBS in diesem Fall den Befehl nicht genau ausführt und eigene Berechnungen ausführt.

Gruß Seehund

[quackster]

hallo Seehund,

ich verstehe dein dilemma, aber warum muss der bagger auf jede (kleine) boden welle reagieren.

man könnte doch in einer kreuzform (+) in fahrrichtung prüfen wie das nächste gelände "aussieht" und nur auf die größten beiden abweichungen zum deszeitigen standort reagieren.
ich finde es nicht schlimm wenn mal so ein kettending im boden verschwindet (ist dann bestimmt wasser, schlamm oder morast), der bagger kommt ja auch wieder da raus.

vg quackster

[BahnLand]

Hallo EASY,

eigentlich kommen bei "Winkeldrehungen" nur die trigonometrischen Funktionen Sinus (sin) und Cosinus (cos) vor, die im Gegensatz zum Tangens (tan) keine "Singularitäten" (Funktionswerte "unendlich") besitzen. Deshalb sollten erzeugte neue x-, y- und z-Koordinaten immer berechenbar sein. 

Das obige Bild zeigt eine Drehung in der x-y-Ebene (x-Achse nach rechts, y-Achse nach oben zeigend). Der Punkt (r,0) wird durch Drehung um den Winkel w entlang des Kreises mit Radius r um den Koordinaten-Nullpunkt (0,0) in die Position (x,y) mit x = r*cos(w) und y = r*sin(w) gedreht. Ist der Ausgangspunkt nicht (r,0), sondern (u,v) "irgendwo" in der x-y-Ebene, wird deren neue Position (x,y) durch die Drehung des Punktes (u,v) um den Koordinaten-Nullpunkt mit Winkel w wie folgt berechnet:

x = u*cos(w) - v*sin(w),
y = u*sin(w) + v*cos(w)

Für die Darstellung von Objekten im 3-dimensionalen Raum werden zumindest beim DirectX-Format Transformations-Matrix-Operationen verwendet, die auf sämtliche Koordinaten-Punkte (x,y,z) eines Objekts angewendet werden. Die "FrameTransformMatrix" in einer (Direct)X-Datei sieht folgendermaßen aus (hellgrau unterlegt):

Hierbei dient die rot umrahmte 3x3-Matrix (3 Zeilen + 3 Spalten) der Rotation der x-, y- und z-Koordinaten eines "Raumpunktes". Im obigen Bild würden die x-, z- und y-Koordinaten des Zielpunktes (links im Bild vertikal angeordnet, bei der im DirectX-Format verwendeten amerikanischen Koordinaten-Schreibweise sind die y- und z-Koordinate vertauscht) berechnet, indem man die Werte der entsprechenden Matrix-Teile mit den ursprünglichen x- z- und y-Koordinaten (oben über der Matrix horizontal angeordnet) multipliziert und dann aufaddiert. Die obige Matrix mit "1" in der Diagonale und sonst "0" ist "neutral" und lässt daher die Original-Werte unverändert.

Bei einer Drehung in der x-y-Ebene (Rotation um die z-Achse) werden in die FrameTransForm-Matrix an den rot markierten Stellen bei einer Drehung um den Winkel w dessen Sinus- und Cosinus-Werte eingetragen. Mit der oben gezeigten Vorgehensweise erhält man dann genau die ganz oben genannten Formeln für die Berechnung der neuen (x,y)-Koordinaten aus den ursprünglich vorhandenen Koordinaten (dort (u,v) genannt).

Für Drehungen in der x-z-Ebene (um die y-Achse) und in der y-z-Ebene (um die x-Achse) geht man analog vor:

Beliebige Drehungen im 3-dimensionalen Raum erhält man nun, indem man die obigen Operationen für die 3 genannten Ebenen (oder Rotationsachsen) "in geeigneter Reihenfolge" hintereinander ausführt. Hierbei ist "geeignet" ein wesentlicher Aspekt. Denn Rotationsoperationen führen beim Vertauschen der Reihenfolge zu unterschiedlichen Ergebnissen. Man kann sich dies am besten mit 90°-Drehungen bei einem Spielwürfel verdeutlichen:

Im obigen Bild sind in 2 Reihen je 3 Spielwürfel angeordnet, deren 1. Würfel (vorne) die identische Ausgangsposition besitzen. Die Anordnung der 2. und 3. Würfel jeder 3er-Reihe entstand jeweils durch eine 90°-Drehung aus der Position des vorangehenden Würfels. In der vorderen Reihe wurde der Würfel zuerst um die x-Achse nach links und dann um die y-Achse nach rechts gedreht. Beim zweiten Würfel wurden dieselben Drehungen durchgeführt, jedoch in umgekehrter Reihenfolge (zuerst um die y-Achse nach rechts, dann um die x-Achse nach links). Man sieht, dass die Endpositionen der beiden Würfel (hinten) völlig unterschiedlich sind.

Man kann diesen Effekt mit "realen" Spielwürfeln leicht nachvollziehen. Um die Drehungen auch im Modellbahn-Studio nachvollziehen zu können, habe ich den Würfel als 3D-Modell in das Verzeichnis "Zusätzlich-Test" des Modellbahn-Katalogs gestellt.

Viele Grüße
BahnLand

 

[seehund]

Hallo Bahnland,

die Berechnung der Positionen und der Rotation stellen nicht das Problem dar, sondern die Rückgabewerte aus dem MBS.

Um die gewählte Richtung beizubehalten, wird durch eine aufwendige, zusätzliche Berechnung (Korrektur der gewählten Richtung) der Ablauf zu langsam, da alle 6 Parameter (Position und Rotation) zusätzlich ausgelesen und neu berechnet werden müssen. Es lief zwar alles, jedoch wurden dem Baggerführer nicht nur die Akkordzulage gestrichen, sondern er wurde gefeuert, da er noch nicht einmal den LKW an einem Tag beladen konnte.

Wenn ich die Rotations-Z-Achse eines Objekt auf Z = 71 setze, soll es nicht auf Z = 71,64 angezeigt und vor allem zurückgegeben werden. Mit jedem Schritt wird Z erhöht, da sich auch die Rückgabewerte der X,Y Position ändern und das Modell fährt eine Kurve, bis es auf Z=0,90,180,... etc. kommt.

Warten wir darauf was Neo dazu sagt.

Gruß Seehund

 

[BahnLand]

Hallo Seehund,

ich hatte EASY im Beitrag #27 eigentlich so verstanden, dass er noch mehr zum theoretischen Verhalten der 3D-Drehungen wissen möchte. Nur darauf habe ich mich in Beitrag #33 bezogen. Bezüglich der Aussage, dass die "eigenmächtiige Modifizierung" explizit eingegebener Rotationswerte durch das Modellbahnstudio nicht korrekt oder zumindest erklärungsbedürftig ist, bin ich vollkommen Eurer Meinung.

[EASY]

Hallo BahnLand,

... Danke für Deine Ausführung... mal sehne ob es in VB etwas äquivalentes gibt...

Nur mal für das Verständnis was mein Ziel ist.

Ich würde gerne ein Objekt1 so drehen, daß es auf ein Objekt2 zeigt.

Zum einen ist Objekt1 im einfachsten Fall ein Pfeil zum anderen (und da sind wir wieder beim eigentlichen Thema) möchte ich einen "Ping" zu einem Objekt schicken... ... mein Ausgabgspunkt sind in ersten Fall also die Koordinaten und die beliebige Anfangs-Drehung von Objekt1 -> auf Koordinaten Objekt2 und im zweiten Fall die "Grundausrichtung" (welche Richtung ist Winkel = 0) und die Koordinaten von Ping -> auf Koordinaten Objekt2 
 

Gruß
EASY

[BahnLand]

Hallo EASY,

eigentlich hat Neo so etwas ja mit der Kamera realisiert: Wenn man die Kamera (in Deinem Beispiel Objekt1) mit einem "Ziel-Objekt" (in Deinem Beispiel Objekt2) verbindet, wird sie von jeder Position aus genau auf dieses Objekt ausgerichtet. Ich weiß nicht, ob Du von Neo den Algorithmus dazu haben kannst. Ansonsten habe ich hier ein kleines Bild gezeichnet:

 

Zwei Objekte "Objekt1" (das bunte Koordinatenkreuz) und "Objekt2" (das graue Koordinatenkreuz) seien an beliebigen Stellen mit den Koordinaten (x1, y1, z1) und (x2, y2, z2) im Raum positioniert (das dünne Fadenkreuz markiere den Koordinatenursprung (0, 0, 0)). Dann wird die relative Verschiebung von Objekt2 gegenüber Objekt1 durch die relativen Koordinaten (x2-x1, y2-y1, z2-z1) dargestellt (siehe die Kanten der im obigen Bild eingezeichneten Dreiecks-Flächen).

Wird ein Objekt aus dem Online-Katalog des Modellbahn-Studios auf die Bodenplatte gezogen, ist es immer zuerst einmal horizontal und vertikal entlang der x-Achse des Gizmos ausgerichtet. Diese Ausrichtung genügt, um aus den oben gezeigten Differenz-Koordinaten die horizontale Winkelabweichung w und die vertikale Winkelabweichung v zu bestimmen, durch welche der Richtungspfeil von Objekt1 nach Objekt2 definiert ist. Für die Berechnung dieser Winkel wird die Funktion "Arcustangens"  (Umkehrfunktion des Tangens, atan) benötigt. Die Winkel w für die horizontale und v für die vertikale Abweichung ergeben sich hieraus wie folgt:

w = atan( (y2-y1) / (x2-x1) )    für x2 <> x1
w = 90°    für x2 = x1

v = atan( (z2-z1) / sqr( (x2-x1)*(x2-x1) + (y2-y1)*(y2-y1) ) )   für mindestens x2 <> x2 oder y2 <> y1  (sqr = Quadratwurzel-Funktion)
v = 90°    für x2 = x1 und gleichzeitig y2 = y1

Setzt man nun beim Objekt1 im Eigenschaftsfenster des Modellbahn-Studios (oder äquivalent über die Schnittstelle) die gewonnenen Winkelwerte v für die Rotation um die y-Achse und w für die Rotation um die z-Achse ein (die x-Rotation wird auf "0" belassen), richtet sich das Objekt1 genau in Richtung zum Objekt2 aus. Hierbei spielt es keine Rolle, welche Orientierung (Verdrehungen) das Objekt1 vor der Zuweisung hatte, weil sich die Winkelmaße grundsätzlich auf die Ausrichtung entlang der x-Achse beziehen.

Um die Drehungen entsprechend der in Beitrag #33 beschriebenen Transformationen durchführen zu können, werden die Sinus- und Cosinus-Werte der beiden Winkel, nicht jedoch die Winkel selbst, benötigt:

sin(w) = (y2-y1) / sqr( (x2-x1)*x2-x1) + (y2-y1)*(y2-y1) )
cos(w) = (x2-x1) / sqr( (x2-x1)*x2-x1) + (y2-y1)*(y2-y1) )

sin(v) = (z2-z1) / sqr( (x2-x1)*x2-x1) + (y2-y1)*(y2-y1) + (z2-z1)*(z2-z1) )
cos(v) = sqr( (x2-x1)*x2-x1) + (y2-y1)*(y2-y1) ) / sqr( (x2-x1)*x2-x1) + (y2-y1)*(y2-y1) + (z2-z1)*(z2-z1) )

Damit von Objekt1 nach Objekt2 ein Richtungspfeil eindeutig positioniert werden kann, dürfen die Koordinaten beider Objekte nicht identisch sein. Da sich dann die Koordinaten entlang mindestens einer Koordinaten-Achse unterscheiden, sind die sqr-Ausdrücke in den obigen Gleichungen für die Sinus- und Cosinus-Werte stets positiv, sodass der Sonderfall der "Division durch 0" nicht - wie es bei den Winkel-Berechnungen darüber der Fall ist - nicht auftritt.

Wendet man nun auf das Objekt1 zuerst die vertikale Drehung um die y-Achse an (Drehung in der x-z-Ebene, Verwendung von sin(v) und cos(v)), und anschließend die Drehung um die z-Achse (Drehung in der x-y-Ebene, Verwendung von sin(w) und cos(w)), so wird für das Objekt1 über die in Beitrag #33 beschriebenen Matrix-Transformationen ebenfalls die Ausrichtung in Richtung von Objekt2 erreicht.

Viele Grüße
BahnLand

 

 

[seehund]

Hallo Bahnland,

nur zum Verständnis, Easy und ich arbeiten an 2 verschiedenen Anwendungen mit dem Befehl 132. Easy hilft mir aber, meine all zu geringen Kenntnisse zu verbessern.

Gruß Seehund

[seehund]

Hallo Easy,

das X,Y-Problem bei Steigungen ist gelöst. Eigentlich war es ganz einfach, aber irgendwo hatte ich eine Blockade. Im Gruppenbefehl bei beim Fahrstart die Richtung mit einer neuen, festen Variable -RotZ2- an die Neigungs-Berechnung gesendet. RotZ durfte nicht in der Do While Schleife abgerufen werden. Jetzt muss nur noch die Synchronisation der Animation mit dem MBS erarbeitet werden. Es ruckelt noch was.

Gruß Seehund

[Neo]

Hallo,

ich konnte das Wochenende das Thema nicht detailliert verfolgen, weshalb ich nochmal nachfragen muss, welche Probleme noch aktuell sind.

Zum Thema Rotationen allgemein: Das Studio arbeitet intern nicht mit Euler-Rotationen (X, Y und Z), sondern mit Quaternions. Diese besitzen gerade im Kontext von Rotationen sehr viele Eigenheiten, die einem das Leben einfacher machen (auch wenn sie mathematisch zunächst komplizierter erscheinen). Da Quaternions aber mit einer vierten Dimension arbeiten, sind sie für die menschliche Darstellung nicht geeignet, weshalb das Studio Rotationen bei der Anzeige im Eigenschaftsfenster und über die Schnittstelle in Euler-Rotationen umrechnet. Bei diesen Umrechnungen kommt es dann zu den bisher beobachteten Effekten, dass Winkel "umspringen" oder übergebene Zahlen leicht abweichen. Solange es diese Umrechnungen gibt, lassen sich solche Probleme leider nicht komplett abstellen. Gerade im Eigenschaftsfenster kann man nur mit den Euler-Rotationen arbeiten. Über die Steuerschnittstelle könnte man überlegen, mit Quaternions zu arbeiten. Dann muss man aber im VB auch damit weiterrechnen. Hier wäre eine Bibliothek sinnvoll, die für VB fertige Quaternion- und Matrixoperationen anbietet, da diese alle standardisiert sind und nicht doppelt programmiert werden müssen (das Studio z.B. verwendet viele Mathematikoperationen von DirectX).

@Seehund
Du bewegst den Bagger in einer Do-While-Schleife mit festen Abständen. Das ist bei Echtzeitanimationen ein Problem, was zu dem Ruckeln führen kann, denn durch das Multitasking unter Windows ist der Abstand zwischen den Do-While-Durchläufen immer unterschiedlich. Solche Probleme löst man folgendermaßen:

1. Beim Start der Animation wird die aktuelle Zeit gespeichert = A
2. Bei jedem Durchlauf der Do-While-Schleife wird erneut die Zeit gespeichert (B) und die Differenz zu A berechnet
3. Alle Bewegungen werden nun mit der Zeitdifferenz multipliziert
4. B wird zu A, die Schleife startet erneut bei 2

Es spielt nun keine Rolle mehr, wie lange ein Schleifendurchlauf dauert, der Bagger wird sich auf jedem Computer im gleichen Zeitintervall immer gleich weit bewegen. Wichtig ist hierbei, dass die Zeitmessung sehr exakt ist. Es reichen hier keine Sekunden, sondern es muss mindestens in Mikro-, besser noch Nanosekunden gemessen werden. Dafür gibt es sicher auch unter VB Möglichkeiten. Ich habe hier ein kleines Tutorial gefunden (interessant ist dort _lastRender  und deltaTime).

@Easy
BahnLand hat die mathematischen Grundlagen zum Ausrichten von Objekten auf andere Objekte sehr gut beschrieben, das Studio selbst muss sich mit diesen Details aber gar nicht beschäftigen, da vieles von der DirectX-Mathematikbibliothek übernommen wird. Das Studio selbst erstellt lediglich eine Rotationsmatrix aus den 3 Koordinatenachsen. Diese Achsen werden folgendermaßen berechnet:

• X-Achse: Differenz zwischen Zielposition und Startposition (normalisierter Vektor)
• Z-Achse: Wird auf (0, 0, 1) festgelegt
• Y-Achse: Kreuzprodukt aus X und Z
• Z-Achse (erneut): Kreuzprodukt aus X und Y

Die Werte der Achsen werden dann in die Transformationsmatrix eingetragen und zu einer Quaternion konvertiert, mit der das Studio das Objekt dann dreht. Ich denke mal, in diese Richtung muss es auch bei dir geben, ich empfehle hier aber unbedingt eine fertige Vektor- und Matrizenbibliothek einzusetzen, da man sonst mit sehr viel Mathe beschäftigt ist.

Viele Grüße,

Neo

[seehund]

Hallo Neo,

hatte über das Wochenende genügend Zeit, die Steuerung ans" Laufen" zu bringen. Was man so laufen nennen kann.
Der Bagger fährt zwar jetzt im richtigen Winkel die "Berge" hoch und runter, jedoch ist nun die Zeit das große Problem, denn durch die 4 Pings von 132 um über die Höhendifferenz die Winkel von X und Y zu bestimmen und den Berechnungen diese dann über 105 wieder zu setzen, wurde der Animationseffekt so verlangsamt, das um eine "normale" Geschwindigkeit des Modells darzustellen die Schrittweite extrem erhöht werden musste.
Nun "springt" das Modell  natürlich, obwohl die "Function Neigung" nur aus 5 x "Send_Command" und 10 Zeilen mit Berechnungsformeln besteht.
Wenn jetzt zusätzlich noch deine vorgeschlagene Zeitmessung dazu kommt, wird die Schrittweite noch höher anzusetzen sein.

Scheinbar ist das Ganze zu komplex um über die Schnittstelle im MBS in nahezu angestrebter Echtzeit verarbeitet zu werden.

Weiterhin und für mich wichtiger ist immer noch das Problem den Parameter Z beim Befehl 105 exakt zu setzen. Wenn X und Y <> 0  sind, kann ich dort eintragen was ich will, das MBS errechnet trotzdem die Z-Rotation eigenständig und führt diese auch aus.
Somit wird eine Fahrt in die von der Steuerung gesendeten Richtung auf die Werte die das MBS errechnet, abgelenkt.

Werde die Spielerei bei Gelegenheit noch mal auf Matrixbasis testen, mal sehen ob es dann schneller wird.

Gruß Seehund

 

 

 

[Neo]

Hallo Seehund,

könntest du mir nochmal deinen aktuellen Skript-Stand schicken? Ich würde gern in Visual Studio Zeitmessungen durchführen. In der Vergangenheit konnte ich testweise mehrere 1000 Befehle pro Sekunde über die Schnittstelle verarbeiten, weshalb es mich etwas wundert, dass so wenig schon so langsam sein soll. Ich vermute irgendwo ein Problem, was nicht sofort ersichtlich ist.

Viele Grüße,

Neo

[seehund]

Hallo Neo,

habe die Neigungs-Funktion leider schon gelöscht, da ich das Ganze neu angehen möchte.

Auf die Idee die Zeit der Funktion zu messen kam ich auch schon und war verwundert hier unregelmäßige Zeiten von 52 -216 Milli-Sekunden maß. Auf jeder neuen Position schwankte die  Zeit in der Funktion, obwohl der Ablauf immer gleich war. Alleine die Werte aus PosX und PosY  flossen neu in die Berechnung ein.

Ohne die 4 x Send_Command("132......") für die Höhenberechnung lief die Funktion zwischen 4 und 5  Milli-Sekunden (incl. Send-Command("105;...").

Sobald ich die neue Funktion fertig habe, sende ich sie dir zu.

Gruß Seehund

@neue Version :

Habe die erforderlichen 4 Höhenpunkte zur Neigungsermittlung geändert in x+30, x-30, y+20 und y-20. Hiermit läuft die Berechnung wesentlich schneller, hat aber den Nachteil, das nicht mehr an den 4 Außenkanten gemessen wird und die Ketten manchmal etwas in der Bodenplatte verschwinden. Die Neigungs-Funktion läuft jetzt stabil mit 59 mS je Durchlauf.
Jetzt tut sich aber beim Drehen des Baggers eine neue Baustelle auf, da mit dieser Art Berechnung der Mittelpunkt des Fahrzeugs der Ausgangspunkt ist und bei  Y, Y > 0 der Befehl 105 wieder sein eigenes Spielchen treibt.
Da die Drehung aber sowieso zu schnell lief und durch ein Sleep(50) gebremst werden musste, habe ich ja da noch etwas Spielraum für zusätzliche Berechnungen.

[Neo]

Hallo Seehund,

ich habe dein aktuelles Programm analysiert und kann sagen, dass es kein Performanceproblem gibt. Der Grund für die Ruckler sind die fehlenden Gruppenkommandos. Dadurch, dass du jedes Kommando 132 einzeln herausschickst und auf eine Antwort wartest, bremst du dein Programm künstlich ab, denn eingehende Kommandos werden vom Studio nur einmal pro Frame verarbeitet. Das erkannt man daran, dass das Kommando 132 genau 16 ms Zeit in Anspruch nimmt, rund 1/60 einer Sekunde. Deaktiviere im Studio einmal die vertikale Synchronisation und entferne die Sleeps, dann wird deine Baggersteuerung einen großen Geschwindigkeitssprung machen.

Wegen dieser Kopplung an die vertikale Synchronisation wurden die Gruppenkommandos eingeführt, da alle Kommandos einer Gruppe dann in einem Frame zusammenhängend verarbeitet werden. Fasse die 4 132er-Kommandos in einer Gruppe zusammen und werte die Ergebnisse am Ende nach der Gruppe erst aus.

Da du nicht jedes Kommando in einer Gruppe zusammenfassen kannst (da einige Kommandos auf dem Ergebnis des vorhergehenden Kommandos aufbauen), kann es sein, dass wir uns eine Schnittstellenerweiterung ausdenken müssen, um das Studio für eine gewisse Zeit zu blockieren, während ein Client mehrere Kommandos verarbeitet. Dieses Schritt würde ich aber erst zum Schluss gehen wollen.

Weiterhin habe ich noch folgende Tipps für dich:

• Verzichte auf die Sleeps, versuch besser die zeitabhängige Steuerung aus Beitrag 40. Es gibt kein Geschwindigkeitsproblem in VB, Ruckler entstehen durch die vertikale Synchronisation und den fehlenden Gruppenkommandos
• Die Umrechnungen zwischen Grad und Bogenmaß kannst du dir sparen, wenn du die Schnittstelle am Anfang direkt auf Bogenmaß konfigurierst (Kommando 43). Das macht den Code etwas übersichtlicher.

Viele Grüße,

Neo

[seehund]

Hallo Neo,

danke für deine Hilfe. Habe deine Hilfen umgesetzt und den Bug beim Drehen durch einen festen Wert ersetzt, der nur einmal am Anfang ausgelesen wird.

Optimal ist anders, aber wir sind schon sehr nahe daran. Eine Geschwindigkeitssteigerung habe ich nur beim Drehen feststellen können, bei Vor- und Zurück blieb die Schrittweite der Kette jedoch auf 0,42 stehen.

Werde versuchen das leichte Ruckeln durch Veränderung der Anzahl an Frames in der Animation wegzubekommen.

Dankend grüßt der Seehund

[EASY]

Hallo Neo,

... ich weiß, daß es nicht mehr so richtig zur Themenüberschrift passt, aber ich wollte trotzdem keinen neues Theme eröffnen...

Zitat

Da du nicht jedes Kommando in einer Gruppe zusammenfassen kannst (da einige Kommandos auf dem Ergebnis des vorhergehenden Kommandos aufbauen), kann es sein, dass wir uns eine Schnittstellenerweiterung ausdenken müssen, um das Studio für eine gewisse Zeit zu blockieren, während ein Client mehrere Kommandos verarbeitet. Dieses Schritt würde ich aber erst zum Schluss gehen wollen.

... wie Du Dich vielleicht erinnern kannst, sind die Gruppenkommandos aus meiner Frage entstanden, warum die Schnittstelle "schneller arbeitet" wenn man eine Menüleiste aufmacht...

... nun gibt es noch eine Beobachtung von mir, die einen "Geschwindigkeitsschub" der Schnittstelle bietet:
wenn ich die Maus im Projektfenster bewege, läuft z.B. eine Bewegung eines Objektes, das durch die Schnittstelle gesteuert wird, schneller ab...(der Effekt ist nach meiner bisherigen Beobachtung kleiner, als wenn ich ein Menü öffne aber auch deutlich und besonders deutlich bei eingeschalteter vertikaler Synchronisation)... Auch der Bagger von Seehund lief deutlich besser (mit der Vorversion die er mir geschickt hat), wenn ich die Maus im Projektfenster bewegt habe.

... vielleicht kannst Du ja daraus noch etwas ableiten... oder hat dies den gleichen Hintergrund, wie das geöffnete Menüfenster?
Gruß
EASY

[Neo]

Hallo Easy,

kurze Antwort, ja. Die Mausbewegungen führen intern zum gleichen Verhalten wie die Aktivierung eines Menüs.

Viele Grüße,

Neo

[EASY]

Hallo Neo,

... schade !!! ... aber ein Versuch war es wert...

Gruß
EASY

[seehund]

Hallo Neo und Easy,

bei meinen Zeitmessungen fiel mir auf, das die StopWatch-Funktion statt 59 MS je Durchlauf, nur noch 16 MS anzeigte, wenn der Bagger selektiert war.

Gruß Seehund

[EASY]

Hallo Neo,

Dringend!!!

... ich habe mich gerade noch etwas mit der Steuerung von Seehund beschäftigt... und die 4 Pings in einem Gruppenkommando zusammengefasst...

dabei bin ich (unangenehm) darauf getoßen, daß wenn der Ping auf kein Objekt trifft trotzdem als Antwort zuerst eine "1" sendet...
... dies würde bedeuten (auch ohne Gruppenkommando), daß man den Ping extra auswerten müßte... nicht auf "0" oder "1" am Anfang, sondern auf die Anzahl der Rückgabeparameter (wenn nicht getroffen keine weiteren Parameter in der Antwort)... dies wäre in der Kommandoauswertung so etwas wie ein Stielbruch...

... deshalb... wenn Ping nichts trifft... Antwort = "0" am Anfang und noch eine Meldung (wie bei den anderen kommandos auch...)

Gruß
EASY