Koordinaten-Feedback an LUA/Model: (Rollen-) Stromabnehmer

[~cab]

Hallo,

weder gibt es O-Busse noch entsprechende andere Fahrzeuge mit Rollenstromabnehmern — und das wird wohl auch immer so bleiben.

Alle anderen E-Fahrzeuge mit Stromabnehmern behelfen sich mit einer "MBS-genormten" statischen Höhe und die Oberleitung ist aktuell nur deshalb ein Spline, damit man es einfacher konfigurieren kann — aber technisch betrachtet handelt es mit jedem dieser Splines um ungenutztes Potential.

Nimmt man die aktuellen Gegebenheiten, dann könnte Spline 1 das Gleis, Spline 2 eine Oberleitung, Spline1-User ist das Fahrzeug, Spline2-User könnte die Schleifkohle (_CP_Spline) sein. Schleifkohle folgt Fahrzeug. Das ganze kann man jetzt schon bauen. Nur der bewegliche Teil dazwischen fehlt: denn das ist imho inverse Kinematik und ich finde es verständlich, dass man auf Grund der Komplexität (entweder richtig oder gar nicht, und dann sind wir bei Bones) lieber die Finger davon lässt.

Aber: Stromabnehmer!1111elf

Ja, ich weiß: es gab Bahnen mit Unterstromzufuhr — aber nur punktuell, versuchsweise, gleiches für Akku-Bahnen.

Ich überlege mit welchem "Hack" man auf derartige Kinematiksachen verzichten kann. Da stolperte ich letztens in diesem Forum nach Animations-Stop über LUA, damit man skripten kann, dass der Stromabnehmer zu Frame X gehen soll, damit er keine Wände im Betriebshof einreißt.

Der Vorschlag ist aber nicht befreidigend, da ich dann erst ausrechnen muss, wie schnell das Fahrzeug ist, wie die Neigung der Oberleitung zur Schiene ist etc. um dann manuell den Frame anzuspringen — worüber eigentlich? Mit einem Fahrzeug-betritt-Gleis-Event? Alle 5mm ein Stück Gleis für ein neues Event: setze Stromabnehmer auf Frame 0.345? Oder mit einer Horde Timeout-Funktionen, die im 1s/24-Takt den Frame setzen? Und wenn ich 6 Monate später beschließe, das Fahrzeug soll mit 2km/h weniger auf den Betriebshof fahren, weil dort jetzt neue Weichen liegen, die nicht mit mehr als 4km/h befahren werden wollen, dann ändere ich 100-Timeout-Funktionen? Animationsstop via LUA ist zwar nice, aber nicht hierfür: derartiges für Stromabnehmer klingt nach Anti-Pattern…

Etwas ähnliches kam mir aber auch schon in den Sinn, geht aber in eine andere Richtung und lässt sich aktuell nicht umsetzen. Das Thema des Threads könnte sein:
Ich möchte via LUA mit den Koodinaten zweier Objekte spielen und über die Differenz einen Frame ansteuern.

Ich habe das noch nicht zu Ende gedacht und eventuell denke ich auch falsch:
Die Zutaten sind irgendwas mit Fahrzeug-Koordinaten (o. g. Spline-User1), zugehörige Zielkoordinaten an der Oberleitung (Spline-User2). Aus diesen beiden Koodinaten kann man dann die Soll-Höhe der Schleifkohle ermitteln und einen passenden Frame für die Stromabnehmerhöhe ansteuern. Das funktioniert am einfachsten wenn der Stromabnehmer in der Fahrzeugmitte sitzt, dann brauch ich nur die Z-Achse — in anderen Fällen steht die Distanz relativ zu den Fahrzeugkoordinaten.

Bei Rollenstromabnehmern funktioniert das anders, denn der Rollenstromabnehmer ist drehbar gelagert. Das Problem ist hier eher nicht die Berechnung der Distanz zwischen Schleifkohle und Stromabnehmer-Halterung, sondern der Umgang mit der Animation/den beweglichen Teilen, denn es sind 2: um die Z-Achse sowie auf und ab. Es wäre ein bisschen heavy die Animationen in 2 Ebenen für 180°-Z-Achse mit jeweiligem Höhenwinkel zu rendern: 180° Z-Achse × (nur!) 45° Höhe = 8100 Frames
Einfacher wäre es Rotation ist Softwareseitig über ein spezieles Objekt gelöst, dass sich um die Z-Achse dreht. Der Rest wäre dann wie bei "normalen" Stromabnehmern: auf und ab.

