Wiederbelebung eines RN-Control Boards

[juergen009]

Hallo zusammen,
Habe nach einigen Jahren meine RN-Cotrol mit Atmega 32(1.4) wieder ausgegraben und möchte diese wieder in Betrieb nehmen. Habe mal probeweise 10 V angelegt; das Board piepst, aber sonst tut sich nichts. Muss eventuell der Chip erneuert werden? Ich würde am liebsten mit AVRStudio Version 4.19 in C++ programmieren. Das Ganze soll mal ein 6-beiniger Robot mit 18 Servos werden.
Ein Erweiterungsboard SD21 habe ich auch noch.

Bin für jeden Tip dankbar

Jürgen

[oberallgeier]

Hi Jürgen!

.. RN-Cotrol mit Atmega 32(1.4) .. probeweise 10 V .. das Board piepst, aber sonst tut sich nichts .. eventuell der Chip erneuert werden ..

Hast Du noch die sonstigen Unterlagen? Schaltplan? Pinbelegung(en)? Die Beschreibungs-pdf (33 Seiten) ? Originalcode-hex und Fusestellung gesichert? Am besten die damals mitgelieferte CD ? In der Beschreibung steht z.B.

.. Falls Sie ein Messgerät haben, können Sie auch den Strombedarf des Boards checken. Wenn alles korrekt zusammengebaut wurde, muss dieser deutlich niedriger als 100 mA liegen. Bei 16 Mhz und Mega 16 bei ca. 60 mA!. Ein wesentlich höherer Strom würde auf Lötfehler hin deuten.
Ein weiterer Test wäre das anfassen des Spannungsreglers 78S05. Er darf warm bis sehr warm werden, aber man darf sich nicht dran verbrennen. Er ist im übrigen gegen Überlastung geschützt! ..

Hast Du die BAuteile auf strammen Sitz (und Korrosion ! !) geprüft? Lotbrüche? Läuft IRGENDEINE Textausgabe beim Start über UART? - vermutlich 38 oder 19 kBd ?

.. Ich würde am liebsten mit AVRStudio Version 4.19 in C++ programmieren. Das Ganze soll mal ein 6-beiniger Robot mit 18 Servos werden ..

AVRStudio 4.19 und C++ ? Geht das denn? Ich dachte mit C++ kann man erst mit späteren Versionen arbeiten? Ich programmiere (meine ersten cpp-Schritte) mit Studio 7, den Rest mit Studio 4.18, Build 700. Mal nur so - als ganz grobe Schätzung nach Deinem geplanten Projekt: wenn Du nicht unbedingt mit dem Bootloader arbeiten möchtest, dann knüpf Dir gleich nen mega1284 drauf und nen 20 MHz-Quarz. BTW: wie willst Du Deinen Hexcode "in den Zielcontroller" bringen? Sprich: welcher Programmierer?

Mein archie läuft seit Jahren mit meiner ersten RNControl (in der unteren Röhre mit den Rechteckfenstern verbaut, drunter das LCD) - und bald seit den Anfängen mit dem größtmöglichen Controller. Klappt prächtig - auch wenn ich damit im Wesentlichen "nur" IR-Steuerungsbefehle und UART-Kommandos empfange und verwalte und den Satellitenboards ihre Aufgaben per I²C sende. Und natürlich elementare Meldungen auf ein 2x16-LCD schreibe.

.. Bin für jeden Tip dankbar ..

Anleitungen, evtl. mega16-Democode etc wird vermutlich noch im Internet verfügbar sein, im äussersten Notfall kann ich Dir das mailen.

Viel Erfolg noch - ist ja schon ein ziemlicher Projektumfang

[juergen009]

Hi Jürgen!
Hast Du noch die sonstigen Unterlagen? Schaltplan? Pinbelegung(en)? Die Beschreibungs-pdf (33 Seiten) ? Originalcode-hex und Fusestellung gesichert? Am besten die damals mitgelieferte CD ? In der Beschreibung steht z.B.

Ja die CD habe ich noch ist aber alles in Bascom

Hast Du die BAuteile auf strammen Sitz (und Korrosion ! !) geprüft? Lotbrüche? Läuft IRGENDEINE Textausgabe beim Start über UART? - vermutlich 38 oder 19 kBd ?

Das Board habe ich damals fertig aufgebaut gekauft, hatte aber beruflich bedingt nicht genug Zeit, um mich intensiv damit zu befassen. Soll ich mal den Chip rein und wieder rausmachen wg. Korrision?

