Jump to content

Empfohlene Beiträge

Geschrieben

Hallo Neo,

gibt es eine Möglichkeit, die aktuelle Höhe unter einem Objekt (Modell auf Position x,y) auf der Bodenplatte zu ermitteln ohne das ein Gleis verlegt ist. Habe einen solchen Befehl bei den Schnittstellen-Kommandos nicht finden können.
Ich meine nicht die feste Höhe der Bodenplatte im Eigenschaftsfenster.

Gruß Seehund

  • Antworten 58
  • Erstellt
  • Letzte Antwort

Höchste Beteiligung

Höchste Beteiligung

Bilder

Geschrieben

Hallo Seehund,

direkt gibt es so einen Befehl aktuell nicht. Man müsste dafür z.B. eine Ebene aus den Grundkörpern auf der Bodenplatte mit automatischer Höhenanpassung platzieren und deren Höhe dann von deinem Objekt abziehen. So wie es klingt scheinst du aber per Plugin die Höhe berechnen zu wollen. Kannst du kurz beschreiben, was du vorhast?

Viele Grüße,

Neo

Geschrieben

hallo Seehund,

108 gibt die höhe des objektes zurück, die halbe höhe ist dann der boden des objektes.
102 die position des objektes (höhe bezogen auf die position der bodenplatte)

wenn das gelände eben ist gibt es kein problem, ist aber das gelände geformt müsste man auf das höhenfeld des bereiches zugreifen so wie es EASY beim spantenbau getan hat.

vg quackster

Geschrieben

Hallo Neo,

der Caterpillar Kettenbagger soll frei und ohne Gleise per Plugin-Steuerung über die Anlage bewegt werden. Die Steuerung des Baggers ist nicht das Problem, da läuft schon alles auch ohne Gleise. Macht wirklich Spaß so frei über die Anlage fahren zu können. Sobald ich aber an eine Steigung oder einen Berg komme, fährt er natürlich mitten durch, da ich die aktuelle Höhe unter der X,Y-Position des Baggers nicht direkt auslesen kann.

Das Ganze sollte natürlich funktionieren, ohne das ich jedes mal an der aktuellen Position das Höhenfeld auslesen muss. Geht zwar, aber verzögert gerade beim Kettenbagger die Animation der Ketten und es kommt zum sehr sichtbaren Ruckeln.

Die einzelnen Höhenpunkte je nach Konfiguration der Bodenplatte müssten doch auslesbar sein.

Der oder die bisherigen Bagger-Steuerungen sind zwar einfach und normalerweise ausreichend, jedoch sind sie an die verlegten unsichtbaren Gleise gebunden und dann ist da noch die Snap-Funktion der Fahrzeuge und schon wieder klebt der Bagger am LKW.

Lass dir Zeit, denn momentan arbeite ich an einer getrennten Ketten-Animation, damit die Ketten beim Drehen gegenläufig sind. Da jedes Glied ein Unterobjekt darstellt, versuche ich jetzt einen anderen Weg der Animation, da bei Einzelanimation das Kettenglied über den Boden rutscht und bei der Bezier-Animation zu viele Unterobjekte notwendig sind.

@ Quackster: Danke für den Hinweis, aber mit 108 kannst du bei animierten Modellen nicht viel anfangen, da sich bei diesen Modellen je nach Animations-Position die Maße laufend ändern. Die Position ständig auszulesen und zu berechnen wäre eine unnötige Verzögerung und es ruckelt wieder.

Gruß Seehund

 

 

 

Geschrieben

Hallo,

@ Seehund
... danke für die Angerung an Neo für dieses Kommando... lag mir sozusagen auch schon mal auf der Tastatur um geschrieben zu werden...

