Projekt "AHLTONE"

Hallo,

Heute will ich mein Roboter "AHLTONE" vorstellen. Ich arbeite daran bereits fast 2 Jahre und bin auch noch lange nicht fertig. Zum einen kommt die Zeit dadurch zustande da ich das ganze bereits 3 mal wieder umgebaut habe und ich auch nur bei schlechtem Wetter etwas daran basteln kann. Viel Zeit hab ich auch in die Planung investiert.
Kurz zu mir, ich heiße Hendrik, bin 39 und komme aus Chemnitz(Sachsen). Das Hobby ATMEL AVR betreibe ich nun schon 4 Jahre. Angefangen mit dem EvolationsBoard2.0 bis hin zum RP6 mit dem ich schon einiges an Erfahrung sammeln konnte.

Ich hab Anfang lezten Jahres über einen Kumpel , mehr durch Zufall, ein HengLong "Tiger1" zum Sonderposten bekommen. Sonderposten heißt, es handelt sich nur um die Unterwanne mit RC Modul und Rauchgenerator.
Über solch Panzer als Roboter zu nutzen hab ich im Forfeld schon hier im Forum gelesen das es nicht so einfach ist, was ich mitlerweile auch bestätigen kann.
Hier mal ein Bild, schon mit Querstreben und "alter" Heckklappe.
Anhang 32919
Ich hab eigentlich bis auf die Stehbolzen fürs Getriebe alles entfernt, die Batterieklappe eingeleimt, verspachtelt und Unebenheiten verschliffen.
Anhang 32920
Hier meine "alte" Heckklappe. Vorgesehen waren 2 Schalter für beide Akkus, Akkuanzeige mit je 5 LEDs für beide Akkus, Lade- und Balancebuchsen und 2 ISP-Buchsen sowie die beiden 9 pol Buchsen für UART und LogicAnalyzer.
Mitlerweile hab ich diese neu gebaut und besteht nur noch aus Schalter, Akkuanzeige und Ladebuchse.
Anhang 32921

Ansonten habe ich von meschanischer Seite her das Antriebs und Leitrad von Plase in Metall gewechselt und am Heck einen Kettenspanner eingebaut. Auch habe ich den Antriebsachsen Kugellager gegönnt. Somit laufen die Ketten erstmal optimal und gleichmäßig.

In den nächsten Tagen stelle ich weitere Bilder hierein.

Bis die Tage Hendrik

Ui, ich bin schon gespannt wie du das Problem löst wo man am besten Radencoder anbringt. Also als Roboter nutzen kann man die Platform finde ich trotzdem prima, davon abgesehen, dass mein Modell davon sich ständig die Ketten abgezogen hat, sobald man nicht mehr auf reibungsarmem Unterboden gefahren ist. Man macht sich das Leben aber wesentlich einfacher wenn man Radencoder oder irgendeine Art von Odometrie hat um herauszufinden wie weit vorwärts man gefahren ist. Die Orientierung kann man prima mit einem Magnetkompass ausregeln.

Das mit den raddecodern liegt mir auch noch schwer im Magen, so richtig Platz finde ich nicht. Ich hatte mal hier gelesen das einer die decoder vom rp6 verwendet, aber das wie und wo nicht. Das Getriebe ist ja auch nicht gerade spielfrei.

Das sinnvollste ist am Ausgang zum Rad. Wie man die dort allerdings reinbekommen soll ohne das Getriebe komplett umzubauen...keine Ahnung. Hatte bei mir eine USB Maus umfunktioniert um auf dem Boden die XY Bewegung zu messen. Funktioniert natürlich auch nur auf ebenem Boden. (Die Maus ist mal an einer Türkante hängengeblieben..und seit dem ist sie nicht mehr dran ^^ )

Am Rad hatte ich auch schon die Idee, aber das Problem sind die antriebsräder. Auch wenn ich welche aus Stahl habe, sie eiern und da denke ich fehlt ab und zu dann der Kontakt zur codescheibe.
Und selbst wenn es funktionieren würde, wäre mir die Auflösung zu gering pro Radumdrehung. Zum Vergleich beim rp6 sind es so ca 600 Flanken pro Radumdrehung .

Man kann so einen optischen Maussensor nicht nur über den Boden schleppen. Er sollte seinen Dienst grundsätzlich auch an einer rotierenden Scheibe, auf der Mantelfläche eines Zylinders oder sogar auf der Stirnverzahnung der großen Zahnräder tun, die auf dem ersten Bild zu sehen sind. Die Anforderungen an die Oberflächenstrukturierung sind bekanntermaßen sehr niedrig.

Ich hab da so an die Richtung hallsensor gedacht am ersten großen Zahnrad, aber wie gesagt , soweit bin ich noch nicht. Will erstmal soweit kommen das es fährt. Sensoren kommen dann nach und nach.

Nimmst du die schon verbauten Motoren oder hast du vor da was umzubauen ? Die verbauten Motoren sollen recht hohe Spitzenströme ziehen (Hab ich nie nachgemessen). Aber mit 2 L298 (H Brücken parallel geschaltet) kommt man schon an die Grenze der L298.

