XPlorer 2

[Rabenauge]

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 (https://www.thingiverse.com/thing:2527319) ü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 (https://www.adafruit.com/product/3777) 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?

[Rabenauge]

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:
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.

[Klebwax]

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

[Rabenauge]

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.

[Moppi]

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

[Rabenauge]

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 (https://www.roboter-bausatz.de/143/l298n-motortreiber-mit-doppelter-h-bruecke) 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.

[Rabenauge]

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...


34674
34675
34676
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.

[Moppi]

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

[Rabenauge]

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.

[Rabenauge]

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.

[inka]

gefällt mir gut :-)

[Rabenauge]

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.

[021aet04]

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

[Klebwax]

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.


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..

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.


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

[inka]

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

[Moppi]

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

[inka]

ja wozu sind denn schneeketten? :-)

[Moppi]

Doch nicht mit den Rädern :p

[inka]

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? :-)

[Moppi]

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

[inka]

aber hier geht es um den Xplorer von Sly.
ja, sorry Sly, war etwas OT :-)



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!

[Rabenauge]

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.

[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!

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

[inka]

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...

[Rabenauge]

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 (https://eckstein-shop.de/V-TEC-Metal-Getriebemotor-25D-mit-Encoder-6V-177-U-min) 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.

[Moppi]

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?


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

[Rabenauge]

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.
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.
34707
Hier die beiden Motoren, die ich schon da hab (drum haben die auch beide Encoder, die ohne kommen wahrscheinlich morgen).
34708

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

[Moppi]

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

[Rabenauge]

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.

[Rabenauge]

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.

[Rabenauge]

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...

[Rabenauge]

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...

[inka]

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

[Rabenauge]

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..

[Rabenauge]

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:

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.

[Rabenauge]

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:


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?

[inka]

ich gehe davon aus, dass die

#define MAX_DISTANCE 100 //400

auf 400 eingestellt ist?

wie verhält sich der hintere sensor vorne?

[Holomino]

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

[Rabenauge]

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).

[inka]

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 :-)

[Rabenauge]

Das ist kein 04er, sondern der 05er.
Die kosten ein bisschen mehr...

Inzwischen hab ich mal weiter experimentiert:
Sensor ausgebaut, und an nen Uno gestöpselt:
Mit dem Testprogramm (das enthält nur die Definitionen und die Sensor-Ansteuerung, direkt aus dem XP2-Code rüberkopiert, weiter nix)- funktioniert!
Vorausgesetzt, ich stelle das Timeout auf mindestens 150ms.
Bei Werten darunter liefert er gar nix.

Bau ich ihn wieder ein- gehts nicht.
Dabei benutze ich in beiden Fällen sogar das gleiche Anschlusskabel.
Die gedruckte Sensorbrille kann eigentlich auch nicht die Ursache sein, denn die müsste ja dann deutlich kürzere Distanzen zurückgeben (falls die beiden Sensorkapseln irgenwdie akustisch kurzgeschlossen würden).
Aber bis etwas oberhalb 60 cm funktioniert die Messung _zuverlässig_.

Ich bin halbwegs ratlos...

[inka]

Bau ich ihn wieder ein- gehts nicht. Dabei benutze ich in beiden Fällen sogar das gleiche Anschlusskabel.
Die gedruckte Sensorbrille kann eigentlich auch nicht die Ursache sein, denn die müsste ja dann deutlich kürzere Distanzen zurückgeben (falls die beiden Sensorkapseln irgenwdie akustisch kurzgeschlossen würden). Aber bis etwas oberhalb 60 cm funktioniert die Messung _zuverlässig_.

dann weiss ich auch nicht, irgendwie muss es aber schon mit der jeweiligen einbausituation zusammenhängen...
Was ich mich frage - nicht nur bei deinem xplorer, sondern auch beim Moppi's chassis - braucht man wirklich zwei (oder sogar vier!) abstand sensoren? Eigentlich bin ich bisher immer mit einem - in hauptfahrrichtung - hingekommen, zur not kann sich das ding ja drehen, oder?
Frage: wie sieht denn die "brille" für den US-sensor aus?

[Defiant]

Huh? Ich hab zwei Ultraschallsensoren vorne, einen hinten und ein Lidar und fühle mich damit immer noch "unterbewaffnet". Ich bin tatsächlich mit nur einem Sensor vorne in der Mitte gestartet mit dem Resultat, dass ich bei einer kombinierten Geradeaus/Drehbewegung regelmäßig irgendwo gegen gefahren bin: Der Sichtbereich des Sensors hat nicht ausgereicht Hindernisse zu erkennen die sich von vorne rechts/links nähern.

[Rabenauge]

Die Sensorbrille ist ein einfaches Druckteil, wo der halt vorne raus sieht, und von hinten angeschaubt wird.
Die wird dann einfach ins Gehäuse geklickt, und ist dadurch auch in Grenzen im Winkel verstellbar.
Das hab ich bewusst so gemacht, um nicht jedem Krempel, der auf dem Boden rum liegt, zu erfassen.
Ich häng mal nen Screenshot von Blender an, da hab ich sie doppelt platziert, so dass man sie von vorne und von hinten sieht (das untere ist die Seite, wo der Sensor rangeschraubt wird).
Die berührt den Sensor auch nur an seiner Platine (muss ja, irgendwie muss man ihn ja montieren), nicht jedoch an den Schallkapseln.

