Erlebnisbericht: Hardwarepraktikum Robotik

[](http://www.karllorey.de/wp-content/uploads/2012/04/hardwarepraktikum_robotik_roboter.png)

Da im Sommersemester 2012 an der Universität Würzburg wieder die Möglichkeit besteht, das Hardwarepraktikum in Robotik zu absolvieren und ich wiederholt nach meinen Erfahrungen im Hardwarepraktikum Robotik gefragt wurde, ist es wohl an der Zeit dies schriftlich festzuhalten.

Das Hardwarepraktikum an der Uni Würzburg

Jeder Informatik-Student muss während seines Studiums neben dem Java-Programmierpraktikum und dem Softwarepraktikum auch mindestens ein Hardwarepraktikum absolvieren. Es stehen hierbei drei verschiedene Praktika zur Auswahl:

Möglichkeiten ein Hardwarepraktikum an der Universität Würzburg zu absolvieren

• Hardwarepraktikum Prozessorbau (Kolla)
• Hardwarepraktikum Netzwerktechnik (Tran-Gia)
• Hardwarepraktikum Robotik (Busch)

Das Hardwarepraktikum Robotik ist nur während des Semesters und nicht in den Semesterferien zu absolvieren. Es wird von Stephan Busch betreut und findet in der Robotik-Halle hinter dem Informatik-Gebäude statt. Die Arbeit findet wie bei anderen Praktika im Team von zwei oder mehr Personen statt. Ich denke, dass man zudem zumindest die Rechenanlagen-Vorlesung besucht haben sollte.

Phasen des Hardwarepraktikum Robotik

1. Bau eines Grundgerüsts aus Fisher-Technik
2. Aufbau des Mikroprozessors sowie Anschluss und Kalibrierung der Sensoren
3. Implementierung von Lokalisation, Pfadverfolgung und anderen Features
4. Abschlussbesprechung mit Theorie-Fragen sowie Roboter-Test und -Präsentation.

Um meine Erfahrungen strukturiert und möglichst neutral zu halten, habe ich eine Liste mit positiven und negativen Punkten erstellt. Nichts desto trotz bleiben meine Eindrücke natürlich weiterhin subjektiv. Wir haben Stephan Busch unsere Erfahrungen nach Abschluss des Hardwarepraktikums sowohl schriftlich, als auch im Gespräch mitgeteilt.

Positiv

Eigenständiges Arbeiten

Die Arbeit am Roboter findet zu jeder Zeit im Team, jedoch ohne direkte Betreuung statt. Man arbeitet also völlig eigenständig, kann jedoch bei Bedarf Stephan Busch um Hilfe bitten. Die Einarbeitung in den Mikroprozessor findet per User Guide und Google statt.

Freie Zeiteinteilung

Dem Student steht es völlig frei, wann er sich um das Hardwarepraktikum Robotik kümmert. Einzige Voraussetzung ist, dass sich jemand in der Robotik-Halle befindet. Dies ist meistens ungefähr von 9 Uhr bis mindestens 18 Uhr der Fall. Wir haben als Zweier-Team über das Semester verteilt circa zehn Stunden pro Woche am Roboter gearbeitet.

Interessantes Thema

Wer baut nicht gerne einen Roboter? Im Vergleich zu den Hardwarepraktika Netzwerktechnik und Prozessorbau ist das Thema meines Erachtens ansprechend und praxisorientiert. Auch die Arbeit ist abwechslungsreich, da ständig zwischen Bau, Programmierung und Test gewechselt werden muss.

Sympathische Betreuung

Stephan Busch ist ein äußerst freundlicher, netter und ausgeglichener Betreuer. Dies sorgt er für ein wirklich sehr angenehmes Arbeitsklima.

Negativ

Fehlendes Feedback

Leider gibt es beim Hardwarepraktikum Robotik kein klares Feedback bis zur Abschlusspräsentation. Zwar existiert ein Trac (Projektmanagement-Software) in dem die einzelnen Zwischenschritte einzusehen sind, aber der Student erhält keine Rückmeldung darüber, wie gut seine Leistungen bisher sind. Die formulierten Milestones sind dafür zu knapp bzw. vage formuliert und natürlich statisch. Es fehlen aus meiner Sicht beispielsweise Zwischenprüfungen, aus denen hervorgeht, ob der Roboter bisher alles kann, oder ob von den Praktikumsteilnehmern nachgearbeitet werden muss. Da die Theorie auch eine größere Rolle als zunächst angenommen spielt, wären auch Tests zur Theorie wünschenswert.

Zu wenig Vorwissen als Informatiker

Für Informatiker gibt es wenig Möglichkeiten während des Informatik-Studiums schon Vorwissen anzusammeln. Gerade mit der Programmiersprache C oder etwas komplexeren Schaltungen wird man ins kalte Wasser geworfen. Dieses Vorwissen wird jedoch als Voraussetzung für das Hardwarepraktikum Robotik angesehen, weshalb während dem Praktikum keine oder wenig Zeit ist etwas nachzuholen.

Keine Möglichkeit der Heimarbeit

Mit dem Mikroprozessor/Roboter muss in der Robotik-Halle gearbeitet werden. Es ist nicht möglich den Prozessor mit nach Hause zu nehmen. Dies offensichtlich kein Fehler der Verantwortlichen, man sollte sich dessen trotzdem bewusst sein. Man kann also nur am Roboter arbeiten, wenn man auch in der Robotik-Halle ist. Die Arbeit muss also beendet werden, wenn in der Robotik-Halle die Tür geschlossen wird.

Keine Beachtung des Codes

Als Informatiker bemüht man sich meistens um einen sauberen und strukturierten Code. Dies war auch bei uns der Fall. Leider hatte Stephan Busch bei der Entscheidung, dass wir das Hardwarepraktikum Robotik bestehen, scheinbar noch zu keinem Zeitpunkt einen Blick auf unseren Quellcode geworfen, dessen Erstellung mindestens 60-70% der Arbeitszeit ausgemacht hat. Obwohl dies womöglich eine Lektion aus dem echten Leben ist, wo nur das Endprodukt zählt, empfinde ich dies bei einem Informatik-Praktikum (auch wenn es sich um Robotik handelt) doch als sehr enttäuschend und nicht verhältnismäßig. (Selbst wenn der Code ohne unser Beisein gesehen worden sein sollte, gab es zumindest zu keinem Zeitpunkt ein Feedback.)

Keine Berücksichtigung der Gruppengröße

Da beim Hardwarepraktikum Robotik die Gruppen selbst gewählt werden können, entstehen Gruppen von mindestens zwei und bis zu vier Personen. Beim Abschlussgespräch wurden wir als Zweier-Gruppe jedoch an den Leistungen der größeren Gruppen gemessen und somit keine Rücksicht auf die Gruppengröße genommen. Wir lagen als Zweier-Gruppe – was die Feature-Implementierung angeht – sicher nicht mehr als 10% im Vergleich zu anderen Vierergruppen zurück (bei halber Gruppengröße). Ich denke jedem ist klar, wie viel mehr eine Vierergruppe in einem Semester erreichen kann. Aus diesem Grund wäre eine Berücksichtigung der Gruppengröße durchaus angemessen gewesen.

Keine klar definierten Ziele und Organisationsmängel

Als großes Problem während des Hardwarepraktikums erwies sich immer wieder die Tatsache, dass sowohl uns, als auch anderen Teams nicht klar war, was eigentlich das Ziel zum Ende des Praktikums ist. Es war klar, dass der Roboter durch ein Labyrinth navigieren können muss, aber was implementiert sein muss und was nicht, war bis kurz vor Schluss völlig unklar (Muss-, Soll-, und Kann-Kriterien). Relativ früh hatte ein Team zum Beispiel einen Algorithmus entwickelt, wodurch ihr Roboter autonom aus dem Labyrinth finden konnte, allerdings ohne Lokalisation und Pfadverfolgung. Es stellte sich erst später heraus, dass Lokalisation und Pfadfindung zwingend implementiert sein müssen und das Herausfahren aus dem Labyrinth nicht als primäres Ziel, sondern eher als Bonus (wenn alles andere funktioniert) zu sehen ist.

Es wurde leider auch klar, dass Stephan Busch eine Liste (oder zumindest klare Vorstellungen) von dem hatte, was mindestens funktionieren können muss. Leider wurden diese Punkte weder herausgegeben, noch den Studenten zumindest mündlich (und rechtzeitig) mitgeteilt. Gerade der Sachverhalt, dass der zu implementierende Funktionsumfang scheinbar klar definiert, jedoch nicht klar genannt wurde, ist ein unnötiger Nachteil für Studenten und beeinträchtigt die Freude am Praktikum.

Auch in der Abschluss-Besprechung wurden plötzlich Theorie-Kenntnisse der Robotik gefragt, die während des Praktikums – wenn überhaupt – nur am äußersten Rand von Bedeutung waren. Es war bis dahin überhaupt nicht klar, dass bei dem Praktikum eine solche Auseinandersetzung mit der Theorie stattzufinden hat (Grad der Beweglichkeit, Interrupts auf Assembler-Ebene, u.v.m.). Es existierten zwar Fragen zur Selbsteinschätzung, diese waren aber bedeutend leichter als alles, was bei der Abschlusspräsentation gefragt wurde. Eine klare Angabe der nötigen Theorie-Kenntnisse oder detailliertere Fragen zur Selbsteinschätzung hätten hier sicherlich für mehr Klarheit gesorgt.

Ich möchte eindeutig darauf hinweisen, dass dieses Problem, wie die anderen Probleme auch, kein Problem der Machbarkeit, sondern nur eines der vorherigen Kommunikation und der Organisation des Praktikums ist:

• Natürlich kann man sich intensiv mit der Theorie befassen, aber das muss man das von vornherein wissen!
• Natürlich kann man sich besonders um ein bestimmtes Feature kümmern, aber auch das muss man von vornherein wissen und die Prioritäten kennen.

Fazit

Aufgrund der oben genannten, hauptsächlich organisatorischen Mängel kann ich das Hardwarepraktikum Robotik leider nicht empfehlen. Obwohl das Thema interessant ist, überwiegt nach einiger Zeit schnell die Frustration, die sich bis zum Schluss hält. Es fehlen klar definierte Ziele und angemessene Bewertungskriterien. Hier schneidet vor allem das Hardwarepraktikum Netzwerktechnik (Tran-Gia) mit wöchentlichen Bewertungen und begrenztem zeitlichen Rahmen im Vergleich deutlich besser ab. Auch vom Hardwarepraktikum Prozessorbau habe ich noch nichts schlechtes gehört, kann dazu aber auch nicht viel mehr sagen.

Falls sich jemand trotzdem entscheiden sollte das Hardwarepraktikum Robotik zu wählen, wäre ich für einen kleinen Bericht in den Kommentaren sehr dankbar. Auch gegenüber Kritik an meiner Sicht der Dinge bin ich offen.