Parametrierung der Fahrtregler über Raspberry-Pi

    • Offizieller Beitrag

    Hallo Robot-Bastler,

    ich bräuchte mal ein paar Rückmeldungen wie ihr zu einer Idee von mir steht.

    Aktuell werden meine Fahrtregler ja mit einem Windows-PC-Programm parametriert. Also unter Windows.

    Einige von euch haben ihren Home-Bereich zur microsoftfreien Zone erklärt (=Apple). Ausserdem finde ich das Handling beim Turnier mit einem Laptop immer etwas mühselig.

    Problem: Mit einem Smartphone komme ich an den Fahrtregler nicht heran. Erstens habe ich vom Programmierung unter Android genausoviel Ahnung wie von meiner Steuererklärung. Zweitens ist das dann wieder eine „Sackgasse“ für die IPhone-User.

    Aktuell werden die Raspberry ziemlich günstig (ca. 40 Euro) angeboten. Die Idee wäre, in einem Raspberry einen Webserver zu programmieren. Die Parametrierungsoberfläche ist praktisch auf jedem Smartphone/IPhone/Laptop/IPad darstellbar. Webkommandos lösen dann die entsprechende Aktion am Rasp-Pi aus, der dann die Sachen zum Fahrtregler lädt oder abruft.

    „Wie“ das im Detail funktioniert, das weis ich nicht. Ob Wi-Fi oder sonstwas… keine Ahnung.

    Warum ich mal die Stimmung zu diesem Projekt abklopfen wollte: Was haltet ihr davon? Wäre es eine Option, dass jeder Fahrtregler-User sich einen Rasp-Pi zulegt, nur damit er den Fahrtregler parametrieren kann?
    Statt 15 Euro für das aktuelle USB-Interface sind das dann ca. 40 Euro (zuzüglich Netzteill und Gehäuse).

    Bitte mal unverblümte Rückmeldung.

    Danke!

    • Offizieller Beitrag

    Ich muß auch gestehen daß ich lange Zeit die Fahrtregler nur im "Auslieferungsmodus" betrieben habe :;
    Aber wenn man einmal die Funktionen entdeckt hat möchte man sie nicht mehr missen, ist so ähnlich wie bei dem ersten Auto mit Klimaanlage, vorher ging es auch ohne...

    Mit der microsoftfreien Zone fühle ich mich direkt angesprochen. Allerdings habe ich noch einen kleinen Eeepc mit Windows XP, der dient zur Parametrierung von Reiners Reglern und meiner DJI Drohne. Wenn das Netbook sich verabschiedet siehts mit der Drohne düster aus, aber für die Fahrtregler wäre der Raspberry dann eine echte Alternative. Aber noch läufts...

  • Gegenvorschlag: Du legst das Protokoll offen und ich schreib ein C++ Konsolenprogramm, was sich auf allen Betriebssystemen nutzen lässt. Dann bräuchte nur mehr ein GUI-Programmierer einen GUI-Wrapper darum schreiben ;)

    • Offizieller Beitrag
    Zitat

    Original von Alex
    Gegenvorschlag: Du legst das Protokoll offen ...

    Daran soll's nicht scheitern. Sind nur ASC-Befehle bzw. Werte, die ich hier in einem Frame ("STX" => Data => "ETX") übertrage. Kann ich ja mal in die Doku des jeweiligen Fahrtreglers mit aufnehmen.

    Zitat

    Original von Alex
    .... Dann bräuchte nur mehr ein GUI-Programmierer einen GUI-Wrapper darum schreiben ;)


    Tja,... da waren sie wieder, unsere drei Probleme....
    Irgendwas wehrt sich in mir, dass ich mich mit den Programmieroberflächen von drei verschiedenen Betriebssystemen herumärgere....


    Das Protokoll ist bei jedem Fahrtregler-Typ anders, da ich mit der Zeit immer mehr Features einbaue. "Es lebt". :D


    Am Einfachsten wäre natürlich, eine "Bedien-html-Oberfläche" zu schreiben. Aber ich hab' bisher noch niemand gefunden, der er schafft, sich von einer lokal laufenden html-Oberfläche mit der USB-Schnittstelle zu verbinden, an der der FT232-Chip dranhängt.

  • Zitat

    Original von IBF
    Das Protokoll ist bei jedem Fahrtregler-Typ anders, da ich mit der Zeit immer mehr Features einbaue. "Es lebt". :D

    Dann töte es ;) ... Im Ernst: Vereinheitlichen und zusammenführen ;) Eventuell wäre ja auch denkbar, dass die Konfiguration über ein XML-File erfolgt. Da kann dann jeder mit dem Texteditor selbst herumkonfigurieren. Nachdem anscheinend der Bedarf nicht allzu hoch ist muss das Tool auch nicht allzu komfortabel sein, da sich ja auch der Entwicklungsaufwand irgendwo lohnen muss.

    • Offizieller Beitrag

    :D

    Zitat

    Dann töte es Augenzwinkern ... Im Ernst: Vereinheitlichen und zusammenführen Augenzwinkern


    Ist nicht ganz so einfach. Seit der Version 3_1 ist die Entwicklung einfach weitergegangen. In der neuen Version vom 4_1 z.B. wurde noch erweitert, auch den Status des dritten Empfängerkanals abfragen und am PC darstellen zu können. Also ein Byte mehr im Protokoll notwendig.

    Der damalige "Spargedanke", das Telegramm auf möglichst wenig Byte zu reduzieren, hat sich in diesem Fall also als Bumerang erwiesen.

    "Töten" werde ich die bisherigen Entwicklungen nicht, dafür sind zuviele Fahrtregler in der Gemeinde verteilt. Und ich lasse hier niemand auflaufen, dass es (ähnlich wie bei Microsoft) heißt: "Das Bisherige ist ab heute nicht mehr kompatibel, kauf Dir was Neues."

    Auch in Hinblick auf Entwicklungen, die ich nicht kenne, muss ich nach oben offen bleiben. Beispiel aus dem anderen Thread: Separater PWM-Kanal für einen Gyro. Das weis ich jetzt noch nicht, "ob" man das braucht oder nicht. Und wenn ja, ob man eine Limitierung einsetzt.

    Derzeit mache ich im PC-Programm (programmiert unter Visual Basic 5 => für die Jüngeren unter euch: Entstanden zu der Zeit, als man Musik noch von so runden schwarzen Scheiben hörte...) einen sehr großen Aufwand, um die einzelnen Softwarestände zu verwalten. Mein Ziel ist, dass eigentlich jeder sinnvolle Wunsch von einem Roboteer im Fahrtregler integriert wird. (Wenn technisch möglich). Trotzdem sollen die bisher ausgelieferten Baugruppen weiterhin bedienbar sein. Und für jeden Firmware-Stand ein separates PC-Programm verwalten, das möchte ich mir nicht antun.

    Zitat

    Da kann dann jeder mit dem Texteditor selbst herumkonfigurieren. Nachdem anscheinend der Bedarf nicht allzu hoch ist muss das Tool auch nicht allzu komfortabel sein, da sich ja auch der Entwicklungsaufwand irgendwo lohnen muss.


    Anhand der Resonanz hier scheint das Thema "Parametrierung" tatsächlich keinen hohen Stellenwert zu haben. Das frühere System mit DIP-Schaltern am Fahrtregler war für kleine Sachen ausreichend. Aber jetzt, wenn es um die Einstellung von den Fahreigenschaften geht (z.B. Lenkverhalten bei der Kreuzmischersteuerung), dann sind Wertebereiche unerlässlich.

    Dass ich den Jungs und Mädels hier das herumstochern in einem XML-File zumute, da habe ich zugegebenerweise etwas Bauchweh. Bei der Bedienung des Programms wird es zwar niemals eine goldene Sänfte geben, aber mein Ziel ist es, dass eigentlich jeder schon beim Anblick der Bedienoberfläche weis, zu was der Parameter gut ist.

    Fazit bis hierher:
    Separat einen Webserver in einem Rasp-Pi zu programmieren, erscheint derzeit wirklich unnötig. Werd' also doch irgendwann mal nur auf C# unter Visual Studio umsteigen und den ganzen Summs neu aufsetzen. (Damit meine Entwicklungsumgebung auch mal ohne Windoof XP auf einer VirtuellenMaschine läuft)

    Alex: nach MMMV19 dokumentiere ich mal meine Datenprotokolle, dann siehst Du was ich meine.

  • Also ich finde die Software wie sie jetzt ist gut und fände ein extra benötigtes Raspberrypi zuviel des guten ;D
    Ich find die Paremetierung übers programm praktisch, auch der Übersicht wegen, ich hasse XMLs oder ähnliche Formate, hab mich bei genug Spielen mit dem Editeren dieser Dateien plagen müssen, ist nervig...