Vorüberlegungen zu meiner Diplomarbeit

[WhiteVelvet]

In 2 Monaten beginne ich mit meiner Diplomarbeit, wo ich eine Software in C++ schreiben werde, die von einer 3D-Kamera die Daten über IEEE1394 annimmt, visualisiert und analysiert. Nun fange ich aber schonmal an, Vorüberlegungen zu machen. Zum Beispiel wie einfach oder schwer ist es, Daten vom Firewire-Anschluss abzugreifen. Wie viel Zeit muss ich dafür einplanen, wenn ich noch nie soweit in die Hardware programmiert habe? Ich muss sowieso mal sehen, wie viele Programmteile ich von anderen verwenden darf. Wenn also schon jemand einen Port für Firewire programmiert hat, darf ich den dann weiterverwenden oder muss ich das Rad neu erfinden.
Dann noch eine Frage: Ich werde die Kamera nicht immer an den PC angeschlossen haben und ich muss viel mit Simulationsdaten arbeiten. Ich habe mir dazu folgendes überlegt: Ich lese den Datenstrom vom Firewire aus und speichere ihn in eine Datei. Dann schreibe ich ein Hilfsprogramm, das diese Daten in einer Schleife irgendwohin streamt. Aber wohin genau? Kann ich an einen Port streamen, den ich dann mit dem Hauptprogramm abfrage? Oder kann ich das auf den Firewire-Anschluss ausgeben und gleichzeitig wieder einlesen?
Fragen über Fragen, aber vielleicht hat von Euch ja noch wer Ideen und Anregungen

[Senior Sanchez]

Zitat von WhiteVelvet:

Dann noch eine Frage: Ich werde die Kamera nicht immer an den PC angeschlossen haben und ich muss viel mit Simulationsdaten arbeiten. Ich habe mir dazu folgendes überlegt: Ich lese den Datenstrom vom Firewire aus und speichere ihn in eine Datei. Dann schreibe ich ein Hilfsprogramm, das diese Daten in einer Schleife irgendwohin streamt. Aber wohin genau? Kann ich an einen Port streamen, den ich dann mit dem Hauptprogramm abfrage? Oder kann ich das auf den Firewire-Anschluss ausgeben und gleichzeitig wieder einlesen?
Fragen über Fragen, aber vielleicht hat von Euch ja noch wer Ideen und Anregungen

Dazu bieten sich doch TCP-Socket an
Du schreibst nen kleines Programm, dass von Firewire lesen kann und dass die Daten einfach auf nem TCP-Port wieder streamed.

Dein Hauptprogramm (das halt analysiert) brauch sich nur auf den Port verbinden und wird mit Daten gefüttert. Wenn de nun den Simulator auch auf diesem Port operieren lässt, ist es dem Hauptprogramm völlig latte, ob es ne Simulation ist oder nicht und eine pot. Fehlerursache (nämlich der Unterschied zwischen Simulation und echt) sollte somit beseitigt sein

[WhiteVelvet]

Hört sich gut an, so stelle ich mir das vor. Ich will im Hauptprogramm dann quasi nur einen Schalter umlegen und er liest von Firewire oder von dem TCP-Socket.

[Senior Sanchez]

Zitat von WhiteVelvet:

Hört sich gut an, so stelle ich mir das vor. Ich will im Hauptprogramm dann quasi nur einen Schalter umlegen und er liest von Firewire oder von dem TCP-Socket.

Naja, so meinte ich das nicht ganz

Ich meinte das mehr so:

Firewire-Leser ----- via TCP/IP -----> Hauptprogramm
Simulator ----- via TCP/IP -----> Hauptprogramm

Das Hauptprogramm greift nur auf den TCP-Port zu, was anderes interessiert es gar nicht. So ist es ihm dann völlig egal obs nun per Firewire ankommt oder ne Simulation ist. Da brauchste dann also keinen Schalter im Hauptprogramm mehr.

[ScottManDeath]

Die Daten würde ich (unter Windows) mit einem selbstgeschriebenem DirectShow Filter auslesen. Ich hatte damals ein SDK Sample manipuliert um an die Frames ranzukommen.

