Einige Hinweise bekommt ihr hier.
Das Senden ging bei uns nur, als wir das erste Byte 1 gesetzt hatten. Im Bespiel wird die 7 gesendet.
public static void sendRequest()
{
byte[] packet = {(byte)1, (byte)7};
josx.platform.rcx.Serial.sendPacket(packet, 0, 2);
}
Da Prinzip der Behaviorklassen ist eigentlich eine sehr gute Idee, die Programme Übersichtlich und strukturiert zu halten, aber der Arbitrator kann, einmal gestartet, nicht mehr beendet werden. Bei uns gab es ein paar Probleme, bei denen wir nicht wussten, ob es am Quellcode lag oder daran, dass der Arbitrator zu langsam die Zustände wechselt. Wir haben uns dann nach Beratung mit unseren Leitern dazu entschlossen den Quellcode "hart" zu kodieren, was letztendlich auch gut klappte.
Das wahrscheinlich größte Problem bei der Konstruktion ist, dass die beiden Motoren einfach nicht gleich schnell drehen wollen. Es gibt zwar so genannte Drehsensoren, aber die standen uns nicht zu Verfügung. :-(
Die einzige Möglichkeit, die uns blieb, war eine Kalibrierung, bei der wir eine Rechts- bzw. Linksdrehung ausführten und die skalierten Werte benutzten.
Beide Varianten haben Vor- und Nachteile. Beim Differenzial ist es einfach geradeaus zu fahren, aber das große Problem ist es die Mitte beim Manüvrieren intern zu behalten. Die zwei Antriebsmotoren ermöglichen eine einfache Lenkung, wogegen nun das Problem besteht, längere Strecken geradeaus zu fahren. Wir haben uns für die zwei Motoren Variante entschieden und sind damit relativ gut gefahren.
Da ein Vorderrad bei unserem Robot aufgrund der fehlenden Flexibilität nicht funktionierte, sind wir über viel ausprobieren zu den Schläuchen gekommen. Diese gaben uns eine gute Auflagefläche und bremsten die Lenkung nicht aus.
Unsere Lösung für die Schräge war ein robuster, kompakter Grundaufbau, kombiniert mit einer guten Übersetzung aus Kraft und Schnelligkeit. Durch Ausprobieren ermittelten wir die perfekte Position für den RCX. Natürlich kann man auch Ketten verwenden, wenn man das möchte.