Inhalt

Mobile Roboterplattform: Mechanik

Basisplattform und Antrieb

Bei der Antriebsplattform habe ich mich für einen Raupenantrieb entschieden. Diesen habe ich mit Zahnriemenscheiben und Doppeltverzahnten Zahnriemen(T10) realisiert. Die Antriebs- und Umlenkwellen sind schlicht Kugelgelagert. Den Rahmen habe ich aus Aluminiumprofilen zusammengebaut.

Die mobile Roboterplattform im Aufbau

Als Antriebsmotoren für die Roboterplattform werden zwei 24V- Getriebemotoren mit eingebautem Impulsgeber zur Drehzahlmessung-/ -Regelung verwendet. Die Motoren  vom Typ EMG49 von Devantech sind mittels Klauenkupplungen mit den Antriebswellen verbunden und mittels zweier Aluminiumwinkel am Grundrahmen befestigt.

Technische Daten der Antriebsmotoren EMG49

Auf dem Grundgestell wurde dann eine Einhausung aus Aluminiumprofilen und -Blechen aufgebaut, die die bisherige Elektronik und Spannungsversorgung des Roboters beinhaltet.

Die mobile Roboterplattform im Aufbau

Mobile Roboterplattform: Elektronik

Im Bild oben ist der bisherige Aufbau der mobilen Roboterplattform schematisch skizziert

Einplatinencomputer pcDuino

Statt des Raspberry Pi verwende ich inzwischen den leistungsfähigeren Einplatinencomputer pcDuino3 als Rechner auf dem Roboter.

MAX232-5V-Pegelwandler (für MD49)

Wir können die serielle Schnittstelle des MD49 nicht ohne weiteres mit der des pcDuino verbinden, da der pcDuino 3,3V und das MD49-Board 5V als Betriebsspannung am jeweiligen UART führt. Deswegen setzten wir hier beidseitig einen Pegelwandler ein. Für das MD49 den MAX232-5V-Pegelwandler und für den pcDuino den MAX3232-3,3V-Pegelwandler. Die Schaltung und Platine habe ich mit der E-CAD Software Target3001 entworfen.

MAX3232-3,3V-Pegelwandler (für pcDuino)

Das Layout und PCB ist hier dasselbe, wie beimMAX232-5V-Pegelwandler. Auch von der Bestückung ist es annähern baugleich, nur ist bei der 3,3V-Version statt dem MAX232 der MAX3232 verbaut und statt den 10µF Elkos werden 1µF Elkos verwendet.

Motoransteuerung MD49

Als Motortreiber wird die Steuerplatine MD49 verwendet, es wird wie die Motoren von der Firma Devantech vertrieben. Die Ansteuerung erfolgt per serieller Schnittstelle und es ist geeignet für den Betrieb zweier EMG49-Motoren.

Die Eckdaten für diesen 24V 5A Dual H-Bridge Motortreiber:

• Kann Motor-Encoder auslesen und Daten für Strecken- und Richtungsberechnungen liefern
• Für 2 Motoren mit unabhängiger oder gemeinsamer Steuerung
• Arbeitsstromstärke des Motors lesbar
• 24V Stromversorgung erforderlich
• Lenkfuntion: Die Motoren lassen sich um vorgegeben Werte weiterdrehen
• Beschleunigungsfunktion
• Bietet Schutz vor Kurzschluss, zu starkem Strom oder falscher Spannung. Fehler-LED und Fehler-Byte Diagnose
• Die Motoren werden ausgeschaltet, wenn mehr als 2 Sekunden kein Befehl über die serielle Schnittstelle erhalten wurde. Dies fungiert als Schutz, falls die Ansteuerung versagt. Diese Funktion kann auch abgeschaltet werden
• Der MD49 ist dafür ausgelegt, an einem seriellen Bus mit TTL-Spannung (5V) bei 9600 oder 38400 baud betrieben zu werden, mit 1 oder 2 Stop-Bits. Auswahl der Baud-Rate erfolgt durch Jumper.

Link zur technischen Dokumentation MD49

Spannungsversorgung Antriebe und Antriebsregelung

Als Spannungsversorgung für die Antriebe und die Antriebsregelung verwende ich zwei 12V-Bleigel-Akkus, die in Reihe geschalten die nötigen 24V für Antriebe und Antriebsregelung bereitstellen.

Spannungsversorgung pcDuino3 und Steuerelektronik

Als Spannungsversorgung für den Einplatinencomputer und alle anderen 5V- Komponenten verwende ich eine 5V Powerbank mit 19,6 Ah

Die Elektronik der mobilen Roboterplattform im Aufbau

Arduino am pcDuino

Für weitere Mess- und Regelaufgaben, z.B. die Auswertung der Akkuspannung und den Anschluss weiterer Sensorik und Aktorik für den Roboter sollen Mikrokontrollerboards auf Basis des Arduinos zum Einsatz kommen. Diese können einfach per USB mit dem pcDuino verbunden und programmiert werden. Messwerte und Kommandos könnten ebenfalls einfach per USB zwischen Arduino und pcDuino seriell übertragen werden. Um die Programmierung der Arduinos auch per Kommandozeile zu ermöglichen kann man Inotool verwenden, damit kann man Arduino-Projekte ohne die Arduino IDE unter Linux per Kommandozeile erstellen, kompilieren und übertragen. Mehr zur Installation der Arduino IDE, Inotool und Integration von Arduinos in ROS ist im Kapitel Betriebssystems (robotOS) für pcDuino installieren und im Kapitel Grundlagen unter ROS: Arduino als ROS-Nodes beschrieben.

Kinect als Sensor

Ich habe lange überlegt, mit welcher Sensorik der Roboter zur Objekt- bzw. Hinderniserkennung ausgestattet werden soll. Ein Ziel des Projekts ist ja, dass der Roboter später autonom navigieren und seine Umgebung Kartografieren soll (Mapping). ROS bietet dazu den Navigation Stack, den wir nach und nach implementieren wollen. Dazu sind natürlich Sensordaten notwendig.

Prinzipiell gibt es mehrere Möglichkeiten diese Sensordaten zu liefern. Da wären zum einen Laserscanner, wie sie oft in anderen Projekten verwendet werden, wie der Hokuyo URG-04LX (~1.100€) oder der etwas günstigere RPLIDAR (~400€).  Ein anderer inzwischen von ROS unterstützter Laserscanner ist der XV-11, der aus einem Neato Staubsaugerroboter stammt und teilweise gebraucht (~150€) erstanden werden kann. Ein wesentlicher Nachteil ist hier, zumindest bei den professionellen Ansätzen, der hohe Preis für den Sensor.

Eine weitere, günstigere Möglichkeit wäre, einen eigenen Sensor auf Ultraschall- oder Infrarotbasis aufzubauen. Vorstellbar wäre z.B. ein Aufbau aus einem SR04- oder SR08 Ultraschallsensor auf einem Servo, der dann zum Beispiel einen Bereich von 180° scannt und die Daten als ROS Laserscan Message bereit stellt. Ein Nachteil bei dieser Lösung ist zum einen die beschränkte Reichweite der Sensoren und die durch den Aufbau bedingte langsame Verarbeitungsgeschwindigkeit der Daten.

Bei meiner Recherche bin ich dann über den Microsoft Kinect, den man ja von der XBOX kennt, gestolpert. Der Sensor ist inzwischen gebraucht relativ günstig zu erhalten (~60€) und wird von ROS unterstützt. Deshalb viel meine Wahl zunächst auf diesen Sensor. Einzelheiten zur Inbetriebnahme, Programmierung und Integration in ROS findet man unten im ROS Package robot_kinect

Mobile Roboterplattform: Programmierung

Betriebssystem (workstationOS) für Workstation installieren

Ich verwende derzeit als Workstation sowohl ein Notebook, arbeite aber parallel auch in einer VM mit der Oracle VM VirtualBox auf meinem Desktop-PC unter Windows 10. Aufgebaut wird auf einer Basisinstallation von Ubuntu 16.04 Xenial. Das Betriebssystem workstationOS mit ROS Kinetic wurde eingerichtet, wie im folgenden beschrieben:

Zuerst habe ich Ubuntu 16.04 a) unter Windows10 in einer VM und b) auf dem ebenfalls als Workstation verwendeten Laptop direkt  installiert.

Benutzerdaten

User: user

Hostname: workstationOS

Static IP

In Ubuntu am einfachsten über die grafische Netzwerkeinstellung ändern.

192.168.178.201

Passwort für User root ändern

sudo passwd root

System aktualisieren

sudo apt-get update

sudo apt-get upgrade

Hostname ändern, falls nicht bereits bei der Installation festgelegt, in workstationOS

sudo nano /etc/hosts

sudo nano /etc/hostname

sudo reboot

Ein paar Softwarepakete installieren

sudo apt-get install libnss-mdns sshpass chrony sqlite3 git lxterminal

ROS-Kinetic installieren

