Druckbare Version
...her damit!Ich denk aber das läuft!Warum auch nicht?Sooo anspruchsvoll ist Simulink aber auch nicht...
Hatte ich auch gedacht ABER der Stromverbrauch ist wahnsinn.Hatte mir auch nen µ-ITX Board geholt aber die lieben Dual-Cores fressen eben.Zitat:
Zitat von ppppp
So ein Atom Netbook wird ja heutzutage mit 10 Stunden angepriesen, da vermute ich dass es 5-6h machen kann. Bildschirm aus...
Vielleicht ein Grund für ne Anschaffung ;)
Es geht weiter...langsam aber unaufhörlich.
Auch wenn ich schwer beschäftigt bin, find ich doch zwischen Schlafengehen & Aufstehen noch Zeit.
Der Aufbau hat Form angenommen und das embedded Board ist befestigt. Dank Klettverschlüssen kann es nicht mehr rumwackeln.
Der Grüne Akku diente nur als Platzhalter und wird noch ausgetauscht.
Als nächstes habe ich mich mit dem Servo Controller Board beschäftigt, welches ich nur per Remote Desktop ansteuern kann. Der Pan & Tilt Kopf bewegt sich fast so wie er soll. Es ist erstmal nur festgeklemmt. Ich weiß noch nicht genau wo ich ihn unterbringe und festmache.
Der Aufbau:
Bild hier
Der Testaufbau mit µServo Board:
Bild hier
Das µServoboard hängt am TTL RS232 des embedded Boards.
Sieht gut aus!
einen hinweiß hätte ich aber noch. und zwar würde ich die grundplatte an den ecken aberrunden oder einen kantenschutz anbringen. ich hab mir hier schon einige kratzer in die möbel gemacht weil sich mein bot selbstständig gemacht hatte.
gruß,
Bammel
Hi Bammel, danke für die Blumen.
Ans abrunden habe ich auch schon gedacht, aber da er noch nicht selbstständig fährt, ist das noch nicht akut ;-)
Werde ich aber noch machen, sobald mich ich überwinden kann die Odometrie endlich fertig zu machen...Ich muss die SFH9202 endlich mal bestellen und die Encoder aufbauen :-(
Ich konnt es doch nicht abwarten. Habe also nochmal schnell Dremel & Feile bemüht und den Pan & Tilt Kopf angebracht zum spielen :-)
Die kleine Platine hinter dem Kopf ist das µControl Servo Board. Das ist noch nicht befestigt.
Bild hier
Nun muss ich mir nur noch Gedanken machen wie ich das Platinchen der VX-800 Usb Cam an dem Pan & Tilt Kopf befestige.
Die Steuerung dank der Software von Jaecko ist kinderleicht.
https://www.roboternetz.de/phpBB2/ze...729&highlight=
So die Cam ist mittlerweile am Pan & Tilt Kopf befestigt und liefert klasse Bilder. Nebenbei habe ich noch die beiden Akkupacks zusammengelötet (6x 1,2V mit 3500mAh) und verbaut. Einmal im Originalbatteriefach und einmal unterm ebbedded Board.
Zusätzlich habe ich noch eine Aluprofil an der Seite angebracht, um den USB-Buchsen,dem Schalter und der Ladebuchse halt zu geben.
Die letzten Tage habe ich dazu verwendet die UART-Verbindung zwischen Board und Motortreiberboard zum laufen zu bringen. Das Board kann jetzt Befehle entgegennehmen und darauf reagieren. Die Befehle sind noch einzelne Buchstaben. Ich kann den Bot mittels W,A,S,D ausm WLAN sogar fahren lassen =D>
Als nächstes werde ich mir eine Befehlsliste zusammenstellen. Mein eigentliches Ziel ist es ein Commando-Parser zu integrieren, damit man sich nicht die einzelnen Buchstaben merken muss.
Und ja die Odometrie fehlt immer noch :-(
weiter gehts... =D>
Jetzt geht voran, wenn auch nur langsam dafür aber stetig ;-)
Ich habe mich rangesetzt und auf die schnelle ein zusätzliches Board entworfen.
Bild hier
Technische Daten:
- Stromverteiler:3 x Akkuspannung (7,2v), 3 x 5V & 3 x beliebige Spannung (zwischen 0V - 7,2V) auf Stiftleiste bzw. Schraubbuchse
- 2 x DC/DC Wandler mit Step Down Schaltregler mit StausLED,mit hohem Wirkungsgrad,denn Wärme hab ich schon genug. Beide Ausgangsspannungen sind grundsätzlich frei wählbar. Eine wird 5V betragen die zweite ist noch offen.
- 2 x MAX232 auf Sockel : einmal anschließbar am ATmega32 oder embedded Board, der zweite ist komplett frei wählbar(Reserve)
- gesicherte Stromversorgung (mit Sicherung)
- 8 x ADC auf Stiftleiste
- 5 x I2C Verteilung mit Abschlusswiderständen
- Expansionport(mit allen Spannungen) für Display
- Poti für Kontrast (Display)
- Alle I/Os auf Stiftleiste
- 3 StatusLEDs (rot,gelb,gruen) zur Ausgabe von Fehlern etc.
- Schalter
- ATmega32 auf Sockel mit 16MHz SMD Quarz
Das Board soll dann alle Sensoren (die nicht mehr aufs Motorboard passen) auswerten. Habe noch 5 Sharps liegen und einen SFR02.
Ein Sharp wird auf einem Servo platz nehmen.
Ich glaub das war soweit alles. Werd das alles nochmal sacken lassen und dann die Tage das Board bestellen. \:D/
..und weiter gehts
super, das Projekt gefällt mir immer besser, geht ja beständig vorran ;)
Ist ne gute Idee mit der Zusatz-Platine, mal sehen, was du da noch so alles mit anstellst \:D/
Hey,
Dein Projekt ist ja ziemlich interessant.
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. Und wenn du sowieso Boards entwirfst ist es ja nicht so ein großer Aufwand. Für 300 Kannst du außerdem 4 Riesen-Boards mit allem Drum und Dran Planen und dann anfertigen lassen (wie ich), das dann ungefähr 50-Mal mehr kann als so ein Embedded Board.
Oder liege ich da falsch?
Noch wegen der Odometrie:
Ich hab gesehen, dass deine Gleiskettenglieder nicht eben sind. Bei mir sind diese Eben, zumindest dort wo mein Sensor draufschaut. Du musst drauf achten, dass wenn du die Kettenglieder färbst, dass du bei jeder Kette nur eine Ebene verwendest. Außerdem sollten keine "Löcher" vom Sensor gesehen werden.
Achja,
Die CNY sind IR-Sensoren. Das heißt, dass Weiß nicht unbedingt Weiß ist. Nimm deine USB-Kamera, schalt das Licht ab und leuchte mit einer IR-Diode auf deine Weiße Farbe und auch auf die Gleiskette. Es kann vorkommen, dass deine schwarzen Gleisketten IR sehr gut zurückwerfen und deine Weiße-Farbe das IR verschluckt.
Da ist schon so mancher liniensuchender Roboter dran gescheitert :-D
Nur mal so als profilaxe, damit dich nichts überrascht :-D
Hab übrigens das gleiche Metallgetriebe, ist aber bei mir ziemlich laut...
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.Zitat:
Zitat von oratus sum
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:
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.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;
}
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:
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.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);
}
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:
Die ISR dazu sieht so aus:Code:TCCR2 = (1 << WGM21) | (1 << CS20); // CTC-Mode, no prescaling, no OC2-PIN!
OCR2 = 208; // 36kHz @15MHz
TIMSK |= (1 << OCIE2);
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.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--;};
}
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.
Hi,
Ich habe so mal eine kurze Frage:
Du sagst unter 10cm ist sowieso rückwärtsfahren angesagt. Aber wie unterscheidest du was unter 10cm ist? Vielleicht ist es dir aufgefallen, dass der Graph von den GPD-Sensoren nicht immer eindeutig ist. Ich weiß es nicht genau wie es bei deinen Sensoren ist aber bei den 120ern ist die Spannung für 4cm und 2m gleich. Auch bei 10cm und >2cm ist es gleich. Daher ist es o, das du beim Hochpunkt des Graphen dein Minimalabstand haben solltest weil ab dort es nicht mehr eindeutig ist.
Und wegen dem Grenzwert des IR-Sensors
Wieso bastelt ihr nicht eine kleine Funktion. Dann könntet ihr aus IR-Sensor und Stellung des Servos direkt die PWM Werte für die Motoren errechnen so könnte man Hindernissen viel schneller und effizienter ausweichen.
Das bietet sich bei euch ja richtig an.
Und achja...
Da ihr alles auf eine Karte setzt also auf einen Sensor...
Würde ich mir überlegen nen kleinen software Tiefpass zu bauen um falsche Messwerte zu filtern. Das bewirkt manchmal wunder.
Lg
@oratus sum :
Ich glaube jetzt habe ich das in Deinem Thread erst richtig verstanden.
Du meinst, wenn der Sensor auf der rechten Seite ein Hindernis entdeckt, dann soll er direkt den PWM-Wert für beiden Ketten setzen. In diesem Fall linke Kette langsamer, rechte Kette schneller, damit er sich nach links dreht. Dadurch würde der Bot direkt reagieren und das sehr flüssig. Hindernisse auf der linken Seite, würden dann die rechte Kette langsamer und die linke schneller werden lassen. Das scheint mir ne klasse Idee zu sein!!!
Meinst Du das bei Dir mit der Fuzzy Logic?
Was Rabenauge mit den 10cm meint, ist bei mir genauso. 10cm entsprechen bei mir 2,7V. Was nahezu dem maximal Wert entspricht. Bei 10cm heisst es also Stop in jedem Fall und dann rückwärts. <10cm ist nicht detektierbar, das haste recht.
Ja ganz genau so habe ich das gemeint.
Die Formel die ich in meinem Thread gepostet habe, habe ich aus den dort genannten gründen selbst aufstellen müssen.
Es funktioniert aber wirklich sehr gut. Das Drehen ist nämlich sogut wie nie nötig, das ist ja der Clou dabei. Würdest du ein Slalom aufstellen würde dein Bot mit dem Grenzwert zu nem Hindernis hinfahren, Drehen,Vorwärts, Drehen Vorwärts fahren.
Mein Bot fährt dann tatsächlich ein Slalom, da er die Kettengeschwinigkeit direkt über diese Funktion "regelt". Die Zahlen stimmen nicht mehr ganz von der Funktion, da ich den Messbereich erweitert habe.
Kurz zur Erklärung für die Zahlen:
49: Das ist die "Mitte" des Sensors. Ich messe den Bereich von 25cm (=Stoßstange des Bots) bis 72 cm, die Mitte ist 49cm. (eigentlich 48.5). Bei 49 habe ich meinen Wendepunkt der Funktion. Dort schlägt er von Vorwärts auf Rückwärts um. Also bei einer Kette.
/2 :
Das dvidiert durch 2 beweirkt eine Abflachung der Funktion. Je größer die Zahl desto langsamer schlägt er um. Aber desto weicher ist auch die Steuerung. Ich habe da 2 genommen weil bei mir die PWM-Werte nur von 150-255 die Motoren beschleunigen. Hast du eine höhere Auflösung solltest du unbedingt eine höhere Zahl nehmen.
0.5:
Einfach lassen. Die Sigmoid-funktion muss einen estimmten Bereich haben, damit Sie "funktioniert"
510:
Ist quasi der Verstärkungsfaktor.
Er sorgt dafür, das letztendlich die Werte wirklich von -255 bis 255 reichen. Du musst die 2 und die 510 aufeinander abstimmen.
Ist nicht so kompliziert wie es sich anhört.
Ich würde bei dir das folgendermaßen realisieren:
Dein Bot fährt Vorwärts. Anstatt deine gesamte Umgebung zu scannen würde ich abwechselnd Links/Rechts schauen, falls ein Hindernis entdeckt wird mit immer größeren Ausschlägen. Also:
Servo = 0° (Hindernis)
Servo = -5° (Hindernis)
Servo = +5° (Hindernis)
Servo = -10°(Hindernis)
Servo = +10°(frei)
So kannst du immer zwischen Links und Rechts unterscheiden und schaffst dir zwei "logische" Sensoren, einen für Links und einen für Rechts. Wenn du jetzt noch die gemessenen Werte mit meiner Funktion koppelst sollte das funktionieren.
Das setzt natürlich voraus, dass dein Servo schnell genug ist. Mit der Funktion kannst du sowieso aber die Geschwindigkeit begrenzen also wenn der Servo zu langsam ist.
Das mit dem Links/Rechts schauen hat den Vorteil, dass es viel schneller geht. Während du beim Scannen als von -90 bis +90 abscannst, was ja ein Winkel von 180° ist bzw bei dir ja 100 Schritte. Und hier kommt wieder der Vorteil des IR-Sensors: Es reicht nur eine kleine Drehung um eindeutige Ergebnise zu erlangen. Beim US Sensor müsstest du viel mehr drehen.
Hier nochmal die Funktion zu verdeutlichung:
Bild hier
Bild hier
falls du matlab hast, hier die Funktion:
y=(int32(((1.0 ./ (1.0+exp(-((x-49)/4))))-0.5)* 510))
bzw kannst so wie es ist für dein C übernehmen. Ich weiß nicht ob das so geht mit dem avgcc.
das int32() nimmt nun den Ganzzahligen Anteil. das exp() ist einfach e^() e ist ja eine Konstante.
Achja:
Nett ist auch, dass du vollkommen ohne if-Abfrage auskommst. Wie du beim Grpahen siehst, egal wie groß oder klein die Zahlen sind, aber einem geweisen Punkt bleiben sie immer in deinem Bereich (bei mir 255).
also quasi:
lim(f(x)) = 255
x->∞
und
lim(f(x)) = -255
x->-∞
Wenn du mir die PWM-Werte deiner Motoren sagst und die gewünschten Bereiche kann ich dir die Funktionsgleichung gerne aufstellen, du müsstest si dann nurnoch anpassen bzgl der Servogeschwindigkeit,
Falls noch Fragen offen sind einfach stellen. Ich drücke mich manchmal sehr ungeschickt aus :-D
Ich habs soweit verstanden. Ich komm auf Dein Angebot der Kontrolle zurück, sobald mein Servo an OCR2 läuft, meld ich mich...
Ohh man, sobald ich den zweiten Timer aktiviere mit
TCCR2 = (1<<WGM20)| (1<<WGM21) | (1<<COM21) | (1<<CS22) | (1<<CS20); scheint der kleine Atmega8 die Ohren anzulegen.
Ich bekomme übern UART nur noch halbe Befehle und kann auch keine absetzen die er versteht. Und die beiden PWMs die laufen, setz er beim Auslesen der jeweiligen ADC mit Verzögerung...argg das kann ja wohl nich sein...H I L F E!
Hast du schon nen Timer laufen?
Ich kenne mich mit den avgcc nicht aus. Halbe Befehle sehen nach zu kleinem auswärtspuffer aus und gleichfalls das er die Befehle nicht versteht.
Wie greifst du auf UART zu? Per Interrupt oder sub?
Wie oft wird denn dein Timer aufgerufen und was muss der alles machen? Sieht mir irgendwie danach aus, dass dein Timer alles blockiert.
Derzeit laufen 2 8-Bit Timer für 2 PWMs (für die Motoren).
Der UART ist Interrupt gesteuert. Kommt ein Zeichen an, dann wird es verarbeitet. Außerdem laufen 4 ADCs. 2 sind fürs Einstellen der PWM per Hand übern Poti (für Testzwecke, wird nachher anders gelöst) und 2 ADCs sind für das Einlesen der IR Sensoren.
Eigentlich laufen noch 2 ADCs,diese messen die Stromaufnahme der VNH2SP30, sind aber abgeschaltet.
Das wars soweit. Takt ist 8MHz, sollte auch ausreichen...
Ich weiß nicht wo das Problem ist.
Noch sind ja nicht mal alle Hardwareresourcen belegt :-k
@oratus sum : so ganz habe ich deine Erklärung noch nicht verstanden, aber für reinen Hindernislauf klingt das recht gut. Das schaue ich mir auf jeden Fall noch mal gründlich an nachher.
Funktioniert das auch, wenn "etliche" Hindernisse im Weg sind, in verschiedenen Entfernungen?
Mir geht es nämlich mittelfristig schon darum, auch die Positionen der Hindernisse genau zu detektieren, um später beispielsweise Hindernisse ganz gezielt (und möglichst genau) anfahren zu können.
@Kellerkind: hast du in den ISR`s irgendwelche zu lang dauernden Geschichten drinnen?
Das Problem hatte ich auch schon mal, während eine ISR läuft, geht nix anderes.
Hast an meinem Beispiel ja gesehen, wie knapp ich die halte- das _ist_ die komplette ISR. Soweit ich weiss, werden Interrupts, die während einer ISR auftreten, auch aufgehoben und danach abgearbeitet, also liegt dort vielleicht der Hase im Pfeffer (die ISR wird_wieder_ aufgerufen, ehe der Rechner zu was anderem kommt).
Ich habe drei Timer laufen (Timer0 für allgemeines, Timer1 ist für die PWM beim NiboBee und Timer2 fürs Servo)-> keine Probleme.
Mahlzeit :-D
Ich habe noch ein wenig rumgebastelt und meine Funktion etwas angepasst. Ich habe dir ja erzäht, dass meine Motoren erst so ab 150 losrollen. Dem entsprechend habe ich die Funktion angepasst.
Klar man hätte einfach sagen können wie mit Grenzwert,
wenn PWM unter 150 dann PWM = 150
bäh sowas mag ich nicht :-D
Das ist danna uch eine gerade Strecke im Graphen schaut unschön aus.
Deshalb habe ich diese gerade Strecke abgerundet. So sind zwar in der FUnktion zwei if-Bedingungen aber dafür reagiert er jetzt noch schöner.
Ich muss sagen ich bin nicht so gut in Mathe, das:
[0:150] soll heißen 0 bis 150. Also das Intervall 0-150
War mir jetzt unsicher ob das ein - oder : Zeichen ist.
Also hier:
Die Zahlen habe ich auch verändert... weiterhin gilt falls was unklar ist einfach Fragen :-D ich weiß ja nciht ob jeder meine chaotischen Gedanken nachvollziehen kann :-D
[edit]
@Rabenauge
Nunja das ist vorerst ein Antikollisonssystem. Es funktioniert mit dem Objekt die vor dem Sensor. Beim Ultraschall wirst d direkt nciht feststellen können wo sich das Objekt befindet. Es sei denn du machst eine Triangulation mit zwei Sensoren.
Mit dem IR weißt du schon wo sich das Objekt befindet, unzwar direkt vor dem Senor :-D. Da kannst du auch ur das messen was sich vor dem Sensor befindet.
Wieso willst du wissen wei viele Objekte es gibt? Wichtig ist ja nur ob du fahren kannst oder nicht.
Willst du eine Karte erstellen muss man die Sache anders angehen. Da ist dann wieder scannen angesagt aber die zwei Sachen sind von Grund auf verschieden. Entweder du erstellst eine Karte, berechnest den Weg und fährst oder du hast ein ACS, Antikollisionssystem, fährst und erstellst derweil die Karte, so werde ich es machen.
Also die Frage ist wieso du wissen willst wie viele Objekte vor deinem Roboter sich befinden.
Also mir hat deine Erklärung wunderbar weiter geholfen (ich bin die letzten Tage nicht zu gekommen), allerdings habe ich es erstmal mit einer, sagen wir, einfacheren, Formel versucht.
Im Grunde wird nur aus dem aktuellen Sensorwert immer dann ein Offset errechnet, wenn der Sharp was findet- das ergibt von ganz alleine eine Abhängigkeit (bei entfernteren Hindernissen ergibt sich also automatisch eine kleinere Abweichung der Soll-Geschwindigkeit).
Funktioniert _so_ primitiv bereits erstaunlich gut, wenn auch noch nicht wirklich praxistauglich (bis jetzt habe ich den Winkel, in dem der Sensor wirklich steht noch gar nicht weiter gewertet), kommt noch.
Hallo,
Das hört sich schonmal gut an. Es ist sowieso besser wenn du es langsam angehst, weil du es dann besser verstehst und besser auf deine Wünsche anpassen kannst.
Ich hab ja auch nicht gleich diese Formel aufgestellt und programmiert. Meien erste Funktion sah noch ganz anders aus. Dann habe ich es einfach angepasst.
Ich habe euch noch ein Video gedreht. Da sieht man schln wie das funktioniert:
http://www.youtube.com/watch?v=RRPJmG_tzRY
Bei der ersten Kiste fährt er scön ruhig und sanft eine Kurve um der Kiste auszuweichen. Bei der zweiten Kiste muss er sich aber schond rehen weil er sonst kollidieren möchte.
man sieht, dass der Roboter sowohl sanft Hindernissen mit einer leichten kurve ausweichen kann alsauch mittels Drehung bei nahen Hindernissen.
Lg
Ich habe am Donnerstag meine Platine geliefert bekommen und heute endlich auch die Zeit gefunden mich darum zu kümmern.
Bild hier
Habe die Platine bei Platinenbelichter bestellt. Preislich Top, Quali ne 2, weil 2 Löcher haben gefehlt, die Bohrdurchmesser haben teilweise nicht gestimmt und es war ein deutlicher Versatz zwischen Top & Bottom erkennbar (Vias)...bin aber insgesamt doch zufrieden für den Preis!
Die Platine war eigentlich anders geplant und so musste ich einiges improvisieren. Wichtig ist ja die Funktion ;-)
Habe alle DKs mit Draht gemacht und einige Pinheader musste ich von beiden Seiten löten...
Bild hier
Das Bestücken ging relativ fix. Die beiden MAX232 sind noch unbestückt und der zweite DC/DC Wandler dümpelt noch vor sich hin. Es fehlt mir auch noch ein Poti fürs spätere Display(habe kein passenden da,Klasse).
Ansonsten bin ich sehr zufrieden.
Das Problem mit der Servoansteuerung meines Atmega8s (Motortreiberboard) habe ich auch gefunden. Die ISR war nicht etwa zu beschäftigt, nein sie war garnicht vorhanden.
Der Servo lässt sich allerdings noch nicht bewegen...das kommt sicherlich noch ;-)
Sieht interessant aus. Teilweise auch SMD. Lötest du den µC immer direkt ein? Das ist ziemlich mutig wenn der mal den Geist aufgibt...
Ich kannte Platinenbelichter garnicht.Der macht das wohl per Hand wenn das so verrutscht ist. Wie viel hast du dafür gezahlt?
Die ersten Versuche meiens Maiboards habe ich auch selbst belichtet und geätzt, das ist wirklich schwierig Top und Bottom aufeinander zu bekommen. Das Bohren ist dann geduldsache :-D
Bin schonmal sehr gespannt wie es weiter geht.
Jupp teilweise SMD. Für den µC hatte ich eigentlich (jedenfalls dachte ich das) eine Fassung aber es kommt immer anders...Normalerweise nehm ich auch SMD µCs, doch diesmal hatte ich die nur in DIL und wenn er hin ist (was sehr schwer ist) krieg ich den da auch wieder raus ;-)
Habe für zwei Platinen (je halbe Euro 80x100) zusammen ~27€ bezahlt. Versiegelung mit Lötlack habe ich selber gemacht (0,80€ pro Platine gespart)
Hi kellerkind,
Mit welchem Betriebssystem betreibst du dein Embedded-Board nun eigentlich ?
Mich würde interessieren wie genau du das Kammerabild streamst.
Mich würde auch interessieren wie mana uf so einem embedded-Board die Ports anspricht, sprich PWM GPIOs und so weiter
Derzeit läuft ein sehr sehr abgespecktes WinXP. Mit nLite kann man sich selbst eine schmale Version basteln. Die Cam hängt am USB. Per Remote Desktop kann ich mir die Bilder anschauen. Das ist nicht die besten Lösung, war aber die schnellste ;-) Die Verzögerung ist aber sehr nervig!Zitat:
Zitat von fat tony
@oratus sum Die Ports kann man mit einer eigenen Lib ansprechen.
Alles was man braucht findet man hier:
http://robosavvy.com/forum/viewforum.php?f=17 (Hilfe)
bzw hier:
http://www.roboard.com/download_ml.htm
Hmm sieht zwar nett aus trotzdem sehe ich da keinen Vorteil zu einem selbstgemachten Board. Der Preis ist ja happig, dafür kann man 2 selbstgemachte Bestellen ohen Verschwendung von Ressourcen.
Klar USB ist ja nett aber das kann man ja ach lösen. Eine Webcam vielleicht nicht aber da würde ich wenn dann sowieso eine WLan Cam verwenden...
Wegen dem verzögerten Bild:
Es gibt ein haufen Freeware im WWW mit dem du Kamerabilder per TCP/IP übertragen kannst. Ich glaube sogar, dass der VCL player das kann.
Mensch Du bist aber auch hartnäckig O:)Zitat:
Zitat von oratus sum
Wie schon gesagt, daß war nur die erste Lösung für eine Cam und die komlette Steuerung für den Bot. Mittlerweile bin ich auch soweit, daß ich die Boards alle selber mache.
Das neue Board, was ich entworfen und bereits bestückt habe, reicht mir schon wieder fast nicht aus. Ich überlege grade ob ich nochmal eins mit einem größerem µC Bsp. Atmega128 TQFP mache....den gibts ja auch mit USB!
Da ich eigentlich so wenig wie möglich I/Os vom Atmega32 verwenden will (man weiß ja nie was noch kommt O:) ) hab ich mal schnell zwischendurch das GLCD (Winstar 12864B KS0108) an einen ATmega8 angeschlossen. Die Ansteuerung war super einfach.
Bild hier
Viell. ist es ja auch wirklich besser einen separaten Controller nur fürs Display zu nehmen, denn die Schriftarten schlucken jede Menge Speicher und das Display I/Os. Steuerung des Displays dachte ich macht man am besten über SPI oder I2C...wäre ja auch ne Lösung !!!???
Ich würde das GLCD auf jedenfall auf einen extra Controller legen aus den besagten Gründen. Und mit dem I2C ist es dann ja kein Problem.
Verwende doch gleich wie eich das Mega2560 Modul. Das hat den Vorteil, dass es ein haufen Schnittstellen drinnen hat und man sich nicht um den lässtigen Kram wie MAX232 FTDI chip usw kümmern muss.