Umbau meines Roboters

[robodriver]

Hallo ihr lieben,

ich Plane momentan den Umbau meines Roboters und würde ganz gern eure Meinungen dazu hören. Vielleicht könnt ihr auch noch verbesserungsvorschläge machen. Den jetzigen Entwurf finde ich selber recht gewagt, aber ich denke er lässt sich umsetzen. Desshalb hätt ich gern mal eure Meinung dazu...

Also der jetzige Stand des Roboters ist hier aufgeführt: http://www.cyberdriver2.de.vu
Besonders mal unter Schaltplan nachsehen.

Nun Plane ich folgenden Umbau:

1. Display
Das Floureszenzdisplay mit den beiden Controllern als Ansteuerung fliegt komplett raus, es hat zwar funktioniert, aber hin und wieder kam es zu verschiebungen einzelner Stellen und 8 Zeichen sind mir allmälig zu wenig.
Hier soll ein LCD Dotmatrixdisplay mit 2x16 Zeichen eingesetzt werden.
Da mehrere Controler die Möglichkeit haben sollen etwas auf dem Display anzeigen zu lassen und dieses Display, was ich da habe keinen I²C Bus hat, bekommt das Diplay einen eigenen uC.
Damit dieser uC sich aber nicht all zu sehr langweilt, wird er ebenfalls nich ein IR-Empfangsmodul abbekommen und die Daten auswerten, die per IR-Fernbedienung gesendet werden.

2. Motorsteuerung
Bisher ist der uC der die Motoren ansteuert gleichzeitig auch der Hauptcontroler die die Menüsteuerung realisiert, Programmaufzeichnungen und wiedergaben und so weiter...
Dieser Controler ist mittlerweile von der Software bis unters Dach voll gepackt.
Jetzt sollen die Motoren durch 2 neue mit Radencoder ersetzt werden. Der uC wird desshalb entlastet und soll sich ausschließlich um die Motorsteuerung kümmern. Also auch die Auswertung der Encoder, drauf achten das er gerade aus fährt und die Soll-Geschwindigkeit immer hält.

3. Haupt-Steuerung
Der uC mit der Adresse 2, der auf dem neuen Schaltplan doch sehr unnütz wirkt, soll die Komplette Steuerung und Koordinierung übernehmen. Sprich Menüsteuerung, Ausweichrutinen, Wegfindung bis hin zum abspeichern ganzer Maps eines Zimmers (evtl. bekommt er später dann noch ein externes EEPROM)

So viel dazu...
Was ich nun dabei sehr gewagt finde: Alles läuft über den I²C Bus.
Displaytexte, Sensorzustände, Motorbefehle... Ich denke die Buslast könnte relativ hoch werden...

Wie seht ihr das? Was haltet ihr von der neuen Idee? Würdet ihr etwas anders machen?

Freu mich auf eure Anregungen

Gruß Robodriver

PS: Im Anhang der Schaltplan, wie alles nach dem Umbau aussehen soll

[Andun]

Hi

Ich finde deine Ideen sehr gut und die hören sich auch schon einigermaßen gut durchdacht an.

Ich denke nicht, dass der I2C Bus damit so schnell überfordert ist, da er ja auch dafür ausgelegt wurde, viele Chips zu verbinden und abzufragen.

Wie hast du das Protokoll dafür denn vorgesehen? Fragt der Hauptcontroller die anderen µC ständig ab, oder willst du das ganze im Multimasterbetrieb laufen lassen?

mfg
Andun

[robodriver]

Also die I²C Geschichte ist ja unter Bascom (womit ich programmiere) immer so ne heikle Geschichte. Funktioniert, aber nicht so ganz zu 100%...
Desshalb habe ich mir diesen Bus bei meinem aktuellen Roboter mal zu gemüte geführt, mir eine eigene Bibliothek in Assembler geschrieben und was soll ich sagen: Der Bus funktioniert einwandfrei. Bei dem jetzigen habe ich es noch folgender masen laufen:
Beim Initialisieren wird jeder Chip zum Slave mit der definierten Adresse. Sobald ein Chip Daten an einen anderen Chip senden will, macht er sich, insofern der Bus frei ist, selbst zum Master, sendet die Daten und macht sich direkt im Anschluss wieder zum Slave.
Multimaster ist das glaub ich nicht direkt, weil soweit ich das verstenden habe, bei Multimaster mehrere Master gleichzeitig am Bus hängen oder?

