fischertechnik community forum

Hallo,

unter der original fischertechnik Firmware wird der TXT automatisch ordentlich heruntergefahren, wenn die Batterie schwach wird.

Es ist nun möglich über die direkte serielle Ansteuerung der Motorplatine den Spannungszustand der Stromversorgung des TXT abzufragen (siehe ftrobopy v1.52). Evtl. könnte man das ja verwenden, um den TXT auch unter der community Firmware automatisch geregelt herunterzufahren, wenn die Batterie schwach wird. Dafür müsste dann in der CFW ein Prozess laufen, der ständig die Batterie überwacht (z.B. einmal pro Sekunde).
Allerdings kämen sich dann ein laufendes ftrobopy-Programm im 'direct'-Modus und dieser Prozess wahrscheinlich gegenseitig ins Gehege, weil die Motorplatine die beiden Prozesse nicht auseinanderhalten könnte und sich beim sog "cycle_counter" verzählen würde. Ausserdem sollten nicht zwei Prozesse gleichzeitig auf denselben seriellen Schnittstellenport zugreifen.

Habt ihr eine Idee wie man das am Besten regeln könnte ?

Edit: Sollte man einen einzigen CFW-Prozess haben, der die komplette Kommunikation mit der Motorplatine übernimmt und dann eine Schnittstelle zu anderen Programmen, wie z.B. ftrobopy, bietet ?

Viele Grüße
Torsten

Geniale Idee. Habe ich im Schaltplan noch gar nicht gesehen. Wo ist das denn angeschlossen?

Torsten hat geschrieben:Edit: Sollte man einen einzigen CFW-Prozess haben, der die komplette Kommunikation mit der Motorplatine übernimmt und dann eine Schnittstelle zu anderen Programmen, wie z.B. ftrobopy, bietet ?

Das wäre gut.

Raphael

Ah, habs gefunden.

Über den Spannungsteiler und dann auf den Cpu ADC.

Raphael

ski7777 hat geschrieben:Habe ich im Schaltplan noch gar nicht gesehen. Wo ist das denn angeschlossen?

Ich habe das nicht aus dem Schaltplan. Ich habe nur festgestellt, dass die Batteriespannung (bzw. die Netzteilspannung) im Datensatz enthalten ist, den die Motorplatine zurücksendet. Einen Temperaturwert gibt es dort auch, allerdings habe ich keine Ahnung in welcher Einheit der angegeben ist (der Wert liegt bei mir typischerweise um die 420).

Die Motorplatine sendet den Datensatz normalerweise alle 10ms zum TXT. Allerdings kann man die Daten auch im 1ms Rhythmus abfragen, bzw. die PWM-Werte (und nur die) im 1ms Rhythmus setzen. Man müsste also einen Prozess in der CFW haben, der alle 1ms die Kommunikation zur Motorplatine aufbaut. Das sollte man besser nicht mehr in Python machen, sondern in "C/C++" (was natürlich genauso möglich ist), damit das nicht zuviel Rechenzeit verbraucht.

Wie sollte dann die Schnittstelle für andere Programme aussehen ? (Man könnte dabei natürlich auch wieder an die Socket-Kommunikation, wie bei ROBOPro, denken)

Gruss,
Torsten

Der gemeinsame Nenner ist da die ftrobopy. Das ist das, wo jedes Programm durch geht, wenn es auf den Motorcontroller zugreift und das ist die Stelle, wo man sowas kollisionsfrei integrieren könnte. Der launcher lauscht permanent auf TCP port 9000 auf Kommandos. Genau dort könnte man ihm aus der ftcobopy auch sagen, dass er den TXT wegen Batt-Low runterfahren soll. Das würde er dann auch anzeigen. Aber elegant ist irgendwie was anderes ...

Eleganter wäre in der Tat ein im Hingerund laufender Conrol-Daemon ganz ähnlich dem, was wir zur Zeit mit dem TxtControlMain machen. Und TCP-Kommunikation würde ich gerne wieder sehen. Das kann man sicher immer gut gebrauchen. Aber das Origjinal-Protokoll würde ich bestenfalls als Add-on wegen der Kompatibilität sehen. Wenn ma es eh neu schreibt bietet es sich an, was skalierbares zu machen. Ein modernes Protokoll, das es erlaubt, die Fähigkeiten des Controllers auszulesen wäre cool und könnte dann auch auf zukünftigen R-Pi-basierten Lösungen zu Einsatz kommen, ohne dass man seine Sachen immer an neue API-Versionen anpassen muss.