(Mein Erster) Modularer Autonomer Mobiler Roboter

Ich habe jetzt mittlerweile ein paar Inspirationen aus diesem sehr schönen Forum gewonnen und möchte euch nun auch meine Roboterpläne vorstellen :)

Ich werde einen zweirädigen Roboter mit einem Stützrad hinten bauen.
Dabei werde ich eine Hauptplatine aufbauen, an die ich dann Module anschließen kann. Als Controller werde ich auf der Hauptplatine vermutlich einen Mega32@16MHz nutzen.

Module
Die Modulstecker werden Versorgungsspannung, I²C, SPI und noch ein paar andere Sachen bereitstellen. Zu diesen anderen Sachen zählt das EmergencyStopFlag (Wenn der Roboter sofort anhalten muss). Dieses Flag wird einfach von den Modulen auf Vss gezogen. Dann sollte das entsprechende Modul auch eine "Problembeschreibung" an den Hauptprozessor senden.

Die Modulplatinen werden mit der Zeit aufgebaut werden, dadurch ergeben sich mir mehrere Vorteile:
- Ich muss nicht alles auf eine Platine packen
- Ich muss nicht alles sofort kaufen und planen
- Dadurch kann ich auch später noch Ideen angenehm verwirklichen

Als Module sind zuerst geplant:
Ausgabe-Modul
Das Ausgabemodul soll ein 16x2 LCD Display zur genauen Statusausgabe haben. Desweiteren wird ein 7-Segmentdisplay eingebaut um wichtige Roboterstatuscodes auch auf größere Entfernung erkennen zu können.
Als Controller wird ein Mega8 eingesetzt, der die I²C Schnittstelle nutzt

Sensormodul 1 (Grundlegende Hinderniserkennung)
Dieses Sensormodul wird die Hindernissensoren am Chassis des Roboters auslesen und bei Berührung den NotStop-Flag setzen und eine genaue Beschreibung wo der Roboter gegengestoßen ist per I²C an den Hauptprozessor senden

Gedanken und Probleme
Natürlich gibt's noch einige Dinge bei denen ich mir nicht sicher bin, wie ich sie realisieren soll..
1.) Weitere Anschlüsse am Modulstecker
Mögliche Ideen: gibt es weitere Protokolle die ich einbauen sollte?
2.) Stromversorgung
Mögliche Ideen: Ich wollte 2x10 AA-Akkus nehmen, damit komme ich auf ordentliche Laufzeit und eine Spannung von 12V die ich angenehm für die Motorenverwenden kann und gleichzeitig auf 5V für die µC runterregeln kann
3.) Wie SS vom SPI realisieren
Mögliche Ideen: Vom Hauptprozessor an jeden Modulstecker eine eigene Leitung.

Ende des Beitrags ;)
Ich hoffe ihr interessiert euch ein wenig für mein Projekt und könnt mir neue Inspirationen geben ;) Bald werde ich ein 3D-Modell von meinem Roboter hier hochladen, auch Schaltpläne und weitere Ideen und Umsetzungen werde ich hier posten. (Bitte rechnet aber nicht allzuschnell mit der Umsetzung, das ganze soll ja gut geplant sein ;))

cu, CowZ

du könntest, statt SS zu verwenden, einfach ein 1-wire device emulieren, die haben nen eigenen 64-bit code, davon kannst du 48 als adressierung verwenden, so werde ich das machen, wenn ich mal zeit finde, ich hatte nämlich auch schon die selbe idee wie du, bloß dass bei mir noch INTs an die module kommt, damit die module sagen können, wann sie daten haben, danach übermitteln sie ihre nummer, und der master (in diesem falle nen 128er) fragt das modul dann über seinen zustand ab.

Martin

1-Wire device? Das ist dann aber nicht mehr SPI oder? Am liebsten würde ich ja auch Module ermöglichen, auf denen kein µC drauf is, sondern halt bspw. nur irgendein Sensor, der halt über SPI ansteuerbar ist...

gruß, CowZ

naja, es gibt so ziemlich viele verschiedene sensoren, die über 1-wire angesteuert werden, da sind se mal alle: www.maxim-ic.com/1-wire.cfm

Mh, interessant ;)

