heise online · c't · iX · Technology Review · Telepolis · mobil · Security · Netze · heise open · heise resale · Autos · c't-TV · Jobs · Kiosk
Zum Inhalt
c't

c't Projekte - c't-Bot und c't-Sim - Mailinglisten

c't-Bot und c't-Sim


[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: Benjamin Benz
Datum: Mi, 26.04.2006 12:17:47
In-reply-to: <444F37DB.6000007@xxxxxxxxxx>
References: <006901c668cf$6bf19030$2201a8c0@user08> <444F37DB.6000007@xxxxxxxxxx>


Hallo,

>> beigebracht wird, sollten weder Compiler- noch Linkeroptionen die
>> Logik der
>> Algorithmen beeinflussen. Ob der Linker nun frisch übersetzten Quellcode
>> oder alte libs verwendet, sollte IMHO Einsteigern doch eigentlich
>> ziemlich
>> egal sein.
> 
> Eben nicht. das eine Mal fängt man mit einem Haufen Quellcode an,
> in dem man main() erstmal suchen muß, das andere Mal gibt es ein
> paar Bibliotheken und Header, das erste Projekt kann aber leer sein.

Nun, ganz sollte man vielleicht auch die begleitenden c't-Artikel nicht
ausser acht lassen, denn dort finden sich genau die Hinweise, wo man am
besten einsteigt.

> Ein "int main(){ led(GREEN,ON); }" ließe sich dann flashen, und
> würde einen wirklich einfachen Einstieg garantieren.
das lässt es auch so. Es spricht nicht das geringste dagegen, in
ct-Bot.c eine eigene neue Main-Routine zu schreiben, die genau so aussieht.

> Zum einen finde ich das Framework nicht sehr modular (so sind z.B.
> Maschinenkonstanten über etliche Headerfiles verstreut), zum anderen
> soll eine Modularisierung dem Anfänger helfen und den Fortgeschrittenen
> nicht hindern. Das momentane Framework bietet nur letzteres.

Eben das ist modular. Wäre alles an einem Ort würde ich den Begriff
monolithisch verwenden. Die Konstanten sind, wo auch immer möglich dort,
wo sie thematisch dazugehören. Wer sich gerade mit den LEDs beschäftigt
soll sich doch nicht durch Timer-Konstanten wühlen müssen. Wer an der
PWM spielt, braucht nicht im gleichen File die Definitionen für die
Sensorkalibration. Es gibt zu fast jedem Themenkomplex ein .c-File und
den dazu passenden header (.h) hier die Liste:


File		Inhalt

mcu/ :
adc.c       	Analog-Digitalkonverter
display.c 	Display-Routinen
ir-rc5.c	Low-Level dekodierung/Empfang von IR-Signalen
motor-low.c  	PWM-Steuerung und Co
sensor-low.c	Low-Level Abarbeitung der Sensoren
srf10.c		Ansteuerung eines Ultraschall-Distanzsensors
TWI_driver.c	Ansteuerung der I2C- (alias TWI-) Schnittstelle
bot-2-pc.c  	Kommunikation mit dem PC per UART
delay.c		Delay-Routinen
ena.c		Ansteuerung der Sensor-Schalter
led.c		Ansteuerung der LEDs
mouse.c		Ansteuerung des Maussensors
shift.c		Ansteuerung der Shift-Register
timer-low.c	Timer
uart.c		Low-Level-Routinen für die serielle Übertragung

Bei Bedarf setze ich diese Liste auch gern mit den weiteren Files in den
anderen Verzeichnissen fort.

Ich denke, der Begriff Modular trifft hier zu. Wobei wie sicherlich
nichts gegen konkrete Umbauvorschläge haben, wenn sie es modularer machen.

> (das wäre ebenso ein Beispiel) dazuschreiben? Der erfahrenen Benutzer
> hat dann das Framework, welches keine hartkodierten Werte benutzt,
> sondern Konstanten/Funktionen bietet, der Anfänger kann direkt sein
> 1001 benutzen, um erstmal mit der FB rumzuspielen. Beide benutzen
> dann aber doch eine Funktion "uint16 remotecontrol(void)" einer Basis-
> Bibliothek.

Im derzeitigen Modell, bekommen aber doch alle alles. Der Einsteiger
kann sofort loslegen und alles ignorieren. Der Erfahrene Coder kann auch
tiefer einsteigen. Zwei getrennte Code-Basen machen die wartung viel
komplexer und Binary-Libraries machen es IMHO auch nicht besser und
machen 1. die Installation schwieriger und dürften in absehbarer Zeit
für komplexe Versionsabhängigkeiten sorgen (siehe Linux). Derzeit kann
man aus dem CVS eine Version holen und weiss, alles passt zusammen.

> Nochmal: das sind nur Ideen, ob die Routine wirklich so heissen soll,
> ob sie keinerlei Parameter kennt, ob es eine Routine für die RC5-Nutzdaten
> und eine für die RC5-Adresse geben soll, das alles ist mir nicht wichtig,
> nur eben die Idee, Einsteigern einen simplen Einstieg zu ermöglichen.
gerade beim Verhaltensframework haben wir uns bemüht es auf einfache
Nutzung für Anfänger zu optimieren (siehe Bsp. in meiner anderen Mail).
der preis dafür ist allerdings ein etwas komplexeres Innenleben. Ich
würde aber hier gerne nochmal ganz kurz für das Verhaltensframework
werben, bzw. die dahinter stehenden Überlegungen darstellen:

1. Es soll aller Low-Level-Kram im Hintergrund geschehen, damit dem User
ganz einfach Sensorwerte und co zur Verfügung stehen, ohne dass er sich
drum kümmern muss
2. Es soll ohne komplexe Dinge wie Echtzeitbetriebssysteme auskommen
3. Es soll möglich sein Straight-Forward-Code zu schreiben. d.h. um
delays und Co muss man sich ebensowenig kümmern wie um PWM-Werte und
Stromsparfunktionen der Sensoren
4. Es soll möglich sein modulare Verhalten zu bauen, die man immer
wieder verwenden kann.

Und ich denke genau das tut es im Moment. Hier nochmal ein ganz kurzes
Bsp. für ein Verhalten, dass den Bot Stoppt, wenn er vor einem Abgrund
steht:

void bot_avoid_border_behaviour(Behaviour_t *data){
  if (sensBorderL > BORDER_DANGEROUS)
    speedWishLeft=-BOT_SPEED_NORMAL;
	
  if (sensBorderR > BORDER_DANGEROUS)
    speedWishRight=-BOT_SPEED_NORMAL;
}

Könnte es sein, dass wir vielleicht eher ausführlichere Doku brauchen,
als eine umdefinierte API? Ich finde den hier in der Liste gemachten
Vorschlag dafür schon sehr gut und würde mich über weitere freuen. Dann
können wir da vielleicht gemeinsam etwas auf die Beine Stellen. Ich
würde mich freuen, wenn gerade die Kritiker, die sich ja damit
beschäftigt haben uns konstruktive Vorschläge liefern, damit wir die
Punkte, die uns bisher entgangen sind glatt schleifen können, denn ich
denke unser Ziel ist identisch: Eine Codebasis zu schaffen, die für
Anfänger und Profis passt.

MfG Benjamin Benz
-- 
Benjamin Benz
Heise Zeitschriften Verlag
Redaktion c't
eMail: bbe@xxxxxxxx
WWW  : http://www.heise.de





Copyright © 2007 Heise Zeitschriften Verlag Kritik, Anregungen bitte an c't-WWW Datenschutzhinweis   Impressum