2010-04-05T16:47:49Z

HannoHupmann: /* Master */

Programm für einen AVR mit [[TWI]] (Hardware-[[I2C]])-Schnittstelle als Slave.
Manchmal stellt sich die Aufgabe, mehrere AVRs per [[I2C]] zu vernetzen. Ein Beispiel ist die Erweiterung eines bestehenden Systems um einen leistungsstärkeren Controller. Dies ist etwa beim [[Asuro]] oder [[Yeti]] denkbar, um z.B. mehr Ein/Ausgänge oder Speicherplatz zu bekommen.

Man kann aber beim Bau eines Roboters auch von Anfang an auf ein System von mehreren vernetzten Controllern setzen. So kann man verschiedene Aufgabe, die weitgehend unabhängig voneinader gleichzeitg erledigt werden müssen, besser verteilen. Denkbar ist z.B. ein Controller für die Motorsteuerung, einer für die Sensorik, einer für Ein-und Ausgabe (wie LCD und Bedientaster),... , und ein zentraler Controller, der die Richtung vorgibt und alle anderen Controller mit Befehlen versorgt. Ein konkretes Beispiel ist der Roboterbausatz Nibo (siehe: [http://www.nicai-systems.de/nibo.html]) von nicai-systems, der einen Atmel ATmega128 als Hauptcontroller und zwei Atmel ATtiny44 als Controller für die Motorsteuerung und die IR-Sensorik einsetzt. Die Kommunikation läuft mit 400 kHz über den I2C-Bus mit dem ATmega128 als Master.

Schließlich kann ein entsprechend programmierter AVR auch als Ersatz für handelsübliche I2C-Bauteile dienen. Der kleinste AVR mit Hardware-I2C, der ATmega48, ist mit 1,30€ (Reichelt) billiger als viele normale I2C-ICs. Er kann bei entsprechender Programmierung z.B. die Aufgaben von zwei PCF8574 (8bit-Portexpander, 1,25€) und einem PCF8591 (4fach AD-Wandler, 2,35€) übernehmen und außerdem noch als I2C-EEPROM mit 256 Bytes dienen.

Das folgende Programm (twislave.c) steuert das TWI (Hardware-I2C)-Interface eines AVRs als Slave an. Es müsste auf allen AVRs der Mega-Reihe funktionieren, die über eine TWI-Schnittstelle verfügen.

Das System ist als eine Art Dualport-RAM konzipiert, Master und Slave teilen sich also einen Speicherbereich und können darüber Daten austauschen.

== Master ==
Ein Testprogramm für den Master. Es wird die [http://homepage.hispeed.ch/peterfleury/avr-software.html#libs I2C-Master-Bibliothek von Peter Fleury] verwendet.
Es wird geprüft, ob der Slave bereit ist, dann werden drei Bytes erst in den Slave geschrieben, und anschließend wieder ausgelesen.
<pre>

// I2C-Master-Routinen von Peter Fleury verwenden
// siehe http://homepage.hispeed.ch/peterfleury/avr-software.html#libs
// Hier sind auch die Datein: i2cmaster.h und twimaster.c zu finden, die benötigt werden
// (wer mit AVR-Studio arbeitet braucht nur diese Datein)
// Letztes Update des Codes 5. April 2010 durch HannoHupmann

#include <avr/io.h>
#include "i2cmaster.h"
#define SLAVE_ADRESSE 0x50

uint8_t byte1 = 42;
uint8_t byte2 = 43;
uint8_t byte3 = 44;

int main(void)
{
i2c_init(); // init I2C interface

if(!(i2c_start(SLAVE_ADRESSE+I2C_WRITE))) //Slave bereit zum schreiben?
{
i2c_write(0x00); // Buffer Startadresse setzen
i2c_write(byte1); // Drei Bytes schreiben...
i2c_write(byte2);
i2c_write(byte3);
i2c_stop(); // Zugriff beenden
}
else
{
/* Hier könnte eine Fehlermeldung ausgegeben werden... */
}

if(!(i2c_start(SLAVE_ADRESSE+I2C_WRITE))) //Slave bereit zum lesen?
{
i2c_write(0x00); //Buffer Startadresse zum Auslesen
i2c_rep_start(SLAVE_ADRESSE+I2C_READ); //Lesen beginnen

byte1= i2c_readAck(); // Bytes lesen...
byte2= i2c_readAck();
byte3= i2c_readNak(); // letztes Byte lesen, darum kein ACK
i2c_stop(); // Zugriff beenden
}
else
{
/* Hier könnte eine Fehlermeldung ausgegeben werden... */
}

if ((byte1 != 42)||(byte2 != 43)||(byte3 != 44))
{
/* Die Bytes wurden nicht korrekt übertragen und wieder gelesen! */
}
for(;;);
}

// Code wurde von mir getestet und funktioniert auf einem Mega32
</pre>

== Slave sourcecode ==
Die twislave.c für den Slave. Stand: 19.2.2010
<pre>

#include <util/twi.h> //enthält z.B. die Bezeichnungen für die Statuscodes in TWSR
#include <avr/interrupt.h> //dient zur Behandlung der Interrupts
#include <stdint.h> //definiert den Datentyp uint8_t
#include "twislave.h"

//%%%%%%%% Globale Variablen, die vom Hauptprogramm genutzt werden %%%%%%%%
/*Der Buffer, in dem die Daten gespeichert werden.
Aus Sicht des Masters läuft der Zugrif auf den Buffer genau wie bei einem I2C-EEPROm ab.
Für den Slave ist es eine globale Variable
*/
volatile uint8_t i2cdata[i2c_buffer_size+1];

volatile uint8_t buffer_adr; //"Adressregister" für den Buffer

/*Initaliserung des TWI-Inteface. Muss zu Beginn aufgerufen werden, sowie bei einem Wechsel der Slave Adresse
Parameter adr: gewünschte Slave-Adresse
*/
void init_twi_slave(uint8_t adr)
{
TWAR= adr; //Adresse setzen
TWCR &= ~(1<<TWSTA)|(1<<TWSTO);
TWCR|= (1<<TWEA) | (1<<TWEN)|(1<<TWIE);
buffer_adr=0xFF;
sei();
}

//Je nach Statuscode in TWSR müssen verschiedene Bitmuster in TWCR geschreiben werden(siehe Tabellen im Datenblatt!).
//Makros für die verwendeten Bitmuster:

//ACK nach empfangenen Daten senden/ ACK nach gesendeten Daten erwarten
#define TWCR_ACK TWCR = (1<<TWEN)|(1<<TWIE)|(1<<TWINT)|(1<<TWEA)|(0<<TWSTA)|(0<<TWSTO)|(0<<TWWC);

//NACK nach empfangenen Daten senden/ NACK nach gesendeten Daten erwarten
#define TWCR_NACK TWCR = (1<<TWEN)|(1<<TWIE)|(1<<TWINT)|(0<<TWEA)|(0<<TWSTA)|(0<<TWSTO)|(0<<TWWC);

//switched to the non adressed slave mode...
#define TWCR_RESET TWCR = (1<<TWEN)|(1<<TWIE)|(1<<TWINT)|(1<<TWEA)|(0<<TWSTA)|(0<<TWSTO)|(0<<TWWC);
//Die Bitmuster für TWCR_ACK und TWCR_RESET sind gleich. Dies ist kein Fehler und dient nur der Übersicht!

/*ISR, die bei einem Ereignis auf dem Bus ausgelöst wird. Im Register TWSR befindet sich dann
ein Statuscode, anhand dessen die Situation festgestellt werden kann.
*/
ISR (TWI_vect)
{
uint8_t data=0;

switch (TW_STATUS) //TWI-Statusregister prüfen und nötige Aktion bestimmen
{

// Slave Receiver

case TW_SR_SLA_ACK: // 0x60 Slave Receiver, Slave wurde adressiert
TWCR_ACK; // nächstes Datenbyte empfangen, ACK danach senden
buffer_adr=0xFF; //Bufferposition ist undefiniert
break;

case TW_SR_DATA_ACK: // 0x80 Slave Receiver, ein Datenbyte wurde empfangen
data=TWDR; //Empfangene Daten auslesen
if (buffer_adr == 0xFF) //erster Zugriff, Bufferposition setzen
{
//Kontrolle ob gewünschte Adresse im erlaubten bereich
if(data<i2c_buffer_size)
{
buffer_adr= data; //Bufferposition wie adressiert setzen
}
else
{
buffer_adr=0; //Adresse auf Null setzen. Ist das sinnvoll? TO DO!
}
TWCR_ACK; // nächstes Datenbyte empfangen, ACK danach, um nächstes Byte anzufordern
}
else //weiterer Zugriff, nachdem die Position im Buffer gesetzt wurde. NUn die Daten empfangen und speichern
{

if(buffer_adr<i2c_buffer_size)
{
if(!I2C_reg_Schreibschutz[buffer_adr]) //Wenn Position nicht schreibgeschützt...
i2cdata[buffer_adr]=data; //...dann Daten in Buffer schreibe

}
buffer_adr++; //Buffer-Adresse weiterzählen für nächsten Schreibzugriff
TWCR_ACK;
}
break;

//Slave transmitter

case TW_ST_SLA_ACK: //0xA8 Slave wurde im Lesemodus adressiert und hat ein ACK zurückgegeben.
//Hier steht kein break! Es wird also der folgende Code ebenfalls ausgeführt!

case TW_ST_DATA_ACK: //0xB8 Slave Transmitter, Daten wurden angefordert

if (buffer_adr == 0xFF) //zuvor keine Leseadresse angegeben!
{
buffer_adr=0;
}

if(buffer_adr<i2c_buffer_size)
{
TWDR = i2cdata[buffer_adr]; //Datenbyte senden
buffer_adr++; //bufferadresse für nächstes Byte weiterzählen
}
else
{
TWDR=0; //Kein Daten mehr im Buffer
}
TWCR_ACK;
break;

case TW_ST_DATA_NACK: // 0xC0 Keine Daten mehr gefordert
case TW_SR_DATA_NACK: // 0x88
case TW_ST_LAST_DATA: // 0xC8 Last data byte in TWDR has been transmitted (TWEA = “0”); ACK has been received
case TW_SR_STOP: // 0xA0 STOP empfangen
default:
TWCR_RESET;
break;

} //end.switch (TW_STATUS)
} //end.ISR(TWI_vect)

////Ende von twislave.c////

</pre>

== Slave header ==
Die zugehörige Headerdatei twislave.h für den Slave. Stand: 19.2.2010
<pre>

#ifndef _TWISLAVE_H
#define _TWISLAVE_H

#include <util/twi.h> //enthaelt z.B. die Bezeichnungen fuer die Statuscodes in TWSR
#include <avr/interrupt.h> //dient zur behandlung der Interrupts
#include <stdint.h> //definiert den Datentyp uint8_t

/**
* @defgroup twislave TWI-Slave
* @code #include "twislave.h" @endcode
*
* @brief Betrieb eines AVRs mit Hardware-TWI-Schnittstelle als Slave.
* Zu Beginn muss init_twi_slave mit der gewuenschten Slave-Adresse als
* Parameter aufgerufen werden.
*
* Der Datenaustausch mit dem Master erfolgt ueber den Buffer i2cdata,
* auf den von Master und Slave zugegriffen werden kann.
* Dies ist fuer den Slave eine globale Variable (Array aus uint8_t).

* Der Zugriff durch den Master erfolgt aehnlich wie bei einem
* normalen I2C-EEPROM.
* Man sendet zunaechst die Bufferposition, an die man schreiben will,
* und dann die Daten.
* Die Bufferposition wird automatisch hochgezaehlt, sodass man mehrere
* Datenbytes hintereinander schreiben kann, ohne jedesmal die
* Bufferadresse zu schreiben.
*
* Um vom Master aus zu lesen, uebertraegt man zunaechst in einem
* Schreibzugriff die gewuenschte Bufferposition und liest dann nach
* einem repeated start die Daten aus. Die Bufferposition wird
* automatisch hochgezaehlt, sodass man mehrere Datenbytes
* hintereinander lesen kann, ohne jedesmal die Bufferposition zu
* schreiben.
*
* Abgefangene Fehlbedienung durch den Master:
* - Lesen ueber die Grenze des txbuffers hinaus
* - Schreiben ueber die Grenzen des rxbuffers hinaus
* - Angabe einer ungueltigen Schreib/Lese-Adresse
* - Lesezugriff, ohne vorher Leseadresse geschrieben zu haben
*
* @author uwegw
*/

/*@{*/

//%%%%%%%% von Benutzer konfigurierbare Einstellungen %%%%%%%%
/**@brief Groesse des Buffers in Byte (2..254) */
#define i2c_buffer_size 8 //Beispiel: acht Register

//%%%%%%%% Globale Variablen, die vom Hauptprogramm genutzt werden %%%%%%%%
/**@brief Der Buffer, in dem die Daten gespeichert werden.
* Aus Sicht des Masters laeuft der Zugrif auf den Buffer genau wie
* bei einem I2C-EEPROm ab.
* Fuer den Slave ist es eine globale Variable
*/
volatile uint8_t i2cdata[i2c_buffer_size+1];

/**@brief Initaliserung des TWI-Inteface. Muss zu Beginn aufgerufen werden, sowie bei einem Wechsel der Slave Adresse
* @param adr gewuenschte Slave-Adresse */
void init_twi_slave(uint8_t adr);

//%%%%%%%% ab hier sind normalerweise keine weiteren Aenderungen erforderlich! %%%%%%%%//
//____________________________________________________________________________________//

//Bei zu alten AVR-GCC-Versionen werden die Interrupts anders genutzt, daher in diesem Fall mit Fehlermeldung abbrechen
#if (__GNUC__ * 100 + __GNUC_MINOR__) < 304
#error "This library requires AVR-GCC 3.4.5 or later, update to newer AVR-GCC compiler !"
#endif

//Schutz vor unsinnigen Buffergroessen
#if (i2c_buffer_size > 254)
#error Buffer zu gross gewaehlt! Maximal 254 Bytes erlaubt.
#endif

#if (i2c_buffer_size < 2)
#error Buffer muss mindestens zwei Byte gross sein!
#endif

/*@}*/

#endif //#ifdef _TWISLAVE_H
////Ende von twislave.h////

</pre>

== Slave Testprogramm ==
Ein Testprogramm für den Slave.
<pre>
/*
Testprogramm für die twislave.c
Der Buffer wird mit Werten gefüllt. Dann wird er fortlaufend über die serielle Schnittstelle ausgegeben.
*/

#include "twislave.h"
#include "uart.c"

#define BAUD 9600 //Baudrate
#define SLAVE_ADRESSE 0x50 //Die Slave-Adresse

//Funktion für Warteschaleifen
//Parameter: Wartezeit in Milisekunden
#include <util/delay.h>
void warte (int loop) //loop: wartezeit in ms
{
int i;
for(i=0;i<loop;i++) _delay_ms(1);
}

int main (void)
{
//TWI als Slave mit Adresse slaveadr starten
init_twi_slave(SLAVE_ADRESSE);

//i2cdatamit Werten füllen, die der Master auslesen und ändern kann
for(uint8_t i=0;i<buffer_size;i++)
{
i2cdata[i]=10+i;
}

//Serielle Schnittstelle aktivieren
uart_init((UART_BAUD_SELECT((BAUD),F_CPU)));
uart_puts("I2C-Test\r\n");
uart_puts("Teste I2C-Slave mit Adresse "); uart_puti(SLAVE_ADRESSE);
uart_puts("\r\n");
uart_puts("\r\n"); //Leerzeile

//in einer Endlosschleife den Inhalt der Buffer ausgeben
while(1)
{
uart_puts("i2cdata:\r\n");
for(uint8_t i=0;i<buffer_size;i++)
{
uart_puti(i2cdata[i]);
uart_puts("\r\n");
}
uart_puts("\r\n");//leerzeile
warte(500);
} //end.while
} //end.main
</pre>

[[Kategorie:Microcontroller]]
[[Kategorie:Quellcode C]]

TWI Slave mit avr-gcc

2010-04-05T16:47:03Z

HannoHupmann: /* Master */

Programm für einen AVR mit [[TWI]] (Hardware-[[I2C]])-Schnittstelle als Slave.
Manchmal stellt sich die Aufgabe, mehrere AVRs per [[I2C]] zu vernetzen. Ein Beispiel ist die Erweiterung eines bestehenden Systems um einen leistungsstärkeren Controller. Dies ist etwa beim [[Asuro]] oder [[Yeti]] denkbar, um z.B. mehr Ein/Ausgänge oder Speicherplatz zu bekommen.

Man kann aber beim Bau eines Roboters auch von Anfang an auf ein System von mehreren vernetzten Controllern setzen. So kann man verschiedene Aufgabe, die weitgehend unabhängig voneinader gleichzeitg erledigt werden müssen, besser verteilen. Denkbar ist z.B. ein Controller für die Motorsteuerung, einer für die Sensorik, einer für Ein-und Ausgabe (wie LCD und Bedientaster),... , und ein zentraler Controller, der die Richtung vorgibt und alle anderen Controller mit Befehlen versorgt. Ein konkretes Beispiel ist der Roboterbausatz Nibo (siehe: [http://www.nicai-systems.de/nibo.html]) von nicai-systems, der einen Atmel ATmega128 als Hauptcontroller und zwei Atmel ATtiny44 als Controller für die Motorsteuerung und die IR-Sensorik einsetzt. Die Kommunikation läuft mit 400 kHz über den I2C-Bus mit dem ATmega128 als Master.

Schließlich kann ein entsprechend programmierter AVR auch als Ersatz für handelsübliche I2C-Bauteile dienen. Der kleinste AVR mit Hardware-I2C, der ATmega48, ist mit 1,30€ (Reichelt) billiger als viele normale I2C-ICs. Er kann bei entsprechender Programmierung z.B. die Aufgaben von zwei PCF8574 (8bit-Portexpander, 1,25€) und einem PCF8591 (4fach AD-Wandler, 2,35€) übernehmen und außerdem noch als I2C-EEPROM mit 256 Bytes dienen.

Das folgende Programm (twislave.c) steuert das TWI (Hardware-I2C)-Interface eines AVRs als Slave an. Es müsste auf allen AVRs der Mega-Reihe funktionieren, die über eine TWI-Schnittstelle verfügen.

Das System ist als eine Art Dualport-RAM konzipiert, Master und Slave teilen sich also einen Speicherbereich und können darüber Daten austauschen.

== Master ==
Ein Codeschnipsel für den Master. Es wird die [http://homepage.hispeed.ch/peterfleury/avr-software.html#libs I2C-Master-Bibliothek von Peter Fleury] verwendet.
Es wird geprüft, ob der Slave bereit ist, dann werden drei Bytes erst in den Slave geschrieben, und anschließend wieder ausgelesen.
<pre>

// I2C-Master-Routinen von Peter Fleury verwenden
// siehe http://homepage.hispeed.ch/peterfleury/avr-software.html#libs
// Hier sind auch die Datein: i2cmaster.h und twimaster.c zu finden, die benötigt werden
// (wer mit AVR-Studio arbeitet braucht nur diese Datein)
// Letztes Update des Codes 5. April 2010 durch HannoHupmann

#include <avr/io.h>
#include "i2cmaster.h"
#define SLAVE_ADRESSE 0x50

uint8_t byte1 = 42;
uint8_t byte2 = 43;
uint8_t byte3 = 44;

int main(void)
{
i2c_init(); // init I2C interface

if(!(i2c_start(SLAVE_ADRESSE+I2C_WRITE))) //Slave bereit zum schreiben?
{
i2c_write(0x00); // Buffer Startadresse setzen
i2c_write(byte1); // Drei Bytes schreiben...
i2c_write(byte2);
i2c_write(byte3);
i2c_stop(); // Zugriff beenden
}
else
{
/* Hier könnte eine Fehlermeldung ausgegeben werden... */
}

if(!(i2c_start(SLAVE_ADRESSE+I2C_WRITE))) //Slave bereit zum lesen?
{
i2c_write(0x00); //Buffer Startadresse zum Auslesen
i2c_rep_start(SLAVE_ADRESSE+I2C_READ); //Lesen beginnen

byte1= i2c_readAck(); // Bytes lesen...
byte2= i2c_readAck();
byte3= i2c_readNak(); // letztes Byte lesen, darum kein ACK
i2c_stop(); // Zugriff beenden
}
else
{
/* Hier könnte eine Fehlermeldung ausgegeben werden... */
}

if ((byte1 != 42)||(byte2 != 43)||(byte3 != 44))
{
/* Die Bytes wurden nicht korrekt übertragen und wieder gelesen! */
}
for(;;);
}

// Code wurde von mir getestet und funktioniert auf einem Mega32
</pre>

== Slave sourcecode ==
Die twislave.c für den Slave. Stand: 19.2.2010
<pre>

#include <util/twi.h> //enthält z.B. die Bezeichnungen für die Statuscodes in TWSR
#include <avr/interrupt.h> //dient zur Behandlung der Interrupts
#include <stdint.h> //definiert den Datentyp uint8_t
#include "twislave.h"

//%%%%%%%% Globale Variablen, die vom Hauptprogramm genutzt werden %%%%%%%%
/*Der Buffer, in dem die Daten gespeichert werden.
Aus Sicht des Masters läuft der Zugrif auf den Buffer genau wie bei einem I2C-EEPROm ab.
Für den Slave ist es eine globale Variable
*/
volatile uint8_t i2cdata[i2c_buffer_size+1];

volatile uint8_t buffer_adr; //"Adressregister" für den Buffer

/*Initaliserung des TWI-Inteface. Muss zu Beginn aufgerufen werden, sowie bei einem Wechsel der Slave Adresse
Parameter adr: gewünschte Slave-Adresse
*/
void init_twi_slave(uint8_t adr)
{
TWAR= adr; //Adresse setzen
TWCR &= ~(1<<TWSTA)|(1<<TWSTO);
TWCR|= (1<<TWEA) | (1<<TWEN)|(1<<TWIE);
buffer_adr=0xFF;
sei();
}

//Je nach Statuscode in TWSR müssen verschiedene Bitmuster in TWCR geschreiben werden(siehe Tabellen im Datenblatt!).
//Makros für die verwendeten Bitmuster:

//ACK nach empfangenen Daten senden/ ACK nach gesendeten Daten erwarten
#define TWCR_ACK TWCR = (1<<TWEN)|(1<<TWIE)|(1<<TWINT)|(1<<TWEA)|(0<<TWSTA)|(0<<TWSTO)|(0<<TWWC);

//NACK nach empfangenen Daten senden/ NACK nach gesendeten Daten erwarten
#define TWCR_NACK TWCR = (1<<TWEN)|(1<<TWIE)|(1<<TWINT)|(0<<TWEA)|(0<<TWSTA)|(0<<TWSTO)|(0<<TWWC);

//switched to the non adressed slave mode...
#define TWCR_RESET TWCR = (1<<TWEN)|(1<<TWIE)|(1<<TWINT)|(1<<TWEA)|(0<<TWSTA)|(0<<TWSTO)|(0<<TWWC);
//Die Bitmuster für TWCR_ACK und TWCR_RESET sind gleich. Dies ist kein Fehler und dient nur der Übersicht!

/*ISR, die bei einem Ereignis auf dem Bus ausgelöst wird. Im Register TWSR befindet sich dann
ein Statuscode, anhand dessen die Situation festgestellt werden kann.
*/
ISR (TWI_vect)
{
uint8_t data=0;

switch (TW_STATUS) //TWI-Statusregister prüfen und nötige Aktion bestimmen
{

// Slave Receiver

case TW_SR_SLA_ACK: // 0x60 Slave Receiver, Slave wurde adressiert
TWCR_ACK; // nächstes Datenbyte empfangen, ACK danach senden
buffer_adr=0xFF; //Bufferposition ist undefiniert
break;

case TW_SR_DATA_ACK: // 0x80 Slave Receiver, ein Datenbyte wurde empfangen
data=TWDR; //Empfangene Daten auslesen
if (buffer_adr == 0xFF) //erster Zugriff, Bufferposition setzen
{
//Kontrolle ob gewünschte Adresse im erlaubten bereich
if(data<i2c_buffer_size)
{
buffer_adr= data; //Bufferposition wie adressiert setzen
}
else
{
buffer_adr=0; //Adresse auf Null setzen. Ist das sinnvoll? TO DO!
}
TWCR_ACK; // nächstes Datenbyte empfangen, ACK danach, um nächstes Byte anzufordern
}
else //weiterer Zugriff, nachdem die Position im Buffer gesetzt wurde. NUn die Daten empfangen und speichern
{

if(buffer_adr<i2c_buffer_size)
{
if(!I2C_reg_Schreibschutz[buffer_adr]) //Wenn Position nicht schreibgeschützt...
i2cdata[buffer_adr]=data; //...dann Daten in Buffer schreibe

}
buffer_adr++; //Buffer-Adresse weiterzählen für nächsten Schreibzugriff
TWCR_ACK;
}
break;

//Slave transmitter

case TW_ST_SLA_ACK: //0xA8 Slave wurde im Lesemodus adressiert und hat ein ACK zurückgegeben.
//Hier steht kein break! Es wird also der folgende Code ebenfalls ausgeführt!

case TW_ST_DATA_ACK: //0xB8 Slave Transmitter, Daten wurden angefordert

if (buffer_adr == 0xFF) //zuvor keine Leseadresse angegeben!
{
buffer_adr=0;
}

if(buffer_adr<i2c_buffer_size)
{
TWDR = i2cdata[buffer_adr]; //Datenbyte senden
buffer_adr++; //bufferadresse für nächstes Byte weiterzählen
}
else
{
TWDR=0; //Kein Daten mehr im Buffer
}
TWCR_ACK;
break;

case TW_ST_DATA_NACK: // 0xC0 Keine Daten mehr gefordert
case TW_SR_DATA_NACK: // 0x88
case TW_ST_LAST_DATA: // 0xC8 Last data byte in TWDR has been transmitted (TWEA = “0”); ACK has been received
case TW_SR_STOP: // 0xA0 STOP empfangen
default:
TWCR_RESET;
break;

} //end.switch (TW_STATUS)
} //end.ISR(TWI_vect)

////Ende von twislave.c////

</pre>

== Slave header ==
Die zugehörige Headerdatei twislave.h für den Slave. Stand: 19.2.2010
<pre>

#ifndef _TWISLAVE_H
#define _TWISLAVE_H

#include <util/twi.h> //enthaelt z.B. die Bezeichnungen fuer die Statuscodes in TWSR
#include <avr/interrupt.h> //dient zur behandlung der Interrupts
#include <stdint.h> //definiert den Datentyp uint8_t

/**
* @defgroup twislave TWI-Slave
* @code #include "twislave.h" @endcode
*
* @brief Betrieb eines AVRs mit Hardware-TWI-Schnittstelle als Slave.
* Zu Beginn muss init_twi_slave mit der gewuenschten Slave-Adresse als
* Parameter aufgerufen werden.
*
* Der Datenaustausch mit dem Master erfolgt ueber den Buffer i2cdata,
* auf den von Master und Slave zugegriffen werden kann.
* Dies ist fuer den Slave eine globale Variable (Array aus uint8_t).

* Der Zugriff durch den Master erfolgt aehnlich wie bei einem
* normalen I2C-EEPROM.
* Man sendet zunaechst die Bufferposition, an die man schreiben will,
* und dann die Daten.
* Die Bufferposition wird automatisch hochgezaehlt, sodass man mehrere
* Datenbytes hintereinander schreiben kann, ohne jedesmal die
* Bufferadresse zu schreiben.
*
* Um vom Master aus zu lesen, uebertraegt man zunaechst in einem
* Schreibzugriff die gewuenschte Bufferposition und liest dann nach
* einem repeated start die Daten aus. Die Bufferposition wird
* automatisch hochgezaehlt, sodass man mehrere Datenbytes
* hintereinander lesen kann, ohne jedesmal die Bufferposition zu
* schreiben.
*
* Abgefangene Fehlbedienung durch den Master:
* - Lesen ueber die Grenze des txbuffers hinaus
* - Schreiben ueber die Grenzen des rxbuffers hinaus
* - Angabe einer ungueltigen Schreib/Lese-Adresse
* - Lesezugriff, ohne vorher Leseadresse geschrieben zu haben
*
* @author uwegw
*/

/*@{*/

//%%%%%%%% von Benutzer konfigurierbare Einstellungen %%%%%%%%
/**@brief Groesse des Buffers in Byte (2..254) */
#define i2c_buffer_size 8 //Beispiel: acht Register

//%%%%%%%% Globale Variablen, die vom Hauptprogramm genutzt werden %%%%%%%%
/**@brief Der Buffer, in dem die Daten gespeichert werden.
* Aus Sicht des Masters laeuft der Zugrif auf den Buffer genau wie
* bei einem I2C-EEPROm ab.
* Fuer den Slave ist es eine globale Variable
*/
volatile uint8_t i2cdata[i2c_buffer_size+1];

/**@brief Initaliserung des TWI-Inteface. Muss zu Beginn aufgerufen werden, sowie bei einem Wechsel der Slave Adresse
* @param adr gewuenschte Slave-Adresse */
void init_twi_slave(uint8_t adr);

//%%%%%%%% ab hier sind normalerweise keine weiteren Aenderungen erforderlich! %%%%%%%%//
//____________________________________________________________________________________//

//Bei zu alten AVR-GCC-Versionen werden die Interrupts anders genutzt, daher in diesem Fall mit Fehlermeldung abbrechen
#if (__GNUC__ * 100 + __GNUC_MINOR__) < 304
#error "This library requires AVR-GCC 3.4.5 or later, update to newer AVR-GCC compiler !"
#endif

//Schutz vor unsinnigen Buffergroessen
#if (i2c_buffer_size > 254)
#error Buffer zu gross gewaehlt! Maximal 254 Bytes erlaubt.
#endif

#if (i2c_buffer_size < 2)
#error Buffer muss mindestens zwei Byte gross sein!
#endif

/*@}*/

#endif //#ifdef _TWISLAVE_H
////Ende von twislave.h////

</pre>

== Slave Testprogramm ==
Ein Testprogramm für den Slave.
<pre>
/*
Testprogramm für die twislave.c
Der Buffer wird mit Werten gefüllt. Dann wird er fortlaufend über die serielle Schnittstelle ausgegeben.
*/

#include "twislave.h"
#include "uart.c"

#define BAUD 9600 //Baudrate
#define SLAVE_ADRESSE 0x50 //Die Slave-Adresse

//Funktion für Warteschaleifen
//Parameter: Wartezeit in Milisekunden
#include <util/delay.h>
void warte (int loop) //loop: wartezeit in ms
{
int i;
for(i=0;i<loop;i++) _delay_ms(1);
}

int main (void)
{
//TWI als Slave mit Adresse slaveadr starten
init_twi_slave(SLAVE_ADRESSE);

//i2cdatamit Werten füllen, die der Master auslesen und ändern kann
for(uint8_t i=0;i<buffer_size;i++)
{
i2cdata[i]=10+i;
}

//Serielle Schnittstelle aktivieren
uart_init((UART_BAUD_SELECT((BAUD),F_CPU)));
uart_puts("I2C-Test\r\n");
uart_puts("Teste I2C-Slave mit Adresse "); uart_puti(SLAVE_ADRESSE);
uart_puts("\r\n");
uart_puts("\r\n"); //Leerzeile

//in einer Endlosschleife den Inhalt der Buffer ausgeben
while(1)
{
uart_puts("i2cdata:\r\n");
for(uint8_t i=0;i<buffer_size;i++)
{
uart_puti(i2cdata[i]);
uart_puts("\r\n");
}
uart_puts("\r\n");//leerzeile
warte(500);
} //end.while
} //end.main
</pre>

[[Kategorie:Microcontroller]]
[[Kategorie:Quellcode C]]

2007-02-18T20:31:35Z

HannoHupmann: Diskussion:Spinnenbeine wurde nach Diskussion:Spinnenbeine (Hexapods) verschoben: Da Spinnenbeine im Regelfall für Hexa, Poly und Quadropods verwendet werden und so Einsteigern der Einstieg erleidert wird.

#redirect [[Diskussion:Spinnenbeine (Hexapods)]]

Spinnenbeine (Hexapods)

2007-02-18T20:28:42Z

HannoHupmann: /* Ein Rechenbeispiel */

Spinnenbeine (Hexapods)

2006-09-15T08:17:34Z

HannoHupmann: /* Mit Bodenhaftung */

==Spinnenbeine, Hexapods, Quadropods und Polypods==

Wenn man sich erstmal nicht damit zufriedengibt, einfach mit den Beinen irgendwie herumzurudern ("Hauptsache, es bewegt sich"), sind Beinbewegungen gar nicht so ohne.

Schauen wir uns mal die häufigste Variante an, das sind die echsen- oder spinnenartigen Bauformen. Hauptmerkmal ist, dass die Beine seitlich am Körper angebracht sind.

Dabei können folgende Anordnungen und Beine unterschieden werden:
Die auf dem Bild gezeigte anordnung von 3 Beinen links so wie rechts ist die gängigste für Hexabots. Alternativ können die Beine auch in einem Sechseck angeordnet werden (siehe auch Bild weiter unten). Diese Anordnung hat den Vorteil, dass sie etwas wendiger ist, dies erkauft man sich durch eine etwas komplizierte Programmierung. Denn die Beinstellungen sind hier aufwendiger.

Roboter mit nur 4 Beinen werden gemeinhin als Quadropods bezeichnet.
Roboter mit mehr als 6 Beinen werden als Polypod bezeichnet.

==Ein Beinpaar im Querschnitt==
Das hier dargestellte Bein hat 3 Gelenke (jedoch sind nur 2 sichtbar). Einmal ein Gelenk an der Schulter und eines am Knie, das nicht sichtbare ist in der ansicht von Oben dafür verantwortlich das Bein vor und zurück zu bewegen.
Somit hat diese Bein 3 Freiheitsgrade (1x Knie, 1x Schulter (auf und ab) und 1x Schulter (vor zurück) dies wird oft auch als 3DOF (Degree of Freedom) bezeichnet.

[[Bild:Podlegside.jpg]]

(Die Beinhaltung ist hier ganz allgemein gehalten, tatsächlich sind da große Unterschiede, je nach Bauart.)
*Z ist die vertikale Drehachse des "Schulter"-Gelenks
*h ist die Höhe des Körpers über dem Boden
*a ist der Oberschenkel
*β der Winkel des Oberschenkels
*K ist das Knie
*b ist der Unterschenkel
*α der Winkel im Knie
*F ist der Fußpunkt
*γ der Winkel, den der Unterschenkel mit dem Boden einnimmt
*r ist der resultierende Radius des Fußpunktes um die Schulter
*M der Schwerpunkt unseres Roboters
*br der Abstand des Schwerpunkts bis zur Schulter

==Variante "Lynxmotion"==
[[Bild:Podlynx.jpg]]

Hier ist der Oberschenkel gewissermaßen geteilt. Der vertikal bewegliche Teil davon ist sehr kurz und als Parallelogramm ausgeführt, um den Unterschenkel senkrecht halten zu können. Dieser kann aktiv nur gehoben und gesenkt werden, durch Federn hat er aber ein gewisses seitliches Spiel.

Der Zweck dieser Konstruktion ist es, das Schultergelenk mit nur einem Freiheitsgrad sehr robust ausführen zu können.
Diese Variante der Beine hat also insgesammt nur 2 Freiheitsgrade (Schulter und heben, senken) und wird oft auch als DOF2 bezeichnet.

==Ein (linkes) Bein von oben==

[[Bild:Podlegtop.jpg]]

man findet die Werte aus der seitlichen Ansicht
*Z die vertikale Drehachse der Schulter (bleiben wir mal bei "Schulter")
*rmin als kleinstmöglicher Radius, den der Fußpunkt beschreiben kann (wenn der Unterschenkel maximal angezogen ist = kleines α)
*rmax als größtmöglicher Radius (= großes α)
*δmax das ist der größtmögliche Drehwinkel des Schultergelenks

schraffiert ist der Bereich, in dem sich die "Fußspitze" bewegen kann.

'''s''' ist somit die größtmögliche Schrittweite (bei gerader Fortbewegung)

und dann noch
*M ist der Schwerpunkt (oder Mittelpunkt) des gesamten Fahrzeuges
*br die halbe Breite
*f der Abstand dieses Beines von der Querachse

==Beinbewegung==
===Geradeaus===
Wird das Bein nun für einen Schritt von vorne nach hinten gedreht (durch Drehung des "Schulter"-Servos), würde sich die Fußspitze in einem Kreisbogen bewegen. Unterwegs würde allerdings die Fußspitze nach außen wegrutschen. Am schlimmsten daran ist der Verlust der Haftreibung, von der noch zu sprechen ist.

Das Bein muß also unterwegs so verkürzt werden, daß sich die Fußspitze entlang der geraden Sehne '''s''' bewegt. Und dann muss noch die Winkelgeschwindigkeit des Schultergelenks angepasst werden, da ja auch der Radius kontinuierlich verändert wird.
===In einer Kurve===
Um irgendein Fahrzeug in eine Kurve nach rechts zu bringen, kann man z.B. die Räder links schneller drehen lassen. Sowas geht bei Beinen natürlich nicht. Hier muß die Schrittweite variiert werden.
Und noch eine Tücke in der Kurve: Der Schreitweg '''s''' muss um den Kurvenradius-Mittelpunkt einen Bogen machen.

[[Bild:Podtopc.jpg]]

*P Kurven-Mittelpunkt
*M Fahrzeugmittelpunkt
*rfzgRadius des Fahrzeuges um P

==Anordnung der Beine==
===Hexapods===
[[Bild:Hextop1.jpg]]
[[Bild:Hextop2.jpg]]

das sind zwei Möglichkeiten, bei einem Hexpod die Beine anzuordnen. Die linke Variante hat den Vorteil, dass beim Geradeauslauf die Bewegungen der Beine identisch sein können, allerdings den Nachteil, dass der Rumpf länger sein muss (damit sich die Beine nicht in die Quere kommen). Die rechte Bauart hat diesen Nachteil nicht, aber dafür sind die erforderlichen Schrittbewegungen komplizierter.

==Schrittfolge==
Es ist ja klar, daß wir nicht alle sechs Beine gleichzeitig bewegen können. Man braucht also eine Schrittfolge.
Hier können mehrere Varianten unterschieden werden. Da ein Spinnenroboter 6 Beine hat und zum stehen 3 Stück (ein Dreieck bildend) ausreichen gibt es: 3:3. Wir können aber auch nur 2 Beine bewegen und 4 auf dem Boden stehen lassen also 2:4 oder alternativ nur ein Bein bewegen und mit den restlichen 5 auf dem Boden stehen, also 5:1. In Kurven ist das ganze noch etwas komplizierter daher beschäftigen wir uns als erstes mit:

===geradeaus 3:3===
Die folgende Methode wird gerne angewandt, weil sie recht einfach und auch rein mechanisch gemacht werden kann, allerdings ist die Belastung für die Servos bei dieser Variante am grössten, denn nur 3 Beine teilen sich das gesamte Gewicht des Roboters. Die Beine 1, 4 u. 5 bzw. 2, 3 u. 6 werden jeweils gleich angesteuert, phasenmäßig aber um 180 Grad versetzt.

Im linken Bild sind die Beine 2, 3 u. 6 gerade ganz vorne, die anderen Beine 1, 4 u. 5 ganz hinten

[[Bild:Podstp1.jpg]]
[[Bild:Podstp2.jpg]]

Im rechten Bild sind 2, 3 u. 6 mit ihrer Bewegung fertig, sie haben das Fahrzeug fortbewegt, jetzt kehrt sich die Sache um

'''Schwerpunkt ?'''

Unterstützt wird das ganze Gerät immer an den Fußpunkten der Beine. Verbindet man diese jeweils drei Punkte, ergeben sich zwei Dreiecke, die in den beiden Zeichnungen strichliert angedeutet sind. Teilweise überlappen sie sich, das ist der Bereich, wo sich der Schwerpunkt des ganzen Fahrzeuges befinden darf.

Und man sieht, dass diese Fläche bemerkenswert klein ist.

Für 3:3 laufen benötigt jedes Bein 2 Stellungen einmal vorn (A) und einmal hinten (B). Zuerst befinden sich die Beine 2,3 u 6 in Stellung A und werden auf dem Boden gleichzeitig in Stellung B bewegt. Dadurch schiebt sich der Roboter um das Stück A zu B nach vorn. Die Beine 1, 4 u 5 bewegen sich in der selben Zeit von Stellung B nach A, jedoch ohne Bodenkontakt. Wird nun diese Sequenz, im wechsel mit 1, 4 u 5 am Boden und 2, 3 u 6 in der Luft, zyklisch ausgeführt, hat man schon ein passables Laufprogramm für gerade aus.

===geradeaus 2:4===
Bei dieser Variante wird jeweils ein Beinpaar gleichzeitig bewegt. Diese sind günstigerweise:
1 und 4 (Paar 1); 3 und 6 (Paar 2); 2 und 5 (Paar 3)
Jedes Beinpaar benötigt jedoch 3 Stellungen: A, B, C. Der Algoritmus teilt sich daher auch in drei Schritte auf I, II und III.

Für Schritt I bringen wir Paar 1 in Stellung A, Paar 2 in Stellung C und Paar 3 in Stellung B.
Für Schritt II bewegt sich Paar 1 in Stellung B, Paar 2 in Stellung A (diese Bewegung muss ohne Bodenkontakt erfolgen) und Paar 3 in Stellung C.
Für Schritt III bewegt sich Paar 1 in Stellung C, Paar 2 in Stellung B und Paar 3 in Stellung A (auch wieder in der Luft)
Ab hier wiederholt sich das Programm

Fazit: Die Bewegungn sind etwas aufwendiger sich zu überlegen und zu programmieren, der Roboter gewinnt aber insgesammt an Stabilität und ist nur etwas langsamer als bei 3:3.

===geradeaus 1:5===
Diese Variante ist die langsamste, aber dafür am stabilsten, denn das Gewicht verteilt sich auf 5 Standbeine.
Es werden 6 Stellungen pro Bein benötigt (A, B, C, D, E, F) und 6 Schritte.
Es gibt mehrere Möglichkeiten der Startaufstellung ich will hier eine kurz Darstellen:
Bein 1: A -> B -> C usw. 
Bein 2: D -> E -> F 
Bein 3: E -> F --> A 
Bein 4: B -> C -> D 
Bein 5: C -> D -> E 
Bein 6: F --> A -> B 

Die Pfeile geben an in Welche Stellung sich die Beine als nächstes bewegen, Bein 6 wird sich in die Stellung A bewegen. Dieser Rückstellvorgang muss immer in der Luft erfolgen. So wird sich der Roboter kontinuierlich vorwärts bewegen.

==Hexapods in der Kurve==

Nochmals das Bild von oben

[[Bild:Hextop1.jpg]]

Die effektiven Beinwege '''s''' können auch wie die Räder von einem sechsrädrigen Fahrzeug verstanden werden.

Wenn wir nun eine Kurve beschreiben wollen, verkürzen wir die Wege '''s''' auf einer Seite, dadurch ergibt sich ein Drehpunkt '''P'''

[[Bild:Hexcurv1.jpg]]

Was man sieht: Es muss eigentlich jedes Bein eine individuelle Bewegung machen.
UND: jedes Bein muss seinen eigenen [[Spinnenbeine#Beinbewegung|Kurvenradius einhalten]]

===Hexapods drehen===
Alternativ, etwas einfacher zu programmieren, weil die Stellungen von Oben weiter verwendet werden können ist das Panzer Modell.
Konkret heisst es, die rechte Seite der Beine bewegt sich weiter nach oben, wärend die linke Seite der Beine sich nach unten bewegt. Dadurch wird der Roboter auf der Stelle gedreht. D.h. die Bewegungsrichtung der Beine ist insgesammt links zu rechts gegenläufig.

==Kräfte am Spinnenbein==
Da eine genaue Berechnung recht aufwendig ist und von vielen Faktoren zusätzlich stark beeinflusst wird (Dynamik und äußere Einflüsse), soll hier nur eine qualifizierende Betrachtung erfolgen.

Für Beine gibt es zwei völlig unterschiedliche Situationen:
===Ohne Bodenhaftung===
(Glatteis)
[[Bild:Podvec1.jpg]]

Die Beine werden auseinandergedrückt. Das Kniegelenk muß versuchen, Ober- und Unterschenkel beisammenzuhalten, und in der Schulter muss das anteilige Gewicht des Fahrzeuges getragen werden. Durch die langen Hebel wird da, je nach Beinstellung, eine beachtliche Kraft erforderlich.

===Mit Bodenhaftung===
(Teppich)
[[Bild:Podvec2.jpg]]

Ganz anders bei ausreichender Haftung: Da die Füße ja nicht wegrutschen, zieht das Gewicht des Fahrzeuges über die Oberschenkel die Knie nach innen. Hier müssen die Oberschenkel nach außen stemmen, um dem entgegenzuwirken.

''Bitte beachten, die Beine können auch günstiger als auf dem Bild dargestellt, eingerichtet werden. Wenn der Oberschenkel waagrecht zum Roboterkörper ist. Muss das Schultergelenk zwar das gesammte Gewicht des Roboters tragen, aber das Kniegelenk wird praktisch vollständig entlastet. Auch bei Eis als Untergrund würde ein Wegrutschen der Beine so verhindert werden. ''

====Ein Rechenbeispiel====
Des weiteren ist es wichtig zu erwähnen, dass je nach Bauart des Beines, also welche die sich weiter an der Seite vom Bot befinden, enorme Hebelkräfte auftreten. Um die passenden Servos für seinen Roboter heraus zu suchen hier ein Rechenbeispiel:

[[Bild:Beine65.jpg]]

Gegeben sei "a" als größtmöglicher Abstand zum Körper (blau).
Je nach Bauart des Roboters und der Wahl der Bewegung sind entweder 3 oder 4 oder gar 5 Beine gleichzeit am Boden. Auf diese wird das gesammte Gewicht des Roboter verteilt. Uns interessiert an dieser Stelle wieviel Ncm im Schultergelenk notwendig sind um den Roboter hochzudrücken. Aus der Zeichnung wird wieder deutlich warum es sinnvoll ist den Unterschenkel möglichst senkrecht zu halten und den Oberschenkel waagrecht. Unter dieser Positionierung muss das Kniegelenk nämlich kein Drehmoment übertragen.

Aber zurück zur Rechnung.

das Drehmoment in der Schulter wird wie folgt berechnet:
(Gewicht /Anzahl der Beine)* Hebelarm = Drehmoment in der Schulter

in unserem Beispielt
a=10cm; G=1kg=10N; 3Beine am Boden

(10N / 3)* 10cm = 33,3Ncm

Wir benötigen also in der Schulter Servos welche mindestens 33,3Ncm schaffen, zur Sicherheit wären 35Ncm sinnvoller.
Die Rechnung lässt sich natürlich auch so umstellen, dass anhand der Servos das Gesamtgewicht ermittelt werden kann:

(Drehmoment der Servos / Hebelarm)* Anzahl der Beine = Gewicht des Roboters

Dasselbe gilt natürlich auch für Quadropods. Nur muss man die Faktoren der Anzahl der Beine ändern

==Siehe auch==
* [[Servos]]

[[Kategorie:Mechanik]]
[[Kategorie:Praxis]]

[http://www.lynxmotion.com Lynxmotion, Referenz für Roboter mit Beinen]

Spinnenbeine (Hexapods)

2006-09-15T08:15:10Z

HannoHupmann: /* Spinnenbeine, Hexabots, Quadrobots und Polybots */

==Spinnenbeine, Hexapods, Quadropods und Polypods==

Wenn man sich erstmal nicht damit zufriedengibt, einfach mit den Beinen irgendwie herumzurudern ("Hauptsache, es bewegt sich"), sind Beinbewegungen gar nicht so ohne.

Schauen wir uns mal die häufigste Variante an, das sind die echsen- oder spinnenartigen Bauformen. Hauptmerkmal ist, dass die Beine seitlich am Körper angebracht sind.

Dabei können folgende Anordnungen und Beine unterschieden werden:
Die auf dem Bild gezeigte anordnung von 3 Beinen links so wie rechts ist die gängigste für Hexabots. Alternativ können die Beine auch in einem Sechseck angeordnet werden (siehe auch Bild weiter unten). Diese Anordnung hat den Vorteil, dass sie etwas wendiger ist, dies erkauft man sich durch eine etwas komplizierte Programmierung. Denn die Beinstellungen sind hier aufwendiger.

Roboter mit nur 4 Beinen werden gemeinhin als Quadropods bezeichnet.
Roboter mit mehr als 6 Beinen werden als Polypod bezeichnet.

==Ein Beinpaar im Querschnitt==
Das hier dargestellte Bein hat 3 Gelenke (jedoch sind nur 2 sichtbar). Einmal ein Gelenk an der Schulter und eines am Knie, das nicht sichtbare ist in der ansicht von Oben dafür verantwortlich das Bein vor und zurück zu bewegen.
Somit hat diese Bein 3 Freiheitsgrade (1x Knie, 1x Schulter (auf und ab) und 1x Schulter (vor zurück) dies wird oft auch als 3DOF (Degree of Freedom) bezeichnet.

[[Bild:Podlegside.jpg]]

(Die Beinhaltung ist hier ganz allgemein gehalten, tatsächlich sind da große Unterschiede, je nach Bauart.)
*Z ist die vertikale Drehachse des "Schulter"-Gelenks
*h ist die Höhe des Körpers über dem Boden
*a ist der Oberschenkel
*β der Winkel des Oberschenkels
*K ist das Knie
*b ist der Unterschenkel
*α der Winkel im Knie
*F ist der Fußpunkt
*γ der Winkel, den der Unterschenkel mit dem Boden einnimmt
*r ist der resultierende Radius des Fußpunktes um die Schulter
*M der Schwerpunkt unseres Roboters
*br der Abstand des Schwerpunkts bis zur Schulter

==Variante "Lynxmotion"==
[[Bild:Podlynx.jpg]]

Hier ist der Oberschenkel gewissermaßen geteilt. Der vertikal bewegliche Teil davon ist sehr kurz und als Parallelogramm ausgeführt, um den Unterschenkel senkrecht halten zu können. Dieser kann aktiv nur gehoben und gesenkt werden, durch Federn hat er aber ein gewisses seitliches Spiel.

Der Zweck dieser Konstruktion ist es, das Schultergelenk mit nur einem Freiheitsgrad sehr robust ausführen zu können.
Diese Variante der Beine hat also insgesammt nur 2 Freiheitsgrade (Schulter und heben, senken) und wird oft auch als DOF2 bezeichnet.

==Ein (linkes) Bein von oben==

[[Bild:Podlegtop.jpg]]

man findet die Werte aus der seitlichen Ansicht
*Z die vertikale Drehachse der Schulter (bleiben wir mal bei "Schulter")
*rmin als kleinstmöglicher Radius, den der Fußpunkt beschreiben kann (wenn der Unterschenkel maximal angezogen ist = kleines α)
*rmax als größtmöglicher Radius (= großes α)
*δmax das ist der größtmögliche Drehwinkel des Schultergelenks

schraffiert ist der Bereich, in dem sich die "Fußspitze" bewegen kann.

'''s''' ist somit die größtmögliche Schrittweite (bei gerader Fortbewegung)

und dann noch
*M ist der Schwerpunkt (oder Mittelpunkt) des gesamten Fahrzeuges
*br die halbe Breite
*f der Abstand dieses Beines von der Querachse

==Beinbewegung==
===Geradeaus===
Wird das Bein nun für einen Schritt von vorne nach hinten gedreht (durch Drehung des "Schulter"-Servos), würde sich die Fußspitze in einem Kreisbogen bewegen. Unterwegs würde allerdings die Fußspitze nach außen wegrutschen. Am schlimmsten daran ist der Verlust der Haftreibung, von der noch zu sprechen ist.

Das Bein muß also unterwegs so verkürzt werden, daß sich die Fußspitze entlang der geraden Sehne '''s''' bewegt. Und dann muss noch die Winkelgeschwindigkeit des Schultergelenks angepasst werden, da ja auch der Radius kontinuierlich verändert wird.
===In einer Kurve===
Um irgendein Fahrzeug in eine Kurve nach rechts zu bringen, kann man z.B. die Räder links schneller drehen lassen. Sowas geht bei Beinen natürlich nicht. Hier muß die Schrittweite variiert werden.
Und noch eine Tücke in der Kurve: Der Schreitweg '''s''' muss um den Kurvenradius-Mittelpunkt einen Bogen machen.

[[Bild:Podtopc.jpg]]

*P Kurven-Mittelpunkt
*M Fahrzeugmittelpunkt
*rfzgRadius des Fahrzeuges um P

==Anordnung der Beine==
===Hexapods===
[[Bild:Hextop1.jpg]]
[[Bild:Hextop2.jpg]]

das sind zwei Möglichkeiten, bei einem Hexpod die Beine anzuordnen. Die linke Variante hat den Vorteil, dass beim Geradeauslauf die Bewegungen der Beine identisch sein können, allerdings den Nachteil, dass der Rumpf länger sein muss (damit sich die Beine nicht in die Quere kommen). Die rechte Bauart hat diesen Nachteil nicht, aber dafür sind die erforderlichen Schrittbewegungen komplizierter.

==Schrittfolge==
Es ist ja klar, daß wir nicht alle sechs Beine gleichzeitig bewegen können. Man braucht also eine Schrittfolge.
Hier können mehrere Varianten unterschieden werden. Da ein Spinnenroboter 6 Beine hat und zum stehen 3 Stück (ein Dreieck bildend) ausreichen gibt es: 3:3. Wir können aber auch nur 2 Beine bewegen und 4 auf dem Boden stehen lassen also 2:4 oder alternativ nur ein Bein bewegen und mit den restlichen 5 auf dem Boden stehen, also 5:1. In Kurven ist das ganze noch etwas komplizierter daher beschäftigen wir uns als erstes mit:

===geradeaus 3:3===
Die folgende Methode wird gerne angewandt, weil sie recht einfach und auch rein mechanisch gemacht werden kann, allerdings ist die Belastung für die Servos bei dieser Variante am grössten, denn nur 3 Beine teilen sich das gesamte Gewicht des Roboters. Die Beine 1, 4 u. 5 bzw. 2, 3 u. 6 werden jeweils gleich angesteuert, phasenmäßig aber um 180 Grad versetzt.

Im linken Bild sind die Beine 2, 3 u. 6 gerade ganz vorne, die anderen Beine 1, 4 u. 5 ganz hinten

[[Bild:Podstp1.jpg]]
[[Bild:Podstp2.jpg]]

Im rechten Bild sind 2, 3 u. 6 mit ihrer Bewegung fertig, sie haben das Fahrzeug fortbewegt, jetzt kehrt sich die Sache um

'''Schwerpunkt ?'''

Unterstützt wird das ganze Gerät immer an den Fußpunkten der Beine. Verbindet man diese jeweils drei Punkte, ergeben sich zwei Dreiecke, die in den beiden Zeichnungen strichliert angedeutet sind. Teilweise überlappen sie sich, das ist der Bereich, wo sich der Schwerpunkt des ganzen Fahrzeuges befinden darf.

Und man sieht, dass diese Fläche bemerkenswert klein ist.

Für 3:3 laufen benötigt jedes Bein 2 Stellungen einmal vorn (A) und einmal hinten (B). Zuerst befinden sich die Beine 2,3 u 6 in Stellung A und werden auf dem Boden gleichzeitig in Stellung B bewegt. Dadurch schiebt sich der Roboter um das Stück A zu B nach vorn. Die Beine 1, 4 u 5 bewegen sich in der selben Zeit von Stellung B nach A, jedoch ohne Bodenkontakt. Wird nun diese Sequenz, im wechsel mit 1, 4 u 5 am Boden und 2, 3 u 6 in der Luft, zyklisch ausgeführt, hat man schon ein passables Laufprogramm für gerade aus.

===geradeaus 2:4===
Bei dieser Variante wird jeweils ein Beinpaar gleichzeitig bewegt. Diese sind günstigerweise:
1 und 4 (Paar 1); 3 und 6 (Paar 2); 2 und 5 (Paar 3)
Jedes Beinpaar benötigt jedoch 3 Stellungen: A, B, C. Der Algoritmus teilt sich daher auch in drei Schritte auf I, II und III.

Für Schritt I bringen wir Paar 1 in Stellung A, Paar 2 in Stellung C und Paar 3 in Stellung B.
Für Schritt II bewegt sich Paar 1 in Stellung B, Paar 2 in Stellung A (diese Bewegung muss ohne Bodenkontakt erfolgen) und Paar 3 in Stellung C.
Für Schritt III bewegt sich Paar 1 in Stellung C, Paar 2 in Stellung B und Paar 3 in Stellung A (auch wieder in der Luft)
Ab hier wiederholt sich das Programm

Fazit: Die Bewegungn sind etwas aufwendiger sich zu überlegen und zu programmieren, der Roboter gewinnt aber insgesammt an Stabilität und ist nur etwas langsamer als bei 3:3.

===geradeaus 1:5===
Diese Variante ist die langsamste, aber dafür am stabilsten, denn das Gewicht verteilt sich auf 5 Standbeine.
Es werden 6 Stellungen pro Bein benötigt (A, B, C, D, E, F) und 6 Schritte.
Es gibt mehrere Möglichkeiten der Startaufstellung ich will hier eine kurz Darstellen:
Bein 1: A -> B -> C usw. 
Bein 2: D -> E -> F 
Bein 3: E -> F --> A 
Bein 4: B -> C -> D 
Bein 5: C -> D -> E 
Bein 6: F --> A -> B 

Die Pfeile geben an in Welche Stellung sich die Beine als nächstes bewegen, Bein 6 wird sich in die Stellung A bewegen. Dieser Rückstellvorgang muss immer in der Luft erfolgen. So wird sich der Roboter kontinuierlich vorwärts bewegen.

==Hexapods in der Kurve==

Nochmals das Bild von oben

[[Bild:Hextop1.jpg]]

Die effektiven Beinwege '''s''' können auch wie die Räder von einem sechsrädrigen Fahrzeug verstanden werden.

Wenn wir nun eine Kurve beschreiben wollen, verkürzen wir die Wege '''s''' auf einer Seite, dadurch ergibt sich ein Drehpunkt '''P'''

[[Bild:Hexcurv1.jpg]]

Was man sieht: Es muss eigentlich jedes Bein eine individuelle Bewegung machen.
UND: jedes Bein muss seinen eigenen [[Spinnenbeine#Beinbewegung|Kurvenradius einhalten]]

===Hexapods drehen===
Alternativ, etwas einfacher zu programmieren, weil die Stellungen von Oben weiter verwendet werden können ist das Panzer Modell.
Konkret heisst es, die rechte Seite der Beine bewegt sich weiter nach oben, wärend die linke Seite der Beine sich nach unten bewegt. Dadurch wird der Roboter auf der Stelle gedreht. D.h. die Bewegungsrichtung der Beine ist insgesammt links zu rechts gegenläufig.

==Kräfte am Spinnenbein==
Da eine genaue Berechnung recht aufwendig ist und von vielen Faktoren zusätzlich stark beeinflusst wird (Dynamik und äußere Einflüsse), soll hier nur eine qualifizierende Betrachtung erfolgen.

Für Beine gibt es zwei völlig unterschiedliche Situationen:
===Ohne Bodenhaftung===
(Glatteis)
[[Bild:Podvec1.jpg]]

Die Beine werden auseinandergedrückt. Das Kniegelenk muß versuchen, Ober- und Unterschenkel beisammenzuhalten, und in der Schulter muss das anteilige Gewicht des Fahrzeuges getragen werden. Durch die langen Hebel wird da, je nach Beinstellung, eine beachtliche Kraft erforderlich.

===Mit Bodenhaftung===
(Teppich)
[[Bild:Podvec2.jpg]]

Ganz anders bei ausreichender Haftung: Da die Füße ja nicht wegrutschen, zieht das Gewicht des Fahrzeuges über die Oberschenkel die Knie nach innen. Hier müssen die Oberschenkel nach außen stemmen, um dem entgegenzuwirken.

''TextBitte beachten, die Beine können auch günstiger als auf dem Bild dargestellt, eingerichtet werden. Wenn der Oberschenkel waagrecht zum Roboterkörper ist. Muss das Schultergelenk zwar das gesammte Gewicht des Roboters tragen, aber das Kniegelenk wird praktisch vollständig entlastet. Auch bei Eis als Untergrund würde ein Wegrutschen der Beine so verhindert werden. ''

====Ein Rechenbeispiel====
Des weiteren ist es wichtig zu erwähnen, dass je nach Bauart des Beines, also welche die sich weiter an der Seite vom Bot befinden, enorme Hebelkräfte auftreten. Um die passenden Servos für seinen Roboter heraus zu suchen hier ein Rechenbeispiel:

[[Bild:Beine65.jpg]]

Gegeben sei "a" als größtmöglicher Abstand zum Körper (blau).
Je nach Bauart des Roboters und der Wahl der Bewegung sind entweder 3 oder 4 oder gar 5 Beine gleichzeit am Boden. Auf diese wird das gesammte Gewicht des Roboter verteilt. Uns interessiert an dieser Stelle wieviel Ncm im Schultergelenk notwendig sind um den Roboter hochzudrücken. Aus der Zeichnung wird wieder deutlich warum es sinnvoll ist den Unterschenkel möglichst senkrecht zu halten und den Oberschenkel waagrecht. Unter dieser Positionierung muss das Kniegelenk nämlich kein Drehmoment übertragen.

Aber zurück zur Rechnung.

das Drehmoment in der Schulter wird wie folgt berechnet:
(Gewicht /Anzahl der Beine)* Hebelarm = Drehmoment in der Schulter

in unserem Beispielt
a=10cm; G=1kg=10N; 3Beine am Boden

(10N / 3)* 10cm = 33,3Ncm

Wir benötigen also in der Schulter Servos welche mindestens 33,3Ncm schaffen, zur Sicherheit wären 35Ncm sinnvoller.
Die Rechnung lässt sich natürlich auch so umstellen, dass anhand der Servos das Gesamtgewicht ermittelt werden kann:

(Drehmoment der Servos / Hebelarm)* Anzahl der Beine = Gewicht des Roboters

Dasselbe gilt natürlich auch für Quadrobots. Nur muss man die Faktoren der Anzahl der Beine ändern

==Siehe auch==
* [[Servos]]

[[Kategorie:Mechanik]]
[[Kategorie:Praxis]]

[http://www.lynxmotion.com Lynxmotion, Referenz für Roboter mit Beinen]

Spinnenbeine (Hexapods)

2006-09-14T17:18:55Z

HannoHupmann: /* Siehe auch */

==Spinnenbeine, Hexabots, Quadrobots und Polybots==

Wenn man sich erstmal nicht damit zufriedengibt, einfach mit den Beinen irgendwie herumzurudern ("Hauptsache, es bewegt sich"), sind Beinbewegungen gar nicht so ohne.

Schauen wir uns mal die häufigste Variante an, das sind die echsen- oder spinnenartigen Bauformen. Hauptmerkmal ist, dass die Beine seitlich am Körper angebracht sind.

Dabei können folgende Anordnungen und Beine unterschieden werden:
Die auf dem Bild gezeigte anordnung von 3 Beinen links so wie rechts ist die gängigste für Hexabots. Alternativ können die Beine auch in einem Sechseck angeordnet werden (siehe auch Bild weiter unten). Diese Anordnung hat den Vorteil, dass sie etwas wendiger ist, dies erkauft man sich durch eine etwas komplizierte Programmierung. Denn die Beinstellungen sind hier aufwendiger.

Roboter mit nur 4 Beinen werden gemeinhin als Quadrobots bezeichnet.
Roboter mit mehr als 6 Beinen werden als Polybot bezeichnet.

==Ein Beinpaar im Querschnitt==
Das hier dargestellte Bein hat 3 Gelenke (jedoch sind nur 2 sichtbar). Einmal ein Gelenk an der Schulter und eines am Knie, das nicht sichtbare ist in der ansicht von Oben dafür verantwortlich das Bein vor und zurück zu bewegen.
Somit hat diese Bein 3 Freiheitsgrade (1x Knie, 1x Schulter (auf und ab) und 1x Schulter (vor zurück) dies wird oft auch als 3DOF (Degree of Freedom) bezeichnet.

[[Bild:Podlegside.jpg]]

(Die Beinhaltung ist hier ganz allgemein gehalten, tatsächlich sind da große Unterschiede, je nach Bauart.)
*Z ist die vertikale Drehachse des "Schulter"-Gelenks
*h ist die Höhe des Körpers über dem Boden
*a ist der Oberschenkel
*β der Winkel des Oberschenkels
*K ist das Knie
*b ist der Unterschenkel
*α der Winkel im Knie
*F ist der Fußpunkt
*γ der Winkel, den der Unterschenkel mit dem Boden einnimmt
*r ist der resultierende Radius des Fußpunktes um die Schulter
*M der Schwerpunkt unseres Roboters
*br der Abstand des Schwerpunkts bis zur Schulter

==Variante "Lynxmotion"==
[[Bild:Podlynx.jpg]]

Hier ist der Oberschenkel gewissermaßen geteilt. Der vertikal bewegliche Teil davon ist sehr kurz und als Parallelogramm ausgeführt, um den Unterschenkel senkrecht halten zu können. Dieser kann aktiv nur gehoben und gesenkt werden, durch Federn hat er aber ein gewisses seitliches Spiel.

Der Zweck dieser Konstruktion ist es, das Schultergelenk mit nur einem Freiheitsgrad sehr robust ausführen zu können.
Diese Variante der Beine hat also insgesammt nur 2 Freiheitsgrade (Schulter und heben, senken) und wird oft auch als DOF2 bezeichnet.

==Ein (linkes) Bein von oben==

[[Bild:Podlegtop.jpg]]

man findet die Werte aus der seitlichen Ansicht
*Z die vertikale Drehachse der Schulter (bleiben wir mal bei "Schulter")
*rmin als kleinstmöglicher Radius, den der Fußpunkt beschreiben kann (wenn der Unterschenkel maximal angezogen ist = kleines α)
*rmax als größtmöglicher Radius (= großes α)
*δmax das ist der größtmögliche Drehwinkel des Schultergelenks

schraffiert ist der Bereich, in dem sich die "Fußspitze" bewegen kann.

'''s''' ist somit die größtmögliche Schrittweite (bei gerader Fortbewegung)

und dann noch
*M ist der Schwerpunkt (oder Mittelpunkt) des gesamten Fahrzeuges
*br die halbe Breite
*f der Abstand dieses Beines von der Querachse

==Beinbewegung==
===Geradeaus===
Wird das Bein nun für einen Schritt von vorne nach hinten gedreht (durch Drehung des "Schulter"-Servos), würde sich die Fußspitze in einem Kreisbogen bewegen. Unterwegs würde allerdings die Fußspitze nach außen wegrutschen. Am schlimmsten daran ist der Verlust der Haftreibung, von der noch zu sprechen ist.

Das Bein muß also unterwegs so verkürzt werden, daß sich die Fußspitze entlang der geraden Sehne '''s''' bewegt. Und dann muss noch die Winkelgeschwindigkeit des Schultergelenks angepasst werden, da ja auch der Radius kontinuierlich verändert wird.
===In einer Kurve===
Um irgendein Fahrzeug in eine Kurve nach rechts zu bringen, kann man z.B. die Räder links schneller drehen lassen. Sowas geht bei Beinen natürlich nicht. Hier muß die Schrittweite variiert werden.
Und noch eine Tücke in der Kurve: Der Schreitweg '''s''' muss um den Kurvenradius-Mittelpunkt einen Bogen machen.

[[Bild:Podtopc.jpg]]

*P Kurven-Mittelpunkt
*M Fahrzeugmittelpunkt
*rfzgRadius des Fahrzeuges um P

==Anordnung der Beine==
===Hexapods===
[[Bild:Hextop1.jpg]]
[[Bild:Hextop2.jpg]]

das sind zwei Möglichkeiten, bei einem Hexpod die Beine anzuordnen. Die linke Variante hat den Vorteil, dass beim Geradeauslauf die Bewegungen der Beine identisch sein können, allerdings den Nachteil, dass der Rumpf länger sein muss (damit sich die Beine nicht in die Quere kommen). Die rechte Bauart hat diesen Nachteil nicht, aber dafür sind die erforderlichen Schrittbewegungen komplizierter.

==Schrittfolge==
Es ist ja klar, daß wir nicht alle sechs Beine gleichzeitig bewegen können. Man braucht also eine Schrittfolge.
Hier können mehrere Varianten unterschieden werden. Da ein Spinnenroboter 6 Beine hat und zum stehen 3 Stück (ein Dreieck bildend) ausreichen gibt es: 3:3. Wir können aber auch nur 2 Beine bewegen und 4 auf dem Boden stehen lassen also 2:4 oder alternativ nur ein Bein bewegen und mit den restlichen 5 auf dem Boden stehen, also 5:1. In Kurven ist das ganze noch etwas komplizierter daher beschäftigen wir uns als erstes mit:

===geradeaus 3:3===
Die folgende Methode wird gerne angewandt, weil sie recht einfach und auch rein mechanisch gemacht werden kann, allerdings ist die Belastung für die Servos bei dieser Variante am grössten, denn nur 3 Beine teilen sich das gesamte Gewicht des Roboters. Die Beine 1, 4 u. 5 bzw. 2, 3 u. 6 werden jeweils gleich angesteuert, phasenmäßig aber um 180 Grad versetzt.

Im linken Bild sind die Beine 2, 3 u. 6 gerade ganz vorne, die anderen Beine 1, 4 u. 5 ganz hinten

[[Bild:Podstp1.jpg]]
[[Bild:Podstp2.jpg]]

Im rechten Bild sind 2, 3 u. 6 mit ihrer Bewegung fertig, sie haben das Fahrzeug fortbewegt, jetzt kehrt sich die Sache um

'''Schwerpunkt ?'''

Unterstützt wird das ganze Gerät immer an den Fußpunkten der Beine. Verbindet man diese jeweils drei Punkte, ergeben sich zwei Dreiecke, die in den beiden Zeichnungen strichliert angedeutet sind. Teilweise überlappen sie sich, das ist der Bereich, wo sich der Schwerpunkt des ganzen Fahrzeuges befinden darf.

Und man sieht, dass diese Fläche bemerkenswert klein ist.

Für 3:3 laufen benötigt jedes Bein 2 Stellungen einmal vorn (A) und einmal hinten (B). Zuerst befinden sich die Beine 2,3 u 6 in Stellung A und werden auf dem Boden gleichzeitig in Stellung B bewegt. Dadurch schiebt sich der Roboter um das Stück A zu B nach vorn. Die Beine 1, 4 u 5 bewegen sich in der selben Zeit von Stellung B nach A, jedoch ohne Bodenkontakt. Wird nun diese Sequenz, im wechsel mit 1, 4 u 5 am Boden und 2, 3 u 6 in der Luft, zyklisch ausgeführt, hat man schon ein passables Laufprogramm für gerade aus.

===geradeaus 2:4===
Bei dieser Variante wird jeweils ein Beinpaar gleichzeitig bewegt. Diese sind günstigerweise:
1 und 4 (Paar 1); 3 und 6 (Paar 2); 2 und 5 (Paar 3)
Jedes Beinpaar benötigt jedoch 3 Stellungen: A, B, C. Der Algoritmus teilt sich daher auch in drei Schritte auf I, II und III.

Für Schritt I bringen wir Paar 1 in Stellung A, Paar 2 in Stellung C und Paar 3 in Stellung B.
Für Schritt II bewegt sich Paar 1 in Stellung B, Paar 2 in Stellung A (diese Bewegung muss ohne Bodenkontakt erfolgen) und Paar 3 in Stellung C.
Für Schritt III bewegt sich Paar 1 in Stellung C, Paar 2 in Stellung B und Paar 3 in Stellung A (auch wieder in der Luft)
Ab hier wiederholt sich das Programm

Fazit: Die Bewegungn sind etwas aufwendiger sich zu überlegen und zu programmieren, der Roboter gewinnt aber insgesammt an Stabilität und ist nur etwas langsamer als bei 3:3.

===geradeaus 1:5===
Diese Variante ist die langsamste, aber dafür am stabilsten, denn das Gewicht verteilt sich auf 5 Standbeine.
Es werden 6 Stellungen pro Bein benötigt (A, B, C, D, E, F) und 6 Schritte.
Es gibt mehrere Möglichkeiten der Startaufstellung ich will hier eine kurz Darstellen:
Bein 1: A -> B -> C usw. 
Bein 2: D -> E -> F 
Bein 3: E -> F --> A 
Bein 4: B -> C -> D 
Bein 5: C -> D -> E 
Bein 6: F --> A -> B 

Die Pfeile geben an in Welche Stellung sich die Beine als nächstes bewegen, Bein 6 wird sich in die Stellung A bewegen. Dieser Rückstellvorgang muss immer in der Luft erfolgen. So wird sich der Roboter kontinuierlich vorwärts bewegen.

==Hexapods in der Kurve==

Nochmals das Bild von oben

[[Bild:Hextop1.jpg]]

Die effektiven Beinwege '''s''' können auch wie die Räder von einem sechsrädrigen Fahrzeug verstanden werden.

Wenn wir nun eine Kurve beschreiben wollen, verkürzen wir die Wege '''s''' auf einer Seite, dadurch ergibt sich ein Drehpunkt '''P'''

[[Bild:Hexcurv1.jpg]]

Was man sieht: Es muss eigentlich jedes Bein eine individuelle Bewegung machen.
UND: jedes Bein muss seinen eigenen [[Spinnenbeine#Beinbewegung|Kurvenradius einhalten]]

===Hexapods drehen===
Alternativ, etwas einfacher zu programmieren, weil die Stellungen von Oben weiter verwendet werden können ist das Panzer Modell.
Konkret heisst es, die rechte Seite der Beine bewegt sich weiter nach oben, wärend die linke Seite der Beine sich nach unten bewegt. Dadurch wird der Roboter auf der Stelle gedreht. D.h. die Bewegungsrichtung der Beine ist insgesammt links zu rechts gegenläufig.

==Kräfte am Spinnenbein==
Da eine genaue Berechnung recht aufwendig ist und von vielen Faktoren zusätzlich stark beeinflusst wird (Dynamik und äußere Einflüsse), soll hier nur eine qualifizierende Betrachtung erfolgen.

Für Beine gibt es zwei völlig unterschiedliche Situationen:
===Ohne Bodenhaftung===
(Glatteis)
[[Bild:Podvec1.jpg]]

Die Beine werden auseinandergedrückt. Das Kniegelenk muß versuchen, Ober- und Unterschenkel beisammenzuhalten, und in der Schulter muss das anteilige Gewicht des Fahrzeuges getragen werden. Durch die langen Hebel wird da, je nach Beinstellung, eine beachtliche Kraft erforderlich.

===Mit Bodenhaftung===
(Teppich)
[[Bild:Podvec2.jpg]]

Ganz anders bei ausreichender Haftung: Da die Füße ja nicht wegrutschen, zieht das Gewicht des Fahrzeuges über die Oberschenkel die Knie nach innen. Hier müssen die Oberschenkel nach außen stemmen, um dem entgegenzuwirken.

''TextBitte beachten, die Beine können auch günstiger als auf dem Bild dargestellt, eingerichtet werden. Wenn der Oberschenkel waagrecht zum Roboterkörper ist. Muss das Schultergelenk zwar das gesammte Gewicht des Roboters tragen, aber das Kniegelenk wird praktisch vollständig entlastet. Auch bei Eis als Untergrund würde ein Wegrutschen der Beine so verhindert werden. ''

====Ein Rechenbeispiel====
Des weiteren ist es wichtig zu erwähnen, dass je nach Bauart des Beines, also welche die sich weiter an der Seite vom Bot befinden, enorme Hebelkräfte auftreten. Um die passenden Servos für seinen Roboter heraus zu suchen hier ein Rechenbeispiel:

[[Bild:Beine65.jpg]]

Gegeben sei "a" als größtmöglicher Abstand zum Körper (blau).
Je nach Bauart des Roboters und der Wahl der Bewegung sind entweder 3 oder 4 oder gar 5 Beine gleichzeit am Boden. Auf diese wird das gesammte Gewicht des Roboter verteilt. Uns interessiert an dieser Stelle wieviel Ncm im Schultergelenk notwendig sind um den Roboter hochzudrücken. Aus der Zeichnung wird wieder deutlich warum es sinnvoll ist den Unterschenkel möglichst senkrecht zu halten und den Oberschenkel waagrecht. Unter dieser Positionierung muss das Kniegelenk nämlich kein Drehmoment übertragen.

Aber zurück zur Rechnung.

das Drehmoment in der Schulter wird wie folgt berechnet:
(Gewicht /Anzahl der Beine)* Hebelarm = Drehmoment in der Schulter

in unserem Beispielt
a=10cm; G=1kg=10N; 3Beine am Boden

(10N / 3)* 10cm = 33,3Ncm

Wir benötigen also in der Schulter Servos welche mindestens 33,3Ncm schaffen, zur Sicherheit wären 35Ncm sinnvoller.
Die Rechnung lässt sich natürlich auch so umstellen, dass anhand der Servos das Gesamtgewicht ermittelt werden kann:

(Drehmoment der Servos / Hebelarm)* Anzahl der Beine = Gewicht des Roboters

Dasselbe gilt natürlich auch für Quadrobots. Nur muss man die Faktoren der Anzahl der Beine ändern

==Siehe auch==
* [[Servos]]

[[Kategorie:Mechanik]]
[[Kategorie:Praxis]]

[http://www.lynxmotion.com Lynxmotion, Referenz für Roboter mit Beinen]

Spinnenbeine (Hexapods)

2006-09-14T17:16:53Z

HannoHupmann:

Spinnenbeine (Hexapods)

2006-09-14T17:11:26Z

HannoHupmann: /* Ein Rechenbeispiel */

==Spinnenbeine==

Wenn man sich erstmal nicht damit zufriedengibt, einfach mit den Beinen irgendwie herumzurudern ("Hauptsache, es bewegt sich"), sind Beinbewegungen gar nicht so ohne.

Schauen wir uns mal die häufigste Variante an, das sind die echsen- oder spinnenartigen Bauformen. Hauptmerkmal ist, dass die Beine seitlich am Körper angebracht sind.

Dabei können folgende Anordnungen und Beine unterschieden werden:
Die auf dem Bild gezeigte anordnung von 3 Beinen links so wie rechts ist die gängigste für Hexabots. Alternativ können die Beine auch in einem Sechseck angeordnet werden (siehe auch Bild weiter unten). Diese Anordnung hat den Vorteil, dass sie etwas wendiger ist, dies erkauft man sich durch eine etwas komplizierte Programmierung. Denn die Beinstellungen sind hier aufwendiger.

Roboter mit nur 4 Beinen werden gemeinhin als Quadrobots bezeichnet.
Roboter mit mehr als 6 Beinen werden als Polybot bezeichnet.

==Ein Beinpaar im Querschnitt==
Das hier dargestellte Bein hat 3 Gelenke (jedoch sind nur 2 sichtbar). Einmal ein Gelenk an der Schulter und eines am Knie, das nicht sichtbare ist in der ansicht von Oben dafür verantwortlich das Bein vor und zurück zu bewegen.
Somit hat diese Bein 3 Freiheitsgrade (1x Knie, 1x Schulter (auf und ab) und 1x Schulter (vor zurück) dies wird oft auch als 3DOF (Degree of Freedom) bezeichnet.

[[Bild:Podlegside.jpg]]

(Die Beinhaltung ist hier ganz allgemein gehalten, tatsächlich sind da große Unterschiede, je nach Bauart.)
*Z ist die vertikale Drehachse des "Schulter"-Gelenks
*h ist die Höhe des Körpers über dem Boden
*a ist der Oberschenkel
*β der Winkel des Oberschenkels
*K ist das Knie
*b ist der Unterschenkel
*α der Winkel im Knie
*F ist der Fußpunkt
*γ der Winkel, den der Unterschenkel mit dem Boden einnimmt
*r ist der resultierende Radius des Fußpunktes um die Schulter
*M der Schwerpunkt unseres Roboters
*br der Abstand des Schwerpunkts bis zur Schulter

==Variante "Lynxmotion"==
[[Bild:Podlynx.jpg]]

Hier ist der Oberschenkel gewissermaßen geteilt. Der vertikal bewegliche Teil davon ist sehr kurz und als Parallelogramm ausgeführt, um den Unterschenkel senkrecht halten zu können. Dieser kann aktiv nur gehoben und gesenkt werden, durch Federn hat er aber ein gewisses seitliches Spiel.

Der Zweck dieser Konstruktion ist es, das Schultergelenk mit nur einem Freiheitsgrad sehr robust ausführen zu können.
Diese Variante der Beine hat also insgesammt nur 2 Freiheitsgrade (Schulter und heben, senken) und wird oft auch als DOF2 bezeichnet.

==Ein (linkes) Bein von oben==

[[Bild:Podlegtop.jpg]]

man findet die Werte aus der seitlichen Ansicht
*Z die vertikale Drehachse der Schulter (bleiben wir mal bei "Schulter")
*rmin als kleinstmöglicher Radius, den der Fußpunkt beschreiben kann (wenn der Unterschenkel maximal angezogen ist = kleines α)
*rmax als größtmöglicher Radius (= großes α)
*δmax das ist der größtmögliche Drehwinkel des Schultergelenks

schraffiert ist der Bereich, in dem sich die "Fußspitze" bewegen kann.

'''s''' ist somit die größtmögliche Schrittweite (bei gerader Fortbewegung)

und dann noch
*M ist der Schwerpunkt (oder Mittelpunkt) des gesamten Fahrzeuges
*br die halbe Breite
*f der Abstand dieses Beines von der Querachse

==Beinbewegung==
===Geradeaus===
Wird das Bein nun für einen Schritt von vorne nach hinten gedreht (durch Drehung des "Schulter"-Servos), würde sich die Fußspitze in einem Kreisbogen bewegen. Unterwegs würde allerdings die Fußspitze nach außen wegrutschen. Am schlimmsten daran ist der Verlust der Haftreibung, von der noch zu sprechen ist.

Das Bein muß also unterwegs so verkürzt werden, daß sich die Fußspitze entlang der geraden Sehne '''s''' bewegt. Und dann muss noch die Winkelgeschwindigkeit des Schultergelenks angepasst werden, da ja auch der Radius kontinuierlich verändert wird.
===In einer Kurve===
Um irgendein Fahrzeug in eine Kurve nach rechts zu bringen, kann man z.B. die Räder links schneller drehen lassen. Sowas geht bei Beinen natürlich nicht. Hier muß die Schrittweite variiert werden.
Und noch eine Tücke in der Kurve: Der Schreitweg '''s''' muss um den Kurvenradius-Mittelpunkt einen Bogen machen.

[[Bild:Podtopc.jpg]]

*P Kurven-Mittelpunkt
*M Fahrzeugmittelpunkt
*rfzgRadius des Fahrzeuges um P

==Anordnung der Beine==
===Hexapods===
[[Bild:Hextop1.jpg]]
[[Bild:Hextop2.jpg]]

das sind zwei Möglichkeiten, bei einem Hexpod die Beine anzuordnen. Die linke Variante hat den Vorteil, dass beim Geradeauslauf die Bewegungen der Beine identisch sein können, allerdings den Nachteil, dass der Rumpf länger sein muss (damit sich die Beine nicht in die Quere kommen). Die rechte Bauart hat diesen Nachteil nicht, aber dafür sind die erforderlichen Schrittbewegungen komplizierter.

==Schrittfolge==
Es ist ja klar, daß wir nicht alle sechs Beine gleichzeitig bewegen können. Man braucht also eine Schrittfolge.
Hier können mehrere Varianten unterschieden werden. Da ein Spinnenroboter 6 Beine hat und zum stehen 3 Stück (ein Dreieck bildend) ausreichen gibt es: 3:3. Wir können aber auch nur 2 Beine bewegen und 4 auf dem Boden stehen lassen also 2:4 oder alternativ nur ein Bein bewegen und mit den restlichen 5 auf dem Boden stehen, also 5:1. In Kurven ist das ganze noch etwas komplizierter daher beschäftigen wir uns als erstes mit:

===geradeaus 3:3===
Die folgende Methode wird gerne angewandt, weil sie recht einfach und auch rein mechanisch gemacht werden kann, allerdings ist die Belastung für die Servos bei dieser Variante am grössten, denn nur 3 Beine teilen sich das gesamte Gewicht des Roboters. Die Beine 1, 4 u. 5 bzw. 2, 3 u. 6 werden jeweils gleich angesteuert, phasenmäßig aber um 180 Grad versetzt.

Im linken Bild sind die Beine 2, 3 u. 6 gerade ganz vorne, die anderen Beine 1, 4 u. 5 ganz hinten

[[Bild:Podstp1.jpg]]
[[Bild:Podstp2.jpg]]

Im rechten Bild sind 2, 3 u. 6 mit ihrer Bewegung fertig, sie haben das Fahrzeug fortbewegt, jetzt kehrt sich die Sache um

'''Schwerpunkt ?'''

Unterstützt wird das ganze Gerät immer an den Fußpunkten der Beine. Verbindet man diese jeweils drei Punkte, ergeben sich zwei Dreiecke, die in den beiden Zeichnungen strichliert angedeutet sind. Teilweise überlappen sie sich, das ist der Bereich, wo sich der Schwerpunkt des ganzen Fahrzeuges befinden darf.

Und man sieht, dass diese Fläche bemerkenswert klein ist.

Für 3:3 laufen benötigt jedes Bein 2 Stellungen einmal vorn (A) und einmal hinten (B). Zuerst befinden sich die Beine 2,3 u 6 in Stellung A und werden auf dem Boden gleichzeitig in Stellung B bewegt. Dadurch schiebt sich der Roboter um das Stück A zu B nach vorn. Die Beine 1, 4 u 5 bewegen sich in der selben Zeit von Stellung B nach A, jedoch ohne Bodenkontakt. Wird nun diese Sequenz, im wechsel mit 1, 4 u 5 am Boden und 2, 3 u 6 in der Luft, zyklisch ausgeführt, hat man schon ein passables Laufprogramm für gerade aus.

===geradeaus 2:4===
Bei dieser Variante wird jeweils ein Beinpaar gleichzeitig bewegt. Diese sind günstigerweise:
1 und 4 (Paar 1); 3 und 6 (Paar 2); 2 und 5 (Paar 3)
Jedes Beinpaar benötigt jedoch 3 Stellungen: A, B, C. Der Algoritmus teilt sich daher auch in drei Schritte auf I, II und III.

Für Schritt I bringen wir Paar 1 in Stellung A, Paar 2 in Stellung C und Paar 3 in Stellung B.
Für Schritt II bewegt sich Paar 1 in Stellung B, Paar 2 in Stellung A (diese Bewegung muss ohne Bodenkontakt erfolgen) und Paar 3 in Stellung C.
Für Schritt III bewegt sich Paar 1 in Stellung C, Paar 2 in Stellung B und Paar 3 in Stellung A (auch wieder in der Luft)
Ab hier wiederholt sich das Programm

Fazit: Die Bewegungn sind etwas aufwendiger sich zu überlegen und zu programmieren, der Roboter gewinnt aber insgesammt an Stabilität und ist nur etwas langsamer als bei 3:3.

===geradeaus 1:5===
Diese Variante ist die langsamste, aber dafür am stabilsten, denn das Gewicht verteilt sich auf 5 Standbeine.
Es werden 6 Stellungen pro Bein benötigt (A, B, C, D, E, F) und 6 Schritte.
Es gibt mehrere Möglichkeiten der Startaufstellung ich will hier eine kurz Darstellen:
Bein 1: A -> B -> C usw. 
Bein 2: D -> E -> F 
Bein 3: E -> F --> A 
Bein 4: B -> C -> D 
Bein 5: C -> D -> E 
Bein 6: F --> A -> B 

Die Pfeile geben an in Welche Stellung sich die Beine als nächstes bewegen, Bein 6 wird sich in die Stellung A bewegen. Dieser Rückstellvorgang muss immer in der Luft erfolgen. So wird sich der Roboter kontinuierlich vorwärts bewegen.

==Hexapods in der Kurve==

Nochmals das Bild von oben

[[Bild:Hextop1.jpg]]

Die effektiven Beinwege '''s''' können auch wie die Räder von einem sechsrädrigen Fahrzeug verstanden werden.

Wenn wir nun eine Kurve beschreiben wollen, verkürzen wir die Wege '''s''' auf einer Seite, dadurch ergibt sich ein Drehpunkt '''P'''

[[Bild:Hexcurv1.jpg]]

Was man sieht: Es muss eigentlich jedes Bein eine individuelle Bewegung machen.
UND: jedes Bein muss seinen eigenen [[Spinnenbeine#Beinbewegung|Kurvenradius einhalten]]

===Hexapods drehen===
Alternativ, etwas einfacher zu programmieren, weil die Stellungen von Oben weiter verwendet werden können ist das Panzer Modell.
Konkret heisst es, die rechte Seite der Beine bewegt sich weiter nach oben, wärend die linke Seite der Beine sich nach unten bewegt. Dadurch wird der Roboter auf der Stelle gedreht. D.h. die Bewegungsrichtung der Beine ist insgesammt links zu rechts gegenläufig.

==Kräfte am Spinnenbein==
Da eine genaue Berechnung recht aufwendig ist und von vielen Faktoren zusätzlich stark beeinflusst wird (Dynamik und äußere Einflüsse), soll hier nur eine qualifizierende Betrachtung erfolgen.

Für Beine gibt es zwei völlig unterschiedliche Situationen:
===Ohne Bodenhaftung===
(Glatteis)
[[Bild:Podvec1.jpg]]

Die Beine werden auseinandergedrückt. Das Kniegelenk muß versuchen, Ober- und Unterschenkel beisammenzuhalten, und in der Schulter muss das anteilige Gewicht des Fahrzeuges getragen werden. Durch die langen Hebel wird da, je nach Beinstellung, eine beachtliche Kraft erforderlich.

===Mit Bodenhaftung===
(Teppich)
[[Bild:Podvec2.jpg]]

Ganz anders bei ausreichender Haftung: Da die Füße ja nicht wegrutschen, zieht das Gewicht des Fahrzeuges über die Oberschenkel die Knie nach innen. Hier müssen die Oberschenkel nach außen stemmen, um dem entgegenzuwirken.

''TextBitte beachten, die Beine können auch günstiger als auf dem Bild dargestellt, eingerichtet werden. Wenn der Oberschenkel waagrecht zum Roboterkörper ist. Muss das Schultergelenk zwar das gesammte Gewicht des Roboters tragen, aber das Kniegelenk wird praktisch vollständig entlastet. Auch bei Eis als Untergrund würde ein Wegrutschen der Beine so verhindert werden. ''

====Ein Rechenbeispiel====
Des weiteren ist es wichtig zu erwähnen, dass je nach Bauart des Beines, also welche die sich weiter an der Seite vom Bot befinden, enorme Hebelkräfte auftreten. Um die passenden Servos für seinen Roboter heraus zu suchen hier ein Rechenbeispiel:

[[Bild:Beine65.jpg]]

Gegeben sei "a" als größtmöglicher Abstand zum Körper (blau).
Je nach Bauart des Roboters und der Wahl der Bewegung sind entweder 3 oder 4 oder gar 5 Beine gleichzeit am Boden. Auf diese wird das gesammte Gewicht des Roboter verteilt. Uns interessiert an dieser Stelle wieviel Ncm im Schultergelenk notwendig sind um den Roboter hochzudrücken. Aus der Zeichnung wird wieder deutlich warum es sinnvoll ist den Unterschenkel möglichst senkrecht zu halten und den Oberschenkel waagrecht. Unter dieser Positionierung muss das Kniegelenk nämlich kein Drehmoment übertragen.

Aber zurück zur Rechnung.

das Drehmoment in der Schulter wird wie folgt berechnet:
(Gewicht /Anzahl der Beine)* Hebelarm = Drehmoment in der Schulter

in unserem Beispielt
a=10cm; G=1kg=10N; 3Beine am Boden

(10N / 3)* 10cm = 33,3Ncm

Wir benötigen also in der Schulter Servos welche mindestens 33,3Ncm schaffen, zur Sicherheit wären 35Ncm sinnvoller.
Die Rechnung lässt sich natürlich auch so umstellen, dass anhand der Servos das Gesamtgewicht ermittelt werden kann:

(Drehmoment der Servos / Hebelarm)* Anzahl der Beine = Gewicht des Roboters

Dasselbe gilt natürlich auch für Quadrobots. Nur muss man die Faktoren der Anzahl der Beine ändern

==Siehe auch==
* [[Servos]]

[[Kategorie:Mechanik]]
[[Kategorie:Praxis]]