Willas Shrediquette Tricopter / Quadrocopter / Hexacopter

[jevermeister]

Hey Scotch, das mit dem Empänger ist ja n guter Tipp.

Hallo an alle,
ich hab gestern ein bisschen mit Bammel gefachsimpelt aber eine Sache brennt mir noch unter den Nägeln:
Ich hab zusammen mit ssellere einen Pieper eingebaut um besser mit zu kriegen wann es Zeit ist auf den Boden der Tatsachen zurück zu kehren.

Bisher hatte ich meine Mystery Pentium 30A Regler noch auf Lipo Mode und da hatte ich ja den Effekt, dass die Regler die Motoren unter einem gewissen Spannungswert einfach abgeschaltet haben. Somit hatte ich bei der Defaulteinstellung für die Spannungsgrenze ab Blinken der LEDs nur noch ca 5 sek Zeit zu Landen bevor es knallte. Bisher hatte ich immer Glück.

Nun habe ich wie oben erwähnt ja den Pieper, der an einem Ausgang des Arduino hängt und im gleichen Moment lospiept wenn die LEDs anfangen schnell zu Blinken.
Die Regler habe ich auch auf NiMh Mode umgestellt, aber nach ca. 5 sek schalten die Motoren wieder ab, man bemerkt ziemlich schnell nach Piepen, das der schub immer weniger wird und dann gehen sie nach und nach aus.

Bammel meinte gestern das könne mit den zu großen ESC zusammenhängen (30A)

Wie gehe ichd as jetzt am besten an? Zuerst hatte ich gedacht, dass ich den Schwellenwert für die Spannungswarnung im TRIGUI höher setze, aber ich weiß halt nicht wie die Entladekurve so eines Akkus aussieht. Eigentlich sollte die Spannung doch bis zuletzt konstant sein oder? Von daher würde mir das Ändern der Warnschwelle ja nichts bringen. Habt ihr da Erfahrung? Und warum schalten die Regler trotzdem die Motoren relativ früh ab?

Gruß
Nils

[DanielSan]

Hi,

den Füllgrad eines Lipo oder Life (damit fliege ich) über die Spannung zu ermitteln, ist keine allzu gute Idee. Da die Spannung relativ konstant bleibt, bis sie letztendlich "zusammenbricht". Besser wäre hier über den Strom zu gehen und darüber zu integrieren.
Das Problem bei deiner Methode ist, wenn die Elektronik merkt das der Akku leer ist, ist es schon zu spät. Allerdings ist das Messen des Stroms nicht ganz so leicht wie es bei der Spannung ist.

Lipos mögen es garnicht wenn sie zu leer geflogen werden. Meine Lipos entlade ich immer nur bis 80%. Aus einem 2200mAh Akku entnehme ich ca. 1800mAh. An meinem Sender (hitec Aurora9) kann ich einen Timer starten wenn ich Gas gebe. Dazu sind 2-3 "rantastflüge" notwendig. Dann weiss man ungefähr wie lange man fliegen kann. Die entnommene Kapazität sieht man nach dem Laden des Akkus.

Grundsätzlich kann man sagen, wenn der Regler dicht macht ist es schon zu spät. Das ist ungefähr so wie mit der Öl warnlampe im Auto.

Hier http://www.elektromodellflug.de/sls-apl_45c.html kannst du dir mal eine entladekurve ansehen. Auf der Seite gibt es viele gute Informationen und test´s rund um Elektromodellflug

Gruß Daniel

[ssellere]

@ Scotch:

dann hab ich das irgendwie falsch verstanden, werd mir deinen Link noch mal ganz genau anschauen.

Ja ich benutze den QuadroPPM12-Umsetzer von qc-copter.de, um aus den einzelnen Kanälen meines 2,4GHz Empfängers das Summensignal zu generieren.
Wo ist denn der Unterschied zwischen deinem Bild und meinem Bild. Ich sehe bei dir auch nen Impuls mit ca. 0,4ms und dann ein Low-Signal von 0,6 bis 1,6ms.
In Summe wären das dann die 1-2ms pro Kanal. Es müssen ja nicht 0,4ms zu Beginn eines Kanals sein. Nur die Summe sollte halt stimmen.
Wo kommt denn dein Summensignal her? Auch mit nem Umsetzer für 2,4GHz erzeugt, direkt vom 40MHz Empfänger oder ...?

