Hallo DEV Team - inwieweit darf ich eigene Software für die Racer teilen?

[jobia]

vor 4 Stunden schrieb THR3360:

Das kann man doch aber noch implementieren. Vielleicht ist genau deshalb auch die Frage nach der Erlaubnis des Teilens im Titel?

Mich interessiert bspw. ob es Einschränkungen in der Lenkung gibt? Kann man theoretisch seitwärts fahren? Wenn ja, dann könnte man evtl. näher an die Realität kommen, als es die Simulation schafft.

Der Porsche bspw hat einen Wendekreis von knapp über 11m in der Realität, in der Simulation kommst du nicht unter 30cm, sollten aber 26 sein...

Das sollte doch aber klar sein, dass man theoretisch seitwärts fahren kann. Tut der racer ja auch fast beim eingebremsten handbremsmanöver. Die AE rotiert ja auch so um 360grad bei der Kalibration. Alle Positionen sind im Prinzip möglich. Die Simulation regelt wie die Driftwinkel und Kurvenradien sind. Sprich diese sorgt für ein individuelles begrenztes Racerverhalten. Die Fahreinheit ist standardware, die identisch ist. Der Racer kann im Prinzip alles was die PWM Regelung und regelschleifen bzw. Lipospannung für die motorsteuerung hergibt. Nur die Kalibrierlücke bei 180 grad  dürfte bei der Überwachung, Steuerung ev. Ein Problem darstellen. Regulär wird diese Position beim Fahren nie benutzt. Ich weis nicht ob die Racerfirmware selber eine exakte 180grad fahrt zulässt, denn es fehlt ja das Auswertesegment. (Genau genommen dürfte das Problem rechts und links von 180 grad liegen) Es gibt allerdings momentan physikalische Grenzen mit dem Konzept wie wir es beim Racer umgesetzt haben. Die Tarierfeder ist unser Dritter Auflagepunkt. Dieser hebt den Hintern mit dem schweren Akku an  sorgt für realistische Lastwechsel. Steht die AE um 180grad gedreht, drückt die Feder das schwere Heck zusätzlich auf den Boden. Selbst seitliche Fahrt lässt das Fahrzeug schon seitlich stark kippen. Sehr ausgeprägt bei schlecht austarierten Umbauten. Volle 360grad Nutzung funktioniert mit dem federprinzip also eh nicht. Also original kein panzer möglich

 Dann müsste man komplett ohne feder mit perfekt in Waage liegenden Fahrzeug/ Objekt arbeiten. Dann ev. Mit kleinem stützrad vorn und hinten an der runden AE. Von daher ist es egal woher unsere bisherigen Racer ihre Steuersignale bekommen. App oder PC. Ohne mechanische Anpassung sind nicht alle Manöver möglich. Fakt ist aber mit dem was Gurkensaft gemacht hat besteht eine unabhängige Möglichkeit ganz ohne Simulationskram die racer Hardware laufen zu lassen. Jeder racer ist dann im Prinzip gleich. Gewichte, Reibung, lipostatus die eine beeinflussung haben aussen vor

Bearbeitet 21. Juni von jobia

[THR3360]

vor 3 Stunden schrieb jobia:

Das sollte doch aber klar sein, dass man theoretisch seitwärts fahren kann. Tut der racer ja auch fast beim eingebremsten handbremsmanöver. Die AE rotiert ja auch so um 360grad bei der Kalibration. Alle Positionen sind im Prinzip möglich. Die Simulation regelt wie die Driftwinkel und Kurvenradien sind. Sprich diese sorgt für ein individuelles begrenztes Racerverhalten. Die Fahreinheit ist standardware, die identisch ist. Der Racer kann im Prinzip alles was die PWM Regelung und regelschleifen bzw. Lipospannung für die motorsteuerung hergibt. Nur die Kalibrierlücke bei 180 grad  dürfte bei der Überwachung, Steuerung ev. Ein Problem darstellen. Regulär wird diese Position beim Fahren nie benutzt. Ich weis nicht ob die Racerfirmware selber eine exakte 180grad fahrt zulässt, denn es fehlt ja das Auswertesegment. (Genau genommen dürfte das Problem rechts und links von 180 grad liegen) Es gibt allerdings momentan physikalische Grenzen mit dem Konzept wie wir es beim Racer umgesetzt haben. Die Tarierfeder ist unser Dritter Auflagepunkt. Dieser hebt den Hintern mit dem schweren Akku an  sorgt für realistische Lastwechsel. Steht die AE um 180grad gedreht, drückt die Feder das schwere Heck zusätzlich auf den Boden. Selbst seitliche Fahrt lässt das Fahrzeug schon seitlich stark kippen. Sehr ausgeprägt bei schlecht austarierten Umbauten. Volle 360grad Nutzung funktioniert mit dem federprinzip also eh nicht. Also original kein panzer möglich

 Dann müsste man komplett ohne feder mit perfekt in Waage liegenden Fahrzeug/ Objekt arbeiten. Dann ev. Mit kleinem stützrad vorn und hinten an der runden AE. Von daher ist es egal woher unsere bisherigen Racer ihre Steuersignale bekommen. App oder PC. Ohne mechanische Anpassung sind nicht alle Manöver möglich. Fakt ist aber mit dem was Gurkensaft gemacht hat besteht eine unabhängige Möglichkeit ganz ohne Simulationskram die racer Hardware laufen zu lassen. Jeder racer ist dann im Prinzip gleich. Gewichte, Reibung, lipostatus die eine beeinflussung haben aussen vor

Es ist für mich alles andere als klar, wie schnell man seitlich fahren, Herr Prof. Dr. Dr. Knowitall!

[gurkensaft]

vor 9 Stunden schrieb jobia:

Das sollte doch aber klar sein, dass man theoretisch seitwärts fahren kann. Tut der racer ja auch fast beim eingebremsten handbremsmanöver. Die AE rotiert ja auch so um 360grad bei der Kalibration. Alle Positionen sind im Prinzip möglich. Die Simulation regelt wie die Driftwinkel und Kurvenradien sind. Sprich diese sorgt für ein individuelles begrenztes Racerverhalten. Die Fahreinheit ist standardware, die identisch ist. Der Racer kann im Prinzip alles was die PWM Regelung und regelschleifen bzw. Lipospannung für die motorsteuerung hergibt. Nur die Kalibrierlücke bei 180 grad  dürfte bei der Überwachung, Steuerung ev. Ein Problem darstellen. Regulär wird diese Position beim Fahren nie benutzt. Ich weis nicht ob die Racerfirmware selber eine exakte 180grad fahrt zulässt, denn es fehlt ja das Auswertesegment. (Genau genommen dürfte das Problem rechts und links von 180 grad liegen) Es gibt allerdings momentan physikalische Grenzen mit dem Konzept wie wir es beim Racer umgesetzt haben. Die Tarierfeder ist unser Dritter Auflagepunkt. Dieser hebt den Hintern mit dem schweren Akku an  sorgt für realistische Lastwechsel. Steht die AE um 180grad gedreht, drückt die Feder das schwere Heck zusätzlich auf den Boden. Selbst seitliche Fahrt lässt das Fahrzeug schon seitlich stark kippen. Sehr ausgeprägt bei schlecht austarierten Umbauten. Volle 360grad Nutzung funktioniert mit dem federprinzip also eh nicht. Also original kein panzer möglich

 Dann müsste man komplett ohne feder mit perfekt in Waage liegenden Fahrzeug/ Objekt arbeiten. Dann ev. Mit kleinem stützrad vorn und hinten an der runden AE. Von daher ist es egal woher unsere bisherigen Racer ihre Steuersignale bekommen. App oder PC. Ohne mechanische Anpassung sind nicht alle Manöver möglich. Fakt ist aber mit dem was Gurkensaft gemacht hat besteht eine unabhängige Möglichkeit ganz ohne Simulationskram die racer Hardware laufen zu lassen. Jeder racer ist dann im Prinzip gleich. Gewichte, Reibung, lipostatus die eine beeinflussung haben aussen vor

