Fahrtregler auf Arduino Basis

Quote

Original von IBF

*Neugierig* Wie hätte das funktionieren sollen? Meine Erfahrung mit der Bremserei sagt, dass man die Bremspulse (Länge eines Bremspulses und Anzahl der Bremspulse) abhängig von dem Bot machen muss. Ein vierrädiger Bot bleibt schneller stehen als ein Zweirädiger. Ebenso spielt die Masse des Bots eine Rolle, wie lange die noch "nachschiebt", bevor die Bremse gelöst und die Gegenrichtung aktiviert werden kann. (Augenblicklich stelle ich die Bremse anhand des blauen Funkenflugs der Motor-Kollektoren ein. Wenn's zu viel der blauen Funken sind, wird die Pulslänge verringert, ...) Wie wolltest Du das "intelligent" lösen? (Auch wenn's nicht funktioniert, ware die "Vision" ganz interessant zu wissen.)

Ein sehr interessantes Thema!
Zunächst einmal um Missverständnisse zu vermeiden eine Rückfrage. Unter "Bremsen" ist hier gemeint:

a) das Kurzschließen eines unbestromten, drehenden Motors (dann Generator) über dessen Anschlußdrähte maximal bis zum Stillstand, wobei es egal sein sollte, ob es sich um einen Bürstenmotor handelt oder dieser bürstenlos ist (BLDC).

oder

b) das Bestromen des drehenden Motors ENTGEGEN dem gegenwärtigen Drehsinn, wobei der Bremsvorgang dann spätestens ab Stillstand in eine Beschleunigung in die Gegenrichtung übergeht.

Ohne die Rekuperation zu betrachten (beim Bot egal): Wo liegen die Vor- u. Nachteile der jeweiligen Methode?

OK, heißt also hier wird Methode a) diskutiert und Krümmel's "Intelligenzbremse" bezieht sich auf eben diese Methode.

Da kann ich etwas zu beisteuern: Bei meinem Elektro-Quad (Projekt eQuad2009) hatte ich zu dieser Methode a) genau zwei Varianten bei meinem 4kW-Selbstbau-Controller im praktischem Fahrbetrieb ausprobiert:

Variante 1: der 2kW-BLDC-Motor wird (vereinfacht beschrieben ohne Betrachtung der Ströme innerhalb der H-Brücke) beim Gasgeben normal bestromt und beim Gas-Wegnehmen (oder Betätigung der Betriebsbremse) wird die Bestromung unterbrochen und der Motor dreht frei (Freewheel) ggf. bis zum Stillstand od. erneuter Bestromung.

Diese Variante dürfte auch der "Rollervariante" entsprechen, es wird i.d.R. nicht rekuperiert (keine Energierückgewinnung) und der Motor dreht nach und nach aus...

Variante 2: bei dieser Variante wird der Motor eher wie ein Schrittmotor betrieben, was bedeutet, dass beim Gas-Wegnehmen der Motor eben nicht ausläuft sondern (durch Kurzschluß) gebremst wird, wobei die Bremswirkung (Verzögerungsmoment) umso stärker ist, je höher die Drehzahl (= Generatorleistung) ist.