Vorteil der Sache, Du nutzt alle Codecs die benötigt sind. AFAIK ist das DirectShow SDK inzwischen vom DirectX SDK ins Plattform SDK gewandert.

[ScottManDeath]

Je nachdem was Du für eine Sprache und/oder System Du nutzt, kannst Du einfach Komponenten schreiben, eine für Daten von Firewire lesen, eine für Daten aus Datei laden, eine fürs analysieren, eine fürs Speichern. Dann kannst Du in Deinem "Hauptprogramm" einfach die passenden Komponenten zusammenstöpseln.

[WhiteVelvet]

@Senior Sanchez: Stimmt, jetzt verstehe ich was Du meinst, das klappt natürlich auch. Allerdings frage ich mich, ob ich mich dadurch nicht durch TCP/IP abhängig mache. Es kann passieren, dass die Software später auf einem Roboter eingesetzt wird und weiss natürlich nicht, ob da überhaupt TCP/IP verfügbar sein wird Daher würde ich es nur zu sim-Zwecken nutzen und die Hauptdaten direkt vom Firewire abgreifen.

@ScottManDeath: Muss ich mich mal in DirectShow einarbeiten. Bisher kenne ich das alles nur aus dem Grafikbereich. Die Daten von der 3D-Kamera sind echte 3D Daten in einem speziellen Format, keine 2D DV-Daten. Ausserdem möchte ich auf Linux-Kompatibilität achten. Mal sehen, was sich noch findet als Schnittstelle. Der Prof meinte nur, ich sollte irgendwie einen Kontakt mit dem Firewire-Treiber aufnehmen.

[ScottManDeath]

Weißst Du, wie andere Software and die Daten rankommt, bzw. gibts für die Kamera kein SDK? Bin mir nicht sicher ob DirectShow auch andere Datenformate außer Audio und Video verarbeitet.

[Demirug]

Zuerst würde ich das ganze über ein Interface entkoppeln. Dann kannst du zwei Klasse schreiben die dieses Interface implementieren. Eine für den echte Hardware zugriff und eine für die Simulation. Zum anderen bist du dann auch variable für andere Hardware.

Was die Linux-Kompatibilität angeht so wirst du wahrscheinlich auch dafür zusätzlichen Code schreiben müssen den gerade im Bereich der Hardware ansteuerung gibt es ehrhebliche Unterschiede. Gleiches gilt dann für die UI. Wenn du Linux-Kompatibilität haben willst musst du gleich von Anfang an einen GUI Framework benutzten der sowohl auf Windows wie auch auf Linux verfügbar ist. Nicht zu vergessen das du das ganze dann fortwährend immer auf beiden Platformen testen musst.

Was die Ansteuerung der Kamera selbst angeht kann ich nicht viel dazu sagen da ich nicht weiß was dort an Treibern mitgeliefert wird bzw. als welche Art von Gerät sie sich meldet.

[Monger]

Nur so mal interesseweise: Wieviel Zeit hast du denn für die Diplomarbeit?

Imho ist das nämlich ein ziemlich kräftiges Stück Arbeit, vorallem weil es viele Teilgebiete umfasst:

- Hardware (Kamera)
- Netzwerk
- Simulator
- Visualisierung
- Bild-Analyse

An deiner Stelle würde ich versuchen, den Aufwand für jedes Teilgebiet möglichst präzise zu schätzen. Je nachdem über welche Zeiträume du planen musst, lohnt es sich möglicherweise, erstmal ein, zwei Wochen nur Infos zu sammeln um zu sehen, wieviel Arbeit du dir an welcher Stelle sparen kannst. Wenn du z.B. ein gutes Tutorial zur Anbindung an einen Firewire Port für C++ findest (wovon ich ausgehe, das ist ja keine exotische Anwendung), bist du an der Stelle fix fertig. Wenn du aus irgendeinem dämlichen Grund da erst nah an der Hardware rumbuddeln musst, können dafür alleine schonmal locker ein paar Wochen drauf gehen.

