Hallo,

ich bin auch sehr an einer veröffentlichung des codes interessiert. Finde eure Arbeit richtig klasse. Ein MK ist aber nicht die einzige Anwendung für ein OSD. Viele hier möchten gerne einige extra Daten mit anzeigen oder ihre eigene Oberfläche designen, oder das Ding in ein Auto/Boot oder sonstwas einbauen.

Mich würde mal interessieren, warum ihr euch entschieden habt, den Sourcecode nicht freizugeben. Mit dem GPS Code war es doch das gleiche, einer hat was, gibts aber nicht her und lässt sich stattdessen feiern. Jetzt hat's jeder, und nun gibt es viele Varianten. Da ist für jeden was dabei.

Gruß, Moertsches

Hallo

Das jetzige EPI-OSD ist nicht so sehr für andere Aufgabengebiete geeignet, weil es keine eigene Sensorig hat.

Das wird sich aber ändern mit der EPI-ES. Eine kleine Zusatzplatine für das OSD.

Strom und Spannungsmessung ist schon fertig. Weitere Sensoren folgen in der nächsten Zeit.

Wichtig vor allem ein eigener Luftdruckmesser. Das wird die Tage fertig.

Und das soll alles noch in das OSD integriert werden. Und bis das fertig ist bleibt der Source closed.

Es wird auch die Tage ein EPI-Tool geben, wo man einige Änderungen per PC vornehmen kann


Gruß Wolfgang

moertsches meinte

...Mich würde mal interessieren, warum ihr euch entschieden habt, den Sourcecode nicht freizugeben...

...weil sie sich so entschieden haben. Warum sollen sie sich rechtfertigen dafür, daß sie nicht nur die compilierten Files freigeben? ...und das für umsonst.

Mach doch selber was.

wowie meinte

Es wird auch die Tage ein EPI-Tool geben, wo man einige Änderungen per PC vornehmen kann

Sehr schön. Man wird nicht zufällig die Anordnung/Position des OSD's einstellen können?
Ich hätte einige Anzeigeelement gerne weiter in der Mitte des Bildes.

Es wäre auch super wenn man die Stromanzeige des Akkus auf Numerisch schalten könnte. Die "Akkustandanzeige die keine ist" finde ich sehr unpraktisch.

Hallo

Der Balken bleibt erstmal, zusätzlich gibt es eine numerische Anzeige.

Balken deshalb, weil es ein "echte" Kapazitätsanzeige werden soll.
Bedingt aber die EPI-ES als zusatzboard.
wie weit das nun praktikabel ist wird sich zeigen. Es muss ja der Akkutyp eingestellt werden.

Positionierung frei wählbar wäre auch ein Wunschtraum vom mir. Mal sehen wie weit man das treiben kann. Wird aber wohl noch ein paar Tage dauern

Gruß Wolfgang

auf das PC-Tool freue ich mich auch schon. Klasse.
Wunsch von mir wäre, das Vario auch etwas etwas empfindlicher anzeigen lassen zu können.
In einer älteren Version habe ich mal gelesen, war die Anzeige um den Faktor 30 zu heftig, würde mir beim Fliegen aber eine besser Vorstellung geben, was der Kopter gerade macht.
Bei der Aktuellen Version dagegen kommt es mir vor, als wenn es viel zu wenig anzeigt, obwohl ich eine funktionierende Höhenanzeige im Bild habe.
In einem Video hat sich das Vario auf gerade mal -1 bis - 2m/sec eingestellt obwohl dabei 100m in ca 18sec abgestiegen wurden...
Das hätte dann nach Adam Riese -5,5 anzeigen müssen......

Wo sich bei mir ein weiters Fragezeichen auftut, ist ob diese Höhenanzeige auch wirklich stimmt.....
Habt jemand sich mal die Mühe gemacht, die OSD Höhenanzeige mit einem echten Höhenmesser verglichen ?
(Im Auto mit Kopter und einem echten Flugzeug Höhenmesser auf dem Schoss mal ein Berg hoch fahren)

Was mir zu der Optik vom OSD einfällt, wäre das ich es bevorzugen würden, wenn der Künstliche Horizont in der Mitte die Flugzeugnase wäre und der Rest von dem Balken also das Äußere sich bewegen würde.
Wenn ich in einem Flugzeug den Künstlichen Horizont ansehe, dann sieht das auf dem Gerät auch so aus, dass in der Mitte das Teil feststeht und sich die der äußere Bereich bewegt. Der Balken für die improvisierte Schräglagenerkennung kann so bleiben, die ist ok.