Vorerst verwende ich das was da ist. Ich hab das Monster Moto Shield mit Dual VNH2SP30 Treiber für Gleichstrom- & Schrittmotoren bis 30A 16V und das ist mit einer 4A Sicherung abgesichert. Wird sich zeigen ob die später in der Praxis ausreicht oder nicht.
Vorgesehen war erst je ein fahrtregler aus dem modellbau, einfache von Conrad gewesen, haben allerdings nur 2A Dauerstrom und 3A Spitze. Denke auf kurz oder lang hätte ich die gegrillt.

Ja so ein VNH2SP30 sollte locker reichen. Ich verwende so einen im Moment um einen Motor der um Größenordnungen größer ist anzutreiben. Die Erfahrung die ich mit den fertigen Shields allerdings gemacht habe ist, dass die meisten sich nicht an das empfohlene Layout von ST halten, weshalb die Treiber recht warm werden können.

Ein Tiger.
Ich hab einen als RC-Modell.
War ne Menge Arbeit, aber den hält (fast) nix mehr auf inzwischen. Der kommt sogar durch Schnee durch....wenn du Tipps für das Fahrwerk brauchst, sag es. Ist Arbeit, aber machbar.

Thema Encoder (meiner ist ein reines RC-Modell, der braucht keine): warum nicht einfach eins der Getrieberäder durchbohren, und ne Lichtschranke drum? Funktioniert bei diversen Robotern einwandfrei.
Wahrscheinlich ist das kein Stahl, sondern einfacher Zinkguss....bohren also kein Problem.
Die Zahnräder werden niemals überspringen, so kann man also ganz gut rechnen.
Auch die Kette kann, auf den Rädern, nicht durchrutschen.

Moin, das mit der Lichtschranke ist garkeine so schlechte Idee, werd ich sicherlich im Hinterkopf behalten.
So ähnlich hatte ich schon mal den Gedanken, allerdings wollte ich eine extra Scheibe anbringen. Auch hatte ich kurzzeitig mit den Reflexkoppler CNY70 mich versucht, dafür hatte ich mir eine Scheibe gedreht. Plan war noch flächen zu fräsen und entsprächend einfärben. Anhang 32922

Guck dir mal an, wie das bei NiboBee (der hat Löcher in den Getrieberädern) und Asuro (der hat keine, da sind einfach schwarz/weisse-Markierungen aufgemalt) gelöst ist.
Asuro hab ich keinen, aber beim Nibobee funktioniert das super. Schaltplan ist, soweit ich weiss, frei verfügbar.
Zwar kann man damit die Drehrichtung nicht rausfinden, aber im allgemeinen weiss man ja auch, wie rum man den Motor ansteuert.
Wenn du z.B. das erste Zahnrad nach dem Motor nimmst, dürfte da ne sehr feine Auflösung herauskommen. Das wird dann genauer als sinnvoll, denn milimetergenau lässt sich ein solches Fahrwerk sowieso nicht platzieren.

Heute Gabellichtschranken wieder rausgekraben. Das Erste Zahnrad hab ich auch mal gemessen, ist natürlich 5mm breit. Eine GL hab ich noch da gehabt mit 5mm Abstand, aber ist mir etwas zu eng das ganze. Und das Zahnrad will ich nicht abdrehen.
Ich hab jetzt eine TCST 2103 geteilt und schau mal wie ich das am Getriebe befestigen kann. Laut Verkäufer sollte das funktionieren.

Spontan würde ich sagen das in dem Kettenrad noch Platz für einen kleinen Neodymmangnet ist, sieht jedenfalls auf den Rädern so aus und in der wanne ist genug Platz für einen Hallsensor.

Guten Abend,

ja in den Antriebsrädern wäre Platz für Magnet und Hallsensor, aber wie schon gesagt ist mir das zu geringe Auflösung. Das Antriebsrad hat 55mm Durchmesser, sind ca. 69mm Umfang.

Ich hab heute das Regenwetter genutzt und mich an die Gabellichtschranke gemacht:
Anhang 32926 Anhang 32927

Bevor ich jetzt anfang mit Zahnrad bohren hab ich erstmal zum Taschenrechner gegriffen. Ich geh davon aus das die Motoren als Standard verbaut sind ( stehen keine Werte drauf ). Laut Online Shop haben diese 8500 U/min.
Der Motor muss sich 4,5mal drehen um das erste Zahnrad 1mal zu drehen. Das erste Zahnrad muss sich 9mal drehen um das das Antriebsrad sich einmal dreht.
also

8500 U/min /60s == 141 U/s /4,5 == 31 U/s /9 == 3,5 U/s == 601,6mm/s maximale Geschwindigkeit bei max Umdrehung des Motors

Aber zurück zum ersten Zahnrad,
bei 4 Bohrungen sind es bei 31 U/s ca 124 Flanken /s


MFG Hendrik

Hallo zusammen,

mein Gabellichtschranke ist fertig. Bohren war doch nicht ganz so einfach wie gedacht, aber habe es recht gut hinbekommen.
Anhang 32934
Am Oszilloskop sieht das ganze sehr gut aus.
Anhang 32935
Der Motor hat zu diesem Zeitpunkt ca 5Volt.
In den nächsten Tagen bau ich mal alles wieder zusammen und versuche etwas Leben in den Tiger zu hauchen.

