Think Modular

[Holomino]

Darf ich die offensichtliche Antwort verlinken?

Natürlich darfst Du das. Und Du darfst auch weiterhin die Vorteile bezüglich ROS lobpreisen.

Der Link löst aber mein Problem nicht. Ich halte ein Stück selbstgebaute Hardware mit UART in der Hand. Da muss ich mich entscheiden, welchen Protokollrahmen ich verwende. Nehme ich vielleicht z.B. sowas (Seite 2)?
Synchronisiert sich dieses Protokoll bei Störungen? Ich sitze hier im Graben und fummel am Code meines Moduls rum. Ich progge den Controller ab und zu neu. Das unterbricht zwar die Daten, aber die Verbindung nicht. Ich hab auch keine Lust, nach jedem Neuproggen die Gegenstelle zu rebooten. Da muss also (auf beiden Seiten) was her, was unterbrochene Telegramme wegschmeißt. Je schlanker, desto besser. Meine Ressourcen auf dem Controller sind begrenzt.

[Defiant]

Das mit dem "darf" war jetzt nicht so wörtlich gemeint. Ich habe nur das Gefühl ich gehe euch ein wenig damit auf die Nerven.

Der Link löst aber mein Problem nicht. Ich halte ein Stück selbstgebaute Hardware mit UART in der Hand.

ok, klingt nach einem Job für rosserial (Nur ROS1). Wobei ich selber allerdings ein eigenes einfaches i2c-Protokoll zur Kommunikation mit meinem µC verwende. Der Neustart der ROS-Node die die I2C-Hardware an das ROS-Ecosystem anbindet muss ich dann zwar manuell neustarten, aber das stört mich nicht hinreichend genug um das zu ändern. Geht ja auch hinreichend schnell, da alle anderen Nodes weiter laufen können. Theoretisch könnte ich auch einen automatischen Restart bei Bus-Fehlern einbauen..
Mir persönlich war rosserial zuviel Overhead zum Einsatz auf einem 8-Bitter.


Der Vollständigkeit halber: Bei ROS2 wurde rosserial durch micro-ROS abgelöst. Das braucht aber wohl "größere" µC wie einen ESP32. Ich denke nicht, dass es auf einem AVR lauffähig ist. Ich habe keine Erfahrungen mit micro-ROS.

Update: Hier gibt es was mit micro-ROS auf Arduino: https://discourse.ros.org/t/micro-ros-on-arduino/17009

[Moppi]

Wenn Du eine Hardware hast und nach Protokolllösungen suchst, habe ich hier was gefunden. Die Blockdiagramme enthalten auch den Fall des Abbruchs. Es gibt immer zwei Möglichkeiten: das Protokoll wird nicht eingehalten (es gibt eine Zeitüberschreitung, weil Verbindung getrennt -> Timeout -> Abbruch) und die übertragenen Daten stimmen nicht (Prüfsumme einführen CRC bspw.) -> dann werden die gesendeten Daten, i.R. ein ganzes Datenpaket (s. Protokollrahmen), verworfen/ignoriert und das letzte Datenpaket nochmals angefordert. Dafür brauchst Du mindestens eine Paketnummer und, im Falle der Überprüfung, eine Prüfsumme, die enthalten sein müssen. Außerdem muss der Empfänger mitteilen können, ob das letzte Paket i.O. war. Dafür kann man eine extra Datenleitung verwenden, entweder für Sender und Empfänger eine oder eine gemeinsame Leitung; im Protokoll muss dann festgelegt sein, wann wer von beiden diese Leitung nutzt, den/einen Status mitzuteilen (weil einer muss den Leitungszustand auswerten und einer setzen). Andere Möglichkeit, wenn das Paket nicht i.O. war: der Empfänger tut so, als ob die Leitung unterbochen wurde, es wird dann dieses Prozedere ausgeführt.

MfG

[Holomino]

Das mit dem "darf" war jetzt nicht so wörtlich gemeint. Ich habe nur das Gefühl ich gehe euch ein wenig damit auf die Nerven.