Die Akku Anzeige wäre als Volt Anzeige neben dem Balken auch noch eine Feine Sache.

Also wenn man das alles in dem Tool frei konfigurieren könnte, wäre es echt genial.

Hallo

Höhensensor: Hatte ich schon in einem älteren Post geschrieben das da Nachholbedarf ist.

Das ist wahrscheinlich nächste Woche schon gefixt. Es gibt einen eigenen Sensor dafür.
Die Updaterate machte mir auch Kopfzerbrechen.

Die Idee mit der feststehenden Flugzeugnase werde ich die Tage mal umsetzen. Roll wird so bleiben, da sehe ich keine andere vernünftige Möglichkeit es zu realisieren.

Gruß Wolfgang

PS. Neuigkeiten gibt es dann wieder im Wiki. Auch wenn einigen die Revisionübersicht zu chaotisch ist.

super schon mal im voraus vielen dank für die Umsetzung.

Bezüglich der Updaterate fällt mir auch noch etwas ein, bzw auf.
Wenn ich das Bluetooth-Sercon im Menu aktiviere, ist die OSD Dastellung ja recht ruckelig- ist ja bekannt.
Bei der Verwendung von einem GPS Empfänger an der Fligth ctrl benötige ich ja auch diese Einstellung, wenn ich mich nicht irre.
Ist dass dann später bei der Verwendung vom Navi Board auch so ?

Das würde dann ja alles zusammen darauf hinauslaufen, mit dem schon angekündigtem zusätzlichen Luftdruck Sensor, auch am besten gleich die komplette Sensorik nochmal mit auf das OSD zupacken.
Vielleicht bekommt man von Walkerea so ein Breakout board mit den drei Piezos und dem ACC für ein Apfel und ein Ei ab 100er Stückzahlen.
http://forum.mikrokopter.de/topic-5461.html

Irgendwie wiederstrebt es zwar alle Sensoren im Kopter doppelt und dreifach zu haben, bei dem OSD würde ich da gerne eine Außnahme machen, weil dann könnte ich es auch an einem anderen Flieger verwenden :-)
(Fligth ctrl ein ACC, Navi Baord ein ACC und vielleicht noch das OSD mit einem ACC.... cool ;-)

ufus meinte

Irgendwie wiederstrebt es zwar alle Sensoren im Kopter doppelt und dreifach zu haben,

"Wiederstreben" ist garkein Ausdruck... der MK ist nun weder Lastesel noch Kernkraftwerk. Wie sieht das Problem mit der Sensor-Update-Rate eigentlich aus.

@tycho-x
duch machst so, als wenn jeder der Sensoren 100g wiegen würde
und jeder davon mindestens 1A zieht.....
eine einzelne Led, von der du auch sicher mehr als eine an deinem Kotper hast, zieht mehr als alle Sensoren zusammen !!!

Das Problem mit der Sensor Updaterate kommt wohl daher, das die Daten immer über die Serielle von der Fligth ctrl geschaufelt werden müssen und wenn diese Schnittstelle zusammen mit GPS oder Bluetooth benutzt wird, ist es halt der Flaschenhals, wenn ich richtig liege.
Wie es aussieht, sieht man dann am Ruckeln auf dem OSD.

Sich gegen eine extra Bestückung von Sensoren zu wehren ist glaube ich nicht klug, man kann die Verwendung und Bestückung ja optional halten, das macht das OSD nur flexibler, kann mir vorstellen nicht der einzige zu sein, der es auch an einem Flächenflieger benutzen möchte.

ufus meinte

@tycho-x
duch machst so, als wenn jeder der Sensoren 100g wiegen würde
und jeder davon mindestens 1A zieht.....

Ich sehe das so wie beim Rahmenbau auch. Jede "Kleinigkeit" addiert sich. FC + Navi-CTRL + OSD ist veursacht einfach zu hohen Stromverbrauch. Und diese Liste da ist ja nicht das ende der Fahnenstange. Es gibts noch Cams, Videosender, Step-up/down Regler, Verteilerplatinen, Servos etc. Da muss man sparen wo immer es geht.

Zitat