Ich habe die Rotation der AE im Code bereits auf jeweils 90 Grad nach links oder rechts begrenzt. Es stimmt das der Racer mechanisch natürlich darauf ausgelegt ist sein Gewicht möglichst für normales Fahrverhalten sinnvoll auszutarieren, da ist seitens SK viel Gehirnschmalz investiert worden das hinzubekommen. Beim direkten Seitwärtsfahren merkt man das schon sehr gut das das dann nicht mehr passt, z.B. auch das die Vorderräder Mechanik zum Einlenken dann anfängt zu flattern, da ja seitlich gegen die Reifen geschoben wird.

Die Regelkreise im Racer arbeiten mMn auch nicht linear in Bezug auf Geschwindigkeit und Drehwinkel (das heißt Vollgas vorwärts ist schneller als Vollgas seitwärts), was ja auch Sinn macht. 

Wie gesagt, das Ganze ist als Proof of Concept oder Anreiz zu verstehen, sich selber mal mit Fahrphysik zu beschäftigen, oder eben als Fun-Racer, der direkt die drei im ersten Post angesprochenen Werte auf dem Controller abbildet. Ich habe auch versucht einen frei verfügbaren Car-Physics Code zu implementieren, bin da aber gescheitert, denn an dieser Stelle ist viel Feinjustierung erforderlich, und das ist SK mit ihrer App eben hervorragend gelungen, auch in Bezug auf das Zusammenspiel der Fahrzeugspezifischen Parameter.

 

[jobia]

vor einer Stunde schrieb gurkensaft:

Ich habe die Rotation der AE im Code bereits auf jeweils 90 Grad nach links oder rechts begrenzt. Es stimmt das der Racer mechanisch natürlich darauf ausgelegt ist sein Gewicht möglichst für normales Fahrverhalten sinnvoll auszutarieren, da ist seitens SK viel Gehirnschmalz investiert worden das hinzubekommen. Beim direkten Seitwärtsfahren merkt man das schon sehr gut das das dann nicht mehr passt, z.B. auch das die Vorderräder Mechanik zum Einlenken dann anfängt zu flattern, da ja seitlich gegen die Reifen geschoben wird.

Die Regelkreise im Racer arbeiten mMn auch nicht linear in Bezug auf Geschwindigkeit und Drehwinkel (das heißt Vollgas vorwärts ist schneller als Vollgas seitwärts), was ja auch Sinn macht. 

Wie gesagt, das Ganze ist als Proof of Concept oder Anreiz zu verstehen, sich selber mal mit Fahrphysik zu beschäftigen, oder eben als Fun-Racer, der direkt die drei im ersten Post angesprochenen Werte auf dem Controller abbildet. Ich habe auch versucht einen frei verfügbaren Car-Physics Code zu implementieren, bin da aber gescheitert, denn an dieser Stelle ist viel Feinjustierung erforderlich, und das ist SK mit ihrer App eben hervorragend gelungen, auch in Bezug auf das Zusammenspiel der Fahrzeugspezifischen Parameter.

 

Ja ich verstehe dich und das was du vor hast. Ja da gibt es viele Besonderheiten. Auch im Bereich der Sturmkind Simulation in der app die ja bei dir im jetzigen Stadium komplett aussen vor ist. So wird wenn man z.b im Drift Mode fährt, aber diesen drift Anteil selber eliminiert, feststellen können,  dass trotz konstanten Gas der racer in kurven deutlich langsamer wird. Arbeitet man im Racemode ist das deutlich weniger ausgeprägt.  Das Phänomen was du jetzt bei dir festgestellt hast könnte sehr gut mit der Firmware im Racer zusammenhängen. Denn der Racer selber erkennt ja den Winkel der runden AE. Sturmkind könnte hier also etwas in der Firmware hinterlegt haben. Auch wurde hier mal ein phänomen erwähnt was auf einen gyro einfluss zurückzuführen sein könnte. Der gyro hängt ja auch am hauptcontroller und ist über die firmware eingebunden. Mit deiner jetzigen Umsetzung unterliegen ja deine Befehle auch der Firmware. Ich gehe zunächst davon aus das du im ble Chip (firmware) der ja unser Hauptcontroller ist noch nichts verändert hast.

