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
Angehängte Dateien:
-
NIBObee_320.jpg
21 KB
>> Bewerbungen mit kurzer Beschreibung der Vorkenntnisse bitte per Mail an: >> nibobee@nicai-systems.de Klasse Idee um an die Adresse und Daten potentieller Werbeopfer - pardon - Kunden zu kommen!
Die Adressen werden wir selbstversändlich vertraulich behandeln und auf keinen Fall für Werbezwecke, sondern nur für die Benachrichtigung der Testpersonen benutzen.
eigentlich keine schlechte idee, wenn man das ernst nehmen kann wär ich einfach mal probehalber dabei. aber eine frage: gibts inzwischen nicht schon genug µCs auf rädern? was ist an diesem so besonders bzw. was soll an diesem so besonders werden? meine, wenn eine firma die dinger verschenkt will sie doch in der regel auch was für zurückbekommen, und sei es das programm aus den µCs.
Hallo Herr Springob, ich hätte auch Interresse an diesem Test teilzunehmen, sind Hardwareerweiterungen auch gewünscht oder soll nur der Grundbausatz getestet werden. Da ich selbst schon einen "Robbi" gebaut habe, würde mich die erweiterung um eigene Sensoren interressieren. Gruß aus Köln Frank
Dass dort mehr als 5 Zeilen "Erfahrungsbericht" erwartet wird, duerfte selbstverstaendlich sein, oder?
Ich denke, das dürfte klar sein, aber ein Buch wird man wohl auch nicht schreiben müssen. Gruß aus Köln Frank
einen erfahrungsbericht zu schreiben der auch ein ordentliches format hat sollte ja nicht das problem darstellen. was wird eigentlich gebraucht um das ding zu programmieren, hat man zugang zur ISP schnittstelle des AVR? atmega644 hätt ich auch noch drei hier fg
@Ben Laut Schaltbild kommt man wohl nicht direkt auf die ISP schnittstelle des ATMega 16. Man kann das Ding aber über USB Proggen. Zur Not schmeisst man halt den tiny44 raus der das USB Hanling macht. Gruß aus Köln Frank
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.
ah, also die ISP fest verdrahtet, auch nicht schlecht. das heißt aber auch, daß man den USB nicht zum datenaustausch mit dem PC verwenden kann? wäre mal ein interessantes projekt sowas zu programmieren.
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.
@Nils Springob Kann man sich denn noch für diesen Test anmelden, oder wurden die Teilnehmer schon ausgewählt? Gruß aus Köln Frank
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)
@Karl heinz Buchegger Super Idee, ich dachte eigentlich auch das es so implementiert wäre. Gruß aus Köln Frank
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.
yep, der atmega16/32/644 kann kein usb in hardware... ich hab USB kommunikation auch noch nicht probiert, war nur eine idee weil der USB anschluß gleich dran ist. ist der attiny44 gelötet? wird dieser eigentlich programmiert geliefert oder muß der erst noch programmiert werden? ich würd ja schon wieder modifizieren wollen... grins also die ISP schnittstelle vom atmega zum proggen direkt nutzen und anstelle des attiny44 irgendwas rein was den USB datentransfer machen kann.
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.
im extremfall atmega raus, in einen programmieradapter gesteckt und schon kannst damit machen was du willst... ;)
Das ist natürlich ein gutes Argument, das erleichtert AVR Anfängern das arbeiten mit dem Teil erheblich. Was ich ein bisschen nachteilig finde ist, das kein 10 oder 6poliger ISP Stecker vorhanden ist aber man kommt an die Anschlüsse ja dran Knuffig finde ich auch die möglichkeit die Akkus über USB laden zu können. Gruß aus Köln Frank
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.
hmmm das ding laden jetzt wirds schon wieder kompliziert... :D nee mir ist schon klar, daß man wenn gefordert mit der vorhandenen basis auskommen muß. sehe ich auch nicht als problem, wird reichen um mit dem ding spaß zu haben. @threadstarter liest du eigentlich die emails die ankommen oder macht das wer anders?
Was wird denn als Erfahrungsbericht erwartet? Wie man mit der HW und der Lib klar kommt, oder Erweiterungsideen, die evtl. nachher kommerziell umgesetzt werden?
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 ;-)
oki dann weißt du ja bescheid. der rest kommt halt alles drauf an was an dokus usw. dabei ist.
Gibt es einen Shop, wo man die Motoren und die Getriebe kaufen kann?
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'.
>Okay, sicher. Aber wenn ein C-Programm die 30k-Marke überschreitet, ist >eine Wartung nach einem halben Jahr Pause genau so 'heftig'. Nö, man arbeitet ja nicht mit Mnemonics sondern mit aussagekräftigen Funktionsnamen und Definitionen. Selbsterklärender Code sozusagen;) Einarbeit nach einem halben Jahr vieleicht ne halbe Stunde.
In ASM kommentiert man halt mehr. Mit vordefinierten, ebenfalls aussagekräftigen Variablen und einer halbwegs konkreten Struktur geht das ebenfalls ganz gut.
ich bin ebenfalls für assembler. bei solchen sachen weiß ich gerne genau was der prozessor macht, erst recht wenn es ein so überschaubarer prozi ist.
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?
Da ich mich nun schon einige Zeit mit kleinen mobilen Robotern beschäftige, kann ich zum C/Assembler Streit nur folgendes sagen: Wenn man nicht nur "Basics" machen will, braucht man ein Roboterbetriebssystem. Sonst ist es so wie einen PC ohne Betriebssystem zu kaufen und sich zu überlegen, ob man den jetzt in Assembler oder C programmieren will ( btw: hat das schon mal jemand probiert ? )
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.
ist zwar off-topic, aber ich hab durchaus vor einiger zeit mit PC ohne DOS herumgespielt. zwar nur auf disketten (mit festplatten wäre es auch gegangen aber die waren damals nicht so billig zu kriegen wie heute), aber so ein mini-betriebssystem ist auch in assembler kein problem. es muß ja auch irgendwann mal so angefangen haben, schließlich brauch ich heute ein lauffähiges system um überhaupt irgendwas zu programmieren. ist halt die frage wie groß die programmierwut des anwenders ist.
>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.
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, das Teil ist doch quasi ein ASURO Clone (ja verbessert natürlich) und mit dem kleinen Flitzer brauchte es auch nie ein Betriebssystem oder sowas damit der ner Linie folgt, Licht verfolgt, Teelichter und Bälle schiebt usw. ;) (den ASURO gibts schon seit glaube 2005 oder 2004...)
>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?
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.
David, Du bist wie einer dieser unerfahrenen Jungstudenten, die meinen, sie hätten im Studium schon alles gelernt, was es zu wissen gibt. Wenn Du Dich einmal wirklich mit der Programmierung eines Roboters auseinandersetzt, wirst Du feststellen, dass Du mit Deiner Aussage so um den Faktor 100 daneben liegst. Die Geradeausfahrt des ASUROs beistpielsweise hat mehrere Leute über mehrere Monate beschäftigt ( siehe entsprechende Threads im Roboternetz ). Falls Du glaubst, Du könntest es besser, nur zu. Aber ich bin mir sicher: Du wirst auf die Nase fallen. Ausserdem gibt es gewisse Unterschiede bei Programmieraufgaben. Den Motor eines Roboters einzuschalten ist so einfache wie das Blinken einer LED am Mikrocontroller: Anfängerniveau. Eine Bahnregelung inclusive Multithreating für eine Subsumption Architektur ist dann ohne das entsprechende Betriebssystem schon etwas anstrengender.
BTW: es lohnt sich imWikipedia Artikel http://de.wikipedia.org/wiki/Autonome_mobile_Roboter mal den Punkt "Softwarearchitektur" durchzulesen.
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.
Herzlichen Glückwunsch! Ich habe noch nicht mal eine Rückmeldung bekommen, ob die Mail eingegange ist ...
Christoph H. schrieb: > Herzlichen Glückwunsch! Ich habe noch nicht mal eine Rückmeldung > bekommen, ob die Mail eingegange ist ... dito
... Da ich einen Zuschlag bekommen habe: ... Allein aus Gründen der Werbetaktik des Herstellers hast du als Moderator den Zuschlag bekommen.
Wäre bereit mitzuarbeiten, habe auch den Zuschlag bekommen.
Siggi schrieb: > ... Da ich einen Zuschlag bekommen habe: ... > > Allein aus Gründen der Werbetaktik des Herstellers hast du als Moderator > den Zuschlag bekommen. ack
@ Siggi: seh ich auch so... Ausserdem denke ich nicht, dass dieser 1000ste ASURO-clone irgendeine Erwähnung, geschweigen denn einen eigenen Thread wert wäre.
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?
Hallo Zusammen, ist jemand von euch aus Berlin? Ich würde gerne ein Treffen organisieren. Gruß, chris
melde mich heute abend an, bin noch auf Arbeit...
so jetzt das Ganze nochmal mit Anmeldung, wäre also bereit für eine Zusammenarbeit. Gruss Ronny
jo wie gesagt, wenigstens eine absage wäre nett gewesen.
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...
sehe ich ähnlich. 50 euro investieren mag ich nicht und die zeit kann ich ebenfalls in andere projekte stecken. bin aber der meinung daß man sich schon um die interessenten kümmern kann egal ob sie letztendlich mitwirken oder nicht. hinterläßt einen faden beigeschmack für zukünftige gleichartige projekte, da hab ich dann mit sicherheit auch keine lust mehr auf eine antwort. ich find das gehört einfach zum freundlichen umgang miteinander, aber darum gehts der firma vermutlich (wie so oft) nicht. wollen halt alle nur dein bestes...
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 ;-)
wäre zumindest freundlich gewesen. ohne das forum würd ich heute noch auf gewissheit warten.
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!
Leider bin ich jetzt doch unfreiwilliger Tester: Es fehlen nämlich verschiedene Bauteile: Alle Schalter, Stiftleisten, Elkos, 15Mhz Quarz. Ist es bei euch ähnlich?
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.... ;-)
irgendwie sah mir deine tüte auf dem bild schon so dünne aus... naja wenn das schon so gut anfängt hast du immerhin rückgaberecht.
>naja wenn das schon so gut anfängt hast du immerhin rückgaberecht. Ich will ihn nicht zurückgeben. Ich habe ein paar Asuros und kenne deren Schwächen: Probleme beim Programmieren über die IR-Schnittstelle, Odometriesensoren Probleme. Falls die USB-Schnittstelle am NiboBee gut funktioniert, wäre zumindest das größte Handicap des ASURO verbessert. Das kann ich allerdings erst testen, wenn ich die restlichen Bauteile habe. Was die Odometrie anbelangt bin ich mal gespannt wie er sich im ultimativen "Haus vom Nikolaus Test" schlägt: http://www.youtube.com/watch?v=6E_e8AHvhNg
**rofl** naja ich denk dafür brauchts dann wirklich schrittzähler an den motoren. schade daß die kiste sowas nicht hat. mal sehen, vielleicht besorg ich mir mal etwas größeres, diese kleinen dinger finde ich ziemlich frizzlig. mir ist was lieber wo richtig mit schrauben und ein paar watt antriebsleistung.
Angehängte Dateien:
-
NiboBeeAsuro.jpeg
45 KB
So, geschafft, bis auf die fehlenden Bauteile habe ich jetzt alles aufgelötet. Mal schauen, ob ich den Rest morgen auftreiben kann. Ich hätte die Plati ne auch ohne die Elkos und die Schalter in Betrieb genommen, aber ohne den 15Mhz Quarz geht erst mal nichts. Der Versorgt witigerweise den Attiny44 und den Atmega16 gleichzeitg.
Hallo Leute, ich habe heute den Robi in Betrieb genommen. 1. Problem: Wenn die Platinen der Motoren nicht 100%ig ausgerichtet sind, bewegt sich auch kein Motor. 2. Die Funktion der IR Sensoren funktionieren nur auf der Linken Seite. Es gibt keinen Fehlerhinweis, was zu tun ist, wenn die andere Seite nicht funkt. 3. Odometrieeinstellung: Wenn die Einstellung links richtig ist, geht Rechts nicht und umgekehrt. Hat hier vielleicht jemand eine Fehlerbehebungsroutine ( :-) ) oder eine Idee? Die Fühler funktionieren, aber wie gesagt die Sensoren Vorne Rechts und die ODO Rechts haben Probleme. Gruß, Frank
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
Die Odometrie LEDs kannst Du bestimmt einfach mit einem Programm testen, das einfach die externen LEDs blinken lässt, wenn das Zahnrad das Licht durchlässt. Die unterschiedlichen Empfindlichkeiten könnten mechanisch bedingt sein. Dann nämlich, wenn der Strahl der IR-LED nicht genau das Loch trifft. Die Empfindlichkeit der FrontLEDs zu testen ist schwieriger. Es wäre praktisch, wenn man über die USB-Schnittstelle Zeichen vom Atmega16 zum PC schicken könnte. Eine andere Lösung wäre, via einer IR-Diode und einem ASURO IR-Empfänger die Daten zum PC zu übertragen.
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.
Der Schaltplan ist am Ende der Dokumentation. Gruß, chris
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
Hurra, die fehlenden Bauteile hat mir NicaiSytems anstantslos geschickt und ich konnte weiterbasteln. So wie es aussieht, funktioniert alles. Jetzt geht es an die Software: Es gibt ein Verzeichnis mit dem Namen "first", dort befindet sich ein Programm, welches print-Befehle auf der seriellen Schnittstellee des Atmega ausgibt. Jetzt stellt sich mir nur die Frage: wo gehen die hin?
Programmieren ... Mein erstes Testprogramm fördert schon einen vermutlichen Fehler in der Nibo-Lib zutage: Damit die Motoren mit dem Befehl motpwm_setLeft(-500); rückwärts laufen, muss vorher enable_interrupts(); aufgerufen werden. Wenn nicht, laufen die Motoren nur vorwärts. Erstaunlich, oder?
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.
Hallo Karlheinz, das mit den Tastern ist bei mir auch so. Allerdings funktinieren sie im Betrieb ganz gut. Im Anhang ist mein Testprogramm, es zeigt ziemlich gut, wenn die Taster funktionieren ( Auf den Boden stellen, sausen lassen ). Gruß, chris
Übrigens, hier habe ich gerade den "Konkurrenz-Thread" entdeckt: http://www.roboternetz.de/phpBB2/viewtopic.php?t=51033
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 :-)
Beim mir funktioniert das Programmieren auch problemlos. Bei der Installation meldet der Treiber "USBasp", wenn man im Internet such findet sich ein ISP-Programmier von Fischl, die USB Software ist vermutlich von OBDEV.
> 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
Falls Ihr einen Asuro-Ir Receiver habt, könnt Ihr Daten zum PC übertragen und die Sensorwerte überprüfen. Hier habe ich mal das entsprechende Programm dazu geschrieben: http://www.hobby-roboter.de/forum/viewtopic.php?f=4&t=88
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.
Hallo, [quote]Weiß jemand von Euch wie der "richtig" durchgeführt wird?[/quote] Die Antwort findet sich gut versteckt im Quellcode des calibration Programmes. Wenn der NIBObee mit allen Liniensensoren auf einer weißen Fläche steht, drückt man den linken Fühler nach hinten. Dann auf eine schwarze Fläche stellen und den rechten Fühler nach hinten drücken. Beide Aktionen werden mit LED blinken quittiert und die gemessenen Werte werden permanent im EEPROM gespeichert, wenn man beide Fühler nach vorne drückt. Siehe dazu: http://nibobeelib.svn.sourceforge.net/viewvc/nibobeelib/trunk/src/test/calibration/calibration.c?revision=6&view=markup Die gespeicherten Werte werden dann bei der line_get Funktion berücksichtigt. Grüße Peter
@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?
Liniensensoren: Bei mir war es zuerst so, dass ich Lötfehler an den Linensensoren hatte. Es war nicht einfach zu sehen, dass der Kontakt zwischen den gewinkelten Platinen nicht zustande kam. Den Fehler habe erst gefunden, als ich versucht habe, die Liniensensoren zu IR-Datenübertragung zu verwenden. Da das zuerst nicht funktioniert hat, habe ich eine kleines Programm geschrieben,das die IR-Leds 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.
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.
> Dürfen wir Deine Worte für das Tutorial so übernehmen? :-)
Erlaubnis erteilt.
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
Hi Lt. Katalog gibt es den bai Reichelt. MfG Spess
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.
Wenn ich Roboterbausatz höre stößt es mir immer auf. Schuld dran ist meine ehemalige Berufschule. Im Lehrplan war "Programmierung eines µC in C" dran. Unser Lehrer hat ne Handvoll ASURO besorgt (Danke für die initiative). ABER mit "C" hatte das wenig zu tun. Befehle wie "speed(100);" sind nicht wirklich in der realen Berufspraxis zu gebrauchen. Für "Lieschen Müller(hab das hier weiter oben mal aufgeschnappt) reichts das. Aber es sollte genau darauf hingewisen werden, das solche "Befehle" fertig Programmierte Funktionen sind. Für die Schule reichte das, man hat das geschluckt und seine Note kassiert. In der Praxis, mit nem eigenen Projekt, musste ich bei 0 anfangen. Denn ein "led_on();" musste erst selber deklariert werden. Optimal wäre ein zweigleisiges system. 1. Für Lieschen Müller; fertige Funktionen hintereinander schreiben. 2. Fertige Hardware Dokumentation und Step-by-Step einführung in C
>Was mach man eigentlich mit so einem Ding? >.... >Isolierband auf das Laminat kleben und den NEBObee die Strecke abfahren >lassen ist auf Dauer nicht die Erfüllung. Stimmt. Alles was Du aber brauchst, ist Phantasie, dann lassen sich wunderbare Dinge damit machen. Ich werde mit dem NiboBee diesen Wettbewerb etwas ausbauen: http://www.youtube.com/watch?v=W3ldn7vbIEM
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
In der Bauanleitung fehlt die Beschreibung der Bestückung der Sensorplatine. Alle anderen Platinen sind aufgeführt. Gruss Ronny
@ 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
ich suche einen fertig gelöteten nibobee welchen ich nur noch programmieren muss. gerne aber auch mit fertigen programmen. kann mir jemand sowas anbieten?? bitte umgehend melden. 015118513008 danke schonmal
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
Auch wenn das schon ne Weile her ist: @Knut Ballhause: auch wenn du (ich sag einfach mal du) ganz gut durch Tonnen von ASM-Code durchschauen können, so ist es ohne Pflege des Codes und der Doku natürlich schlecht was Gruppenarbeit oder Weitergabe des Codes angeht... auch könnte es später mal Probleme geben, wenn man sich ne Weile nicht mehr mit dem Code und/oder der µC-Art beschäftigt hat... es gibt inzwischen nur noch gelegentlich für die meisten Grund dafür Code in ASM zu coden - und das weiß man meist auch erst nach der Entwicklungsphase (Planung und Umsetzung in Beispielcode oder gleich in C)... (sehr komplexe, verschachtelte Logik, die der C-Compiler nicht mehr gut umsetzen kann) Gründe dafür, die mir einfallen: nicht schnell genug (zur Not kann man ja auch noch ein bisschen übertakten, einer auf der Arbeit betreibt die 168er mit 25 MHz statt mit 20 MHz - ohne jegliche Kühlung! Gut, dafür halten die dann nicht so lange, aber anders kriegt er die Ansteuerung+Operationen nicht hin...) nicht klein genug (Kumpel wollte letztens schon wieder den Code so weit runterstutzen, dass er 100 Bytes kleiner ist und in den nächstkleineren µC passt - auch wenn ich das bei einer Stückzahl von bisher nur 2 und einer Ersparnis von <2€ nur so halb verstehe... Herausforderung!?) was Roboter angeht bin ich ja immer noch der Meinung, dass ein FPGA nie verkehrt sein kann - auch wenn ich die Dinger bisher nur am Rechner genutzt hab und nicht auf Robotern aufgelötet habe... kann ja ganz praktisch sein, wie beim Menschen auch, z.B. eine Art Angst "hart gecoded" einzubauen (Distanzsensor --> FPGA --> Stopp, wenn Abgrund = Ansteuerung vom Antrieb lahmlegen und Bremse (falls vorhanden) an) Nachteil natürlich, dass man den FPGA erstmal passend "programmieren" muss, also Hardware beschreiben und hochladen... falls da nichts vorgegeben ist vom Roboterdesigner, dann macht das sicher keiner... an der Schule fehlte mal genau sowas beim Geschwindigkeitstest auf dem Flur. Meine Mitschüler haben kluger Weise den Lego-Roboter im ersten Stock getestet und der "raste" davon und machte dann ne Linkskurve zur Treppe (ein Rad keinen Kontakt zum Boden?)... die Typen mussten danach die Einzelteile auf der Treppe und im Erdgeschoss zusammensuchen und alles neu bauen - wäre das der E-Technikkurs gewesen (gut, die hatten bis ich weg war keine Hardware, die selbstmordgefährdet war) oder der Informatikkurs 3 Jahre später (die hatten schon Asuro), dann wäre das "tödlich" gewesen für die Note...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.