eine einzelne Led, von der du auch sicher mehr als eine an deinem Kotper hast, zieht mehr als alle Sensoren zusammen !!!

Mein "LED-Count" ist zur Zeit noch 0.

Zitat

Das Problem mit der Sensor Updaterate kommt wohl daher, das die Daten immer über die Serielle von der Fligth ctrl geschaufelt werden müssen und wenn diese Schnittstelle zusammen mit GPS oder Bluetooth benutzt wird, ist es halt der Flaschenhals, wenn ich richtig liege.

Ich verstehe das nicht ganz da ja ohne OSD die Datenübertragung funktioneren muss, ansonsten würde der Navi-CTRL nicht gehen. Und das OSD sollte nur mitlesen. Wowie schrieb aber schon das er momentan "ACK's" sendet wenn ich mich recht erinnere. Vieleicht kann "Wowie" das mal genau erklären.

Zitat

Wie es aussieht, sieht man dann am Ruckeln auf dem OSD.

Aha, habe ich noch nicht gehabt. Welche Updaterate braucht man denn für eine "ruckelfreies Display"? Ich würde davon ausgehen das niemand in der Lage ist mehr wie 3 updates pro Sekunde zu vearbeiten. Und dann wäre er schon gut.

Zitat

Sich gegen eine extra Bestückung von Sensoren zu wehren ist glaube ich nicht klug, man kann die Verwendung und Bestückung ja optional halten, das macht das OSD nur flexibler,

Es macht wenig sinn etwas gegen ein "optionales" Bauteil zu haben.

Hallo

Datenübertragung erfolgt seriell und die Daten werden vom EPI-OSD angefordert sofern man es aktiviert hat. Default ist allerdings eingeschaltet.

Die Updaterate liegt bei ca. 10Hz für Nick, Roll und Spannung.

Wenn eine NaviCtrl mit im Verbund ist werden auch dort die Daten angefordert unabhängig von der FC. Somit erkenne ich, ob die GPS-Daten mit angezeigt werden müssen.

Beim Höhensensor bilde ich einen Mittelwert über 5 Messungen. D.h. die Updaterate liegt bei ca. 2 Hz.

Das ist einfach zu wenig. und ich habe eine Latenz von 0,5 sec. Das sieht man schon.

Bezüglich Stromverbrauch wegen einem weiteren Sonsor sollte man sich keinen Kopf zerbrechen.
1mA beim Messen, standby 0,1µA. und so groß das er auch in eine Armbanduhr reinpasst.

Betr.: NaviCtrl unterhält sich mit der FC über SPI.

Gruß Wolfgang

wowie meinte

Die Updaterate liegt bei ca. 10Hz für Nick, Roll und Spannung.

Wenn eine NaviCtrl mit im Verbund ist werden auch dort die Daten angefordert unabhängig von der FC.

Das OSD lässt sich also gleichzeitig von zwei unterschiedlichen seriellen Devicen die am gleichen Kabel hängen Daten senden?!Das muss Probleme machen. Ich dachte immer die FC kriegt die Daten via SPI vom Navi-CTRL und "pumpt" die dann über serielle raus.

Zitat

Beim Höhensensor bilde ich einen Mittelwert über 5 Messungen. D.h. die Updaterate liegt bei ca. 2 Hz.
Das ist einfach zu wenig. und ich habe eine Latenz von 0,5 sec. Das sieht man schon.

2HZ ist zu wenig, aber mehr wie 4 muss es meines erachtens nicht sein weil das kein mensch mehr verarbeiten können sollte.

Was hälst du eigentlich generell von der Idee die OSD-Daten per audiokanal zu boden zu pumpen und das OSD dort laufen zu lassen? Laut meinen Berechnungen kriegt man ohne HW compression locker 30HZ update raten zu boden. Incl. Protokoll-Overhead.

Gruss,

Arnd

Haben wir dann nicht ein Fehlerkorrekturproblem, wenn wir das ueber nen analogen kanal schieben?

lephisto meinte

Haben wir dann nicht ein Fehlerkorrekturproblem, wenn wir das ueber nen analogen kanal schieben?

CRC? Fehlerhafte Pakete kann man einfach ignorieren und das nächste nehmen. Es sind wie gesagt problemlos 30HZ update rate möglich und wir brauchen laut "Wowie" nur 10. Sehr wahrscheinlich reichen auch 4-6HZ update. Wie hoch da die Fehlerrate sein darf kannst du dir j ausrechnen.

