Druckbare Version
Hallo,
ich wollte mal fragen wie man beim Asuro die Geschwindigkeit bestimmen kann. Denn dafür müßten ja zwei Dinge gleichzeitig ablaufen. Der Prozessor müßte durch zählen des Schwingers die Zeit bestimmen und gleichzeitig durch überprüfen der Helligkeitswechsel die Helligkeitswechsel zählen. Dann könnte man den Rest ja einfach Hochrechnen. Aber wie schaffe ich, daß er das parrallel macht???
Oder habe ich einen Denkfehler?
MFG
Christian
Hallo!
Nein, das ist kein Denkfehler, da liegst du vollkommen richtig. Parallele Aufgaben sind für einen µC aber kein Problem, man löst sowas mit Interruptroutinen.
Such hier mal nach der Lib von Weja, der hat sowohl eine Zeitfunktion Gettime() als auch eine komfortable Funktion zum Auslesen des Encoders bereits eingebaut. Damit sollte die Berechnung der Geschwindigkeit mit ein paar Zeilen zu lösen sein.
Gruss Waste
Und wie gehts mit dem normalen??? bzw. wie funktioniert das mit diesen Interruptroutinen?? Kann das mal einer kurz erklären oder mir bitte einen Link dazu schicken.....
MFG
Christian
Hallo Christian 25,
Parallel macht der Mega8 grundsätzlich erstmal garnichts,
er kann Befehle nacheinander abarbeiten,
Selbst mit den Interrupts, geht nichts parallel, wie das hier oben behauptet wurde.
Bei eintretten eines Interrupts unterbricht er seine Arbeit im Hauptprogramm, und arbeitet erstmal die Interruptroutine ab.
Also immer schön alles nacheinander.
Ein Timer, oder PWM laufen nebenbei, was spricht dagegen, wenn Du einen Timer auf sagen wir mal eine Sekunde stellst, und danach die Anzahl der übergänge zählst?
Wenn Die Zeit um ist, hörst Du in der Interruptroutine des Timers auf hochzuzählen, dann hast Du schon Deine Variable.
Google mal nach avr +interrupt, oder schaue Dir mal das Dattenblatt des Megas8 an,
Ich denke hier in Forum wirst Du auch jedemenge Stoff finden, die Sufu benutzen
Gruß Sebastian
@Christian25
schau mal hier wegen Interrupt:
http://www.mikrocontroller.net/tutorial/interrupts
http://www.mikrocontroller.net/artic...Programmablauf
@izaseba
Wie bezeichnest du es, wenn ein µC zwei Aufgaben parallel abarbeitet?
Waste
Hallo Waste,
Ich verstehe Deine Frage jetzt nicht, wann arbeitet der µC zwei Aufgaben parallel ab???
Antwort Nie,
Das einzigste, was parallel zu Programm laufen kann sind die Timer und PWM sonst nichts.
Gruß Sebastian
Es kommt sicher vor, dass Aufgaben parallel anstehen, das ist von der Lösung mit einem Controller noch unabhängig.
Schade, dass gerade keiner eine gute Formulierung für das stückweise sequenzielle Abarbeiten der Aufgaben parat hat.
Manfred
Hallo Sebastian!
Na die beiden Aufgaben:
- Zeit zu bestimmen
- und Helligkeitsunterschiede zu zählen
die müssen doch laufend gemacht werden, zwar nicht beide zur gleichen Zeit aber irgendwie parallel oder nebeneinander oder wie auch immer. Mir fällt da nichts besseres ein wie parallel.
Waste
Ich drücke das so aus,
Die Aufgaben werden NACHEINANDER abgearbeitet, das geht aber so schnell, daß es für uns als gleichzeitig (parallel) erscheint.
Als Beispiel nenne ich hier die multiplexe 7 Segment Anzeige die Zahlen werden so schnell ein und ausgeschaltet, daß es für uns garnicht mehr sichtbar ist.
Gruß Sebastian
Ich meine es eigentlich so, dass der interleave Effekt mehr betont wird, es werden die Aufgaben ja nicht nur nacheinander ausgeführt, sondern sie müssen ja ständig auch Ergebnisse liefern.Zitat:
Zitat von Manf
Der Multiplexeffekt ist ein gutes Beispiel, wie nennt man es denn bei Prozessen?
Manfred
Es ist schon klar, dass die Prozessorbefehle nur nacheinander ausgeführt werden können. Die Abarbeitung der Aufgaben wird ineinander geschachtelt.
Der Zeitraum der Aufgabe ist aber länger, also kann man meiner Ansicht bei der Aufgabe durchaus von parallel sprechen. Aber ich bin auch mit multiplex einverstanden. Mir ist nur oben nix besseres eingefallen.
Waste
PS: Christian25 wird sich wundern, was für eine Diskussion aus seiner Frage wurde. Aber vielleicht hilft es für ihn.
Multitasking vielleicht ?Zitat:
Zitat von Manf
Wobei bei Multitasking auch nur alle Prozesse nacheinander abgearbeitet werden, es sei denn man hat einen Prozessor mit mehreren Kernen, und das passende Betriebsysten dazu, das hat aber nichts mit dem AVR zu tun.
Wenn der AVR sich in einer Interruptroutine befindet, kann Ihm kein anderer Interrupt dazwischen funken weil die Interrupts da komplett abgeschaltet sind,
erst beim verlassen der routine werden sie wieder eingeschaltet und freigegeben,
Das ist auch der Grund warum sie kleingehalten werden sollen.
Wie das bei Pics oder anderen aussieht weiß ich nicht.
Soltte ich da falsch liegen bitte nicht erschlagen
8-[
Gruß Sebastian
hoffen wir mal, das ist ja unser ZielZitat:
PS: Christian25 wird sich wundern, was für eine Diskussion aus seiner Frage wurde. Aber vielleicht hilft es für ihn.
Erstmal danke für die viele Antworten.
Jetzt hätte ich aber doch noch mal einige Fragen um da komplett durchzublicken:
Was ist genau dieses AVR??? Ist das eine Art Programmiersprache (glaub ich nicht) oder was genau? Und passt daß zu jeder beliebigen Programmiersprache?
Dann hat vielleicht jemand mal dieses Datenblatt desATmega8 auf deutsch oder was vergleichbares, weil auf Englisch wird das bei mir nix.
Und könnte mir vielleicht mal jemand der das ganze schon mal Programmiert hat mir diese zukommen lassen (eMail) am besten mit kurzen Kommentaren (also den Quellcode)
Vielen Dank
MFG
Christian
AVR nennt sich eine Prozessor-Familie von ATMEL. Zu dieser Familie gehört auch der ATMega8, der im Asuro verwendet wird.
Programmieren kannst du den in jeder beliebigen Sprache, für die Compiler auf dem Markt sind. Mit dem Asuro wird der Gnu-Compiler mitgeliefert, der nennt sich AVR-GCC weil er ein C-Programm in den Maschinencode für die AVR-Familie übersetzt. Wenn du in einer anderen Sprache programmieren willst, dann brauchst auch einen anderen Compiler.
Ein Beispielcode für dein Problem kommt gleich.
Gruss Waste
Hier ist der Beispielcode zur Geschwindigkeitsbestimmung. Mit der Weja-Lib sind es wirklich nur ein paar Zeilen. Der relevante Code ist als Auszug hier:
Das gesamte Programm incl. Weja-Lib ist in dem angehängten zip-File.Code:unsigned long endtime=Gettime()+1000;
while(1){
if (Gettime()>endtime){
v=encoder[0]*3; // berechnet Geschwindigkeit in mm/s
//SerWrite("v = ",4); PrintInt(v); SerWrite("mm/s\n\r",6);
endtime=Gettime()+1000; //setzt neue Sekunde auf
Encoder_Set(0,0); //Encoder auf 0 setzen
}
}
Erklärung:
Gettime() ist eine Funktion in asuro.c, die einen Taktzähler in ms zurückgibt.
encoder[0] ist die Variable in der die Helligkeitsunterschiede mittels einer Interruptroutine hochgezählt werden.
Mit der Zeile
v=encoder[0]*3;
wird die Geschwindigkeit in mm/s berechnet, weil bei mir ein Helligkeitsunterschied 3mm entspricht.
Wenn du das angehängte Beispielprogramm compilierst, dann musst du auch die dazugehörigen Dateien asuro.c und asuro.h aus dem zip-File verwenden, sonst läuft es nicht.
Gruss Waste
Hallo Christian,Zitat:
Zitat von Christian 25
solltest Du ein Datenblatt auf Deutsch finden, lass mich das wissen...
Ich glaube, da mußt Du Dich mit Englisch auseinandersetzen :-s
Gruß Sebastian
Aber zu einem sostark verbreiteten Prozessor muß es doch auch was auf deutsch geben. Zumindestens mal eine ausführliche Erläuterung die dem Datenblatt gleich zu setzten ist....
Kennt da jemand einen Link??
MFG
Christian
Hallo,
Für C würde ich das hier vorschlagen,
http://www.mikrocontroller.net/artic...R-GCC-Tutorial
Dabei muß ich sagen, daß ich mit Englisch auch auf Kriegsfuß bin, und trotzdem komme ich mit den Dattenblätern gut zurecht, die sind echt einfach geschrieben.
Gruß Sebastian
Hallo,
zu den Begriffen der parallelen Bearbeitung von Aufgaben
auf einem Prozessor:
Multiprozessing, Multitasking benennt die Eigenschaft eine Aufgabe
nebenläufig zu anderen Aufgaben ausführen zu können.
Steht dazu nur ein Prozessor zur Verfügung, so wird die Arbeitsleistung
des Prozessors in kleine Zeitscheiben zerlegt "reihum" den einzelnen
Aufgaben zugeteilt => "Time-Sharing".
Jede Aufgabe erledigt in dieser Zeit soviel wie sie kann und den jeweiligen
Rest in späteren Zeitscheiben.
Auf dem Prozessor läuft dabei natürlich alles schön nacheinander ab,
aber auf Ebene der Aufgaben läuft alles parallel.
Was wichtig ist, ist die Parallelität auf Aufgabenebene.
Die Quasiparallelität der Aufgabenbearbeitung auf Prozessorebene - durch Time-Sharing -
ist im Wesentlichen eine Performance-Frage.
Parallele Bearbeitung von Aufgaben ist damit also eigentlich eine
Eigenschaft der SW - üblicherweise des Betriebssystemes -
und unabhängig davon, ob der Prozessor diese Parallelität direkt
unterstützt oder nicht.
Also auch der Asuro könnte multitasking-fähig gemacht werden.
Tschüss
Ewi
PS:
sorry grade erst entdeckt, da passiert schon was in dieser Richtung:
https://www.roboternetz.de/phpBB2/ze...rag.php?t=9735[/b]
"Der Zeitraum der Aufgabe ist aber länger, also kann man meiner Ansicht bei der Aufgabe durchaus von parallel sprechen."
nein gas geht nicht!!!!!! es ist nicht parallel!!!!!!!!!!!!!!!!!!!!
mfg pebisoft
man kann mit einem avr und einem encoder nicht die momentane v0 errechnen, das geht nicht. die v0 hast du erst bestimmt wenn du schon wieder ganz woanders stehen tust und da hat es schon gebumst weil du zu spät heunter gedrosselt hast. du bestimmst immer die vergangene v0 und davon braucht man keine daten.
mfg pebisoft
Hallo Pebisoft,
woher kommt eigentlich deine kategorische Überzeugung in die
ausschließliche Korrektheit deiner Definition von Parallelität mit
den vielen "!"?
Es ist nämlich trotz der vielen "!", wenn man sich auf die
Abstraktionsebene der Aufgaben begibt,
also aus Sicht der Aufgaben, eine parallele Bearbeitung.
Wie ich oben versucht habe zu erklären.
Wastes Sicht ist für mich somit durchaus vertretbar ;) .
Bzgl. des Nutzens, die vor kurzem noch gültige Geschwindigkeit zu bestimmen,
bin ich auch anderer Meinung.
Für ein autonomes Aggieren kann das durchaus ausreichend sein,
man sieht's an den Lebewesen, die über ihre Geschwindigkeit auch nur
mit dem Manko des veralteten Datums orientiert sind und trotzdem recht
gut schaffen nicht gegen die Wände zu laufen.
Tschüss :)
Ewi
Hallo pebisoft,
eigentlich wollte ich hier nichts mehr posten, aber du hast mich jetzt doch wieder auf den Plan gerufen und mit deiner Aussage neugierig gemacht.
v0 ist üblicherweise das Kürzel für Anfangsgeschwindigkeit. Was das hier zu suchen hat, versteh ich nicht ganz. Noch weniger, was eine momentane Anfangsgeschwindigkeit ist. Aber vielleicht kannst du mich da aufklären.Zitat:
man kann mit einem avr und einem encoder nicht die momentane v0 errechnen, das geht nicht. die v0 hast du erst bestimmt wenn du schon wieder ganz woanders stehen tust und da hat es schon gebumst weil du zu spät heunter gedrosselt hast. du bestimmst immer die vergangene v0 und davon braucht man keine daten.
Ausserdem würde mich interessieren, welche anderen Messmethoden es gibt, die für Roboter praktikabel sind und in welcher Messzeit damit gemessen werden kann.
Gruss Waste
ich meine natürlich "v". wenn du ein tacho beobachtest, fällt ja auch nicht die zahl immer wieder auf "0" zurück und dann wieder auf die stellung die evtl der "v-generator" vorgibt. das passiert aber bei dir, wenn du mit einem radencoder abgreifen tust und nicht eine elektronik einbaust wie man sie in elektronischen tachometern hat. es wir immer pro zeiteinheit in allen augenblicken die "v" angezeigt. beim radencoder hast du die "v" immer erst , wenn du schon wieder eine neue "v" hast. du hinkst immer hinterher.
schau die mal das innenleben eines elektronischen fahrradtachos an.
der fahrradtacho bekommt immer einen eklektronischen impuls pro zeit und zurückgelegten weg des rades. so einen tacho kauft du dir und den kannst du dann am avr anschliessen. ist ganz einfach, pro radumdrehung ein stromimpuls , kann auch vom radencoder sein. den radumfang musst du im tacho noch eingeben.
mfg pebisoft
Sie fällt nicht auf 0 zurück, sondern sie übernimmt einfach den vorigen Wert. Ein Radtacho kann nur einmal pro Radumdrehung die Geschwindigkeit ermitteln.
Am ASURO ist das ja nichts anderes, nur das nicht nur einmal pro Radumdrehung sondern, je nach Schablone, 40-60 mal pro Radumdrehung gemessen wird.
Liebe Mitleser,
lasst Euch nicht beirren, mit dem Radencoder vom Asuro kann sehr wohl die Geschwindigkeit gemessen werden und das je nach eingebauter Reflexscheibe alle 2mm bzw. 3mm. Zum Beweis ist ein Diagramm angehängt, es zeigt die vom Asuro selbst gemessene Beschleunigung aus dem Stand. Da fällt nichts auf 0 zurück, wie von pebisoft behauptet.
Waste
Hallo,
es gibt ja auch für deises "Zurückfallen auf 0" keinen Grund,
es sei denn man programmiert diesen "Effekt" gezielt.
Hübsches Diagramm ;)
Tschüss
Ewi
welche effekt hält denn die tachonadel(mechanisch ) auf den momentanen v-punkt, das ist doch nur das ständige magnetische drehfeld ansonsten, würde nur die trägheit der masse und die spiralfeder den abfall der tachonadel bis unten runter bestimmen. und beim elektronischen tacho wird der spannungsabfall compensiert durch einen condensator der eine spannung eine bestimte zeit hält, damit die anzeige nicht dauernd auf "0" fällt wenn der geber gerade gegenüber des messpunktes liegt.
dein diagramm gibt nicht die praxis wieder.
mit dem encoder kann ich nur die strecke feststellen und nichts anderes.
der avr sagt mir die ausgerechnete "v" erst wenn ich schon zeitlich vom fragepunkt entfernt bin. mit dem tacho erfahre ich die zum sofortigen zeitpunkt gefahrene "v" . darum habe ich an meinem küchenbrettroboter ein fahrradtacho angebaut, der vom encoder nur den impuls bekommt. am tacho selber muss ich noch den radumfang eingeben. schon kann ich am display die "v" ablesen, die zeit die er gefahren ist, die durchschnittliche "v" und die strecke.
mfg pebisoft
Lieber pebisoft,
wenn du es nicht kannst, heisst das doch nicht automatisch, dass es andere auch nicht können oder dass es gar nicht geht.
Was glaubst du, wie der Fahrradcomputer auf deinem Küchenbrettroboter funktioniert? Das würde mich jetzt brennend interessieren. Erklär es doch bitte.
Gruss Waste
Also um das jetzt hier mal auch einzuwerfen:
Du teilst ja immer die Strecke durch die Zeit und die Strecke hast du erst nach einer gewissen Zeit, dass heißt du berechnest doch auch immer den Wert, der vor einem gaaaaanz kurzen Moment war. Du kannst NIE die momentane Geschwindikgkeit messen, da du immer die Strecke, bzw. Drehung pro Zeitmessen musst. Da hinkst du immer (mal nebenbei gesagt: unwesentlich) hinterher.
Das ist auf jeden Fall meine Meinung.
Andun
Hallo pebisoft, und alle anderen,
hier vielleicht mal eine Erklärung für die Unterschiede der Messmethode aus dem tollen Beispielprogramm (genau sowas wollte ich auch schon mal schreiben, danke für's Muster) und der Methode im küchenbrettroboter (Fahrradcomputer)
Der Fahradcomputer bekommt EIN Signal pro Radumdrehung. Über die vorher eingegebene Radgröße weiss der Fahrradcomputer jetzt, dass nach diesem Signal eine bestimmte Strecke, wir nennen sie mal m, zurückgelegt wurde. Nun hat der Fahradcomputer eine Eingebaute Uhr, die er mit jedem Signal ausliest und sofort wieder auf 0 zurücksetzt. (P.S.: Dies wird auch nicht angezeigt.) Die ausgelesene Zeit wollen wir mal s nennen.
In dem sehr schönen Beispielprogramm (nochmals Danke) wurde eine Uhr aufgezogen, die für eine Sekunden den Raddekoder mal so zählen ließ. Diese eine Sekunde wollen wir auch hier mal s nennen, da es sich ja um eine Zeit handelt. Nun wird nach dieser EINEN Sekunde der Zähler vom Raddecoder ausgelesen und sofort wieder auf 0 gesetzt. Da der Zähler ja einem Weg entspricht können wir den Wert auch m nennen.
Also in beiden Fällen haben wir s (Zeit) und m (Weg).
Formel für die Geschwindigkeit bleibt unabhängig von der Messmethode v=m/s (habe ich in der Schule gelernt. pebisoft, bist du einverstanden?)
Der einziege Unterschied ist also, dass das eine System eine feste Zeit kennt (Software) und das andere System kennt den Weg (Fahrradcomputer). Beide Systeme ermitteln also nur den fehlenden 2.ten Wert und berechnen nach der gleichen Formel ein Ergebnis. Das ist in beiden Fällen RISCHTIEG.
Aber in beiden Fällen hinken die Messsystheme tatsächlich ein gaaaanz klein wenig hinter her. Aber keine fällt auf 0 ab. Dazu ist noch nicht mal ein Condensator nötig.
Gruß vom Sternthaler (heute zum ersten mal hier mit eigenem Senf.)
P.S.: Mein Asuro fährt dank einiger Unterstützung aus diesem Forum schon geradeaus.
"Mein Asuro fährt dank einiger Unterstützung aus diesem Forum schon geradeaus."
da die beiden motoren auf dem asuro keine markenartikel sind und die zahnräder auch nicht, kommt es zwangsläufig zum drehzahlunterschied.
den kannst du kompensieren wenn du nach einer messstrecke die
spannungregelung von einem motor etwas höher stellen tust oder etwas niedriger. ist nicht so schwer im programm.
mfg pebisoft
Hallo pebisoft,
ich warte noch auf eine Erklärung des Prinzips der Geschwindigkeitsmessung (Fahrradcomputer) auf deinem Roboter? Oder bist du mit der Erklärung von Sternthaler einverstanden.
Waste
pebisoft schrieb:
da die beiden motoren auf dem asuro keine markenartikel sind
Das habe ich bei meinen ersten Versuchen schmerzlich festgestellt. Eine halbwegs gerade Linie war nicht hinzubekommen.
Als Lösung habe ich in meinen Sourcen einen Define eingeführt, der meinen rechten Motor immer um diesen Wert stärker mit Saft versorgt.
P.S.: Linker Motor fährt bei mir in MotorSpeed mit 110 an. Der Rechte aber erst bei 160. Differenz von 50 also im Define.