c't

c't-Projekte - Mailinglisten


[Voriger (Datum)] [Nächster (Datum)] [Voriger (Thread)] [Nächster (Thread)]
[Nach Datum][Nach Thread]

Re: Fwd: Re[2]: [ct-bot] ct-Bot-Wettkämpfe

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