Hexapod - mal etwas anders

[lemmings]

Hallo zusammen,

was haltet ihr von diesem Projekt:


===============
HexaBoard Mini Board

Technische Ausstattung:

7 Mikro-Kontroller in 1-6 Master/Slave Konfiguration

Hauptprozessor „Master“
Wahlweise kann einer der folgenden Prozessoren Verwendung finden:
Atmel ATmega48, ATmega88, ATmega168 oder ATmega328.
aktueller (Juli 2009) Preis bei Reichelt: 1.25€ für ATmega48

Hilfsprozessoren „SLAVE1“ - „SLAVE6“
Wahlweise kann einer der folgenden Prozessoren Verwendung finden:
Atmel ATtiny24, ATtiny44 oder ATtiny88.
aktueller (Juli 2009) Preis bei Reichelt: 1.20€ für ATtiny24
Für umfangreiche Schrittfolgen (Details weiter unten) empfiehlt sich die Verwendung
eines ATtiny84 mit 8k Flash.

Zusammenspiel und Verwendung der Prozessoren:
Der Hauptprozessor stellt über 2x 10polige Pfostenleisten je 8 I/O Ports, also insgesamt 16 Ports, die frei im Modell für weitere Funktionen genutzt werden können.
Am Hauptprozessor befinden sich weiter jeweils 3 Taster, 3 LEDs in verschiedenen Farben, um jeweilige Stati anzeigen zu können, ein kleiner Lautsprecher für akustische Signale, ein interner 2-Draht und ein externer I²C-Bus.

Der interne 2-Draht Bus entspricht elektrisch dem I²C Bus und dient der Kommunikation des Hauptprozessor mit den Hilfsprozessoren.
Da der interne Bus getrennt vom externen I²C Bus ist besteht keine Notwendigkeit, auf dem internen Bus das I²C Protokoll zu verwenden.

Die 6 Hilfsprozessoren stellen jeweils 3 PWM-Ports bereit, die auf (RN-Standard kompatible) 3-polige Stervo-Stecker herausgeführt sind.
In der GND-Leitung eines jeden PWM-Port ist ein 0.1 Ohm Widerstand eingeschliffen.
Die mechanische Belastung (die Kraft, die Sollposition zu halten bzw. zu erreichen) jedes einzelnen Servo lässt sich aus der Stromaufnahme des der Last gegensteuernden Motor ermitteln.
Am eingeschliffenen Widerstand steigt der Spanungsabfall mit der Zunahme der Last an.
Diese Spannung kann je seperatem PWM-Port über den ADC des Hilfsprozessor gemessen werden.

Im praktischen Betrieb bedeutet das, dass „Hindernisse“ wie Bodenunebenheiten etc. komfortabel kompensiert werden können, da jedes einzelne Bein selbst erkennen kann, wenn der Fuss auf ein Hindernis trifft bzw. den Boden berührt.
Selbst der Gefahr, dass das Modell durch Verlagerung des Gewichtes bei der Überwindung von Hindernissen kippt, kann begegnet werden, ohne weitere Sensoren zu benötigen.
Der Prozessor „fühlt“ die mechanische Last an der Stromaufnahme des Servo.


Anschlüsse:

18x 8/16-Bit-Timer-PWM
1x I²C
2x 8-Bit I/O
1x RS232
1x 5VDC Stromversorgung
1x ISP Hauptprozessor
6x ISP Hilfsprozessoren

Zusätzliche Funktionen:

3x Taster zur Eingabe
3x Status LED


Betrieb:

Zum Gehen gibt der Hauptprozessor gibt den Hilfprozessoren die vollständigen Bewegungen der Schrittfolge vor und steuert danach nur noch Tempo und Richtung.
Die jeweiligen Hilfsprozessoren arbeiten die Schrittfolge entsprechend dem vorgegebenen Tempo synchron ab und kompensieren kleinere Probleme wie Türschwellen etc. selbstständig.

Das Ziel der Hilfsprozessoren ist ausserdem eine ausbalancierte waagerechte Plattform, was sich einfach erreichen lässt, indem man einen stärker belasteten Servo entlastet, indem man auf der anderen Seite des Modells den korrespondierenden Servo belastet – unabhängig davon, wie schräg oder uneben der Untergrund ist.

