Für den neuen Roboterbausatz NIBObee werden 5 Testpersonen gesucht, die
gerne über Ihre Erfahrungen beim Bau und bei der Programmierung des
Roboters schreiben wollen. Der Roboterbausatz wird gestellt und darf
behalten werden.

Bewerbungen mit kurzer Beschreibung der Vorkenntnisse bitte per Mail an:
nibobee@nicai-systems.de

Technische Daten:
* Atmel ATmega16 (15 MHz, 16 kByte Flash, 1 kByte SRAM, 512 Byte
EEPROM), erweiterbar auf ATmega644
* 2 Odometriesensoren mit Kalibrierung
* 2 Motoren mit 25:1 Getriebe
* 3 Funktions-LEDs
* 4 Tastsensoren mit Fühlern
* Integrierter USB-Programmer mit eigenem Mikrocontroller (ATtiny44)
* Liniensensor mit 2 IR-LEDs und 3 Phototransistoren
* 5 Erweiterungsports mit je 2 Bit
* 4 direkt ansteuerbare LEDs

Weitere Informationen unter http://nibobee.nicai-systems.de

Das Gerät wird übrigens auch bei Reichelt verkauft:

http://www.reichelt.de/?;ARTICLE=91023

Die Adressen werden wir selbstversändlich vertraulich behandeln und auf
keinen Fall für Werbezwecke, sondern nur für die Benachrichtigung der
Testpersonen benutzen.

Dass dort mehr als 5 Zeilen "Erfahrungsbericht" erwartet wird, duerfte
selbstverstaendlich sein, oder?

Zur Programmierung benötigt man lediglich einen Computer (Linux oder XP)
mit USB Schnittstelle. Der NIBObee hat einen integrierten
Programmieradapter, mit dem der ATmega16 über ISP programmiert wird.

Theoretisch ist ein Datenaustausch möglich, dazu müsste man allerdings
den ATtiny44 gegen den ATtiny84 austauschen um mehr Speicher zu
bekommen, der Tiny44 ist relativ voll ;-)
Die Kommunikation zum ATmega16 kann dann über das TWI erfolgen, die
ATmega-Seite müsste dabei in Software implementiert werden.

Ketzerische Frage:
Wäre es da dann nicht geschickter gewesen, in den Mega16 einen
Bootloader zu integrieren und der Tiny fungiert nur als 'USB Umsetzer'


(Kann man immer noch machen, von daher jetzt sicherlich kein Thema)

Wir haben uns gegen ein Bootloader-Konzept entschieden, da hier die
Gefahr des 'sich aussperrens' besonders hoch ist. Durch den Programmer
kann der ATmega16 (fast) in jeder Situation programmiert werden. Das
Fehlerhafte setzen der Fuse-Bits fangen wir durch ein eigenes
Windows-Programmiertool ab. Profis können auf AVRdude ausweichen, damit
können dann die Fuse-Bits beliebig gesetzt werden.

Nils Springob schrieb:
> Wir haben uns gegen ein Bootloader-Konzept entschieden, da hier die
> Gefahr des 'sich aussperrens' besonders hoch ist.

Hmm.
Wie gesagt, ist jetzt noch kein Thema. Aber das würde ich nochmal
überdenken. Meine Erfahrung (und auch die des Forums) ist nämlich genau
anders herum. Dadurch, dass man per Bootloader nicht an die Fuses
rankommt, ist die Gefahr des Aussperrens überhaupt nicht gegeben. Peter
Danegger hat da ein paar sehr gute Bootloader in der Codesammlung
hinterlassen. Wenn der Programmierer einen fatalen Softwarefehler
gemacht hat ... Bootloader starten, den Prozessor resetten und schon
kann die nächste Version eingespielt werden.

Nachteil:
  An die Fuses kommt man so nicht mehr ran. Da benötigt man dann einen
richtigen Programmer.
  Man muss ein wenig Programmspeicher opfern

Alles in allem ist es immer eines der ersten Dinge, die ich bei einem
neuen Prozessor mache ... Bootloader einspielen und den Programmer
wieder zur Seite legen (kommt dem Kabelsalat auf dem Tisch entgegen :-)

Aber hey: das müsst ihr entscheiden. War nur eine Idee. Ich denke nur,
dass es durchaus interesassant ist, wenn man nach einer 'Testfahrt' den
Robbi wieder an den PC anschliesst und dann ein spezielles Programm die
während der Fahrt gesammelten Daten auslesen kann.

Ben schrieb:
> im extremfall atmega raus, in einen programmieradapter gesteckt und
> schon kannst damit machen was du willst... ;)

Ja schon klar, das man das ändern kann.
Bei einem Produkttest kannst du aber nicht damit anfangen zunächst das
System zu modifizieren. Da musst du mit dem Testen was du vom Hersteller
kriegst.

Wir erwarten Berichte wie man mit der HW und der Lib klar kommt und auch
Erweiterungsideen. Die Ideen sind als Anregungen für andere Benutzer
gedacht, die "kommerziellen Erweiterungen" überlegen und entwickeln wir
selbst ;-)

Björn schrieb:
> Was wird denn als Erfahrungsbericht erwartet?

Ich denke mal
* Gab es Schwierigkeiten bei
    Aufbau
    Inbetriebnahme

* Einspielen der Software (USB Treiber können einem ja immer
  wieder mal einen Strich durch die Rechnung machen)

* Wie gut sind die Demobeispiele verständlich

* Wo waren Stolpersteine in der beigepackten Doku

* Wo waren Stolpersteine bei den ersten Programmen

* Gab es unerwartete Fehler oder Probleme in den
  beigepackten Libraries.


Solche Dinge halt.
Ziel ist es: Lieschen Müller soll den Robbi fahren lassen können. Kann
sie das oder stösst ie auf Schwierigkeiten. Und sei es nur, weil sie es
nicht gebacken bekommt, die Odometriesensoren gegen Fremdlicht
abzuschirmen (was zb beim Asuro ein Problem ist, dessen Lösung man sich
erst im Internet suchen muss).

@Ben
Da ich die Testpersonen mitauswähle, lese ich sie selbst ;-)

Wann werden die Leute benachrichtigt, die sich beworben haben?