Zitat:

---

.. Roboter "AHLTONE" .. fast 2 Jahre und bin auch noch lange nicht fertig .. nur bei schlechtem Wetter .. Viel Zeit hab ich auch in die Planung ..

---

Das geht sicher den meisten so - bei mir (aber kein Tank) gehts jedenfalls genau gleich: mal diese Baugruppe, mal jene. Die aktuelle Hand mit bewegten Fingern ist schon die Version 6 *gg*.

Zitat:

---

.. da denke ich fehlt ab und zu dann der Kontakt zur codescheibe .. rp6 sind es so ca 600 Flanken pro Radumdrehung .

---

Bei meinem WALL-R habe ich je sechs weiße und schwarze Segmente am Hinterrad. Das reicht - eher grob, aber immerhin (siehe Video) kann das Vehikel recht dynamisch und einigermassen genau fahren. Schnell bei Gib-Gummi-Status und stufig langsamer wenns eng wird.

Zitat:

---

Zitat von Jackeder

Ich hab da so an die Richtung hallsensor gedacht am ersten großen Zahnrad, aber wie gesagt , soweit bin ich noch nicht. Will erstmal soweit kommen das es fährt. Sensoren kommen dann nach und nach.

---

IN DAS Getriebe eines Mikromotors (dieser) hatte ich mal ne Encoderscheibe mit vier Schlitzen zum Abfragen genommen. Geht einwandfrei - aber SEHR feinmechanisch (hier ein Blick ins Getriebe) und bei nur einer Gabellichtschranke auch nur die Drehzahl ohne Drehrichtung. Aber Deine gegenwärtige Lösung ist ja schon s..gut!

Insgesamt ne hübsche Arbeit (nach Problem und bisherigen Lösungen), bravo.

Frage: mein archie läuft (noch) auf Rädern, sollte aber ein Kettenfahrwerk bekommen. 2 Ketten, je ca. 9 cm breit, ca 80+ cm lang. Ich fürchte, dass damit dann der größte Teil der Antriebsleistung flöten geht. Stimmt das? Die verbraten doch die meiste Energie mit Lärm und Reibung ! ? ! ?

Zu den Ketten kann ich dir erstmal noch garnicht viel sagen, da bis Juni2017 noch garnix lief und ab Juli2017 der momentane Umbau stattfand. Die Tests oben mit dem Enconder hab ich bei ausgebautem Getriebe gemacht, hatte bei 4,5V ca. 350mA. Mit Ketten ists etwas mehr, je nachdem wie straff ich die Kette spanne. Ohne den Kettenspanner ist das ganze nur Quälerei, da das Antriebsrad und Leitrad wie gesagt nicht rund läuft. Was den Lärm angeht, da das Getriebe schon recht laut ist hört man die Ketten wenigstens nicht mehr ^^. Was mir noch zu bedenken gibt ist die Haftung der Ketten. Gerade auf PVC oder Parlett denke ich werden die Plasteketten hier und da Propleme haben. Gibt zwar auch Metallketten aber befürchte das ich dann Propleme bekomme wenn ich über den Boden damit kratze. Kumpel meinte ja das sogar auf Tepichböden der Tiger ins driften gerät je nach dem wie die Faser gewebt ist.
Dein Archie gefällt mir, erinnert mich an Nr.5.
Den Drehgeberencoder war eigentlich momentan noch garnicht geplant,hatte das nur irgendwo im Hinterkopf, "das brauchst du auch noch". Dann kam der Tip mit der Gabellichtschranke und dem NioBee von Rabenauge und los gings. Ehrlich gesagt, hab ich garnicht gedacht das das so gut werden würde.
Jetzt steht aber die Frage dazu , brauche ich eigentlich wirklich zwei, also für jedes Getriebe ein Encoder. Das der Tiger geradeaus fährt wollte ich eigentlich über Kompass(CMPS11) regeln und über den Encoder nur Drehzahl und Weg messen. Alledings hab ich auch schon gehört das das Kompassmodul sehr störempfindlich ist.

ja, hat den kompass nach möglichkeit mindestens 20cm von der elektronik weg.

Zitat:

---

Zitat von Jackeder

[...] Das der Tiger geradeaus fährt wollte ich eigentlich über Kompass(CMPS11) regeln und über den Encoder nur Drehzahl und Weg messen. Allerdings hab ich auch schon gehört das das Kompassmodul sehr störempfindlich ist.

---

Warum nimmst du nicht ein Gyroskop? Wie zB.: 6-achsen-bewegungssensor-modul-6d-bs Neben den Beschleunigungssensor ist dort auch ein Gyro verbaut. Dieser Gyro schaft bis zu 2000deg/s. Den Beschleunigungssensor könnte man her nehmen, um ein Drift bzw. Durchdrehen der Kette auf dem Boden festzustellen.

Zitat:

---

Zitat von Jackeder

Dass der Tiger geradeaus fährt wollte ich eigentlich über Kompass(CMPS11) regeln und über den Encoder nur Drehzahl und Weg messen. Allerdings hab ich auch schon gehört das das Kompassmodul sehr störempfindlich ist.

---

Zitat:

---

Zitat von morob

ja, hat den kompass nach möglichkeit mindestens 20cm von der elektronik weg.

---

... und, was den CMPS11 angeht, mindestens 1m (!) von allen (elektro-) magnetischen Teilen weg, wie z.B. Radachsen und Motoren, und externe magnetische Störfelder von Gegenständen, in deren Nähe man sich befindet oder an denen man sich vorbei bewegt, dürfen auch keine vorhanden sein.

Zitat:

---

Zitat von Jimmybot

Warum nimmst du nicht ein Gyroskop? Wie zB.: 6-achsen-bewegungssensor-modul-6d-bs Neben den Beschleunigungssensor ist dort auch ein Gyro verbaut. Dieser Gyro schaft bis zu 2000deg/s. Den Beschleunigungssensor könnte man her nehmen, um ein Drift bzw. Durchdrehen der Kette auf dem Boden festzustellen.

---

Reine Gyros sind auch keine Lösung (LMS330, wie im ELV Modul 6d-bs verbaut), da Gyros keine absolute Orientierung zum Initialisieren besitzen und grundsätzlich einen Driftfehler haben (der müsste wiederum durch einen zusätzlichen Kompass kompensiert werden, womit sich die Katze in den Schwanz beißt, d.h. reiner Gyro geht nicht, und man bräuchte doch einen 9D IMU (3D Kompass+ 3D Gyro+ 3D Accel.) und extrem gute stochastische und statistische Kompensationsalgorithmen, s.u.).
@Jimmybot: ich wette, das ist graue Theorie und du hast es mit Sicherheit noch nie selber ausprobiert: völlig illusorisch!
Accelerometer sind viel zu verrauscht, um daraus Bewegungs- und Ortungsdaten zu gewinnen, geschweige denn, um damit Schlupf der Antriebsketten herauszurechnen.

@Jackeder: Eine Idee wäre höchstens der Tinkerforge IMU Brick 2, z.B. in Verbindung mit einem Raspberry Pi, doch der erfordert einen ziemlichen Implementierungsaufwand (ich habe ihn aufgegeben, aber vielleicht hast du ja entsprechende fortgeschrittene Linux-, C++ und Python Kenntnisse).

Unterm Strich halte ich Kettenfahrzeuge für absolut ungeeignet bezüglich Navigation per Odometrie und IMUs, einzig externe Ortungssysteme mit Satelliten- oder Bakenpeilung (wie GPS oder z.B. pozyx) halte ich z.Zt. für aussichtsreich.

Ich kann diesbezüglich den BNO055 empfehlen. Der ist ziemlich unempfindlich was externe Störungen anbelangt.

Zitat:

---

Zitat von shedepe

Ich kann diesbezüglich den BNO055 empfehlen. Der ist ziemlich unempfindlich was externe Störungen anbelangt.

---

hast du es mal ausprobiert und einen Stab- oder Elektromagneten daneben gelegt und/oder vorbei bewegt?
Ich wäre sehr überrascht, wenn er daraufhin keine Veränderung zu Kompass-Nord zeigen würde.

Wenn du den Magneten statisch daneben legst, kann man das tatsächlich in begrenztem Maßstab durch die Sensorgeometrie kompensieren.

Und natürlich, Jeden Magnetkompasss kann man durch ein außreichend starkes externes Magnetfeld stören. Durch geschicktes wählen der Sensorposition und Sensorfusion (was der BNO intern macht zum Glück) kann man aber einiges ausgleichen.

Nur zum Vergleich. Wir fahren mit so einem Sensor in einer Laborhalle wo auch Starkstromversuche für Antriebstechnik gemacht werden. Klappt trotzdem.

Zitat:

---

Zitat von shedepe

Wenn du den Magneten statisch daneben legst, kann man das tatsächlich in begrenztem Maßstab durch die Sensorgeometrie kompensieren.

Und natürlich, Jeden Magnetkompasss kann man durch ein außreichend starkes externes Magnetfeld stören. Durch geschicktes wählen der Sensorposition und Sensorfusion (was der BNO intern macht zum Glück) kann man aber einiges ausgleichen.

Nur zum Vergleich. Wir fahren mit so einem Sensor in einer Laborhalle wo auch Starkstromversuche für Antriebstechnik gemacht werden. Klappt trotzdem.

---

nein, ich meinte erst z.B. auf Nord ausrichten und dann einen Magneten temporär danebenlegen und irgendwann wieder wegnehmen oder öfters zufällig vorbei bewegen. Außerdem hast du sicherlich eine funktionierende Odometrie, nehme ich an?
Außerdem machen Starkstromleitungen wenig, denn die produzieren ja nur magnetische 60 Hz Wechselfelder, kreisförmig um die Leiter herum, aber keine gerichteten Magnetfelder wie magnetisierte Metallachsen, Metallleisten, oder Elektromagnete.

der Tinkerforge IMU Brick 2 kann ja laut Firmeninfos alle Magnetstörungen über die Sensorfusion kompensieren, das hatte ich ja angesprochen, dennoch bezweifle ich, dass das jemand mit eigenen Mitteln nachmachen könnte, und außerdem kann selbst dies mMn nicht eine aus dem Ruder laufende Odometrie bei durchrutschenden Kettenantrieben kompensieren.

- - - Aktualisiert - - -

ps,
der CMPS11 (9D IMU) hat ja ebenfalls eine interne Sensorfusion, dennoch ändert sich der berechnete (Kompass-) Kurs bei Fremdmagneteinfluss um bis zu 180°, aber schon 5° wären dauerhaft zuviel:
10 Min. Fahrt bei 10m/min und 5° Fehlweisung = knapp 8m Navigationsfehler!
Und das betrifft nur den Kursfehler - der Fehler durch Odometrie bei Kettenschlupf kommt noch oben drauf!

Guten Morgen,

erstmal danke für die vielen Antworten und Anregungen.

Zitat:

---

Zitat von morob

ja, hat den kompass nach möglichkeit mindestens 20cm von der elektronik weg.

---

Da erübrigt sich schon mal meine Frage ob der Standort günstig ist.
Anhang 32938
Ich wollt halt alles so bauen das nichts rausschaut bzw kompackt ist, da meine Tochter mit ihren 2 Jahren schon sich sehr dafür interesiert, Taster sind ja zum tasten da usw.

Zitat:

---

vielleicht hast du ja entsprechende fortgeschrittene Linux-, C++ und Python Kenntnisse

---

sorry, bin denke ich noch ganz am Anfang mit meinen C++ Kenntnissen

wie gesagt: und den CMPS11 mindestens 1m von den Motoren und Eisenteilen etc. entfernt.
Ich habe selber so ein Gefährt, und ich kann dir sagen: es klappt sonst nicht damit.
Und auch sonst mit Kettenantrieben zur Odometrie: keine Chance, spätestens nach der 1. Kurve.

Einzige halbwegs aussichtsreiche Möglichkeit wäre der Tinkerforge IMU 2, den kannst du u.U. auch in der Nähe von Magnetteilen verbauen, wenn er korrekt initialisiert worden ist (s. Videos).

So schnell noch paar aktuelle Bilder.

Anhang 32939 Anhang 32940
Ganz unten die beiden Akkus und die Versorgungsplatine mit dem ATmega8 der die Spannung über die Balancer überwacht und als Zusatz die Temperatur des LF50.


Anhang 32941 Anhang 32942
Darüber dann die Hauptplatine von Pollin ein ATmega128A, das MotorShild und in der Mitte die ISP Steckplatzbrücke mit Reset Taster für beide ATMEGAs, da ich sonst nicht anders ran komme.
Obendrauf auf dem Messingrahmen das LCD und 7 Tasten für einstellungen usw.

Guten Abend,

erstmal noch was zum CMPS11. Ich hab das Modul so wie oben gezeigt eingebaut und mit ATmega8 ausgelesen. Bei laufenden Motoren sinds ca. 20° Schwankungen. Ist natürlich zu viel um halwegs genau geradeaus zu fahren, bzw. überhaupt in eine Richtung zu steuern. Ich kann maximal im Stillstand die Richtung zumindest ermitteln. Zumindest sind Roll und Pitchwerte verwendbar wehrend der Fahrt.

Gestern Abend und heute Mittag hab ich Zeit gefunden die Drehgebersensoren umzubauen. Ich hatte ja schon mal für eine Seite was gebastelt, aber das hat nur bedingt gehalten.
Anhang 33000 Anhang 33001 Anhang 33002
Durch die Trägerbrücke hab ich auch gleich ein wenig Stabilität gewonnen. Jetzt muss ich erstmal für alles Programme schreiben und dann alles in eines packen.

- - - Aktualisiert - - -

@ shedepe
du schriebst ja das du ebenfals so ein MotorShild verwendest.

Hast du schon mal versucht den Motorstrom damit zu messen ? Ich hab im Netz gelesen das beim VNH2SP30 die Stromsensor- (CS) -Pins etwa 0,13 Volt pro Ampere des Ausgangsstroms ausgeben.
Ich wollte das mit einem LM358 um das 5fache versterken und dann am ATmega128A über ADC messen. Sollte ja so gehen, oder ?

Zum Thema Ketten einiges. Hab ich mit dem Tiger auch durch...
-Metallketten haben generell den schlechteren Grip.
Ist einfach so....die Kunstoffketten greifen besser. Damit fährt der Tiger auch 100% Steigungen rauf (natürlich nicht auf ner Glasplatte, aber im Freien problemlos), davon können die Metallketten-Fahrer nur träumen.
Einziger "Vorteil" von Metallketten: die reissen nicht. Da zerlegen sich dann die Getriebe...:)
Ja ok-durch das enorme Gewicht der Dinger kann man sie etwas lockerer hängen lassen, das sieht "echter" aus-bringt aber ansonsten keine Vorteile.
Kunstoffketten gibt es verschiedene (leider kaum vor dem Kauf rauszufinden, welche man bekommt), es gibt stabilere und anfälligere.
Optisch nahezu gleich-man erkennt es höchstens wenn man sie nebeneinander hält. Hab auch schon vom selben Händler verschiedene bekommen....von daher kann man eigentlich nur auf Glück hoffen.
Irgendwo hatte ich mal welche gesehen, wo die Glieder durchgehend geschlossen waren-die dürften noch mehr aushalten...weiss aber nicht mehr, wo das war (ich hab die auch nicht, die normalen reichen).