vor 7 Stunden schrieb THR3360:

Es ist für mich alles andere als klar, wie schnell man seitlich fahren, Herr Prof. Dr. Dr. Knowitall!

Diese Antwort schockt mich doch etwas, dass du das nicht weißt oder dir denken kannst. Aber jetzt weiß ich was ich generell von deinen bisherigen Aussagen halten kann. Ev. Mache ich dir mal ein Video.

(Video steht, da sieht man wie schnell ich seitlich fahren konnte. Wäre der Raum ein paar Meter länger ging es noch schneller. Lade ich in Cloud hoch. Verlinke ich dann später wenn Zeit)

Noch etwas ich weis nicht alles!!!!!!!!!!!!.

Z.B habe ich mich noch nie mit alternativer Steuerung über Bluetooth wie Gurkensaft beschäftigt, da es für mich persönlich fahrtechnisch ohne den Simulationsanteil der App keinen Sinn ergibt. Weil dann kann man auch bei einem RC Car bleiben. Aber für ihn ist ja auch interessant, was geht oder kann ich noch anderweitig mit Fahrzeug anstellen. Schon allein um Wissen zu sammeln, ist das ja interessant, was er macht.

Ich für mich kann aber sagen, alles was ich weis, habe ich ziemlich eindeutig ermittelt, habe mir Testmöglichkeiten usw. erschaffen. Das ist nicht nur blabla...... wie es manch einer macht. Da steckt schon Aufwand dahinter und es setzt voraus, dass man sich auch mit der Materie befasst hat.

Bearbeitet 22. Juni von jobia

[THR3360]

vor 58 Minuten schrieb jobia:

Diese Antwort schockt mich doch etwas, dass du das nicht weißt oder dir denken kannst. Aber jetzt weiß ich was ich generell von deinen bisherigen Aussagen halten kann. Ev. Mache ich dir mal ein Video.

Nicht nötig, bist jetzt einer von 2 geblockten. 😅

[jobia]

vor 28 Minuten schrieb THR3360:

Nicht nötig, bist jetzt einer von 2 geblockten. 😅

Ist mir egal, ich weis, was ich von deinen bisherigen Aussagen halten muss. Werde den Sachverhalt trotzdem noch posten. Wie gesagt ich beschäftige mich viel mit dem Kram. (aktuell weniger wegen des A.... Problem)

Zur Sachlage simulierte Fahrphysik von der Racermechanik selbst. Was ich zuvor beschrieb. Problematik Tarierfeder und das gewisse AE Winkel kritisch werden und mit Original Konzept fahrtechnisch nicht möglich sind. Bild "Fahrlage austariert", zeigt austarierten Racer, die Tarierfeder hebt mit ca. 9 bis 12gramm Federvordruck das Heck an. Lastwechsel werden ideal simuliert bei Gas und Bremsen.

Bild "runde AE in Fahrtrichtung 90° rechts also Handbremsdrift nach links" zeigt im Stand wie quer unser seitlich symmetrischer Racer jetzt über der runden AE durch die Federvorspannung quer gedrückt wird. Ist ja durchaus realistisch, dass sich das Fahrzeug zur Aussenseite neigt. Kritisch wird das aber bei schlecht gemachten Umbauracern.