Diese Variante finde ich für einen Bot als Motorbremse genau richtig. Ich habe das technisch in meinen (u.a. hier im Forum beschriebenen) H-Brücken wie folgt gelöst: Beim Bestromen (Hochtouren) wird bekanntermaßen mit einer PWM gearbeitet, vereinfacht gibt es H-Pulse (= Bestromen) und L-Pulse (= Pause/keine Bestromung). Vom Stillstand des Motors fängt man also mit kleinen H-Pulsen an, die dann von der Pulsdauer her immer größer werden. Nun mache ich folgendes, was möglicherweise nicht unbedingt dem Standardverfahren entspricht: Bei den L-Pulsen schließe ich in dieser Variante den Motor IMMER kurz (über den Low-FET der Halbbrücke, die den H-Pulse liefert!). Auftouren bedeutet also bildlich gesprochen: 1% Bestromen 99% Kurzschluß, 2% Bestromen 98% Kurzschluß, usw... Wenn man dabei (Motorabhängig!) die richtige Frequenz auswählt, dann erwärmt sich der Motor beim gesamten Betrieb marginal stärker, als bei der Variante 1., und auch die Batterie-Stromaufnahme ist unwesentlich höher.
Der Vorteil entsteht beim Abtouren: Der Motor hängt "hart" an der PWM und bleibt auf dem Punkt stehen (lastabhängig!) wenn die PWM= 0 ist. Der Clou: Der Motor bleibt mit PWM= 0 einfach kurzgeschlossen (und damit gebremst) bis wieder Aufgetourt wird; das Fahrzeug (Bot) kann also nicht od. nur erschwert rollen / geschoben werden.

Diese Variante hatte ich bei meinem eQuad sogar im praktischen Fahrbetrieb getestet, jedoch war das Abtouren sehr unkomfortabel, da der 16kg schwere BLDC-Motor extreme Vibrationen auf den Fahrzeugrahmen übertragen hatte.
ABER: Bei einem Bot würde ich erwarten, dass immer nach diesem Verfahren gearbeitet wird, da es doch m.E. überhaupt keinen Sinn macht den Bot langsam ausrollen zu lassen.
Meine H-Brücke, die ich hier ausführlich vorgestellt habe, arbeitet exakt nach diesem Prinzip (PWM-L-Puls= 100% Kurzschluß für diese Pulsdauer). In meinem Video sieht man sehr deutlich, dass die (zugegeben unbelasteten) Bürstenmotoren exakt reagieren und sehr schnell abtouren: http://www.youtube.com/watch?v=EBkdO6Ccq_g