34813

Und ja: eigentlich braucht man etliche solche Sensoren, wenn man eine halbwegs (richtig gut geht es mit US alleine _gar nicht_) gute Hinderniserkennung realisieren will denn: die funktionieren nur unter Laborbedingungen recht gut.
Die erkennen aber eine Wand _nicht_, wenn du im spitzen Winkel drauf zu fährst- dann wird nämlich der Schall vom Sensor weg reflektiert.
Deswegen melden die, wenn sie nach vorne schauen, auch den Boden eben nicht als Hindernis.
Den erkennen die einfach nicht....
Bessere Resultate liefert so ein Ding, wenn man es bewegen kann (per Servo z.B.), aber das wollte ich wiederum nicht, weil ich beim XP2 Wert auf Robustheit lege.

Du hast schon ganz recht mit dem drehen: kann man so machen, aber:
Der XP2 soll ja später ferngesteuert werden. Also durchaus auch ausserhalb meiner Sicht- und da will ich halt wenigstens grob wissen, was hinter dem Roboter los ist.
Und nach vorne macht das halt auch Sinn, so lange die IR-Cut-Kamera noch nicht drauf ist.
Ausserdem: wie du schon sagtest..die Dinger kosten ja nix. Genug freie Pins hat der Nano auch (seit dem Umbau sogar noch zwei mehr, da der neue Motortreiber bloss vier Leitungen braucht, während der alte sechs hatte), warum also nicht.

[inka]

mit welchen geschwindigkeiten bist du da unterwegs?

[inka]

Die Sensorbrille ist ein einfaches Druckteil, wo der halt vorne raus sieht, und von hinten angeschaubt wird.
Die wird dann einfach ins Gehäuse geklickt, und ist dadurch auch in Grenzen im Winkel verstellbar.
Das hab ich bewusst so gemacht, um nicht jedem Krempel, der auf dem Boden rum liegt, zu erfassen.
Ich häng mal nen Screenshot von Blender an, da hab ich sie doppelt platziert, so dass man sie von vorne und von hinten sieht (das untere ist die Seite, wo der Sensor rangeschraubt wird).
Die berührt den Sensor auch nur an seiner Platine (muss ja, irgendwie muss man ihn ja montieren), nicht jedoch an den Schallkapseln.

sieht schon gut aus, richtige details erkennen kann ich da allerdings nicht - da sind so seltsamme dallen an den öffnungen für die schallkapseln, wozu sind die denn? Wäre es möglich eine *.stl oder *.obj datei anzuschauen?

[Rabenauge]

Der braucht Aussparungen auf der Rückseite, weil da auf den Platinen noch ein Quarz oder sowas sitzt.
Anders kann man die Platine nich vernünftig verschrauben- ich häng das Teil mal an.
Passt übrigens für die 04er und auch die 05er (mein 05er hat aber nur zwei Befestigungsbohrungen, in die anderen beiden Löcher hab ich halt Dummy-Schrauben geklebt).

[inka]

ein schönes teil :-)
auch die flächenübergänge an der aussenfläche, gefält mir....
Ich nehme an, das in der STL datei entspricht der einbaulage. Druckst du das auch so? Mit oder ohne stützstrukturen?

[Rabenauge]

Hm-weiss ich nicht mehr genau, wie ich den gedruckt hatte.
Aus dem Bauch raus würd ich sagen: auf der Innenseite liegend- dann braucht es ein bisschen Stütze, aber nich viel.
Als noch noch Cura benutzt hab (bis vor ner Woche etwa...) hatte ich dieses Auto-Orientation-Plugin drin, das kann die beste Lage zum Drucken ziemlich gut ausknobeln.
Allerdings kann mich Cura, bis auf weiteres, erstmal....:roll:

Ich drucke bei solchen Teilen meistens "auf Sicht"- Stützstrukturen sind mir, in gewissen Grenzen, Wurst (so viel kostet das bisschen Zeugs auch wieder nicht), daher achte ich lieber drauf, dass die später sichtbaren Flächen ordentlich aussehen werden nach dem Druck.
Bei den Lampengläsern war das ne ziemliche Herausforderung, weil ich den Fresnel-Linsen-Effekt (der sich bei höherer Schichtdicke und klarem Material sowieso ergibt) unbedingt in der passenden Richtung haben wollte.

Insgesamt aber hab ich beim XPlorer schon darauf geachtet, die Teile gleich so zu zeichnen, dass man möglichst wenige Stützen braucht.
Aber eben: bei so Kleinteilen....*pffff

Ja- die *-stl ist Einbaulage- ich dreh die in Blender immer so, so hab ich im 3D-Programm alles da, wo es hingehört.
Dadurch hab ich den XPlorer, komplett montiert, im Programm, und sehe recht gut, wo was passen wird- oder wo nicht.
Durch die feine Ebenen-Organisation kann man das ja alles fix ein- oder ausblenden.