Dazu ist es angeraten, dass die Hilfsprozessoren (analog, wie es mit den ABS-Steuergeräten etc. im KFZ gelöst ist) in regelmässigem Abstand ihre aktuellen Betriebsparameter (aktuelle Servostellung, Motor-Last) als Datenticket auf den internen Bus senden, um so sowohl den Master up-to-date zu halten und auch zum Zweck der Synchronisation.


interner Bus:

ein typisches Datenpaket für die Übertragung einer Schrittfolge ist wie folgt aufgebaut:

Quell-ID (4 Bit) 0000 Master
Ziel-ID (4Bit) 1111 alle
Paket-Typ (1 Byte) Upload Schrittfolge (0x04h)
Sequence (2 Byte) 0000.0000.0000.0000 für die erste Pos. der ersten Sequenz
PWM1A (1 Byte) Soll-Position 1. Servo
PWM1B (1 Byte) Soll-Position 2. Servo
PWM1C (1 Byte) Soll-Position 3. Servo
PWM2A (1 Byte) Soll-Position 4. Servo
PWM2B (1 Byte) Soll-Position 5. Servo
PWM2C (1 Byte) Soll-Position 6. Servo
PWM3A (1 Byte) Soll-Position 7. Servo
PWM3B (1 Byte) Soll-Position 8. Servo
PWM3C (1 Byte) Soll-Position 9. Servo
PWM4A (1 Byte) Soll-Position 10. Servo
PWM4B (1 Byte) Soll-Position 11. Servo
PWM4C (1 Byte) Soll-Position 12. Servo
PWM5A (1 Byte) Soll-Position 13. Servo
PWM5B (1 Byte) Soll-Position 14. Servo
PWM5C (1 Byte) Soll-Position 15. Servo
PWM6A (1 Byte) Soll-Position 16. Servo
PWM6B (1 Byte) Soll-Position 17. Servo
PWM6C (1 Byte) Soll-Position 18. Servo

Die Übertragung eines vollständigen Telegramms dauert bei einem Takt von 100khz weniger als 5ms.
Eine Schrittfolge, die aus 200 Einzelschritten je Zyklus besteht, wäre nach 1s übertragen.

Danach kann der Hauptprozessor die jeweiligen Schrittpositionen über einfachere Pakete abfordern:

Quell-ID (4 Bit) 0000 Master
Ziel-ID (4Bit) 1111 alle
Paket-Typ (1 Byte) Ausführen Schrittfolge (0x10h)
Sequence (2 Byte) 0000.0000.0000.0000 für die erste Pos. der ersten Sequenz

Ein kompletter Zyklus inclusive der Statis bzgl. erreichter Position und der Belastung würde dann so aussehen:

Quell Ziel Typ
0000 1111 0x10h 0x0000h
Hauptprozessor an alle: GOTO Pos. 0

0001 1111 0x00h 0x80h 0x77h 0x25h 0x22h 0x28h 0x20h
Hilfsprozessor „SLAVE1“ Status an alle: PWM1A auf Position 80h, PWM1B auf Position 77h, PWM1C auf Position 25h, Belastung Servo 1A 22h, Belastung Servo 1B 28h und Belastung Servo 1C 20h.

0002 1111 0x00h 0x80h 0x77h 0x25h 0x21h 0x28h 0x21h
Hilfsprozessor „SLAVE2“ Status an alle: PWM2A auf Position 80h, PWM1B auf Position 77h, PWM1C auf Position 25h, Belastung Servo 1A 21h, Belastung Servo 1B 28h und Belastung Servo 1C 21h.

0003 1111 0x00h 0x80h 0x77h 0x25h 0x21h 0x26h 0x21h
0004 1111 0x00h 0x80h 0x77h 0x25h 0x25h 0x26h 0x31h
0005 1111 0x00h 0x80h 0x77h 0x25h 0x27h 0x28h 0x21h
0006 1111 0x00h 0x80h 0x77h 0x25h 0x23h 0x28h 0x23h

45ms Pause

0000 1111 0x10h 0x0001h
Hauptprozessor an alle: GOTO Pos. 1
<...>

jede Status-Message ist 8 Bytes lang, d.h. alle 6 Stati zusammen sind 48 Bytes.
Jedes Schrittfolge-Kommando ist 4 Bytes lang, die vollständige Ausführung eines Schrittes ist vom Protokoll her gesehen nach 52 Bytes oder auch nach weniger als 5 ms abgeschlossen.
Mit Rücksicht auf die Trägheit der Mechanik sollte es ausreichen, wenn der Hauptprozessor alle 50ms eine Positionsänderung anfordert, um eine fliessende Bewegung hinzubekommen.

