XPlorer 2

Hallöle.
Einige Bilder hatte ich ja schon gezeigt: ich baue derzeit an nem neuen Rover.
Der Vorgänger XPlorer (1) ist auch ganz nett, aber zu klein und zu schwachbrüstig. Eigentlich hatte ich mit dem nur ausprobiert, ob man tatsächlich ein brauchbares Kettenfahrwerk mit nem 3D-Drucker überhaupt hinbekommt.

Der XP2 ist inzwischen nahezu fahrbereit (er ist auch schon gefahren, es fehlt nur noch ein "sinnvolles" Programm für).
In dem -deutlich grösseren- hab ich einiges realisiert, was beim Vorgänger einfach nicht mehr rein passte:

-Odometrie
-stärkere Antriebe
-viel mehr Platz im Inneren
-wesentlich modularer
- deutlich stabiler
Er soll nämlich auch draussen einsetzbar sein. Das geht zwar mit dem XP1 auch, aber er ist eben...kleiner.

Die Antriebssektionen sind nicht ganz auf meinem Mist gewachsen, ich hab die Grundkonstruktion der beiden Kettengehäuse mehr oder weniger von dem hier übernommen.
Allerdings: bis auf die Kettenräder (die ich wahrscheinlich auch noch etwas ändere) und die Mitnehmer ist alles praktisch neu konstruiert.
Der gesamte restliche Aufbau ist komplett selbst entworfen, gezeichnet- und inzwischen auch gedruckt.
Insgesamt dürften das jetzt an die 30 einzelnen Druckteile sein, alles passt gerade in nen Drucker, der 22x22cm Bauraum hat (vielleicht kriegt mans auf 20x20cm grade noch hin).
Die beiden Kettengehäuse, in denen die Motoren sitzen, sind identisch und symmetrisch, die Unterwanne ebenso.

Antriebe sind vier Stück der berühmten gelben TT-Motoren , sowas hier.

Sämtliche Elektronik-Komponenten sitzen auf einzeln eingeklebten Rahmen (worauf sie mit kleinen Spaxen verschraubt sind), so kann man alles frei positionieren, wie man will.
Ober-und Unterwanne kann man trennen, auch die Kettengehäuse lassen sich abschrauben, das ist alles mit M3-Schrauben verbunden.

Ausstattung :
-pro Kette zwei TT-Motoren mit innenliegenden Encoder-Scheiben und Gabellichtschranken
in der Unterwanne stecken dann noch:
-zwei kleine und ein grösserer Stepdown (der grössere macht mir 6V für die Motoren, die anderen beiden jeweils 5V)
- ein Akku 7.4V 2s2p (Shorty) mit 4200mAh
- eine Dual-H-Brücke für die Motoren (die beiden auf einer Seite hängen einfach parallel)
-die beiden Gabellichtschranken für die Odometrie

In der Oberwanne:
-Arduino Nano (der steuert momentan alles, soll aber später seine Befehle von nem RasPi Zero erhalten)
-vorn und hinten je ein US-Sensor (erstmal HC-SR04, aber die Panele kann man austauschen)
- vier Lampen in den Ecken, jeweils bestückt mit zwei WS2812-RGB-Leds
- ein 30mm-Lüfter (später soll ein Dach obendrauf, da möcht ich gerne die Wärme aus dem Ding bekommen)
Schalter und Ladebuchse- beides von aussen zugänglich.

In die Oberwanne würden problemlos auch zwei Arduino Mega 2560-Platinen passen, oder zwei Raspberrys in Normalgrösse.
Ich hab nur nen ZeroW drin.