Eiernde Antriebsräder?
Kriegt man weg:
Der Tiger hat aussen auf der Wanne Atrappen für die originalen Vorgelege. Da rein ein stabiles Kugellager (weiss das nicht mehr ausm Kopf, müsste 8 innen gewesen sein), das kann man z.B. mit Powerknete in diesen Vorgelege-Atrappen "einschweissen".
Entlastet nebenbei das Getriebe enorm, da sämtliche von aussen kommenden Kräfte von dem starken Lager problemlos geschluckt werden.
Und die Antriebswelle hat ausgeeiert. Die tut das nämlich, weil in den Getrieben alles chinesische Wurfpassungen sind (Lagerbüchsen wackeln in den Platinen, Wellen wackeln in den Büchsen....](*,) ).
Ggf. kann man noch im Zubehört erhältliche Metall-Antriebsräder verbauen, die sind auch nicht präziser, aber stabiler (mir persönlich ist es lieber, die Kette reisst mal als dass sich was anderes zerlegt, so ne Ersatzkette kostet nen Fünfer, und man hat laaaange genug Ersatzglider, gewechselt sind die in ner halben Minute).

Leitrad eiert?
Die gibts auch aus Metall. Zusammen mit nem vernünftigen Kettenspanner (keinen benutzen, der die Kette per Feder vorbelastet, das gibt Verschleiss und funktioniert spätestens im Gelände eh nicht mehr) funktioniert auch das dann einwandfrei.
Ich benutze diese Dinger: https://tank-modellbau.de/7/Tiger-I-...-Kettenspanner
Neue Kette auflegen, ne Weile laufen lassen (die längen sich erstmal so bissel), dann leicht spannen (nicht wirklich straff-einfach bisschen probieren, leicht durchhängen muss die Kette noch), fertig.
Alle "paar km" mal nachspannen, wenn man die "besseren" Ketten erwischt hat, ist das sehr selten nötig.
Bei dem oben verlinkten Laden gibts übrigens auch ne fertige Lösung für die Achsabstützung...

Um die Laufrollen bisschen präziser laufen zu lassen, hab ich in meiner Wanne innen Alu-Schienen verbaut (gibts auch im Zubehör, passen aber nicht bei jeder Ausführung). Dadurch verwindet sich der ganze Kram nicht mehr so- und dann auch metallene Schwinghebel. Die sind wesentlich steifer als der Plastikkram.
Metallene Laufrollen bringen nix-ausser ner Menge unnötigem Gewicht. Präziser sind die auch nicht, und ich hab das Gefühl, zuviel Präzision mag das Fahrwerk auch wieder nicht...allerdings sind die Kunstoffdinger _manchmal_ schlampig montiert. Das sollte man schon beheben (die kosten auch als Ersatzteile fast nix, so dass man sich nen Satz hinlegen kann und dann einfach die besten zusammensucht).
Für eine reine Laborratte (kein Ausseneinsatz, und Gelände nich mehr als Türschwellen) sollte man eigentlich auch ohne Metallräder auskommen, lediglich das Leitrad wird irgendwann ausleiern.

Danke für deine umfangreichen Tips.

Einiges hab ich schon bereits in Panzerforen gelesen.
Wie gesagt Leit und Antriebsräder hab ich aus Metall, aber ist halt Druckguss. Laufen halt nicht ganz rund, okey nicht ganz so schlimm wie die aus Plaste. Beim Leitrad aus Plaste ist mir auch immer die Kette abgesprungenund hat sich in der Bodenwanne verklemmt. Sieht man auf dem Foto gut.
Anhang 33018

Kugellager hab ich bei Conrad passende gefunden 4mm breit 8mm Innendurchmesser Außendurchmesser hab ich nicht im Kopf jetzt, aber haben kaum Spiel.
Sieht vieleicht nur so aus aber man könnte meinen das hier für ein Kugellager vorgesehen ist.
Anhang 33019

Kettenspanner hab ich den von HennTec, etwas teurer wie deiner, aber erfüllt sicher den gleichen Zweck. Ketten laufen und die Motoren brauchen weniger Kraft.
https://heng-long-panzer.de/de/ZUBEH...anne-1-16.html

Die Schwingarme kommen auch irgendwann an die Reihe, da schon einige Schrauben für die Laufrollen durchdrehen in den Plasteteilen.

Einen hab ich noch: Unterlegscheiben. Sieh zu, dass du mit diesen Scheiben alle Räder so ausrichtest, dass die ganze Mimik einwandfrei läuft.
Aber mach vor allem die ganzen Laufrollen nicht völlig spielfrei.
Die Ketten, die du da drauf hast, sehen wie die etwas stabileren aus, wenn die dir nicht dauernd zerfliegen (die schwächeren tun das auch schonmal scheinbar grundlos), lass die drauf.
Ja stimmt-da ums Antriebsrad sieht es aus als wäre ursprünglich ein Lager vorgesehn gewesen (und, unter uns gesagt, ist es ohne einfach erbärmlicher Pfusch, da letzten Endes die ganze Kraft erst vom Getriebe, und dann von den paar kläglichen Schräubchen, die es in der Wanne halten, geschluckt werden soll).
Ich glaube, ich hatte da Lager für Inline-Skater verbaut, die sind so richtig kräftig. Anständige gekapselte, ist das ne Endlösung.

