Chassis zusammenbauen

[Moppi]

Warum ziitert der so?

Das ist normal, weil er so langsam fährt und alles noch ungeregelt ist. Eben "die ersten, abgestimmten Fahrversuche". Bedeutet nichts weiter, als dass ich mit Werten experimentiert habe, um den möglichst geradeaus fahren zu lassen. So wird mir erst mal klar, wie, wann, wo, was verändert werden kann, um die Geschwindigkeit zu verlangsamen, die Kraft zu erhöhen und sowas. Die Mindestgeschwindigkeit für diese Motoren ist viel zu hoch. Da hätte noch ein Zahnrad rein gekonnt, für mehr Drehmoment am Ende. Soll ja kein RC high speed car werden. Die gehen nämlich ganz schön ab diese Motörchen. So kann ich erkennen, wie das Verhalten ist. So zeigt sich auch, dass der ohne Nachzuregeln nie geradeaus fährt - je nach Belastung bei Schräge, Steigung usw. Würde der schneller fahren, könnte man nicht wirklich gut was erkennen, außer, dass der nach einer Seite abhaut und irgendwo gegenfährt.


MfG

[Rabenauge]

Irgendwo hatte ich mal was mit 200U/min gelesen....das ist für drinnen nicht schlecht, aber schnell nun auch wieder nicht.
Und: die Motoren _gibt_ es auch langsamer (ich glaub, 80U/min)- die mit den Metallgetrieben, von Adafruit.
Hab ich auch schon bei deutschen Händlern gesehen.....so um die 8€ das Stück- geht eigentlich vom Preis her.

Ohne Regelung wird dir der aber nie geradeaus laufen, das ist bei Bürstenmotoren nahezu unmöglich. Es kann sogar sein, dass die geschwindigkeitsabhängig reagieren: mal dreht der eine langsamer, mal der andere, bei gleicher Vorgabe.
Aber du hast ja die Lichtschranken- damit sollte das hin zu biegen sein.

Hatte ja beim XPlorer schon ganz gut funktioniert.
Mit den neuen Antrieben wird es vermutlich noch besser, weil die Odometer jetzt eine viel höhere Auflösung haben.

[Moppi]

Wenn Du überlegst, dass beim Fahren noch jede Menge Sensoren abzufragen sind, inklusive der Umgebung (Entfernung in 4 Richtungen) dann ist die Normalgeschwindigkeit eigentlich schon recht hoch, zu hoch, möchte ich sagen. Merkst Du dann, wenn Du versuchst, das Teil einzufangen, wenn es voll beschleunigt hat; da bist Du froh, wenn im halben Meter eine Wand oder ein Schrank kommt Was ich für angemessen halte, ist eine gedrosselte Geschwindigkeit. Aber da ist das letzte Wort noch nicht gesprochen, weil die Regelung dazu kommt ja noch und dann wird die Geschwindigkeit nach Impulslänge der Lichtschranken einstellbar sein.

mal dreht der eine langsamer, mal der andere, bei gleicher Vorgabe.

Interessant ist, dass man die Richtung bestimmen kann, indem man ein Rad kurz antippt. Dann fährt er z.B. im Kreis.


MfG

[Rabenauge]

Kickstart.
Alter Trick: immer mit reichlich Gas losfahren, danach runterregeln (wenn die Motoren wirklich laufen, weiss man ja von der Odometrie).
Mach ich z.B. bei manchen Settings mit dem 3D-Drucker auch: der Bauteil-Lüfter läuft bei 5% nich an, aber wenn man ihn mit 25% startet, kann man ihn problemlos auf die gewünschten 5% runterregeln.

Was die Timing-Probleme mit den Sensoren angeht: nachdenken.
Wozu muss ein hinterer Sensor abgefragt werden, wenn ich vorwärts fahre?
Bieg ich links ab, ist der rechte Sensor auch nicht so sehr nützlich...

