3D-FPV mit der NerdCam3D - Offizielle Diskussion
- Themenstarter kritzelkratzel
- Beginndatum
Hast völlig recht. Der Konverter, den ich benutzt hatte, war auch nicht geeignet. Deswegen habe ich den av2hdmi Wandler bei auch schon auf dem Zettel. Die Bauteile sind ausgewählt und den Anti-Bluescreen-Algorithmus gibt's schon mal als Grobkonzept. Ich muss jedoch gestehen, dass die Idee momentan auf Eis liegt, weil mich die Qualität vom Rift DevKit nicht überzeugt hat. Könnte aber sein, dass ich das bald wieder aus der Kiste hole...
Gregory (der Kopf hinter FatShark/ImmersionRC) hat angebissen. Er schreibt mir, dass er tatsächlich an einer eigenen 3D-Kamera arbeitet oder gearbeitet hat, jedoch hat sich sein Fortschritt damit nur langsam entwickelt. Er führt hier die vielen anderen FatShark-Produkte an. Mal sehen, wie sich die Sache entwickelt...
Kleines Update zur späten Stunde, damit keiner auf die Idee kommt, das sich hier nichts tut:
Ich hatte mich vor einigen Tagen entschieden, vor dem offiziellen Start nun doch noch einen ersten (privaten) Produktionsdurchlauf anzuleiern, also Vielfachnutzen-Leiterplatte (32 Kameras) machen lassen, Bauteile beschaffen und bestücken lassen. Nun, die LP ist fertig. Ich bin gerade beim Beschaffen der Bauteile, was etwas mehr Mühe macht als erwartet. Ich schicke diese in mehreren Lieferungen an meinen Bestücker und wenn alles da ist, kann er loslegen. Übrigens alles Made in Germany, bis auf die elektronischen Bauteile. Kein Bullshit. Wenn ihr euch dann später für den Erwerb einer Kamera erwärmen könnt, unterstützt ihr damit großherzig den deutschen Mittelstand.
Wenn die Kameras dann auch noch alle funktionieren (Firmware bespielen mache ich höchstpersönlich zu Hause - die gebe ich nie und nimmer aus der Hand), dann geht's bei mir dann auch los.
Aktuell befindet sich eine Kamera auf dem Weg zu einem interessierten Beta-Tester (kann man das bei Hardware auch so sagen?) und ich hoffe, dass wir bald die ersten Eindrücke hier in der Diskussion lesen werden können. Ist übrigens die Version mit 3D-OSD (mini, Spannung, Strom und Flugzeit). Ich habe es hinbekommen, die Firmware kompatibel mit den Flytron 50A bzw. 100A Stromsensoren zu machen. Ich schwanke auch noch innerlich, den Flytron GPS I2C Sensor V2 zu unterstützen, bin aber unsicher, ob das alles in den FPGA der Kamera - zusammen mit all dem anderen Zeugs wie Oculus Rift Support - noch reinpasst.
Ohje, ich hätte mir nie vorstellen können, dass ich es mal so weit schaffen werde. Manchmal frage ich mich, wo/wann kommt der befürchtete, vorzeitige Projekt-Abbruch wegen irgendeines unlösbaren Problems. Bislang bin ich um die verschiedenen Klippen immer noch irgendwie herumgekommen. Hoffentlich bleibt es so noch eine Weile.
Ich hatte mich vor einigen Tagen entschieden, vor dem offiziellen Start nun doch noch einen ersten (privaten) Produktionsdurchlauf anzuleiern, also Vielfachnutzen-Leiterplatte (32 Kameras) machen lassen, Bauteile beschaffen und bestücken lassen. Nun, die LP ist fertig. Ich bin gerade beim Beschaffen der Bauteile, was etwas mehr Mühe macht als erwartet. Ich schicke diese in mehreren Lieferungen an meinen Bestücker und wenn alles da ist, kann er loslegen. Übrigens alles Made in Germany, bis auf die elektronischen Bauteile. Kein Bullshit. Wenn ihr euch dann später für den Erwerb einer Kamera erwärmen könnt, unterstützt ihr damit großherzig den deutschen Mittelstand.
Wenn die Kameras dann auch noch alle funktionieren (Firmware bespielen mache ich höchstpersönlich zu Hause - die gebe ich nie und nimmer aus der Hand), dann geht's bei mir dann auch los.
Aktuell befindet sich eine Kamera auf dem Weg zu einem interessierten Beta-Tester (kann man das bei Hardware auch so sagen?) und ich hoffe, dass wir bald die ersten Eindrücke hier in der Diskussion lesen werden können. Ist übrigens die Version mit 3D-OSD (mini, Spannung, Strom und Flugzeit). Ich habe es hinbekommen, die Firmware kompatibel mit den Flytron 50A bzw. 100A Stromsensoren zu machen. Ich schwanke auch noch innerlich, den Flytron GPS I2C Sensor V2 zu unterstützen, bin aber unsicher, ob das alles in den FPGA der Kamera - zusammen mit all dem anderen Zeugs wie Oculus Rift Support - noch reinpasst.
Ohje, ich hätte mir nie vorstellen können, dass ich es mal so weit schaffen werde. Manchmal frage ich mich, wo/wann kommt der befürchtete, vorzeitige Projekt-Abbruch wegen irgendeines unlösbaren Problems. Bislang bin ich um die verschiedenen Klippen immer noch irgendwie herumgekommen. Hoffentlich bleibt es so noch eine Weile.
Interessanter Punkt. Ich kenne leider Mavlink nicht und habe mir daher einmal die Online Doku angesehen. Ist recht komplex. Mir erschließt sich momentan noch nicht, woher / wie die GPS-Daten konkret kommen sollen.
Die Kamera hat eine 3.3v i2c Schnittstelle mit der ich Rohdaten in den FPGA schaufeln kann. Beim besagten GPS Sensor von Flytron würde das wohl genau gehen.
Von welcher Mavlink/Frsky kompatiblen Hardware könnte ich diese Daten denn entnehmen?
Die Kamera hat eine 3.3v i2c Schnittstelle mit der ich Rohdaten in den FPGA schaufeln kann. Beim besagten GPS Sensor von Flytron würde das wohl genau gehen.
Von welcher Mavlink/Frsky kompatiblen Hardware könnte ich diese Daten denn entnehmen?
Ich beschäftige mich nur mit Smart Port von FrSky. Das ist ein Kabel mit Poll-Sequenzen über alles mögliche an Sensoren und dann halt auch die Antworten vom Sensor. Aber da müsste man doch ein paar Zeilen Code übernehmen um dies richtig aufzuarbeiten. Und dann noch am richtigen Ort anzeigen.
Ev wäre der Weg sinnvoller, wenn Du die Schnittstelle definierst. Also beispielsweise über welche HW (z.b. i2c) und was im Protokoll enthalten sein muss. Beispielsweise Felder festlegen mit Grösse (resp. Anz. Zeichen) und Zeichensatz. Und dann muss dir eine hw genau so die Daten liefern. Dann kann jeder (mit einem controller) genau das aus seinem System zaubern und dorthin pappen wo er es haben will (und von dir vorgesehen wurde). Ich denke nur so hast du das im Griff und es können all die Varianten von Dantenzulieferern abgedeckt werden.
Denn ich höre schon den ersten (mich
), der sagt, GPS interessiert mich nicht, ich will Strom / Spannung / Verbrauch. Und dann biste nahe am Requirement einer Vollintegration.
Hier mein Rat als Sprichwort: Wer schreibt, führt. Definiere ein Kritzel-Protokoll und wir füllen das. Und wenn es nur 3.3V Pegel sind ist es so. Ich schaue dann selber wie ich meine 5V runter bekomme... Das hört sonst nie mehr auf.
Ev wäre der Weg sinnvoller, wenn Du die Schnittstelle definierst. Also beispielsweise über welche HW (z.b. i2c) und was im Protokoll enthalten sein muss. Beispielsweise Felder festlegen mit Grösse (resp. Anz. Zeichen) und Zeichensatz. Und dann muss dir eine hw genau so die Daten liefern. Dann kann jeder (mit einem controller) genau das aus seinem System zaubern und dorthin pappen wo er es haben will (und von dir vorgesehen wurde). Ich denke nur so hast du das im Griff und es können all die Varianten von Dantenzulieferern abgedeckt werden.
Denn ich höre schon den ersten (mich
), der sagt, GPS interessiert mich nicht, ich will Strom / Spannung / Verbrauch. Und dann biste nahe am Requirement einer Vollintegration.Hier mein Rat als Sprichwort: Wer schreibt, führt. Definiere ein Kritzel-Protokoll und wir füllen das. Und wenn es nur 3.3V Pegel sind ist es so. Ich schaue dann selber wie ich meine 5V runter bekomme... Das hört sonst nie mehr auf.
Grundsätzlich finde ich die Idee richtig, nach außen eine Schnittstelle zu definieren, an der dann interessierte User nach eigenen Wünschen die notwendigen Informationen einblenden können. Wie wäre es z.B. entweder komplett oder teilweise den I2C-Port des bekannten Maxim OSD-Generators MAX7456 zu emulieren? Das Teil ist ja hinreichend bekannt, wird aber wohl bald auslaufen (NRND).
Das Problem ist, diese Erkenntnis der externen User-Schnittstelle kommt für mich etwas spät. Für die o.g. Schnittstelle muss ich einen I2C-Slave bereitstellen, leider sind die vorhandenen zwei I2C-Cores in meinem FPGA schon belegt als I2C-Master. Auch frisst der jetzige OSD-Character-ROM ewig viel Ressourcen, zur Zeit kann ich z.B. nur 21 verschiedene Zahlen/Buchstaben/Satzzeichen benutzen, also nicht einmal das komplette Alphabet. Der FPGA den ich benutze ist der dickste von Lattice, den man noch im TQFP-100 Gehäuse bekommen kann. Die noch dickeren Dinger kosten leider mehr, sind entweder im TQFP-144 Gehäuse (20mm x 20mm, zu groß) oder kommen als BGA (schwierig zu löten, selbst mit meinem SMD-Backofen).
In diesem Sinne wäre das etwas für das Nachfolgemodell der NC3D. Für die jetzige Version wird es wohl nur bei einer einfachen OSD-Implementation bleiben, mit den Sensoren, welche die simpelste Schnittstelle bereitstellen.
Das Problem ist, diese Erkenntnis der externen User-Schnittstelle kommt für mich etwas spät. Für die o.g. Schnittstelle muss ich einen I2C-Slave bereitstellen, leider sind die vorhandenen zwei I2C-Cores in meinem FPGA schon belegt als I2C-Master. Auch frisst der jetzige OSD-Character-ROM ewig viel Ressourcen, zur Zeit kann ich z.B. nur 21 verschiedene Zahlen/Buchstaben/Satzzeichen benutzen, also nicht einmal das komplette Alphabet. Der FPGA den ich benutze ist der dickste von Lattice, den man noch im TQFP-100 Gehäuse bekommen kann. Die noch dickeren Dinger kosten leider mehr, sind entweder im TQFP-144 Gehäuse (20mm x 20mm, zu groß) oder kommen als BGA (schwierig zu löten, selbst mit meinem SMD-Backofen).
In diesem Sinne wäre das etwas für das Nachfolgemodell der NC3D. Für die jetzige Version wird es wohl nur bei einer einfachen OSD-Implementation bleiben, mit den Sensoren, welche die simpelste Schnittstelle bereitstellen.
Der Code vom MinimOSD dürfte eine gute Basis zur Implementierung von MAVlink sein: http://code.google.com/p/arducam-osd/wiki/arducam_osd?tm=6
Diese Fragen sind delikat.
Ich rechne (bei weiterem Ausbleiben von unerwarteten Problemen) mit einer effektiven Verfügbarkeit von Anfang Mai diesen Jahres. Die WEEE-Registrierung dauert 8 Wochen, in denen ich trotz gefüllten Lagers nichts verkaufen darf. Ich würde mich sonst angreifbar machen, weil jedermann anonym in DE nachprüfen kann, ob ein Produkt registriert ist oder nicht.
Was den Preis betrifft, da habe ich natürlich meine Vorstellungen. Diese kann ich aber jetzt noch nicht herauslassen, weil es mir Flexibilität nehmen würde. Nur soviel - der Erlös muss nicht meinen Lebensunterhalt sichern. Er wird (hoffe ich) fair und angemessen sein.
Ich rechne (bei weiterem Ausbleiben von unerwarteten Problemen) mit einer effektiven Verfügbarkeit von Anfang Mai diesen Jahres. Die WEEE-Registrierung dauert 8 Wochen, in denen ich trotz gefüllten Lagers nichts verkaufen darf. Ich würde mich sonst angreifbar machen, weil jedermann anonym in DE nachprüfen kann, ob ein Produkt registriert ist oder nicht.
Was den Preis betrifft, da habe ich natürlich meine Vorstellungen. Diese kann ich aber jetzt noch nicht herauslassen, weil es mir Flexibilität nehmen würde. Nur soviel - der Erlös muss nicht meinen Lebensunterhalt sichern. Er wird (hoffe ich) fair und angemessen sein.
