Testpersonen für Roboterbausatz NIBObee gesucht

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.

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.

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/nibobeelib/trunk/NIBObeeProgrammer/
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/nibobeelib/trunk/programmer/

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