- 3D-Druck Einstieg und Tipps         
Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 18

Thema: LUISE - LUftInhalierendes Saug Experiment (Saugroboter)

  1. #1
    Neuer Benutzer Öfters hier
    Registriert seit
    31.03.2009
    Beiträge
    17

    LUISE - LUftInhalierendes Saug Experiment (Saugroboter)

    Anzeige

    Powerstation Test
    Liebes Forum,
    ich wollte Euch an meinem Projekt LUISE beteiligen. Luise, weil es mit den autonomen Roboter ja ein ach so weites Feld ist.

    Luise soll autonom meine Wohnung saugen. Es gibt hier keine Türen aber große Flächen - ein Fall für Luise.

    Luise soll mit einem handelsüblichen Staubsauger ca. 1800 W ausgestattet sein, kein Akku, sondern ein Schleppkabel - evtl. mit einem mehr oder weniger inteligentem Kabelaufrollmechanismus.

    Die innovative Idee ist bei Luise die Raumorientierung: Luise ist mit einer IR-empfindlichen Webcam ausgestattet. Weil Luise auch mit kräftigen IR-LED Strahlern ausgestattet ist, kann sie (auch bei Dunkelheit) an der Decke klebene "fiducials" aus dem Sourgeforgeprojekt "ReacTIVision" erkennen.

    Die ReacTIVision-Engine funktioniert auf allen Plattformen ziemlich gut. Sie ist ursprünglich gedacht über Lichttische Synthesizer zu bedienen.
    Der Output ist ein TUIO-Stream über das Netzwerk, dass neben der ID (es gibt über 200 Stück) des fiducials auch dessen Position im Kamerablickfeld und dessen "Verdrehung" ausgibt. Ich finde sehr vielversprechende Voraussetzungen für eine ordentliche Lokalisierung.

    Die Nahorientierung und Hindernisserkennung soll Luise mit einem Sick Laserscanner bewerkstelligen.

    Mechanisch besteht Luise in erster Linie aus einem Brett, auf dem der Staubsauger, die Rechenmaschinen, die Netzteile, die Schleppkabelwickel und der Sick aufgeschraubt sind. Rechts und links hinten sind zwei Scheibenwischermotoren angebracht. Vorn stützt eine drehbare Rolle.

    Luise - Luise - das ist ein weites Feld... die angestrebte Autonomie soll Luise in Modulen erhalten: Ein ITX-Mainboard mit WLAN steht im Zentrum. Ein Arduino übernimmt die Motorik. Ein MD22 sorgt für die Kraft.

    Als ich vor ca. drei Wochen mit dem Projekt begann, war mir bei weitem nicht klar, dass jeder Minischritt von so grossen Problemen begleitet ist. Deshalb möchte ich mit Luise jetzt in dieses Forum treten, in der Hoffnung konstruktive Kritiker und mitfühlende Begleiter zu finden.
    Miniaturansichten angehängter Grafiken Miniaturansichten angehängter Grafiken cimg0001.jpg  

  2. #2
    Neuer Benutzer Öfters hier
    Registriert seit
    31.03.2009
    Beiträge
    17

    Probleme - die erste

    Beim Mainboard gingen die Probleme schon los:
    1. die SATA Notbookplatte Toshiba MK1652GSX, die extra wegen dem SATA gekauft habe wurde vom Mainboard VIA Epia SP-13000 nicht erkannt. Musste dann noch einen SATA-IDE Converter kaufen. Das Epia hatte ich mir ausgesucht, weil es alle möglichen Anschlüsse hat. Sogar I2C (SMBus), Firewire, seriell, parallel und natuerlich USB.
    2. die Webcam Speedlink VAD Laplace versprach eine echte HD-Auflösung im Videomodus - aber es gibt ausschliesslich Treiber für Windows. Eigendlich wollte ich alles auf Linux laufen lassen - grrr.
    Als Workarround habe ich dann XP installiert und dortdrin dann mit SUNs VirtualBox ein Debian Lenny.
    3. Der Billig WLAN-Stick den ich eigendlich einsetzen wollte, liess sich aber nicht durch VirtualBox auf Windows bridgen, so dass ich auf die D-Link DWL-G520 ausgewichen bin. Dies bereue ich aber überhaupt nicht, weil die echt super stabil mit Top-Übertragungsraten sowohl unter Windows als auch Linux glänzt.
    4. Weil Luise ja keinen Moni oder Tastatur haben soll, wurde auf dem XP der RemoteDesktop freigegeben und die IP aus dem WLAN-Netz fest vergeben.
    5. Die nächste Schwierigkeit war, die VirtualBox als Windowsdienst zu starten, damit auch die LinuxLuise automatisch am Start ist.
    6. Nachdem dies klappte, begab ich mich auf die Suche nach einer Robotersoftware, die für mich einigermaßen verständlich war. Beim Installieren vom Mikrosoft freien Robotikkram und den sicher 10 Mikrosoftabhängigkeiten .... bin ich doch wieder dazu übergegangen mich auf mein vertrautes Linux zurückzukommen und entschied mich für Player/Stage.
    7. Leider braucht man zumindest für Stage eine grafische Oberfläche, die mein Konsolen Linux mit SSH-Zugriff nicht bot. So habe ich dann noch NoMashines NX Server auf dem Lenny installiert und mein erster DemoRobot konnte über WLAN auf meinem OSX Powerbook Bildschirm sein Labyrinth erkunden.

    Nebenbei habe ich auch versucht, den SMBus auf dem EPIA in Betrieb zu nehmen. Irgendwann habe ich auch ein paar Daten, die vom Mainboard bereitgestellt werden auf die WindowsKonsole bekommen, das Schreiben allerdings hat überhaupt nicht hingehauen: entweder passiert nix oder der Rechner friert ein. Falls an dem Punkt jemand noch Tipps hat, wäre ich dankbar.


    Diese Apt-Pakete mussten nach der reinen Lenny-Basis-Installation installiert werden:
    • ---- basic ---
      ssh
      apt-file
      ---- develop ---
      linux-libc-dev
      subversion
      GCC
      bzip2
      g++
      libglib2.0-0
      libncurses5-dev
      autoconf
      make
      libperl-dev
      libtool
      docbook
      kernel-package
      linux-source-2.6.26
      linux-headers-2.6.26-2-486
      libmpfr-dev
      gnat-4.3
      bison
      flex
      gcc-avr
      uisp
      avrdude
      avr-libc
      libftdi-dev
      texlive-base-bin
      texlive-latex-base
      texlive-latex-recommended
      ---- Desktop -----
      xorg
      gdm
      xfce4
      ---- nxserver ------
      libaudiofile0
      dpkg -i nxclient_3.3.0-6_i386.deb
      cups
      dpkg -i nxnode_3.3.0-17_i386.deb
      dpkg -i nxserver_3.3.0-22_i386.deb
      ---- carmen ----
      compile http://www.kvaser.com/cgi-bin/files/linuxcan.tar.gz
      libgtk1.2-dev
      libreadline5-dev
      libgtk2.0-dev
      gdk-imlib11-dev
      libwrap0-dev
      imagemagick
      libmagick9-dev
      java-common
      sun-java6-bin
      sun-java6-jre
      sun-java6-jdk
      ant
      doxygen
      swig
      compile carmen
    Miniaturansichten angehängter Grafiken Miniaturansichten angehängter Grafiken cimg0002.jpg  

  3. #3
    Neuer Benutzer Öfters hier
    Registriert seit
    31.03.2009
    Beiträge
    17

    Probleme 2

    Lange Zeit habe ich auch damit verbracht, den ReaTIVision Engine dazu zu bringen, auch als Dienst unter Windows zu starten, was mir noch nicht gelungen ist, weil die unbedingt auf einen Desktop will. Wenn ich remote angemeldet bin, gibt es keine Probleme. Ausserdem habe ich mich schwergetan, das die Engine ihre TUIO Daten an die VirtualBox statt auf den Localhost schickt, bis ich dann die IP der vBox hardgecodet in den Sourcen eingetrage und neu kompliert habe. Danach habe ich dann allerdings das XML-File zur Konfiguration entdeckt, womit das wohl einfacher gewesen wäre.
    Als ich dann die TUIO-Daten mit TUIODump zuverlässig auf der Konsole hatte, habe ich mich erstmal wieder der Hardware zugewendet.

    Ich wollte aus der Webcam gern den IR-wegfilternden Filter ausbauen und dann einen nur IR-durchlassenden Filter einbauen, damit die Erkennungsrate von ReacTIVision verbessert wird. Leider habe ich beim Rumpulen mit dem Teppichmesser einen dicken Kratzer auf das Winz-Objektiv bekommen, aber die Engine erkennt zwar schlechter als bisher, aber immer noch die Fiducials, die im übrigen auch unter der Zimmerdecke recht dekorativ sind.
    Miniaturansichten angehängter Grafiken Miniaturansichten angehängter Grafiken cimg0007.jpg  

  4. #4
    Neuer Benutzer Öfters hier
    Registriert seit
    31.03.2009
    Beiträge
    17

    Probleme 3

    Zur Entspannung, glaubte ich, bin ich dann an meinen Arduino, dem ich die folgende Funtion zuweisen wollte:
    Empfange seriell den Befehl "gehe x cm y Grad". Er soll dann die Motoren selbständig steuern und in regelmäßigen Abständen auch seriell "z % erlegigt" zurückgeben. Beispiel: gehe(100,0) wäre 1Meter geradeaus. gehe(0,90) -> dreht 90° rechtsrum auf der Stelle. gehe(-50,-180) -> Fährt einen 0,5 Meter langen Kreisbogen rückwärts linksrum.
    Er soll ausserdem noch auf einen "notstop" Befehl reagieren, bei dem beide Motoren auf der Stelle angehalten werden.
    Der Motortreiber MD22 kann analog, i2c-seriell und über PWM angesprochen werden. Ich dachte "bleibe ich doch solang wie möglich digital" und habe mich auf den I2C bus konzentriert und wäre fast verzweifel, weil nichts ging. Zum Glück bin ich gestern abend noch auf einer Webseite auf ein Script gestossen, in dem eine andere Basis-Adresse verwendet wurde. Entgegen aller Beschreibungen und Manuals hört der MD22 rev.10 NICHT auf 0xB0, sondern auf 0x58. Dann klappts auch mit den Nachbarn.

    Gestern und heute schliesslich, sollte der Odometer ausprobiert werden. Bei Pollin gabs für ein paar Cent die IR-Gabel TCYS5201 mit Schmitt-Trigger Ausgang. Die dann an meinen Arduino angeschlossen und als Interrupttrigger verwendet. Bei LOW alles supi, aber bei HIGH zählte mein Arduino in ein paar Sekunden so viele Ticks, dass er übergelaufen steckenblieb. Erst dachte ich, die Verwendung von externen Interrupts sei vielleicht gar nicht gleichzeitig mit Serial.begin möglich, weil dort ja auch Interrupts ausgelöst wurden. Aber wer liest ist klar im Vorteil: im Datenblatt der Gabel wird empfohlen, einen Kondensator möglichst nah am Sensor zwischen VCC und GRD zu legen und dann zählte mein Ardu wie gewünscht.

    Code:
     /******************************************************************************
     *  Luises - Motorsteuerung  - erste Erfolge
     *  Arduino analog input 5 - I2C SCL
     *  Arduino analog input 4 - I2C SDA
     *  Arne Groh 2009-04-03
     * ******************************************************************************/
    #include <WString.h>
    #include <Wire.h>
    
    
    volatile unsigned int LeftEncoderTick = 0;
    int l_enc_v0 = 12;
    int left_speed = 60;
    int right_speed = 128;
    int incomingByte = 0;	// for incoming serial data
    int revision;
    int mot1;
    int mot2;
    int accel;
    
    
    #define md22Address 0x58  // !! NOT 0xB0 !!
    
    void setup() {
      pinMode(l_enc_v0, OUTPUT);
      digitalWrite(l_enc_v0, HIGH);
      Wire.begin(0x53);       // Host Address
      Wire.beginTransmission(md22Address);       // MD22 Address (All Switches ON = 0x58)
      Wire.send(0x00);                           // Set Register 0 (Mode)
      Wire.send(0x00);                           // Send Data Mode to 0 (0 to 255)
      Wire.endTransmission();  
      Wire.beginTransmission(md22Address);       // MD22 Address (All Switches ON = 0x58)
      Wire.send(0x03);                            // Register of Acceleration
      Wire.send(128);                            // Send Data for Acceleration
      Wire.endTransmission();  
    
      readMD22();
      attachInterrupt(0, LeftEncoderEvent, HIGH);
      Serial.begin(9600);
      write_MD22();
    }
    
    
    void loop() {
    readSpeed();
    delay(10);
    }
    
    void write_MD22(){ 
       Wire.beginTransmission(md22Address);       // MD22 Address (All Switches ON = 0x58)
       Wire.send(0x01);                            // Register of Motor 1
       Wire.send(left_speed);                            // Send Data for left Motor(1) Speed (0 = Full Reverse | 128 = Stop | 255 = Full Forward)
       Wire.send(right_speed);                            // Send Data for right Motor(2) Speed
       Wire.endTransmission();
    }
    
    
    void readSpeed(){
      if (Serial.available() > 0){
        char string[8] = "       "; // declare string variable
        for (int i = 0; i < 7; i++){
          if (Serial.available() > 0)                 // send data only when you receive data:
            {string[i] = Serial.read();}
        }
        String sstring = String(string);
        String l_string = sstring.substring(0, 3);
        String r_string = sstring.substring(4, 7);
        left_speed = (atoi(l_string));
        right_speed = (atoi(r_string));
        write_MD22();
        printmessage();
      }
    }
    
    void readMD22(){                              // Reads Data from MD22
      Wire.beginTransmission(md22Address);        // Calles software register
      Wire.send(0x07);                            // Register of SoftwareRevision
      Wire.endTransmission();
      Wire.requestFrom(md22Address, 1);           // Requests one byte
      while(Wire.available() < 1);                // Wait for it to arrive
      revision = Wire.receive();              // Get byte
      
      Wire.beginTransmission(md22Address);        // Calles software register
      Wire.send(0x01);                            // Register of Motor 1
      Wire.endTransmission();
      Wire.requestFrom(md22Address, 1);           // Requests one byte
      while(Wire.available() < 1);                // Wait for it to arrive
      mot1 = Wire.receive();                  // Get byte
      
      Wire.beginTransmission(md22Address);
      Wire.send(0x02);                            // Register of Motor 2
      Wire.endTransmission();
      Wire.requestFrom(md22Address, 1);           // Requests one byte
      while(Wire.available() < 1);                // Wait for it to arrive
      mot2 = Wire.receive();                  // Get byte
      
      Wire.beginTransmission(md22Address);
      Wire.send(0x03);                            // Register of Acceleration
      Wire.endTransmission();
      Wire.requestFrom(md22Address, 1);           // Requests one byte
      while(Wire.available() < 1);                // Wait for it to arrive
      accel = Wire.receive();                 // Get byte
    
       
      
    }
    
    void LeftEncoderEvent(){
        LeftEncoderTick++;
      }
    
    void printmessage(){
      readMD22();
      Serial.print("MD22-Ver: ");                 // Print to Serial
      Serial.print(revision);
      
      Serial.print(" | Current Mot 1 Speed: ");
      Serial.print(mot1);
      
      Serial.print(" | Current Mot 2 Speed: ");
      Serial.print(mot2);
      
      Serial.print(" | Current Accel: ");
      Serial.print(accel);                      // Print to serial and CR
      
      Serial.print(" | LeftEncoderTick: ");
      Serial.println(LeftEncoderTick);                 
    }
    Als nächstes werde ich versuchen, meine Trigonometrie-Erinnerungen aufzufrischen, um die Kursumsetzung zu implementieren. Ich hatte anfangs mit dem Gedanken gespielt, hier einen PID-Regler einzusetzen, aber ich verstehe nicht wirklich, was der treibt...
    Miniaturansichten angehängter Grafiken Miniaturansichten angehängter Grafiken cimg0006.jpg   cimg0004.jpg  

  5. #5
    Moderator Robotik Einstein Avatar von HannoHupmann
    Registriert seit
    19.11.2005
    Ort
    München
    Alter
    41
    Beiträge
    4.534
    Blog-Einträge
    1
    Ich hätte ja statt des ITX Boards ein klassisches Embedded Linux Board verwendet. Komm natürlich darauf, weil ich gerade mit sowas arbeit bzw. mich in ner Vorlesung damit beschäftige.

    Das NGW100 welches wir verwenden, zickt zwar gerade noch etwas rum bei mir, da ich Linux bisher nur als VMware betreibe und es da wohl Probleme mit dem Auflösen des DHCP Servers gibt. Das Potential dieser Boards ist aber sehr interessant und zukunftsträchtig.

  6. #6
    Neuer Benutzer Öfters hier
    Registriert seit
    31.03.2009
    Beiträge
    17

    Der Sick

    Mitte letzter Woche kam der bei Ebay ersteigerte Sick PLS 101-312 an. Nachdem ich gepeilt hatte, das die seriellen Leitungen so angerschlossen werden:
    SICK Pin 5 GND -> PC Pin 5 GND
    SICK Pin 2 RXD -> PC Pin 3 TXD
    SICK Pin 3 TXD -> PC Pin 2 RXD
    konnte ich auch mit dem Sick -Konfigurationsprogramm auf meinen Laserscanner unter Windows zugreifen und konfigurieren.

    Die nächste Herausforderung war der Zugriff von Linux aus:
    Fast alle Beschreibungen und Tools aus dem Netz beziehen sich auf den Sick LMS und nicht auf den PLS (meistens wird gesagt, dass es keinen Unterschied gibt) - jedenfall ist mir der Zugriff (mit den LMS-Treibern) nicht direkt gelungen.
    Zuerst habe ich mit den Treibern von PlayerStage probiert. Dann mit der sicktoolbox-1.0, dann mit LMSdemo.c, danach stundenlang versucht DROS-0.98 zu kompellieren (ohne Erfolg). Versucht habe ich auch noch zaza und Aria. Leider konnte ich keinem dieser Programme einen Output meines Lasers entlocken.
    Schliesslich habe ich dann noch Carmen ausprobiert und habe mit diesen Einstellungen einem ersten Teilerfolg errungen (siehe Bild):
    Code:
    In der carmen/src/carmen.ini:
    
    [b21]
    
    base_type                  b21
    
    # laser parameters
    
    #laser_laser1_dev           /dev/cur60
    laser_front_laser_dev      /dev/ttyS0
    #laser_laser1_dev           /dev/ttyS0
    #laser_laser1_type          PLS
    laser_front_laser_type     PLS
    laser_front_laser_baud          38400
    laser_front_laser_resolution    0.5
    laser_front_laser_fov           180
    laser_front_laser_flipped       0
    laser_front_laser_use_remission  no     # none / direct / normalized
    
    laser_rear_laser_dev            none
    laser_laser2_dev            none
    laser_laser3_dev                none
    laser_laser4_dev                none
    laser_laser5_dev                none
    dann das Carmen-System starten mit diesen Befehlen:
    Code:
    l-robot-01:~/carmen-0.7.4-beta/bin# ./central &
    l-robot-01:~/carmen-0.7.4-beta/bin# ./param_daemon -r b21 ../data/freiburg.map &
    l-robot-01:~/carmen-0.7.4-beta/bin# ./laser &
    Der "laser" - Befehl hat glücklicheweise mit dieser Ausgabe geantwortet:
    Code:
    ###########################################
    INFO: select mode ..................... on
    INFO: LASER type ...................... PLS
    INFO: connect TTY /dev/ttyS0     ...... ok
    INFO: set port param   9600:8E1 ....... ok
    INFO: detect connected baudrate: ...... 9600
    INFO: set LASER in config-mode ........ ok
    INFO: set LASER baudrate to  38400 .... ok
    INFO: using remission mode ............ none
    INFO: start LASER continuous mode ..... ok
    ###########################################
    Daraufhin habe ich mich getraut, unter X den Befehl "laserview" aufzurufen und wurde mit dem anhängenden Laserscann belohnt.

    Das bisherige Fazit:
    Luise wird mit Carmen statt PlayerStage laufen!
    Miniaturansichten angehängter Grafiken Miniaturansichten angehängter Grafiken sick.jpg   laserview.jpg  

  7. #7
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    30.12.2008
    Beiträge
    1.427
    Das sieht wirklich super aus!
    ich hab mal ne frage wieviel geld hat der ganze spaß bisher gekostet? weiler mich doch schon ein bissel interessiert das mit dem schleppkabel gefällt mir persöhnlich got wenn es geht also nich verfitzen kann.
    mfg thomas

  8. #8
    Neuer Benutzer Öfters hier
    Registriert seit
    31.03.2009
    Beiträge
    17
    @Thomas$
    bin inzwischen bei etwa 400 Eus (nur für die Teile) über die Stunden schweige ich lieber - hätte damit sicher unsere Bude lebenslang gestaubsaugt halten können
    arne

  9. #9
    Neuer Benutzer Öfters hier
    Registriert seit
    31.03.2009
    Beiträge
    17

    neu Motoren

    Die alten Motoren liefen doch etwas schnell. Ausserdem erschienen mir die zuletzt verwendeten Räder zu "spackelig".

    Jetzt habe ich die ganz langsamen Pollin-Scheibenwischermotoren verwendet. Ausgerüstet mit Luftreifen, macht das Chassis jetzt einen soliden Eindruck.
    Miniaturansichten angehängter Grafiken Miniaturansichten angehängter Grafiken luise_chassis_217.jpg  

  10. #10
    Neuer Benutzer Öfters hier
    Registriert seit
    31.03.2009
    Beiträge
    17

    neue Odometrie Sensoren

    Mit den neuen Rädern hat Luise jetzt auch "Phase-Quadratur Encoder" erhalten. Dazu habe ich jeweils zwei Gabellichtschranken nebeneinander geklebt. Die neuen Encoderscheiben mussten dadurch etwas grober ausfallen. Sie haben jetzt pro Umdrehund nur noch 9 High/Low Phasen (die alten hatten 12). Dadurch kann Luise jetzt aber auch die Drehrichtung erkennen und die Encoder-Ticks bei Rückwärtsdrehungen wieder abziehen.

    Die Auswertung der Quadratursignale werde ich wahrscheinlich mit einer alten BasicStamp machen, von denen ich noch ein paar rumliegen habe. Bin im Netz auf einen prima Zusammenhang gestoßen, der im RN offensichtlich auch nicht betrachtet wurde:

    Code:
    von Scott Edwards
    
    0     1    3     2     0  state
    ----> ----> ----> ---->    CW
     
    0  _  1  _  1  _  0  _  0  B
      /     /     /     /                all 0->1 or 1->0
    0  -  0  -  1  -  1  -  0  A 
      
     
     
    0     1     3     2     0   state
     <---- <---- <---- <----    CCW
     
    0  _  1  _  1  _  0  _  0   B
        \     \     \     \      all 0->0 or 1->1
    0  -  0  -  1  -  1  -  0   A
    Es zeigt sich nämlich, dass wenn man die Übergänge der Statusänderungen der beiden Encoder betrachtet, bei der Vorwärtsfahrt der Status des einen Encoders vor der Änderung IMMER genau invers zu dem aktuellen des anderen ist.
    Bei der Rückwärtsfahrt sind die Zustände IMMER gleich.

    Dies ermöglicht eine simple XOR Auswertung bei gleichzeitiger Filterung von Signalen die sich nur auf einem "Tick" abspielen (Ruckel der Räder auf der Stelle).
    Miniaturansichten angehängter Grafiken Miniaturansichten angehängter Grafiken quad_odom.jpg  

Seite 1 von 2 12 LetzteLetzte

Berechtigungen

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

Solar Speicher und Akkus Tests