Frage: warum eigentlich dieser Tage mit einem ATmega16 und nicht
gleich einem ATmega164P starten?  Die Preise dürften bei Mengenabnahme
vergleichbar sein, man ist hardwaremäßig komplett kompatibel mit der
möglichen Erweiterung auf einen ATmega644P, und die Software lässt
sich zumindest auf Quelltextebene 1:1 weiterverwenden auf dem 644.
Wenn man dagegen einen ATmega16-Quelltext später auf einen ATmega644(P)
portieren will, hat man nervige Umbenennereien der Register- und
Bitnamen.

Weiß nicht, ggf. wäre ja auch der geringere mögliche Stromverbrauch
des ATmega164P (im Vergleich zum mittlerweile Steinzeit-ATmega16)
ein Thema, falls das Teil auch irgendwie standby von der Batterie
arbeiten können soll.  Im Vergleich zum Stromverbrauch des Fahrwerks
sind das natürlich peanuts.

@Jörg: 100% ACK. Sollte ich mal so ein Teil haben wollen, würde ich den
644 gleich stecken und die Software komplett in ASM schreiben ;-) Das
ist bei so hardwarenaher Anwendung ohnehin von Vorteil. Sleep-Modes
machen bei einem Robbi auch durchaus Sinn, wenn er im Wohnzimmer parkt
und auf die Aktion oder Reaktion des Anwenders wartet.

Travel Rec. schrieb:
> @Jörg: 100% ACK. Sollte ich mal so ein Teil haben wollen, würde ich den
> 644 gleich stecken und die Software komplett in ASM schreiben ;-)

Sisyphosarbeit. ;-)  Einen 64-KiB-Prozessor mit sinnvollem Assembler-
code zu füllen (und das zu pflegen) ist doch ein Lebenswerk...

> Das
> ist bei so hardwarenaher Anwendung ohnehin von Vorteil.

Gängiges Vorurteil.

Ich habe (dienstlich) neulich eine Schleife schreiben müssen, in der
N mal im genauen (bezogen auf einen extern am Timer eingespeisten
Hardwaretakt) 8-µs-Abstand je zwei SPI-Transfers (die allein netto
4 µs brauchen) auszuführen waren.  Ich hab's in C geschrieben.  In
der ersten Version hatte der Compiler genau einen überflüssigen
Befehl drin (er hat nicht geschnallt, dass DEC rN für den Schleifen-
zähler bereits das Z-Flag setzt und hat noch ein AND rN, rN danach
eingebaut).  Dann musste ich die Schleife aus anderen Gründen nochmal
umstrukturieren, und es gab nichts mehr, was ich am generierten Code
noch auszusetzen gehabt hätte.  Der Schleifendurchlauf hat dabei
übrigens so 2...5 CPU-Takte ,Luft'.

Auch wenn ich mir in diesem Falle den sich ergebenden Assemblercode
ansehen musste (und die Takte zählen), war der C-Code trotzdem
schneller geschrieben und ist leichter zu überschauen.

> Sleep-Modes
> machen bei einem Robbi auch durchaus Sinn, wenn er im Wohnzimmer parkt
> und auf die Aktion oder Reaktion des Anwenders wartet.

Sehe ich auch so.

>Sisyphosarbeit. ;-)  Einen 64-KiB-Prozessor mit sinnvollem Assembler-
>code zu füllen (und das zu pflegen) ist doch ein Lebenswerk...

Najaaa - nicht ganz. Wenn man´s gewöhnt ist, geht´s ganz gut. Der
SD-Kartenrecorder ist auch komplett ASM und ich blicke durch die 30k
XMEGA-Code noch ganz gut durch ;-).

>war der C-Code trotzdem
>schneller geschrieben und ist leichter zu überschauen.

Okay, sicher. Aber wenn ein C-Programm die 30k-Marke überschreitet, ist
eine Wartung nach einem halben Jahr Pause genau so 'heftig'.

In ASM kommentiert man halt mehr. Mit vordefinierten, ebenfalls
aussagekräftigen Variablen und einer halbwegs konkreten Struktur geht
das ebenfalls ganz gut.

Ben schrieb:
> ich bin ebenfalls für assembler.

Lass mal.  Ist ja eh' ein endloser Streit, und wir wollen dem OP nicht
seinen Thread kaputt machen damit.

Richtig, letztenendes geht es um das Testen der Apparatur in praxisnaher
Umgebung. Und da ist die Programmiersprache eigentlich egal - es sei
denn, man will die 7. Nachkommastelle an Performance herauskitzeln ;-)

Travel Rec. schrieb:
> ...es sei
> denn, man will die 7. Nachkommastelle an Performance herauskitzeln ;-)

Wo gibt ein Roboter eigentlich Kommas aus? ;-)

Kommt auf die Programmierung an: Festkomma oder Fließkomma ;-)

Travel Rec. schrieb:
> Kommt auf die Programmierung an: Festkomma oder Fließkomma ;-)

Du meinst, bei Festkomma fallen sie als Würfel raus, während sie
bei Fließkomma rauslaufen? :-)

Also müssen wir in Zukunft unterscheiden zwischen:

   Igittigit, mein Roboter ist inkontinent!

und

   Igittigit, mein Roboter hat auf den Teppich gekotzt!


Tolle Technik. Toller Fortschritt.

So in der Art :-).

@Nils Springob:

Ist denn jetzt schon jemand durch das Auswahlverfahren durchgekommen
oder läuft es noch?

Naaa - das sind völlig verschiedene Dinge. So ein PC ist schweinekomplex
und nicht mit einem Mikrocontroller vergleichbar. Zum Geradeausfahren
des Roboters braucht ein geübter Programmierer sowohl in C, als auch in
ASM, nicht viel länger, als eine halbe Stunde. Die einzelnen Sensoren
abzufragen und dies dann in eigene Routinen zu packen, ist dann ein
schrittweises Vorgehen. Fakt ist, daß ein Roboter kein Betriebssystem,
sondern ein auf die Bedürfnisse des Anwenders zugeschnittenes Programm
braucht. Was anderes ist auf einem derart 'kleinen' Controller auch gar
nicht sinnvoll umzusetzen. Das Mitliefern von Libraries ist ein schöner
Anfang, aber noch lange nicht das Ende.