Wenn also von einem "intelligentem Bremsen" geschrieben wird dann ist vermutlich damit gemeint, dass zu diesem Zeitpunkt die PWM völlig abgeschaltet wird und dafür punktuell (IBF's Brems-Pulse) der Motor kurzgeschlossen wird. Die Intelligenz dabei soll offenbar die Anzahl / Pulsweite dieser Brems-Pulse steuern, möglicherweise lastabhängig oder (intelligenter) in dem Maß, wie schnell der Kreuzknüppel betätigt wird. Ist das richtig so? Falls ja, warum nicht wie in meiner Variante die PWM anliegen lassen (mit zunehmenden L= Kurzschluß) und lediglich die Zeitspanne, in der die PWM runtergefahren wird, "intelligent" variieren? Dies könnte doch proportional zur Kreuzknüppelstellung umgesetzt werden.

Nach meinem Verständnis bräuchte es keine Brems-Intelligenz, sondern eine stets anliegende und aktive PWM, welche mit einer zeitlich variablen Rampe (Kreuzknüppel-Position + Betätigungsgeschwindigkeit) hoch- bzw. runtergefahren wird.
Gibt es möglicherweise ein Problem damit (außer das die Temperatur am "Bremstransistor" ansteigt), speziell beim Einsatz von Bürstenmotoren?
Oder begrenzt der Temperaturanstieg an den Transistoren sogar die Brems-Dauer/Wirkung?
Ich vermute eher, dass die betreffenden Personen Probleme mit der SW-Adaption haben, immerhin müssen ja die Signale der Funke in hammerharte-MOSFET-PWM umgesetzt werden; ist vielleicht nicht jedermanns Sache...
.

Nein, nein, es gibt bei meiner Variante keine Rückspeisung. Und ich bremse doch....!
Ist doch klar: Wenn (bildlich) auf der linken Seite meiner H-Brücke der H-FET zum Auftouren hochgepulst wird dann ist ZEITGLEICH auf der rechten Seite der L-FET vollens durchgesteuert - für die gesamte Dauer des Fahrens, beim Stillstand und bis zum Richtungswechsel! Damit habe ich beim Abtouren sehr wohl eine starke Bremswirkung, da dann kurzfristig BEIDE L-FET's leitend sind - die gemäß Deiner Definition weiche Bremsung also. Aaaaber: Diese "weiche" Bremsung kann unvermittelt (quasi sofort) in eine "harte" überführt werden, eben dann, wenn die PWM wie von mir vorgeschlagen schlagartig runtergefahren wird; kann ja im ms-Bereich passieren: Dann sind sofort BEIDE L-FET dauerhaft aktiv und bleiben das auch (PWM= 0)!

Ich habe keine Rekuperation, jedenfalls nicht geplant bzw. aktiv innerhalb der Brücke gesteuert - somit auch nicht verifiziert. Eine Spannungsüberhöhung am Fahrakku hatte ich tatsächlich mal festgestellt, meine Vermutung war via Bodydioden-Rückfluß...

Einzig die Masse der Bots kann tatsächlich zu einem Problem bei VOLLEM Kurzschluß und hoher Drehzahl werden; deratiges hatte ich aber auch nicht empfohlen.

edit: Nochmal zum Thema Rekuperation/Rückspeisung: Nach meinem Verständnis immer dann, wenn der ABTOURENDE Motor als Generator mit einem Generatorstrom belastet wird, welcher DURCH DIE BATTERIE fließt (= Ladestrom). Nur fließt außer in den FET-Umschaltmomenten bei mir nichts in die Batterie, da innerhalb der H-Brücke ein L-FET permanent und der andere L-FET zeitweise immer dann leitend ist, wenn innerhalb dieser HALB-Brücke der H-FET nicht leitend ist. Anders: Ein wirksamer Strom fließt AUS der Batterie via H-FET in den Motor (und via permaleitenden L-FET u. Masse zurück zur Batterie) ODER aus dem Motor via zeitweise leitenden L-FET / Masse / permaleitendem L-FET in den Motor zurück - aber nicht in die Batterie; somit auch keine Gefahr von Überspannung etc. (hoffe die technisch etwas unkorrekte Ausdrucksweise verdeutlicht den Stromfluß).

Also begrenzen die Verluste (Temperaturerhöhung) die wirksame Brems-Kennlinie.
Die von Krümmel angestrebte Brems-Intelligenz könnte also darin bestehen, möglichst stark via Motor-Kurzschluß bremsen zu können, ohne dabei ein Bauteil thermisch oder mechanisch zu überlasten...

Oje, oje - nochmals edit: Es gibt TATSÄCHLICH in meiner Variante einen möglichen Rückfluß zur Batterie, würde ich nicht als (gewollte) Rekuperation bezeichnen aber immerhin, nämlich dann, wenn zwei Bedingungen erfüllt sind: a) der H-FET leitet (vermutete Bodydiode dann irrelevant) UND b) die Generatorspannung des abtourenden Motors GRÖßER als die Batteriespannung ist. LOL, ich kapier' meine eigene Brücke bald nicht mehr... Zu meiner Entlasutung ist mir das bislang garnicht aufgefallen, weil: a) ich in diesem Bereich soviele Versuche & Messungen gemacht habe, dass ich garnicht mehr weiß was ich wann gemessen habe und b) ich zur Absicherung der FET's immer ein paar fette Schutzdioden spendiere, die offensichtlich die folgende Spannungsüberhöhung verdauen ohne die weiße Fahne zu schwenken...
Es war UnskilledWorker der mich auf die Idee brachte... Danke!
.

@ UnskilledWorker: ich war schneller ich war schneller..... grins.... Habe meinen Fehler selbst entdeckt und per nochmals-edit eingefügt während du noch gegrübelt hast.....

Quote

Original von UnskilledWorker
Kann man meine "Erläuterung" verstehen?

