RP6 Remotrol 1.3: Die Opensource RP6-Fernsteuerung

[Fabian E.]

Hallo und danke erst mal für dein ausführliches Feedback.

Ich habe dazu einige Dinge zu sagen und zu korrigieren:

Mir gefällt jedoch die Anzeige bzw. Steuerung der Motorfunktion nicht, der Motorbefehl wird erst abgesetzt wenn man den Regler loslässt

Das ist mit Absicht so. Der RP6 würde sonst tonnenweise Befehle bekommen.

Der Regler ganz rechts hat irgendwie keine Funktion?

Doch, dort stellt du die Geschwindigkeit für die Pfeiltasten-Steuerung ein.
Danach in die Textbox oben klicken und mit dem Pfeiltasten fahren.

Mir gefällt jedoch die Anzeige bzw. Steuerung der Motorfunktion nicht, der Motorbefehl wird erst abgesetzt wenn man den Regler loslässt. Man sieht auch die eigentlich interssanten Messwerte der Motordaten aus dem Überwachungsfenster nicht oder nur indem man zwischen den Reitern umschaltet. Das lässt sich besser lösen.

Dein Vorschlag?

Bedient man den Motorenmittelregler, werden zwar die Regler der Einzelmotoren mit bewegt, der Befehl an beide Motoren scheint aber manchmal verloren zu gehen bzw. nur manchmal an der Base anzukommen. Die Einzelregler funktionieren aber wohl - da hatte der Bot noch keine Aussetzer.

Entweder hast du eben den Regler nicht losgelassen, oder es war Zufall, dass nur die vom mittleren Regler nicht ankommen. Ein Zusammenhang mit dem Regler an sich ist ausgeschlossen.

Dann ist mir aufgefallen, das die LEDs auf der M32 falsch angesteuert werden. Die Reihenfolge von LED 1-4 ist vertauscht, also wenn ich LED4 anschalte geht LED1 an, usw. Ich weis nicht ob das ein Bug in der Firmware oder im Programm ist, es ist jedenfalls sicher reproduzierbar.

Ich würde es nicht unbedingt Bug nennen. Habe mir da keine großen Gedanken drum gemacht welche LED nun LED1 ist. Ich kann aber gerne noch mal drüber gucken, welche wann angesteuert werden.

Leider liest das Programm die Werte für die ADC0/1 auf dem Baseboard nicht aus, ich habe mir da ein Linesensormodul angeschlossen und würde natürlich gerne auch die Daten am ADC sehen.

Gleiches gilt für die ADC Werte des M32 Boards (die ich aktuell noch nicht nutze).

Das war auch ein Vorschlag einer meiner Beta-Tester und steht auf der ToDo-Liste. Hast du einen Vorschlag für die grafische Darstellung?

Dann hab ich versucht das Log im Programm zu stoppen um es mit c&p hier einzubauen.. zum meinem erstaunen stoppt das log aber nicht... auch läuft es nicht so das die jeweils aktuelle Zeile sichtbar ist.... sondern ab der ersten im log... das macht wenig Sinn.

Bin mir grade nicht ganz sicher was auf den Buttons drauf steht, die waren jedenfalls nie dazu gedacht, das Log zu "stoppen", sondern nur um das Autoscrolling zu deaktivieren. Leider ist das so wie ich mir das vorstelle nicht möglich. Daher wird lediglich der Fokus von der Textbox genommen und wenn man wieder reinklickt scrollt sie weiter.

Was ich nämlich dokumentieren wollte ist, das der Bot verbunden ist, es auch Werte für die Batterie und die LDRs gibt (oder zumindest was angezeigt wird - ich bezweifele dass es sich um aktuelle Daten des Bot handelt), jedoch das auslesen weiterer Daten scheinbar fehlschlägt.

Inwiefern schlägt denn das Auslesen fehl? Du kannst im Terminal gucken, ob aktuelle Daten ankommen.

[INFO] 00:13:14: 'RP6SensorReader.RefreshSensors': Heartbeat
[INFO] 00:08:10: 'RP6AsyncControler.EnqueueCommand': Trying to start command: #9:1:67*
[INFO] 00:13:15: 'RP6SensorReader.RefreshSensors': Heartbeat
[INFO] 00:08:10: 'RP6AsyncControler.EnqueueCommand': Trying to start command: #9:1:68*