Aktueller Stand: er ist fahrbereit.
Die Odometrie funktioniert (möglicherweise muss ich da noch mal ran, aber das muss ich austesten)
Vorderer Hindernissensor läuft (hinten ist grad keiner drin, auf den warte ich noch)
Akku wird vom Arduino überwacht (der gibt auch den "Füllstand" über die vier hinteren RGB-LED's aus)
Beleuchtung läuft: die LED's sind als Stripe geschalten, aber die vorderen nur paarweise. Was also das vordere linke Licht macht, tut auch das rechte- natürlich spiegelverkehrt.
Die hinteren können alle einzeln angesprochen werden...die bentze ich derzeit so bisschen als Display.

Später will ich versuchen, den Pi als Fernsteuerung zu verwenden: ich bau zu dem eine kabellose Verbindung auf (das geht auch schon, per VNC), und er kommuniziert mit dem Nano über die serielle Schnittstelle (das geht noch nicht).
Für sinnvolle Reichweite kommt später ein Wifi-Repeater obendrauf, der als Zugangspunkt arbeitet.
Ausserdem soll der Pi eine Kamera bekommen (die läuft auch schon, ne IR-Cut, die auch im dunklen gut funktioniert).
Idealerweise wird die dann auch noch stabilisiert (eine Achse wenigstens).
Hauptziel der Sache soll es sein, mich in die Programmierung des Pi mal _so richtig_ einzuarbeiten.

Jetzt einige Bilder, die nahezu den Jetzt-Stand zeigen (inzwischen ist hinten noch ne schicke Blende um den Schalter dazu gekommen, auf der auch der Name steht), und ein Screenshot aus Blender, mit dem ich alles konstruiere.
Ich hab noch mehr Fotos, und kann auch weitere machen, hehe.

Was haltet ihr von dem Teil?

Inzwischen gibt es kleinere Neuigkeiten: da ich heute frei hab, hab ich mich mal dran gesetzt, eine Spur-Regelung zu programmieen.
Diese TT-Motoren sind nicht so gut, dass ein Roboter damit _wirklich_ geradeaus fährt, daher musste sowas her.

Funktioniert inzwischen recht gut: die Odometer werden jede Sekunde vergleichen, und die PWM der beiden Ketten entsprechend angepasst:
Anhang 34667

Die "Aussreisser" in den Odo-Werten (wo die Werte deutlich höher sind als sonst) rühren nur daher, dass alle 20 Sekunden auch die Akkuspannung mal ausgegeben wird.
Da meine Odometer aber bis 255 zählen können, ist das unerheblich.
Die Regelung ist sehr simpel gestrickt: jede Sekunde wird die Differenz aus beiden Odo-Werten gebildet, anschliessend wird der Absolutwert dieser Differenz auf den langsameren Antrieb aufaddiert (auf die Soll-Vorgabe der PWM) und vom schnelleren wird der selbe Wert abgezogen.
Anschliessend werden die Odometer wieder auf Null gestellt.
So kann ich dennoch die Geschwindigkeit nach Belieben regeln (über ne Soll-Vorgabe der PWM), und die Regelung läuft nich ausm Ruder.

Zitat:

---

Zitat von Rabenauge

Diese TT-Motoren sind nicht so gut, dass ein Roboter damit _wirklich_ geradeaus fährt, daher musste sowas her.

---

Ich würd das nicht den Motoren anlasten. Die Reibung in den Lagern und im Getriebe und bei dir auch in den Ketten ist schon relativ groß und wirkt sich auf die Drehzahl aus. Und sie ist für zwei Motore kaum gleich hinzubekommen. Das kann man schon mit einem Motor zu erkennen. Wenn er lange gelegen hat, läuft er mit etwas frischen Öl bei gleicher Spannung schneller, d,h, die Reibung wird merklich geringer. Ohne eine Regelung oder die Ausrichtung auf ein externes Ziel wird man eine wirklich gerade Fahrt kaum hinbekommen.

MfG Klebwax

Ja das stimmt natürlich.
Diese Antriebe haben nur "Spielzeug-Leistung"- von daher war das nicht anders zu erwarten (hatte ich auch nicht).
Eigentlich staune ich, das die den, immerhin inzwischen ca. Kiloschweren, XPlorer überhaupt vernünftig bewegen können, hehe.
Allerdings: die Ketten bei dem laufen extrem leicht, die Antriebsräder auch, die sind "fliegend" gelagert, damit dort nicht zu viel Leistung weggefressen wird.
Natürlich hat man trotzdem mehr als bei Rädern.

Zitat:

---

Zitat von Rabenauge

Was haltet ihr von dem Teil?

---

Mit 16cm mal 16cm ist er nicht gerade groß. Ich frage mich daher, wo die Kilogramm an Gewicht herkommen. Klingt nach schweren 3D-Druckteilen.
Ich finde den nicht schlecht. Allerdings beim Design: hat das eine Bestimmung? Mit den Ketten ist die gleiche Frage. Ketten bringen doch auch was auf die Waage.
Allerdings kannst D mit Ketten auch über viele höhere Hindernisse fahren.

Was ist denn für ein Motortreiber verbaut?


MfG

Hi Moppi.
Der Innenraum der Oberwanne ist ungefähr 20x20 cm. Die ragt ein Stück über die Ketten raus...meine Angabe mit zwei Arduino Mega-Platinen war geschätzt-vermutlich passen auch vier liegend rein, hehe (schräg stehend dann nen dutzend).
Gesamtbreite (mit Ketten 21.5cm. Länge auch so, in etwa.

Das Gewicht rührt zum einen von den Ketten, die ich bewusst mit reichlich Infill gedruckt hatte, als auch dem Monsterakku. Der hat alleine knapp 280g. Nen kleinerer täts auch, aber ich mag längere Laufzeiten einfach (und er passt rein).
Aber es stimmt: das ist alles ziemlich bulletproof gedruckt (1.2mm Wanddicke), dafür allerdingt mit wenig Infill.

Als Motortreiber hab ich wieder so einen verbaut. Die Dinger haben sich bewährt-einziger Nachteil: wenn du PWM nutzen willst, brauchst du drei Pins pro Motor.

Und nö: das Design sollte einfach etwas anders aussehen als ne Kiste auf Rädern-diese Form-Idee kam mir eigentlich erst während ich dran modelliert hatte.
Da kam ich zuerst drauf, den Boden der Unterwanne (das sieht man nich wirklich, weil die Oberwanne zweifarbig gedruckt ist (das orange hätte nich gereicht), keilförmig zu machen. Und dann hab ich mir diese Ausbuchtung an den Seiten überlegt- ich finds einfach ganz nett so.
Ausserdem hat die recht glatte Aussenhaut den Vorteil, dass ich den Burschen später problemlos in den Rucksack stopfen kann.
Und natürlich: die Aerodynamik.:cool:

Was die Ketten angeht: der soll ins Freie. Da sehe ich gewisse Vorteile in Ketten, richtig.
Weniger die Kletterfähigkeit über Hindernisse, eher im Grip.
Die haben auch profilierte Glieder.
Wobei die nicht so super geländegängig sind (dazu müsste man sie vorn und hinten hoch ziehen, aber das würde auch zusätzliche Laufrollen bedeuten, und damit Störanfälligkeit).
Aber Türschwellen sollten kein Problem sein.

Gestern kam nunder noch fehlende US-Sensor für vorne.
Den HC-SRF05 wollt ich schon lange mal ausprobieren, also hab ich mal so einen genommen.
Läuft tadellos- man kann ihn bis auf eine Winzigkeit direkt gegen die HC-Sr04 austauschen, ohne am Code was zu ändern.

*Die Winzigkeit besteht darin, dass er nur zwei Befestigungslöcher hat, statt vieren, wie die Sr-04.
Auch der Abstand der Befestigungslöcher ist etwas anders- aber es handelt sich höchstens um nen knappen mm.
Um den nun in meiner gedruckten Sensor-Brille verbauen zu können, hab ich die beiden Schraublöcher einfach etwas aufgeweitet.
In die beiden leeren Löcher kleb ich später kurze Dummy-Schrauben, dann sieht das wieder gut aus...

Ausserdem hab ich ein Heck-Teil noch mal neu gedruckt (nix funktionswichtiges, eher Zierde, das Teil um Schalter und Ladebuchse herum), und mir einen Arbeitsstand gedruckt, das babyblaue Ding.
So kann ich den XPlorer aufbocken, und die Ketten können frei drehn- sehr praktisch beim programmieren.

Apropos Ketten: die sind etwas locker. Da ich keine Möglichkeit habe, sie zu spannen (gibt das Fahrwerk ohne grössere Umbauten auch nich her), werd ich mir wahrscheinlich einige Kettenglieder drucken, die 2/10mm kürzer sind. Das sollte innerhalb der Toleranz der Kettenräder sein, und man kann die Ketten ganz einfach spannen, indem man mehr oder weniger dieser kürzeren Glieder einsetzt.
Allerdings hab ich von dem blauen Filament nur noch nen Rest, mal gucken, woher ich das hatte, und ob es genau _dieses_ blau noch gibt.
Es ist das Selbe, mit dem auch die blauen Schriftzüge aufgedruckt sind.
Passt, wie ich finde, super zu dem Orange.

Und: ich hab die Ketten aussen noch mit schicken Blenden komplett verkleidet.
Das wollte ich sowieso noch machen (das orange Filament war nur alle, inzwischen ist Nachschub da), nicht nur, weil es besser aussieht, sondern die Blenden stabilisieren die Ketten seitlich zusätzlich, und verhindern, dass gröberer Dreck dazwischen gerät.
Hatte sich beim XP1 schon bewährt...


Anhang 34674
Anhang 34675
Anhang 34676
Anhang 34677

Aktuell sitze ich am Zeit-Management des Arduino Nano: einen Timer, der 20 Sekunden hochzählt, hab ich schon lange drin.
Der ist z.B. für die Akku-Überwachung zuständig, kann aber auch andere Aufgaben erledigen, die nur gelegentlich notwendig sind.
Sowas teil ich immer auf mehrere Sekundenticks auf.
Aber ich brauch, vor allem für die Regelung, auch kürzere Zyklen.
Da bastele ich grad dran....es hakelt noch ein bisschen, wird aber.

Hallo Sly,

Ich habe meine NEMA17 so gelagert, mit einem Sockel, in dem der Schlitten (in dem der Motor eingesetzt ist) ca. 1cm Spiel hat; unten in den Schlitten eine Mutter reingesetzt, von außen eine längere Schraube rein gedreht. Bei Schlitten und Sockel spielt Passgenauigkeit gar nicht mal eine so große Rolle, der Motor muss nur brauchbar an Position gehalten werden, das geht auch mit etwas Spiel. Die Möglichkeit, über die Kette selbst zu spannen, finde ich aber auch gut. Du kannst es ja machen. Kette zusammenziehen und ein kleineres Glied einsetzen - warum nicht!

Was ich auch interessant finde sind ein anderes Maß zwischen den Löchern der SR-04 und der SRF-05. Das hätte ich nicht gedacht. Auf Bildern sieht das identisch aus, möchte man meinen. Ist eigentlich doof, weil so kann man die Typen nicht einfach austauschen. Wobei zu hoffen bleibt, dass bei allen SR-04 das Maß bei den Bohrlöchern identisch ist, nicht dass es noch Unterschiede zwischen den Herstellern gibt; bei den SRF-05 natürlich auch. Die Löcher finde ich sowieso irgendwie zu klein. Normal passt überall eine 3mm-Schraube rein. Die SRF-05 sind die ersten Platinen, wo ich kleinere Schrauben nehmen musste (irgendwie 2.2mm oder 2.4mm).


MfG

Es ist wirklich minimal.
Man sieht ja auf den Bildern, wie dick meine Brillen sind, die Kapseln schauen nur noch ca. 3mm raus.
Und trotzdem hats gereicht, die Löcher ein bisschen aufzuweiten, von innen.
Ich denke, wenn man die Löcher etwas grösser im Durchmesser zeichnet (meine sind nur 1.8mm), dann geht das mit dem Austauschen schon.
Von den HC-Sr04 hab ich zwei verschiedene Ausführungen: die einen haben auf der Rückseite mindestens doppelt so viel Hühnerfutter als die anderen- beide Versionen passten einwandfrei.
Was auch ich nicht geschafft habe: die Brillen um die Kapseln ringsrum im gleichen Spaltmass zu zeichnen.
Der ursprüngliche Plan war, die noch enger um die Kaseln zu legen-das hat nicht geklappt.
Die Kapseln haben nämlich etwas abweichende Abstände, von Sensor zu Sensor.

Wegen den Schrauben: die Bohrungen sind ausgelegt für M 1.6. Diese greifen nicht in der Platine (du kannst die Schrauben durchstecken).
Auf der Rückseite hab ich dann passende Muttern benutzt, und die, nach der Montage, mit nem winzigen Tröpfchen Sekundenkleber auf der Platine gesichert.
So kann ich die Sensoren mit nem passenden Imbusschlüsel ohne weiteres abschrauben.


Wegen den Kettenspannern: die Motoren etwas zu verschieben, hatte ich mir auch überlegt- die sind ja nur "saugend" in die Kettengehäuse eingelegt, und dann da verschraubt. Ein paar Langlöcher für die Schrauben, und es würde gehn.
Aber: die Kettenräder sind bei der Konstruktion nicht fest mit den Motoren verbunden- soweit trau ich den Plastik-Achsen nicht.
Die sind eigentlich eher im gedruckten Gehäuse gelagert (damit die Kräfte, die von unten kommen, von den Gehäusen und nich vom Motor aufgefangen werden)- als Verbindung zwischen Motor und Rad gibts nur nen Vierkant-Mitnehmer.
Daher ist es nicht so einfach, die Motoren zu verschieben.
Minimal abweichende Kettenglieder sind da die einfachere Lösung, auch, wenn sich die Ketten später etwas einlaufen werden (wovon ich ausgehe, PLA neigt dazu, sich mit der Zeit zu setzen.

Im Grunde kann ich die Ketten auch so lassen- es funktioniert. Aber ich hab ein paar Erfahrungen mit Modellketten, und die sagen mir: es ist besser die richtige Spannung zu haben.

Heute gabs wieder was neues: ich hab noch nen Helligkeits-Sensor ins Heck gebaut (rechts war ja noch Platz, hehe).
Der dimmt nun die Bordbeleuchtung, in Anhängigkeit vom Umgebungslicht.
Jetzt nerven die hellen LED's nicht mehr, abends, in der ziemlich dunklen Bude, und sind am Tage trotzdem gut zu sehen.
Viel Zinnober hab ich da nich gemacht: ein Fotowiderstand und ein normaler, in Reihe, dazwischen nen Abgriff auf nen Analogeingang, fertig ist die Laube.
Der Sensor wird auch nur alle 20 Sekunden mal abgefragt, soo genau brauchen wir das auch wieder nich...und die schnellsten sind diese Fotowiderstände ohnehin nicht.

Die Motorregelung hab ich auch umgestrickt: statt, wie bisher, zeitgesteuert (es wurde einmal pro Sekunde nachgesehn, ob die tatsächlichen Drehzahlen gleich sind) läuft sie nun ereignisgesteuert: immer wenn eins der Odometer einen bestimmten Wert erreicht hat, wird, im Bedarfsfalle, nachgeregelt.
Das Ganze läuft nun auch andauernd: je länger das ausregeln dauert, desto mehr _wird_ geregelt.
Funktioniert inzwischen ganz gut.
Ich will noch versuchen, die Auflösung der Odometer zu erhöhen: momentan werden Zähl-Interrupts nur bei fallender Flanke ausgelöst. Wenn ich aber Änderung nutze, hab ich eine doppelt so Auflösung, und somit auch ne schnellere Regelung.

gefällt mir gut :-)

Freut mich, hehe.

Mir bisher auch....
Was mir aber gestern gar nicht gefallen wollte war eine kleine Probefahrt.
Erst ab PWM 200 (von 255) bewegte sich die Fuhre überhaupt, und dann reichte eine lausige Türschwelle, um den XPlorer 2 zu stoppen (Motoren abgewürgt).
Das geht ja mal gar nich....
Daher hab ich, kurzentschlossen, mal das Multimeter an den starken StepDown gehalten, der die Motoren versorgt, und: es stimmt. Der braucht 2V Differenz zwischen Ein-und Ausgang.
Wird es weniger, bricht der ein.
Ich hatte also nur bei rappelvollem Akku die 6V, auf die die Motoren ausgelegt sind.
Daher hab ich den Stepdown kurzerhand ausgebaut- die Motoren werden jetzt direkt aus dem Akku versorgt.
Dabei ist mir allerdings schonmal einer durchgebrannt (das war nich beim XP2, sondern bei irgendwas anderem mal)- nun hoffe ich, der hatte eh schon nen Treffer (was mich nich wundern würde, das sind Motoren der billigsten Bauart).

Erste Probefahrt vorhin (nur mal 2m gradeaus): wesentlich besser. Ich hab im Moment um die 7.6V am Akku und damit sind die Antriebe kaum wieder zu erkennen. Wenn sie das auf Dauer durchhalten, könnte das so bleiben, schätze ich.

Aber es gibt schon einen Plan C: stärkere Motoren.
Wenn ich 25mm-Motoren mit Inline-Getrieben verwende, die es auch mit Encodern gibt, müsste ich lediglich drei grössere Druckteile neu machen: die Innenteile der Kettenantriebe und die Wanne- halb so wild.
An der Wanne hätte ich sowieso eigentlich gern noch ne grössere Änderung, die könnt ich dann auch gleich mit umsetzen.
Ich denke, davon besorg ich mir mal zwei, und schaue mal, was die so drauf haben.

Da aber die Fuhre nun _erstmal_ läuft (so lange die Motörchen nich versterben), hat das keine Eile- raus kommt der XPlorer sowieso noch nicht so bald.

Gestern hab ich etwas am Kilometerzähler gebastelt: ich wollte ne Funktion haben, welche die gesamte Fahrstrecke in Metern berechnet, um vorgeben zu können: "fahr doch mal eben 20m weit" oder so.
Das funktioniert auch, nur sind der Roboter und ich uns noch nicht ganz einig, wie lang ein Meter wirklich ist (ich vermute, ich hab irgendwo nen logischen Fehler drin).


Ausserdem hab ich schon ein, zwei Stunden an der oberen Abdeckung gezeichnet, die wird -im Wesentlichen- vierteilig.
Ist aber noch nicht fertig, die muss noch weiter ausmodelliert werden, ehe ich da was drucken kann.

Du könntest in der Software eine Art Motorschutz integrieren. Entweder du misst den Strom und regelst zurück oder du begrenzt die PWM auf einen Maximalwert.
Eine dritte Variante wäre das du den PWM Wert dynamisch anpasst, damit du die Motoren nicht dauerhaft überlastest. Also z.B. wenn du stehst kannst du kurzzeitig die PWM auf Maximum stellen, wenn du aber für längere Zeit schnell fährst (PWM relativ hoch) wird die maximale PWM immer weiter verringert.

Das Projekt gefällt mir aber sehr gut.

MfG Hannes

Zitat:

---

Zitat von Rabenauge

Daher hab ich, kurzentschlossen, mal das Multimeter an den starken StepDown gehalten, der die Motoren versorgt, und: es stimmt. Der braucht 2V Differenz zwischen Ein-und Ausgang.
Wird es weniger, bricht der ein.

---

Daß man das vermuten kann, geht schon aus der Verwendung des Wortes "stark" hervor. Der braucht Luft, um Regeln zu können, daher die relativ hohe Dropoutspannung.

Zitat:

---

Daher hab ich den Stepdown kurzerhand ausgebaut- die Motoren werden jetzt direkt aus dem Akku versorgt.
Dabei ist mir allerdings schonmal einer durchgebrannt (das war nich beim XP2, sondern bei irgendwas anderem mal)- nun hoffe ich, der hatte eh schon nen Treffer (was mich nich wundern würde, das sind Motoren der billigsten Bauart).

---

Solange die Spannung nicht so hoch ist, daß in der Wicklung ein Funke überspringt, geht ein Elektromotor nicht an zu hoher Spannung kaputt. Nur so als Hinweise für einen Funken von 1mm Länge braucht man rund 1kV. Er stirbt entweder mechanisch z.B. durch zu hohe Drehzahl oder wahrscheinlicher den Hitzetod. Selbst wenn du deine Motore nur mit 3V betreibst, sie aber blockieren, werden sie nach einer Weile so heiß werden, daß sie durchbrennen. Dein Regler ist also eher ein Problem als eine Lösung. Er ist eine Heizung die 2V mal Gesamtstrom in Wärme umsetzt, Platz braucht und auch noch das Gewicht erhöht. Die Leistung, die dein Motor umsetzt, kannst du leicht mit der PWM unter Kontrolle halten. Einfach nie 100% Dutycycle einstellen.

Bei dir kommt noch etwas dazu, die Wahl der Treiber. Der L298 ist steinalt. Am Anfang des Datenblattes wird er zwar mit "LOW SATURATION VOLTAGE" beschrieben, das wurde aber vor 30 oder mehr Jahren geschrieben und das "LOW" gilt schon lange nicht mehr..

Anhang 34689

An der Brücke bleiben also im schlechtesten Fall 5V liegen. Da bleibt bei 6V Betriebsspannung nur noch 1V für den Motor übrig. Nun wird der schlechteste Fall nicht immer zutreffen, aber für den Betrieb an niedriger Spannung ist der L298 nicht wirklich gut. Man bräuchte rund 10V für 6V am Motor. Dabei wird dann 40% der Energie aus dem Akku in Wärme umgesetzt.

Heutzutage gibts es wesentlich besseres. Moderne Treiber mit FETs haben so Widerstände von 0,5Ω, das macht bei 1A ein halbes Volt aus. Aber auch bei denen braucht man 6,5V Betriebsspannung um am Motor 6V zu erhalten.

Zitat:

---

Aber es gibt schon einen Plan C: stärkere Motoren.

---

Das wird nicht wirklich was helfen. Stärkere Motoren brauchen entweder mehr Spannung oder mehr Strom. Mehr Strom erhöht dein Problem mit Dropout und Saturation Voltage. Am Ende schaltet der Treiber dann wegen Übertemperatur ab.

MfG Klebwax

ich hab mal für die TT Räder Schneeketten entwickelt.. :-)
Anhang 34691

Inka, wozu denn das ? :confused:
Schaut niedlich aus!

ja wozu sind denn schneeketten? :-)

Doch nicht mit den Rädern :p

die sind bei mir mal auf einem teppich immer durchgerutscht, war ein versuch wert. Aber vielleicht willst du ja mit deinem robby - (wie heisst der eignetlich?) auch mal raus? :-)

