Hi,

das meiste, was ich hier so sehe, sind kleine Testprogramme, die meist immer von vorne anfangen.

Ich werde die nächste Zeit wohl einiges mehr mit den Nibobees machen, und möchte das auch gleich auf ein vernünftiges Gerüst stellen.

Ich persönlich finde die Bibliothek des nibos gar nicht mal so schlecht, sie ist eine gute Grundlage. Ich würde sie um folgende Punkte erweitern:

* www.roboternetz.de/community/threads/47567-NIBObee-Hier-ist-eine-alternative-C-Library - daraus die serielle Schnittstelle für printfs etc. kompatibel machen, erspart viel Arbeit^^ Dabei das Display als 2. Kanal anbieten und eventuell auf den AVR des Displays eine PS/2 Unterstützung einbauen, sodass man eine Tastatur anschließen

* Warteschlangen für die einzelnen Interrupts, sodass ich mehrere ISRs für einen Interrupt registrieren kann

* Lokalisierung mithilfe der Incrementalgeber: Man hat ein Koordinatensystem, dessen Ursprung bei der Startposition ist (aber verschoben und gedreht werden kann). Mithilfe der Incs. wird die Position und Orientierung berechnet. Wird mit der Zeit ungenau, geht aber erstaunlich gut.
* "Fahre 2m vorwärts / drehe um 30 Grad"
* "Fahre auf Position x/y"
* Die Fahrkommandos sollen parallel zum Hauptprogramm ablaufen, und ein Flag gesetzt werden, wenn die gewünschte Position erreicht wurde
* I2C Bibliothek für verbreitete Bauteile (A/D Wandler, Port Extender, Speicher,RTC,...) - gerne auch Einbindung anderer Bibls.
* Grundfunktionalität für SLAM
* Grundfunktionen für die Verarbeitung der IR-Signaldaten

Ich würde dafür auch ein SVN-Repository etc. aufsetzen. Wer würde so mitmachen?

Hallo mifritscher,

wenn Du dafür Code-Teile aus der NIBObee Lib verwenden möchtest, kannst Du das gerne tun, ist ja Open-Source...
Es wäre auch prima, wenn Du die Daten aus der Kalibrierung des Liniensensors übernehmen würdest, dann wären die EEPROM Daten kompatibel!

Gruß,
workwind

Ja, ich werde möglichst viel aus der NIBObee Lib verwenden Das NIM Syndrom (not invented by me) ist da nur schädlich^^
Die Kalibrierungsdaten sind kein Problem, ich habe nur insofern etwas Bauchschmerzen, dass die Daten keinen "Kopf" haben, wo zumindest die Versionsnummer und ein "Magic String" enthalten ist, anhand man schauen könnte, ob die Daten ok sind.
Nunja, werde ich wohl tricksen: ich werde gucken, ob plausible Werte für die Liniensensoren vorhanden sind, und ob in den 4...16 Bytes danach und in den Positionen 251-255 Nuller stehen, Wenn ja, werde ich ab Position 251 des EEPROMS die Version und das Magic Word nachtragen. Ich denke mal, dass 255 Bytes für Konfigurationsachen wie Namen, Kalibrierungswerte, I2C Adressen etc. erstmal dicke reichen

Dieses Layout wäre dann sowohl mit der ursprünglichen Bib als auch mit der "neuen" kompabibel.