Bild "180° Feder drückt Heck runter" zeigt die Situation eines eigentlich perfekt austarierten Racer, wenn die runde AE um 180° gedreht ist. Wir sehen, das Heck wird massiv runter auf die Straße gedrückt. Fahren wäre so nicht vernünftig möglich und wird auch nicht offiziell per App simuliert (kann eigentlich nur im Fehlerfall vorkommen).

Das war das was ich gestern meinte.

Selbst wenn wir unabhängig von der App steuern, ist vieles ohne Änderung des mechanischen Racerkonzept nicht möglich. Da benötigt es Anpassungen. Das was ich mit Stützrädern vorn und hinten an der runden AE meinte (ev. gefedert für Lastwechselsimulation). Die Tarierferder müsste dann weg.

Auch wenn es THR3360 nicht mehr sehen kann (ist mir egal), hier der Beweis für die seitliche Fahrt.

Wenn wir nicht gerade im Wohnzimmer renovieren würden, hätte ich noch ein paar Meter mehr und schneller fahren können.  Habe es einfach verlinkt, da ich kein Bock hatte, dass hinsichtlich Speicherbedarf zu verringern.

Vorder und Hinterachse habe ich wegen der seitlichen Reibung entfernt. Wie man sieht, kann man seitlich im Prinzip genau so schnell fahren wie nach vorn oder auch hinten (sollte auch klar sein, wenn man sich mal ein bischen mit dem Konzept auseinander setzt)

 z.B wenn man wie Gurkensaft das Fahrzeug nicht über die App ansteuert. Das was dann letztendlich  reglementiert ist die Firmware des Racer, PWM Controller Ausregelung und die abnehmende Lipospannung (bis zur Sicherheitsabschaltung der Hardware). Weil irgendwann sind die Impulse des PWM Signals zeitlich maximal aufgezogen, dann kommt das Signal einer DC gleich. Mehr Speed geht dann nicht. Im Regelfall begrenzt  hier aber die Simualtion. Denn das war es ja, was das Sturmkind Konzept eigentlich ausmacht. Den Racer simuliert realistisch fahren zu lassen. Die App selber ist hier der beschränkende Faktor.

Hier der Link zum Video

https://magentacloud.de/s/MHYnA6BZdk6zc9T

Bitte melde dich an um Bilder zu sehen.

Bitte melde dich an um Bilder zu sehen.

Bitte melde dich an um Bilder zu sehen.

Bearbeitet 22. Juni von jobia

[jogger86]

Bitte melde dich an um den Link zu sehen.

Um mal zur Ausgangsfrage zurückzukehren:

Ja, ein Interesse besteht, dass der Code geteilt wird, wenn  das für dich und SK in Ordnung geht.

Ein richtiger Mehrwert besteht ja schon darin, dass man selbst wenn die DR!FT App in 10 Jahren, aus welchen Gründen auch immer, nicht mehr verfügbar sein sollte, man trotzdem anstelle eines Technikklumpens immer noch ein Auto mit einer Software Schnittstelle hätte, worauf man aufbauen kann.

Man könnte sich auch vorstellen die Software beispielsweise auf eine kleine bekannte Hardware wie den Raspberry Pi hin zu entwickeln.

Also Möglichkeiten sehe ich viele.

[Mutige Orchidee]

Bitte melde dich an um den Link zu sehen.

 ich finde die Idee super! 

Ich beschäftige mich auch grade mit Autophysik, allerdings nicht für DR!FT, sondern arbeite an einem normalen Computerspiel.  

Auf welcher "Engine" läuft das Programm eigentlich? Unity, Unreal Engine, Godot, …? 

Da ich auf Unity arbeite, könnte ich vielleicht helfen. 

 

Falls das Programm auf Unity läuft, würde ich VPP (mit dem ich momentan auch arbeite) nicht empfehlen, wenn es ein "Arcade-Racing-Game" sein soll oder der Input nicht über den Input Manager läuft (also der Input nicht als 

InputManager.GetAxis("");

abgerufen werden kann).

Viele Grüße Mutige Orchidee.

Bearbeitet 22. Juni von Mutige Orchidee

