Quadrocopter (Dimensionierung)

[Che Guevara]

Hi,

also wenn ich mich recht erinnere, hatte Harald ( https://www.roboternetz.de/community...uette-NanoQuad ) damals fast das selbe Problem, da half glaube ich nur die Suche nach anderen Motoren, die runder laufen.
Was mir spontan auffällt:
- Beim MPU-6000 ist der DLPF auf 5Hz gestellt, das ist zu stark --> ich habe ihn auf 44Hz, etwas mehr ginge wohl auch noch (experimentiere gerade mit nem FIR-Filter)
- Beim Komplementärfilter beziehst du die Regelfrequenz (dt) mit ein. Da du aber in Fixed-Point rechnest und deswegen sowieso skalieren musst, würde ich (auch im Bezug aufs Ergebnis) den Filter mit einem festen Zeitintervall (z.b. 2ms oder 1ms oder..) aufrufen, so ist dt konstant und kann entfallen. Du musst dann nur den ACC-Winkel richtig skallieren.
- ATAN2 ist relativ teuer, es ginge auch mit arcsin. Wenn du aber bei ATAN2 bleiben willst, würde ich folgende Gleichung vorschlagen:

TotalForce = sqrtf((AccX*AccX)+(AccY*AccY)+(AccZ*AccZ));
RollAngleAcc = atan2(AccY, TotalForce);
NickAngleAcc = atan2(AccX, TotalForce);

Damit beziehst du die aktuelle Gesamtbeschleunigung mit ein und der Fehler durch "Querbeschleunigungen" wird geringer.
- Beim Komplementärfilter solltest du statt "0.999" & "0.001" lieber zwei Variablen nehmen, z.b. GyroInfluence & AccInfuence. Dann beschreibst du eine Variable und berechnest (!!!) aus dieser die andere Variable. So verhinderst du "Rundungsfehler" durch die begrenzte Nachkommastellenzahl bei Floats. Ansonsten könnte es passieren, dass 0.001f + 0.999f != 1.0f .
- Den Komplementärfilter würde ich als Float berechnen, ansonsten bekommst du ein ähnliches Problem wie beim Punkt vorher (Rundungsfehler).
- Hin und wieder ein Type-cast würde nicht schaden, schützt vor üblen Überraschungen
- Wenn du den Timer TE1 verwendest, addressierst du immer CNTL & CNTH. Wieso nimmst du nicht einfach CNT (u16)?

Hoffe, das sind jetzt nicht zuviele Punkte auf einmal, aber ich hab mit den meisten davon selbst schon zu kämpfen gehabt ...

Gruß
Chris

[crabtack]

Hi!

Zu viele Punkte gibts nicht, ich bin dankbar für jeden einzelnen.
Die 5Hz waren nur zum testen, ob es das Verhalten des Beschleunigungssensors verbessert, ursprünglich hatte ich auch die 44Hz genommen (Wie in deinem Programm vom Anfang).

Die Idee, die Berechnung in einem festen Zeitintervall erfolgen zu lassen ist gut, lasse ich dann einfach per Interrupt steuern.

Ich musste schon feststellen, dass die Berechnung etwas Langsam ist, das Programm schafft nur etwa 1000 Durchläufe pro Sekunde, da sollte noch mehr möglich sein.
Sobald die groben Fehler beseitigt sind werde ich mal darauf umstellen, danke!

Zu den Rundungsfehlern.
Ich denke, dass ein 16bit int genau genug ist, dafür habe ich ja alles auf Werte von 0 bis 2^16 skaliert, damit ich nicht den höheren Rechenaufwand von float in kauf nehmen muss.
Oder irre ich mich?

- Hin und wieder ein Type-cast würde nicht schaden, schützt vor üblen Überraschungen

Du meinst, dass ich jeweils explizit auf signed oder unsigned casten soll?

- Wenn du den Timer TE1 verwendest, addressierst du immer CNTL & CNTH. Wieso nimmst du nicht einfach CNT (u16)?

Ich wusste bisher einfach nicht, dass diese Möglichkeit besteht und war es so gewohnt, aber wenn das geht werde ich es ab jetzt so machen.

Ich bin dem Problem jetzt etwas näher gekommen.
Ich habe mir mal die Werte, die das Gyroskop ausgibt über UART ausgeben lassen und grafisch dargestellt.
Dabei haben sich die Y und Z Achse so verhalten, wie ich es erwartet habe.
Der Wert bleibt bei Ausgeschalteten Motoren stabil, reagiert auf Lageänderungen und Erschütterungen, wie er soll.
Wenn ich die Motoren Einschalte schwingt der Wert um den eigentlich richtigen Wert (z.B. 0).
Wenn ich das Gleiche auf der X Achse mache, dann verhält es sich ohne Motoren normal und reagiert auf Lageänderungen und Erschütterungen.
Wenn ich aber die Motoren einschalte ist der Ausgangswert ungewöhnlich stark gestört.
Und vor allem Schwingt er nicht um 0, sondern darunter.
Ich habe die Bilder in den Anhang gesteckt, damit man sieht, was ich meine.

Ich verstehe nicht, wie das sein kann.
Die Y Beschleunigung wird auf die gleiche Weise ausgelesen, wie der X und die Z Beschleunigung.
Woher kann es kommen, dass nur die X Beschleunigung fehlerhaft ist?

@Chris: Gibt es eigentlich Videos oder sonstige Doku zu deinem Copter?
Würde mich mal interessieren, wie der sich so verhält.

mfg
Olaf

[Che Guevara]

Hi,

also zu den Rundungsfehlern. Nehmen wir mal dieses Stückchen Code:

Xangle.integer = 0.999*(Xangle.integer + (-Gx.integer * deltaTime)) + 0.001*AccXangle.integer;

So sähe es schonmal mit Typecase aus (ich verwende lieber zuviel als zuwenig wie man merkt):

Xangle.integer = (int16_t)((0.999f*(float32_t)(Xangle.integer+((float32_t)-Gx.integer * deltaTime)) + (0.001f*(float32_t)AccXangle.integer));

So wird auch korrekt gerechnet. Hast du mal überprüft, was dabei rauskommt, wenn man einen int16_t (vor allem sehr kleine Werte) mit einem float (0.999 oder 0.001) multipliziert?
Diese Kurve vom AccX sieht wirklich etwas komisch aus, da fällt mir momentan auch keine Erklärung ein (außer evtl. Vibrationen von den Motoren).
Ein Video bzw. Homepage steht schon lange auf der Liste, aber dafür hab ich irgendwie nie so wirklich Zeit ...

Gruß
Chris

[crabtack]

Hi, danke für die Antwort!

Bisher hatte ich noch nicht mit float auf Mikrocontrollern gearbeitet, sondern nur auf dem PC, dort hatte ich damit nie Probleme gehabt.
Ich werde es mal auf dem Controller ausprobieren, sobald ich wieder in der Werkstatt bin.

Also es liegt definitiv an den Vibrationen der Motoren.
Das "Schwingen" der werte auf den Anderen beiden Achsen liegt ja auch daran.
Problem ist nur, dass die AccX Kurve nicht um die Nullinie Schwingt und außerdem viel zu stark.
Vibrationen können ja eigentlich nicht auf eine Achse viel Stärker wirken als auf die andere, zumindest in diesem Fall nicht.
Ich finde einfach keinen Grund dafür, bin jetzt alles nochmal mehrfach durchgegangen.

mfg
Olaf

[crabtack]

Hi!

Das Problem ist endlich gelöst
Ich habe einfach die Motoren mit Gummimatten gedämpft, damit die Schwingungen nicht so stark aufs Gestell wirken.
Jetzt sind die Vibrationen nicht mehr so schlimm und laufen vor allem Symmetrisch.

Jetzt noch was an der Reglung feilen, dann gibt es hoffentlich bald einen Testflug!

mfg
Olaf

[crabtack]

Hi!

Also, wenn ich den Copter in einem Gestell habe, wo er sich nur um eine Achse drehen kann ist alles bestens.
Lässt sich gut steuern und bleibt stabil.

Wenn ich ihn jetzt frei fliegen lasse klappt es prinzipiell ganz gut.
Problem ist, dass er relativ stark in eine Richtung geneigt bleibt (Y Achse).
Wenn ich nun etwas zu viel Gas gebe, kippt er um.

Also, ich denke, ich muss die Parameter weiter einstellen.
Aber wie soll ich das am besten Machen, ohne viel zu viele Rotoren zu zerstören?

Ich habe die PID übrigens etwas unkonventionell gelöst, um Fließkommazahlen zu umgehen:

int16_t PID::Compute(int16_t error)
{
	
	//errSum += (error); //Integralanteil
	
	if ((errSum + error/prescaler) > Imax) //errsum begrenzen
	errSum = Imax;
	
	else if ((errSum + error/prescaler) < Imin)
	errSum = Imin;
	else
	errSum += (error /prescaler);
	
	float dErr = (error - lastErr); //Differentialanteil
	
	lastErr = error;
	
	return (int16_t)((error/kp) + (dErr / kd) + (errSum/ki));
	
}

pidX.SetParam(420,10000,10); //P, I, D
pidX.SetLimits(-5000,5000);
pidX.SetPrescaler(100);

zum Test war der I Anteil verschwindend gering, der war früher mal höher

Aber Prinzipiell spricht nicht gegen das Prinzip, oder?

mfg
Olaf

[radbruch]

Hallo

Ich kenn mich nicht aus, aber wenn du hier ankommst berechnest du das zum dritten mal:

else
errSum += (error /prescaler);

Gruß mic