Nein, will ich nicht, danke! ;)
Der ist nur für drinnen und funktioniert hoffentlich, aber hier geht es um den Xplorer von Sly.
Draußen würde der sowieso überfahren...

MfG

Zitat:

---

Zitat von Moppi

aber hier geht es um den Xplorer von Sly.

---

ja, sorry Sly, war etwas OT :-)

Zitat:

---

Zitat von Moppi

Draußen würde der sowieso überfahren...

---

ja, hast recht, das fahren auf zwei rädern ist schon gefährlich :-)

@moppi - aber du hast deine beiträge zu deinem roboter auch ganz schön gestreut - suche bauteil, chassis, arduino selbst.... wo noch?

edit: KI noch!

Halb so wild- ich find die Schneeketten niedlich.
Sowas könnte mein Cayenne (1:10er Rallyauto, von Tamiya) mal brauchen....hab allerdings noch keine Ketten in passender Grösse gefunden, die standhalten würden.
Dazu ist der ein bisschen zu üppig motorisiert....

Ja, wie gesagt: ohne den Stepdown für die Motoren geht es _deutlich_ besser.
Gut möglich, dass der eine dieser Motoren, der mir mal direkt an so nem Akku verstorben war, einfach schon ne Macke hatte.

Trotzdem hab ich mir mal zwei stärkere bestellt- so hab ich die Option auf Plan C.
Und wenn das nicht nötig ist: auch nicht schlimm.
Solche Getriebemotoren vertun sich bei mir schon irgendwann mal.

