Hexacopter

[BurY]

So, die Platinenlayout ist fertig & die ersten Bestellungen sind raus
- ATXMega32 + Quarz etc
- 2 Motoren, 2 Regler, 2 Propeller
- MPU6050 auf Breakoutboard
Denke das sollte für den Anfang reichen!?

Könnt ihr mir denn noch etwas theorie empfehlen?
z.B. - Wie ich mit den Daten des Gyro + Beschleunigungssensor umgehen muss / Wie erreiche ich es, dass sich die 2 Propeller, an einer Wippe, ausbalancieren?
- Regelungstechnik (Schritte zu einem gut funktionierenden PID-Regler, und dessen Funktion (Wikipedia kenn ich da Schon, gerne etwas praktischer, in C ))
- ...

[BurY]

Hallo zusammen, nun hat sich doch ein Problem aufgetan - der I2C.

Ich habe aus Atmels ASF die TWI-Integration.

Das Protokoll des MPU6050 ist mir klar, steht ja im Datenblatt

Start-Bedingung - Adresse - Write bit - ACK vom MPU - Register-Adresse - ACK vom MPU
Start-Bedingung - Adresse - Readbit - ACK vom MPU - Byte vom MPU - NACK vom Master - Stop Bedingung.

Nun habe ich einige male die TWI-Docs von Atmel "durchgeblättert", aber so wie es mit schein stehen mir nur die
twi_master_write() und twi_master_read() - funktionen zur verfügung.

Von den ATMegas kenne ich Fleurys lib, mit Mauellem senden von Start/Stop/(N)ACK/etc.
Wie genau das die Lib von Atmel macht, konnte ich nicht herausfinden :-/

Ich habe es nun wie folgt umgesetzt (davon ausgehen, dass Atmel das schon richtig macht):

uint8_t data_received[10];


void mpu6050_readByte(uint8_t regAddr) {

	 
	 usart_serial_write_packet(USART_DEBUG, "START-Read\n", strlen("START-Read\n"));
		 uint8_t *data = regAddr;
		 twi_package_t packet_write = {
			 .chip         = MPU6050_ADDR,      // TWI slave bus address
			 .buffer       = data,			// transfer data source buffer
			 .length       = 1		// transfer data size (bytes)
		 };
		 
		 while (twi_master_write(&TWIE, &packet_write) != TWI_SUCCESS);
		delay_ms(10);
		
		//request register
		twi_package_t packet_read = {
			.chip         = MPU6050_ADDR,      // TWI slave bus address
			.buffer       = data_received,        // transfer data destination buffer
			.length       = 1                    // transfer data size (bytes)
		};
		
		// Perform a multi-byte read access then check the result.
		if(twi_master_read(&TWIE, &packet_read) == TWI_SUCCESS){
			usart_serial_write_packet(USART_DEBUG, "TWI-Read OK\n", strlen("TWI-Read OK\n"));
		}	
}

Nach diesem Beispiel:
http://asf.atmel.com/docs/3.3.0/xmeg...uickstart.html

Wenn ich so nun das WHO_AM_I-Register-Auslese

	while(1)
	{
		mpu6050_readByte(MPU6050_RA_WHO_AM_I);
		test = data_received[0];
		
		char itmp[10];
		itoa(test, itmp, 10);
		usart_serial_write_packet(USART_DEBUG, itmp, strlen(itmp));
		usart_serial_putchar(USART_DEBUG, '\n');}

Bekomme ich eine 205 (0xCD) und nicht 104 (0x68 ) als Antwort.

Für GYRO_XOUT_L/H, ACCEL_XOUT_L/H und TEMP_OUT_L/H bekomme ich immer 255 zurück.

Ich habe am MPU6050 noch keine Initialisierung durchgeführt. So wie ich das sehe, ist es auch nicht unbedingt notwendig.

Hab ihr mir eventuell hierzu ein paar tpps? Eventuell eine andere TWI-Lib, oder muss ich doch bestimmte Initialisierungen machen?
Vielen Dank!

[Che Guevara]

Hi,

der MPU muss initialisiert werden und zwar Register 107 (Power Management 1). Außerdem ist es ratsam, folgende Register einzustellen: 25, 26, 27 und 28.
Mach das mal und gib dann Bescheid.

Gruß
Chris

[BurY]

hi,

ok danke, habe nun folgende config:

        MPU6050_writeByte(&TWIE, MPU6050_RA_PWR_MGMT_1, (MPU6050_CLOCK_PLL_XGYRO));        
    MPU6050_writeByte(&TWIE, MPU6050_RA_CONFIG, (MPU6050_DLPF_BW_42 | MPU6050_EXT_SYNC_DISABLED));    
    MPU6050_writeByte(&TWIE, MPU6050_RA_SMPLRT_DIV, 4);
    MPU6050_writeByte(&TWIE, MPU6050_RA_GYRO_CONFIG, (MPU6050_GYRO_FS_500));
    MPU6050_writeByte(&TWIE, MPU6050_RA_ACCEL_CONFIG, (MPU6050_ACCEL_FS_4));

