Kopfsache - und ein m1284, etliche Servos, viel Alu

Zur Kommunikation von PC oder RasPi per WLAN oder Kabel mit meinen Platine/n.

Primäres Merkmal: Die Telegramme können unterschiedliche Länge haben.
Sekundär: Die Übertragung über interruptbasierte UART+FIFO geht störungsfrei, mittlerweil mit nem bescheidenen Sende-/Empfangspuffer von 32 Bytes; waren mal 128 Bytes.

Kurz der Aufbau und ein paar Codeschnippsel als Skizze:

Definition der einzelnen Telegramme, Beispiel:

Code:

---

  #define  KOMMANDO_DATS      'd'    // (aktuelle) Daten der Motoren
  #define  KOMMANDO_DATS_LEN    1    // Kommandolänge
  #define  KOMMANDO_MOSTL      'M'    // Fahrbefehl Motoren Mnikkk. Mot1 = re
  #define  KOMMANDO_MOSTL_LEN    6    //  n = {1, 4, 5}, Motor 1re, 4li, 5beide
                                        //    i = { r, l } Drehrichtung
                                        //    kkk  Stellwert für MotorPWM

---

Empfang initialisieren:

Code:

---

  zeiger              = 0;
  telegrammlaenge      = 0;

---

Empfang eines Telegramms abwarten:

Code:

---

    if ( ! ukbhit0 () )
      continue;
...
    zeichen_aus_fifo = ugetchar0();

---

... und nun die Auswertung:

Code:

