- LiFePO4 Speicher Test         
Seite 3 von 8 ErsteErste 12345 ... LetzteLetzte
Ergebnis 21 bis 30 von 75

Thema: NIBObee Erfahrungsberichte

  1. #21
    Erfahrener Benutzer Roboter Genie Avatar von pinsel120866
    Registriert seit
    18.12.2007
    Ort
    Hohenems
    Alter
    58
    Beiträge
    847
    Anzeige

    Praxistest und DIY Projekte
    Hmm,

    ich vermute die Datei line.c aus der Bibliothek stimmt nicht. Ich kann nämlich den Quellcode aus Seite 38 auch nicht kompilieren.

  2. #22
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    08.01.2006
    Beiträge
    4.555
    Zitat Zitat von oberallgeier
    Hallo NIBObee `s,

    . dann z.B. Dioden, usw. Immer schön so, dass man bei den nächsten Teilen noch an die Lötpunkte kommt. Aber bei der hübschen Hauptplatine ist sowieso nicht wenig Platz.
    Alter Trick, man fängt immer mit den niedrigsten Bauteilen an, hier
    warscheinlich die Dioden. Zum Löten gegenherausfallen der Bazteile
    sind Haarklipps gut zu gebrtauchen, es gibt ziemlich lange und zur
    Not lötet man eine Verlängerung an. Wenn man gleich mehr Bauteile
    Löten wil, einfach einne Schamstoffmunterlage auf die Platine legen
    und beides zusammen umdrehen. Dann fällt nix mehr raus.

    Sag jetzt keiner der Schaumstoff schmilst..und wenn ist das togalegal.
    Ich habe einen bstückungsrahmen für bis zu 2 Eurokarten der ähnlich
    funktioniert und da verkokelt nix.

    Gruß Richard

  3. #23
    Moderator Robotik Visionär Avatar von radbruch
    Registriert seit
    27.12.2006
    Ort
    Stuttgart
    Alter
    61
    Beiträge
    5.799
    Blog-Einträge
    8
    Hallo

    Ich habe es nun doch übersetzt bekommen. Da ich ja noch meine alte AVR-GCC-Installation verwende (never chance a runing system;) kann ich nicht sagen, ob die Probleme representativ sind:

    -In allen Funktionsprototypen ein void in die Klammern eingefügt, auch in main()
    -Alle #include "" nach <> geändert
    -Trotz anscheinend korrekt eingebundener atomic.h klappte das Kompillieren erst nachdem ich überall die atomic-Funktionen mit cli()--sei() ersetzt hatte. atomic.h verhindert u.a. Fehler bei gleichzeitigem Zugriff von Programm und ISR auf eine mehr als 8bit-Variable und rettet wichtige Register. Änderungsbeispiel in motpwm.c:
    Code:
    void motpwm_stop(void) {
    	//ATOMIC_BLOCK(ATOMIC_RESTORESTATE)
    	{
    	cli();
        motpwm_motor_l = 0;
        motpwm_motor_r = 0;
        PWM_TIMER_OCRA = 0;
        PWM_TIMER_OCRB = 0;
    	sei();
    	}
    }
    Meine atomic.h:
    Code:
    /* Copyright (c) 2007 Dean Camera
       All rights reserved.
    
       Redistribution and use in source and binary forms, with or without
       modification, are permitted provided that the following conditions are met:
    
       * Redistributions of source code must retain the above copyright
         notice, this list of conditions and the following disclaimer.
    
       * Redistributions in binary form must reproduce the above copyright
         notice, this list of conditions and the following disclaimer in
         the documentation and/or other materials provided with the
         distribution.
    
       * Neither the name of the copyright holders nor the names of
         contributors may be used to endorse or promote products derived
         from this software without specific prior written permission.
    
      THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
      AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
      IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
      ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
      LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
      CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
      SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
      INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
      CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
      ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
      POSSIBILITY OF SUCH DAMAGE.
    */
    
    /* $Id: atomic.h,v 1.3 2007/12/20 14:17:56 joerg_wunsch Exp $ */
    
    #ifndef _UTIL_ATOMIC_H_
    #define _UTIL_ATOMIC_H_ 1
    
    #include <avr/io.h>
    #include <avr/interrupt.h>
    
    #if !defined(__DOXYGEN__)
    /* Internal helper functions. */
    static __inline__ uint8_t __iSeiRetVal(void)
    {
        sei();
        return 1;
    }
    
    static __inline__ uint8_t __iCliRetVal(void)
    {
        cli();
        return 1;
    }
    
    static __inline__ void __iSeiParam(const uint8_t *__s)
    {
        sei();
        __asm__ volatile ("" ::: "memory");
        (void)__s;
    }
    
    static __inline__ void __iCliParam(const uint8_t *__s)
    {
        cli();
        __asm__ volatile ("" ::: "memory");
        (void)__s;
    }
    
    static __inline__ void __iRestore(const  uint8_t *__s)
    {
        SREG = *__s;
        __asm__ volatile ("" ::: "memory");
    }
    #endif	/* !__DOXYGEN__ */
    
    #if defined(__DOXYGEN__)
    #define ATOMIC_BLOCK(type)
    #else
    #define ATOMIC_BLOCK(type) for ( type, __ToDo = __iCliRetVal(); \
    	                       __ToDo ; __ToDo = 0 )
    #endif	/* __DOXYGEN__ */
    
    /** \def NONATOMIC_BLOCK(type)
        \ingroup util_atomic
    
        Creates a block of code that is executed non-atomically. Upon
        entering the block the Global Interrupt Status flag in SREG is
        enabled, and disabled upon exiting the block from any exit
        path. This is useful when nested inside ATOMIC_BLOCK sections,
        allowing for non-atomic execution of small blocks of code while
        maintaining the atomic access of the other sections of the parent
        ATOMIC_BLOCK.
    
        Two possible macro parameters are permitted,
        NONATOMIC_RESTORESTATE and NONATOMIC_FORCEOFF.
    */
    #if defined(__DOXYGEN__)
    #define NONATOMIC_BLOCK(type)
    #else
    #define NONATOMIC_BLOCK(type) for ( type, __ToDo = __iSeiRetVal(); \
    	                          __ToDo ;  __ToDo = 0 )
    #endif	/* __DOXYGEN__ */
    
    /** \def ATOMIC_RESTORESTATE
        \ingroup util_atomic
    
        This is a possible parameter for ATOMIC_BLOCK. When used, it will
        cause the ATOMIC_BLOCK to restore the previous state of the SREG
        register, saved before the Global Interrupt Status flag bit was
        disabled. The net effect of this is to make the ATOMIC_BLOCK's
        contents guaranteed atomic, without changing the state of the
        Global Interrupt Status flag when execution of the block
        completes.
    */
    #if defined(__DOXYGEN__)
    #define ATOMIC_RESTORESTATE
    #else
    #define ATOMIC_RESTORESTATE uint8_t sreg_save \
    	__attribute__((__cleanup__(__iRestore))) = SREG
    #endif	/* __DOXYGEN__ */
    
    /** \def ATOMIC_FORCEON
        \ingroup util_atomic
    
        This is a possible parameter for ATOMIC_BLOCK. When used, it will
        cause the ATOMIC_BLOCK to force the state of the SREG register on
        exit, enabling the Global Interrupt Status flag bit. This saves on
        flash space as the previous value of the SREG register does not
        need to be saved at the start of the block.
    
        Care should be taken that ATOMIC_FORCEON is only used when it is
        known that interrupts are enabled before the block's execution or
        when the side effects of enabling global interrupts at the block's
        completion are known and understood.
    */
    #if defined(__DOXYGEN__)
    #define ATOMIC_FORCEON
    #else
    #define ATOMIC_FORCEON uint8_t sreg_save \
    	__attribute__((__cleanup__(__iSeiParam))) = 0
    #endif	/* __DOXYGEN__ */
    
    /** \def NONATOMIC_RESTORESTATE
        \ingroup util_atomic
    
        This is a possible parameter for NONATOMIC_BLOCK. When used, it
        will cause the NONATOMIC_BLOCK to restore the previous state of
        the SREG register, saved before the Global Interrupt Status flag
        bit was enabled. The net effect of this is to make the
        NONATOMIC_BLOCK's contents guaranteed non-atomic, without changing
        the state of the Global Interrupt Status flag when execution of
        the block completes.
    */
    #if defined(__DOXYGEN__)
    #define NONATOMIC_RESTORESTATE
    #else
    #define NONATOMIC_RESTORESTATE uint8_t sreg_save \
    	__attribute__((__cleanup__(__iRestore))) = SREG
    #endif	/* __DOXYGEN__ */
    
    /** \def NONATOMIC_FORCEOFF
        \ingroup util_atomic
    
        This is a possible parameter for NONATOMIC_BLOCK. When used, it
        will cause the NONATOMIC_BLOCK to force the state of the SREG
        register on exit, disabling the Global Interrupt Status flag
        bit. This saves on flash space as the previous value of the SREG
        register does not need to be saved at the start of the block.
    
        Care should be taken that NONATOMIC_FORCEOFF is only used when it
        is known that interrupts are disabled before the block's execution
        or when the side effects of disabling global interrupts at the
        block's completion are known and understood.
    */
    #if defined(__DOXYGEN__)
    #define NONATOMIC_FORCEOFF
    #else
    #define NONATOMIC_FORCEOFF uint8_t sreg_save \
    	__attribute__((__cleanup__(__iCliParam))) = 0
    #endif	/* __DOXYGEN__ */
    
    #endif
    -In der For-Schleife will mein Kompiller keine Variablendeklaration akzepieren
    -Die Variable uint16_t nibobee_initialization von Hand erzeugt. Ich weiß noch nicht, wo die normalerweise herkommen sollte.

    Meine mit 2386 Bytes übersetzte Version des Liniendemos sieht nun so aus:
    Code:
    // kleines Linienfolgedemo (nachbearbeitet)                             14.10.09 mic
    
    // https://www.roboternetz.de/phpBB2/vi...=470433#470433
    // https://www.roboternetz.de/phpBB2/ze...=468642#468642
    
    #include <nibobee/iodefs.h>
    #include <nibobee/motpwm.h>
    #include <nibobee/analog.h>
    #include <nibobee/line.h>
    #include <nibobee/led.h>
    #include <nibobee/delay.h>
    
    #include <avr/io.h>
    #include <avr/interrupt.h>
    #include <util/delay.h>
    
    uint8_t i;
    uint16_t nibobee_initialization;
    
    int main(void) {
      activate_output_group(IO_LEDS);  // LED bits als Output
      motpwm_init();
      motpwm_setLeft(0);
      motpwm_setRight(0);
      analog_init();
      line_readPersistent();
      set_output_group(IO_SENS);       // Pull-ups aktivieren
      activate_output_bit(IO_LINE_EN);
    
      int16_t speed_flt_l=0;
      int16_t speed_flt_r=0;
    
      // Countdown: LEDs blinken lassen
      for (i=0; i<10; ++i) {
        led_set(LED_L_RD, 1);
        led_set(LED_R_RD, 1);
        _delay_ms(10);
        led_set(LED_L_RD, 0);
        led_set(LED_R_RD, 0);
        _delay_ms(990);
      }
      led_set(LED_L_YE, 1);
      led_set(LED_R_YE, 1);
      _delay_ms(1000);
      led_set(LED_L_YE, 0);
      led_set(LED_R_YE, 0);
    
      // Hauptschleife:
      while(1) {
        sei();
        _delay_ms(1);
        int16_t speed_l=0;
        int16_t speed_r=0;
    
        int16_t lval = line_get(LINE_L);
        int16_t cval = line_get(LINE_C);
        int16_t rval = line_get(LINE_R);
    
        if (lval+cval+rval < 20) {
          led_set(LED_L_RD, 0);
          led_set(LED_R_RD, 0);
          speed_r=0, speed_l=0;
        } else if ((lval<cval) && (lval<rval)) {
          // lval is minimum
          led_set(LED_L_RD, 1);
          led_set(LED_R_RD, 0);
          speed_r=550, speed_l=450-1*(cval-lval);
        } else if ((rval<cval) && (rval<lval)) {
          // rval is minimum
          led_set(LED_L_RD, 0);
          led_set(LED_R_RD, 1);
          speed_r=450-1*(cval-rval), speed_l=550;
        } else {
          // cval is minimum
          led_set(LED_L_RD, 1);
          led_set(LED_R_RD, 1);
          speed_r=750 + 1*(rval-cval), speed_l=750 + 1*(lval-cval);
        }
    
        speed_flt_l*=3; speed_flt_l+=speed_l; speed_flt_l/=4;
        speed_flt_r*=3; speed_flt_r+=speed_r; speed_flt_r/=4;
    
        motpwm_setLeft(speed_flt_l);
        motpwm_setRight(speed_flt_r);
    
      }
      return 0;
    }
    Und kann das:
    Bild hier  
    http://www.youtube.com/watch?v=WaxGDNcvVpo

    Der Löthilfeschaumstoff hat mich locker eine halbe Stunde Zeit gekostet, weil die beiden Odo-IR-LEDs unter ihm versteckt (festgeklammert!) waren ;)

    Gruß

    mic

    [Edit]
    Achtung! Nach dem Übertragen des Programms schwirrt die Biene sofort los!
    Angehängte Dateien Angehängte Dateien
    Bild hier  
    Atmel’s products are not intended, authorized, or warranted for use
    as components in applications intended to support or sustain life!

  4. #24
    Erfahrener Benutzer Roboter Genie Avatar von pinsel120866
    Registriert seit
    18.12.2007
    Ort
    Hohenems
    Alter
    58
    Beiträge
    847
    Komisch... müssten bei deinem Code nicht zuerst die LEDs blinken bevor die Bee losfährt?

    Ich kann den Code jedenfalls auch nicht fehlerfrei übersetzen:

    Code:
    Build started 14.11.2009 at 21:50:34
    avr-gcc -I"C:\Users\HP\Documents\NibobeeTest\..\..\..\..\Program Files\NIBObeeLib\include"  -mmcu=atmega16 -Wall -gdwarf-2 -std=gnu99  -D_NIBOBEE_    -DF_CPU=15000000UL -Os -fsigned-char -MD -MP -MT NibobeeTest.o -MF dep/NibobeeTest.o.d  -c  ../NibobeeTest
    .c
    
    avr-gcc -mmcu=atmega16  NibobeeTest.o   -L"C:\Program Files\NIBObeeLib\lib"  -lnibobee_base -lnibobee_utils -lnibobee_line  -o NibobeeTest.elf
    C:\Program Files\NIBObeeLib\lib\libnibobee_line.a(line.o): In function `line_calibrateBlack':
    line.c:(.text.line_calibrateBlack+0x4): undefined reference to `delay'
    C:\Program Files\NIBObeeLib\lib\libnibobee_line.a(line.o): In function `line_calibrateWhite':
    line.c:(.text.line_calibrateWhite+0x4): undefined reference to `delay'
    make: *** [NibobeeTest.elf] Error 1
    Build failed with 2 errors and 0 warnings...

  5. #25
    Moderator Robotik Visionär Avatar von radbruch
    Registriert seit
    27.12.2006
    Ort
    Stuttgart
    Alter
    61
    Beiträge
    5.799
    Blog-Einträge
    8
    Komisch... müssten bei deinem Code nicht zuerst die LEDs blinken bevor die Bee losfährt?
    Jepp, müssten sie. Sie tun es auch, allerdings ziemlich schnell. Das Blinken sollte (10+990)*10 Millisekunden (=10 Sekunden;) dauern, in meiner Version dauert das Ganze keine Sekunde. Muss ich mal genauer anschauen...

    Warum deine Orginalinstallation nicht funktioniert kann ich im Moment echt nicht sagen. Wir werden wohl abwarten müssen bis sich workwind wieder meldet :(

    Gruß

    mic
    Bild hier  
    Atmel’s products are not intended, authorized, or warranted for use
    as components in applications intended to support or sustain life!

  6. #26
    Erfahrener Benutzer Roboter Genie Avatar von m.a.r.v.i.n
    Registriert seit
    24.07.2005
    Ort
    Berlin
    Beiträge
    1.247
    Hallo,

    @pinsel. Der 'delay' Fehler ist in der aktuellen Lib Version beseitigt.
    http://sourceforge.net/projects/nibobeelib/

    Ich habe mich auch dazu entschlossen, die Liniensensoren tiefer zu legen. Mit der Plexiglas Halbkugel funktioniert das irgendwie nicht.

  7. #27
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.686
    Zur Liniensensorik

    Sie hat eine nicht unbekannte Eigenschaft: die LEDs schielen zu den Phototransistoren und beeinflussen deren Messungen durch einen Offset auf den Messwert des reflektierten Lichtes. Da die Photoempfänger keine AGC haben, ist es meiner Meinung nach empfehlenswert, die LEDs mit Schrumpfschlauchblenden von den Phototransistoren abzuschotten. Ein erster Versuch mit dünnen, nicht aufgeschrumpften Schrumpfschläuchen die bündig zur LED-Kalotte stehen, ergab eine drastische Veränderung der Messcharakteristik. Diese wurde vorerst nur qualitativ festgestellt mit dem Programm, das je nach Signalausgang der Phototransistoren die rtLED und/oder die geLED schaltet. Während ohne Schirm meine Schreibtischoberfläche bis etwa 20 cm Abstand als Reflektor erkannt wurde, sank die Empfindlichkeit mit Schirm auf etwa 5 bis 10 cm. Da die elektronische Empfindlichkeit nicht verändert wurde, wird ziemlich sicher im ersten, ungeschirmten Fall das Streulicht einen kräftigen Offset erzeugen. Es ist fraglich, ob so ein Offset für die meisten Fälle gut, weniger gut oder schlecht ist. Ich meine, dass ich für Liniensuche die Schirme benützen werde – das entspricht auch meinen Erfahrungen zu ähnlich aufgebauten irDME´s:
    https://www.roboternetz.de/phpBB2/vi...bed874a0b24ad8
    oder vielmehr dieses Posting hier:
    https://www.roboternetz.de/phpBB2/ze...c6525d0#351464
    Ciao sagt der JoeamBerg

  8. #28
    Zum Problem mit dem nicht gefundenen delay

    Du musst in der Library Konfiguration im AVR-Studio die nibobee_base ganz ans Ende der Libraryauflistung verschieben (Button: Move Down). Dies deshalb, damit zuerst die nibobee_line.a eingebunden wird. Von dort werden Funktionen verwendet (delay), die sonst nicht in deinem Programm vorkommen. Würde man die nibobee_base zuerst einbinden, dann wird die Funktion delay nicht ins EXE übernommen, weil der Linker noch nicht weiß, das er sie brauchen wird.

    Auch hatte ich das Problem, dass die Taster an den Fühlern zwar geschaltet haben aber nur dann, wenn man den Fühler um fast 100° nach hinten biegt. Von 4 Tastern schaltete nur einer mit dem tastertypischen Knacksen.
    Ich habe das Problem so gelöst, dass ich die Fühler noch einmal ausgelötet habe und jeweils das hintere der beiden Löcher für den Silberdraht mit einem 1.5mm Bohrer aufgebohrt habe. Das andere 1mm Loch fungiert als Lager für den Silberdraht und das aufgebohrte Loch verschafft dem Draht die nötige Luft um sich um dieses Lager drehen zu können. Nach dem Zusammenbau ergaben sich 4 einwandfrei rastende Taster, die beim Bewegen des Fühlerendes um ca. 2cm einwandfrei hörbar rastend schalten.

  9. #29
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.686
    Zitat Zitat von radbruch
    ... gewöhnungsbedürftig ist das direkte Durchstarten nach dem Flashen ...
    Mic, Du hast es sicher selber schon längst gemerkt: vor dem Flashen den Jumper 7 ziehen (vgl. Bauanleitung S 6, Mitte und S 7, 1.2.2 - letzter Satz).

    Zitat Zitat von kbuchegg
    ... Problem, dass die Taster ... geschaltet haben aber nur dann, wenn man den Fühler um fast 100° nach hinten biegt ...
    Ich habe (vgl. Bauanleitung S 36, 2.5.4 - oben) den Silberdraht in den länglichen Hilfsplatinen für die Fühler nicht festgelötet und die beiden kleinen Hilfsplatinen (vgl. Bauanleitung S 36, 2.5.4 - unten) mit einem Papierstreifen als Abstandshalter festgelötet; Papier danach entfernt. Der Schaltklick kommt sauber und trocken. Auslösekraft, gemessen 100 mm von der Fühlerachse - mit vorschriftsmässigen Fühlern, tangential zum Fühler: rechts +/- 60 mN / 100 mN (sprich: 6 g beim Zurückbiegen, 10 g beim Vorbiegen), links +/- 60 mN / 80 mN. (Meine Freie Pistole=Olympiapistole kann ich bei meinem allerbesten Trainingszustand nicht mit weniger als ca. 3..5 g schiessen - sonst geht die sozusagen von alleine los.)
    Ciao sagt der JoeamBerg

  10. #30
    Erfahrener Benutzer Roboter Genie Avatar von pinsel120866
    Registriert seit
    18.12.2007
    Ort
    Hohenems
    Alter
    58
    Beiträge
    847
    Hallo,

    danke für eure Hinweise. Mit der Umstellung der Reihenfolge der Verarbeitung der Bibliotheken konnte ich den Code kompilieren.

    Eine deutliche Verbesserung der Linienerkennung brachte das Anbringen eines Schrupfschlauches auf alle fünf Dioden, zusätzlich habe ich eine Manschette über die Baugruppe gestülpt. Das bringt das beste Ergebnis, siehe Fotos bzw. Video. Als Abstandhalter dient bei mir der gute, alte Tischtennisball, die Orginalkuppel ist meiner Ansicht nach zu hoch.

    Nun kann mein Bienchen unter Vollgas die Linie abfahren, siehe dazu:
    http://www.youtube.com/watch?v=Au-YrTreRK4

Seite 3 von 8 ErsteErste 12345 ... LetzteLetzte

Berechtigungen

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

LiFePO4 Speicher Test