https://wiki.das-labor.org/api.php?action=feedcontributions&user=83.135.83.184&feedformat=atomLaborWiki - Benutzerbeiträge [de]2024-03-28T15:51:10ZBenutzerbeiträgeMediaWiki 1.39.6https://wiki.das-labor.org/index.php?title=Raum&diff=7730Raum2008-07-08T18:31:04Z<p>83.135.83.184: "gesamte" hat nur ein m ;)</p>
<hr />
<div>[[Bild:SZ Grundriss.jpg|150px|right]]<br />
Unser Raum oder mittlerweile unsere Räume, befinden sich beide im 1. Stock.<br />
Auf dem Grundriss handelt es sich dabei um Raum 5, Raum 51 und Raum 4<br />
Raum 5 hat zwei Oberlichter und ist offen mir Raum 51 verbunden.<br />
<br />
* In Raum 5 befindet sich unser Theke und die Sitzecke mit dem [[Beamer]].<br />
* Raum 51 hat ein Fenster zum Hof und dient als Bastelecke, dort steht auch das Regal.<br />
* Raum 4 ist durch eine Tür über Raum 5 zu erreichen. Er dient momentan eher noch als Rückzugsraum, was sich aber duch derzeitige Verschönerung der Raums ändern soll.<br />
<br />
==Die Sitzecke==<br />
<br />
[[Bild:Sitzecke1.jpg|150px]]<br />
[[Bild:Sitzecke3.jpg|150px]]<br />
So sieht unsere Sitzecke in sehr aufgeräumt auf.<br />
<br />
==[[Regal]]==<br />
[[Bild:Regal2.jpg|150px]]<br />
Wir haben ein [[Regal]] um unseren Stuff zu lagern.<br />
<br />
== Theke ==<br />
[[Bild:Theke.jpg|150px]]<br />
Unsere Theke mit Spüle und Kühlschrank ist mit der [[Moodbar]] beleuchtet.<br />
<br />
<br />
== Das Gesamte Labor ==<br />
[[Bild:Labor1.jpg|150px]]<br />
[[Bild:Labor2.jpg|150px]]<br />
{{Revision (angepasst)|Diese Seite ist stark unvollständig. Das Layout könnte verbessert werden.}}</div>83.135.83.184https://wiki.das-labor.org/index.php?title=RFMBot&diff=7709RFMBot2008-07-08T17:11:54Z<p>83.135.83.184: </p>
<hr />
<div> ACHTUNG, diese Seite befindet sich noch im Aufbau und ist daher nirgends verlinkt.<br />
Fotos und weitere Beschreibungen Folgen<br />
-- Sören (08.07.2008)<br />
<br />
Der RFM Bot ist ein Roboter, welcher mit einem [[Datenfunk mit dem AVR|RFM12]] ausgestattet ist. Er verfügt über verschiedene Sensoren zur Erkennung seiner Umgebung und kann aus der Ferne gesteuert werden.<br />
<br />
==== Sensoren ====<br />
* 2 Lichtschranken am "Rüssel"<br />
* 2 Entfernungssensoren von Sharp mit analogem Ausgang (5-30 cm Reichweite)<br />
<br />
<br />
[[Kategorie:Robotik]]</div>83.135.83.184https://wiki.das-labor.org/index.php?title=RFMBot&diff=7707RFMBot2008-07-08T17:11:34Z<p>83.135.83.184: Die Seite wurde neu angelegt: ACHTUNG, diese Seite befindet sich noch im Aufbau und ist daher nirgends verlinkt. Fotos und weitere Beschreibungen Folgen -- Sören (08.07.2009) Der RFM Bot...</p>
<hr />
<div> ACHTUNG, diese Seite befindet sich noch im Aufbau und ist daher nirgends verlinkt.<br />
Fotos und weitere Beschreibungen Folgen<br />
-- Sören (08.07.2009)<br />
<br />
Der RFM Bot ist ein Roboter, welcher mit einem [[Datenfunk mit dem AVR|RFM12]] ausgestattet ist. Er verfügt über verschiedene Sensoren zur Erkennung seiner Umgebung und kann aus der Ferne gesteuert werden.<br />
<br />
==== Sensoren ====<br />
* 2 Lichtschranken am "Rüssel"<br />
* 2 Entfernungssensoren von Sharp mit analogem Ausgang (5-30 cm Reichweite)<br />
<br />
<br />
[[Kategorie:Robotik]]</div>83.135.83.184https://wiki.das-labor.org/index.php?title=Datenfunk_mit_dem_AVR&diff=7693Datenfunk mit dem AVR2008-07-08T01:00:10Z<p>83.135.83.184: </p>
<hr />
<div>= Hardware =<br />
Die benutzten Transceiver gibt es bei verschiedenen Herstellern unter dem Namen RFM12 oder RF12. Sie können im 433 Mhz ISM Band und zusätzlich auf Frequenzen in der Umgebung von 315, 868 und 915 MHz funken.<br />
<br />
In Deutschland sind die Module bei Pollin zum Preis von 8 Eur erhältlich, allerdings lohnt sich ab einer Menge von 10 oder mehr Modulen eine direkte Bestellung beim Hersteller ([http://www.hoperf.com/doce/pro/RF12.html Produktseite]).<br />
<br />
Die Module sind zum Selbstkostenpreis von 2.95 EUR bei Sören erhältlich.<br />
<br />
= Library für den Atmel =<br />
Wir haben eine library für die RFM12 Module gebastelt. Mit ihr lassen sich die Module auf einfache Weise an den Microcontroller anbringen.<br />
<br />
Die Handhabung der Library ist realtiv einfach: Sämtliche Konfigurations-Variablen lassen sich in der Datei ''[http://roulette.das-labor.org/trac/browser/microcontroller/src-atmel/lib/rfm12/rfm12_config.h rfm12_config.h]'' einstellen. Für Atmega8 und Atmega32 Mikroprozessoren gibt es schon fertige Config-Dateien in den jew. test-Verzeichnissen (siehe [https://roulette.das-labor.org/trac/browser/microcontroller/src-atmel/lib/rfm12/ SVN]). Entsprechende Pinbelegung findet sich in besagter Config-Datei. Sollte der Interrupt PIN ein anderer sein, so muss man am Ende der Config natürlich auch die Compilezeitvariablen ''RFM12_INT_VECT'' und ''RFM12_INT_BIT'' verändern.<br />
<br />
Am Anfang sollte die Funktion ''rfm12_init()'' aufgerufen werden zur Initialisierung. Diese Funktion kümmert sich automatisch um Interrupts und korrektes Setup für die jew. Ports. Das einzige was diese Funktion nicht macht, ist die Interrupts anschalten - diese muss man selbst mit ''sei()'' anschalten.<br />
<br />
Die Funktion ''rfm12_tick()'' sollte regelmäßig aufgerufen werden.<br />
<br />
== Beispielcode ==<br />
Im [[Subversion|SVN]] ist Beispielcode [https://roulette.das-labor.org/trac/browser/microcontroller/src-atmel/lib/rfm12/test Beispielcode] hinterlegt, der die Module in Empfangsbereitschaft versetzt und ein empfangenes Byte mit den LEDs des [[Laborboard]]s anzeigt. Wenn man Button 0 drückt, sendet das Modul.<br />
<br />
Zum Betrieb der Module sind im Grunde nur wenige Befehle nötig - hier ein Beispiel:<br />
<br />
uint8_t teststring[] = "teststring\r\n";<br />
rfm12_init();<br />
sei();<br />
<br />
while (23)<br />
{<br />
/* ... */<br />
rfm12_tx (sizeof(teststring), 0, teststring);<br />
rfm12_tick();<br />
}<br />
<br />
= USB Packetsniffer & Debugtool =<br />
Derzeit entsteht ein USB Datenlogger- und Sender für die Funkmodule. Vorab gibt es schon einmal den Code im [http://roulette.das-labor.org/trac/browser/microcontroller/src-atmel/rfm12/rfm12usb SVN]. Das Gerät soll ein Werkzeug werden, um damit leichter die Funkschnittstelle zu debuggen und um ein Interface zwischen Datenfunk und PCs zu bieten.<br />
<br />
Wir bedienten uns dabei der selbst geschriebenen RFM Library, sowie der [http://www.obdev.at/products/avrusb/ USB library von objective development], die auf einen Software USB Stack implementiert und ein USB Lowspeed device aus gewöhnlichen Microcontrollern macht.<br />
<br />
Das Projekt ist noch in der Entwicklungsphase und entsteht zunächst hauptsächlich im SVN. Derzeit entsteht zusätzlich eine GUI für die Hostseite in QT.<br />
<br />
= Datenblätter =<br />
Auf der Pollin Homepage sind unvollständige Datenblätter und nicht funktionierender Beispielcode verzeichnet. Die beigelegte Papierdokumentation ist ebenso unbrauchbar. Von diesen ist ausdrücklich abzuraten!<br />
<br />
Ein etwas brauchbareres, aber dennoch nicht ganz vollständiges Datenblatt findet sich auf der Herstellerseite: [http://www.hoperf.com/pdf/RF12.pdf Herstellerseite].<br />
<br />
= Protokoll =<br />
Die erste Version des Datenaustauschprotokolls hat den Namen [[AirLAB_Protokoll_Version_0|AirLAB v0]]. Es ist ein erste Entwicklung, die zunächst einmal in der Praxis erprobt werden muss.<br />
<br />
= Probleme =<br />
Die Module können scheinbar keine '''Kollisionen''' erkennen. Die erste Version des Protokolls arbeitet mit relativ kleinen Paketen (<= 260 Bytes), damit der Ether zum Einen möglichst schnell wieder frei wird und zum Anderen ganz einfach weil die partizipierenden Devices groessere Pakete zumeist garnicht handlen koennten.<br />
<br />
Ferner können die Module offenbar nicht die '''Empfangsstärke''' messen oder bzw. ausgeben.<br />
<br />
<br />
'''''Fehler im Beispielcode des Herstellers'''''<br />
<br />
Die Zeile "RFXX_WRT_CMD(0xC400);//1.66MHz, 2.2V" (Low Battery Detector and Clock Divider) spricht den falschen Adressbereich an und ueberschreibt die Einstellungen des AFC Command. Richtig ist (0xC000). Trotzdem funktioniert der Beispielcode - so lange man nicht den externen Takt nutzen moechte...<br />
<br />
Ueberhaupt sollte man bei den Commands nicht alles glauben, was die Kommentare als Setup vorgaukeln. Es gibt deutliche Abweichungen, unter anderem auch bei besagtem Clock Divider.<br />
<br />
= Verschlüsselung und Authenzität =<br />
Parallel zum Netzwerkstack für die Funkmodule wird auch die [[Crypto-avr-lib]] entwickelt, welche hash- und verschlüsselungsfunktionen bietet, um den Datenverkehr der Geräte untereinander zu sichern.<br />
<br />
= Praxiserfahrung =<br />
Erste Tests mit zwei mit dem Beispielcode aus dem SVN geflashten Microcontrollern haben gezeigt, das die Module wirklich zuverlässig arbeiten und offenbar relativ unanfällig für Störungen sind. So war es z.B. möglich, mit der Funkfernbedienung für die billigen Baumarktsteckdosen zu senden, während das Empfängermodul Pakete empfing.<br />
<br />
Bei einigen hundert gesendeten Paketen gingen natürlich welche verloren (gerade während des Fernbedienungs-Tests), aber offenbar kam nicht eins mit falschen Daten am Empfänger an.<br />
<br />
[[Kategorie:Microcontroller]]</div>83.135.83.184https://wiki.das-labor.org/index.php?title=Kategorie:Robotik&diff=7691Kategorie:Robotik2008-07-08T00:44:12Z<p>83.135.83.184: Die Seite wurde neu angelegt: In dieser Kategorie finden sich alle Projekte, die etwas mit Robotik zu tun haben.</p>
<hr />
<div>In dieser Kategorie finden sich alle Projekte, die etwas mit Robotik zu tun haben.</div>83.135.83.184https://wiki.das-labor.org/index.php?title=ChilliBot&diff=7690ChilliBot2008-07-08T00:43:07Z<p>83.135.83.184: </p>
<hr />
<div>= ChilliBot =<br />
[[Bild:ChilliBot.gif|right]]<br />
Ein elektrischer Rollstuhl, ausgestattet mit einem kleinen PC, einem GPS-System, einer Webcam und Sensoren soll über das Internet gesteuert werden können. Auf Events können dann Interessierte diesen Bot durch die Gegend navigieren und mit den Personen in Kontakt treten, ohne physikalisch anwesend zu sein. <br />
<br />
<br />
== Ideen ==<br />
* Rollstuhl hat RS232-Anschluss<br />
* GPS Korridor (NMEA-Protokoll, 9600 Baud, RS232)<br />
* 220V Versorgung (am besten aus 24V)<br />
* Schachtel-PC (220V Input)<br />
** Soundkarte ist drin für Krawall, Aktivboxen dabei packen<br />
** USB-Webcam dran<br />
** Flachbildschirm (warsch. auch 220V)<br />
* Ultraschall-Sensoren (RS232 oder I2C)<br />
* Extras: Gesicht auf Bildschirm, Scheinwerfer/Hupe/etc. steuern<br />
<br />
== Umsetzungsreihenfolge ==<br />
* GPS Korridor anlegen<br />
* Schachtelpc klarmachen<br />
* Ansteuerung überlegen (fahren nach Karte oder Handsteuerung) <br />
* Sensoren anschliessen<br />
* Welche Videoübertragungssoftware<br />
<br />
<br />
== Korridor ==<br />
* Problem: Wie erkennen, ob Punkt in einem Polygon?<br />
<br />
* Einfachere und flexiblere Alternative: Koordinaten in eine Bitmap umsetzen, Helligkeit/Farbe in Bitmap bestimmt dann auch die max. Geschwindigkeit des Bots. Bitmap kann mit jedem x-beliebigen Program gemalt werden.<br />
<br />
== Software ==<br />
<br />
=== Ziele ===<br />
* Benutzer soll den Bot steuern können (Client)<br />
** Java/Rubyquelle/Flash oder anderes Teil um Tastatureingaben in TCP-Steuerdaten umwandeln zu können<br />
<br />
* Sicherheitssystem (Server)<br />
** Bot-Geschwindigkeit nach Korridor einstellen<br />
*** GPS-Daten entgegen nehmen (serielle Library)<br />
*** GPS-Daten in Bitmap-Koordinaten konvertieren<br />
*** max. Geschwindigkeit über Bitmap-Koordinaten extrahieren<br />
*** Bitmap lesen, neue Bitmap für Webserver erstellen (zeigt aktuelle Position im Gebiet nach alternativer Karte)<br />
** Sensoren auswerten (RS232-Kram sammeln, verknüpfen)<br />
*** max. Geschwindigkeit reduzieren/auf 0 setzen, wenn Sensor angesprochen hat<br />
** Wenn ausserhalb des Gebietes bekommt der Nutzer X Fahrsekunden Zeit, wieder das Gebiet zu erreichen. Ansonsten Admin-Zugriff erforderlich<br />
** Zugangssteuerungssystem <br />
<br />
=== Clientsoftware ===<br />
Welche Sprache? Benötigt wird am besten:<br />
* Einfache GUI<br />
* Möglichkeit KeyDown und KeyUp Ereignisse zu unterscheiden<br />
* Client-Socket, am besten uneingeschränkt<br />
* Soll möglichst Plattformunabhängig und einfach zu nutzen sein <br />
<br />
Kandiaten:<br />
* Per Web: ActionScript 3 + Java(script), doof weil ActionScript reine Löhnware ist <br />
* reines Java (erfordert dann aber zumindest ein minimales Startskript, damit es einfach zu nutzen ist)<br />
* Alles andere: Eher blöd, weil schwerer zu kompilieren etc.<br />
<br />
<br />
=== Fremdsoftware ===<br />
* CAM-Server (Netmeeting (Win), Skype, Alternativen?, schnelle Webserver )<br />
* Voice-Server (Teamspeak?)<br />
* evtl. XMMS-Plugin für Gesichtsdarstellung<br />
* Palantir, bietet steuerdatenkanal, video und bidirektionales audio mit windows und java ambeddet client.<br />
<br />
== Maße der Teile ==<br />
=== Batteriebox ===<br />
Höhe: 27cm, Breite: 29cm, Länge: 37cm<br />
<br />
=== Thin-Client ===<br />
Höhe: 5cm, Breite: 29cm, Tiefe: 22,5cm + Buchsen<br />
<br />
== Status ==<br />
* 24V/230V Spannungswandler<br />
** Ich (tixiv) habe einen defekten mit 500W auf ebay ersteigert, ist aber nochnicht da. (Mitlerqweile repariert, wiederstand def. :))<br />
<br />
* Compi<br />
** Die Embedded-Box zeigte sich arg lahm für JPG-Videos (~ 3 fps), was besseres wäre sinnvoll<br />
** Ich (tut) habe als Leihgabe ein Embedded-3,5'-Mobo mit Via Mark 800Mhz Prozessor, mal sehn ob das besser ist<br />
<br />
* Sensoren<br />
** Die Ultraschallsensoren nicht vergessen<br />
<br />
* Bildschirm<br />
** nicht wichtig... wozu verwenden?! <br />
** Evtl. LED-Gesicht bauen, vielleicht auf einfacher 10x7 Matrix<br />
<br />
* Sound<br />
** Aktivboxen werden benötigt, hauptsache billig<br />
** Mikrofon, in jedem Fall eine Kapsel einstecken für alle Fälle (tut)<br />
<br />
* WLAN<br />
** Mein (tut) Board hat nur USB als Slots, woher bekommen wir WLAN für den Bot?<br />
** Ich (tut) habe Arcor-WLAN-Router, aber kein Plan, ob damit auch WLAN als Client statt AP-Modus möglich ist<br />
<br />
* USB/Serielles Geraffel<br />
** Tut bringt ein FT232-basierenden USB-Seriell-Wandler mit<br />
<br />
* CAM<br />
** tixi hat eine (teilweise matschiges Bild)<br />
** tut hat eine (heftiger Farbstich)<br />
** bessere cam mit problemen bei extremer helligkeit vorhanden<br />
<br />
[[Kategorie:Robotik]]</div>83.135.83.184https://wiki.das-labor.org/index.php?title=Spielzeug_Roboter&diff=7689Spielzeug Roboter2008-07-08T00:42:16Z<p>83.135.83.184: </p>
<hr />
<div>== Allgemeines ==<br />
[[Bild:Robbi mit kaffeetasse.jpg|left|200px]]<br />
Suschman hat bei einer seiner letzten Schrott-Sammel-Aktionen etwas sehr schönes für das Labor gefunden: einen Spielzeug-Roboter, der früher mal über eine Funk-Fernbedienung gesteuert werden konnte.<br />
<br />
Der Roboter fährt auf 2 Raupen, kann den Oberkörper beugen, mit den Armen etwas greifen, und hat ein Projektil-Abschuss-Device auf der Brust. Insgesammt erinnert er ein bisschen an Evolver aus dem gleichnamigen Film.<br />
<br />
Da die Fernsteuerung fehlte, und ohne diese nicht viel aus dem kruddeligen China-Microcontroller des Roboters raus zu bekommen war, haben wir kurzerhand entschlossen, stattdessen einen AVR einzubauen. Suschman hat das auch bereits getan, und nun kann der Mega8 auch schon die Motoren des Roboters steuern. In dem Roboter befindet sich auch noch ein Soundmodul, das noch etwas Reverse-Engineerings bedarf. Wir haben es bisher nochnicht ohne die Original-CPU zum Sprechen bekommen.<br />
<br />
<br />
Inzwischen kann der Robbi jetzt über die Serielle (UART) Befehle annehmen und all seine Funktionen steuern. Des weiteren schaltet er automatisch ab, wenn ein Motor überbelastet ist.<br />
<br />
Sourcecode gibts im svn unter <br />
https://roulette.das-labor.org/trac/browser/microcontroller/src-atmel/killerbot/<br />
<br />
== Robby Steuern ==<br />
<br />
Der Robby lässt sich ganz einfach via serieller konsole steuern und kennt bisher die unten angegebenen Befehle.<br />
<br />
'''WICHTIG''' Man sollte bei der Steuerung sicheheitshalber immer einen Daumen auf der Leertaste haben, damit das Ding nicht vom Tisch purzelt oder ähnlichen Scheiss macht. Einige Kommandos werden auch ab und zu nicht korrekt gelesen, sodass man ggf. mehrmals auf eine Taste drücken muss. (BugFix kommt ;)<br />
<br />
'''Navigation'''<br />
Pfeiltaste alle moeglichen Richtungen.<br />
Leertaste Stop (alle Bewegungen stoppen / not-aus)<br />
<br />
'''Rumpf'''<br />
b Rumpf nach hinten<br />
v Rumpf nach Vorne<br />
B oder V Rumpfmotor stop<br />
<br />
'''Arme'''<br />
a Arme auf<br />
s Arme zu<br />
A oder S Armmotor stop<br />
<br />
<br />
<br />
'''Weniger wichtig & nicht empfehlenswert'''<br />
l Linke Kette rückwärts<br />
k Linke Kette vorwärts<br />
K oder L Linke Kette Stop<br />
<br />
r Rechte Kette Rückwärts<br />
e Rechte Kette vorwärts<br />
R oder E Rechte Kette stop<br />
<br />
[[Kategorie:Microcontroller]]<br />
[[Kategorie:Robotik]]</div>83.135.83.184https://wiki.das-labor.org/index.php?title=ChilliBot&diff=7688ChilliBot2008-07-08T00:38:52Z<p>83.135.83.184: </p>
<hr />
<div>= ChilliBot =<br />
[[Bild:ChilliBot.gif|right]]<br />
Ein elektrischer Rollstuhl, ausgestattet mit einem kleinen PC, einem GPS-System, einer Webcam und Sensoren soll über das Internet gesteuert werden können. Auf Events können dann Interessierte diesen Bot durch die Gegend navigieren und mit den Personen in Kontakt treten, ohne physikalisch anwesend zu sein. <br />
<br />
<br />
== Ideen ==<br />
* Rollstuhl hat RS232-Anschluss<br />
* GPS Korridor (NMEA-Protokoll, 9600 Baud, RS232)<br />
* 220V Versorgung (am besten aus 24V)<br />
* Schachtel-PC (220V Input)<br />
** Soundkarte ist drin für Krawall, Aktivboxen dabei packen<br />
** USB-Webcam dran<br />
** Flachbildschirm (warsch. auch 220V)<br />
* Ultraschall-Sensoren (RS232 oder I2C)<br />
* Extras: Gesicht auf Bildschirm, Scheinwerfer/Hupe/etc. steuern<br />
<br />
== Umsetzungsreihenfolge ==<br />
* GPS Korridor anlegen<br />
* Schachtelpc klarmachen<br />
* Ansteuerung überlegen (fahren nach Karte oder Handsteuerung) <br />
* Sensoren anschliessen<br />
* Welche Videoübertragungssoftware<br />
<br />
<br />
== Korridor ==<br />
* Problem: Wie erkennen, ob Punkt in einem Polygon?<br />
<br />
* Einfachere und flexiblere Alternative: Koordinaten in eine Bitmap umsetzen, Helligkeit/Farbe in Bitmap bestimmt dann auch die max. Geschwindigkeit des Bots. Bitmap kann mit jedem x-beliebigen Program gemalt werden.<br />
<br />
== Software ==<br />
<br />
=== Ziele ===<br />
* Benutzer soll den Bot steuern können (Client)<br />
** Java/Rubyquelle/Flash oder anderes Teil um Tastatureingaben in TCP-Steuerdaten umwandeln zu können<br />
<br />
* Sicherheitssystem (Server)<br />
** Bot-Geschwindigkeit nach Korridor einstellen<br />
*** GPS-Daten entgegen nehmen (serielle Library)<br />
*** GPS-Daten in Bitmap-Koordinaten konvertieren<br />
*** max. Geschwindigkeit über Bitmap-Koordinaten extrahieren<br />
*** Bitmap lesen, neue Bitmap für Webserver erstellen (zeigt aktuelle Position im Gebiet nach alternativer Karte)<br />
** Sensoren auswerten (RS232-Kram sammeln, verknüpfen)<br />
*** max. Geschwindigkeit reduzieren/auf 0 setzen, wenn Sensor angesprochen hat<br />
** Wenn ausserhalb des Gebietes bekommt der Nutzer X Fahrsekunden Zeit, wieder das Gebiet zu erreichen. Ansonsten Admin-Zugriff erforderlich<br />
** Zugangssteuerungssystem <br />
<br />
=== Clientsoftware ===<br />
Welche Sprache? Benötigt wird am besten:<br />
* Einfache GUI<br />
* Möglichkeit KeyDown und KeyUp Ereignisse zu unterscheiden<br />
* Client-Socket, am besten uneingeschränkt<br />
* Soll möglichst Plattformunabhängig und einfach zu nutzen sein <br />
<br />
Kandiaten:<br />
* Per Web: ActionScript 3 + Java(script), doof weil ActionScript reine Löhnware ist <br />
* reines Java (erfordert dann aber zumindest ein minimales Startskript, damit es einfach zu nutzen ist)<br />
* Alles andere: Eher blöd, weil schwerer zu kompilieren etc.<br />
<br />
<br />
=== Fremdsoftware ===<br />
* CAM-Server (Netmeeting (Win), Skype, Alternativen?, schnelle Webserver )<br />
* Voice-Server (Teamspeak?)<br />
* evtl. XMMS-Plugin für Gesichtsdarstellung<br />
* Palantir, bietet steuerdatenkanal, video und bidirektionales audio mit windows und java ambeddet client.<br />
<br />
== Maße der Teile ==<br />
=== Batteriebox ===<br />
Höhe: 27cm, Breite: 29cm, Länge: 37cm<br />
<br />
=== Thin-Client ===<br />
Höhe: 5cm, Breite: 29cm, Tiefe: 22,5cm + Buchsen<br />
<br />
== Status ==<br />
* 24V/230V Spannungswandler<br />
** Ich (tixiv) habe einen defekten mit 500W auf ebay ersteigert, ist aber nochnicht da. (Mitlerqweile repariert, wiederstand def. :))<br />
<br />
* Compi<br />
** Die Embedded-Box zeigte sich arg lahm für JPG-Videos (~ 3 fps), was besseres wäre sinnvoll<br />
** Ich (tut) habe als Leihgabe ein Embedded-3,5'-Mobo mit Via Mark 800Mhz Prozessor, mal sehn ob das besser ist<br />
<br />
* Sensoren<br />
** Die Ultraschallsensoren nicht vergessen<br />
<br />
* Bildschirm<br />
** nicht wichtig... wozu verwenden?! <br />
** Evtl. LED-Gesicht bauen, vielleicht auf einfacher 10x7 Matrix<br />
<br />
* Sound<br />
** Aktivboxen werden benötigt, hauptsache billig<br />
** Mikrofon, in jedem Fall eine Kapsel einstecken für alle Fälle (tut)<br />
<br />
* WLAN<br />
** Mein (tut) Board hat nur USB als Slots, woher bekommen wir WLAN für den Bot?<br />
** Ich (tut) habe Arcor-WLAN-Router, aber kein Plan, ob damit auch WLAN als Client statt AP-Modus möglich ist<br />
<br />
* USB/Serielles Geraffel<br />
** Tut bringt ein FT232-basierenden USB-Seriell-Wandler mit<br />
<br />
* CAM<br />
** tixi hat eine (teilweise matschiges Bild)<br />
** tut hat eine (heftiger Farbstich)<br />
** bessere cam mit problemen bei extremer helligkeit vorhanden<br />
<br />
[[Kategorie:Fun|Robotik]]</div>83.135.83.184https://wiki.das-labor.org/index.php?title=Datenfunk_mit_dem_AVR&diff=7687Datenfunk mit dem AVR2008-07-08T00:36:28Z<p>83.135.83.184: </p>
<hr />
<div>= Hardware =<br />
Die benutzten Transceiver gibt es bei verschiedenen Herstellern unter dem Namen RFM12 oder RF12. Sie können im 433 Mhz ISM Band und zusätzlich auf Frequenzen in der Umgebung von 315, 868 und 915 MHz funken.<br />
<br />
In Deutschland sind die Module bei Pollin zum Preis von 8 Eur erhältlich, allerdings lohnt sich ab einer Menge von 10 oder mehr Modulen eine direkte Bestellung beim Hersteller ([http://www.hoperf.com/doce/pro/RF12.html Produktseite]).<br />
<br />
Die Module sind zum Selbstkostenpreis von 2.95 EUR bei Sören erhältlich.<br />
<br />
= Library für den Atmel =<br />
Wir haben eine library für die RFM12 Module gebastelt. Mit ihr lassen sich die Module auf einfache Weise an den Microcontroller anbringen.<br />
<br />
Die Handhabung der Library ist realtiv einfach: Sämtliche Konfigurations-Variablen lassen sich in der Datei ''[http://roulette.das-labor.org/trac/browser/microcontroller/src-atmel/lib/rfm12/rfm12_config.h rfm12_config.h]'' einstellen. Für Atmega8 und Atmega32 Mikroprozessoren gibt es schon fertige Config-Dateien in den jew. test-Verzeichnissen (siehe [https://roulette.das-labor.org/trac/browser/microcontroller/src-atmel/lib/rfm12/ SVN]). Entsprechende Pinbelegung findet sich in besagter Config-Datei. Sollte der Interrupt PIN ein anderer sein, so muss man am Ende der Config natürlich auch die Compilezeitvariablen ''RFM12_INT_VECT'' und ''RFM12_INT_BIT'' verändern.<br />
<br />
Am Anfang sollte die Funktion ''rfm12_init()'' aufgerufen werden zur Initialisierung. Diese Funktion kümmert sich automatisch um Interrupts und korrektes Setup für die jew. Ports. Das einzige was diese Funktion nicht macht, ist die Interrupts anschalten - diese muss man selbst mit ''sei()'' anschalten.<br />
<br />
Die Funktion ''rfm12_tick()'' sollte regelmäßig aufgerufen werden.<br />
<br />
== Beispielcode ==<br />
Im [[Subversion|SVN]] ist Beispielcode [https://roulette.das-labor.org/trac/browser/microcontroller/src-atmel/lib/rfm12/test Beispielcode] hinterlegt, der die Module in Empfangsbereitschaft versetzt und ein empfangenes Byte mit den LEDs des [[Laborboard]]s anzeigt. Wenn man Button 0 drückt, sendet das Modul.<br />
<br />
Zum Betrieb der Module sind im Grunde nur wenige Befehle nötig - hier ein Beispiel:<br />
<br />
uint8_t teststring[] = "teststring\r\n";<br />
rfm12_init();<br />
sei();<br />
<br />
while (23)<br />
{<br />
/* ... */<br />
rfm12_tx (sizeof(teststring), 0, teststring);<br />
rfm12_tick();<br />
}<br />
<br />
= Datenblätter =<br />
Auf der Pollin Homepage sind unvollständige Datenblätter und nicht funktionierender Beispielcode verzeichnet. Die beigelegte Papierdokumentation ist ebenso unbrauchbar. Von diesen ist ausdrücklich abzuraten!<br />
<br />
Ein etwas brauchbareres, aber dennoch nicht ganz vollständiges Datenblatt findet sich auf der Herstellerseite: [http://www.hoperf.com/pdf/RF12.pdf Herstellerseite].<br />
<br />
= Protokoll =<br />
Die erste Version des Datenaustauschprotokolls hat den Namen [[AirLAB_Protokoll_Version_0|AirLAB v0]]. Es ist ein erste Entwicklung, die zunächst einmal in der Praxis erprobt werden muss.<br />
<br />
= Probleme =<br />
Die Module können scheinbar keine '''Kollisionen''' erkennen. Die erste Version des Protokolls arbeitet mit relativ kleinen Paketen (<= 260 Bytes), damit der Ether zum Einen möglichst schnell wieder frei wird und zum Anderen ganz einfach weil die partizipierenden Devices groessere Pakete zumeist garnicht handlen koennten.<br />
<br />
Ferner können die Module offenbar nicht die '''Empfangsstärke''' messen oder bzw. ausgeben.<br />
<br />
<br />
'''''Fehler im Beispielcode des Herstellers'''''<br />
<br />
Die Zeile "RFXX_WRT_CMD(0xC400);//1.66MHz, 2.2V" (Low Battery Detector and Clock Divider) spricht den falschen Adressbereich an und ueberschreibt die Einstellungen des AFC Command. Richtig ist (0xC000). Trotzdem funktioniert der Beispielcode - so lange man nicht den externen Takt nutzen moechte...<br />
<br />
Ueberhaupt sollte man bei den Commands nicht alles glauben, was die Kommentare als Setup vorgaukeln. Es gibt deutliche Abweichungen, unter anderem auch bei besagtem Clock Divider.<br />
<br />
= Verschlüsselung und Authenzität =<br />
Parallel zum Netzwerkstack für die Funkmodule wird auch die [[Crypto-avr-lib]] entwickelt, welche hash- und verschlüsselungsfunktionen bietet, um den Datenverkehr der Geräte untereinander zu sichern.<br />
<br />
= Praxiserfahrung =<br />
Erste Tests mit zwei mit dem Beispielcode aus dem SVN geflashten Microcontrollern haben gezeigt, das die Module wirklich zuverlässig arbeiten und offenbar relativ unanfällig für Störungen sind. So war es z.B. möglich, mit der Funkfernbedienung für die billigen Baumarktsteckdosen zu senden, während das Empfängermodul Pakete empfing.<br />
<br />
Bei einigen hundert gesendeten Paketen gingen natürlich welche verloren (gerade während des Fernbedienungs-Tests), aber offenbar kam nicht eins mit falschen Daten am Empfänger an.<br />
<br />
[[Kategorie:Microcontroller]]</div>83.135.83.184https://wiki.das-labor.org/index.php?title=Diskussion:AVRBoardPortable&diff=7686Diskussion:AVRBoardPortable2008-07-08T00:33:32Z<p>83.135.83.184: Die Seite wurde neu angelegt: Gibts da inzwischen weitere Pläne, bzw. ist das Projekt fertig? -- Sören</p>
<hr />
<div>Gibts da inzwischen weitere Pläne, bzw. ist das Projekt fertig? -- Sören</div>83.135.83.184https://wiki.das-labor.org/index.php?title=Datenfunk_mit_dem_AVR&diff=7685Datenfunk mit dem AVR2008-07-08T00:13:19Z<p>83.135.83.184: /* Library für den Atmel */</p>
<hr />
<div>= Hardware =<br />
Die benutzten Transceiver gibt es bei verschiedenen Herstellern unter dem Namen RFM12 oder RF12. Sie können im 433 Mhz ISM Band und zusätzlich auf Frequenzen in der Umgebung von 315, 868 und 915 MHz funken.<br />
<br />
In Deutschland sind die Module bei Pollin zum Preis von 8 Eur erhältlich, allerdings lohnt sich ab einer Menge von 10 oder mehr Modulen eine direkte Bestellung beim Hersteller ([http://www.hoperf.com/doce/pro/RF12.html Produktseite]).<br />
<br />
Die Module sind zum Selbstkostenpreis von 2.95 EUR bei Sören erhältlich.<br />
<br />
= Library für den Atmel =<br />
Wir haben eine library für die RFM12 Module gebastelt. Mit ihr lassen sich die Module auf einfache Weise an den Microcontroller anbringen.<br />
<br />
Die Handhabung der Library ist realtiv einfach: Sämtliche Konfigurations-Variablen lassen sich in der Datei ''[http://roulette.das-labor.org/trac/browser/microcontroller/src-atmel/lib/rfm12/rfm12_config.h rfm12_config.h]'' einstellen. Für Atmega8 und Atmega32 Mikroprozessoren gibt es schon fertige Config-Dateien in den jew. test-Verzeichnissen (siehe [https://roulette.das-labor.org/trac/browser/microcontroller/src-atmel/lib/rfm12/ SVN]). Entsprechende Pinbelegung findet sich in besagter Config-Datei. Sollte der Interrupt PIN ein anderer sein, so muss man am Ende der Config natürlich auch die Compilezeitvariablen ''RFM12_INT_VECT'' und ''RFM12_INT_BIT'' verändern.<br />
<br />
Am Anfang sollte die Funktion ''rfm12_init()'' aufgerufen werden zur Initialisierung. Diese Funktion kümmert sich automatisch um Interrupts und korrektes Setup für die jew. Ports. Das einzige was diese Funktion nicht macht, ist die Interrupts anschalten - diese muss man selbst mit ''sei()'' anschalten.<br />
<br />
Die Funktion ''rfm12_tick()'' sollte regelmäßig aufgerufen werden.<br />
<br />
== Beispielcode ==<br />
Im [[Subversion|SVN]] ist Beispielcode [https://roulette.das-labor.org/trac/browser/microcontroller/src-atmel/lib/rfm12/test Beispielcode] hinterlegt, der die Module in Empfangsbereitschaft versetzt und ein empfangenes Byte mit den LEDs des [[Laborboard]]s anzeigt. Wenn man Button 0 drückt, sendet das Modul.<br />
<br />
Zum Betrieb der Module sind im Grunde nur wenige Befehle nötig - hier ein Beispiel:<br />
<br />
uint8_t teststring[] = "teststring\r\n";<br />
rfm12_init();<br />
sei();<br />
<br />
while (23)<br />
{<br />
/* ... */<br />
rfm12_tx (sizeof(teststring), 0, teststring);<br />
rfm12_tick();<br />
}<br />
<br />
= Datenblätter =<br />
Auf der Pollin Homepage sind unvollständige Datenblätter und nicht funktionierender Beispielcode verzeichnet. Die beigelegte Papierdokumentation ist ebenso unbrauchbar. Von diesen ist ausdrücklich abzuraten!<br />
<br />
Ein etwas brauchbareres, aber dennoch nicht ganz vollständiges Datenblatt findet sich auf der Herstellerseite: [http://www.hoperf.com/pdf/RF12.pdf Herstellerseite].<br />
<br />
= Protokoll =<br />
Die erste Version des Datenaustauschprotokolls hat den Namen [[AirLAB_Protokoll_Version_0|AirLAB v0]]. Es ist ein erste Entwicklung, die zunächst einmal in der Praxis erprobt werden muss.<br />
<br />
= Probleme =<br />
Die Module können scheinbar keine '''Kollisionen''' erkennen. Die erste Version des Protokolls arbeitet mit relativ kleinen Paketen (<= 260 Bytes), damit der Ether zum Einen möglichst schnell wieder frei wird und zum Anderen ganz einfach weil die partizipierenden Devices groessere Pakete zumeist garnicht handlen koennten.<br />
<br />
Ferner können die Module offenbar nicht die '''Empfangsstärke''' messen oder bzw. ausgeben.<br />
<br />
<br />
'''''Fehler im Beispielcode des Herstellers'''''<br />
<br />
Die Zeile "RFXX_WRT_CMD(0xC400);//1.66MHz, 2.2V" (Low Battery Detector and Clock Divider) spricht den falschen Adressbereich an und ueberschreibt die Einstellungen des AFC Command. Richtig ist (0xC000). Trotzdem funktioniert der Beispielcode - so lange man nicht den externen Takt nutzen moechte...<br />
<br />
Ueberhaupt sollte man bei den Commands nicht alles glauben, was die Kommentare als Setup vorgaukeln. Es gibt deutliche Abweichungen, unter anderem auch bei besagtem Clock Divider.<br />
<br />
= Verschlüsselung und Authenzität =<br />
Parallel zum Netzwerkstack für die Funkmodule wird auch die [[Crypto-avr-lib]] entwickelt, welche hash- und verschlüsselungsfunktionen bietet, um den Datenverkehr der Geräte untereinander zu sichern.<br />
<br />
= Praxiserfahrung =<br />
Erste Tests mit zwei mit dem Beispielcode aus dem SVN geflashten Microcontrollern haben gezeigt, das die Module wirklich zuverlässig arbeiten und offenbar relativ unanfällig für Störungen sind. So war es z.B. möglich, mit der Funkfernbedienung für die billigen Baumarktsteckdosen zu senden, während das Empfängermodul Pakete empfing.<br />
<br />
Bei einigen hundert gesendeten Paketen gingen natürlich welche verloren (gerade während des Fernbedienungs-Tests), aber offenbar kam nicht eins mit falschen Daten am Empfänger an.</div>83.135.83.184https://wiki.das-labor.org/index.php?title=Datenfunk_mit_dem_AVR&diff=7684Datenfunk mit dem AVR2008-07-08T00:08:24Z<p>83.135.83.184: </p>
<hr />
<div>= Hardware =<br />
Die benutzten Transceiver gibt es bei verschiedenen Herstellern unter dem Namen RFM12 oder RF12. Sie können im 433 Mhz ISM Band und zusätzlich auf Frequenzen in der Umgebung von 315, 868 und 915 MHz funken.<br />
<br />
In Deutschland sind die Module bei Pollin zum Preis von 8 Eur erhältlich, allerdings lohnt sich ab einer Menge von 10 oder mehr Modulen eine direkte Bestellung beim Hersteller ([http://www.hoperf.com/doce/pro/RF12.html Produktseite]).<br />
<br />
Die Module sind zum Selbstkostenpreis von 2.95 EUR bei Sören erhältlich.<br />
<br />
= Library für den Atmel =<br />
Wir haben eine library für die RFM12 Module gebastelt. Mit ihr lassen sich die Module auf einfache Weise an den Microcontroller anbringen.<br />
<br />
Die Handhabung der Library ist realtiv einfach: Sämtliche Konfigurations-Variablen lassen sich in der Datei ''rfm12_config.h'' einstellen. Für Atmega8 und Atmega32 Mikroprozessoren gibt es schon fertige Config-Dateien in den jew. test-Verzeichnissen (siehe [https://roulette.das-labor.org/trac/browser/microcontroller/src-atmel/lib/rfm12/ SVN]).<br />
<br />
Am Anfang sollte die Funktion ''rfm12_init()'' aufgerufen werden zur Initialisierung. Diese Funktion kümmert sich automatisch um Interrupts und korrektes Setup für die jew. Ports.<br />
<br />
Die Funktion ''rfm12_tick()'' sollte regelmäßig aufgerufen werden.<br />
<br />
== Beispielcode ==<br />
Im [[Subversion|SVN]] ist Beispielcode [https://roulette.das-labor.org/trac/browser/microcontroller/src-atmel/lib/rfm12/test Beispielcode] hinterlegt, der die Module in Empfangsbereitschaft versetzt und ein empfangenes Byte mit den LEDs des [[Laborboard]]s anzeigt. Wenn man Button 0 drückt, sendet das Modul.<br />
<br />
Zum Betrieb der Module sind im Grunde nur wenige Befehle nötig - hier ein Beispiel:<br />
<br />
uint8_t teststring[] = "teststring\r\n";<br />
rfm12_init();<br />
sei();<br />
<br />
while (23)<br />
{<br />
/* ... */<br />
rfm12_tx (sizeof(teststring), 0, teststring);<br />
rfm12_tick();<br />
}<br />
<br />
= Datenblätter =<br />
Auf der Pollin Homepage sind unvollständige Datenblätter und nicht funktionierender Beispielcode verzeichnet. Die beigelegte Papierdokumentation ist ebenso unbrauchbar. Von diesen ist ausdrücklich abzuraten!<br />
<br />
Ein etwas brauchbareres, aber dennoch nicht ganz vollständiges Datenblatt findet sich auf der Herstellerseite: [http://www.hoperf.com/pdf/RF12.pdf Herstellerseite].<br />
<br />
= Protokoll =<br />
Die erste Version des Datenaustauschprotokolls hat den Namen [[AirLAB_Protokoll_Version_0|AirLAB v0]]. Es ist ein erste Entwicklung, die zunächst einmal in der Praxis erprobt werden muss.<br />
<br />
= Probleme =<br />
Die Module können scheinbar keine '''Kollisionen''' erkennen. Die erste Version des Protokolls arbeitet mit relativ kleinen Paketen (<= 260 Bytes), damit der Ether zum Einen möglichst schnell wieder frei wird und zum Anderen ganz einfach weil die partizipierenden Devices groessere Pakete zumeist garnicht handlen koennten.<br />
<br />
Ferner können die Module offenbar nicht die '''Empfangsstärke''' messen oder bzw. ausgeben.<br />
<br />
<br />
'''''Fehler im Beispielcode des Herstellers'''''<br />
<br />
Die Zeile "RFXX_WRT_CMD(0xC400);//1.66MHz, 2.2V" (Low Battery Detector and Clock Divider) spricht den falschen Adressbereich an und ueberschreibt die Einstellungen des AFC Command. Richtig ist (0xC000). Trotzdem funktioniert der Beispielcode - so lange man nicht den externen Takt nutzen moechte...<br />
<br />
Ueberhaupt sollte man bei den Commands nicht alles glauben, was die Kommentare als Setup vorgaukeln. Es gibt deutliche Abweichungen, unter anderem auch bei besagtem Clock Divider.<br />
<br />
= Verschlüsselung und Authenzität =<br />
Parallel zum Netzwerkstack für die Funkmodule wird auch die [[Crypto-avr-lib]] entwickelt, welche hash- und verschlüsselungsfunktionen bietet, um den Datenverkehr der Geräte untereinander zu sichern.<br />
<br />
= Praxiserfahrung =<br />
Erste Tests mit zwei mit dem Beispielcode aus dem SVN geflashten Microcontrollern haben gezeigt, das die Module wirklich zuverlässig arbeiten und offenbar relativ unanfällig für Störungen sind. So war es z.B. möglich, mit der Funkfernbedienung für die billigen Baumarktsteckdosen zu senden, während das Empfängermodul Pakete empfing.<br />
<br />
Bei einigen hundert gesendeten Paketen gingen natürlich welche verloren (gerade während des Fernbedienungs-Tests), aber offenbar kam nicht eins mit falschen Daten am Empfänger an.</div>83.135.83.184https://wiki.das-labor.org/index.php?title=Datenfunk_mit_dem_AVR&diff=7683Datenfunk mit dem AVR2008-07-07T23:53:28Z<p>83.135.83.184: link verbessert</p>
<hr />
<div>= Hardware =<br />
Die benutzten Transceiver gibt es bei verschiedenen Herstellern unter dem Namen RFM12 oder RF12. Sie können im 433 Mhz ISM Band und zusätzlich auf Frequenzen in der Umgebung von 315, 868 und 915 MHz funken.<br />
<br />
In Deutschland sind die Module bei Pollin zum Preis von 8 Eur erhältlich, allerdings lohnt sich ab einer Menge von 10 oder mehr Modulen eine direkte Bestellung beim Hersteller ([http://www.hoperf.com/doce/pro/RF12.html Produktseite]).<br />
<br />
Die Module sind zum Selbstkostenpreis von 2.95 EUR bei Sören erhältlich.<br />
<br />
= Beispielcode =<br />
Im [[Subversion|SVN]] ist Beispielcode [https://roulette.das-labor.org/trac/browser/microcontroller/src-atmel/lib/rfm12/test Beispielcode] hinterlegt, der die Module in Empfangsbereitschaft versetzt und ein empfangenes Byte mit den LEDs des [[Laborboard]]s anzeigt. Wenn man Button 0 drückt, sendet das Modul.<br />
<br />
= Datenblätter =<br />
Auf der Pollin Homepage sind unvollständige Datenblätter und nicht funktionierender Beispielcode verzeichnet. Die beigelegte Papierdokumentation ist ebenso unbrauchbar. Von diesen ist ausdrücklich abzuraten!<br />
<br />
Ein etwas brauchbareres, aber dennoch nicht ganz vollständiges Datenblatt findet sich auf der Herstellerseite: [http://www.hoperf.com/pdf/RF12.pdf Herstellerseite].<br />
<br />
= Protokoll =<br />
Die erste Version des Datenaustauschprotokolls hat den Namen [[AirLAB_Protokoll_Version_0|AirLAB v0]]. Es ist ein erste Entwicklung, die zunächst einmal in der Praxis erprobt werden muss.<br />
<br />
= Probleme =<br />
Die Module können scheinbar keine '''Kollisionen''' erkennen. Die erste Version des Protokolls arbeitet mit relativ kleinen Paketen (<= 260 Bytes), damit der Ether zum Einen möglichst schnell wieder frei wird und zum Anderen ganz einfach weil die partizipierenden Devices groessere Pakete zumeist garnicht handlen koennten.<br />
<br />
Ferner können die Module offenbar nicht die '''Empfangsstärke''' messen oder bzw. ausgeben.<br />
<br />
<br />
'''''Fehler im Beispielcode des Herstellers'''''<br />
<br />
Die Zeile "RFXX_WRT_CMD(0xC400);//1.66MHz, 2.2V" (Low Battery Detector and Clock Divider) spricht den falschen Adressbereich an und ueberschreibt die Einstellungen des AFC Command. Richtig ist (0xC000). Trotzdem funktioniert der Beispielcode - so lange man nicht den externen Takt nutzen moechte...<br />
<br />
Ueberhaupt sollte man bei den Commands nicht alles glauben, was die Kommentare als Setup vorgaukeln. Es gibt deutliche Abweichungen, unter anderem auch bei besagtem Clock Divider.<br />
<br />
= Verschlüsselung und Authenzität =<br />
Parallel zum Netzwerkstack für die Funkmodule wird auch die [[Crypto-avr-lib]] entwickelt, welche hash- und verschlüsselungsfunktionen bietet, um den Datenverkehr der Geräte untereinander zu sichern.</div>83.135.83.184