Die PWM entsprechend der Überspannung anzupassen, hatte ich mir auch schon überlegt- da ich die Akkuspannung sowieso alle 20 s mal auslese, wär das nicht weiter kompliziert.
Da könnte man zusätzlich noch die Odometer einbezehen, damit die Fuhre z.B auch bergauf die Geschwindigkeit hält.

Was mir momentan noch nicht wirklich gefällt, ist die Geradeausfahr-Regelung.
Im Prinzip funktioniert sie zwar, aber da ich relativ wenige Odo-Ticks pro Radumdrehung habe, und andererseits pro Umdrehung schon nen ganzes Stück gefahren wird, gibts immer wieder deutliche Bögen.
Die werden dann wieder ausgeglichen, aber so richtig gut funktioniert es nicht.
Mir ist klar, dass sich das im Gelände sowieso wieder relativiert, aber ich hätt es gerne zumindest unter "Laborbedingungen" noch besser.

Bin am überlegen, ob ich eine PID-Regelung einbauen sollte..mal gucken.

Zitat:

---

Zitat von inka

aber du hast deine beiträge zu deinem roboter auch ganz schön gestreut - suche bauteil, chassis, arduino selbst.... wo noch?

edit: KI noch!

---

Meinst Du das ist ein eigenständiges Roboter-Projekt? - Hmm...
Zu Anfang standen nur Fragen im Raum, wie ich was lösen könnte und was ich damit evtl. machen würde.
Das war kein geplantes Projekt, das hat sich so ergeben, weil jetzt eins zum andern kommt.
Ich baue die Sachen mal zusammen, ob das aber am Ende was wird, da will ich mich noch nicht festlegen.