Egal.

Auf jeden Fall werden (orientiert am Display) immer 32 Byte Daten versendet.
Es soll z.B. so laufen:
Sensor vorn links erkennt Hindernis, aktiviert Interrupt vom Motor-Chip zum sofortigen stehen bleiben und sendet über Bus an den Hauptcontroler welcher Sensor geschalten hat. Dieser berechnet daraus dann (unter Beachtung, was zuvor alles so passiert ist) eine Ausweichroutine und gibt dann über den Bus die entsprechenden Fahr-Befehle an den Motor-Chip. Während der Ausweichroutine ist der Sensorchip aber jeder Zeit berechtigt diese über den Interrupt zu unterbrechen, damit beim Ausweichen nichts umgefahren wird.

Die Interruptsteuerung hat sich bei mir recht gut bewährt, da über den Bus doch einige Verzögerungen entstehen und ich es anfangs bei dem aktuellen Roboter auch hatte, das die verzögerung so lange war, das er trotz erkennung gegen die Wand gefahren ist, weil die Reaktionszeit einfach zu lang ist übern Bus. Desshalb diese Interrupt-Steuerung

Was mich an der ganzen Geschichte etwas irritiert: Ich benötige 4 uC.
Auf den meisten anderen Robotern ist meist nur 1 Chip. Was mach ich anders/falsch? ODer sind meine Programmierkünste doch noch zu schlecht; weil ich hätte null Plan wie man all diese Funktionen in einem Chip vereinen sollte...

[Robotniks]

Hi,

sehr schönes Projekt!!!

Aber deinen IR-Code zur FB erkennung finde ich nicht im Quellcode

Genau das würde mich für meinen kleinen Bot interessieren...

Die Rutine zum Teachen und zum auswerten mit EEPROM, wenn ich da richtig sehe schaust du nur auf die Bits und machst deinen eignen BIN Code??!!

Kannst du das näher erklären ich steige da leider net durch

Grüße Oli

[Foooob]

Ich habe nicht alles bis ins Detail gelesen aber ein paar Punkte meinerseits:

I2C-Bus:
- Der I2C-Bus ist für viele Chips an einem Bus ausgelegt und funktioniert damit auch Ich habe an meinem Roboter 9 I2C-Devices hängen. Das ganze funktioniert super. Die Verzögerungen durch den Bus sind Minimal. Das ganze ist ja mit 100kHz bzw. mit 400kHz getaktet. Das ist im Vergleich zu dem Datenaufkommen von ein paar Bytes pro Device völlig ausreichend. Das einzige was zeitintensiv ist sind die EEPROMs die physikalisch bedingt nunmal bis zu 10ms zum Schreiben brauchen. Hier eignen sich jedoch Flash-Speicher, die sind bedeutend schneller.
Und wenn man wirklich auf Zeit arbeiten will und EEPROMs braucht kann man ´nen Flash einbauen, den der MasterµC beschreibt und ein Slave die daten vom Flash in einen EEPROM brennt.


µC:
Ich verstehe nicht wieso du das so kompliziert machst? Soweit ich das verstanden habe hast du ein paar Sensoren, Motoren und ein Display. Dafür 4µC zu nehmen ist wie ich finde total ineffizient. Dazu reicht wirklich ein einziger dicker AVR.
Ich würde die ATmega8 Flotte gegen einen einzigen ATmega128 ersetzen, den mit 14,7xx MHz (für RS232) oder glatten 16MHz takten.
Der schafft das spielend.

Der Clou liegt nur in der Programmierung. Du darfst nicht eine (zeitintensive) Aufgabe nach der anderen machen sondern musst diese geschickt aufsplitten. So kommt es auch zu keinen bzw. minimalen Verzögerungen. Die liegen auf jeden Fall bei wenigen ms.

Ich hab selbst ein Programm mit ca. >10k Zeilen, dutzend Sensoren, Motoren, Servos, LCD, I2C, RS232...der AVR braucht nur ca. 100ms um das komplette Programm einmal zu durchlaufen. Darin enthalten sind auch Delays für die RS232, wenn man die rauslässt dauerts keine 50ms.

