Für ein Museumsprojekt habe ich einen Laserpointer (<1mW rot) auf zwei Servos gesetzt. In Abhängigkeit von einem gewählten Dokument auf einem PC mit Touchscreen zeigt dieser auf Positionen einer großen Landkarte. Als Basis verwende ich einen Wemos D1 Mini mit dem Webserver-Beispiel (Servo-Positionen werden per GET-Statement übertragen) und die Standard-Servo-Lib. Wegen der feineren Auflösung verwende ich write.microseconds() zur Positionierung. Eine deutliche Steigerung der Positioniergenauigkeit erreiche ich dadurch, dass ich (bei ausgeschaltetem Laser) die Position immer aus der gleichen Richtung und (nach 100ms Pause für den Hauptweg) immer aus der gleichen Entfernung anfahre. So erreiche ich auf einer Entfernung von ca. 2m eine Wiederholgenauigkeit um 1cm. In ca. 19 von 20 Fällen funktioniert das Ganze genau so, wie es soll. Manchmal hingegen bewegt sich der Lichtpunkt - etwa 1s nachdem er zunächst die korrekte Position erreicht hat - plötzlich nochmal um 2..3cm weiter und bleibt dort auch. Das ist doof. Bei der nächsten Positionierung auf die gleiche Stelle stimmt es dann wieder. Dieses Verhalten betrifft beide Achsen und mehrere solcher "Zeigegeräte". Eine Macke eines Servos oder D1 fällt damit eigentlich aus. Hat jmd. ne Idee, an welcher Stelle ich anfangen sollte, die Ursache für das Problem zu suchen? Ein mechanisches Problem (wackeln der Servo-Achse) schließe ich eigentlich aus, weil ich ich aus größerer Menge ausgesuchte Servos verwende und eine Art mechaische Bremse/Dämpfer mit leichter mechanischer Vorspannung einsetze.
:
Bearbeitet durch User
Was soll man mit Programmprosa anfangen? Wenn ein Bug drin ist, wird üblicherweise debuggt, indem man sich hier Positionsdaten ausgeben lässt und Soll mit Ist vergleicht. Ausgabe seriell über USB. Und dann provoziert man den Bug, mit 1 Fehler aus 20 sieht das überschaubar aus.
MWS schrieb: > Was soll man mit Programmprosa anfangen? > > Wenn ein Bug drin ist, wird üblicherweise debuggt, indem man sich hier > Positionsdaten ausgeben lässt und Soll mit Ist vergleicht. Ausgabe > seriell über USB. Und dann provoziert man den Bug, mit 1 Fehler aus 20 > sieht das überschaubar aus. Wie ich schrieb, verwende ich die (Arduino-) Standard-Servo-Lib. Soll ich die hier reinstellen? Ich nehme an, dass die millionenfach von anderen verwendet wird. Evtl. ist die beschriebene Macke ja auf einen Bug in der Firmware des Wemos begründet? Könnte ja sein, dass jmd. Erfahrungen diesbezüglich hat. Ich erwarte nicht, dass jemand meinen Code debuggt ...
:
Bearbeitet durch User
Frank E. schrieb: > Hat jmd. ne Idee, an welcher Stelle ich anfangen sollte, die Ursache für > das Problem zu suchen? Guck dir mit einem LA die Länge der Impulse an, die an den Servo geschickt werden.
Frank E. schrieb: > Ursache Deine verwendeten Analogservos sind ungeeignet, ausserdem wird sich ihre Wiederholgenauigkeit durch Alterung noch verschlechtern. Lösung 1: Sündhaft teure Digitalservos verwenden Lösung 2: Mehrere fest ausgerichtete Laserpointer verwenden HTH
2 Cent schrieb: > Frank E. schrieb: >> Ursache > Deine verwendeten Analogservos sind ungeeignet, ausserdem wird sich ihre > Wiederholgenauigkeit durch Alterung noch verschlechtern. Ich verwende digitale Servos. Die Alterung ist im Moment nicht das Problem, sondern das bisher nicht erklärliche und seltene (aber trotzdem störende) "Nachrücken" > Lösung 1: > Sündhaft teure Digitalservos verwenden die sind nur unwesentlich teurer als analoge Servos > Lösung 2: > Mehrere fest ausgerichtete Laserpointer verwenden > Es sind zu viele Anzeigepunkte und es ist uncool.
Wie wäre es mit Steppermotoren, die du mit Microstepping ansteuerst. Klingt vielleicht kompliziert, aber dafür gibt es mittlerweile eine Menge fertiger und sehr günstige Treiberbausteine, die du einfach mit Clockpulsen und Direction betreibst. Als Anschlag dienen einfach kleine Lichtschranken. Ich glaube nämlich auch nicht, dass der Aufbau mit Servomotoren die nötige Wiederholgenauigkeit bieten wird.
Ich gehe davon aus das du schon forher Probleme hatte mit der genauigkeit, und das diese Lösung mit starten in identische position das verbessert hat. Ich glaube das der Wifi-Ablauf in Wemos den arduino sketch unterbrecht, und das haben sie nicht in der Hand. Wahrscheinlich wird dan diese 20 ms nicht genau gehalten, und ist ihre schone positionierung ein bischen daneben. Ausschliessen kansst du diese Vermutung durch ein Versuch mit eine Arduino Uno. Ich vermute auch das aus Stillstand eine minimale Weg notwendig ist um das Servo neu zu bewegen (Regelfenster von Servo).
Harald schrieb: > Wie wäre es mit Steppermotoren, die du mit Microstepping > ansteuerst. > Klingt vielleicht kompliziert, aber dafür gibt es mittlerweile eine > Menge fertiger und sehr günstige Treiberbausteine, die du einfach mit > Clockpulsen und Direction betreibst. Als Anschlag dienen einfach kleine > Lichtschranken. > > Ich glaube nämlich auch nicht, dass der Aufbau mit Servomotoren die > nötige Wiederholgenauigkeit bieten wird. Danke, aber ich glaube du hast meinen Eingangspost nicht richtig gelesen. Ich habe mir nicht umsonst die Mühe gemacht, das Problem so datailiert zu beschreiben. Nochmal: Die Servos fahren zunächst auf die richtige Position, halten dort für ca. 1s und gehen dannach erst auf die falsche Position. Die Servos funktionieren mit den beschriebenen "Tricks" ansonsten absolut genau genug. Nur manchmal kommt eben diese Störung, von der ich gerne die Ursache wüsste. Dabei ist übrigens - habe ich wohl bisher vergessen zu erwähnen - auch das Motorengeräusch der Servos zu hören. Die werden also tatsächlich von irgendwas falsch angesteuert und "klappern" nicht irgendwie mechanisch.
:
Bearbeitet durch User
RP6conrad schrieb: > Ich glaube das ... Glauben ist hier der falsche Ansatz, Nachmessen wäre ein vernünftiger Weg. Dann weiss man, ob die Baustelle bei den Servos oder bei der Ansteuerung liegt. Falls es an der im Hintergrund auf dem ESP-8266 laufenden Software liegt, muss man sich überlegen, ob man die während der entscheidenden maximal 2ms blockieren kann oder die Impulse mit per Timer-Hardware direkt erzeugen kann, d.h. ohne dass Software an der eigentliche Erzeugung des Pulse beteiligt ist. Bei irgendeiner "Standard-Servo-Lib" kann es schon mal sein, dass die auf solche Anforderungen nicht ausgelegt ist.
Wolfgang schrieb: > RP6conrad schrieb: >> Ich glaube das ... > > Glauben ist hier der falsche Ansatz, Nachmessen wäre ein vernünftiger > Weg. Dann weiss man, ob die Baustelle bei den Servos oder bei der > Ansteuerung liegt. > > Falls es an der im Hintergrund auf dem ESP-8266 laufenden Software > liegt, muss man sich überlegen, ob man die während der entscheidenden > maximal 2ms blockieren kann oder die Impulse mit per Timer-Hardware > direkt erzeugen kann, d.h. ohne dass Software an der eigentliche > Erzeugung des Pulse beteiligt ist. Bei irgendeiner "Standard-Servo-Lib" > kann es schon mal sein, dass die auf solche Anforderungen nicht > ausgelegt ist. Danke, gute Idee. Ich habe natürlich zum Thema "servo jitter" schon recherchiert. Es gibt Lösungen, die an Stelle der Standard-Lib eigen Routinen an den Timer 1 des Original-Arduino binden, der soll präziser sein. Aber da mein Problem immer nur in rel. großen Abständen auftritt (und nicht als ständig wahrnehmbare Störung), habe ich da noch meine Zweifel. Es müsste sich um das rel. seltene Zusammentrefen "Ungünstiger Umstände" handeln. Ich vermute allerdings, dass sich der Code so nicht direkt auf den ESP übertragen lässt, oder?
Besorg dir ein PCA9685 Modul. Das gibt's in der Bucht für ~5€ (BSP: www.ebay.de/itm/162533562184 ). Wenn du länger als eine dreiviertel-Stunde deinen Fehler suchst hast du für unter Mindestlohn gearbeitet. Mit den übrigen PWM-Kanälen kannst du sogar noch weitere Spielereien nachrüsten. Mit der sicher mitgelieferten Standardlib für I²C ist der Code ruckzuck gestrickt um die paar Register zu schreiben. Vielleicht gibts ja sogar was fertiges.
Schon gesehen? https://arduino-projekte.info/servo-ansteuern-arduino-esp8266-esp32/ Da du keinerlei Programmcode lieferst, ist die Hilfestellung doch sehr anstrengend.
Max D. schrieb: > Besorg dir ein PCA9685 Modul. Mit der Auflösung von knapp 8 Bit für die Servopulsbreite kommt es dann auf die mechanische Umsetzung an, ob in 2m Entfernung noch eine Auflösung von 1cm erreicht wird. Zwischen Richtung von Servoarm und Laserpointer müsste dafür etwa eine 1:2 Untersetzung des Winkels vorhanden sein.
STK500-Besitzer schrieb: > Schon gesehen? > https://arduino-projekte.info/servo-ansteuern-ardu... > > Da du keinerlei Programmcode lieferst, ist die Hilfestellung doch sehr > anstrengend. Danke, aber darüber bin ich längst hinweg. Es geht um den sporadisch auftretenden Fehler (vermutlich aus den Tiefen der ESP-Firmware) und NICHT um Grundsätzliches.
Wolfgang schrieb: > Max D. schrieb: >> Besorg dir ein PCA9685 Modul. > Mit der Auflösung von knapp 8 Bit für die Servopulsbreite kommt es dann > auf die mechanische Umsetzung an, ob in 2m Entfernung noch eine > Auflösung von 1cm erreicht wird. Zwischen Richtung von Servoarm und > Laserpointer müsste dafür etwa eine 1:2 Untersetzung des Winkels > vorhanden sein. Och Mensch Leute, was soll der Unfug? Ich will weder das Projekt umbauen oder andere Chips oder Hebel verwenden, auch genügt die Genauigkeit vollkommen. Ich möchte lediglich wissen, warum es ca. 20x einwandfrei !!! funktioniert und (gefühlt) beim 21. Mal nicht ...
:
Bearbeitet durch User
Frank E. schrieb: > Ich möchte lediglich wissen, warum es ca. 20x einwandfrei !!! > funktioniert und (gefühlt) beim 21. Mal nicht ... Miss die Pulsdauern nach. Falls es die erzeugte Pulslänge ist, könnte z.B. ein auflaufender Interrupt höherer Priorität den Ausgabepuls verlängern - kommt drauf an, wie deine Standardbibliothek die Pulse erzeugt. Servopulse kommt standardmäßig mit einer Periodendauer von 20ms und die Pulsdauer liegt um die 1.5ms - je nach dem, wo dein Arbeitspunkt liegt. Das wäre dann dicht an deinen 1:20. Falls soetwas der Grund ist, müsste dein Servo immer in die selbe Richtung abhauen.
Frank E. schrieb: > Ich möchte lediglich wissen, warum es ca. 20x einwandfrei !!! > funktioniert und (gefühlt) beim 21. Mal nicht ... RP6conrad schrieb: > Ich glaube das der Wifi-Ablauf in Wemos den arduino > sketch unterbrecht, und das haben sie nicht in der Hand. Das war doch eine Antwort, nicht zufrieden? Frank E. schrieb: > Harald schrieb: >> Wie wäre es mit Steppermotoren, > Danke, aber ich glaube du hast meinen Eingangspost nicht richtig > gelesen. Doch, aber bis dahin dachte ich noch es ginge um Lösungen und nicht um Betriebssystem-Esoterik.
Frank E. schrieb im Beitrag > Ich möchte lediglich wissen, warum es ca. 20x einwandfrei !!! > funktioniert und (gefühlt) beim 21. Mal nicht ... Das musst du debuggen. Finde raus was beim 21. mal anders ist und dann warum es anders ist. Danach überlege wie du den Fehler beseitigen kannst. Also Debugausgaben/Logging in dein Programm, LA ran und alles was sonst noch notwendig ist. Und das ist jetzt kein Problem was du hast, das gehört immer dazu wenn man was programmiert. Also alles so wie es sein soll.
Ich wollte mir eigentlich angewöhnen mich aus sich derart entwickelnden Threads in Folge herauszuhalten. Meine letzte Ausnahme, dann kommt von mir hier nichts mehr, versprochen! @Frank E. Ohne dir zu nahe treten zu wollen, aber deine Tricks mit vorherigem Anfahren einer Nebenposition, dann weiterfahren, und die mechaische Bremse/Dämpfer mit leichter mechanischer Vorspannung deuten doch stark darauf hin, das deine Servos (und nicht deine Software) dein Problem darstellen. Ich habe den Vorschlag "Sündhaft teure Digitalservos verwenden" bewusst so formuliert; das ist genau so gemeint wie es geschrieben steht. Deine Billigservos bringen es offenbar nicht. Beispielsweise dort wird dir sogar mit Sonderanfertigungen geholfen: https://www.multiplex-rc.de/ueber-uns/industrie-servos.html
Wie werden die Servos versorgt? Mal testweise an eine eigene Batterie hängen? Edit: nach dieser Diskussion ist das wohl überflüssig, das Problem eher wie hier auch schon gennant wurde die Störungen durch Interrupts/wifi stack und deshalb die Lösung mit ext. PWM Generator durch PCA IC. https://www.reddit.com/r/esp8266/comments/6i5zue/software_pwm_disadvantages/
Frank E. schrieb: > verwende ich die (Arduino-) Standard-Servo-Lib. Soll > ich die hier reinstellen? Ich nehme an, dass die millionenfach von > anderen verwendet wird. Eine frozzelige und bornierte Antwort. Dein Code besteht nicht nur aus einer Arduino Servolib. > Evtl. ist die beschriebene Macke ja auf einen Bug in der Firmware des > Wemos begründet? Ein Standard unter Programmieranfängern: alles auf die Hardware, Fremdsoftware schieben, der Bug ist überall anders, nur nicht vor dem Bildschirm. Du hast wahrscheinlich irgendwo gepfuscht (oder überall) und das macht sich im beschriebenen Verhalten bemerkbar. Frank E. schrieb: > Ich habe mir nicht umsonst die Mühe gemacht, das Problem so > datailiert zu beschreiben. Detailliert? Da war doch nichts zur Sache detailliert. Hättest Du geschrieben: "Servos fahren nicht immer exakt an die bestimmte Position", so wäre das genauso inhaltsleer gewesen. > Nochmal: Die Servos fahren zunächst auf die richtige Position, halten > dort für ca. 1s und gehen dannach erst auf die falsche Position. Nur das gerade fahrende Servo oder sind andere, ruhende auch betroffen? Einfach mal dafür sorgen, dass ein bewegtes Servo erst nach z.B. 3 Sekunden wieder bewegt werden kann und schauen was passiert. Wenn Du ein Debug-Print auf die Serielle machen und beim Schreiben der Servopositionen diese ausgeben würdest, dann würde man erkennen, ob sich etwas ändert. Ob dieser Ansatz Sinn macht, hängt wieder davon ab ob die Servopositionen direkt mit Konstanten geschrieben werden, oder mit Variablen, die irgendwie eine nachträgliche Änderung erfahren können. Ohne Beispielcode kann man das nicht wissen und wenn Du Dir nicht das klein wenig Mühe machst, wenigsten einen gekürzten Code zur Verfügung zu stellen, warum sollen andere sich die Mühe machen zu erraten, wo der Murks liegt?
RP6conrad schrieb: > Ich glaube das der Wifi-Ablauf in Wemos den arduino > sketch unterbrecht, und das haben sie nicht in der Hand. Dazu möchte ich ergänzen, dass der ESP8266 die PWM Signale per Software generiert und diese in unregelmäßigen Abständen durch die Basis-Firmware unterbrochen wird. Daher ist es mit diesem Chip unmöglich, bei eingeschaltetem WLAN Interface, saubere PWM Signale zu erzeugen. Du bist hier nicht der erste, der daran scheitert. 2 Cent schrieb: > Deine verwendeten Analogservos sind ungeeignet, ausserdem > wird sich ihre Wiederholgenauigkeit durch Alterung noch > verschlechtern. Das kommt noch dazu.
Stefanus F. schrieb: > RP6conrad schrieb: >> Ich glaube das der Wifi-Ablauf in Wemos den arduino >> sketch unterbrecht, und das haben sie nicht in der Hand. > > Dazu möchte ich ergänzen, dass der ESP8266 die PWM Signale per Software > generiert und diese in unregelmäßigen Abständen durch die Basis-Firmware > unterbrochen wird. > > Daher ist es mit diesem Chip unmöglich, bei eingeschaltetem WLAN > Interface, saubere PWM Signale zu erzeugen. Du bist hier nicht der > erste, der daran scheitert. > Danke für die sachliche Antwort, klingt logisch. Womöglich erreiche ich nicht die maximal mögliche Genauigkeit meines Systems. Aber das kann nicht die Ursache des von mir beschriebenen Fehlers sein. Ich nehme an, dass die "störenden" anderen Interrups wesentlich häufiger aufgerufen werden und deshalb eher zu permanenten Ungenauigkeiten bei jeder Positionierung oder gar zu ständigem "tänzeln" der Servos führen müssten. Wieso dieses (jeweils einmalige) "Nachtreten" nach kurzer Ruhe? Ich muss nochmal die Beschreibung wiederholen: a) die Servos fahren die richtige Position an (in 80% der Fälle) b) nach ca. 1s verfahren sie auf eine (geringfügig) falsche Position Also die PWM wird z.B. auf 1600ms gestellt. Der Servo fährt dort hin. Dann verstellt nach ca. 1s irgendwas die PWM auf 1610ms und die bleibt dann aber auch so stabil bis zum nächsten Aufruf - dann stimmt sie wieder.
Frank E. schrieb: > Ich nehme an, dass die "störenden" anderen Interrups wesentlich > häufiger aufgerufen werden und deshalb eher zu permanenten > Ungenauigkeiten bei jeder Positionierung oder gar zu ständigem "tänzeln" > der Servos führen müssten. Dann solltest du mal prüfen, ob die Servos um die Position nicht einen Totbereich haben und wie groß der ggf. ist, eben genau damit sie nicht permanent "tänzeln".
Du hast zwei Erklärungen bekommen, die Dir nicht gefallen. So ist es aber nun einmal. Solange du darauf beharrst, dass dein nicht gezeigtes Programm fehlerfrei ist und dass du geeignete Bauteile ausgewählt hast, kommst du nicht weiter. Deine Einstellung zu der Sache behindert die Fehleranlayse stark. Es gibt hier nur eins, was Dich weiter bringt: Die Signale zum Servo überprüfen. Aber auch das wurde ja schon gesagt.
Frank E. schrieb: > In ca. 19 von 20 Fällen funktioniert das Ganze genau so, wie es soll. Frank E. schrieb: > a) die Servos fahren die richtige Position an (in 80% der Fälle) Wie sich doch im Laufe eines Threads die Fehlerquote ändert, von einem fast richtig funktionierendem System mit 5% Fehler zu einem kaputtem mit 20 % Fehler. Ganz unten Im Thread steht dann, dass es noch nie funktioniert hat. ;D Versuchsweise könnte man vor das Servo-Write() ein Yield() setzen, damit der ESP8266 seine Hausaufgaben vorher erledigt.
Kann mir bitte jemand mal folgendes erklären: Warum verschwendet ihr alle eure Zeit damit hier noch weiter zu posten, obwohl der TO ein paar Lösungsansätze schon nach wenigen Posts erhalten hat, diese aber noch nicht einmal untersucht hat. Das ergibt überhaupt keinen Sinn. Das gilt sowohl für den TO als auch alle anderen Poster. Ich mein.. ist zwar nett wenn ihr euch so damit auseinandersetzt aber ihr diskutiert das Problem alle irgendwie gerade einfach nur tot, anstatt es zu lösen. Lieber TO: Fang doch bitte endlich mal an zu debuggen. D.h nachmessen, wie die Steuerimpulse, die dein Servo erhält, timingmäßig aussehen. Dann kann man weiterspekulieren und weiteruntersuchen. Du willst doch zum Ziel kommen, nicht?
Paul H. schrieb: > ihr diskutiert das Problem alle irgendwie gerade einfach nur tot Der normale Wahnsinn, jeden Tag neu, hier in ihrem Forum. Wer hat noch nicht? Wer will nochmal? Du hast damit absolut Recht.
Paul H. schrieb: > ihr diskutiert das Problem alle irgendwie gerade einfach nur tot, > anstatt es zu lösen. Lösen muss es der TE, das ist nicht unser Job, unser Job ist das diskutieren und das machen wir ja auch. Egal wie borniert und auf "seine" Fehlerursache fixiert der TE auch sein mag, er wird zudiskutiert bis er entweder aufgibt, oder bereit ist ein wenig offener auf Anregungen eingeht, bzw. seinen Job des Debuggens zu machen. Wie aus dem Anfangspost erkennbar wollte der TE nur eines hören, nämlich das es ein Fehler in der Arduino-Lib ist. Zumindest die Schwäche derselben wurde ihm bereits erklärt. Und nun isser weg, weil er annimmt dass sich seine Befürchtung bewahrheitete und er da nichts daran ändern kann. Oder er hockt jetzt auf der Couch, futtert Chips und zieht sich ein Bier rein. Zur Diskussion wird er eh' nicht gebraucht.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.