Tau Labs Software unterstützt vielfältige Hardware

Angeblich soll das alles möglich sein. Ist nur die Frage wie man an die Sache ran geht. Wenn jemand einen Hinweis hat, dann wäre ich dankbar. Es muss ja keine 0815 Lösung sein, kann schon etwas Arbeit und ggf. Zeit investieren. Nur der Weg, wie ich die Sache angehen sollte, müsste man mir mal erklären. Es gibt ja verschiedene Tools mit denen man das sicherlich umsetzen könnte.
Ist der Weg über das MicroXplorer von STM eine Möglichkeit, die Konfiguration entsprechend anzupassen.?
 

ernieift

Erfahrener Benutzer
Sorry, aber es führt wohl kein Weg daran vorbei, es mit den Fingern auf der Tastatur zu machen. Ich habe noch nicht ganz verstanden, was Du vorhast. Willst Du ein komplettes target entwerfen, einen neuen Adapter designen um ein Entwicklungsboard zu benutzen oder suchst Du nach dem passenden FC für Deine Anwendung.
 
Okay, also fang ich mal an, was ich will / möchte.
Also gescuht wird eine FC, die meinen Vorstellungen entspricht und auch das umsetzten kann, was ich bisher so an Features gefunden und erlesen habe. Mittlerweile gibt es auf dem Markt viele Kauflösungen, die auch jede für sich Ihre Vor- und Nachteile haben und sich auch preislich von niedirg bis hoch unterscheiden.
Nun will ich aber den Copter selbst aufbauen und nicht in den Laden rennen und mir das nächst beste Stück holen, also soll es eher was zum basteln sein. Über verschiedene Projekte und Hinweise im Netz bin ich nun auf die Möglichkeit gekommen, das man auch eine FC selber aufbauen kann. Auch bei der eigentlichen Software für die FC gibt es Unterschiede. Hier hat mich der Weg zu Tau Labs geführt, weil es OpenSource ist und vielversprechend ausschaut. (Hinweisen aus dem Forum sei Dank ;-) ). Weiteres Lesen brachte mich nun auf die Idee ein STM32F4Discovery-Board mit entsprechendem Shield zu nehmen und damit den Quadcopter auszustatten. Da verschiedene Shield-Kauflösungen nicht mehr verfügbar sind oder nur für das STM32F3Discovery sind, bleibt mir wohl hier nichts anderes übrig, wie selber eine Shield zu gestalten. Es sollte natürlich keine komplette Neuentwicklung werden, weil das Rad will ich nicht neu erfinden. Verschiedene Ansätze sind u.a. auch hier vorhanden, also dachte ich mir, das es ja nciht ganz zu schwierig sein kann.
So weit, so gut. Aber da ich kein IT-Profi bin, der sich mit der Entwicklung von entsprechender Software aus dem FF auskennt und die Unterstützung der Hardware mal eben an einem Tag anpasst (reine Annahme), bin ich auf gewisse Hilfe, Tipps und ggf. Unterstützung angewiesen.
Ich denke, dass das derzeit der richtige Ansatz für mich ist. Als realisierte, fertige FC wäre ja sonst u.a. das Quanton noch zur Verfügung. Die Frage ist nur, ob Zeitansatz, Hilfe/Unterstützung, Umsetzung und Nerven sich lohnen gegenüber einer fertigen FC-Kauflösung.


Hmm. Sieht so aus. Ich habe damals 2 Platinen bestellt. Eine habe ich bestückt und die andere liegt hier noch. Nach der Preissenkung beim Quanton ist die Variante auch nicht mehr so interessant.

PS: Aber benutzt habe ich es auch vor kurzem. Zum Testen von OneShot auf TauLabs.
Warum ist oder war dem so? Lohnt sich der Kauf des shields und eien STM32F4 gegenüber dem Quanton (nach der Presireduzierung) nicht mehr?
Das ist ja auch das was ich am überlegen bn, ob der ganze Aufwand den vermeintlichen Presiunterschied nachher rechtfertigt.
 
Zuletzt bearbeitet:

ernieift

Erfahrener Benutzer
Ein Shield musst Du entwickeln und bestücken. Dazu brauchst Du noch Sensoren und ein Discovery oder Core board oder Du designst gleich eine komplette FC nach Deinem Gusto. Wenn Du Dich dann tagelang mit Eagle und Co gequält hast, suchst Du noch jemanden, der Dir das PCB "günstig" in Kleinserie fertigt. TauLabs installiert sich auch nicht gerade wie Windows auf einem x-beliebigen PC. Du wirst also ein Target anlegen müssen und es pflegen. Tools werden Dir dabei kaum helfen. Du wirst auch niemanden finden, der noch den kompletten Überblick über den ganzen Taulabs-Code hat.
Mein Vorschlag für Dich wäre erstmal anzufangen. Wenn Du Spaß am Löten hast, nimm ein Quanton-PCB und baue das Ding selbst, schau Dir die Software an und verändere/verbessere was Dir nicht gefällt. Du schreibst, dass Du (noch) kein IT-Profi bist. Also wieso einen Grafikkartentreiber schreiben ohne vorher mal einen Button programmiert zu haben?
Es gibt keinen richtigen Weg zum Wunschcopter. Ich will Dich auch nicht entmutigen. Versuch doch erstmal was zu bauen oder hole Dir einen gebrauchten zum verbessern. Es wäre schade, wenn Deine Entwicklung schon nach ein paar Sekunden mangels Flugerfahrung von Himmel fällt.
 