Das ist dann aber was anderes als SPI... Für solche Sensoren kann ich dann ja noch extra Anschlüsse auf der Platine anbringen. Für einzelne Sensoren benötige ich ganzes "Extra" Modul...

Aber wie meinst du, dass ich ein 1-Wire Device mit SPI emulieren soll? vor allem wie soll ich das emulieren, wenn ich keinen µC auf mein Modul bauen möchte, sondern eben nur ein SPI-Device...

gruß, CowZ

hä? emulieren? ^^ ich wusste da ja noch gar nicht, dass du nicht auf jedes modul nen controller packen wolltest, ich fände das allerdings sehr hilfreich, wegen adressenüberschneidung und standardisiertes protokoll, undn controller kostet doch nich wirklich viel... warum willstn das ohn controller machen?

Martin

Mhh ja... Ansich kann ich auch auf jedes Modul nen Controller setzen... Funktioniert dass denn, dass ich SPI ohne SS benutze und das SS dann per Software auf dem Modul setze? (Indem jedes Modul seine eigene "ID" hat, die der Master sendet)

Und... Wenn ich auf jedes Modul einen Controller setze, brauche ich SPI irgendwie ja gar nich, dann kann ich auch gleich nur I²C benutzen. Dann entfällt das Problem von SS sowieso ;)

Zu deiner Idee, dass die Module auch an die INTs vom Hauptprozessor kommen... Was bringt das? Du kannst doch Daten usw. auch per I²C übertragen. Und wie würdest du die Modul"nummer" an den Hauptprozessor senden?

Gruß, CowZ

also: die 1-wire devices haben eh immer ne 48-bit unique nummer die beim auslesen der einzelnen slaves als erstes gesendet wird, und der int bringt das, das du nich die ganze zeit dumm rumpollen musst, bis mal irgendwer daten hat, sondern du kannst genau dann reagieren, wenn ein slave grade neue daten für dich hat, so lange die int-leitung low/high (je nachdem ob man das jetz low oder high-active macht) ist, darf kein anderer slave was senden... danach wieder, das iss eigentlich nen recht cooles prinzip, die 48-bits vergeb ich mir vermutlich selber, oder ich mach das ganz anders, so dassich einfach nen paar adressleitungen hab, die mit nem ex-or und nem undgatter den anderen int vom modul-prozi auf high setzt, so dass dieser ausm sleep aufwacht, und sich angesprochen fühlt ^^

Martin

Ich muss doch mit I²C nicht die ganze Zeit pollen... Die Slaves können doch auch selbstständig an den Master senden, oder hab ich was falsch verstanden?

Ich finde halt nur, dass es irgendwie ne Radneuerfindung is, wenn man sich nen eigenes Protokoll ausdenkt...

Gruß, CowZ

das iss doch gar kein eigenes protokoll, das ist 1-wire, das iss genau son protokoll wie I²C, nur mit einer leitung weniger ^^

naja, aber wenn nen slave per I²C was an den master sendet, dann muss der master doch das auch abfragen, oder seh ich das jetzt ganz falsch, daher mussich ja immer mal wieder mit dem master fragen, ob was neues da iss, und das iss ja grad das polling...

Martin

Du bekommst (imho) nen Interrupt bei den AVR Controllern, wenn da Daten über I²C ankommen.

Aber bei 1-wire muss ich die ganze Zeit pollen und wenn ich dann noch ne Leitung brauche, die sagt, ob gerade gesendet wird (deine INT-Leitung), dann habe ich wieder zwei Leitungen und kann gleich I²C benutzen, oder gibt es versteckte Vorteile beim 1-Wire (was ich ja auch noch per Software im µC basteln muss...)

es iss schneller, es kann weitere strecken überbrücken, und sich selbst per strong-pullup versorgen, dann brauche ich mit int-leitung nur 3 leitungen... es sind bis zu 80 devices pro sekunde scannbar

Martin

Moin

Also dein Projekt hört sich wirklich sehr interessant an. Vorallem da du es auch so gut planst. Das ist bei mir immer das Problem, dass cih zu schnell was sehen will :D

Also wie hier schon gesagt würde: Ich würde noch weitere Interruptsdurchschleifen.

Andun

