Antweight Fahrregler

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Original von panzerbot
      Der Pilot meinte wohl PCM
      Ich hab früher immer gelesen das PPM sicherer sei, von daher verwundert es mich.

      Bisschen lektüre


      "PCM" könnte sein, dass er das gemeint hat. Bin mir nicht sicher, darum hier etwas "um den heißen Brei geschrieben".
      Laut Deinem Link zu der Lektüre wäre PCM sicherer, weil noch Prüfbits mit dabei sind.
      .
      Interesse an Elektronik für Schaukampfroboter und Kettenfahrzeuge (Fahrtregler, ESC) ? => http://www.Robots.IB-Fink.de
    • Ich habe mir als einfache Testplattform für den Fahrtregler einen Breadboardbot zusammengebaut. Er besteht im Wesentlichen aus zwei Minigetriebemotoren welche mittels Heißkleber an der Rückseite eines Breadboards befestigt wurden. Am Breadboard selbst befinden sich Fahrtregler, OrangeRX Empfänger und Akku. Das ganze fährt mit Panzersteuerung schon ganz wunderbar. Zur Bedeutung der LEDs: Die gelbe LED ist die Power-LED: Sie leuchtet, wenn der Fahrtregler mit Spannung versorgt ist. Die rote LED dient zur Signalisierung des ACTIVE-State: Sie ist nur dann an, wenn der Fahrtregler aktiv ist (sprich die Eingangssignale in Motorsteuersignale umsetzt).
    • Für den Delta-Fahrmodus (d.h. die Kreuzmischerfunktion) habe ich die Motorkennlinie durch einen methodischen Ansatz auf Grundlage der mathematischen Abbildung einer Ebene berechnet. Die gesamten Ausführungen sind unter lxrobotics.com/kreuzmischer-fu…ht-fahrtregler-delta-mode im Detail dargestellt. Das Konzept wurde durch eine Implementierung für den Fahrtregler und Test unter Verwendung des Breadboardbot in ihrer Funktion verifiziert.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Alex ()

    • *Boah* ... Da erkennt man den Jung-Ingenieur, der noch aktiv im Vorlesungssaal sitzt. :D ;)

      Man merkt, dass meine Mathestunden schon fast 30 Jahre her sind. Ebenengleichungen sind mir fremd geworden.
      Ich habe die Abhandlung mal durchgelesen und weis ungefähr, was Du da treibst. Selbst herleiten oder "kontrollieren" könnte ich das ehrlich gesagt nur schwerlich.....

      Wenn Du Deine Kenngrößen im Controller berechnest, wird der Prozessor da nicht zu lahm für den Rest, der da für die Motoren und vor allem der Erfassung der beiden Empfängerkanäle so anfällt? Kein Jittern festgestellt?

      Ich hätte ehrlich gesagt etwas Skrupel, solche Gleichungen in meiner Software mit einzubauen. (Meine Taktik ist, die derzeit starre Zuordnung der Größen über ein Kennlinienfeld abzugleichen. Das heißt, die Berechnung von den einzelnen Punkten sollte schon beim Parametrieren im PC stattfinden. Im Programm wird dann nur anhand der beiden Empfangsgrößen die bereits vorberechneten Werte aus dem Feld ausgelesen. Leider ist das EEPROM zu klein dafür. Es wird also eine Mischung aus Deiner Methode und dem Kennlinienfeld werden. (Auslesen der Geradengleichungs-Kenngrößen pro Vor-Zurück-Arbeitspunkt aus einer Look-Up-Table)

      Dann zieh' ich zunächst mal den Hut vor Deiner Mathematik!

      Aber: Zum Schluss sind ein paar Formeln da. Wie geht's da weiter? Du kriegst vom Empfänger zwei Werte und musst jetzt zwei andere Werte daraus berechnen. Bei Deiner Ebenen-Gleichung startest Du mit "Vollgas-Bedingungen", also dass links/rechts bzw. vor/zurück mit jeweils dem vollen Empfängerausschlag die Motorreaktionen steuern dürfen. Mir fehlt irgendwie der Eingriff auf eine Limitierung des Lenkeinschlags.

      Lassen sich Deine Überführungen der Empfängerwerte auf die PWM auch hier in ein paar Zeilen darstellen? *NeugierigAufRealisierung*
      .
      Interesse an Elektronik für Schaukampfroboter und Kettenfahrzeuge (Fahrtregler, ESC) ? => http://www.Robots.IB-Fink.de
    • Hallo Reinhard,

      Erstmal Danke ;) Ich habe die momentane Realisierung des Delta-Modus ins GitHub Repository hochgeladen. Die Magie passiert in dem Modul linear_mapper_2d. Zu beachten ist, dass noch keine Korrektur der Mittelwerte für den Deltamodus integriert ist. Die Umsetzung von Eingangssignal zu PWM Wert benötigt zwei Multiplikationen und zwei Subtraktionen. Die Werte für r, s und t werden im Moment noch am PC berechnet. Ich sehe aber keinen Grund, diese Berechnung nicht einmalig beim beim Hochfahren im Rahmen der Kalibrierung im µC durchzuführen.

      Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von Alex ()

    • Reiner, Frage: Wieso reicht dein EEPROM nicht? Vorschläge:

      (1) Ins EEPROM kommen Stützstellen des Mappings. Beim Start wird (sinnvollerweise wie bei Alex) die LUT daraus berechnet und im RAM abgelegt. Bei 8-Bit, also 256 Werten benötigt die LUT 256 Bytes. Wenn man ein Viertel davon als Stützstelle im EEPROM ablegt und durch Interpolation ersten Grades die 3 fehlenden Werte berechnet, dann bnötigt man 64 EEPROM Bytes und ich wage zu behaupten die Fehler durch die lineare Interpolation fallen gar nicht auf.

      (2) Ins Flash kommt die komplette LUT. Beim AVR les ich ohne Probleme mit pgm_read_byte direkt aus dem Flash und das geht so schnell wie aus dem EEPROM, also kein Problem.

      Ich habe damals beides für das Mapping zwischen Empfänger und Motor, also die Reglerkennlinie umgesetzt und beides mit Erfolg und ohne Problem. Die Variante mit dem EEPROM fand ich besser weil dabei nicht komplett neu flashen muss sondern einfach nur das EEPROM neu beschreiben konnte...
      .: Formerly known as GRA Administrator, now OUT OF ORDER :.
    • Die Umsetzung von Eingangssignal zu PWM Wert benötigt zwei Multiplikationen und zwei Subtraktionen. Die Werte für r, s und t werden im Moment noch am PC berechnet.

      Ah... *klick*. Dann versteh' ich das jetzt, wie Du hier vorgehst. Auch die Taktik, dem Prozessor die "Konstanten" schon mundgerecht vorbereiten und dann mit wenigen Taktzyklen alles rechnen. (Irgendwie war ich auf dem Trichter, dass Du die "Eckwerte" von X und Y des Empfängers vorgibst und der Controller muss dann erst mal seine Herleitungen der Konstanten durchführen.)

      Danke für den Hinweis, werde ich dann mal nachprüfen. Derzeit aber keine Zeit für solche weiterbildenden Maßnahmen. Die Vorbereitungen für die Messe in Herne kosten derzeit alle Resourcen....



      Wieso reicht dein EEPROM nicht?

      Schön von Dir Marco, dass Du technisch wieder mitpostest. Deine Beiträge hatte ich schon schwer vermisst.
      Der PIC-Prozessor hat 256Byte EEPROM. ca. 25 davon verbrate ich derzeit für die Speicherung der Parameter (Bremszeiten, Anlaufverzögerung, Funktionsauswahl,...). Und weitere ca. 30 Bytes für die Motorkennlinie. (Müßte jetzt nachsehen...)

      Ich hatte mich damals auf das System fixiert, dass eine Kennlinie bei "0" losgeht (=Neutralstellung des Kreuzknüppels) und bei Maximum endet. Damit werden alle vier Quadranten der Bewegung abgebildet. Alex macht das anders, bei ihm ist die Neutralstellung bei 0x80 . Das hat jetzt Vorteile. Denn ich muss mir separat immer noch den Quadranten ausrechnen und "mitschleppen", vor allem wenn ich bei der Kreuzmischersteuerung eine Überlagerung habe. (Bei geringer Vorwärtsfahrt wird ein großer Linkseinschlag gemacht. Bei der Berechnung ist somit der Wert vom Linkseinschlag größer als der Vorwärtswert, somit muss der Quadrant des Motors von "vorwärts" auf "rückwärts" geändert werden.)
      Wenn ich also "jeden" Punkt von X und Y der beiden Empfängersignale auf einen entsprechenden PWM-Wert für zwei Motoren fest ablegen will, dann sind das 23 X-Werte mal 23 Y-Werte. Istgleich über 500 Werte. Ok, das ist die primitve Version, im PC jeden Punkt auszurechnen und dann eine zweidimensionale Tabelle im EEPROM abzulegen.

      Im Flash würde genügend Speicherplatz zur Verfügung stehen. Nur muss ich zu meiner Schande gestehen, dass ich bei Flash-Operation etwas die Hosen voll habe. Denn "Einzelweise" kann man die Bytes nicht speichern. Ich muss immer einen ganzen Block lesen, den im Ram halten, die entsprechenden Werte modifizieren und dann den ganzen Block wieder schreiben. => Gefällt mir nicht.

      Im Prinzip hast Du das mit der linearen Interpolation schon so beschrieben, wie ich das in ähnlicher Form vor habe. Du kannst Dir das ungefähr so vorstellen, wie man typischerweise das Ausgangskennlinienfeld von einem bipolaren Transistor darstellt. (Mehrere Kennlinien bei verschiedenen Basis-Arbeitspunkten). So hätte ich das jetzt vor. Heißt z.B.: Der Y-WErt (vorwärts) = 13. Im Index 13 des Kennlinienfeldes sind jetzt die beiden Kennwerte der Geradengleichung (hatte ich in der Schule mal mit "m" und "t" gelernt. => y = mx +t). Damit kann ich für jeden Wert der Vorwärtsrichtung eine separate Geradengleichung aufstellen. Anhand der Geradengleichung und dem X-Wert des Empfängers (= Lenkeinschlag) wird dann der entsprechende Wert für den PWM des Motors berechnet. Nachdem es zwei Motoren sind und die Motoren asymetrisch angesteuert werden sollen (siehe Tabelle und Grafik von Marien), brauche ich das Ganze zweimal. Wären also bei 23 Y-Werte jeweils 4 Werte zum Beschreiben der Geradengleichungen. Also knapp 100 Werte. Das ist machbar.

      Soweit verstanden, wie ich das vorhabe? Der Clou dabei ist, dass ich durch die beiden Geradengleichungen sowohl eine Vorberechnung im PC machen kann, gleichzeitig aber relativ wenig mathematische Operationen im Prozessor notwendig sind, die mir eventuell dann das Messen von den Empfängersignalen versauen. (Jitter).

      Wie gesagt, das ist meinerseits noch alles nicht zu Ende gedacht und es können hier noch Fehler in der Denke sein. Vor allem muss ich die Berechnung der Geradengleichungen im Prozessor soweit in den Griff kriegen, dass das "flott" durchläuft. Floating-Point-Operationen scheiden aus. Auch bei Integer-Operationen bin ich misstrauisch. Ich weis nicht, ob das geht, aber ich würde versuchen, eine eigenes System zur Berechnung der "Bruchzahlen" bei der Variablen m mit anzuwenden. Irgendwie an Integer-Operationen angelehnt, aber soweit abgespeickt, dass die Division durch einen 8fach-Shift des High-Bytes zum Low-Byte erfolgt. => ... wie gesagt, alles noch nicht zuende gedacht, da können noch viele Fehler enthalten sein.

      Ich werde das auch erst dann programmieren, wenn der neue Fahrtregler mit dem neuen Prozessor hardwaremäßig vor mir liegt. ;)

      Beim AVR les ich ohne Probleme mit pgm_read_byte direkt aus dem Flash und das geht so schnell wie aus dem EEPROM, also kein Problem.

      Das ist eine vorgefertigte Routine aus dem mitgelieferten AVR-Baukasten?

      Tja,... da muss ich passen. Mit solchen "mitgelieferten" Sachen arbeite ich nicht mehr, seitdem ich mir mit der mitgelieferten Routinge zum Ansteuern externer EEPROMs über I2C mein Nervenkostum ruiniert hattet. Seitdem kommt in den Prozessor nur noch "eigener" Code rein. Und der steht in einem einzigen File... ;)

      diese Berechnung nicht einmalig beim beim Hochfahren im Rahmen der Kalibrierung im µC durchzuführen.

      Muss das zwangsweise einen Einfluss auf die "Kennwerte" haben? Ich weis nicht, wie Du die Kalibrierung realisiert hast. Aber eigentlich musst Du dir doch nur einen Offset (ok.. zwei Offsets für die Kreuzknüppel) merken und die nach jedem Einlesen der neuen Timerwerte berücksichtigen. (Addition/Subtraktion). Dann kannst Du Deine berechneten Konstanten so lassen wie sie sind.
      Denn: Wenn Du die Kennlinie von Marien ansiehst, dann braucht man unterschiedliche "Zoomfaktoren" bzw. Limiten. (Z.B. bei einer reinen Lenkbewegung links/rechts nur 50% von dem Kreuzknüppelwert.) Das kann dann im PC "vorberechnet" werden und bleibt im EEPROM gespeichert. Ohne Modifikation durch Berechnungen des Controllers, denn woher soll der wissen, was für eine Kennliniencharakteristik Du haben willst.

      Hier der Link zu der Kennliniengrafik von Marien Ich denke, dann wird klar, warum ich zwei verschiedene "asymetrische" Motoransteuerungen vorbereiten will:
      - Mittelstellung: Kreuzknüppel nur "voll" links und rechts: Motoren drehen mit maximal 50%, aber gegenläufig.
      - Vollgas vorwärts, ohne Lenkung: Beide Motoren gleichsinnig mit 100%
      - Vollgas vorwärts geht gleichzeitig auf linken vollen Lenkausschlag. Linker Motor geht auf 0%, Rechter Motor auf 75%.

      Das geht doch nur mit einer "Vorberechnung" oder ? ;)
      .
      Interesse an Elektronik für Schaukampfroboter und Kettenfahrzeuge (Fahrtregler, ESC) ? => http://www.Robots.IB-Fink.de
    • Wie gesagt, das ist meinerseits noch alles nicht zu Ende gedacht und es können hier noch Fehler in der Denke sein. Vor allem muss ich die Berechnung der Geradengleichungen im Prozessor soweit in den Griff kriegen, dass das "flott" durchläuft. Floating-Point-Operationen scheiden aus. Auch bei Integer-Operationen bin ich misstrauisch. Ich weis nicht, ob das geht, aber ich würde versuchen, eine eigenes System zur Berechnung der "Bruchzahlen" bei der Variablen m mit anzuwenden. Irgendwie an Integer-Operationen angelehnt, aber soweit abgespeickt, dass die Division durch einen 8fach-Shift des High-Bytes zum Low-Byte erfolgt. => ... wie gesagt, alles noch nicht zuende gedacht, da können noch viele Fehler enthalten sein.

      Da bist du schon auf dem richtigen Weg. Floating Point Operationen (von 32bit floats) auf einem 8-Bit ist in schon ein "mutiges" Unterfangen. Einfach Integer hernehmen und vor der eigentlichen Division den Dividenden ein wenig aufblasen (z.B. der von dir genannte Left-Shift-by-8 ) - Dabei natürlich achten, dass man die Größe des verwendeten Datentypen nicht überschreitet. Nach der Vision das Ergebnis durch Right-Shift-by-8 wieder in die richtige Größenordnung übertragen. Rundungsfehler lassen sich durch geschicktes Wählen der Eingangsgrößenordnungen vermeiden. Wenn der Ergebnis der Division Hausnummer (1.9 * 2^8) wäre, dann bleibt nach einem Right-Shift-by-8 nur mehr 1 übrig. In diesem Beispiel also ein Fehler von 90 %. Wird der Dividend von vornherein so gewählt, dass das Ergebnis der Integerdivision einen größeren Wert ergibt, so ist der Nachkommawert vernachlässigbar. Beispiel: Ergebnis = 190.5 * 2^8 führt zu 190. Ich habe diese Methode bei meinem linear_mapper Modul für die Berechnung der Motorsteuersignale bei Panzersteuerung angewendet. Als maximaler Motorausschlag wird 8160 verwendet, der tatsächliche maximale Motorausschlag liegt jedoch bei 255 (8160 = 255 << 5). Dadurch kann bei der Bestimmung der Parameter k und d der Stützgeraden auf jeden Fall eine passable Genauigkeit erreicht werden.

      Im Prinzip hast Du das mit der linearen Interpolation schon so beschrieben, wie ich das in ähnlicher Form vor habe.

      Verstehe, du hast eine Kennlinienfeld mit mehreren Arbeitspunkten. Der Arbeitspunkt wählt eine Kennlinie aus und anhand dieser führst du die lineare Interpolation durch. Meine Fragen an dieser Stelle lauten:
      1) Sind die 23 x 23 Werte eine willkürliche Festlegung deinerseits oder ergeben sie sich aus technischen Constraints (z.B. dass die Auflösung der Eingangssignale auf 23 Schritte begrenzt ist)?
      2) Ich nehmen an, dass du die Stützgeraden anhand des konkreten Eingangssignales berechnest, und nicht irgendwo im Speicher vorhälst? Würde dies dann bedeuten, dass zusätzlich zum Umsetzen des Eingangs- auf den Ausgangswert noch eine Berechnung der Geradenparameter stattfinden muss?

      Vorteil deines Modells ist auf jeden Fall, dass auch asymetrische Kennlinienverläufe möglich sind. Die ließen sich zwar auch in die Ebene integrieren - ohne es jetzt überprüft zu haben denke ich aber, dass dies zu einer Unausgeglichenheit in der Kennlinie führen würde und möglicherweise nicht mehr den vollen Ausschlag für beide Motoren ermöglichen würde.
      Muss das zwangsweise einen Einfluss auf die "Kennwerte" haben?

      Nopes. Ich habe der Kalibration im Delta-Mode erst ein paar Gedenken gewidmet, aber bis jetzt halte ich die von dir vorgeschlagene Idee, einfach eine Korrektur der Offsetwerte vorzunehmen für einen einfachen, praktikablen und vor allem effizienten Ansatz.

      Eine Kennlinie wie die von Marien ist zumindest teilweise möglich, d.h. der maximale Lenkeinschlag der Motoren beim Drehen lässt sich auch beim Ebenenmodell vergleichsweise einfach beschränken. Zusätzliche Extrawünsche lassen sich nicht realisieren, da die Umsetzung der Eingangssignale auf die Motorsignale mit den drei Konstanten r, s, t durchgeführt und nicht durch ein KL-Feld approximiert wird.

      EDIT: Habe die Erkennung der Neutralstellung via Offsetwerte nun im Fahrtregler integriert und getestet -> Funktioniert.

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Alex ()

    • Schön von Dir Marco, dass Du technisch wieder mitpostest. Deine Beiträge hatte ich schon schwer vermisst.
      Ich hab Urlaub... Und bin über meine alten Regler-Jugendsünden gestolpert... :rolleyes:

      Floating-Point-Operationen scheiden aus.
      Auf jeden Fall immer dann wenn es zeitkritisch wird. Davor und danach geht aber. Was Alex da so erklärt kann man machen, es gibt aber auch Fixed Point Libs für 8-Bitter ohne FPU die man verwenden kann. Das ist zwar deutlich schneller aber niemals so schnell wie einfache billige Shifts. Ich kann daher nur empfehlen sowas VOR oder NACH einer langen oder zeitkritischen Operation durchzuführen...

      Soweit verstanden, wie ich das vorhabe?
      Ja, aber mir ist bei den Lösungen von euch beiden noch nicht klar warum der Aufwand so hoch sein muss? Reicht denn eine 2 dimensionale Tabelle für den Kreuzmischer nicht aus? Apropos EEPROM Mangel, zur Not ein externes EEPROM per I2C oder SPI anklemmen...

      Das ist eine vorgefertigte Routine aus dem mitgelieferten AVR-Baukasten?
      Vom avr-gcc, also vom Compiler...
      .: Formerly known as GRA Administrator, now OUT OF ORDER :.
    • Ja, aber mir ist bei den Lösungen von euch beiden noch nicht klar warum der Aufwand so hoch sein muss? Reicht denn eine 2 dimensionale Tabelle für den Kreuzmischer nicht aus?

      Ich empfinde drei zu speichernde Konstanten und die beschriebenen 2 Multiplikationen und Subtraktionen nicht als hohen Aufwand ;)
    • Reicht denn eine 2 dimensionale Tabelle für den Kreuzmischer nicht aus?

      So wie von Dir angedacht, eine 2dimensionale Tabelle mit Stützpunkten und die dann linear interpolieren, das ginge prinzipiell schon mal gut. Aber wie die Praxis beim Fahren gezeigt hat, muss man langsam auf asymmetrische Motoransteuerungen umschwenken, sonst fahren die Bots wie Besoffen, oder bei "Vollgas-Links" macht er nur ein ganz kleines Kurvchen.
      Heißt: Es müssen dann zwei 2 dimensionale Tabellen sein (linker Motor / rechter Motor). Klappt genauso gut wie mein Vorhaben, zwei verschiedene Geradengleichungen pro Vorwärts-/Rückwärts-Stellgröße bereitzulegen.

      @Marco: wenn Du jetzt Urlaub hast, dann wird an dem Ant weitergebaut? ;) ;) ;)

      EDIT: Habe die Erkennung der Neutralstellung via Offsetwerte nun im Fahrtregler integriert und getestet -> Funktioniert.

      Bei Dir gehen die Realisierungen immer so schnell.... Ich kämpfe abends vor lauter "Peripherie-Arbeiten" um jede Minute, um an den Botsachen was arbeiten zu können... *neid*
      .
      Interesse an Elektronik für Schaukampfroboter und Kettenfahrzeuge (Fahrtregler, ESC) ? => http://www.Robots.IB-Fink.de
    • Ich empfinde drei zu speichernde Konstanten und die beschriebenen 2 Multiplikationen und Subtraktionen nicht als hohen Aufwand Augenzwinkern
      Mit der entsprechenden Vorarbeit natürlich nicht... :]
      @Marco: wenn Du jetzt Urlaub hast, dann wird an dem Ant weitergebaut? Augenzwinkern Augenzwinkern Augenzwinkern
      Nee, am Moped... :]
      .: Formerly known as GRA Administrator, now OUT OF ORDER :.
    • @Reinhard: Nachdem ich auf die Rückgabe meiner korrigierten und benoteten Masterarbeit warte, habe ich gerade ein wenig Zeit frei ;)

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Alex ()

    • Kleines Statusupdate:
      -> Konfiguration des Kreuzmischers in das Config-Tool mitaufgenommen und getestet.
      -> Einen kleinen, aber dafür ärgerlichen "Bug" im Bootloader beseitigt - Bei Interesse empfehle ich meinen zu dem Problem verfassten Blogartikel.

      Damit sind alle für den Fahrtregler notwendigen Implementierungen abgeschlossen. Ich habe von meinen für Testzwecke gebauten Prototypen noch ein paar Fahrtregler übrig - diese würde ich um den Materialkostenpreis + einen kleinen Aufschlag fürs Zusammenbauen hergeben. Wenn jemand Interesse hat, dann bitte PN an mich.