XPlorer 2- ein Roboter ausm 3D-Drucker

  • Hallöle.

    Da hier erstaunlicherweise Interesse dran besteht, will ich mich nicht betteln lassen.

    Neben RC-Cars (und -booten, -fliegern) bastele ich auch an Robotern.


    Im vorigen Jahr hab ich den ersten Roboter komplett selbst gedruckt, das war der XPlorer (1).

    Bei dem gings vor allem darum, rauszufinden, ob man einen kettengetriebenen Roboter tatsächlich komplett am 3D-Drucker bauen kann.

    Basis beim 1er waren diese Fahrwerke.

    Das Endergebnis sieht so aus:

    Noch eins, mit geschlossenem Deckel:



    Der ist, im Grunde, einfach ein "RC-Fahrzeug".

    Antriebe sind pro Kette einer der berühmten gelben TT-Mootoren, sowas hier.


    Er hat einen Arduino Nano drin, als Bordrechner, zusätzlich einen Node-MCU als Funkbrücke.

    Vorn und hinten sind jeweils einige WS 2812-RGB-Led-Streifen eingebaut (je drei in den Rückleuchten, in der vorderen Lampe sechs).

    Er kann seinen Akku überwachen, und auf Kommando halt noch fahren, mehr nicht.

    Zum steuern hab ich dem sogar ne kleine App gebastelt gehabt.


    Fazit: der ist zu klein. Zum einen ziehen diese Motörchen keinen Hering so richtig vom Teller, zum anderen ist im Innenraum nicht mal Platz für Odometer (Odometer sind ne Art Tacho von den Rädern, damit kann man z.B. messen, wie weit er gefahren ist, aber auch die Geschwindigkeit ermitteln usw.).

    Da ich, aus Platzmangel, die Motoren nicht mal mit 6V versorgen konnte (dazu hätten sie nen eigenen Spannungswandler gebraucht, der nich rein passt) fährt das Ding zwar, aber recht ...träge).

    Und bei bis zu 8.4V, die der Shorty nunmal liefert, versterben die Mickymaus-Motoren bereits....


    Also musste es ne Nummer grösser werden.

    Vom gleichen Designer, wie die kleinen Ketten, stammen auch diese hier.

    Bei denen sitzen in jedem Antriebssatz _zwei_ der berüchtigten Motoren.

    Als ich davon einen zur Probe gedruckt hatte, hab ich gemerkt: viel zu umständlich gelöst, also ab ans Reissbrett.

    Ich hab die kompletten Fahrwerke umkonstruiert, inzwischen gibt es nur noch ein Innenteil, ein Aussenteil, die Kettenblende (das mit dem Schriftzug drauf, die stabilisiert die Kette seitlich zusätzlich), zwei Räder (die sind vom Originalentwurf noch übrig) und zwei kleine Mitnehmer.

    Die äussere Form hab ich so verändert, dass er nen bisschen Bodenfreiheit bekommt- ungefähr 22mm.

    Immerhin.


    Nun war die Wanne von Thingiverse natürlich auch nich mehr zu gebrauchen, also hab ich kurzerhand weiter konstruiert:



    Die Wanne ist _deutlich_ grösser als die vom 1er.

    Und inzwischen ziemlich voll: im Heck sieht man einen etwas stärkeren Spannungswandler, der 6V für die Motoren bereitstellt.

    Davor der Dual-Motortreiber, der die Motoren ansteuert, ganz vorne der Shorty 2s2p mit 200mAh), links und rechts davon erkennt man die Odometer: ich hab einfach die Abtriebswellen der Motoren etwas verlängert, und dann innen Encoderscheiben aufgesteckt. Die laufen zwischen kleinen Gabel-Lichtschranken-Modulen, so bekomm ich pro Radumdrehung ungefähr 36 Impulse, die ich auswerten kann.

    Im Bild noch nicht zu sehen: neben dem Motortreiber-Modul sitzen jetzt noch zwei kleinere Stepdown-Spannungsregler, die jeweils 5V bereitstellen.

    Die versorgen später die beiden Rechner.


    Hier ist schonmal der Boden der Oberwanne drauf.

    Der wird mit vier M3-Schrauben mit der Unterwanne verbunden, somit kann man alles jederzeit wieder zerlegen, wenn nötig. Übrigens:alle wichtigen Baugruppen sind so verschraubt. Geklebt ist nur, was nicht mehr auseinander genommen werden muss, später (die Oberwanne mit diesem silbernen Boden z.B.).

    Das silberne Deck hat eine Aussparung im Heck-dort kommt später ein HC-S04-Ultraschall-Sensor hin, als grobe Hinderniserkennung.

    Ausserdem sind in dem Teil hinten Aussparungen für Rücklichter (sieht man hier nicht).

    Der Arduino Nano, der hier schon drin ist, ist auf nem Stück Streifenraster-Platine gesockelt- der ist jederzeit rausnehmbar. Diese Adapter-Platine kriegt später die ganzen Steckplätze für die übrige Elektronik, damit man alles austauschen kann.


    In dem Zustand kann das Ding bereits fahren, den Akku überwachen, und auch den Gerdeauslauf regeln.

    Aber ich wollt natürlich ein komplettes Gehäuse, also weiter...



    Hier ist die Oberwanne nun komplett.

    Sie ist mit ihrem Boden (dem silbernen von vorher) kurzerhand verklebt.

    Das lies sich, separat, besser drucken.

    Ausserdem sind weitere Einbauplätze dazu gekommen, die Kettenblenden sind hier auch schon dran.

    Lampen hat die Oberwanne vorn noch bekommen, auch die Lampengläser sind gedruckt:




    Die Oberwanne hat ne Aussparung für einen Schalter im Heck- daneben sitzt die Ladebuchse.

    Ich komm nämlich an den Akku jetzt nur noch mit einiger Bastelei ran (das ist was, dass ich in einer nächsten Version ändern würde: ne Bodenklappe in der Unterwanne).

    Rechts im Heck sitzt ein 30mm-Lüfter.

    Mittig der schon erwähnte Ultraschall-Sensor, ich hab die softwaremässig so justiert, dass sie auf ca. nen Meter Hindernisse erkennen können.

    Vorn drin ist ein HC-SRF 05- der Nachfolger des 04er.


    Die vier Lampen sind quasi als Streifen geschalten: hinten links- hinten rechts- vorn.

    Die beiden vorderen laufen tatsächlich nur parallel, das heisst, die können immer nur -spiegelbildlich- das Gleiche tun.

    Bei den Rücklichtern ist dem nicht so, da kann ich jede LED separat steuern (es sind, auch vorn, in jeder Lampe zwei Stück drin).

    Fahr-und Bremslichter, Blinker, Blaulicht- alles ist damit möglich.


    Fahrlicht gibts schon in der Software, Bremslicht ebenfalls.

    Ausserdem benutze ich die vier Rücklichter, um die Bordspannung anzuzeigen: je nachdem, wie voll der Akku ist, leuchten die von links nach rechts alle 20 Sekunden kurz grün auf.

    Wird der Akku bedenklich leer, wechselt die Farbe auf orange- und ab einem bestimmten Wert weigert sich der Roboter, weiter zu fahren.


    Die beiden Ultraschall-Sensoren sitzen in eigenen Brillen, die man austauschen kann. So ist es keine grosse Sache, da ganz andere Sensoren zu verbauen, man muss nur diese kleinen Platten neu drucken.

    Insgesamt sind _sämtliche_ Einbauten frei platzier- und austauschbar, da ich im ganzen Roboter _keine_ Befestigungen drin habe.

    Jede Platine hat ein, eigens für die gezeichnetes, Rähmchen mit kleinen Stützen, die passend zu ihren Montagebohrungen sind.

    Diese Rahmen werden einfach nur dort eingeklebt, wo an sie haben will. Die sind sehr schnell konstruiert (5-10 Minuten) und genauso schnell auch gedruckt.


    Dadurch kann man den Roboter ganz nach Belieben ausrüsten- viel flexibler gehts nicht mehr.

    Was auf den Fotos noch nicht drauf ist: hinten links (da wo die noch freie orange Ecke ist) sitzt inzwischen noch ein Helligkeits-Sensor. Der misst das Umgebungslicht, und steuert damit die Helligkeit der Lampen: mich hat es genervt, abends hier zu programmieren, und die hellen RGB-LED's dauernd in den Augen zu haben.

    Nun werden die im Dunklen einfach gedimmt-automatisch.


    In der Oberwanne sitzt auch schon ein Raspberry Pi Zero(W) inzwischen, der aber noch nix tut. Der ist erstmal nur der Passagier- später soll er

    -die Fernsteuerung werden, indem er Kommandos vom Tablet oder Laptop empfängt (via WLAN),

    -eine IR-Cut-Kamera ansteuern (die hat einen zuschaltbaren Infrarot-Filter, und kann somit sowohl im Hellen als auch im Dunklen vernünftige Bilder liefern)

    -den Camerastream zum Steuergerät schicken.

    - weitere Daten auch mit übertragen

    Aber so weit bin ich noch nicht.


    Da die Mini-Antenne des Pi keine vernünftige Reichweite liefert, kommt ins Dach ein kleiner Wifi-Repeater, der als Wlan- Zugangspunkt arbeitet. Mit dem verbinden sich der Raspi und das Steuergerät.

    Der läuft einfach mit USB-Stromversorgung- 5V hab ich ja eh.

    Erfahrungsgemäss schafft man mit dem Ding etwa 100-300m.


    Momentaner Stand:

    -er läuft.

    Es gibt einen Software-Tacho, und ich kann beispielsweise anweisen, dass der XPlorer zehn Meter weit fahren soll, und dann stoppen (genaugenommen kann er mit einer Angabe wie "Meter" noch nix anfangen, aber das ist nur ne lausige Umrechnung, er zählt momentan nur Radumdrehungen).

    Dabei kann er die Ketten auf Gleichlauf regeln (freiwillig laufen die nie gleich schnell), damit er auch zumindest einigermassen geradeaus fährt (ganz genau wird das nie werden, im Freien mit Unebenheiten sowieso nicht, da bräuchte man nen ganz anderen Geber).

    Die beiden Hindernis-Sensoren laufen auch schon, wie gesagt: auf Entfernungen bis ungefähr nen Meter (die könnten auch weiter, aber so schnell fährt der nicht, dass das nötig wäre, also kann ich die Zeit, die eine Messung dann bräuchte, auch sparen)- die gemessene Entfernung wird auch schon auf cm umgerechnet.

    Alle 20 s wird die Akkuspannung gemessen, und -wie oben beschrieben- über die Rückleuchten angezeigt.

    Ebenfalls alle 20s (aber nicht in der selben Sekunde, wie der Akku) wird mal die Umgebungshelligkeit gemessen, und die Helligkeit der Lichter entsprechend justiert: je heller es ist, umso heller auch die Lampen.


    Ein Lichtprogramm "Fahren" gibts, ein Lichtprogramm "Bremslicht" ebenfalls, da kommt noch einiges.

    Das ist aber nur Spielerei (ab und zu gehts mit mir halt durch-die Lichter sind eigentlich für die spätere Aufgabe vollkommen unnötig). Aber cool ist es schon, wenn er beim einschalten mal eben die Lichter kurz der Reihe nach blau aufblitzen lässt, hehe...


    Der nächste Schritt ist jetzt, ihm lenken beizubingen, das kommt nun die Tage.

    Danach kann er -autonom- mal auf dem Wäscheboden einige Runden drehn- und dabei den Wänden ausweichen.

    Dafür werd ich den Bordtacho dann mal auf Meter umstellen, damit ich ihn beauftragen kann, nach 30m (oder so) alleine anzuhalten.


    Falls Fragen sind: fragt einfach.

    ___________
    Grüssle, Sly

    Edited 2 times, last by Rabenauge ().

  • Sly, mein Kompliment, auch sehr schön erklärt. Gelegentlich noch ein paar Infos zur Rolle des Arduino und wie/womit du ihn programmiert?

    LG Rolf (Rapper)


    Mein Drucker: Anycubic i3 Mega

    Mein CAD: Sketchup Make

  • Der Arduino wird ganz normal mit der Arduino-IDE programmiert.

    Da es ein Nano ist, braucht man nicht mal nen Adapter- ein simples USB-Kabel reicht.


    Im Grunde kümmert er sich um die gesamte Hardware:

    -er steuert die Motoren an (genaugenommen die Motortreiber)

    - er überwacht den Akku

    -er steuert die LED's an

    -misst die Umgebungshellugkeit

    -liest die Odometer aus

    - misst vorn und hinten die Entfernung zu Hindernissen.


    Bisher hab ich lediglich eine einzige Bibliothek benutzt, nämlich die FastLED.

    Die ist für die Beleuchtung zuständig.


    Alles andere mache ich selber- inzwischen gibts in dem Arduino-Programm bestimmt ein Dutzend Unterprogramme, die ich quasi als vorgefertigte Routinen so geschrieben hab, dass ich die bei Bedarf einfach nur aufrufen brauche.

    Damit der Aduino die vielen Aufgaben bewältigen kann (bei einigen ist das Timing wichtig), gibts eine Art Zeitscheiben-Steuerung:

    im Hinterrund läuft ne Art Uhr, die volle Sekunden hochzählt (bis 20 im Moment, danach wird sie wieder auf 0 gesetzt).

    Nun kann ich, je nachdem, welchen Wert der Sekundenzeiger hat, den Akku auslesen, oder in der nächsten Sekunde nach Hindernissen scannen, die Umgebungshelligkeit messen oder so.

    Dadurch kommen sich die ganzen Aufgaben nich in die Quere und vor allem: sie blockieren sich nicht gegenseitig.

    Gerade, wenn vieles "gleichzeitig" zu erledigen ist, macht so ein Bordtimer Sinn- das mach ich öfters so.


    Die beiden Odometer (die Gabellichtschranken an den Motoren) werden mittels Interrupts angebunden, das läuft in etwa so ab:

    bei jedem "Tick" eines der Sensoren wird einfach ein Interrupt ausgelöst.

    interrupts deshalb, weil die auch dann ausgelöst werden, wenn der Rechner grad was anderes macht.

    In dessen Routine wird nun eine Variable hochgezählt.


    Da ich je eine Variable hab (eine für die linke, eine für die rechte Kette) ist es ganz einfach, beide Werte zu vergleichen.

    Dieser Vergleich wird z.B. für die Geradeausfahr-Regelung genutzt: immer, wenn die Odometer-Variablen nen bestimmten Wert überschreiten (momentan 20) wird ausgewertet, ggf. ein Offset berechnet aus den unterschiedlichen Werten, der dann von der schnelleren Kette abgezogen, und zur langsameren hinzugezählt, und dann werden die Odometer wieder auf 0 gesetzt.

    Weiterer Vorteil dieser Regelung: ich kann die Fahrgeschwindigkeit ganz leicht verändern, indem ich einfach die Soll-Variable der Motoren ändere.

    Da immer auf den langsameren der gleiche Wert aufaddiert wird, der vom schnelleren abgezogen wird, hab ich -im Durchschnitt- immer den Soll-Wert der Fahrgeschwindigkeit.


    Auf diese Weise pendeln sich die Geschwindigkeits-Vorgaben der Ketten so lange ein, bis sie tatsächlich gleich schnell laufen (ganz genau ist das nicht, es gibt immer mal wieder kleinere Abweichungen, schon, weil man mit so niedrigen Werten keine präzisen Offsets berechnen kann, aber nehm ich längere Zyklen, wird die Regelung langsamer)- ich will das auch nich auf die Spitze treiben, denn im Freien, auf unebenem Untergrund, hats sich sowieso mit schnurgerade fahren.

    Das Ganze liest sich etwas einfacher, als es ist- beispielsweise muss man sicherstellen, dass die Regelung nie zu niedrige Werte generiert, bei denen ein Motor schon stehen bleiben würde, und wirklich Vollgas fahren kann man auch nicht- weil dann zum Regeln nix mehr übrig wäre, und es gibt noch einige weitere Tücken - aber im Prinzip läuft das schon so ab.


    Theoretisch könnte man die Odometer ausserdem nutzen, um ganz präzise Kurvenradien zu fahren, da bekannt ist, wieviele Impulse pro Radumdrehung kommen, kann man das über den Durchmesser der Räder machen.

    Dann könnte man z.B, gezielt einen Kreis fahren, bei dem die Mitte des Roboters genau auf dem Radius X ist.

    Tu ich aber nicht- mal sehen, iob ich heute noch Lenk-Routinen schreibe.

    Ich will erstmal nur zwei haben: eine für auf dem Punkt drehen (kann beim rangieren nützlich sein), und nen grösseren Kurvenradius.

    Beides kein grosser Zauber..


    Was ich aber schon mache: bevor die Odometer zurückgesetzt werden, wird aus beiden der Durchschnitt berechnet, und dieser Wert gespeichert- das ist ne Art Kilometerzähler.

    Den kann man mathematisch dann so aufdröseln, dass man die Fahrstrecke in Metern messen kann.

    Oder vor gibt, dass der Roboter X Meter weit fahren soll, sowas halt.

    Superpräzise ist das nicht: ich kann die Ketten im Stand ca. 10mm vor-oder zurück bewegen, ohne dass der Motor sich überhaupt bewegt, aber es wird ausreichen.



    Später wird der Nano seine Befehle über eine serielle Schnittstelle vom Raspberry bekommen, das heisst: der Raspi bekommt die Fahrbefehle per Funk, und leitet sie weiter an den Arduino.

    Der setzt sie dann entsprechend um..und sendet ggf Meldungen zurück zum Raspi.

    Arduinos sind halt für Steuer- und Regelaufgaben besser geeignet, als die RaspBerrys, ausserdem wird der RasPi später mit dem Videostream genug zu tun haben.


    Wenn man einfach nen autonomen Roboter bauen will, ist der Raspi überflüssig- aber nen Echtzeit-Videostream schafft ein Arduino im Leben nicht...nicht mal in kleiner Auflösung.


    Aktuell: heute morgen (und auch nachher wieder) konstruiere ich am Deckel weiter.

    Der wird insgesamt vierteilig: es kommt eine Art Träger auf den Roboter, in den dann drei "Platten" eingesetzt werden.

    So kann ich hübsch bei dem silber-orangen Look bleiben, und diese einzelnen Platten später austauschen.

    Zusätzlich wird in dem Träger der Wifi-Repeater eingebaut, der dafür sorgt, dass der RaspBerry auch über eine gewisse Entfernung noch erreichbar ist.


    Der ist eigentlich ein Fertiggerät, so einer.

    Ich werde davon allerdings nur die Antennen und die Platine verbauen-das Gehäuse ist unnötig gross (das Innenleben ist höchstens die Hälfte), und der klappbare USB, der nur der Stromversorung dient, neigt zu Wackelkontakten.

    Die einklappbaren Antennen will ich aber schon haben- das vereinfacht später den Transport, hehe.

    Diese Dinger kann man ziemlich frei konfigurieren, die können als reiner Repeater arbeiten, aber z.B. auch als AP.

    Diesen Modus werd ich nutzen.

    Dann hat der XPlorer ein eigenes WLAN, draussen später die sinnvollste Variante.

    ___________
    Grüssle, Sly

  • Sly, ich bin immer wieder begeistert! Da viele User gar nicht wissen, wie ein Raspberry oder ein Arduino programmiert wird: stell doch bitte mal einen Screenshot von einem Programmcode hier rein und sage kurz, was dieser Code bewirken soll.

    Dein Projekt ist faszinierend!

    :thumbup:


    PS: ich hatte letztes Jahr einen Robot in USA im Web entdeckt, den wollte ich mir zulegen, leider vergessen wie der hiess. Der machte im Prinzip das was deiner macht.

    Solltest du irgendwann deine Pläne öffentlich zugänglich machen, wäre ich ein heisser Interessent.

    LG Rolf (Rapper)


    Mein Drucker: Anycubic i3 Mega

    Mein CAD: Sketchup Make

    Edited once, last by Rapper ().

  • Hm, du willst ein wenig Code?


    Dann zeige ich mal, wie ich das "Multitasking" handhabe:



    So sieht das in der Arduino-Programmierumgebung aus.

    Im wesentlichen passiert hier folgendes: der Rechner vergleicht seine interne Uhr (er hat keine Echtzeituhr, aber eine Art eingebute Uhr, die die Millisekunden seit dem Start zählt) mit einer Vorgabe- in meinem Fall sind das 1000Millisekunden.

    Somit habe ich die Basis für einen Sekunden"tick".

    Dann wird erstens: dieser Tick auf 0 gestellt, wenn er 1 war, oder auf 1, wenn er null war "Tick, Tack...) und zweitens ein Zähler erhöht, der bis 20 zählen kann.Erreicht er die 20, wird er wieder auf 0 gesetzt.

    Den kann ich dann im nächsten Screenshot benutzen, um Dinge zu tun, die nur alle 20 Sekunden passieren sollen (die ganzen Zeiträume sind beliebig anpassbar, wie mans eben braucht).

    Zusätzlich werden einige Variablen, die ich "Flags" nenne, zurückgesetzt.

    Dazu dann noch was.

    Hier nun ein Screenshot, der zeigt, wie mittels dieser Schaltuhr gezielt ein Vorgang ausgelöst wird:



    Immer dann, wenn der "Sekundenzeiger" auf der 1 steht, _und_ das "gemacht-Flag" für die Helligkeitsmessung noch nicht 1 ist, wird der Helligkeits-Sensor abgefragt, und sein Wert so umgerechnet, dass die LED's dann damit später was anfangen können.

    Die Variable Brightness wird hier üerhaupt nicht genutzt, das ist quasi nur eine Stellschraube, die angepasst wird.

    Erst wenn, in nem anderen Unterprogramm, dann mal die Lichter aktualisiert werden, wirkt es sich aus.


    Das Flag ist deshalb erforderlich, weil der Rechner binnen einer Sekunde etliche mal die ganzen Zykln durchläuft. Er würde also in der "Sekunde 1" das Ganze sonst womöglich 50x erledigen.

    Da er aber nach dem ersten Durchlauf dein "gemacht-Flag" auf 1 stellt (das oben im Timer erst zur nächsten Sekunde wieder zurückgestellt wird), tut er das genau einmal, und das eben alle 20 Sekunden.


    Die Vorgehensweise mittels diesem "Timer" ist im übrigen alles andere als ne Präzisionsuhr, die geht niemals wirklich auf die Milisekunde genau (weil diese ganze Funktion nur dann aufgerufen werden kann, wenn grad nix anderes anliegt, und erst dann die Sekunden überhaupt gezählt werden können), aber das macht nichts- so lange es sich nicht um extrem zeitkritische Aktionen handelt.

    Ist doch nun Wurst, ob die Akkuspannung mal 0.02s später ausgelesen wird..

    Aber genau das ist auch der Vorteil: die damit gesteuerten Vorgänge können beliebig auf die Rechenzeit verteilt werden.

    Wenn ich die ganzen Aufgaben, der der Timer in einem 20-Sekunden-Rhytmus abarbeitet, direkt nacheinander machen würde, kann das einige Sekunden lang alles blockieren- so teil ich es halt so auf, dass das nicht passiert.

    Jede einzelne Aufgabe kriegt so "zwischendurch" immer ein bisschen Rechenzeit, und das kann ich kontrollieren!

    Obendrein ist der Timer beliebig anpassbar: er kann auch Minuten, sogar Stunden zählen, wenn man will.

    Genauso einfach könnte er alle Zehntelsekunden "ticken".


    Alles kann man mit der Vorgehensweise natürlich nicht erledigen: beispielsweise die Rad-Sensoren, die die Bewegungen der Räder zählen, müssen ganz anders gehandhabt werden, sonst gehen da Signale verloren.

    Aber bei allem, was nicht so extrem schnell erledigt werden muss, funktioniert das hervorragend.


    Übrigens:

    Roboter mit ähnlichen "Fähigkeiten" gibts jede Menge.

    Einer meiner ersten war ein NiboBee von Nicai-Systems. Der ist deutlich kleiner, hat keine Ketten, aber auch der hat eine Odometrie, zwei Fahrmotoren (na gut, ich hab vier, aber da immer zwei zusammenhängen macht das keinen wirklichen Unterschied), einen Linien-Folge-Sensor (den man, in Grenzen, auch anders nutzen kann) und zwei Fühler als Hinderniserkennung.

    Nicht outdoortauglich, aber ein ziemlich guter Einstieg.


    Auch erweiterbar...einige Erweiterungen gibts von Nicai, aber man kann sich auch eine Menge Zeugs selber dazu bauen.

    Made in Germany übrigens- bei Conrad zu bekommen für einen, wie ich finde, durchaus anständigen Preis.


    Recht bekannt ist auch der Asuro von Arrex- ne ähnliche Plattform wie der NiboBee, wobei letzterer in einigem doch etwas besser ist...er ist einfach neuer.

    Mit Ketten hat (oder hatte-weiss nicht, ob es den noch gibt) Arexx den RP-6 im Sortiment, allerdings hab ich den nie wirklich in Betracht gezogen: das Fahrwerk hat zwar Ketten, schafft aber, aufgrund der dusseligen Bauform (Klasse Ingenieursleistung, ehrlich mal...) nicht mal ne Türschwelle....da brauch ich auch kein Kettenfahrwerk *lach


    Mein NiboBee war der letzte, den ich fertig gekauft hab (naja, fertig nicht, der ist ein Bausatz), seitdem mache ich das eigentlich alles selber denn die, die es "in grösser" zu kaufen gibt, haben allesamt irgendwo Schwachstellen:

    Arexx hat die Wild-Thumper-Plattform (die ein Superding sein könnte), die eigentlich auch outdoortauglich ist (der kann, mit dem Sechsrad-Antrieb und der Federung auch ziemlich gut echtes Gelände) ,ein Kunstwerk , was draussen mal gar nicht zu gebrauchen ist: da alles offen ist, wird jeder Wassertropfen das Ding lahmlegen.

    Dank der "durchdachten" Konstruktion ist es nahezu unmöglich, das Ungetüm zu verkleiden.

    Sowas kann man in sehr trockenen Gegenden der Welt sicherlich benutzen, aber doch nich in Mitteleuropa...

    Andere bauen auch wetterfeste Chassis- die dann aber keiner bezahlen kann.

    Es gibt auch eine relativ schnelle Plattform mit Ketten: den T'Rex - nicht ganz günstig (geht aber noch), und auf den Werbevideos ne beeindruckende Performance.

    Aber nur dort: ich kenne genau diese Ketten zu gut (sind 1:16er Tigerketten aus China)- in echtem Offroad-Betrieb werden die eine Schererei nach der anderen machen.


    Fazit für mich: wenn du was richtig gutes willst, machs selber.


    Aktueller Stand: ich ab den Stepdown-Wandler, der mir 6V für die Motoren bereitstellen sollte, raus geworfen.

    Der grund: aufgrund seiner Bauart braucht der, um 6v erzeugen zu können, mindestens 8V.

    Ein voll geladener 2s hat die-aber nicht lange. Und dann bricht die Motorspannung so weit ein, dass die Fuhre sich nur noch bei Vollgas überhaupt bewegen konnte.

    Nun bekommen die Motoren die volle Akkuspannung- und ziehn wesentlich besser durch.

    Eine Dauerlösung ist das- für meine Ansprüche- nicht: sie schaffen vielleicht 15-20% Steigung, dann geht ihnen die Puste trotzdem aus.


    Daher hab ich mal ein Pärchen deutlich stärkere Motoren bestellt. Praktischerweise auch mit angeflanschtem Getriebe und Encoder hinten dran.

    Für die muss ich ne neue Unterwanne konstruieren (naja, einiges an der alten ändern..), und jeweils ein Teil der Kettenfahrwerke umzeichnen- keine so grosse Sache.


    Da der XPlorer eh noch nicht so weit ist, um draussen zu operieren, hat das keine Eile-für drinnen gehn die kleinen Antriebe ja nun.

    ___________
    Grüssle, Sly

    Edited 2 times, last by Rabenauge ().

  • Kleiner Rückschlag naja, der war vorherzusehen): die Antriebsmotoren sind aus dem Geschäft.

    Nachdem ich die Spannung erhöht hatte, fingen die Wellen an, durchzurutschen (oder irgendwelce Ritzel auf Wellen..)- keiner der Motoren brachte mehr seine volle Leistung.


    Die werden also mal beiseite gepackt (für kleinere Fahrzeuge gehn die ja trotzdem)- aber der XPlorer 2 bekommt jetzt _richtige.


    Zwei hab ich schon da: 25mm-Motoren (das müsste Baugrösse 300 sein) mit Inine-Getriebe, ziemlich stark untersetzt (angeblich drehn die am Ausgang nur 170U/min, das wird dann so ungefähr der selben Geschwindigkeit wie vorher entsprechen).

    Und: die haben Encoder hinten dran. Keine Lichtschranken, sondern Hall-Sensoren (die auf nen Magneten reagieren, der direkt auf der Motorwelle sitzt).

    Das wird eine sehr viel höhere Auflösung der Odometrie geben, und somit wahrscheinlich auch eine schnellere Regelung, der Geradeausfahrt, z.B.

    Praktisch: die selen Motoren (mit Getriebe) gibts auch -etwas billiger- ohne die Encoder.

    Ich bau also in jeden Antrieb einen mit, einen ohne. Durch die Ketten werden sie ja sowieso Zwangs-synchronisiert.


    Vier solcher Motor-Getriebe-Kombis sollten dann ausreichen, dass der XPlorer auch senkrechte Wände rauf könnte, hehe.

    Mein 1:16er Tiger-Modellpanzer schafft ein bisschen über 100% Steigung, wenn der XPlorer das auch hinkriegt, bin ich mehr als zufrieden.


    Allerdings muss ich einige Teile neu zeichnen und drucken, aber nicht viele:

    -die Innenteile der Antriebssätze müssen neu gemacht werden (hab ich schon, der erste Druck läuft, wenn das ales passt, ist morgen dann auch der zweite fertig)

    - die Radmitnehmer musste ich ummodellieren, weil die Achsen etwas anders sind

    -die Unterwanne muss neu.


    Alles nich die Welt- die Wanne wird allerdings etwa 12 Stunden Druckzeit brauchen. Naja- im Moment sind die Nächt ja lang, hehe.


    Der Umbau hat aber, neben einer, wie ich denke, nun mehr als ausreichenden Leistung, noch nen grossen Vorteil: durch die andere Bauform (und nen völlig anderen Einbau) der Motoren ist es kein Problem, die Unterwanne vollkommen dicht zu bekommen.

    Das war mit den TT-Motoren unmöglich...jetzt _könnte_ ich den XPlorer ganz leicht bis ca. 10cm Wattiefe wasserdicht bekommen.

    Vermutlich würde er allerdings aufschwimmen, daher spar ich mir das: mal ne Pfütze von 3-5cm Tiefe durchfahren wird er nach dem Umbau ohne weitere Massnahmen können, das reicht mir erstmal.


    Ach- und natürlich bauche ich jetzt nen stärkeren Motortreiber..da müsste ich noch was da haben, such ich die Tage mal....da war was mit 15A bei bis zu 35V irgendwo- das wird locker reichen.

    Angegeben sind die Motoren mit ca. 2.5-2.8A Anlaufstrom, selbst parallel geschalten komm ich da nicht mal in die Nähe von 15A.


    An der Software muss ich für den Umbau gar nicht mal viel ändern: natürlich muss der "Kilometerzähler" an die Odo-Ticks angepasst werden, und evtl. brauchen die anderen Motortreiber auch ne etwas andere Ansteuerung, aber so schwer ist das alles nicht.

    ___________
    Grüssle, Sly