• sudo sh -c 'echo "deb http://packages.ros.org/ros/ubuntu $(lsb_release -sc) main" > /etc/apt/sources.list.d/ros-latest.list'

Auf anderen auf Ubuntu basierenden Distributionen (z.B. Elementary OS oder Linux Mint) kann statt dem Befehl oben folgender Befehl verwendet werden:

• sudo sh -c 'echo "deb http://packages.ros.org/ros/ubuntu trusty main" > /etc/apt/sources.list.d/ros-latest.list'

• sudo apt-key adv --keyserver hkp://ha.pool.sks-keyservers.net:80 --recv-key 421C365BD9FF1F717815A3895523BAEEB01FA116
• sudo apt-get update
• sudo apt-get install ros-kinetic-desktop-full
• sudo rosdep init

Auf anderen auf Ubuntu basierenden Distributionen (z.B. Elementary OS) diese Zeile in die .bashrc einfügen bevor rosdep update ausgeführt wird:

• export ROS_OS_OVERRIDE=elementary

• rosdep update
• echo source /opt/ros/kinetic/setup.bash >> ~/.bashrc
• source ~/.bashrc
• sudo apt-get install python-rosinstall python-rosinstall-generator python-wstool build-essential

ROS-Package robot-pose-ekf

• sudo apt-get install ros-kinetic-robot-pose-ekf

ROS-Package joy installieren

http://wiki.ros.org/joy 

Dieses Package enthält die Node joy_node, welche für uns die Auswertung eines angeschlossenen Joysticks/Gamepads übernimmt und uns die ermittelten Daten mittels ROS-Topic /joy zur weiteren Verwendung bereitstellt. Das Package mit folgendem Befehl installieren:

• sudo apt-get install ros-kinetic-joystick-drivers

ROS-Package rosbridge-suite

Dieses Package wird später verwendet um Web-Konnektivität mittels ROS herzustellen

• sudo apt-get install ros-kinetic-rosbridge-suite

ROS-Package liburdfdom-tools

• sudo apt-get install liburdfdom-tools

ROS-Package map-server

• sudo apt-get install ros-kinetic-map-server

ROS-Package amcl

• sudo apt-get install ros-kinetic-amcl

Kinect-Treiber und ROS-Package freenect_stack

• sudo apt-get install freenect

• sudo apt-get install libfreenect-demos
• sudo apt-get install ros-kinetic-freenect-stack

ROS-Package depthimage_to_laserscan

• sudo apt-get install ros-kinetic-depthimage-to-laserscan

ROSserial mit Arduino

• sudo apt-get install ros-kinetic-rosserial-arduino
• sudo apt-get install ros-kinetic-rosserial

Arduino Toolchain

Es wurde auf dem workstationOS die komplette Arduino Toolchain installiert, wie weiter unten, unter Betriebssystem (robotOS) für pcDuino installieren, beschrieben. Also die Arduino IDE, Ino für die Programmierung der Arduinos in der Kommandozeile und die Integration in ROS per rosserial.

Um mit den Arduinos zu arbeiten muss der angemeldete User Mitglied der Gruppe dialout sein:

• sudo usermod -a -G dialout user
• sudo apt-get install arduino
• sudo apt-get install python-pip
• pip install --upgrade pip
• sudo pip install ino
• sudo apt-get install picocom
• sudo apt-get install ros-kinetic-pr2-common
• sudo apt-get install ros-kinetic-pr2-description
• sudo apt-get install ros-kinetic-convex-decomposition
• sudo apt-get install ros-kinetic-ivcon
• cd ~/sketchbook/libraries
• rm -rf ros_lib
• rosrun rosserial_arduino make_libraries.py .

ROS-Workspace von Git klonen und kompilieren

• cd ~
• git clone https://github.com/Scheik/ROS-Workspace.git
• cd ROS-Workspace
• rosdep install --from-paths . --ignore-src --rosdistro kinetic

Elementary OS oder andere auf Ubuntu basierende Distributionen, statt dem Befehl oben folgenden Befehl verwenden:

• rosdep install --from-paths . --ignore-src --rosdistro kinetic --os=ubuntu:xenial

• catkin_make
• echo source /home/user/ROS-Workspace/devel/setup.bash >> ~/.bashrc
• source ~/.bashrc

ROS für SSH- Betrieb einrichten

export ROSLAUNCH_SSH_UNKNOWN=1 in ~/.bashrc einfügen

• echo export ROSLAUNCH_SSH_UNKNOWN=1 >> ~/.bashrc
• source ~/.bashrc

ROS für das lokale Netzwerk einrichten

• sudo nano /etc/environment

dort folgende Zeilen anhängen

Skript ssh2robot.sh und Desktopverknüpfung

Zuerst das Skript zum starten der SSH-Verbindung zum robotOS erstellen:

• sudo nano ~/ssh2robot.sh

und mit

• sudo chmod +x ~/ssh2robot.sh 

ausführbar machen.

Auf dem Desktop dann folgenden Desktopeintrag ssh2robot.desktop einrichten:

Bei Elementary OS das File in /usr/share/applications erstellen, es kann dann im Dock verankert werden.

IDEs für die Programmierung (C++)

Inzwischen habe ich mich für einfachere Arbeiten am Quellcode des Projekts für den Editor Atom IDE entschieden.

Atom IDE

• sudo snap install atom --classic

Um in der IDE ein Terminal (z.B. zum kompilieren einer Änderung) zur Verfügung zu haben habe ich mich für das Atom Package Termination entscheiden, das wie folgt installiert werden kann:

• apm install termination

Once a new release is out, install updates via command:

• sudo snap refresh atom

Webserver Nginx, Sqlite und PHP installieren

Zuerst klonen des webserver_root Directorys von Github:

• cd ~
• git clone https://github.com/scheik/webserver_root

Installieren von nginx, php5 und sqlite

• sudo apt-get install nginx php5-fpm php5-sqlite sqlite3 libsqlite3-dev

nginx Konfiguration:

• sudo nano /etc/nginx/sites-available/default

bei folgender Zeile den Kommentar entfernen:

• listen 80; ## listen for ipv4; ...

darunter “index.php” hinzufügen:

• index index.php index.html index.htm

nun das document-root- Verzeichnis von nginx anpassen in:

• root /home/user/webserver_root;

dann folgende Zeilen auskommentieren:

• location ~ \.php$ {
  fastcgi_pass 127.0.0.1:9000;
  fastcgi_index index.php;
  include fastcgi_params;
  }

User user zur Gruppe www-data hinzufügen:

• sudo addgroup user www-data

Ändern des Users für nginx von www-data zu user

• sudo nano /etc/nginx/nginx.conf

hier ändern:

• user www-data; in user user;

Damit sowohl aus den einzelnen Programmen (erstellt in C++) und auch aus dem Browser, z.B. mit phpliteadmin auf die Datenbanken zugegriffen werden kann muss man noch folgende Anpassungen vornehmen:

Ändern des Users für php von www-data zu user:

• sudo nano /etc/php5/fpm/pool.d/www.conf

hier ändern:

• user=user statt user=www-data und
• listen.owner=user statt listen.owner=www-data
• und die Zeile listen = /var/run/php5-fpm.sock ändern in listen = 127.0.0.1:9000

Nginx und PHP5-fpm neustarten:

• sudo service nginx restart
• sudo service php5-fpm restart

Nginx Monitoring Tool

Ein gutes Kommandozeilen Tool um den Traffic auf dem Webserver anzuzeigen ist ngxtop.

Zuerst falls noch nicht geschehen pip, einen Python Package-Installer installieren:

• sudo apt-get install python-pip

Dann ngxtop installieren mit:

• sudo pip install ngxtop

und mit ngxtop starten.

Eine andere Ausgabe kann z.B. mit folgendem Befehl erzeugt werden:

ngxtop print request http_user_agent remote_addr

Damit der Server auch unter seiner WAN, nicht nur unter seiner lokalen IP, auch von außerhalb des lokalen Netzwerks erreichbar ist, muss am Router eine Portweiterleitung für den Webserver eingerichtet werden, hier exemplarisch für einen Speedport-Router der Telekom oder die Fritzbox 7490:

Dyndns einrichten

Damit der Server bzw. das Webinterface des Roboters auch unter einer festen IP erreichbar ist, wurde unter no-ip.com ein DynDNS- Dienst eingerichtet. Der Server ist somit,wenn online unter der Adresse robotik.ddns.net erreichbar.

Router ohne NAT-Loopback

Unterstützt der Router ,z.B. der Telekom Speedport 723V, kein NAT-Loopback muss man, damit der Webserver auch im lokalen Netzwerk unter robotik.ddns.net erreichbar ist, auf allen Rechnern im lokalen Netzwerk die hosts-Dateien anpassen.

Unter Linux:

In Datei ‘/etc/hosts’ den Eintrag ‘IP_der_Workstation robotik.ddns.net’ anhängen, z.B.:

192.168.178.201 robotik.ddns.net

