Robotron T2

Zitat:

Zitat von oratus sum

Ich habe auch dieses Embedded-Board gesehen, aber ich frage mich wieso jemand Windows oder Linux für sowas verwendet? Da gehen ja schon ein haufen Ressourcen für Hintergundprozesse drauf.
Klar das Teil hat dann Multithreading aber mein C-Controll II hat das genauso.

USB hat auch mein Bot (Host) und dadurch ebenfalls WLan, Bluetotooth hängt an meinem UART.

Daher sehe ich den Sinn dieser Boards nicht.
Oder liege ich da falsch?

Nöö,richtig.Das hat einen einfachen Grund. Ich kann ziemlich einfach Bilder der USB Cam per Wlan streamen. Bei jedem anderen Board müsste ich mir das selber schreiben. Der Rest (PWM Kanäle, USB, RS232, RS234 etc.) sind dann nice to have. Dafür bräucht ich das Board sicherlich nicht.
Das war wirklich die einfachste Lösung, einstecken und losgehts...

Zur Odometrie:

Ich habe fürn Versuch mal einen TCST1103 (Gabellichtschranke) auseinander genommen und ihn nebeneinander geklebt. Was anderes hatte ich grad nicht zur Hand. Ich werde mir morgen mal Lackstifte besorgen und ausprobieren, was am besten reflektiert.

Meine Getriebe laufen abgedeckt relativ ruhig und ein bißchen rasseln darf er ;-)

Die letzen Tage hatte ich mal wieder Zeit ein Stück weiterzumachen.
Da die Zusatzplatine noch nicht angekommen ist, habe ich mich mit den GP2D12-Sensoren beschäftigt.
Ich wollte den Bot endlich mal alleine fahrrn lassen.
Ich hab die Spannung für die für mich interessante Entfernung bestimmt (10-35cm) und den Programmcode des Motorboards angepasst.

Ich verwende eine einfache IF-Anweisung, die je nach Hindernisseite entscheidet ob er sich nach rechts oder nach links drehen soll, um dann sein Fahrt fortzusetzen.

Also schnell noch ein zusätzlichen Akku angeschlossen, die Sensoren provisorisch an der Front befestigt und ausgerichtet und ab gehts durch die Bude. =D>
Ich hätte auch gerne ein Video gemacht, hatte aber mit dem Not-Aus in der Hand hatte ich genug zu tun, um größere Beschädigungen an Mobilar und Bot zu verhindern ;-)

Trotzdem bin ich fürs erste sehr zufrieden.

Problem bestehen nur wenn er grade auf Hindernisse zufährt und nicht entscheiden kann ob er nun nach links oder rechts drehen soll. Er bleibt dann stehen. Stuhlbeine sind auch problematisch. Er hat sich manchmal übersehen und dann sind sie genau in den Sensor gecrasht. O:)

Hat jmd. eine gute Idee hinsichtlich der Entscheidungsschwelle? Ein zusätzlicher Sensor wird sicherlich auch nicht schaden.

Hier noch 2 Bilder vom Testaufbau:

Bild hier

Bild hier

Hi,

für kollisionsvermeidung ist ein ultraschall-sensor besser geeignet den der nimmt durch seine keule ein breiteres feld wahr als der ir-sensor der quasie nur einen strahl wahrnimmt.

Hab ja noch einen SRF02 hier liegen. Der sollte ohnehin verbaut werden.
Wie vermeide ich allerdings die Entscheidungsfalle?

Daran grübele ich gerade.
Im Moment arbeitet mein NiboBee so, dass der Sensor permanent geschwenkt wird- so kann ich die Umgebung (da ich bautechnisch nur rund 90° Schwenkbereich habe, beschränken wir uns auf: Umgebung _vor_ dem Roboter) ziemlich präzise vermessen. Anfängliche Bedenken, dass der Sensor mit recht schmalen Hindernissen Probleme haben würde, haben sich nicht bestätigt: nen aufrecht stehenden Bleistift erkennt meiner auf 50cm problemlos.
Derzeit (mir fehlt noch die Software dafür, bin gerade in der Grübelphase) kann der Sensor Hindernisse im Erfassungsbereich lediglich feststellen und deren Richtung auf dem Display ausgeben.
Da man aber die Entfernung ja _auch_ (tut meiner derzeit gar nicht) vermessen kann, reicht das aus.
Falls du den oder die Sensoren nicht schwenken willst oder kannst, kannst du auch den ganzen Roboter drehen, muss man ja nicht dauernd.
Aber _so_ kann man auch problemlos ausmessen (bzw. berechnen) wo genug Platz zum durchkommen ist.
Der Rest ist dann eher Wegfindung nach dem Motto: welche Variante ist günstiger zum Ziel.