---

    if (zeiger == telegrammlaenge)
    {
        zeiger          = 0;
        telegrammlaenge = 0;
      /*  Die Funktionen koennen nun gemuetlich das
        Telegramm auswerten.      */
...
// - - - - - - - - - - - - - - - - - - - -
//      Wurde "KOMMANDO_DATS" = "D" erkannt ?  DatenAusgabe
    if (mein_rx_buff [0] == KOMMANDO_DATS)      // Tastatur-Eingabe "D"
    {                                          //
      dat_aus ();                      // Motordaten ausgeben
    }        // Ende if (mein_rx_buff [0] == KOMMANDO_DATS)
// - - - - - - - - - - - - - - - - - - - -
//      KOMMANDO_MOSTL MOtoren STeLlen : Mnikkk, Motor n = {1, 4, 5} 1, 4, beide
        // i { +, 0, p, t, x }  Drehrichtung 0/+ => math. pos, - => math. neg
        //        p = aus, x = Schnellstop/Brems
                                //  kkk  Stellwert für MotorPWM und Rampentimer
    if (mein_rx_buff [0] == KOMMANDO_MOSTL)   
    {                          // Motor 1=re/12 oder 4=li/34 oder 5=beide ?
      do_MOSTL2 (mein_rx_buff); // Motoren stellen/ansteuern                  r1n
    }        // Ende if (mein_rx_buff [0] == KOMMANDO_MOSTL)
...

---

Das macht die Testerei wegen der einfachen Kommunikation PC<=>Platine wirklich leicht.
Noch etwas Gutes ist dabei: Ich kann natürlich dem UART-Puffer ein I²C-Telegramm "unterschieben" - sprich: eine Funktion ist testbar per PC-basierter Kommunikation, sie läuft im praktischen (z.B. autonomen) Betrieb genau gleich über I²C-Telegramm ab.

Dank an Sterntaler für Hilfen, Diskussionen, Korrekturen, Zusprachen.

Das Projekt Archie ist ein Stück vorangekommen. Anfangs hatte ich noch gepostet etwas wie "mal halber Durchblick bei I²C" - gefühlt war es weniger. Auch die ganze Koordination und Organisation der Controllerkommunikation war für mich ein sattes Stück Programmierarbeit, aber mittlerweile hat das Projektchen einen gewissen, präsentablen Grad erreicht.

Und Archie "spricht", läuft und bewegt sich. Das Ganze so in einer Art Tasksteuerung per RC-5 in 1-Byte-Befehlen oder einem Dreierpaket. Aber Autonomie ist mir an sich kein Fremdwort und wenn erst die Funktionen selbst und die Kommunikation gut läuft, dann ist das Aufwerten mit autonomen Funktionen auch nicht mehr weit. Bis zur Maker Faire Hannover 2014 wirds nicht bis zum letzten i-Tüpfelchen reichen, aber ich bin mit dem aktuellen Baufortschritt doch zufrieden.

Wer will kann mal einen kurzen Blick drauf werfen:

https://www.youtube.com/watch?featur...;v=I5edmA1O4LA

Sehr sehr geil! Ich bin beeindruckt und auch etwas neidisch! Freue mich schon sehr darauf, ihn bald live zu sehen und dich über die ganze Technik auszufragen.

Sehr gut gefällt mir die Armbewegung und vor allem die Sprachausgabe. Werden da Soundfiles abgespielt, oder wie geht das?

Zitat:

---

... über die ganze Technik auszufragen ... vor allem die Sprachausgabe ... Soundfiles abgespielt ...

---

Sprachausgabe ist EINER der vielen sollteso-und-gehtebenanders Punkte. Eigentlich wollte ich ein text-to-speech über das raspi machen. Aber weil ich dazu noch keinen Einstieg gefunden habe musste eben das WTV020 herhalten. Das klappt überraschend gut und die Qualität ist auch nicht schlecht. Und es ist mehr Speicherplatz da als sinnvoll sein kann:

Zitat:

---

Zitat von oberallgeier

... Auf eine MikroSD mit 1GB gingen demnach satte 44tausend Sekunden ...

---

Witzig ist meine aktuelle Ausgabe über einen Kopfhörer in einer Filmdose, ich war selbst verblüfft wie gut das geht. Schon fast ein minimalistischer kleiner Brüller, der mit der Elektronik noch bequem Platz im Kopf gefunden hatte. Aber ich stecke bis dahin vielleicht noch/auch mein X-mini dran. Leider größer, auffälliger - aber eben von beachtlicher Lautstärke, kommt schon eher an Deine Brüllwürfel ran, vielleicht sogar mehr *gg*

......Anhang 28358
Legende (zum kleinen WTV020-Träger-Platinchen):
oben - 5V-Anschluss,
Links - Lautsprecher-Ausgang,
Rechts: Busy, Clock und Data.
Rechts unten der LDO 5V-3,3V, die Pegelanpassung von Atmel auf 3,3V sind Spannungsteiler auf der Rückseite.
Hinter dem Platinchen die Filmbüchse bei der in einem Bodenausschnitt eine Kopfhörerpille sitzt.

Zitat:

---

... Sehr gut gefällt mir die Armbewegung ...

---

Danke, schön, dass Du die Bewegung positiv beurteilst.

Es sieht hübsch aus und man empfindet es ja auch als gleichmässig, finde ich auch. Dabei ist das nur eine zeitliche Synchronisierung der Gelenkziele (jeder Teilbewegung) mit Stützpunktvorgaben im Periodentakt der Servos - bei mir rund 40 Hz. Das führt zu der glatten Bewegung aber leider zu keiner sauberen TCP-Spur.

Ideales Ziel für mich wären humanoid-ähnliche Abläufe. Aufwändiger zu Programmieren, klar, aber das ist weniger das Problem - - wenn man mal weiß, wos lang geht *ggg*. Aber humanoid ist ein teils häufiger Wechsel des TCP: Finger- oder Daumenspitzen, Knöchel, Handgelenkwurzel oder gar TCP-Kombinationen wie Zeigefinger- und Daumenspitze oder Ellbogen und Handballen. Gravierender: wo bekomme ich den Mathe-CoProzessor her, der mir FP im Millisekundentakt - höchstens Millisekunden - transzendente Funktionen rauswirft?

Zusätzlich könnte man z.B. die Überlegungen von Katja Mombaurs Gruppe zur Optimierung der Beinbewegung einfließen lassen - wenn man noch mehr Rechenaufwand möchte.

Abschließend noch ein kleines Problemchen - bei den skizzierten aufwändigeren Bewegungsstrategien sind Servos egal welcher Preisklasse natürlich out. Da müssen Stellantriebe her denen man auch mal ne Beschleunigungsrampe überstülpen kann - - mit selbst und fallweise wählbaren Parametern - - -

Es ist also noch ein bisschen Fortschrittsmöglichkeit für mich drin wenn mir eine Zwischenlösung einfällt. Ist aber ein Abschnitt fürs nächsten Kapitel oder danach.

Find das Ding auch enorm Klasse.

Zu den Bewegungen: beim Arm fällt es mir auf: man hebt gewöhnlich nen ausgestreckten Arm _nicht_ an.
Beobachte dich mal, selbst wenn du nach vorn zeigen willst, winkelst du den Arm zuerst etwas an und hebst ihn dann hoch-dann streckst ihn wieder.
Der Grund dafür wird im Artikel über K.Mombaur genannt: Energieeinsparung. Nen gestreckten Arm anheben braucht mehr Kraft.
Leider wird sich das zwar, aufgrund gewisser Überlegungen, simulieren lassen, aber ich glaub nicht, dass wir in unserer Liga es schaffen, Bewegungsabläuft im voraus so zu berechnen. Ums wirklich menschlich wirken zu lassen, kämen dann noch weitere Aspekte hinzu.

Kennst du die Software Poser? Das ist ein Figuren-Animierprogramm, von dem es ab und zu ne kostenlose Version gab.
Dort kann man virtuelle Puppen (Tiere auch) schon recht realistisch bewegen. Da das auch in Zeitlupe geht, ne gute Inspiration, wenn mans zumindest nachbilden will. Interessant sind die, relativ guten, vorgefertigten IK-Ketten in dem Programm. Schon, wenn man nen Arm ausstreckt, bewegt sich irgendwie fast alles..

Auch Blender (Open Source) eignet sich: dort kann man virtuelle Skelette erstellen, und die dann nach allen möglichen Parametern (Bewegungen einschränken, aber auch komplette IK-Ketten bilden, unterschiedliche Gewichtungen einstellen usw.), dort kannst du im Grunde deinen Archie virtuell nachbilden, und dann mal studieren, wie sich was am "realistischsten" bewegen sollte.

Vielen Dank für den Beifall und ich freu mich schon über weitere Diskussionen, Kritiken und Ratschläge!

Zitat:

---

... Zu den Bewegungen ... Der Grund dafür ... Energieeinsparung ... Poser ... Auch Blender ...

---

Sly, das ist ja eine ganze Latte von Anregungen, danke. Ja, die Optimierungsgrundlage von Katja M ist schon ziemlich pfiffig/ausgefuchst! Übrigens, eines meiner Befehlstelegramme heißt auch Poser - Position Servo ;.-.)