@ Neo
... eigentlich ist es das Auslesen des Höhenfeldes der Bodenplatte über die Schnittstelle für einen beliebigen xy-Punkt. Allerdings wäre der xy-Punkt nicht bezogen auf die Bodenplatte, sondern bezogen auf den Nullpunkt der "Welt"  ... wird sonst schwer bei meheren Bodenplatten im MBS-Projekt... und z.B. Kommandofehler, wenn sich dort keine Bodenplatte befindet...
... und um beim Beispiel von Seehund mit dem Fahren zu bleiben... die xy-Koordinate dürfte nicht objektbezogen sein, da man z.B. für die Berechnung des Anstellwinkels (Fahren auf einer Rampe) vorausschauend berechnen muß... (hier bin ich.... dahin will ich... was muß ich dazu tun...)

Nun weiß ich nicht was hinter der "automatischen Höhenanpassung" steckt... aber ein Teil müßte darin doch schon implementiert sein (?)

Gruß

EASY

Geschrieben

Hallo Seehund und Easy,

technisch ist es kein Problem, die Höhe auf einer Bodenplatte für einen beliebigen Punkt in Weltkoordinaten zurückzugeben, wir müssen uns nur auf einen Standard einigen, da sich unter einem Objekt mehrere Bodenplatten befinden könnten.

Bei der automatischen Höhenanpassung wird ausgehend von einem Objekt ein Strahl nach unten ausgesendet und der Kollisionspunkt mit jeder Bodenplatte berechnet. Der Kollisionspunkt mit dem kürzesten Abstand zum Objekt wird dann für die neue Höhe verwendet. So würde ich auch das neue Kommando gestalten. Als Parameter wird ein 3D-Punkt angegeben, von dem ein Strahl nach unten gesendet wird. Zurück wird die 3D-Koordinate des Kollisionspunktes gegeben, falls eine Kollision stattfindet. Zusätzlich wird noch der Normalenvektor an dieser Stelle zurückgegeben, damit man das Objekt auch entsprechend anstellen kann.

Wäre das was für euch?

Viele Grüße,

Neo

Geschrieben

Hallo,

... so erhellend bin ich nun auch wieder nicht... aber das Getriebe gibt schon ein paar Töne von sich...

@Neo

Normalvektor zuerst ... und wenn es natürlich möglich wäre das Ergebnis meherer "Pings" zurückzugeben (sortiert ?... größte zuerst (für das Oberflächenfahren)), so könnte man z.B. wenn eine "Deckplatte" vorhanden ist auch einen "echten" 3D-Schnitt erzeugen (Spantenriss)...

Gruß

EASY

Geschrieben

Hallo Neo,

die Grundsteuerung für den Bagger ohne Gleise zu steuern ist schon soweit fertig und bewegt sich auf der Bodenplatte (solange gleiche Höhe) einwandfrei.
Jedoch habe ich mich wohl direkt mit einer etwas schwierigeren Animation beschäftigt, denn es ist sehr schwer die richtige Anzahl an Frames und die richtige Schrittweite in der Schnittstelle zu wählen.
Obwohl ich das Script durch Neustrukturierung redlich verkleinern und auch durch Einsatz von Gruppenkommandos das Ganze etwas auf Tempo bringen konnte, ist immer noch ein geringfügiges Ruckeln ( bei Nahzoom) feststellbar.

Wenn nun noch die Berechnung der Bodenplatte an den 4 Außenpunkten des Modells dazukommt, bin ich gespannt, ob die Geschwindigkeit der Kommunikation mit dem MBS dann noch ausreichend ist, ohne die Anzahl der Frames(Sek.) zu verringern.

Erwartungsvoll auf den neuen Befehl grüßt der Seehund

 

Geschrieben

Hallo Seehund und Easy,

ich denke, ich werde noch diese Woche eine Testversion veröffentlichen können, mit der ihr das neue Kommando ausprobieren könnt.

@Seehund
Flüssige Animationen sind schon eine neue Art der Herausforderung, am besten du schickst mir mal deinen Plugin-Code, dann kann ich auch mal einen Blick drauf werfen und eventuell Schwachstellen bei der Steuerschnittstelle ausmerzen.