LOL...! Also ich verstehe das schon, was kein Wunder ist, da ich mir die Controller für manntragende und seit Jahren im Einsatz befindliche Elektrofahrzeuge selbst erfolgreich aufbaue und teste. Aaaaber ob alle anderen wissbegierigen User aus dem Geschreibsel noch schlau werden - wer weiß....

Quote

Original von Krümmel
Wird komplizierter als ich dachte.

Das wird es meistens....
In meinem (hier ausführlich vorgestellten) H-Brücken-Bauprojekt hatte ich testweise eine Pistolen-FB nebst 2,4GHz-Empfänger adaptiert. Soweit ich mich erinnere war die SW nach Aufbau der HW innerhalb von 1 bis 2 Tagen erstellt, die beiden Motoren liefen bei FB-Betätigung wie erwünscht. Aber es gab jede Menge Störungen, welche z.T. zu erheblicher Fehlfunktion führten, u.a. zuckten die Motoren bei Betrieb einer Mikrowelle, welche auch auf 2,4GHz "sendet". So habe ich weitere Tage benötigt, um die SW mühevoll zu entstören, damit die gesamte Steuerung an DIESER Pistolen-FB einwandfrei läuft; nun auch mit Mikrowelle und 2,4GHz-Funkkamera. Bei der nächsten FB (und entsprechendem Timing) kann natürlich alles wieder ganz anders sein!

Übrigens würde ich nie mit Compiler-Befehlen wie PulsIn o.ä. arbeiten, weil die Gefahr besteht, dass die Abfrage der Port-Eingänge (welche die FB-Empfängersignale verarbeiten) im Polling erfolgt, dass Hauptprogramm also auf den nächsten Impuls "wartet". Das ist für Anfänger zwar erstmal leichter, aber technisch leider keine schöne Methode, da der Programmierer ein Stück weit die Kontrolle über das Timing verliert (= zusätzliche Fehlerquelle).

Viel geschickter finde ich folgendes Verfahren, welches ich auch konsequent umsetze:

Die Signale vom Empfänger laufen (für 2 Kanäle) auf 2 interruptfähige I/O-Ports, beim ATMEL z.B. INT0 und INT1, wobei JEDE Flanken-ÄNDERUNG einen Interrupt auslöst - den sog. IRQ-Handler (Interrupt-Serviceroutine). Der IRQ-Handler wird von mir aus Gründen möglichst schneller Programm-Abarbeitung konsequent in Assembler geschrieben, dass Hauptprogramm dagegen in einer beliebigen Hochsprache (C, BASCOM, o.ä.).

Der IRQ-Handler wertet also die Signale der FB vollständig aus (inkl. SW-Filter), aber NUR DANN, wenn diese auch tatsächlich auftreten (Flankengetriggert). Ansonsten läuft das Hauptprogramm und macht andere (hoffentlich sinnvolle) Dinge. Innerhalb des Hauptprogramms werden nun 2 Variablen definiert, z.B. Kanal1 und Kanal2 für die beiden FB-Kanäle, wobei der Byte-Wert Kanal1= Kanal2= 128 bedeuten würde, dass bei der Pistolen-FB Gas & Lenkung auf Mitte stehen (nicht betätigt) - soweit ganz einfach.
Der Clou ist nun folgender: Da sich die IRQ's völlig um die Empfänger-Signale kümmern, kann das Hauptprogramm nach Belieben auf die beiden Variablen Kanal1/Kanal2 zurückgreifen und dabei sicher sein, dass diese stets aktuell sind. Für einen Failsafe ist dann ein weiterer Timer-IRQ nötig, welcher solange nicht auslöst, wie eingehende und als plausibel interpretierte Empfänger-Signale (keine Störungen) den Timer periodisch zurücksetzen.

Wenn die IRQ's sauber programmiert werden, braucht sich das Hauptprogramm nicht mehr um die Erfassung der Empfänger-Signale zu kümmern und kann stattdessen die Variablen auswerten und die Motoren entsprechend ansteuern.

