Druckbare Version
Hallo ACU,
Meine habe ich gerade runtergeladen und bin vom Umfang erschlagen.Zitat:
Die Tester vom RP6 (zu denen ich glücklicherweise auch gehöre) haben heute von SlyD die Anleitung bekommen.
Na dann werde ich 'mal mit dem Lesen anfangen ...
Gruß Dirk
@adrisch:
Es gab 25 gute Bewerbungen.
Was aufgrund der kleinen Einschränkungen schon relativ viel gewesen ist.
(bei der ASURO Aktion damals haben sich natürlich in kurzer Zeit einige mehr beworben - aber da gab es ja auch keinerlei Einschränkungen ausser hier angemeldet zu sein ;) )
Die 8 MHz sind aus Stromspargründen gewählt worden. Reicht vollkommen und wenn man einen externen Controller zur Steuerung einsetzt, braucht man auf dem Mainboard ohnehin keinen besonders hohen Takt ...
Der MEGA32 auf dem RP6 CONTROL M32 läuft übrigens mit den maximal möglichen 16MHz.
MfG,
Dominik
OK, Danke........
OK, Danke........
Wie sieht man den RP6 (ATmega32)
http://www.henkessoft.de/Roboter/Roboter.htm#RP6
im Vergleich zum ebenfalls neuen NIBO? (ATmega128)
http://www.henkessoft.de/Roboter/Roboter.htm#NIBO
Was beim RP6 wird genau mit 8 MHz und was mit 16 MHz betrieben?
Zum Kompass beim Drehen: Wie weit muss dieser in der Höhe von den Motoren entfernt sein? Hat das schon jemand praktisch beim RP6 probiert?
@ehenkes:
Diese Roboter sind erstmal von der Mechanik und den Erweiterungsmöglichkeiten her natürlich nicht direkt vergleichbar. Der Nibo ist deutlich kleiner als der RP6 - eher so ähnlich wie der ASURO.
Motorregelung, IRCOMM, ACS (Infrarot Sensorik), alle ADCs periodisch auslesen, I2C Bus Master oder Slave Routinen, diverse Timing Sachen, Debug Ausgaben auf der seriellen Schnittstelle und noch einige andere Dinge wie eine Subsumptionsarchitektur kann man schonmal von der Rechenzeit her problemlos "gleichzeitig" auf dem MEGA32 auf dem Mainboard laufen lassen (habe ich getestet).
Der MEGA32 unterscheidet sich vom MEGA128 ja nur in punkto Speicher und Anzahl der Ports/Peripherie.
Der AVR Kern ist identisch.
Die 8MHz wurden wie gesagt aus Stromspargründen für den Controller auf dem Mainboard gewählt - mehr braucht man grundsätzlich erstmal nicht.
(mit abgeschalteten Sensoren und LEDs nimmt er etwa 18mA auf - wenn alles an ist sind es ca. 40mA, im Standby (also sleep mode vom AVR) etwa 4mA - alle Werte ohne Motoren und IRCOMM natürlich)
Das RP6 CONTROL M32 wird mit den maximalen 16MHz getaktet. Wer also mehr braucht, kann dieses Erweiterungsmodul oben auf dem Roboter montieren. Dann hat man zwei MEGA32 - einer kümmert sich dann um die Motorregelung, ACS, IRCOMM etc. pp. und entlastet den MEGA32 auf dem RP6 CONTROL somit. Der hat dann alle Ressourcen frei und muss eigentlich nur einen I2C Bus Master implementieren - ob in Software oder Hardware ist dabei egal.
---------------------
Zum Kompass:
Habe ich noch nicht ausprobiert - aber es gab hier diverse Leute die auf dem alten RP5 einen Kompass verwendet haben!
Der Kompass sollte natürlich etwas höher angebracht werden (z.B oben auf einem Erweiterungsmodul) damit er nicht von den Motoren und der restlichen Elektronik beeinflusst wird.
Habe ich aber noch nicht ausprobiert (hatte leider keine Zeit dazu bisher - mache ich aber demnächst mal)
Alternativ könnte man hinten oder vorne am Roboter auch mal mit einem Optischen Maussensor experimentieren ob es damit klappt...
MfG,
Dominik
Ich finde die Bedienungsanleitung ebenfalls sehr gut gelungen, v.a. im Vergleich zum RP5, bei dem man sich sehr viel aus den Fingern saugen (bzw. im Forum erfragen) musste.
V.a. die Einführung in die Programmierung ist super für Anfänger.
Die optischen Maussensoren stehen auf meiner Liste... wollte ich eh schon länger mal ausprobieren, also warum nicht am RP6.
Ich habe einige Wochen mit dem Gedanken gespielt einen neuen Eigenbaurobbi auf die Beine (bzw Räder) zu stellen. Da ich nun den RP6 bekomme habe ich diese Pläne erstmal verworfen und werde versuchen meine geplanten Komponenten so weit es geht auf den RP6 zu übertragen.
Zum Kompass mal ein Wort:
Der sollte auf jeden Fall 20cm von den Motoren entfernt sein. Sonst gibt der aus, dass überall Osten ist.
Und Kabel mit einem höheren Strom sollten auch 20cm entfernt sein, da das elektromagnetische Feld den Kompass stört.
Ich habe das praktisch an IMADEIT getestet.
Zum Quarz:
Funktioniert die Kommunikation über I2C oder UART einwandfrei?
wenn man zwei Quarze verwendet, arbeitet das System asynchron.
Da wäre es besser, wenn man das Signal über SDL an die anderen µCs weitergibt. Sonst muss man eben ein Protokoll entwickeln, dass das alles synchronisiert...
jon
Dafür gibt es bei I2C ja die SCL Leitung... ich versteh dein Problem jetzt nicht ganz...
@Jon:
Wie gesagt habe ich das beim RP6 noch nicht getestet - allerdings ist das Mainboard nicht mehr so wie beim alten RP5 - da war es komplett ohne Masseflächen (naja und bei Dir war es ja ein stapel Lochrasterplatinen so wie ich das gesehen habe).
Das Board hat jetzt aber sehr große Masseflächen und ich denke mal das die Motoren damit nach oben hin zumindest ein kleines bisschen besser abgeschirmt sind. Ob es für den Kompass reicht, kann ich aber nicht genau sagen weil ich nicht weiss wie empfindlich der ist.
Nur so eine Idee - man könnte die Motorfilter auch noch etwas verbessern und mal versuchen das Motorgehäuse noch über zwei zusätzliche Kondensatoren zu verbinden. Das habe ich aber noch nicht getestet - ohne Kompass war der Bedarf nicht vorhanden ;)
Naja - wem der Kompass dann zu hoch ist, kann es noch mit nem Gyro versuchen!
hmmm???Zitat:
Zum Quarz:
Funktioniert die Kommunikation über I2C oder UART einwandfrei?
wenn man zwei Quarze verwendet, arbeitet das System asynchron.
Da wäre es besser, wenn man das Signal über SDL an die anderen µCs weitergibt. Sonst muss man eben ein Protokoll entwickeln, dass das alles synchronisiert...
Den Gedankengang verstehe ich jetzt nicht. Die I2C Taktfrequenz wird IMMER vom Master generiert und der Bus ist somit komplett synchron. Du kannst die Slaves auch mit 13,334567 MHz laufen lassen - das interessiert den I2C Bus ja nicht :mrgreen:
Beim UART muss man nur die gewählte Baudrate möglichst genau treffen. Mit welchem Takt die Controller laufen ist egal - muss nur zur Baudrate passen. Zur kommunikation empfehle ich 38400 Baud oder gleich 0.5MBaud. Wobei aber die Kommunikation übers UART unter den Controllern nicht direkt vorgesehen ist - möglich ja - aber eigentlich nicht notwendig mit dem I2C Bus.
MfG,
SlyD