Viele Grüße,

Neo

Geschrieben

Hallo Neo,

arbeite gerade noch an  einer neuen Animation der Ketten, dafür muss ich aber auch noch eine neue Textur erstellen, die Koordinatengerecht ist. Ziel ist, eine 180° Animation auf 36° zu bringen. Normal kein Problem, aber dafür muss auch die Textur passen.

Es kann also noch etwas dauern, bis ich dir den Bagger und das Script zusende.

Gruß Seehund

Geschrieben

Hallo Seehund,

du kannst dir hier eine neue Beta-Version herunterladen, die ein neues Kommando enthält:

  • 132 - Berechnet den Kollisionspunkt eines Strahls. Parameter 1-3: Startpunkt (X, Y, Z). Parameter 4-6: Richtung (X, Y, Z), Parameter 7: Optional, Beschränkung der Kollisionsberechnung auf ein konkretes Objekt

Der Befehl ist recht allgemein gehalten und kann genutzt werden, um eine beliebige Kollision in der Szene zu berechnen. Für deine Höhenermittlung kannst du den Befehl z.B: so anwenden:

132;0;0;50;0;0;-1;Bodenplatte

In diesem Fall wird von der Position "0, 0, 50" ein Strahl nach unten gesendet (0, 0, -1) und eine Kollision mit der Bodenplatte ermittelt. Das Kommando gibt im Erfolgsfall die Koordinate der Kollision (X, Y, Z) zurück.

Viele Grüße,

Neo

Geschrieben

Hallo Neo,

danke für die schnelle Hilfe. Habe dir per Mail das Script für die Steuerung und das dafür geänderte Modell gesendet.

Werde den neuen Befehl sofort austesten.

Gruß Seehund

@ 1. Test:

Bei Senden der Fahrzeug-Höhen-Position erfolgt ObjektOutOfRange-Fehlermeldung. Gesendete Höhe muss immer über dem Fahrzeug sein und Parameter 7 ist dann aber erforderlich. Zur Berechnung der Bodenplatte muss der Boden selbiger deaktiviert sein.

 

Geschrieben

Hallo Neo,

Ping:) ... bin begeistert:D ...Ping... Ping... Ping...:PB| (ich hoffe es ist für mich ohne bleibende Schäden...)

... meine ersten Versuche ergeben folgendes...
Bei einem Ping auf eine Bodenplatte, kann ich mich sowohl außerhalb als auch innerhalb der Platte befinden und bekomme eine absoluten Wert der jeweiligen Oberfläche und nach meinen bisherigen Versuchen, werden "Löcher" in der Bodenplatte als nicht vorhandene Oberfläche erkannt. Ist diese Interpretation meiner bisherigen Messungen richtig?

... wenn ich z.B. einen Quader (Grundkörper) bepinge, kann ich die Oberfläche "nur" von außen erfassen (kein Wert, wenn ich mich innerhalb befinde)... gilt dieses Verhalten prinzipiell für alle Modelle?

... oder kann ich einfach davon ausgehen, daß wenn ich mit der Kamera in ein Objekt gehe und eine Fläche sehe, diese auch durch den Ping erfasst wird... und wenn ich von innen nach außen durchsehen kann, wird auch die Fläche nicht "erkannt"?

... und die letzte Frage stelle ich einmal ganz vorsichtig: ist es mit einem größeren Aufwand verbunden, dem Ping noch einen Richtungsvektor (Drehwinkel) mit auf den Weg zu geben?...

Gruß
EASY 

Geschrieben

Hallo,

@Seehund
Kannst du kurz beschreiben, was es mit der "ObjektOutOfRange-Fehlermeldung" auf sich hat? Wird sie von der Steuerschnittstelle zurückgegeben? Im Moment ist mir so eine Fehlermeldung nicht bekannt. Wie sieht dein Befehl aus, den du an die Schnittstelle übergibst?