Die Idee mit der Pulsauswertung über ISR's finde ich ansich auch gut und habe ich sonst auch gerne so gemacht. Aber gibt es da leider folgendes Problem -> Beispiel mein selbstentwickelter Copter (aktuell auf Eis gelegt) -> Dort habe ich ja sechs Kanäle, die ich auch mittels Interrupt-Eingänge abfrage. Nur bei den sechs Kanälen, die alle mit ihrem Interrupt dazwischen funken, wird die ganze Steuerung ziemlich träge...

Gibt es da nicht eine Alternative? Nimmt man die MultiWii (überlicher Flight-Controller -> Mein Hexa fliegt damit) werten die ja zehn Kanäle aus und die Steuerung ist absolut verzugsfrei...

Quote

Original von Replikator
Aber gibt es da leider folgendes Problem -> Beispiel mein selbstentwickelter Copter (aktuell auf Eis gelegt) -> Dort habe ich ja sechs Kanäle, die ich auch mittels Interrupt-Eingänge abfrage. Nur bei den sechs Kanälen, die alle mit ihrem Interrupt dazwischen funken, wird die ganze Steuerung ziemlich träge...

Gibt es da nicht eine Alternative?

Gibt es.
Beispiel IRQ-Handler/ISR: Es gibt Compiler-Anweisungen, die ALLE 32 Register des Controllers beim IRQ pushen und am Ende der IRQ-/ISR-Routine wieder popen. Ist (speziell auch für weniger geübte Programmierer) die sichere Methode, man kann dann kein Register vergessen u. kommt auch mit der LIFO-Reihenfolge nicht durcheinander. Kostet aber Laufzeit: Wenn z.B. nur 2 Reg. im IRQ-Handler benötigt werden, dann werden für die restlichen 30 völlig unnötig kostbare Taktzyklen verschwendet...
Lösung: Im IRQ-Handler möglichst wenige Reg. nutzen u. manuell PUSHen u. POPen = Laufzeitgewinn!

Beispiel Hardware: Controller kosten kaum Geld. Das es wohl ein Selbstbauprojekt ist wird einfach ein weiterer Slave-Controller eingesetzt, welcher sich ausschließlich um diese 6 IRQ/ISR kümmert und die (gesiebten!) Ergebnisse der 6 Kanäle z.B. via I²C periodisch an den Master-Controller überträgt. Da ist der Failsafe dann auch umsonst: Ausbleiben der Daten = Failsafe.

Weiters käme noch Prüfung der eigenen Programmiersystematik zu tragen, also Optimierung des Programmcodes. Da lassen sich meisten Routinen optimieren sodass 10...20% Laufzeitgewinn schnell zusammen sind.

Wenn das auch nicht reicht: Controller übertakten (nur Test, nicht im Sicherheitsbereich) und ggf. nächst höhere Controllergeneration einsetzen.... viel Erfolg!

Quote

Original von IBF
Zu der o.g. Methode, die Empfängersignale über Interrupt abzufangen: Ihr seid durch die 2.4GHz-Technik natürlich etwas verwöhnt. Wer noch mit 40Mhz arbeitet, dem sei dringend davon abgeraten, mit der Interrupt-Methode zu arbeiten.

@ IBF: Natürlich kennst Du die Fertigkeiten der Fragesteller hier wesentlich besser als ich, dennoch bin ich ein glühender Verfechter der Interrupt-Techniken. Folglich ist es nie zu spät, sich damit eingehend zu beschäftigen. Bei Hochgeschwindigkeitsanwendungen (hier im 22ms-Frame sind wir natürlich weit davon entfernt) setze ich auch schonmal rekursive Interrupts ein und verzichte ggf. zu Gunsten eines Laufzeitgewinn auf den Register-Push/Pop, sofern das Reg. NUR in dieser speziellen ISR genutzt wird. Verschachtelte Interrups OHNE Register-Rettung ist natürlich was für Vollprofis und wird von mir auch keinesfalls empfohlen (= Haftungsausschlußerklärung).