Hallo

es hängen keine 2 ser. Devices am selben Kabel.

Das OSD hat 2 serielle Schnittstellen und die Navictrl auch. Also gibt es auch kein Problem.

2 Sender auf einer geht leider nicht. Zumindest nicht einfach.

Gruß Wolfgang

@Tycho-x
den Audio kanal unbedingt für so etwas nutzen zu wollen, halte ich etwas für Fragwürdig, damit kann man es auch nicht jedem Recht machen.
Zum Beispiel finde ich die Geräusch Kulisse mit dem Summer als feedback beim Fliegen nicht schlecht.....

außerdem kann man nicht immer einfach so den Digitalen Ausgang vom Atmel , für die Daten Übertragung, an den analogen Audiokanal stecken und
ich will kein Akustikkoppler in meinem Kopter mitfliegen lassen (Scherz !)
http://de.wikipedia.org/wiki/Bild:Coupleur-accoustique-IMG_0298.JPG

Zitat

Das OSD lässt sich also gleichzeitig von zwei unterschiedlichen seriellen Devicen die am gleichen Kabel hängen Daten senden?!Das muss Probleme machen. Ich dachte immer die FC kriegt die Daten via SPI vom Navi-CTRL und "pumpt" die dann über serielle raus.

wenn das mit einem gescheiten acknowledgement geregelt ist und es eine Anfrage an Navi stellen kann, mit sende mir Daten
und dann eine Anfrage an Fligth ctrl mit jetzt sende du Daten, dann funkioniert das einwandfrei

@WoWie
ich dachte zuerst das Navi Board benutzt beide Schnittstellen von der Flight ctrl.
Aber so ist es natürlich besser.
Mir sind im Moment nur nicht die Umstände klar, was die Anzeige auf dem OSD wirklich verlangsamt, wenn man es auf Bluetooth-Sercon stellt.
Schickt die Fligth ctrl dann seltener Daten und ist die OSD dann in einem stillen lausch Mode, was den RX auf der Fligth ctrl für die serielle Kommunikation via Bluetooth-Sercon-GPS freihält ??
Umgekehrt, wenn Bluetooth nicht aktiviert ist, werden dann vom OSD immer laufend die Daten von der Fligth ctrl angefragt ?

Hallo

Wenn BT/PC aktiv ist, wird die TX Leitung vom OSD hochohmig und läßt somit die Kommunikation von BT und FC zu. Das OSD sendet dann auch keine Daten. Es lauscht nur noch an der RX-Leitung.

Die FC sendet im Takt von ca. 2HZ die Debug.out Daten selbständig.

Das BT/PC == Koptertool fordert die Daten dann selbst an, da kann man die Refesh-Zeit soviel ich weis auch einstellen.


Gruß Wolfgang

PS: Ich mal mal ein Bild und setze es ins Wiki unter OSD

wowie meinte

2 Sender auf einer geht leider nicht. Zumindest nicht einfach.

Wie meinst du das? Die Idee wäre die Telemetriedaten über den Audio-Kanal eines AV Senders zu schicken. Alternativ ging natürlich auch XBee. Das wäre sogar einfacher.

tycho-x meinte

wowie meinte

2 Sender auf einer geht leider nicht. Zumindest nicht einfach.

Wie meinst du das? Die Idee wäre die Telemetriedaten über den Audio-Kanal eines AV Senders zu schicken. Alternativ ging natürlich auch XBee. Das wäre sogar einfacher.

Jetzt plötzlich? Ich dachte du wolltest ein zweites Funkmodul unbedingt vermeiden?
Ich finde es ja löblich, dass du die ganze MK- Elektronik verkleinern möchtest, aber ich denke du bist dir der Schwierigkeit dieses Unterfangens nicht ganz bewusst. 50x50mm sind nun mal recht wenig und selbst beim besten Willen wird jeder, der sich ein Redesign der Hardware mit dem Ziel der Miniaturisierung vornimmt, sehr bald wieder vor einem Turm aus FC, NavBoard, OSD, Sender usw. landen. Sogar wenn einem mehrlagige Layouts, Bestückungsautomaten und Reflowöfen zur Verfügung stehen, mit denen man ultra-kleine Bauteile einsetzen kann, setzen einem andere Komponenten, für die es keine Alternativen gibt, sehr schnell Grenzen. Das Preis-/Leistungsverhältnis wäre dann sowieso jenseits von Gut und Böse.
Ist nicht böse gemeint, aber ich habe das Gefühl dein Enthusiasmus lässt dir die Dinge ein wenig einfacher erscheinen, als sie sind. So geht es anfangs allen hier

