Tau Labs Software unterstützt vielfältige Hardware
- Themenstarter JUERGEN_
- Beginndatum
Guten Morgen,
ich habe die Version vom 27.2. (Git commit hash: b5c8f235) auf einem FF3. Angeschlossen ist nur ein GR12 über USART2 (HoTT Telemetrie an USART4 ist z.Zt. disabled, 2k2 Widerstand zwischen Tx und Rx), die 5V kommen über USB.
Ist der Sender ausgeschaltet, dann ist das Rx-Modul im Failsave und alles andere ist grün (OK).
Schalte ich den Sender ein, verschwindet Failsave. Für die CPU gibt es dann ein Overload Warning (>80%). Ist das normal?
Gruß Markus
Edit: SUMDOF06 ist eingestellt, PERIODE von 10ms auf 20ms umstellen ändert nichts
ich habe die Version vom 27.2. (Git commit hash: b5c8f235) auf einem FF3. Angeschlossen ist nur ein GR12 über USART2 (HoTT Telemetrie an USART4 ist z.Zt. disabled, 2k2 Widerstand zwischen Tx und Rx), die 5V kommen über USB.
Ist der Sender ausgeschaltet, dann ist das Rx-Modul im Failsave und alles andere ist grün (OK).
Schalte ich den Sender ein, verschwindet Failsave. Für die CPU gibt es dann ein Overload Warning (>80%). Ist das normal?
Gruß Markus
Edit: SUMDOF06 ist eingestellt, PERIODE von 10ms auf 20ms umstellen ändert nichts
Zuletzt bearbeitet:
Morgen Markus,
ich fliege mein FF3 mit der Master vom 23.12.. Hott Telemetrie aber PPM. Kein Baro. CPU Load um die 50%.
Kannst Du in der Version die Gyrorate verändern? Steht die auf 3xx ?
Wenn es aber mit Einschalten des Senders kommt würde ich auch mal versuchen auf PPM zu gehen. Zumindest zum Eingrenzen.
Eventuell ist in der Version die Priorität der Ser zu hoch angesetzt.
ich fliege mein FF3 mit der Master vom 23.12.. Hott Telemetrie aber PPM. Kein Baro. CPU Load um die 50%.
Kannst Du in der Version die Gyrorate verändern? Steht die auf 3xx ?
Wenn es aber mit Einschalten des Senders kommt würde ich auch mal versuchen auf PPM zu gehen. Zumindest zum Eingrenzen.
Eventuell ist in der Version die Priorität der Ser zu hoch angesetzt.
SUMD ist ein serielles Übertragungsverfahren das sich der Routinen der UART Treiber bedient.
In flight/pios/der jeweilige Prozessor/pios_usart.c findest Du die Routinen. Die Zeichen werden imho per Int in einen Buffer befördert aus dem sich dann das HottSumD Modul, das mit geringerer Priorität läuft, bedient.
Im übrigen benutze ich auch Sparky Boards mit SUMD da habe ich aber noch keine Erhöhung der Prozessorlast bemerkt.
Ich hatte einmal auf dem F3 eine Prozessorlast mit 80% da ist der Kopter aber auch sehr eigenartig geflogen. Die Steuerung war ziemlich träge.
In einer späteren Firmware wurde einerseits die Ausleserate des Gyros auf 3xx HZ reduziert/halbiert, und die A/D Routinen die 8% CPU Zeit benötigt hatten geringer priorisiert.
Eine Erhöhung der Ressourcen habe ich beim Einschalten des Altitude Moduls bemerkt da wird dann Stack/MEM gelb.
In flight/pios/der jeweilige Prozessor/pios_usart.c findest Du die Routinen. Die Zeichen werden imho per Int in einen Buffer befördert aus dem sich dann das HottSumD Modul, das mit geringerer Priorität läuft, bedient.
Im übrigen benutze ich auch Sparky Boards mit SUMD da habe ich aber noch keine Erhöhung der Prozessorlast bemerkt.
Ich hatte einmal auf dem F3 eine Prozessorlast mit 80% da ist der Kopter aber auch sehr eigenartig geflogen. Die Steuerung war ziemlich träge.
In einer späteren Firmware wurde einerseits die Ausleserate des Gyros auf 3xx HZ reduziert/halbiert, und die A/D Routinen die 8% CPU Zeit benötigt hatten geringer priorisiert.
Eine Erhöhung der Ressourcen habe ich beim Einschalten des Altitude Moduls bemerkt da wird dann Stack/MEM gelb.
Die Steuerung wie sie GCS darstellt ist extrem träge - so könnte man verm nicht fliegen (ca. 2s delay).
Bei DMA wäre es nur ein Interrupt pro Paket. Bei 115kBaud ist die Last sonst hoch. Aber der Empfänger sendet die Pakete doch auch wenn der Sender aus ist - oder? Dann halt mit Failsave. In diesem Fall wäre das nicht die Ursache.
Bei DMA wäre es nur ein Interrupt pro Paket. Bei 115kBaud ist die Last sonst hoch. Aber der Empfänger sendet die Pakete doch auch wenn der Sender aus ist - oder? Dann halt mit Failsave. In diesem Fall wäre das nicht die Ursache.
Also ich habe mal ein Sparky drangehängt.
CPU Load am USB 51% nach Einschalten der MX16 54/55%.
Oszi kann ich da jetzt nicht anschließen da das Board montiert ist, aber ich würde sagen und meine mich auh an eine Aussage von Ernieift zu erinnern das der RX noch ein paar Failsafe Bytes schickt und dann Pause ist.
Die CPU Load geht nach dem Ausschalten des TX wieder auf 51/52% zurück - ergo 3% Last auf einem F3 durch SUMD.
Jemand Einwände?
Firmware Master vom 26.1.2014
CPU Load am USB 51% nach Einschalten der MX16 54/55%.
Oszi kann ich da jetzt nicht anschließen da das Board montiert ist, aber ich würde sagen und meine mich auh an eine Aussage von Ernieift zu erinnern das der RX noch ein paar Failsafe Bytes schickt und dann Pause ist.
Die CPU Load geht nach dem Ausschalten des TX wieder auf 51/52% zurück - ergo 3% Last auf einem F3 durch SUMD.
Jemand Einwände?
Firmware Master vom 26.1.2014
Grrrrrrr.
Könnt mich in den Hinte..... "Newer change a running systen", ich weis es, habe trotzdem gestern auf das aktuelle NEXT upgedatet.
Copter fliegt sch..., ich muss die ganze Zeit sehr stark Nick geben, damit er schwebt.
Die alten Einstellungen hatte ich vorher gesichert, Update gemacht, die alten Einstellungen gelöscht, die neuen eingespielt.
Senderwege habe ich neu angelernt. Das hat nicht gereicht. Jetzt die Propeller runter und die vier Regler neu anlernen.
Firmareupdates sind also mit großer Vorsicht durch zu führen. Also was lernt man daraus -> Newer change a runing system
Könnt mich in den Hinte..... "Newer change a running systen", ich weis es, habe trotzdem gestern auf das aktuelle NEXT upgedatet.
Copter fliegt sch..., ich muss die ganze Zeit sehr stark Nick geben, damit er schwebt.
Die alten Einstellungen hatte ich vorher gesichert, Update gemacht, die alten Einstellungen gelöscht, die neuen eingespielt.
Senderwege habe ich neu angelernt. Das hat nicht gereicht. Jetzt die Propeller runter und die vier Regler neu anlernen.
Firmareupdates sind also mit großer Vorsicht durch zu führen. Also was lernt man daraus -> Newer change a runing system
Das mit den Updates ist mir auch schon unangenehm aufgestoßen.
Einen guten Weg habe ich da noch nicht.
Ich sichere zwar auch meine Einstellungen und lese sie zurück, ich habe aber manchmal dem Eindruck, dass manche Einstellungen verschoben sind.
Wenn z.B. ein Wert irgendwo zwischen geschoben wird.
Doof wird das, wenn einen diese Einstellung eigentlich gar nicht interessiert.
Für mich sieht es so aus, also ob beim Speichern der Settings, alle Werte gesichert werden, und nicht du die, die ich bewust geändert habe.
Einen guten Weg habe ich da noch nicht.
Ich sichere zwar auch meine Einstellungen und lese sie zurück, ich habe aber manchmal dem Eindruck, dass manche Einstellungen verschoben sind.
Wenn z.B. ein Wert irgendwo zwischen geschoben wird.
Doof wird das, wenn einen diese Einstellung eigentlich gar nicht interessiert.
Für mich sieht es so aus, also ob beim Speichern der Settings, alle Werte gesichert werden, und nicht du die, die ich bewust geändert habe.
Gesichert wird alles, ist eine XML Datei oä. Nur leider funktioniert das zurückschreiben nicht so wirklich. eventuell muss man das ja auch zweimal machen und dazwischen einen Powerreset?
Zumindest picke ich mir meine Werte für die SpgMessung immer zu Fuß daraus.
Flensburger welches Board? FF3? Markus hatte geschrieben das er eine CPU Load von 80% hat das würde Deiner Flugerfahrung oben entsprechen. Das hatte ich auch schon einmal beim FF3. Wie ist die Gyrorate? Halbiert oder geht nur 7xx Hz?
Zumindest picke ich mir meine Werte für die SpgMessung immer zu Fuß daraus.
Flensburger welches Board? FF3? Markus hatte geschrieben das er eine CPU Load von 80% hat das würde Deiner Flugerfahrung oben entsprechen. Das hatte ich auch schon einmal beim FF3. Wie ist die Gyrorate? Halbiert oder geht nur 7xx Hz?
Flensburger das was ich über das Flugverhalten,CPU Load und Gyrorate geschrieben habe betrifft das FF3 nicht Quanton.
Ein sch... Flugverhalten hatte ich beim Quanton am Anfang mit den Standartwerten P verdreifacht auf 60 war da der Bringer.
Zu den ESC´s da bin ich ein bisschen faul geworden: Fast nur noch BLHelis, beim flashen gleich auf 1000-2000 und TX Prog aus.
Und wenn die 1000 vom TL Board nicht die 1000 des ESCs waren und ESC´s nicht anlaufen wollten habe ich einfach die Anfangswerte in der GCS auf 970 runtergesetzt.
Ein sch... Flugverhalten hatte ich beim Quanton am Anfang mit den Standartwerten P verdreifacht auf 60 war da der Bringer.
Zu den ESC´s da bin ich ein bisschen faul geworden: Fast nur noch BLHelis, beim flashen gleich auf 1000-2000 und TX Prog aus.
Und wenn die 1000 vom TL Board nicht die 1000 des ESCs waren und ESC´s nicht anlaufen wollten habe ich einfach die Anfangswerte in der GCS auf 970 runtergesetzt.
Das Quanton war schon immer drauf, ohne Auffälligkeiten. In der GCS habe ich die Motorstartwerte angepasst. Alles andere ist jetzt auf default. Morgen werde ich die neuen Einstellungen testen.
GPS ist angekommen und installiert und in den Modulen eingeschaltet, Board ist Quanton. Wenn es nicht angeschlossen ist, disarmt der Copter nicht. OK, kann ich mit leben.
Ich habe einige andere Fragen.
1) Habe noch keinen Rückkanal. Wie erkenne ich ob GPS genügend Sateliten gefunden hat ??
2) Möchte RTH ausprobieren, wie mache ich es ??
GPS ist angekommen und installiert und in den Modulen eingeschaltet, Board ist Quanton. Wenn es nicht angeschlossen ist, disarmt der Copter nicht. OK, kann ich mit leben.
Ich habe einige andere Fragen.
1) Habe noch keinen Rückkanal. Wie erkenne ich ob GPS genügend Sateliten gefunden hat ??
2) Möchte RTH ausprobieren, wie mache ich es ??
Also ich nochmal was getestet: Der Alarm kommt bei 80% CPU-Last. Mit abgeschaltetem Sender liege ich bei 79%, angeschaltet bei 82%. Es liegt also gerade so an der Grenze. Bei PPM das gleiche Bild. Evtl sollte ich mal eine andere Version probieren - gibt es da eine Empfehlung?
80% Last mit dem nackten Board + Receiver - mit Telemetrie und GPS sieht es dann schlecht aus, oder?
80% Last mit dem nackten Board + Receiver - mit Telemetrie und GPS sieht es dann schlecht aus, oder?
Nur zum Vergleich, Rat habe ich auch keinen: mein Quanton liegt mit taulabs_next_20140222_021634_233afad32e bei ca. 43% Last, einzelne Spitzen bei 50%.
Updates sind in der Tat nervig, ich mache Screenshots der relevanten Einstellungen und übernehme die dann per Hand, wenn es automatisch nicht klappt. Zum Glück ändern sich die uavobjects nicht jeden Tag.
RTH: Im Wiki https://github.com/TauLabs/TauLabs/wiki/PH-Testing
einzig ThrottleControl würde ich gleich zu Anfang auf TRUE stellen, sonst fühlt sich das sehr komisch an. Und immer den Finger am Schalter um notfalls sofort zu Attitude zurück zu können wenn was schiefläuft. WENN der Copter störungsarm aufgebaut ist und die Sensoren richtig kalibriert sind funktioniert das so. Sieht man eigentlich auch schon im PFD, wenn's dort im INS-Modus wackelt sollte man nachbessern. Mit PH und RTH hatte ich nie ernste Probleme, schlimmstenfalls fängt der Copter an rumzueiern und man muss zurückschalten. Aufpassen: seit ein paar Wochen heißt RTH warten-steigen-zurückfliegen-landen. Vorsicht mit Waypoints, wenn da etwas nicht stimmt fällt auch schon mal was vom Himmel (ich weiß das ... ).
>Wie erkenne ich ob GPS genügend Sateliten gefunden hat ??
Im Flug? Gar nicht, schon weil der Copter (im INS Outdoor, in den restlichen Modi ist es ihm egal) erst armt, wenn mindestens 7 empfangen werden. Manche GPS blinken oder leuchten wenn sie ihren Fix haben. Für sämtliche Navi-Spielchen empfiehlt sich Telemetrie, sonst merkt man nie was und warum nicht geht. Bluetooth, Oplink, Xbee, irgendwas sollte man sich ranhängen.
Updates sind in der Tat nervig, ich mache Screenshots der relevanten Einstellungen und übernehme die dann per Hand, wenn es automatisch nicht klappt. Zum Glück ändern sich die uavobjects nicht jeden Tag.
RTH: Im Wiki https://github.com/TauLabs/TauLabs/wiki/PH-Testing
einzig ThrottleControl würde ich gleich zu Anfang auf TRUE stellen, sonst fühlt sich das sehr komisch an. Und immer den Finger am Schalter um notfalls sofort zu Attitude zurück zu können wenn was schiefläuft. WENN der Copter störungsarm aufgebaut ist und die Sensoren richtig kalibriert sind funktioniert das so. Sieht man eigentlich auch schon im PFD, wenn's dort im INS-Modus wackelt sollte man nachbessern. Mit PH und RTH hatte ich nie ernste Probleme, schlimmstenfalls fängt der Copter an rumzueiern und man muss zurückschalten. Aufpassen: seit ein paar Wochen heißt RTH warten-steigen-zurückfliegen-landen. Vorsicht mit Waypoints, wenn da etwas nicht stimmt fällt auch schon mal was vom Himmel (ich weiß das ... ).
>Wie erkenne ich ob GPS genügend Sateliten gefunden hat ??
Im Flug? Gar nicht, schon weil der Copter (im INS Outdoor, in den restlichen Modi ist es ihm egal) erst armt, wenn mindestens 7 empfangen werden. Manche GPS blinken oder leuchten wenn sie ihren Fix haben. Für sämtliche Navi-Spielchen empfiehlt sich Telemetrie, sonst merkt man nie was und warum nicht geht. Bluetooth, Oplink, Xbee, irgendwas sollte man sich ranhängen.