AVRStudio 4.19 und C++ ? Geht das denn? Ich dachte mit C++ kann man erst mit späteren Versionen arbeiten? Ich programmiere (meine ersten cpp-Schritte) mit Studio 7, den Rest mit Studio 4.18, Build 700. Mal nur so - als ganz grobe Schätzung nach Deinem geplanten Projekt: wenn Du nicht unbedingt mit dem Bootloader arbeiten möchtest, dann knüpf Dir gleich nen mega1284 drauf und nen 20 MHz-Quarz. BTW: wie willst Du Deinen Hexcode "in den Zielcontroller" bringen? Sprich: welcher Programmierer?

Im Moment spiele ich mit dem NIBO2 von NICAI unter AVR-Studio 4.19. Dort sind schon einiger Routinen in C++ enthalten. Zur übertragung nutze ich den ISP Programmer über USB (STK500 kompatibel)

Mein archie läuft seit Jahren mit meiner ersten RNControl (in der unteren Röhre mit den Rechteckfenstern verbaut, drunter das LCD) - und bald seit den Anfängen mit dem größtmöglichen Controller. Klappt prächtig - auch wenn ich damit im Wesentlichen "nur" IR-Steuerungsbefehle und UART-Kommandos empfange und verwalte und den Satellitenboards ihre Aufgaben per I²C sende. Und natürlich elementare Meldungen auf ein 2x16-LCD schreibe.

Anleitungen, evtl. mega16-Democode etc wird vermutlich noch im Internet verfügbar sein, im äussersten Notfall kann ich Dir das mailen.

Viel Erfolg noch - ist ja schon ein ziemlicher Projektumfang

Ja, das Projekt ist heftig, vor allem macht mir die Stellgeschwindigkeit der Servos Kopfzerbrechen (Servo1 120° Servo2 60° als Beispiel) in der gleichen Zeit.

Ich möchte bei diesem Projekt auf Räder verzichten (Die Natur kennt auch keine Straßen) Der Robot soll sich auch in unwegsamem Gelände bewegen können.

[oberallgeier]

Ja, das Projekt ist heftig .. macht mir die Stellgeschwindigkeit der Servos Kopfzerbrechen (Servo1 120° Servo2 60° als Beispiel) in der gleichen Zeit ..

Es wäre blöd wenn ich nun sage: alles kein Problem. Aber diese simultane Ansteuerung der/von Servos hat mich etliche Zeit gekostet . Es läuft ja darauf hinaus, dass man die an sich typbedingte, maximale Servo-Stellgeschwindigkeit von rund 60°/0,15 sec zu einer langsameren und weichen Geschwindigkeit runterbremst. Alles kein Problem ! Das läuft dann bei mir (bei archie) bis zur simultanen Gestik (Video - leider grottenschlecht). Bei letzterer werden vom zentralen Controller = RNControl die einzelnen Steuersequenzen für Arm links, Arm rechts und Kopf zeitlich genau ausgegeben (mittlerweile "gute" Eigenbauplatinen); auch die Stimme (zeitlich genauer Einsatz einer bestimmten Teilsequenz) wird von der Zentrale per I²C an den Kopf geleitet - der steuert entsprechend die Audioelektronik an.

Wie hab ich die Servosynchronisation gemacht?
1) Bekanntlich werden die Servos nur max 10% der Ansteuerungsdauer mit einem genau bemessenen Stellsignal bedient. Ich habe also in der Ansteuerungspause Zeit die "andern" Servos zu bedienen. Ich hab im Archie viele Billigst-Mikroservo (aktuell insges 27 und vier "normalgrosse") verbaut aus der LxBxH 25 mm x 13 mm x 22 mm Baugröße.
2) Die Servos werden im Standardprotokoll betrieben siehe Link oben : alle ca. 20 ms einen Stellpuls.
3) Ich habe eine Servoroutine mit unterschiedlichen Befehlsmöglichkeiten. Der wichtigste Befehl lautet: fahre Servo i von A nach B mit x Inc/Servoperiode. A und B sind meine Pulsteilchen - rund 5000 pro Vollausschlag/>180° des Servos. Etwa 180 inc/Periode bedeutet dabei full speed und weniger als sechs bis acht inc/Periode ist das minimale Ende; ab 10 inc/Periode läufts wirklich bzw gut glatt. Also gibt die Servoroutine das entsprechende Signal aus und macht jeden einzelnen Puls um x inc länger. Der "Rest" zum genauen Ziel ist dann der letzte variable Puls. Danach neue Bewegung oder Stillstand <=> gleichbleibende Pulsdauer.

