Softwaretest
Wir schreiben Freitag den 15.02.2013, ein Teamtreffen steht an – dieses mal ist es aber doch etwas anders: Zum ersten mal wollen wir den Roboter mit unserer neuen Software in Betriebe nehmen und mit eiem Gamepad fahren.
Vor einem Monat haben wir erst die Entwicklungsumgebung eingerichtet.
Erst vor drei Wochen waren die Stummel für die notwendigen Klassen für diese Aufgabe fertig.
Vor einer Woche machte der Code auf den ersten Blick noch den Eindruck, dass alles noch etwas zusammenhangslos ist und der richtige Ablauf erst noch reinprogrammiert werden muss.
Diesen Ablauf haben der Teamleiter Peter Merkert und Stephan Gocht 3 Tage vor dem Start eingebaut.
Da es damit nun wirklich realistisch war die Deadline zu erreichen, wurde dies zwei Tage vor dem Start offiziell über alle Verteiler angekündigt, damit Interessenten bei dem Ereignis dabei sein konnten.
Am Donnerstag – dem letzten Tag – wurde Peter Merkert durch sein Einladungsrundschreiben am Vortag von Team Mechanik kontaktiert: Ein Lenkservo wurde vor einiger Zeit ausgebaut und noch nicht wieder eingebaut. Das wäre zum Fahren natürlich ungünstig.
Simon Merz, Mitglied im Team Mechanik und 1. Vorstand, hat sich bereit erklärt kurzfristig am Folgetag vorbei zu kommen und den Lenkservo einzubauen und bei Problemen zu helfen.
Freitag, 15.02.2013, 15 Uhr. Der Code von uns sollte soweit stehen und wir haben jetzt vor, diesen auf den Roboter zu portieren und auch zu starten. Aber bevor überhaupt einmal unser Programm gestartet werden kann, blockieren folgenden Steine unseren Weg:
Problem: Der PC im Roboter startet nach dem Stromanschluss nicht.
Lösung: Kurzschließen von den Startpins vom Mainboard löst einen PC Start aus. Problem: Bei jedem PC Start müssten die Pins kurzgeschlossen werden.
Lösung: Im BIOS die Einstellung setzen, dass der PC bei Stromanschluss sofort automatisch startet.
Problem: Nach dem Startproblem wurde der PC wieder in den Roboter eingebaut. Leider startet er wieder nach Stromanschluss nicht automatisch.
Lösung: Das BIOS hat sich zurückgesetzt, es mussten also wieder die Pins kurzgeschlossen werden.
Problem: BIOS hat sich zurückgesetzt.
Lösung: Die BIOS Batterie war fast leer. Zum Glück hat Alexandru Albu aus unserem Team eine baugleiche in seiner Tasche dabei! :D
Problem: Der PC im Roboter startet nun. Damit alle sonstige Bauteile im Roboter gestartet werden muss zuerst ein Schalter umgelegt werden, der eine rote LED als Anzeige hat und danach ein größerer weißer. Beim Umschalten den Ersten leuchtet die LED nicht auf.
Lösung: Es wurden Kabel neu verlötet und Kabel in Lüsterklemmen gefestigt. Es wurden auch die Akkus zuerst vergessen einzubauen, deshalb konnte kein Strom fließen. Leider hat dies alles nichts geholfen. Nach langer Suche wurde entdeckt, dass der Notaus-Schalter eingedrückt war.
Der Clou ist, dass mal betont wurde, dass der Schalter nicht angeschlossen sei, weshalb es egal ist ob der gedrückt ist oder nicht. Nun, scheinbar ist es doch relevant in welcher Position er ist…
Nun konnten wir endlich unser Programm ausführen, aber dennoch ging nicht alles wie geplant, sondern es kam tausende Male die Fehlermeldung „Wrong Response“ vom CAN-Bus.
Da wir keinen Elektrontechniker erreichen konnten, der sich mit dem alten Motortreiber vom letzten Field Robot Event auskennt, den wir jetzt verwenden mussten, sah es trüb aus.
Bereits kapitulierend wurde der Monitor und alle Eingabegeräte für den Roboter abgesteckt und weggestellt. Aber Stephan Gocht hat weiter probiert den Fehler zu evaluieren und die Ursache zu finden. Kurze Zeit später sagt er, er habe eine Lösung gefunden: Wir müssten unser Programm mit root-Rechten ausführen, da die Interaktion mit dem CAN-Bus dies unter Linux erfordere.
Und tatsächlich: Wir starten das Programm und können mit dem Gamepad die Achsen drehen!!!
Vor einem Monat haben wir erst die Entwicklungsumgebung eingerichtet.
Erst vor drei Wochen waren die Stummel für die notwendigen Klassen für diese Aufgabe fertig.
Vor einer Woche machte der Code auf den ersten Blick noch den Eindruck, dass alles noch etwas zusammenhangslos ist und der richtige Ablauf erst noch reinprogrammiert werden muss.
Diesen Ablauf haben der Teamleiter Peter Merkert und Stephan Gocht 3 Tage vor dem Start eingebaut.
Da es damit nun wirklich realistisch war die Deadline zu erreichen, wurde dies zwei Tage vor dem Start offiziell über alle Verteiler angekündigt, damit Interessenten bei dem Ereignis dabei sein konnten.
Am Donnerstag – dem letzten Tag – wurde Peter Merkert durch sein Einladungsrundschreiben am Vortag von Team Mechanik kontaktiert: Ein Lenkservo wurde vor einiger Zeit ausgebaut und noch nicht wieder eingebaut. Das wäre zum Fahren natürlich ungünstig.
Simon Merz, Mitglied im Team Mechanik und 1. Vorstand, hat sich bereit erklärt kurzfristig am Folgetag vorbei zu kommen und den Lenkservo einzubauen und bei Problemen zu helfen.
Freitag, 15.02.2013, 15 Uhr. Der Code von uns sollte soweit stehen und wir haben jetzt vor, diesen auf den Roboter zu portieren und auch zu starten. Aber bevor überhaupt einmal unser Programm gestartet werden kann, blockieren folgenden Steine unseren Weg:
Problem: Der PC im Roboter startet nach dem Stromanschluss nicht.
Lösung: Kurzschließen von den Startpins vom Mainboard löst einen PC Start aus. Problem: Bei jedem PC Start müssten die Pins kurzgeschlossen werden.
Lösung: Im BIOS die Einstellung setzen, dass der PC bei Stromanschluss sofort automatisch startet.
Problem: Nach dem Startproblem wurde der PC wieder in den Roboter eingebaut. Leider startet er wieder nach Stromanschluss nicht automatisch.
Lösung: Das BIOS hat sich zurückgesetzt, es mussten also wieder die Pins kurzgeschlossen werden.
Problem: BIOS hat sich zurückgesetzt.
Lösung: Die BIOS Batterie war fast leer. Zum Glück hat Alexandru Albu aus unserem Team eine baugleiche in seiner Tasche dabei! :D
Problem: Der PC im Roboter startet nun. Damit alle sonstige Bauteile im Roboter gestartet werden muss zuerst ein Schalter umgelegt werden, der eine rote LED als Anzeige hat und danach ein größerer weißer. Beim Umschalten den Ersten leuchtet die LED nicht auf.
Lösung: Es wurden Kabel neu verlötet und Kabel in Lüsterklemmen gefestigt. Es wurden auch die Akkus zuerst vergessen einzubauen, deshalb konnte kein Strom fließen. Leider hat dies alles nichts geholfen. Nach langer Suche wurde entdeckt, dass der Notaus-Schalter eingedrückt war.
Der Clou ist, dass mal betont wurde, dass der Schalter nicht angeschlossen sei, weshalb es egal ist ob der gedrückt ist oder nicht. Nun, scheinbar ist es doch relevant in welcher Position er ist…
Nun konnten wir endlich unser Programm ausführen, aber dennoch ging nicht alles wie geplant, sondern es kam tausende Male die Fehlermeldung „Wrong Response“ vom CAN-Bus.
Da wir keinen Elektrontechniker erreichen konnten, der sich mit dem alten Motortreiber vom letzten Field Robot Event auskennt, den wir jetzt verwenden mussten, sah es trüb aus.
Bereits kapitulierend wurde der Monitor und alle Eingabegeräte für den Roboter abgesteckt und weggestellt. Aber Stephan Gocht hat weiter probiert den Fehler zu evaluieren und die Ursache zu finden. Kurze Zeit später sagt er, er habe eine Lösung gefunden: Wir müssten unser Programm mit root-Rechten ausführen, da die Interaktion mit dem CAN-Bus dies unter Linux erfordere.
Und tatsächlich: Wir starten das Programm und können mit dem Gamepad die Achsen drehen!!!