Ich hab gestern abend ausgiebig getestet und das zucken ist weg. Dabei ist mir dann noch eingefallen, dass ich gar keinen Extra-Kanal für Failsafe brauche. Es würde ja reichen zu überprüfen, ob der letzte Kanal (Ch8 bei mir)
eingelesen wurde, wenn nicht werden die neuen Werte nicht verwendet.

MfG Sven

[Willa]

@SvenSellere: Du sagst du hast 8 Kanäle, jeweils mit 0.4ms high davor und einem low-signal von 1-2 ms. Wie lang ist bei dir die Pause nach dem Summensignal? Der Timer braucht eine Pause von mindestens 3.984ms (d.h. keine steigende Flanke in dieser Zeit) damit er überläuft und bei Kanal 1 wieder richtig einsteigt. Kann es sein, dass die Pause bei dir evtl. zu kurz ist?
Wenn das der Fall wäre, könnte man bei Kanälen > 5 einfach die Überlaufzeit des Timers verkürzen. Dann würden auch kürzere Pausen detektiert werden. Wäre schön wenn du mal den Code testen könntest (Propeller besser abmontieren, das war jetzt auf die Schnelle geschrieben), vielleicht hilft das ja schon?

'===READ RX=====================================================================
Getreceiver:    
If Channel > 0 And Channel < 6 Then                         'fill empf(1-5)
  Empf(channel) = Timer0
  Timer0 = 6                                                  'preload for 3.984ms
else                                                             'Channel > 5
  Timer0 = 150                                               'preload for 1.68ms
End If

If Channel = 5 Then                                         'when all relevant channels were read, enable the servo interrupt
  Enable Timer1
End If
Incr Channel                                                'if no falling edge was detected for a longer period, channel will increase above 11

Return

Alternativ könnte man auch statt "Timer0 = 6" ein "Timer0 = 100" für alle Kanäle versuchen (dann aber muss der Offset von "Sempf" angepasst werden). Damit würde der Timer nach 2.48ms überlaufen, das würde in deinem Fall reichen um die Kanäle auszulesen (0.4ms + 1 bis 2ms). Aber ob das für andere Empfänger auch funktioniert bleibt unklar. Und ich bin an einer Lösung interessiert die für die ca. 100000 möglichen Sender/Empfänger/Summensignalerzeuger Kombinationen funktioniert.

[ssellere]

@ Willa:

An den 4ms, die Timer0 braucht zum Überlaufen kann es nicht liegen. Ich hatte vorher nen 6Kanal-Empfänger angeschlossen. Der Summensignalerzeuger gibt dann auch nur 6 Kanäle raus. Das Summensignal eines Kanals setzt sich aus 0,4ms High und 0,6 bis 1,6ms Low-Signal zusammen = 1-2ms. In Summe bei 6Kanälen sind das dann bei maximalen Ausschlägen 6x2ms und am Ende noch mal 0,4ms High = 12,4ms. Nach 20ms startet das neue Summensignal. Also genug Zeit zum Überlaufen.
Bei dem 8 Kanal-Empfänger passt es auch noch, da Kanal8 fest auf 1,5ms eingestellt ist (bei mir): 7x2ms + 1,5ms + 0,4ms = 15,9ms. Wobei das schon knapp ist. Werde deine Idee mal aufgreifen und die Vorlaufzeit von Timer0 verkürzen, sobald alle 8 Kanäle gelesen wurden.
Wahrscheinlich gibt es keine Generallösung für sämtliche Kombinationen, aber ich halte es für sinnvoll abzufragen, ob auch wirklich soviele Kanäle gelesen wurden, wie auch gesendet werden. Wenn nicht, dürfen die neuen Receiverwerte nicht übernommen werden. So hab ich jetzt eingebaut und werde mal fleißig testen und berichten, ob noch Zuckungen auftreten.

MfG Sven

PS: wie werden eigentlich die Summensignale bei anderen Projekten eingelesen und ausgewertet, z.B. bei MikroKopter? Hat da jemand Erfahrung. Hatte bisher beim Googlen exakt die Umsetzung von Willa gefunden

[deHarry]

Hallo Zusammen!

Getrieben durch die Fragen von Sven? (ssellere) habe ich gestern abend meinen Tri auf den Schreibtisch platziert um ein paar Oszillogramme meines Empfängerausgangs anzufertigen.