[Rabenauge]

Nach einigem Hin-und Herüberlegen bin ich zu nem Entschluss gekommen:

Ich werde mir als nächstes (nebenbei zeichne ich trotzdem weiter Druckteile, immerhin fehlt oben noch einiges) eine Fernsteuerung bauen.
Später soll er ja, via RaspberryZero, sowieso ferngesteuert werden, aber ich mach mir da nichts vor: vom Pi hab ich noch zu wenig Ahnung, das wird sich ziehen....ich will ihn aber endlich mal ordentlich probefahren.
Autonom, draussen, mit zwei lausigen (und zudem fest montieren) Ultraschallsensoren wird das nix- das war von Anfang an klar.

Aber wenn ich mir schon eine baue, dann leg ich die gleich so aus, dass sie auch später für andere Roboter verwendet werden kann.
Die Funkstrecke soll per Bluetooth gemacht werden- zwei HC 05 (ich seh keinen Grund, als Empfänger nen 06er einzusetzen, nennenswert billiger sind die auch nich, können aber halt weniger) sind schon da. Die werd ich die Tage mal bespielen....

Aktuell hab ich im "Schaltplan" zwei analoge Joysticks drin (die ich vorerst nicht beide brauche, aber wennschon, will ich die auch später verwenden können), einen Drehencoder, und im Moment drei Taster (solche wie im Bild werd ich natürlich nicht verwenden, da kommt was anständiges rein).
Einige Pins sind noch frei....
Display ein 128x64 LCD (nen blaues, nicht, weil das nun das beste ist was man kriegen könnte, sondern weil ich diesen Retrolook einfach gut finde), das ermöglicht auch einige Telemetrie.
Stromversorgung wird ziemlich sicher eine simple Powerbank (womit wir schonmal 5V haben), allzu gross muss die bei Bluetooth gar nicht sein....möglicherweise brauche ich da noch nen Lastwiderstand, aber ich denke, das Display wird genug Strom ziehen.

Rechner wollte ich zuerst einen Arduino Pro Mini (5V) nehmen, hab das aber verworfen- momentan tendiere ich, wie im XP2, zum Nano.
Immernoch hübsch klein, aber der lässt sich im Gehäuse so einbauen, dass man von aussen an den USB-Port kommt.
Das ist einfach noch praktischer, und kostet auch kaum mehr...

Einer der beiden Joystick-Buttons liegt auf nem Interruptfähigen Pin, so könnte man den z.B. als Notaus verwenden (was bei einer Funkstrecke mit Bluetooth nur in Grenzen Sinn macht), und einer der beiden Ausgänge des Drehencoders auch....damit der ordentlich funktioniert.