[CowZ]

Hi,

es lässt sich meist ziemlich viel in einen µC integrieren. Wenn man bspw. einen Atmel AVR Mega nimmt, dann kann man die Motorsteuerung per Hardware-PWM machen.
Die integrierten ADCs sind auch (relativ) schnell, um Hindernisse etc. zu erkennen. Das Display ist auch nicht besonders zeitkritisch.

Imho sollte das (locker) auf einen Mega passen, kommt natürlich auch drauf an, wie "krass" deine Algorithmen sein sollen.

Was man natürlich machen sollte: Möglichst viel von der Hardware ausnutzen (Hardware PWM, Hardware IIC/TWI, etc) und auch mit Interrupts arbeiten.

Gruß, CowZ

[HannoHupmann]

übrigens bischen offtopic @Robodrive "Widerstand ist zweglos" schreibt man mit "ck" und nicht mit "g" :-D kommt nämlich von Zweck und nicht von Zweg was es gar nicht gibt.

[robodriver]

Ja, also ich nutze ja die Hardware PWM und auch das Hardware TWI.
Aber dennoch.
Ich habe ja nie was festes zum Thema Software gelernt. Ich Programmiere zwar mittlerweile seit über 3 Jahren in Visual Basic, aber Bascom ist doch etwas anders. Alles selbst beigebracht und dadurch sicher an vielen Stellen nicht gerade rentabel der quelltext, wird bei mir immer sehr schnell äußerst unübersichtlich...
Und wenn ich mir nur mal die Ausweichroutine an gucke, die frisst momentan 100% der Resourcen. Der Controller kann in dem Moment nichts anderes mehr machen...
Gut, in der ausweichroutine steckt auch eine Menge drinne: Verschiedene Routinen zum ausweichen, erkennen wenn er sich in einer Sack Gasse verfangen hat und so...
Da könnt ich nicht noch nebenbei Sensoren auswerten...
Vielleicht würe es gehen, das übersteigt aber halt meine Softwarekenntnisse. Ich arbeite halt immer mit gaanz vielen do-loop schleifen für jede einzelne Funktion...

Aber ich denke darüber nach, den Displaycontroller und den Hauptcontroller in meinem neuen Entwurf zusammen zu fassen, denn nur mit Text anzeigen und IR-Fernbedienung auswerten, wäre der Display-Controller äußerst gelangweilt...

[robodriver]

übrigens bischen offtopic @Robodrive "Widerstand ist zweglos" schreibt man mit "ck" und nicht mit "g" :-D kommt nämlich von Zweck und nicht von Zweg was es gar nicht gibt.

Oh, *rotwerd* Rechtschreibung ist einer meiner Schwachpunkte... Dafür kann ich Roboter bauen *lol*

Danke für den Hinweis, werde es demnächst mal ändern...

[Foooob]

Ich sag dir mal vom schematischen her wie ich das in der Programmierung gemacht habe. Ich hab mir auch alles selbst beigebracht, also wird das auch nicht zu 100% optimiert sein, aber es ist mal eine Orientierungshilfe.


-Ich habe nur eine einzige DoLoop-Schleife (mit wenigen Ausnahmen für LCD, spielt jedoch keine Rolle), sie bildet das Hauptprogramm.

-Soweit es möglich ist werden immer nur Flags abgefragt, damit nie gewartet werden muss. Beispiel: Anstatt zu warten bis man ein Zeichen über RS232 oder I2C empfängt liest man nur die Zustandsflags der Buffer aus.

-KEINE Delays verwenden. Nur dort wo es wirklich hardwarebedingt nicht anders möglich ist. Das gleiche gilt für alle anderen zeitfressenden Dinge.

-Um den Roboter softwaremäßig nicht bei einer Warteroutine fest zu fahren kann man Timer oder den Watchdog nutzen, die dann nach einer bestimmten Wartezeit die Routine beenden, überspringen

-Möglichst die Hardware voll ausnutzen. Also Hardware PWM, I2C, UART, auch Timer, Watchdog,...



Die Rechnerei an sich ist extrem zeitsparend. Eine Addition beispielweise dauert glaube ich nur 5 Cycles oder sowas. Das sind wenige µs bis ns. Da kannst also weis der Geier was berechnen und es lastet den µC nicht aus.