Ist das verständlich?

[juergen009]

Es wäre blöd wenn ich nun sage: alles kein Problem. Aber diese simultane Ansteuerung der/von Servos hat mich etliche Zeit gekostet . Es läuft ja darauf hinaus, dass man die an sich typbedingte, maximale Servo-Stellgeschwindigkeit von rund 60°/0,15 sec zu einer langsameren und weichen Geschwindigkeit runterbremst. Alles kein Problem ! Das läuft dann bei mir (bei archie) bis zur simultanen Gestik (Video - leider grottenschlecht). Bei letzterer werden vom zentralen Controller = RNControl die einzelnen Steuersequenzen für Arm links, Arm rechts und Kopf zeitlich genau ausgegeben (mittlerweile "gute" Eigenbauplatinen); auch die Stimme (zeitlich genauer Einsatz einer bestimmten Teilsequenz) wird von der Zentrale per I²C an den Kopf geleitet - der steuert entsprechend die Audioelektronik an.

Wie hab ich die Servosynchronisation gemacht?
1) Bekanntlich werden die Servos nur max 10% der Ansteuerungsdauer mit einem genau bemessenen Stellsignal bedient. Ich habe also in der Ansteuerungspause Zeit die "andern" Servos zu bedienen. Ich hab im Archie viele Billigst-Mikroservo (aktuell insges 27 und vier "normalgrosse") verbaut aus der LxBxH 25 mm x 13 mm x 22 mm Baugröße.
2) Die Servos werden im Standardprotokoll betrieben siehe Link oben : alle ca. 20 ms einen Stellpuls.
3) Ich habe eine Servoroutine mit unterschiedlichen Befehlsmöglichkeiten. Der wichtigste Befehl lautet: fahre Servo i von A nach B mit x Inc/Servoperiode. A und B sind meine Pulsteilchen - rund 5000 pro Vollausschlag/>180° des Servos. Etwa 180 inc/Periode bedeutet dabei full speed und weniger als sechs bis acht inc/Periode ist das minimale Ende; ab 10 inc/Periode läufts wirklich bzw gut glatt. Also gibt die Servoroutine das entsprechende Signal aus und macht jeden einzelnen Puls um x inc länger. Der "Rest" zum genauen Ziel ist dann der letzte variable Puls. Danach neue Bewegung oder Stillstand <=> gleichbleibende Pulsdauer.

Ist das verständlich?

Ja. verständlich wenn man es 3 Mal liest.

Das Problem ist, ich versuch mal es deutlich zu beschreiben:
Der Robot hat 6 Beine (Stabheuschrecke od ähnlich)
Jedes Bein hat 3 Servos
Servo 1 geht vor und zurück = x-Richtung
Servo 2 geht auf und ab = z-Richtung
Servo 3 geht nach innen oder aussen = y Richtung

Wenn jetzt Servo 1 von vorne nach hinten geht, wird der Körper nach vorne geschoben.
Dabei würde das Bein eine kreisförmige Bewegung machen, wenn nicht Servo 3 gleichzeitig
eine Bewegung nach innen machen würde. Diese Bewegung ist aber nicht linear sondern
abhängig von Pos. Servo 1. Wenn nun Servo 1 z.B 60° nach vorne gegangen ist, muss Servo 2
das Bein absenken. Servo 1 geht von z.B. 60°+ nach 0°, also Mittelstellung. In der gleichen Zeit
gleicht Servo 2 die Kreisbewegung durch Bewegung nach innen zu einer Geraden aus. Durch die Bewegung
von Servo 2 bekomme ich aber eine Höhenänderung, in diesem Fall nach oben; dies muss Servo 3 ausgleichen.
Auch hier ist die Bewegung nicht linear.

Mein erster Ansatz ist nun, dass immer 5 Beine am Boden sind. Das heisst, die Zeit vom Abheben eines Beines von 60°- zu Pos. 60°+
wäre dann 1/5 der Zeit der Rüchwärtsbewegung unter Last.

Weiterhin wäre noch unebenes Gelände zu berücksichtigen, damit ein Bein, das in Wirklichkeit keinen Bodenkontakt
hat, nicht sinnlos durch die Luft fährt. Hier sind dann wohl der Einsatz von Tasterm am Füß nötig.

