ZitierenIch seh auf der Platine gar kein Anschluss für die Stromversorgung von Logik und Servos? Bin ich blind oder fehlen die einfach?
http://lutschi.biz/navi/ssp_186_CAN_Bus.pdfZitat von Richard
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
kann das so funktionieren?
Wo seht ihr die Haken?
Ralph
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
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<
Hallo,
super Projekt, endlich nochmal ein gut durchdachtes
Ich werde natürlich mitlesen und bin gespannt wie es weiter geht.
Benutze doch einfach einen MicroSD Slotso ein SD-Slot ist ja brutal gross PrayDie Dinger sind so klein, dass ich sie immer verliere bzw. verlege
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
Mein Hexapod im Detail auf www.vreal.de
Ä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
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.ph...=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
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.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
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
Berechtigungen
Lesezeichen