Baro Code Änderungen

[Roberto]

@Scotch: Die angepsrochene Änderung ist noch NICHT online. Ich muss erst noch die Armschalter Sache für die "barologik1" hinbiegen.
@FireN: Genau, wenn ich das Problem beim Probefliegen nicht noch hätte provozieren können, hätte ich die schon als Final hochgeladen. Bei normalem Gebrauch tritt das Problem auch nicht auf...
@Helste: Der Sinn ist, dass man, wenn man sieht dass es brenzlig wird, schon mal den Armschalter auf aus setzen kann und dann der Copter beim Gaswegziehen sofort aus ist.

LG
Rob

 

[Scotch]

Ok danke,
kann hier eh nicht Fliegen.
Dann kann ich auch noch etwas warten...

 

[helste]

Rob, das kann man aber auch einfacher haben. Einfach im Sketch
//#define MOTOR_STOP
auskommentieren. Dann laufen die Motoren nicht, sobald Gas ganz weg genommen wird.
Laufen dann auch nicht an, wenn man scharf schaltet. Das ist vielleicht der einzige Nachteil, weil man nicht gleich merkt, dass gearmt ist. Ist aber beim APM auch nicht anders und da stört es auch niemanden.

 

[Roberto]

Genau, aber das ist mit der Barologic2 dann gefährlich, weil man ggf. beim Sinken mit dem Gasknüppel in den Motorausbereich kommen kann.

 

[helste]

Sehe ich eigentlich nicht so kritisch. Wenn Du in den Motor aus Bereich kommst, dann ist im Falle von motor_stop eben der Motor aus, aber er geht ja gleich wieder an, sobald man Gas gibt. Im Falle von nicht motor_stop, gehen die Motoren das zwar nicht aus, aber es kommt sich auf das gleiche hinaus, weil die Lageregelung da nicht mehr arbeitet.
Wenn man den Kopter an der GUI scharf stellt (ohne Akku natürlich), dann sieht man die Balken für die Motoren nicht rauf gehen, wenn man den Kopter neigt, wenn das Gas ganz unten ist. Es bringt also für die Lageregelung gar nix, wenn die nur auf Standgas laufen und Auftrieb hast DU da auch so gut wie keinen. Da ist es dann schon egal, wenn sie ganz aus sind. Sind ja sofort wieder an, wenn man Gas gibt.

 

[upapa]

Genau, aber das ist mit der Barologic2 dann gefährlich, weil man ggf. beim Sinken mit dem Gasknüppel in den Motorausbereich kommen kann.

Hi Roberto,
plädiere für eine möglichst "idiotensichere" Lösung.
Je weniger potentielle Überraschungen, desto höher die Chance, dass (nicht nur Einsteiger) mit einer geringeren Anzahl von Propellern oder Auslegern über die Runden kommen...

upapa

 

[merlin4]

@helste: das Problem mit dem arm- bzw- kill-switch kommt durch mein versehentliches Nicht-Ausschalten des Baro-Modes. Dadurch lies sich der Kopter nicht mehr disarmen. Gleichzeitig hatte sich der Kopter mittlerweile auf den Kopf gelegt, weil er mit seiner momentanen Lage "wohl nicht zufrieden" war. Und die Motoren liefen und liefen und der Kopter zappelte, als ob er gleich wieder abheben wollte. In dem Moment konnte ich nicht realisieren, wodurch es zu diesem Verhalten gekommen war. Weil es ja nur ein Quad ist (kein OctoX mit Propellern auch auf der anderen Seite), und er ja schon auf dem Rücken lag, konnte ich dann halbwegs gefahrlos den Akku vom Kopter trennen.
Ich halte es für eine unglückliche Idee, wenn ein Stück Software entscheidet, ob es denn auf meinen Disarm-Befehl reagieren will oder nicht. Wichtig: es geht nicht um das normale Fliegen. Es geht darum, dass immer Situationen auftreten können, die - gelinde gesagt - so nicht geplant waren. Und genau dann muss es eine einfache, im Zweifelsfall anfängertaugliche, möglichst idiotensichere Möglichkeit geben, den Kopter auszuschalten (und das notfalls auch mitten im Flug! - und ich muss es entscheiden können). Software beinhaltet immer Fehler. Und auch bei noch so viel Sorgfalt treten Umstände ein, die man sich im Vorfeld nicht vorstellen konnte. Es gibt dazu ja dazu mittlerweile genügend anschauliche Beispiele. Der Sensor ist ja bei den meisten mit Schaumstoff eingepackt. Und dennoch kann z.B. keiner ausschließen, dass nicht durch irgend einen Umstand z.B. ein Sandkorn oder sonst irgend etwas auf den Sensor kommt und dadurch die Wirkung verstellt und der Kopter wie eine wilde Hummel durch die Gegend schießt? Und nicht alle fliegen wie Warthox. Und genau deswegen bin ich sehr froh, dass Roberto sich meinen Gedanken angeschlossen hat und versucht, möglichst viel Sicherheit einzubauen.
Natürlich warten wir alle gespannt auf die Final, aber: safety first.

