Hawkeye

Genau, es geht um die Fahrstrecke von Fahrzeugspitze bis zum Kontakt. Die grünen Stecken in den folgenden Bildern werden von vehicle:isheadingTowards(contact) bei Aufruf der Funktion intern ermittelt, stehen uns aber noch nicht zur Verfügung. Bisher ermittle ich die Distanz (rot) nur annähernd genau linear mit Lua. (bzw. Vorderkante/ Hinterkante der Fahrzeuge -> siehe nächstes Bild) Für die gestellte Aufgabe benötige ich einigermaßen genau die Strecken rot und gelb der Fahrzeuge , die auf denselben Kontakt zufahren und das zum gleichen Zeitpunkt. Über die aktuellen Geschwindigkeiten lässt sich dann ermitteln, welches Fahrzeug den Kontakt zuerst erreicht und welches ggf. abgebremst werden muss, um eine Kollision zu vermeiden. VG, Hawkeye

Hallo Götz, sorry, ich dachte das erkennt man am Thema des Threads und der Antwort von Neo vom 26. Juli. VG, Hawkeye

Hallo @Neo , mal vorsichtig gefragt, wann gibst du den Zugriff auf die Strecke bei dieser Funktion frei? Ich probiere jetzt schon eine ganze Weile an dem Thema "Schnittstelle von Fahrspuren". Die erforderlichen Längen (Vorderkante/Hinterkanten der Fahrzeuge) ermittle ich bisher nur linear, was gerade bei den unterschiedlichen Kurvenradien an Kreuzungen zu verfälschten Ergebnissen führen kann. Auf der Testanlage macht das noch keinen Unterschied, da hier beide Spuren den gleichen Fehlbetrag erzeugen. Hierzu auch mal eine erste Anlage dazu: Test Schittstelle Spuren.mbp Ziel ist es, wenn Fahrzeuge auf Kollisionskurs sind, ein Fahrzeuge rechtzeitig vor der Schnittstelle (rot) so abzubremsen, das die Kollision vermieden, aber trotzdem der Verkehrsfluss kaum beeinträchtigt wird. Ein Fahrzeug zu beschleunigen wäre auch eine Alternative (z.B. bei einer Autobahnauffahrt). Das ist aber erst einer der nächsten Schritte und jetzt noch nicht Thema. Bisher verfolge ich den Ansatz über die Zeiten t der Fahrzeuge bis zum Ziel. Das wird aber bei sehr niedrigen Geschwindigkeiten problematisch, da bei V -> 0 t unendlich wird. Alternativ wäre der Ansatz über die Reststrecke. Der Ansatz berücksichtigt dann aber nicht, ob ein Fahrzeug weiter entfernt ist und das Ziel aufgrund seiner höheren Geschwindigkeit doch früher erreichen würde. An einem Kompromiss arbeite ich noch. (z.B. Wenn für ein Fahrzeug gilt V = 0 , dann ermittle t über die Zeit für die Beschleunigung von 0 auf 50kmh) Wer Ideen oder Anregungen dazu hat, immer raus damit. VG, Hawkeye

Hallo @wkh , Zähler sind problematisch, Timer und Verzögerungen funktionieren zuverlässig. Hier kann es nur zu Fehlern kommen, wenn während der Ausführung einer Verzögerung noch zu benutzende Variablen verändert werden. Das sollte in der Verzögerungszeit nicht passieren. Ich hatte z.B. mal festgestellt, das es bei der Verwendung von Modulvariablen in Verbindung mit Verzögerungen zu unbeabsichtigten Fehlern kommen kann, wenn sich die Modulvariable, während die Verzögerung noch läuft, ändert. Deshalb versuche ich Variablen direkt in den anzusprechenden Objekten zu hinterlegen. VG, Hawkeye

Danke Götz, stimmt, das erklärt das Verhalten im obigen Beitrag. Das hatte ich nicht mehr auf dem Schirm. Dann ist es für den Straßenverkehr gerade bei langen Fahrzeugen (Gelenkbus, Sattelschleppern oder Fahrzeugen mit Anhängern) besser auf diese integrierte Funktion im Kontakt für die Beschleunigung von Fahrzeugen zu verzichten und für ein Kfz eine höhere Geschwindigkeit über das entsprechende Ereignis in der EV zu definieren. Dann entfällt die beschriebene Wirkung. VG, Hawkeye