Am liebsten hätte ich nen dreiachsigen Joystick (so ein Ding hab ich hier rumliegen, der steckt noch in ner alten Kamerasteuerung von Philips) benutzt-wenn das Ding nicht so monströs wäre. So ist das Display das Grösste an der Sache- und wenn ich nicht unbedingt _so eins_ wollte, würde ein winziges OLED (die 0.9"-Dinger haben genau die selbe Auflösung) den gleichen Zweck erfüllen-I2C wäre frei, man würde also sogar noch einige Pins mehr gewinnen. Und ablesbar sind die kleinen OLED auch draussen mindestens genauso gut.
Mit dem winzigen Display könnte man das Teil in Gamecontroller-Grösse bauen....aber ich _will_ das Grosse.
Ausschalter verbaue ich keinen-die eine der Powerbänke, die in Frage käme, hat nen Button zum abschalten, die kleineren haben nix-die zieh ich halt einfach raus.
Den Anschluss kann ich, wie bei meinem Lightpainting-Tool mit nem Stück, ins Gehäuse eingeschmiedeten USB-Kabel machen.

Was haltet ihr von dem Entwurf- besonders unter Berücksichtigung der Tatsache, dass diese Fernsteuerung möglichst universell sein soll?

34889

[Defiant]

Wegen der Fernsteuerung: Das du mit relativ wenig Aufwand einen gekauften Game-Controller per Bluetooth an einen rpi anbinden kannst, ist dir bewusst? Du könntest vor allem das Nebenprojekt Fernsteuerung vermeiden und dich auf dem Roboter an sich konzentrieren.

[Rabenauge]

Ja- weiss ich.
Wobei "wenig Aufwand"...ich hab so ein Ding hier- der funktioniert mitunter wochenlang _nicht_ (verbindet sich nicht), dann geht er mal wieder einige Monate (zugegeben, das ist so'n 20€-Ding), der funktioniert, wenn ers denn tut, mit Handy, Tablet und dem Laptop- im Moment aber nur mit dem Handy.

Der Pi soll aber später nich per Bluetooth, sondern per Wlan gesteuert werden-der Reichweite wegen.
Und: der Pi ist noch gar nicht an Bord.
Wie ich ja schon schrieb, soll das mein Einstiegsprojekt für Raspberry-Programmierung werden- das wird also dauern, bis die Fernsteuerung per Pi dann auch läuft.

Mit dieser Fernsteuerung hab ich zum einen die Möglichkeit, das Fahrwerk schonmal gründlich auszuprobieren (und zwar auch draussen), und zum anderen hatte ich schon öfter Basteleien, wo ich mir so eine Fernsteuerung gewünscht hätte. Da hab ich mir dann mit RC-Fernsteuerungen (sowas hab ich ausreichend rumliegen) mehr oder weniger beholfen.

Ich sehe einfach ein paar Vorteile in so einer Universal-Fernsteuerung: da alles über simple serielle Kommandos läuft (und zwar in beide Richtungen!) ist die sehr simpel zu programmieren, kann aber so ausgelegt werden, dass sie enorm viele Möglichkeiten bietet (die man bei einer RC-Fernsteuerung erst mit höherem Aufwand oder gar nicht haben kann). Beispielsweise lassen sich die Steuerkomandos (welche Eingabe was bewirkt) in den jeweiligen Robotern hinterlegen, so dass sie nach dem Pairing automatisch richtig eingestellt wird (Stickmode z.B.), man kann recht einfach beliebige Telemetriedaten übertragen, usw), man hat beliebig viele "Kanäle" zur Verfügung....und da Ganze für, na sagen wir mal 30 Mäuse (dafür kriegt man im RC-Bereich nicht viel vernünftiges).

Und da der XP2 im Slave-Modus arbeiten wird, brauch ich da nur ne vierpolige Buchse einbauen (seriell&Strom, mit Levelshifter), die ich später für die Kommunikation mit dem Pi gleich weiter benutzen kann.
Das soll ja auch seriell laufen, wenn ich es also clever genug anstelle, brauch ich später nicht mal die Firmware auf dem Nano ändern, sondern einfach nur das BT-Modul gegen den Pi austauschen.
Der muss dann nur die selben Kommandos schicken, wie die BT-Fernsteuerung....ich bau also am XPlorer nichts um, was ich nicht sowieso noch machen müsste.

Und hab später, als Bonus, noch diese Fernsteuerung für den XP3 (falls es den geben wird, aber einige Anzeichen am Horizont deuten drauf hin).
Für andere Basteleien auch....die ist also ne Langzeit-Investition.
Sicher für andere auch interessant...

[inka]

Für andere Basteleien auch....die ist also ne Langzeit-Investition.
Sicher für andere auch interessant...
auf jeden fall! Einen extra thread aufmachen?

[Klebwax]

Was haltet ihr von dem Entwurf- besonders unter Berücksichtigung der Tatsache, dass diese Fernsteuerung möglichst universell sein soll?

Ich beschreibe mal, was ich mir ausgedacht und zum Teil auch schon realisiert habe.

Als Funk benutze ich Wlan. Für die vielen bei mir vorhandenen Geräte ist es sowieso da. Sollte es im Freien nicht jeden Punkt erreichen, rüste ich mit einem Outdoor-AP zur Not nach.

Der Anschluß an mein LAN ermöglicht es, daß jeder Rechner mit dem mobilen Teil über das gleiche Medium kommunizieren kann. Das war für mich eine wichtige Überlegung. Die Protokolle sind zwar komplex, sie sind aber vorhanden und ich muß mich nicht wirklich darum kümmern. Auf einem Rechner habe ich Sockets, die kann ich aus C, Javascript, Python oder eigentlich jeder Sprache direkt ansprechen. Und sollte ich da mal Probleme haben, stehen bei mir ein halbes Dutzend Bücher im Regal. Praktisch ist das möglich geworden, seit es die ESP preiswert gibt. Auch dort muß ich mich nicht um die Komplexität von (W)Lan kümmern. Ich kann dort auf das bekannten Konzept der Sockets aufsetzen.

Was bietet das für Vorteile? Eine (W)Lan-Verbindung bietet prinzipiell die Möglichkeit, mehrere Kommunikationskanäle gleichzeitig und in jeder Richtung zu nutzen. Über den einen Socket kann ich Fernsteuerkommandos schicken, währen über einen anderen Socket z.B. Telemetriedaten an einen Server in meinem Netz gehen. Und der Programmieraufwand hält sich in Grenzen, einen Socket auszulesen und die Daten in einem für Gnuplot oder Excel passenden Format in eine Datei zu schreiben ist in wenigen Zeilen gescriptet.

Jeder Rechner kann die Funktion des "Fersteuersenders" übernehmen, interaktiv oder als Programm. So lässt sich eine automatische Steuerung realisieren. Zusammen mit der Möglichkeit des Rückkanals kann sie auch intelligent sein. Es kann während der Entwicklung auch die größere Rechenleistung eines PCs genutzt werden.

Nun fehlt nur noch ein "richtiger" Sender. Ich hab mir einen gebastelt.

34891

Das ist ein ESP mit einem Akku und einem Nunchuk als Steuerknüppel. Ich hab mal an anderer Stelle einen meiner Prototypen (https://www.roboternetz.de/community/threads/74645-Aufbau-eines-Roboters?p=658806&viewfull=1#post658806) gezeigt. Für die ersten Versuche hab ich dort den Nunchuk direkt angeschlossen, später kamen die Nunchukdaten über Wlan. Die nächste Platine des Senders wird dann in ein Gehäuse passen.

Wie ist das mit dem ESP realisiert? Im Prinzip kann man die SW, die von Hause drauf ist, verwenden. Die ganze Wlan Angelegenheit kann man, wie bei einem klassischen Modem, über AT-Kommandos auf der seriellen steuern. Ich bin kein großer Fan der AT-Schnittstelle. Ich habe daher eine Art allgemeines Wlan-Modem auf der lua-Firmware für den ESP programmiert. Die Kommunikation läuft dort bidirektional, die Parameter wie die IP-Adresse werden über die gleiche serielle eingestellt. So kommt es als Empfänger zum Einsatz. Für einen Sender, der keinen eigenen µC hat, kommt dann noch I2C für den Nunchuk dazu. Für aufwändigere Sendern, den Umbau eines alten RC-Senders z.B., kann man die die gleiche Firmware wie im Empfänger verwenden und einem µC die Arbeit überlassen.

Soweit mein Konzept. Die ESP sind so billig, billiger als eine RJ45 Buchse mit eingebautem Trafo, daß ich auch eigentlich stationäre Steuerung wie Rollläden so ansteuere. Die Firmware auf dem ESP bleibt (im Wesentlichen) immer die Gleiche. Sie passt auch in den Flash eines ESP-01. Wenn ich auf einer µC-Schaltung, die ich baue den Platz für die 8-Polige Stiftleiste übrig und einen Uart frei habe, layoute ich das mit rein. Später fällt einem möglicherweise eine Anwendung dazu ein oder man bestückt es nicht.

MfG Klebwax

P.S.

Wie ich grad sehe, hast du ähnliche Überlegungen angestellt.

[Rabenauge]

Cool.
Allerdings..ein bisschen mehr möchte ich haben (an Bedienelementen).
Etwas cooler aussehen darfs auch, hehe..die Idee kam mir bei James Bruton.
In der Playlist zum openDog taucht sowas gelegentlich auf....ich kann nur nicht begreifen, wieso der es nicht geschafft hat, da nen Akku einzubauen (das Gemurkse mit der Powerbank da unten drunter ist gruselig).
Der hat übrigens die grossen 3-achsigen Sticks verbaut, die ich etwas weiter oben erwähnte. Würd es sowas in deutlich kleiner (und bezahlbar) geben, wären die ne bessere Wahl. Aber die Monster sind mir zu klobig...

Mein Problem ist: WLAN ist mir zu..."gross" für den Moment. Ich hab schon einiges mit Wifi-Modulen (ESP..) gebaut, und das funktioniert auch, aber ich bin weit davon entfernt, zu behaupten: ich kann sowas.
Der XP(1) hatte einen NodeMCU als Funkempfänger.
Da hab ich mit Müh und Not (so schlimm wars auch wieder nicht, es hat funktioniert) ne Steuerung per Handy hinbekommen.
Bei der Telemetrie bin ich gescheitert....

Bluetooth ist ganz einfach: was du vorne rein schiebst, kommt hinten auch wieder raus.
Was du hinten rein schiebst, kommt vorne raus.
Ende der Geschichte.
Funktioniert so easy, wie z.B. ein Nextion-Display.
Und so ein Ding läuft bei mir inzwischen seit..hm, zwei Jahren bestimmt.
Krieg ich also zeitnah hin.

@Inka: können wir machen, klar!

[Klebwax]

Mein Problem ist: WLAN ist mir zu..."gross" für den Moment. Ich hab schon einiges mit Wifi-Modulen (ESP..) gebaut, und das funktioniert auch, aber ich bin weit davon entfernt, zu behaupten: ich kann sowas.

Mit Sockets. d.h. TCP/IP von PC zu PC hatte ich schon Erfahrungen. Da kann man auch schön Testen, z.B. mit Wireshark und netcat. Ob die Rechner über Ethernet oder Wlan am Netz hängen ist dabei gleichgültig. Mit Wlan selbst oder dem TCP-Stack auf einem PC habe ich nichts gemacht, es nur benutzt. Auf dem ESP habe ich mir eine Marscherleichterung gegönnt und die lua Firmware benutzt. Das Programmieren direkt auf dem SDK war mir zu aufwendig und eine Arduino Umgebung gabs da noch nicht. lua kannte ich schon (wobei so gradlinige Sachen fast so aussehen wie in anderen Sprachen auch) und das Wlan wird auch dort über Sockets angesprochen.

Wenn man Sockets einmal kapiert hat, kann man sie auf jedem vernetzten Gerät einsetzen, ob mit oder ohne Kabel. Man muß ja dabei nicht jeden Trick anwenden. Und ein Linuxrechner wie der PI kann das natürlich auch von Hause aus. Für ein größeres Teil würd ich möglicherweise auch auf den ESP verzichten und gleich mit dem PI über Wlan reden. Da muß dann im Sender noch nicht mal was verändert werden.

Der ESP hat ja nicht viel IO. In der lua Firmware kann man einen I2C Treiber haben, da wars leicht einen Nunchuk an zwei IOs zu schalten. Hat man aber im Sender einen eigenen µC und benutzt den ESP nur zum Senden, kann man alles anschließen, Joysticks, Schieberegler und Schalter jeder Größe und Form. Packt man noch ein Display ran, kann man Telemetriedaten direkt anzeigen. Da sie im Netz verfügbar sind, kann sie ein Rechner dort zusätzlich aufzeichnen. Die Flexibilität, die sich daraus ergibt, daß die Daten überall in meinem Netz verfügbar sind, war mir wichtig. Und zum Debuggen kann man immer etwas nehmen, das ein volles Display und mächtige Tools hat.

MfG Klebwax

[Rabenauge]

Ich bin da anspruchsvoll.
Der XP(1) hat natürlich ne eigene, selber gebaute App- wenn auch "nur" mit dem MIT App-Inventor zusammengebastelt, aber besser als diese ganzen Blinkys usw (bei denen weiss man nie, was die noch alles treiben).

Der XP2 soll auch ein grafisches Interface bekommen, und daher weiss ich: das _wird_ dauern!
Der Plan sieht vor, ein Programm (eben mit grafischer Oberfläche) direkt auf dem Pi laufen zu haben- und dann mittels VNC von _irgendeinem_ Endgerät darauf zuzugreifen.
Bis zu dem Punkt bin ich auch schon, ich komme per Handy, Tablet oder Laptop auf den Pi Desktop.

Bluetooth ist halt kinderleicht: einfach seriell senden, was immer man senden will-das funktioniert in beide Richtungen.
So kann man beliebige Kommandos hin- und beliebige Telemetriedaten zurückschicken.
Die Fernsteuerung wirft die einfach nur aufs Display, die muss nicht mal verstehen, was sie da bekommt.
Der Roboter braucht nur nen String zu senden "Akku: 4.5V"- und schon steht das _genauso_ auf dem Display- einfacher gehts nicht.
Fahrkommandos kann man genauso einfach senden:
"X=255", und dann den Wert aus dem String extrahieren.
Sowas hab ich in ner Woche zusammengebaut- bei der Pi-Anwendung werden das Monate...

Lua- neee..nix für mich....ich hab schon ne gewisse Abneigung gegen Python ( Java verursacht Krämpfe, hehe)...ich bin mir recht sicher, dass ich es auf dem Pi mit C versuchen werde.
Python wäre Plan B....

[Rabenauge]

Erfolgserlebnis:
eins der HC-05-Module hab ich heute in den XPlorer eingebaut- schön, mit nem Levelshifter, sicher ist sicher (man sagt, die vertragen auch auf der Logik die 5V problemlos)- aber spätestens für den RasPi brauch ich dann ja sowieso 3.3. Also kann ich den auch gleich einbauen...

Blöd dabei war: der Levelshifter hat vier Leitungen, und die sind so angeordnet, dass auch die EN-Leitung vom BT-Modul mit am Levelshifter angesteckt war.
Eingestellt hatte ich das Modul vorher mit nem Arduino UNO, einem sehr simplen Programm (im Grunde werden da nur Eingaben der seriellen Konsole zur zweiten seriellen Schnittstelle durchgereicht und umgedreht), schön in den Slave-Mode, Passwort und Name angepasst...und es lief auch.
Als ich den XPlorer einschalte, blinkte es langsam...
Es war dauernd im AT-Mode!
Hat bissel gedauert, bis ich drauf kam: der Levelshifter hat Pullups drauf!
Vorerst hab ich also kurzerhand die EN-Leitung gekappt, mir fiele jetzt nichts ein, wofür ich die sinnvoll im XPlorer benutzen könnte, daher gibts auch keinen Grund, die bis zu nem Pin weiter zu führen (mit dem ich dann zwischen AT- und BT-Modus umschalten könnte).

Inzwischen sitzt der zweite HC 05 am UNO auf dem Steckbrett- als Master konfiguriert, und beide verbinden sich direkt nach dem einschalten.
Klappt wunderbar....den XP2 hab ich inzwischen mehrere Runden durch die ganze Wohnung getragen, die Verbindung bricht nirgends ab (auch nich, wenn ne Betonwand dazwischen ist und geschlossene Türen)- super.
Da haben wir draussen ganz sicher mehr als 10m..es wird mir genügen.

Als nächstes werd ich jetzt mal ein bisschen Code schreiben, der irgendwelche "Nutzdaten" hin und herschickt. Mal gucken, ob das genauso einfach ist (die dann auch auszuwerten, vor allem)- aber ich denke schon.

Was die Fernsteuerung angeht: ich bin nochmal gründlich in mich gegangen und hab mich entschieden: es wird erstmal nur _einen_ zusätzlichen Button geben.
Der kriegt aber dafür nen interupt-fähigen Pin.
Den anderen Interruptpin brauch ich halt für den Drehencoder (der nicht verhandelbar ist, auch wenn ich den, um den XP2 probezufahren, nicht brauchen werd).
Die beiden analogen Sticks haben ja auch noch Buttons drin, beim Encoder weiss ich es grade nicht (der ist auf dem Weg zu mir, zusammen mit dem anderen Kram, aber eben noch nicht da), ich hab also sowieso drei Buttons.
Dazu XYLinks und XYRechts, und den Drehencoder- fürs Erste genug.
Man kann ja zusätzliche Funktionen trotzdem problemlos reallisieren, über ein Software-Menü, wenn nötig.
Oder den separaten Taster als "Shift-Taste" nutzen....
Auch ein Umbau auf mehr Buttons (falls sich dazu ne Notwendigkeit ergeben sollte) ist nachträglich kein Problem.

Warum abgespeckt: ich hab mich an die Krämpfe erinnert, die mir jedesmal bevorstehen, wenn ich meine MX-RC-Fernsteuerung mal wieder (ich benutz die nur noch selten) in die Hand nehme: ..zig Funktionen auf zwei Sticks und sechs Schaltern überall verteilt- kein Mensch merkt sich das über längere Zeit.
Jedes Mal, wenn ich die brauche, muss ich erst ne Stunde üben, die Fernsteuerung richtig zu bedienen *grusel
Weniger ist mehr.

Aber vielleicht baue ich noch einige programmierbare RGB-LED's ein, die ich dann als Statusanzeigen für "irgendwas" benutzen kann.
Hab da noch nen paar schöne, grosse in 8mm irgendwo rumschwirren....aber SMD (5050) auch massenhaft.

[inka]

gut, dass es so funktioniert :-)

bei den vorgängern des outdoor's roboters habe ich auch schon "datenübertragung" über BT realisiert, in anführungszeichen deshalb, weil es sich dabei in allen fällen um übertragung zwischen PC und dem MEGA gehandet hat, in den meisten fällen ging es um meldungen des roboters an den PC, also im seriellen monitor, aber auch ums fernbedienen - da allerdings vom smartphone aus.

Die versuche, den arduiono über BT zu programmieren sind - auch wenn es im netz viel darüber zum lesen gibt - allesamt gescheitert. Siehst Du da einen weg?

Eine andere frage: Hast Du Dir schon überlegt, wie Du verhindern willst, dass dein roboter in ein plötzlich auftauchendes loch (oder eine stufe z.b.) fällt?

[oberallgeier]

.. Hast Du Dir schon überlegt, wie Du verhindern willst, dass dein roboter in ein plötzlich auftauchendes loch (oder eine stufe z.b.) fällt?Da geb ich mal meinen Senf dazu.

Diese Frage nach dem "Treppenende" oder Absturz hatte ich mit einem Sensoraufbau der Familie "Blindenstock" gelöst. Dazu hier ein Posting zu den ersten (https://www.roboternetz.de/community/threads/33984-Abstandsmessung-%C3%A4hnlich-wie-IR-Schnittstelle-des-asuro?p=334010&viewfull=1#post334010) Überlegungen, hier die (erste funktionierende) Lösung (https://www.youtube.com/watch?v=s4DU7mS0p2w) mit/auf der 0,33-l-Dose, hier die Lösung mit/auf/in der 0,15-Liter-Dos (https://www.roboternetz.de/community/threads/36121-Autonom-in-kleinen-Dosen-R2_D03-Nachfolger-R3D01?p=478095&viewfull=1#post478095)e "minid015" und noch´n Video von nem Testlauf (https://www.youtube.com/watch?v=jgm9DhS7vS4) . . .

Der wesentliche Trick dabei ist, dass der von "oben" - etwa 100 mm über Fahrbahn-(Tisch-)Oberfläche schräg nach vorn-unten testende IR-Lichtstrahl durch ein Fenster drei Abschnitte definierte: Nahfeld bei etwa 50 mm..60 mm : alles drunter ist "unmittelbare Crashgefahr", Fernfeld ca > 200 mm : alles drüber ist Absturzgefahr - dazwischen ist im Rahmen diese Abstände freie Fahrt. Weitere Abstände könn(t)en gesondert erfasst werden.

[inka]

klar darfst du dich einmischen :-)

wenn ich es richtig verstehe, misst du mit drei kombinationen von IR sender und empfänger den abstand schräg zum boden. Wenn dieser sich abrupt ändert -- grösser == loch, kleiner == hindernis -- weichst du aus, stoppst oder was auch immer...

- gab es da keine störungen der kombinationen untereinander?
- liesse sich das auch mit ultraschall lösen? IR ist draussen wohl nicht die erste wahl, oder?

btw. ich habe deine colabüchse schon damals bewundert :-)