Mhh... Wie genau soll denn dieses 1-Wire Zeugs jetzt aussehen, irgendwie finde ich gerade nichts gescheites dazu...

Wenn wir mal davon ausgehen, dass wir sowieso Versorgungsspannung haben, dann brauch man doch nur eine Datenleitung und eben die Interruptleitung..
Die Datenleitung ist klar wofür die ist, die Interruptleitung wird von einzelnen Modulen gesetzt (ob jetzt High oder Low is egal) um zu signalisieren, dass jetzt Daten kommen.

Sobald jetzt die INT-Leitung gesetzt wurde (vom Modul) sendet das Modul über die Datenleitung die Modulnummer usw. usf.

Dieses 1-Wire Protokoll muss ich aber erst noch in meinen Controllern programmieren oder gibt es sowas bei den Atmelprozessoren schon?


Zu den durchgeschliffenen Interrupts: Wofür könnten die Module die denn gebrauchen? Es würden 3 am Mega32 zur Verfügung stehen.

also es iss so: eine situation: ein modul erkennt plötzlich, dass sich ein objekt mit der geschwindigkeit 5km/h nähert, dies tut es durch einen sharp-sensor, und einem aufgebauten µc!

1. master führt andere aufgaben aus
2. slave errechnet aus zwei messpunkten geschwindigkeit
3. slave setzt int auf high
4. master geht in ISR
5. slave sendet seine id (um zu erkennen, WELCHES modul nun gesendet hat, dasses neue daten senden will)
6. master spricht den chip mit der id an, und erwartet daten
7. slave sendet daten
8. slvae setzt int auf low
9. master reagiert, da keine daten mehr vorhanden (da int = low)

so ist das gedacht...

das 1-wire gibts einfach in bascom schon, weiß nich ob du das kennst, finde ich ganz praktisch...

das mit den ints:

den erste (master <-> slave) setze ich ein, um zu signalisieren: ein device hat daten für dich

der zweite (master -> slave) setze ich vermutlich ein, um die einzelnen module direkt schnell anzusprechen, der master setzt einige adressleitungen auf die passende adresse, und durch eine logik, die auf jedem modul sitzt, wird diese gegen die moduladresse verglichen, und der int am modulprozessor auf 1 gesetzt, so kann man den modulprozessor aus dem sleep in den normalmodus versetzen, wenn der prozessor daten anfordert.

haste das jetzt so verstanden?

Martin

Ja :) Danke :)

Ich habe vor, die Controller mit Assembler zu programmieren ;) SPI und I²C haben daher den Vorteil, dass die Hardwaremäßig schon auf den Controllern drauf sind :) Daher würde ich gerne nur auf die beiden Protokolle zurück greifen, aber ich kann ja auf jeden Fall auch Leitungen für das 1-Wire Protokoll machen, schadet ja nicht (kostet mich aber eine Int-Leitung) Aber ich werd's machen, so kann ich später noch Module bauen, die das 1-Wire Protokoll nutzen :)

Für das zweite (die Addressierung der Module) brauche ich doch aber keine Int-Leitung vom Mega32, das kann ich doch auch über "normale" Portpins machen. Die Logik würde ich auf die Hauptplatine bauen, so dass ich am Modul nur einen Pin habe, der signalisiert, ob das Modul angesprochen wird oder nicht. Das spart Bausteine auf den Modulen und so brauch ich dann auch nicht aufzupassen, dass keine zwei Module die gleiche Adresse haben.

So nachdem ich noch länger drübernachgedacht hab:

Ich werde kein SPI und kein 1-Wire benutzen. Da ich eh jede Modulplatine selber entwickeln werde und somit frei in meiner Entscheidung bin, welches Bussystem ich nehme, werde ich I²C nehmen.

Dafür spricht:
Gegenüber SPI braucht es weniger Pins.
Gegenüber 1-Wire ist es einfacher zu benutzen (im Controller schon integeriert) und zudem schneller.

1-wire ist schneller als I²C, aber ich will dir nicht deine Meinung nehmen ^^

außerdem iss 1-wire nen extrem einfaches protokoll ^^ musste dir vielleicht mal durchlesen

Martin

Hast du denn einen Link zu den Spezifikationen? Ich finde nichts, auch nicht auf der Seite, die du schon gelinkt hast.

