Roboterhauptprogramm

[oderlachs]

Ich hoffe ja das ich in dieser Rubrik hier richtig bin, aber ich habe ein grosses Problem beim Erstellen des Hauptprogrammes für den Roboter.
Bislang habe ich ja nur einzelne Test der Sensoren und Aufgaben gemacht, um die Reaktion des Roboters darauf zu testen. ich kann ja natürlich im Main auch grob verschiedene Aufgaben auswählen , wie da sind Linienfahrt usw. Aber wenn ich den Robby so durch die Gegendfahen lassen möchte , muss er natürlich auch auf alle Sensoren (Anstossen, Abstand(IR/US), Tischkantenerkennung bzw ein "Nichts vor ihm" , Rufen, Licht usw) Reagieren. Da will ich nicht jedesmal für ein extra Programmfile uploaden...

In richtigen PC Programmen ( mit Delphi,ASSR, C++ usw. ) war das ja keine Hürde, aber wie mache ich es hier, ist ja auch eine Speicherplatzangelegenheit bestimmt.

Gibt es denn irgendwo da mal Code-Beispiele zu Anschauen, oder verstehe ich das ganze falsch un muss wirklich für jede "Rubrik der Robotereinstellung" neu das Programm aufspielen?

Gruss und Dank Gerhard

[ijjiij]

Für Code-Beispiele wäre es sicher empfehlenswert zu wissen, welche Programmiersprache du überhaupt verwendest (verstehst), hat ja kaum sinn dir da Basic-Code hinzuknallen wenn du damit nix anfangen kannst, mit C aber sehr wohl.

Prinzipiell nehm ich an ist Programmieren ja nix neues für dich (entnehme ich deiner Aussage), ein Programm für deinen Bot unterscheidet sich da prinzipiell kaum davon.
Definier dir am anfang deine Variablen, den Rest des Programms lasst du dann in einer Schleife ablaufen. Bestimmte Sensor-Werte lässt du deine Variablen ändern, Reaktionen darauf sind dann halt abhängig von dieses Variablen. Dadurch das die Schleife sowieso endlos durchlaufen wird, gleichen sich die Variablen immer wieder an, somit wird immer wieder neu entschieden, welche Reaktion auf die Sensor-Werte passiert.

Beim Linienfolger von ASURO (den du ja anscheinend hast, auf deiner Website gesehen) sieht man das eh gut. Wenn links dünkler ist als hell wird drauf reagiert, umgekehrt genauso. Versuch mal da herum noch eine Taster abfrage zu basteln. Sowas in die Richtung von, if(kein Taster ist gedrückt) -> folge der Linie, also führe das normale linien-such Programm aus, else{irgendeine Reaktion auf die Taster, rurückfahren oder blinken oder ähnliches}

Nach dem gleichen Prinzip kannst du alle Programme aufbauen.


Hoffe das ist iwie verständlich für dich...

lg
ijjiij

[radbruch]

Hallo

"In richtigen PC Programmen ... war das ja keine Hürde,.." ..weil der PC ein Betriebssystem besitzt das im Hintergrund mitarbeitet.

Ein AVR hat das natürlich nicht, deshalb muß man sich um die Organisation des Programmablaufs selbst kümmern. Basis ist die Hauptschleife. In ihr wird zyklisch alles erledigt was nicht zeitkritisch ist und jederzeit unterbrochen werden kann. Das sind z.B. Anzeigen, Textausgaben, Einlesen von Pufferspeichern, größere Berechnungen usw. Wichtig ist, dass man in der Hauptschleife keine blockierenden Funktionen verwendet, gegebenfalls muss man die Abarbeitung von größeren Aufgaben auf mehrere Zyklen verteilen. Die Zykluszeit sollte so kurz wie möglich sein.

Gleichzeitig (wirklich gleichzeitig!) kann ein AVR mit seiner Hardware asynocron zur Hauptschleife arbeiten. Z.B. kann er per Hardware-PWM Ausgänge schalten oder serielle Daten einlesen und ausgeben (USART, SPI, TWI...), AD wandeln oder Gleichspannungen vergleichen. Diese Funktionen werden meist einmalig angestoßen und laufen dann im Hintergrund quasi als Hardwareprogramme (in den AVR eingebaut) weiter.

Wenn für schnelle Vorgänge die Zykluszeit der Hautptschleife zu lange dauert, kann man die Hauptschleife mittels Interrupts kurzzeitig unterbrechen und in die Abarbeitung einer Interruptanforderung verzweigen. Auch hierbei muss man auf möglichst kurze Abarbeitungszeiten achten. Beispiele sind Flankenerkennungen von Gebersignalen, gepufferte serielle Kommunikation, Tastenabfrage, Timer- und Counterfunktionen oder AD-Wandeln. Die Kommunikation zwischen ISR und Hauptschleife geschied über Flags.