Um das alles allgemeiner zu machen gibt es ein neues Objekt am Fahrzeug, dass seine eigenen Koordinaten mit sich herum trägt, falls der Stromabnehmer nicht in der Mitte des Fahrzeuges auf dem Dach montiert ist und entsprechend abweichende Koordinaten hätte. Zwei weitere für Soll- und Ist-Koordinate der Schleifkohle. Derer Daten kann ich abgreifen und aus der Differenz gezielt einen Frame für die Höhe ansteuern. Selbst wenn diese Spielerei nur alle 6 Frames berechnet würde, wäre das besser als gar nichts zu haben.

Die Objekt-Hierarchie könnte dann so aussehen:
1. Fahrzeug (weiß jetzt schon wo es auf der Platte ist)
1.1 spezielles Empty#1 für Stromabnehmerhalterung wird am Gelenkmittelpunkt/Dach des Strobamnehmers positioniert (optional rotierbar um Z-Achse, weiß wo es sich am Fahrzeug befindet -> weiß wo es sich auf der Platte befindet, hat Tuple XYZ)
1.1.1 spezielles Empty#2 für Soll-Position Schleifkohle (kollidiert immer mit Splines oberhalb Empty#1, hat Tuple XYZ)
1.1.2 Modell Stromabnehmerhalterung
1.1.2.1 Modell Stromabnehmer (animiert auf/ab, Frame für Höhe via LUA aus… Empty#2-Empty#1… oder so)
1.1.2.1.1 Modell Schleifkohle
1.1.2.1.1.1 spezielles Empty#3 für Ist-Position Schleifkohle (positioniert an Oberseite der Schleifkohle, macht erst was, wenn Toleranzbereich Spline betreten wird, hat Tuple XYZ)

-> Fahrzeug kommt auf Gleis: Empty#1 ist am Dach, Empty#2 dockt sich am Spline oberhalb des Fahrzeuges an. Beide wissen wo sie sind
-> Animation "Stromabnehmer auf" wird gestartet
-> Empty#3 kommt in Toleranzbereich für Oberleitungs-Spline, und erhält ein Bit "angelegt". Ab diesem Moment wird errechnet wie weit die Animation vor-zurückgespielt werden soll, um annähernd an #Empty2 zu kommen
-> Update alle 0,1s oder so, dann wird die Animation entsprechend vor-/zurückgespielt.
-> Berechnungen werden gestoppt wenn Fahrzeug steht
-> Bit "angelegt" wird entfernt/Berechnungen werden gestoppt wenn "Strobabnehmer ab" abgespielt wird.

 

Irgendwie… Ist dieser Ansatz diskussionswürdig?

Gruß ~cab.

Bearbeitet 26. Februar 2020 von ~cab
tippitappi

[HaNNoveraNer]

Hallo cab

>>> Ab diesem Moment wird errechnet wie weit die Animation vor-zurückgespielt werden soll, um annähernd an #Empty2 zu kommen <<<
Das ist der Knackpunkt.
Das ganze könnte man auch auf den Lenkeinschlag eines Autos anwenden, um die Vorderräder entsprechend dem Radius des Spline zu bewegen.
Ich kann mir nicht vorstellen, daß man eine Animation abhängig von der Position des Fahrzeugs steuern kann.
Da müßte es eine ganz klare Schnittstelle/Definition geben, wie diese Animation auszusehen hat.
Ob dafür Performance und der Bewegungsprozess geeignet sind, kann nur EINER sagen.

Gruß
Thomas

[Andy]

Hallo,
zum Thema Animationsframes ansteuern sind schon einige Wünsche für die unterschiedlichsten Anwendungen eingelaufen, sodaß ich denke, dass sich da schon was tun wird.

Gruß
  Andy

[~cab]

 

On 2/26/2020 at 3:39 PM, HaNNoveraNer said:

Ich kann mir nicht vorstellen, daß man eine Animation abhängig von der Position des Fahrzeugs steuern kann.

Zusammengehackt sähe das irgendwie so aus:

var   = variable
const = unveränderlicher Wert

Angaben in Millimeter 1:1, ab Schienenoberkante, irgendwelche Beispielwerte

---
const Sensitiver Bereich Spline Oberleitung: S.
var   Oberleitung Unterkante:                L.
var   Sensitiver Bereich beginnt bei:        Ls = L-S.
---
Modell wird in den Katalog aufgenommen und damit eh mindestens einmal analysiert.
Diese Werte werden mit dem Modell gespeichert:

const Schleifstück Oberkante (Empty#3) b. Stromabnehmer unten: Su, definiert in Animation Frame 1.
const Schleifstück Oberkante (Empty#3) b. Stromabnehmer oben:  So, definiert in Animation Frame n.
const Schleifstück Oberkante (Empty#3) Distanz:                D = So - Su.
const Schleifstück Oberkante (Empty#3) Distanz pro Frame:      Df = D/Frame n.
---
Beispiel:

Modell mit linearer Animation für den Stromabnehmer über 60 Frames wird in den Katalog geladen;
diese 4 Werte ändern sich nicht mehr:

const Su sei 3900 @ Frame 1
const So sei 7000 @ Frame 60
const -> D = 7000-3900 = 3100
const -> Df = 3100/60 = 51,66666 (pro Frame bewegt sich der Stromabnehmer also um ~51,66666mm auf-/abwärts.


Modell wird auf Anlage gezogen:

var Distanz, die sich der Stromabnehmer aktuell bewegen kann: d.

a) Fahrzeug steht irgendwo (Empty#2 findet keinen Spline oberhalb seiner selbst):
   -> d = D = 3100.
   -> Fmin = 1
   -> Fmax = 60
      Bei "Animation abspielen" wird die Animation von Frame Fmin (Su) bis
      Frame Fmax (60 [×Df+Su=So=7000]) abgespielt.

b) Fahrzeug steht unterhalb Oberleitung (Empty#2 hat sich an Oberleitungsspline angedockt):
L sei 5800 bei Koordinate X/Y.
S sei  400.
   -> die Animation steht nicht auf Frame 1
      -> dann gilt der Stromabnehmer als angelegt:
         -> d = L-Su = 5800-3900 = 1900.
         -> und das Schleifstück (Empty#2) steht irgendwo zwischen Ls (5800-400=5400) und L (5800)
            -> dann prüfe, ob die Animation an einem gültigen Frame steht:
               -> Fmin = 1
               -> Fmax = d/Df = 1900/51,66666 = 36,77419 = 36
                  (besser Luft nach oben, als dass der Stromabnehmer über der Fahrleitung hängt.)
                  
                  Bei "Animation abspielen" wird die Animation von Frame Fmin (Su) bis
                  Frame Fmax (36 [×Df+Su=5760=~L=~5800]) abgespielt.

                  Ohne die Möglichkeit zu berücksichtigen, dass MBS "zwischen den Frames" abspielen kann,
                  ansonsten die 36,77419 auf den entsprechenden float umrechnen.

            -> mach das alles noch einmal, sobald sich die Koordinaten des Fahrzeuges ändern, synchron oder alle 1s/5=0,2s…,
            -> wenn der Kontakt zum Spline abbricht oder das Schleifstück den Bereich L - Ls verlässt,
               spiele weiter bis Frame 60 und weiter wie unter a)
            -> stoppe, wenn die Animation manuell rückwärts abgespielt, weil Stromabnehmer abzezogen, wird.

So ganz ohne Bones/Collision…

Auf den ersten wart, der mir dieses Bild ins Gesicht klatscht: https://de.wikipedia.org/wiki/Datei:El_2-Industrieellok_4-1305.jpg

Beim Anblick des Bildes gällt mir auf, dass der Ansatz selbst dann funktionieren könnte, wenn man mit exotischem Zeug kommt:

Dazu müsste man das ganze Konstrukt nur um seine eigene Achse drehen — den zugehörigen Oberleitungs-Spline eben auch: Z ist dann X und der 0-Punkt nicht die Platte, sondern die Gleismitte.

Bearbeitet 28. Februar 2020 von ~cab