Wikipedia:
"1-Wire is similar in concept to I²C, but with lower data rates and a much lower cost."
lower datarate => langsamer (oder?)

Gruß, CowZ

http://www.mcselec.com/index.php?opt...=140&Itemid=54

ab seite 111

Martin

Danke :)

Aber wie implementier ich das in Assembler? Wird wohl eher aufwändig und deswegen für mich als Anfänger kaum machbar, aber ich frag mal hier im passenden Forum :)

Ich werde aber auf jeden Fall einen Interrupt am Hauptprozessor an die Module anschließen um den Modulen zu ermöglichen, dem Hauptprozi mitzuteilen, dass sie gepollt werden möchten. Dazu werde ich auch noch ein Bit zur Moduladdressierung nutzen. (Der Modul setzt einen festen Pin und der Hauptprozessor erkennt welches Modul den Pin gesetzt hat)

Was für Anschlüsse (abgesehen von 1-Wire und SPI) sollten noch an die Module weitergeleitet werden? Man könnte auch ein paar "Spezialmodul-Buchsen" einbauen, die dann z.B. an den AD-Wandler des Hauptprozessors angeschlossen sind. (Aber da stellt sich mir die Frage, wofür? Die AD-Wandlung kann ja auch der Modulprozessor übernehmen...)

Eine weitere Frage: Wie weit lohnt es sich Sachen auszulagern? Lohnt es sich ein Ausgabemodul mit LCD und 7-Segmentanzeige zu machen und lohnt es sich ein Motormodul zu bauen? Oder sollten solche Grundlegenden Funktionen auf dem Hauptprozessor sein? (Und wenn nicht, was macht dann der Hauptprozessor überhaupt noch?)

Ich freu mich auf eure Anregungen, CowZ

wie erkennt der prozi denn, wer den pin gesetzt hat?

motormodul iss praktisch, wegen zusätzlicher motoren zum drehen von sensoren oder sowas...

die sensormodule, aber das dürfte ja klar sein, die müssen ausgelagert werden, und ich mach noch eins für die akkuladung

Martin

Ich könnte z.B. einfach für jede Modulbuchse einen Inputport vom Mega32 benutzen. Besser wären natürlich irgendwelche Schieberegister etc.

Das Motormodul soll ansich nur den Grundantrieb machen, aber dafür evtl. solche Sachen wie Kurvenfahren, Drehen etc.. Ebenso, dass der Hauptprozi nur sagt, "Dreh dich um 90° nach links" und das Motormodul (besser wäre wohl Antriebsmodul) dreht um 90°. Auf dieses Modul könnte dann eventuell (wenn ich ne Bezugsquelle finde) auch noch ein optischer Maussensor.

Die Sensormodule werden ausgelagert, klar, weiß ja auch nicht, was ich da in n paar Monaten alles haben will ;) Akkuladung wäre natürlich auch cool... Müsste ich noch mal n paar Gedanken drüber verschwenden ;)

Als Stromversorgung hatte ich an 10xAA Akkus gedacht, die würden eine "angenehme" Spannung von 12V liefern, 17Ah.

Eine Frage bleibt mir noch offen...

Soll ich die Module als Einsteckmodule machen, oder die Module per Kabel mit der Hauptplatine verbinden?
Für Einsteckmodule sprechen folgende Punkte:
- Geileres Feeling ;)
- Weniger Kabelsalat

Dagegen spricht aber:
- Stabilität der (größeren) Modulplatten, wenn die in kleinen Steckbuchsen stecken

Meinungen, Ideen? Könnte man die Modulplatten irgendwie sichern, sobald die in den Steckbuchsen drin stecken, und welche Steckbuchsen sollte man nehmen? Ich dachte an normale Buchsenleisten und Stiftleisten auf den Modulen. Somit wäre gewährleistet, dass man auch Module auf normalen Lochrasterplatinen aufbauen kann, ohne dass man bestimmte Sachen braucht (wie z.B. bei PCI etc.)

Zitat:

---

Zitat von CowZ

