Codeaustausch und "herzeig" Thread - Projekte mit TinkerForge Bricks

Hallo an alle Entwickler und Kunden hier,

ich will mal zeigen, dass die Bricks nicht nur gekauft und nie wieder angesehen werden sondern auch für kleine und große Aufgaben eingesetzt werden. PS: Ich hoffe auf Nachahmer hier im Thread.

Projekt 1: Test der Bricklets - "Die Kiste"

http://www.therealblack.net/TFUploads/Kiste_Test1_20111224.jpg

http://www.therealblack.net/TFUploads/Kiste_Test1_Aufbau_20111224.jpg

http://www.therealblack.net/TFUploads/Tests_1.zip

In diesen Test verwende ich das Temperatur Bricklet, das Umgebungslichtbricklet, einen IR Entfernungsmesser und ein IO16 Bricklet zusammen mit einen Masterbrick.

Aufbau:

Wie am Bild zu sehen ist (oben rechts) habe ich Temeratur und Umgebungslicht Brickltes zusammen geschaubt damit sie eine handlichere einheit ergeben. Den IR Sensor habe ich an die Rückseite des entsprechenden Bricklets geschraubt später soll dies als Sensoreinheit dienen. Am IO16 Bricklet habe ich auf Port A 8 Leds angebracht, dass ist ziemlich einfach da Grd immer zwischen 2 Ausgängen platziert ist (Top! So wünscht man es sich!). An Port B befindet sich ein Schiebeschalter auf 0 und 1 sowie 2 Taster auf 2 und 3. Alle Pins von Port B sind sinnvollerweise auf Hi gesetzt.

Codeaufbau:

In einer Utilklasse habe ich statisch alle ID Strings hinterlegt welche wenn jemand das Projekt verwenden möchte auf die jeweiligen ID's angepasst werden muss. Die gezeigten Benutersteuerelemente sind so aufgebaut, dass man in die Eigenschaft "Bricklet" nur das erstellte und der Verbindung hinzugefügte Objekt stecken muss damit sie arbeiten. Im Grunde ist dies nur eine Spielerei damit die Daten der Bricks auf die Oberfläche geschrieben werden. Diese Aufgabe hätte auch der Brickviewer erledigen können.

Die "Kiste" soll nur die erste Stufe meines Projekts darstellen. Step 2 ist ein stationärer "Scanner" bzw. "Wetterstation". Der IR Sensor soll auf einen Servo befestigt werden damit er in einen 180° Winkel mehrere Abstandsmessungen durchführt. Step 3 ein mobiler Scanner also ein Roboter ^^ welcher sich bewegt und eine Karte eines Raumes erstellt. Ziel in Schritt 4 ist es, dass ein Ausgesetzter Roboter einen Raum erfasst und verschiedene Karten erstellt (Wärme, Licht, Umgebung).

Aber erst mal steht Step 2 an: Hierzu benötige ich ein Servo Bricklet und einen passenden Servo Motor. Ich freue mich über Tipps welche Servos für mein Projekt geeignet sind und sich auch problemlos mit den Bricks betreiben lassen. Für Tipps von Bastlern und Modellbauern wäre ich sehr dankbar. Wenn jemand Erfahrungen bereits gesammelt hat sollte sie bitte hier oder im Wiki dann niederschreiben. (Tabelle welche Servos geeignet sind, Kosten, Einstellungen am Brick usw)

PS: die Komponenten sind frei zu verwenden solange sie weiter Quellcode offen und kostenlos bleiben ^^ vieles beruht sowieso auf den Beispielen von TinkerForge.

Für Softwareentwickler hätte ich einen Tipp für ein deutschsprachiges Entwicklerforum:

http://zfx.info/

ich denke mal sie hätten nichts dagegen wenn wir uns dort über TinkerForge austauschen würden. Ebenso ist die Forenverwaltung etwas gewöhnter und nicht Antworten orientiert wie hier.

Happy Coding und ein schönes Fest

wünscht The_Real_Black

Edit: ^^

Cool!

Wie schon im Blog beschrieben arbeiten wir an einem Community Portal wo man solche Projekte einfach vorstellen können wird! Da wird es dann auch ein besseres Forum geben (dieses hier werden wir entfernen)

Frohe Weihnachten, Olaf

