- LiFePO4 Speicher Test         
Seite 2 von 8 ErsteErste 1234 ... LetzteLetzte
Ergebnis 11 bis 20 von 72

Thema: Probleme mit 22er-Lochscheiben

  1. #11
    Erfahrener Benutzer Robotik Einstein Avatar von inka
    Registriert seit
    29.10.2006
    Ort
    nahe Dresden
    Alter
    77
    Beiträge
    2.180
    Anzeige

    LiFePo4 Akku selber bauen - Video
    hi damaltor,

    habe die 22er räder gegen die 8er gewechselt - das geht inzwischen wie beim ferrari team - die werte in der asuro.h wurden zunächst unverändert übernommen:
    Code:
    /* Tastaturabfrage */
    /*! Faktor zur Berechnung der gedrueckten Tasten.\n
          Der Originalwert ist \b 61L und koennten im Bereich zwischen ca. 58L und
          65L schwanken. Dieser Wert gleicht Toleranzen der Wiederstaende an den
          Tastern aus.
    */
    //#define MY_SWITCH_VALUE           61L   /*!< Multiplikator fuer Tasterwerte */
    #define MY_SWITCH_VALUE           63L   //20_08_2007
    
    /* Odometrie / Encoder */
    /*! Wert, der in der Odometrie ueberschritten werden muss, um zum
        weiterzaehlen der Ticks in encoder[] zu fuehren bei aktivierter
        Automatik\n
        Die Originalwerte (links, rechts) sind \b 160.
        Diese Werte sind sehr stark vom Umgebungslicht abhaengig.
        Sie MUESSEN GROESSER als die Werte fuer MY_ODO_DARK_VALUE_L sein.
    */
    //#define MY_ODO_LIGHT_VALUE_L     160    /*!< Encoderschwellwert fuer Hell (linke Seite) */
    //#define MY_ODO_LIGHT_VALUE_L     97    //20.08.2007
    #define MY_ODO_LIGHT_VALUE_L     105    //16.10.2007 - 8er räder
    //#define MY_ODO_LIGHT_VALUE_L     76    //24.10.2007 - 22er räder
    /*! Wert, der in der Odometrie unterschritten werden muss, um zum
        weiterzaehlen der Ticks in encoder[] zu fuehren bei aktivierter
        Automatik\n
        Die Originalwerte (links, rechts) sind \b 140.
        Diese Werte sind sehr stark vom Umgebungslicht abhaengig.
        Sie MUESSEN KLEINER als die Werte fuer MY_ODO_LIGHT_VALUE_L sein.
    */
    //#define MY_ODO_DARK_VALUE_L      140    /*!< Encoderschwellwert fuer Dunkel (linke Seite) */
    //#define MY_ODO_DARK_VALUE_L      59    //20.08.2007
    #define MY_ODO_DARK_VALUE_L      65    //16.10.2007 - 8er räder
    //#define MY_ODO_DARK_VALUE_L      47    //24.10.2007 - 22er räder
    /*! Wert, der in der Odometrie ueberschritten werden muss, um zum
        weiterzaehlen der Ticks in encoder[] zu fuehren bei aktivierter
        Automatik\n
        Die Originalwerte (links, rechts) sind \b 160.
        Diese Werte sind sehr stark vom Umgebungslicht abhaengig.
        Sie MUESSEN GROESSER als die Werte fuer MY_ODO_DARK_VALUE_R sein.
    */
    //#define MY_ODO_LIGHT_VALUE_R     160    /*!< Encoderschwellwert fuer Hell (rechte Seite) */
    #define MY_ODO_LIGHT_VALUE_R     107    //16.10.2007 - 8er räder
    //#define MY_ODO_LIGHT_VALUE_R     87    //24.10.2007 - 22er räder
    /*! Wert, der in der Odometrie unterschritten werden muss, um zum
        weiterzaehlen der Ticks in encoder[] zu fuehren bei aktivierter
        Automatik\n
        Die Originalwerte (links, rechts) sind \b 140.
        Diese Werte sind sehr stark vom Umgebungslicht abhaengig.
        Sie MUESSEN KLEINER als die Werte fuer MY_ODO_LIGHT_VALUE_R sein.
    */
    //#define MY_ODO_DARK_VALUE_R      140    /*!< Encoderschwellwert fuer Dunkel (rechte Seite) */
    #define MY_ODO_DARK_VALUE_R      66    //16.10.2007 - 8er räder
    //#define MY_ODO_DARK_VALUE_R      55    //24.10.2007 - 22er räder
    /* Werte für 12 Segmente Encoder */
    /*! Faktor zur Berechnung von Ticks um aus den in mm angegebenen Parameter
        umzurechnen.\n
        Der Originalwert ist \b 19363L und ist von der Anzahl der schwarz/weiss
        Teilstuecke auf den Odometriescheiben abhaengig.\n
        Der Originalwert wurde durch stochri ermittelt.
    */
    //#define MY_GO_ENC_COUNT_VALUE  19363L   /*!< GO Funktion, Divisor fuer Entfernung   */
    #define MY_GO_ENC_COUNT_VALUE  15740L   //20.08.2007 - 8er räder
    //#define MY_GO_ENC_COUNT_VALUE  5723L   //24.10.2007 - 22er räder
    /*! Faktor zur Berechnung von Ticks um aus den in Grad angegebenen Parameter
        umzurechnen.\n
        Der Originalwert ist \b 177L und ist von der Anzahl der schwarz/weiss
        Teilstuecke auf den Odometriescheiben abhaengig.\n
        Der Originalwert wurde durch stochri ermittelt.
    */
    //#define MY_TURN_ENC_COUNT_VALUE  177L   /*!< Turn Funktion, Mutiplikator fuer Winkel */
    //#define MY_TURN_ENC_COUNT_VALUE  197L   //20.08.2007
    //#define MY_TURN_ENC_COUNT_VALUE  210L   //06.09.2007
    #define MY_TURN_ENC_COUNT_VALUE  192   //16.10.2007 - 8er räder
    //#define MY_TURN_ENC_COUNT_VALUE  350 //24.10.2007 - 22er räder
    /* Werte zum ausgleichen unterschiedlicher Motoren */
    /*! Differenzangabe zwischen den beiden Motoren.\n
        Der angegeben Wert verteilt sich je zur Haelte auf die Vorgaben fuer die\n
        Motorgeschwindigkeit.\n
        Bei einem \n positiven Wert, wird der \n rechte Motor \b verstaerkt.\n
        Bei einem \n negativen Wert, wird der \n linke Motor \b verstaerkt.
      */
    #define MY_MOTOR_DIFF              0    /*!< 1/2 PLUS fuer Rechts, 1/2 MINUS fuer Links */
    
    #endif /* MYASURO_H */
    asuro dreht nicht.
    ich habe das testprogramm etwas erweiter, die LED´s leuchten brav:
    Code:
    #include "asuro.h"
    #include "inka.h"
    
    
    int main (void)
    
    {
    
    Init();
    WaitforStart();
    
    EncoderInit ();
    
    Go(100,100);
    StatusLED(GREEN);
    Msleep(500);
    Turn(100,100);
    StatusLED(RED);
    Msleep(500);
    Go(100,100);
    StatusLED(GREEN);
    Msleep(500);
    Turn(-100,100);
    StatusLED(RED);
    Msleep(500);
    
    Go(100,150);
    StatusLED(GREEN);
    Msleep(500);
    Turn(100,150);
    StatusLED(RED);
    Msleep(500);
    Go(100,150);
    StatusLED(GREEN);
    Msleep(500);
    Turn(-100,150);
    StatusLED(RED);
    Msleep(500);
    
    Go(100,200);
    StatusLED(GREEN);
    Msleep(500);
    Turn(100,200);
    StatusLED(RED);
    Msleep(500);
    Go(100,200);
    StatusLED(GREEN);
    Msleep(500);
    Turn(-100,200);
    StatusLED(RED);
    Msleep(500);
    
    return 0;
    }
    Dann veränderte ich die werte in die für 8er räder, asuro dreht...

    Ich kann mich immer noch nicht des eindrucks erwehren dass es mit der interpretation des turn wertes in der myasuro.h zu tun hat...
    gruß inka

  2. #12
    Erfahrener Benutzer Robotik Einstein Avatar von inka
    Registriert seit
    29.10.2006
    Ort
    nahe Dresden
    Alter
    77
    Beiträge
    2.180
    hi sternthaler,

    habe noch einmal die 22er räder aufgezogen und noch einmal den versuch gemacht mit wertermittlung für die myasuro.h mit deinem programm:

    - die werte in der myasuro.h habe ich dafür nicht verändert, für die fertige test.hex spielt das wohl aber kaum eine rolle...

    alle tests durchgeführt:

    - tastertest ergab 63, wie schon gehabt
    - hell/dunkel werte kannte ich auch schon
    - beim go test bricht der asuro nach rechts aus, spielt hier aber keine rolle, das go(xxx, 150) geht ja
    - beim turn-test konnte ich 2x "zu klein" angeben, anschliessend wiederholen, der gedrehte winkel war größer, beim dritten versuch "zu klein" per taster einzugeben streikte die systemLED, sie blieb rot. beim bestätigen mit OK taster erschien im feld für den turnparameter eine "1"!!!

    hilft das?
    gruß inka

  3. #13
    Erfahrener Benutzer Robotik Einstein Avatar von inka
    Registriert seit
    29.10.2006
    Ort
    nahe Dresden
    Alter
    77
    Beiträge
    2.180
    hi allerseits,

    ich habe noch ein bischen mit den 22er rädern experimentiert, unter umgehung der turn-funktion, sprich mit etwas abgewandelten code aus dem band II-asuro (aufgrund des fast rechteckigen verlaufes des odo-signales kann ich die hysterese vergrößern und den wert für triggerlevel auf 300 legen) lässt sich ein ziemlich genaues quadrat fahren . Durch die vergrößerung des abstandes zwischen den dunkel/hell werten ist die justage der doch relativ weich aufgehängten lichtschranken auch nicht mehr so difizil und störungsanfällig...

    Was kann es mit der turn funktion sein? Das einzige was mir bei dem code aus dem Buch auffiel, ist folgendes:
    am anfang: unsigned int distance=0;
    wenn es dann komplizierter wird: unsigned long int distance=0;

    distance ist dort die variable (switch) wo die ticks gezählt werden...

    Code:
    *im quadrat - 22er räder*/
    
    #include "asuro.h"
    #include "inka.h"
    
    //schwellwert für die hell/dunkel unterscheidung
    //evtl. muss damit etwas variiert werden
    
    #define TRIGGERLEVEL 300
    #define HYSTERESIS 50
    
    #define LOW 0
    #define HIGH 1
    
    int main (void)
    {
    	unsigned int data[2];
    	signed int status[2]={0,0};
    	signed int difference=0;
    	unsigned long int distance=0;
    	signed int speed=0;
    //	int i;
    
    	Init();
    	WaitforStart();
    
    	while(1)
    {
    	switch (distance)
    	{
    	//am anfang der strecke langsam anfahren
    	case 0: MotorDir (FWD,FWD); speed=150; break;
    	case 50: MotorDir (FWD,FWD); speed=200; break;
    	case 100: MotorDir (FWD,FWD); speed=255; break;
    	//am ende langsamer werden
    	case 750: speed=200; break;
    	case 800: speed=150; break;
    	//und stehebleiben
    	case 860: MotorDir(BREAK,BREAK);
    	//distance=861;
    	//etwas warten bis der asuro wirklich steht
    	Msleep(200);
    
    	MotorDir(RWD, FWD);speed=150;
    	distance=861;
    	case 900: speed=255; break;
    	case 950: speed=200; break;
    	case 980: speed=150; break;
    	case 1019: MotorDir(BREAK,BREAK);
    	//etwas warten bis der asuro wirklich steht
    	Msleep(200);
    	MotorDir (FWD,FWD); speed=150;
    	//und von vorne
    	distance=0;
    
    	 break;
    	}
    
    		//helligkeitswerte der lichschranke auslesen
    		OdometrieData(data);
    
    		//wechsel linker sensor von weiss (low) auf schwarz(high)?
    		if ((status[0]==LOW) && (data[0]>TRIGGERLEVEL + HYSTERESIS))
    		{
    		status[0]=HIGH;
    		difference++;
    		distance++;
    		}
    
    		//wechsel linker sensor von schwarz (high) auf weiss(low)?
    		if ((status[0]==HIGH) && (data[0]<TRIGGERLEVEL - HYSTERESIS))
    		{
    		status[0]=LOW;
    		difference++;
    		distance++;
    		}
    
    		//wechsel rechter sensor von weiss (low) auf schwarz(high)?
    		if ((status[1]==LOW) && (data[1]>TRIGGERLEVEL + HYSTERESIS))
    		{
    		status[1]=HIGH;
    		difference--;
    		}
    
    		//wechsel rechter sensor von schwarz (high) auf weiss(low)?
    		if ((status[1]==HIGH) && (data[1]<TRIGGERLEVEL - HYSTERESIS))
    		{
    		status[1]=LOW;
    		difference--;
    }
    
    //zur sichreit: verhindern, dass der differenzzähler
    //den erlaubten wertebereich verlässt
    if (difference<-speed) difference=-speed;
    if (difference>speed) difference=speed;
    
    //status LED entsprechend der erkannten segmente aufleuchten lassen
    //grün für links, rot für rechts
    StatusLED(status[0]+status[1]*2);
    
    //Zählerdifferenz passend auf die motoren verteilen
    if (difference>0) MotorSpeed(speed-difference,speed);
    else MotorSpeed(speed,speed+difference);
    }
    return 0;
    }
    gruß inka

  4. #14
    Moderator Robotik Einstein Avatar von damaltor
    Registriert seit
    28.09.2006
    Ort
    Milda
    Alter
    38
    Beiträge
    4.067
    na ein long INT ist immer noch ein int... denke nicht das das ein prolem werden könnte, wenn du auf die kommazahlen im long abzielst.
    Read... or die.
    ff.mud.de:7600
    Bild hier  

  5. #15
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    29.05.2005
    Beiträge
    1.018
    Hallo inka,
    hier erst einmal eine Betrachtung der Rechengeschwindigkeit und der Zeit am Rad.

    Gute Nachricht (oder doch nicht, da es keine Erklärung für dein Problem liefert).

    Ich habe mal die AD-Wandlergeschwindigkeit nachgerechnet.
    Folgendes ist da rausgekommen (ATmega8-Doku von der CD):
    Code:
    Ab Seite 193 in der Doku
    - Wandlerzeit zwischen 65 und 260 us
    - prescaler Clock 50-200 kHz für 10 Bit
                       > 200 kHz für < 10 Bit
    - prescaler bits in ADPS im Register ADCSRC
    - normale Wandlung in 13 ADC-Clock's
        erste Wandlung in 25 ADC-Clock's
    - bei 'free running' sofortiger Start einer weiteren Wandlung
    
    - prescaler auf Seite 205
      ADPS2-0 Faktor Frequenz bei 8MHz
      --------------------------------
            0    2   4000000
            1    2   4000000
            2    4   2000000
            3    8   1000000
            4   16    500000
            5   32    250000
            6   64    125000
            7  128     62500
    Es gibt 2 verschiedene Einstellungen des Prescalers in den Asuro-Funktionen.
    - Init(): Der Prescaler wird auf 6 (Teiler 64) gesetzt.
    - Encoder_Init(): Der Prescaler wird auf 7 (Teiler 12 gesetzt.

    Für die weitere Betrachtung nun der 128-Teiler:

    - ADC-Clock: 8Mhz / 128 = 62,5 kHz
    - ADC-Conversion: 62,5 kHz / 13 Clocks = 4808 Wandlungen pro Sekunde
    - 2 Räder: 4808 / 2 Seiten = 2404 Wandlungen pro Sekunde pro Rad
    - Zeit pro Wandlung pro Rad: 1 / 2404 = 416 us


    Für deine Hardware (22 Löcher/22 Hindernis) ergibt sich folgendes:
    - 1 - Max. Asuro Geschwindigkeit: 50 cm/sec
    - 2 - Rad-Umfang: ca. 12 cm
    - 3 - Umdrehung / sec: 4,16
    - 4 - Getriebe Rad/Odo-Scheibe: 1/5
    - 5 - Odo-Scheiben-Umdrehung / sec: 5 * 4,16 = 20,8
    - 6 - Löcher/Hindernis / Umdrehung: 44
    - 7 - Messpositionen / sec: 44 * 20,8 = 916
    - 8 - Mindestens 2 Messungen erforderlich: 1832 Messungen / sec
    - 9 - Zeit pro Messung: 1 / 1832 = 546 us


    Es sieht so aus, dass die AD-Wandlerzeit mit 416 us so eben ausreicht, um die Zeit am Rad mit 546 us so gerade abzudecken.
    Da ich von maximaler Asuro-Geschwindigkeit ausgegangen bin, ist auf alle Fälle genug Zeit bei niedrigeren Geschwindigkeiten vorhanden.

    Fazit: Eben keine Erklärung, warum es bei dir nicht geht.
    Über die Asuro-LIB sollte es möglich sein, deine 22-Löcher-ODO-Scheibe so gerade noch zu bearbeiten.

    Aber:
    Das Messprogramm von mir schafft die 22-ODO-Scheibe definitiv nicht mehr.
    Da in dem Programm pro AD-Kanal immer 2 Messungen gemacht werden, alle 4 Sensoren (Rad, Linie / Rechts, Links) permanent bearbeitet werden, vervierfacht sich die Messzeit der oben angegeben Zeit von 416 us auf 1664 us.
    Außerdem enthält das Messprogramm 'künstliche' Pausen zwischen den einzelnen Messungen, so dass die Messzeit noch länger wird.

    Fazit Messprogramm:
    Alle Werte, die dir bei den Tests 2, 3 und 4 geliefert werden, sind falsch.
    Somit sind auch die im Test 2 ermittelten Werte für die MY_ODO_xxx_VALUE_[L|R] nicht korrekt.
    Deshalb würde ich jetzt sagen, dass deine Mühe, die Werte aus dem Messprogramm für mich zusammenzustellen, mit Sicherheit überflüßig war. Trotzdem war's ja ein Versuch wert.

    Es bleibt somit wohl bei der Turn()-Funktion, in der ihr ja gerade die Variablen-Längen betrachtet. Von mir dazu später Kommentare.

    Gruß Sternthaler
    Lieber Asuro programieren als arbeiten gehen.

  6. #16
    Moderator Robotik Einstein Avatar von damaltor
    Registriert seit
    28.09.2006
    Ort
    Milda
    Alter
    38
    Beiträge
    4.067
    ich denke aber, dass man das hier beachten sollte:
    http://de.wikipedia.org/wiki/Abtasttheorem
    die abtastfrequenz muss mindestens doppelt so groß sein wie die frequenz des zu messenden signales. also reicht die geschwindigkeit absolut nicht aus.
    Read... or die.
    ff.mud.de:7600
    Bild hier  

  7. #17
    Erfahrener Benutzer Robotik Einstein Avatar von inka
    Registriert seit
    29.10.2006
    Ort
    nahe Dresden
    Alter
    77
    Beiträge
    2.180
    hi sternthaler, damaltor,

    wenn ich das richtig verstehe müsste bei

    - Zeit pro Wandlung pro Rad= 416 us

    die minimale zeit für die messung 2x so groß sein, also etwa 850 us. Bei 22 löchern ist die messzeit 546 us. Die maximale anzahl löcher wäre demnach 546x22/850=14.

    ist das in etwa so?
    gruß inka

  8. #18
    Moderator Robotik Einstein Avatar von damaltor
    Registriert seit
    28.09.2006
    Ort
    Milda
    Alter
    38
    Beiträge
    4.067
    stop, andersrum:

    ein tick des rades dauert ca 550 µs. um alle tiks zu erfassen darf eine wandlung MAXIMAL 275 µs dauern. man könnte versuchen, den takt des adc zu erhöhen, über 200 khz hinaus (adc prescaler, siehe datenblatt). dadurch würde die messung weniger genau (bei den extrem guten werten kein problem) aber es würde schneller gehen.
    Read... or die.
    ff.mud.de:7600
    Bild hier  

  9. #19
    Erfahrener Benutzer Robotik Einstein Avatar von inka
    Registriert seit
    29.10.2006
    Ort
    nahe Dresden
    Alter
    77
    Beiträge
    2.180
    naja,
    mir geht es ja nicht darum das 22er rad zu erhalten, die genauigkeit eines 16er rades mit einer durchlich-lichschranke wäre auch noch gut genug - und ich wäre wieder - was den rest des asuro betrifft - etwas näher an de algemeinheit...
    Also höchsten änderungen/anpassungen in der myasuro.h und keine so grundlegende änderungemn wie z.b. die takterhöhung. Wie macht man sowas überhaupt? Würde dann andere software überhaupt noch gehen?

    Eine andere frage. Mit der durchlicht-lichschranke und deren guten werten - erübrigt sich die mysuro.h nicht zum größten teil?
    gruß inka

  10. #20
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    29.05.2005
    Beiträge
    1.018
    Hallo?? Was habe ich übersehen?
    bei der Berechnung der Anzahl Messungen am Rad habe ich doch in der dort angegebene Zeile "- 8 - Mindestens 2 Messungen erforderlich: 1832 Messungen / sec" schon eine doppelte Messanzahl berücksichtigt.
    Dann sind nach meinem Taschenrechner da 1 / 1832 also die angegeben 546 us schon für das Theorem berechnet.

    @inka
    Ob sich die myasuro.h deshalb erübrigt, möchte ich bezweifeln. Warte mal auf das Sommerlicht. Die Meswerte der ODO-Dinger gehen dann auf Werte um 50 runter. Differenzen zu der mickerigen LED-Beleuchtung kann man zwar mit dem Auge in einer EXCEL-Tabelle ausmachen, aber ich habe es noch nie geschafft daraus Tik's zu ermitteln.

    Gruß Sternthaler
    Lieber Asuro programieren als arbeiten gehen.

Seite 2 von 8 ErsteErste 1234 ... LetzteLetzte

Berechtigungen

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

LiFePO4 Speicher Test