- LiFePO4 Speicher Test         
Seite 2 von 4 ErsteErste 1234 LetzteLetzte
Ergebnis 11 bis 20 von 34

Thema: 1 Jahr erfolglos progrmmiert - verzweifelt - python-Programmierer gesucht

  1. #11
    HaWe
    Gast
    Anzeige

    LiFePo4 Akku selber bauen - Video
    das ist ja schon mal ne ganze Menge. Zur Fehlersuche musste du aber Teile abschalten und nur Einzelkomponenten testen.
    Probleme, die ich sehe:
    Python ist absolut nicht echtzeitfähig,
    WLAN ist absolut nicht echtzeitfähig,
    und Threads stören sich gegenseitig, wenn wichtige Threads keine höhere Priorität haben als andere, die warten können.

    Also teste doch mal nur nackt WLAN in Verbindung mit der Motorsteuerung, ohne alles andere.

    (ich selber kann kein Python, ich verabscheue diese "Sprache", ich verwende C(++), weil es klar ist und streng strukturiert und pthread Multithreading auch mit thread priorities erlaubt, bis hin zur Echtzeitfähigkeit.)

  2. #12
    Benutzer Stammmitglied
    Registriert seit
    07.09.2017
    Beiträge
    52
    Nun, bei der Sprachwahl bin ich ganz offen. Ob C++, Java oder Python ist mir insofern egal.
    Die Wahl ist damals auf Python gefallen, weil wie gesagt die GPIO einfach angesprochen werde konnten, ich überall gelesen habe, dass es die beste Möglichkeit sei und ich am meisten Tutorials gefunden habe.
    Aber da lasse ich mich gerne eines Besseren belehren, denn die meisten in diesem Forum habe sicher mehr Erfahrung im Modellbau und der Programmierung als ich. Meine Stärke liegt da eher bei Datenbanken, Excel und Finanzanalysen...

    Die Latenzzeiten bei diesem Konstrukt sind mir auch aufgefallen. Daher wollte ich über Variablen nachschauen, ob sich der aktuelle Wert der Einstellung für die Motoren um einen gewissen Prozentsatz, z.B. 5%, verändert hat und ansonsten soll nichts am aktuellen PWM-Signal verändert werden. Das Umschalten der Lichter/Kameras und die Blinker funktionieren soweit einwandfrei, manchmal zwar erst auf den zweiten Klick, aber damit könnte ich leben.

  3. #13
    HaWe
    Gast
    probier erst mal, ob du dein Problem, wie ich es vorgeschlagen habe, eingrenzen kannst. Dann kann man weiter entscheiden.

  4. #14
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    18.01.2012
    Beiträge
    485
    Hallo,
    das schon gelesen ?
    https://www.elektormagazine.de/files/attachment/196

    Gruß

  5. #15
    Benutzer Stammmitglied
    Registriert seit
    07.09.2017
    Beiträge
    52
    So, ich habe die Skizze des Programms nun zusammen.
    Links ist der Teil des PC, von dem aus der LKW gesteuert werden soll.
    Rechts ist der Teil, der die Motoren usw. ansteuern soll.
    Einerseits werden die Steuerbefehle in einem String vom PC zum RPi geschickt, andererseits soll zwischen den beiden Programmen kontinuierlich eine Kette von vier "Pings" hin und her geschickt werden, damit die Signalstärke über die Antwortzeit gemessen werden kann. Aktuell kein kritischer Teil und noch nicht implementiert.
    Morgen Abend habe ich Zeit die einzelnen Code-Fragmente zu testen.
    Ich hoffe, die Skizze ist einigermassen verständlich. Heute funktioniert der Code nicht parallel sondern nur sequenziell, was vermutlich die Ursache meines Problems ist. Parallel mit Python habe ich nicht hinbekommen.
    Klicke auf die Grafik für eine größere Ansicht

