- Akku Tests und Balkonkraftwerk Speicher         
Seite 2 von 3 ErsteErste 123 LetzteLetzte
Ergebnis 11 bis 20 von 21

Thema: Wer findet den Fehler, Belohnung

  1. #11
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.652
    Anzeige

    Powerstation Test
    ... schön langsam denke ich eher in Richtung Hardware defekt da es nur die Steuerung der Fahrmotoren betrifft
    Bei meinen Anfängen (Teillösungen zusammengeschnitten und auf einen Controller gebracht) hatte ich auch Probleme mit der Motorsteuerung.
    Was half dann:
    - Leitungstest Motorausgang vom Treiberbaustein zum Motoreingang auf Platine und Verdrahtung
    - Leitungstest von Kurzschlüssen (Übersprechen) von einer Motorleitung zur andern
    - GENAUE Inspektion der Schaltbefehle - also Testprogramm dass nacheinander für je 30 sec einen Motorpin nach dem andern schaltet - und das Ganze mit dem DMM nachverfolgen.
    - Prüfung der PWM-Funktion statt Nur-Motorpinne-ein-aus
    - GENAUE, aufmerksame (umständliche *gg*) Programmiererei, gut kommentierte Motoransteuerung, siehe Beispiel unten
    - Zusammenbau der Grundfunktionen Motoransteuerung und NUR die in einem Test prüfen in der Art Mot1 vor, Mot1 zurück, Mot2 ...
    - Die Motoren werden softwareseitig NUR über diese Funktionen geschaltet!!

    Nur so, als (m)ein Beispiel - und das läuft und läuft. BTW: die Motoren werden softwareseitig NUR über diese Funktionen geschaltet!!
    Code:
    // ============================================================================= =
    // Motoransteuerung mit RN VN2 MotorControl, hier werden die Drehrichtungen gesetzt
    //   Anschlüsse am mega1284 auf MoCo4 (eigne Platine, Stand Anfang Sep14 ) :
    //   Motor12 ist in Fahrtrichtung rechts, Rad rechts vom Motor
    //   Motor34 ist in Fahrtrichtung links,  Rad links  vom Motor
    //  Motorbefehle: Mxxxxvor => Rad bewegt Gefährt VORwärts etc.
    //  A C H T U N G : Motoranschlüsse der VN haben (+) "innen" und GND/(-) "aussen"
    //                  ###############              ##########          ############
    //                      - - - - - - - - - -
    //               XTAL1  PB6___9   20___VCC                              
    //               XTAL2  PB7  10   19   PB5, SCK, _|-- 3,4 Guz           
    //                      PD5  11   18   PB4, MISO                        
    //  Mot12 _|-- 1,2  uz, PD6__12   17___PB3, MOSI, Reserve 2             
    //  Mot12 _|-- 1,2 Guz, PD7  13   16   PB2, OC1B => PWM4 für Mot34      
    //  Mot34 _|-- 3,4  uz, PB0  14   15   PB1, OC1A => PWM1 für Mot12      
    //   -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -
    //      vgl. Erklärung von Hubert.G     (zu L293D)
    // https://www.roboternetz.de/community/threads/59146
    //-Wieso-benötigt-RN-Control-(1-4-)-für
    //-integrierten-Motortreiber-gleich-3-freie-Ports?p=558716&viewfull=1#post558716
    //      Zitat   Mit Setzen von Kanal 1 und 2 auf 0 ist der Motor im Freilauf
    //              Werden beide Kanäle auf 1 gesetzt wird der Motor gebremst
    //   -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -
    //                -----------------------
    //  Drehrichtungsbefehle für Motor 1,2 = "rechter" Motor
    //             r r r r r r r Motor 1,2 = rechter Motor r r r r r r
    // ============================================================================= =
      void Mrechtsvor (void)        // Recht Mot12 dreht rechts=Uhrzeiger=math-negativ
     {                              //   dann fährt recht. Rad "vorwärts" = Mrechtsvor
      TCCR1A |=  (1<<COM1A1);       // Clear/set OC1A on Cmp Match enabled         132
      PORTD  |=  (1<<M11);          // => 1; Setze M1-IN1 high
      PORTD  &= ~(1<<M12);          // => 0; Setze M1-IN2 low
      m12dir  =  1;                 // m12dir ist positiv, weil Antrieb VORWÄRTS
     }                              //
    // ============================================================================= =
      void Mrechtszur (void)        // ReMot12 dreht links=Gegenuhrzeigersinn=math-pos
     {                              //   .. dann fährt rechtes Rad "rückwärts"
      TCCR1A |=  (1<<COM1A1);       // Clear/set OC1A on Cmp Match enabled         132
      PORTD  &= ~(1<<M11);          // => 0; Setze M1-IN1 low
      PORTD  |=  (1<<M12);          // => 1; Setze M1-IN2 high
      m12dir  = -1;                 // m12dir ist negativ, weils Antrieb RÜCKWÄRTS
     }                              //
    // ============================================================================= =
      void Mrechtsaus (void)        // Motor 12 aus
     {                              //
      TCCR1A &= ~(1<<COM1A1);       // Disable clear/set OC0B on Compare Match
      OCR1A   =   0;                // PWM-Wert Mot12 auf Null setzen
      PORTD  &= ~(1<<M11);          // Setze M1-IN1 low 
      PORTD  &= ~(1<<M12);          // Setze M1-IN2 low => beide low => Freilauf
      m12dir  =  0;                 //
     }                              //
    // ============================================================================= =
      void Mrechtsbrms (void)       // Motor 12 BREMSEN
     {                              //
      TCCR1A &= ~(1<<COM1A1);       // Disable clear/set OC0B on Compare Match
      OCR1A   =   0;                // PWM-Wert Mot12 auf Null setzen
      PORTD  |=  (1<<M11);          // Setze M1-IN1 high 
      PORTD  |=  (1<<M12);          // Setze M1-IN2 high => beide high => Bremsen
      m12dir  =  0;                 //
     }                              //
    //                -----------------------
    //  Drehrichtungsbefehle für Motor 3,4 = "linker" Motor
    //             l l l l l l l Motor 3,4 = linker Motor l l l l l l
    // ============================================================================= =
      void Mlinksvor (void)         // LiMot34 dreht im Gegenuhrzeigersinn = math. neg
     {                              //   dann fährt linkes Rad "vorwärts" = Mlinksvor
      TCCR1A |=  (1<<COM1B1);       // Enable clear/set OC0B on Compare Match
      PORTC  &= ~(1<<M41);          // => 0; Setze M4-IN1 low
      PORTC  |=  (1<<M42);          // => 1; Setze M4-IN2 high
      m34dir =  1;                  // m34dir ist positiv, weils Antrieb VORÄRTS
     }                              //
    // ============================================================================= =
      void Mlinkszur (void)         // Linkr Mot34 dreht im Uhrzeig=math-pos.
     {                              //   .. dann fährt linkes Rad "rückwärts"
      TCCR1A |=  (1<<COM1B1);       // Enable clear/set OC0B on Compare Match
      PORTC  |=  (1<<M41);          // => 1; Setze M4-IN1 high
      PORTC  &= ~(1<<M42);          // => 0; Setze M4-IN2 low
      m34dir = -1;                  // m34dir ist negativ, weil Antrieb RÜCKWÄRTS
     }                              
    // ============================================================================= =
      void Mlinksaus (void)         // Motor 34 aus
     {                              //
      TCCR1A &= ~(1<<COM1B1);       // Disable clear/set OC1B on Compare Match
      OCR1B        =   0;           // PWM-Wert Mot34 auf Null setzen
      PORTC  &= ~(1<<M41);          // => 0; Setze M4-IN1 low
      PORTC  &= ~(1<<M42);          // => 0; Setze M4-IN2 low
      m34dir  =  0;                 //
     }                              //
    // ============================================================================= =
      void Mlinksbrms (void)        // Motor 34 BREMSEN
     {                              //
      TCCR1A &= ~(1<<COM1B1);       // Disable clear/set OC1B on Compare Match
      OCR1B   =   0;                // PWM-Wert Mot12 auf Null setzen
      PORTC  |=  (1<<M41);          // => 1; Setze M4-IN1 high 
      PORTC  |=  (1<<M42);          // => 1; Setze M4-IN2 high => beide high = Bremsen
      m34dir  =  0;                 //
     }                              //
    // ============================================================================= =
    //      Wahrheitstabelle für die Motoren gemäß VN2 und Drehsinn-Definitionen
    // #define        M11     PD6     // M1-IN1 auf PD6     Motor 1 (12) weil er auf
    // #define        M12     PD7     // M1-IN2 auf PD7       den Anschlüssen 12 liegt
    // #define        M41     PC4     // M4-IN1 auf PC4     Motor 4 (34) weil er auf
    // #define        M42     PC5     // M4-IN2 auf PC5       den Anschlüssen 34 liegt
    // - - - - - - - - - - - - - - -
    //  MoRe        "vor"  =:  Vorwärtsfahrt        "rechts"  =:  Drehsinn Mot
    //  Beispiel    mot12 dreht mathematisch negativ bei Befehl "vor" = "rechts"
    //              vor/re  zur/li  stop    brems   vor/zur = Rad-/Fortbewegung
    //      M11=    1       0       0       1       re / li = Motordrehrichtung
    //      M12=    0       1       0       1
    // - - - - - - - - - - - - - - - -
    //      MoLi    =:      Mot34, "vor/links" dreht Motor mathematisch positiv
    //              vor/li  zur/re  stop    brems   vor/zur = Rad-/Fortbewegung
    //      M41=    1       0       0       1       re / li = Motordrehrichtung
    //      M42=    0       1       0       1
    // - - - - - - - - - - - - - - -
    
    // ============================================================================= =
    // =====  ENDE    Subroutinen  ================================================= =
    // ============================================================================= =
    Ciao sagt der JoeamBerg

  2. #12
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    06.08.2008
    Ort
    Graz
    Beiträge
    521
    Genau solche Funktionen habe ich ja:


    Code:
    inline void Motor_re_ru(void)
    {    M_rechts_Relais_ein; 
        _delay_ms(15);
        M_rechts_SD_ein;
        if (status_motor_re==M_stop)
            {
            status_motor_re=M_aktiv;
            status_motor_re_count=0;
            }
        
        }
    inline void Motor_re_vor()
    {    M_rechts_Relais_aus;
        M_rechts_SD_ein;
        if (status_motor_re==M_stop)
            {
            status_motor_re=M_aktiv;
            status_motor_re_count=0;
            }
    
    }
    
    inline void Motor_re_stop(void)
    {
    status_motor_re=M_stop;
    M_rechts_SD_aus;
    }
    
    
    inline void Motor_re_faststop(void)
    {
    status_motor_re=M_stop;
    M_rechts_SD_aus;
    }
    Erster Test mit neuer Hardware waren die Motoren, hatte ein eigenes Testprogramm erst linker Motor, dann rechter Motor, jeweils vor und zurück, mit verschiedenen PWM Werten, dann beide Motoren zusammen, etc. Funktioniert.

    Nur werden jetzt die Motoren angesteuert obwohl diese Funktionsaufrufe nicht im entsprechendem Programmabschnitt enthalten sind.
    Paradebeispiel Funktion Messerstart, seit 2 Jahren unverändert, dort werden zu Beginn die Fahrmotoren gestoppt. Dann erst der Messermotor gestartet, das kann ein paar Sekunden dauern bis der im Gras die Solldrehzahl erreicht. Dann wird noch ein paar Sekunden gewartet bis sich der Drehzahlregler eingeschwungen hat. Es kommen keine weiteren Funktionsaufrufe an die Fahrmotoren vor.
    Trotzdem werden ca 3s nach Start des Messermotors auch die Fahrmotoren vorwärts aktiv.
    Korrekt wäre abwarten der Solldrehzahl Mähantrieb, ca 2s warten, rückwärts fahren und dann nach links drehen.
    Warum???
    Bis dahin läuft alles korrekt.
    Auch danach ist wie erwähnt GPS, Bluetooth, Messerdrehzahl, Erkennung Bumper usw korrekt. Nur die Fahrmotoren nicht.

    LG Werner
    alles über meinen Rasenmäherroboter (wer Tippfehler findet darf sie gedanklich ausbessern, nur für besonders kreative Fehler behalte ich mir ein Copyright vor.)

  3. #13
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.652
    Genau solche Funktionen habe ich ja ... Bis dahin läuft alles korrekt ... Nur die Fahrmotoren nicht ..
    Hmmm, schön zu sehen, dass andere ähnliche Softwareaufbauten haben.

    Andere Sichtweise. Ich hab mal in den Parametertabellen nachgesehen: die 1284er haben 128 K Flash, 4K EEPROM und 16K (!!) SRAM - JEDER, der 2560er hat 256 K Flash, 4 K EEPROM und 8 K SRAM. Fazit: früher insgesamt 32K SRAM, jetzt 8 K.

    Warum ich das nachlese? Es war, glaub ich, Hubert.G der mich mal an Stack und so erinnert/hingewiesen hatte. Das war mein Übergang von 328ern auf 1284er *gg*.

    So - nun bei Dir. Was meint der Compiler in der Speicherplatzstatistik? VIELLEICHT könnte es ja sein, dass Du bei dem Zusammenschluss der zweimalsechzehn K SRAM auf 1x8 K SRAM ein bisschen in die Enge gekommen bist? Ich habe zwar keine wirkliche Kenntnis über Speicherplatzverbrauch des Stacks - aber der eben genannte Hinweis meinte, dass in der Gegend von 80..90% SRAMVerbrauch der Platz für den Stack eng würde. WENN das so wäre, könntest Du ja die LCD-Meldungen ins EEPROM auslagern.

    Nachtrag: LCD-Ausgaben hat der Teufel erfunden. Ich habe bei mir etliche gekürzt oder ganz gestrichen, weil das LCD soooo lange braucht bis es Daten übernimmt ! ! ! Das führte bei mir in wenigen Fällen zu massiven Störungen meiner interruptverseuchten Codes. Vor allem wohl weil ich solche Ausgaben auch in ISR habe (brrrrrrrrrrrrrrrrrrrr).
    Ciao sagt der JoeamBerg

  4. #14
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    06.08.2008
    Ort
    Graz
    Beiträge
    521
    Mit Ram wird es eng, stimmt. Fix sind 4600 Byte, bei A-Stern Berechnung kommen nochmal 3x800 Byte dazu. Lasse mir mit Mem-chec den freien Speicher laufend ausgeben, bisher waren >3kB frei (zum Fahren nach A-Stern ist er dieses Jahr nie gekommen). Der Hauptkontroller von den 1284 hatte 9kB frei, der andere benötige nur ein paar Bytes, damals wichtig waren vor allem die 2 Uarts des 1284. Sonst wäre ich gar nicht auf den 2560 umgestiegen.
    Vor allem mit der Miniversion vom Code die nur 107 Byte Ram benötigt sollte so ein Stack Fehler nicht mehr auftreten.

    In den ISR kommen die PI Regler vor, aber keine LCD Ausgaben
    alles über meinen Rasenmäherroboter (wer Tippfehler findet darf sie gedanklich ausbessern, nur für besonders kreative Fehler behalte ich mir ein Copyright vor.)

  5. #15
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.652
    Zitat Zitat von damfino Beitrag anzeigen
    Mit Ram wird es eng, stimmt. Fix sind 4600 ... nochmal 3x800 Byte dazu ... 1284 hatte 9kB frei ...
    Ok, dann sind wir bei satt 7K SRAM, evtl. deutlich drüber - der Controller wird irgendwas bei 10..12% errechnen. Eine Onlinemessung des RAMbedarfs - hmmm, ob ich der glauben kann? Denn wenns da mal ein paar hunderstel Sekunden zuu knapp wird - - kannst oder könntest Du das erkennen? Ich habe so etwas nie gemacht, weiß also nicht Bescheid.

    Neu :
    - Wieviel ISR laufen denn so ?
    - Wie sieht der Zeitbedarf aller ISR insgesamt aus (der worst case *ggg*). Evtl. mit LED an bei Beginn und off beim Ende - für jede ISR gesondert; den Overhead halt dazuschummeln - siehe *.lls. ODER aus der *.lls den Zeitbedarf rausrechnen (LED sind für mich "einfacher").
    - Hast Du nested Interrupts?
    - Regelfrequenz (also Zeitablauf von beiden Regelroutinen - MOTre und MOTli) ? Laufen die ISR zur Motorregelung wenigstens "auf Lücke" - also ENTWEDER die ISR-li ist aktiv oder die ISR-re. Dann dauert ein Regelvorgang nicht sooo lang.

    Hmmm - meine Fragen und Ratschläge klingen mir nu nicht wirklich planvoll, aber ich habe ein paar solche Abenteuer hinter mir und eigentlich immer geschafft (Komplex ist aktuell Archie - ein Hauptcontroller - I²C-Master, aktuell vier I²C-Sklaven und zwei UART-Satelliten, die Slaves haben selbst noch "Satelliten").
    Geändert von oberallgeier (12.08.2015 um 18:13 Uhr) Grund: falsch geguckt
    Ciao sagt der JoeamBerg

  6. #16
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    08.08.2008
    Ort
    DE
    Beiträge
    523
    Der 2560 hat ein JTAG-Interface! Und der Debugger ist nach dem Compiler dein 2t bester Freund.

    mfg

  7. #17
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    06.08.2008
    Ort
    Graz
    Beiträge
    521
    ISR:
    Timer 3: alle 10ms
    Messerdrehzahl: max 200 Impulse/s, Regelung in ISR von Timer 3 alle 0.25s
    2x Fahrmotoren je max 166 Impulse/s, Regelung in ISR von Timer 3 alle 0.125s, Regelung beider Fahrmotoren gleichzeitig aber zeitlich versetzt zu Messerdrehzahl
    1 UART über ISR bei 9200Baud
    1x Kontrolle vom Vorderrad, ca 2 Impulse/s

    I2C und zweiter UART werden gepollt.

    Ich hatte die Zeiten im Simulator gemessen, bzw Anzahl der Takte verglichen. Die Regelungen und 90% aller Funktionen sind unter 1ms erledigt. Die Positionsberechnung liegt bei 2.7ms.
    Bis auf 2 mathematischen Operationen sind alle in Fixkommaarithmetik.
    Wirklich lange (bis 1-3s) dauert die A-Stern Berechnung, da wird der Roboter gestoppt.

    Timer 3 regelt alle zeitkritischen Funktionen, dort werden Flags gesetzt wann die Messerdrehzahl, die Fahrmotoren, Daten über Bluetooth raus, oder wann die Odometrie berechnet wird, praktisch der Taktgeber fürs gesamte Programm.
    Standard Zeiteinheit dafür ist 0.25s, dh 1x in 0.25s werden alle regelmäßigen Funktionen abgearbeitet. Ausgenommen Fahrmotoren mit 0.125s und Positionsberechnung mit 1s. Aber auch die haben ihr freies Zeitfenster im 0.25s Abschnitt.

    Da ist noch einiges an freier Rechenleistung übrig.



    Debugger ist leider keiner vorhanden, bisher kam ich immer mit Anzeigen im LCD und setzen der LEDs als Ablaufkontrolle aus.

    LG!
    alles über meinen Rasenmäherroboter (wer Tippfehler findet darf sie gedanklich ausbessern, nur für besonders kreative Fehler behalte ich mir ein Copyright vor.)

  8. #18
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.652
    Zitat Zitat von damfino Beitrag anzeigen
    ... Da ist noch einiges an freier Rechenleistung übrig ...
    Klingt gut - ausser, dass es nicht so läuft wie es soll. Zumal ich da meine Bedenken hatte, weil der 2560 nur mit 16 MHz kann, der 1284er dagegen mit 20 MHz. Also 25% mehr Tempo.

    Dumme Frage: MUSS denn der 2560er sein? Wenn die "alte" Version mit I²C und zwei 1284ern störungsfrei läuft und der Umbau auf eine Platine nicht klappt - und diese ziemlich zähe Fehlersuche - da würde ich bei der Zwei-Platinen-Lösung bleiben. Nebenher (während der Robby läuft) kannst Du ja die Sache vielleicht interessehalber mit zwei Minimotörchen weiter treiben. "Vieles vom Code ist praktisch identisch zum Referenzcode..." - kenn ich auch. Und dann läufts nicht wie "immer". Sorry, dass ich momentan keine Idee habe wie es weitergeht.

    Jedenfalls viel Erfolg. Sozusagen mit einer oder mit zwei Platinen.

    Nachtrag zum letzten Post:
    UART pollen dauert mir viel zu lange, nochdazu mit 9600 Bd. ISR mit FIFO und Ringspeicher für RX und TX, läuft bei mir vom 328er zum 1284er selbst mit 1,25 MBd (UBRR = 1) - weil beide mit 20 MHz tickern und da wirken sich Zeitfehler nur in der Höhe der Quarztoleranzen aus *gg*.
    Geändert von oberallgeier (12.08.2015 um 18:15 Uhr) Grund: Maulen über langsame UART
    Ciao sagt der JoeamBerg

  9. #19
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    06.08.2008
    Ort
    Graz
    Beiträge
    521
    Die 2 Stück 1284 hatten ein paar Nachteile:
    1) Der Datenaustausch wurde immer umfangreicher und bremste schließlich das System aus. So ist vorgesehen das man den Roboter übers Tablet/Smartphone fernsteuern kann. Mit den zusätzlichen Daten wäre es kritisch geworden
    2) Konnte nicht so viel wie erwartet auf den 2. Kontroller auslagern, erstens wegen Punkt 1 noch mehr Daten, zweitens hatte ich sicherheitskritische Bereiche wie Motorsteuerung lieber direkt angesteuert. Wenn man den Motor stoppen will und gerade dann geht das I2C nicht ist es weniger lustig.
    3) Debuggen vom Hauptkontroller war sehr schwer, der hatte direkt nur 2 Leds, die LCD Anzeige lief über den Nebenkontroller. Es waren zwar schon einige Standard Debug Anzeigen vorgesehen, aber es fehlte immer etwas.

    Bei einem großen Kontroller geb ich einfach eine Zeile für LCD Ausgabe rein und fertig, muss nicht jedesmal 2 Programme aufeinander abstimmen.
    Es war eigentlich nur eine Zwischenlösung da mir die Pins ausgegangen sind, und die liefen beide auch nur mit 16Mhz.
    Die Arduino Platine war dann auch billiger als der Neukauf der 1284.

    Zurückgehen auf den alten Stand hatte ich mir schon überlegt, müsste die alte Platine aber erst reparieren.
    Wahrscheinlich liegt der Fehler an irgendeiner Kleinigkeit

    LG Werner
    alles über meinen Rasenmäherroboter (wer Tippfehler findet darf sie gedanklich ausbessern, nur für besonders kreative Fehler behalte ich mir ein Copyright vor.)

  10. #20
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    06.08.2008
    Ort
    Graz
    Beiträge
    521
    Noch ein Versuch der Sache auf den Grund zu gehen:
    Habe die Pins der Motorsteuerung am Atmega gewechselt, einfach mal um einen Defekt oder übersprechen vom Steuerung Mähmotor auf die Antriebsmotoren auszuschließen.

    Erster Test: Alles natürlich angesteckt, aber noch die alten Motorpins konfiguriert: Fahrmotoren werden nicht angesteuert => Kein Übersprechen der Leitungen per Hardware.

    Zweiter Test: Jetzt werden die richtigen Motorpins konfiguriert: Fahrmotoren laufen schon wieder bei Messerstart an, bei Rückwärtsfahrt wird schon nach 1s das Relais auf vorwärts geschalten, Anzeige am Display und PWM bleibt immer noch im Modus für Rückwärts.
    Also Fehler wie immer, gleiches Verhalten im vollen und mini Programm.

    Im Anhang das Mini Programm, braucht nur mehr 106 Bytes Ram, dass da der Stack übergeht kann man wohl ausschließen.

    Wie schon erwähnt scheint alles andere zu funktionieren, auch bei Fahrfunktion Spiralfahrt wird die PWM der Motoren richtig geregelt, Bumper, Sensoren erkannt, zumindest lt Display daraufhin gedreht, etc.
    Es sind nur diese 4 Ausgänge (2x Relais für Fahrtrichtung Rückwärts, 2x SD Enable am Motortreiber) die nicht richtig geschalten werden.
    Könnte ja noch verstehen dass zB wegen Überlast der Ports die Relais nicht geschalten werden können und deswegen nach 1s die Relais abfallen, aber warum gehen die Enable Leitungen zum falschen Zeitpunkt auf high?


    Braucht wer einen zu 99% funktionierenden Rasenroboter?? Erst 440 Betriebsstunden alt

    LG Werner
    Angehängte Dateien Angehängte Dateien
    alles über meinen Rasenmäherroboter (wer Tippfehler findet darf sie gedanklich ausbessern, nur für besonders kreative Fehler behalte ich mir ein Copyright vor.)

Seite 2 von 3 ErsteErste 123 LetzteLetzte

Ähnliche Themen

  1. Findet den Fehler
    Von jok3r im Forum Arduino -Plattform
    Antworten: 6
    Letzter Beitrag: 04.04.2015, 13:59
  2. Compiler findet i bewährt Deklarationen neue Fehler (gelöst)
    Von oberallgeier im Forum C - Programmierung (GCC u.a.)
    Antworten: 2
    Letzter Beitrag: 22.10.2008, 14:25
  3. Wer findet den Programmfehler? ..
    Von Lenox im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 8
    Letzter Beitrag: 25.02.2007, 13:03
  4. Wer findet den Trick??
    Von Roboter n00b im Forum Kopfnüsse / Wissensquiz
    Antworten: 10
    Letzter Beitrag: 06.07.2005, 23:00
  5. Wo findet mann Documentationen?
    Von rnhvw im Forum Robby CCRP5
    Antworten: 0
    Letzter Beitrag: 11.07.2004, 21:05

Berechtigungen

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

12V Akku bauen