Dies hatte ich bis jetzt nicht mitbekommen, aber solange wollte ich auch nicht warten ^^ Ich freue mich schon auf einen Austausch mit anderen Entwicklern\Bastlern\"euren Kunden" ^^ Mal sehen welche Projekte hier noch aufkommen.

Test Test ^^

Ich schreib mal wieder was damit ihr nicht denkt, dass ich euch vergessen habe ^^ Ich habe 2 Servos bereits gekauft und warte nur noch darauf, dass der Servo Brick verfügbar wird. Desweiteren will ich noch das 4x20 Display und einen zweiten IR Sensor. Wird es dafür auch noch andere Sensoren bei euch geben? Wenn nicht hoffe ich, dass der mit der größten Reichweite auf Lager ist. Wenn es bereits die Chibi und IMU gibt werde ich über diese auch nachdenken. Softwareseitig hat sich leider nichts weiter entwickelt wenn ich Zeit habe werde ich aber dort auch wieder weiter machen.

IMU Brick ... nee zu teuer... später mal muhahaha

Servo Brick -> ab in Warenkorb

Analog Out Bricklet -> ab in Warenkorb

LCD 20x4 Bricklet -> *Fuuuuuuuuuuuu* ausverkauft...

Euch kaufen die Leute ganz schön die Brick umterm A** weg oder?

;-P

Naja wenn mal alles 3 verfügbar ist kaufe ich es dann mal.

http://www.therealblack.net/TFUploads/TRB_TF_Projekt.7z

Viel neues gibt es nicht. Die letzte Zeit habe ich mit dem Verwalten der Bricks verbracht. Mit der Enumaration Methode packe ich alle empfangenen Daten in eine Liste welche ich dann einfacher durchgehen kann.

Als Test gibt es eine Form welche alle angeschlossenen Bricks in einen DataGridView auflistet.

Ideensammlung:

Die beiden LCDs haben je 3 Taster hier lohnt sich die Entwicklung eines generisches Menüsystems. In einen XML wird die Struktur vorgegeben, dann kann man durch Navigieren und Werte setzen.

<menu>

___<Gruppe text="Hallo">

___</gruppe>

___<Gruppe text="Welt">

______<IntWert text="Integer Test" min="0" max="10" value="3" default="2"/>

______<IntWert text="Testing2" min="0" max="10" value="3" default="2"/>

______<BoolWert text="an\aus" value="true" default="false"/>

______<DoubleWert text="genau:" value="3.1"  min="0" max="10" step="0.1" default="2.0"/>

___</gruppe>

</menu>

Ansichten:

- Hallo

-

-

- Tasten: <-left (in Gruppe gehen) right->

*l oder r und "enter" drücken*

- Integer Test

- Value=3

- <-Zurück ok nächste Option->

- Tasten: <-left(gruppe verlassen) (Wert Ändern) right->

*enter*

- Integer Test

- Value = 3

- Wert Setzen

- <- verringern (Wert setzen) werterhöhen->

*hin her und enter* siehe eins Oben.

Um aus den Menübaum wieder zurück zu kommen würde dauern da immer bis zur ersten oder letzten Option Scrollen muss um nach oben zu kommen. Sicherheit würde es auch nicht geben, da so kein "nicht Speichern" Button gibt.

Wie kommt man überhaupt auf 3 Buttons... 5 ist eine schöne Zahl ;-P ne bei einer Uhr hat man auch ein Paar Knöpfe und man muss ja nicht gigantische Menü Strukturen aufbauen ^^

Ansonsten gehe ich dieser Idee mal nach ^^

@The_Real_Black: Die Idee eines generischen Menüs finde ich gut!

Ich glaub ich brauch einen Eigenen Thread mit meinen Namen als Threadersteller...

Link ist immer noch der gleiche:

http://www.therealblack.net/TFUploads/TRB_TF_Projekt.7z

Nun mit Menüsystem! Ich habe den Bin Ordner hier mal nicht gelöscht damit gleich getetet werden kann. Dieses "MenueSystem" arbeitet mit 3 Methoden: Left Enter Right

wleche die 3 Buttonsdarstellen. Im beiliegenden XML wird das Menü aufgebaut.

Es gibt im Moment nur eine flache Struktur. Es wird nicht empfohlen gruppe in eine gruppe zu packen ^^. Ansonsten lassen sich die Optionen bereits setzen.