Tiger ist halt, aufgrund der breiten Ketten, und dieses Schachtellaufwerks, eine ziemliche Herausforderung.
Nen Roboter würde _ich_ damit nicht bauen, das Fahrwerk vom Walker Bulldog ist entschieden geeigneter.
Die laufen alle schon aus der Schachtel raus einwandfrei und auch dauerhaft.
Da muss ich mir auch irgendwann mal einen besorgen.

Was die Schwingarme angeht: so lange dein Roboter eher drinnen bleiben soll, kannst du wahrscheinlich auch jeden zweiten kurzerhand weglassen- weniger Rollen-weniger Probleme.
Wär nen Versuch wert...und schwerer als ein Modell-Tiger wird er als Roboter wohl auch nicht, eher leichter (meiner ist, nach diversen Umbauten, innen rappelvoll). Ich glaube, auch die Federn kann man verschieden vorspannen (weiss ich aber nicht mehr genau, und zerlegen möcht ich meinen jetzt nicht, da brauch ich ne Stunde für, weil ich ewig nicht mehr dran rum geschraubt hab).

Guten Abend zusammen,

mechanisch will ich im Moment nicht groß erstmal verändern, lieber erstmal alles zum laufen bringen. Aber da kommen auch immer wieder Propleme.
Im moment will ich ja die Lichtschranken am ATmega128A auslesen, aber da taucht ein kleines Proplem auf. Der ATmega128A kann entweder steigende oder fallende Flanken erkennen, nicht aber beide zusammen.
Ich könnte jetzt
nur die Steigenden Flanken zählen, was aber pro Seite immer nur 6 sind
oder
mein "Co prozessor" ATmega8, der für die Akkuüberwachung zuständig ist, hat noch 2 Pins frei und könnte somit die Encoder übernehmen und die Werte alle 200ms über UART an den 128A senden
oder
ich nehm mir einen zusätzlichen MC der die Encoder ausliest und bei jeder steigenden und fallenden Flanke einen weiteren Pin für paar ms high schaltet welche dann der ATmega128A ausliest.

@ Rabenauge
kannst du etwas über das 4:1 Getriebe sagen ? hier mal der Link dazu
https://heng-long-panzer.de/de/ZUBEH...NZER-1106.html
hab die Idee das gegen das 3:1 zu tauschen und aber auch langsamere Motoren, weil die im 4:1 verbauten Motoren sind mit 18000 U/min mir doch zu schnell.
Selbst das 3:1 Getriebe ist mir schon zu schnell und im oberen Drehzahlbereich auch zu laut :)
Das 5in1 Getriebe hab ich mir auch schon angesehen, soll aber nicht so der Hit sein was ich darüber gelesen habe.

grüße Hendrik

Zitat:

---

Zitat von Jackeder

Guten Abend zusammen,

mechanisch will ich im Moment nicht groß erstmal verändern, lieber erstmal alles zum laufen bringen. Aber da kommen auch immer wieder Propleme.
Im moment will ich ja die Lichtschranken am ATmega128A auslesen, aber da taucht ein kleines Proplem auf. Der ATmega128A kann entweder steigende oder fallende Flanken erkennen, nicht aber beide zusammen.
Ich könnte jetzt
nur die Steigenden Flanken zählen, was aber pro Seite immer nur 6 sind
oder
mein "Co prozessor" ATmega8, der für die Akkuüberwachung zuständig ist, hat noch 2 Pins frei und könnte somit die Encoder übernehmen und die Werte alle 200ms über UART an den 128A senden
oder
ich nehm mir einen zusätzlichen MC der die Encoder ausliest und bei jeder steigenden und fallenden Flanke einen weiteren Pin für paar ms high schaltet welche dann der ATmega128A ausliest.

@ Rabenauge
kannst du etwas über das 4:1 Getriebe sagen ? hier mal der Link dazu
https://heng-long-panzer.de/de/ZUBEH...NZER-1106.html
hab die Idee das gegen das 3:1 zu tauschen und aber auch langsamere Motoren, weil die im 4:1 verbauten Motoren sind mit 18000 U/min mir doch zu schnell.
Selbst das 3:1 Getriebe ist mir schon zu schnell und im oberen Drehzahlbereich auch zu laut :)
Das 5in1 Getriebe hab ich mir auch schon angesehen, soll aber nicht so der Hit sein was ich darüber gelesen habe.

grüße Hendrik

---

wenn du jetzt schon mit 2 cpus nicht auskommst mit pins und pinchange-interrupts, warum dann nicht von Anfang an nur 1 cpu mit ausreichend pins (60), und davon mehr als genug für pwm und interrupts?
Ich meine z.B. einen Arduino mega2560. Damit kannst du bis zu 8 Motoren steuern mit pwm und 8 Quadraturencoder parallel auslesen - und hast immer noch haufenweise Pins übrig.
(Außer Quadraturencoder mit pinchange-Interrupts auslesen gehen aber IMO beliebig viele mit 1 Timer-Interrupt sogar viel besser, da musst du gar keine Flanken überwachen).

