-
        

Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 16

Thema: Hexapod - mal etwas anders

  1. #1
    Benutzer Stammmitglied
    Registriert seit
    08.06.2009
    Alter
    52
    Beiträge
    83

    Hexapod - mal etwas anders

    Anzeige

    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
    Miniaturansichten angehängter Grafiken Miniaturansichten angehängter Grafiken hexa2p.jpg   hexa2b.jpg  

  2. #2
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    19.07.2007
    Alter
    53
    Beiträge
    1.080
    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
    Mein Hexapod im Detail auf www.vreal.de

  3. #3
    Erfahrener Benutzer Roboter Experte Avatar von ikarus_177
    Registriert seit
    31.12.2007
    Ort
    Grein
    Alter
    24
    Beiträge
    601
    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

  4. #4
    Benutzer Stammmitglied
    Registriert seit
    08.06.2009
    Alter
    52
    Beiträge
    83
    Zitat Zitat von MeckPommER
    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.

    Zitat Zitat von MeckPommER
    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.

    Zitat Zitat von MeckPommER
    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.

    Zitat Zitat von MeckPommER
    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.

    Zitat Zitat von ikarus_177
    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")

    Zitat Zitat von ikarus_177
    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

  5. #5
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    19.07.2007
    Alter
    53
    Beiträge
    1.080
    Ü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
    Mein Hexapod im Detail auf www.vreal.de

  6. #6
    Benutzer Stammmitglied
    Registriert seit
    08.06.2009
    Alter
    52
    Beiträge
    83
    Zitat Zitat von MeckPommER
    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.

    Zitat Zitat von MeckPommER
    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

    Zitat Zitat von lemmings
    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

  7. #7
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    08.01.2006
    Beiträge
    4.556
    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

  8. #8
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    19.07.2007
    Alter
    53
    Beiträge
    1.080
    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
    Mein Hexapod im Detail auf www.vreal.de

  9. #9
    Benutzer Stammmitglied
    Registriert seit
    08.06.2009
    Alter
    52
    Beiträge
    83
    Zitat Zitat von Richard
    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

    Zitat Zitat von Richard
    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).

    Zitat Zitat von Richard
    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

  10. #10
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    08.01.2006
    Beiträge
    4.556
    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

Seite 1 von 2 12 LetzteLetzte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •