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

[lemmings]

Das Original Can Protokoll ist etwas kompliziert

http://lutschi.biz/navi/ssp_186_CAN_Bus.pdf :-)

ob man priorisierte Mechanismen braucht, die wieder eine besondere Bus-Hardware brauchen, hängt doch von den Anforderungen ab.
Die CAN-AVRs hatte ich mir angesehen, das ist zu Umfangreich und auch mechanisch vom Footprint des Chips zu gross, das fängt erst bei 64 Pins an und das lötet auch nieman freiwillig gerne von Hand.

Bei insgesamt 7 Teilnehmern sehe ich das entspannt.

die ATtiny84's haben 8k Flash, die ich sonst nicht verwenden muss.

eine Beinposition ist bei einer Auflösung von 256 pro Servo mit 3 Bytes beschrieben, d.h. ich bekomme also gut 2700 Positionen je Bein gespeichert (im Moment gehe ich davon aus, dass alle Beine den gleichen Inhalt im Flash benötigen, jeweils um ein paar kleine Positionen in der Sequenz versetzt bzw. auch gespiegelt).

Wenn ich 4 Gangarten haben will und auch Schrittfolgen für rechts-links-bewegungen vorbereitet im Flash habe brauche ich 12 Schrittsequenzen, kann also mit dem verfügbaren Speicher jeden Schrittzyklus in 225 Einzelschritte zerlegen.

danach wissen alle Beteiligten, was mit der jeweiligen Position gemeint ist und der Master kann diese Positionen abrufen, ohne jedes Mal die Einstellungen berechnen zu müssen.

Auf diesem Weg kann ich jede von 2700 Beinstellungen mit nur 12 Bit beschreiben.
in sinnvollen Grössenordungen (ganze Bytes) also 2 Bytes.
Bei den oben beschriebenen 100khz Bustakt (das ist für mich mittelmässig schnell, da ist auch noch "Luft" nach oben) würde dann die Übertragung des "Marschtaktes" 4 Bytes gross sein.

Wenn jeder Schritt 5cm weit reicht und ich 200 "Marschtakte" für jeden vollständigen Schritt brauche, alle 50ms ein Takt kommt - dann dauert ein vollstandiger schritt von 5cm 10 Sekunden - das ist entschieden zu langsam.
Entweder muss ich die Auflösung für einen Schritt verringern (50 statt 200 brächte mich von 18m/h auf 72m/h, das ist immer noch erheblich zu langsam) und/oder die Taktrate erhöhen (100% Zeitausnutzung brächte Faktor 10 und trotzdem nur 720m/h - Mein ungefähres Ziel liegt so bei 10.000m/h :-) )

Da ich mit den Prozessoren an den Beinen nicht nur lokal reagieren will, sondern den Hauptprozessor entlasten will muss ich mir zusätzlich etwas einfallen lassen.

Beispielsweise eine separate "Marschtakt-Leitung".
Der Hauptprozessor würde zu Beginn eines Schrittes den Schrittyp ankündigen und auf der separaten Leitung dann z.B. je Schritt 200 Taktzyklen ausgeben, denen das Bein dann jeweils folgt. bei 100khz Marschtakt, 200 Teilschritten pro Schritt und 5cm Schrittweite wäre ich so auf 18 km/h - das sollte ausreichen. :-P

zur Synchronisation und zur Einleitung eines Schrittes sendet der Master den Schrit-Typ
"Master an Alle" (1 Byte) und im MessageTyp z.B. 0xE2 (1 Byte) für die Schrittfolge 2.
danach führt jeder Pegelwechsel einen Teilschritt aus, um nach 200 Teilschritten wieder einen weiteren Schritt einzuleiten.

4 Schrittfolgen - Gallopp, Trab, Gehen, robben :-)
jeder schritt ist (abhängig vom Schrittyp) eine definierte Länge weit
zu jedem Schritt gibt es dann noch eine versetzte Schrittfolge, um nach rechts oder links zu laufen, die auch definiert sind.
jede schrittfolge ist in 200 Teilschritte zerlegt, die mit bis zu (naja, vielleicht geht ja mehr :-) ) 100khz Takt abgearbeitet werden.

kann das so funktionieren?
Wo seht ihr die Haken?

Ralph

[HannoHupmann]

Ich seh auf der Platine gar kein Anschluss für die Stromversorgung von Logik und Servos? Bin ich blind oder fehlen die einfach?

[lemmings]

Ich seh auf der Platine gar kein Anschluss für die Stromversorgung von Logik und Servos? Bin ich blind oder fehlen die einfach?

Mitten drauf die 2 Lötaugen (da wo 5VDC stehen sollte) - ich hatte Streit mit eagle3d, der Klemmblock war immer verdreht 8-[
Ich werde aber Servo-Spannung und Logik-Spannung trennen, das wird dann eine 3- statt 2-poliger Klemme.

Langsam wird's voll auf der Platine :-)

Ich überlege, ob ich Kompass und Neigungssensoren auf dem Board brauche ... und ein SD-Slot am Master wäre schön für die Map... oder ob das ein Aufsatz-Modul wird... so ein SD-Slot ist ja brutal gross [-o<

[daniel.weber]

Hallo,

super Projekt, endlich nochmal ein gut durchdachtes :)
Ich werde natürlich mitlesen und bin gespannt wie es weiter geht.


so ein SD-Slot ist ja brutal gross Pray
Benutze doch einfach einen MicroSD Slot :) Die Dinger sind so klein, dass ich sie immer verliere bzw. verlege :(

[MeckPommER]

Für mich beisst sich noch ein wenig, das die Entwicklungsrichtung der Software in zwei Richtungen gleichzeitig geht. Einmal in das vorprogrammierte Abarbeiten von Servopositionen aus dem EEPROM und einmal im schnellen und intelligenten Reagieren auf Umwelteinflüsse.

Das wird meiner Meinung nach mehr Probleme verursachen, als das es die Sache vereinfacht.
Arbeitest du vorgegebene Servopositionen ab, so hat dein Bot eigentlich keine Ahnung von seiner Position im Raum. Willst du Beinpositionen gegeneinander ausgleichen oder Hindernisse detektieren, so muss der Bot wissen, wo im Raum seine Beine sind.
Das Umschalten zwischen Berechneten und Abgespeicherten Servopositionen wird nicht ordentlich funktionieren - ist mal meine Prophezeiung.
Wenn du vorberechnete Servopositionen durch Berechnungen auf die aktuelle Situation anpassen willst, wird es mehr als knifflig, denn z.B. um ein Bein an einer anderen Stelle auf den Boden zu stellen, brauchst du wieder die realen Positionen vom Bot mit seinen Beinen.

Anmerkungen am Rande - vielleicht nützlich für dich ...

Du wirst im Laufe der Entwicklung feststellen, das dein Bot je schneller du ihn zu betreiben versuchst, immer mehr den geforderten Servopositionen hinterherläuft. Servos sind nicht unendlich schnell und es braucht seine Zeit, bis die geforderte Position erreicht ist. Bekommt der Servo schon vor Erreichen dieser Position wieder einen anderen Wert, so wird er niemals an der Position, die du schon für erreicht erachtet hast, ankommen.

Ich ... also ich ganz persönlich, halte 8 Bit-Auflösung für nen Servo für viel zu gering. Für schnelle Schrittfolgen mag es gehen, aber wenn der Bot sich nur mal langsam und nur ein wenig bewegen soll, dann sieht man das Ruckeln schon sehr deutlich.

Gruß MeckPommER

EDIT: ach ja, und nen SMD-Atmega mit 64 oder 100 Pins anzulöten ist nur eine Frage der Technik und einfacher, als man zunächst denkt :-)

[lemmings]