MfG

Zitat:

---

Zitat von Moppi

Meinst Du das ist ein eigenständiges Roboter-Projekt? - Hmm...
Zu Anfang standen nur Fragen im Raum, wie ich was lösen könnte und was ich damit evtl. machen würde.

---

wenn man alle themen zusammenzählt:
- linienfolger mit KI
- druck der teile
- thema kommunikation roboter / bedieneinheit
- ...

besser jetzt noch als in 3 monaten - Du bist ja noch lange nicht fertig...

Sodele.
Es ist beschlossene Sache: der XPlorer2 kriegt _richtige_ Motoren rein.

Ich hab das Getue der Mickymaus-Antriebe satt.
Inzwischen rutschen gelegentlich sogar irgendwelche Zahnräder durch..die Dinger sind einfach nicht für solche Belastungen ausgelegt.
Vorgestern hatte ich beim Eckstein zwei solche bestellt.
Die waren heute da...und ich hab schonmal angefangen, die in Blender einzupassen.

Da ich keine Lust mehr auf grosse Experimente mit der Antriebsauslegung hab, hab ich eben noch zwei davon bestellt-allerdings die Ausfürung ohne Encoder.
Ich werd also wieder zwei davon in jeden Kettenantrieb bauen.
Mal ehrlich: für _den_ Preis.....
Damit müsste genug Leistung dasein, damit der XPlorer auch senkrecht rauf könnte.
Naja: mit 100% Steigung würd ich mich auch zufrieden geben (mein Modellpanzer schafft ca. 105%, kurz danach kippt er allerdings nach hinten, ist halt kein Crawler).

Die Tage such ich mal nen stärkeren Motortreiber, da müsste noch was rumliegen, wo ich 15A pro Kanal im Hinterkopf hab-das wäre ausreichend.

Inzwischen zeichne ich einige Teile der Unterwanne neu:

-die Wanne selbst wird geändert (an der alten gefielen mir einige Kleinigkeiten eh nicht, das wird also gleich ein Abwasch)
-die Innenteile der Ketttenantriebe müssen ummodelliert werden (das hab ich schon fast fertig, Stündchen mit Blender..)
-die Vierkant-Mitnehmerchen zwischen Motorwelle und Kettenrädern mussten leicht angepasst werden (die Abtriebswellen haben halt andere Abmessungen, auch schon erledigt, das waren 10 Minuten).