Name:	Programm.jpg
Hits:	29
Größe:	40,7 KB
ID:	33808

  6. #16
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    18.03.2018
    Beiträge
    2.650
    Zwei Dinge sind bei der Sache:

    Einmal hast Du geschrieben, reagiert manchmal etwas nicht / nicht sofort. HaWe hatte schon geschrieben, dass das am Netz liegen kann. Klingt für mich aber auch ein wenig nach UDP, statt TCP.
    Dann hast Du geschrieben, dass er manchmal in die falsche Richtung lenkt. Das hört sich nach einem Fehler in der Programmlogik an, die ist aber eng verknüpft mit der Sprache selbst, so dass es dann auch Fehler aufgrund nicht verstehen der Programmiersprache sind, bzw. falscher Umsetzung mit der Programmiersprache.


    MfG
    Moppi

    PS: wegen besserer Lesbarkeit:

    1. Datenflussdiagramm (https://de.wikipedia.org/wiki/Datenflussdiagramm)
    2. Programmablaufplan (https://www.heise.de/download/product/papdesigner-51889)
    Kann bei der Dokumentation helfen, bzw. Sachverhalte übersichtlich und durchsichtig darzustellen.
    Geändert von Moppi (28.11.2018 um 12:25 Uhr)

  7. #17
    Benutzer Stammmitglied
    Registriert seit
    07.09.2017
    Beiträge
    52
    Nun hatte ich endlich wieder Zeit, an der Steuerung weiterzubauen.
    Bin mit euren Vorschlägen systematisch an die Sache ran und habe die ganze Verkabelung getestet, vielleicht ist da ja eine Lötstelle schlecht. Alles geprüft, alles i.O.
    Also habe ich ein kleines Programm geschrieben, mit dem ich nur die Servos und nur in bestimmten Werten ansteuere. Das Programm läuft direkt auf dem RPi. So kann ich zumindest mal Übertragungsprobleme aus dem WLAN ausschliessen.
    Zum Testen habe ich ebenfalls die Last von den Servos genommen. Unter Last läuft einer nicht, ohne Last laufen alle drei. Akku evtl. zu schwach?
    Anbei die gewünschten Bilder des Lenkungsaufbaus, der Verkabelung und des Akkus.
    Klicke auf die Grafik für eine größere Ansicht

Name:	IMG_20181221_221623.jpg
Hits:	14
Größe:	101,5 KB
ID:	33873Klicke auf die Grafik für eine größere Ansicht

Name:	IMG_20181221_221640.jpg
Hits:	14
Größe:	106,4 KB
ID:	33874Klicke auf die Grafik für eine größere Ansicht

Name:	IMG_20181221_221703.jpg
Hits:	13
Größe:	71,1 KB
ID:	33875

    Auf dem Video wäre zu sehen, dass die Servos auch ohne Last zittern. Daher gehe ich eher davon aus, dass irgendwo was mit dem PWM-Signal nicht passt.
    Wie kann ich das hier einfügen, ohne einen Google- oder Facebook-Account erstellen zu müssen?

    Hier der Code, mit dem ich die Steuerung prüfe:
    Code:
    import sys
    import time
    import socket
    import RPi.GPIO as gpio
    from decimal import Decimal
    
    print "Setting up board"
    #General board settings
    gpio.setmode(gpio.BCM)
    
    print "Setting pins"
    #Pin settings for X axis
    gpio.setup(16, gpio.OUT)
    gpio.setup(20, gpio.OUT)
    gpio.setup(21, gpio.OUT)
    
    #Check LED on pwmServo Pin
    #gpio.output(16, True)
    #gpio.output(20, True)
    #gpio.output(21, True)
    #time.sleep(3)
    
    #gpio.output(16, False)
    #gpio.output(20, False)
    #gpio.output(21, False)
    #time.sleep(1)
    
    #Set pwmServo Pins as PWM
    pwmServo1 = gpio.PWM(16, 50)
    pwmServo2 = gpio.PWM(20, 50)
    pwmServo3 = gpio.PWM(21, 50)
    
    #Pin settings for blinker
    #gpio.setup(19, gpio.OUT)
    #gpio.setup(26, gpio.OUT)
    
    #Blinkers off
    #gpio.output(19, False)
    #gpio.output(26, False)
    
    time.sleep(1)
    
    #************************************************************************************************
    #Change from left to right
    fltCounter = float(7.5)
    pwmServo1.start(fltCounter)
    pwmServo2.start(fltCounter)
    pwmServo3.start(fltCounter)
    
    while fltCounter < 10.0: #12.5:
    	print "Angle % 0.2f" % fltCounter
    	pwmServo1.ChangeDutyCycle(fltCounter)
    	pwmServo2.ChangeDutyCycle(fltCounter)
    	pwmServo3.ChangeDutyCycle(fltCounter)
    	time.sleep(0.1)
    	fltCounter = float(fltCounter + 0.1)
    		
    #************************************************************************************************
    #Change from right to left
    fltCounter = float(10) #float(12.5)
    while fltCounter > 5:
    	print "Angle % 0.2f" % fltCounter
    	pwmServo1.ChangeDutyCycle(fltCounter)
    	pwmServo2.ChangeDutyCycle(fltCounter)
    	pwmServo3.ChangeDutyCycle(fltCounter)
    	time.sleep(0.1)
    	fltCounter = float(fltCounter - 0.1)
    
    #************************************************************************************************
    #Reset pins, turn off
    print "Stop"
    fltCounter = float(7.5)
    pwmServo1.ChangeDutyCycle(fltCounter)
    pwmServo2.ChangeDutyCycle(fltCounter)
    pwmServo3.ChangeDutyCycle(fltCounter)
    time.sleep(1)
    	
    #X axis stop
    pwmServo1.stop()
    pwmServo2.stop()
    pwmServo3.stop()
    gpio.output(16, False)
    gpio.output(20, False)
    gpio.output(21, False)
    
    #Right and left blinker off
    #gpio.output(19, False)
    #gpio.output(26, False)
    		
    gpio.cleanup()
    
    print "Exiting"

  8. #18
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    18.03.2018
    Beiträge
    2.650
    Wenn ein PWM-Signal erzeugt wird, könnten Interrupts/Timerereignisse dieses stören. So dass das Timing des PWM-Signals geringfügig durcheinandergerät und sich also die Frequenz ändert. Besser ist vielleicht, einen externen PWM-Generator zu verwenden, der sich von nichts durcheinanderbringen lässt.

    Noch eine Idee wäre, nur mal ein Programm dafür zu schreiben, dass eine PWM-Signal ausgegeben wird, aber sonst nichts gemacht wird. - Glaube das hast Du ja schon. Vielleicht kann man für kurze Zeit dort auch mal die Interrupts alle abstellen und sehen, ob die Servos während dieser Zeit ruhig sind.

    Oder es ist ein äußerer Einfluss, der die Frequenz des Signals beeinflusst.

    RPi kenne ich mich leider nicht aus, daher kann ich dazu nichts Konkretes sagen.

    Eine Idee zum externen Test mit einem PWM-Signal wäre vielleicht der TL494.


    Nachtrag:

    Habe gerade gelesen, dass andere auch das Problem bei RPi haben, dass die PWM-Frequenz instabil ist. Mit externem PWM-Generator ist das dann wohl verschwunden.

    MfG
    Geändert von Moppi (22.12.2018 um 09:32 Uhr)

  9. #19
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    05.11.2007
    Beiträge
    1.076
    Moin Chris,

    normalerweise sind die PWM Module (zumindest in denen von mir verwendeten Controllern) Hardwaregesteuert,
    somit dürfte da nix eiern, da kann die Software selbst sogar stehen bleiben ohne Auswirkungen auf die PWM.

    Wenn die PWM aber tatsächlich per Software erzeugt wird, dann hat man ein RIESEN Problem, was eigentlich unlösbar ist.
    Das kann man dann wirklich nur, wie Moppi schrieb, mit externen PWM Controllern in den Griff bekommen.
    Ich weis aber nicht wie das beim RasPi abläuft. Da ich gelesen habe, dass ein Servo sogar in die falsche Richtung läuft,
    klingt das wirklich wie ein Pulsbreitenproblem.

    Kann man das rausbekommen ob die PWMs per Software erzeugt werden ?, bzw. sollte das sicher hier im Forum jemand beantworten können.

    Es könnte auch ein Reset ausgelöst werden durch Lastschwankungen oder Störungen
    In den Servos sitzen ja auch Controller, die bei Störungen auf der Versorgungspannung gerne mal einen Neustart ausführen können.
    Der dauert nur paar Millisekunden, aber hier zuckt der Servo dann kurzzeitig und läuft evtl. auch in die falsche Richtung.
    Das Problem tritt dann vermehrt in Erscheinung, je mehr Servos gleichzeitig laufen bzw. bei größerer Last.
    Ich hab so ein Problem schon in meinem Hubis gehabt. Dann gibts nen kurzen Aussetzer und dann geht es wieder.
    Hier hilft dann die Versorgungsspannung evtl. noch mit einem/mehreren dicken Elko abzublocken oder aber die Verkabelung genauer zu untersuchen.
    Oft ist diese nicht optimal gelöst, über ein Steckbrett (Experimentierboard) z.B. sind solche Fehler besonders häufig.
    Vielleicht zieht der eines Servo bei Dir mehr Strom weil er einen größere Last bewegen muss, dehalb verhält er sich dann etwas merkwürdig.
    Im Zweifel sollte tausche ich auch gerne mal die Servos untereineinader, um sicherzustellen, das es nicht am Servo selbst liegt.
    Wenn das Problem dann an andere Stelle auftaucht, hat das Servo wohl ein Problem.


    Siro
    Geändert von Siro (22.12.2018 um 10:53 Uhr)

  10. #20
    HaWe
    Gast
    moin!
    Auf AVRs oder ARMs werden die ausgewiesenen pwm-Pins über eigene Interrupts gesteuert und daher eigentlich nie durch andere Interrupts gestört.
    Hier ntl nicht die "normalen" pwm-Befehle verwenden ( wie bei Arduino: analogWrite), sondern die auf Servo-Steuerung hin ausgelegten (bei Arduino: z.B. Servo.h, Servo::write(), damit kann ich hier bei mir 6 angeschlossene Servos meines Robotarms steuern )

    Beim Raspi gibt es zum Einen 2 ausgewiesene Hardware-Interrupt Pins, die ebenfalls völlig ungestört arbeiten (verwende ich persönlich überhaupt nicht; man braucht dazu auch root Rechte).
    Zusätzlich lässt sich aber zum Anderen jeder beliebige GPIO per Software-pwm ansprechen: Man kann dazu z.B. die C Wrapper Funktionen von pigpio oder wiringPi verwenden. Gordon Henderson, der Autor von wiringPi, schrieb einmal im Raspi.org Forum dazu, dass diese genauso gut in der Lage sind, pwm zu erzeugen, wie aufgesetzte oder angesteckte pwm-Platinen (wie z.B. PCA9685), und zwar nicht nur für 1 Pin allein, sondern auch für alle simultan.

    edit2: hier Python Code:
    https://learn.adafruit.com/adafruits...motor/software

    Ich selber habe es für 3 Servos schon problemfrei selber gemacht. Da der Raspi aber insgesamt recht wenige GPIOs ohne spezielle Sonderfunktionen hat (i2c, SPI, UART, 1-Wire,...), würde ich bei mehr als 3 Servos dennoch eher einen PCA9685 über I2C verwenden.

    Immer jedoch wichtig: für die Servos eine externe, leistungsfähige Stromquelle verwenden (ich verwende 7V 10A bei meinen 6 Servos).
    Dass Servos aber manchmal zittern, kann ich bei mir auch nicht immer verhindern.


    edit -
    PS, ich vergaß, du nutzt ja Python - aber wiringPi ist auch für Python verfügbar
    https://learn.adafruit.com/adafruits...motor/software
    Geändert von HaWe (22.12.2018 um 14:55 Uhr)

Seite 2 von 4 ErsteErste 1234 LetzteLetzte

Ähnliche Themen

  1. Anleitung alter Alphaluxx Empfänger verzweifelt gesucht ..
    Von PsiQ_unterwegs im Forum Suche bestimmtes Bauteil bzw. Empfehlung
    Antworten: 1
    Letzter Beitrag: 06.12.2013, 10:44
  2. Biete Job Programmierer gesucht
    Von darkzone666 im Forum Jobs/Hilfen/Stellen - Gesuche und Angebote
    Antworten: 0
    Letzter Beitrag: 25.10.2011, 18:54
  3. C- Programmierer gesucht
    Von nonoboy im Forum C - Programmierung (GCC u.a.)
    Antworten: 3
    Letzter Beitrag: 14.10.2008, 23:56
  4. Programmierer(in) gesucht
    Von ricoderrichter im Forum Software, Algorithmen und KI
    Antworten: 0
    Letzter Beitrag: 24.03.2005, 23:17
  5. Programmierer Gesucht
    Von johnjudge im Forum Elektronik
    Antworten: 1
    Letzter Beitrag: 16.03.2005, 20:16

Stichworte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

12V Akku bauen