Meine Methode will ich später noch verfeinern (um Zeit zu sparen) indem ich grobe Langstreckenmessungen mache und nur in eine feinere Auflösung gehe, wenn es nötig ist.

Ans Schwenken habe ich auch schon gedacht. Servos und IR bzw. US Sensoren hab ich ja noch genug da.
Was schenkst Du? Einen IR-Sensor oder einen US?
Wie sieht Deine Auswertung aus?
Programmierst Du in C?

Hey,

Wie du bei mir sehen kannst habe ich ebenfalls eine Kombination aus US und IR Sensoren auch SRF02 und die GPD Sensoren.

Zuerst habe ich mal die SRF02 Sensoren etwas weiter hinten montiert damit auch Hindernise direkt vor dem Bot erkannt werden - der misst ja nur bis minmal 10cm oder so.

Ich habe dann ganz vorne auf einen Serv ein GPD IR Sensor angebracht. Ich empfehle dir auf jeden Fall den IR Sensor zum schwenken weil du nur sp genau feststellen kannst ob du fahren kannst oder nicht. Bei meinem Algo habe ich noch implementiert, dass er autmatish Zuerst in die Richtung schaut in der der vorherige Algo die Richtung berechnet at. Also Algo1 berechnet Fahrtrichtung und legt die Motorrichtung und Geschwindigkeit fest. Algo2 schaut dann in die errechnete Richtung schaut obs frei ist wenn ja werden die erechneten Werte an die Fahr-Funktion weitergegeben.

Ich werde dann bald ein Video machen. Es funktioniert nämlich sehr sehr gut. Da ich einen eigenen IR-Sensor and en Seiten habe kann icha uch schön entlang an einer Wand fahren. Dazu drehe ich einfach den Vorderen Sensor in Richtung Wand und kann so schön Regeln.

Beim US Sensor hast du dann weider das Problem, dass die Servoposition ekannt ist aber nicht wo das Hindernis tatsächlich ist. Maximal Links/Rechts kann unterschiedenw werden. Bei Vorne hast du schon Probleme denn wenn ein wenig links oder rechts sich ein Gegenstand befindet in weitere Entfernung kannst du dir nciht mehr sicher sein. Beim IR weißm du 100%, dass vor dem Sensor kein oder ein Hidnernis ist.

Bei meinem Algo gibt es so wieder keien harten "nur" Links oder "nur" Rechts, es ist ein schöner fortlaufender Prozess.

Ich werd jetzt mal das Video machen :-D

Ich habe einen IR-Sensor, den Sharp GP2Y....der zwischen zehn und 80 cm misst.
Habe mich für den entschieden, da ich denke, dass mein NiboBee mit 80cm allemal auskommt und wenn er näher als 10cm dran ist, hilft eh nur noch Stop und Rückwärts. ;)

Ausgewertet wird analog (grundsätzlich jedenfalls) per AD-Wandler vom AtMega16 (hat ja genug Ports).
Derzeit allerdings "reagiert" mein Sensor nur auf einen fest voreingestellten Wert, aber da der nur eine Variable ist, kann ich den zur Laufzeit mühelos ändern und somit schön genau messen.
Geht auf jeden Fall genauer als auf den cm.
Eine wirkliche Entfernungsmessung habe ich _noch_ nicht ins Programm integriert, eigentlich hatte ich vor, ihn erstmal digital zu benutzen, das heisst, dass die Biene einfach erkennen soll: da gehts nicht lang...und nen anderen Weg suchen.
Programmiert wird in C mit dem AVR-Studio, ja.

Die Vorgehensweise ist momentan so, dass im Hauptprogramm ständig ein Unterprogramm aufgerufen wird, in dem das Servo jeweils einige Grad geschwenkt wird (wechselweise von rechts nach links bzw. umgekehrt) und bei jeder Richtungsänderung der Sharp abgefragt wird (derzeit wird ein Mittelwert aus je fünf Messungen gebildet, ich hatte erst zehn, aber da dauerte das scannen zu lange).

Der Sharp wird (unter Zuhilfename der NiboBee-Bibliothek) so abgefragt:

Code:

int Sharp(void) { sharpResult=0; // Ergebnis zurücksetzen int16_t sharpTemp=0; // temporäre Variable zum messen int8_t i; for (i=1; i<=5; i++) { // Sharp mehrmals abfragen sharpTemp=analog_getValue(ANALOG_EXT3); // ADC-Wert holen sharpResult=sharpResult+sharpTemp; // Ergebnis aufaddieren delay(5); } sharpResult=sharpResult/5; // Mittelwert bilden lcd_setCursor(0,2); // Ergebnis ausgeben printf("Sharp:%4d",sharpResult); return 0; }

Damit sind Messungen im Milimeterbereich drin, auch wenn er selbst bei um die 5cm (so lange steigt der Wert) nur auf ca. 600 kommt, anstelle der maximal möglichen 1023. Noch näher an einem Hindernis sinkt der Wert wieder rapide.
Je weiter weg das Hindernis ist, umso geringer ist der Wert, ab jenseits der 80cm gibts nur noch Werte zwischen 10 und 20, wahrscheinlich "rauscht" da irgendwas.

Gescannt wird so:

Code:

int Scan(void) { while(servo<servo_maxLinks) // nun stückweise nach links schwenken { i=0; servo=servo+servo_scanStep; Sharp(); // Sharp abfragen if (sharpResult>150) // wenn Sharp was findet... { i=servo-(servo*2); // Wert Servo negieren i=i+155; // i wieder positiv machen i=i*10; // um Kommarechnung zu vermeiden CSp=i/56+2; // Ergebnis auf die Skala aufteilen lcd_setCursor(0,1); printf(" "); lcd_setCursor(CSp, 1); printf("\x5e"); delay(10); } delay(50); // Zeit fürs Servo } while(servo>servo_maxRechts) // stückweise nach rechts schwenken { i=0; servo=servo-servo_scanStep; Sharp(); // Sharp abfragen if (sharpResult>150) // wenn Sharp was findet... { i=servo-(servo*2); // Wert Servo negieren i=i+155; // i wieder positiv machen i=i*10; // um Kommarechnung zu vermeiden CSp=i/56-2; // Ergebnis auf die Skala aufteilen lcd_setCursor(0,1); printf(" "); lcd_setCursor(CSp, 1); printf("\x5e"); delay(10); } delay(50); // Zeit fürs Servo } return(0); }

Da der Wert servo_maxLinks höher als servo_maxRechts ist, die umständliche Umwandelei, damit ich am Ende auf meine Displayzeile von 16 Zeichen komme.
Ergab sich halt durch meinen Aufbau so, das Servo bedient den Sharp über ein Gestänge mit Kugelköpfen (wäre auch anders lösbar gewesen, aber nicht so schön).
servo_scanStep ist auch eine Variable, ich arbeite momentan lediglich mit einem Zehntel der möglichen Servoauflösung, reicht, um 4cm breite Hindernisse auf nen halben Meter zu entdecken. Der Sharp ist also wirklich ziemlich scharf. ;)
Höher Auflösen werde ich nur, wenn es mir zu unpräzise wird, das geht dann gewaltig auf die Zeit alles.

Vermutlich geht das Ganze auch effizienter zu programmieren, aber _es_ funktioniert bis auf eine Ungenauigkeit in der Display-Ausgabe, die vom runden her kommt.
Als nächstes werde ich (nur dann ist eine leidlich effiziente Wegfindung möglich, wenn die Anzahl und Entfernung der Hindernisse unbekannt ist) mal eine vernünftige Entfernungsmessung einbauen und vielleicht habe ich bis dahin dann ein paar Ideen, wie weiter.

Ausserdem überlege ich, ob ich den Sensor nicht wenige Grad nach unten neigen sollte, dann kann man auch Abgründe (meine Biene lebt gewöhnlich auf dem Tisch) gleich noch mit erkennen.

Hab mir grad mal Dein Code angeschaut. Ich werte meine Sharps auch so aus. Allerdings mache ich nur 4 Messungen und breche dann meinen 10Bit Wert (0-1023) auf einen 8Bit Wert(0-255) runter.

Die Umrechnerei machste ja nur für Dein Display.
An welchem Port hängt Dein Servo? Welchen Atmega nutzt du?
Wie sieht die Init für den Servo aus?
Dein Sharpwert liegt bei 150. Dann ist ja sicherlich noch einiges an Platz zum ausweichen ;-)

Ich nutze 220. Werde mal den Wert runtersetzen und ne Testfahrt machen.