[Rabenauge]

@inka: nein, derartiges ist auch gar nicht vorgesehen.
Der XPlorer2 soll ja quasi nur ein FPV-Vehikel (allerdings nachttauglich) werden.

Die IR-Cut-Kamera, die ich habe, funktioniert auch im stockdunklen _ausreichend_ gut, dass man eine Treppe bemerken sollte, ehe man runter fällt.
Wenn s vom Platz her noch geht, will ich die auch schwenkbar (in X ) machen, so dass man etwas nach oben/unten schauen kann.
Idealerweise sogar stabilsiert (weiss ich noch nicht, ob das klappen wird).
Mehr kriegt der nicht.

[oberallgeier]

.. Wenn dieser sich abrupt ändert -- grösser == loch, kleiner == hindernis -- weichst du aus, stoppst oder was auch immer ..Sozusagen. Es gibt natürlich Regeln: Mittensensor spricht an => weiche nach rechts aus <=> wenn Sensor rechts NICHT auf freie Fahrt steht, weiche nach links aus und <=> wenn links auch besetzt ist, dann fahre mal ne viertel Kreisbogen zurück und versuchs nochmal. !!! Das Zurückstoßen ist kritisch - da gibts keinen Sensor, es wird einfach blind zurückgefahren.


..
- gab es da keine störungen der kombinationen untereinander? ..Ne. Eher wenig bis kaum, aber siehe unten.
Einmal senden die IR-Dioden in verschiedene Richtungen - entsprechend der IR-typischen Lichtkeule. ABER primär: Es werden die drei Sensoren nur umlaufend abgefragt. Wenn einer sensoriert haben die andern Pause. Das geht folgendermaßen. ALLE IR-Diode werden zur Abfrage gechirpt. Z.B. - es werden alle drei gleichzeitig gechirpt, aber nur ein IR-Empfänger wird abgefragt. Chirpen bzw. CIR - siehe hier (danke an Sterntaler (https://www.roboternetz.de/community/threads/33984-Abstandsmessung-%C3%A4hnlich-wie-IR-Schnittstelle-des-asuro?p=341243&viewfull=1#post341243)). Ich versuchs kurz zu erläutern: die IR-LED(s) werden per PWM betrieben.
Anm.: Soweit ich mich erinnere gaben PWMs über 128 manchmal ähnliche Ergebnisse wie PWM (256 minus aktueller dc - so ne Art komplementäre Signalform).

1ter Schritt: Die IR-LED sendet einen Burst (mehrere Pulse) mit duty cycle dc-64. Abfrage mit Empfänger: Antwort da oder nicht.
......o Empfänger sagt "da": Der Burst war zu "stark" = duty cycle zu lang => nächstes Mal Pulse schwächer=kürzer, also Ddc-alt)-32.
......o Nicht da: Der Burst war zu "schwach" = kurz => nächstes Mal Pulse stärker=länger, also (dc-alt)+32
2ter Schritt:
....a) PWM sendet dc-32 (dc-alt)-32. Abfrage mit Empfänger: Antwort da oder nicht.
......o Da: Der Puls war zu "stark" = lang => nächster Puls schwächer=kürzer, also dc-16.
......o Nicht da: Der Puls war zu "schwach" = kurz => nächster Puls mit dc-48.
....b) PWM sendet dc-96 (dc-alt)+32. Abfrage mit Empfänger: sinngemäß wie oben
3ter Schritt: hier wird sinngemäß weiter nach dem "zu schwachen" letzten Puls gesucht - aufwärts zu 128 oder abwärts zu PWM DC-1 - immer mitten zwischen zwei mögliche Werte. Somit ist man nach wenigen Schritten (hier nach sechs) bei der richtigen Pulslänge bis zum Erkennen des "richtigen" Messwertes - es sei denn, die Entfernung (Reichweite) ist über- oder unterschritten.

