Zitat von Moppi Aber woher kommt der Spannungsabfall? Ist das einfach nur, weil da die Ausgangsbeschaltung nicht die volle Spannung durchlässt? In Wärme werden die doch nicht umgewandelt, diese 2V? Hm... Ich bin auch nur Hobby Elektroniker aber schaut man sich im Datenblatt die interne Beschaltung an, sind dort bipolare Transistoren verwendet; keine MOSFETs. Der diskrete 2N2222 Transistor ( https://www.farnell.com/datasheets/296640.pdf ) hat auch ein Uce(sat) von 1,6V. Der Wert ändert sich mit dem Strom. Bei 150mA sind es nur 0,4V (Seite 2, Electrical Characteristics) MOSFET Brücken sind da besser aber auch teurer. Wenn dann vom DC/DC-Wandler 6.5V kommen, bleiben nur ca. 4V für den Motor. Hoffe, dass das dann genügt! Das dann auf 8V einzustellen und die folgenden Spannungsregler, am Arduino, nodeMCU., dann auf 5V und 3,3V runterregeln zu lassen, ist ja auch nicht das Wahre. Das Leben ist nicht leicht Ich dachte ja auch, daß ich mit meinen 5 NiMh Zellen und Abgriff nach 4 Zellen klar komme. Geht eine Weile zum Erfahrungen sammeln aber ein starker Akku und gute verläßliche Spannungs-, Stromversorgungen sind aber nicht zu verachten Ob Dir 4V für den Motor reichen, wirst Du sehen. Dadurch, daß ich meine Motore hauptsächlich aus CD-Roms und Floppylaufwerken beziehe sind die für solche Vehikel eigentlich zu schwach. Das gibt Probleme beim regeln. Sie reagieren nur träge auf Ansteueränderungen. Man könnte natürlich die Getriebeübersetzung ändern um mehr Kraft auf den Boden zu kriegen - dann sind mir die Dinger aber zu langsam. Man wird vermutlich nicht auf Anhieb die ideale Abstimmung hinbekommen. Ich habe Deinen gedruckten Rundumultraschallstrahler gesehen. Sieht gut aus aber da werden sicher noch eine Menge Experimente nötig sein, bis er sich zufriedenstellend verhält. Motore arbeiten über einen großen Spannungsbereich. Da werden vermutlich die kleinsten Schwierigkeiten liegen. Hauptsache die Spannungen brechen bei hoher Stromabnahme nicht ein, wie bei mir. Gruß Searcher PS: Jetzt hat es mich auch erwischt: zu lange geschrieben und vom System ausgeloggt worden. Eingeloggt und auf Forumregel Seite gelandet. Mit Browser "Zurück" noch den editierten Text gerettet.
Nach welchem Algorithmus findet bzw. hält Dein Gerät die Linie eigentlich, Searcher? Die Sensoren sitzen schon mal an der Stelle, wo ich die auch hingesetzt habe. - Nahe der Räder. MfG
Ja, direkt am Motor wollte ich das machen. Werde ich dann auch. Aber woher kommt der Spannungsabfall? Ist das einfach nur, weil da die Ausgangsbeschaltung nicht die volle Spannung durchlässt? In Wärme werden die doch nicht umgewandelt, diese 2V? Hm... Wenn dann vom DC/DC-Wandler 6.5V kommen, bleiben nur ca. 4V für den Motor. Hoffe, dass das dann genügt! Das dann auf 8V einzustellen und die folgenden Spannungsregler, am Arduino, nodeMCU., dann auf 5V und 3,3V runterregeln zu lassen, ist ja auch nicht das Wahre. Aber gut, dass ich es gelesen habe. Sollte öfter mal messen. MfG
Ist das bei jedem L293D? Oh ja und eher noch mehr. Als H-Brücke geschaltet schon fast 3 Volt. zB findet man im Datenblatt Vce sat. typ. 1,2 .. 1,4V das macht 2,4 .. 2,8V Spannungsverlust bei Vollbrücke. Das Ding ist echt nicht gut und nicht zu Unrecht wird oft drauf verwiesen, daß es da viel bessere H-Brücken gibt. Ich benutze die nur, weil ich sie schon habe und noch verbaut werden müssen Zur Entstörung kann ich keinen Tipp geben. Meine Stepper haben kein Bürstenfeuer. Was man so liest, ist Entstörung direkt an der Störquelle, also am Motor wohl das Übliche. Gruß Searcher
reduziert durch den Spannungsabfall von ca. 2V über den L293D Ist das bei jedem L293D? Ich will den auch für die Motorsteuerung verwenden. Aber an 2V Spannungsabfall habe ich nicht eingerechnet. Dann muss ich, wenn ich 6V an einem Motor haben möchte 8V Spannung anlegen? Und wo mach ich dann die Entstörung, wohl direkt am Motor. Oder besser doch einen Kondensator in die Spannungsversorgung, vor dem L293D? MfG
Neue Energieversorgung --> https://www.roboternetz.de/community...rgieversorgung
Auch der Upload von sketches zum ATmega88 über den HW-COM Port hat inzwischen funktioniert. Dazu gibt es einen Forumthread: https://www.roboternetz.de/community...-Kabel-gesucht
Für BASCOM benutze ich einen Programmer für den Parallelport mit SP12 Belegung: https://sbolt.home.xs4all.nl/e-spide....html#hardware von https://sbolt.home.xs4all.nl/e-index.html also DB25 Pin 2 - SCL DB25 Pin 3 - RESET DB25 Pin 9 - MOSI DB25 Pin 11 - MISO DB25 Pin 18..25 - GND Um den, statt dem im Blogeintrag verlinkten Parallel Port Programmer, benutzen zu können, habe ich in der "programmer.txt" Datei in der Arduino IDE Installation im "...\Arduino\hardware\arduino\avr" directory unter dem Eintrag "Parallel Programmer" das "parallel.protokoll" von "dapa" nach "sp12" geändert. Beim Wechsel zwischen BASCOM und Arduino parallel flashen muß ich jetzt nicht immer umstöpseln
Zitat von Siro sorry, hab das eben wieder gelöscht. Hatte noch etwas über meine Pulsauswertung geschrieben, habe dann aber gesehn, dass es ja schon perfekt funktioniert bei Dir. Hallo Siro, hab ich trotzdem über die Benachrichtigungsemail gelesen und fand den Beitrag toll. Hättse ruhig stehen lassen können. Deine Timermessung ist wirklich interessant und scheint vom Konzept her besser zu sein, als die Methode mit Ticks pro Zeiteinheit zu arbeiten. Mich reizt es, Deine Methode auch mal auszuprobieren. Zunächst habe ich jedoch noch den Ehrgeiz herauszufinden, warum es bei mir nicht so gut klappt. Ein Haken ist die aktive Bremse. Da habe ich es noch nicht geschafft, sie bei allen Fahrsituationen richtig zu dosieren. Falls ein Motor zu schnell läuft, zB angetrieben durch die Trägheit des Vehikels beim Gas wegnehmen, soll die H-Brücke umpolen. Also nicht nur vorwärts regeln sondern auch bei negativer Beschleunigung regeln. Im Moment lasse ich die aktive Bremse nicht sanft einsetzen, sondern nur bei großem Unterschied zwischen Soll- und Istgeschwindigkeit, als Notbremse sozusagen. Andere Hürden habe ich inzwischen genommen. Bei scharfem Lenkeinschlag soll ein Rad beginnen rückwärts zu drehen und zwar so weit, daß das Ding sich um seinen Achsmittelpunkt dreht. In der Bewegung kann dann der "Rückwärtsgang" eingelegt und die Drehung soll mit gleicher Geschwindigkeit in engegengesetzter Richtung einsetzen. Das hatte ich schon bei früheren "Geräten" verwirklicht aber dort einen Bug übersehen, der sich nur recht selten zeigte. Deswegen habe ich jetzt im Unterschied zu früheren Programmen, die Übersetzung von der Bedienung zur Steuerung umgestellt. Gerade fertig, hoffentlich. Ich versuche eine PI-Regelung zu implementieren. In einigen Situationen setze ich den I-Anteil auf 0, da sonst "unübersichtliche" Dinge passieren Bei Versuchen hatte ich auch Regelungen probiert, die vermutlich auch nicht in Lehrbüchern auftauchen. Wenn ganz simple Algorithmen schnell genug angewandt werden... - ... geht es auch. Du erwähntest, daß eventuell Räder durchdrehen könnten. Ich habe eher ein entgegengesetztes Problem. Ich verwende recht schwache Motore, die auch entsprechend lahm reagieren. Da werden Schwachstellen geradezu in Zeitlupe offengelegt Reale Fahrten habe ich bis jetzt noch nicht durchgeführt. Mittlerweile stimmt die Drehzahlregelung beim aufgebockten Vehikel. Ich müßte so langsam mal den µC auf eine Platine und aufs Vehikel bauen. Muß dann mal schauen, ob sich die frühere Beobachtung, des Schrägziehens in der Beschleunigungs- bzw Verzögerungphase eventuel geändert hat. Ein Traum wäre, falls nötig, die Regelungen der beiden Motore zu synchronisieren und noch die aktive Bremse zu kultivieren. Gruß Searcher
sorry, hab das eben wieder gelöscht. Hatte noch etwas über meine Pulsauswertung geschrieben, habe dann aber gesehn, dass es ja schon perfekt funktioniert bei Dir.
Hallo Siro, danke für die Bestätigung. Immer gut zu hören, daß man nicht der Einzige ist, der so eine Beobachtung macht. Ich hatte noch weitere Tests zur Überprüfung gemacht. Dazu hatte ich einen anderen ATmega88PA und später noch einen ATmega88A genommen, ein Poti an einen ADC Pin geschaltet und von einem ATiny25 aus Impulse an andere Eingänge des PortC angelegt. Am Ende war es in verschiedenen Zusammenschaltungen so, daß immer, wenn zusätzlich Impulse am PortC ankommen, der ADC für das Poti keine stabilen Meßergebnisse liefert. Der Höhe der Abweichungen kann anders sein, wenn der Impulseingang innerhalb des PortC geändert wird, der Meßeingang aber gleich bleibt. Meine Versuche fanden auf dem Steckbrett statt und ich dachte schon vorsichtig an einen Einfluß der Eigenarten des Steckbretts. Fazit mag wohl sein: Sich des Verhaltens bewußt sein. Keine unkontrollierten Zustände an PortC während einer Messung zulassen bzw. entsprechende Toleranzen einkalkulieren. Fehler durch verschiedene, in Datenblatt und App-Notes empfohlene Maßnahmen so gering wie nötig zu halten. Gruß Searcher PS. Ich versuche bei der Regelung mit der Anzahl der Impulse in einem Zeitintervall zu arbeiten und tue mich da schon schwer weil ich differentielle Lenkung, Gesamtgeschwindigkeit und Vorwärts-/Rückwärtsgang implementieren möchte und merke, daß das nicht so wirklich mein Ding ist. Deine Regelung mit Messung der Impulsabstände halst mir noch eine weitere Idee auf Ist nicht ernst gemeint und ich finde die Tests auf dem "Prüfstand" echt interessant.
Hallo Searcher, laut Datenblatt gibt es wohl tatsächlich einige Probleme mit ADC. Die Decodersignale also nicht auf den ADC Port (Portc) zu legen ist durchaus sinnvoll. Dieser Hinweis laut Datenblatt 28.6.2 macht es nochmal deutlich: If any ADC [3:0] port pins are used as digital outputs, it is essential that these do not switch while a conversion is in progress. Das gleiche gilt natürlich auch für extern angelegte Signale. Wenn hier deine Encodersignale drauf liegen ist das äußerst ungünstig, da anscheinend die Signalflanken auf den ADU übersprechen. Durch die ratiometrische Messung ist VREF nicht so entscheidend, obwohl ich trotzdem immer gegen VREF arbeite. Wie in der Zeichnung im Datenblatt Figure 28-9 sollte man den AVCC Bin über ein LC Glied einspeisen. Das ist sicher gut, brachte bei mir aber keine Verbesserung. Ich habe bei meinen Messungen einen Software Ringpuffer gebaut. Dieser beinhaltet immer die letzen 10 ADC Messwerte. Von diesen 10 Messwerten schmeisse ich den Kleinsten und den Größten weg, die restlichen 8 werden aufadiert und durch 8 mittels 3 mal rechts schieben dividiert. Mein ADU Streuung lag ohne dieser Maßnahme bei 15 ADU Counts. Nach dieser Maßnahme nur noch bei 5. Im Prinzip wirkt es wie ein Tiefpassfilter.Hier kann man natürlich noch weitere Filter einbauen oder auch den Puffer größer machen. Das Ein/Ausschwingverhalten der ADU Werte ändern sich natürlich entsprechend, vermutlich tut ein externer Kondensator ähnliches. Meine Encoderscheibe am Pumpenmotor lieferte mir auch, je nach Drehzahl, bis zu 7000 Impulse pro Sekunde. Anhand der Zeitdifferenz zweier Flanken konnte ich die Drehzahl erstaunlich schnell und präzise regeln. Laut Datenblatt gibt es noch einen "Analog Noise Canceling" Mode. Hier werden während der AD Wandlung diverse Komponenten im Controller ausgeschaltet um Störungen zu vermeiden, nach der Wandlung werden diese dann wieder aktiviert. Wenn die Störungen aber extern durch Signalflanken der Decoderscheibe enstehen, nützt Dir das leider auch nichts. Siro
Ich konnte es erst auch nicht glauben. Anscheinend hatte ich so eine Konstellation vorher noch nicht oder hab nicht drauf geachtet. Die ADC Wandlung in meinem Afbau ist jetzt jedenfalls auch mit beiden laufenden Motoren gut. Die ADC Frequenz ist auf 125kHz eingestellt. Im Programm werden in einer Schleife die beiden Potis an Kanal 1 und 2 abwechselnd im Single Conversion Mode gemessen. Nach Application note AVR126 verwerfe ich nach Kanalwechsel die erste Messung. An AREF habe ich auch einen 100nF nach GND geschaltet (ist aber glaube ich nur notwendig, wenn interne Referenz genutzt wird. Ich verwende Vcc als Referenz) Durch die SW-Hysterese, wie oben verlinkt, sende ich über RS232 die Meßwerte nur an den PC, wenn der aktuelle Meßwert um mehr als drei Einheiten vom vorherigen abweicht. Solange ich nicht an Potis fummele, herrscht am PC-Terminal Ruhe. Die UP/DOWN Leitungen, die ja durch die laufenden Motore über die Enkoder aktiv sind, liefern gemeinsam je nach Drehzahl vielleicht 500 bis 6000 Flankenwechsel pro Sekund zwischen 0 und 5V. Sind die aber auch an PortC Eingängen angeschlossen, gibt es am PC-Terminal Betrieb. Von beiden Potis gab es dann 10 Bit Werte vom ADC, die bis zu ±10 Einheiten und auch mehr pendelten. Oszi an Vcc zeigte im Takt der PWM Frequenz für die Motore kurzzeitig minimale Schwingungen höherer Frequenz, die vielleicht zusammen mit den UP/DOWN Wechseln die Schwankungen der Messungen verursachten. Tatsache ist: UP/DOWN an anderen Port: ADC gut (Ruhe am PC-Terminal)! Ich hatte noch, teils halbherzig versucht die UP/DOWNs auf die I2C Pins zu legen und auch die Buffer an den Meßpins im DIDR0 Register abzuschalten. Kleine Kondensatoren (1nF nach GND) an den Eingängen der UP/DOWNs. Ferrit bead nach AVR042 an AVCC. Nix. Einzig das Verlegen der UP/DOWNs auf einen anderen Port hat geholfen. Wenn sich tatsächlich die Störungen an den Eingängen innerhalb des Ports negativ auf die Messung auswirken, wüßte ich nicht, wie man das verhindern könnte. Bei Gelegenheit würd ich es auch mal mit Spannungswandlern und externer/interner AREF versuchen und mehr Aufwand bei Filterung der Spannungen treiben. Im Augenblick laß ich es mal so, da ich möglichst wenig Aufwand bei der Schaltung treiben möchte und der ADC jetzt meinen Ansprüchen genügt. Gruß Searcher
Interessant. Der ADC lässt sich also doch und ziemlich leicht beeinflussen? Dann war das nicht nur so ein "Gefühl" bei mir. Ich hatte schon den selben Verdacht. Deswegen habe ich auch den AREF mit einem Kondensator gegen GND verbunden. Steht auch irgendwie im Datenblatt bei den µCs, wie dem ATmega328P. Dann habe ich da nichts Überflüssiges gemacht, auch wenn ich den Sensoren einen extra Spannungsregler zugestanden habe. Aber ich hätte nicht gedacht, dass selbst Digitaleingänge Einfluss auf den ADC haben würden. Wenn Du jetzt noch messen tust, wenn ein Motor läuft .... Wenn eben alles an einer Versorgung dran hängt und nichts getrennt ist. Bei den µCs ist es ja doch rel. einfach, einen Spannungsregler extra dafür einzusetzen, mit den entsprechenden Kondensatoren dazu. Ich hatte mir für div. Zwecke ein paar LM2936 zugelegt. MfG
Nachtrag: Bisher hatte ich mit 5V Vcc für den kompletten Aufbau getestet. Da ich später ja Akkus verwende, habe ich nun auch mit 4,5V getestet und da zeigte sich doch, daß ein Enkoder nicht mehr richtig mitspielte. Leichte Vergrößerung der Pulldown Widerstandes an den beiden Fototransistoren hob das Niveau der Signale etwas an. Nun läuft es auch bei 4,5 Volt, also bei leerer werdenden Akkus. Akkubetrieb wird demnächst auch noch auf dem Prüfstand getestet.
Zitat von Moppi Ich muss sagen, dass Du Dir auch sehr viel Mühe gibst mit den Platinen. Nur CU-Draht zum Löten... habe ich nie benutzt, soll oft auch nicht einfach sein. Wie machst Du die Aussparungen, mit Schleifscheibe raustrennen? Die Aussparungen in den Platinen und auch das passende Herausschneiden aus größeren Platten mache ich mit Laubsäge und Metallsägeblatt. Oft muß ich die Sägekanten noch etwas nachfeilen damit sie nicht ganz so uneben aussehen. So säge ich mir auch meistens Aluprofile bis 1,5mm Stärke zurecht. Wellen aus "Silberstahl" sind sehr hart. Um die zu schneiden nehme ich dann Schleifscheiben in einer mittlerweile in die Jahre gekommenen Proxxon FBS/E. Mit der gleichen Maschine und einem Kugelhartmetallfräser, ich glaub 0.8mm, fräse ich auch die Leiterbahnunterbrechungen. Eigentlich mache ich mir tatsächlich zu viel Arbeit mit den Platinen. Das ergibt sich aber irgendwie so. Dadurch, daß das Chassis schon vorgegeben ist und relativ klein ist, mache ich mir automatisch Gedanken zur Drahtführung. Führen die irgendwo quer durch den Raum kriegt man weitere Platinen nur noch schwieriger unter und es soll doch schon etwas aufgeräumt erscheinen. Dadurch, das ich zwei H-Brücken brauche, drängte sich schon von selbst ein symmetrischer Aufbau auf. Daß sich sogar eine H-Brücke in sich so gut aufbauen ließ, ergab sich bei dem detaillierten Entwurf der Platine. Und ein bißchen macht es auch Spaß, das so hinzukriegen. Auf der IC-Platine hatte ich noch nach den Leiterbahnunterbrechungen ein IC zurechtgerückt damit es auch zusammen mit dem anderen symmetrisch zur Mitte liegt. Dadurch mußte ein Widerstand auf die Leiterbahnseite wandern. Der Kupferlackdraht, den ich verwende, stammt von einer alten Monitorbildröhre. Da muß ich recht aufwendig mit Lackkratzer abisolieren und vor verlöten verzinnen um sicher zu gehen, daß auch gut abisoliert ist und die Lötung später gut wird. Es soll aber Lackdraht geben, bei dem man mit ein bißchen Lötkolbenschmurgelei den Lack abbekommt. Also einfach abschneiden und versuchen direkt zu verlöten. Vorteil vom Lackdraht ist der, das er so dünn ist. Bei gleichem Leiterdurchmesser ist kunststoffisolierter Draht dicker. Deshalb habe ich bei der IC-Platine, wo doch noch einige Drähte zusätzlich zur Kupferkaschierung hinzu mußten, Lackdraht genommen. Je nach Qualität zieht sich Kunststoffisolierung auch zurück und an diffizielen Stellen kann es zu Kurzschlüssen kommen. Eigentlich möchte ich nicht soviel Zeit darauf verwenden aber zum Schluß gefällt es mir besser als fahrig aufgebaute Schaltungen. Im Großen und Ganzen MUß es aber NICHT immer so sein; besonders nicht, wenn ich schnell fertig sein möchte Gruß Searcher
Ich muss sagen, dass Du Dir auch sehr viel Mühe gibst mit den Platinen. Nur CU-Draht zum Löten... habe ich nie benutzt, soll oft auch nicht einfach sein. Wie machst Du die Aussparungen, mit Schleifscheibe raustrennen? MfG Moppi
Zitat von Moppi Das Klappern hält sich in Grenzen, was man so hören kann. Es ist doch nicht so hochfrequent. Wenn es funktioniert, kann man die Relais doch belassen? Ja, das Klappern könnte man bei wenig Gebrauch des Vehikels noch tolerieren. Es hat mich aber auch noch auf ein Problem in der Regelprogrammierung gebracht. Ich schrieb schon, daß manchmal ein oder beide Motore auf Vollgas schalten und nur durch HW-Reset des µC (Strom aus/ein) zur "Vernunft" gebracht werden können. Durch initialisieren von Variablen in dem Regelungsteil des Programms bei ferngesteuertem Aus-/Einschalten des Antriebs geht es mittlerweile auch per Fernbedienung. Wenn man im Video genau hinschaut, kann man erkennen, daß bei Verschärfen des Lenkeinschlags das kurveninnere Rad von vorwärts nach rückwärts zu drehen beginnt und den Kurvenradius noch kleiner macht. Außerden gibt es einen FB-Befehl, der die Drehrichtung der beiden Motore gleichzeitig umkehrt. Also quasi ein Rückwärtsgang. In Kombination mit der aktiven Bremse weiß die Regelung in manchen Situationen nicht mehr, ob gerade vorwärts oder rückwärts gefahren wird und regelt falsch. Da ich noch nicht recht weiß, ob ich unter Beibehaltung aller anderen Features den Bug behoben bekomme, lasse ich die Relais erst mal drin und schaue, wie sie sich weiterhin verhalten. Der Bug ist auch beim TT 2.0 und Quadenc PI vorhanden, macht sich dort aber praktisch nicht bemerkbar. Kann aber auch dort provoziert werden. Gruß Searcher
Das Klappern hält sich in Grenzen, was man so hören kann. Es ist doch nicht so hochfrequent. Wenn es funktioniert, kann man die Relais doch belassen? MfG Moppi
Wenn der Drucker richtig eingestellt ist, was schon mal ein Weilchen dauert, kann man sogar mit so einem günstigen Anet A8 auf ein 10tel genau drucken. Für viele ist das zu anspruchsvoll, aber die Tüftler schreckt das nicht ab. Wenn man es drauf anlegt, geht mit so einem Teil ziemlich viel. Mit den teureren Druckern wahrscheinlich sowieso. Aber so ein Drucker macht nicht weniger Müll und Holz dürfte da noch immer umweltfreundlicher sein. Bevor ein Teil gedruckt ist, braucht er auch eine Menge Strom und nicht jedes Teil gelingt. MfG
Links
Kategorien
Besucher
Profil anzeigen
Als gelesen markieren