Entwicklung: RoPi - Autonomer Roboter mit RaspberryPI

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Entwicklung: RoPi - Autonomer Roboter mit RaspberryPI? Schau mal ob du hier fündig wirst!


  • ach du programmierst Arduino am PI ? :s

    wie geht das ? ist der nicht ein bissl lahm ?

    *handheb* ich tu das weil mir das ständige hin und her stecken zu blöd is :D *faulguck* aber lahm is das nicht wirklich, dank Übertaktung auf Turbo :P
    (und ich nutz Xming um arduino ohne LXDE zu starten)


  • Ach jar ... es gibt auch eine Welt jenseits von Redmond ;) ...

    och einiges kenne ich schon, nur am PI ist mir neu :blush: sollte aber dank java irgendwie gehen


    *handheb* ich tu das weil mir das ständige hin und her stecken zu blöd is :D *faulguck* aber lahm is das nicht wirklich, dank Übertaktung auf Turbo :P
    (und ich nutz Xming um arduino ohne LXDE zu starten)

    interessant, für später :thumbs1:

    nun bin ich gerade dabei IRMP auf den Arduino zu bringen

    universal IR Code Auswerter kann man immer gebrauchen und da mir @work der 4te PI fehlt nehme ich eben Redmond OS :lol:

    evt. ist das mit dem IR am Arduino ausgewertet per rs232 als Klartext zum PI interessant ?

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • Gerade ist mein Arduino Mega 2560 R3 angekommen, leider ohne USB-Kabel, hab da nicht drauf geachtet, aber hab glücklicherweise noch eins rumfliegen - von der Bestellung bis zur Lieferung hats keine 2 Tage gedauert :) (am 31.07 gekauft, am 02.08 geliefert)

    Damit hab ich jetzt auf jedenfall genug Platz für meine Programme - mein aktueller Sketch verbrät ~15kB, enthält aber noch kein Mapping oder kleinere Regeln, auch will ich noch ein paar mehr Steuerbefehle einbauen damit der PI noch mehr Einfluss nehmen könnte. Und genug Pins hab ich nun auch :fies:
    Die SerialServer.py und client.py Scripts aus Beitrag #84 funktionieren soweit auch schon mal sehr gut.


    Nun versuch ich mich aber bereits seit 2 Tagen an ROS, hab davon abgesehen den Source zu kompilieren weil das nicht funktionieren wollte, stattdessen hab ich die Binary Pakete installiert:

    "ROS Binary Install"

    Alle Befehle als Benutzer pi ausführen!

    Code
    sudo sh -c 'echo "deb http://64.91.227.57/repos/rospbian wheezy main" > /etc/apt/sources.list.d/rospbian.list'
    wget http://64.91.227.57/repos/rospbian.key -O - | sudo apt-key add -
    sudo apt-get update
    sudo apt-get install ros-groovy-ros-comm
    echo "source /opt/ros/groovy/setup.bash" >> /home/pi/.bashrc


    Quelle: http://curantilrobot.wordpress.com/2013/10/13/ins…e-raspberry-pi/

    Dann hab ich die ersten Schritte der Tutorials befolgt - aber leider versteh ich kein bisschen wie ich jetzt einen eigenen Roboter anlege/konfiguriere usw... Leider sind die Anleitungen auch alle auf Englisch, was Deutsches hab ich bisher nicht gefunden =(

    ROS will ich ausprobieren weil ich mir dann erhoffe das Mapping usw leichter zu verstehen - und letztlich wird es auch von vielen Professionellen Roboter Entwicklern eingesetzt, also wieso nicht auch ich :D

    Hat sich hier schon mal jemand mit ROS beschäftigt und könnte mir'n paar Tipps geben :huh:

    //EDIT: Nach längerem googlen hab ich nun gelesen das man auf dem PI roscore laufen lassen muss und dann auf einem anderen Rechner die ROS-Desktop (bzw rvis) installieren soll.
    Dafür nutze ich VirtualBox und Ubuntu 14.
    Nach ersten Anlaufschwierigkeiten die Auflösung zu ändern hab ich diesen Workaround gefunden (mit der TAB Taste erst auf Zurücksetzen und dann noch mal TAB gefolgt von ENTER um die Änderung zu übernehmen, da man diese Schaltfläche bei 640x480 nicht sieht) und befolge nun diese Anleitung um ROS zu installieren (man sollte auf beiden Systemen die selbe Version (indigo) nutzen um voll kompatibel zu bleiben)... Für groovy muss man max. Ubuntu 12 nehmen, für 14 gibts kein groovy sondern dann muss es das aktuelle indigo sein :-/
    Mal gucken ob das nun klappt :)

    roscore auf dem PI ausführen.
    Auf dem Ubuntu System ein Terminal öffnen und

    Code
    export ROS_MASTER_URI=http://192.168.0.11:11311/

    ausführen... IP muss die vom PI sein..
    Auf dem Ubuntu System anschließend:

    Code
    rosrun rviz rviz

    ausführen


    //EDIT2: ..ich notier hier mal einige Schritte die ich durchgeführt habe - ob das so alles richtig ist weiß ich aber noch nicht :D

    ..nachdem der workspace usw erstellt wurde..

    Code
    cd ~/catkin_ws/src
    catkin_create_pkg ropi std_msgs rospy roscpp
    nano ~/catkin_ws/src/ropi/package.xml

    quelle: http://erlerobot.github.io/erle_gitbook/e…os_package.html

    Code
    cd ~/catkin_ws
    catkin_make


    quelle: http://wiki.ros.org/rosserial_ardu…o%20IDE%20Setup

    Code
    mkdir -p ~/sketchbook/libraries
    cd ~/sketchbook/libraries
    rosrun rosserial_arduino make_libraries.py .
    tar -cz ros_lib >/tmp/ros_lib.tar.gz
    ...ros_lib.tar.gz auf den WinPC ins Arduino-IDE libraries Verzeichnis kopieren und entpacken...


    Ausprobieren: http://wiki.ros.org/rosserial_ardu…vo%20Controller

  • Ich hab mir heute Nacht folgendes bestellt:

    • RoboSavvy.com:

      • DAGU - Rover 5 Explorer PCB w/ 4A Motor Drivers, Encoder Support -- für 48€
      • plus 6,80€ VSK
    • eBay.de:

    • HobbyKing.com:

      • Dagu - Rover 5 Robot Platform (2 motors + 2 encoders) -- für 27,50€
      • Arduino EEPROM Shield With 256K AT24C256 -- für 6,60€
      • plus 24€ VSK (DHL Express)

    Das sind die günstigsten Angebote die ich gefunden habe (hab 3 Tage gesucht, auch nach anderen Chassis mit Radencodern; nachrüsten wäre teurer gekommen). Das EEPROM Shield hätt ich auch günstiger gekriegt aber das war mir heute Nacht um 3Uhr egal :D

    Nun bastel ich erst mal weiter an der Steuerungssoftware und dem WebInterface..
    von ROS bin ich erst mal ab da das auf dem PI (zumindest bei mir) nicht zufriedenstellend läuft (ist ziemlich langsam, benötigt gut 5 Sekunden bis ein Befehl umgesetzt wurde)

    Für den Rover5 hab ich auch noch > hier < ein bisschen Code gefunden.

  • Kettenantrieb finde ich gut ! (besser als billige unpräzise Einzeltriebe)
    den AT24C256 hättest du doch auch einzeln bekommen, wozu diese Platine ?

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • Hi,

    sieht gut aus, das Chassis ...
    Gut finde ich, dass der Encoder in einem Gehäuse untergebracht ist.
    Mir wäre das allerdings, ehrlich gesagt, zu teuer.
    Der ganze Kleinkram ( ich denke da nur an Schrauben, Muttern, Scheiben, ... in versch. Ausführungen ) läppert sich auch so ganz schön.
    Sicher, Kettenantrieb hat was ... hm, vielleicht später mal in einem anderen Vorhaben ( oder einem anderen Leben ;) ). Im Moment fummle ich noch am Prototypen einer 2-Rad-Variante ...

    Das EEPROM willst Du vermutlich für Deine Kartendaten verwenden.
    Ich hatte seinerzeit -> hier <- mal mit EEPROMs auf dem RPi rumgespielt. Dumm ist, dass man die immer in Chunks lesen muss ... das dauert. Aber sonst eine feine Sache.
    SD-Karte wäre keine Alternative gewesen (könntest Du evtl. extern ändern/schreiben/löschen)?

    jar: ich kann mir nicht vorstellen, dass hier hochwertigere Motoren/Getriebeteile verbaut werden, als in der TT-Getriebemotor-Variante.

    cheers,
    -ds-


  • ..... jar: ich kann mir nicht vorstellen, dass hier hochwertigere Motoren/Getriebeteile verbaut werden, als in der TT-Getriebemotor-Variante.

    das steht aber auf einem anderen Blatt,

    2 angetriebene Ketten sind leichter zu syncronisieren als 4 Motoren und laufen auch besser

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • Ketten haben aber mehr Schlupf (rutschen) und sind somit ungenauer. Hab ich hier bereits irgendwo erklärt ;)

    Man sollte sich aber so oder so auf mehrere Sensordaten stützen, also nur Radencoder reicht nicht.


  • Ketten haben aber mehr Schlupf (rutschen) und sind somit ungenauer. Hab ich hier bereits irgendwo erklärt ;)

    ist das pauschal so ? ich kenne auch Kettentriebe mit Zahnräder oder Rippenriemen, aber egal ....

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)


  • Es geht um die Verbindung zum Untergrund - Ja das ist pauschal mit Kettenantrieb immer so

    ok daran dachte ich nicht :thumbs1: ich bin ja Robot Dummi kann nur dazulernen :thumbs1:

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • Hi,

    ich hab' da übrigens gerade -> hier <- was ausgebuddelt, was ganz interessant sein könnte: ein ARM Developer Board mit imho sehr interessanten Features ... das kommt bei mir sicher auf die Wunschliste ;) ...
    cu,
    -ds-

  • Gerade ist das Akku Pack angekommen. Leider kommt mir das schwerer als die angegebenen "zirka 435g" vor, würde eher das doppelte schätzen. (hätt ich mir vllt doch lieber dieses Teil aus China bestellen sollen? naja egal..)
    Auch finde ich komisch das es fast aufgeladen ausgeliefert wird, es fehlt nur ein Balken.
    Sobald man etwas in die beiden Ausgänge oder den einen Eingang steckt geht es automatisch an, zieht man das Kabel dann wieder raus geht es automatisch nach ca. 10 Sekunden wieder aus.
    Dabei ist ein ca. 30cm langes Kabel mit auf der einen Seite ein USB Typ A Stecker und auf der anderen eine Hohlbuchse für 8 verschiedene Adapter für verschiedene Handys. Da ist unter anderem auch ein MiniUSB und MicroUSB Adapter dabei, über den man das Akku Pack aufladen kann (der Eingang ist MiniUSB).
    Läd man es auf blinkt die letzte LED wie sie zuvor auch den aktuellen Ladezustand angezeigt hat.

    Nun werde ich nach vollständigem aufladen erst mal testen wie lange RaspberryPI+Arduino davon betrieben werden können.
    Die Motoren wollte ich übrigens über den 6xAA AkkuPack der beim Chassis dabei ist betreiben.


    //EDIT: Heute (07.08.2014) um 10:23 Uhr -> RaspberryPI (Standard Taktung) und Arduino an die voll aufgeladene PowerBank angeschlossen.
    //EDIT2: (20:13 Uhr) Ganzen Tag am PI gearbeitet und das WebInterface entwickelt - die letzte LED von der Ladezustands Anzeige ist jetzt nicht mehr ganz so hell wie heute morgen... Ich gehe zZt davon aus das ich den PI nen Tag mit dem PowerPack betreiben kann :)
    //EDIT3: 08.08.2014 08:28 Uhr: Nur noch eine LED der Ladezustands Anzeige leuchtet, das Gespann läuft aber noch ;) 22h up
    //EDIT4: 10:18 Uhr: Das Gespann ist soeben ausgegangen - Akku alle :) Hat also fast 24h gehalten, das sollte erstmal reichen :D

  • Hi,

    also ich finde die zweite Powerbank, also die mit dem Solarpanel, einfach genial :) ...
    Das Zeugs wird auch immer billiger ... irre ... die Frage ist halt, ob so ein Teil hält was es verspricht.

    Ich weiss jetzt nicht, ob Du mit Batterien für den Antrieb auf Dauer glücklich wirst. Meiner Erfahrung nach verbrennen die Motoren schon eine Menge Energie. Hast Du schon mal als Alternative über Modellbau-Akkus mit 7,4 bzw. 12 V nachgedacht?

    Jetzt bin ich aber mal gespannt, was bei Deinem Versuch rauskommt.
    BTW: ich hab' mir kürzlich einen kleinen Akkuschrauber gekauft. Der war ebenfalls aufgeladen - trotz OVP - allerdings scheinbar nur teilweise, weil er dann doch einige Stunden am Ladegerät benötigte, bis der Akku voll war. Ist also scheinbar usus, dass Akkus teilgeladen ausgeliefert werden ...

    //EDIT:
    Ich hab jetzt gerade mal in der Modellbau-Ecke unter Kettenfahrzeuge rumgegruschelt ... das sind imho durchaus interessante Sachen dabei. Vor allem sind die relativ groß ... Fahrzeuge im Maßstab 1:20 sind z.B. so um die 40 cm, im Maßstab 1:16 etwa 65 cm lang.


    cheers,
    -ds-

  • Gerade ist das Paket von HobbyKing.com angekommen.
    Leider musste ich zusätzlich auch noch 22,85€ berappen für "Einfuhrumsatzsteuer" sowie "Kapitalbereitstellungsprovision auf Zoll und EUSt" und "MwSt auf Kapitalbereitstellungsprovision" ... das ist anscheint eine neue Regelung bei "DHL Express" siehe hier ...hätt ich das mal früher gewusst dann hätte ich den langsameren und billigeren Versendungsweg genommen :(

    Das Chassis macht einen sehr guten Eindruck. Anscheint ein Original trotz HongKong, ist gut verarbeitet und sieht sehr stabil aus (fühlt sich auch so an :D).
    Der Batteriehalter ist separat in einem Beutel, it einem kleinen Kreuzschlitz, einem Imbus und einer kleinen Tüte mit Schmiermittel(?) verpackt. Leider ist am Batteriehalter kein Stecker dran, muss man also selber was dran löten.
    Auch liegt leider keine Anleitung bei wie man das Chassis höher machen kann, aber anscheint muss man dazu die innere Verschraubung (diese silbernen Dinger) lösen und das gesamte Konstrukt mit den Motoren drin, drehen.
    Motoren und Encoder sind in jeweils separaten Leitungen ausgeführt. In der Plusleitung für die Motoren (oder is das für die Encoder?) ist auch anscheint eine Spule eingearbeitet die man im inneren des Chassis in sone Vorrichtung einklemmen kann. Leider sind die anderen 4 adrigen Kabel nicht allzu lang.
    Ich ärger mich nur grad das ich die Variante mit nur 2 Motoren genommen hab und hoffe die 2 sind für mein späteres Bollwerk stark genug :-/


    Nun sitze ich bereits seit ein paar Tagen an dem Web-Interface für den RoPi, aber habe das Problem kein verzögerungsfreie Lösung für die RaspiCam zu finden, bzw bin ich mit den bisherigen Lösungen nicht zu frieden.
    Ich kann aber bereits in Echtzeit Pan/Tilt steuern sowie Fahrt Richtungen angeben. Auch empfange ich bereits ein paar Daten, allerdings nicht vom Arduino - da scheint sich der tornado breit zu machen und den Serial_read_Thread zu blockieren, wobei senden wie gesagt geht :-/

  • um mich hier mal mit einzumischen.... :D
    hier -->

    Externer Inhalt www.youtube.com
    Inhalte von externen Seiten werden ohne deine Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklärst du dich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.
    <-- wurde ein ähnliches projekt realisiert, vielleicht nur so als anregung, ich bin ja zZ auch an nehm roboter projekt dran, und würde dir als "echtzeit steuerung" eine l298 empfehlen. Die ist günstig und reagiert zuverlässig und schnell, verwende ich auch :D
    bezüglich der orientierung des pis: hut ab das du das mit der quartad orientierung machst ^^ evt wäre auch opencv mit ner kamera was für dich :thumbs1:

    lg Tim

    Some people have told me they don't think a fat penguin really embodies the grace of Linux, which just tells me they have never seen a angry penguin charging at them in excess of 100mph. They'd be a lot more careful about what they say if they had."[1996] -Linus Torvalds (*1969) :geek: ~hehxes

  • Ja hallo, altes Bastel-Schanierl ... äh Genie ;) ...


    ...
    Nun sitze ich bereits seit ein paar Tagen an dem Web-Interface für den RoPi, aber habe das Problem kein verzögerungsfreie Lösung für die RaspiCam zu finden, bzw bin ich mit den bisherigen Lösungen nicht zu frieden.
    ... allerdings nicht vom Arduino - da scheint sich der tornado breit zu machen und den Serial_read_Thread zu blockieren, wobei senden wie gesagt geht :-/


    hm ... wie meinst Du das mit "verzögerungsfrei"? Auf der Web-Oberfläche nehme ich jetzt mal an.
    Ich denke, das wird allein schon aufgrund der Datenrate, die sich eher unterhalb des Durchschnitts bewegt, nicht so einfach sein.
    Hast Du schon mal über Graustufen zur Reduzierung der Datenmenge nachgedacht?

    Das mit der seriellen Schnittstelle ist allerdings strange ... meinst Du, der Controller fischt das ab?

    Ansonsten ... Du machst echt Fortschritte ... und zudem finde ich diesen Thread prima :) ...

    Gutes Gelingen weiterhin,
    -ds-


  • hm ... wie meinst Du das mit "verzögerungsfrei"? Auf der Web-Oberfläche nehme ich jetzt mal an.

    Naja, die meisten Lösungswege beschreiben zB mjpeg_streamer aber damit werden ja nur Bilder erzeugt bzw immer die selbe Bilddatei die dann nur neu geladen wird, dh man hat nur 2 FPS.

    Und Lösungen wo der Video-Input von raspivid an ffmpeg weiter reichen um den zu recoden, haben eine Verzögerung von 5 bis 60 Sekunden drin, man sieht also nie das tatsächliche Bild sondern immer nur das Verzögerte - das kann in Sachen Roboter aber kritisch werden :(

    Diese Problematik hab ich gestern hier im Livestream in HTML Seite auf PI einbinden genauer ausgeführt.

    Es gibt hierzu zwar ein paar Lösungen (HTML5) allerdings hatte ich gestern entweder Probleme diese überhaupt ans laufen zu kriegen, oder die haben trotzdem eine Verzögerung aber das möchte ich nicht - weniger als eine Sekunden wäre für mich akzeptabel aber keinesfalls mehr als eine Sekunde.

    Ich denke, das wird allein schon aufgrund der Datenrate, die sich eher unterhalb des Durchschnitts bewegt, nicht so einfach sein.
    Hast Du schon mal über Graustufen zur Reduzierung der Datenmenge nachgedacht?

    Die CSI Schnittstelle sollte genügend Kapazitäten haben, es liegt eher an den Programmen die genutzt werden bzw die Kombination vieler und da wird dann denk ich auch das Problem mit Reduzierung der Graustufen sein, oder kann man das direkt mit raspivid?

    Das mit der seriellen Schnittstelle ist allerdings strange ... meinst Du, der Controller fischt das ab?

    Ne das liegt an tornado. Also an meinem python Script.
    Also eben was zum Hintergrund:
    Da der Arduino seine Daten (Sensoren, Position usw) ungefragt an den PI übermittelt brauch ich auf seiten des PI diese Daten nur zwischenzuspeichern und bei Bedarf an zB das Web-Interface weiterleiten.
    Ich benutze mittlerweile python-tornado weil dort ein WebSocket Paket dabei ist den man ziemlich leicht über Javascript ansprechen kann. Das mach ich deshalb weil ich im Web-Interface nicht jedesmal die Seite erst abschick möchte damit PHP die Daten übermittelt, sondern nur einzelne Elemente der Seite quasi refreshen.
    Also anfangs ging ich erst den Weg über die socket Funktionen von PHP, fand das aber irgendwann ziemlich mies und AJAX erstrecht. Mit Javascript (auch wenn ich das hasse wie die Pest) geht das wesentlich einfacher, vor allem da Javascript bekanntlich nicht auf dem Server sondern auf dem Client ausgeführt wird, also bei demjenigen der den Browser hat. Was zur Folge hat das der PI nicht auch noch mit irgendwelchen PHP Scripts beschäftigt wird.
    Beim Client laufen dann in regelmäßigen Intervallen Abfragen im Hintergrund ab um zB die aktuellen Sensordaten, Fahrtrichtungen oder Geschwindigkeitswerte abzufragen, die mir dann im Web Interface OHNE die Seite neuladen zu müssen, angezeigt werden. That's pretty cool :D
    Zugegeben habe ich mich dabei an einem bereits vorhandenen Projekt orientiert, worüber ich bei meinen Recherchen irgendwo in den Tiefen des Internets drüber gestolpert war und mir den Source geladen hatte, nach dem Motto "später kannste dann immer noch entscheiden ob du das brauchst.." ;)
    Übrigens hab ich vor WebSocket zwei verschiedene Ansätze probiert, erst den direkten weg über nativ PHP; dann eine Mischung aus PHP und Javascript in der ein send_command.php aufgerufen wurde und Javascript Sachen ausgelesen und versendet hat - aber das war alles Mist, langsam und umständlich.


    Das sieht derzeit wie folgt aus:

    Wie man sieht ist das ganze schlicht(ich mags schlicht) in einzelne Segmente eingeteilt.
    Oben links stellt man die Verbindung zum WebSocket her, die beim aufrufen der Seite aber auch automatisch erfolgt. Da sind auch ein paar Infos vom PI zu finden wie Ram Auslastung usw.
    In der Mitte soll der Livestream angezeigt werden und befindet sich auch die Ran/Tilt Steuerung da die RaspiCam ja mit dem einen US auf dem PanTilt angebracht is - auch wenn ich noch nix sehe funktionieren diese Sachen übrigens schon sehr gut :)
    Rechts daneben ist noch ein leeres Feld, da soll später die Map angezeigt werden.
    Unten werden alle 2 Sekunden die Sensordaten ausgelesen und angezeigt.
    In der Mitte ist die Steuerungseinheit bei der man entweder über die Pfeile steuern/eingreifen kann, oder bei Keyboard auch direkt Befehle eingeben kann - da soll später bei mouseOver noch eine Auflistung der möglichen Befehle als Tooltip angezeigt werden... Es fehlen auch noch Knöpfe für zB "Scan" oder das Umschalten zwischen Autonom und Manuell - da konnte ich mich noch nicht entscheiden wo ich die platziere.. Auch kann man dort die Motor Geschwindigkeit für wahlweise links oder rechts per Schieberegler festlegen, oder für beide gleichermaßen über den "Master Speed". Die zahlen ändern sich zB dank Javascript sobald man den Regler irgendwie bewegt.
    Und rechts daneben sind auch wieder Werte, allerdings vom Antrieb.
    Ach und unten links lasse ich mir zZt Debug Ausgaben vom WebIf anzeigen, also selbstverständlich in Echtzeit ;)

    Nun zum Problem mit tornado:
    Das Problem besteht darin das tornado nicht thread-safe programmiert ist. Startet man tornado mit der eigenen Funktion IOloop, beansprucht der Prozess die volle Aufmerksamkeit und blockiert andere auch zuvor gestartete Threads. Das heisst mein Serial_read_Thread wird nur ganz am Anfang ein mal ausgeführt aber danach nicht mehr weil der tornado in einer Endlosschleife alles andere blockiert.
    Ich kann zwar aus der tornado WebSocketHandler Routine heraus Daten via Serial verschicken aber eben nur wenn über den WebSocket dazu eine Aufforderung kam, also vom Web-Interface.

    Nun steh ich halt vor dem Problem das WebSocket nicht das selbe wie ein normaler Socket ist, der handshake sieht anders aus und ist eben so wie man es von http kennt.
    Denn meine erste Idee war es das ganze einfach in 2 Scripts aufzuteilen: Arduino<->RPI und RPI<->WebIf ; und die beiden Scripts auf dem PI verbinden sich untereinander und tauschen Daten aus... Aber das klappt leider aus besagtem Grund noch nicht :(
    Auch bringt es leider nichts im tornado Script noch den normalen Socket einzubauen da der tornado sich ja so aufplüstert und alles andere in dem Script blockiert... Und erst dann eine Verbindung zum Arduino herstellen sobald es vom Web-Interface verlangt wird, und die Daten abrufen ist auch nicht so optimal da der Arduino bekanntlich resettet wird sobald eine Serial Verbindung hergestellt wird - dafür gibts zwar auch Lösungen aber ich hab noch ein Grund: Der PI ist das Gehirn und muss die Daten unabhängig von irgendeinem WebInterface permanent empfangen. Das WebInterface dient ja nicht der Hauptsteuerung sondern nur zur Kontrolle (von wegen Autonom). Auch soll auf dem PI ja die Pathfinding Berechnungen stattfinden und das Mapping erstellt werden usw.
    Ich will den Krams auch nicht unnötig ausbremsen, will nicht jedesmal anhalten damit irgendwelche Werte ausgelesen werden können, vor allem aber müsste ich den Sketch auf dem Arduino dann wieder komplett umschreiben :(

    :denker:
    :s

  • Hi,

    ich hab's jetzt nur mal überflogen ... Deine Antwort ist so ausführlich, das muss ich noch mal in Ruhe durchgehen.
    Aber mir fiel beim Lesen eben ein: gibt es für das "tornade" socket-Teil keinen asynchronen Handler?
    So was wie "onReceive" oder ähnlich? Das geht ja sogar mit der Standard-C-Library für die serielle Schnittstelle.
    Wie gesagt ... war jetzt das erste, was mir in den Sinn kam.
    Aber jetzt lese ich erst nochmal Dein Post in Ruhe durch :thumbs1:

    cu,
    -ds-

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!