<text> dient zur 4 zeiligen Anzeige von Texten (Hilfe und Co)

<int> ist ein Int Wert

<double> ein double Wert

und <bool> true oder false...

<menu> ist die root.

<gruppe> ist eine Sammlung von weiteren Elementen.

Wenn ein Gruppe nach Links oder Rechts bis zum Ende durchlaufen wird wird die Gruppe wieder verlassen.

Wenn ein Wert Knoten betreten wird (enter) gelangt man in den Editier Modus hier ist Links und Rechts Wert verringern oder erhöhen! Mit Enter wird der Wert gespeichert (auch im XML).

XML Menü:

<?xml version="1.0" encoding="utf-8" ?>

<menu>

  <gruppe text="Text Menü">

      <text lineA="Zeile1" lineB ="Zeile2" lineC="Zeile3" lineD="Zeile4" />

      <text lineA="ZeileA" lineB ="ZeileB" lineC="ZeileC" lineD="ZeileD" />

  </gruppe>

  <gruppe text="Options Menü">

      <int text="Integer Test" min="0" max="10" value="3" default="2"/>

      <int text="Testing2" min="0" max="10" value="3" default="2"/>

      <bool text="an\aus" value="true" default="false"/>

      <double text="genau" value="3.1"  min="0" max="10" step="0.1" default="2.0"/>

  </gruppe>

  <gruppe text="A other Menue">

    <int text="IntegerValue" min="0" max="10" value="3" default="2"/>

  </gruppe>

</menu>

Für Anregungen oder Kommentare bin ich froh.

PS: Dies ist eine TF Unabhängige Klasse! Ihr braucht zum Test keine Bricks anstecken. Einen Test mit einem angeschlossenen LCD Brick folgt noch ^^

Der Zugriff auf die Variablen ist im Moment auch noch nicht Implementiert, dass soll ein Dic werden zum auslesen und setzen ^^.

Viel Spaß mit dem Code!

Update! Box2 ein LCD Test mit dem neuen Menü. Das Menü kann von der GUI aus gesteuert werden wie auch vom LCD Bricklet aus. Sollten keine Bricks angeschlossen sein ist das Programm immer noch lauffähig.

Die Werte können gesammelt ausgelesen werden (Rückgabe in einen Dic<string,object>) aber auch einzeln über die id. Die id muss eindeutig sein!

Ein Beispiel XML liegt bei!

Viel Spaß mit dem Code!

Edit:

Ein Bild wie gut es funktioniert ^^

Doku:

Left(), Enter(), Right() und die allgemeine Variante Button(MenueButtons klick)

Entsprechen den Buttons am LCD Bricklet.

string[] GetCurrentLines() und GetCurrentLines(bool cutLines)

Geben die 4 anzuzeigenden Zeilen zurück. Mit dem Bool wird gesteuert ob die Zeilen bei 20 Zeichen bereits geschnitten werden sollen. Die Zeilen der Optionen sind festgelegt Editiermodus (siehe Bild) 1. Text Feld der Option (Freitext, nur Id muss eindeutig sein) 2. Value: Der aktuelle Wert der Option 3. ist der Default Wert die letzte Zeile ist dann das Minimum und Maximum der Option. Im Ansichtsmodus bleiben die beiden unteren Zeilen leer. Es lässt sich aber alles leicht anpassen.

Ich muss noch die Zeichensätze umbiegen... oder hat da schon in C# eine Implementierung?

Ich hab jetzt eine Wiki Seite:

http://www.tinkerunity.org/wiki/index.php/The_Real_Blacks_Projekte

Box 3 ist in Arbeit

http://www.therealblack.net/TFUploads/Box3_ServoScanner.jpg

der neue Code kommt die Tage ^^

Ich musste erst mal feststellen, dass je kleiner die Servos sind auch die Löcher in den Flügeln keiner sind... 1mm Schrauben hat man halt nicht so einfach im Keller ^^ Jetzt musste der größere Servo ran um das IR Bricklet fest zu halten. 3mm Schrauben passt ^^ klappt im Handbetrieb bereits gut.

Meinungen, Anregungen, Hinweise zum Code und zur Kiste sind gerne gesehen.

Update

http://www.therealblack.net/TFUploads/Box3_ServoScanner_Scann.jpg

Es lebt und es sieht sich um!