[gurkensaft]

Am 22.6.2024 um 20:27 schrieb Mutige Orchidee:

Bitte melde dich an um den Link zu sehen.

 ich finde die Idee super! 

Ich beschäftige mich auch grade mit Autophysik, allerdings nicht für DR!FT, sondern arbeite an einem normalen Computerspiel.  

Auf welcher "Engine" läuft das Programm eigentlich? Unity, Unreal Engine, Godot, …? 

Da ich auf Unity arbeite, könnte ich vielleicht helfen. 

 

Falls das Programm auf Unity läuft, würde ich VPP (mit dem ich momentan auch arbeite) nicht empfehlen, wenn es ein "Arcade-Racing-Game" sein soll oder der Input nicht über den Input Manager läuft (also der Input nicht als 

InputManager.GetAxis("");

abgerufen werden kann).

Viele Grüße Mutige Orchidee.

Der Code ist frei von jedweder Engine, sondern einfach eine kompakte C++ Klasse. Für unser Racing habe ich einfach eine 64bit Kommandozeilen .exe mit MSVC drumherum gebaut, die dann noch den Controller bedient und die Klassenfunktionen aufruft.

Am 22.6.2024 um 13:58 schrieb jogger86:

Bitte melde dich an um den Link zu sehen.

Um mal zur Ausgangsfrage zurückzukehren:

Ja, ein Interesse besteht, dass der Code geteilt wird, wenn  das für dich und SK in Ordnung geht.

Ein richtiger Mehrwert besteht ja schon darin, dass man selbst wenn die DR!FT App in 10 Jahren, aus welchen Gründen auch immer, nicht mehr verfügbar sein sollte, man trotzdem anstelle eines Technikklumpens immer noch ein Auto mit einer Software Schnittstelle hätte, worauf man aufbauen kann.

Man könnte sich auch vorstellen die Software beispielsweise auf eine kleine bekannte Hardware wie den Raspberry Pi hin zu entwickeln.

Also Möglichkeiten sehe ich viele.

Ja, ich werde mich in den nächsten Tagen nochmal selber damit auseinandersetzen und überlegen was ich dann letztendlich mache. Sollte ich es freigeben werde ich eh den Code noch besser kommentieren müssen und evtl. auch eine Doku über die Klassenfunktionen zusammenstellen. Es ging in erster Runde in dem Thread ja erstmal darum überhaupt die Freigabe von SK zu bekommen.

[THR3360]

Wie siehts denn mit Latenzen aus? Xbox Controller via bt an PC, PC via bt an Racer.

[GTAce]

Oh man, das wäre mega für mich.

[GTAce]

Hey, gibt es was Neues zu dem Projekt?

[Dr!ft-MaBo]

Das klingt alles sehr interessant...

Also falls es da eine Freigabe geben sollte, wäre ich auch daran interessiert...

Grüße Marcel

[gurkensaft]

Hallo zusammen,

sorry das es solange gedauert hat bis ich mal wieder melde. Aktuell bin ich privat und im Job sehr eingespannt, deshalb komme ich im Moment nicht dazu den Code "releasefähig" zu machen, so dass Interessierte auch ohne größere Rückfragen damit etwas anfangen können, 

Es freut mich auf jeden Fall das doch Interesse zu bestehen scheint, und ich werde auf jeden Fall das Projekt fertigstellen sobald ich etwas Zeit dafür finde. Aktuell stresst mich mein reallife Fahrzeug so dermaßen (Motorschaden, TÜV, etc.) das ich wenig Zeit habe mich generell mit Programmierung privat zu beschäftigen 😞 

Sobald ich die Sache in einen für mich akzeptablen Zustand gebracht habe wird es einen GitHub-Link geben.

 

[GTAce]

Gut zu hören, dass das Projekt noch aktiv ist. Für mich ist das so interessant, weil ich wegen einer Behinderung die Smartphone-Steuerung nicht nutzen kann.