Das ganze müsste man mal irgendwie grafisch darstellen, damit es wirklich verständlich wird.

Die Reihenfolge der Beine 1 - 4 - 2 - 5 - 3 - 6 od. so. Auf jeder Seite sollen immer 2 Beine am Boden sein.

Was sagst Du, ist das machbar?

Gruß

Jürgen

[oberallgeier]

Ja. verständlich wenn man es 3 Mal liest ..

Ohhh - pardon!

.. Der Robot hat 6 Beine (Stabheuschrecke od ähnlich) ..

Dass Du so etwas im Sinn hast, war mir ziemlich klar als Du von 18 Servos geschrieben hattest. Das ist die übliche Servoanzahl für Hexapoden. Sechsfüßler hatten mich mal interessiert - aber ich kam nie dazu mich damit zu beschäftigen, kann Dir hier also nicht weiterhelfen. Das ist eine total andere Welt als meine Projekte. Es gibt zu dieser Stichwortwolke Hexa, Hexapod, Hexapode, IK, Inverse Kinematik usf ne Menge Informationen auch hier im Forum. Die Suche von eben nach [hexapod kinematik] hier im Forum wirft mir gleich zwanzig Funde raus.

.. Mein erster Ansatz ist nun, dass immer 5 Beine am Boden sind ..

Grad eben habe ich auf die Schnelle zwei Ausarbeitungen gefunden die sich mit dieser Sache beschäftigen, ein umfangreiches PDF-Dokument und eine ausführliche Webseite. Eine eigene Suche wird da förderlich sein. Ausserdem wird ein anderer Thread mit einem entsprechend passenden Titel die dann richtigen Leute ansprechen.

[Tomy83]

Hallo Juergen009

Wenn jetzt Servo 1 von vorne nach hinten geht, wird der Körper nach vorne geschoben.
Dabei würde das Bein eine kreisförmige Bewegung machen, wenn nicht Servo 3 gleichzeitig
eine Bewegung nach innen machen würde. Diese Bewegung ist aber nicht linear sondern
abhängig von Pos. Servo 1. Wenn nun Servo 1 z.B 60° nach vorne gegangen ist, muss Servo 2
das Bein absenken. Servo 1 geht von z.B. 60°+ nach 0°, also Mittelstellung. In der gleichen Zeit
gleicht Servo 2 die Kreisbewegung durch Bewegung nach innen zu einer Geraden aus. Durch die Bewegung
von Servo 2 bekomme ich aber eine Höhenänderung, in diesem Fall nach oben; dies muss Servo 3 ausgleichen.
Auch hier ist die Bewegung nicht linear.
Jürgen

Wenn man die ganze Bewegeung des Beins "von Vorn nach Hinten" in ganz viele Teilschritte aufteielt, dann erübrigt sich das Thema Servogeschwindigkeit fast von selbst. So wie oberallgeier es unter Punkt 3 erklärt hat. Nur das man nicht seine Endgültige Position anfährt, sondern nur den nächsten kleinen Schritt. Ich hab das so gelöst das ich pro Schleifendurchlauf des µC nur einen ganz kleinen Schritt mache. Somit berechne ich pro Schleifendurchlauf alle 3 Servopositionen neu. Das ist dann stark Laufzeitabhänig. Lässt sich aber durch messung der Laufzeit (Timer) ermitteln und mit der Zielposition verrechen. Zu beachten ist noch das dann das Programm nicht schneller die Servoposition wechselt (errechnet) als der Servo schnell ist.

Der Gangmodus 5-1 ist wirklich sehr sehr langsam, besser ist der 4-2 Modus oder 3-3. Bitte beachte das die maximale Servogeschwindigkeit immer im Rückhub (Bein nicht auf dem Boden/ohne Last zurück zur Ausgangsposition) zur verfügung stehen muss, also ist im Vorhub (Bein Trägt die Roboterlast) die Geschwindigekeit des Beins langsamer. Es ist auch zu empfehlen das das Bein erst ein Stück mit der Roboterbewegeung mitschwingt bevor es auf dem Boden aufsetzt. Gleiches gilt für den Ende des Schritts. Sonst bremst das Bein den Roboter ersteinmal ab, da es noch entgegen der Laufrichtung des Roboters schwingt, das Getriebespiel und die Masseträgheit werden hier sichtbar.