Okay, zunächst Danke für die guten und aufklärenden Worte... in gewissen Punkten kann ich das sicherlich unterstreichen, dass der von mir angedachte Weg nicht der einfachste sein könnte.
Ich bin davon ausgegangen, dass man mit dem ST32F4Discovery-Board und einem anderen Shield nur die Zuordnung der einzelnen Devices neu definieren muss, aber keine tiefergehende Programmierarbeit leisten muss.
Das Shield wäre so gut wie fertig und auch die pinout-Belegung, die mir vorliegt, sähe wesentlich mehr vor, wie das was nach meinem Kenntnisstand bisher mit dem Board umgesetzt worden ist. Allein die Umsetzung zu einem funktionierendem "Target" fehlt mir, weil ich nicht so tief im Detail drinstecke, das ich erkenne an welcher Stelle noch was geändert werden sollte/muß. Hier war meine Hoffnung bei dem OpenSource jemanden zu finden, der sich ggf. der Sache annehmen könnte.
 

ernieift

Erfahrener Benutzer
Wenn Du Dich bei dem Shield zunächst an die Schaltung vom Quanton hältst, und die Quantonbootloader auf das Discovery spielst, dann könnte es wenigstens booten. Dennoch kommst Du um einen eigenen Bootloader m.E. nicht herum. Da ja ein F407 drauf ist. Du kannst natürlich auch gleich die CPU im Makefile Deiner Kopie vom Source ändern um es schnell zu machen. Wenn Du schon ein Shield für ein Discovery machen willst und keine Scheu vor der Größe/Gewicht hast, warum nicht gleich das Discovery mit STM32F429. Da hast Du RAM ohne Ende und einen Bildschirm mit Touch drauf ;).
Oder Du gehst andere Wege und baust einfach mit dem Raspberry und Navio einen TauLabs-Port. Das könnte ca. 0,5 Jahre dauern, wenn man das nicht als Job betreibt. Leider fehlen diesem Board noch ein paar UARTS. Da müsste man mal sehen, ob es nichts für SPI gibt. Die eierlegende Wollmichsau wirst Du nicht kaufen aber auch nicht bauen können. Kompromisse sind überall. Um das Lesen der Datenblätter kommst Du nicht herum.

Was ein eigenes Target angeht: Es muss in einen separaten Ordner bei flight. Der Bootloader und ein paar andere Dinge müssen angepasst/neu programmiert werden. Im shared Ordner braucht es noch passende hw_xxx.xml damit die GCS überhaupt etwas davon weiss. Die gcs müsste um ein paar Bilder erweitert werden, damit man auch etwas sieht. Das wars ;).
 
Zuletzt bearbeitet:

cGiesen

Erfahrener Benutzer
Allein die Umsetzung zu einem funktionierendem "Target" fehlt mir, weil ich nicht so tief im Detail drinstecke, das ich erkenne an welcher Stelle noch was geändert werden sollte/muß. Hier war meine Hoffnung bei dem OpenSource jemanden zu finden, der sich ggf. der Sache annehmen könnte.
Bei OpenSource ist das halt so, dass jeder nur dann etwas macht, wenn er selbst seinen Nutzen sieht.
Ich habe selbst viel gemacht (BaseFlight GUI). Aber seit dem ich kein Naze32 mehr mache, ist das Projekt für mich tot.
Und nur für andere? Warum?
Hört sich hart an, ist aber das Leben.
Wenn Du also jetzt mit Deiner Hardware einen genialen Wurf bringst, der andere ins Boot holt, weil sie das auch haben wollen, kannst Du Glück haben.
Aber im Ernst, ich kenne das Quanton Board, da muss VIEL kommen, um das zu toppen!
Da lohnt einfach der Aufwand nicht! In der Zeit kann man besser fliegen gehen!
 

ernieift

Erfahrener Benutzer
Gestern habe ich mir was neues für PicoC überlegt. Für alle, die an Featureritis leiden ;). Ich versuche mal ein paar Funktionen einzubauen, die den I2C-Bus für eigene Hardware nutzbar machen. Vorstellbar wären da 16Bit Portregister, OLED-Displays oder UARTS wie SC16IS752. Die Funktionen wären dann Lowlevel. Also nur Lesen und Schreiben. Irgendwelche Protokolle könnte man dann wie bei den RGB-LEDs in den source oben einfügen.
 