Meine Vermutung ist, dass du mit großem Abstand am meisten Zeit für den Simulator und für die Analyse brauchen wirst. Netzwerk sollte kein Akt sein, Anbindung an den Kameratreiber sollte gehen (wenn der nicht existiert, kannst du es sowieso vergessen), Visualisierung sollte auch nicht so das Problem sein. Aber je nachdem was du mit deinem Simulator alles simulieren willst und wie weit du es mit der Analyse treiben willst, kann das sehr igitt werden.

[WhiteVelvet]

Ich denke dir Linux-Kompatibilität wird nicht so ein Akt werden, ich habe bereits in einigen anderen Praktika C++ für beide Plattformen geschrieben. Wenn ich mich nicht irre, war es Qt, das ich dafür einsetze, das läuft auf beiden Plattformen.

Offiziell habe ich 4 Monate Zeit, aber der Prof räumt mir netterweise einen Monat als Vorlaufzeit ein und ich werde noch einen Monat vorher beginnen mit Testsoftware, womit ich einfach nur mal aus Spass meine DV-Cam ansprechen will. Wenn das klappt, habe ich das schonmal gelöst. Die 3D-Kamera hat wohl einen eigenen Treiber und meine Simulationssoftware wird danach nicht länger als ein paar Tage in Anspruch nehmen. Sie soll ja nur lesen, in Datei schreiben und später aus Datei lesen und ausstreamen. Das ist sicher nicht viel Codeaufwand. Netzwerkmässig muss ich doch gar nichts machen, ausser einen TCP-Socket anzusprechen, mit den richtigen Tutorials sollte das auch nicht lange dauern. Gerade diese Simulationsgeschichten sind allein meine Idee und keine geforderten Aufgaben, also muss ich diese so oder so möglichst klein und unaufwändig halten.

[Darkstar]

Ist in den vier bzw. sechs Monaten auch der schriftliche Teil enthalten? Mal so eben 80–100 Seiten schreiben, formatieren und korrekturlesen dürfte nämlich auch noch etwas Zeit in Anspruch nehmen.

[WhiteVelvet]

Zitat von Darkstar:

Ist in den vier bzw. sechs Monaten auch der schriftliche Teil enthalten? Mal so eben 80–100 Seiten schreiben, formatieren und korrekturlesen dürfte nämlich auch noch etwas Zeit in Anspruch nehmen.

Ja, das ist inbegriffen. 70 Seiten sollten es werden meint der Professor. Er meinte, das wären 3 Wochen. Das passt schon, das ist momentan das kleinste Problem.

[ollix]

Denke auch das der schriftliche Teil nicht das größte Problem sein wird - seit ihr denn fest auf 6 Monate? Bei uns war das damals effektiv so, daß man sein Thema bearbeitet hat und wenn man fertig war, hat man angemeldet und abgegeben.

[ScottManDeath]

Huch, 3 Wochen für 80 Seiten? Ich hab in 6 Wochen 45 geschafft.

Kann es auch Java sein? Zumindest für GUI und Kommunikation wäre das auch eine Option. Den HW Kram dann z.B. über das Java Native Interface machen.

[WhiteVelvet]

Bei uns schreiben D-I-Diploma 4 Monate und D-II Diploma 6 Monate. Diesen Unterschied gibt es nur in NRW. Der Prof meinte ich solle ruhig schonmal anfangen und wenn ich gut dabei bin, sollte ich mich anmelden. So werd ich es auch machen.

Die Sprache ist mir im Prinzip freigestellt, aber der Prof will es lieber einheitlich haben, weil alle anderen in dem Forschungsbereich auch C++ programmieren. Ich bin eher Delphi-Programmierer (9 Jahre Erfahrung), dann kommt Java (wenig Erfahrung, bisher nur durch Vorlesung und ein Praktikum) und dann C++ (ein Praktikum letzten Winter). Das Programmgerüst werde ich schon irgendwie hinbekommen, es ist ja doch alles ähnlich. Bloss für die GUI habe ich noch keine Idee. In dem Praktikum vom letzten Winter haben wir Qt benutzt, denke das werde ich dann auch machen. Gibt aber genügend Leute dort die ich fragen kann. Ich soll MS Visual Studio 6 benutzen, mal sehen, wie es ist. Ich habe letzten Winter MS Visual Studio 2005 Beta benutzt, also sollte es ähnlich sein.