Den Rest kann ich unverändert übernehmen.
Angenehmer Nebeneffekt: durch diese andere Bauform ist es sogar möglich, die Unterwanne nahezu komplett nach aussen abzudichten.
Konkret: Wattiefe etwa 65mm.
Wenn man beim montieren der Ketten ein bisschen Dichtungspappe, Ölpapier oder einfach Silikon dazwischen packt, wird das sogar dauerhaft wasserdicht.
Mit nem bisschen Aufwand gehts bis etwa Unterkante der US-Sensoren, das wären sogar knapp 10 cm.
So viel Aufwand treibe ich nicht: es reicht, wenn er mal durch ne kleine Pfütze fahren kann.
Viel mehr macht, so ohne weiteres, auch keinen Sinn: der würde wahrscheinlich eher schwimmen.

Haken gibts, wie bei jeder guten Sache, natürlich auch einen: ich muss mir was einfallen lassen, wie ich Kühlluft ins Gehäuse bekomme. Aber der Deckel ist ja noch nicht fertig, das seh ich optimistisch.
Nen 30mm-Lüfter hab ich ja schon drin.

Zitat:

---

Inzwischen rutschen gelegentlich sogar irgendwelche Zahnräder durch..die Dinger sind einfach nicht für solche Belastungen ausgelegt.

---

Mein NVA-Panzer aus Kindertagen hatte ein Metallgetriebe mit doppelt so großem Bürstenmotor. Das hat gut funktioniert. Etwas können die TT-130 schon leisten, aber für Ketten? Du brauchst da gute Lager, dass alles leicht läuft, denke ich, denn Du nimmst doch nur einen Motor für jede Seite. Auf einer Seite der Kette hast Du den Motor, wie ist die Gegenseite gelagert, wo die Kette drüber läuft?

Zitat:

---

wie ich Kühlluft ins Gehäuse bekomme

---

Du kannst versuchen, einen größeren Kühlkörper ins Gehäuse zu montieren, so dass der halb drinnen und halb draussen sitzt. 3D-Druck ist doch ziemlich genau, so dass ein Kühlkörper gut passen würde, den Spalt dichtest Du dann ab, mit wasserbeständigem Klebstoff z.B. oder Silikon oder was ähnlichem. Ansonsten brauchst Du natürlich einen Lüfter und einen Luftschacht mit Grobfilter - nach oben vermutlich (mit versenkter Wanne und Ablauf, wegen Wasser und Dreck). Evtl. auch einen Radiallüfter, aber nicht die Billigteile, die nach paar Stunden einen Lagerschaden haben.


MfG

