Quadrocopter (Dimensionierung)

[crabtack]

Hi!
Danke, für die schnelle Antwort.
Die Größe ist Absicht, so passt das ganze schön aufs Gestell.
Die Flächen unter dem Xmega ist eine GND Fläche, wenn ich das Polygon rein mache, wird die verbunden und dann ist die GND Führung auch nicht mehr Grausig
Sorry, für die Blöde Frage, aber was meinst du mit PH / CH / WP? Davon habe ich noch nie gehört und finde auch nichts dazu.
Ich dachte mir, dass ein Kompass eher sinnlos ist, wegen den Magnetfeldern der Motoren, die das Magnetfeld der Erde überdecken.
Hast du damit schon Erfahrungen gemacht?
Also wenn ich noch einen Kopass verwende würde ich ihn entweder per I²C an den MPU6000 anschließen, so kann ich irgendwann auch mal den DMP mit einbeziehen.
Oder ich verwende den MPU 9150, der schon ein Magnetometer integriert hat, nachteil ist halt, dass ich den nur mit I²C ansprechen kann (400KHz), der 9255 ist ja leider noch nicht erhältlich.
Oder ich werde ihn direkt per SPI oder I²C an den Xmega hängen, das wäre wohl die schnellste (Wobei die Kompassmodule alle recht lahm sind) und sicherste Möglichkeit, dafür entfällt aber die Möglichkeit der Nutzung des DMPs.
Viel gutes habe ich zu dem HMC5883L von Honeywell gehört, währe der Brauchbar?
Welche Vorgehensweise würdest du empfhehlen?

Noch was anderes, zur Höhenmessung wollte ich eigentlich das GPS nutzen, aber das soll ja relativ ungenau sein.
Könnte ich mit einem Luftdrucksensor bessere Ergebnisse erzielen oder wäre das unsinnig?
Also viele kommerzielle Quadrocopter haben ja beides verbaut.

mfg
Olaf

[crabtack]

Tag,

Ich habe mich jetzt gegen Luftdrucksensor und Magnetfeldsensor entschieden, da Luftdrucksensoren nicht deutlich präziser als GPS sind.
Der Magnetfeldsensor würde vor allem durch die Motoren so stark gestört werden, dass er kaum die Schwankungen der anderen Sensoren ausgleichen kann, ich denke Gyro und ACC sind vollkommen ausreichend.

Ich habe das Layout überarbeitet, es ist jetzt noch 80x80mm groß und die Masseführung ist direkter.
Es ist zwar nicht optimal, aber ich denke, damit sollte ich keine großen Probleme haben oder?

mfg
Olaf

[Che Guevara]

Hi,

also WP (WayPoint), PH (Position Hold) und CH (Coming Home) sind Funktionen, die du mit dem GPS-Modul bewerkstelligen KÖNNTEST, aber nur in Verbindung mit einem Kompass.
Die berechnete Höhe des GPS-Moduls kannst du nie-und-nimmer für eine Höhehalten Funktion verwenden! ALLE Multikopter (von Firmen, Privatleuten, etc...) verwenden Luftdrucksensoren, um die Höhe zu messen, auch wenn dies natürlich Wetterabhängig ist. Lediglich einige wenige Projekte verwenden US-Sensoren (da fällt mir nur die AR-Drone ein), die meisten (u.a. Arducopter) aber in Verbindung mit einem Luftdrucksensor.
Den MPU würde ich per SPI auswerten, damit kommst du bei 12Bytes (6Bytes für Gyro, 6 für ACC) auf ca. 30us, mit TWI würde das ca. 520us dauern (bei 400kHz). Den Kompass kannst du dann per TWI anschließen, der muss / kann maximal mit 75Hz ausgelesen werden (HMC5883L), das reicht aber auch locker. Den DMP des MPU zu nutzen würde ich nicht machen, da gibts nur einige reverse-engenierd Lösungen, der Hersteller gibt da die nötigen Infos nur gegen Bezahlung raus.

Sorry, für die Blöde Frage, aber was meinst du mit PH / CH / WP? Davon habe ich noch nie gehört und finde auch nichts dazu.

Sorry für die blöde Antwort, aber hast du mal gegoogelt?

Meiner Meinung nach gehst du etwas sehr blauäugig an das Thema heran!
Einen Quadrocopter (oder generell dessen Steuerung) zu bauen, ist nichts, was man mal eben auf ein paar Wochen macht. Dazu gehört auch viel Erfahrung und Simulierung und/oder Ausprobieren.
Ich habe vor einige Jahren damit begonnen eine Steuerung zu entwerfen, von Anfang an bis jetzt habe ich bestimmt über 30 Motoren (â 30€) in den Sand gesetzt, teilweise weil ich nicht fliegen konnte, teilweise weil ich Fehler in der Software hatte, die sich nur in bestimmten, speziellen Flugmanövern (etc..) gezeigt haben. In solchen Fällen braucht man seeeehr viel Durchhaltevermögen (bzw. Interesse & Leidenschaft), um das ganze nicht in die Ecke zu schmeißen, sondern sich tagelang / nächtelang davor zu hocken und zu debuggen und überlegen, wo den jetzt der Fehler stecken könnte ....