Arbeitest du vorgegebene Servopositionen ab, so hat dein Bot eigentlich keine Ahnung von seiner Position im Raum. Willst du Beinpositionen gegeneinander ausgleichen oder Hindernisse detektieren, so muss der Bot wissen, wo im Raum seine Beine sind.

Ähmmmm... ja, so ungefähr.

Ich versuchs mal an einem Beispiel zu erklären, wie ich das vorhabe.

Der Haxapod stapft da also mit festem Schritt vor sich hin und mit einem Mal ist der Boden abschüssig - nicht viel, aber so gleichmässige 10% Gefälle.
Die Beine werden anfangen, die vermuteten Schlaglöcher zu adaptieren und je weiter der Hexapod vorwärts geht, desto hochbeiniger wird der Gang. Die Platform wird ja in konstanter Höhe gehalten.
Irgendwann ist die erlaubte Adaption erreicht und das Ding bleibt stehen.

Einerseits könnte ich jetzt sagen, dass der Hauptprozessor das gefälligst vorher erkennen soll, dass es abschüssig wird... ist aber ein wenig blöde, das alles vermessen zu wollen. das muss auch einfacher gehen.

Grundsätzlich gehe ich vom Mittelpunkt des Hexapod als Referenz aus und wenn das Ding Treppen steigen soll brauche ich eine 3D-Map (daher auch die Idee mit der SD-Karte - für die Micro-SD hab ich noch keine Sockel/Slots gefunden).

Wenn sich das Ding sowieso 3D im Raum bewegt (sonst kann es ja Hindernisse in gleich geschnittenen übereinanderliegenden und mit Treppe verbundenen Räumen nicht bewältigen) brauche ich doch ggf. nur eine Niveau-Korrektur über alle Beine machen.

der Abstand vom Ende der Beine zum Mittelpunkt ist ja bei allen Beinen gleich und auch bekannt.

Mir ist auch bewusst, dass das Ding fürchterlich auf die Nase fällt, wenn man zu Beginn 18km/h Trab erwartet. :-) :-) :-)

Die Physik ist da unerbittlich, sobald Mechanik im Spiel ist muss die Elektronik immer warten :-) Massenträgheit kann schon sehr hinderlich sein.

18km/h würde ich als "Ziel erreicht" definieren, das dient mir derzeit zur als theoretische Messlatte. Und solange ich das mit realistischen Annahmen in der Elektronik hinbekomme bin ich sicher, dass der Flaschenhals immer in der Mechanik liegt und nicht wie bei den Soft-PWMs in der Elektronik/Software.

<kidding>
Aber wenn die Mechanik tatsächlich mit dem Takt der Elektronik mithalten kann und das dann mit knapp 20km/h in der Gegend rumrennt... witzig wär es doch... noch cooler wären etwas mehr als 80km/h - dann könnte man das ding darauf abrichten, Nitro-Cars zu fangen. http://www.hpieurope.com/kit-info.php?lang=de&partNo=868
So ein paar getunedte Hexapods mit 3 mikrofonen drauf im Wald nahe der Modell-Rennstrecke aussetzen und wenns laut wird den Störenfried fangen gehen.
Die RC-Fraktion guckt bestimmt gut sparsam, wenn da 'ne horde viecher aus dem wald gerannt kommt und sich auf die autos setzt.
</kidding>

Ralph


EDIT: ach ja, und nen SMD-Atmega mit 64 oder 100 Pins anzulöten ist nur eine Frage der Technik und einfacher, als man zunächst denkt :-)

Ich weiss - ich hab hier auch so nen Severin Grill als Reflow Ofen, benutze aber für die Feinarbeit den Weller PyroPen - mit Zinnpaste in der richtigen Dosierung ist das wirklich einfach.
Wenns nachbaufähig sein soll ist die Messlatte aber trotzdem zu hoch.
Ich weiss seit 30 Jahren, welche Seite vom Lötkolben heiss wird - mir macht das nichts.
Was ich sehen kann kann ich auch belöten. Trotzdem ist 100 Pin BGA mühsam und nichts für Gelegenheitslöter 8-[