DFRobot, turtle mit Encoder Kit

International Deutsch
1

Hi, bin ein Arduino-Neuling.
Wir haben für das Studium eine Projektarbeit auf. Es gilt auf einem Tisch ca. 1m auf 2m 7 Pucks zu finden und in ein 15 cm breites tor zu schiessen.
Die Idee ist, den Roboter sequenziell den ganzen Tisch abfahren zu lassen und das Programm erst bei Detektion eines Pucks zu verlassen um uns Schussprogramm zu gelangen. Danach zurück in die Ausgangsposition und weiter im Programm.

Auf Anfrage beim Dozenten erhielt ich einen Bausatz für den turtle Robot von DFRobots.

Ich habe den Roboter zusammen gebaut, die beiden Motoren montiert, auf den motor Shield gehängt und auf den arduino Uno gesteckt.

Nach einigem Probieren hatte ich den Roboter soweit, dass ich ihn vorwärts und rückwärts für eine bestimmte Zeit fahren lassen kann.
Allerdings musste ich feststellen, dass die beiden Motoren weder gleichzeitig beginnen zu drehen, noch gleich schnell drehen.

Das macht ein genaues Abfahren und Kennen der Position und des Winkels unmöglich.

Also bin ich zum Dozenten zurück, welcher mir einen Universal-Encoder Kit aushändigte.
Diese Encoder Kits bestehen aus jeweils einem Metallring auf einem Gummihalter und einem Sensor.
Der Metallring hat 8 Pole.

Nach einigem Versuchen und umstecken der Leiterverbindungen kriege ich jetzt 8 Sektionen mit einer 1 aus den Sensoren.

Zuerst dachte ich mit Hilfe von Countern die Flanken zu messen und die Geschwindigkeit anzupassen. Das wird aber bis zur Anpassung Abweichungen auf die Position und den Winkel haben. Also überlegte ich mir, dass ich die Zeit zwischen den Flanken messen könnte und anpassen.

Jetzt hab ich einige Fragen an euch:

Als erstes sicher mal ist meine Idee umsetzbar?

Ich zweifle an der Genauigkeit der Manöver und der Messung aufgrund der schlechten Auflösung der Encoder und auch deren Montage (Die Sensoren werden mit Kabelbindern befestigt).

Habe ich das richtige Material?

Aufgrund einer Budgetlimite von 150€ benutze ich bisher das Gratismaterial des Dozenten.Der Arduino Uno und der MotorShield kosten zusammen 40€. Ich hätte ca. 35€ zur Verfügung um Motoren bzw. Encoder zu kaufen.
Sind bessere Motoren besser für die Aufgabe geeignet oder ändert das nur wenig?
Brauche ich einen Akku oder reicht ein Batterypack aus 10 Batterien? (<- 2 x 5 Batterien à 1.5V)
Worauf müsste ich achten und wie gross ist der Programmieraufwand?

Wie programmiere ich richtig?

Ich habe gerade erst meine ersten Schritte in der Programmierung eines Arduino gemacht. Ich habe während des Studiums sowohl c++ wie auch java kennengelernt. Wir haben Pins initialisiert und kleine Programme geschrieben.
Für das Projekt habe ich im Internet nach passenden Befehlen gesucht.
Ich versuche viele Kommentare zu setzen um den Überblick zu behalten.
Gibt es in der Struktur etwas zu beachten?

Habt ihr Tipps zur Lösung meiner Aufgabe für das Schulprojekt?

Vielen Dank im voraus,

Michiaelius

2

Studierst Du Mechatronik, IT, BWL oder Manager? Das Verhalten des Dozenten ist schon etwas undurchsichtig :wink:

Die zwei größten Probleme, die ich sehe, sind das Finden der Pucks und des Tors. Wie soll das funktionieren? Was meint euer Dozent dazu?
Für die Motorsteuerung braucht man eigentlich keine hochauflösenden Encoder, wenn man die Richtung zu den Zielen als Anhaltspunkt hat. Zudem kann Schlupf der Räder die Encoderwerte ungenau bis unbrauchbar machen. Nur wenn die Pucks durch Berührung gefunden werden müssen, muß der Roboter auch das ganze Spielfeld systematisch abfahren können. Erst wenn man das alles weiß, kann man die Anforderungen an die Encoder richtig spezifizieren.

Danach kommt das Manövrieren und Schießen der Pucks. Wie soll das funktionieren?

