- LiTime Speicher und Akkus         
Seite 1 von 11 123 ... LetzteLetzte
Ergebnis 1 bis 10 von 110

Thema: Think Modular

  1. #1
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    07.04.2015
    Beiträge
    865

    Think Modular

    Anzeige

    Praxistest und DIY Projekte
    (Für die, die hier öfter lesen: Ich wurde aufgefordert.)

    Hier soll es um den modularen Aufbau mobiler autonomer Roboter gehen. Vor dem Hintergrund, dass solche Systeme mittlerweile z.B. auch als Staubsauger systematisch unsere Wohnung abgrasen und damit technisch offensichtlich für wenig Geld machbar sind, ist die Frage: Was steckt drin? Wie spielt es zusammen? Was muss ich tun, um Ähnliches zu erreichen?

    Ähnlich könnte sein, ein eigenes Saugsystem mit der Sicherheit zu bauen, dass Daten nicht ungefragt zum Hersteller versendet werden. Vielleicht kann man auch einen Teleskoparm drauf montieren, der Lichtschalter und Heizungsregler bedient. Oder es soll nur der Teppichkrabbler als Programmierspielzeug werden. Ideen und Realisierungen auch in diese Richtung sind hier gefragt.

    All diesen Ideen gemeinsam ist: Es bewegt sich, es hat Sinne und es interagiert über Schnittstellen mit Umgebung und Benutzer. Zumindest die Arbeitszeiten kann man beim Staubsaugerroboter einstellen, meist auch Umgebungskarte und Standort abfragen. Dahinter steckt ein fein abgestimmtes System aus Sensoren, Aktoren, Mechanik und auf jeden Fall auch eine deftige Portion Software.

    Eigentlich fast zu viel, um als Hobbyist von der Pike auf all diese Themen zu beackern: Hinter der Bewegung und den Sinnen steckt die Versorgung. Für den autarken Betrieb braucht man Ladetechnik, zum Andocken an eine Ladestation braucht es wieder Sensorik. Vorlagen, Konzepte oder der schlichte Meinungsaustausch sind also wünschenswert. Letztlich noch die Idee, hier im Forum einzelne Module herauszunehmen und praktische Lösungen für den Nachbau so zu gestalten, dass sie untereinander kombinierbar sind.


    Um der Diskussion an diesem Punkt etwas Fleisch zu geben, anbei (neben ein paar Bildern aus dem RP6-Nachfolger-Thread) das Modulschaltbild meines letzten Modells:
    Anhang 34456

    Klicke auf die Grafik für eine größere Ansicht