@Easy
Die Grundregel gilt, jede Fläche, die du siehst, kann auch von dem Strahl getroffen werden. Löcher von Bodenplatten sind echte Löcher, wo der Strahl durchgeht, der Strahl trifft dann den Boden der Platte.

Was meinst du mit Richtungsvektor? Die Parameter 4-6 geben doch bereits die Richtung des Strahls an.

Viele Grüße,

Neo

Geschrieben

Hallo Neo,

du hast doch das VB-Script, dort ist der Befehl 132 ja vorhanden. Mein Problem ist:
Wenn Bodenplatte z=0 ist, stelle ich den Bagger auch auf Höhe z=0. Wenn ich dann den Ping aus der Höhe des Baggers sende, kommt es beim Debugging im Visual-Studio 2013 zu der Fehlermeldung -ObjectOutOfRange-.
Sende ich den Ping aus z=200, ist der Parameter 7 Name des Objekts zwingend erforderlich, da ich ansonsten den höchsten Punkt der Außenhaut des Baggers zurück bekomme. Mit fester Höhe z>0 funktioniert Alles.

Sende ich den Ping z:B.: z= -2 dann muss ich den Boden der Bodenplatte deaktivieren, da ich ansonsten deren Wert bekomme.

Hatte heute wenig Zeit weiter zu machen, mal sehen was morgen noch alles passiert. Auf jeden Fall fährt der Bagger, zwar noch waagerecht, schon über den Berg.

Gruß Seehund

Geschrieben

Hallo Neo,

Zitat

Was meinst du mit Richtungsvektor?

... einfaches Beispiel: Ich nehme eine Lok, die auf einem Gleis fäht als Bezugspunkt für die Position. Die Lok befindet sich in einem Tunnel... Nun würde ich gerne die Tunnelbreite "messen"... dazu müßte ich einen Ping im Winkel von 90 Grad zur Fahrtrichtung aussenden... Da die Lok nicht zwingend genau in x oder y Richtung fährt, bekomme ich keine Messzung zustande, da der Ping "stur" in x oder y Richtung gesendet wird (bezogen auf die Welt).... Der Ping müßte also so "gestaltet" sein, daß seine Bezugskoordinatensystem der Drehung folgt...

@Seehund: für mich ergeben sich (so aus der Ferne) aus der Fehlermeldung 2 Möglichkeiten:

- wenn die Schnittstelle kein Parameter zurücksendet gibt es ein Problem bei der Auswertung
- die Schnittstelle liefert bei 0 manchmal einen sehr kleinen Wert der sich von 0 unterscheidet... -> Variablentyp in der Antwortauswertung?

... wie gesagt nur so aus der Ferne...  Du kannst Dich gerne mit mir in Verbindung setzen...

Gruß
EASY
 

Geschrieben

Hallo Easy,

das eigentliche Problem liegt darin, das jede neue Zeile im Script, sei es die Berechnung oder auch die Fehlerermittlung,  verändert den Zeitraum bis der eigentliche Befehl zur Positionierung des Modells gesendet wird.
Somit muss bei jeder neuen Zeile die Animation und auch die Schrittweite im Script neu eingegeben werden, Dies kann nur durch Austesten geschehen, denn ich wie soll man so etwas in einer Formel berechnen.
Bei der Animation von einer Raupenkette kann ich nicht auf RadAnim oder _AnimWheel zurückgreifen da hier die linke und rechte Kette getrennt animiert, da sie beim Drehen gegenläufig sind.

Du siehst, das Problem liegt zu Eins bei der Zeit zwischen Start der Animation und Positionierung des Modells, zu Zwei bei der Synchronisation zwischen Animation und Schrittweite, damit das Kettenglied beim Fahren am gleichen Fleck bleibt.

Wäre es möglich, die Fehlerauswertung schon im Client-Modul unterzubringen?

Gruß Seehund

Geschrieben