Ich muss mir mal Gedanken um Bewegung machen damit die Kiste auch durch die Welt kommt.

Edit: Ich habe die TF.DLL im Projekt mal mitgegeben. Hoffentlich klappt es mit dem Projekt kompilieren besser.

Das Bild ist auch schon wieder veraltet: Es gibt jetzt eine neue Checkbox namens"Glätten", welche beim Automatischen Messen erst über 3 Messungen einen Mittelwert bildet bevor es im Radar eingetregen wird.

Edit 20.05.2012 17:30:

Es gibt schon wieder eine neue Version (ich hab ein Tool geschrieben welches mit die Ordner bereinigt und dann Zippt *g*) an der Kiste 3 habe ich einige kleine Änderungen gemacht die Glättung kann nun eingestellt werden um stabilere Werte zu erhalten. Wertebereich ist 3-10 das sollte genügen wenn man Werte für Navigation eines Roboters anstrebt.

@Coder: Ich unterscheide im Moment meine beiden IR Bricklets anhand der UID wenn ihr eure Bricklets unterscheiden wollt müsst ihr die IDs anpassen und im Radar Control eure Min Max Werte setzen:

                        rad_Dispaly.RadarMaximum = 150;

                        rad_Dispaly.RadarMinimum = 10;

Sensor von 150 cm bis Minimal 10 cm

ich vermisse den berühmten [like] Button im Forum 

Like

Danke euch beiden ^^

Roadmap:

- Radar zu einer Map weiterentwickeln damit verschiedene Messungen in ein Bild übertragen werden können.

- Kiste 3 verbessern (Scann Typen: Gerade aus\Umgebung\kontinuierlich)

-- Events für Annäherung usw implementieren.

- Code clean up\Kommentieren\angeachte Methoden fertig stellen.

-- LCD Bricks immer in den Utils merken und bei Bedarf Licht ausschalten und Text löschen wenn Form geschlossen wird. (Muss im Moment mit der Hand gemacht werden...)

- Projekte säubern

- Menü 1 irgendwo Sinnvoll verwenden

-- Events beim Ändern von Werten hinzufügen, damit man auch mitbekommt, dass der User im Menü was geändert hat.

- Menü 2 (Auswahl Rauf Runter)

- Gedanken um Kiste 4 machen:

-- Lochblech für Brickmontage besorgen

-- Fahrwerk aussuchen

-- Montage Plan ersellen

-- Stepper Brick(s) oder DCs, passende Motoren, einen weiteren Servo RS-2, Akku Pack, Chibi\WLan Brick und weiteren Kram bestellen...

Viel zu tun ^^

Update größte Änderung, ich hab ein Changelog  :

Version: 1.2    Datum:    25.05.2012

- Box 3 Servo Scanner 2:

    Von Version 1 des Scanners wurde das Layout überarbeitet

    und mehr Optionen für den Automatikmodus hinzugefügt

    Es gibt eine Hilfe wenn mit der Maus über die

    verschiedenen Controls gefahren wird.

    Es gibt einen Andauernden Scan Modus:

        Dieser Modus ist über einen Thread realisiert welcher sanft beendet

        werden kann beim zurückschalten auf Stop wird der Servo auf Pos 0 gesetzt

        und der Thread verlassen. Dies kann ein paar Sekunden dauern (je nach

        gewählter Option...)

        Es gibt folgende Optionen:

        - Messwinkel (Schwenkbereich 0 bis +-100)

        - Pause zwischen den Messungen kann in ms festgelegt werden

        - Wartezeit in s wenn der Sensor eine der beiden Maximalpositonen erreicht hat.

        - Wartezeit in ms beim Messen der Werte zur Mittelwertbildung.

    Wenn nicht alle nötigen Bricks erkannt werden wird eine MsgBox angezeigt

    und die Form gesperrt da einiges bereits gesetzt wurde was sich nur

    per Debugger zurück setzen lässt. (Selbst da mache ich immer einen

    neustart ist einfacher und so fliegen keine Exceptions auf!)

- Hilfe Anzeigen per Helperklasse (In Controls

    muss die "Tag" Eigenschaft mit einen String

    gefüllt sein um eine Mouse-Over-Hilfe

    angezeigt zu bekommen.)