Hallo Hendrik.

Zitat:

---

.. ein kleines Proplem .. ATmega128A kann entweder steigende oder fallende Flanken erkennen, nicht aber beide zusammen ..

---

Das wundert mich; ich hatte aber noch nie nen 128A gehabt.

Zitat:

---

Zitat von Datenblatt 8151H–AVR–02/11

..
Table 13-3. Interrupt Sense Control

...ISCn1 ISCn0 Description
.....0.....0 ... The low level of INTn generates an interrupt request.
.....0.....1 ... Any logical change on INTn generates an interrupt request..

---

Das sollte dann doch für beide Flanken funktionieren ! ? Oder habe ich im Rest des Datenblattes etwas überlesen ? Ausnahmen - die Flanken sind zu schnell (siehe dazu Anmerkungen im Datenblatt) sodass beide Flanken in einem einzigen Arbeitstakt kommen . . .

Hallo,

erstmal großes sorry,
ich hatte folgende PDF gegoogelt, http://www.atmel.com/Images/Atmel-81..._Datasheet.pdf
und da steht auf der Seite 90 Anhang 33069 nur Reserved.

Also doch besser Datenblatt beiseite legen, ATmega 128A zur Hand nehmen und ausprobieren obs funktioniert oder nicht.

Zitat:

---

.. erstmal großes sorry .. Atmel-8151-8-bit-AVR-ATmega128A_Datasheet .. auf der Seite 90 .. nur Reserved. .. Also doch besser Datenblatt beiseite legen ..

---

Ohhh, das ist ja nun wirklich ein Dilemma. Und von Deiner Seite war ja nun alles richtig gemacht worden!

Nun ist ja "Deine" Version : "Atmel-8151J..09/2015" deutlich jünger als meine "8151H–AVR–02/11" (klar, Version ~J~ gegen ~H~) UND auch die aktuellste, jüngste Version. Allerdings zeigt die Datasheet Revision History in dem von Dir referenzierten Datenblatt - also die aktuellste Version - nichts zu dieser Änderung. Auch unter Errrate habe ich beim Vergleich der beiden Dokumentationen nichts gefunden! Seltsam.

Vielleicht vor eigenen, vielleicht unnötigen, Versuchen lieber ATMEL anschreiben, um Auskunft bitten und gleich ein paar neueste 128A-Muster kostenlos ordern ! ? ! ? *ggg*

Hallo,

ich hab mich am Wochenende mit dem UART ausenander gesetzt. Im moment ist der ATmega8 mit dem ATmega128A verbunden (UART1) und der ATmega128A vorerst über Kabel mit dem PC (HTERM) (UART0).
Das senden der Werte vom ATmega8 funktioniert einwandfrei.
Momentan hab ich mit dem UART0 des ATmega128A Sorgen. Vom PC zeichen empfangen funktioniert einwandfrei, aber sowie ich etwas an den PC sende, resetet mir das Programm und fängt von vorne an.
Ich hab mal nur putch0('A'); geschrieben. im HTERM taucht ein A auf, der 128A resetet und ein A kommt dazu und so weiter ....

Code:

---

if ((puffer1[0]=='T') && (puffer1[1]=='E') && (puffer1[2]=='M'))                // wird senden von TEM vom ATmega8 erkannt im puffer1
        {
                        PORTG ^= (1<<PG4);
                        _delay_us(2000);
                        puffer1[0] = '0';//T
                        puffer1[1] = '0';//E
                        puffer1[2] = '0';//M
                        adc0 =atoi(puffer1);
                        adc0=adc0-1000;
                        temperatur=(adc0 * 500.0 / 1023) -273.15;        // adc in Temperatur umrechnen
                        dtostrf(temperatur,3,1,str);
                        I2C_SetDisplayCursor(3,6);
                        I2C_WriteDisplayString(str);
                        putstring0(" Temperatur = ");               
                        putstring0(str);
                        putstring0(" Grad ");                                // resetet ATmega128A an dieser stelle !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
                        reset_puffer1();
        }

---

So sieht momentan meine Temperaturabfarge aus. im HTERM erscheint dann "Temperatur = 21,2 Grad" , anschließend Resetet der 128A.
Wie gesagt, ohne Weiterleitung an den PC lauft alles gut.

Sehr seltsam das.

Zitat:

---

.. der ATmega128A vorerst über Kabel mit dem PC (HTERM) (UART0) .. Vom PC zeichen empfangen funktioniert einwandfrei, aber sowie ich etwas an den PC sende ..

---

Ich will hier kein Wort über HTERM verlieren, nur - ich benutze es nicht. Sicherlich/vermutlich liegt die Fehlfunktion bei Deinem Projekt nicht am Terminal - einerseits. Andererseits ist das Terminal von br@y einfach toll! Eine Downloadmöglichkeit ist hier, Version 1.93b 20141030, ich benutze aber (mittlerweile ausschließlich und eben) lieber die 2004er Version v1.9b 20040714.