Hallo Easy,

die Richtungsangabe (Parameter 4-6) ist bereits ein Vektor. Es gehen also auch Werte wie z.B. 0.3;0.8;-0.2 (der Vektor wird vom Studio nochmal normalisiert). Wenn du nun einen Vektor in Abhängigkeit der Lokrotation aufstellen willst, kommt ein bisschen Mathematik ins Spiel:

  • Hol dir mit Kommando 104 die Rotation der Lok um die 3 Achsen
  • Für eine Lok, die auf der XY-Ebene fährt, ist nur die Rotation um die Z-Achse von Interesse
  • Der Richtungsvektor für den Ping ist nun: Sin(Z-Rotation), Cos(Z-Rotation), 0
  • Addiere oder subtrahiere etwas von Z-Rotation, um den Richtungsvektor zu drehen

@Seehund
Ich werde wohl erst Anfang kommender Woche dazu kommen, mich mit deinem Skript auseinander zu setzen, dann schau ich mir mal, welche Möglichkeiten es noch alles gibt.

Viele Grüße,

Neo

Geschrieben

Hallo Easy,

habe dir eine Email geschickt. Bin gerade dabei, die Geländeanpassung  zu schreiben. Durch die hohe Anzahl an "Send_Commands" und deren Rückgabewerte wird die Bewegung des Baggers immer langsamer. Auch wurden ein paar Rückgabe-Parameter verschluckt, sodass ich ein kurzes "Sleep" eingeben musste.
Die Berechnung der Rotation der X,Y-Achse des Modells wird wohl die Animation zu langsam machen.

Gruß Seehund

Geschrieben

Hallo Neo und Easy,

es wird wohl bei der einwandfrei funktionierenden, freifahrende Steuerung (ohne Gleise) des Baggers auf ebener Fläche bleiben müssen, da die Berechnung der Rotation für die X,Y-Winkel des Modells zwar gelungen ist, jedoch verlangsamte sich der Ablauf durch die hohe Anzahl an "Send_Commands" , deren Rückgabe und der etwas komplexen Berechnung fast bis zum Stillstand. Bei einer dadurch erforderlichen Schrittweite von 2,5 mm um eine normale Fahrbewegung zu erzielen, springt das Modell nur noch Position zu Position.

Nicht nur die Rotation am Berg muss berechnet werden, sondern auch noch die Höhe des Modells, damit sich an einer beginnenden Steigung die Ketten nicht in die Bodenplatte fressen.

Momentan bin ich mit meinem Latein am Ende, aber vielleicht hat unser EASY ja noch etwas auf Lager.

Gruß Seehund

Geschrieben

Hallo Easy,

danke für dein Angebot, ich werde sobald ich eine Antwort von Neo bekommen habe, bestimmt noch mal auf dich zu kommen. Es gibt nämlich ein kleines Problemchen mit der Z-Achse, die sich je nach Befehl der X- oder Y-Achse ändert, obwohl ein fester Z-Wert gesendet wurde. Der Z-Wert bleibt nur konstant, wenn x- und Y = 0 sind.

Gruß Seehund

Geschrieben

Halo Seehund,

... schön, dann sind wir schon zu zweit... da bei gleichzeitigem Setzen von x und y Winkeln die z-Achse "taumelt" ist mir das "Verhalten" schon klar... nur über einen Tip für das was mathematisch dahintersteckt, wollte ich Neo auch schon ansprechen, da ich mich momentan (auch) etwas intensiver mit dem "Ping" beschäftige (wenn auch mit einem anderen Hintergedanken...) habe aber prinzipiell (mathematisch gesehen) auch noch ein Problem mit der Drehung um alle drei Achsen)...

Gruß
EASY

Erstelle ein Benutzerkonto oder melde dich an, um zu kommentieren

Du musst ein Benutzerkonto besitzen, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen.

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde dich hier an.

Jetzt anmelden
×
×
  • Neu erstellen...