Ich werde aber auf jeden Fall einen Interrupt am Hauptprozessor an die Module anschließen um den Modulen zu ermöglichen, dem Hauptprozi mitzuteilen, dass sie gepollt werden möchten. Dazu werde ich auch noch ein Bit zur Moduladdressierung nutzen. (Der Modul setzt einen festen Pin und der Hauptprozessor erkennt welches Modul den Pin gesetzt hat)

---

Das klingt jetzt für mich so, als wolltest Du jedes Modul mit einer
besonderen Leitung (Stichleitung) an einen PIN des Hauptcontrollers
hängen. Das geht, hat allerdings Vor- und Nachteile:

Der Hauptnachteil ist, dass Du für jedes Modul einen PIN am
Hauptcontroller benötigst. Die Anzahl der Module ist also schon allein
deshalb begrenzt. Ausserdem musst Du an jeden Modulstecker die
Stichleitung führen und kannst sie nicht einfach nur parallel schalten.

Der große Vorteil ist aber, dass Du erkennen kannst, wenn mehrere
Module gleichzeitig einen Interrupt setzen und die Anfragen dann in
der Reihenfolge ihrer Wichtigkeit abarbeiten kannst.

Meistens wird man aber Stichleitungen vermeiden wollen.

Zitat:

---

Zitat von CowZ

Eine weitere Frage: Wie weit lohnt es sich Sachen auszulagern? Lohnt es sich ein Ausgabemodul mit LCD und 7-Segmentanzeige zu machen und lohnt es sich ein Motormodul zu bauen? Oder sollten solche Grundlegenden Funktionen auf dem Hauptprozessor sein? (Und wenn nicht, was macht dann der Hauptprozessor überhaupt noch?)

---

Meiner Meinung nach lohnt es sich durchaus, auch die scheinbar "trivialen"
Sachen auszulagern.
Beispiel:
Wenn Du das LCD-Modul auslagerst, dann kannst Du es z.B. durch ein
Funkmodul (ich glaube, es gibt Standardkomponenten, die RS232 zu Funk
machen) ersetzen, ohne dass Du irgendwas an der Programmierung
des Hauptprozessors änderst.
Du steckst einfach das andere Modul an und erhältst die Ausgabe am
PC-Terminal statt auf dem LCD.

Der Hauptprozessor muss sich dann noch um die Koordination der
einzelnen Module kümmern. Immerhin soll der Roboter ja eine bestimmte
Funktion bzw. ein bestimmtes Verhalten haben.

Grüße,

Hans

Die Problematik mit der verbrauchten Pinanzahl könnte man durch Schieberegister ausmerzen. Dann muss der µC nur ein paar Ports benutzen um die Schieberegister anzusteuern.

(Wie heißen diese Schieberegister, die nicht Ausgänge, sondern mehrere Eingänge haben?)

edit: sonst könnte man auch einen Mega8 nutzen, der könnte die ganze zeit nur die Moduladdresspins pollen, wenn da einer ist, kann er nen Int beim Hauptprozi auslösen und per I²C (nachdem er vom Hauptprozi gepollt wird) die Moduladdresse senden. so könnte man verdammt viele Module haben ;) (Allein ein Eingangsport würd für 512 Module reichen, wenn ich mich nich grad verrechnet hab ;))

So, nach weiterem Denken und Entwicklung stellen sich mir erneut mehrere Fragen :)

1.) Was für Anschlüsse muss ich am Modul haben. Die Module sollen über IIC (bzw. I²C / TWI) mit dem Hauptprozessor kommunizieren. Folglich reichen mir ansich 5 Pins pro Modul:
- 5V
- GND
- SDA
- SCL
- "PollMe!"

Ich dachte desweiteren daran auch noch eine SPI-Schnittstelle einzubauen, damit die Systemumstellung auf, bzw. Integrierung von SPI-Modulen einfach ist. (z.B. für große Datenübertragungen...)

Was für weitere Pins sollte man direkt auf den Modulen haben? Pins wie die AnalogINs vom Hauptprozessor sind extra Pins auf der Hauptplatine.

2.) Sollte man eine große Hauptplatine ("Motherboard") haben, oder eine kleinere Hauptprozessorplatine, an die man dann über Kabel "Modulhalterungsplatinen" connecten kann, auf denen letztendlich die Module sitzen?