Wie man das umsetzen kann zeigt die Library des RP6. Sie besteht aus einer Sammlung von Tasks für die verschiedenen Komponenten des Roboters. Damit wird eine Art von kooperativem Multitasking ausgeführt (natürlich ist es beim AVR kein echtes Multitasking) bei dem sich die einzelnen Tasks nach der Abarbeitung ihrer Aufgabe freiwillig beenden.

https://www.roboternetz.de/community...king-für-asuro
https://www.roboternetz.de/community...-quot-beim-RP6
RP6-Anleitung: http://arexx.com/rp6/downloads/RP6_M...E_20071219.zip (Ab Seite 78)
RP6-Library: http://arexx.com/rp6/downloads/RP6Examples_20080915.zip

Gruß

mic

P.S.:
Zustandsmaschine (statemashine): https://www.roboternetz.de/community...-macht-Ihr-das

[seite5]

hallo,
ich verwende ich ähnliches, wie oben dargestelltes Prinzip:
In einer Hauptschleife werden Status-Bytes auf ihren Zustand abgefragt und entsprechende Programmverzweigungen "angesprungen". z.B. Motor-Status hat sich geändert, verzeigen in die
Motor-Routine, dort Ports/PWM einstellen und nach wenigen µs zurück zur Hauptschleife. Dieses Status-Byte wird dann bei erreichen des Ziels durch Interrrupt (Rotary-Encoder/Compare_Match_Int)
wieder zurückgesetzt. Innerhalb der Hauptschleife gibt es den Aufruf einer Programm-Routine, falls ein Programm ausgeführt werden soll (wird beim Start durch Abfragen einer Dip-Schalterbank
erkannt) wird in dieses Routine verzweigt. Aus einer 2-dim Tabelle nimmt sich diese state machine den nächsten "Auftrag" (1. dim = Programm-Nr.), setzt bestimmte Status-Bytes und kehrt wieder
in die Hauptschleife zurück zur Abarbeitung dieser und inzwischen anderer angefallener Aufgaben. Ist die durch die state machine gestellte Aufgabe erledigt, wird ein flag task_ready gesetzt und
der pointer auf die Aufgabentabelle erhöht. Am Ende jeder Tabellenzeile steht ein LOOP, die state machine setzt dann den pointer wieder auf den Anfang der Zeile. Um "regelmässige" Aufgaben
zu erledigen läuft ausserdem im Hintergrund ein 10ms-timer, der u.a. alle 1min ein flag setzt, das die Hauptschleife bei "Untätigkeit" veranlasst, eine Routine zur Batteriekontrolle aufzurufen.
mfg
Achim

[oderlachs]

Hallo liebe Helfer !
So ich möchte erst mal herzlichen Dank für Hinweise und Anregungen sagen !!!

Mit meinen Asuro 1. habe ich noch mech. Probleme, die Motoren wollen einfach nicht in der Stellung fest bleiben, wo ich sie per Strapse fixiere, die werde ich wohl (ungern)kleben müssen. Beim Eigen-Nachbau (Foto Webseite) warte ich da noch auf Distanzstücke, die noch irgendwo auf dem Postwege umherschwirren..grr.
So muss ich mich noch mit den Unterprogrammen befassen die ich so testen kann, der US-Sensor fehlt auch noch, aber das GPG Modul ist schon getestet und kann dann eingebunden werden, mehr so als "Luxus" in der Anzeige auf dem Display als wie zur <Notwendigkeit im Betrieb, Thermofühler gehen auch für den MotordriverIC...

@Radbruch :
ich werde mir mal die angegebenen Links zu Gemüte ziehen...mit den IRQ Routinen bin ich noch nicht so bewandert, das muss ich noch am "Trockenmodell" ausprobieren...

@seite5 :
Ja mit entsprechenden Flags hatte ich mir das schon so ausgedacht, kenne das aus anderer Programmierung, wo es darauf ankam verschiedene Statuspunkte abzufragen

@ijjiij :
Ob Basic, C, oder Assr ich durfte alles mal erlernen, will mich hier also noch nicht festlegen welches beim AVR die Standart-Sprache wird, da ich auf dem STK 500 fast alles in Bascom erledige, so ist doch der "Arduino & co." eigentlich mit C zu bewältigen..

Gruss und Dank Gerhard