Techniker Miniprojekt 2011 Modell Kuka Roboterarm

[Staind]

Hallo,


Der aktuelle Stand ist so lala. Mein Kollege der muss ab Morgen für 1 Wochen ins Krankenhaus und ich habe zwar 2Wochen Ferien, in den ich hoffentlich viel schaffen werde aber irgendwie komme ich momentan nicht weiter.

Vorher lief ja alles mit ein Atmega8. Gestern Abend und Heute den ganzen Tag versuche ich den Atmega644 über UART anzusteuern und das klappt nicht so gut wie beim Atmega8...

Anfangs hatten wir Probleme Daten in den EEPROM des Atmega664 reinzuschreiben. Dabei haben wir das mySmartUSB Board MK2 Programmer benutzt. Es hat auch nicht geklappt. Liegt wohl an den Programmer. Haben dann über Ebay ein günstiges STK500 ersteigert und damit klappt es.

Habe heute geschafft das LCD Display anzusteuern und den Wert den ich über UART sende über das Display ausgeben lassen, aber dieses Funktioniert nicht. Ich Sende zwar über das C# Programm Daten zum uC, es kommen auch welche an, aber nicht die die ich gesendet habe.

Am C# Programm wird es wohl nicht liegen, da dieses mit den Atmega8 funktioniert hat.

Hoffe Ihr könnt uns ein paar Tipps geben.

Hier mal das uC Programm

#include <avr/io.h>
#include <inttypes.h>
#include "lcd-routines.h"

#define BAUD        9600UL
#define UBRR_BAUD   ((F_CPU/(16UL*BAUD))-1)

// USART initialisieren

void
uart_init(void)
{
    // Baudrate einstellen (Normaler Modus)
    UBRR0H = (uint8_t) (UBRR_BAUD>>8);
    UBRR0L = (uint8_t) (UBRR_BAUD & 0x0ff);

    // Aktivieren von receiver und transmitter
    UCSR0B = (1<<RXEN0)|(1<<TXEN0);

    // Einstellen des Datenformats: 8 Datenbits, 1 Stoppbit
    UCSR0C = (1<<UCSZ01)|(3<<UCSZ00);
}
main(void)
{
    
//-------------------------------------------------------------------------------------------
// Initialisierung 
//-------------------------------------------------------------------------------------------    
    
    uart_init();
    lcd_init();
    
// Variablen
    uint8_t buffer= 00;



    //TCCR1A = (1<<WGM11) | (1<<WGM10) | (1<<COM1A1);
    //TCCR1B = (0<<WGM13) | (1<<WGM12) | (1<<CS10) | (0<<CS11) | (0<<CS12);  
     
//-------------------------------------------------------------------------------------------
// Schleife
//-------------------------------------------------------------------------------------------    
        //Zeile 1
        lcd_setcursor( 0, 1) ;
        lcd_string("Hallo");
        //Zeile 2
        lcd_setcursor( 0, 2 );
        lcd_string("Bitte um Hilfe!");
        //Zeile 3
        lcd_setcursor( 20, 1 );
        lcd_string("UART funkt. nicht!");
        //Zeile 4
        lcd_setcursor( 20, 2 );
        lcd_data(UDR0);
        

    while (1) 
    {
    
         // Wenn Daten empfangen wurden dann...         
        if ( (UCSR0A & (1<<RXC0)) )
        {
        lcd_setcursor( 20, 2 );
         lcd_data(UDR0);
        }

        //sonst....
        else
        {
        
        }
    
    }
  return 0; // never reached 
}

Ich weiß dass er in der vierten Zeile nicht den Wert z. B. 102 schreibt, sondern diesen in ASCII Zeichen angibt, aber die könnte man ja vergleichen z.B. hier:
http://www.code-knacker.de/ascii.htm

Hier mal ein Bild:



Das STK500 benutze ich zum Programmieren und das mySmartUSB Board MK2 wird ist in den UART-USB-Bridge Modus. Angeschlossen ist ein 16MHz Quarzoszillator.

Momentan sieht es folgenermaßen aus:


Wenn ich das Programm darauf gespielt habe dann erscheint folgendes auf den Display



das Zeichen in der 4ten Zeile ist denk ich mal normal weil ja noch nichts wirkliches in UDR0 drinsteht.

Sende ich jetzt irgendeine Zahl (Byte)

dann sieht es so aus:



Folgende FuseBits sind gesetzt



hoffe Ihr könnt uns ein paar Tips geben!

Gruß André

[Staind]

^^ habe gerade den Fehler gefunden!
Es lag an den Fuse Bits. Entlich kann es weiter gehen.
Das Projekt wird auf jedenfall weitergeführt, will ja keine schlechte Zeugnisnote kassieren

[Staind]

So heute haben wir viel geschafft. UART läuft endlich mit den Atmega644, Display läuft, alle 6 PWM Ausgänge laufen auch erstmal.
Haben aber wieder ein weiteres Problemm, welches wir hier beschrieben haben:
https://www.roboternetz.de/community...017#post529017

hoffe Ihr könnt uns da ein wenig weiter helfen.

[radbruch]

Der Link funktioniert nicht.

...aber bei uns sind vorne im Greifelement zwei Servos, einen zum Greifen und einen, der den Greifkopf nochmal um 180° drehen kann...

Günstiger ist es natürlich, wenn das Gewicht möglichst innen liegt. Drehservo am Arm und Greiferservo an der Drehservoachse.

[Staind]

Der Link funktioniert nicht.

Günstiger ist es natürlich, wenn das Gewicht möglichst innen liegt. Drehservo am Arm und Greiferservo an der Drehservoachse.

So der Links sollte jetzt funktionieren.

Ja da haben Sie recht. Das es günstiger ist das Gewicht so weit wie möglich innen zu verlegen. Wir denken aber das die Servos das Gewicht packen

[Staind]

So heute kam endlich ein größeres Streckboard an.



Morgen kommt denke ich mal das erste Video wo der Roboterarm richtig was macht (hoffe ich zumindest mal).

[Geistesblitz]

Das wäre wirklich cool
Hast du das mit der PWM noch hinbekommen?

[Staind]

Hallo,

benutze bis jetzt die 8bit PWM-Variante. Mal schauen was noch so kommt.

Und ja ich habe nicht zu viel versprochen, nach ca 12 Stunden durch programmieren habe ich es geschafft ein halbwegs vernünftiges Programm auf den Beinen zu stellen. Klar gibt es an den massig noch zu verbessern, aber ich wollte erst mal gucken ob es läuft... und eigentlich läuft es super, trotz 8 Bit PWM und nur ca. 31 Schritten Verfahrensweg des Servos.

Aber schaut selbst (das versprochene Video)