Powermanagement: Clock: X-Axen Gyro
Config: DLPF_CFG:3, EXT_SYNC disabled
SampleRate: 1000/5 -> 200hz
Gyro: +-500°/s
Acc: +-4g

[...zeg wieder weg, ist alt...]
//UPDATE 10:30Uhr:
Ich vermute es sind die ACK/NACK/STOP-Bedingungen, die die Fehler verursachen.

void MPU6050_writeByte(TWI_t *twi, uint8_t regAdress, uint8_t data){
    Send_Address(twi, MPU6050_ADDR, 0);
    delay_ms(10);
    twi->MASTER.DATA = regAdress;
    while(!(twi->MASTER.STATUS&TWI_MASTER_WIF_bm));
    
    delay_ms(10);
    twi->MASTER.DATA = data;
    while(!(twi->MASTER.STATUS&TWI_MASTER_WIF_bm));
    
    delay_ms(10);
    twi->MASTER.CTRLC = TWI_MASTER_CMD_STOP_gc;
    delay_ms(10);
}


uint8_t MPU6050_readSequence(TWI_t *twi, uint8_t regAdress)
{


    uint8_t readData;
    Send_Address(twi, MPU6050_ADDR, 0);


    delay_ms(10);
    twi->MASTER.DATA = regAdress;
    while(!(twi->MASTER.STATUS&TWI_MASTER_WIF_bm));


    delay_ms(10);
    Send_Address(twi, MPU6050_ADDR, 1);
    delay_ms(20);


    readData = twi->MASTER.DATA;
//    while(!(twi->MASTER.STATUS&TWI_MASTER_RIF_bm));
    
    twi->MASTER.CTRLC = TWI_MASTER_CMD_STOP_gc;
    delay_ms(10);
    return readData;
}

Die initialisierung mit mehrfachem writeByte läuft nun durch, anschließend kann er einmal einen wert auslesen. Beim nächsten mal bleibt er beim senden der Adresse, also in der ersten Zeile hängen. Es kommt wohl kein ack vom MPU, da dieser noch auf etwas wartet. Was genau das ist weis ich aber nicht...


//UPDATE 23:13Uhr
UUUND der TWI läuft

[BurY]

noch fix eine Auswertung für den PC, und schon ist man Glücklich(er)

Oben Gyro X-Y-Z
unten Acc X-Y-Z



-------
Während dem Schreiben noch schnell das Programm aktualisiert:



oben Gyro unten Acc. Leider ist die GUI in C# etwas langsam - bei einem 20ms-Delay beim Auslesen im AVR kann er max. 50 Werte im Diagramm Flüssig anzeigen.
Aber darum geht es hier ja nicht

[BurY]

Hallo zusammen,

Habe nun mit der PWM etwas getestet.
50Hz, 100Hz und 450Hz laufen eigentlich ohne Probleme, auch mit dem Oszi in der FH überprüft.

Die ESCs zeigen nun folgendes Verhalten:
- Initialisierung ab 1ms möglich.
- Motoren laufen im bereich ab etwa 1,4ms bis 2ms
- Leistung bricht zusammen: Habe eine Netzteil, bis 3A bei 11.1V. Motoren werden immer schneller bis 2A, dann regeln sie sich automatisch Auf 1,5A. Dann kann die Leistung auch nicht mehr gesteigert werden. Auch bei längerem DutyCycle ändert sich nichts mehr.

Könnt ihr mir dieses Verhalten erklären?

[Che Guevara]

Hi,

dieses Verhalten liegt mit 99%iger Wahrscheinlichkeit am Netzteil. 3A sind für BL-Motoren idr. eindeutig zu wenig. Probiers mal mit einem Akku (Lipo), auf die richtige C-Zahl achten

Gruß
Chris

[BurY]

hm nagut... wie wäre es denn mit einem MAAS-SPS-30-II, das bis 35A liefert?
Ich hätte eben gerne den Vorteil des Ein/Ausschalters am Netzteil

Immer einen/genug vollen Akku parat zu haben sehe ich als etwas überflüssige Arbeit!?

[Che Guevara]

Hi,

nichts ist in diesem Fall so gut geeignet wie ein Akku, weil dieser am schnellsten auf die Strompeaks reagieren kann. Wenn du also die Motoren wirklich korrekt überprüfen willst, besorg dir nen Akku
Was genau bringt den der Ein/Ausschalter für einen Vorteil? Den Akku kannst du auch abstecken!

Gruß
Chris

[BurY]

Naja Netzteil steht immer zur Verfügung, der Akku muss geladen sein.

Dann kommt es, dass der Akku nach einer Zeit leer ist. Dann müsste ich warten bis er wieder geladen ist, oder einen 2. besitzen, damit der andere Laden kann.
Bei 2 Motoren vllt noch unproblematisch. Wenn ich aber 6-8 Motoren testen will, denke ich ist dass schon eher ein Problem.

Außerdem gibt es das Problem mit den begrenzten Ladezyklen?

Naja, aber da ich sie eh irgendwann brauche, könnte ich mir auch schon jetzt einen zu tuen.
Wieviel C bräuchte ich denn 6 Motoren?
Ich denke im 5Ah Bereich wäre in Ordnung?