Absender: Michail Brzitwa
Datum: Mi, 26.04.2006 00:36:55
In-reply-to:
<444E01B3.3060408@xxxxxxxx>
References:
<896780142@xxxxxx> <444DFD7F.80705@xxxxxx> <444E01B3.3060408@xxxxxxxx>
Am 25.04.2006 13:02, schrieb Benjamin Benz:
hier verstehe ich nicht ganz, was gemeint ist. Der ganze Bot-Code ist doch extrem stark gekapselt. Wer keine Lust auf Low-Level-Programmierung hat, ignoriert die Unterverzeichnisse und beschäftigt sich mit 2-3 verbliebenen Dateien im Hauptverzeichnis. Alles andere übernimmt das Framework. Wer nur ein Verhalten programmeren will, kommt sogar mit einer einzigen Datei aus. Vorher übersetzte Binary-Libraries bringen da IMHO keinen Vorteil. Und wen die interna nicht interessieren, kann doch die entsprechenden Dateien getrost zu lassen.
Ich habe aber auch schon an funktional gegliederte Bibliotheken gedacht. Die aktuellen Quellen sind viel zu komplex, um Einsteigern das Leben einfach zu machen, insbesondere schreckt das sicherlich gut gemeinte Behaviour-System doch eher ab, da man eben doch dort nach- schauen muß, warum der Bot gerade etwas bestimmtes macht. Wenn man z.B. die Licht/Wandfolger-Quellen aus dem anderen Forum anschaut, wird das Problem sofort offensichtlich: dort braucht es zehn bis zwanzig Zeilen Code, um eine absolut simple Fahrstrategie umzusetzen. Als anderes Beispiel mag das Turtle-Konzept der Sprache Logo herhalten: zum Lernen auch komplexerer Zusammenhänge und Problemstellungen war das System hervorragend geeignet, obwohl oder eben weil das Grundgerüst sehr einfach aufgebaut war. Hätte ich die Zeit (momentan komme ich bzgl. der ct-Bots zu garnix), würde ich wahrscheinlich versuchen, einige echte Bibliotheken für die Sensoren/Aktorensteuerung vorzuschlagen und mit zu entwickeln, die wirklich nur einfachste Schnittstellen bieten: - momentaner Wert Rad/Kante/Distanz/Linie rechts/links (keine globalen Variablen, sondern Funktionsaufrufe), - Setzen der Motorengeschwindigkeit rechts/links, - Setzen anderer Aktoren (LEDs etc.) - momentane Werte anderer Sensoren (auch IR etc.). Wenn dann das existierende Framework auf dieser simplen Bibliothek basieren würde, könnte der bis jetzt eher verwirrte Anfänger das Framework einfach wegwerfen (nicht benutzen), die Bibliothek in das eigene, leere Projekt einbinden, und Code ala int main() { led(LEFT_BLUE,ON); while (1) { if (sensor(DISTANCE,LEFT) < 30) motor(BACKWARD,10,30); // rechts etwas, links stärker zurück else if (sensor(DISTANCE,RIGHT) < 30) motor(BACKWARD,30,10); // rechts stärker, links etwas zurück else motor(FORWARD,30,30); // gleichmässig nach vorn pause(10); // zehn ms Pause } } schreiben. Im obigen Falle gäbe es keine Verarbeitung von RC-Kommandos, keine echte Kollisions/Kantenvermeidung usw. Perfekt um zu lernen, und einfach dazu. Zehn Zeilen, und der Bot rennt los. Zudem würde eine derartige Kapselung (nicht eben nur auf Quelldatei- Basis, sondern direkt auf Projekt/Binärbasis) erlauben, komplexe Änderungen ohne die momentanen Abstimmungsprobleme zu beginnen. Ich möchte mich z.B. irgendwann doch nochmal mit einem Multithreading- Kern für den Bot befassen, dazu sollte aber nirgends auf irgendwelche Variablen zugegriffen werden, die eine Hardware-Nähe aufweisen, kein direkter Zugriff auf irgendwelche I/O-Ports usw.usf. So könnte obiges motor() im ersten Stadium direkt aus bestehendem Code zusammengesetzt werden, später könnte das eine Signalfunktion für einen Aktorenthread sein, die diesem Thread die Werte übergibt, und ihn dann aufweckt. Den Threading-Kern könnte ich sowohl obigem Miniprojekt als auch dem aktuellen Behaviour-Projekt unterjubeln. Eine Aufteilung in verschiedene Bibliotheken und einem Hauptprogramm würde wahrscheinlich auch die CVS-Verwaltung vereinfachen, da weitaus weniger Quelldateien pro Projekt zu überschauen wären. Ist natürlich nur eine Idee von vielen, ob es wirklich motor() heissen oder drei Parameter haben sollte, ist nicht wirklich relevant. Die Schnittstellen müssten gut durchdacht und letztlich so simpel wie nur möglich sein. Gruß, -- Michail Brzitwa <michail@xxxxxxxxxx> +49-511-343215