Hat auch anfangs ganz gut geklappt, bis ich anfing, die einzelnen Impulse und deren Auslenkung zu untersuchen. Zu diesem Behufe habe ich die Knüppel ein paar mal durchgerührt und dann, um abschließend den Kanal 5 zu checken, den Kippschalter betätigt... WUUSCHHH und autsch (ich war schnell!! und habe den mit Vollgas startenden Tri noch auf dem Tisch in den Schwitzkasten genommen).
Er hat um sich gebissen, wir sind fest umklammert unter den Schreibtisch gerutscht, wo ich (ganz) kurz überlegt habe, ob ich den qualmenden Motor loslassen soll um den Akku zu trennen, oder lieber doch den Motor festhalte. Ich habe mich für ein paar weitere Kratzer entschieden und den Stecker auseinander gerissen. Zum Glück hat der letzte laufende Motor nur noch müde hin und her gezuckt, die beiden anderen Propeller wurden wohl vom Fußboden gestoppt.
Auf dem Schreibtisch sah es aus wie bei Hempels unterm Sofa. Lauter zerfetzte Kabel (Programmieradapter für den Atmel, Serielle Schnitte für TriGUI, ein Testboard für kleine I²C-Wandler, ein paar USB-Kabel für Kamera usw.), alles im Zimmer verteilt, ebenso die Papiere mit Notizen, die sich im Laufe der Zeit angesammelt hatten.
Ein Kabel Suche ich immer noch...

Dann bin ich ganz schnell ins Bad und habe mich verarztet. Drei mittelgroße Pflaster haben für die tieferen Schnitte genügt, die restlichen Kratzer und blaue Flecken konnten unbehandelt bleiben.

In meinem speziellen Fall kam noch erschwerend hinzu, dass meine Propeller abgeschnitten und somit scharfkantig sind.

Insgesamt habe ich echt Glück gehabt, dass mir die Kiste nicht ins Gesicht gesprungen ist, alle Löcher sind an den Unterarmen, den Händen und am Bauch (durch T-Shirt und Unterhemd hindurch).

Lerne: Tricopter unter Spannung am Schreibtisch IMMER ohne Propeller!!! (Wie Willa mehrfach an allen möglichen Stellen ausgeführt hat)

Und nein, ich habe nicht alles sofort wieder heile gemacht, sondern ihn erst mal mit Verachtung gestraft und mich weiter um meinen Rechner gekümmert

[3003henk]

Hallo

@deHarry mein Zeigefinger hat auch mal was bekommen und zu Hause immer Props weg und draußen I2C Stecker raus wenn ich was schnell reparieren muss.

@deHarry während des Fluges würde ich nicht versuchen Werte in eeprom zu speichern da Interrups abgeschaltet werden... also besser auf dem Boden.

Code Variante nur zum einstellen der Offsetwerte benutzen da Ch6 und Ch7 nicht gefiltert werden und ist es nicht unmöglich dass sich mal ein Impuls 'einschleicht'. Bislang hat es geklappt und mir sind keine ungewünschte Impulse registriert worden.

Offset wird korrigiert wenn in Hover modus (von hinten/Heck betrachtet):
kippt nach links (roll Yacc) muss Offset dekrementiert werden
kippt nach vorne (nick Xacc) muss Offset dekrementiert werden

Ich hoffe dass ich keine Modifikation falsch gemacht habe (und Willa nichts dagegen hat):

Tricopter_m328p_11_Offsets.bas

Zur Zeit ist meine Bauform etwas 'spartanisch' (und traue mich noch nicht es vorzustellen) aber wie Javermeister werde ich warten und umbauen bzw. erleichtern wenn ich etwas mehr als nur schweben schaffe.

Gruß
Hans

[deHarry]

Hi Hans,

danke für die Bereitstellung des Code.

@deHarry während des Fluges würde ich nicht versuchen Werte in eeprom zu speichern da Interrups abgeschaltet werden... also besser auf dem Boden.

Ich denke, du beziehst dich auf meinen Vorschlag, die Werte "per Knopfdruck" zu speichern.
Ich meinte nicht, sofort ins EEPROM zu speichern, sondern nur "merken" (irgendwo in Variablen) und dann wie du es momentan mit deiner Version machst, erst nach der Landung ins EEPROM.
Erst dann kann man ja auch ungestört die Trimmung wieder auf Null stellen und die neuen Parameter in der TriGUIDE verwenden, die per Reset übernommen werden.

Code Variante nur zum einstellen der Offsetwerte benutzen da Ch6 und Ch7 nicht gefiltert werden und ist es nicht unmöglich dass sich mal ein Impuls 'einschleicht'. Bislang hat es geklappt und mir sind keine ungewünschte Impulse registriert worden.

Klingt vernünftig.