Zum Betrieb würde ich Akkus nehmen (LiPo?), zum Probieren ggf. den Roboter an die Leine legen und per Kabel kommunizieren und versorgen. Sonst muß man ggf. länger aufs Aufladen warten als man das Projekt testen kann.

3

Hallo

schau ma hier

4

Hi

Was kann denn Alles verwendet werden?
Als Zielhilfe würde sich eine Bake anbieten, würde hier eine IR-LED leuchten oder senden lassen, Die zum Zielen angepeilt werden muß.

Natürlich kannst Du mit High-End-Motoren ein besseres Ergebnis erzielen - worin besteht aber eigentlich hier Deine Aufgabe?
Wenn's um Wiederholgenauigkeit geht und Geschwindigkeit eine (weit) untergeordnete Rolle spielt: 28BYJ-48
Billig, fast im Dutzend zu bekommen wenn man nicht rechtzeitig Nein sagt.

Bei Deinen Encodern kannst Du die Zeit zwischen den Flanken messen und die Räder auf einander abstimmen - dann fährt das Ding auch geradeaus, sofern die Räder gleiche Größe aufweisen :wink:

Puck suchen - jo, Das könnte interessant werden.
Wie groß ist der Puck?
Könnte man per US knapp über der Tischoberfläche danach suchen?

Wie erkennst Du, daß für Deinen Puck der Weg zum Tor frei ist?
Ist ja blöd, wenn Du den dritten (von sieben) Pucks durch die Gegend zimmerst, Dieser aber an anderen Pucks abprallt und Du eigentlich noch sieben Pucks abzuräumen hast.

MfG

5

Hi, erstmal danke für die Antworten.

Ich studiere Projektmanagement in Mechatronik Trinational.

Bei der Umsetzung der Aufgabe haben wir freie Hand, nur die Budgetlimite von 150€, die (Ausgangs)Ausmasse (Roboter: 250 x250 x250; Puck: 1 cm höhe, 5cm Durchmesser) , 60 Sekunden als Zeitvorgabe und das Stackverbot.

Aufgrund der grossen Spielfläche und der gegebenen Position des Tores ist die Grundidee, den ganzen Tisch abzufahren und von der jeweiligen Position richtung Tor zu schiessen. Wir haben eine Schussmechanismus gebaut, welcher nach dem Prinzip einer Schere gebaut ist. Geöffnet soll dieser eine Breite von 25 cm aufweisen. Durch die V-Form werden bei der Vorwärtsbewegung die Pucks immer weiter Richtung Scharnierpunkt geschoben. Dort werden sie erkannt und der "Schnapper" schnappt mit Hilfe einer Zugfeder zu. Aufgezogen wird das ganze wieder durch einen Motor mit Getriebe. Der Einsatz einer Bake zur Torerkennung ist Plan B, falls die Programmierung zu aufwändig/kompliziert werden sollte/bzw. das System nicht trifft.

Danke für die Auskunft über den Akku, aufgrund der kurzen Einsatzdauer des Roboters und der Anschaffungskosten des Akkus habe ich bisher versucht, das System mit einem Batterypack von 5 in Reihe geschaltenen 1,5 V zu betreiben wie für den Bausatz vorgesehen. Später entschied ich mich dazu, gegen die Schwankung der Spannung ein identisches Batterypack parallel zu schalten. Ich werde mich ein wenig umschauen gehen was in Frage kommen würde.

Vielen Dank für den Link Rentner. Die Encoder sind nicht diesselben, aber ich werde mit dem Code ein wenig herumexperimentieren xD.

Bei der Bake haben wir an Ultraschallsensoren oder Infrarotsensoren gedacht, allerdings bräuchten wir mind. 3 Sensoren mit 60° Zwischenwinkel, um konstant ein Signal zu haben und das Programmieren dieser Sensoren mit Ausgabe der Position und des Winkels trauen wir uns nicht zu, falls die sequenzielle Programmierung nicht hinhaut werden wir dies aber probieren.
Eine andere Lösung zur Positionerkennung wären Distanzsensoren, wir haben aber bedenken, dass das Bord von 2 cm Höhe nicht erkannt werden könnte oder dass herumliegende Pucks erkannt werden.

6

Das ist die Aufgabenstellung, leider gibts die nur in Französisch..

Projet_Mecatronique_Sujet_2017-2018.pdf (281 KB)