Unter Windows findet man die Datei hosts unter C:\Windows\System32\drivers\etc

Sublime Text installieren

Ein praktischer Editor für Sourcecodes

• sudo add-apt-repository ppa:webupd8team/sublime-text-2
• sudo apt-get update
• sudo apt-get install sublime-text

VNC-Viewer installieren

Am besten Reminna dazu verwenden, es ist bereits in der Standardinstallation von Ubuntu 14.04 enthalten

Doxygen und epydoc installieren

• sudo apt-get install doxygen doxygen-gui epydoc-doc

• sudo apt-get install ros-indigo-rosdoc-lite

In das Verzeichnis des zu dokumentierenden Packages wechseln:

cd ~/ROS-Workspace/src/base_controller

sudo nano rosdoc.yaml (neu anlegen)

sudo nano package.xml (folgendes im export tag einfügen)

rosdoc_lite .

Die Dokumentation wird in ~/ROS-Workspace/src/base_controller/doc erstellt

( Ich verwende rosdoc-lite, der Vollständigkeit halber sei hier folgende Möglichkeit erwähnt:

Doxygen im QTCreator verwenden:

Package in den Editor laden wie oben unter QT installieren beschrieben, hier z.B. das base_controller Package.

<Projekte> -> Build-Schritt hinzufügen: Kommando: doxygen; als Argumente den Pfad zum Doxyfile (/home/user/ROS-Workspace/src/base_controller/src/base_controller/Doxyfile)

)

Bloom

Release Tool. Wird von mir verwendet, um ROS Packages zu veröffentlichen

• sudo apt-get install python-bloom

ZSH als Shell

Will man ZSH als Linux Shell benutzen:

• sudo apt-get install zsh

ZSH als Standardshell für den user ‘user’

• sudo chsh -s /bin/zsh user

Oh-My-ZSH bietet viele Themes und nützliche Addons für ZSH

• git clone git://github.com/robbyrussell/oh-my-zsh.git ~/.oh-my-zsh

TMUX

• sudo apt-get install tmux

VIM

Zuerst alles an VIM vom System entfernen, was vielleicht schon vorhanden ist

• sudo apt-get remove vim vim-runtime gvim  vim-tiny vim-common vim-gui-common

VIM-Nox installieren:

• sudo apt-get install vim-nox

VIM Plugins

• cd ~
• mkdir -p .vim
• mkdir -p .vim/bundle
• git clone https://github.com/gmarik/Vundle.vim.git ~/.vim/bundle/Vundle.vim

myDotFiles clonen:

• git clone https://github.com/scheik/myDotFiles

        Symlinks anlegen:

• ln -s myDotFiles/.zshrc ~/.zshrc
• ln -s myDotFiles/.vimrc ~/.vimrc
• ln -s myDotFiles/.tmux.conf ~/.tmux.conf

dann ausführen:

• vim +PluginInstall (oder :PluginInstall in VIM)

Dann alle colorschemes von flazz/colorschemes nach .vim/colors kopieren/verschieben

• mkdir .vim/colors

