Robotron T2

[kellerkind]

Hi Community,

nach sehr langem Mitlesen und selber basteln habe ich mich jetzt entschlossen mein Projekt hier vorzustellen, denn manchmal sind die Sichtweisen von außen sehr hilfreich. O:)

Ich beschäftige mich erst seit kurzem mit Robotern (knappes Jahr). Meine Elektronikerfahrung reicht wesentlich weiter zurück!
Mein erster Bausatz war der Nibo2. Der funktioniert auch auf Anhieb, allerdings kam schnell Langeweile auf und so entschied ich mich zum Selbstbau.

Die Grundplattform habe ich bereits fertig. Sie beruht auf eine Heng Long Jagdpanther 1:16 mit Metallgetriebe. Das ganze soll mit 2 Akkus (derzeit noch einmal Lipo und einmal NiMH) betrieben werden. Die Lipos versorgen die Hauptsteuereinheit, ein rb-100 Embedded Board mit WinXP / Linux und die NiMH versorgen den Stromhungrigen Antrieb.

Viell. mal ein paar Daten:
- Modell: Heng Long Jagdpanther 1:16 mit Metallgetriebe
- Akkus: wahlweise 6V / 12 V NiMH 3000mAh für Antrieb & 2 Lipozellen mit 1350mAh.
- Motortreiber: 2 x VNH2SP30 (wenn dann richtig ;-) )
- Motortreiberboard mit Atmega8, 2x VNH2SP30, 4xADC, i2C, RS232 und Not Aus
Hauptrechner:rb-100 technische Daten:
http://robosavvy.com/site/index.php?option=com_content&task=view&id=183&Itemid=135

Was ist geplant?
Irgendwann soll er sich mal autonom durch den Garten schlagen, Menschen und Tiere erkennen und diese mittels Cam ablichten. Dafür hat er eine Tag und eine Nachtkamera mit IR-Leds.
Seine Ergbnisse wird er per WLAN ins Netz stellen bzw. zu einem bel. PC übertragen von der er auch ferngesteuert werden kann.
Neben Ultraschallsensoren vorne hat er noch IR Sensoren an den Seiten und hinten bzw für den Frontnahbereich.

Aktueller Stand
Das Embedded Board läuft. Es bootet WinXP SP3 von einer SDHC Karte.
Das Motortreiberboard habe ich auch bereits fertig. Der Atmega8 meldet sich auch. Ich überlege derzeit noch wie ich die Motorboard ansteuere. Es bestehen die Möglichkeiten COM & i2C. Beides wird von meinem rb-100 unterstützt.
Mein Programmierwissen reicht für blinkende LEDs mit Atmel oder PIC, PWMs, RC5 und RC6 Code einlesen... UART und i2C habe ich noch nicht programmiert.

Alles in allem ein großes Projekt für das es weder einen zeitlichen noch einen Kostenrahmen gibt. Ich möchte vorallem mich mit der Programmierung beschäftigen und entwickle daher alles selbst.

Nächster Schritte und Gedanken:

- Ich wäre derzeit sehr zufrieden wenn ich ihn über mein embedded Board fahren lassen kann. (vor & zurück)
- Wie & wo bekomm ich am besten einen HAL oder Inkrementalgeber verbaut ohne Motoren o. Getriebe zu tauschen?
- Was wäre die beste Akkulösung. Viell. doch ein Bleiakku (bestes Preis/Kapazitätsverhältnis)?
- Wenn er fährt, brauch ich dann auch noch logischerweise eine Ladeschaltung.

Ich bin für jede Anregung oder Kritik offen.

[ppppp]

Hallo,

ich würde auch gerne einen Panzerunterbau verwenden. Hast Du schon Erfahrung zu diesen Fragen ;)

Hat das Fahrgestell des Jagdpanther vorteile bspw. Gegenüber dem Bulldog?
Ist der Panzer laut mit Metallantrieb/Ketten?

Kannst Du etwas über die Zulading sagen? Ich würde gerne einen 3Kg 12Ah Bleiakku verbauen + Elektronik. Geht das?

Danke und Gruss
Peter

[021aet04]

Statt PB-Akku würde ich eher NiMh oder Lithium Akkus verwenden

MfG Hannes

[ppppp]

Wegen des Gewichts?

[021aet04]

Wegen dem Leistungsgewicht (kg pro Ah) und der Größe. PB Akkus sind bei gleicher Kapazität größer.