Eigentlich nicht. Solange wir hier ROS als eine Alternative aus mehreren Möglichkeiten behandeln können, kann ich vergleichen und Dir Löcher in den Bauch fragen.

Apropos Löcher:
Im Nachbarthread hattest Du beschrieben, dass auch Du Spannung und Strom vom Akku misst. Magst Du vielleicht einmal beschreiben, wie bei Dir in ROS der Weg dieser Werte bis in die Oberfläche aussieht (Messaufbau brauchste nicht zu beschreiben, aber so ab dem Teil, ab dem die Werte an irgendeinem AD-Wandlerpin landen)?

...

Naja, so richtig auf der Suche bin ich nicht. Ich dachte nur, es kommen schon praktische Implementierungen von Euch, bevor ich die von mir angewendete Lösung vorstelle.
Wenn ich Nachrichten übertragen oder lesen will, möchte ich dies möglichst benutzerfreundlich in meinem Code gestalten.
Anwendungsspezifisch schreibe ich z.B. eine Struktur von Typ DUMMY auf die UART:

//Anywhere from header
#define MagicID_DummyTelegram 0x42
typedef struct
{
    uint8_t CmdID; //0
    uint8_t Mode; //1
    uint16_t  Val; //2
}__attribute__ ((packed)) Dummy_t; //Length 4 Byte


//Anywhere in declaration
Dummy_t dummy;

//Anywhere in code 
dummy.CmdID = MagicID_DummyTelegram;
dummy.Mode = 0x80;
Dummy.Val = 0xEEFF;
SendTelegram((uint8_t*) &dummy, sizeof(dummy));

Auf dem Empfängercontroller könnte die Empfangsroutine so aussehen

//Anywhere from header
#define MagicID_DummyTelegram 0x42
typedef struct
{
    uint8_t CmdID; //0
    uint8_t Mode; //1
    uint16_t  Val; //2
}__attribute__ ((packed)) Dummy_t; //Length 4 Byte

//Anywhere in code
void TelegramReceived(uint8_t *data, uint8_t len)
{
    switch (data[0]) // get CmdID
    {
        case MagicID_DummyTelegram:
        {
            Dummy_t* dummy = (Dummy_t*) &data[0]; //Cast 
            if (dummy->Mode == 0x80)                         //and do something 
                SetLEDBrightness(dummy->Val);
       }
        break;

       case AnotherMagicID:
          .
          .
          .
    }
}

Ein mögliches Protokoll dazu:
- Ein Telegramm beginnt mit einem Startbyte (0xFF)
- Ist ein Byte in den Telegrammdaten gleich dem Startbyte, wird es doppelt gesendet
- Ohne Kenntnis über Länge und Bedeutung des Telegrammes benötigt die Empfangsroutine eine Längenangabe.

Über den Draht gehen aus dem obigen Beispiel also:
0xFF (Startbyte)
0x04 (Strukturlänge)
0x42, 0x80, 0xEE, 0xFF, 0xFF (Strukturinhalt, Beachte: 1. Element ist die CmdID, 0xFF in den Strukturwerten wird doppelt gesendet)

Genauere Implementierungsdetails (was bei mir bezüglich FIFO und Parsen zwischen den Endpunkten SendTelegram und TelegramReceived liegt) findet Ihr z.B. im VL53L1X-Thread...

Controller: Anhang 34152
PC: Anhang 34153

...wobei mich aus meiner beschränkten Sicht heraus z.B. der Vergleich und die Kompatibilität zu ROS, Arduinoprogrammierung oder Bascom interessieren würde.

[Moppi]

Naja, so richtig auf der Suche bin ich nicht. Ich dachte nur, es kommen schon praktische Implementierungen von Euch, bevor ich die von mir angewendete Lösung vorstelle.

Das geht eben nicht immer bei Dir hervor, da tappt man etwas im Dunkeln. Du formulierst immer so, als ob Du generelle Fragen hast.