7

Da empfiehlt sich ja fast eine Kamera, um die Pucks, die Bande und das Tor zu erkennen, und festzustellen ob das Schußfeld zum Tor hin frei ist. Bei einem 32u4 eher keine gute Idee. Was für einen Controller hat der Roboter?

Habt ihr schon mal ausgerechnet, wie weit euer Roboter in 1 Minute überhaupt kommt, incl. Pucks sammeln, drehen und schießen?

8

wir wissen, dass der Roboter in einer Minute 18 m fahren muss und 6 mal anhält um zu schiessen was uns eine mittlere geschwindigkeit von 0.4 - 0.5 m/s vorgibt.

Habt ihr einen Beispielcode für die Angleichung der Geschwindigkeiten anhand Zeitmessung der Flanken?

9

Welches Bewegungsmuster liegt der Berechnung zugrunde?

Wollt ihr solange mäandern bis ein Puck eingefangen ist, dann zum Tor drehen, schießen, zurückdrehen und weitersuchen? Und dabei für jede Teilstrecke auf 0,5m/s beschleunigen und wieder bremsen? Das erscheint mir ganz schön sportlich!

Beispielcode für PID Regler mit Encoder gibt es zuhauf, und die Geschwindigkeit ist umgekehrt proportional zum Abstand der Flanken (v=const/dt). Einstellen müßt ihr den Regler selbst, so daß sich der Roboter wie gewünscht bewegt. Zum systematischen Abgrasen des Spielfelds dürfte der schwierigste Teil werden, den Roboter keine Schlangenlinien fahren zu lassen, und ihn nach einem Schuß wieder in die vorherige Position und Richtung zu bringen.

10

Schafft denn das Ding die 0.5m/s überhaupt?
Ich kenn diese Antriebe eher vom wegschauen, die sehn mir nicht besonders tauglich aus....mein NiboBee schafft die 0.5m/ geradeso, mit Regelung für Geradeausfahrt (beide einfach Vollgas klappt nicht, die werden nie genau gleich laufen).

Auf Verdacht die Gegend abgrasen machen allenfalls Anfänger- eine Erkennung der Pucks auf eine gewisse Entfernung muss her...ist nicht viel aufwendiger, als diese Pucks dann in der "Schere" zu erkennen.
Ultraschall wird-eher nicht- funktionieren, aber mit nem Sharp GPYirgendwas sollte das ziemlich gut gehn. Die Dinger schaffen, je nach Modell, Reichweiten >1m.
Damit fährt man dann einfach mal grob in die Mitte des Feldes, dreht sich mal im Kreis und guckt, wo denn da was liegt. So kann man einen Fahrweg berechnen, der idealerweise gleich mehrere Pucks aufsammelt.

Die Schussfunktion ist eher albern: lass die Pucks mal einfach schlecht rutschen, dann wird das Pillepalle.
Zudem bremst die zuschnappende Schere schon wieder...
Idealerweise sowas wie ein Räumschild bauen: möglichst viele Pucks auf einmal zusammenschieben, und ab damit, ins Tor.
Das ist bei weitem effizienter, weil es weder Fehlschüsse gibt, noch andere Pucks im Weg liegen können: die werden gleich mitgenommen.

Zwar kann man durchaus eine vernünftige Odometrie bauen, die genau genug ist, aber nich mit dem billigsten vom billigen.
Beispielsweise könnte man hier einen Maus-Sensor einsetzen. Zusammen mit den Encodern, die ja sowieso da sind, sollte das schon ganz brauchbar werden. Maussensoren sind recht einfach zu handhaben, wenn man nicht zu viel Abstand zum Boden hat (bis etwa 2mm funktioniert das super, danach muss man an die Optik ran, da war ich damals dann gescheitert).
Ich hätte die Spielerei mit den Encodern gelassen, und stattdessen ins Getriebe Lichtschranken eingebaut, und zwar nicht erst an der Radachse, sondern eine oder zwei Wellen früher. Damit gehts dann auch schon viel genauer.
Der NiboBee hat das so serienmässig, und kam auf eine Abweichung von 0.5cm/m Fahrweg, damit kann man schon was anfangen. Genauer wirds mit so einfachen Mitteln nur, wenn man das Ganze irgendwie "nullen" kann-z.B. mit einer fest und präzise anfahrbaren Position, weil sich die Fehler der Odometrie aufaddieren.