Foren Aktuelles Erstellen Mitglieder Anmelden

Der "gute Laune"-Thread

Benutzer, welche sich diesen Thread anschauen:

Nach 2 Jahren Anlauf haben es mein Mitbewohner und ich endlich mal geschafft den alten Güterbahnhof bei uns zu erkunden, eine wahnsinnig geile Industrie Ruine, daneben ist auch noch ein alter Ringlokschuppen. An Westseite der Gebäude sind mehrere Discos drin, das hat n besonderes Flair da feiern zu gehen, aber nun haben wir es endliche mal in die hinteren Teile geschafft. Kameras haben wir leider keine mitgenommen, aber wenn ich nochmal ne Spiegelreflex mein eigen nennen werde, weiss ich wohin ich zurückkomme. :dhoch:

Hier sind ein paar Fotos aus dem Inet, um mal einen kleinen Eindruck zu schaffen:

dji_6128tm.jpg


13367112.jpg


os03.jpg
 
el_barto schrieb:
eMKay schrieb:
el_barto schrieb:
Geilo, grade im Assemblerprogrammierungslabor ne Stunde früher fertig gewesen :)
Dabei dachte ich, heut is die schwerste Aufgabe.
Sollten nen Lego-Mindstorm-Roboter, der ne Custom-Firmware drauf hat, so dass man den ARM-Prozessor direkt mit Assembler-Befehlen programmieren kann, mit PID-Regelung als inverses Pendel programmieren.
Das Ding steht also auf 2 Rädern, deren Motoren wir abhängig von nem Lichtsensor so regeln mussten, dass der Roboter im Gleichgewicht bleibt und nicht umkippt. Ging erstaunlich gut von der Hand, selbst anschubsen hat ihn nicht aus der Ruhe gebracht :dhoch:

Hat der einen Neigungssensor oder wie erkennt Ihr, dass er im Gleichgewicht ist?
Wo hat der denn Lichtsensoren? Sind das sie, die die Radumdrehung zählen?

Ne, der hat nur nen Lichtsensor mit nebenanliegender LED vor den Rädern.
[vid]http://www.youtube.com/watch?v=VO-oN5a2ZtY[/vid]
Das is n Vid aus nem vergangenem Semester, der Lichtsensor ist vorne, n paar cm überm Boden.
Wenn man das Programm startet, wird der aktuelle Rückgabewert des Sensors als Sollwert gespeichert. Daher muss der Roboter zum Programmstart auch ausbalanciert sein.
Kippt das Ding jetzt vor oder zurück, verändert sich ja durch die sich ändernde Entfernung zur Tischplatte der Rückgabewert des Sensors (Platte weiter weg --> empfangenes Signal dunkler), und über den PID-Regelkreis steuert man die Räder so an, dass die Kipplage ausgeglichen wird, das ganze logischerweise in ner Endlosschleife.


Was macht er, wenn du das Licht an und ausschaltest im Raum, oder jemand vorbeiläuft und einen Schatten wirft, oder wenn sich die farbe des Bodens ändert?

Ich kenne das vom Asuro Roboter, da habe ich auch mit Lichtsensoren gearbeitet. Einerseits konnte man da eine Linienverfolgung machen, ich habe eine Art Morsecodesensor realisiert. Es war aber verdammt anfällig für Streulicht oder generell Lichtänderungen.

Mit was hast du das geschrieben (compiler etc?), wenn du sagst dass du den ARM direkt programmiert hast? Hast du den PID in Assembler selbst geschrieben? Das hört sich schon nach einer schlampe an. :skep:
 
Jap, hab den ARM in Assembler programmiert :D
War ja auch die Übung zur Vorlesung Assemblerprogrammierung^^
Man muss aber sagen, dass wir nicht das ganze Programm schreiben mussten (geht in 2 Stunden nicht wirklich), sondern nur einen bestimmten Ausschnitt. Wir bekommen ein fertiges C-Programm, das auf Subroutinen referenziert, die wir direkt in Assembler schreiben.
Bei den anderen Aufgaben (Line Follower und Grabber, letzterer hat farbige Bälle anhand des Lichtsensors erkennen und unterscheiden können) waren es nur kleinere Fragmente, wie Sensorauswertung und Motoransteuerung, bei dem hier mussten wir aber so ziemlich alles bis auf die Aufnahme des Referenzwerts in Assembler geschrieben.
Vor allem if-then-else-Schleifen und so Zeug, das man in Hochsprachen in einer Zeile schreiben kann, sind extrem fies in Assembler, die wurden deshalb meist im C-Programm abgehandelt.

War bei der Vorbereitung auch ziemlich verzweifelt, da ich nicht wusste, wie ich die Integration und Differentiation aus dem PID-Kreis implementieren soll. Wir durften aber stark vereinfachen^^
Die Integration war dann die Addition von jetzigem und vorherigem Sensorwert, multipliziert mit einer Konstante, die Differentiation war die Differenz... Geklappt hats trotzdem :D
Naja, war ja auch nicht Mess- und Regeltechnik, es ging ja mehr um das Programmieren an sich.

Was passiert wär, wenn die Oberfläche die Farbe gewechselt hat, wär echt interessant gewesen... Ich denk mal, die regelung hätte nicht mehr funktioniert. Schatten von vorbeilaufenden Personen sind egal, da ja neben dem Sensor eine relativ starke LED war.
 
Ah ok, so klingt das ganze dann doch wieder machbar (einfach möchte ich nicht sagen) :)
Auf jeden Fall ein interessantes Konzept.

Hättest du es nicht aber auch sinnvoller gefunden gleich alles in C zu machen? Ich habe meinen Asuro damals in C programmiert und dann den ganzen Kram durch einen compiler gejagt und das hex file geflasht.
 
Jo, an sich wärs natürlich sinnvoller gewesen, aber man muss es eben im Kontext sehen. Da es halt ne Assembler-Übung war, wärs relativ sinnlos gewesen, direkt in C zu programmieren (noch dazu kann ich C nicht schreiben, hab nur Java gelernt. Da sich aber beide in der Syntax ähnlich sind, versteh ich C-Programme beim lesen einigermaßen).
Aber es war auf jeden Fall ne tolle und lehrreiche Alternative zu schnöden Aufgabenblatt-bearbeiten-Hörsaal-Übungen. So behalt ich den ganzen Kram wenigstens im Kopf, da ich schon damit gearbeitet hab und es nciht nur vom Papier kenn.
 
döschensam schrieb:
spielt mingo nicht sogar golf ? und der ist armer student.

Ja, habe allerdings Golf als Seminar im Rahmen meines Sportstudiums gewählt.
Das macht so riesen Bock, leider kann ich nur noch dieses Semester kostenlos spielen, danach müsste ich Moneten springen lassen. :(
 
Hab mir das jetzt 5 mal hintereinander angehört und hab jetzt echt gute Laune.
Des is so sche liab.

[vid]http://www.youtube.com/watch?v=ybHKyYhFK-k[/vid]
 
Zurück
Oben