- BrickConnectionUtil ("Die Helperklasse"  )

    kann jetzt mit einer Form gefüttert werden welche dann

    in die FormClosingUtils gepackt wird und somit die

    IP Connection sauber beendet wenn die Form beendet wird.

- Utils

    letzte UIDs wurden aus den Constanten entfernt!

    wurden nur noch in Box 1 verwendet!

    Test Utils wurden auch in Box 1 verschoben!

- LCD wird über Code Schnipsel von TinkerForge nun um Codiert.

    Danke an TF!

- Beginne ein Changelog

    mehr oder weniger Sinn bei der Reihenfolge der Features ^^

Ah cool, sehr interessant!

Ich bin dabei ähnliches zu programmieren. Bei mir wirds auf Basis des RP6.

Dazu habe ich den selben Ansatz wie du mit dem Servo und Distance IR gewählt um die Umgebung zu scannen. Dazu habe ich auch eine Scanner Klasse geschrieben. Hier kleines Demo Form:

Leider fehlen mir derzeit noch das Servo Brick um das ganze auf einem Servo zu testen. (Hier ist das IR mit der Hand bewegt).

Wie ist deine Messauflösung? 1 Messung pro 1°?

Schöne Grüße

Leider fehlen mir derzeit noch das Servo Brick um das ganze auf einem Servo zu testen. (Hier ist das IR mit der Hand bewegt).

Wie ist deine Messauflösung? 1 Messung pro 1°?

Ja genau, außer ich Glätte die Werte dann sind es x Messungen je Grad.

Eine Option mit der die Auflösung gesteuert werden kann fehlt mir leider noch ^^

Die Frage ist wie viele Messung benötige ich wenn die Kiste mal Räder bekommt um eine Wegfindung umzusetzen.

Mit Messlinie und Flächen sieht das Radar auch gut aus. Ich will später aber die Messungen übereinander legen da würden Flächen stören, aber die Line werde ich auch einbauen, alleine wegen der Optik ;-)

Den RP6 habe ich mir auch schon angesehen, aber ich habe mich noch nicht festgelegt. Da würde ich gerne Erfahrungen hören, wie man dort am besten mit den Motoren umgeht und die verbaut... Ich würde da auf Stepper verwenden um etwa messbare Wege zu erhalten.

Die Frage ist wie viele Messung benötige ich wenn die Kiste mal Räder bekommt um eine Wegfindung umzusetzen.

Der Distance IR ist da sehr gut geeignet für die Kollisionsvermeidung. Die muss eigentlich auch nicht sehr genau messen und daher sollten dann auch nen einzelner Messwert ausreichen.

