Pin 18 + Servo fällt aus

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Hallo Zusammen,

    ich hab ein sehr merkwürdiges Phänomen an meinem Raspi am beobachten.
    Ich hab einen Rover gebaut der mit Hilfe eines Servos das Ultraschallmodul permanent in 3 Stufen links, rechts, mitte Messungen vornehmen soll.
    Soweit funktioniert dies sehr gut. Doch nach ein paar Minuten steigt der Servo immer aus und bleibt einfach stehen. anfangs hab ich gedacht das liegt an dem Software PWM,
    daraufhin hab ich ihm mal den Hardware (BOARD)Pin 12 GPIO 18 dafür gegeben. Da dieser ja bekanntlich richtiges PWM über die CPU berechnet. Jedoch steigt der dort genauso schnell aus wie bei den anderen Pins. Ich bin etwas frustriert und mir fehlt ein Ansatzpunkt wie ich das Problem lösen kann. Vielleicht habt Ihr auch solche Erfahrungen gemacht das Euer Servo bei permanenter Bewegung einfach irgendwann stehen bleibt. Und wie man das lösen kann.
    Ich bin schon hingegangen und hab mal auf den Signalpin 18 ein 100 Ohm Wiederstand dazwischengesetzt. Aber ohne Erfolg.

    Schreibt mir mal was dazu wie man das lösen kann

    danke

    MFG

    Zappelmann

  • vielleicht falsche LIB ?

    dreamshader hatte glaube ich mal darüber was geschrieben das manche bei PWM zicken.....

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • nein ein Osziliskop hab ich leider nicht ist ein wenig teuer diese Hardware ^^
    Ich nutze die LIBs RPI.GPIO und time sonst eigentlich nichts bis auf die smbus, aber die nutze ich ausschließlich für den MCP23017 der die LED´s steuert.
    gibt es denn noch andere LIB´s die man für PWM einsetzen kann ?
    Ich nutze ein 50 hz Signal zur Ansteuerung des Servos. hier mal den Code den ich dazu benutze.

  • Tach zusammen ...


    vielleicht falsche LIB ?
    ...


    da hat er recht, unser Belliner ... äh Bärliner ;) ...
    Wie hast Du das Program realisiert, welche Module, welche Sprache, ...
    Im Zweifelsfall mag pigpio ausprobieren, das habe ich meistens im Einsatz und hatte bisher keine Probleme. Einen Dauerläufer habe ich allerdings noch nicht ausprobiert.

    bye,
    -ds-


  • vielleicht falsche LIB ?

    dreamshader hatte glaube ich mal darüber was geschrieben das manche bei PWM zicken.....

    weisst du zufällig den genauen Beitrag ? denn bei über 3000 Beiträgen suche ich scheinbar noch nächstes jahr nach dem bestimmten Beitrag

    bitte linken.

    MFG

    Zappelmann

    ach da isser ja direkt hallo dreamshader
    sag mal hast du nen ts das wir uns kurz darüber unterhalten können meinetwegen hier das forums ts ?

    Einmal editiert, zuletzt von Zappelmann (31. Mai 2014 um 16:21)

    • Offizieller Beitrag

    Wenn wir es schaffen in einem Jahr (Oh ich hab meinen Forengeburtstag verpasst....) 3k+ Beiträge zu schreiben, dann sollte das lesen deutlich schneller gehen ;). Warum ist dein Code oben unvollständig?

    Der Unterschied zwischen Genie und Wahnsinn definiert sich im Erfolg.

    Einmal editiert, zuletzt von dbv (31. Mai 2014 um 16:26)


  • Tach zusammen ...


    da hat er recht, unser Belliner ... äh Bärliner ;) ...
    Wie hast Du das Program realisiert, welche Module, welche Sprache, ...
    Im Zweifelsfall mag pigpio ausprobieren, das habe ich meistens im Einsatz und hatte bisher keine Probleme. Einen Dauerläufer habe ich allerdings noch nicht ausprobiert.

    bye,
    -ds-

    Ich habe es komplett in Python geschrieben. Diese PIGPIO kenn ich bisher nicht uns weis uach nicht wie ich die am besten dafür einsetzen kann. Wäre dankbar für ein Teamspeka talk mit dir. Damit ich das besser verstehen kann was du mit der Lib meinst.

    MFG

    Zappelmann

    Weil der sehr lang ist und ich den jetzt nicht voll dokumentiert habe. Sonst kann niemand was damit anfangen. ich kann den aber auch mal vollständig reinsetzen. Nur dann bitte nicht mekern das der so lang ist nicht dokumentiert und nicht irgendwelchen Standards folgt. Denn ich bin noch Anfänger was Python angeht.

    Fakt ist aber dass das Programm sauber funktioniert bis auf das der Servo halt irgendwann aussteigt.

    Einmal editiert, zuletzt von Zappelmann (31. Mai 2014 um 16:36)

  • Also, ich fass mal kurz zusammen:
    ich würde jetzt mal mit möglichst wenig Aufwand die wiringPi- (kann Python) und die pigpio-Bibliothek austesten, ob die im Dauerbetrieb auch Probleme machen.
    Die entsprechende Library dann halt verwenden, um Dein Programm zu realisieren.
    Das ist kein Hexenwerk und kriegen wir schon irgendwie hin ;)

    Was mir noch einfiel: wie hast Du denn den Servo verschaltet und welchen hast Du da im Einsatz ...
    Nicht dass es nachher daran liegt und wir hier eine Luftnummer hinlegen.

    Tja, dann bis zum Nächstenmal,
    -ds-

  • also ich habe diese Servos hier im Einsatz.
    Und ich nutze nur den Tilt servo als den unteren um insgesamt 180 grad abzudecken.
    Desweiteren wie ich schon erwähnte hab ich aktuell Pin GPIO 18 am nutzen. wo der Servo sein Signal drüber bekommt. Ansonsten 5V plus und GND. Zusätzlich hab ich testweise mal ein 100 Ohm Wiederstand auf das Signal zwischengehangen, aber das hat keine Auswirkung gehabt.
    Was die PIGPIO angeht jo ich werde das mal durcharbeiten und schauen ob ich mein Script auf diese Libary angepasst bekomme. Sollte ja eventuell nicht so schwierig sein. Ich melde mich wieder sobald ich die Software umgeschrieben habe.

    Natürlich bin ich weiterhin offen für weitere Vorschläge um mein Problem zu lösen.
    Viellecht mag ja mal jemand anderes mit nem anderen Servo auch ein Test starten um zu schauen ob das ein allgemeines Problem ist oder ob nur ich das so habe.

    MFG

    Zappelmann

  • Ok, ist soweit angekommen ...

    Einen hab' ich aber noch: woher bekommt der Servo seine 5V?
    Von der GPIO-Leiste (Pin #2) des RPi? Wenn ja, befeuerst Du den RPi über die Micro-USB-Buchse? Das wird dann vermtlich mehr als eng (miss mal nach, wieviel mA der Servo zieht).
    In diesem Fall mal eine eigene Spannungsversorgung für den servo ausprobieren oder eine andere Art der Versorgung des RPi ( guckst Du mal -> hier <- ).
    ciao,
    -ds-

    Hab noch was vergessen:

    Zum Thema Pin mit Hardware-PWM-Unterstützung ...
    In den Forenbeiträgen,, die ich so im Laufe der Recherche wegen PWM so durchsucht habe, ist immer wieder davon abgeraten worden, diese Pins zu verwenden. Sie werden vom Soundsystem benötigt und es wäre sinnvoller Soft-PWM zu nutzen.
    Darüber bin ich dann auf pigpio gekommen, weil wiringPi - zumindest zu dem Zeitpunkt - sogar lt. Autor Schwierigkeiten bei mehreren PWM-Kanälen hat (brauchte ich damals für -> diese <- Ansteuerung einer RGB-LED).

    cu,
    -ds-

  • Hi

    so hier zu den angefragten Infos ein paar Antworten.

    zum einem nutze ich diesen Motorshieldtreiber

    Desweiteren gibt es über die Micro USB Schnittstelle keine Spannungsversorgung. Dies wird außschließlich über den PIN 2 geregelt. Da ich eine Spannung von 7,5 V direkt an das Raspiboard anlege. Im Akkubetrieb sind es sogar nur 6V.
    die Spannung wird nur über das RaspiRobotBoard eingespeisst.
    Durch ein Spannungswandler gejagd, der mir dann die 5V für den Raspi auf Pin 2 einspeisst. Ansonsten gehen die 6V in den die Motoren die soweit ich weis mit maximal 600 mAh befüttert werden können zumindest ist es das was ich zu dem Motortreiber IC rausgefunden habe. L293DNE
    Ja richtig ist der Servo verfügt daher über keine eigene Spannungsversorgung direkt von einer Quelle, da der indirekt mit über Pin 2 versorgt wird. Könnte ich aber ändern. Dazu müsste ich wohl noch eine weitere Leitung von dem Akku zu einem Breadboard legen und dann die Spannungsversorgung von dem Servo mit auf die Linie legen. Das kann ich mal ausprobieren. Masse denke ich mal kann ich ja überall anlegen wo es eh schon vorhanden ist. Gibt bei meinem Bau jede menge davon ^^
    Was das Strommessen angeht, hmmm gute Frage wie viel der benötigt oder verbraucht weis ich aktuell nicht. Kann ich bestimmt herausfinen wenn ich wieder zu Hause bin und mein Messgerät mal dranhalte. Aber ob ich dann eine saubere Messung hinbekomme wage ich jetzt mal zu bezweifeln Da der im laufenden Modus ja permanent ein neues Signal bekommt, wo es schwierig sein wird da eine sauber stabile Messung hinzubekommen, aber ich werde es mal ausprobieren.

    Ich hab da so eine Ahnung worauf du hinaus willst. Ich bin mir auch ziemlich sicher das es wahrscheinlich sogar daran legen wird. Aber wenn du meinst das ich dem eine eigene Stromquelle geben sollte Ohne über Pin 2 zu gehen wo der nur 5V bzw. 4,8V beziehen kann. Müsste ich wissen ob ich da noch ein Wiederstand vorparken sollte damit der sich nicht zuviel Strom reinzieht und mir der Servo dadurch durchbrennt. Sonst Adjö Servo im Servonirvana. ^^
    Liege ich mit meiner Vermutung hier richtig ?
    Wenn ja dann werde ich es austesten.
    Die Autonome Quelle ist ein 6V Bleiakku mit 4,5 Ah. Das reicht ca. 2 Stunden dann ist das Akku am ende und ich muss wechseln.
    Ich hab mir letzte Woche noch ein Netzteil zugelegt. was ich zwischen 6 -15V schalten kann mit max 5000 mAh. dies nutze ich wenn ich den Rover auf meinen Schreibtisch stehen lasse um daran zu basteln oder zu programmieren. Dabei schalte ich den dann auf 7,5V damit habe ich eine ausreichende Spannungs und Strom Versorgung geschaffen.
    keine Panik dank des Spassnungswandler der sogar bis zu 12V reguliert bekommt der Raspi nur seine 5V nicht mehr.

    So wolltest noch etwas wissen wenn ja dann einfach fragen.

    hier mal ein Movie von dem Servo der immer wieder den Geist aufgibt.
    hier noch eins wo er voll in Aktion ist.

    So was die PIGPIO LIB angeht also ich hab mir die mal vorhin etwas genauer angesehen, aber mir fehlen da ein paar wichtige Antworten. Bisher war ich es gewohnt mit die Pins in meinen Scripten so zu definieren.

    Code
    GPIO.setmode(GPIO.BOARD) #oder (GPIO.BCM)
    GPIO.setup(19,GPIO.OUT)

    Wie muss ich das mit der PIGPIO Lib dann machen ?
    und werden auch alle PINS angesprochen wie in der RPi.GPIO Lib ?
    Siehe dazu mal den Code von mir ganz oben wo alles definiert wurde. Nicht die Hexwerte die sind nur für smbus für den MCP23017, der ist hier jetzt irrelevant.

    Dies wäre mal ein erster Schritt um mich dieser Lib zu nähern und mein Script mal auf die andere Lib anzupassen. (Bitte immer dran denken, ich Anfänger in Python und Raspi)

    Achja da fällt mir gerade noch etwas anderes ein was mir schon seit anfang an auf den Sender geht. Als ich den Raspi gekauft habe, gab es ja diesen kleinen Edimax WLAN Stick dazu. Den ich auch nutze, aber das Scheis Teil hat immer Verbindungsabbrüche, egal welches WLAN ich nutze. Ich arbeite überwiegend mit AVM Routern 7390 / 7490.
    Ich hab schon mal ein Tut gefunden wo man ein kleines Script in den Autostart einbauen kann der die WLAN Verbindung prüft und bei festgestelltem Abbruch diese wieder herstellt. Hab das schon auf 1 min prüfen gesetzt. Aber der verliert trotzdem immer noch regelmäßig immer wieder seine Verbindung, gibt es dazu ein Workaround oder sowas in der Art ? Ich behelfe mir im Moment indem ich in Putty ein permanentes Byte senden lasse damit die Putty Verbindung zum Raspi nicht ständig abbricht. Dies funktioniert zwar sehr gut. Bringt aber nicht viel wenn ich nicht direkt eine Verbindung nach dem Bootvorgang initiiere.

    Soviel mal dazu, vielleicht weis dazu jemand mal mitlerweile eine Lösung wenn ja mal bitte hier eben nen Link dazu. Aber bitte keine anderen Hardwarevorschläge. Das muss ja irgendwie mal gefixt worden sein. Nur bisher hab ich dazu nichts schlüssiges gefunden.

    So desweiteren habe ich mir Überlegt ob ich nicht sogar ganz auf den Servomüll verzichten sollte. Denn mitlerweile hat er sich schon 2 mal ne Blutige Nase geholt und vorne den Servoabgerissen wenn er doch vor ein hartes Hindernis stößt.
    Mein Gedankengang hierbei ist eher mit 3 - 5 Ultraschall Modulen zu arbeiten. Nur dabei werden mir die Pins rechtschnell ausgehen. Denn ich benötigte ja für jedes Modul 2 Pins Trigger/Echo also mal eben 10 Pins. Da kommt mal eben schnell die Frage auf kann ich sowas über ein I2C IC lösen, sprich das der HC-SR04 US-Modul ja über die GPIOs benutzt wird und der MCP23017 mir ja im endeffekt auch nur weitere GPIOs zur Verfügung stellt. Nur halt anders angesprochen. [0x01] usw... Oder benötige ich dafür eventuell ein weiteres Shield, wo ich dann über genug GPIOs verfüge und so viele US-Module anzusteuern. Denn dann würde ich eher hingehen diese Module einmal rundum aufbauen, und permanente Messungen laufen lassen und wenn dann bei einem Modul in der jeweiligen Richtung besonders die drei vorderen siehe Video wie der misst. eine Distanz unterschritten wird, soll der dann garnicht erst anhalten sondern direkt in die
    (links Signal unterschreitung nach rechts ausweichen / rechts nach links ausweichen / vorn links und rechts vergleichen welche Distanz größer ist und dorthin ausweichen) entgegengesetzte Richtung ausweichen und somit das Hinderniss direkt ausweichen ohne vorher zu stopen. Ein Stopp wäre dann nur noch nötig, wenn er in ein Engpass fahren würde wo vorn 180 Grad dann überall die Minimaldistanz unterschreiten würde, sodas er nicht weiter fahren kann und nur noch rückwärts aus dieser Sackgasse käme.

    So dies mal mein Gedankengang. Um diesen Servomüll zu umgehen. Das hört sich wahrscheinlich eher so an als wenn ich mich der Herausforderung dieses Problems mit den Servos nicht stellen mag. Aber generell ist es ein Problem das die Messungen mit dem Servo so lange dauern, dass er doch immer wieder irgendwo vorfährt bis der eine zu niedrige Distanz misst, wo er dann sein Stopsignal bekommt. Ich kann natürlich die Distanz erhöhen damit der schon früher stoppt, aber ich hab eine kleine Wohnung und von daher nicht sehr viel Platz wo der gerade wenn der auf glatten Böden auf Speed kommt dann bei der entsprechenden Geschwindigkeit nicht zum stehen kommt und voll vor die Wand fährt und sich dabei jedesmal eine Blutige Nase holt. ^^

    Also was sagt ihr zu dem Gedankengang macht das Sinn oder ist es eher unrealistisch ?
    Dies ist nur ein alternativer Lösungsansatz der ein anderes Problem der Geschwindigkeitssteuerung mit lösen würde. Eventuell aber auch nicht. Ist mal wieder Erfahrungsache die ich erst noch machen muss und mich wahrscheinlich viel Kohle kosten wird ..... ^^

    Natürlich bleiben wir in erster Linie bei dem Servo Problem denn ich will es lösen....


    MFG

    Zappelmann

  • Ich habe mir Deine Videos mal angeschaut. Der Servo wird ja mächtig belastet. Kann es sein, dass Du einen nutzt, der eine Eigensicherung gegen Überlastung hat. Fährt er wenn er aussteigt immer an die selbe Position? Die Lösung mit dem Portextender und mehreren Sensoren scheint mir die Bessere zu sein. Obwohl, irgendwie siehts cool aus, wenn Dein Robot nach dem Hindernis nach Links und Rechts schaut, um zu sehen wo es langgeht.


  • Ich habe mir Deine Videos mal angeschaut. Der Servo wird ja mächtig belastet. Kann es sein, dass Du einen nutzt, der eine Eigensicherung gegen Überlastung hat. Fährt er wenn er aussteigt immer an die selbe Position? Die Lösung mit dem Portextender und mehreren Sensoren scheint mir die Bessere zu sein. Obwohl, irgendwie siehts cool aus, wenn Dein Robot nach dem Hindernis nach Links und Rechts schaut, um zu sehen wo es langgeht.

    Hi

    also von einer Sicherung ist mir nichts bekannt.
    Und ja er steigt immer an der selben Position aus, wenn er nach vorn ausgerichtet ist.
    Ja cool sieht es aus, das stimmt schon aber wenn das so nicht funzt weil der mit der Dauerbelastung nicht klar kommt würde ich echt eher die alternative ausprobieren.

  • ich würde auch zu mehr Sensoren tendieren, dieses Geflatter der Servos kann doch nur in Kabelbruch und vorzeitig leere Akkus enden.

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • Also ich hab dem Servo jetzt mal eine eigene Spannungsquelle gegeben aber das ist wohl scheinbar nicht das Problem. Denn nach ein paar Minuten setzt dieser dann auch wieder aus.
    Scheinbar liegt das Problem beim Signal dort steigt der dann immer wieder aus.

  • Ja hey,
    immer noch am tüfteln ...
    hast Du mittlerweile mal nachgemessen, was der Servo so an Strom zieht?
    Das mit der eigenen Stromversorgung ist ja ok, aber besser wäre es, wenn Du das Endprodukt hier inkl. einiger Daten auch visualisieren würdest.
    Evtl. machst Du ja unbewusst immer den gleichen Fehler, den Du schon aus Gewohnheit übersiehst ( glaub mir, ich weiss wovon ich rede :lol: ) ...
    Fritzing wär nicht schlecht ... aber auch eine handgemalte Skizze tut es ....

    cu,
    -ds-


  • So den Strom hab ich versucht zu messen aber irgendwie scheint mein Messgerät da nicht mehr mitzumachen ich kann damit leider nur noch Spannung und Wiederstand messen. Muss mir wohl ein neues zulegen.

    Ja ne Skizze hmmm das wird schwierig. Da das Teil schon ziemlich komplex aufgebaut wurde. Zumal wie soll ich denn das Raspirobotboard damit draufpacken, dazu gibbet leider keine Vorlage in Fritzing. Aber ich schau mal was sich da machen läst.
    Fakt ist aber das Signalkabel vom Servo hängt direkt an Pin 12 GPIO18 sonsthängt da nix dran an dem PIN

    Und ja bin immer noch am tüfteln. So schnell gebe ich nicht auf ich bin da sehr hartnäkig. Aber davon mal abgesehen ich hatte einige Fragen bezüglich der Lib gestellt wie hier noch nicht beantwortet wurden. Wäre gut wenn da mal jemand was zu schreiben würde.

    MFG

    Zappelmann


  • ...
    So was die PIGPIO LIB angeht also ich hab mir die mal vorhin etwas genauer angesehen, aber mir fehlen da ein paar wichtige Antworten. Bisher war ich es gewohnt mit die Pins in meinen Scripten so zu definieren.

    Code
    GPIO.setmode(GPIO.BOARD) #oder (GPIO.BCM)
    GPIO.setup(19,GPIO.OUT)

    Wie muss ich das mit der PIGPIO Lib dann machen ?
    und werden auch alle PINS angesprochen wie in der RPi.GPIO Lib ?
    ...

    -> Hier <- ist ein Beispiel zur Ansteuerung von zwei, allerdings DC-, Motoren mit der pigpio.

    Das Ansprechen der GPIOs erfolgt über ihre Broadcom-Nummer. Ein ent- oder weder wie bei dem anderen Teil das Du verwendet hast ( ich aber dafür nicht kenne ;) ) gibts nicht.

    Weitere Infos findest Du in der Online-Doku. Wenn dann noch was unklar ist ... fragen ...


    ...
    Als ich den Raspi gekauft habe, gab es ja diesen kleinen Edimax WLAN Stick dazu. Den ich auch nutze, aber das Scheis Teil hat immer Verbindungsabbrüche, egal welches WLAN ich nutze.
    ...

    Das ist, zumindes für mich, ein known issue ( -> hier <- ).
    Ich bin mittlerweile bei 3.12.19+ angekommen, und seit einiger Zeit hat sich das Verhalten verbessert.
    //EDIT:
    Ach ja - ich habe seinerzeit den ifplugd deinstalliert. Das hat einiges gebracht und das WLAN lief seit dem wesentlich sauberer.
    Alternativ könntest Du einen anderen WLAN-Stick probieren. Die Dinger sind ja mittlerweile relativ preiswert, und bevor ich mich da rumärgern würde, tät ich das andere Teil rausschmeissen und mir z.B. einen WL0084B besorgen.


    ...
    ich hatte einige Fragen bezüglich der Lib gestellt wie hier noch nicht beantwortet wurden. Wäre gut wenn da mal jemand was zu schreiben würde.
    ...

    sorry ... danke für den Hinweis. Da hätte ich jetzt nicht mehr dran gedacht.
    Ich hoffe das, was ich dazu angemerkt habe, reicht Dir.

    So long,
    -ds-

  • Jo erstmal danke für deine Infos ich werde mir das jetzt mal in ruhe durchlesen und melde mich dann später wieder hier.

    Eins habe ich aber noch, ein Kollege von mir hat mir mal heute den Tipp gegeben ich sollte den Servo doch mal mit nem Zufallsgeneratorprogramm laufen lassen, um damit mal ein dauerbelastungstest zu tätigen. Also unabhängig von meiner bisherigen Software. Jetzt wollte ich mal fragen ob hier jemand dazu ein Script in C oder Python für so ein Belastungstest kennt was ich dazu mal nutzen könnte.

    MFG

    Zappelmann

    Ach ja was leider noch nicht beantwortet wurde fällt mir gerade wieder ein, Ich suche noch ein expansion Board für den Raspberry. Wo ich weitere GPIOs zur verfügung hätte. Natürlich sollte das nicht unbedingt eine SPI oder I2CErweiterung sein. Ich hab mir mal eben das Gertboard angesehen ist dies sowas was ich suche oder gibt es da noch andere gute Erweiterungsboards die man mit dem Raspi zusammen nutzen kann ?

    MFG

    Zappelmann

    Einmal editiert, zuletzt von Zappelmann (2. Juni 2014 um 21:12)

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!