sepp schrieb:
>>Zum Geradeausfahren
>>des Roboters braucht ein geübter Programmierer sowohl in C, als auch in
>>ASM, nicht viel länger, als eine halbe Stunde. Die einzelnen Sensoren
>>abzufragen und dies dann in eigene Routinen zu packen, ist dann ein
>>schrittweises Vorgehen.
>
> Eindeutig die Aussage von jemandem, der noch nie einen Roboter
> programmiert hat.

Was willst du denn gross machen ausser die PWM fuer die Motoren
rauszupusten und die Encoder abzufragen? Bloss weil du dafuer laenger
brauchst heisst das nicht, dass das fuer alle gilt :>

sepp schrieb:
>>Was willst du denn gross machen ausser die PWM fuer die Motoren
>>rauszupusten und die Encoder abzufragen?
>
> Jetzt wird mir klar, warum Einstein folgenden Spruch gesagt hat:
>
> Albert Einstein: "Phantasie ist wichtiger als Wissen, denn Wissen ist
> begrenzt"
>
> Fällt Dir wirklich nichts ein?

Die Aussage war, dass ein geubter Programmierer nicht mehr als eine
halbe Stunde braucht, um den Roboter geradeausfahren zu lassen. Nein,
mehr als die Motoren anzusteuern und die Radencoder auszulesen faellt
mir dazu nicht ein.
[Hier kannst du dir einen schlauen Spruch hindenken, sowas wie "Wer
lesen kann ich klar im Vorteil" oder so]

Bewerbungsschluss ist morgen, Samstag 31.10.09 12:00.

David ... schrieb:

> Die Aussage war, dass ein geubter Programmierer nicht mehr als eine
> halbe Stunde braucht, um den Roboter geradeausfahren zu lassen. Nein,
> mehr als die Motoren anzusteuern und die Radencoder auszulesen faellt
> mir dazu nicht ein.

Es ist jetzt 15:53. Postest du dann um 16:23 den Code?

Peter Stegemann schrieb:
> David ... schrieb:
>
>> Die Aussage war, dass ein geubter Programmierer nicht mehr als eine
>> halbe Stunde braucht, um den Roboter geradeausfahren zu lassen. Nein,
>> mehr als die Motoren anzusteuern und die Radencoder auszulesen faellt
>> mir dazu nicht ein.
>
> Es ist jetzt 15:53. Postest du dann um 16:23 den Code?

Bis ich nicht weiss, ob ich das Ding zum Testen zur Verfuegung bestellt
bekomme, code ich dafuer garnichts.

Hi,

bevor ihr euch jetzt gegenseitig zerfleischt...
Ihr habt ja beide recht! Nur unterschiedliche Vorstellungen von der
bedeutung des "Geradeausfahrenlassens"

Wenn ich damit (wie David und wohl die meisten ohne
"Robotikhintergrund") eine einfache vorwärts gerichtete Bewegung unter
akzeptanz einer Spurabweichung verstehe und keine Randbedingungen wie
ein Betriebssystem verlange, so ist das in der Tat nicht viel schwerer
als eine LED ein und Ausszuschalten. Das bekomme ich auch in einer
halben Stunde hin, incl. der Zeit die mein REchner zum booten braucht.

Verstehe ich dagegen aber eine echte Spurtreue und geregelte
Vorwärtsbewegung, eingebettet in viele andere Prozesse, mit dem Ziel ein
wirklich (fast) autonomes System zu haben, dann ist der Arbeitsaufwand
ein paar Zehnerpotenzen höher...
Aber wer keinen "Robotikhintergrund" hat, der versteht eben das obere...

Also: Durchatmen...

Gruß
Carsten

Zum Thema Motor-Encoder auswerten: Sehe ich das richtig, daß das gute
Stück sowas garnicht hat?!
Damit wird wohl das genaue Geradeausfahren eh unmöglich...

Das Gerät hat Odometrie-Lichtschranken. Siehe Info und
Bedienungsanleitung auf der Seite des Herstellers.

Nils Springob schrieb:
> Bewerbungsschluss ist morgen, Samstag 31.10.09 12:00.

Damit ist die Sache vorbei :) Wann erfahren die Bewerber, ob sie zu den
5 Gluecklichen gehoeren?

Über die 20 Uhr Tagesschau im Ersten ;-)

Da wir sehr viele Zuschriften bekommen haben, wurde das Kontingent auf
10 Roboter verdoppelt.
Die ausgewählten Testpersonen werden im Laufe der Woche von uns
benachrichtigt - allen anderen trotzdem vielen Dank für die Teilnahme!

Nils Springob schrieb:
> Da wir sehr viele Zuschriften bekommen haben, wurde das Kontingent auf
> 10 Roboter verdoppelt.
> Die ausgewählten Testpersonen werden im Laufe der Woche von uns
> benachrichtigt - allen anderen trotzdem vielen Dank für die Teilnahme!

Da ich einen Zuschlag bekommen habe:

Wer aus dem Forum ist noch dabei? Wir könnten uns einen Thread
aufmachen, um uns softwaremässig abzustimmen.

Christoph H. schrieb:
> Herzlichen Glückwunsch! Ich habe noch nicht mal eine Rückmeldung
> bekommen, ob die Mail eingegange ist ...

dito

Siggi schrieb:
> ... Da ich einen Zuschlag bekommen habe: ...
>
> Allein aus Gründen der Werbetaktik des Herstellers hast du als Moderator
> den Zuschlag bekommen.

ack

Wie viele Bewerbungen sind eigentlich eingegangen? Würde mich mal
interessieren, wie hoch das Interesse dann doch war.

Siggi schrieb:
> ... Da ich einen Zuschlag bekommen habe: ...
>
> Allein aus Gründen der Werbetaktik des Herstellers hast du als Moderator
> den Zuschlag bekommen.

Weiss ich nicht. Was die Auswahl letztendlich entschieden hat, kann ich
nicht sagen.
Ich habe eine ganz normale, freundliche Bewerbung geschrieben und nach
ein paar Tagen war Antwort da.
Ich gehe aber auch davon aus, dass sich der Hersteller einen wilden Mix
aus den Bewerbungen zusammengestellt hat. Er hat nichts davon, sich
lauter Profis zu holen und er hat auch nichts davon sich lauter Anfänger
zu holen. Die Mischung machts.

Eines ist klar: Ich werde hier im Forum sicher nicht irgendwelche
Bausatzprobleme breittreten und darauf herumreiten. Ich werde auch keine
Werbung hier im Forum dafür machen. Der Hersteller möchte meine Meinung
haben und die werde ich ihm mitteilen.

Ich bin allerdings daran interessiert, mit den anderen in Kontakt zu
kommen. Sei es um Techniken auszutauschen, Software-Lösungen zu
vergleichen, zu sehen ob ich bei Problemen einfach nur ein Brett vorm
Kopf habe (was auf ein Dokuproblem hinweisen könnte) etc.
Aber grundsätzlich ist der Hersteller sicherlich daran interessiert,
meine Meinung, meine Erfahrungen etc. möglichst unbeeinflusst von
Anderen zu erfahren. Und das werde ich ihm liefern.

ronny schrieb:
> Wäre bereit mitzuarbeiten, habe auch den Zuschlag bekommen.

Könntest du dich anmelden, damit man dich per Mail erreichen kann?

so jetzt das Ganze nochmal mit Anmeldung, wäre also bereit für eine
Zusammenarbeit.

Gruss Ronny

bin auch dabei

Gruß
Frank

Keine Zusage ist auch eine Absage.

Naja, wenigstens hier im Forum hätte man schreiben können, daß die
"Gewinner" benachrichtigt wurden und alle, die bisher keine Antwort
bekommen haben nicht dabei sind. Um Tester wurde ja auch hier
geworben...
Ich bin zwar auch nicht dabei, aber egal, verschiebt sich mein Einstieg
in die Roboterwelt halt um weitere paar Jahre ;)
Gruß, Helge

Ich kauf einfach so´n Ding, wenn ich wieder etwas Geld und Zeit habe.
Wäre zwar schön gewesen, bei der Weiterentwicklung zu partizipieren,
aber so what...

In der Tat, ich habe mich schon oft gefragt warum so viele Firmen nicht
standardmäßig mit vorgefertigen Antwortschreiben arbeiten. Einmal als
Vorlage erstellt, beliebig oft wiederverwendbar. Man muss nur noch den
Namen und die E-Mail-Adresse desjenigen einsetzen, dauert ne halbe
Minute wenn man extra langsam macht. Aber gut, ich muss ja nicht alles
verstehen ;-)

Naja. Wir wollen mal keine voreiligen Schlüsse ziehen. Vielleicht hat
der OP einfach zu viel zu tun...

Dem Threadersteller wärs ja nicht zu verübeln wenn er hier gar nix mehr
postet. War doch ein cooles Angebot...die Chance für lau so einen
Bausatz zu bekommen und dafür bischen was drüber schreiben & berichten.
Quasi eine Art Gewinnspiel und wer leerausgeht hat auch nix verloren da
man nix investieren mußte( Ja ok, 5min kostbare Zeit die jetzt für die
gaaaanzen anderen "Projekte" fehlt...wers glaubt wird seelig)

Stattdessen wird der Thread wieder zerlabbert und die kleinen Kinder
zanken sich ob nun nach 30min oder doch erst nach 41,23 Minuten ein
Roboter programmiert werden kann.

Und wenn man nach 3/4 des Threads den Holzhammer (den man so manch einem
am liebsten überzimmern würde) gerade wieder zur Seite gestellt hat,
wird sich als krönender Abschluss auch noch beschwert das man kein
persönliches Antworkärtchen mit Schleifchen im Briefkasten hatte...


Naja, jetzt hab ich auch 5min Zeit verschwendet, aber meine Sachen
bekomm ich zum Glück trotzdem noch auf die Reihe :)

chris schrieb:
> So, spasseshalber habe ich mir den Bausatz bestellt.

War vielleicht ein erhoffter Nebeneffekt, der mit dieser Anfrage erzielt
wurde! Anreize schaffen, Interessen wecken, führen zur Ankurbelung des
Geschäfts... Zwei Fliegen mit einer Klatsche!

Da fehlt wohl der Beutel mit den nicht-ESD gefährdeten Bauteilen, die
können wir gerne nachsenden, dafür benötigen wir jedoch die Adresse....
;-)

So, jetzt auch mit Anmeldung.
Mein Bausatz war komplett (Reichelt) und die Beschreibung ist eigentlich
auch OK.
Was mir abgeht, ist ein Forum bzw. Beschreibung für den Fehlerfall.
Sensibilität der vordeeren IR LEDs
ODOmetrie Empfindlichkeit nicht gleichmäßig einstellbar

@springob
Wo können da die Probleme liegen? Würde dieses Ding gerne programmieren
und in Betrieb nehmen :-()

Gruß,
Frank

Mein Bausatz ist in der Zwischenzeit (vorgestern) auch angekommen.
Habe bis jetzt 2 abende a 2 Stunden gebaut. Die Platinen sind bestückt,
heute gehts an den Zusammenbau der Mechanik (Freundin hat gemeckert,
dass ich schon wieder abends bei dem Teil sitze. Na, ja)

Ich hab zwar die beigelegte CD noch nicht durchforstet, aber was mir
bisher fehlt (konnte ich auf der Web Site nicht finden) ist ein
Schaltplan. Habt ihr so ein Teil gefunden?

Was mir bisher so aufgefallen ist
Mein Bausatz war vollständig
Das Verteilen der Widerstände war mühselig. Ich habe mir aus der
Bauanleitung das Blatt mit der Übersicht auf dem Laserdrucker
ausgedruckt (zum Abhaken), wobei natürlich der Druckertreiber sich
geweigert hat, die Graphik zu vergrößern bzw. die graue Hinterlegung
größtenteils verloren ging. Die Idee mit der Graphik in der die
Widerstandwerte (nicht Bauteilbezeichnungen) eingetragen sind, mit einer
Ringtabelle der verwendeten Werte daneben, finde ich jedoch gut. Damit
kommen auch Anfänger gut zurecht (wie meine Freundin bewiesen hat)
Beim Aufmachen des Beutels mit den Zahnrädern haben sich natürlich die
kleinen weißen Hülsen sofort selbstständig gemacht und ... ihr kennt den
Rest
Die mechanische Passung der Platinen scheint ausgezeichnet zu sein. Am
Anfang war ich skeptisch als ich das in der Anleitung gelesen habe, aber
ein Zusammenbau probehalber hat gezeigt, dass alles sehr gut passt.

Was ich gut finde, sind die vorgesehenen Anschlüsse für Stiftleisten auf
denen jeweils Signal, GND und Vcc liegt. Was mir aber fehlt ist ein
komplett herausgeführter Port. Wäre auch zu einfach wenn man nicht lange
fackeln müsste und ein LCD einfach so anschliessen könnte.


In der Nacht hat die Hauptplatine erstmals den Akkusatz komplett
geladen. Von der Umsteckerei der 3 Jumper bin ich nicht so begeistert
aber das muss der laufende Betrieb zeigen, wie relevant das tatsächlich
ist.

Heute abend wird vollständig aufgebaut. Und dann wird sich zeigen, was
alles nicht geht.

Hallo Chris,
erstmal Danke für Deinen Beitrag.
Ich habe auf der rechten Seite beim Zusammenbau anscheinend etwas
mechanische Probleme gehabt, da sich die Räder nur schwer gedreht haben,
mit Motor überhaupt nicht.
Nach einigem nacharbeiten funktionierte dann auch der Motorantrieb, aber
die ODO geht immer noch nicht.
Jetzt ist es natürlich verdammt schwer, den Getriebekasten wieder zu
entfernen um an die innenliegende IR-LED dranzukommen um die genaue
Position evtl. zu berichtigen.
Allerdings sollte die Vorgabe durch die Lötaugen eigentlich richtig
passen. Ich bin jetzt erstmal am Messen, ob vielleicht ein Bauteil nicht
richtig seine Dienste tut.
Ich werde hier weitere Kommentare nach Bedarf einfügen :-)
Gruß, Frank

Auch mein Bausatz ist angekommen. Der Aufbau wird sich sicher noch etwas
hinziehen, da ich den Roboter von einem Laien unter Anleitung aufbauen
lasse. Die Anleitung ist aber schonmal nicht schlecht, auch für einen
Laien nachvollziehbar. Was bei der Anleitung und auch bei Reichelt fehlt
ist der Hinweis das die Akkus nicht mit im Lieferumfang sind.
Ein LCD ist aber über I2C mit dem PCF8574 möglich und werde ich auch
nachrüsten da sich das fürs debuggen recht gut machen wird.

Mal sehen wenn die ersten Probleme auftauchen.

Gruss Ronny

Soweit funktioniert bei mir auch (fast) alles.

Mit dem linken Motor habe (hatte) ich so meine Probleme. Ab und zu ist
er nicht angelaufen. Auch hat ein 'Lager' furchbar gequietscht. Ein
Tropfen Öl an den Achsdurchführungen hat aber Wunder gewirkt. Man könnte
richtig hören, wie beim Testlaufen die Motoren in der Drehzahl zugelegt
haben. Auch ein Fetten der Zahnräder hat sich als Segen für das
Laufgeräusch herausgestellt. Der Motor läuft jetzt wesentlich besser an.
Auch ein Drücken des Motors in Richtung Akkuhalter (um das
Abtriebsritzel etwas frei zu bekommen) hat sich als vorteilhaft
erwiesen.

Die Odometrie sieht gut aus. Auch die IR-Distanzmessung liefert Werte,
wenn auch unsymetrisch. Links sind bei mir die Werte immer höher als
rechts. Aber das ist nicht so schlimm.

Womit ich aber echte Probleme habe, sind die Taster mit ihren Fühlern.
Von den 4 Tastern schaltet eigentlich nur einer so wie ich mir das
vorstelle. Die anderen haben keinen rechten Druckpunkt am Fühler und man
muss bei 2 schon effektiv rohe Gewalt aufbringen, bis die Fühlerbewegung
an den Tastern ankommt. Hier werde ich noch was ausprobieren. Ich denke,
dass der Silberdraht zu stramm in den Bohrungen sitzt und die
Drehbewegung des Fühlers behindert. Ich hab mir überlegt, jeweils eine
Bohrung etwas aufzubohren. Dann würde die andere Bohrung als Drehgelenk
fungieren und der Draht hätte in der anderen Bohrung genug Spielraum,
damit sich das Platinenstück um die Drehachse drehen und auf den Taster
drücken kann.


Ach ja.
Die Library auf meiner CD war nicht vollständig. Dort ging delay.h ab,
sodass ich mir von SourceForge die aktuelle geholt habe.

In der Doku ist auch noch ein Fehler.
Bei der Angabe der Libaries im AVR-Studio muss man darauf achten, dass
die die libnibobee_base.a als letzte angegeben wird. Gegebenenfalls mit
'Move Down' zurechtschieben. Ansonsten linkt das letzte Demobeispiel
(IR-Sensoren) nicht richtig, weil die base zufrüh eingelinkt wird, und
in der line-Lib noch Referenzen in die base existieren, die nicht
aufgelöst werden können.

@Frank Pelzhause
Funktionieren die IR_Sensoren mitlerweile?

Programmier dir die Sensor-Demo in den NiboBee (letztes Programm aus dem
Tutorial).
Mit einer Handykamera kannst du nachsehen, ob die Dioden leuchten.
Wenn sie leuchten kannst du auch mit er Fernsteuerung vom Fernseher ein
paar "Befehle" an die IR-Transistoren schicken. Die roten und gelben LED
blitzen dann im Takt auf.
Die Schaltung an sich funktioniert definitiv. Eventuell bei der Platine
8 an den Ecken noch einmal nachlöten und auch die 6 Verbindungen zur
Hauptplatine nochmal nachsehen.

Ich war eigentlich erstaunt wie gut das löten der Zusatzplatinen
funktioniert hat und wie stabil das ganze wurde.

Hm - wäre auch irgendwie komisch, wenn der Hersteller nur dieses eine
Forum zum betatesten auserkoren hätte. Finde ich nur etwas spät, an den
Kinderkrankheiten zu doktern, wenn das Teil schon im Verkauf ist...

Und weil weiter oben nach einem der Hauptprobleme des Asuro gefragt
wurde:

Meine Hostkonfiguration ist ein Windows-XP
Die Installation des USB Treibers verlief völlig problemlos und auch die
Programmierung über das USB Kabel brachte bisher keine Probleme (nur das
beiliegende USB-Kabel ist für mich ein klein wenig zu kurz :-)

> Ich hab mir überlegt, jeweils eine Bohrung etwas aufzubohren.
> Dann würde die andere Bohrung als Drehgelenk fungieren und der
> Draht hätte in der anderen Bohrung genug Spielraum,
> damit sich das Platinenstück um die Drehachse drehen und auf
> den Taster drücken kann.

> das mit den Tastern ist bei mir auch so. Allerdings funktinieren
> sie im Betrieb ganz gut.

Kontakt hatte ich auch immer. Aber es 'fühlte sich schwammig an'.

Ich hab die Modifikation jetzt ausprobiert.
Die Fühler noch mal ausgelötet und jeweils das hintere der beiden Löcher
für den Silberdraht mit einem 1.5mm Bohrer aufgebohrt (sind im Original
1mm Löcher). Das Resultat sind 4 exakt arbeitende Taster, die nach ca.
2cm Bewegung am Fühlerende mit einem deutlich hörbaren Knackser schalten
(so wie es bei Tastern sein soll) :-) Ein 1.2mm Bohrer könnte auch schon
reichen, es fehlt nicht viel.
Aber nur 1 Loch aufbohren! Das andere fungiert als Lager für den
Silberdraht.

Hat sich also voll gelohnt und war in 10 Minuten eledigt.

So, jetzt hab ich auch wieder weitergebastelt.
Nach einigen Tests und Versuchen hab ich das gleiche Problem mit den
Tastern. Das mit dem Aufbohren ist ein super Hinweis, den ich auch
ausprobieren werde.
Aber nach wie vor hab ich das Problem mit der ODOmetrie. Ich werde jetzt
mal versuchen, die IR und Photo LEDs etwas zu verändern. Die
LinieSensoren vorne haben immer noch das Problem, das die linke Seite
schon ab 10 cm vom Papier reagieren und die rechte Seite erst bei 1 cm.
Nach dem Einspielen des Kalibrations Files (.hex) ist die
Empfindlichkeit auf ca. 4 cm auf der rechten Seite gestiegen (wäre ja in
Ordnung), auf der linken Seite immer noch ca. 10 cm. Hier werde ich
versuchen, die Dioden nochmal etwas hin und her zu biegen. genauso in
der ODO nochmal eine Nachbearbeitung durchführen.