Den Panzer kenn ich.
Ja, die Pico-Antriebe waren Weltklasse: einfach, aber robust (die Robustheit liess später nach, als die anfingen, die unkaputtbaren, aufgepressten Metallzahnräder gegen welche aus Kunstoff auszutauschen).
Allerdings kann man diesen Panzer nich mit meinem Monster vergleichen, was wog denn der T-55...vielleicht 500g.
Da war ja nicht mal die Batterie im Fahrzeug.
Die Pico-Motoren hab ich damals auch reihenweise verbastelt (von dem gabs mal bestimmt ein Dutzend Ausführungen, von 3V bis 12V, verschiedene Drehzahlen usw.
Der war robust, aber leistungsschwach.

Was die Ketten angeht: die laufen superleicht. Das ist nicht das Problem...auch die Lager sind es nicht denn: die Kettenräder werden in den Gehäusen gelagert. Die drücken überhaupt nicht auf die Wellen.
Mit den Wellen sind die nur durch aufgesteckte Vierkant-Mitnehmer verbunden. Das hat den Vorteil, dass sie seitlich etwas Spiel haben.
Aber da ist eben das Gewicht der Fuhre, was ja recht schnell beschleunigt und abgebremst werden muss.

Ich werf das den Antrieben nicht vor: in leichteren Geräten wie deinem oder dem bekannten Arduino-Car werden die schon nen guten Job machen.
Grosse und schwere Fahrzeuge brauchen halt auch entsprechende Antriebe.
Für die TT-Motoren hab ich da schon ne Verwendung im Hinterkopf....

Was die Kühlung angeht: ich hab ja schon nen Lüfter im Heck.
Aber es war so gedacht, dass der von aussen Luft ansaugt, und ins Gehäuse drückt- mt den TT-Antrieben waren in den Kettenhäusern so grosse Öffnungen, dass die dort problemlos raus gekonnt hätte- aus naheliegenden Gründen (Dreck nicht rein saugen) hätte ichd as so rum gemacht.
Nur: die neuen Kettenhäuser werden nahezu völlig dicht sein, da funktioniert das so nicht.
Ich muss also dran denken, wenn ich den Deckel weiter konstruiere, da vorn einen oder zwei Lufteinlässe vorzusehen, denn ich werd einige Heizungen drin haben:
-bisschen Wärme produzieren die Step-Down-Regler
-die Motortreiberplatine auch
-der Raspi
-eventuell (eher nicht, glaub kaum dass die nennenswert belastet werden) auch die Motoren.

Da ich keinen geschlossenen Zwischenboden hab (der ist ja nur eine Art Gitter, damit alle Kabel bequem von oben nach unten zu verlegen sind), wird die erwärmte Luft von unten natürlich aufsteigen- und oben dann vom "Durchzug", den der Lüfter macht, rausgeschafft.
Das müsste klappen.

Und ja: 3D-Druck ist "ziemlich" genau: meine Motoren passen, wie geplant, saugend in ihre Aussparungen. Keinerlei Spiel, aber sie gehn mit sanftem Druck rein.
Das wollte ich so haben: normal werden die lediglich am vorderen Ende mit zwei M3-Schrauben befestigt. An ner Metallplatte reicht das natürlich, aber an Kunstoff- so werden sie vom Gehäuse selber noch mit gehalten.

Hab eben den ersten Prototypen der neuen Kettengehäuse vom Drucker genommen: einige kleine Änderungen noch (wenn ich die Teile schon neu mache, kann ich sie auch noch weiter verbessern) und dann passt das.
Anhang 34706
Hier siehst du, wie das mit den Mitnehmern läuft_ der Vierkant greift nachher ins Kettenrad und nimmt es mit.
Das Rad selber wird in dem orangen "Ring" geführt- von aussen später hat das Gegenstück des Kettengehäuses ebenfalls ne Führung.
Anhang 34707
Hier die beiden Motoren, die ich schon da hab (drum haben die auch beide Encoder, die ohne kommen wahrscheinlich morgen).
Anhang 34708

Ja- bei einem der Motoren fehlt noch ne Montageschraube....der sitzt ja nur mal Probe.

Gefällt mir von der Sache her. Aber ich frage mich, ob es da nicht (bei mehr Gesamtgewicht) zu unerwünschter Reibung zwischen den PLA-Teilen kommt.


MfG

So schlecht eignet sich PLA gar nicht mal als Gleitlager, das weiss ich schon lange.
Voraussetzung: es darf dabei nicht warm werden (dann wird das Zeug weich und verschweisst sich).
Da ich aber zum einen keine hohen Raddrehzahlen hab (die Getriebemotoren sind mit 170U/min angegeben), und zum anderen die "Lager" nen Durchmesser von ungefähr 40mm haben, verteilt sich die Reibung auf ne ziemlich grosse Fläche.
Das wird funktionieren, kannste glauben....

Wenn da durch Abrieb dann mit der Zeit etwas Verschleiss auftritt, ist das nicht schlimm: das Fahrwerk ist bewusst ziemlich fehlertolerant konstruiert, und man kann ja verschlissene Teile recht einfach nachdrucken.

Ausserdem: nur wenn man die Ketten wirklich stramm macht, liegt das gesamte Gewicht auf den Rädern und Ketten. Durch die geschlossene Bauweise der Antriebe kann man aber die Ketten etwas lockerer lassen, und dann verteilt sich das Gewicht auf die gesamte Unterseite.
Dann ist das gar nix mehr.

Sodele- heut hab ich mal wieder bisschen was gemacht.
Zum einen die oben gezeigten Mitnehmer für die Kettenräder: die fliegen raus.
Der Grund: die leiern jetzt schon auf den Wellen aus- die Kräfte der starken Getriebe werden dafür zu hoch.
Da es nur die eine Abflachung auf der Welle gibt, reicht das nicht- und ich will die Wellen nicht auf der anderen Seite auch flach schleifen.
Also Plan B:
es kommen einfach Stellringe auf die Wellen, aus Metall. In die kommen, statt den darin verschwindenden Madenschrauben, M3-Schrauben aus Stahl, und die Kettenräder bekommen ne Aussparung. Somit wird diese Schraube dann als Mitnehmer fungieren.
Das sollte halten.
Das erste modifizierte Kettenrad ist grade am Drucken, wenn es passt wie erwartet, dann druck ich morgen die restlichen.

Dann muss innen in die Wanne ein kleiner Verstärkungsrahmen (in den später M3-Muttern eingeklebt oder mitm 3D-Stift einge"druckt" werden), um den Akkudeckel zu befestigen. Dort hab ich nur ne Dicke von 1.5mm- darum diese kleine Umständlichkeit.
M3-Schrauben in so dünnes PLA- das würde nicht halten.
Dicker kann ich den Wannenboden nicht machen, weil die Motoren jetzt in die Wanne ragen- das war bei den vorherigen nicht so- die steckten ja komplett zwischen den Ketten. Und ich will die vorherige Bodenfreiheit unbedingt beibehalten-viel isses eh nicht.

Es wird insgesamt deutlich enger, unten drin- was solls.

Inzwischen ging es -ein bisschen- weiter:
Die neue Unterwanne (äusserlich von der alten nicht zu unterscheiden, abgesehen vom Akku-Deckel im Boden) ist fertig.
Auch die ganzen Aufnahmen und Halterungen, die da rein mussten, sind drin.
Weniger als in der alten: ich krieg den Motortreiber da unten nicht wirklich rein.

Inzwischen hab ich mich mal mit den Encodern beschäftigt: grosser Murks!
Auf den Platinen steht 3.3V- ich hab drei Stunden umgesteckt, gemessen und gerätselt- kein Mucks von den Hall-Sensoren.
Aus lauter Verzweiflung hab ich dann mal 5V drauf gegeben und -oh wunder- ein grünes Lichtlein geht an!
Und nun kann man die Dinger auch auslesen, funktioniert sehr gut.
Offenbar wussten die Chinesen selber nich genau, was sie da eigentlich basteln....trotzdem sind die Motoren, mit grademal 12€/Stück (incl. Inline-Getriebe und Encoder) ein Schnäppchen, verglichen mit den nahezu baugleichen Polulus.

Auf den angelöteten Platinen gibts jeweils zwei Sensoren- man kann also auch die Drehrichtung ermitteln- wozu man das brauchen könnte, wüsst ich, ehrlich gesagt nicht- schliesslich weiss man ja, was man ansteuert..aber egal: ich lese nur einen aus, und fertig.

Nun muss ich alles mal neu verkabeln, mal sehn, was dieses Wochenende noch wird...

Sodele.
Nach einer halben Bastel-Nacht ist der XP2 wieder im Geschäft.

Inzwischen hab ich die alte Software weitgehend angepasst- da musste einiges umgeschrieben werden, denn der jetztige Motortreiber arbeitet doch deutlich anders- aber sie laufen.
Beeindruckend kräftig- ich glaub, Probleme mit der Antriebsleistung werd ich nicht mehr haben.
Hab im Moment zwar keine Ketten dauf, aber die Kettenräder mit den Fingern anhalten, was bei den kleinen Motoren schon ging, wird nix mehr.

Bin allerdings noch nicht gefahren, vorher muss ich noch den Kilometerzähler anpassen, denn jetzt hab ich irgendwas um die 400 Odo-Ticks pro Radumdrehung, das waren vorher, glaub ich, nur ca. 40.
Vorher aber will ich mich noch mal genauer mit dem Motortreiber befassen, das Ding hab ich seit Jahren nich mehr benutzt...

bin schon auf das nächste video gespannt :-)

Hm, mal sehen, was wird die Woche- hier geht der Stress gerade los.
Riecht ziemlich nach Arbeit....

Aber der XPlorer ist wieder einsatzfähig-ab etwa PWM 150 fährt er schon sicher los (bergauf kann ich grad schlecht probieren).
Das ist deutlich weniger, als er mit den kleinen Motoren brauchte.

Ein kleines Problem gab es noch: diese Motortreiber-Platine braucht Pulldown-Widerstände an den PWM-Pins, sonst laufen die Motoren schon los, sobald der Strom eingeschaltet wird (während der Arduino auf ne Programmierung wartet)- nich so prall.
War aber einfach zu beheben..

Sodele.
Das Timing ist an verschiedenen Stellen angepasst worden, und die Regelung der Geradeausfahrt auch.
Beispielsweise musste ich das Entprell-Delay für die Odometer-Interrupts deutlich runter setzen (aktuell nur noch 5ms), da die Geber jetzt ja direkt auf den Motorachsen sitzen, und nicht mehr am Getriebeausgang.
Dadurch kommen die Interrupts viel schneller rein.

Funktioniert wieder ziemlich gut jetzt:

Anhang 34811