MfG Hannes

[justin]

Beim Lesen des Namens dachte ich zuerst an die DDR-Computer, ich weiß nicht, ob der so gut gewählt ist. Ansonsten schönes Projekt, ich wünsche noch viel Erfolg.

Gruß Justin

[HannoHupmann]

Wie ist das Board? Ich hab noch nix darüber gelesen, such aber gerade selber nen neues Board für meine Robies das mehr als die üblichen 32pins hat und deutlich mehr Möglichkeiten als son µController. Leider bin ich bei dem NGW100 nicht so überzeugt, weils recht kompliziert ist die einzelnen IO Pins anzusprechen.

[kellerkind]

Danke für die Blumen =D>


Hallo,

Hat das Fahrgestell des Jagdpanther vorteile bspw. Gegenüber dem Bulldog?
Ist der Panzer laut mit Metallantrieb/Ketten?

Kannst Du etwas über die Zulading sagen? Ich würde gerne einen 3Kg 12Ah Bleiakku verbauen + Elektronik. Geht das?

Hi Peter,
ja kann ich :-k

Der Ursprungsjagdpanther war wesentlich schwerer als alle seine damiligen Konkurrenten (weil mehr Panzerung) und um dieses Gewicht zu verteilen, hatte er mehrere Achsen. In wie weit es sich auf die Modelle übertragen lässt kann ich nicht sagen, aber ich denke das funktioniert auch im Kleinen O:)

Ich habe das Metallgetriebe mit einer Alukappe vor Dreck geschützt und natürlich auch den Innenraum vorm Fett des Getriebes. Ich finde nicht das er besonders laut ist. Er muss sich nicht lautlos fortbewgen können. Natürlich rasselt ein Metallgetriebe lauter als Plasterädchen ;-)



Beim Lesen des Namens dachte ich zuerst an die DDR-Computer, ich weiß nicht, ob der so gut gewählt ist.
und? Das ist gewollt...



Wegen dem Leistungsgewicht (kg pro Ah) und der Größe. PB Akkus sind bei gleicher Kapazität größer.
aber dafür sind sie bei gleicher bzw. größere Kapazität wesentlich günstiger und können auf Grund ihres Aufbaus wesentlich größere Ströme liefern.

@HannoHupmann: Also bis jetzt habe ichs noch den Kauf des Boards nicht bereut. Ich kann allerdings auch noch nicht sagen, wie leicht es nachher ist die einzelnen Boards, Aktoren, Sensoren etc. anzusteuern, da ich soweit einfach noch nicht bin. Ausstattungstechnisch dürfte das Board nur sehr sehr schwer zu übertreffen sein.

[ppppp]

Hallo Kellerkind,

schonmal danke für die Tips!

