Was nützt einem ein failsafe coprozessor, wenn am Ende die Software nichts taugt. Das ist kein Kommentar über die Qualität des o.g. Boards sondern ein allgemeiner Gedanke. TL ist portierbar gehalten. Wer will, kann ja ein Raspberry zum Fliegen bringen. Ich denke da kommt man mit einer Handvoll M4 nicht hinterher. Wer controlloops parallelisieren will, der sollte besser in VHDL o.ä. programmieren. Es ist wohl nur eine Frage der Zeit, bis die ersten NIOS Chips das Fliegen lernen.
Tau Labs Software unterstützt vielfältige Hardware
- Themenstarter JUERGEN_
- Beginndatum
der Möglichkeiten, gibt es viele.
aber ob nun ein Rapsodie oder wie auch immer die neuen Nachfolger heissen,
sind es doch keine kompletten FC zum "angemessenen" Preis.
warum man eigentlich einen "RTFhawk", unbedingt mit einer APM-Softwareverschnitt füttern will,
erschließt sich mir, trotz alledem nicht.
aber ob nun ein Rapsodie oder wie auch immer die neuen Nachfolger heissen,
sind es doch keine kompletten FC zum "angemessenen" Preis.
warum man eigentlich einen "RTFhawk", unbedingt mit einer APM-Softwareverschnitt füttern will,
erschließt sich mir, trotz alledem nicht.
Es gibt mittlerweile so viele FCs und jede schreibt irgendwo ab. Keiner kann sagen: "Das ist aber unsere Entwicklung". FCs wie Sand am Meer jede für einen anderen Zweck - ist doch super. VR Brain ist z.B. auch schön. Eine FC auf FPGA-Basis hatten wir glaube ich noch nicht. Die Softwareentwicklung wäre zwar aufwändiger, aber man hätte Rechenleistung ohne Ende und IOs solange die Kabel reichen. Wenn es dann noch in VHDL geschrieben wird, bleibt es komplett Hardwareunabhängig. Ein Cyclone hat genug LEs für einen Copter. Also los alle gelangweilten Hardwarelevelprogrammierer: Ein 10-DOF Sensor an ein terasic ran und frisch ans Werk ...
...Man könnte sich die Motorsteuerung, die PID-Logik und eventuell noch einen Bilderkennungszauber in einen FPGA holen. Ich habe mal interessehalber bei Pixhawk im github nachgesehen. Da tut sich schon lange nichts. Der PX4 ist aktiv. Daher schliesse ich auf dieselbe Softwarebasis. Und der "CoPro" ist also nicht viel mehr als der STLink auf dem FlyingF3 .
Es ist nicht so, dass der Kleine den Grossen bei irgendwas entlastet, sondern nur überwacht und ein paar mehr IOs bereithält - naja. Ein Coprozessor sollte schon mehr machen. Irgendwas wie x-PWM-IN/OUT und Sensorkommunikation über CAN z.B.
Zum Debuggen reicht ein SWD-Port auch. SD-Karten finde ich gut, aber beim Pixhawk scheinen die reihenweise kaputt zu gehen.
Vielleicht gibt ja jemand ne Stange Geld aus und portiert TL darauf. Ich habe noch ein DiscoveryF429 hier. Das ist billiger, hat auch einen CoPro, viel mehr RAM und sogar noch einen Touchscreen (falls da jemand beim Fliegen rankommt)
PS: wenn ein kompletter C64 in einen Cyclone passt, warum sollte dann nicht auch ein MWC reinpassen?
.Es ist nicht so, dass der Kleine den Grossen bei irgendwas entlastet, sondern nur überwacht und ein paar mehr IOs bereithält - naja. Ein Coprozessor sollte schon mehr machen. Irgendwas wie x-PWM-IN/OUT und Sensorkommunikation über CAN z.B.
Zum Debuggen reicht ein SWD-Port auch. SD-Karten finde ich gut, aber beim Pixhawk scheinen die reihenweise kaputt zu gehen.
Vielleicht gibt ja jemand ne Stange Geld aus und portiert TL darauf. Ich habe noch ein DiscoveryF429 hier. Das ist billiger, hat auch einen CoPro, viel mehr RAM und sogar noch einen Touchscreen (falls da jemand beim Fliegen rankommt)
PS: wenn ein kompletter C64 in einen Cyclone passt, warum sollte dann nicht auch ein MWC reinpassen?
Stimmt. Kenne ich von WinRTX, das hat Siemens immer auf die SPS-PCs gespielt. Aber RTOSes gibt es ja nun auch genug. Leider muss man immer den HAL anpassen und Sensoren/PWM bringen die Boards meist nicht mit. Also wird es immer zu gross werden.
Ich hatte heute morgen viel Zeit mich mal in der Pix-/Rtf-Hawk einzulesen. Ein TL-Port ist prinzipiell möglich, aber den sollte doch schon jemand schreiben, der die Hardware hat. Einen Fork und die Hardware lauffähig zu machen geht sicher schnell. Ein PR würde wohl die Offenlegung der Hardware verlangen. Da sieht es bei 3DR nicht so gut aus. Ob man sich die Mühe machen sollte, den Kartenslot ans Rennen zu bringen weiss ich jedoch nicht.
Ich hatte heute morgen viel Zeit mich mal in der Pix-/Rtf-Hawk einzulesen. Ein TL-Port ist prinzipiell möglich, aber den sollte doch schon jemand schreiben, der die Hardware hat. Einen Fork und die Hardware lauffähig zu machen geht sicher schnell. Ein PR würde wohl die Offenlegung der Hardware verlangen. Da sieht es bei 3DR nicht so gut aus. Ob man sich die Mühe machen sollte, den Kartenslot ans Rennen zu bringen weiss ich jedoch nicht.
Die RT Versionen von Linux sind schon sehr gut, kein Vergleich zu WinRTX. Leider sind die z.Zt. im o.g. Projekt verfügbaren Treiber im userspace. An kernelmode Treibern wird (?) gearbeitet.
Als Sensoren sollten ein 9250 und 5611 an SPI reichen. Wie die das mit der PWM gelöst haben, habe ich mir nicht angeschaut.
Boards mit Linux wird es immer geben, die werden stetig kleiner und schneller. Ich glaube das ist die Zukunft, fragt sich ob wir schon soweit sind...
Als Sensoren sollten ein 9250 und 5611 an SPI reichen. Wie die das mit der PWM gelöst haben, habe ich mir nicht angeschaut.
Boards mit Linux wird es immer geben, die werden stetig kleiner und schneller. Ich glaube das ist die Zukunft, fragt sich ob wir schon soweit sind...
warum sollte 3DR, das maß aller Dinge sein ?
in letzter Zeit hatten die eh kaum ein gutes Händchen bei der Auswahl ihrer Bauteile.
an der Hardware hat sich ansonsten hauptsächlich in der Wahl der Sensoren etwas geändert ?
nun Dual MPU6000
da sich die L3GD20 wohl zu bockig benahmen, und öfters einfach nicht antworteten.
in letzter Zeit hatten die eh kaum ein gutes Händchen bei der Auswahl ihrer Bauteile.
an der Hardware hat sich ansonsten hauptsächlich in der Wahl der Sensoren etwas geändert ?
nun Dual MPU6000
da sich die L3GD20 wohl zu bockig benahmen, und öfters einfach nicht antworteten.
Ich frage mich sowieso, wer die Dinger kauft. Einerseits sind sie für Softwareentwicklung interessant, andererseits scheinen die meisten der Nutzer ihre copter damit in die Luft zu stellen und haben wenig Skills zum selber Coden. Ist es etwa so: Schau mal bei Youtube, was die Plattform alles kann, meiner könnte das auch :stolz: und dafür habe ich 0,2k€ ausgegeben .
.
Die Skills zum coden sind wohl sehr unterschiedlich. Genau wie die Projekte. Arbeitet man einfach drauf los wird's unübersichtlich wie Multiwii, isses klein und halbwegs aufgeräumt wie baseflight oder cleanflight kann fast jeder mit programmieren. Taulabs ist schon recht komplex, wer nicht beruflich mit sw Entwicklung zu tun geht da kaum ran. Da darf man usern die nur fliegen keinen Vorwurf machen. Selbst alles Features zu nutzen, ohne in den source zu schauen ist nicht so einfach.
Es ist halt immer die Frage was man will.
Es ist halt immer die Frage was man will.
TauLabs Tau Labs Software unterstützt vielfältige Hardware
ist sie,
und für mein dafürhalten ,ist die Dokumentation sogar recht aktuell.
-> https://github.com/PX4/Hardware
was man von anderen Projekten nicht gerade behaupten kann.
ist sie,
und für mein dafürhalten ,ist die Dokumentation sogar recht aktuell.
-> https://github.com/PX4/Hardware
was man von anderen Projekten nicht gerade behaupten kann.
Dann verstehe ich nicht, wieso es offenbar ein Problem mit Clonen und deren Beschaffung gibt. Openhardware kann ja wohl jeder bauen. Es existiert aber nur ein Schaltplan und kein Layout eventuell ist das ja das Problem. Das PX4 kann man wohl so nachbauen. Ich kenne die Geschichte nicht, aber wenn die Schweitzer es erfunden haben, wieso bauen die Amerikaner (3DR) die Hardware? Falls ich völlig falsch liege, korrigiert mich bitte.