==> alle 50ms hat der Hauptprozessor für 5ms mit dem Gehen zu tun, die restlichen 90% der CPU-Zeit verbleiben dem Hauptprozessor für andere Aufgaben (Orientierung, Navigation, ...) und den Hilfsprozessoren, die PWMs anzupassen und die aktuellen Werte für die Belastung zu ermitteln.

Was haltet ihr von diesem Ansatz?

Ralph

[MeckPommER]

Hoi

Also da hast du dir ja im Vorfeld schon richtig Gedanken gemacht, super!

Insgesammt sieht die Geschichte für mich recht stimmig aus, wenn es auch stets so ist, das sich die wahren Stolperfallen erst im Laufe der Zeit offenbaren.

Ich habe nur - ohne es komplett analysiert zu haben - das Gefühl, als wäre der ganze Datenverkehr überdenkenswert. Jedes Bein muss in Echtzeit wissen, ob ein anderes Bein Probleme hat oder überlastet ist, etc.
Der Hauptcontroller muss also alle 50ms alle Informationen von allen Beinen abholen, diese auswerten und auch wieder Steuerkommandos an alle Beine senden.
Vorberechnete Sequenzen an Schrittfolgen für die Beincontroller sind eine gute Überlegung, aber wie sieht es mit Reaktionen des Bots auf die Umwelt aus?
Zudem muss der Hauptcontroller ja erstmal die ganzen Bewegungsabläufe berechnen, die Aufgrund deiner Idee der Ausbalancierung auch nicht statisch sein können.

Das sind Dinge, die mir da noch nicht so ganz klar sind.

Gruß MeckPommER

[ikarus_177]

Hi lemmings,

der Weg der Aufteilung der Arbeit auf mehrere Controller ist mir sehr sympathisch

Wenn aber nun der Master den Slaves alle Positionen der Servos vorgibt, die sie im Zuge der Schrittfolge anfahren müssen, kommen da für flüssige Abläufe schnell sehr viele Daten zusammen, die übertragen werden müssen. Sprich, wenn der Bot von einer Sequenz auf eine andere "wechselt", in einer Kurve zum Beispiel, würde er stets für einen Moment "hängen", bis die neue Schrittfolge übertragen wäre.
Der Master müsste dann auch die Schrittfolgen im voraus berechnen, das kostet auch Zeit. Angenommen, der Bot läuft im Moment geradeaus, und will nun eine Kurve gehen. Erstens könnte der Bot anhalten, seine Beine in die Standardstellung bringen, und danach die neue Sequenz ablaufen lassen, die vom Master für die Nullstellung berechnet wurde (also der "Anfang" der Sequenz liegt in der Nulllage). Der "schönere" Weg ist es natürlich, den Bot "fließend" in die Kurve zu schicken. Dafür müsste der Master aber auch wissen, wo sich seine Beine momentan befinden, damit er die Sequenz entsprechend anpassen kann.

Die Idee der gleichmäßigen Belastung der Servos ist auch super! Aber wie "weiß" ein Bein, in welcher Stellung die Servos weniger belastet werden, ohne dabei den Boden unter dem Fuß zu verlieren?

Ansonsten aber ein schönes Konzept, auch die Eagle-Platine sieht toll aus!

Viele Grüße
ikarus_177

[lemmings]

der ganze Datenverkehr überdenkenswert. Jedes Bein muss in Echtzeit wissen, ob ein anderes Bein Probleme hat oder überlastet ist, etc.

Mit dem Datenverkehr hast du Recht, das ist noch nicht endgültig.

Mal eine grundsätzliche Überlegung - ein Bein, was Probleme hat (der Boden ist weg oder an der falschen Stelle) zieht notfalls die INT-Leitung (ja, sorry, hatte ich nicht erwähnt) und eskaliert an den Hauptprozessor. Das wäre generell "Alles Stop" - nicht so schön.

Beispiel "da liegt ein Streichholz":
Über die Stromaufnahme kommt bei einem Bein zu früh "Boden", d.h. der jeweilige Fuss setzt auf dem Streichholz auf.
Zu diesem Zitpunkt weiss ich in etwa, wie gross das Hindernis ist und der Controller für das jeweilige Bein kann "im Rahmen sinnvoller Grenzen" eigenmächtig zwischen Adaption und Hindernis, welches zu Stop & Eskalation führt, entscheiden.