cGiesen

Erfahrener Benutzer
Damit kannst Du mich nicht gemeint haben ;)
OLED brauche ich nicht.
Auf das Hubble habe ich keinen Zugriff, außerdem haben wir HoTT für die Telemetrie ;)
Ich sehr für mich in I2C nicht wirklich bedarf.
Da wäre mir der Status wie mal angefragt wichtiger/nützlicher.
Ein Softserial Debugport wäre was, oder eine andere Art in die GCS zurück zu schreiben.
Keine Aufsätze, aber zusätzlich zu dieser Variable (mir fällt der Name gerade nicht ein) noch String 20(?) Char wäre cool. Und ein Break via GUI Hardcoded, das man die Variable nicht braucht.
 

ernieift

Erfahrener Benutzer
An Deinen String habe ich auch schon gedacht. Ich wollte mal was mit der Telemetriezeile in HoTT machen. Das blöde ist aber, dass nicht jeder HoTT hat. Ansonsten könnte man noch Texte über die Sektorbytes zur gcs schicken, ohne gleich alles umzubauen. Das muss ich aber in Ruhe machen.
Im Moment teste ich OneShot auf dem Quanton mit Leora-Rahmen. Sieht gewöhnungsbedürftig aus. Eigentlich passt es Board da gar nicht drauf. Es kommt auch wieder runter, wenn ich ein kleineres F4-Target in den Händen halte ;).
 
Bei OpenSource ist das halt so, dass jeder nur dann etwas macht, wenn er selbst seinen Nutzen sieht.
Ich habe selbst viel gemacht (BaseFlight GUI). Aber seit dem ich kein Naze32 mehr mache, ist das Projekt für mich tot.
Und nur für andere? Warum?
Hört sich hart an, ist aber das Leben.
Wenn Du also jetzt mit Deiner Hardware einen genialen Wurf bringst, der andere ins Boot holt, weil sie das auch haben wollen, kannst Du Glück haben.
Aber im Ernst, ich kenne das Quanton Board, da muss VIEL kommen, um das zu toppen!
Da lohnt einfach der Aufwand nicht! In der Zeit kann man besser fliegen gehen!
Tja, da wirst Du wohl Recht haben. Der große Wurf wird es wohl nicht werden, weil das Quanton mit den ganzen Möglichkeiten die Latte schon recht hoch gesetzt hat.

Ein Adaptershield für den STM32F4Discovery zu kreieren, um dann bis zu: 6xUART's, 3xSPI, 3xI2C, 6xADC und über 10xPWMOut's zu haben, ist unter den ganzen Randbedingungen auch nicht mit der höchsten Motivation bedacht. Was dann natürlich auch von den Abmessungen nicht an andere Boards herankommt, sondern eher auf die Abmaße des STM32F4 ausgerichtet ist. Es sollte eine "Quick-and-Dirty" Lösung werden, die aber so ohne Unterstützung von mir allein nicht umgesetzt werden kann.

Dann lieber, wie schon ernieift geschrieben hat, irgendwo Abstriche machen und auf was Verfügbares zurückgreifen oder wie cGiesen sagt:
Da lohnt einfach der Aufwand nicht! In der Zeit kann man besser fliegen gehen!
 
...
Ein Adaptershield für den STM32F4Discovery zu kreieren, um dann bis zu: 6xUART's, 3xSPI, 3xI2C, 6xADC und über 10xPWMOut's zu haben, ist unter den ganzen Randbedingungen auch nicht mit der höchsten Motivation bedacht. ...
Da wirst Du aber erst noch die Überflüssige Hardware auf dem Discovery entlöten müssen um alles das zur Verfügung zu haben :)

ernieift
Q2 2015 kommen die STM32F7 raus. Da kann man sich dann drauf stürzen.
Oder für den Carsten dann lieber gleich einen A9: http://developer.mbed.org/platforms/Renesas-GR-PEACH
Da hätte er dann endlich genügend Serielle zur Verfügung ;)
Nur mit ner 30er Befestigung könnte es schwierig werden.
 

cGiesen

Erfahrener Benutzer
@Jörg
Ich bin jetzt mal echt böse. Mache Dich doch bitte über meine wirklich schwerwiegende Krankheit lustig.
Was kann ich dafür, das ernieift mit seinem PicoC Möglichkeiten eröffnet die meine Krankheit auch noch mit Nahrung versorgt und leider dadurch auch die Ansprüche steigert.
Es so schon schwer genug zu überlegen, worauf man den lieber verzichten muss.

:engel:
 

cGiesen

Erfahrener Benutzer
sagt mal.
Kann es sein, das bei Export UAV Settings, die Werte für HoTT und PicoC nicht gesichert werden?

Ich habe gerade dummerweise Safe Boot gemacht und dann die Werte die vorher gesichert habe zurück geladen und da waren die alle leer :(
 
FPV1

Banggood

Oben Unten