Liste der Anhänge anzeigen (Anzahl: 1)
Hallo Sternthaler,
die long Werte hat ich mir eigentlich für so Spiralfahrten überlegt, wo mein
Sauroboter Robertina den Boden z.B. in Spiralen abfährt.
Habe mich etwas ernsthafter mit den Encoderwerten beschäftigt.
Da das Programm aus Asuro Band II recht hohe Maximal-Werte (600-850) ausgab, bin ich dann irgendwie/wann daraufgekommen, dass im Gegensatz zu Odometry/ie(data) die neuen Encoderfunktionen (EncoderInit(),IsrEnc, ...) mit eiem 8-bit ADC arbeiten. (in irgendwelchen Doku's hab ich nichts dazu gefunden, hab's dann an dem ADLAR beim ADMUX erkannt und daran, dass nur ADCH dem Encoder/tmp - Wert zugewiesen wird (in IsrEnc().
Hab dann ein eigenes Programm geschrieben, um an die 8-bittigen Werte meiner Encoder zu kommen. (Dein Win-Programm machte bei der Installation gar-nichts, nur hängte sich der Rechner auf. (Vielleicht liegt das aber daran, dass meine Systempartition nicht die C: , sondern seit einer dubiosen (fast Neu) Installation die E: Partition ist.) Auch verwende ich die Asuro-Bib 2,80 , da ich auch mit dem ATmega168 experimentiere.
Parallel dazu hab ich, da die Kurven doch sehr lichtempfindlich und auch geschwindigkeitsabhängig waren, die Hardware vom Asuro leicht modifiziert: Den R22 Widerstand (470 Ohm) - er befindet sich in der Nähe Pin 1-3 vom Atmega8 - hab ich entfernt bzw. den Draht durchgekniffen, auf der Rückkseite von der +5V Versorgung eine Schottky-Diode gelötet und an deren Kathode (Strich) einen Elko/Tantal gelötet. Von dem Pukt aus hab ich die Anoden der Encoder Leds D13/D14 mit je einem 349 Ohm Widerstand verbunden. Die Kathoden der Leds hab ich direkt an Masse angeschlossen (Verbindungsleiterbahn Kathode D12 nach Anode D13 hab ich unterbrochen (etwa da, wo auf dem Foto der Widerstand den schwarzen Kabelbinder "untertunnelt").
Mit der separaten Versorgung hab ich mehrere Vorteile:
- Betrieb der Backleds parallel zum Encoder möglich
- stabilere / störungsfreiere Versorgung der EncoderLeds (entkoppelt über Diode und Elko)
- freie Wahl der Ströme durch die Encoderdioden unabhängig von der Belastbarkeit des ATmega-Ports (bei hohen Diodenströmen schalten die FotoTransistoren T11/T12 besser durch (gegen 0V).
- Anpassungsmöglichkeit der Encoderkennlinie durch unterschiedliche Ströme durch entsprechende Widerstandswahl. (Hab ich (noch?) nicht gemacht, könnte aber vielleicht in sehr heller Umgebung was bringen).
Ich denke aber - einfacher und vielleicht auch besser wäre es, die Dioden in Reihe geschaltet zu lassen und nur den Widerstand nach + VCC (je nach Batteriezustand 5V-6V) so zu dimensionieren, dass ein höherer Strom fliesst ( bei mir z.Z. ca 2 x 12 mA : (5V - 2*1,1V) = 3,8V.
Ein Betrieb mit 20mA ist wohl sinnvoll (bei IRL80 max. 60mA möglich),
dann würde ich die Dioden aber in Reihe geschaltet lassen mit einem 154 Ohm Widerstand, besser noch mit einer Fet-Konstantstromquelle (z.B. FET BF245 oder besser BBS129 (Depletion Mode-Mosfet)), die ich auf 20 mA einstelle.
Mit diesen Hardwareänderungen und den neu ermittelten 8-Bit Parametern My_ODO... hab ich jetzt saubere Encoderwerte auch bei wechselnden Lichtverhältnissen (wenn gar nichts mehr geht, kann man auch die Encoder-Transistoren/Dioden gegen Fremdlicht kapseln oder gleich bessere Reflexlichtschranken (z.B. CNY70) einbauen).
Vielleicht komm ich auch nochmal dazu, das Programm von hai1991 zu testen/ändern, aber zumindest gehen bei mir jetzt die Go/Turn Funktionen.
Gruss mausi_mick
Liste der Anhänge anzeigen (Anzahl: 1)
hallo hai1991,
hallo Sternthaler,
1. Win-Programm von Sternthaler für My_asuro.h
- Ich hab zwar die Oberfläche des Programm's mit den DLL's zum Laufen ?
gebracht, zumindest kann ich die schöne Oberfläche bewundern, aber auf die Tasten reagiert es nicht. Ist vielleicht doch ein Problem mit der Installation auf E:
2. Kurvenprogramm von hai1991
- das modifiz. Programm Kurven-Programm läuft bei mir jetzt stabil und relativ genau, man sollte aber mit der speed möglichst oberhalb von 170 bleiben, da sonnst das innere Rad zu langsam wird und das eher ein Rucken auf der Stelle wird.
Den (Winkel == 0) hab ich noch nicht realisiert (für geradeaus) ebenso fehlt noch der Teil mit (speed < 0).
Es verträgt jetzt auch recht hohe Winkel ( durch (int) begrenzt: 32... < w < 32... ) , ich habe bei mir encoder [] als unsigned long definiert, wobei das unsigned vielleicht doch etwas überflüssig ist, sodass man dortso leicht keinen Überlauf bekommt.
als Anhang noch mein Programmbeispiel (weder optimiert noch Schnittstelle an andere ASURO-Programme (Turn/Go/GoTurn...) angepasst)
Gruss
mausi_mick
Liste der Anhänge anzeigen (Anzahl: 1)
Hallo Sternthaler,
hab jetzt mal die Kurvenfunktion (links,rechts,vorwärts,rückwärts)
realisiert und den Aufruf in der Form
char GoTurnArc(int distance,int radius, int degree, int speed)
gebracht. Scheint zu funzen. (Bisher nur mit distance 0)
Hardwaremässig hab ich die beiden Encoder gegen Fremdlicht (von hinten und oben ) mit einem Plastikgehäuse ( PVC-Rechteckkrohr für Aufputz Kabelmontage) gekapselt. Von vorne werde ich noch testen, ob die Schwarzfärbung der Encoderscheibe/rades (natürlich von der Rückseite)
was bringt (werd sie wohl vorsichtshalber erstmal mit schwarzer Folie / Tesa bekleben).
Im Anhang der Code des GoTurnArc-Programms.
PS: Sorry betreff SauRoboter, er verhält sich aber zur Zeit so, hat auf den Encoderkurven jede Menge Peaks (von Motor/H-Brücke), die von 0 bis 255 gehen. Entstörung in Arbeit.
Gruss
mausi_mick
Liste der Anhänge anzeigen (Anzahl: 1)
Grüß dich mausi_mick,
da warst du ja echt fleißig.
Aufgefallen sind mir folgende Stellen:
- Keine Prüfung, ob Parameter "radius" negativ ist. Soll das gehen?
Zumindest wird ja nur mit "if (radius > 0)" wirklich weiter gemacht.
- Dann hier:
Code:
while (weg_s < weg_as) // Ist-Tiks < Soll-Tiks
{
zist = (int)(Gettime () - zista);
//Msleep (5); // 2 ??? 4 und 6 Problem kleiner Durchmesser
//Odometrie einlesen
if (degree > 0) // Rechtskurve: im Uhzeigersinn
{
MotorSpeed (speed_ac, speed_ic); // links = aussen , rechts = innen
count_an = encoder [0]; // links schneller als rechts
count_in = encoder [1];
count_ai = count_ai + count_an;
}
else
{
count_an = encoder [1]; // rechts schneller als links
count_in = encoder [0];
count_ai = count_ai + count_an;
}
Hier müsste doch eigentlich auch ein MotorSpeed() in den else-Zweig, oder?
- Was bedeutet der Kommentar hinter dem auskommentierten Msleep (5)?
" //Msleep (5); // 2 ??? 4 und 6 Problem kleiner Durchmesser"
- Merkwürdig: Wenn "60Tik/U" bedeutet, dass pro Radumdrehung 60 ODO-Tiks erzeugt werden (Ich bin sicher, dass es dies bedeutet). Bei meinem Asuro sind es 80 Tiks pro Radumdrehung.
- Last and least
Warum unterscheidest du beim Sammeln der Daten in Variable dax[][] über "if (degree > 0)" in Rechts- bzw. Linkskurve?
Ansonsten macht mir das Ganze einen soliden Eindruck.
Die von mir aufgeführten Punkte sind ja ohne Auswirkung zum gewünschten Programmablauf.
Dass es aktuell 'etwas' lang und mit sehr vielen float-Berechnungen versehen ist, stört im Moment nicht so dolle. Optimierungspotential habe ich jedenfalls an einigen Stellen entdeckt. Aber wer weiß schon, ob es danach noch gehen würde ;-)?
Auch hier wieder: Es war noch nicht in meinem Asuro. Ich schaue nähhhhmlich gerade auf die Uhr.
Gruß Sternthaler
P.S.: Die Parameter, so wie ich vorgeschlagen hatte sind jedenfalls gut geeignet, um die Lib-Macros Go und Turn weiterhin erhalten zu können. Klasse!
Sauroboter haben immer die Angewohnheit zu quicken. Nicht peaken ;-)
Wermutstropfen: Deine Formatierung ist echt grottig.
Liste der Anhänge anzeigen (Anzahl: 1)
Hi Sternthaler,
Dank für Deine frühe Mühe,
Mit dem Radius hab ich mir das so vorgestellt:
- radius ==0 : erlaubt für Geradeausfahrt (noch nicht realisiert)
sonst:
- radius < halbe Spurweite: Abbruch mit Fehler 1 (err_fl).
Mit der Motorspeed hast Du wohl recht, wobei ich denke, dass ich die Zeile oben deaktivieren werde, da ich am Ende der Schleife MotorSpeed für beide Winkel anpasse. Hab wohl anfangs die MotorSpeed am Anfang der while Schleife für +-Winkel anpassen wollen , hat aber irgendwie (ich weiss echt nicht warum) nicht geklappt und hab dann die Zeilen nach unten kopiert und wohl oben nur eine gelöscht. Muss das aber testen, ob's dann auch noch funktioniert.
Mit den auskommentierten Msleep - Werten : waren alles Tests ,
fährt aber z.Z. ohne Msleep.
Auch noch unsauber ist die Abbruchbedingung, da die letzten counts wohl noch gemacht werden, auch wenn die Ist-Wegstrecke über der Sollstrecke ist. (Fährt dann immer etwas zu weit.)
Mit den 60 Tiks : Ich hab eine Encoderscheibe mit 6 schwarzen und 6 weissen Segmenten, also 12 s-w-Wechseln , macht 12 Tiks pro Encoderrad. Die Über/Untersetzung zum Laufrad beträgt 5 . Ergibt 5* 12 = 60 Tiks pro Laufradumdrehung. Du hast vermutlich eine Encoderscheibe mit 2 * 8 Segmenten .
Das Sammeln der DAX-Werte (hat vermutlich nicht direkt was mit dem Index zu tun) für links und rechts separat ist eigentlich nicht nötig, ich wollte nur in dax[0] die Daten des linken Motors und in [1] die des rechten.
Der Code ist wohl echt etwas kotig, zuviele Casts und zum Teil zu genau (float/double), auch wenig ++. Da sollte man (nicht umbedingt ich ) was tun, wenn die Sache sauber läuft.
Muss mir mal gleich Deine Formatierung ansehen.
Ok, hab mal Deine anders formatierte Version genommen und obige MotorSpeed-Zeile entfernt und die DAX-Tab-Füllung etwas modifiziert.
Erste Tests ok, meist fährt ASURO etwas zu weit / lang,
auch Probleme mit kleiner Speed (z.B. 170) und engen Kurven, da dann das Innenrad je nach Schmierung etc. eventuell steht.
Im Anhang noch der neuste Code
Gruß
mausi_mick
Liste der Anhänge anzeigen (Anzahl: 1)
Hi Sternthaler,
hab nochmal ein paar Sachen geändert und auch für Geradeausfahrt
(distance > 0, radius =0) getestet, wobei mein Asuro vorwärts recht gut die Richtung hält, rückwärts zieht er nach rechts (ein Kreis mit ca 2 m Durchmesser).
Gruss
mausi_mick