Beispiel "Abgrund":
Wenn der Boden wider Erwarten nicht auftaucht und auch im Rahmen der Adaptions-Grenzen weg ist, es also ein echter Abgrund ist ind nicht nur eine 3mm Schwelle zwischen 2 Räumen - Reaktion: Bein einziehen (wegen Schwerpunkt verlagern vom Abgrund weg), Fehlerstatus setzen INT ziehen und warten.

Der Hauptcontroller muss also alle 50ms alle Informationen von allen Beinen abholen, diese auswerten und auch wieder Steuerkommandos an alle Beine senden.

Nein, er gibt nur den Takt für die vordefinierte Schrittfolge vor. Die 50ms Auflösung habe ich willkürlich gewählt, weil ich glaube, dass die Bewegung dann flüssig aussieht und um überhaupt etwas zum Rechnen zu haben.

aber wie sieht es mit Reaktionen des Bots auf die Umwelt aus?

Kleine Hindernisse sollten die Beine kompensieren, grössere Hindernisse müssen althergebracht umgangen werden - ansonsten liegt noch 16 I/O Pins und ein unbenutzter I²C Bus am Hauptkontroller brach, an die man nach Belieben Sensoren hängen kann.

Zudem muss der Hauptcontroller ja erstmal die ganzen Bewegungsabläufe berechnen, die Aufgrund deiner Idee der Ausbalancierung auch nicht statisch sein können.

ich denke, das läuft auf ein paar Grundgangarten hinaus, die dann im 8k Flash der ATtiny84's abgelegt sind und eine gesunde Definition von dem, was das einzelne Bein noch selbständig adaptieren darf oder ab wann es besser ist, das Hindernis zu umgehen.

wenn der Bot von einer Sequenz auf eine andere "wechselt", in einer Kurve zum Beispiel, würde er stets für einen Moment "hängen", bis die neue Schrittfolge übertragen wäre.

Guter Einwand! Danke.

Ich hab's noch nicht durchgedacht (wollte es wie die kleinen Hindernisse "on the fly" adaptieren) - was aber bei Kurven auf einem Prozessor ohne Hardware-Multiplikation blöd ist