• mv ~/.vim/bundle/vim-colorschemes/colors/* ~/.vim/colors

Damit das Vim Plugin vim-airline Symbole in der Statusbar richtig anzeigt, brauchen wir die Powerlinefonts:

• sudo git clone https://github.com/powerline/fonts.git /.powerline_fonts
• cd /.powerline_fonts
• ./install.sh

Im Gnome Terminal muss dann bei den Profileinstellungen auch ein Powerlinefont, z.B. ‘Ubuntu Mono derivative Powerline’ eingestellt werden.

FreeCAD

• sudo add-apt-repository ppa:freecad-maintainers/freecad-stable
• sudo add-apt-repository ppa:freecad-community/ppa
• sudo apt-get update
• sudo apt-get install freecad
• sudo apt-get install freecad-extras-assembly2  

PyCharm

IDE für Python

• sudo add-apt-repository ppa:mystic-mirage/pycharm
• sudo apt-get update
• sudo apt-get install pycharm-community

Docker

• sudo apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv-keys 58118E89F3A912897C070ADBF76221572C52609D
• sudo nano /etc/apt/sources.list.d/docker.list

• deb https://apt.dockerproject.org/repo ubuntu-trusty main

• sudo apt-get update
• sudo apt-get purge lxc-docker
• sudo apt-get install linux-image-extra-$(uname -r)
• sudo apt-get install docker-engine
• sudo usermod -aG docker user

Videocapture

• sudo apt-get install recordmydesktop
• sudo apt-get install gtk-recordmydesktop

Bildbearbeitung

Entweder die eierlegende Wollmilchsau:

• sudo apt-get install gimp

Eine einfachere, MS Paint entsprechende Variante

• sudo apt-get install pinta

Betriebssystems (robotOS) für pcDuino installieren

Ich verwende zur Zeit für meinen pcDuino3 die Ubuntu Xenial Distribution von Armbian. Derzeit die Legacy Variante mit Kernel 3.4.113 für den pcDuino3.

Das Betriebssystem robotOS mit ROS Kinetic wurde, wie im folgenden beschrieben, eingerichtet:

Basisinstallation Ubuntu Xenial

Das Image (RAW-Datei) Armbian_5.31_Pcduino3_Ubuntu_xenial_default_3.4.113_desktop.img z.B. unter Windows mit Win32DiskImager auf eine MicroSD brennen und den pcDuino damit booten. Man kann sich das erste mal mit Username: root und Passwort: 1234 anmelden. Dabei wird man direkt aufgefordert ein neues root- Passwort einzugeben und kann dann einen neuen User anlegen. Bei mir heißt der neu angelegte User ‘robot’.

Nun richten wir das WLAN ein, dazu zuerst mit:

• nmtui

den Onboard-WLAN-Adapter einrichten.

Von nun an kann man auch headless per SSH auf dem pcDuino, als User root oder User robot, einloggen:

• ssh root@ip2pcduino oder
• ssh robot@ip2pcduino oder
• ssh robot@pcduino3

Nun fügen wir dem neuen User der Gruppe sudo und einigen anderen Gruppen hinzu

• sudo usermod -aG sudo,tty,dialout robot

AVAHI Daemon und Chrony

1. sudo apt-get install avahi-daemon libnss-mdns chrony

Betriebssystem auf SATA-Festplatte transferieren

Jetzt die SATA Platte anschließen und das folgende Script starten:

• sudo apt install armbian-config
• sudo armbian-config

Nach einem Neustart, sollte der pcduino nun von der Festplatte booten, was mit df -h überprüft werden kann.

System aktualisieren

• sudo apt-get update
• sudo apt-get upgrade

Hostname ändern, dazu in /etc/hosts und /etc/hostname von pcduino3 in robotOS ändern

• sudo nano /etc/hosts
• sudo nano /etc/hostname
• sudo reboot

ROS Kinetic installieren und einrichten

• sudo sh -c 'echo "deb http://packages.ros.org/ros/ubuntu $(lsb_release -sc) main" > /etc/apt/sources.list.d/ros-latest.list'
• sudo apt-key adv --keyserver hkp://ha.pool.sks-keyservers.net:80 --recv-key 421C365BD9FF1F717815A3895523BAEEB01FA116
• sudo apt-get update
• sudo apt-get install ros-kinetic-desktop
• sudo rosdep init
• rosdep update
• echo source /opt/ros/kinetic/setup.bash >> ~/.bashrc
• source ~/.bashrc
• sudo apt-get install python-rosinstall

ROS für lokales Netzwerk einrichten

• sudo nano /etc/environment, dort folgende Zeilen anhängen

Environment File erstellen, damit ROS Nodes remote auf dem pcDuino ausgeführt werden können:

• sudo nano /opt/ros/kinetic/myenv.sh 

speichern und ausführbar machen mit:

• sudo chmod +x /opt/ros/kinetic/myenv.sh

ROS-Workspace installieren

• cd ~
• git clone https://github.com/Scheik/ROS-Workspace.git
• cd ROS-Workspace
• rosdep install --from-paths . --ignore-src --rosdistro kinetic
• catkin_make
• echo source /home/robot/ROS-Workspace/devel/setup.bash >> ~/.bashrc
• source ~/.bashrc

Die mobile Roboterplattform im Aufbau

Serielle Schnittstelle UART2 einrichten

• sudo cat /proc/tty/driver/serial

zeigt zwar , dass ttyS1 richtig konfiguriert ist:

RX und TX von ttyS1 (UART2) am GPIO  sind aber standardmässig noch als I/O konfiguriert (siehe Forenpost). Abhilfe schafft das Skript setuart2, welches z.B. manuell heruntergeladen und gestartet werden kann:

wget --no-check-certificate http://www.the-starbearer.de/Files/setuart2

sudo chmod +x setuart2

Jetzt kann der UART2 (ttyS1) manuell mit ‘sudo ./setuart2 on’ aktiviert, und mit ‘sudo ./setuart2 off’ wieder deaktiviert werden.

Sowohl der Quellcode als die ausführbare Datei setuart2 sind auch auf https://github.com/Scheik/pcDuino_UART2.git hinterlegt.

Um den Befehl ‘setuart2 on’ aber nicht nach  jedem Neustart des pcDuino manuell neu eingeben zu müssen, nehmen wir folgende Änderungen am System vor.

Zuerst erstellen wir ein neues Script in /etc/init.d:

• sudo nano /etc/init.d/setuart2on.sh

und speichern es mit folgen Inhalt ab:

nun machen wir dieses Skript und die Datei setuart2 ausführbar mit:

• sudo chmod +x ~/ROS-Workspace/scripts/setuart2
• sudo chmod +x /etc/init.d/setuart2on.sh

und fügen wir es den Sytemservices hinzu:

• sudo update-rc.d setuart2on.sh defaults

Jetzt wird der Befehl ‘setuart2 on’ bei jedem Systemstart automatisch ausgeführt und man muss ihn nicht nach jedem Neustart erneut eingeben. Die Konfiguration kann mit folgendem Befehl erneut überprüft werden:

• sudo cat /proc/tty/driver/serial

VNC Server installieren

• sudo apt-get install tightvncserver

VNC starten um config file zu erzeugen:

• tightvncserver :1

VNC wieder stoppen:

• tightvncserver -kill :1

Bei XFCE waren keine Änderungen notwendig in ~/.vnc/xstartup

VNC neu starten:

• tightvncserver :1 -geometry 1024x768 -depth 24

Arduino Toolchain installieren

Arduino IDE installieren

• sudo apt-get install arduino

Arduino IDE starten damit das Verzeichnis /sketchbook angelegt wird

• arduino

Inotool, dazu installieren wir pip, einen Python Package-Installer:

• sudo apt-get install python-pip

dann Inotool selbst

• sudo pip install ino

und ein Terminalprogramm für die Konsole

• sudo apt-get install picocom

ROSserial mit Arduino

• sudo apt-get install ros-kinetic-rosserial-arduino
• sudo apt-get install ros-kinetic-rosserial
• sudo apt-get install ros-kinetic-pr2-common
• sudo apt-get install ros-kinetic-convex-decomposition
• sudo apt-get install ros-kinetic-ivcon
• cd ~/sketchbook/libraries
• rm -rf ros_lib
• rosrun rosserial_arduino make_libraries.py .

Nach dem Neustart der Arduino-IDE sollte ros_lib unter File -> Examples zu finden sein.

Im Kapitel Grundlagen unter 4. Arduino (Linux) zeige ich anhand einfacher Beispiele, wie man Arduinos mit Inotool auch per Kommandozeile programmieren oder direkt im ROS-Workspace per CMake mithilfe von rosserial_arduino kompilieren kann. Arduinos können so, auf dem hier gezeigten Weg, auch als Nodes für ROS programmiert werden. Beispielcodes dazu sind im ROS-Workspace im Package arduino_examples zu finden.

Kinect-Treiber und ROS-Package freenect_stack

• sudo apt-get install freenect

• sudo apt-get install libfreenect-demos
• sudo apt-get install ros-kinetic-freenect-stack

Der angemeldete User muss, falls nicht schon geschehen, zur Gruppe video hinzugefügt werden und Mitglied der Gruppe plugdev sein.

• sudo adduser robot video plugdev

Package depthimage_to_laserscan installieren

• sudo apt-get install ros-kinetic-depthimage-to-laserscan

WLAN ändern

Muss man mit einem neuen WLAN verbinden, kann man dazu einfach die Einstellungen in /etc/network/interfaces ändern.

Bisher haben wir das robotOS immer per WLAN direkt mit unserem Router verbunden, um eine Internetverbindung herzustellen und im lokalen Netzwerk eine Verbindung zur Workstation zu haben. Das ist für den Betrieb des Roboters im lokalen Heimnetz in Ordnung, bringt aber das Problem mit sich, dass wir den Roboter im Verbund mit der Workstation außerhalb unseres Heimnetzes so nicht betreiben können.

Dieses Problem kann man folgendermaßen umgehen:

Auf dem Smartphone z.B. die Android App ‘Wi-Fi hotspot’ oder jede andere funktionierende WLAN Hotspot App installieren und beide Geräte (Workstation und Roboter) mit dem hier erstellten WLAN verbinden.

Autologin als User robot

• sudo apt-get install rungetty
• sudo nano /etc/init/tty1.conf
• Die folgende Zeile kommentieren:

•  "exec /sbin/getty 38400 tty1"

• Die folgende Zeile hinzufügen:

•  "exec /sbin/rungetty --autologin robot tty1"

ROS-Workspace

Wie man sieht, habe ich mich für die Software ROS als Betriebssystem/Middleware für den Roboter entschieden; und ich habe wie oben beschrieben ROS Indigo auf dem pcDuino und der Ubuntu-Workstation installiert. Das unten verlinkte Git- Repository enthält den aktuellen ROS Workspace für den Betrieb des Roboters als Catkin Workspace.

Der komplette Sourcecode befindet sich als Repository auf GitHub unter:

• https://github.com/Scheik/ROS-Workspace.git

Das Repository wird für den Betrieb des Roboters, wie folgt, sowohl auf den pcDuino als auch die Ubuntu-Workstation geklont und kompiliert.

1. cd ~
2. git clone https://github.com/Scheik/ROS-Workspace.git
3. cd ~/ROS-Workspace
4. rosdep install --from-paths . --ignore-src --rosdistro indigo
5. catkin_make
6. echo source /home/robot/ROS-Workspace/devel/setup.bash >> ~/.bashrc
7. source ~/.bashrc

Im folgenden beschreibe ich die Funktion aller ROS-Packages, Nodes und Funktionsbibliotheken in diesem Workspace, die ich für den Betrieb des Roboters entwickelt habe. Dabei kommen im Verlauf des Projekts viele eigens programmierte Codes dazu, es werden dazu aber auch 3rd-Party Packages verwendet oder kommen modifiziert zur Anwendung.

Die erste Aufgabe bestand darin eine Möglichkeit zur Fernsteuerung der Roboterantriebe mittels ROS zu implementieren (Also ein Teleoperation, kurz TeleOP- Modus). Der ROS Workflow dazu sieht so aus:

Einfaches Beispiel zur Veranschaulichung der Funktionsweise von ROS, hier zur Fernsteuerung mittels Gamepad

Dieses Basissetup stellt auch schon ganz gut die prinzipielle Funktion der mobilen Roboterplattform mit ROS dar. Dieses einfache Setup ermöglicht so erst mal die einfache Fernsteuerung der Roboterplattform per Joystick oder Gamepad von der Workstation aus.

Ein Vorteil von ROS ist, das es die meisten der oben gezeigten Funktionen schon von Haus aus mitbringt. Es musste dazu zuerst nur der base_controller und der joystick_driver selbst programmiert werden.

Im folgenden werden alle Packages/ Nodes des ROS-Workspace und deren Funktion und Aufgaben vorgestellt.

ROS Package: md49_messages

ROS Nodes kommunizieren miteinander, indem Messages an Topics gepublished oder von Topics subscribed werden. ROS bietet dazu von Haus aus viele Standardtypen dieser Messages an. Das im folgenden beschriebene Package base_controller soll z.B. die Encoderwerte der Antriebsmotoren an das Topic /md49_encoders publishen. Dieses Topic enthält dann mehrere Werte, die durch ein so genanntes msg-File definiert werden. Dieses msg-File ist im Grunde ein einfaches Text-File, welches die Daten und Struktur der jeweiligen Message definiert.

Deshalb wurde das Package md49_messages erstellt, also ein separates Package für unsere eigenen, benutzerdefinierten ROS-Messages/Topics.

Zum erstellen des Packages wurden zuerst die nötigen Verzeichnisse im ROS-Workspace erstellt:

• mkdir ~/ROS-Workspace/src/md49_messages
• mkdir ~/ROS-Workspace/src/md49_messages/msg

Es enthält bislang folgende Custom Messages/ Topics:

• /md49_data
• /md49_encoders

Dazu wurden im Ordner /msg des Packages folgende .msg Files erstellt:

~/ROS-Workspace/src/md49_messages/msg/md49_data.msg

~/ROS-Workspace/src/custom_messages/msg/md49_encoders.msg

Nun wurden die Dateien CMakeLists.txt und package.xml erstellt:

~/ROS-Workspace/src/md49_messages/CMakeLists.txt

~/ROS-Workspace/src/custom_messages/package.xml

Kompiliert man nun den Workspace mit

• catkin_make

werden die md49_messages als eigenes Package kompiliert und können in anderen Packages/ Nodes des Workspace verwendet werden.

Ich zeige nun exemplarisch, anhand des Package base_controller, wie die oben beschriebenen benutzerdefinierten Messages verwendet werden können. Dazu müssen im Package base_controller in den Dateien package.xml und CMakeLists.txt folgende Änderungen vorgenommen werden:

~/ROS-Workspace/src/base_controller/package.xml

~/ROS-Workspace/src/base_controller/CMakeLists.txt

ROS Package: serialport

Im Laufe des Projekts bin ich dazu gekommen, für die Ansteuerung der seriellen Schnittstelle des pcDuino, eine bereits bestehende C++ Funktionsbibliothek in Form eines offiziellen ROS Packages zu verwenden und dieses für meine Zwecke anzupassen.

Basis war dafür ein offizielles ROS Package:

• cereal_port, “Simple C++ serial port class for ROS” (http://wiki.ros.org/cereal_port).

Das Package serialport in unserem ROS-Workspace enthält folgende Bibliotheken/ Programme

• serialport serialport.cpp & serialport.h (die eigentliche Funktionsbibliothek mit Source- und Header-File)
• example example.cpp (Ein einfaches Anwendungsbeispiel, keine ROS-Node)

Das Package serialport ist also eine C++-Funktionsbibliothek für die serielle Schnittstelle und kann somit leicht auch in andere Packages, wie bei mir z.B. in das Package base_controller, eingebunden werden.

Dazu muss folgendes erfüllt sein:

1. #include <serialport/serialport.h> im Sourcecode des Programms,
2. find_package(catkin REQUIRED COMPONENTS serialport) im CMakeLists.txt des jeweiligen Packages,
3. <build_depend>serialport</build_depend> und <run_depend>serialport</run_depend> im jeweiligen package.xml des Packages.

ROS Package: base_controller

Kommen wir nun zur base_controller_node selbst. Sie dient als direkte Schnittstelle zur Roboterhardware, genauer zum MD49, und muss deswegen auf dem pcDuino selbst gestartet werden. Die eigentliche Funktion ist leicht beschrieben: Derzeit empfängt diese Node Twist-Messages über das ROS-Topic /cmd_vel  und übersetzt diese in entsprechende serielle Befehle um damit die Antriebe des Roboters anzusteuern. Gleichzeitig liest sie laufend die Encoderwerte und alle anderen Parameter der beiden Motoren seriell vom MD49 aus und veröffentlicht die so empfangenen Daten an die ROS Topics /md49_encoders und /md49_data.

Das Package enthält folgende Nodes:

• base_controller base_controller_node.cpp

        Dient als direkte Schnittstelle zum MD49

Node base_controller

Topics

Parameter

Die Node base_controller lädt bei ihrem Start per Launchfile mehrere ROS Parameter aus den Konfigurationsdateien serialport_defaults.yaml und md49_defaults.yaml. So können vor dem Start die zu verwendende serielle Schnittstelle zum MD49 und die Parameter des MD49 angepasst werden.

Die eingestellten Parameter für die serielle Schnittstelle und die MD49-Defaults für Mode, Acceleration, Timeout, etc. wurden mittels des Befehls rosparam dump im Ordner config des ROS Workspace als YAML-Files gesichert:

• rosparam dump -v src/base_controller/config/serialport_defaults.yaml /serialport
• rosparam dump -v src/base_controller/config/md49_defaults.yaml /md49

Die Parameter, wie die verwendete serielle Schnittstelle oder z.B. der gewünschte MD49-Mode können so vor dem Start der base_controller Node entweder per rosparam set in der Konsole, oder indem man das entsprechende YAML-File per rosparam load einliest, angepasst werden.

Die Default-Werte für das MD49 kann man der obigen Tabelle entnehmen. Ihre Funktion sind in der Dokumentation des Motortreiberboards MD49 beschrieben.

Beispiele zum Ändern von Parametern per Kommandozeile:

• rosparam set /serialport/name /dev/ttyS2
• rosparam set /serialport/bps 9600
• rosparam set /md49/regulator false

Mit folgenden Befehlen in der Konsole können die Parameter aus den jeweiligen YAML-Files manuell eingelesen werden:

• rosparam load -v src/base_controller/config/serialport_defaults.yaml /serialport
• rosparam load -v src/base_controller/config/md49_defaults.yaml /md49

Mit dem folgenden Befehl kann die Node base_controller, lokal auf dem pcDuino, gestartet werden. Werden die Parameter vorher nicht manuell wie oben gezeigt eingelesen, werden dann aber die im Sourcecode angegebenen Defaults als Parameter verwendet:

• rosrun base_controller base_controller

Launchfile base_controller_local.launch

Um den Start der base_controller Node zu vereinfachen wurde ein ROS Launchfile für die Node erstellt. Mittels base_controller_local.launch lässt sich die Node dann einfach mittels eines einzelnen Befehls starten und nimmt uns viel Arbeit ab. So legt es in diesem Fall das robotOS als Rechner fest, auf dem die Node lokal gestartet wird, da das MD49 ja mit dessen serieller Schnittstelle verbunden ist. Dannach lädt es alle zum Betrieb nötigen Parameter aus den beiden Config-Dateien md49_defaults.yaml, serialport_defaults.yaml und startet dann die Node.

Starten der Node base_controller auf der Ubuntu Workstation (Remote)

Da im Launchfile als Rechner auf dem die Node base_controller gestartet werden soll das robotOS, also der pcDuino angegeben wurde, kann sie einfach über das Netzwerk, also “remote” von der Ubuntu-Workstation, mittels des Launchfiles base_controller_remote.launch gestartet werden. Zuvor müssen aber ein paar Dinge auf dem pcDuino und der Workstation eingerichtet sein (Quelle: Node remote starten):

Auf der Workstation:

1. Der pcDuino muss unter robotOS.local anpingbar sein und anders herum (Siehe Kapitel Die Toolchain: ROS im Netzwerk)
2. Standardmässig arbeitet ROS nur mit ssh Hosts die auch im known_hosts file definiert wurden, um das zu ändern:
   export ROSLAUNCH_SSH_UNKNOWN=1
   Möglich aber nicht optimal: Die Zeile in die ~/.bashrc packen, wie hier beschrieben.
   oder die sicherere Variante wählen und den Host ordentlich in known-hosts definieren.

Auf dem pcDuino:

1. Es muss ein Environment- File angelegt sein, bei mir /opt/ros/indigo/myenv.sh,wie hier beschrieben.

Diese Vorraussetzungen sind alle erfüllt, wenn die Betriebssysteme robotOS und workstationOS wie oben beschrieben eingerichtet wurden.

Auf der Workstation wird die Node base_controller dann per Launchfile mit folgendem Befehl gestartet:

• roslaunch base_controller base_controller_remote.launch

Mittels der base_controller Node können nun also die Antriebe des Roboters einfach mittels des Topics /cmd_vel angesteuert werden. Zusätzlich stehen durch diese Node laufend die aktuellen Daten des MD49 über die Topics /md49_encoders und /md49_data zur weiteren Verwendung zur Verfügung.

Diese beiden Topics können z.B. über die Befehle

• rostopic echo /md49_encoders 

und

• rostopic echo /md49_data 

in der Konsole angezeigt werden.

Es könnten nun auch schon die Antriebe mittels

• rostopic pub  /cmd_vel geometry_msgs/Twist -r 20 '[0.2,0,0]' '[0,0,0]' 

aus der Kommandozeile angesteuert werden, das wäre aber dauerhaft zum fernsteuern der Antriebe des Roboters wohl zu umständlich.  

ROS Package: robot_teleop

Um den Roboter fernsteuern zu können entstand das zweite Package robot_teleop, mit der joystick_teleop und der keyboard_teleop Node. Mit ihnen ist es möglich, den Roboter einfach mittels eines USB-Gamepads oder -Joysticks oder per Tastatur, angeschlossen an der ROS-Workstation, fernzusteuern.

Node joystick_teleop

Topics

Parameter

Wie man sieht, hört die joystick_driver Node auf das Topic /joy. Hier kommt die erste 3rd-Party Node zum Einsatz, die wir benutzen. Denn wir wollen den Vorteil von ROS ja auch nutzen und das Rad nicht neu erfinden. Für die Auswertung eines USB-Gamepads oder -Joysticks gibt es nämlich schon ein ROS-Package http://wiki.ros.org/joy 

Dieses Package enthält die Node joy_node, welche für uns die Auswertung des angeschlossenen Joysticks übernimmt und uns die ermittelten Daten mittels ROS-Topic /joy zur weiteren Verwendung bereitstellt. Das Package wurde einfach mittels sudo apt-get install ros-indigo-joystick-drivers auf der Ubuntu-Workstation installiert.

Nun kann mit folgendem Befehl der angeschlossene Joystick mit ROS bekannt gemacht werden:

• rosparam set joy_node/dev "/dev/input/jsx" 

Wobei hier  ‘jsx’ für den jeweils verwendeten Joystick, z.B: js2, js1 oder js0 steht (mittels lsusb oder ls /dev/input ermitteln)

Nun kann auch schon die joy_node gestartet werden:

• rosrun joy joy_node

Das Setup lässt sich einfach testen, indem man  in der Kommandozeile  rostopic echo /joy eingibt

Startet man nun unsere eigene Node joystick_teleop aus dem Package robot_teleop, übersetzt diese jede neue /joy Message in eine entsprechende /cmd_vel Message. Voila, zusammen mit unserer Node base_controller lässt sich unser Roboter nun schon per Joystick an der Workstation fernsteuern.

Um den verwendeten Port für die joy_node nicht mit “rosparam set” angeben zu müssen wurde im Package robot_teleop das Config-file joystick_defaults.yaml angelegt.

Dieses kann mit folgendem Befehl eingelesen werden:

•  rosparam load -v src/robot_teleop/config/joystick_defaults.yaml

Nun kann man die joy_node starten:

• rosrun joy joy_node

Und schließlich kann man die Node joystick_teleop in einem neuen Terminalfenster starten:

• rosrun robot_teleop joystick_teleop

Node keyboard_teleop

Topics

Die Node keyboard_teleop kann einfach mit folgendem Befehl gestartet werden:

• rosrun robot_teleop keyboard_teleop

Launchfile joystick_driver.launch

Um den hier beschriebenen Ablauf zum Starten der Joystick-Ansteuerung zu automatisieren bietet sich wieder ein ROS Launchfile an. Dieses führt folgende Schritte aus:

1. Setzten des Parameters für den Port an dem der Joystick angeschlossen ist, z.B. /dev/input/js2. Dazu wird der Parameter aus der Datei joystick_defaults.yaml ausgelesen
2. Starten der Node joy_node aus dem 3rd Party Package Joy
3. Starten der selbst programmierten Node joystick_driver

Das Launch-File joystick_driver.launch:

Meilenstein: Fernsteuerung des Roboters mittels eines Gamepad

Im folgenden will ich zeigen wie der Ablauf aussieht, den Roboter per Gamepad an der Workstation fernzusteuern.

Vorraussetzung dafür ist, dass das Betriebssystem robotOS auf dem pcDuino eingerichtet ist, wie hier beschrieben und das Betriebssystem der Workstation, das workstationOS wie hier beschrieben eingerichtet wurde. Damit sollte auch der komplette ROS-Workspace sowohl auf dem robotOS als auch auf dem workstationOS geklont und kompiliert sein.

Wir haben also inzwischen alle Komponenten beieinander, um den Roboter manuell fernsteuern zu können. Im wesentlichen ist das die Node base_controller, welche das Topic /cmd_vel subscribed und die entsprechenden Steuerbefehle über die serielle Schnittstelle an das MD49 sendet.

Zweiter Bestandteil sind die Nodes, welche das Gamepad  auswerten. Das ist zum einen die Node joy_node aus dem ROS Package joystick_drivers und unsere eigene Node joystick_teleop, die dann das Topic /joy in entsprechende /cmd_vel -Befehle übersetzt.

Workflow auf der Workstation:

• roslaunch base_controller base_controller_remote.launch
• roslaunch robot_teleop joystick_driver.launch

Launchfile joystick_teleop.launch

Um den obigen Ablauf zu vereinfachen habe ich inzwischen das Launchfile joystick_teleop.launch in ~/ROS-Workspace/launch erstellt. Dieses startet alle zum fernsteuern per Joystick nötigen Nodes/Launchfiles mit einem Befehl. Dazu auf der Workstation folgendes ausführen:

• cd  ~/ROS-Workspace
• roslaunch launch/joystick_teleop.launch

Ausgabe von rqt_graph vom Ablauf gestartet durch joystick_teleop.launch

ROS Package: sqlite_connector

Die Idee hinter diesem Package ist, dass eine ROS Node Daten aus ROS Topics, hier /md49_data und /md49_encoders in eine Datenbank schreiben kann, um später, z.B. über ein Webinterface/ -tool darauf zugreifen zu können.

Es muss dazu der Nginx Webserver, PHP und SQLite auf der Workstation installiert sein, wie in diesem Kapitel beschrieben.

Bisher loggt die Node sqlite_connector also die Daten der Topics /md49_encoders und /md49_data in eine SQLite Datenbank. So sind alle Daten der Motoren in der SQLite Datenbank md49data.db für die weitere Verarbeitung, z.B. in einem Webinterface per PHP, verfügbar. Die dafür verwendete Datenbank md49data.db liegt im Root-Verzeichnis unseres Webservers unter :

~/webserver_root/sqlite_connector/md49data.db.

Starten der Node sqlite_connector:

• rosrun sqlite_connector sqlite_connector

Topics

ROS Package: base_odometry

Nun, da die Ansteuerung der Motoren per Twist- Messages möglich ist und die Encoderdaten zur Verarbeitung bereitstehen, möchte ich in Anlehnung an den ROS-Navigation-Stack Odometriedaten daraus errechnen. Dazu ist die Node base_odometry im dazugehörigen Package base_odometry des ROS-Workspace entstanden. Um die Theorie dahinter zu verstehen, kann folgende Antwort aus den ROS Answers helfen:

Topics

Parameter

Die Parameter können über das File base_odometry_parameters.yaml aus dem Ordner /config des Packages base_odometry gesetzt werden.

Startet man die Node per

• rosrun base_odometry base_odometry

muss das Config-File dazu zuvor mit

• rosparam load -v src/base_odometry/config/base_odometry_parameters.yaml

eingelesen werden.

Die Node wird deswegen am besten über das Launchfile base_odometry.launch gestartet, so wird das Config-File beim Start automatisch mit eingelesen:

• roslaunch base_odometry base_odometry.launch

ROS Package: robot_urdf

Enthält u.a. urdf-Files und launch-Files, und dient dazu mit RViz Roboter-Modell, -Bewegungen, Sensordaten und Umgebung zu visualisieren.

Dieses kurze Video demonstriert die Funktionsweise von RViz.

Erstellung des Package robot_urdf und erste Schritte

Im Verzeichnis src des ROS-Groovy-Workspace wurde das Package robot_urdf erstellt:

• cd ~/ROS-Workspace/src
• catkin_create_pkg robot_urdf std_msgs rospy roscpp geometry_msgs

Dann wurde ein Verzeichnis urdf im Stammverzeichnis des eben angelegten Package erstellt und darin das urdf-File robot.urdf angelegt:

Testen/Parsen des urdf-Files

• sudo apt-get install liburdfdom-tools
• cd ~/ROS-Workspace/src/robot_urdf/urdf

jetzt kann man mit

• urdf_to_graphiz robot.urdf 

eine Visualisierung des URDF Files (robot.pdf und robot.gf) erstellen und mit

• check_urdf robot.urdf 

testen, ob das angelegte File korrekt geparsed wird.

Ein mit urdf_to_graphiz visualisiertes urdf- File robot.pdf, hier im Bild ein früher Stand des Files robot.urdf

Darstellen des Modells in RViz

Dazu muss man die RViz- Konfigurationsdatei urdf.rviz in ~/ROS-Workspace/src/robot_urdf erstmalig erstellen:

Das Verzeichnis ~/ROS-Workspace/src/robot_urdf/launch erstellen. Darin das Launch-File display.launch erstellt

Das so angelegte launch-File starten:

• cd ~/ROS-Workspace
• roslaunch robot_urdf display.launch model:=src/robot_urdf/urdf/robot.urdf gui:=True

Ein einfacheres Launchfile robot_rviz.launch, ohne Argumente im Aufruf:

Das Launch-File robot_rviz.launch starten:

• roslaunch robot_urdf robot_rviz.launch

Ein frühes urdf- Modell des Roboters im ‘3D Visualization Tool’ rviz

Das statische Roboter-Modell aber einfach nur so in RViz darzustellen ist aber natürlich nicht Zweck des ganzen. Später sollen alle Bewegungen des Roboters und seine Sensordaten in RViz dargestellt werden. Kommen wir nun also zuerst dazu, wie wir die Bewegungen des Roboters visualisieren können.

Meilenstein: Roboter fernsteuern und Bewegungen in RViz darstellen

Die einzigen Sensordaten die uns bisher zur Orientierung des Roboters dienen erhalten wir bisher aus dem Package base_odometry, welches die Encoderdaten der der Antriebe in Odometriedaten verarbeitet. Dies reicht vorerst schon aus, die Bewegungen des Roboters in RViz darzustellen.

Kommen wir also nun zum Test unseres Robotermodells in RViz mit diesen Odometrie-Daten. Wir starten dazu folgenden Workflow:

• roslaunch base_controller base_controller_remote.launch
• roslaunch robot_teleop joystick_driver.launch
• roslaunch base_odometry base_odometry.launch
• roslaunch robot_urdf robot_rviz.launch

Sind alle Nodes gestartet müsste man den Roboter per Gamepad steuern können und es sollten die Bewegungen simultan in RViz abgebildet werden. In RViz muss dazu unter ‘Global Options’ als ‘Fixed Frame’ der Link  ‘encoder/odom’ angegeben werden.

Video?

tf-Debugging Tools

http://wiki.ros.org/tf/Debugging%20tools

• rosrun tf view_frames

Ausgabe frames.pdf von ‘rosrun tf view_frames’

• rosrun rqt_tf_tree rqt_tf_tree

        Macht eigentlich dasselbe wie view_frames aus dem Package tf nur direkt in einem rqt- Fenster anstatt der Ausgabe in einem PDF.

• roswtf

• rosrun tf tf_monitor base_footprint base_link

ROS Package: interactive_markers_twist_server

Mit diesem Package kann der Roboter über RViz mittels ROS Interactive Markers ferngesteuert werden:

Workflow auf der Workstation:

• roslaunch base_controller base_controller_remote.launch
• roslaunch base_odometry base_odometry.launch (optional)
• roslaunch robot_urdf robot_rviz.launch
• roslaunch interactive_marker_twist_server interactive_markers.launch

Das Package basiert auf dem Sourcecode von http://wiki.ros.org/interactive_marker_twist_server, der in meinem Package etwas modifiziert zum Einsatz kommt.

ROS Package: robot_gazebo

Enthält u.a. xacro-Files und launch-Files, und dient dazu mit Gazebo Roboter-Modell, -Bewegungen, Sensordaten und Umgebung zu visualisieren.

http://www.romin.upm.es/wiki/index.php?title=ROS%3ATutorials/Simulate_Your_Robot_in_Gazebo

Package robot_gazebo erstellen

• cd ~/ROS-Gazebo/src
• catkin_create_pkg robot_gazebo gazebo_msgs gazebo_plugins gazebo_ros gazebo_ros_control
• rosdep update
• rosdep install --from-paths . --ignore-src --rosdistro indigo

Folgende Dateien in ~/ROS-Gazebo/src/robot_gazebo/urdf/ erstellen:

• materials.urdf.xacro
• wheel.urdf.xacro
• robot.urdf.xacro

In ~/ROS-Gazebo/src/robot_gazebo/launch/ das folgende Launchfile erstellen:

• robot_gazebo.launch

Launchfile starten:

• roslaunch robot_gazebo robot_gazebo.launch

ROS Package robot_maps

Um später den ROS Navigation Stack für den Roboter zu implementiert benötigt man Karten. Dieses Package beinhaltet Map- und  YAML-Files für den ROS map_server. Das map_server package beinhaltet die map_server -Node, welche Map-Daten als ROS Service bereitstellt.

Für die ersten Versuche habe ich im Package eine leere Karte empty_map.pgm erstellt. Eine PGM-Datei ist Mitglied des PNM-Formats, was eine Familie von einfachen Dateiformaten zur Speicherung von Rastergrafiken ist.

Für ROS sind dabei weiße Pixel freies, schwarze Pixel belegtes und Graustufen dazwischen unbekanntes Terrain. In einem dazugehörigen YAML-File, hier empty_map.yaml werden Parameter für die jeweilige Karte festgelegt werden, z.B. die Auflösung/Resolution und Threshold der Graustufen.

Man kann den map_server manuell starten mit:

• cd ~/ROS-Workspace
• rosrun map_server map_server src/robot_maps/maps/empty_map.yaml

Die ROS Node map_server hat die bisher leere Karte geladen.

Wie man sieht wird die gewünschte Map hier mit einem yaml-File empty_map.yaml gestartet. In diesem yaml- File sind z.B. der Pfad zur gewünschten Map und weitere Parameter der Map  hinterlegt:

Das YAML Format (Aus der Dokumentation des ROS Packages map_Server):

• image : Path to the image file containing the occupancy data; can be absolute, or relative to the location of the YAML file
• resolution : Resolution of the map, meters / pixel
• origin : The 2-D pose of the lower-left pixel in the map, as (x, y, yaw), with yaw as counterclockwise rotation (yaw=0 means no rotation). Many parts of the system currently ignore yaw.
• occupied_thresh : Pixels with occupancy probability greater than this threshold are considered completely occupied.
• free_thresh : Pixels with occupancy probability less than this threshold are considered completely free.
• negate : Whether the white/black free/occupied semantics should be reversed (interpretation of thresholds is unaffected)

Alleine macht diese map_server Node noch nicht viel, man wird sie normalerweise nicht manuell starten. Wir kommen aber später im Package robot_2dnav noch zur Anwendung.

ROS Package robot_kinect

Beginnen wir mit der Inbetriebnahme des Kinect Sensors unter Ubuntu 16.04 LTS. Derzeit gibt es dafür zwei relevante Open-Source Treiberpakete, da wäre zum einen OpenNi und zum anderen libfreenect von OpenKinect. Der Unterschied wird in einem Thread auf Stackoverflow ziemlich gut zusammengefasst:

“Libfreenect is mainly a driver which exposes the Kinect device's features: - depth stream - IR stream - color(RGB) stream - motor control - LED control - accelerometer. If does not provide any advanced processing features like scene segmentation, skeleton tracking, etc.

On the other hand, OpenNI allows generic access to Kinect's feature (mainly the image streams), but also provides rich processing features such as: - scene segmentation - skeleton tracking - hand detection and tracking - gesture recognition - user interface elements etc. but no low level controls to device features like motor/LED/accelerometer.”

Da uns zunächst die Grundfunktionalität der Kinect für unsere Pläne ausreicht, habe ich mich für das Treiberpaket libreenect von OpenKinect entschieden und werde im folgenden zeigen, wie ich dieses installiert habe.

Treiber für Kinect installieren

Der angemeldete User muss, falls nicht schon geschehen, zur Gruppe video hinzugefügt werden und Mitglied der Gruppe plugdev sein.

• sudo adduser user video plugdev

Nach dem anstecken des Kinect sollten 3 neue Einträge durch den Befehl lsusb angezeigt werden:

Installieren wir nun die Treiber für Kinect, wie gesagt habe ich mich für die freenect-Treiber des OpenKinect Projektes entschieden:

• sudo apt-get install freenect

• sudo apt-get install libfreenect-demos

Nun können wir einen ersten Test mit einem der libfreenect-demos durchführen:

• freenect-glview

Mit diesem Demo kann auch der Tiltmotor mit den Tasten ‘w’ nach oben, mit ‘x’ nach unten und mit ‘s” in die neutrale Position gefahren werden. Daneben kann mit den Tasten ‘1’-’6’ und ‘0’ die LED-Anzeige am Kinect verändert werden. Alle möglichen Kommandos kann man dem Sourcecode des Programms entnehmen.

Die Ausgabe des libfreenect-Demos freenect-glview

Bei Problemen bis hier hin bitte folgende Fehlerquellen prüfen (Quelle):

• Der angemeldete User muss in der Gruppe plugdev sein (sudo adduser $USER plugdev)
• Es kann der Kerneleigene Treiber für die Kinect geladen sein, so dass libfreenect nicht die Kontrolle über die Kinect erhalten kann:

• lsmod | grep -i gspca (sollte nichts ausgeben)

• Kann man die Demo nur mit sudo starten, den angemeldeten User zur Gruppe video hinzufügen (sudo adduser $USER video)

ROS und Kinect

Installieren wir nun den zum gewählten Treiberpaket passenden ROS Stack für die Kinect:

• sudo apt-get install ros-kinetic-freenect-stack

(Im Falle man das Treiberpaket von OpenNi statt libfreenect verwendet hätte, wäre das Pendant hierzu die Packages ros-indigo-openni-camera und ros-indigo-openni-launch.)

Erste Tests  analog zu http://wiki.ros.org/openni_launch:

• roslaunch freenect_launch freenect.launch
• rosrun rviz rviz

In RViz den Global Frame (links oben) zu /camera_depth_optical_frame ändern. Dann ein neues Display Pointcloud2 hinzufügen, und das  Topic auf /camera/depth/points setzen.

Man sollte nun eine weiße Punktewolke sehen.

Nun wollen wir die Punktewolke mit der RGB Kamera synchronisieren. Dazu in einem neuen Terminal das Tool rqt_reconfigure starten:

• rosrun rqt_reconfigure rqt_reconfigure

Hier dann /camera/driver im Dropdownmenu wählen und die Checkbox depth_registration anwählen.

Dann zurück in RViz das Topic /camera/depth_registered/points für die Pointcloud2 wählen und den ColorTransformer Wert auf RGB8 setzten.

Das Package freenect_launch bietet weitere Launchfiles, mit denen man weiter experimentieren kann:

• roslaunch freenect_launch freenect_registered-xyz.launch
• roslaunch freenect_launch freenect_registered-xyzrgb.launch

Zur Funktion zitiere ich hierzu die Dokumentation des Packages:

“The first launch files only produces a pointcloud from depth data. The second launch file produces a registered pointcloud using hardware registration on the device.”

2D-Laserscan Daten für den Navigation-Stack

Um mit dem Kinect später im Navigation Stack eine 2D- Karte aufzubauen benötigen wir einen Laserscan in einer Ebene, also in 2D, deswegen muss die, durch den obigen Treiber gelieferte Pointcloud in eine Laserscan- Message umgewandelt werden.

Dazu kann z.B. das ROS Package depthimage_to_laserscan,  das Package pointcloud_to_laserscan oder das Package  kinect_2d_scanner verwendet werden. Ich werde später nur noch das Package depthimage_to_laserscan verwenden, zeige aber auch kurz die Funktionsweise der anderen beiden Packages auf.

Package kinect_2d_scanner:

• sudo apt-get install ros-indigo-kinect-2d-scanner
• rosrun kinect_2d_scanner kinect_2d_scanner_node
• rosrun rviz rviz

In RViz den Global Frame auf KINECT_2D setzten, ein Display LaserScan hinzufügen un das Topic auf /scan setzen.

Package pointcloud_to_laserscan:

• sudo apt-get install ros-indigo-pointcloud-to-laserscan
• …
• ...

Package depthimage_to_laserscan

• sudo apt-get install ros-kinetic-depthimage-to-laserscan
• roslaunch freenect_launch freenect-xyz.launch
• rosrun depthimage_to_laserscan depthimage_to_laserscan image:=/camera/depth/image_raw
• rosrun rviz rviz

In RViz den Global Frame auf /camera_link setzen und ein Display LaserScan hinzufügen und das Topic auf /scan setzten:

Integration der Kinect in das Projekt/ ROS-Workspace

Das nächste Ziel ist es nun, diese 2D-LaserScan-Daten in RViz anzuzeigen und in Verbindung mit dem Roboter URDF- Modell zu bringen.

1. Dazu wurde zuerst die Kinect mit ins URDF-Modell des Roboters eingepflegt:

Die Kinect im robot.urdf in stark vereinfachter Version.

Die letztlich verwendete Version basiert auf einem Mesh aus dem Package turtlebot_description

2. Nun wurde das Package robot_kinect im ROS-Workspace erstellt, welches die im folgenden erstellten Launchfiles für die Kinect enthält.
3. Zur Wandlung der Kinect- Daten in einen 2D-Laserscan wird, wie oben genannt, das ROS Package depthimage_to_laserscan benutzt. Deshalb wurde im Package robot_kinect das Launchfile depthimage_to_laserscan.launch erstellt:

Eine Version depthimage_to_laserscan.launch

4. Wir können nun die Laserscan-Daten zusammen mit unserem Robotermodell in RViz visualisieren:

• roslaunch robot_kinect depthimage_to_laserscan.launch
• roslaunch robot_urdf robot_RVIZ.launch
• Den Fixed Frame in den Global Options auf base_footprint setzten und ein Display LaserScan mit Topic /scan hinzufügen

Die 2D-Laserscan-Daten des Kinect, visualisiert in RViz 

ROS Package robot_mapping

Zuerst wurde dazu ein Package robot_mapping im ROS-Workspace erstellt:

• cd ~/ROS-Workspace/src
• catkin_create_pkg robot_mapping

Da nun mit der Kinect Laserscan- Daten zur Verfügung stehen, ist das nächste Ziel, basierend auf diesen Daten eine Karte der Umgebung des Roboters zu erstellen und ihn später darin zu lokalisieren. Dazu gibt es in der ROS- Umgebung mehrere mögliche Ansätze. Eine Gegenüberstellung gängiger Mapping-/Slam- Techniken mit ROS bietet diese Ausarbeitung. Sie stellt die folgenden fünf Ansätze gegenüber:

• HectorSLAM
• Gmapping
• KartoSLAM
• CoreSLAM
• LagoSLAM

Hector_Mapping

• sudo apt-get install ros-indigo-hector-slam

Launchfile erstellen aus Vorlage hector_slam/hector_mapping/launch/mapping_default.launch

Erster Versuch:

WorkstationOS

• roslaunch base_controller base_controller_remote.launch
• roslaunch base_odometry base_odometry.launch
• roslaunch robot_urdf robot_rviz.launch
• roslaunch robot_slam hector_mapping.launch

RobotOS

• roslaunch robot_kinect depthimage_to_laserscan.launch

Erster Test eine Karte zu erstellen mit Hector_Mapping

ROS Package robot_2dnav

Mit diesem Package soll der ROS Navigation Stack implementiert werden. Ich bin dazu nach dem Tutorial Setup and Configuration of the Navigation Stack on a Robot vorgegangen.

Zuerst wurde dazu ein Package robot_2dnav im ROS-Workspace erstellt:

• cd ~/ROS-Workspace/src
• catkin_create_pkg robot_2dnav move_base

Dann die jeweiligen Ordner für die Config- und Launchfiles  erstellt:

• cd robot_2dnav
• mkdir launch
• mkdir config

Folgende Launchfiles wurden erstellt:

• cd ~/ROS-Workspace/src/robot_2dnav/launch
• nano robot_configuration.launch
• nano move_base.launch

Folgende Config-Files wurden erstellt

• cd ~/ROS-Workspace/src/robot_2dnav/config
• nano costmap_common_params.yaml 
• nano global_costmap_params.yaml
• nano local_costmap_params.yaml 
• nano base_local_planner_params.yaml

Um den Navigation-Stack zu starten können die beiden dazu nötigen Launchfiles separat gestartet werden:

• roslaunch robot_2dnav robot_configuration.launch
• roslaunch robot_2dnav move_base.launch

Oder man kann die beiden Launchfiles gemeinsam starten mit:

• cd ~/ROS-Workspace
• roslaunch launch/navigation.launch

Meilenstein: Navigieren des Roboters mittels RViz Navigationgoals

Workflow (alles auf der Workstation):

• roslaunch base_controller base_controller_remote.launch
• roslaunch robot_2dnav robot_configuration.launch
• roslaunch robot_2dnav move_base.launch
• roslaunch robot_urdf robot_rviz.launch

VIDEO!

Die nötigen Odometriedaten liefert weiterhin die base_odometry Node. Sie wird hier aber nicht separat, sondern durch das Launchfile robot_configuration.launch gestartet.

Damit die 2D-LaserScan-Daten der Kinect für den Navigation-Stack zur Verfügung stehen, wird das Launchfile depthimage_to_laserscan.launch der Packages robot_kinect ebenfalls durch robot_configuration.launch gestartet.

ROS Package: arduino_examples

Alle nötigen Grundlagen und Erklärungen dazu findet man im Kapitel Grundlagen unter ROS: Arduino als ROS-Nodes.

Dieses Package zeigt anhand einfacher Beispiele, wie ein Arduino als ROS-Nodes programmiert und verwendet werden kann. Welche Schritte also notwendig sind ein Arduino Programm in unserem Catkin ROS-Workspace zu erstellen, zu kompilieren, es auf den Arduino hochzuladen und letztlich mittels rosserial_node mit ROS zu verbinden.

Man findet in diesem Package Beispielprogramme, z. B. einen einfachen ROS-Subscriber und einen -Publisher, um die Funktion eines Arduino als ROS-Node zu demonstrieren.

ROS Webtools

Auf der Workstation wurde wie im Kapitel Betriebssystem (workstationOS) für Workstation installieren beschrieben, Nginx als Webserver installiert. Dieser ist, wenn aktiv, unter http://robotik.ddns.net erreichbar. Neben Newspage, Source- und Projektdokumentation sollen dort nach und nach auch Webtools zu finden sein um interaktiv mit der mobilen Roboterplattform zu arbeiten. Die Web-Konnektivität zur mobilen Roboterplattform wird dazu mittels rosbridge_suite und roslibjs hergestellt.

Im Kapitel Grundlagen unter ROS: Web-Konnektivität mit ROSBridge findet man alles Grundlegende zum Thema ROS Web-Konnektivität mittels rosbridge_suite und roslibjs.

Erstes Ziel ist es derzeit, ein Webtool base_controller zu erstellen. Dieses Tool soll zuerst die von der ROS-Node base_controller gepublishten Topics /md49_data und /md49_encoders live im Browser darstellen und später die Fernsteuerung des Roboters ermöglichen, also auch an das ROS-Topic /cmd_vel publishen.

Bisher werden folgende Techniken zum Erstellen der Seite eingesetzt:

• HTML
• CSS
• Javascript / JQuery / Angular JS

Um die Webtools zu nutzen, muss natürlich wie im Kapitel Betriebssystem (workstationOS) für Workstation installieren beschrieben Nginx als Webserver installiert sein.

Damit dann die betreffenden ROS-Topics auch bereit stehen, muss natürlich zuerst die Node base_controller gestartet werden:

• roslaunch base_controller base_controller_remote.launch

Rosbridge starten:

• roslaunch launch/rosbridge_websocket.launch

Laden wir nun die Webtools im Browser unter http://robotik.ddns.net/Webtools und wechseln zum Tab base_controller, sollten wir die folgende Seite sehen, welche die aktuellen Daten der laufenden Node base_controller visualisiert:

Screenshot des Webtools base_controller