Ich benutze den NiboBee, der hat schön viele Erweiterungsports.
Ausserdem glaube ich, noch nicht ganz so weit zu sein, nen eigenen Roboter zu bauen (der HL-Walker Buldog wäre aber wohl meine nächste Wahl).
Schaltplan gibts bei Nicai-Systems.de
Konkret hängen Sharp und Servo bei mir am Port X3, die genaue Belegung kannst du dem Schaltplan entnehmen.

Der Code, um das Servo anzusteuern, stammt nicht von mir, ich glaube, radbruch hat den geschrieben (schwirrt im Forum herum) und ist, an Einfachheit, wohl schwer zu überbieten, es wird Timer2 (AtMega16) benutzt:

Code:

TCCR2 = (1 << WGM21) | (1 << CS20); // CTC-Mode, no prescaling, no OC2-PIN! OCR2 = 208; // 36kHz @15MHz TIMSK |= (1 << OCIE2);

Die ISR dazu sieht so aus:

Code:

//----------------------------------- Timer2-ISR -------------------------------------------------- ISR (TIMER2_COMP_vect) { if(count_serv>servo) PORTC &= ~(1<<PC3); else PORTC |= (1<<PC3); if(count_serv<1440) count_serv++; else {count_serv=1; if(p) p--;}; }

Die Variable servo() legt die Soll-Position des Servos fest, Mittelstellung ist bei ca. 100 (die habe ich, ebenso wie servo_maxLinks und servo_maxRechts in Konstanten gespeichert, somit ist das Ganze supereinfach trimmbar, indem man den entsprechenden Wert ändert), da ich nicht den vollen, möglichen Ausschlag benutzen kann wegen meiner Umlenk-Hebelei.
Man muss nur dem Servo genug Zeit geben, die vorgegebene Position auch wirklich zu erreichen, ich hab ein, leider etwas lahmes HS55 drin, wenn mir mal ein schnelleres in die Finger kommt (muss ich mal meine Wühlkisten durchsuchen) wird das Ding ausgetauscht, Kraft braucht es für das bisschen Sensor wirklich nicht.

Ich glaube, einfacher gehts kaum mehr. Indem man servo() in Stufen ändert, kann man ziemlich Zeit sparen bzw. erstmal gröber scannen und bei Bedarf (die Variable heisst bei mir servo_scanStep, und hat derzeit den Wert 10) einfach servo_scanStep verringern, um feiner suchen zu können.
Derzeit braucht ein voller Scan (zwischen servo(55) und servo(155) von rechts nach links oder umgedreht rund anderthalb Sekunden, dabei liegt der Erfassungswinkel bei ca. 90°, das reicht für vorne.
Mit geschickter Bauweise lässt sich da allerdings weit mehr herausholen, die meisten Servos schaffen ohne weiteres 180°, und wenn man den Sharp direkt aufs Servo montiert hat man die auch. Zwei reichen also für ringsum, und wenn das Servo oben drauf ist, reicht ein Servo sogar für beide Sensoren. :)
Hinten werde ich irgendwann einfache, digitale IR-Sensoren montieren, denke ich mal.

Was den Wert 150 angeht: so doll ist das gar nicht, wenn die Biene Vollgas fährt, ist sie ganz schön flink, und wie gesagt: eine volle Scanbreite dauert über eine Sekunde. Werde sie aber wahrscheinlich sowieso nicht mit Vollgas betreiben, von daher _wird_ es reichen (notfalls kann man auch mal anhalten).
Grundsätzlich kann man aber auch bedeutend schneller scannen, indem man die Steps erhöht, nur erkennt der Sensor dann eben nur noch breitere Hindernisse. Ich aber denke da (im Hinblick auf für später geplante Dinge) an Dominosteine oder Streichholzschachteln, darum mag ichs nicht gröber haben. Weitere Temposteigerung wäre eventuell noch mit den Warteschleifen fürs Servo drin, die sind erstmal lang genug, damit es _sicher_ klappt (wie gesagt, mit nem schnelleren Servo schaut auch das anders aus).
220 gibt mir der Sharp bei etwas über 20 cm, das ist bereits sehr nahe (wie gesagt, aus irgendeinem Grunde komme ich auf einen Maximalwert von rund 600, das scheint an der Bibliotheksfunktion zu liegen, so ganz blicke ich das alles auch noch nicht).
Man braucht ja auch zum rangieren noch etwas Platz.