Der Gedanke an eine Simulation der Bewegungen ist mir noch garnicht gekommmen. Find ich ja richtig gut! Andererseits - es ist schon entspannend, befriedigend und motivierend das Dingelchen laufen zu lassen und die Bewegungen am laufenden Objekt einzuschätzen. Zumindest geht es mir so.

Dass ich dabei auch so nebenbei an sagenhaft freundliche Lieferanten gerate (Encodermotor hat eine Signalphase immer auf high - der Lieferant liefert mir auf Garantie den Ersatz binnen zwei Tagen - und dann wars doch eine mikroskopische Kurzschlussbrücke) und Ähnliches - das macht doch auch noch Laune neben den ganzen ungeliebten Fehlersuchen. Das liefert die Simulation vielleicht nicht so sehr. Andererseits habe ich bei meinen Aerodynamikaktivitäten auch viel Freude an den virtuellen Versuchen gehabt.

Ich werd mal den Anregungen nachgehen. Danke jedenfalls dafür.

Zitat:

---

... man hebt gewöhnlich nen ausgestreckten Arm _nicht_ an ...

---

Völlig richtig - auch wenn ich lange Jahre genauso trainiert hatte (LuPi, FP, auch mal nen 6Zöller 357MAG).

Kannst deine Lieferanten ja mal bei mir vorbei schicken-können mitbringen, was rumliegt, ich nehm alles. :D