Der Hauptprozessor weiss doch schon vorher, dass eine Kurve kommen wird - Kurven könnten doch anhand der aktuellen US-Messung vom Hauptprozessor vorberechnet und während der Zeit zwischen den Schritten übertragen werden (die ATtiny's haben auch 512 Byte RAM - gut für so "Scratch-Geschichten")

Aber wie "weiß" ein Bein, in welcher Stellung die Servos weniger belastet werden, ohne dabei den Boden unter dem Fuß zu verlieren?

Hmmmm....

Ich glaube, dass die wenigste Energie benötigt wird, wenn sich das Ding auf den Boden legt, also sollte wir das den Hexapod nicht selbst entscheiden lassen. (sonst liegt er den ganzen Tag nur faul rum und spart Energie.

Mal sehen

Erst einmal Suche ich nach einer sinnvollen Alternative, die es vermeidet, einen ATmega mit Soft-PWM zu vergewaltigen um dann festzustellen, dass der einzige Prozessor nur mit dem Erzeugen der PWMs beschäftigt ist und zu sonst nichts mehr Zeit hat.

Die Trennung interner/externer Bus und das "über Board werfen von I²C auf dem internen Bus" hat sehr viel Druck aus dem Timing genommen.

Vielen Dank bisher für's Feedback.

Ralph

[MeckPommER]

Über die Stromaufnahme können je Bein 6 Fehler detektiert werden, je nachdem, welcher Servo mehr Strom zieht als erwartet, und in welcher Richtung dieser Überstrom auftritt. Das Hindernis ist in jedem dieser 6 Fälle also an unterschiedlichen Orten relativ zur augenblicklichen Beinposition zu suchen.

Damit die Last der Beine (für die waagerechte Balance) ausgeglichen werden kann, muss jedes Bein wissen, welche Last die anderen Beine in diesem Momant tragen. Also muss ein Datenaustausch aller Beine über den Hauptcontroller erfolgen, oder nicht?

Gruß und viel Erfolg, MeckPommER

[lemmings]

Damit die Last der Beine (für die waagerechte Balance) ausgeglichen werden kann, muss jedes Bein wissen, welche Last die anderen Beine in diesem Momant tragen.

Naja, vielleicht muss das nicht JEDES Bein von JEDEM anderen wissen - evtl. reicht auch nur das Bein gegenüber.

Also muss ein Datenaustausch aller Beine über den Hauptcontroller erfolgen, oder nicht?

Nein.
ich zietiere mich nochmal selbst, vielleicht kommt's ja besser rüber, wenn es im richtigen Kontext nochmal gesagt wird

Dazu ist es angeraten, dass die Hilfsprozessoren (analog, wie es mit den ABS-Steuergeräten etc. im KFZ gelöst ist) in regelmässigem Abstand ihre aktuellen Betriebsparameter (aktuelle Servostellung, Motor-Last) als Datenticket auf den internen Bus senden, um so sowohl den Master up-to-date zu halten und auch zum Zweck der Synchronisation.

Der, der die Daten verwenden will, liest einfach mit und verwertet die Daten bei Bedarf.

Ralph

[Richard]

Moin moin.

Schönes Projeckt! Dabei würde sich für die Datenübertragung
recht gut der Can-Bus eignen wenn der so Konfiguiert ist das
Alle "alle" Teielnehmer gleichzeitig lesen und wenn für sie wichtig
auswerten. So weiss jeder gleichzeitig den Zustand aller Anderen
Teielnehmer. Da beim Can Bus festgelegt werden kann wer/was
wann Vorrang hat, kann z.B. der Master jederzeit andere Daten
überschreiben, die Überschriebenen Daten werden automatisch
nocheinmal gesendet.

Damit läßt sich dann so etwas wie eine Rückenmarkfunktion
realisieren, tritt z.B. ein Bein ins leere, bekommt der BeinKontroller
von diesem Bein (für diese) Meldung oberste Rechte. Anhand der
ID (dieses Beines) kann dann das Korrospondierende Bein (am
Masterkontroller vorbei) schon einmal einen entsprechenden
"ausführen". Der Masterkontroller hat etwas Zeit und sendet
danach die Restlichen Steuerbefehle....

Das schöne an der Rechtevergabe (über das Datenbyte) man kann
Permanennte Übertragung mit Polling mischen. Der Master macht
Poling mit reduziertem Recht (2), die Slaves senden dauernd ihren Zustand mit Reduziertem Recht (3). Tritt ein Problem bei einem
Slave auf..(Tritt ins Leere) bekommt dieser Slave für diese Meldung
Obermasterrecht (1).

Das funktioniert "eigentlich" einfach, der Cam Bus ist Low Aktiv.
Eine Mastersendung liest eine gerade laufende Übertragung mit
und zieht übertragene Hig Level (Bits!) einfach auf Lo. Der eigentliche
Ursprungssender liest auf RX seine eigene Nachricht mit,
Wurde diese "Überschrieben" sendet er die Originalnachricht
einfach SO lange weiter bis diese selber Originalgetreu mitgelesen
werden konnte.

Hier wurde schon oft über Sinn/Unsinn von Multiprozessor Anwendung
geschrieben, sind die Dinger doch heute SO weit das ein großer
reicht (?).Das ist eh ein Glaubenskrieg. Aber kaum ein einzelner
Prozessor dürfte in der Lage sein so etwas wie "Reflex"
Rückenmarkfunktion in Echtzeit zu realisieren. Klar, die "Reflexe"
müssen als ISR in den jeweilig einzelnen "Bein µC´s" hinterlegt
sein.

Wie auch immer, mir gefällt dieser Ansatz

Gruß Richard

[MeckPommER]

Das mit "dem Jeder Slave sendet einfach mal so" wird in der Praxis bestimmt interessant ^^. Wie Richard schon schrieb, gibt es aber Bus-Strukturen für sowas, wie z.B. den CAN-Bus. Ob sich das aber auf einem ATtiny realisieren läßt, bezweifle ich.

lemmings, ich bin der Ansicht, das wirklich jedes Bein wissen muss, welche Lasten alle anderen Tragen. Wenn sich nur die jeweils gegenüberliegenden angleichen, wird der Bot kaum irgendeine stabile Ruheposition einnehmen können. Wird ein Bein durch einen unebenen Boden stärker belastet, so reagiert nur das gegenüberliegende Bein und die beiden Beine machen dann - im Verhältnis zu den anderen 4 Beinen - Unfug. Da ist kein sinnvoller Ausgleich möglich.

Es stimmt, es ist ein spannender Ansatz und auf dem Weg zum Ziel warten sicherlich noch manche interessante Nebenaspekte. Bin gespannt, wie sich dein Bot entwickelt!

Gruß MeckPommER

[lemmings]

für die Datenübertragung recht gut der Can-Bus eignen

Meine Idee mit der Trennung der Busse hat mir den Vorteil gebracht, das ich an einer relativ zeitkritischen Stelle (Steuerung der Beine für eine gleichmässige sanfte Bewegung)
alle äusseren Anforderungen, die mich stören (Protokoll-Overhead etc) rauswerfen und von den verschiedenen Ideen der anderen Bussysteme das Beste herauspicken kann.

Hardware ist a la I²C (weils so schön einfach ist), das Protokoll ein Gemisch von guten Ideen. Ein Bischen I²C, ein Bischen CAN-Bus, ...
Der interne Bus ist ja völlig isoliert, hier ist der Weg das Ziel - kurz, knackig, effektiv - aber von Standards bremsen lassen - niemals

Da beim Can Bus festgelegt werden kann wer/was wann Vorrang hat, kann z.B. der Master jederzeit andere Daten überschreiben, die Überschriebenen Daten werden automatisch nocheinmal gesendet.
<...>
Das funktioniert "eigentlich" einfach, der Cam Bus ist Low Aktiv.
Eine Mastersendung liest eine gerade laufende Übertragung mit
und zieht übertragene Hig Level (Bits!) einfach auf Lo. Der eigentliche
Ursprungssender liest auf RX seine eigene Nachricht mit,
Wurde diese "Überschrieben" sendet er die Originalnachricht
einfach SO lange weiter bis diese selber Originalgetreu mitgelesen
werden konnte.

Hier bin ich noch nicht so tief im Detail aber ich stelle für mich fest, dass es keine schlechte Idee wäre, den CAN-Bus bezgl. seiner Vorteile auszuschlachten.

Bisher habe ich nur festgelegt, dass die Kommunikation seriell erfolgt und ich dazu zwischen den Controllern ein 3-Draht-Netz haben werde.
1x Clock, einmal Daten und eine Interrupt-Leitung (die ich mit dem CAN-Protokoll wohl gar nicht mal brauche).

Glaubenskrieg.

Eben. Software-PWM hängt für mich direkt zusammen mit "ruckeligen" Bewegungen, was letztlich auch wieder nur die Konsequenz aus einem zu schwachen Prozessor ist.
Ein besserer Prozessor (BGA100 o.ä.) lässt sich bei realistischen Stückzahlen nicht mehr von Hand bestücken.
Für mich gibt es heute keine Alternative zur Verteilung auf mehrere Prozessoren und das vielfach beschworene Timing Problem mit dem seriellen Bus sehe ich eher bei den Mythen und Sagen.
Grob überschlagen und selbst wenn ich die Hälfte vergessen hätte - das Timing ist derart entspannt - ich hab da ein gutes Gefühl

Ralph

[Richard]

Moin moin.

Das Original Can Protokoll ist etwas kompliziert, deshalb gibt
es auch AVR`s mit intregiertem Can Bus. Welche Typen
habe ich jetzt gerade nicht zur Hand.

Ich habe einmal die damals für (mich) brauchbaren Teile
in ASM Selber geschrieben.

1.) Jedes übertragene BIT wird gleich wieder eingelesen
b.z.w. überprüft ob ein High Bit mit Low überschrieben wurde.
Wenn ja hat ein höher Berechtigter "zugeschlagen" und die
Sendung (BYTE) muß wiederholt werden. Dazu wird dann nur
noch gelesen bis ein End Byte kommt.
Das sollte aber auch mit ganzen Byte Vergleich klappen?

2.) Der Bustreiber !muß! ein Canbustreiber sein (open Collecktor)
so können alle Teilnehmer Parallel auf den Bus zugreifen und
nötigenfalls gesendete High Bit`s mit Low überswchreiben.

RS232 oder I²C sind deshalb nicht geeignet, da kommt dann nur
Datenmüll zustande.

Das mit dem "gegenüberliegenden Bein" war als Demo gedacht.
Wenn eh alle gleichzeitig mitlesen wissen auch alle Beine was die
Anderen gerade so machen, der Master natürlich auch.

Wobei der Master eigentlich für die Grobe Richtung zuständig ist,
den Rest müssen die Beinkontroller "unter sich" aushandeln.

Gruß Richard