Hast Du schon etwas zur Odometrie eingebaut, oder hättest Du eine Idee, was man hier am einfachsten realisieren könnte? Auf Fotos sehe ich, dass es "im" Getriebe recht eng zugeht... Das macht mir bei den Panzern am meisten sorgen ;(

Siehst Du eine Möglichkeit, einen CNY70 oder ähnliches einzubauen?

Gruss, Peter

[HannoHupmann]

Dann warte ich erst mal ab, Ausstattungstechnik gibts einiges vergleichbars, es kommt natürlich darauf an wo man seinen Schwerpunkt im Pflichtenheft setzt.

[ppppp]

Als günstiges ARM-Board kann ich das mini2440 von esky-sh (ebay) empfehlen. Kostet vglweise wenig und super Ausstattung, läuft bei mir ohne probleme und aktueller Linux Kernel ist ebenfalls verfügbar + Linux bspw emdebian auf SD-Card. Ein 8 Euro WALN Stick von reichelt tut das übrige.
Benutze die IOs des Boards allerdings nicht, dafür sind 2 Mega32 zuständig (I2C) Für den I2C braucht man einen Adapter (3.3V<->5V), gibt es auch für ca. 15 Euro...

Ich meine, dass das Board allein ca. 65 Euro kostet, mit 3,5" Touchscreen 80 oder so...
Sogar sound, LAN und USB an 2x Bord

</werbung>

Gruss

[kellerkind]

Hallo Kellerkind,

schonmal danke für die Tips!

Hast Du schon etwas zur Odometrie eingebaut, oder hättest Du eine Idee, was man hier am einfachsten realisieren könnte? Auf Fotos sehe ich, dass es "im" Getriebe recht eng zugeht... Das macht mir bei den Panzern am meisten sorgen ;(

Siehst Du eine Möglichkeit, einen CNY70 oder ähnliches einzubauen?

Gruss, Peter

Genau die Frage stelle ich mir momentan auch...
Ich werd vermutlich das erste Zahnrad anbohren (Loch rein =D> ) und eine Lichtschranke verbauen. Ich teste der Zeit verschiedene Möglichkeiten...werd mich melden, wenn ich was brauchbares habe.

[021aet04]

Ich habr einen änliches Kettenfahrzeug (von meldano). Werde mir die EMG30 mit einem Winkelgetriebe einbauen (http://www.shop.robotikhardware.de/shop/catalog/product_info.php?cPath=70&products_id=164). Die Pullupwiderstände habe ich direkt in den Motoren verbaut (unter der schwarzen Kappe)

MfG Hannes

[Bammel]

@021aet04:
wenn dein bot recht zügig fahren soll sind die emg30 doch nicht so das wahre. ich kann max. 440mm/s fahren aber um regelungstechnisch reseven zu haben habe ich meine höchstgrenze erstmla auf 300mm/s gesetzt das ist aber immernoch recht fix. meine minimalgeschwindigkeit liegt bei 30mm/s

[ppppp]

Hallo Bammel,

Sind die EMG30 stark genug für einen Panzer?

Du schreibst Geschwindigkeit ist nicht so das wahre aber immernoch recht fix ? ;)
Ich habe gelesen, dass die EMG30 schnell aber bisschen schwach sind, stimmt das so?

Gruss Peter

[kellerkind]

Ich werd die CNY36 nehmen oder hat jmd.nocheine einfachere Lösung?
Gibts die irgendwo noch billiger als bei ebay?

http://cgi.ebay.de/CNY-36-Gabellichtschranke-10-Stueck_W0QQitemZ370226601091QQcmdZViewItemQQptZBau teile?hash=item5633399c83

...oder viell. doch aus ner alten Maus?

[Bammel]

hi ppppp,
ja stark genug sind diese allemal. fürs langsame fahren sind diese sogar besser als die originalen. mit dennen konnte ich nicht langsam fahren. ja rasend schnell ist der bot nicht. ist vllt auhc nicht so sinnvoll. aber naja es "fehlen" halt so ein paar reserven nach oben hin für die regelung. und anfahren tut der bot auch erst bei einem 8bit pwm wert von 130. dennoch bin ich überzeugt von denn motoren. diese sind schön klein, laufruhig und haben die encoder dran. was dazu führte das ich mich für die motoren entscheiden habe. reichen tun diese nur sehr schnell wird dieser nicht. 300mm/s entspricht 1,08km/h

[ppppp]

Hallo Bammel,

super Infos. Allerdings ist das einbauen der EMG30 vermutl mit viel nmechanischer Arbeit verbunden, oder passen diese mit ein paar Griffen? Auf dem Foto ist dies leider nicht so gut zu erkennen.
Könntest Du deinen Umbau ein bisschen beschreiben?

Danke, Peter

[ppppp]

Kellerkind, wie würdest Du die CNY36 denn mit einem Signal versorgen? Mit einem zusätzlichen "Rad" an einer Zahnradwelle oder ähnlichem?

Grüsse

[Bammel]

@ppppp: lass uns das "gespräch" dann lieber in meinem thread fortführen

[kellerkind]

Kellerkind, wie würdest Du die CNY36 denn mit einem Signal versorgen? Mit einem zusätzlichen "Rad" an einer Zahnradwelle oder ähnlichem?

Grüsse
Ich werde die CNY36 mit einer Inkrementalscheibe betreiben und dafür gibt es unterschiedliche Möglichkeiten die irgendwo anzubringen. Bin am probieren...

[ppppp]

Hallo Kellerkind,

konntest Du die CNY36 schon irgendwo anbringen?

Gruss

[kellerkind]

Hi ppppp,
hab gestern die Motortreiber und 10x CNY36 geordert. Ich sitze grad an der Programmierung vom Motortreiberboard.
Ich werde berichten sobald die Teil da sind.

[hunni]

Hey nur eine kleine Randbemerkung:
Robotron hieß auch eine Frima in der DDR die Computer gebaut hat :)

[kellerkind]

Hey nur eine kleine Randbemerkung:
Robotron hieß auch eine Frima in der DDR die Computer gebaut hat :)
und wieder ](*,) , das war so geplant O:)