LG
Holger

 

[Roberto]

Die "Idiotensicherheit" ist genau mein Anliegen, Upapa . Bei meinen Testen, hat mich meine eigene "Idiotensicherung" heute vor dem Propellerbruch gerettet, sonst wäre mir das gleiche passiert wie Dir Holger. Die Wahrheit ist, dass es keine echten Multicopter "Idioten" gibt, und jeder mal in abwegige Situationen kommen kann. Dann ist ein "Arm-Schalter" auf aus und Nullgas eine schnelle Rettung. Die Barologic2 habe ich m.E jetzt wirklich sicher, komischerweise gibt es noch eine seltsame Situation mit der Barologic1, die Motoren lassen sich zwar abschalten, werden aber nicht wirklich disarmt - muss ich mir noch mal in Ruhe anschauen. Wenn die beiden Modi wasserdicht sind, kommt die Finalversion. Der aktuelle MWII-trunk ist sehr weit weg von der 2.1. Es wird sinnlos sein, die Änderungen gegenüber der original 2.1 darzustellen. Sinnvoller scheint mir da die zusätzliche Integration in eine aktuelle Dev und die Gegenüberstellung der Änderungen.
LG
Rob

 

[helste]

Holger, jetzt verstehe ich das Problem. Ich weiß noch aus meiner Anfangszeit beim helifliegen, wie das ist, wenn man in der Panik das falsche macht. Habe zuerst mit Coax und dann mit Fixed Pitch Helis begonnen. Da ist Gas weg, Motor aus.
Wenn Du dann Collected Pitch fliegst, läuft der Motor immer gleich schnell und mit dem Gashebel verstellst nur den Anstellwinkel der Rotorblätter. Am Anfang war das dann so, dass ich in brenzligen Situationen von den vorherigen Helis gewöhnt war, einfach Gas ganz runter. Beim CP Heli haut es Dir den Heli dann ganz ordentlich in den Boden, weil Du damit vollen Druck nach unten gibst. Starten tust Du da den Motor ja mit zentriertem Gashebel. Bis ich das verinnerlicht hatte, verging auch eine Zeit.
Bei den Mutlikoptern haben wir es da leichter. Das ist im Prinzip wie ein Fixed Pitch Heli.
Gas ganz runter, könnte man da ganz einfach mit Motor aus (aber nicht disarmed) nehmen.
Das hat den Vorteil, dass der Motor aufhört zu drehen, sobald man Gas ganz runter gibt, er aber gleich wieder anläuft, wenn man Gas gibt.
Erreichen kann man das indem man im config.h #define MOTOR_STOP setzt. Dann laufen die Motoren beim Armen nicht an. Erst wenn man Gas gibt geht es los.
Das ist eigentlich idiotensicher. Man muss halt nur aufpassen, dass man weiß, ob nun gearmt ist oder nicht. Nicht, dass man den gearmten Kopter aufhebt und dann vielleicht den Gashebel unabsichtlich nach oben schiebt. Ist aber beim APM auch standardmäßig so, und da kann man auch damit leben.
Rob müsste nun also nur dafür sorgen, dass bei Gas Minimum, die Barologic ausschaltet und dadurch der Motor auch ausgehen kann. Ich denke, das ist die einfachste Lösung des Problems. Unangenehme Seiteneffekte sehe ich da eigentlich nicht.

 