Ich will dich damit nicht entmutigen, aber auf die leichte Schulter sollte man es auch nicht nehmen, auch wenn ich sehe, dass du nichtmal in der Lage warst, GRUNDLEGENDE Begriffe zu ergoogeln (WP, CH, PH).

Gruß
Chris

[Rabenauge]

Ohne einen vernünftigen Kompass kannst du ne autonome Navigation vergessen. Das geht, wenn überhaupt, _nur_ per GPS bestenfalls sehr grob.
Im "Stand" schon mal gar nicht.
Die Magnetfelder der Motoren sind nicht wirklich nen Problem- ich betreibe einen 5883l in weniger als 20 cm Abstand von nem 540er Bürstenmotor- geht einwandfrei.
Dafür gibt die Kalibrierung (meiner ist _nur_ hard-iron kalibriert)- damit erreiche ich Genauigkeiten von ungefähr 5 Grad- mit bisschen Filterung unter 3 Grad. Das reicht völlig aus, um metergenau zu navigieren, vorausgesetzt, das GPS hat das auch drauf.
Würd man wahrscheinlich noch genauer hinbekommen, wenn es denn nötig wäre- isses aber nicht.
Die Ausleserate dagegen reicht locker- das GPS wird dir auch nicht mehr als 10 Hz liefern, wozu also brauchst du alle Millisekunden Kompassdaten? Völlig sinnlos...

[crabtack]

Hi, Danke für die Antworten!

Gut, dann kommen Kompass und Luftdrucksensor noch rein.
Ja, ich habe versucht nach den Abkürzungen zu googlen, aber einfach nichts brauchbares gefunden.
Zu autonomen Funktionen habe ich mir noch nichts durchgelesen, da ich die Probleme selbst lösen möchte.
Den Kompass wollte ich dadurch ersetzen, dass durch die GPS Daten (in Bewegung) die Richtung bestimmt wird und bei Drehungen auf der Stelle soll das Gyro übernehmen.
Wenn der Copter dann nah genufgam Homepoint ist soll die Kamera den Landeplatz erkennen und den Copter landen (Er soll nie ohne PC gesteuert werden).
Aber wenn Kompassmodule so gut funktionieren werde ich noch eins einplanen.

Sorry, dass ich gerade etwas unmotiviert bin, aber es gibt einfach nichts, was ich mehr hasse, als Layouten.
Ich möchte einfach so schnell wie möglich damit fertig werden, damit ich mit dem Programmieren anfangen kann, woran ich deutlich mehr Spaß habe.
Ab nächster Woche darf ich endlich wieder arbeiten, dann wird das wieder besser.

mfg
Olaf

[crabtack]

Hi!

So, jetzt passiert endlich mal was.
Letzte Woche sind die Bauteile für die Fernbedienung angekommen, habe dann gleich eine Platine geätzt und bestückt.
Nach 3 Stunden probieren wusste ich dann auch, dass der Kondensator an Reset zum Programmieren weg muss
Dann lief erstmal alles gut, Ansteuerung für Dualshock war schnell geschrieben, Kommunikation zum PC läuft auch ohne Probleme und das Funkmodul scheint auch zu funktionieren.
Xmegas sind echt toll.

Jedenfalls habe ich jetzt doch ein Problem, dass ich mir einfach nicht erklären kann.
In meinem Programm sende ich dem Xbee 3 Plus Zeichen um es in den Command Mode zu versetzen, danach soll es ein "OK<CR>" zur Bestätigung senden.
Das kommt auch definitiv an.
Jedenfalls möchte ich die Zeichen, die das Xbee sendet in einer Interrupt Routine in ein Char Array schreiben, das später durch die Debug() Funktion an den PC übertragen werden soll.
In der Funktion gebe ich auch die Zählvariable ISRCounter aus, die in der Interrupt Routine hochgezählt werden soll.
Außerdem Toggle ich in der ISR das untere Nibble von PORTB, dadurch sehe ich an den LEDs, dass die ISR auch ausgeführt wird.
Das Problem ist, dass der ISRCounter immer seinen Ursprungswert behält, in dem Fall 0, ich habe es aber auch mal oben mit 1 definiert, auch dabei bleibt der Wert 1.
Ich kann mir das einfach nicht erklären, der Wert ist auch volatil und global, aber er ändert sich einfach nicht.
Hier das Hauptprogramm:

#include "Dualshock.h"


volatile char USARTdata[20];
volatile uint8_t ISRCounter = 0;