Zum "Schluss" noch kurz zwei bis drei "fachliche" Aspekte: 2.4 GHz Datenmodem und analoge Videoübertragung auf derselben Frequenz geht nicht gut, auch wenn schon anderes behauptet wurde. Schon nach relativ kurzen Distanzen wird die Bildqualität entsetzlich schnell schlechter.
Ob man über den Audiokanal genügend schnell Daten für ein OSD übertragen kann, wage ich immer noch ein wenig zu bezweifeln. Ich würde das gerne mal selbst testen, aber momentan fehlt mir leider die Zeit dazu. Problematisch ist, dass du vermutlich nicht einfach die UART dranhängen kannst und unten dann alles wieder schön als Datenstrom rauskommt. Du müsstest die Daten noch codieren, damit sie überhaupt über den Audiokanal übertragen werden können (Stichwort: Manchester- Code). Ich habe Berichte von etwa 4800 Bit/s gelesen, welche mit dieser Technik möglich seien. Wenn du nur die Akkuspannung, Höhe und ähnliche Werte in rein numerischer Form darstellen möchtest, dann wirst du mit 5 Hz Update- Rate vermutlich glücklich. Für ein HUD mit "künstlichem Horizont" sollten es aber schon 20- 30 Hz sein, wenn du kein Ruckeln mehr sehen möchtest. Da ich mich nicht mit ein paar Zahlen und einem Akkuspannungsbalken zufrieden gebe, ist das natürlich für mich nichts. Vor allem fehlt mir auch der Uplink zum Quadrokopter.

Ich gebe zu, dass ist meine ganz persönliche Sicht und die wiederspiegelt selbstverständlich nicht die Vorstellungen anderer OSD- User

Gruss
Patrick

Hallo

Ihr triggert auf irgendwelche Worte die in keinem Zusammenhang stehen.

wowie meinte

Hallo

es hängen keine 2 ser. Devices am selben Kabel.

Das OSD hat 2 serielle Schnittstellen und die Navictrl auch. Also gibt es auch kein Problem.

2 Sender auf einer geht leider nicht. Zumindest nicht einfach.

Gruß Wolfgang

Sender == TX auf einer seriellen war gemeint und nichts anderes

Danke für deine Ausführungen Crossfire, das Posting war wirklich sehr gut. Anerkennung und es wirklich auf den Punkt gebracht.

Gruß Wolfgang

ich schließe mich dem Lob für den Crossfire Beitrag an.

Möchte aber gerne nochmal auf den Seriellen Schnittstellen herumreiten ;-)
Die Fligth ctrls mit den 644p haben ja auch zwei davon, eigentlich könnte man die eine serielle dann ja für die Daten, ungestört in brauchbarer Geschwindigkeit, zum OSD verwenden. Oder ?
Dazu müsste man nur die Fligth ctrl Firmware etwas anpassen.
Dann hätte man den Standard Port auf der Fligth ctrl für Killagreg GPS und Bluetooth-Sercon frei.

schönen Sonntag
Gruß
Christian

Hallo

Bedingt aber spezielle FWs für die FC. Das wollte ich vermeiden.

War aber am Wochenende aktiv und hab mal das Display des OSD neu designed.

In der Mitte eine feststehende Nase, darüber Pfeil ( Auf/ab/neutral) fürs Vario. Unter der Nase Vario in Zahlen und darunter die Höhe über Grund.

Die Balkenanzeige ist noch da, aber daneben Spannung und Strom in Zahlen.

Hoffe das Wetter spielt mit und ich kann mal Probefliegen. Danach wird die FW freigegeben.

So die Vorbereitungen sind soweit fertig. Jetzt kann die EPI-ES auch getestet werden.


Gruß Wolfgang

Hallo wowie,

kannste mal das ein oder andere Bild einstellen?

Hallo fm2241

ja mache ich Morgen. Muss erst fliegen.

Gruß Wolfgang