Ich habe mir heute eine bzw. zwei PWMen gebastelt (programmieren kann man das nicht nennen :-b ), die ich über 2 potis einstellen kann. Damit möchte ich wenn die Tage die Motortreiber ankommen, die Motoren und das Board testen. Es wird Zeit, das endlich was rollt!

Was mir jetzt noch fehlt ist eine Idee, wie ich das ganze dann per embedded Board steuere? Per WLAN aufs Embedded Board und von da aus dann per RS232? Oder lieber doch I2C?

http://img69.imageshack.us/img69/6532/motorboardpwm.th.jpg (http://img69.imageshack.us/i/motorboardpwm.jpg/)
http://img710.imageshack.us/img710/9154/pwm.th.jpg (http://img710.imageshack.us/i/pwm.jpg/)

[kellerkind]

So es geht weiter.
Meine Motortreiber sind angekommen und verbaut. Sie funktionieren wunderbar. Die VNH2SP30 sind kinderleicht anzusteuern. Das Board funktioniert (bis grade eben) auch wunderbar. Leider habe ich grade die PWM Ausgänge kurzgeschlossen und damit vermutlich den Controller gehimmelt. MIST! ](*,) Ansprechen & proggen lässt er sich noch, er schaltet auch die Ausgänge noch, aber die PWM Outputs bleiben tot :-k

Ich wollte noch ein Video reinsetzen, wo man die Motorreglung per PWM wunderbar sieht, allerdings scheitert es am Format...manchmal ist nich alle Tage (oder so ähnlich ;-))

Im übrigen passt das Zahnrad des Metallgetriebes nicht in die CNY36 (Gabellichtschranken). Die Zahnräder sind 5mm dick. Wenn ich den Controller getauscht habe, werde ich mich daran machen, eine passende Möglichkeit am Getriebe zu suchen, wo man eine Inkrementalscheibe montieren kann...

[ppppp]

Hallo Kellerkind,

wieviel Platz ist denn zwischen dem kleinen Zahnrad auf der ANtriebswelle und der Aussenwand? mehr oder gleich 12mm? Und welchen Durchmesser hat das kleine Zahnrad auf der Antriebswelle? Wg. Einbau CNY70

Danke und Gruss, Peter

[kellerkind]

Mensch, so schnell bin ich einfach nicht mit dem posten:
hier:
https://www.roboternetz.de/phpBB2/viewtopic.php?p=476021#476021

Für den CNY70, (laut Datenblatt:
http://www.datasheetcatalog.org/datasheet/vishay/83751.pdf ) hast du ja 12mm mit den Beinchen, die man ja auch anwinkeln kann, bzw. bei Montage auf Platine hast Du dann nur 6mm plus 1,5mm für die Platine. Das Passt...

[ppppp]

hehe ;) Danke für das Bild ;)

Ja scheint von der Tiefe zu gehen, nur ist das Ritzel 1,7cm hoch, mit Achse bleiben dann noch ca. 5mm für den cny70, schätze ich...

Gruss

[kellerkind]

Ja fast, vom Ritzel (Zahn) bis zur Zahnrarwellenbefestigung (hatte kein besseres Wort ;-) ) bleiben 5,5mm, bis zu eigentlichen Wellen sinds dann 6,5mm (das is nochmal ein kleiner Absatz).

Warum nimmste nicht das große Zahnrad? Die Auflösung hier ist wensentlich besser und der Platz ist auch gegeben?!

-Edit-
Ich habe meinen Fehler entdeckt. Es ich habe im Programm, das Hardware_init gelöscht...das kommt davon wenn man 1000 Sachen gleichzeitig macht...

[ppppp]

Hallo,

so, die Odometrie ist eingebaut, mangels Platz habe ich meinen RP6 geschlachtet, die Reflexlichtschranken dort sind unschlagbar und können gut eingebaut werden.

CNY36 müssten auch gehen mit geeigneter Scheibe, für die CNY70 ist wenig Platz, man könnte aber etwas aus der Getriebehalterung ausschneiden, um einen "Blick" auf ein Zahnrad zu bekommen.

Hat jemand Erfahrung weitere Erfahrung mit den CNY36/70 machen können?


Gruss, Peter

[kellerkind]