Das hier deutet darauf hin, dass die Kommunikation zwischen Master-Modul und PC nicht perfekt klappt. In der nächsten Version habe ich die Befehlsverwaltung komplett neu geschrieben, sie ist jetzt wesentlich verlässlicher.

Im Programm ist wärend dessen auch das Selbsttestfenster eingegraut. Anscheinend funktioniert die I2C Bus Kommunikation nicht mehr richtig worauf hin auch das Programm durcheinander gerät. Trennt man im Programm die Verbindung, bleibt der Button trennen aktiv und eine Widerverbindung ist nicht möglich.

Woran willst du bitte erkennen das die I2C (!!!) Kommunikation nicht klappt?
Der Bot wird nicht über I2C angesprochen. Die Kommuniktion mit dem PC läuft über UART.
Nur die interne Kommunikation der Controler läuft über I2C.

Die I2C Kommunikation war nur nach mehrmaligem Booten mit Glück hinzubekommen, die M128 konnte das LCD welches auf der M32 aufgesteckt war z.b. nicht beschreiben (per i2clcdtest sollte das doch gehen), Messwerte wie für die LDR gingen verloren, die LEDs auf dem m32 Board waren ebenfalls verdreht usw usw... geschätzt sind ca. 40% aller Daten verloren gegangen, letztlich hatte ich massenweise Schwierigkeiten das Ganze ansatzweise zum Laufen (oder sagen wir besser zu einer Reaktion) zu bringen. Es war offensichtlich das beide kleinen CPUs im Slave Mode liefen und teilweise Daten ankamen... aber eben nicht durchgängig und nicht immer 100%ig reproduzierbar.

I2C: s.o.
Was lässt dich vermuten, dass die M128 auf das LCD der M32 schreiben kann? Das ist momentan nicht möglich. (Aber auf der ToDo-Liste)
Der Test ist übrigens ein I2CLED-Test kein LCD-Test.

Was lässt dich denn vermuten, dass Daten verloren gehen?
Das ist eigentlich nie der Fall. Ein Befehl kann schonmal verloren gehen, Daten aber eigentlich nicht. Der RP6, bzw die M128 sendet konstant mit einer Standardübertragungsrate von 5 Übertragungen die Sekunde alle neuen Daten zum PC.

Es scheint dabei evtl. Timingprobleme auf dem ic2 sowie auch Programmfehler bei unerwarteten Antworten des Bot auf Sensorabfragen zu geben. Bei der M128 jedoch mehr als mit der M32.

Timing-Probleme mit I2C? Da hast du glaube ich was falsch verstanden.
Der PC fragt keine Sensorwerte ab, daher kann er auch keine falschen Antworten bekommen.

Achso... und manchmal bekomme ich beim beenden des Programms auch eine Fehlermeldung das irgendwas abgeschmiert sei, das mir netterweise beim Neustart dann angezeigt wird...

Die Fehlermeldung sagt mir, dass dir eine Dateiendungsverknüpfung fehlt. Das ist interessant und sollte gefixt werden.

Meine Meinung: An dem Programm sowie an den Libs und "Firmware" muss noch viel gemacht werden bevor das eine sinnvolle nützliche Software ist, für einfache Tests ist das Ding jedoch brauchbar und für Entwickler ein schönes Beispiel was alles schief gehen kann.

Ich bin mir nicht ganz sicher, ob ich diesen Satz ernst nehmen soll.
Ich finde er klingt ein bisschen arrogant. Ich stecke viel Freizeit in dieses Projekt und stelle es hier zu Anschauungszwecken zur Verfügung.
Niemand muss etwas dafür zahlen oder so, es gibt daher keinen Grund die Software schlecht zu machen. Das Feedback oben drüber ist gut, der Satz hier macht es aber irgendwie wertlos.
Das ganze hat übrigens bei unzähligen Leuten vor dir schon gut funktioniert...

PS: Informier dich doch vor dem nächsten so ausfühlrichen Beitrag etwas mehr über die Funktionsweise von Remotrol, dann kannst du dir viel Getippe bezüglich deiner Fehlinformationen sparen, im Speziellen bezüglich des I2C-Bus.

Trotzdem danke für die nützlichen Hinweise, ich werde mir folgende Punkte mal näher ansehen und entsprechend ändern:

• Pfeiltastensteuerung verdeutlichen (steht eh schon auf der ToDo-Liste)
• Reihenfolge der M32 LEDs
• Anzeige aller ADC/IO-Werte
• Dateiverknüpfung vom Fehlerlog

Liebe Grüße,
Fabian