Entwicklung: RoPi - Autonomer Roboter mit RaspberryPI

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Nach längerem herumprobieren bin ich jetzt zu dem Schluss gekommen die Socket-Problematik wie folgt zu lösen:

    Es werden 2 Scripte auf dem PI benötigt:

    • RoPi_Socket.py: Empfängt & verarbeitet Daten vom Arduino, und sendet Steuerbefehle an den Arduino
    • WebSocketControl.py: Zur Kommunikation zwischen WebInterface und RoPi_Socket.py


    Das 1.Script empfängt permanent Daten vom Arduino wie zB von den Sensoren, Distance Werte oder Movement Rückmeldungen.
    Diese Werte werden im Script gespeichert bzw jeweils der aktuelle Wert hinterlegt. Hier soll später auch die KI enthalten sein. Das Script entscheidet dann auch was der RoPi machen soll wenn zB ein Hindernis im Weg ist.
    Es nutzt den normalen SocketServer sowie Threading und Serial.

    Das 2.Script ist vom 1.Script unabhängig und dient ausschließlich der Steuerung übers Web-Interface. Daten die das Web-Interface anfordert werden über einen internen Socket ausgetauscht - in dem Fall dann eben die Werte die das 1.Script zwischengespeichert hat.
    Im 2.Script wird tornado für den WebSocket verwendet. Das erscheint mir zZt die einfachste Möglichkeit zu sein, zumal der als am schnellsten gilt. Zusätzlich kommt aber noch der normale SocketServer zum Einsatz, der nur aufgerufen/ausgeführt wird wenn ein Befehl vom WebIf erfolgt.


    Somit gestaltet sich das ganze auch etwas Modularer und man könnte später auch noch weitere Socket Scripts einbinden die zB fürs Mapping zuständig sind o.ä.


    Einen sehr ausführlichen Artikel zu dieser ganzen Python Real-Time Problematik hab ich > hier < gefunden, sollte man sich mal durchlesen ist echt interessant.

  • Entwicklung: RoPi - Autonomer Roboter mit RaspberryPI? Schau mal ob du hier fündig wirst!

  • Aber Linux ist nun mal kein Realtimesystem

    *hust*

    Ich bitte euch keine Grundsatz Diskussion von wegen Realtime vom Zaun zu treten. Sucht euch dafür bitte einen anderen Thread

  • So ich hab jetzt 2 Probleme gelöst.

    Zum einen das oben erwähnte Socket Problem - das funktioniert schon erstaunlich gut, muss nur noch am Arduino Sketch ein paar Optimierungen vornehmen (Debugcode raus nehmen)

    &quot;RoPi_Socket.py&quot;
    &quot;WebSocketControl.py&quot;

    PS: https://github.com/giampaolo/psutil ist Fundstück der Woche und sehr mächtig, nutze aber zZt noch eigene functions.

    Das zweite Problem was ich endlich gelöst habe ist der Livestream, der endlich fast Verzögerungsfrei ist. Eine entsprechende Anleitung dazu habe ich nach dem EDIT von folgendem Beitrag gepostet: >> hier <<

    Das WebIf sieht nun so aus:


    //EDIT: Eine grobe Beschreibung des WebIfs hab ich >> hier << und >> hier << gepostet.

  • Danke ;)

    Was willst du mir mit dem Pentagon nun sagen? :lol:

    Die Akkulaufzeit beträgt beinahe 24 Stunden mit angeschlossenem Raspberry-Model-B und dem Arduino-UNO R3. Details zur Laufzeit hatte ich in Beitrag #114 beigefügt.

    Die Ladezeit des leeren Akkus liegt leider bei ca. 8 Stunden (letzteres geschätzt weil ich auch solange schlafe :D)

    Die PowerBank mit Solarzelle ist leider noch nicht da, aber vermutlich wird die Solarzelle nicht sooo viel ausmachen.

  • Hi,
    danke für die Info ...
    24 Stunden ist ja schon irre ... ich denke, für "Otto Normalbastler" könnte ein Drittel auch reichen.
    Das würde dann die Ladezeit auch erheblich verkürzen.
    Hattest Du da die Motoren und das ganze andere Zeugs mit laufen?
    Würde mich mal interessieren, wieviel Dein Kunstwerk so bei Maximal-Last bzw. im Durchschnitt zieht.

    //EDIT: Mal wieder überlesen ... die Motoren wolltest Du ja extra versorgen.
    Was hast Du Dir da als Kapazität vorgestellt?
    So um 2000 mAh sind da imho der Standard ...

    Ach ja: das mit dem Pentagon hast Du schon verstanden, altes Schlitzohr ;)


    cheers,
    -ds-


  • So ich hab jetzt 2 Probleme gelöst.

    Zum einen das oben erwähnte Socket Problem - das funktioniert schon erstaunlich gut, muss nur noch am Arduino Sketch ein paar Optimierungen vornehmen (Debugcode raus nehmen)

    &quot;RoPi_Socket.py&quot;
    &quot;WebSocketControl.py&quot;

    PS: https://github.com/giampaolo/psutil ist Fundstück der Woche und sehr mächtig, nutze aber zZt noch eigene functions.

    Das zweite Problem was ich endlich gelöst habe ist der Livestream, der endlich fast Verzögerungsfrei ist. Eine entsprechende Anleitung dazu habe ich nach dem EDIT von folgendem Beitrag gepostet: >> hier <<

    Das WebIf sieht nun so aus:

    Muss sagen sieht Top aus ;) Wåre nice das Ganze Open Source zu machen. Es gibt da mit dem Raspberry Pi zu wenig Beispiel über einen Roboter.


  • //EDIT: Mal wieder überlesen ... die Motoren wolltest Du ja extra versorgen.
    Was hast Du Dir da als Kapazität vorgestellt?
    So um 2000 mAh sind da imho der Standard ...

    Ja beim Rover5 ist ja ein extra Batteriehalter dabei, für 6 x AA Akkus... Also 6 x 1,2V (=7,2V) und Kapazität möglichst hoch, denke da geht maximal 2800mAh wenn ich mich recht erinner..
    Die Motoren laufen ja im Gegensatz zum PI/Arduino nicht die ganze Zeit - Aber die PCB muss glaub ich darüber auch mit Strom versorgt werden - also weiß noch nicht obs bei dieser Konfiguration bleiben wird ;)


    Gerade eben ist endlich die Rover 5 Explorer PCB angekommen *freu*

    Dabei ist ein sog. "RS002C Jumper Cable Pack", ganz viele Männlein/Weiblein strippen, aber relativ kurze (max. 5cm).
    Desweiteren eine Tüte mit langen und kurzen, kleinen, Kreuzschlitz Schrauben, mit Gewinde..
    Sowie 2 unterschiedliche Längen an kupfernen Abstandshaltern - wo man zB den Arduino oder den Pan/Tilt Servo über der PCB mit anbringen kann. 6 Lange und 8 kürzere.

    Die PCB stinkt leider etwas dolle und was ich scheiße finde ist dass die IR Sender und Empfänger LEDs alle nach oben verbogen sind :( Passte ansonsten wohl nicht in die 0815 Verpackung des Shops...

    Auch fehlt (wie beim Chassis auch schon) eine Anleitung oder Beschreibung, auch wenn die PCB bedruckt ist frag ich mich bei manchen Sachen schon wofür das is.... Zum Beispiel frag ich mich auch gerade wo ich die Stromversorgung für die Motoren anbringen kann/soll :huh: Bzw hab ich das glaub ich grad entdeckt (steht 7.2V dran) aber dafür benötige ich einen Stecker den ich natürlich nicht habe :(

    Zur Befestigung der PCB aufs Chassis ist jeweils nahe der Ecken son Schlitz in der PCB, damit man minimal etwas Spiel zur Seite hat. Aber nun kommt das nächste Problem: Wo sollen die Rad-Encoder Kabel durch? Dafür ist leider keine Öffnung vorgesehen, die müssen aber jeweils an die Seite des PCBs, aber die PCB würd ich schon gern bündig aufs Chassis schrauben :-/ Muss ich dafür die große Prototype Fläche verwenden?

    Vor dem Zusammenbau muss ich mich also anscheint doch erst noch durch etliche Seiten wühlen um genauere Details herauszufinden =(


    //EDIT: ExplorerPCBInstructionsManual.pdf und >> hier << ist noch eine HowTo zum Explorer PCB.

    Demzufolge befindet sich auf der Unterseite des PCB in der Nähe der Motor-Anschluss-Stecker auch die Stiftleiste für die Encoder. (Seite 5)

    Was ich mir jetzt aber noch besorgen muss sind zum einen NiMh oder NiCd Akkus und so einen kleinen Stecker für den Batterie-/Akku-Halter..

    " 4x self tapping screws provided " die sind leider auch nicht dabei, muss ich also auch noch auftreiben :(

    //EDIT2: An den Akkuhalter hab ich einfach 2 weibliche Strippen gelötet, das hält so gerade.

    Beachten werden muss aber auch unbedingt das laut der HowTo man keine Batterien verwenden soll da es sonst auf 9V käme aber das halten die Motoren nicht aus...

    //EDIT3: Den Arduino-Mega krieg ich leider nur mit 2 Schrauben befestigt da die Schraubenköpfe zu groß sind, oder mein Arduino von SunFounder nicht exakt dem Original entspricht.. Aber egal, Spacer sind trotzdem in allen 4 Ecken drunter. Muss mir aber leider auch noch eine Befestigung für den PI ausdenken, das hab ich bei all dem Coden völlig vergessen :-/

    //EDIT4: Ich verhasse gerade das billig Pan/Tilt ding... Mir war aufgefallen das ichs falsch zusammengebaut hab, musste das Ding andersherum auf das PCB anbringen damit der mittig ist... Dabei ist mir noch ein Schraubenkopf angebrochen.... Und jetzt wo ichs grad aufs PCB schrauben will fällt mir auf das die Löcher am Servo für die Schraube viel zu klein sind - muss ich also aufbohren .... :@

    //EDIT5: Als Akkus dachte ich jetzt an eines der folgenden Auktionen (alle aus der EU und Ni-MH):

    Beim Ladegerät dachte ich an >> dieses << (11,29€ inkl. VSK) und hoffe das da ein Stecker bei ist der auch passt, denn leider finde ich keine Infos was für ein Hohlstecker das PCB hat :(

  • Ich hab gestern noch einen anderen AkkuPack mit dazu passendem Ladegerät bestellt bei dem man den Ladestrom usw einstellen kann (hat gute Bewertungen gekriegt sofern man ein Original kauft)

    Zum einen erhoff ich mir durch 5Ah eine wesentlich längere Laufzeit (schließlich muss auch das PCB über den Motor-Akku versorgt werden) und zum anderen will ich mir mit der Ladestation eine Art "Laderampe" basteln - zumal die auch eine automatisch Abschaltung und verschiedene Aufladungsprogramme hat sowie übern PC gesteuert werden kann usw.

    Zusätzlich hab ich mir dann noch 2x 270pin Breadboards bestellt sowie ein paar andere Brass Spacer.

    Wegen des blöden Pan/Tilt muss ich noch ein bisschen rum suchen obs da nicht was vergleichbar besseres gäbe - auch würd ich gern gleich Servos nehmen die eine Abtastung drin haben um ne Rückmeldung zu haben... Und 360° drehbar (zumindest für Pan) wäre auch nicht schlecht ;)

    Ich werd aber auch 2 verschiedene Bauweisen ausprobieren da ich ja auch noch einen separaten MotorDriver habe und ich von der PCB eigentlich nur die IR Dioden verwende, will ich für mich auch wissen wieviel Leistung ich durchs weglassen des PCB's einsparen würde.

  • Achja ein kleines Update - schon lange nichts mehr geschrieben :blush:

    Der Kraftmax Akku ist leider zu dick und passt nicht in den unteren Teil des Rover5 (also unter die Explorer PCB).
    Beim SKYRC iMAX B6 Mini ist leider kein externes Netzteil dabei gewesen - hab ich leider verpeilt... Da kann man aber auch irgendein anderes verwenden (hoffentlich hrhr).

    Ich hab mich letztlich für 6x Oege, 2800mAh - 15,90€ inkl. VSK entschieden, die versorgen Motoren + Explorer PCB.. Hab aber noch keine Gelegenheit gehabt genauer zu testen wie lange die in der Praxis halten.

    Die PowerBank aus China ist auch endlich eingetroffen, die is auf jedenfall besser geeignet da nicht so dick und lang, nochdazu auch noch leichter als die andere ;)
    Obwohl in dem Artikel was anderes steht, stehen auf der PowerBank die selben Daten wie auf der anderen PowerBank:
    Ein Ausgang liefert 1A, der andere Ausgang 2,1A.
    Wenn man die PowerBank in die Sonne Legt (oder eben sonnen Strahlen auf das Solarpannel treffen) fangen die "Ladezustands LEDs" in Form eines Lauflichts an zu leuchten - finde ich persönlich etwas dumm da das ja auch wieder Strom verbraucht aber nunja.... Wirklich zum Laden kann man das aber denk ich nicht verwenden, ein Tag (12h übern Tag) in der Sonne liegen gehabt und die "Ladezustands LEDs" zeigen keine Veränderung ; als die PowerBank hier ankam war der Akku zur Hälfte geladen.

    Leider hab ich mein Galaxy S3 versenkt (wörtlich :(), sonst würd ich mal ein Fotos vom derzeitigen RoPi hochladen... Hol ich aber selbstverständlich noch nach sofern mir nen Kollege mal seine Digicam leid :D

    Ich hab den PI jetzt im vorderen Bereich auf ein Stück Schaumstoff gelegt, da im Prototype Bereich wo ich aber oben drüber 2x 270 Kontakte Breadboards angebracht hab um meine Verkablung vorzunehmen. Auf den Breadboards hab ich auch den Compass aufgesteckt sowie 2 LEDs für Motor und Error (wie in meinem Sketch vorgesehen).
    Am Pan/Tilt ist oben der UltraSchall Sensor und da drunter die PiCam.. Sieht lustig aus, der US sind die Augen und die PiCam die Nase oder der Mund :huh: :lol:
    Ich muss jetzt nur noch Platz für die PowerBank schaffen - da weiß ich noch nicht genau wie ich die befestigen werde... Betreibe den PI zZt noch stationär übern Netzteil ;)

    Was mich bei ersten Tests aber schon sehr genervt hat sind die doch relativ lauten Motoren =(
    Und auch das sie bei einer PWM-Speed von <=30 nichts mehr machen sondern nur noch fiepen =(

    Ich hab meinen Sketch auch etwas umgeschrieben und in mehrere Dateien unterteilt, die aber natürlich alle in einem Ordner liegen:

    RoPi_Arduino_driver.ino - Hauptprogramm.

    Spoiler anzeigen

    IO_pins.h - Pin Konfiguration.

    Spoiler anzeigen

    constants.h - Konstanten Konfigurations Datei, also Statische Werte.

    Spoiler anzeigen

    notes.h - Speaker Tunes, um beim Startup/Powerup ein paar Töne über ein Buzzer auszuspucken..

    Spoiler anzeigen

    Binäre Sketchgröße: 22.048 Bytes

    Der Code ist aber selbstverständlich noch nicht fertig und im Hauptprogramm sind auch noch etliche Funktionen als Leichen enthalten und auskommentiert, da ich noch nicht sicher bin ob ich die brauche usw


    Beim WebIf bin ich zZt datei das noch mal ein bisschen umzukrämpeln - da ich keine Lust hab die default Werte aus dem Arduino Hauptprogramm, wenn ich da mal was änder, noch mal im WebIf Code ändern zu müssen...

    Deshalb hab ich mir überlegt die default Werte vom WebIf abrufen zu lassen wozu ich auch ein Problem-Frage-Thread erstellt hab: >> hier << :helpnew:

  • Nach einer etwas längeren Pause, in der ich mich auch vom Forum hier habe ablenken lassen (:D), hab ich mich mal wieder an dieses Projekt gesetzt und poste auch mal den aktuellen Status :)

    Wie in Beitrag#134 erwähnt habe ich mich zunächst noch um das Optionale WebInterface gekümmert - da ich Standard Werte nur am Arduino einstellen möchte aber nicht noch mal separat/extra im WebInterface..

    Bei diesen Umbauten ist mir dann auch aufgefallen das im RoPi_Socket.py und WebSocketControl.py noch ein Fehler war, und zwar das untereinander keine Werte/Antworten weitergereicht wurden...
    Das brauch ich jetzt aber, da ja der Arduino die defaultSettings ans RoPi_Socket.py übermittelt was diese dann in ein Dictionary speichert und sobald das WebSocketControl.py eine entsprechende Anfrage stellt werden die ausgelesen.

    Bei diesem Vorgehen ist mir dann schnell aufgefallen das ich diese Liste irgendwie terminieren muss, also festlegen wann das Ende der defaultSettings erreicht ist - da ich ja nicht hardcoded festlegen will wie viele oder welche Settings vorhanden sind, um das später flexibler erweitern zu können..

    Also habe ich das jetzt so aufgebaut:

    • Arduino wird gestartet und sendet am Ende von setup() die DEFAULT: Werte

      Da muss man die Werte halt leider noch händisch eintragen. Ob ich das später noch mal änder weiß ich nicht, aber vermutlich nicht da es mir sonst zu kompliziert wird ;)

    • Auf dem PI muss dann selbstverständlich die RoPi_Socket.py laufen, quasi das Herzstück des ganzen. Da ist ja eine Anweisung in der ich die Ausgaben des Arduino's bearbeite und die sieht nun wie folgt aus:

      Da seht ihr nun auch das ich auch currentValue speichere bzw updaten lasse. Es wird also immer der aktuelle Wert von zB distance (vom Ultraschall Sensor) im RAM hinterlegt, was ich mir dann nämlich auch ganz einfach vom WebIf abrufen und anzeigen lassen kann, aber dazu später mehr ;)

    • Erfolgt nun eine Anfrage vom WebInterface wird folgende Anweisung aufgerufen
      (aufs zZt wichtige gekürzt)

      Und hier seht ich auch schon "the magic" :)
      Ich lasse also jeden defaultSettings Eintrag in die returnlist eintragen und am Ende füge ich dann noch END:END ein um das Ende der Liste festzulegen. 2x END weil ich das später im WebIf einfacher handhaben kann.
      Sind aber noch keine Werte bekannt wird NONE:NONE zurück gegeben, was folgenden Hintergrund hat:
      Beim ansurfen des WebInterface's landet man erst auf einer Initialisierungs Seite auf der man erst eine Verbindung zum WebSocketControl.py herstellen muss. Solange noch NONE:NONE gesetzt ist kommt man nicht auf die eigentliche Control Seite, da ja noch die defaultSettings für diese Seite nicht bekannt sind.
      Achja: Die returnlist kann mehrere Werte beinhalten, deshalb nutze ich auch " += " und " \n " um eben alles auf einmal in einer Zeile senden zu können, das geht wesentlich schneller als alles einzeln zu senden. Im WebIf zerlege ich das selbstverständlich wieder..

    • Im WebIf war das ganze nun etwas tricky, da ich nicht jedesmal die Seite neu laden wollte und auch das empfangen der defaultSettings anfangs einige Probleme bereitet hatte... Zum einen musste ich sicherstellen dass das Abrufen der defaultSettings nur am Anfang versucht wird, also beim Aufruf der index.php, und zum anderen mussten die defaultSettings ja auch irgendwie Dateiübergreifend übernommen werden da ich ja anschließend die ropi.php laden wollte (die eigentliche Control Seite).
      Ich hab das nun so geregelt, das er beim Aufruf der Seite zunächst den WebSocket öffnet, besteht eine Verbindung ruft er die defaultSettings ab, was sich auch alle 3 Sekunden lang wiederholt solange er ein NONE:NONE zurück kriegt.
      Kriegt er aber kein NONE:NONE als Antwort wird das an die functions.php übergeben und zwar über einen Trick für den ich lange suchen musste:
      Um nicht bei jeder Übergabe einen page-reload zu kassieren bzw die functions.php direkt aufzurufen, nutze ich die in JavaScript eingebettete Klassen-Funktion Image() und als Source übergebe ich die Werte als $_GET an die functions.php:

      Code
      img = new Image();
      img.src='include/functions.php?'+value+'='+value2;


      In der functions.php wird folgendes gemacht:

      Und hier sieht man nun auch dass das nur ausgeführt wird solange man die index.php auf hat, denn sonst würde das weiterhin ausgeführt werden obwohl man bereits auf der ropi.php ist...

    Tja, also soweit erst mal noch das Update zum WebInterface.


    Auch muss ich mein RoPi_Socket.py noch mal's überarbeiten um Statische und Veränderbare Grundregeln einzubauen - mit dem Hintergrund das er sich selber optimieren kann.
    Beispielsweise würde eine Veränderbare-Grundregel besagten das er Standardmäßig immer erst nach Rechts gucken/fahren soll sofern er auf ein Hindernis trifft; stellt sich aber nach zB 20 Versuchen heraus das Rechts nicht effektiv ist da dort auch ein Hindernis ist und er deshalb ständig nach Links gucken/fahren muss, so dürfte er diese Regel nach 20 Versuchen selber auf die Entgegengesetzte Richtung abändern, was dann das Erkunden und Autonome Fahren hoffentlich beschleunigen würde..
    Was er wie verändern darf muss man aber auch Programmieren - sollte klar sein :)
    Statische-Grundregeln wie zB "nodes mit dem Wert 255 darfst du keinesfalls befahren" (weil zB Abgrund) darf er eben nicht verändern.


    Kopfschmerzen bereitet mir allerdings immer noch das erstellen einer Grid-Map bzw theoretisch weiß ich, was dafür nötig ist usw aber das WIE und ERSTELLEN ist mir weiterhin ein Rätsel :@

  • Hey ich bin gerade ganz zufällig über dein Projekt gestolpert. Verfolge ein ähnliches Projekt und hatte auch vor mir den selben Powerpack zu bestellen (den ohne Solarzellen). Hast du deine Powerpacks mittlerweile im Einsatz? Halten sie was sie versprechen? Meine Google Recherche zu diesen Powerpacks aus China hat eher ergeben, dass diese 20-30 Ah Powerpacks sich eher als 5-10 AH Powerpacks herausgestellt haben und somit sollte man vielleicht eher das Geld in einen guten 10-15 Ah Powerpack investieren. Und wie sieht es mit der Rpi Cam aus China aus? Möchte diese eventuell auch bestellen, da sie 5-10 Euro günstiger ist als die Orginale. Sollte man trotzdem zur Orginalen greifen?

    Viel Spaß dir weiterhin bei deinen Projekt.

    lg pipirasp

  • Also die große schwarze PowerBank-ohne-Solar hält knapp 24h Betrieb durch, worüber halt Arduino + RPI + WiFi + PiCam läuft... Ob das nun 30Ah oder weniger entspricht hab ich nicht nachgerechnet, mir reicht das auf jeden Fall :) Wobei ich mittlerweile lieber den mit Solar verwende da dieser kleiner und leichter ist.

    Die RaspiCam aus China läuft super, habe bisher nichts negatives feststellen können - ist eine normale rev1.3 . Dass das kein Original sein soll hör ich jetzt aber auch zum ersten mal - wo steht das :huh:


    PS: Hast du auch vor Mapping und Pathfinding zu realisieren? Wenn ja, wie machst du das? :)

  • Hey, ich habe keine genauen Projektvorstellungen. Ich habe einen alten Cybot auf den Dachboden gefunden ( war damals ein kleiner Roboter den man mit mehreren Zeitschriften schrittweise zusammenbauen konnte). Versuche von diesen so viel wie möglich wiederzuverwerten und möchte eigentlich nur einen kleinen Wlan oder Umts Rover bauen. Vielleicht packt mich der Ehrgeiz und ich erweiter das Projekt. Aber zurzeit eher atm. Aber viel Erfolg bei deinen Vorhaben, Mapping ist sehr interessant. Noch interessante wäre Mapping mit einen Quadrocopter, gibt dazu interessante youtube Videos.

    Zur Raspi Cam. Also viel das früher oder später aus China kommt und nicht vom Orginal Hersteller vertrieben wird ist meistens ein Nachbau.
    http://www.raspberrypi.org/forums/viewtopic.php?f=43&t=81500

    Bzgl deine Powerbank bin ich jetzt neugierig geworden. Eigentlich wollte ich nicht zu diesen Chinazeug greifen. Die Googlerecherche hatte eher negatives über diese Powerbanks ergeben. Sehr schnell kaputt, hat nicht mal die Hälfte von den angegebenen Ah etc. Aber deine Gufran (die ohne Solarzelle) hält 24h Betrieb aus`. Also Arduiono, Rpi, cam, Wlan auch Betrieb deiner DC Motoren oder hast du für diese seperate Akkus? Rechnerisch wären das Arduino 50mAh, RPI B 700 mAh, Wifi 100mAH, cam 100mAh, DC Motoren (wenn du sie über Akku verbrauchst) sagen wir mal 150mah dass heißt 1.1 Ah Verbrauch, wenn der Powerpack das 24h aushält, wären das um die 24-26 Ah, also fast die angegebenen 30 Ah. Ich habe in Bewertungen gelesen, dass die Dinger oft weniger als die Hälfte der angegeben mAh bereitstellen. Aber deine Erfahrung verblüfft mich jetzt etwas, vielleicht sind die Powerbanks mittlerweile auch besser geworden oder sie hatten Montagsprodukte. Wie sieht es mit den Ladezyklen aus? Hast du beim 2.-3. aufladen schon Einbußen bemerkt?

    Sry für die Fragen, aber wer unüberlegt kauft, der kauft zweimal.

    lg pipirasp.

  • Für die Motoren und das ExplorerPCB hab ich einen separaten Akku..
    WiFi und Cam benötigen soweit ich weiß mehr als die von dir angegebenen 100mA, wieviel das aber genau ist weiß ich nicht ;) Laut Raspberrypi.org wurde zumindest für die RaspiCam 1.0 ca. 250mA eingeplant, wieviel die rev1.3 verbraucht weiß ich aber nicht...
    Der WiFi Stick hat laut Spezifikationen eine MaxPower von 500mA, je nach Leistung bzw Frequenz usw wirds meiner Einschätzung nach bei umdie 200mA liegen..

    Inwiefern die Kapazität nach mehreren Ladezyklen abnimmt kann ich auch nicht beantworten - derzeit hab ich ihn nicht die ganze Zeit über Akku laufen da ich noch immer am entwickeln der Software bin und ihn daher stationär betreibe.
    Für den Preis wäre es aber aus meiner Sicht akzeptabel wenns etwas abnimmt - wer lässt sein Gefährt schon 24 Stunden lang an :huh: Zumal ich mir später auch noch eine Ladestation basteln möchte wo sich der Rover selber wieder aufladen könnte, also dann über Nacht.

  • So, lange tat sich hier nix, nun wirds mal wieder Zeit für ein kleines Update und am Ende auch ein Hilferuf :helpnew:


    Aktuell kämpfe ich ja damit eine GRID-Map zu erstellen, und hatte mir für diese schon damals ein Arduino EEPROM Shield With 256K AT24C256 gekauft.
    Dabei handelt es sich um einen nicht-flüchtigen Speicher dessen Daten auch nach ausschalten des Arduino's noch vorhanden sind.

    Es gibt auch die Möglichkeit einen einzelnen Chip zu verwenden, man muss also nicht gleich solch ein Shield nehmen, was dann auch billiger ausfallen würde: 24LC256

    Zwar hat jeder Arduino bereits einen EEPROM eingebaut, dieser ist aber mit 512Bytes bis 4kB doch relativ klein, und da ich noch nicht genau weiß wie groß meine MAP letztlich sein wird, bin ich mit 256kbit (also 32kB) auf jeden Fall auf der sicheren Seite keine Speicherplatz Probleme zu kriegen :fies:

    Ich hab mich für diesen Weg entschieden weil der Roboter auch nach gewolltem oder ungewolltem ausschalten weiter orientieren können soll und ich in sehr vielen Vorgehensweise-Anleitungen gelesen habe das man 2 verschiedene Maps nutzen soll: Eine lokale und eine globale. Die Lokale befindet sich auf dem Microcontroller und die Globale auf dem PI.

    Nachteil wie bei allen Flash Chips ist aber auch hier das diese Teile nicht unendlich viele Schreibzyklen vertragen. Ab 100000 soll es wohl Probleme geben. Lesen ist aber keine Belastung.
    Aber das betrifft eben auch den aufm Arduino verbauten EEPROM, also tausch ich lieber einen kleinen separaten Chip aus als später das nachrüsten zu müssen weil der aufm Arduino kaputt gheschrieben is...


    Spoiler anzeigen

    Das von mir verwendete Shield hat 4 kleine Dip Schalter. Über A0 , A1 und A2 kann die I2C Adresse bit-weise individuell eingestellt werden. Die Default Adresse ist 0x50 (in bits: 1010) und die letzten Stellen werden über die Dip-Schalter festgelegt. Ist der Dip-Schalter oben entspricht das einer 1, unten wäre 0. Wenn man also alle 2 Dip-Schalter nach oben stellt ist die i2c Adresse 0x57. Das erlaubt es bis zu acht solcher Chips verwenden zu können.
    Diese Dip Schalter machen übrigens nichts anderes als die Daten-Pins des Chips für 1 auf Vcc zu ziehen. Man kann das also auch problemlos ohne Shield setzen.

    Eine gute Anleitung dazu findet ihr >> hier <<


    Ich verwende zwar schon ein I2C Device nämlich den CMPS10 Kompass, dieser läuft aber über die I2C Adresse 0x60 also kann ich den EEPROM auch auf 0x50 lassen :)

    Auf pull-up Widerstände kann man in diesem Fall ebenfalls verzichten da die Wire.h für den Arduino weiß das über die SDA und SCL pins I2C genutzt wird. Verwendet man diese EEPROMs aber mit anderer Hardware wie dem PI oä. muss man jeweils für SDA und SCL zu Vcc einen sog. pull-up Widerstand selber einbauen, wie auch oben im Bild zu sehen.

    Nach einiger Recherche habe ich http://playground.arduino.cc/Code/EepromUtil entdeckt, womit es möglich ist Arrays, Integer und Strings in hoher Geschwindigkeit in den EEPROM abzulegen, was mit der Standard Library so leider nicht geht...


    Um das erst mal zu testen hab ich mir einen kleinen Sketch zurecht gebastelt welches zunächst den Internen EEPROM vom Arduino verwendet:

    Da ich nur jeweils eine, die aktuelle, Map im EEPROM halten will, brauch ich nicht auf den Adressbereich achten.
    Will man aber mehrere verschiedene Sachen (zB Einstellungen o.ä) im EEPROM ablegen, muss man den verfügbaren Speicher- bzw Adressbereich mit der jeweiligen Länge der zu speichernden Werte abstimmen sodass sie sich nicht überschneiden... Eine gutes Beispiel dazu ist auch >> hier << zu finden


    Problem mit dem Sketch ist jetzt allerdings, das es sich nicht kompilieren lässt =(

    Code
    RoPi_Arduino_driver.ino: In function 'void initializeEEPROM()':
    RoPi_Arduino_driver:1173: error: cannot convert 'int (*)[10][10]' to 'const byte*' for argument '2' to 'boolean eeprom_write_bytes(int, const byte*, int)'

    Weiß hier jemand Rat :huh:

Jetzt mitmachen!

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