Fehler sind natürlich möglich. Wenn die Coladose sehr schräg an eine fallende Stufe fährt (oder Tischkante) kann sie runterfallen. Eher bei Vorwärtsfahrt aber auch z.B. wenn mal die Rückwärtskurve zur falschen Seite erfolgt . . . Aber bei Vorführungen fuhr miniD0


..
- liesse sich das auch mit ultraschall lösen? IR ist draussen wohl nicht die erste wahl, oder? ..Hmmm, der grundlegende Sensoraufbau sollte ähnlich funktionieren, aber dann wohl nur mit jeweils nur einem Sensor gleichzeitig und ner Zwangspause zwischen zwei Abfragen damit nicht Echos von fernen Gegenständen die Abfrage des jeweiligen Sensors stört . . . (mal so auf die Schnelle formuliert).
Klar, IR ist draussen nicht wirklich die erste Wahl weils verschmutzt. Die IR-Empfänger sind draussen auch verwendbar - es wird ja mit jeweils 36 kHz gepulst und man muss einige (bei meinen Empfängern mind 6) Pulse abwarten bis der Empfänger das Ergebnis "glaubt"


.. btw. .. colabüchse ..Danke. Mir gefällt das schicke Dingelchen auch. War ursprünglich entwickelt worden . . . aber das dürfte ja bekannt sein. Die kleine miniD0 - nur 0,15 Liter <=> D=54mm, H=80 - habe ich mitunter vorgestellt als sich selbst servierende Getränkebüchse. Sozusagen Prototyp zur Neuentwicklung der Getränkefirma.