- MultiPlus Wechselrichter Insel und Nulleinspeisung Conrad         
Ergebnis 1 bis 10 von 13

Thema: Asuro Lib und Kollisionstest Problem

Hybrid-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #1
    Erfahrener Benutzer Roboter Genie Avatar von m.a.r.v.i.n
    Registriert seit
    24.07.2005
    Ort
    Berlin
    Beiträge
    1.247
    Hallo Marph,

    das sieht soweit alles i. O. aus. Lass dir doch mal die eingelesenen Tasterwerte seriell ausgeben. Dann wird man ja sehen, welcher Taster spinnt. Den kann man dann ggfs. aus der Abfrage ausmaskieren.

    Code:
    ...
    elseif(t1 && t2 && t1 == t2)
    {
          PrintInt(t1);     /* Tastenwert senden */
          SerWrite("\r\n", 2); /* Zeilenvorschub */
          
          MotorStop();
    if(t1 & 0x07)/* Tasten links gedrückt? */
    {
            MotorRwdL();       /* Rückwärtskurve links fahren */
            FrontLED(OFF);
            BackLED(ON,OFF);
    }
    if(t1 & 0x38)/* Tasten rechts gedrückt? */
    {
            MotorRwdR();       /* Rückwärtskurve rechts fahren */
            FrontLED(OFF);
            BackLED(OFF,ON);
    }
          Msleep(1000);        /* 1 Sekunde fahren */
    }
     ...

  2. #2
    Neuer Benutzer Öfters hier
    Registriert seit
    09.07.2015
    Beiträge
    7
    Hallo m.a.r.v.i.n,

    ich hab den Code eingepflegt und mehrere Durchläufe gemacht. Nach einigen Durchläufen gabs eine Low Voltage Meldung. Hab dann die Batteriespannung gemessen, die bei 1,46V pro Batterie lag(keine Akkus, Jumpers ist nicht gesetzt).

    Hab dann sicherheitshalber neue Batterien eingelegt und danach funktionierte es sogar zweimal mit dem Kollisionstest. Dann drehte er aber wieder permanent links rückwärts oder drehte vorwärts und reagierte auf überhaupt keinen Tastendruck. Und auch mit den neuen Batterien hatte ich zweimal eine Low Voltage Meldung.

    Spaßeshalber hab ich dann noch den Kollisionstest mit der originalen Library geflasht und damit lief alles wieder tadellos.

    Des Weiteren habe ich mir Programmers Notepad runtergeladen und auch dort den Kollisionstest mit der v2.80 rc2 Library kompiliert, allerdings mit dem gleichen Resultat wie bisher.

    Code:
    MY_SWITCH_VALUE = 62L
    
    1
    2
    1
    1
    2
    1
    2
    1
    2
    1
    2
    2
    3
    2
    1
    1
    1
    1
    1
    2
    1
    1
    3
    1
    1
    1
    1
    1
    1
    2
    3
    3
    
    MY_SWITCH_VALUE = 63L
    1
    1
    2
    2
    2
    1
    1
    2
    1
    2
    2
    1
    1
    1
    1
    2
    1
    2
    1
    1
    1
    2
    2
    1
    1
    2
    1
    1
    1
    1
    
    MY_SWITCH_VALUE = 63L
    
    1
    1
    1
    224
    2
    1
    2
    2
    1
    ▒1
    ▒▒▒1
    1
    ▒▒VLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVL
    
    VLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVLVL▒1
    2
    1
    1
    1
    1
    2
    1
    1
    1
    1
    
    
    Neue Batterien:
    MY_SWITCH_VALUE = 63L 
    
    2
    1
    1
    22
    1
    1
    2
    2
    1
    2
    1
    1
    1
    1
    Mfg Marph

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


    tja das könnte alles mögliche sein. Wie man aus dem Log sieht, ist nicht nur Taster K1 sondern auch manchmal K2 zu sehen.


    Fehlerursachen könnten sein:
    * schlechte Lötstellen,
    * miese Batterien (z.B. Zink Kohle) vielleicht besser Alkaline AA Zellen mit entsprechendem Batteriefach verwenden,
    * bis hin zu Compiler Optimierungen die etwas wichtiges wegoptimieren (hatten wir in der Vergangenheit auch schon mal).

    Zumal es mit dem Original Hex File scheinbar problemlos funktioniert. Die Original Hex Files wurden mit WinAVR-2010 erstellt.

    Andere Idee, in irgendeinem alten Thread wurde bis zu 6x mal die Taster abgefragt und verglichen.

    Code:
    ---
    while(1)
    {
        t1 = PollSwitch();
        t2 = PollSwitch();
        t3 = PollSwitch();
        t4 = PollSwitch();
        t5 = PollSwitch();
        t6 = PollSwitch();
    if(t1 == 0 && t2 == 0 && t3 == 0 && t4 == 0 && t5 == 0 && t6 == 0)/* keine Taste */
    {
          MotorFwd();          /* vorwärts fahren */
          FrontLED(ON);
          BackLED(OFF,OFF);
    }
    elseif(t1 && t2 && t3 && t4 && t5 && t6 && t1 == t2 && t1 == t3 && t1 == t4  && t1 == t5  && t1 == t6)
    ...
    

    Geändert von m.a.r.v.i.n (18.07.2015 um 12:10 Uhr)

  4. #4
    Neuer Benutzer Öfters hier
    Registriert seit
    09.07.2015
    Beiträge
    7
    Hallo m.a.r.v.i.n,

    vielen Dank für deine Einschätzung.

    Als Compilier verwende ich WinAVR-20100110. Zumindest habe ich diese Version installiert und wenn ich es richtig verstehe gebe ich in der Makefile ja vor, das WinAVR als compilier verwendet wird und nicht die AVR Toolchain, die mit Atmel Studio mitinstalliert wurde.

    Als Batterien verwende ich wirklich sehr billige R03 AAA. Da ich aber sowieso auf Akkus umsteigen wollte habe ich jetzt ein 4x AA Bateriahalter mit hochwertigen NiMH-Akkus bestellt.

    Zudem habe ich den Ansatz, die Taster häufiger abzufragen, probiert und damit erfolg gehabt. Bei 6-facher Abfrage, reagiert er wie er soll, ohne "falsche Kollision". Darauf hin habe ich die Anzahl der Tastenabfragen schrittweise reduziert und jedesmal das Verhalten überprüft.
    Resultat:
    Mit 4-facher Abfrage läuft die Kollisionserkennung stabil. Bei 3-facher Abfrage gibt es noch vereinzelt "falsche Kollisionen".

    Ich verstehe jedoch immer noch nicht warum die vorkompilierte Version, die die Taster nur 2-fach abfragt, funktioniert und die selbst kompilierte 4-fach abfragen muss um das gleiche Resultat zu erzielen.
    Da ja in beiden Fällen die gleiche Hardware verwendet wird, müsste man diese als Fehlerquelle doch ausschliessen können!? (zumindest von meinem Verständnis als Roboter-Anfänger)

    Zumindest bin ich erstmal zufrieden, da ich jetzt mit der AsuroLib weiter programmieren kann.
    Dafür vielen Dank!

    Mfg Marph

    P.S. Bevor ich das Thema als erledigt markiere will ich noch mit den Akkus testen, ob dann eine 2-fache Abfrage ausreicht.

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


    Als Compilier verwende ich WinAVR-20100110. Zumindest habe ich diese Version installiert und wenn ich es richtig verstehe gebe ich in der Makefile ja vor, das WinAVR als compilier verwendet wird und nicht die AVR Toolchain, die mit Atmel Studio mitinstalliert wurde.

    das kann so nicht stimmen, aus den Log-Files entnehme ich GCC 4.8.1 als Compiler, WinAVR-1010 verwendet GCC 4.3.3.


    Leider finde ich den Thread nicht mehr, in dem die Pollswitch Abfrage auf 6 Abfragen erhöht wurde. Dort ließen sich vielleicht weitere Infos entnehmen. Mit 4xAA NiMH Zellen liegst du auf jeden Fall auf der sicheren Seite.

  6. #6
    Neuer Benutzer Öfters hier
    Registriert seit
    09.07.2015
    Beiträge
    7
    Mit etwas Verspätung hier nun mein Feedback.

    Nach dem Umbau auf 4xAA-NiMH-Stromversorgung läuft die Kollisionserkennung nun auch mit einer 3-fach-Abfrage zuverlässig.

    Auch die Compilier Version habe ich mir noch mal angesehen.
    Es gibt in den Projekt-Eigenschaften des Atmel Studio die Möglichkeit ein "Toolchain flavour" einzustellen, dort ist standardmäßig "Native" eingestellt, was wohl auf die AVR Toolchain verweißt und die GCC 4.8.1 Version erklärt.

    Mittels dieser Anleitung habe ich dann WinAVR eingebunden und ausgewählt, woraufhin mir im make-Log auch GCC 4.3.3 angezeigt wird.

    Obwohl ich etwas anderes erwartet habe, funktioniert der Code ,wenn ich ihn mit GCC 4.3.3 compiliere, leider wesentlich unzuverlässiger. Verwende ich GCC 4.8.1 läuft die Kollisionserkennung wie erwähnt mit 3-fach-Abfrage stabil. Verwende ich GCC 4.3.3 muss ich für die gleiche Zuverlässigkeit 5-fach abfragen.

    Grundsätzlich bin ich aber mit der Lösung des Problems zufrieden.
    Und da ich vor habe noch eine ganze Weile mit dem Asuro zu lernen, setze ich die Compiler-Geschichte auf meine ToDo-Liste und werde mich später noch in die Thematik einarbeiten. Vielleicht kommt dann auch das Verständnis für das beobachtete Verhalten unter zwei verschiedenen GCC Versionen.

    Mfg Marph

Ähnliche Themen

  1. Problem beim Einbinden von asuro.h / asuro.c
    Von Andi1888 im Forum Asuro
    Antworten: 8
    Letzter Beitrag: 06.03.2014, 17:09
  2. Antworten: 6
    Letzter Beitrag: 30.03.2013, 21:17
  3. Antworten: 18
    Letzter Beitrag: 06.05.2012, 18:40
  4. [Asuro] Problem: test.c und asuro.c compilieren
    Von Jonas Münch im Forum Asuro
    Antworten: 12
    Letzter Beitrag: 17.05.2010, 09:34
  5. Antworten: 2
    Letzter Beitrag: 26.06.2008, 12:32

Berechtigungen

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

MultiPlus Wechselrichter Insel und Nulleinspeisung Conrad