nabend!
na, niemand interesse an einem schicken original sparkfun adxrs610 ;)
https://www.roboternetz.de/community...486#post505486
Druckbare Version
nabend!
na, niemand interesse an einem schicken original sparkfun adxrs610 ;)
https://www.roboternetz.de/community...486#post505486
Moin, moin,
@ Scotch: danke für deine Antwort. Ich glaube aber nicht, dass es was mit der Signalstärke zu tun hat.
Ich hab am WE mal das Phänomen genauer untersucht mit dem Oszilloskop dran.
Auf dem Bild hab ich mal das Summensignal des QuadroPPM12-Umsetzers mit meinem 8Kanal FlySky-Empfänger skizziert.
Anhang 18308
Jeder Kanal beginnt mit einem Impuls von 0,4ms, anschließend kommt für den jeweiligen Kanal ein Low-Signal von 0,6 bis 1,6ms, dann der neue Kanal...
Also für jeden Kanal insgesamt 1-2ms von einer positiven zur nächsten positiven Flanke.
Die TriGuide wertet die Zeit von einer positiven Flanke bis zur nächsten positiven Flanke aus.
Das klappt auch alles wunderbar.
Nur wenn zwischen Punkt A und Punkt B (Kanäle 1-6) in meiner Grafik exakt 9,28ms liegen, dann wird immer mal wieder der erste Kanal nicht eingelesen, Kanal 2 landet auf Platz 1, Kanal 3 auf Platz 2 usw.
Hierdurch lässt sich das rhythmische Zucken meines Tris erklären. Kanal3(Throttle) bekommt dann ja den Wert von Kanal4(Yaw), der Servo zuckt auch im Takt, da Kanal4 den Wert von Kanal5(State) bekommt.
Dabei spielt es keine Rolle, welche Werte die einzelnen Kanäle dabei haben. Nur die Summe zählt. Und ob auf positive oder negative Flanke abgefragt wird, spielt auch keine Rolle.
Ich hab auch nen 6Kanal-Empfänger ausprobiert, gleicher Effekt. Bei einem Summensignalerzeuger, der nur einen FlySky-Satellitenempfänger benötigt, hatte ich eine Zeit von 8,4ms festgestellt.
Aber warum versäumt der AtMega die erste Flanke? Ich hab auch den ReceiverCheck ausprobiert. Da kann man dann genau sehen, wie die Werte der Kanäle die Plätze tauschen.
Da ich keine Erklärung für diesen Effekt habe, ist im Quellcode jetzt eine Abfrage drin, ob auch Kanal 8 gelesen wurde, wenn nicht, sind die Werte ungültig und werden mit denen des vorherigen Zyklus überschrieben.
Erste Tests gestern Abend waren viel versprechend.
Ich hab es ähnlich wie Hans gemacht, meine Kanäle 6 und 7 liegen auf Potis an der Funke, mit denen beeinflusse ich direkt XaccOffset und YaccOffset. Nur das Abspeichern ins EEPROM fehlt mir noch.
Ich hoffe mal, dass ich jetzt von komischen Zuckungen verschont bleibe. Man erschreckt sich doch ganz schön, wenn er kurz vorm Abheben kräftig loszuckt.
MfG Sven
Soeben gibt es auf Watterott den ADXRS620 als Breakout-Board.
Habe mir gleich 3 Stück bestellt und werde sie mal testen, hoffentlich sind sie genauso gut wie der Vorgänger.
Gruss Sam
hi
hab auch gerade die neuen ADXRS620 bestellt ;)
wie ist eigentlich der unterschied zu den Atlen ?
bei mir dauert es aber noch bis zum test , weil ich noch den rest des hexas zusammenbestellen und bauen muss ;)
Hallo Sven,Zitat:
Zitat von ssellere
Signalstärke? Du meinst bestimmt den Link den ich dir geschickt hatte.
Mir war so das Du aus dem Empfänger mit einer Summensignalwandler dieses erzeugst.
In dem Link war zu sehen, das man dies auch direkt vom Empfänger abgreifen kann.
Das mit den 0,4ms am Anfang sieht komisch aus. Normalerweise sieht ein Summensignal
doch so aus. :confused:
Anhang 18312
Dann bin ich mal gespannt wie die neuen Gyro Sensoren arbeiten...
Gruß Ingo
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
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
@ 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
@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?
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.Code:'===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
@ 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