Tau Labs Software unterstützt vielfältige Hardware

Genau und als Anfangs und Endwert einfach die beiden vorher per TxPID ermittelten Werte.
Bei mir z.B. bei 3S und 4S.
TPA sorgt dafür das man die PID´s im Schwebezustand ziemlich an die Grenze treiben kann, der Kopter bei Vollgas aber nicht schwingt - z.B. beim Abfangen über Grund mit einem kurzen Vollgas Schub.

Hallo, kann mir wer sagen in wie weit die Flugeigenschaften eines Taulabs "boards" gegenüber einer Naze32 sind?
Da ja die Rev5 ja nicht mehr so wirklich "openSource" ist bin ich am überlegen umzusteigen...sparky 2.0 scheint eine vielversprechnde alternative zu sein.

Kommt darauf an, was du willst. Ich habe zwar kein Naze, aber mit TL auf einem F4 kann man schon eine Menge anstellen. Wer nun besser oder schlechter fliegt kann ich nicht sagen. Die Unterscheidung habe ich nie verstanden. Das Regelprinzip ist doch bei allen bis auf ein paar Kleinigkeiten gleich. Einzig die Stock-Parameter sind immer wieder anders. Damit kommt es IMHO mehr auf deine Fähigkeiten bei der Einstellung an.

Okay, das dachte ich mir schon. Mir kommt es eig nur darauf an eine Plattform zu haben die komplett offen ist. An der ich mich einarbeiten kann und selber programmieren kann. Da denke ich ist TauLabs eine gute Basis. Werde wol auf das sparky 2 mal warten und in der Zeit mich noch mit der Naze rev5 gebnügen...

Ging ja mal super schnell. HoTT update gestern aufgemacht und schon drin. Die neuen flightmodes sind nun in der Telemetrie auch sichtbar.

@ernieift: super, dann kann man die auch nutzen.
Leider ist das TPA Feature noch nicht drin.

Ich habe gestern mal das neue NEXT compiliert und auf mein Sparky1 überspielt.
Aber irgendwie komme ich auf keinen grünen Zweig.

Ich bekomme das Board nicht mehr zum Laufen.
Oft wird es nicht mehr erkannt und ich muss den Rechner neu starten

Ich habe schon Safe Boot probiert, hat aber auch nichts gebracht.

Liegt es an mir?

Edit:
Ich beantworte die Frage mal selbst. JA

Die EXE aus den Artifacts klappt....

Habe extra nochmal mein Sparky auf aktuellsten Stand gebracht . Geht bei mir.

Mt der fertigen EXE bei mir auch.
Nur das was ich selbst copiliere nicht. Aber das ist im Moment egal

So nun ist das nächste update für PicoC als PR draußen. Damit kann man nun per Script die Position bzw das Ziel und den Pfad im PH-Mode schreiben.
Die Baudrate lässt sich jetzt auch viel höher setzen. Die, die es brauchen wissen schon wozu...

Und die andern müssen jetzt dumm sterben?

Natürlich nicht. Es war die Frage nach viel höheren baudraten für die RGB-LEDs WS2812b. Ich habe es noch nicht probiert, aber wenn es funktioniert, dann kannst Du Dir am USART einen LED-Streifen davon anschließen und die LEDs einzeln programmieren. Habe zwar welche hier, die sind aber woanders verbaut. Neue sind unterwegs. Dann mache ich selber einen Test.
Für die Waypoints mache ich, wenn ich soweit bin auch mal ein Demo.

Aber der Anschluß an diesen LEDs ist doch keine Serielle?!?!
Müssen da die Pins nicht anders gesteuert werden?

Der DataIn von denen erwartet (ich versuche mal mich zu erinnern) eine periodendauer von 1,4microsec und 0/1 wird über das verhaltn von l/h abgeleitet. Der Ansatz dahinter war der, eine Baudrate von X einzustellen und die Bits über Pattern (0x33,0x37,0x73 und 0x77) zu übertragen. Damit bekommst du pro Byte zwei Bits zu den LEDs. Klingt zwar nach einem bösen Hack, wenn es funktioniert ist es sehr flexibel.

Die Pattern sind glaube ich nicht richtig. Es sind immer 10bit und Start/stop müssen berücksichtigt werden.

Leider kann der STM32 keinen 7-Bit Modus. Da könnte man nämlich direct 3 LED-Bits in ein UART-Byte packen. Ob man 2 LED-Bits in ein Byte verpackt bekommt, hängt ein wenig von den Toleranzen der LEDs ab. Notfalls muß man für jedes LED-Bit ein UART-Byte senden. Ob das dann noch schnell genug geht, muß noch getestet werden. Passende LEDs liegen schon bereit, zum Testen komme ich aber vermutlich erst nach meiner DR.

Bei 10bits bleiben Dir 5:1 als Verhältnis. Mit der richtigen Baudrate sollte es gehen.

Bei 10 bit wären die Pattern 0x31,0x33,0x71 und 0x73. Die Baudrate wäre noch zu berechnen. Oder einfach mit der Logikanneliese hinbiegen.

Gestern habe ich mal ein bisschen mit den höheren Baudraten gespielt. Wenn ich es richtig gemessen habe, dann geht es bis 2,5MBaud! Das LED-Timing sollte damit gehen. Es leuchtet auch schon was, aber so richtig will es per Script noch nicht. Wenn es nicht anders gehen sollte, kann man ja über eine "ws2812.h" nachdenken. Da könnte man ein "struct LED{r,g,b}" oder so definieren und dazu eine "setLED(LED*)"-funktion. Dafür muss ich aber erst noch Zeit finden.
Bin gerade dabei eine Befestigungslösung für mein GPS auf dem HHn zu finden. Gestern ist noch eine Bestellung gekommen.
Zu Auswahl habe ich ein GY-GPS6MV2 (schon getestet, funktioniert) und ein superkleines GPS-11571. Das kann ich in Ermangelung eines Steckers noch nicht anschliessen. Soll aber auch gehen.

Hallo Zusammen,

so langsam trudel die letzten Teile für meinen 250 H-Quad rein.
Da ich dieses mal nicht gleich einfach nur zusammen kloppen will, möchte ich gerne Euren Rat, was ich alles beachten soll, um meine Featurerietis auch in Zukunft daran ausleben zu können.
Das soll ein Copter mit ALLEM werden
Gekauft habe ich:
- http://www.myrcmart.com/rcx-h250cf3k-fpv-quadcopter-3k-carbon-fiber-barebone-frame-p-8092.html
- Quanton Board (Sparky 2 dauert mir noch zu lange)
- Kamere Sony CCD (genau Bezeichnung fehlt)
- FPV Sender
- OSD https://github.com/DTFUHF/brOSD/wiki
- GPS (ich habe auch eines mit Kompass, lohnt das?)

Ich möchte auch LEDs anschließen, zum einem weil es geil aussieht, zum anderen um Zustände, wenn diese bald unterstützt werden anzuzeigen. Welche HELLEN LEDs nehme ich am besten?
(Ich habe dieses Video gesehen, wo die in StarWars Style durch den Wald heizen, https://www.youtube.com/watch?v=ZwL0t5kPf6E)
Macht es Sinn einen LED Treiber zu bauen?

Setze ich das GPS auf einen Turm? Material habe ich (Droteck).

Was fehlt, was würdet IHR noch machen?