[Roberto]

@Helste: Fehler gefunden! Morgen wird getestet!
Für so ein paar Sachen ist jetzt gesorgt

LG
Rob

 

[helste]

Super. Ich muss aber noch auf mein AIO warten.

 

[Roberto]

Schöne SCH..ANDE !!!

Irgendwie kommt es im schnellen Vorwärtsflug, also bei stärkerer Verkippung zum Durchsacken, trotz des Gaswinkelausgleichs.
Das liegt einfach daran, dass die Mahowik Formel eben nicht richtig funktioniert und eben keine winkelgerechte Projektion auf die Vertikale liefert. Da hilft auch das ACC Kalibrieren nicht. So, wat nu?? Da ich von der Mathematik leider zu wenig Ahnung habe um das Grundproblem zu lösen, habe ich mir etwas anderes überlegt. Wenn bei Verkippung der ACC Fehler zunimmt, muss man bei Verkippung eben das ACC im Einfluss herunterfahren. Letztendlich bin ich jetzt bei einem Faktor von Kippwinkel hoch 4 gelandet, das macht schon einen brauchbaren Eindruck. Tja, irgendwie hatte mich schon so auf die Final gefreut. So kann ich eigentlich nur eine Version anbieten, die eigentlich alles hat, aber wegen der Formel noch mal auf den Prüfstand muss.
Die nächste Version wird eigentlich nicht mehr beta sein, aber eben auch nicht final.

LG
Rob

 

[Scotch]

Hallo Rob,
schade das es da Probleme gibt.
Dieser Formelkram ist auch nicht meine Stärke.
Hab mal google bemüht konnte aber zur Mahowik Formel nichts finden.
Ist das eine MultiWii Interne Geschichte oder ist das was wissenschaftliches?
Hast Du mal ein Link, evtl findet sich da dann jemand der mit Dir eine Lösung findet.
Drücke Dir die Daumen.

Gruß Ingo

 

[Roberto]

Danke, Scotch!
Das ist die Formel aus dem Thread: http://www.multiwii.com/forum/viewtopic.php?f=8&t=2371 , die mittlerweile auch in der aktuellen Dev verwendet wird. Leider ist sie fehlerhaft, aber ich bin dran.

LG
Rob

 

[JinGej]

wenn man vorwärts beschleunigt hat man ja noch die G-vectoren und die vorwärtsbeschleunigungsbewegung - ich glaub das geht nich so einfach... meiner z.b. steigt wenn ich zügig vorwärts fliege um beim anhalten wieder auf seinen wert zu sinken... teilweise etliche meter

 

[micha59]

Hallo Roberto,

hier ist noch mal Micha59. Danke für die Antwort in dem anderem Thread. Ich bewundere deinen Drang, Fehler zu beseitigen. Aber irgend wann sagte mir mal ein Lehrer, Genie kommt gleich nach Wahnsinn, denn ich bin ebenfalls immer auf der Suche nach irgendwelchen Fehlern. In diesem Fall kann ich Dir aber nur sagen, o.k. mag hier ein Fehler im Code versteckt sein, ich kann diesen aber PRAKTISCH nicht spüren . . . So wie es jetzt ist, entspricht es voll meinen Erwartungen! Mal ehrlich, wer fliegt immer nur im "Höhe halten Modus", glaube mir, der Fehler im Vorwärtsflug ist meiner Meinung nach vernachlässigbar (ich weiß, es wurmt) . . . Viel wichtiger ist für mich, dass der Copter auf Befehl in der Luft stehen bleibt. Zum Herumfliegen und Fliegen lernen taugt so und so weder Headfree noch Althold! Selber die kleinen Knüppelchen in die Hand nehmen, dass macht für mich Laune . . . (bitte nicht übel nehmen) O.K., ist vielleicht altmodisch, bin eigentlich 3D-Flächenflieger und trotzdem habe ich großen Respekt vor Leuten wie Dir . . . und bin glücklicher Nutznieser davon! Ich bleibe auf jedem Fall am Ball