Der USB hat auch bei mir sofort funktioniert (Oh, welch Wunder) und die
ersten Testprogramme ließen sich auch laden.
Aber beim Versuch ein erstes Programm selber zu schreiben, bekomme ich
den Fehler:
line.c:(.text.line_calibrateBlack+0x4): undefined reference to `delay'
Hat jemand eine Ahnung woran das liegt? (Ich programmiere schon länger
in allen arten von C).
Muss hier die Bibliothek (.o) Dateien neu kompiliert werden?

Ansonsten Gedult, Gedult, Gedult...

@Frank:
zu dem Delay-Problem hatte doch Karl-Heinz schon was geschrieben:
Beitrag "Re: Testpersonen für Roboterbausatz NIBObee gesucht"
Gruß, Helge

@Helge
Danke für den Tipp.

bin vor lauter Suchen schon nicht mehr auf dem Laufenden.
Das Programm funktioniert jetzt und ich habe mit der "kleinen" Zange die
LEDs nochmal ein wenig justiert.
Jetzt reagieren Alle ungefähr so wie ich mir das vorstelle.
Hier nochmal die Linkreihenfolge:

line.a
utils.a
base.a

Dann klappts auch mit dem Linken.
Ein wenig kniffelig ist die Justierung der vorderen Sensoren, bei mir
sind die sehhhhhhhr empfindlich. Ein zehntel links, eins rechts und
immer ein anderes Ergebnis :-)

Allerdings hab ich die ODOs immer noch nicht im Griff. "Wir" basteln
weiter :-))

Gruß,
Frank

So, jetzt gibts schon mal erste Fahrgeräusche.
Probleme hab ich beim "Linien" fahren.
Die roten LEDs blinken (Countdown) dann die 2 gelben, und dann....
totenstille.
Ich hab gelesen das das Programm zum Kalibrieren der Sensoren im EEPROM
gespeichert bleibt und einen Test auf Schwarz und Weiß macht.
Weiß jemand von Euch wie der "richtig" durchgeführt wird?

Gruß, Frank

Frank Pelzhause schrieb:

> Ich hab gelesen das das Programm zum Kalibrieren der Sensoren im EEPROM
> gespeichert bleibt und einen Test auf Schwarz und Weiß macht.

Wo hast du das gelesen?
Ich finde hier die 'Dokumentation' auf der CD dazu ziemlich dürftig. Da
steht nur: Übertragen sie das Programm und alles ist gut. Da steht
nicht, was das Programm genau macht, ob man irgendetwas beachten muss,
woran man erkennt, dass die Kalibrierung vollständig ist, etc.

> Weiß jemand von Euch wie der "richtig" durchgeführt wird?

Frag ich mich auch.
Ich habs einfach draufgespielt. Meine IR-Sensoren sind aber trotzdem
asymetrisch. Drum würde mich nämlich auch interessieren, was dieses Pgm
eigentlich macht.

Die Kalibrierung der Liniensensoren funktioniert nach dem folgenden
Prinzip:

Alle Werte werden als Differenz zwischen einer Messung mit
eingeschalteten und einer Messung mit ausgeschalteten IR-LEDs gemessen.
Bei ausgeschalteter LED wird die Umgebungshelligkeit gemessen, bei
eingeschalteter LED die Summe aus Umgebungshelligkeit und reflektiertem
Licht. Die Differenz ergibt den reflektierten Anteil (und einen kleinen
Anteil direktes Licht, dem Übersprechen).

Das Kalibrierprogramm macht folgendes:
Die Differenzen für einen weissen (Kw) und für einen schwarzen (Kb)
Untergrund werden gemessen und gespeichert.
Die Werte werden nach folgender Formel normalisiert:
f(x) = 1024*(x-Kb)/Kw
Für einen schwarzen Untergrund ergibt sich als Ergebnis 0, für einen
weissen Untergrund ca. 1024.

1023.

@Peter:
Dürfen wir Deine Worte für das Tutorial so übernehmen? :-)

Hat jmd das Ding unter Vista/Windows7 mit 64Bit in Betrieb? tut da der
usb treiber?

robo schrieb:

> dauerhaft einschaltet. Dann habe ich einfach meine Digitalkamera
> genommen ( FotoHandy geht auch ) und geschaut, ob die IR-LEDs leuchten.
> Und siehe da, am Anfang nicht, erst nach dem Nachlöten.

So habe ich meine IR-Leds auch getestet (Handy-Kamera)
Für die umgekehrte Richtung hab ich die Fernbedienung vom TV genommen
und das Demo-Programm zur Auswertung der IR-Sensoren genommen. Mit der
Fernsteuerung angpiepst und nachgesehen ob die gelb/roten Kontrolled
links und rechts aufblitzen.

Hallo Zusammen,
heute hab ich meinen Robi erstmals über eine kurze Teststrecke fahren
lassen.
Auf welche Farbe reagieren denn die Sensoren aus dem Beispiel "linien.c"
Auf einer Schwarzen Linie (Klebeband auf Laminat) bleibt der NiBo
stehen.
Mit einer Konstruktion aus einer schwarzen und außen jeweils 2 Weißen
klebeflächen hab ich einigermaßen Erfolg.

Kann das an der Kalibrierung liegen? Ich hab jetzt wirklich die Sensoren
mit einem weißen und einem schwarzen Blatt "geeicht" und die Werte dann
gespeichert.

Wäre schön, wenn es irgendwo ein plätzchen geben würde, an dem
dokumentierte Programme zur Verfügung gestellt werden können. So können
Erfahrungen irgendwie effizienter ausgetauscht werden.

Vielleicht werden wir ja in Zukunft auch eine größere Bibliothek
zusammen bekommen.

Gruß,
Frank

Frank Pelzhause schrieb:

> Kann das an der Kalibrierung liegen? Ich hab jetzt wirklich die Sensoren
> mit einem weißen und einem schwarzen Blatt "geeicht" und die Werte dann
> gespeichert.

Kalibriere die Sensoren mit dem tatsächlichen Untergrund und dem
Klebeband.
Ich hab auch ein paar Anläufe gebraucht.

Auch ist Klebeband nicht Klebeband.
Ich habe hier zb den Fall, dass blaues Klebeband das IR besser
reflektiert als der Laminatboden.
Das ist ganz witzig. Die Linienverfolgung fährt die Linie aus schwarzem
Klebeband sauber ab und sobald der Wechsel aufs blaue erfolgt, wirkt das
Klebeband abstossend. Für die IR sensoren sieht es dann so aus, als ob
eine helle Linie links und rechts von dunkleren Flächen flankiert wird.

Vielleicht wäre es besser, ultrahelle weiße LEDs und normale
Fototransistoren anstelle des Infrarots zu nehmen. Sollte weniger
Filterwirkung haben und der Robbi hat dann auch gleich noch eine
Unterbodenbeleuchtung ;-)

Ich denke, daß die Kalibrierung nicht nur am Untergrund hängt, sondern
auch an der (tageszeitlich wechselnden) äußeren Beleuchtung. Ein Test zu
diesem Thema ist mir derzeit nicht möglich (Zeitprobleme).

Bernhard

Hallo,
mal wieder ein neuer Status von mir:
Die Liniensensoren arbeiten immer noch nicht wirklich richtig.
Wahrscheinlich ist da immer noch was mit der Kalibrierung nicht so 100
prozentig.
Auch ist die rechte Odometrie nicht funktionsfähig, da ist die
Photodiode defekt (War ein hilfreicher Tipp das mit der Fernbedienung zu
testen)

Um jetzt das lästige "immer wieder neue Programme auf Nibo spielen" zu
umgehen, habe ich hier mal ein kleines Progrämmchen geschrieben, das als
erstes ein Lauflicht steuert, auf Fühler änderungen in die Kalibration
springt und anschließend in das Linienfahrprogramm.
Von dort aus geht es dann auch wieder in den Lauflichtmodus und alles
kann von vorne beginnen.
Ich denke ich hab das Programm einigermaßen gut in der Source
dokumentiert.
Viel Spaß beim testen.
Frank

Was mach man eigentlich mit so einem Ding?

Auf der Suche nach einem Weihnachtsgeschenk für den 9-jährigen Junior
(sehr Technik interessiert) kam mir der NIBObee in den Sinn. Ich finde
das Hardwarekonzept sehr gelungen. Mir stellt sich nur die Frage, was
man mit dem Robotor eigentlich für ein Kind sinnvolles machen kann.
Isolierband auf das Laminat kleben und den NEBObee die Strecke abfahren
lassen ist auf Dauer nicht die Erfüllung.

Anders gefragt: wofür habt Ihr euch den NIBObee bestellt?

Andreas

Ist mir bekannt, ich brauch eh noch Batterien.

Die Antwort hilft mir aber nicht dahingehend weiter ob ich den NIBObee
mitbestellen soll.

Andreas

Andreas Breitbach schrieb:

> man mit dem Robotor eigentlich für ein Kind sinnvolles machen kann.
> Isolierband auf das Laminat kleben und den NEBObee die Strecke abfahren
> lassen ist auf Dauer nicht die Erfüllung.

Kommt drauf an.
Zb merkt man sehr schnell, dass das mit dem Klebeband nicht so einfach
ist (BTW: Ich habe mir auf dem Drucker ein paar Seiten ausgedruckt mit
jeweils einem schwarzen Streifn in der Mitte. Geht einfacher die Blätter
einfach aufzulegen, auch in Kurven, als da lang mit Klebeband
rumzuwurschteln)

Nicht so einfach, weil der Robi aufgrund des Hardwarekonzepts nicht jede
beliebig enge Kurve kratzen kann. Dann verliert er die Linie.
Interessant sind jetzt zb Konzepte: Wie kann er die Linie wiederfinden?
Er könnte zb sofort anhalten wenn die Linie verloren geht, zurücksetzen
bis die Linie wieder da ist und dieselbe Stelle nochmal langsamer
fahren, diesmal mit mehr Drehzahldifferenz an den Motoren. Oder mit den
Sonsoren analysieren wie der Verlauf der Linie ist und dann mit einem
Reversiermanöver der Kurve folgen.

Man könnte aber auch ganz etwas anderes machen:
Auf einem großen Blatt Papier mit schwarzem Edding ein Labyrinth
aufmalen. Der Robbi darf die Linie nie kreuzen (dazu benutzt er seine
IR-Sensoren). Die Frage lautet nun: Wie kommt er aus dem Labyrinth
heraus?

Dann sind da noch die Fühler, die einem Kontaktinformation vor dem Robbi
liefern. Wie könnte der Robbi, wenn er der Linie folgt, einem Glas
Wasser ausweichen, das 'plötzlich' vor der Linie auftaucht. ect. etc.

Du siehst also, da gibt es schon einiges an interessanen Fragen. Aber
die drehen sich alle mehr oder weniger darum, sich Verfahren auszudenken
und in Programmcode umzusetzen und nachzusehen ob sie tatsächlich
funktionieren.

Ob das allerdings etwas für einen 9-jährigen ist, wage ich zu
bezweifeln. Es gibt frühreife 12-jährige, die sehr gut programmieren
können und es gibt 17-jährige die das nie begreifen werden.

Hallo
hatjemand die Bezeichnung der IR Photodioden? Bei mir ist eine defekt,
und ich benötige die genaue Bezeichnung!

Danke

Nachtrag: Die Bezeichnung ist in der Bauanleitung leider nicht angegeben

Also als Spielzeug würde ich den NXT von Lego ins Auge fassen. Ist zwar
mit ca. 280€ nicht gerade billig, aber ich denke auch für Jugendliche
geeignet (Testbericht PC-Magazin 12/2009 Seite 92).

Hat jemand von Euch den Sourcecode vom NiBoBeeProgammer.exe?
Unterlieght doch der GPL, oder? Würde mich Interessieren, wie die USB
Schnittstelle bedient wird.

Gruß,
Frank

Der Code ist im SVN Repository auf Sourceforge zu finden:
http://nibobeelib.svn.sourceforge.net/viewvc/nibob...
Das Programm verwendet AVRDUDE als library um auf den Programmieradapter
zuzugreifen. AVRDUDE wiederum setzt auf die libusb um auf die
USB-Schnittstelle zuzugreifen.
Der NIBObee kann auch direkt mit AVRDUDE als Kommandozeilenapplikation
programmiert werden. Als Programmer muss dabei usbasp ausgewählt werden.

@ Nils Springob
Danke, werde mich auf die Suche begeben
Gruß, Frank

@ Ronny:
Wie meinst Du das? Die Bestückung wird doch in der Bauanleitung in den
Kapiteln 2.3.10 (IR-Phototransistoren) und 2.3.11 (IR-LEDs) genauso
beschrieben wie die Bestückung der übrigen Platinen.

Das ist richtig, aber nur für die Phototransistoren PT1 und PT2. Ein
Anfänger fragt sich natürlich, wohin mit dem Rest. Würde die
Sensorplatine als Bild nochmals mit abbilden. Das Gleiche ist dann bei
den IR-LEDs. Diese Frage wure von meinem Kollegen, der den Roboter
aufbaut, so an mich herangetragen.
Ansonsten ist bis jetzt die Anleitung sehr gut. Der Aufbau dauert für
einen Anfänger halt etwas. Lösten lässt sie sich nach seinen Angaben
aber sehr gut.

Gruss Ronny

Ist dieses Forum nun am Ende??
Wäre interessant, weitere Informationen auszutauschen!
Gruß,
Frank

daniel091184 schrieb:
> ich suche einen fertig gelöteten nibobee welchen ich nur noch
> programmieren muss.

Dann entgeht dir ja der halbe Spass!

Im Ernst: Das Teil ist ganz leicht zusammenzubauen. Da alle IC gesockelt
sind, kannst du auch nichts ruinieren.

Die Anleitung ist ausreichend bebildert und auf Bauteile, deren Polung
wichtig ist, wird hingewiesen. Zusammen mit einem Hinweis, wie man die
richtige Polung ermittelt.

Mit einem kleinen Baumarktlötkolben und etwas Lötzinn bist du dabei.

Hallo!

Ich habe eine Frage zur SPI-Schnittstelle im Nibo bee:

Aktuell ist diese fix zwischen ATiny und Atmega16 zum Flashen des Atmega
verschaltet.

Danach liegt sie aber vermutlich brach. Die SPI-Signale könnte man ja an
den Widerständen abgreifen um damit Bausteine oder Module mit
SPI-Schnittstelle ansprechen zu können (ich denke z.B. an ein
RFM12-Modul usw....)

Leider finde ich keine Informationen, ob sich das mit der Firmware des
ATiny verträgt (dieser ist ja beim Flashen ein SPI-Master und der ATmega
ein SPI-Slave).

Gehen die SPI-Anschlüsse am ATiny nach dem Flashen in einen
Tristate-Zustand und kann dann das SCK-Signal vom Atmega generiert
werden oder kollidieren hier die Ausgänge (insb. SCK) vom Atiny und
Atmega?

Hat jemand damit Erfahrung oder Einblick in die Atiny-Firmware?

Grüße
S.Helmschrott

Wer hindert Dich, eigene Firmwares auf Tiny und Mega zu flashen und Dir
die SPI-Schnittstelle so zu konfigurieren, wie Du sie haben willst?

Der Quellcode der ATtiny Firmware ist frei verfügbar:
http://nibobeelib.svn.sourceforge.net/viewvc/nibob...

In der Datei isp.c werden nach der Programmierung die Signale
freigegeben:

void ispDisconnect() {
  /* set all ISP pins inputs */
  ISP_DDR &= ~((1 << ISP_RST) | (1 << ISP_SCK) | (1 << ISP_MOSI));
  /* switch pullups off */
  ISP_OUT &= ~((1 << ISP_RST) | (1 << ISP_SCK) | (1 << ISP_MOSI));

  /* disable hardware SPI */
  //spiHWdisable();
}

Langweilig. Der wievielte Asuroaufguß ist das jetzt?

... Merci!

Diese Infos habe ich gesucht!

Danke+schönen Abend
Stefan