Ich mach alles in Zeitscheiben: es läuft ein simpler Timer (nach dem Beispielprogramm BlinkWithoutDelay), der mir, beispielsweise, jede Sekunde einen Tick gibt. Diese Ticks werden gezählt, so lange, wie ich halt Aufgaben zu vergeben habe, und bei jeder Tick-Zahl wird eine Aufgabe erledigt.
Danach wird der Tick-Zähler zurückgesetzt, und der ganze Zyklus geht von vorne los.
Auf diese Weise schafft so ein kleiner Arduino erstaunlich viel.....es ist z.B. vollkommen unnötig, den Akku alle paar Millisekunden abzufragen, im XPlorer mache ich das nur alle 20 Sekunden, das genügt völlig, und ich hab 19 Sekunden, auf die ich andere Aufgaben verteilen kann.
Diesen Timer kann man beliebig langsam (oder schnell, der könnte auch Zehntelsekunden oder hundertstel) ticken lassen, so kann man z.B. auch sicherstellen, dass US-Sensoren sich nie gegenseitig in die Quere kommen (Echos abklingen lassen) usw.
Unglaublich einfach und unglaublich flexibel.
Da steht natürlich in Wirklichkeit noch bisschen Kleinkram drin (man sollte sicherstellen, dass der Arduino beim "Lies Akkustand-Tick" nicht 152x den Akku ausliest, usw. aber das Prinzip ist ganz einfach.
Natürlich: diese Schaltuhr ist nicht sonderlich präzise, aber die meisten Aufgaben müssen ja gar nicht auf die Millisekunde pünktlich erledigt werden.
Und: Geschichten wie die Odo-Zähler kann man damit nich handlen, dafür gibts Interrupts.

Es spricht auch nix dagegen, jeden US-Sensor nur zweimal pro Sekunde zu nutzen, so schnell wird die Rübe nicht.
Bisschen Reichweite haben die ja schon.
Und wenn du dann auch nur die einsetzt, die gerade sinnvoll sind, dann brauchen die gar nicht viel Zeit.
Das Timeout (und damit auch die Reichweite der Dinger) kann man auch noch so justieren, dass die Messung beispielsweise schon nach nem Meter beendet wird.
Das spart auch bisschen Zeit.

[Moppi]

Kickstart.
Was die Timing-Probleme mit den Sensoren angeht: nachdenken.
Wozu muss ein hinterer Sensor abgefragt werden, wenn ich vorwärts fahre?
Bieg ich links ab, ist der rechte Sensor auch nicht so sehr nützlich...

Es kommt ja in jeder Situation - und die ändert sich, beim Fahren, ständig - drauf an, welches Signal brauchbar ist. Berücksichtige Ecken / Kanten, abgestufte Wände, schräge und sich ändernde Wände (offene Türen) und enge Räume. Muss man dann sehen.


MfG

[Rabenauge]

Da bin ich mal gespannt, wie gut du es hinkriegen wirst.
Ne saubere Hindernisvermeidung (incl. Wegfindung, im Grunde gehts ja nicht darum, Hindernisse zu erkennen, eigentlich will man ja den Weg dazwischen finden) ist, meiner Meinung nach, alleine mit solchen Sensoren nicht möglich.
Aber ich lass mich gern eines besseren belehren.

[Moppi]

Ich denke, dass es hier weniger um Belehrungen, als um Gedankenaustausch gehen sollte.
Wie genau, was in welcher Situation funktionieren wird, weiß ich auch noch nicht. Mal sehen, was sich für Messungen ergeben und wie man die nutzen kann.

MfG

[Klebwax]

Ich mach alles in Zeitscheiben: es läuft ein simpler Timer (nach dem Beispielprogramm BlinkWithoutDelay), der mir, beispielsweise, jede Sekunde einen Tick gibt. Diese Ticks werden gezählt, so lange, wie ich halt Aufgaben zu vergeben habe, und bei jeder Tick-Zahl wird eine Aufgabe erledigt.
Danach wird der Tick-Zähler zurückgesetzt, und der ganze Zyklus geht von vorne los.

Ich benutze zwar keine Arduino, mach das aber nach dem gleichen Konzept. Ich hab einen Timerinterrupt so im Bereich von 5 bis 10ms. Da werden dann die Softwaretimer bedient. Als nächstes kommen die Taster und Drehencoder dran und werden entprellt. Und dann kommt der Tick-Zähler. Manchmal packe ich auch den ADC da mit rein. Bei Tick 1 Kanal setzen und ADC starten, bei 2 ist der typisch ohne Wartezeit fertig. Also auslesen, nächsten Kanal einstellen und starten.

MfG Klebwax

[Moppi]

Mein erster brauchbarer Versuch, eine Fahrt an einer Linie:





MfG

[inka]

sieht gut aus, auch wenn er bei einer geraden linie doch ein wenig wackelt...

Den zweck dieser breiten linie kann ich irgendwo immer noch nicht nachvollziehen. Wenn ich mir vorstelle Du möchtest so etwas



als testparcour aufbauen. Bei der breiten linie geht das doch gar nicht vernünftig. Das auf dem foto habe ich einfach mit einem schwarzen elektro isolierband draufgeklebt... Drucken? geht meiner meinung auch nur schwer. Und der roboter findet auch eine schmale linie, wenn er quer drauffährt. Also wo sind die vorteile?