Dass da mitunter etwas unstimmige Werte auftauchen, liegt daran, dass die Regelung viel öfter eingreift, als die serielle Ausgabe geschrieben wird- letztere nämlich nur jede Sekunde einmal.
Das sind also nur Snapshots des momentanen Zustandes.

Aber, ich finde, so kann man das erstmal lassen.
Als nächstes werd ich mich mal um den Kilometerzähler kümmern, aber nich mehr heute.

Inzwischen hab ich sowas wie ein Fahrprogramm geschrieben.
Und...Probleme.

Im Grunde läuft es so ab: es wird ein Ultraschall-Ping nach vorne gesendet, dann aufs Echo gewartet, und anhand der ermittelten Entfernung festgelegt, was passieren soll: bei mehr als einem Meter Platz Volgas, wird es weniger, geht der XP2 etwas vom Gas, und wenn ein halber Meter unterschritten wird, wird gelenkt.
Eigentlich ganz simpel nur- funktioniert es nicht richtig.
Der Zustand "Vollgas" wurde nie erreicht.

Also hab ich mir mal angeschaut, was denn der vordere US-Sensor so liefert- und der kommt, aus irgendeinem Grund, nicht mehr über etwa 70cm hinaus.
Auch nicht, wenn 5m vor dem Roboter nichts ist.
Da ich absolut keine Erklärung für finden konnte (und irgendwelche Beeinflussungen durch andere Programmteile ausschliessen wollte), hab ich die Sensor-Abfrage-und Auswert-Routine mal in ein separates Programm gepackt, mit dem selben Ergebnis.

Interessant ist: betreib ich den Arduino Nano nur an USB, wird die mögliche Entfernung grösser.
Schalt ich auf Akkubetrieb um ist bei 70 cm Schluss.
Es kann aber kein Problem mit der Stromversorgung sein, denn im Akkubetrieb messe ich an der 5V-Schiene (die auch den US-Sensor versorgt) 4.97V, im USB-Betrieb nur knapp vier.
Es müsste also, wenn die Stromversorgung die Ursache wäre, umgedreht sein.

Nen Gegentest habe ich auch gemacht: der hintere US-Sensor erreicht lässig Werte oberhalb nem Meter.
Der funktioniert also offenbar...die Software für beide kann auch nicht die Ursache sein, denn die ist identisch.

Interessant auch: innerhalb der Distanz, die der vordere schafft, stimmen die Ergebnisse auch.
Aber während eben der hintere auch Entfernungen von mehr als 2m sicher messen kann, ist vorne bei knapp über 70 cm Schluss.

Ich hänge mal die Sensoren-Abfrage an, finde da zwar keinen Fehler (wie gesagt, der hintere wird ganz genauso abgefragt, funktioniert aber richtig), vielleicht findet doch jemand etwas, dass ich übersehen habe:

Code:

---

void pingVorne()// ******************** Vorn nach Hindernissen suchen **************************************
{
  delay(10);                            // ggf, alte Echos abklingen lassen
  digitalWrite(triggerVorne, LOW);
  delayMicroseconds(2);
  digitalWrite(triggerVorne, HIGH);    //Trigger Impuls 10 µs
  delayMicroseconds(10);
  digitalWrite(triggerVorne, LOW);      //Messung starten
  long laufZeit = pulseIn(echoVorne, HIGH,maxEntfernung); // Echo-Zeit messen, aber nicht zu lange warten
  float messung=laufZeit/ 58.2;        //Laufzeit in cm umrechnen
  entfernungVorne = ((entfernungVorneAlt*0.2)+(messung*0.8)); // Ergebnis glätten
  if(entfernungVorne==0)                // das gibts nicht, also muss die Bahn frei sein
    {
      entfernungVorne=120;
    }
  entfernungVorneAlt=entfernungVorne;
}

---

Die Variable maxEntfernung ist ne globale, die sorgt dafür, dass der Eingang nicht die volle Sekunde wartet, was bei pulseIn() normalerweise der Fall wäre.
Die kann auch nicht die Ursache sein (damit _könnte_ man die mögliche Entfernung einschränken)- aber der hintere benutzt die auch.

Der einzige Unterschied liegt in den Pins: der vordere hängt an A0 und A1, während der hintere digitale Pins nutzt.
Aber die sind natürlich ordentlich als Ein- bzw. Ausgang definiert.

Hat jemand ne Idee?

ich gehe davon aus, dass die

#define MAX_DISTANCE 100 //400

auf 400 eingestellt ist?

wie verhält sich der hintere sensor vorne?

Auch ganz beliebt: Der Sensor bekommt ein Echo vom Boden.
Abhilfe: Etwas nach oben richten.

Nein, die ist sogar deutlich höher.
Das Timeout wird nämlich in Mikrosekunden angegeben.
Wie gesagt: das kann nicht die Ursache sein, denn diese Variable benutzen beide.
Testweise hatte ich das auch mal ganz raus genommen...ohne Erfolg.

Interessante Idee, die Sensoren einfach mal zu vertauschen- da hätte man selbst drauf kommen können.
Grad eben versucht...
Wenn ich sie austausche, dann läufts umgedreht-also ist der Sensor, und nicht das Board, die Ursache *grummel
Was haben denn diese Dinger andauernd....?
Den hatte ich beim Umbau auf die anderen Motoren nicht mal abgesteckt, geschweigedenn ausgebaut.

@Holomino:
Das hab ich schon bedacht. Das Problem besteht auch, wenn ich das Teil quer durch nen grösseren Raum richte, von Ecke zu Ecke (was dann locker mehr als 5m sind).
Er läuft auch _niemals_ ins Timeout, sondern gibt immer brav irgendwas zwischen 68 und 75cm zurück- oder eben weniger (und das stimmt dann auch).

Zitat:

---

Zitat von Rabenauge

Interessante Idee, die Sensoren einfach mal zu vertauschen- da hätte man selbst drauf kommen können.
Grad eben versucht...
Wenn ich sie austausche, dann läufts umgedreht-also ist der Sensor, und nicht das Board, die Ursache *grummel
Was haben denn diese Dinger andauernd....?
Den hatte ich beim Umbau auf die anderen Motoren nicht mal abgesteckt, geschweigedenn ausgebaut.

---

die sensoren kosten fast nichts und sind auch schon mal defekt gleich wenn sie ankommen. ich weiss ja nicht wieviel du bestellt hast - für den fall der fälle - ich hab noch ein paar... so ein teil kann auch sein gewicht in gold wert sein, wenn man es mal eilig hat :-)