Zitat von WhiteVelvet:

Bei uns schreiben D-I-Diploma 4 Monate und D-II Diploma 6 Monate. Diesen Unterschied gibt es nur in NRW. Der Prof meinte ich solle ruhig schonmal anfangen und wenn ich gut dabei bin, sollte ich mich anmelden. So werd ich es auch machen.

Die Sprache ist mir im Prinzip freigestellt, aber der Prof will es lieber einheitlich haben, weil alle anderen in dem Forschungsbereich auch C++ programmieren. Ich bin eher Delphi-Programmierer (9 Jahre Erfahrung), dann kommt Java (wenig Erfahrung, bisher nur durch Vorlesung und ein Praktikum) und dann C++ (ein Praktikum letzten Winter). Das Programmgerüst werde ich schon irgendwie hinbekommen, es ist ja doch alles ähnlich. Bloss für die GUI habe ich noch keine Idee. In dem Praktikum vom letzten Winter haben wir Qt benutzt, denke das werde ich dann auch machen. Gibt aber genügend Leute dort die ich fragen kann. Ich soll MS Visual Studio 6 benutzen, mal sehen, wie es ist. Ich habe letzten Winter MS Visual Studio 2005 Beta benutzt, also sollte es ähnlich sein.

Wenn mit Visual Studio 6 auch VC++ 6.0 eingeschlossen ist, dann viel Spass. Dieser alte Dreckskompiler trieb mich fast in den Nervenzusammenbruch. Wenn du die Option hast, dann nimm bitte was anderes. (Ich hab dann meine 2003er Studioversion aus unserem SWT genutzt).

edit: und komm ja nicht auf die doofe Idee deine Arbeit mit Word zu schreiben. Da hör ich rechts neben mir immer wieder heftiges Fluchen. Da ist zwar ein Wordbuch vorhanden, trotzdem verhaut es dauernd Formatierungen und es fehlen Sätze, weil die als Kommentar markiert sind (was eine hauchfeine gepunktete Linie ist).

[WhiteVelvet]

Zitat von noid:

Wenn mit Visual Studio 6 auch VC++ 6.0 eingeschlossen ist, dann viel Spass. Dieser alte Dreckskompiler trieb mich fast in den Nervenzusammenbruch. Wenn du die Option hast, dann nimm bitte was anderes. (Ich hab dann meine 2003er Studioversion aus unserem SWT genutzt).

edit: und komm ja nicht auf die doofe Idee deine Arbeit mit Word zu schreiben. Da hör ich rechts neben mir immer wieder heftiges Fluchen. Da ist zwar ein Wordbuch vorhanden, trotzdem verhaut es dauernd Formatierungen und es fehlen Sätze, weil die als Kommentar markiert sind (was eine hauchfeine gepunktete Linie ist).

Tja, mal sehen wie der Compiler ist, werde ihn die nächsten Tage mal austesten. Ist mir aber schon öfters aufgefallen, dass meine Uni die unmöglichste Software benutzt: VS 6.0 statt VS 2005, Maya statt 3DMax, Pinnacle Liquid statt Adobe Premiere...

Mit Word habe ich nun wirklich kein Problem Habe schon so viel Text damit geschrieben, dass ich schon weiss wo die Haken sind und wie man sie abschaltet. Mal abgesehen davon werde ich wahrscheinlich sowieso an einem Laptop schreiben, sobald ich den habe, und da installiere ich OpenOffice.

[Senior Sanchez]

Zitat von noid:

edit: und komm ja nicht auf die doofe Idee deine Arbeit mit Word zu schreiben. Da hör ich rechts neben mir immer wieder heftiges Fluchen. Da ist zwar ein Wordbuch vorhanden, trotzdem verhaut es dauernd Formatierungen und es fehlen Sätze, weil die als Kommentar markiert sind (was eine hauchfeine gepunktete Linie ist).

Was sollte man stattdessen nutzen?

[Expandable]

Zitat von Senior Sanchez:

Was sollte man stattdessen nutzen?

LaTeX.