Name:	ModuleSchema.jpg
Hits:	30
Größe:	46,0 KB
ID:	35305

    Power: Es hat auch bei mir etwas gebraucht, diesen Teil mental als USV zu deklarieren. Letztlich steht mein "Movie" (so heißt das Ding) hauptsächlich in Bereitschaft am Ladegerät. Der "Stromausfall" ist dann der eigentliche Betrieb. Weitere Anforderungen (Laden, Balancing, Temperatur-/Spannungsüberwachung der Zellen, Ein-/Ausschalter, zusätzliche Spannungsausgänge) machen die Hardware recht komplex, aber der Anspruch, den Movie 24/7 in Bereitschaft zu halten, besteht nun mal.

    Peripherie: Der Sternpunkt der Hardware. In diesem Fall bot es sich an, neben einigen Hardwarefunktionen der Sensorplattform auch das gesamte Bewegungsmodul direkt über den Peripheriecontroller zu steuern. Ich hatte die Pins. Bei komplexeren Fortbewegungsmethoden (z.B. Beine) kann man daraus auch ein einzelnes DriveModul machen. Letztlich beschränkt sich die Schnittstelle auf eine begrenzte Anzahl von Fahrbefehlen und die zyklische Rückmeldung einer Pose (x-/y-Koordinaten und Blickwinkel des Roboters).

    Sensorplattform: Um die drei Sensoren in 2D messen zu lassen, musste etwas Drehbares her. Vorteil des Eigenbaus gegenüber einem fertigen Lidar (RPLidar z.B.): Ich kann mehrere Sensoren mit vollständiger 360°.Rundumsicht auf dem Drehteller zusammenstellen, ohne dass sie sich gegenseitig die Sicht einschränken. So misst das LidarLite bei mir in horizontaler Ebene die Umgebung, der VL53L1X, leicht nach unten geneigt, im Nahfeld niedrige Hindernisse unterhalb vom LidarLite. Der TSOP detektiert das Leuchtfeuer der Ladestation.

    Brain: Für mich ein Rechner, auf der die GUI-Applikation läuft. Zum Entwickeln ein PC oder Notebook, zum Testen (hinterherdackeln in BT-Reichweite) ein Tablet, on Board ein Banana Pi M2 Zero (Formfaktor Rasperry ZeroW, aber mit Quadcore). Lose angekoppelt über Bluetooth sind die Brains quasi per Knopfdruck austauschbar. Der OnBoard-Brain lässt sich in Wifi-Reichweite per RemoteDesktop oder Browser (NodeJS) bedienen. Die Funktion des "autark fahrens" benötigt diese Verbindung nicht (OnBoard ist die benötigte Reichweite zwischen Brain und Peripherie immer 10cm).

    Ende der Modulbeschreibung. Jetzt kommen einige spezielle Anmerkungen:

    Zum Vergleich: Im Wiki-Artikel über den RP6 sind im Kapitel Sensorik ALLE Sinne aufgeführt, auch z.B. das Monitoring von Akkuspannung, Odometrie, ... Das betrachte ich nicht so. In modularer Bauweise kann ich mir den Luxus erlauben, die interne Sensorik eines Moduls zu kapseln. Inkrementalgeber an Antriebsrädern werden im DriveModul zur Pose transformiert, AD-Werte im Powermodul werden maximal noch im langsamen Zyklus als Monitoring-Werte zur GUI gereicht. Also: Wenn ich von Sensoren spreche, meine ich die nach extern gerichtete Sensorik mit Hardwarebezug (! Eine Kamera kann man auch noch direkt am Brain anstöpseln).

    Der Leim, der die Module zusammenhält, besteht bei mir aus UART-Schnittstellen und einem über alle Ebenen gehenden Protokoll. Alternativ wäre ein Bus (I2C,CAN,...) denkbar, dann aber ist die Schnittstelle zum Brain eine Sonderlocke. So, wie ich es ausgeführt habe, sind die Module auch direkt mit dem Brain kompatibel (ich habe auf den Modulen einfach eine optionale vierpolige Buchsenleiste für einen HC-06-Baustein drauf). Ich kann also unabhängig vom Rest z.B. ein neues Sensorsetup bauen und in der Applikation auch schon Teile testen.
    Das verwendete Protokoll basiert auf der Übertragung von strukturbasierten Telegrammen. Bsp:
    Code:
    typedef struct
    	{
            uint8_t CmdID; //0
            double Diameter; //1
            double WheelDiameter;  //5
            double WheelStepsPerRound;  //9
    	double WheelDistance;//13
    	}__attribute__ ((packed)) PhysicsParams_t;
    So etwas (in diesem Fall ein Hilfsparametersatz aus dem EEPROM der Peripherie zur Berechnung der Pose aus den Daten der Inkrementalgeber) lässt sich bei mir vom Sender auf den Schreib-FIFO einer UART legen oder vom Empfänger aus dem Lese-FIFO anhand des CmdID-Feldes identifizieren, casten und weiterverarbeiten.

    Durchreiche: Kommt ein Messwerttelegramm von der Sensorplattform zur Peripherie, werden Winkel des Drehtellers und Korrekturparameter (z.B. die Sensorplattform selbst sitzt nicht mittig auf dem Roboter und es müssen X/Y-Offsets aufgeschlagen werden) sowie die aktuelle Pose des Roboters (aus dem DriveModule) ergänzt. Danach wird dieses ergänzte Telegramm zum Brain gesendet. Andere Telegrammtypen können auch einfach durchgereicht werden (z.B. wird die vom Brain versendete Struktur zum Setzen von Ladeparametern uninterpretiert an das Powermodul weitergereicht).


    Bezüglich der Applikation auf dem Brain: Das Zauberwort SLAM (Simultaneous Localization And Mapping) lässt sich im Rahmen einer Simulation recht schnell nachvollziehen. Der steinige Weg, eine Hardware dafür zu entwickeln, ist zwar das Ziel, aber kein Garant für den Erfolg. Ich habe mir also die Mühe gemacht, die Aplikation so aufzubauen, dass Experimente in Richtung SLAM aus drei unterschiedlichen "Welten" mit Daten gefüttert werden können:
    - Die RealWorld ist die API zur tatsächlichen Hardware. Neben der Schnittstelle zum SLAM-Algorithmus sind hier auch Diagnose- und Parametrierungswerkzeuge in Richtung Hardware implementiert.
    - SimulationWord generiert aus Polygondefinitionen eine virtuelle Umgebung und bildet die typischen Bewegungen und Messungen eines einfachen Roboters mit Lidar und Bumpern nach. Messwert- oder Bewegungsfehler können simuliert werden.
    - FileRecordWorld spielt in der RealWorld aufgezeichnete Testfahrten ab. Damit werden auch offline Datenanalysen oder Tests möglich.
    Ich denke mal, ROS ist ähnlich strukturiert. Im Gegensatz zu ROS ist meine Applikation in C# geschrieben. Vordergründig erst einmal für Windows entwickelt, lässt sich diese GUI unter dem Mono-Framework auch mit Linux verwenden.

    Ich hoffe, ich habe meinen Rahmen so zumindest grob, aber vollständig umschrieben. (Ich bin sicher, ich habe zu viel geschrieben!)
    Mögen die Spiele nun also beginnen.
    Geändert von Holomino (07.11.2020 um 19:14 Uhr)

  2. #2
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    18.03.2018
    Beiträge
    2.643
    Hallo,


    finde ich zunächst mal gut, dass es doch so schnell was geworden ist, dass Du das hier so ausführlich rein setzt!
    Also erst mal großes Danke dafür!


    Zwar etwas schwer zu verstehen, wenn man nicht in der Materie drin steckt, aber ich kann den Rahmen erkennen.


    Ich weiß, dass andere wieder Vorschläge haben (werden).


    Ich habe auch meine eigene Vorstellung, wie mein Roboter mal funktionieren soll. Ich gehe dabei sicher ähnlich,
    aber wieder anders vor. Mein Gedankengerüst auf dieses Modell zu übertragen, fällt mir eher schwer.




    Ich versuche mal ein Brainstorming:


    aufkommende Fragen:
    - Programmierwerkzeuge und welche Programmierumgebung ist notwendig
    - worauf ist die Software lauffähig, benötigte Hardware (Mindestanforderungen)
    - wie lässt sich die Software weiter entwickeln


    was ich mir vorstellen könnte (Wünsche):
    - Softwareausführung möglichst lauffähig auf vielen Geräten (Desktop-Computer, Mikrocomputer, Betriebssystem egal)
    - einfach, leicht zu bedienen = kurze Einarbeitungszeit
    - benötigte Hardware: alles was gängig ist an AVR bzw. favorisieren würde ich die Arduino-Serie (ab Nanao aufwärts) und die ESP für WIFI
    - Programmierungebung wäre hier Arduino - IDE in C++, mit allem, was es dazu gibt und geben wird


    Protokolle / Datenverbindungen:
    - UART/Serial, I2C


    Speicher erweiterbar:
    - SD-Karte, Filesystem(?), Speichergröße (ESP)?




    - Hardwaremodule?




    Anzumerken ist, dass jeder, aufgrund dessen, was er bisher gebaut hat oder noch baut, irgendwie vorbelastet ist.
    Deswegen könnten wir jetzt alle unsere Ideen in relativer Kurzform vorbringen? Holmino war nun recht ausführlich, das muss ich nicht noch mal machen,
    habe an anderer Stelle schon sehr viel geschrieben, was ich zurzeit mache. Inkas Vorhaben kennen hier eigentlich auch alle.


    Vielleicht finden sich noch mehr und wir sammeln, was jedem so einfällt?



    Freundlichen Gruß

  3. #3
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    27.12.2017
    Beiträge
    165
    Ich denke auch schon längere Zeit über einen DIY-Robi nach. Zuerst dachte ich an einen R2D2 ähnlichen Robi, wie im Droidbuilders-Portal ein paar mal beschrieben. Ich hatte mir auch die R2D2s der Astroch-Mechs auf der MakerFair in Dortmind angeschaut und kann dazu nur eins sagen: Respekt! Das sind klasse Show-Roboter für Events, aber nichts für mich, denn ich will eine Art technische Versuchsplattform.

    Daraus resultiert Anforderung 1: Das Teil soll eine technische Experimentierplattform sein, d.h. modular erweiterbar. Ich möchte alle möglichen Sensoren darauf montieren können, u.a. auch in einem drehbaren Turm, um zum Beispiel Geräusche mit einem Mikrofon-Array orten zu können

    Da wir ein eigenes Haus haben, soll das Teil auch überall hin können. Es muss sich also auch über Treppen fortbewegen können. Deshalb schaue ich mir gerade die openDog V1-Videos von James-Bruton (https://youtu.be/0BoPoWF_FwY). Das Ding ist schon gut gemacht, aber heftig teuer: 12 Motoren á 80€ + 12 Kugelumlaufspindeln á 50 € + 12 Motor-Regler á 40€ + (vermutlich) 500€ für die Profile und Zubehör + ganz viele selbst gedruckte Teile + .... Bevor das Teil vor einem steht, hat man ganz sicherlich irgendwas oberhalb von 3000€ verbraten! Dennoch finde ich das Teil irgendwie cool. Aber mit 6 Beinen würde mir so etaws besser gefallen. Die Größe finde ich aber OK und das Teil ist Mega-Stabil!

    Daraus resultiert Anforderung 2: Das Teil soll Treppen auf- und absteigen können. Das ist schon eine heftige Anforderung, auch wegen der Programmierung und Erkennung von Treppen.

    Anforderung 3 wurde von Holomino schon genannt: Autarkes operieren.

    Anforderung 4: Kommunikation. Der Robi soll mich z.B. per Email oder SMS anfunken, wenn etwas im Haus ist, wie eine Alarmanlage. Bedeutet: Das Teil muss einen WLAN-Adapter haben, denn Robis mit Kabel sind uncool. Der Robi soll auch eine Verbindung ins Internet haben, um mir z.B. Spotify abzuspielen --> Gute Lautsprecher!

    Anforderung 5 wurde auch schon von Holomino genannt: Der Robi soll selbst zur Ladestation finden und sich selbst laden, wenn die Batterie leer läuft.

    Als Steuerungsplattform habe ich mir einen zentralen RasPi gedacht, der diverse Module (Arduinos, andere RasPis) ansteuert. Jedes Modul (Mikrofon-Array, Kameras, Fortbewegung, etc.) soll seinen eigenen Computer haben.

    Als Programmiersprache habe ich mir Python gedacht, da Python einfach, plattformübergreifend und universell ist. Außerdem kann man Java- und C-Libraries einbinden. Im letzten Jahrtausend hatte ich ab und an mal C und viele andere Sprachen programmiert, je nachdem, was gerade angesagt war. Somit stelle ich mir den Einstieg in Python nicht besonders schwer vor. Die Entwicklungsumgebung ist mir egal, solange sie Offline funktioniert und kein Vermögen kostet, am liebsten Open Source, damit ich keine Rücksicht auf irgendwelche Einschränkungen des Herstellers nehmen muss.

    Wie denkt ihr darüber?


    Gruß, Jürgen

  4. #4
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    18.03.2018
    Beiträge
    2.643
    Vielleicht solltest Du Dich mit einem Hexapod-Robotern auseinander setzen? Wenn Dir das andere zu teuer ist, die Zeit zum Bau ist ja auch noch nicht eingerechnet.
    Beim Hexapod kommst Du bei 18 Motoren eventuell auf 1000€, wenn Du keine Micro-Servos einsetzt. Um 20cm Stufenhöhe zu schaffen, sollte das Gerät aber auch nicht zu klein sein. Und da kommst Du an den Punkt, dass Du eher einen kleinen Roboter möchtest. Baust Du einen mit Ketten, der eine Treppe rauf fahren kann, muss der auch eine bestimmte Größe haben. Vielleicht ist ein Flugmodell, das auch fährt, dann eher was, um die Baugröße zu reduzieren. Allerdings wirst Du dann auch hier eine gewisse Größe haben müssen, um das Gewicht von wenigstens 2kg bis 3kg zu stemmen.

    MfG

  5. #5
    Erfahrener Benutzer Roboter Genie Avatar von White_Fox
    Registriert seit
    04.10.2011
    Beiträge
    1.473
    Mir fehlt grundsätzlich etwas der rote Faden: Was soll das Konstrukt am Ende -- so in Etwa -- können?

    Modularisierung ist schön, gut und hilfreich - keine Frage. Aber da gibt es normalerweise einen sehr eng gesteckten Rahmen.
    Es soll beispielsweise am Ende auf jeden Fall ein Auto werden, die Autos sind alle irgendwie ähnlich und unterscheiden sich nur marginal: Alle haben einen Motor, alle haben ein elektronisches Unterhaltungsystem, alle haben vier Räder. Alle haben an jedem Rad eine Bremse, alle werden an derselben Achse angetrieben. Und alle Autos sind normale Straßenautos.

    Man kriegt aus diesem Baukastensystem nie und nimmer ein Schiff oder ein Fluggerät zusammengeschraubt. Und auch keinen Panzer. Man kriegt nichtmal ein richtiges Rennauto oder etwas anständig Geländegängiges damit hin.

    Modularisierung ist fast immer auch nur dann von Vorteil, wenn man in größeren Stückzahlen baut und entwickelt. Modularisierung bedeutet auch, technisch niemals die Anforderungen zu treffen, sondern durch die Modularisierungsforderung gibt es zusätzlich Einschnitte. Seien es z.B. ungenutzte Leitungen im Kabelbaum, eigentlich falsch gewählte Kommunikationsprotokolle (z.B. CAN für Daten, die eigentlich höhere Echtzeitanforderungen hätten) oder dergleichen.

    Für Einzelstücke gibt es da kaum Vorteile. Höchstens, wenn man mehrere hinreichend ähnliche Sachen hin und wieder baut.

    Die Frage wäre: Soll es jetzt ein Roboterarm werden, oder doch ein USV? Modularisieren kann man alles, und wenn man es auf Bauteilebene herunterbricht.

  6. #6
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    07.04.2015
    Beiträge
    865
    Zitat Zitat von jmoors Beitrag anzeigen
    Wie denkt ihr darüber?
    Ich denke, Du solltest mindestens noch einen Arm zum Bedienen von Türklinken einplanen.

  7. #7
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    27.12.2017
    Beiträge
    165
    Modularisierung bedeutet für mich wieder verwertbare Komponenten zu haben, die ich auf verschiedenen Plattformen einsetzen kann. Z.B. wenn jemand mein Peilturm mit Kameras, Mikrofon-Array, usw., gefällt, setzt er diesen vielleicht auf ein funkferngesteuertes Auto.

    Ich verstehe diesen Thread so, dass er die Konstruktion von anderen Threads anstößt, die jeweils ein Modul repräsentieren. Ein Modul kann ein fahrbare Basis auf Rädern, 2-, 4- oder 6 Beinen sein, ein Modul zur Erfassung der radioaktiven Strahlung, usw. Deswegen ist es wichtig, die Komponente von außen steuerbar zu machen, d.h. eine sauber definierte und dokumentierte Schnittstelle zu haben.

    Als zentrale Komponente schwebt mir, wie schon oben erwähnt, ein RasPi vor, da es ein ausgewachsener Computer ist. Was geht euch dazu im Kopf herum?


    VG, Jürgen

  8. #8
    Erfahrener Benutzer Robotik Einstein Avatar von inka
    Registriert seit
    29.10.2006
    Ort
    nahe Dresden
    Alter
    76
    Beiträge
    2.180
    Zitat Zitat von jmoors Beitrag anzeigen
    Als zentrale Komponente schwebt mir, wie schon oben erwähnt, ein RasPi vor, da es ein ausgewachsener Computer ist. Was geht euch dazu im Kopf herum?
    ich hatte zunächst nur einen atmega 2560 im outdoor drin, der wurde nun zum fahrdienstleiter mit hinderniserkennung "degradiert" und ein zero-w ist erstmal als head vorgesehen...

    ansonsten hatte ich bei meinen bisherigen robotern diese funktionen:

    - experimentiershield als verdrahtung und anschlussmodul
    - US-hinderniserkennung
    - IR-linienfolgemodul
    - induktive ladevorrintung
    - BT-modul zur kommunikation mit der umwelt
    - IR-modul zum fernbedienen
    - gyro-modul zur positionsbestimmung

    die module/sensoren waren eingebaut und funktionierten auch, die weiterentwicklung bzw. verfeinerung der nutzung ist ausgeblieben, weil - das kennt wahrscheinlich jeder hier - was neues gebaut wurde. Also kein spezialist in verwendung dieser module, höchstens "reingerochen" in die verwendeung...
    gruß inka

  9. #9
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    07.04.2015
    Beiträge
    865
    Zitat Zitat von jmoors Beitrag anzeigen
    Ich verstehe diesen Thread so, dass er die Konstruktion von anderen Threads anstößt, die jeweils ein Modul repräsentieren. Ein Modul kann ein fahrbare Basis auf Rädern, 2-, 4- oder 6 Beinen sein, ein Modul zur Erfassung der radioaktiven Strahlung, usw. Deswegen ist es wichtig, die Komponente von außen steuerbar zu machen, d.h. eine sauber definierte und dokumentierte Schnittstelle zu haben.
    Das ist mittlerweile auch so mein Gedanke. Ich habe mich vor zwei Jahren ehrlich gesagt dumm und dusselig nach einer griffigen und vollständigen Lösung für die simple Funktion des automatischen Ladens gesucht. Letztlich habe ich die fünf Versionen bis zum endgültigen Ziel alleine durchgezogen.
    Zumindest bei Moppi weiß ich aus einem älteren Thread, dass er das noch vor sich hat.
    Bei anderen weiß ich's nicht, hab's aber auch schon mal (hier und hier, und auch der hier gehört eigentlich noch dazu) probiert.

    Jetzt könnte ich so was mal anstoßen weil ich etwas in den Händen habe.
    Geändert von Holomino (08.11.2020 um 16:41 Uhr)

  10. #10
    Benutzer Stammmitglied Avatar von Gerdchen
    Registriert seit
    09.11.2006
    Beiträge
    98
    Zitat Zitat von jmoors Beitrag anzeigen

    Daraus resultiert Anforderung 1: Das Teil soll eine technische Experimentierplattform sein, d.h. modular erweiterbar. Ich möchte alle möglichen Sensoren darauf montieren können, u.a. auch in einem drehbaren Turm, um zum Beispiel Geräusche mit einem Mikrofon-Array orten zu können

    Da wir ein eigenes Haus haben, soll das Teil auch überall hin können. Es muss sich also auch über Treppen fortbewegen können.

    Daraus resultiert Anforderung 2: Das Teil soll Treppen auf- und absteigen können. Das ist schon eine heftige Anforderung, auch wegen der Programmierung und Erkennung von Treppen.

    Wie denkt ihr darüber?

    Gruß, Jürgen
    Mir gefallen die Konzepte dieser beiden Rover/Roboter, besonders auch wegen der unabhängig verstellbaren Fahrwerksbeine mittels Spindelantrieb. Dadurch könnte sogar eine gewisse Treppensteigfähigkeit erreicht werden. Obendrauf ein Manipulator, oder was anderes. Als technische Experimentierplattform eventuell eine Überlegung wert. Auch der konstruktive Aufwand erscheint machbar.

    https://robotik.dfki-bremen.de/uploa..._Sherpa_de.pdf
    https://robotik.dfki-bremen.de/uploa...herpaTT_de.pdf

    Gerdchen

Seite 1 von 11 123 ... LetzteLetzte

Ähnliche Themen

  1. Roccat Nyth im Test: Die 130-Euro-Modular-Daumentasten-Gaming-Maus
    Von Roboternetz-News im Forum Neuigkeiten / Technik-News / Nachrichten / Aktuelles
    Antworten: 0
    Letzter Beitrag: 01.10.2015, 10:10
  2. ROV-CONTROL - a modular control system for diving robots
    Von Diron im Forum Sonstige Roboter- und artverwandte Modelle
    Antworten: 0
    Letzter Beitrag: 03.02.2015, 23:58
  3. Atmel Studio modular Programmieren
    Von Che Guevara im Forum C - Programmierung (GCC u.a.)
    Antworten: 4
    Letzter Beitrag: 12.06.2014, 00:48
  4. Kennt ihr MTRAN3 Modular Robot?
    Von Sergetg im Forum Allgemeines zum Thema Roboter / Modellbau
    Antworten: 0
    Letzter Beitrag: 09.11.2009, 15:46
  5. Modular, shape-shifting robots
    Von johns im Forum Vorstellungen+Bilder von fertigen Projekten/Bots
    Antworten: 3
    Letzter Beitrag: 01.05.2008, 10:40

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

LiTime Speicher und Akkus