Mir persönlich sagt die Variante mit dem halben Tischtennisball nicht so zu und deshalb hab ich, wie schon andere vor mir, etwas eigenes entwickelt.
Bild hier
Plastekugel mit Kuperdraht, Gewinde drauf und angeschraubt, fertig und wechselbar.
Heiko
Druckbare Version
Mir persönlich sagt die Variante mit dem halben Tischtennisball nicht so zu und deshalb hab ich, wie schon andere vor mir, etwas eigenes entwickelt.
Bild hier
Plastekugel mit Kuperdraht, Gewinde drauf und angeschraubt, fertig und wechselbar.
Heiko
Also irgendwie scheinen ASURO-User sich nicht zu trauen neue Threads aufzumachen ;-) Keine Sorge die Buttons beißen nicht, aber wenn alles zum Thema ASURO in einen Thread gepackt wird steigt ja irgendwann keiner mehhr durch.
Ich hab mir mal die Freiheit genommen und einzelne Themen in extra Threads nach "Elektronik" und "Allgemeines zum..." verschoben.
Gruß, Sonic
Mal so ne Frage. Haben eure Scripts (ua. ./src/FirstTry) ohne weiteres funkioniert zu "maken"? Da mir noch Widerstand fehlt binsch schonmal bisl im Code am rumgucken und lernen ;)
Nachdem ich die Umgenung erst auf ein anderes Laufwerk geladen hatte, das Makefile aber sicher war, daß seine Dateien auf C stehen, habe ich noch mal von vorne angefangen.
Ich habe dann einfach neue Programme per Editor in die Datei Test kopiert und unter dem Namen Test compliliert. So wurden die Make-Parameter neutralisiert und es lief glatt.
Manfred
Also ich kan ohne Probleme Programme mit dem PRogrammers-Notepad erstellen und sie auch umwandeln, nur muss man beim speichern aufpassen, dass man die Endung ".c" anfügt, weil er das bei mir nicht automatisch macht.
MFG Moritz
Hallo
Ich hab eine Frage zur Infrarot-Übertragung am ASURO:
Die Sende-Diode ist ja zwischen Pin 17 und TXD. Mit bascom kann man einfach Print benutzen um Daten zu senden, die werden auch empfangen. Was macht Pin 17 während dem Sendevorgang? Denn wenn ich bei meinem mega32 eine IR-Diode von TXD nach + anschließe blinkt diese zwar während dem Senden auf aber es wird nichts empfangen ???
Weiß vielleicht einer Rat?
Gruß Tobias
Hallo,An Pin17 liegen die 36KHz des Timers an.Zitat:
Was macht Pin 17 während dem Sendevorgang?
Das ist praktisch das Trägersignal,
dem das USART-TXD-Signal aufmoduliert wird. (AND)
Der SFH5110-36 auf der Gegenseite ist nur für diese 36KHz-Signale "empfänglich".
Deshalb funktioniert das direkte Ansteuern der LED von TXD nicht.
Gruß Jan
Hab ichs mir doch gedacht ...
Jetzt muss ich nur noch rausfinden wie ich 36KHz aus dem Timer krieg.
Hallo,
Den Timer auf freilaufend mit 72kHz programmieren,Zitat:
36KHz aus dem Timer
und den Ausgang auf "Toggle" stellen.
Gruß Jan
Öhm wie kann es kommen, dass mein ASURO nie wirklich geradeaus fährt, sondern immer so ein wenig nach rechts?
Und was macht die Funktion Sleep()? Erkenne darin kein Nutzen :!
Und wie nutze ich SerRead()?
Naja, das hägt von der allgemeienen Materialstreuung und vor allem von der Lauffreiheit der Zahnräder ab. Du kannst das aber ausgleichen indem du die Odometriedaten auswertest und die Geschwindigkeit der Motoren einzeln veränderst.
Lass aber am Besten die beiden großen Zahnräder mit Rad ohne Motor nochmal frei laufen. Wenn da der Unterschied schon groß ist würde ich die Achsen nochmal neu einlöten.
Gruß
Stefan
Oh nein, ned die Achen nochmal -.- Ich find das ist der größte Mist überhaupt mit den Achsen.
Aso an die AREXX Leute:
In der Bauanleitung steht bei der Bestückung der Hauptplatine bei R11 folgendes:
Naja die Werte stimmen ja aber die Kodierung nicht. Da muss normalerweise so sein:Zitat:
R11: 100 Ohm, 5% (braun, schwarz, schwarz, gold)
Ich saß da nen paar Tage dran bis ich das, ohne nem Messgerät herausbekommen hab, denn ich hab nach der Kodierung geguckt und nichts gefunden!Zitat:
braun-schwarz-braun-gold
\:D/ ja, ja Die Unterschiede in der Beschreibung und der Wirklichkeit ist schon bitter.
Ich hatte in meiner Packung schon eine korrektur bei liegen.
Ich bin von Natur aus ein Skeptischer Bastler und messe grundsätzlich nach.
Sonst ging der Aufbau echt gut, nur die Motorbefestigung muss ich noch mal ändern (das gefällt mir noch nicht).
Heiko
Jau die ist echt ein wenig komisch aber ich werd mir morgen mal, wenn ich zu meiner Ex fahr Sekundenkleber irgendwo holen damit ich die Motoren endlich mal befestigen kann. Normalerweise müsste ich noch wo Sekundenkleber haben aber find den nicht. Habe lediglich so Modellbaukleber aber ob der so dolle ist :!
Also ich hab ganz normalen UHU genommen. Bis jetzt hält das ganz gut...
Gruß, Sonic
Ja, wie man das am besten macht, darüber denke ich auch schon die ganze Zeit nach. Allerdings weiß ich nicht wirklich wie ich da anfangen soll.Zitat:
Naja, das hägt von der allgemeienen Materialstreuung und vor allem von der Lauffreiheit der Zahnräder ab. Du kannst das aber ausgleichen indem du die Odometriedaten auswertest und die Geschwindigkeit der Motoren einzeln veränderst.
Dachte an sowas:
Motorspeed(x-korrektor1; x-Korrektur2)
- Räder auch maximale Geschwindigkeit
- Timer zum messen der Zeit starten
- Odometrie auslesen, warten bis bestimmter Wert unter/überschritten ist
- Zeit für eine Teilumdrehung aus dem Timer entnehmen
- Das geliche Verfahren bei dem anderen Rad
- Bestimmen welches Rad langsamer dreht
- Schleife:
+ Schnelles Rad um eins langsamer (Abweichung in Variable schreiben)
+ Geschwindigkeit messen
+ Wenn Abweichung unter einem bestimmten Wert, schleiche Beenden sonst schliefe neu.
Das ganze ist ziemlich aufwendig und erfordert vermutlich viele Resourcen, aber ich wüßte im moment nicht, wie man es anders lösen sollte. Um eine Initialisierungsphase kommt man da wohl nicht rum.
MFG Moritz
Ich will mir ein Testprogramm schreiben und mal schaun wie unterschiedlich die Räder drehen und ob der Fehler reproduzierbar ist.
Wenn ja kann man auch die Fehlerfunktion bestimmen und den Fehler korrigieren ohne jedes mal die odometrie zu benutzen.
Habe aber leider im Moment nicht die Zeit dazu melde mich aber wenn ich Ergebnisse habe.
Gruß
Stefan
Hm, ja das ist klar, aber ich finde die nutzung der odometrie irgendwie sehr aufwendig. Ich wollte sie ja längerfristig auch zur Wegerfassung und Positionsbestimmung nutzen, aber das Problem ist: Da man den ADC ständig verfolgen muss ist kein anderes Programm nebenher abspielbar, oder nur ein sehr minimiertes. Es wäre irgendwie besser, wenn man da einen Interrupt auslösen könnte, aber das ist bei dem ADC nicht möglich, da sich der Wert ständig ändert.
Viellieicht kennt ja jemand ne einfacherer Lösung als die oben von mir vorgeschlagene.
MFg Moritz
Zu diesem Problem hatte ein Praktikant von mir eine saugeile Idee:Zitat:
Zitat von RCO
I-Regler - funktioniert folgendermaßen:
Man benötigt eine (signed) Korrekturvariable - im weiteren I genannt. Während einer Endlosschleife stellt man die Motorgeschwindigkeit auf MotorSpeed(Grundgeschw+I, Grundgeschw-I)
Außerdem nutzt man die Odometriesensoren. Findet beim linken Sensor ein Helligkeitswechsel statt (natürlich etwas Hysterese verwenden, sonst verzählt man sich) I um eins erniedrigen, für einen Wechsel beim rechten um eins erhöhen.
Nach kurzer Banane fährt ASURO sehr gut geradeaus. Ggf. kann man sich den Wert im EEPROM auch noch merken...
Der ADC kann übringens nach einer Wandlung automatisch einen Interrupt auslösen, sodass man das Problem auch im Hintergrund laufen lassen kann.
CU, Robin
Das ist in der Tat eine gute Idee! Allerdings muss man dann auch irgendwann ein Ende finden, vielleicht lässt man die Schlaufe 20 mal durchlaufen oder so.
Löst der Interrupt nicht aus, egal an welchem ADC eine Wandlung vorgenommen wurde? Das heißt auch die Linienverfolgung würde einen Interrupt auslösen, oder?Zitat:
Der ADC kann übringens nach einer Wandlung automatisch einen Interrupt auslösen, sodass man das Problem auch im Hintergrund laufen lassen kann.
Danke für den Tip mit der Geschwindigkeitsreglung!
MFG Moritz
Eine BEschränkung der Durchläufe braucht man nicht. Irgendwann sind die Motoren so ausgeregelt, dass sich der Korrekturwert nicht mehr ändert. Lässt man den Regler weiterlaufen, kann der Roboter auch noch auf sich ändernde Umgebungsbedingungen reagieren.Zitat:
Zitat von RCO
Der AD-Wandler kann so konfiguriert werden, dass er nach einer Wandlung (egal auf welchem Eingang der Multiplexer steht) einen Interrupt auslöst. Das muss man aber selbst schreiben, die vorgefertigten Funktionen können das nicht (wäre ja auch viel zu kompliziert für den Anfang). Im Interrupt muss dann entschieden werden, welcher Wert gerade gewandelt wurde und der dazu passende Programmteil ausgeführt werden.Zitat:
Zitat von RCO
Für die Interruptprogrammierung spickt man am besten bei der Sleep-Funktion und im Datenblatt des ATmega8 (*wühl*), damit man weiß, wo welche Bits gesetzt werden müssen um den gewünschten Effekt auszulösen.
Da liegen wohl die Vorteile der C-Programmierung ;-)
Ich hab mich mit den Interrupt in C mal beschäftigt, es hat, wenn man einmal den Durchblick hat, echt viele Vorteile durch die direkte Ansprechung der Register. Man müsste den ADC nur auf FREE stellen und dann den entsprechenden Interrupt aktivieren.
NUR WIE GEHT DAS IN BASCOM?
Das stimmt wohl, aber welche Änderungen könnten einen Einfluss darauf haben? Eine Gewichtsumverteilung auf dem Roboter z.B.Zitat:
Lässt man den Regler weiterlaufen, kann der Roboter auch noch auf sich ändernde Umgebungsbedingungen reagieren.
Allerdings ist auch zu beachten, dass das "Korrekturprogramm" bei Kurvenfahrten abgeschaltet werden muss, während es z.B. bei einer Drehung um die eigene Achse weiterlaufen kann.
IM Übrigen ist es wohl sinnvoll einen möglichst hoch aufgelösten PWM zu verwenden um die Korrekturen feiner zu machen.
MFG Moritz
Wow hab grad nen Flash ohne "c", "t" oder sonstwas hinbekommen :D nur überall flashed :D
// Edit:
Was gibt mir OdometrieData eigentlich? Gibt mir das die Umdrehungen pro Sekunden aus oder was wird mir da ausgegeben?
Schön wärs!
Darüber Diskutiere ich grad mit Archi, OdometrieData liefert nur den ADC-Wert an den Rädern, also wie hell der gerade beleuchtete Teil der Scheibe ist. Wie man daraus sinnvoll Informationen gewinnt und die REsourcen sparend nutzt ist die große Frage.
MFG Moritz
Die 20 Seiten, die trotz Leerprogramm "geflashed" werden, dürften von der libc herühren, die ja die Laufzeitumgebung für das C-Programm bereitstellt. Da sind Funktionen für Aritmetik, Speicherverwaltung und IO drin. Genaueres findet Ihr im Dokument "AVRInstructionSet.pdf", das bei den Datenblättern der aktuellen Asuro Distribution dabei ist.
Grüße,
Sascha
Meiner Erfahrung nach kann es das allein schon durch ein zu fest "angezogenes" Rad kommen. Einfach mal schauen welches der Räder langsamer läuft und dann auf der Seite den Stellring lockern und 1/4 Milimeter nach außen schieben (und dann natürlich wieder fest ziehen).Zitat:
Zitat von freq.9
Grüße,
Sascha
Hö hatte ich vorhin garned abgesendet? -.-
Naja also das mit dem Stellring hat geklappt. Das rechte Rad hatte zwar ein wenig Platz, es war scheinbar aber ein wenig zu wenig. Naja nun gehts auf jedenfall besser.
Wäre es eigentlich möglich den Roboter über den PC zu steuern? Also vllt. könnte man da SerRead() nutzen. Wobei dann bestimmt die Verbindung schwer wird zu halten, denn man sieht ja schon, dass "Mist" ankommt, wenn der RS232-IR-Transceiver bisl weiter weg ist. Aber wäre das möglich? (wüsste sonst nicht, wofür SerRead() zu nutzen wäre.)
Hallo Freq.9
Du hast recht, theoretisch sollte das gehen, es ist soger bei den Demos ein Quellcode dabei, wie es gehen sollte. Interessanter fände ich aber, wenn man das benutzt, um Asuro nur einen befehl zu geben, der dann aus einer Art Menue auf dem Robot ein Programmteil auswählt, das dann ausgeführt wird.
Gruß
Torsten
Na, da kommt einem doch gleich der Gedanke die Signale einer handelsüblichen IR-Fernbedienung auszuwerten. Muss mal schauen ob das irgendwie geht. Sicher nich über SerRead() aber evtl. durch zyklisches Abfragen der Schnittstellenbits. Kann evtl. über Interrupts gelöst werden. Aber das ist schon etwas aufwändigerZitat:
Zitat von thille
Grüße,
Sascha
Hi,
da dieser Thread langsam zu lang wird und eigentlich nur noch speziellere Fragen kommen die nicht zu "ASURO allgemein" passen mach ich diesen Thread mal zu.
Ich glaube nicht das jemand der den Thread nicht von Anfang an verfolgt gewillt ist 15 Seiten zu lesen ;-)
Gruß, Sonic