Was die Bewegungen bzw. das "natürliche" angeht: ich hab mir mal die Mühe (es _ist_ eine) gemacht, das richtig zu lernen. Virtuell meine ich. Das kriegt man _nur_ hin, wenn man mal mit offenen Augen rumläuft. Einfach mal irgendwas anheben (nich verkrampft, sondern so normal wie möglich), und sich dabei selber genau beobachten: wann bewegt sich was....und _dann_ überlegen, wieso eigentlich....

Übrigens modellier ich mir auch schnell mal irgendwelche technischen Dinge, einfach, um zu gucken, ob dieses oder jenes, was in meinem Geiste herumschwirrt, so überhaupt funktionieren kann. Hat man früher mit Karton gemacht (tu ich heute auch noch ab und zu, manchmal gehts einfach schneller) aber in Blender kann ich dann auch gleich noch gucken, ob meine Wunsch-Chassis-Farbe wirklich zu den Sensoren passt. ;)


Aber im Ernst: dein Archie hat irgendwie nen Charakter, den ich Klasse finde. Richtig begeistert war ich dann von dem Satz: "Mein Antrieb is elektrisch!". Weiss selber nicht, wieso aber der passt soo zu dem Burschen, wie die Faust aufs Auge.
Mach weiter mit dem Kerl. Und erzähl drüber...

Zitat:

---

Zitat von Rabenauge

... Richtig begeistert war ich dann von dem Satz: "Mein Antrieb is elektrisch!" ... Und erzähl drüber...

---

Danke für das Lob.

Und mal ganz WICHTIG: danke allen, die mich hier motiviert und mit Problemlösungen/Ratschlägen unterstützt haben. So wars ein hübscher Erfolg und Archie (eigentlich RJ5-jr) - sogar auch das MiniD0 - kommt in den Berichten bzw. Bildreportagen zur Makerfaire häufig vor.

Die anstrengede Arbeit kommt jetzt: Aufbau bzw. Ausbau der 50%-Lösung um einige zehn Prozentpunkte. Aber ich hab ja Zeit (obwohl sich am Horizont eine Jugend-forscht-Gruppe abzeichnet, die vielleicht ein bißchen Motivation braucht).

Nach längerer Ruhepause - für Archie und seine Peripherie - gibts also einen mikroskopischen Fortschritt in Teilprozentgröße. Der Hindernis-Erkennungsfeld-Sensor ist nach der Steckbretterprobung in einer ersten funktionierenden Version fertig.
......Bild hier  

Damit kann ein bis zu DINA4-großer Bereich getestet werden. Die Platine ist schauderhaft, ich weiß, aber für einen Funktionsnachweis gehts ganz gut. Erste Messungen zeigen gute Ergebnisse, nach einer gewissen Justierung werden ausführliche Ergebnisse/Messdaten vorgestellt. Gesteuert wird das Ganze von einem mega328/babyorangutan. Die vier Sensorpaare sind mit 19mmx47mm auch nicht viel größer als ein einziger, zweiäugiger US-Sensor, allerdings ist die Funktion keine millimetergenaue Messung, aber im Zentimeterbereich relativ vertrauenswürdig.

Zum Aufbau: innen das LED-Feld, 4xLD274-3, mit einem Elko für den Stromstoßhunger und gesteuert von einem BC337 links neben dem Elko, drumrum die blechgeschirmten 4 SFH5110.