Soll deine Kiste dann im "freien Gelände" (Zimmer etc.) fahren oder in einer definierten Umgebung (http://www.tu-chemnitz.de/etit/proaut/lehre/rsrc/roboterUndBoje.jpg)? Bei letzterem kann man die Abstandssensoren dann nicht nur für die Kollisionsvermeidung sondern auch zur Erkundung verwenden. Da sind genauere Entfernungsangaben evtl. interessant.

Plan bei mir ist es, einen beliebigen Raum zu erkunden.

Das mit den StepperBrick zur Positionerkennung wird leider nicht funktionieren, da der Kettenantrieb bei Kurvenfahrten sehr viel Schlupf hat (genau das Problem hatte ein Bekannter mit seinem rp6. Er benutzte allerdings die angebotene elektronik fuer dieses modell).

Eine Lösung fuer die Positionserkennung habe ich noch nicht gefunden. Wenn man immer im Abstand zu einem Gegenstand wäre, könnte man diesen Abstand plus Winkel benutzen, aber dann müsste der Raum wieder sehr klein sein.

Ich habe mich jedenfalls für zwei DC Bricks entschieden, da das automatische fahren auch noch nicht ganz oben auf der ToDo Liste steht.

Zuerst will ich den Raspberry mit Wlan zum laufen bekommen, dann muss ich mich noch um eine mobile Stromversorgung umschauen. Ziel ist, über USB eine normale Webcam an den Rasp zu haengen, dort einen MJPEG zu hosten und diesen auf dem Steuerungs PC auszugeben.

Die Webcam kommt dann zur Steuerung auf den rp6.

Schöne Grüße

PS: Macht eigentlich eine Glättung viel Sinn, da pro Messung intern bereits eh 50 Messungen durchgeführt werden? Haben sich die Werte groß geändert? Bei meinen Tests wirkte es nämlich auch so schon sehr genau.

PPS: Bem RP6 sind bereits Motoren samt Getriebe enthalten und eingebaut. Daher müsste man selber einen Schrittmotor einbauen falls gewollt.

Die Frage ist wie viele Messung benötige ich wenn die Kiste mal Räder bekommt um eine Wegfindung umzusetzen.

Tatsächlich sind es ja immer zwei Auflösungen die du Gegeneinander veränderst. Du kannst alle 1° Messen, brauchst dann aber insgesamt sehr lange bis du eine volle Schwenkung geschafft hast:

- Hohe räumliche Auflösung (wenige Lücken)

- geringe Zeitliche Auflösung (in Bewegung schwierig)

Alternativ könntest du halt die Abstände vergrößern, damit würde ein Durchlauf schneller gehen, aber die Lücken würden halt größer und du könntest was übersehen.

Wie lange Dauert im Moment ein Scan von 180° wenn du in 1° Schritten misst?

Eine reine Wegfindung ist denke ich einfacher wie eine Erkundung.

Bei einer Wegfindung fährst einfach direkt auf das Ziel zu und musst Objekten nur ausweichen und immer versuchen den kürzesten Weg zum Ziel zu finden. Ist erstens vom Algorithmus her "einfacher" und benötigt primär Messungen in Fahrtrichtung. Evtl. lohnen auch auch Messungen +-30° zur Fahrrichtung um ggf. den kürzesten Weg zum Ziel bestimmen zu können.

Eine Erkundung, bzw. das was ich jetzt darunter verstehe, ist da sicher aufwändiger. Entweder du fährst das interessante Gebiet komplett ab und vermisst es immer in Fahrtrichtung oder fährst unterschiedliche Punkte innerhalb des Gebietes an um dann Rundum-Messungen durchzuführen.

Die Mitellung der Werte könntest z.B. auch abhängig von der gemessenen Entfernung machen. D.h. wenn du ein Objekt findest die Entfernung genauer vermessen und wenn dort nichts ist dann reicht eine Einzelmessung. Analog kann man dies auch für den Verfahrwinkel machen.

@Holy: Da ich keine definierte Umgebung bieten kann, muss eine freie Umgebung genügen.  Eine einfache Kollisionsvermeidung wird da ein Zwischenschritt zur Raumerkundung.

@Imbafestor: Den Plan verfolge ich auch. Wenn man zumindest über gerade Strecken ein Fixpunkt in Fahrtrichtung hat kann man zurück rechnen um wie viel sich eine Wand angenähert hat. Aber da ist ein geringer (oder kein) Schlupf natürlich auch besser. Mal sehen wie es mit dem IMU (wenn er ankommt so läuft, dann kann ich mal darüber nachdenken was ich an Genauigkeit  bei den Motoren benötige.

@AuronX: “ Wie lange Dauert..180° wenn du in 1° Schritten“:  Ohne Glättung ca. 2 Sekunden.  *Wer misst, misst Mist.* Messung:  2766 ms  Mit Glättung 3xWerte: 6127 ms.

Ich würde die Erkundung so implementieren, dass nach einer Messung der Roboter erst eine definierte Strecke zurücklegt, sehen bleibt und dort eine nächste Messung durchführt. So benötige ich zwar mehr Zeit aber es sollte so kein Problem sein genügend genau zu werden.

@Imbafestor „Glättung…Sinn“: Ja macht es, zumindest bei beim bewegten Messen. Vieleicht müsste ich nur die warte Zeit für die Servo Bewegung erhöhen, aber mit den 3 Messungen verändert sich das Radar (aus einer Position heraus) bei mehreren Messungen hintereinander kaum noch. Vorher haben sich die Punkte immer wieder um cm hin und her verschoben.

@Holy: „Eine reine Wegfindung ist denke ich einfacher wie eine Erkundung.“ Stimmt. Zum Rest werde ich erst mal sehen wie gut die Werte werden und dann erst entscheiden ob ich die Messpunkte eingrenze.

Oh, das ist deutlich fixer als ich erwartet habe ^^

Ich glaube sowas bau ich mir aus Spaß auch noch Habe ja noch nen alten Fighterbuggy (RC-Fahrzeug) ^^