Hallo @alexander42 , Danke für den Tipp. Aber diesen Effekt kann ich ausschließen, da sich die Einstellungen an den Gleiskontakten nicht verändern. Gebremst wird bei dieser Steuerungsvariante erst, wenn das Fahrzeug den Kontakt betritt. Deshalb stelle ich an einem Stoppkontakt einen festen Wert für die Zielgeschwindigkeit (15 km/h) ein. Bei einer planmäßigen Verzögerung von 5 m/s² sind es bis zum Halt keine 2m . Ich habe aber jetzt mal die tatsächlichen Geschwindigkeiten der Fahrzeuge gemessen, wenn das Ereignis "Stoppkontakt wird betreten" ausgelöst wird. Und da ich bin doch sehr überrascht. Das die Fahrzeuge nicht exakt auf die am Kontakt eingestellte Geschwindigkeit (hier: Abbremsen auf 15km/h) abbremsen, hatte ich schon vermutet und eine gewisse Toleranz angenommen. Aber das die Ist-Geschwindigkeit eines Fahrzeuges teilweise um mehr 5 km/h (!) abweichen kann, damit habe ich jetzt auch nicht gerechnet. Das hat natürlich Auswirkungen auf den Bremsweg, da die Ist-Geschwindigkeit im Quadrat in die Bremsweg-Berechnung eingeht. Deshalb gebe ich jetzt den Bremsweg als Variable im Kontakt vor und verändere am Fahrzeug den Wert für die Verzögerung. Dadurch sollten die Fahrzeuge zukünftig auch an der geplanten Stelle anhalten. Durch die Veränderung der Verzögerung an Fahrzeugen kann es aber bei nachfolgenden Fahrzeugen wiederum zu Problemen führen. Mal sehen, ob das Auswirkungen hat. Hallo @Neo , hier noch ein Hinweis zu einem Effekt den ich nicht so ganz verstehe: Fahrzeuge, die (im Stau) auf einem Kontakt anhalten, der einem Fahrzeug eine Beschleunigung (hier auf 80 km/h) zuweist, versuchen diese Geschwindigkeit zu erreichen (siehe grüner Balken in dem Steuerungsfenster), solange sie noch auf dem Kontakt stehen. Das flackert heftig und wird im Protokoll auch vermerkt. Ist das ein gewolltes Verhalten? Wenn ja, warum ? Es reicht doch, wenn das einmalig am Kontakt bei ("Betreten", Fahrzeugmitte", "Beim Verlassen") einstellt werden kann. Durch dieses Verhalten ist doch automatisch "Beim Verlassen" des Kontaktes eingestellt, so das ich gar keine Entscheidungsfreiheit über die EV habe. Oder sehe ich da was falsch? VG, Hawkeye

Hallo @wkh , danke. Ja, leider. Eine Ursache dazu habe ich schon herausgefunden. Manchmal fahren sehr kurze Fahrzeuge zu weit in die Kreuzung ein und blockieren dadurch die Kreuzung (warum auch immer ). Eigentlich sollen "wartenden" Fahrzeuge noch gerade so auf dem Stoppkontakt zum Stehen kommen. Das gilt hier leider nicht für den gelben Golf. Wenn für ein Fahrzeug gilt: "V = 0" und "steht auf einem Stoppkontakt" dann wird das Fahrzeug von der Steuerung ignoriert. Dieses Fahrzeug (hier der gelbe Golf) muss dann leider manuell etwas zurückgeschoben werden. Ich werde mal überprüfen, ob die "automatische Beschleunigung" an diesen Fahrzeugen rechtzeitig ausgeschaltet wird und die Fahrzeuge deshalb ggf. durch die Beeinflussung von anderen Fahrzeugen in unmittelbarer Nähe unbeabsichtigt in die Kreuzung hineingezogen werden. Da sind noch einige kleine Fehlerchen auszubügeln und Feinabstimmungen erforderlich. Tue ich nicht. Es wird nur die Situation an der jeweiligen Kreuzung betrachtet und gesteuert. Die Richtungsauswahl der Fahrzeuge erfolgt hier rein zufällig. Mir geht es im Gegenteil genau darum, Zähler im Straßenverkehr zu vermeiden, da sie störanfällig sind! Den Zähler-Ansatz haben viele Mitglieder versucht und sind, genauso wie ich auch, daran gescheitert. Deshalb musste ein neuer Ansatz her. Auch die Gesamtlänge aller Fahrzeuge auf einem Streckenabschnitt wird von mir nicht berücksichtigt. Das ist aber ein interessanter Ansatz um Rückstaus in eine Kreuzung zu vermeiden. Sollte sich unter den Fahrzeugen jedoch ein Bus befinden, der zu einer Haltestelle fahren will, dann wird er aber wegen "Überfüllung des Streckenabschnitts" keinen Umweg machen wollen. Die Fahrzeuglängen benötige ich nur für die Abstandskontrolle an den Trennstellen der Spuren einer Kreuzung. An diesen Stellen unterliegen hintereinander fahrende Fahrzeuge, die auf verschiedenen Spuren weiterfahren nicht mehr der automatischen Kontrolle, sobald das Fahrzeugzentrum die Trennstelle der Spuren überschritten hat. Der Audi TT würde ohne diese zusätzliche Abstandskontrolle durch den noch haltenden abbiegenden Golf hindurchfahren. Neue Ansätze, wie der Straßenverkehr im MBS verbessert werden kann, sind immer willkommen. VG, Hawkeye

Danke für die Info. Dann werde mit meiner selbsterstellten Liste weitermachen. VG, Hawkeye

Hallo @Neo , eine Frage habe ich noch zu dieser Funktion. Wird intern auch bereits eine Liste von Fahrzeugen angelegt, die aus verschiedenen Richtungen auf einen Gleiskontakt zufahren? Bisher erstelle ich mir eine solche Liste selbst. Es wäre aber schön, wenn auch hier auf die Informationen einer intern vorhanden Liste zurückgegriffen werden könnte. VG, Hawkeye

Gute Idee, hatte ich auch schon mal. Und habe ein Universal-Objekt (mit Antrieb) gebaut, das aus mehreren Teilen besteht und mit dem man alle Bewegung, um die 3-Achsen beliebig ausführen kann. Ich habe das Objekt aber nie veröffentlicht, weil der Zusammenbau der einzelnen Komponenten über die Kontaktpunkte nicht immer reibungslos funktioniert hat und vor allem, weil jede Bewegung um die Achsen in der EV einzeln programmiert werden musste. Vorwärts/ Rückwärts, wann beginnen, wann stoppen, wie schnell soll die Bewegung ausgeführt werden, etc in Kombination mit der Fahrgeschwindigkeit. Viel zu kompliziert. Der Programmieraufwand ist enorm. Daher: Hier ein Link zum damaligen Test. VG, Hawkeye

Hallo @Talima , wie ich an deiner Testanlage sehen kann, hast du auch versucht, das Seilbahnprinzip anzuwenden. Dabei hast du den entscheidenden Faktor, die Kamera vergessen (oder nicht mit kopiert). Die Kamera sorgt bei Verknüpfung der Objekte in der richtigen Reihenfolge untereinander dafür, das ein Objekt, hier ein Fußgänger immer senkrecht bleibt. Der Dummy wird mit dem SX1 verknüpft. Die Kamera mit dem Dummy. Der Fußgänger mit der Kamera. Für diese Konstellation ist es erforderlich, das SX1, der Dummy und die Kamera auf einer Achse liegen. VG, Hawkeye

Hallo Rotti, Schalte mal die automatische Verzögerung bei deinem Handwerker auf der großen Treppe aus. Dadurch läuft er bis an das Ende eines Spurstückes. Hier am Beispiel deines vorderen Handwerkers. Dadurch erkennst du die Stellen besser, wo es hackt. Deine Verbindungen mit den Portalen sind, soweit ich das erkennen kann, in Ordnung. Aber im Grunde ist es das gleiche Problem wie oben. Ich hatte ja schon geschrieben. Wenn es mit den 3mm stellenweise dann doch nicht funktioniert, dann musst du die Länge wieder vergrößern. Nur so nebenbei erwähnt. Ich bin kein Fan von dieser Art des Treppensteigens. Es ist mir zu aufwendig zu erstellen, zu fehleranfällig und sieht durch das "Beamen" von Stufe zu Stufe auch nicht besonders natürlich aus. Aber das ist nur mein Eindruck von dieser Technik. Wen es dir aber gefällt, dann must du dir die optimalen Einstellungen bis es richtig klappt, selbst ermitteln. Du arbeitest hier aber im Grenzbereich des MBS. VG, Hawkeye

Hallo @Neo, einige Beiträge hier im Forum nehmen in letzter Zeit mal wieder an Schärfe zu und werden zum Teil immer persönlicher. Dies passiert eigentlich in unregelmäßigen Abständen immer wieder mal und es sind leider sehr häufig die gleichen Forumsteilnehmer daran beteiligt, die sich nicht zurückhalten können, sich in ein Thema hineinsteigern und verbeißen können. Interessant aber ist, dass es sich hierbei auch um Forumsteilnehmer handelt, die dein Vertrauen genießen und dich hier im Forum tatkräftig durch Hilfestellung in der Beantwortung von Fragen und der Entwicklung von Videos und Modellen unterstützen, damit du dich auf andere wichtige Dinge, wie die Weiterentwicklung des MBS konzentrieren kannst. Klar, du benötigst diesen Kreis. Er ist für das MBS, für dich und das Forum unverzichtbar und jeder hier im Forum ist für ihre objektive und sachliche Hilfe dankbar. Ich finde aber, dass diese Forumsteilnehmer, gerade weil sie eine Sonderstellung einnehmen, dich auch repräsentieren und man davon ausgehen könnte, dass sie aufgrund ihrer Präsens hier im Forum deine Meinung vertreten. Daher denke ich, dass sie gerade in Bezug auf ihre Sonderstellung doch mehr darüber nachdenken sollten, wie sie hier Forum auftreten, antworten und argumentieren. Ich habe mich hier auch gerne eingebracht, vielleicht auch mal den falschen Ton getroffen, aber immer versucht sachlich zu bleiben. Wenn ich aber solche Beiträge wie in den letzten Tagen lese, vergeht mir wieder die Lust mich hier einzubringen und mich in meiner Freizeit mit dem MBS zu beschäftigen, leider. Deshalb solltest du dir vielleicht mal überlegen, ob du nicht einen „Code of Conduct“ für deinen Vertrauenskreis einführst. Es besteht sonst die Gefahr, das du Kunden verlierst! VG, Hawkeye

Hallo @tim-fischertechnik , nur als kleiner Tipp. Du kannst das Nachwippen auch schon in Blender mit "Bounce" definieren. VG, Hawkeye

Hallo Brummi, ist dir die Angabe im Profilbild zu ungenau? VG, Hawkeye

Das wäre klasse, danke @Neo 👍

Hallo @EASY , das habe ich eigentlich versucht mit den Bildern der Testanlage oben darzustellen. Treffen Fahrzeuge an zwei zusammenlaufende Spuren aufeinander, dann wirkt die Fahrphysik des MBS noch nicht, solange sich die Fahrzeuge noch auf den getrennten Spuren befinden. Das führt zu unschönen Kollision. Auf der Testanlage oben ändern Fahrzeuge bei solchen Kollisionen sogar ihre Fahrtrichtung, so das man manuell eingreifen und einzelne Fahrzeuge wieder neu positionieren muss. Durch die Geschwindigkeiten und die Reststrecke der Fahrzeuge zum selben Zeitpunkt kann ich ermitteln, welches der Fahrzeuge A oder B zuerst am „Treffpunkt“ also dem Zielkontakt ankommt und daraus berechnen, wie weit das andere Fahrzeug z.B. Fahrzeug B abgebremst werden muß, damit es sich hinter Fahrzeug A „einreiht“, ohne das beide kollidieren. Oben im Bild z.B.: Der rote Bus auf der Geraden und der blaue Bus in der Kurve fahren jeweils 50km/h. Beide sind auf Kollisionskurs. Die Zeit zum Schnittpunkt wird für beide berechnet und das Fahrzeug mit der höheren Fahrzeit zum Ziel (z.B.: B) wird auf eine Geschwindigkeit abgebremst, die es ermöglicht, das es mit einen Abstand von ca. 3-5m hinter dem ersten Fahrzeug (A) den Zielkontakt erreicht. Sollte sich hinter dem roten Bus noch ein Fahrzeug C befinden, soll C dann auch, falls notwendig, entsprechend abgebremst werden. Fahrzeug B soll sich dann also zwischen A und C einreihen. Im Prinzip muß ich nur noch die Streckenermittlung optimieren, die ist mit noch zu ungenau. VG, Hawkeye

Hallo @Neo , ich habe einen Wunsch. Ist es möglich, die Methode vehicle:isHeadingToward(object) um die Option und Rückgabe der Strecke in [m] zu erweitern, um die tatsächlich noch zu fahrende Strecke eines Fahrzeuges zurückzugeben. Im Moment (missbrauche ) bzw. verwende ich dazu die Fahrstraßen. Aber die Strecke gilt ja nur für den Abstand zwischen 2 Gleisen oder Gleiskontakten. Befindet sich das Fahrzeug schon zwischen den Kontakten auf dem Weg zum Zielkontakt, dann muss der Restweg noch aufwändig berechnet werden. Hier mal ein Beispiel, wie das aussehen könnte. Interessant ist, obwohl es beide Varianten nicht gibt, im Ereignisprotokoll für Variante 1 mit (object, 1) kein Fehler erzeugt wird und ein Boolean-Wert zurückgegeben wird. Und bei Variante 2 die Fehlermeldung sowieso einen numerischen Wert erwartet. Diese würde ich somit auch bevorzugen. Da es auch nur um eine kurze Strecke von < 150m geht, wie bei :getVehiclesOnRoute(contact1,contact2) , dürfte doch bei der Ermittlung der Strecke bei der internen Berechnung kaum ein Performance-Verlust entstehen. VG, Hawkeye

Hallo @Rotti , dein kurzen roten Spuren sind zu kurz und viel zu kurz verträgt die MBS KI nicht. Wenn Du die Länge der Spuren per Spline-Verlängerung verändern möchtest, dann ist die kürzeste einstellbare Länge 10mm. Du hast, um die 2mm Länge für deine Stufen zu erreichen, den Gleiseditor verwendet und damit die KI ausgestrickst. In Verbindung mit den Portalen ist der Weg von Portal zu Portal über das kurze Stücke von 2mm wohl zu klein. Das passt wohl nicht zur Schuhgröße deines Bauarbeiters. Ich habe es mit 3mm für die Stufen probiert und damit beamt sich der Bauarbeiter dann auch die Stufen nach oben. VG, Hawkeye PS: Aber auch nicht immer. Die richtige passende Länge musst dir selbst ermitteln.

Uups, Das stimmt. Da habe ich beim Kopieren der Variablen nicht darauf geachtet, das auch der Inhalt vorhanden ist. Danke für den Hinweis, @Phrontistes . Nein, muss es nicht und sooo kompliziert und aufwändig ist es dann auch nicht. Man braucht nur eine zweite Liste, die alle roten Spuren zu einem Übergang enthält und die muss in alle betroffenen Spuren kopiert werden. Bis auf eine Skript-Zeile mit return geht, das dann auch komplett in der grafischen EV. Auch hatte ich es nicht für mehrere Fußgänger getestet, die ja von beiden Seiten den jeweiligen Übergang betreten. Deshalb @Thomas_103 , hier die überarbeitete Version 2 :Fußgängerübergang Thomas 02.mbp VG, Hawkeye

Danke Götz, aber dazu muß ich eingeloggt sein.🙄

Klar, wer dauernd Online ist, braucht die Funktion nicht. Ich logge mich z.B. nur ein, wenn ich einen Beitrag erstellen möchte. Ansonsten lese ich, wie wohl viele andere auch, als „Gast“ die neuen Beiträge. Kannst du man kurz erläutern, was das ist und worum es dabei geht? VG, Hawkeye

Schade, der Link ist der erste, den man aufruft, wenn man deine Forum-Seite öffnet. Also noch bevor man sich einloggt, um zuerst die letzten aktuellen Beiträge zu lesen. Jetzt klickt man ins Leere und scrollt erstmal manuell nach unten. VG, Hawkeye

Ja, aber nur der linke Teil die Funktion rechts fehlt oben. Und darauf kommt es an! Sonst scrollt man sich in manchen Threads dusselig nach unten. S VG, Hawkeye

Hallo @Neo , was mir sofort aufgefallen ist. Eine wichtige Zeile fehlt . . . . . und hab sie dann irgendwo nach langem Suchen doch noch gefunden. Ganz unten und ganz klein. Aus meiner Sicht gehört die Zeile wieder nach oben, oder es gibt eine Möglichkeit über einen Schalter direkt nach unten zu scrollen. Den neue Editor finde ich interessant. Mit sehr viel mehr Möglichkeiten. VG, Hawkeye