Hi Peter, hast Du mal ein Foto von Deiner Lösung?
Ich bastel immer noch an meiner, siehe:
https://www.roboternetz.de/phpBB2/viewtopic.php?p=477636#477636

Dort kannste meine Erfahrungen nachlesen. Wenn ich eine Lösung habe, werde ich dir logischerweise hier in meinem Projektethread auch posten. Hatte ja bei ebay 10x CNY36 geordert, aber TCST1103 bekomm :-k

Ich sucher derzeit noch eine Möglichkeit, entweder die Welle des Motors oder eine Zahnrades zu verlängern...

[ppppp]

Hallo Kellerkind,

habe Fotos hier abgelegt:
https://www.roboternetz.de/phpBB2/viewtopic.php?p=477646#477646

Antwort weiter unten enthält 4 Bilder der Odometrie

Gruss Peter

[kellerkind]

Es geht weiter...

Auch wenn die Odometrie noch auf sich warten lässt, habe ich heute erfolgreich das embedded Board rb-100 in Betrieb genommen.
Dank einem Belkin Wlan USB Stick und der Remotedesktop-Unterstützung kann ich das embedded Board aus meinem WLAN erreichen.
Die angeschlossene USB CAM (640x480px) liefert auch ganz gute Bilder, wenn auch extrem verzögert (4-5s). Ich werde mit der Auflösung viell. noch runter gehen, sonst lässt sich der Bot jedenfalls nicht per Sicht steuern ;-)

Das Board verbraucht mit Tastatur, WLAN Stick, USB Cam und Grafikkarte bei 7,2V "nur" nen knappen Ampere.
Die Grafikkarte kann ich nun dank RemoteDesktp auch weglassen.

Als nächstes werde ich das embedded Board auf dem Bot befestigen und die Sensoren und das Motorboard ansteuern (I2C & RS232).
Der SRF02 wird mein erstes Opfer...

Hier noch ein Bild vom RemoteDesktop:
http://img31.imageshack.us/img31/3012/rdesktop.th.jpg (http://img31.imageshack.us/i/rdesktop.jpg/)

--edit--
Ohne Grafikkarte, mit WLAN Stick, ohne Tastatur & Maus:
~600mA@7,2V, Startup-Time ~2min bis per Ping erreichbar

[Bammel]

Nen halben Ampere?! Das ja wahnsinn!

Da ist es ja wirklich eine Überlegung wert auf sowas umzusteigen!

[kellerkind]

Nen halben Ampere?! Das ja wahnsinn!

Da ist es ja wirklich eine Überlegung wert auf sowas umzusteigen!
...wenn der Preis von knappen 300€ nicht wäre, dann?!
Aber die Funktionalität und die super Ausstattung macht alles wieder gut ;-)

[Bammel]

Ja den Preis habe ich eben entdeckt!
Und somit ist auch diese Überlegung für mich gestorben.

[ppppp]

Hallo,

nettes Board, woher kommt die CPU-Last?
Nur vom Video, bzw. was "geht" alles mit der Leistung?

Ist der RAM erweiterbar, sodass vielleicht MATLAB laufen würde?

Danke, und Gruss

[kellerkind]

Hi ppppp,
die CPU Last ist hauptsächlich der USB Cam & der damit verbundene Netztraffic, denn als ich die ausgeschaltet habe fiel die Last auf wenige Prozente ab.

--edit--
Die Last fällt auf 6-7%ab. Die hohe Last kommt daher, daß der CPU die volle Grafik aufarbeiten muss, den die Grafikkarte steckt ja nicht im Board.

Der Ram ist leider fest (256MB) und meineserachtens nicht erweiterbar. Es sei denn es gibt RAM, oder ein Adpater, im mini-PCI Format.
Wofür wolltest Du denn MATLAB verwenden?Oder meinste Simulink?

[ppppp]

Hallo,

ja meinte Simulink, mein Bot ist größtenteils codegeneriert, wäre fein, wenn das Modell dort laufen würde...

Kannst Du das mal ausprobieren? ;)

Gruss

edit: da ist so nen Netbook ja eigentlich günstiger, schneller, RAM.. auf einen Panzer passt das drauf und läuft auch 4 Stunden mittlerweile vermute ich..

Hat jemand Erfahrung, ob ein USB 2 I2C Adapter ordentlich funktioniert?