Vorteil der Extraplatinen:
- Leichteres Handling beim Löten
- Kaputte Stecker sind nicht so ein großes Problem, da man kleine Bauteile einfach ersetzen kann
- Man kann einfacher neue Modulsteckplätze anbauen

Nachteile:
- Mehr Platinen
- Extra Verbindungen zwischen den Platinen nötig

3.) Was für Stecker / Buchsen sollte man für die Module nehmen? Das ganze sollte in der benötigten Pinzahl (oder annähernd) verfügbar sein (siehe 1.) und bezahlbar sein. Ich dachte an Buchsen- und Stiftleisten (ein reihig). Das hat den Vorteil, dass man Module auch leicht auf Lochrasterplatinen aufbauen kann. (Was ich nicht kann, wenn ich meinetwegen PCI Steckplätze nehme)

Ich hoffe auf eure kreativen Beitrage :D
Gruß, CowZ

Hi Cowz,

du hast noch die Powerleitung (12V) vergessen.
Für größeren Energiebedarf gehtst du zwar wahrscheinlich direkt vom Netzteil / Akku aus, aber für kleinere Sensoren/Aktoren kanns hilfreich sein.

Ich würde evtl. den Master-Controller ebenfalls nur auf ein recht kleines Modul packen.

Was hältst du davon, alle Module mit einem 5x2-Pfostenstecker zu versehen und dann alle inkl. Master mittels eines 10-adrigen Flachbandkabels mit entsprechend vielen 5x2-Buchen zu verbinden..
Falls Terminierung der Leitung erforderlich, kann man hierfür ebenfalls am Ende des Kabels ein Minimodul einstecken.

So kannst du deinen Bus beliebig erweitern, einfach noch ne Buche anquetschen.

Natürlich kannst du auch eine Platine als Verteiler nehmen, um dann dort alle Leitungen einzustecken.

Ich weiß nicht, was der I"C für Anforderungen an den Bus stellt (sind Stichleitungen erlaubt?, wenn ja wie lang)

Nachteil:
Für einige Sensoren ist eine sternförmige Verkabelung günstiger.

sigo

PS: Hast du schon die AVR-Controller gesehen, bei denen jeder Pin ein Interrupteingang ist? z.B. ATmega169 usw.
Mit denen würde ich dann sternförmig arbeiten und jeden Controller mit einem eigenen Interrupt anbinden. Das ist natürlich dann komfortabel.
Von sowas habe ich in meinen aktiveren Zeiten nur geträumt.

Stimmt, die "Hoch"-Spannungsleitung ist ne gute Idee :) *merk*

Den Mastercontroller auch auf ein Modul (mit identischem Anschluss) wird nicht möglich sein, da dieser besondere Anschlüsse benötigt (z.B. die "PollMe"-Interuptleitung der Module. (s.o.)

Meinen Bus kann ich auch erweitern, wenn ich Platinen als "Steckplätze" habe, also als Verteil. Dann kann ich die einfach immer wieder aneinander hängen ;)

"Für einige Sensoren ist eine sternförmige Verkabelung günstiger."
Die Sensorauswertung kommt sowieso immer auf dem Modulcontroller.

Zu den Mega169 usw. Wofür? Ich kann die Module auch per I²C-Porterweiterungen anschließen (z.b. PCF 8574). Diese lösen auch einen Interrupt aus, sobald sich ein Port verändert. Sobald dieser Interrupt ausgelöst wird (am Hauptcontroller) muss der Hauptcontroller nur noch meine Porterweiterer abfragen und so sehen, welches Modul "Alarm geschlagen" hat.

So, ich bin's wieder :)

Habe mich jetzt (falls ich nicht aus Bekanntenkreisen Motoren geschenkt bekommen sollte) für folgende Motoren entschieden:
Conrad-Link

Diese scheinen mir extrem leistungsfähig zu sein - im Vergleich zu anderen Getriebemotoren bei Conrad. Sprechen irgendwelche Punkte gegen diese Motoren?

Gruß, CowZ
PS: Sry, balds geht hier wieder flotter weiter, muss ersmal mein Zimmer zu ende streichen ;) Dann bekommt ihr auch Schaltplan und Layout vom Modul-Steckbrett und der Hauptcontrollerplatine.