Quote

Original von IBF
Wenn der Empfänger zuviel Blödsinn liefert (=ständiger Flankenwechsel), dann brauche ich zwar in der (Porteinlesen-)Subroutine u.U. die maximale Durchlaufzeit, aber zumindest intressieren mich irgendwelche kurz aufeinanderfolgenden Flankenwechsel nicht, weil ich gerade bei der Auswertung des bisherigen Timerwertes bin.

Mir erschließt sich hierbei nicht, weshalb die konsequente Anwendung der Interrupt-Technik im Störungsfall ggü. dem Hauptprogramm-Polling ein Nachteil darstellen soll. Denn wenn die 100 Flanken/s korrekten / nutzbaren FB-IRQs durch 1000 Störimpulsen/s überlagert werden, dann ist die gesamte Funktionalität infrage gestellt. Das ist m.E. unabhängig davon, ob nun 1000 IRQ's zuviel sind und ggf. das Hauptpgm. nicht mehr abgearbeitet wird oder gleich das Hauptprogramm im Polling hängen bleibt. Verschachtelung mal außen vor, der Stack kann auch dann nicht überlaufen, wenn 100% Nutzsignal durch 1000% Störgröße überlagert wird. Auch ein IRQ bzw. dessen ISR läßt sich übrigens wirksam mit einem Timer verschränken, sodass in einem vorgegebenen Zeitfenster durchaus auf den (zeitlich unerwarteten!) Störimpuls-IRQ angemessen reagiert werden kann (sagen wir innert 2 µs bei 16MHz-ATMEL), OHNE das das System kollabiert: Bei ISR-Einsprung wird zunächst simpel das Timer-Overflowflag abgefragt und im negativen Fall (= Störung, zu früher IRQ) die ISR mit RET sofort wieder verlassen; schneller gehts nicht. Außer die globalen Statusflags (und max. 1 Register) braucht auch nichts gepusht/gepopt werden.

Bezüglich der "dauerhaft abgerauchten" Anwendungen der o.g. User verfängt mein ernstgemeinter Tipp: Bei derartigem Prototyping IMMER ein (einstellbares) strombegrenzendes Netzteil einsetzen und mit dem kleinsten Strom beginnen, welcher gerade für die Prüfung einer neu programmierten / grundsätzlichen Funktion nötig ist (also Motoren im Leerlauf betreiben und NICHT als erstes den Blockadestrom prüfen!) - dann halten auch die Schaltungen länger....

Quote

Original von IBF
Wenn jemand die Interrupts benutzen will, dann kann ich ihn nicht davon abhalten. Aber meine Warnung sollte darauf hinauslaufen, nicht "blind" in eine Störeinkopplungs-Falle zu tappen.

Eigen- und Fremdstörungen sind natürlich immer wieder ein Thema, woran selbst erfahrene Entwickler verzweifeln können. Normalerweise muß dann der gesamte Aufbau ins Labor, um die Fehlerwirkung verlässlich reproduzieren zu können - sonst können die Gegenmaßnahmen kaum untersucht & programmiert werden. Ein eher unerfahrener Entwickler / Programmierer wird dann möglicherweise völlig überfordert sein, dann helfen auch die gutgemeinten Tipps nicht wirklich weiter.

So fände ich es auch nicht verwunderlich, wenn 20% vom Programmieraufwand / Speicherplatz / Laufzeit für das Einlesen / Verarbeiten der eigentlichen (im Idealfall ungestörten) FB-Signale draufgehen, und 80% für Signal-Verifikation / ausgeklügelte Entstörungsmaßnahmen fällig werden. Das ist oftmals die bittere Realität der E-Technik, man sollte als Schaltungsentwickler jederzeit mit einigen "netten Effekten" rechnen...