Was mich angeht, so verwende ich I2C und serielle Schnittstelle über UART, am ATmega328P-PU und nodeMCU. Alles, was man dort benötigt, sind die Bibliotheken für diese Schnittstellen, um das Protokoll muss man sich weitestgehend nicht selber kümmern. Ansonsten hätte ich noch eine parallele Übertragung, vor allem als Versuch, soll aber auch funktionieren (die verfügbaren Pins gaben das so her), dafür ist kein UART notwendig. Dort steht das Protokoll aber auch fest, als Programmablauf. Ich verwende dazu 3 Datenleitungen und für jeden angebundenen µC zwei Kontrollleitungen (eine führt von einem µC zum andern, und eine andere zurück), jeder µC kontrolliert seine eigene Leitung (Status f. Empfang, senden...). Sollte ein Datenpakettransfer fehlschlagen, bricht der Empfänger nach einer Weile ab, dann ist der Fertig. Wenn der Sender bemerkt, dass der Empfänger nicht antwortet, bricht der auch ab. Beim nächsten Schleifendurchlauf ist der Datenblock nicht versendet und wird daher nochmals übertragen. Das Spiel wiederholt sich dann so oft, bis die Daten übertragen werden konnten, oder bis der Akku leer / die Elektronik kaputt ist.

Du hast aber eine andre Lösung für Dich gefunden, wäre Zufall, wenn das einer schon mal so gemacht hätte und daher fertige Protokolle, Software und Datenpaket-Beschreibungen parat hat.

Was ganz einfaches und aber sicheres (halbiert die Datenübertragungsrate), habe ich mal für sie Serielle Datenübertragung gemacht. Findet man in meinem Fotoalbum, als Flußdiagramme/PAP. Kann man rein schauen, aber das ist sicher nicht, was Du suchst(?).

Im Übrigen fände ich PAPs besser. Ist nicht auf eine Programmiersprache fixiert. Erreicht man meist eine breitere Masse an Leuten.

MfG

[Holomino]

Natürlich frage ich zuerst ganz unvoreingenommen. Ich bin nicht der brennende Busch. Meine Lösung ist erst einmal nur eine unter vielen.
Wenn Du schreibst, Du verwendest Bibliotheken: Ich kenne Arduinos nur sehr oberflächlich, praktisch gar nicht. Ich kann mir die Serial.h anschauen und daraus erahnen, dass da wohl ein FIFO verwendet wird. Die textuelle Übertragung einer Konsolenausgabe habe ich auch schon mal als Codebrocken gesehen. Aber wo muss ich suchen, wenn ich eine vollasynchrone Datenübertragung zwischen zwei Arduinos (beide Teilnehmer blasen sich ohne Softwarehandshake gegenseitig mit Daten zu. Jede Seite kann die unterschiedlichen Nachrichten im empfangenen Datenstream aufbröseln. Das Aufbröseln darf bei einer Störung Daten verlieren, aber nicht ins Stocken geraten) haben will?
Gibt's da fertige Libs? Wenn ja, welche? Wie fix sind die? Was geht über den Draht? Kann ich das Protokoll mit Bascom o.ä. nachprogrammieren?

Einen PAP zu zeichnen wäre obsolet, wenn sich ein Arduinofreak einmal den Code anschaut und die Übersetzbarkeit prüft. Wenn das hier keiner machen will, bestell ich mir so'n Teil und mache es selber - kann ja wohl nicht so schwierig sein.

[Defiant]

Im Nachbarthread hattest Du beschrieben, dass auch Du Spannung und Strom vom Akku misst. Magst Du vielleicht einmal beschreiben, wie bei Dir in ROS der Weg dieser Werte bis in die Oberfläche aussieht (Messaufbau brauchste nicht zu beschreiben, aber so ab dem Teil, ab dem die Werte an irgendeinem AD-Wandlerpin landen)?

Spannung & Strom werden von einem A/D-Pin eines AVR gemessen, dort in Volt & Ampere umgerechnet und per I2C an den Einplatinencomputer gegeben. Die ROS-Node holt diese Information aus den entsprechenden I2C-Registern ab. Hier ist der Quellcode für die Implementierung in C und Python. Der ROS-Welt werden die Werte einmal als diagnostics und einmal als BatteryState-Message zur Verfügung gestellt. Letztere lässt sich überall abfragen, z.B. in einem Terminal:

user@wildthumper:~> rostopic echo -n 1 battery/voltage
11.470000267
---

oder grafisch mit Tools wie PlotJuggler. Bei mir allerdings meistens im Browser, vor allem wenn ich nur kurz den aktuellen Wert lesen möchte.

[Moppi]

zum einbinden in den Arduino-Quelltext braucht man:


#include "serial.h"


zur Initalisierung der seriellen Schnittstelle:


Serial.begin(bps);


hier ein anderes Beispiel: https://www.arduino.cc/reference/en/.../serial/begin/


Zum Schicken von Daten, Serial.write() oder Serial.print(). Zum Empfangen Serial.read(). So weit mir bekannt, kann jeder Teilnehmer jederzeit senden und jederzeit empfangen.
Man kann noch eine Funktion angeben, die dann aufgerufen wird, wenn Daten eingetroffen sind (wenn man nicht dauernd nachschauen will).
Wenn die Funktion dann aufgerufen ist, macht man nichts anderes, als Serial.available() - ob und wieviele Daten verfügbar sind - und dann liest man die.


Ich nutze die Sachen auch nur, muss ich nicht alles selber programmieren. Ist der Vorteil daran.
Wie schnell so ein Datenaustausch am Ende ist, teste ich, wenn ich es wissen will, im Programm selber. Beim Hexapod war es schnell genug, um flüssige Bewegungen hervorzubringen, trotz zwischendurch Positionsdatenblöcke für bis zu 3 oder 4 Beine am Stück übermittelt wurden. Also für etwa 9 Servos. Vielleicht auch mal mehr. Kann ich jetzt aber nicht mehr überprüfen, weil das Gerät demontiert ist.


Ob wir hier echte Arduino-Freaks haben?




MfG

--------------------------------------
Nachtrag 27.11.2020:

Das mit der "serial.h" will ich so nicht stehen lassen, weil es offenbar nicht richtig ist. Heute bin ich dazu gekommen, dies direkt auszubrobieren. Wie ich da auch "serial.h" kam? - Weiß ich auch nicht mehr. Wenn ich es benötige, füge ich persönlich "HardwareSerial.h" per #include hinzu. Da ich gerade jetzt damit zu tun habe, hier nur die Richtigstellung.

[Holomino]

Spannung & Strom werden von einem A/D-Pin eines AVR gemessen, dort in Volt & Ampere umgerechnet und per I2C an den Einplatinencomputer gegeben. Die ROS-Node holt diese Information aus den entsprechenden I2C-Registern ab. Hier ist der Quellcode für die Implementierung in C und Python. Der ROS-Welt werden die Werte einmal als diagnostics und einmal als BatteryState-Message zur Verfügung gestellt.

Super, ich kann kein ROS, Du hast keine Lösung für Lithium-Zellen. Abgesehen davon, dass wir weder über Ströme, Spannungen noch Stecker gesprochen haben:
Sieht auf der Softwareseite fast schon so kompatibel aus, als ob ich Dir eine Mitschnittdatei aus meinem Projekt schicken könnte, wo Du Dir in ROS die Telegramme auseinander fummelst und die entsprechenden Nodes meines Powermoduls anbindest.

[Defiant]

Es wurde ja auch viel entwickelt um ROS unabhängig von einer spezifischen Hardware zu bekommen. Ich könnte zumindest unterstützen, wenn du für deinen Roboter eine ROS-Anbindung haben möchtest. Allerdings wären die Spannungs- und Stromwerte nicht meine oberste Priorität, sondern der Antrieb.

Abgesehen davon, dass wir weder über Ströme, Spannungen noch Stecker gesprochen haben

Ja, sollte zuerst gemacht werden. Software lässt sich viel leichter ändern und an verschiedene Gegebenheiten anpassen als Hardware.