editedit:
30 Euro für XP/Linux etc--.-
http://www.roboter-teile.de/Shop/themes/kategorie/detail.php?artikelid=102&kategorieid=13

[kellerkind]

...her damit!Ich denk aber das läuft!Warum auch nicht?Sooo anspruchsvoll ist Simulink aber auch nicht...



edit: da ist so nen Netbook ja eigentlich günstiger, schneller, RAM.. auf einen Panzer passt das drauf und läuft auch 4 Stunden mittlerweile vermute ich..

Hatte ich auch gedacht ABER der Stromverbrauch ist wahnsinn.Hatte mir auch nen µ-ITX Board geholt aber die lieben Dual-Cores fressen eben.

[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 ;)

[kellerkind]

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:
http://img41.imageshack.us/img41/1267/image180e.th.jpg (http://img41.imageshack.us/i/image180e.jpg/)

Der Testaufbau mit µServo Board:
http://img36.imageshack.us/img36/3448/robotrones.th.jpg (http://img36.imageshack.us/i/robotrones.jpg/)

Das µServoboard hängt am TTL RS232 des embedded Boards.

[Bammel]

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

[kellerkind]

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 :-(

[kellerkind]

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.
http://img31.imageshack.us/img31/4158/pantilt.th.jpg (http://img31.imageshack.us/i/pantilt.jpg/)


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/zeigebeitrag.php?t=35729&highlight=

[kellerkind]

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>

[kellerkind]

Jetzt geht voran, wenn auch nur langsam dafür aber stetig ;-)

Ich habe mich rangesetzt und auf die schnelle ein zusätzliches Board entworfen.

http://img232.imageshack.us/img232/341/mainunit.th.jpg (http://img232.imageshack.us/i/mainunit.jpg/)


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

[MF6265]

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/

[oratus sum]

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...

[kellerkind]

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 ;-)

[kellerkind]

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:

http://img686.imageshack.us/img686/5991/frontyjz.th.jpg (http://img686.imageshack.us/i/frontyjz.jpg/)

http://img697.imageshack.us/img697/1016/vonobenb.th.jpg (http://img697.imageshack.us/i/vonobenb.jpg/)

[Bammel]

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.

[kellerkind]

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

[Rabenauge]

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.

[kellerkind]

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?

[oratus sum]

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

[Rabenauge]

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:


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:

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.

[kellerkind]

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.

[Rabenauge]

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:

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:


//----------------------------------- 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.

[oratus sum]

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

[kellerkind]

@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.

[oratus sum]

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:
https://www.roboternetz.de/phpBB2/files/sig3.jpg
https://www.roboternetz.de/phpBB2/files/sigm.jpg

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

[kellerkind]

Ich habs soweit verstanden. Ich komm auf Dein Angebot der Kontrolle zurück, sobald mein Servo an OCR2 läuft, meld ich mich...

[kellerkind]

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!

[oratus sum]

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.

[kellerkind]

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

[Rabenauge]

@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.

[oratus sum]

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.

[Rabenauge]

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.

[oratus sum]

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

[kellerkind]

Ich habe am Donnerstag meine Platine geliefert bekommen und heute endlich auch die Zeit gefunden mich darum zu kümmern.

http://img229.imageshack.us/img229/844/mainunitroh.th.jpg (http://img229.imageshack.us/i/mainunitroh.jpg/)
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...

http://img716.imageshack.us/img716/2731/mainunitt2.th.jpg (http://img716.imageshack.us/i/mainunitt2.jpg/)

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 ;-)

[oratus sum]

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.

[kellerkind]

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)

[fat tony]

Hi kellerkind,
Mit welchem Betriebssystem betreibst du dein Embedded-Board nun eigentlich ?
Mich würde interessieren wie genau du das Kammerabild streamst.

[oratus sum]

Mich würde auch interessieren wie mana uf so einem embedded-Board die Ports anspricht, sprich PWM GPIOs und so weiter

[kellerkind]

Hi kellerkind,
Mit welchem Betriebssystem betreibst du dein Embedded-Board nun eigentlich ?
Mich würde interessieren wie genau du das Kammerabild streamst.

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!

@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

[oratus sum]

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.

[kellerkind]

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...


Mensch Du bist aber auch hartnäckig O:)
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.

http://img341.imageshack.us/img341/2025/glcda8test.th.jpg (http://img341.imageshack.us/i/glcda8test.jpg/)


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 !!!???

[oratus sum]

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.