void DebugOut()
{
    while(!(USARTD0.STATUS & USART_DREIF_bm));
    USARTD0.DATA = ISRCounter;
    for(uint8_t i = 0; ((USARTdata[i - 1] != 13) && (i < 20));i++)
    {
        if(USARTdata[i] != 0x00)
        {
            while(!(USARTD0.STATUS & USART_DREIF_bm));
            USARTD0.DATA = i;
            
            while(!(USARTD0.STATUS & USART_DREIF_bm));
            USARTD0.DATA = USARTdata[i];
        }
        
    }


}




int main(void)
{
    Init::Clock_Init();
    Init::USART_Init();
    PMIC.CTRL |= PMIC_HILVLEN_bm; //High Level Interrupts freigeben
    sei();
    
    PORTB.DIR = 0xFF;
    PORTB.OUT = 0x00;
    Dualshock::init();
    while (!(Dualshock::SetAnalogMode() == 0x73)); //Versuchen in Analog Mode zu wechseln, bis es funktioniert        
    
    _delay_ms(1000); //Funkmodul in Command Mode
    while(!(USARTC0.STATUS & USART_DREIF_bm));
    USARTC0.DATA = '+';
    while(!(USARTC0.STATUS & USART_DREIF_bm));
    USARTC0.DATA = '+';
    while(!(USARTC0.STATUS & USART_DREIF_bm));
    USARTC0.DATA = '+';
    _delay_ms(1000);
    
    DebugOut();
    while(1)
    {
    Dualshock::getBytes();
    //while (!( USARTD0.STATUS & USART_DREIF_bm));
    //USARTD0.DATA = Dualshock::RightY;
    //while (!( USARTD0.STATUS & USART_DREIF_bm));
    //USARTD0.DATA = Dualshock::RightX;
    //PORTB.OUT = (Dualshock::RightX & 0x0F);
    
    }
}


ISR (USARTC0_RXC_vect)
{
    USARTdata[ISRCounter] = USARTC0.DATA;
    PORTB.OUTTGL = 0x0F;
    //if(USARTdata[ISRCounter] == 13)
    //ISRCounter = 0;
    //else
    ISRCounter ++;
}

Kann sich das jemand erklären?

Ich habe mal darauf verzichtet, die Klassen zu Posten, die Funktionen sollten soweit selbsterklärend sein.
Falls jemand Interesse hat kann ich natürlich die Dualshock Klasse hochladen.

Edit:
Habe das Problem jetzt gelöst bekommen.
Problem war einfach nur, dass das Xbee etwas mehr als eine Sekunde braucht um nach dem empfangen der "+++" Zeichenfolge das OK zurückzuschicken.
Deshalb wurde zu dem Zeitpunkt, wo die Debug Funktion aufgerufen wird noch kein einziges mal die ISR ausgeführt.
Echt mies, dass ich erst jetzt drauf gekommen bin, naja egal, jetzt läuft alles bestens.
Hoffe, dass der Kram aus China bald ankommt, langsam wird es langweilig mit der Fernbedienung.

mfg
Olaf

[crabtack]

Morgen!

Ich habe wieder ein Problem.
Der Copter ist jetzt Hardwaremäßig fertig, Funk funktioniert auch fehlerfrei, genauso wie die Datenfusion von Gyroskop und Beschleunigungssensor.
Ansteuerung der Motoren läuft auch.
Minimalgas bei 780µS und Maximum bei 1780µS.

Ich habe erstmal eine einfache P-Reglung geschrieben.
Jetzt habe ich das Problem, dass wenn ich die Motoren Ausgeschaltet habe und das Signal an einem der Motoren messe, verhält es sich richtig.
Ist der Copter zu weit nach hinten geneigt wird das Signal länger, ist er nach vorne geneigt kürzer.

Problem ist jetzt, wenn ich die Motoren einschalte und sie Laufen, dann funktioniert es kurz, aber irgendwann bleibt das Signal beim Maximalwert (1780µS) hängen und schwankt nur noch leicht.
Woran kann das liegen?
Ich vermute eine Störung des MPU-6000 (Gyro + ACC) durch die Motoren.
Der MPU-6000 befindet sich unter der Hauptplatine und ist mit einer etwa 10cm langen Flachbandleitung angeschlossen. (Oben Mittig im Bild zu sehen, zwischen Xbee und Spannungsregler)
Könnte es sinn machen, eine Abgeschirmte Leitung zu verwenden?
Ich hätte nur 2 Adrige Leitung da (1Ader + Abschirmung), würde es funktionieren, den Sensor mit insgesamt 5 Leitungen anzuschließen? (SCK, MISO, MOSI, CS, VCC und Masse als Abschirmung)?

Oder Kann es vielleicht noch an etwas ganz anderem liegen?

mfg
Olaf