7Khz hört man halt - aber als Nachteil finde ich das nicht. Ich fänd's cool, wenn er proportional zur Geschwindigkeit brummen tät. Irgendwas mit Prescaler 64 und Fast PWM oder so..Bei meiner 10 bit Variante hört man die Motoren manchmal leise piepsen
Code:/********************************************************************* N I B O B E E Feste Zykluszeit für Mainloop und zyklische (Sensor) Ein- und (LED) Ausgabe Version 1.07 für alternative Nibobee C Bib von s.frings 20100411 Birger Töpelmann *********************************************************************/ #ifndef _ZYKLUS_H_ #define _ZYKLUS_H_ // Folgende Zeile auskommentieren für "normalen" NiboBee #define _LED6_MUX_ // 6 LEDs an PB0..PB2; PB3 ist frei /*-------------------------------------------------------------------- - PB2 -|100R|-->(x) es leuchtet pro Takt immer nur eine LED; - PB1 -|100R|-->(y) ein PIN ist Plus, ein PIN Minus, ein Pin offen - PB0 -|100R|-->(z) LED (Vor-)Widerstand 2 x 100R LED_Pattern Bit Anode - Kathode DDRB PORTB 0 DUO links grün (y) - (z) ..110 ..010 1 DUO links rot (x) - (z) ..101 ..001 2 DUO rechts grün (z) - (y) ..110 ..100 3 DUO rechts rot (x) - (y) ..011 ..001 4 ROTAUGE links (z) - (x) ..011 ..010 5 ROTAUGE rechts (y) - (x) ..101 ..100 Zuordnung LED_Pattern Bit# und LED anpassbar in led_ausgabe(): case 0:{ ddr = 0x06; pin = 0x02;} break; // DUO links grün case 1:{ ddr = 0x05; pin = 0x01;} break; // DUO links rot case 2:{ ddr = 0x06; pin = 0x04;} break; // DUO rechts grün case 3:{ ddr = 0x03; pin = 0x01;} break; // DUO rechts rot case 4:{ ddr = 0x03; pin = 0x02;} break; // ROTAUGE links case 5:{ ddr = 0x05; pin = 0x04;} break; // ROTAUGE rechts --------------------------------------------------------------------*/ //#include "nibobee.h" // s.frings Bibliothek #include "zyklus.h" // also includes "nibobee.h" #include <stdio.h> #include <avr/interrupt.h> #include <util/atomic.h> #include <util/delay.h> /******************************************* ZYKLUS & CLOCK ***********/ // zählt bis 1000 (1s) in 1ms Schritten volatile uint16_t takt_ms; // zählt die Sekunden seit dem Systemstart volatile uint32_t takt_sec; // Zyklustimer wird in ISR inkrementiert und in Zyklus() volatile uint8_t zyklus_ms; // überwacht und genullt // bremst die Hauptschleife auf feste Zykluszeit (Zzeit in ms) // organisert LED Ausgabe und Sensoren Eingabe mit Flankenerkennung uint8_t Zyklus(uint8_t Zzeit); /****************************************** Sensoren ******************/ volatile uint8_t Sensors; // Aktueller Eingabestatus volatile uint8_t SensSFL; // Steigende Flanke erkannt volatile uint8_t SensFFL; // Fallende Flanke erkannt /*--------------------------------------------------------------------- Flankenerkennung (Trigger): 0101 Bitmuster vorher 0011 Bitmuster aktuell 0010 Bitmuster steigende Flanke 0100 Bitmuster fallende Flanke ----------------------------------------------------------------------*/ void sens_eingabe(); // SensorPins lesen/Flankenerkennung #define SENS_SW1_1 readBit(Sensors,4) #define SENS_SW2_1 readBit(Sensors,5) #define SENS_SW3_1 readBit(Sensors,7) #define SENS_SW4_1 readBit(Sensors,6) #define SENS_SW1_S readBit(SensSFL,4) #define SENS_SW2_S readBit(SensSFL,5) #define SENS_SW3_S readBit(SensSFL,7) #define SENS_SW4_S readBit(SensSFL,6) #define SENS_SW1_F readBit(SensFFL,4) #define SENS_SW2_F readBit(SensFFL,5) #define SENS_SW3_F readBit(SensFFL,7) #define SENS_SW4_F readBit(SensFFL,6) /***************************************** LED MULTIPLEX **************/ volatile uint8_t LED_Pattern; // LED Ausgabemuster volatile uint8_t LED_PattSFL; volatile uint8_t LED_PattFFL; volatile uint8_t LED_Blinker; // gesetztes Bit lässt LED blinken #ifdef _LED6_MUX_ // umgebauter NiboBee // Kompatibilität zu s.frings: entsprechendes Bit in Pattern setzen #define set_LED0(value) writeBit(LED_Pattern,1,value) #define set_LED1(value) writeBit(LED_Pattern,4,value) #define set_LED2(value) writeBit(LED_Pattern,5,value) #define set_LED3(value) writeBit(LED_Pattern,3,value) // Returns 1, if the LED is on #define LED0 readBit(LED_Pattern,1) #define LED1 readBit(LED_Pattern,4) #define LED2 readBit(LED_Pattern,5) #define LED3 readBit(LED_Pattern,3) #else // normaler NiboBee // Kompatibilität zu s.frings: entsprechendes Bit in Pattern setzen #define set_LED0(value) writeBit(LED_Pattern,0,value) #define set_LED1(value) writeBit(LED_Pattern,1,value) #define set_LED2(value) writeBit(LED_Pattern,2,value) #define set_LED3(value) writeBit(LED_Pattern,3,value) // Returns 1, if the LED is on #define LED0 readBit(LED_Pattern,0) #define LED1 readBit(LED_Pattern,1) #define LED2 readBit(LED_Pattern,2) #define LED3 readBit(LED_Pattern,3) #endif //_LED6_MUX_ // meine LED Makros basieren auf LED Nummer #define LED_EIN(NR) LED_Pattern |= (1 << NR); #define LED_AUS(NR) LED_Pattern &= ~(1 << NR); LED_Blinker &= ~(1 << NR); #define LED_BLINK(NR) LED_Pattern |= (1 << NR); LED_Blinker |= (1 << NR); #define LED_TOGGLE(NR) LED_Pattern ^= (1 << NR); void led_ausgabe(); // LED Multiplex Ausgabe // Debughilfen: vordere LED links/rechts bei ea==0 aus-, // sonst einschalten, !! schaltet jew. die andere LED aus void augeL(uint8_t ea); void augeR(uint8_t ea); /***************************************** LED MULTIPLEX **************/ #endif // _ZYKLUS_H_
Und soweit bin ich bisher mit der Main() von s.frings gekommen: hier sind noch etliche Anpassungen nötig; _delay_ms(), while{} oder blockierende Funktionen sind eigentlich No Gos. Aber ich verspreche mir davon, dass mehrere "prozesse" quasi gleichzeitig bearbeitet werden können.Code:/********************************************************************* N I B O B E E Feste Zykluszeit für Mainloop und zyklische (Sensor) Ein- und (LED) Ausgabe Version 1.07 für alternative Nibobee C Bib von s.frings 20100411 Birger Töpelmann *********************************************************************/ #include "zyklus.h" #include <stdio.h> #include <avr/interrupt.h> #include <util/atomic.h> #include <util/delay.h> /***************************************** CLOCK & MOTPID ***********/ volatile uint16_t takt_ms; volatile uint32_t takt_sec; //#define Zykluszeit 1 // Zykluszeit der Hauptschleife in ms volatile uint8_t zyklus_ms; // Zyklustimer wird in ISR inkrementiert // und in Zyklus() überwacht und genullt /************************************************* SENS *************/ volatile uint8_t Sensors = 0; // Aktueller Eingabestatus volatile uint8_t SensSFL = 0; // Steigende Flanke erkannt volatile uint8_t SensFFL = 0; // Fallende Flanke erkannt void sens_eingabe() { SensSFL = ~Sensors; // vorherigen Zustand merken für Flankenerkennung SensFFL = Sensors; Sensors ^= Sensors; // bits nullen für neuen Zustand Sensors |= ~(PINC & 0xf0); // 1 == Sensor aktiv // Hier Eingänge von Ext-Ports Pins verOdern SensSFL &= Sensors; // Steigende Flanke erkennen SensFFL &= ~Sensors; // Fallende Flanke erkennen } /************************************************* LED **************/ /* #define LED_EIN(NR) LED_Pattern |= (1 << NR); #define LED_AUS(NR) LED_Pattern &= ~(1 << NR); LED_Blinker &= ~(1 << NR); #define LED_BLINK(NR) LED_Pattern |= (1 << NR); LED_Blinker |= (1 << NR); #define LED_TOGGLE(NR) LED_Pattern ^= (1 << NR); */ volatile uint8_t LED_Pattern = 0; volatile uint8_t LED_Blinker = 0; void led_ausgabe() { static uint16_t tmux = 0; if (0 == tmux--) tmux = 640; // !Wert = vielfaches von 8 uint8_t leds = LED_Pattern; // Pattern für Ausgabe if (tmux < 400) leds &= ~LED_Blinker; // Blinkbits #ifdef _LED6_MUX_ // umgebauter NiboBee uint8_t ddr = 0; uint8_t pin = 0; if ((1 << (tmux & 0x07)) & leds) // welche LED soll leuchten? { switch((tmux & 0x07)) { case 0:{ ddr = 0x06; pin = 0x02;} break; // DUO links grün case 1:{ ddr = 0x05; pin = 0x01;} break; // DUO links rot case 2:{ ddr = 0x06; pin = 0x04;} break; // DUO rechts grün case 3:{ ddr = 0x03; pin = 0x01;} break; // DUO rechts rot case 4:{ ddr = 0x03; pin = 0x02;} break; // ROTAUGE links case 5:{ ddr = 0x05; pin = 0x04;} break; // ROTAUGE rechts // case 6:{ ddr = 0x00; pin = 0x00;} break; // case 7:{ ddr = 0x00; pin = 0x00;} break; } } DDRB = (DDRB & ~0x07) | ddr; // zwei PINS als Ausgang PORTB = (PORTB & ~0x07) | pin; // ein Pin = 1, Rest = 0 #else // nicht umgebauter NiboBee // Auch hier wird immer nur eine LED eingeschaltet // 1 * Zykluszeit Ein; 3 * Zykluszeit Aus PORTB = (PORTB & ~0x0f) | (leds & (1 << (tmux & 3))); #endif //_LED6_MUX_ } /* // Debughilfen void augeL(uint8_t ea) { uint8_t ddr = 0; uint8_t pin = 0; if(ea){ ddr = 0x03; pin = 0x02;} // ROTAUGE links DDRB = (DDRB & ~0x07) | ddr; // zwei PINS als Ausgang PORTB = (PORTB & ~0x07) | pin; // ein Pin = 1, Rest = 0 } void augeR(uint8_t ea) { uint8_t ddr = 0; uint8_t pin = 0; if(ea){ ddr = 0x05; pin = 0x04;} // ROTAUGE rechts DDRB = (DDRB & ~0x07) | ddr; // zwei PINS als Ausgang PORTB = (PORTB & ~0x07) | pin; // ein Pin = 1, Rest = 0 } */ /******************************* TIMER 1 CONFIG PWM & TAKT **********/ // s.frings setup: // Initialize the motor PWM // Mode 2 = phase correct 10 bit PWM, // channel A+B outputs are set on compare match when upcounting // and cleared on compare match when downcounting. // TCCR1A = PWM invertiert + + 10bit PWM Betrieb // TCCR1A = (1<<COM1A1) | (1<<COM1A0) | (1<<COM1B1) | (1<<COM1B0) | (1<<WGM11); | (1<<WGM10); // Original nibobee (springob) setup // TCCR1A = PWM invertiert + + 9bit PWM Betrieb // TCCR1A = (1<<COM1A1) | (1<<COM1A0) | (1<<COM1B1) | (1<<COM1B0) | (1<<WGM11); // Use I/O clock without prescaling // TCCR1B = (1<<CS10); // Overflow Interrupt enable // TIMSK |= (1<<TOIE1); // F_CPU = 15 Mhz // Prescale = 1 // Frequenz bei 10 bit 15000000/(2*1023)= 7.331 kHz ; OVF alle 136 uS // Frequenz bei 9 bit 15000000/(2* 511)=14.677 kHz ; OVF alle 68 uS #define T1PERIODE 136 // Periodendauer zwischen Overflows in uS /************************************* TIMER 1 OVERFLOW ISR **********/ ISR(TIMER1_OVF_vect) { static uint16_t takt_us=0; takt_us += T1PERIODE; if (takt_us >= 1000) { takt_us -= 1000; takt_ms++; zyklus_ms++; } if (takt_ms >= 1000) { takt_ms -= 1000; takt_sec++; } } /**************************************** ZYKLUS & WATCHDOG **********/ uint8_t Zyklus(uint8_t Zzeit) { if(Zzeit == 0) // Zyklustimer Reset / Init { // Timer 1 Overflow Interrupt freigeben, damit die Uhr tickt #ifdef TIMSK1 // ATmega644 TIMSK1 |= (1<<TOIE1); #else // ATmega16 TIMSK |= (1<<TOIE1); #endif zyklus_ms = 0; return(0); } sei(); // Interrupts freigeben led_ausgabe(); // Ausgänge aktualisieren uint8_t zms = zyklus_ms; // aktuelle Zykluszeit merken while(zyklus_ms < Zzeit){}; // Zykluszeit abwarten sens_eingabe(); // Eingänge lesen // -------------------- WATCHDOG --------------------------- // es wird kein Reset/Neustart ausgelöst -> Endlosschleife // LED blinken im Binär Muster der erfassten Zykluszeit if(zyklus_ms > Zzeit) // Zykluszeit überschritten ? { uint8_t zyt = 0; // alternativ Zyklustimer (Blinken) if (zms > 15) zms = 15; // Zykluszeit >= 15 -> alle LED ein while(1==1) // Fehlerfalle Zykluszeit überschritten { _delay_ms(10); // Klassische Verzögerung if(zyt-- == 0) zyt = 70;// Blinktakt 700ms if(zyt > 50) { LED_Pattern = zms; // Ist-Zykluszeit Binär ausgeben } else { LED_Pattern = 0; // LED aus für Blinklicht } led_ausgabe(); // LED Muster am Port ausgeben } }//-------------------------------------------------------- else zyklus_ms = 0; // Zykluszeit Timer Reset return(zms); // Interessant bei Zykluszeit > 1: // Wie lang war der Zyklus tatsächlich }
Oder ich weiß nicht - liege ich mit meiner Vorstellung einer Controllerprogrammierung total daneben? Dann geb' ich's auf und bastel mir 'ne Logo oder zwei auf Räder...Code:/********************************************************************* N I B O B E E Projekt Alternative s.frings und Birger.T zum Selberbasteln und Ändern Ver.20100411 *********************************************************************/ #define Zykluszeit 1 // Hauptschleife Zykluszeit in ms #define USE_SERIAL 0 #include "nibobee.h" #include "zyklus.h" uint16_t previousSpeed; // Display battery status on the 4 led's // LED0 = >4.1V // LED1 = >4.3V // LED2 = >4.5V // LED3 = >4.7V void battery_check() { set_AREF(REF_256); for (uint8_t i=0; i<10; i++) { // _delay_ms(50); for (uint8_t t=0; t<50; t++) { _delay_ms(1); led_ausgabe(); } set_LED0(analog(VBAT)>(410*2)); set_LED1(analog(VBAT)>(430*2)); set_LED2(analog(VBAT)>(450*2)); set_LED3(analog(VBAT)>(470*2)); // _delay_ms(50); for (uint8_t t=0; t<50; t++) { _delay_ms(1); led_ausgabe(); } set_LED0(0); set_LED1(0); set_LED2(0); set_LED3(0); } set_AREF(REF_VCC); _delay_ms(50); } // Wait for start signal (touch any sensor) // While waiting, display debug information from sensors: // LED0: Left odometer sensor // LED3: Right odometer sensor // LED1: System timer // LED2: Center line sensor void wait_for_start() { while (!(SENS_SW1 || SENS_SW2 || SENS_SW3 || SENS_SW4)) { // Display status of odometry sensors while waiting set_LED0(ODO_L); set_LED3(ODO_R); // Display system timer (flashes every second) set_LED1((system_time() % 1000) < 20); // Display line sensor set_LED2(analog(LINE_C)>600); _delay_ms(1); led_ausgabe(); } set_LED0(0); set_LED3(0); _delay_ms(10); while ((SENS_SW1 || SENS_SW2 || SENS_SW3 || SENS_SW4)) {} _delay_ms(400); } #define FORWARD 1 #define BACKWARD 0 volatile uint8_t running = 0; // Drive forward or backward. // Accellerate or decellerate softly to the maxSpeed. // The distance is measured in 1/20 wheel rotations. // LED0 or LED3 light if a which motor runs too fast. uint8_t drive(uint8_t direction, uint16_t distance, uint16_t maxSpeed) { static uint16_t speed= 0; static uint32_t lastTime=0; if(!running){ if (direction) { set_DIR_L(1); set_DIR_R(0); } else { set_DIR_L(0); set_DIR_R(1); } // Start with the previous speed // uint16_t speed=previousSpeed; // uint32_t lastTime=system_time(); speed=previousSpeed; lastTime=system_time(); reset_odometer(); running = 1; } // while (odometer_left()<distance || odometer_right()<distance) { if(!(odometer_left()<distance || odometer_right()<distance)) running = 0; // Ziel erreicht else{ int16_t diff=odometer_left()-odometer_right(); // If left motor is too fast if (diff>0) { set_LED0(1); PWM_L=speed/2; PWM_R=speed; } // If right motor is too fast else if (diff<0) { set_LED3(1); PWM_R=speed/2; PWM_L=speed; } // Speed of both motors is equal else { set_LED0(0); set_LED3(0); PWM_L=speed; PWM_R=speed; } // If a millisecond has elapsed, increase or decrease the speed // a little until the maxSpeed has been reached. uint32_t currentTime=system_time(); if (currentTime>lastTime) { if (speed<maxSpeed) speed++; else if (speed>maxSpeed) speed--; lastTime=currentTime; } } // vom while previousSpeed=speed; return(running); } // Stop driving. void stop() { PWM_L=0; PWM_R=0; previousSpeed=0; running = 0; } // Main program int main() { uint8_t tour = 0; // Merker für den Fahrtabschnitt uint16_t warten = 0; // nibobee_init(); // Display battery status battery_check(); // Wait for a start signal before start driving wait_for_start(); // Drive forward and backward repeatedly, to demonstrate // that the drive() function keeps straight on properly. Zyklus(0); //Zyklustimer Reset / Init while(1) { // deactivate_output_bit(IO_LINE_EN); // Front IR Leds aus writeBit(PORTB,PB5,0); Zyklus(Zykluszeit); // Zykluszeit abwarten // activate_output_bit(IO_LINE_EN); // Front IR LEDs blitzen im Zyklustakt für // Zeitmessung per IR Transistor und Oszi writeBit(PORTB,PB5,1); // Kollision (oder an die Fühler getippt) = Stop if(SENS_SW2_S || SENS_SW3_S) { tour = 100; stop(); } // Neustart bei Sensor nach vorne tippen und loslassen if((tour == 100) && (SENS_SW1_F || SENS_SW4_F)) tour = 0; // Drive forward 2 meters, accellerating up to nearly maximum speed if((tour == 0) && !drive(FORWARD,2000/6,900)) tour = 10; // Drive forward 30cm, decellerating down to the minimum speed if((tour == 10) && !drive(FORWARD,300/6,200)){ stop(); tour = 20; warten = 500; } // _delay_ms(500); if((tour == 20) && !warten--) tour = 30; // Drive backward 2 meters, accellerating up to nearly maximum speed if((tour == 30) && !drive(BACKWARD,2000/6,900)) tour = 40; // Drive backward 30cm, decellerating down to the minimum speed if((tour == 40) && !drive(BACKWARD,300/6,200)) { stop(); tour = 50; warten = 500; } // _delay_ms(500); if((tour == 50) && !warten--) tour = 0; } return 0; }
Eigentlich wollte ich noch ein Foto machen: Meine Erfahrung LiPos halten so lange, bis man sie dann mal braucht.. bis zum WE.
Ich hatte mich bemüht, ein möglichst simples Programmbeispiel abzugeben, welches zeigt, wie man die wesentlichen Funktionen der Library nutzt.
Natürlich stören blockierende Funktionen in einer anständigen Anwendung. Das sehe ich absolut genau so. Deswegen sind in der Library solche Sachen auch nicht drin.
Hallo,
na prima, so bauen wir alle unsere eigenen Libs für die BieneIch baue ja auch daran herum - noch ein bißchen für mich selber, weil sie meines erachtens noch nicht so den Stand zur Veröffentlichung hat. Vielleicht liege ich damit auch falsch und sollte einfach ein freies Repository auf sourceforge anlegen, damit wir alle daran herumbauen können?
Jetzt aber zu Deiner Lib:
Mir ist gerade noch etwas wichtiges aufgefallen:
_Alle_ Variablen, die sowohl in den IRQs als auch in anderen Programmteilen verändert werden, mit "volatile" deklarieren! Sonst kann das unvorhersehbare Ergebnisse liefern: Der Compiler optimiert sonst unter Umständen unzulässig. Die atomaren Blöcke ersetzen _nicht_ volatile. Außerdem empfehle ich, alle vermeidbaren atomaren Blöcke wirklich wegzulassen.
Dazu kann ich nur den Tipp geben: Genau darüber nachzudenken, was der Autor uns wohl damit sagen wollte. Denn bei einigen Dingen hatte ich auch immer zuerst das Gefühl "Was macht er es sich so schwer???". Aber nachdem ich das Datenblatt des ATmega gelesen hatte, wusste ich oft genug, warumZitat von s.frings
Prima Beispiel für das, was ich oben meinte. Der Original-Code ist an dieser Stelle tadellos korrekt, alles andere ist mutig. Denn: Es wird nicht gewartet, bis der Motor stoppt, sondern bis der Motor nicht mehr durch die PWM bestromt wird, bevor die Fahrrichtung gewechselt wird. Und das finde ich durchaus sinnvoll, den Motor nicht mitten im bestromten Zustand andersherum zu polen. Wo ich Dir recht gebe: Der Kommentar an den ISRs ist etwas blöde - denn er wartet in der Tat nicht, bis der Motor steht.Zum Beispiel die PWM Steuerung: Wenn man die Fahrtrichtung ändert, wird der Motor zuerst gestoppt und erst beim nächsten Interrupt die neue Fahrtrichtung und Geschwindigkeit eingestellt. Das klingt ja erstmal sinnvoll, aber beim nächsten Interrupt steht der Motor noch lange nicht. Also muss man entweder viel länger warten oder man lässt es ganz bleiben.
Dazu habe ich zwei Anmerkungen: Zum einen gebe ich Dir recht, dass die Lib etwas konfus aufgeteilt ist - vor allem auch die Aufteilung auf mehrere .a-Dateien habe ich gar nicht verstanden. Sinn solcher Archive ist ja gerade die Zusammenfassung mehrerer Object-Dateien ist ( .o ).Irgendwie nervt mich auch, dass die eigentlich winzigen Funktionen über mehrere include-Files und mehrere (nicht gleich lautende) Libraries (*.a files) verstreut sind.
Zum anderen sind verfolgen Libs einen anderen Ansatz als "normale" Programme. Deshalb ist es durchaus üblich und sinnvoll, die einzelnen Funktionen für die verschiedenen Peripherieteile in eigene C-Dateien zu schreiben, so etwas nennt man auch modulare Software. Das hat viele Vorteile: Wenn irgendwo ein Fehler bei einem Peripherieteil auftritt, weiß man sofort, in welcher Datei man suchen muss. Wenn mehrere Leute an einem Projekt arbeiten, hat jeder "seine" (bzw. "ihre") Dateien. Wenn man ein neues Projekt mit ein paar (aber nicht allen) gleichen Aufgaben / Peripherieteilen und ein paar neuen Teilen hat, kann man die Teile aus dem alten Projekt durch einfaches Kopieren übernehmen - und muss den Code nicht noch filetieren - welche Teile gehören jetzt wie wozu? Des weiteren sind in der Lib-Datei weiterhin die einzelnen .o-Dateien vorhanden. Der C-Compiler bindet in ein Projekt nur die .o-Dateien aus der .a-Datei ein, die wirklich eingesetzt werden. Bei nur einer .o-Datei also immer alles.
Wenn Du also eine _echte_ Lib bauen willst, die nicht jeder für sich anpasst und so wie sie ist weiter genutzt werden können soll, rate ich Dir unbedingt zu einem modularen Aufbau.
Übrigens ist in der Modularität und der Übernahme aus einem anderen Projekt auch die leichte Konfusität der Codes zu entnehmen: Übereinstimmende Funktionen sind von dem Nibo2 übernommen worden - schaut euch einfach mal dessen Sourcecode an
Tja, klingt nach einer prima IdeeUnd ich vermisse, dass der serielle Port als standart Eingabe und Ausgabe für stdio.h eingerichtet wird, so dass Befehle wie fgets, puts, prinf, etc.funktionieren.An dieser Stelle müsste ich dann mal überlegen, wie das bei meiner Lib funktionieren könnte. Denn ich nutze die USART ganz anders, als eigentlich gedacht... Wie man dazwischen hin und herschalten kann - mal drüber nachdenken.
Überhaupt stecken in Deinem Code gute Ideen, mal sehen, ob ich etwas übernehmen kann
Viel Spaß noch beim weiter entwickeln
Ciao bantyy
Hallo,
Das kommt darauf an
Bei hohen Frequenzen werden die Umsteuerverluste in den Transistoren auch höher, allerdings sind diese kHz-Frequenzen alle noch nicht in einem kritischen Bereich. Ich habe aus technischen Gründen schon mit 36 kHz experimentiert - und das geht prima. Die Trägheit des Motors und die elektrischen Eigenschaften der Spulen im Motor (Strom ändert sich stetig) führen dazu, dass beim Motor bei höheren PWM-Frequenzen die eingestellte Leistung umgesetzt wird.
Niedrige Frequenzen (unter 20 kHz) sind hörbar. Habt ihr schon mal einen IC losfahren gehört? Da gibt es eine Baureihe (oder war es doch eine ICE-Baureihe?), da ist eine PWM im hörbaren Bereich aktiv - und das klingt wie eine Tonleiter. Klingt schon bescheuert, wenn man neben dem losfahrenden Zug steht und der spielt einem eine Tonleiter vor... Das ist btw auch der Grund, warum ihr bei 7 kHz etwas hört: noch fieser sind 1 kHz. Hab ich alles ausprobiert
Die niedrigen Frequenzen haben den Vorteil, dass dort ein höheres Anfahrtmoment zur Verfügung steht. Schließlich werden die Spulen im Motor dort über einen längeren Zeitraum voll bestromt, in dem sie das volle Moment auf die Achse übertragen können.
In der Praxis habe ich herausgefunden, dass es kaum einen Unterschied macht, ob man mit einer 36 kHz oder einer 1 kHz PWM arbeitet. Lediglich der minimal notwendige PWM-Wert sinkt geringfügig - aber nicht der Rede Wert.
Übrigens ist meine Erfahrung, dass sich die Motoren ab etwa 1/8 Vollgas in Bewegung setzen, vorher steht alles still. Ich halte eine "Auflösung" von 10 Bit in der Praxis nicht für relevant. Selbst mit 8 Bit lassen sich die Motoren noch ganz entspannt genau genug steuern. Ich habe mich übrigens für Timer-Mode 10 entschieden: Damit kann ich eine beliebige "Auflösung" und damit Frequenz einstellen.
Und warum ich immer so mit 36 kHz rumwurschtel: Ich würde mir da gerne einen IR-Sender (RC5) mit dran hängen. Zur Zeit bin ich allerdings noch bei einem Empfänger. Der ist mir erstmal wichtiger. Allerdings ist mein Ansatz nicht ATmega16-kompatibel. Dafür nutze ich den SPI-Mode der USART - und den gibts erst ab ATmega xx4. Also 164 / 324 / 644 / 1284 (ja, in den Datenblättern existiert auch der letztere!!!).
Ich habe btw auch einen Systemtimer und ich muss sagen, meine "Vergangenheit" hat mich evtl. eingeholt: Die Idee, den Timer auf 32 Bit aufzubohren und darauf setzen, dass die Biene niemals länger als 49 Tage am Stück eingeschaltet ist, ist schon OK. Ich nutze statt dessen 16 Bit, die auch überlaufen dürfen, dafür kann meiner nur etwa eine Minute in die Zukunft arbeiten. Meine bisherige Software waren alle Langläufer - musste also fünf Jahre und länger ohne Probleme mit Timerüberläufen zurecht kommen.
Für den Systemtimer nutze ich btw timer2 und den Capture Compare, um wirklich auf die 1 ms zu kommen.
Meine Biene ist nur ein klein wenig stromoptimiert und ich habe ihr einen ATmega644 gegönnt, ansonsten unverändert. Ich erkenne auf jeden Fall, dass eine allgemeine Bibliothek nicht so einfach zu erstellen ist, da sich die Hardware der Biene eh jeder mehr oder weniger anpasst.
So, ich hoffe, dass ich weder langweile noch nerve mit den langen Texten
Ciao bantyy
Servus; ich habe jetzt meinen aktuellen Stand der Zyklus-Dateien und der überarbeiteten Demo von s.frings hier im Thread (weiter oben) rein editiert.
zyklus baut auf der nibobee Lib von s.frings auf bzw. soll sie ergänzen; damit das ohne Fehler & Warnungen funktioniert, musste ich allerdings in der folgendes ergänzen:
in der nibobee.c
und in der nibobee.h den gesamten Block unter "Status Led's" auskommentieren.Code:#if USE_SERIAL #include <util/setbaud.h> #endif
Nun das Demoprogramm funktionierte bei mir nicht so doll; mein NiboBee hat 'nen Rechtsdrall, den die Regelung der Demo auch nicht ausregeln konnte (auch nicht das Original ohne zyklus). Ich muss wohl mal wieder Staubmäuse aus den Getrieben befreien.
Ach ja, und wen's interessiert wie ich mein Nibobee hergerichtet habe, anbei mal die Bilder:
Danke bantyy, für Deine ausführlichen Infos zur PWM Freuqenz.
Ich befasse mich gerade ein wenig mit Lejos. Dort finde ich toll, dass bei Fahrmanövern der geschätzte Bremsweg berücksichtigt wird. Dort kann man mit Höchstgeschwindigkeit eine bestimmte Strecke abfahren, ohne ungewollt über das Ziel hinaus zu schießen. Rechtzeitig vor dem Ziel wird abgebremst.
Diese Idee sollte man auch in eine NIBObee Library übernehmen, finde ich.
Hallo,
Welch Zufall, ich habe inzwischen auch einen NXT und bin deshalb - und wegen eines Verkehrsunfalls - mit meinem libbee-Tutorial noch nicht fertig. Aber auf einem guten Weg, ich schätze ich habe so etwa die Hälfte fertig. Und ab nächster Woche Urlaub, also ein wenig Zeit dafür
Der Bremsweg ist dort aber auch manipulierbar. Schließlich nutzen die keine diskrete Minimal-Motorbrücke sondern einen Chip, der die volle Funktionalität bietet.Dort finde ich toll, dass bei Fahrmanövern der geschätzte Bremsweg berücksichtigt wird.
Bei der Biene ist das sehr viel schwieriger: Die Motorbrücke ist vereinfacht und müsste dafür erstmal geändert werden, um einen Bremsbetrieb zu ermöglichen.
Der eigentliche Bremsweg ist darüber hinaus sehr abhängig von dem Untergrund. Wie machen sie denn das bei LeJOS genau? Ich hab nicht in den Quellcode reingeschaut, aber dort wissen sie ja nicht einmal, was für eine Art von Antrieb an dem Roboter ist (Räder, Gummi- oder Plaste-Raupen, Reifendurchmesser, Geometrie...)
Was natürlich möglich wäre: Ein annähern mit voller Geschwindigkeit auf die Sollstrecke - x % und den Rest dann mit geringster Geschwindigkeit fahren. So etwas in der Art ist schon realisierbar. Aber richtig bremsen und Motoren "festhalten", wie es beim NXT möglich ist, geht mit der Biene ohne Umbau nicht.
Ciao bantyy
Bei Lejos gibt es einen default Wert für die geschätzte Bremsleistung. Damit kann der Bremsweg geschätzt werden und wiederum eine zielsichere Bremsung hingelegt werden - vorausgesetzt der default Wert stimmt. Den kannst Du programmatisch anpassen. Da die Lego Reifen richtig guten Grip haben, die Getriebemotoren sehr stark bremsen können, und der NXT Computer viel Gewicht auf die Reifen bringt, kommt es auf einen exaktem Schätzwert nicht so sehr an. Die Lego Hardware kann beeindruckend kurze Vollbremsungen hinlegen.
Zurück zum Nibo: Die Motorbrücke kann auch bremsen, nur einen Freilauf kennt sie nicht (wie es Lego kann). Die Bremsleistung ist aber um Welten schlechter, als bei Lego, weil die Motoren winzig klein sind, weil das Getriebe nur eine geringe Übersetzung hat, weil die Reifen (zumindest auf Laminat) wenig Grip haben und weil der ganze Roboter sehr wenig Gewicht auf die Achsen bringt. Einen Stein mit Gummiband auf's Batteriefach klemmen hilft übrigens prima.
Wegen der geringen Übersetzung und dem geringen Gewicht kann der Nibo viel schneller fahren, als der Lego Roboter. Die Bremsleistung ist aber schwach, deswegen muss der Nibo Roboter sehr viel früher bremsen.
Ich hatte es erstmal so versucht, dass während der Fahrt fortlaufend die aktuelle Geschwindigkeit ermittelt wird (alle 100ms) und der sich daraus ergebende Bremsweg geschätzt wird. Ist der dann kleiner oder gleich der Distanz zum Ziel, dann wird gebremst. Problem: Schätze ich zu viel, dann kommt der Roboter zu früh zum Stillstand.
Also dachte ich mir, lass ich die Bremse wieder los, wenn ich merke, dass ich mich verschätzt habe. Das führt aber zu unschönem Ruckeln auf den letzten Zentimetern vor dem Ziel. Man kann dann buchstäblich sehen, dass der Bremsweg falsch geschätzt wurde.
Letztendlich muss man aber mehr schätzen, als der tatsächliche Bremsweg ist, weil - wie Du schon bemerkt hast - der Bremsweg sehr vom Untergrund abhängt. Ein Staubkorn auf dem Boden kann sich da schon signifikant auswirken, insofern muss man schon wenigstens 20% Reserve einplanen.
Gestern habe ich etwas anderes versucht, mit Erfolg: Alle 100ms berechne ich die geschätzte maximal zulässige Geschwindigkeit, mit der eine Zielgenaue Bremsung gerade noch möglich wäre. Dann begrenze ich die soll-Geschwindigkeit auf genau diesen Wert. Wobei ich bei der Konstante BREMSLEISTUNG schon 20% Reserve vorgesehen habe.
(Das ist Pseudo-code, kann man so nicht 1:1 übernehmen)Code:sollTempo=200cm/sec; motorPower=250; BREMSLEISTUNG=85; while (ziel_noch_nicht_erreicht) { if (100ms_vergangen) { maxTempo=sqrt(restDistanz*BREMSLEISTUNG); if (sollTempo>maxTempo) sollTempo=maxTempo; fehler=sollTempo-istTempo; motorPower=motorPower+fehler; } } motorPower=0;
Aber ganz so einfach geht es leider nicht, weil das Wurzelziehen zu lange dauert. Deswegen die folgende Annäherungsschleife:
Letztendlich führt das Ganze dazu, dass der Roboter mit sehr geringer Geschwindigkeit am Ziel ankommt, wo ich dann getrost per Vollbremsung endgültig anhalten kann. Ich komme also stets wenige Millimeter hinter dem Ziel zum stehen.Code:sollTempo=200cm/sec; motorPower=250; BREMSLEISTUNG=85; while (ziel_noch_nicht_erreicht) { if (100ms_vergangen) { while (1) { bremsweg=(sollTempo*sollTempo)/BREMSLEISTUNG; if (bremsweg>restDistanz) sollTempo=soll_tempo*0.9; else break; } fehler=sollTempo-istTempo; motorPower+=fehler; } } motorPower=0;
Das ist bei Lejos auch so, nur fährt der wieder ein Stück zurück, wenn er das Ziel um mehr als eine gewisse Toleranzgrenze überschritten hat (denn Lejos verwendet einen PID Regler, mein Nibo jedoch nur einen PI Regler).
Ein PID Regler wäre beim Nibo problematisch, denn wenn er erstmal rückwärts in Bewegung ist, kann er nicht schnell genug stoppen. Die Abweichung vom Ziel würde dadurch eher noch größer, als kleiner. Außerdem macht man das mit einem Auto vor der Ampel ja auch nicht. Wenn ich die Haltelinie knapp verfehlt habe, setzte ich ja auch nicht zurück, da käme ich mir blöd vor.
Zudem würde ein Zurücksetzen richtig viel Zeit kosten. Ein Flüssiger Unterbrechungsfreier Übergang zwischen geradeaus-fahrt und anschließender Drehung wäre dann unmöglich (ist bei Lejos auch unmöglich).
Hallo,
Das schreibe ich weder dem Getriebe noch dem Gewicht des Roboters zu. Die NXT-Motoren können regelrecht "festgehalten" werden - wenn Du versuchst, den von Hand zu drehen, wird das schwer ohne zerstörende Wirkung.
Irgendwie haben die eine Bremsen / Halten-Funktion implementiert - wie habe ich mir zugegebenermaßen nicht so genau angesehen. Ach ja, ich hab die Original-Firmware auf dem NXT, bei dem geht das jedenfalls.
Ich hätte das jetzt spontan anders gesehen - denn die Motoren laufen eigentlich immer nach.Zurück zum Nibo: Die Motorbrücke kann auch bremsen, nur einen Freilauf kennt sie nicht (wie es Lego kann).
Letzteres ist erscheint mir nicht logisch zu sein. Wenn der Roboter leicht ist, müsste er auch viel schneller stehen - Massenträgheit lässt grüßen.Die Bremsleistung ist aber um Welten schlechter, als bei Lego, weil die Motoren winzig klein sind, weil das Getriebe nur eine geringe Übersetzung hat, weil die Reifen (zumindest auf Laminat) wenig Grip haben und weil der ganze Roboter sehr wenig Gewicht auf die Achsen bringt.
[/quote]Einen Stein mit Gummiband auf's Batteriefach klemmen hilft übrigens prima.[/quote]
Damit erhöhst Du die Reibung im Getriebe -> Der Roboter beschleunigt auch langsamer und du verbesserst den Grip.
Ich hab den Lego-Roboter zur Zeit als Humanoid. Als Rollen-Roboter kann ich mir durchaus vorstellen, ihn auf die Nibobee-Geschwindigkeit zu bringen.Wegen der geringen Übersetzung und dem geringen Gewicht kann der Nibo viel schneller fahren, als der Lego Roboter.
Ich hatte schonmal versucht, mit bremsen zu arbeiten. Das ist mir leider so gar nicht gelungen. Wie lässt Du denn die Bee praktisch bremsen?dann wird gebremst. Problem: Schätze ich zu viel, dann kommt der Roboter zu früh zum Stillstand.
BlödDas führt aber zu unschönem Ruckeln auf den letzten Zentimetern vor dem Ziel. Man kann dann buchstäblich sehen, dass der Bremsweg falsch geschätzt wurde.
OK, Du verlangsamst also mit einer Wurzelfunktion. Wie wäre es denn mit einer e-Funktion? Die ist doch immer am schnellsten am Ziel, oder hab ich das falsch in Erinnerung?maxTempo=sqrt(restDistanz*BREMSLEISTUNG);
Interessant übrigens. Ich habe meine "Regelung" im Prinzip genau so nur für das Beschleunigen aufgebaut. Ich nähere mich quadratisch dem Soll.
Wie so oftAber ganz so einfach geht es leider nicht, weil das Wurzelziehen zu lange dauert.
Wieviel vor dem Ziel ist denn der Bremsvorgang wirklich merkbar / sichtbar? Das könnte ich in meine Lib ja auch noch einbauen - nachdem ich die anderen Aufgaben mal erledigt habe...Letztendlich führt das Ganze dazu, dass der Roboter mit sehr geringer Geschwindigkeit am Ziel ankommt, wo ich dann getrost per Vollbremsung endgültig anhalten kann. Ich komme also stets wenige Millimeter hinter dem Ziel zum stehen.
Mh. Dann gäbe das ein unendliches hin- und her. In dem Fall wären die Parameter irgendwie falsch gewählt...Ein PID Regler wäre beim Nibo problematisch, denn wenn er erstmal rückwärts in Bewegung ist, kann er nicht schnell genug stoppen.
OK, das mag ich an meiner BieneZudem würde ein Zurücksetzen richtig viel Zeit kosten. Ein Flüssiger Unterbrechungsfreier Übergang zwischen geradeaus-fahrt und anschließender Drehung wäre dann unmöglich
Mh, wie gesagt, mit dem NXT hab ich erstmal die Füßchen des AlphaRex versucht, in den Gang zu bekommen. Wenn ich mal etwas fahrendes habe, werde ich da bestimmt auch eine Menge herumdoktorn...(ist bei Lejos auch unmöglich).
Also: Es gibt einiges zu tun
Wenn ich neue Erkenntnisse habe, schreibe ich mal wieder
Ciao bantyy
Berechtigungen
Zitieren
Lesezeichen