Druckbare Version
Das soll man sicher tun, das ist schon mal ein guter Hinweis, die Absolutwerte streuen zu sehr. Im dargestellten Programm wird zu Beginn der Fahrt eine Anfangsdiffernz gebildet, auf die man sich wärend der Fahrt und Auswertung bezieht.Zitat:
Schon mal daran gedacht, nur die HelligkeitsDIFFERENZ auszuwerten?
Bei Kreisfahrt und seitlicher Beleuchtung kann und sollte man sicher mehr tun. Es wäre dann ganz geschickt, die Sensoren etwas gegen Fremdlicht abzuschirmen.
Manfred
Die Anfangsdifferenz gleicht eigentlich nur die am Startpunkt gemessene Differenz aus, wenn sich die Beleuchtung unterwegs ändert, ist sie eigentlich nicht sehr hilfreich. Wenn die Messung so wie im Programm ziemlich regelmäßig erfolgt, könnte man auch die Änderung auswerten. Oder eine andere Variante wäre, nicht die Linie zwischen die Fototransistoren zu nehmen, sondern nur eine Kante, dann müßte einer der Sensoren über der Linie entlanggeführt werden, und der andere auf dem Untergrund. D. h. die Differenz zwischen den Sensoren sollte möglichst groß sein. Steigt die Summe beider Werte über eine bestimmte Grenze, ist die Abweichung nach einer Seite zu groß, fällt sie unter eine Grenze ist die Abweichung nach der anderen Seite zu groß. Setzt natürlich voraus, daß die Linie mindestens so breit ist, wie der Abstand der Sensoren.
Gruß
Torsten
Da hätte ich auch noch eine Idee: Die Linienbeleuchtung ein- und ausschalten und davon die Differenz bilden. Habe ich aber noch nie ausprobiert...Zitat:
Zitat von Manf
CU, Robin
Prima Idee, das wird ja richtig gut.Zitat:
Da hätte ich auch noch eine Idee: Die Linienbeleuchtung ein- und ausschalten und davon die Differenz bilden. Habe ich aber noch nie ausprobiert...
Ich wollte eigentlich noch mal wissen wie vollständig die Roboter sind und ob es noch Probleme mit den elemataren Funktionen gibt.
Ich habe mich erst zu einem elementaren Beispiel durchgekämpft, um zu sehen, daß die Grund-Funktionen einigermaßen gehen.
Ich habe natürlich das Programm von Thille (vielen Dank) als Anleitung hergenommen und erst mal nur Parameter verändert. Ich glaube irgendwie, daß ich den Funktionsumfang, der sich bietet noch nicht voll nutze.
Sonic ist ja auch schon lange bei eigenen Programmen. Wie sieht es mit dem Rad-Encoder aus? Wenn die Kurven nur sinusförmig sind, dann sollte man vielleicht eine geringere Auflösung nehmen. Nicht 6 sondern 4 oder weniger vielleicht 2?
RCO optimiert die Linienvefolgung also geht auch schon alles? Ich habe die Motoren noch an Kabelbindern, hat sie jemand schon angeklebt?
X-Ryder hat sich zuletzt vom Flashen gemeldet. Wie sieht es mit dem Pogramm aus? Ich habe Teppiche in denen Asuro keine klare Linie findet. Den Boden mit Papier auslegen und mit Filzstift Linien zu zeichnen gelingt mir auch nicht so gut. Viel lieber wäre es mir, einen Sharp Sensor zur Seite auszurichten und den Anstand zur glatten weißen Wand zu regeln. Das ist nur ein kleiner Schritt vom Linienfolger aus. Ich werde das mal angehen mit der Buchsenkombination vorne im Asuro.
Manfred
Hi,
ich hatte die Ehre diesen Sommer am DLR bei Robin Gruber, dem Entwickler von ASURO, ein Praktikum zu absolvieren und am Roboter zu basteln.
Ich hatte davor wenig praktische Erfahrung und muss sagen, dass ich wirklich viel gelernt habe! Jetzt arbeite ich an einem weiteren Roboterprojekt bei dem ich den ATmega32 verwende, das Praktikum hat mir also viel gebracht!
Ich finde ASURO ist leicht zu bedienen, übersichtlich und benutzerfreundlich. Es werden wohl auch verschiedene Zusatzmodule rauskommen, also lasst Euch überraschen ;)
Pott
;-) Nein, da hätte man ja auch mal selber drauf kommen können...
Danke für den Tip
MFG Moritz
EDIT:
Mein Kommentar bezog sich auf die Helligkeitdifferenz-regelung.
Nächste Seite nicht gesehen ;-)
Ja, finde ich auch gut.Zitat:
Zitat von Manf
Nein, bei mir nicht, außer an meinem alten Rechner mit dem Flashen.Zitat:
Ich wollte eigentlich noch mal wissen wie vollständig die Roboter sind und ob es noch Probleme mit den elemataren Funktionen gibt.
Das geht mir auch so, deshalb habe ich mich in den vergangenen Tagen mit asuro.c und asuro.h beschäftigt, aber noch nicht alles verstanden.Zitat:
snip... Ich glaube irgendwie, daß ich den Funktionsumfang, der sich bietet noch nicht voll nutze.
Nein, habe ich noch nicht. Die Kabelbinder habe ich unter den Entstörkondensatoren durchgezogen. Die Motoren sitzen eigentlich ziemlich fest, habe ich nicht so erwartet.Zitat:
snip... Ich habe die Motoren noch an Kabelbindern, hat sie jemand schon angeklebt?
Hast Du das schon umgelötet?Zitat:
snip... Ich werde das mal angehen mit der Buchsenkombination vorne im Asuro.
Gruß
Torsten
@ Gast:
bist du derjenige von der Prosiebenseite, der einen Bericht geschrieben hat? Wenn ja, hätte ich da eine Frage an dich.
MFG Moritz
Ja, (ich hätte vielleicht schönere Buchsen nehmen können).Zitat:
Hast Du das schon umgelötet?
Etwas stört mich die Anordnung außerhalb vom Rastermaß. Da würde ich bei Gelegenheit gerne noch was ändern.
Manfred
Wenn ich mich recht erinnere ist das & bitweise in C und das && logisch.Zitat:
And heiß "&"
Or heißt "|"
NOT heißt !
So sollte es auch gehen:
if (a==1) & (b==2) & (!(c=3))
{
puts "Bedingungen erfüllt";
}
Gilt für alle:
| bitweise OR || Logisch OR.
& Bitweise AND && Logosch AND
Also müsste das if ( (a==1) && (b==2) && (!(c==3) ) heissen
wobei das letze auch ohne klammer geht, aber man immer klammern sollte allein schon wegen der ordnung