Bis bald

LG

Micha

 

[Derjunior]

Hey Roberto,ich hab das durchsacken auch, ich dachte erst an Falsche einstellungen aber wurd nicht besser.Ich hatte nur nichts gesagt weil ich die letzte Zeit mit dem Gps rum experimentiert hab (wenn das nur so schön würde wie das mit dem Baro )
Aber ich weiß du bekommst das mit dem durchsacken hin.

Gruß Junior

 

[Roberto]

Danke, Junior für Deine Zuversicht!
Ich glaube, ich mache trotzdem eine "Final" mit der gleichen Kern-Logik wie in der letzten Beta, nur mit besser abgesichertem Modus2 fertig. Warum soll die Version bei mir Staub fangen, und die etwas unsichere Beta die Alternative sein?

LG
Rob

 

[FireN]

Ist schon iwie dein 2tjob "Multiwiiprogrammierer" ^^
Aber vllt hilft dir das ja mit dem Matheproblem? Es sieht jedenfalls gut erklärt aus

http://www.informatik.uni-oldenburg.de/download/Dissertation_Final_Puls.pdf


MfG

 

[HongKong-Pfui]

Hallo Zusammen,

bin erst heute mal zum testen gekommen. Ich habe ja ein mega board mit ITG3205, BMA180, HMC5883 und BMP085

GPS von Wollez ist auch aktiviert.

Ich habe Robertos Sketch aufgespielt und diese Einträge gemacht:

/*********************** TX-related **************************/
/**************************************************************************************/

/* introduce a deadband around the stick center
Must be greater than zero, comment if you dont want a deadband on roll, pitch and yaw */
//#define DEADBAND 10

/* AltHold Common Variables. Note: When in Baromode YOU CAN NOT DISARM/ARM MOTORS OR TURN OFF REGULATION COMPLETELY
THAT IS WHY YOU CAN DEFINE MinThrbaro and MaxThrbaro */

#define ALT_HOLD_THROTTLE_NEUTRAL_ZONE 80 // This is default uncomment to change

#define MaxThrbaro (MAXTHROTTLE-50) // This is default uncomment to change
#define MinThrbaro (MINTHROTTLE+10) // This is default uncomment to change

//#define Barologic1 // Defines Old Style This is default
//#define AltHoldBlindTime 800000 // This is default uncomment to change

#define Barologic2 // Defines Althold relative to Throttlemiddleposition. Logic: Change targethight. For Safety: Do NOT land in this mode
#define Barologic2SpeedNROMAL // Normal is default
//#define Barologic2SpeedFASTER
//#define Barologic2SpeedFASTEST

//#define Barologic3 // Defines Althold relative to Throttlemiddleposition. Logic: Change Throttle. For Safety: Do NOT land in this mode
//#define Barologic3SpeedNROMAL // Normal is default
//#define Barologic3SpeedFASTER
//#define Barologic3SpeedFASTEST

/* AccBaroLPF off per default. Use at least AccBaroLPF 75 (75%) when you use MPU without "MPU6050 Low pass filter setting"
Possible values: 0% up to 100% (strongest filter+delay), values probably useful >50%. Good combination for MPU seems to be: MPU6050_LPF_42HZ and AccBaroLPF 50 */
#define AccBaroLPF 70

/* Visualize uncorrected RAW Accz Values in Debug0 (incl. Hardwarefilter - normally already activated with 20-25%, in case of mpu please activate at least MPU6050_LPF_42HZ)
and resulting vertical value in Debug1 incl. softwarefilter ("AccBaroLPF"), if activated */
//#define AccBaroDebug



Leider hoovert ert nach wie vor und wandert leicht weg obwohl der ACC kalibriert ist. Eben war es windstill. Beim Zuschalten gibt er ein wenig Gas, dann nimmt er es wieder raus und sinkt um 1m dann wieder Gas und so weiter. Er sinkt somit von Minute zu Minute.

Im Config Tool habe ich ALT auf P=8 I =0,025 und D=80 angepasst. Das hatte ich hier bei einem als Screenshot gelesen. Die Werte weichen schon stark ab.

Hat jemand eine Idee?


VG

HKP