Also, ich steh im wald, versuche aber morgen zu sortieren. Weiss nicht ob mir das gelingt...
Leute,
wo stehen wir gerade?
- Ist das noch ein Projekt mit dem RP6?
- Sind wir jetzt schon outdoor oder immer noch indoor?
- Wollen wir "dicke Batterien" auf einem Roboter und "schlanke Baken" oder den RP6 und Baken z.B. an einem USB-Netzteil?
- Wie relevant ist die Ultraschallfrequenz?
- Wer sendet was, wer empfängt was in IR oder US?
Ich blicke nicht mehr durch ...
Vorschlag: inka, würdest du mal sortieren, wo wir gerade stehen???
Gruß
Dirk
Also, ich steh im wald, versuche aber morgen zu sortieren. Weiss nicht ob mir das gelingt...
gruß inka
hallo allerseits,
das ist die quintessenz der beiträge ab meinem vorschlag eine bake 2.0 zu entwickeln. Bitte um nachsicht wenn ich etwas übersehen haben sollte und hinweis für eine korrektur (im originaldokument), es war wirklich viel text...
zusammenfassung für stromsparende bake:
- es ist (wie bake 1.0) primär eine bake für den RP6-base + m32, die hardware des RP6 (ACS? Und IRCOMM) soll auf der roboterseite primär zum einsatz kommen
- programmtechnisch über RP6-base, aber auch über RP6-base + m32 betreibbar
- durch geringe hardware- und software- anpassungen an der bake soll diese mit anderen systemen verwendbar sein (wie bake 1.0)
- anzahl der baken soll bis 8 erweiterbar sein
- hardware der bake so ausgelegt, dass sie keine software-unterstützung von außen braucht
- outdoor und indoor einsetzbar, reichweite 10m
- geringer stromverbrauch der bake, akku bei outdoor verwendung durch solarzellen aufladbar
- indoor mit 5v (USB) stromversorgung
- positionsgenauigkeit des roboters +- 5cm
- bake hat US-empfänger (geringer stromverbrauch), roboter US-sender
- kommunikation bake <-> roboter und/oder bake <-> bake mit IR
- die bake „schläft“ im standby bis sie ein IR-signal vom roboter empfängt und antwortet dann per IR
- für eine positionsbestimmung des roboters werden zwei baken gebraucht
- wenn roboter die IR-signale der bake(n) empfängt, sendet er gleichzeitig ein IR und US-signal, die bake(n) errechne(n) aus der laufzeitdifferenz die entfernung zum roboter und teilen ihm seine position mit
- kosten max. 150€ für zwei baken
Geändert von inka (13.06.2014 um 16:41 Uhr) Grund: empfänger beim roboter entfernt, titel hinzu
gruß inka
Ich würd mich, was die Lademöglichkeit der Baken angeht, nicht festllegen. Das sollte jeder selber lösen können-nach seinen Anforderungen.
Weiter braucht der Roboter (für _die_ Geschichte) keinen US-Empfänger- die Bake kann eh nix senden.
Und: so teuer wird das nicht. Da ich derzeit recht viel mit Arduinos rumspiele, weiss ich, dass man ne Miniausführung davon für 3-5€ bekommt.
Dazu ne Lipo-Lader-Platine (um die 2€) kleiner LiPo (ne Smartwatch mit Bluetooth läuft mit nem 110mAh-Akku sechs bis acht Stunden), US-Sensor mal grob 1.50 (kann mehr werden, falls die billigen nich empfindlich genug sind, man _muss_ den Sender-Teil ja nicht nutzen), dazu noch die IR-Schnittstelle (paar ordentliche IR-Dioden, einige Empfänger)- ich schätze, das geht für nen 50er locker ab, pro Stück.
Und: da wäre noch Platz für einige Optionen (einstellbare Adresse, Akkuanzeige z.B.). Viel mehr brauchts meiner Meinung nach in der Bake gar nicht.
Oder?
Grüssle, Sly
..dem Inschenör ist nix zu schwör..
Hi inka und alle,
danke für deine Zusammenfassung!
Hier noch kurz meine Meinung dazu:
Ich brauche keinen outdoor Einsatz, weil der RP6 dazu eh ungeeignet ist. Die Reichweite von 10m ist zwar schön, aber in einer "normalen" Wohnumgebung reichen auch 5m. Dafür kann man sicher auch billigere US-Sender/-Empfänger bekommen.outdoor und indoor einsetzbar, reichweite 10m
Über das Thema Stromversorgung würde ich nochmal nachdenken wollen. Eigentlich sollte ein mobiler Roboter möglichst leicht und stromsparend aufgebaut sein. Dazu passt nicht, dass wir die Baken energetisch autonom machen wollen und den Roboter mit mehr Batteriekapazität ausstatten wollen, um z.B. den US-Sender da draufzubauen.geringer stromverbrauch der bake, akku bei outdoor verwendung durch solarzellen aufladbar
indoor mit 5v (USB) stromversorgung
...
bake hat US-empfänger (geringer stromverbrauch), roboter US-sender und empfänger
Ich würde es umgekehrt sehen:
Der Roboter sollte so wenig Strom wie möglich verbrauchen, um eine hohe Betriebszeit zu erreichen. Bei einer (indoor-) Bake ist mir der Stromverbrauch egal: Die kann auch mit einem Netzteil an einer Steckdose hängen.
Wenn man das Stromversorgungsthema (s.o.) mal außer Acht läßt, dann wäre die IR-Kommunikation einfacher, wenn der mobile Roboter selbst die Entfernung berechnen würde (d.h. er den US-Empfänger trägt). Mir ist dabei klar, dass man mit Störungen durch den Körperschall des fahrenden Roboter rechnen muss,- müßte man testen, ob ein Ping der Bake identifizierbar ist trotz des Störpegels. Auch die Tatsache, dass er überhaupt während einer Messung evtl. fährt macht das nicht leichter: Dies gilt aber für beide US-Richtungen.wenn roboter die IR-signale der bake(n) empfängt, sendet er gleichzeitig ein IR und US-signal, die bake(n) errechne(n) aus der laufzeitdifferenz die entfernung zum roboter und teilen ihm seine position mit
Die "US-Ping-Anforderung" durch den mobilen Roboter per IR sehe ich unkritisch: Evtl. Verzögerungen durch Verarbeitungsprozesse auf dem RP6 und der Bake dürften sehr konstant sein und sich herausrechnen lassen.
Was denkt ihr?
Gruß
Dirk
ich habe jetzt in der zusammenfassung (post 153) den US-empfänger beim roboter rausgenommen und eine überschrift hinzugefügt, dass es eine zusammenfassung für eine stromsparende bake ist. Evtl. sollte ich die andere variante noch machen? Aber diskutiert jetzt erstmal - ich lausche zu![]()
gruß inka
Dirk: hast du nen Testlabor, bei dem im Meterabstand Steckdosen am Boden verteilt sind?
Ich nicht, und grad der RP6 ist nun sicher auch nicht von überall herumliegenden Kabeln begeistert.
Wenn das Ganze auch nur _einigermassen_ flexibel sein soll, ists am sinnvollsten, die Baken mit nem Akku zu bestücken. Auch für reinen RP-6-Betrieb.
Dennoch ist ja keinem die Möglichkeit genommen, meinetwegen externe Strombuchsen in den Baken zu verbauen, ganze Netzteile oder nen kleines Atomkraftwerk.
Das Thema Stromversorgung würd ich einfach mal hintenan stellen-kann sich jeder stricken, wie ers haben will. Wenn ihr (RP6-Besitzer) eben lieber Netzstrom benutzen wollt, macht ruhig- da bastele ich mir schon was, wenns soweit ist.
Ausserdem: wenn du mehrere US-aktive Baken hast, wirst du nicht umhin kommen, die gezielt einzeln abzufragen (grade Indoor!) weil sonst durch Echo usw. ein einziges Kauderwelch beim Roboter ankommt.
Du hast dann _mehrere_ US-Sender und musst die wieder koordinieren. Mit einer einzigen Schallquelle (vom Roboter) taucht das Problem gar nicht erst auf. Und mit Infrarot dürfte die Kommunikation um kleine Welten schneller sein als per Ultraschall.
Was die einfachere Kommunikation angeht: ich kenn den RP6 nicht persönlich (will sagen, angeguckt schon, hab aber keinen)- so schwer kann das doch nicht sein mit dem Ding? Sowas hab ich vor >10 Jahren schon mit LEGO-RCX`en gemacht.
Eine gewisse "Intelligenz" brauchen die Baken sowieso (schon, damit der Roboter sie voneinander unterscheiden kann), da ist also eh nen Rechenknecht drin. Und ob der nen Lämpchen irgendeinen Text blinken lässt, oder seine Ansage per Ultraschall trötet, ist dem Kerlchen egal.
Was ich nun nicht weiss: warum willst du diese Änderungen im Plan?
Gibt der RP6 das _so_ ohne grössere Basteleien nicht her?
Grüssle, Sly
..dem Inschenör ist nix zu schwör..
Hi Rabenauge,
tatsächlich kann man die Stromversorgung ja individuell planen. Bei der Szenerie, in der der Roboter in einem Zimmer herumfährt, sehe ich bei 2 Baken z.B. in den Raumecken keine Gefahr von Kabelsalat. Aber klar: Das geht auch mit Akku.
Ja, natürlich muss ich die Baken als US-Sender einzeln ansteuern, das würde ich vom RP6 aus über IR in Form einer Adresse machen. Ich muss dann eigentlich nichts koordinieren, bzw. der Roboter kann mit eigener "Intelligenz" auch entscheiden, welche Bake er ansteuern will (z.B. weil er erkannt hat, dass sie in der Nähe liegt und eine Positionsbestimmung durch sie aussichtsreich ist).Ausserdem: wenn du mehrere US-aktive Baken hast, wirst du nicht umhin kommen, die gezielt einzeln abzufragen (grade Indoor!) weil sonst durch Echo usw. ein einziges Kauderwelch beim Roboter ankommt.
Du hast dann _mehrere_ US-Sender und musst die wieder koordinieren. Mit einer einzigen Schallquelle (vom Roboter) taucht das Problem gar nicht erst auf. Und mit Infrarot dürfte die Kommunikation um kleine Welten schneller sein als per Ultraschall.
Gibt es nur einen US-Sender auf dem Roboter, wird das m.E. nicht zwangsläufig einfacher, weil man dann auch koordinieren muss, in welcher Form und Reihenfolge alle angepingten Baken ihre Ergebnisse dann über IR an den Roboter senden. Das ist sicher auch machbar, muss aber in Form eines Protokolls und eines Zeitschemas sicher gestellt werden.
Ich meine: Es ist nicht so eindeutig möglich, sich mit dem Aspekt der Koordination der Kommunikation für eine der beiden Optionen zu entscheiden.
FÜR den Sender auf dem Roboter spricht für mich fast nur das Argument der störungsfreieren US-Laufzeitmessung in den Baken. GEGEN diese Lösung spricht der höhere Strombedarf auf dem Roboter und die Tatsache, dass der Roboter nicht direkt selbst über das Messergebnis verfügt, sondern es erst noch von den Baken geschickt bekommen muss.
Eine IR-Kommunikation ist mit dem RP6 gut möglich, auch ohne weitere Hardware. Was meinst du?Was die einfachere Kommunikation angeht: ich kenn den RP6 nicht persönlich (will sagen, angeguckt schon, hab aber keinen)- so schwer kann das doch nicht sein mit dem Ding? Sowas hab ich vor >10 Jahren schon mit LEGO-RCX`en gemacht.
Es gibt aktuell nur eine tolle Sammlung von Erfahrungen und Meinungen, aber noch keinen Plan.Was ich nun nicht weiss: warum willst du diese Änderungen im Plan?
Gibt der RP6 das _so_ ohne grössere Basteleien nicht her?
Auf den RP6 kann man auch fast alles draufsetzen,- gar kein Problem.
Es geht mir nur darum, Lösungen nicht vielleicht zu schnell "festzustampfen", sondern ein Nachdenken noch zuzulassen.
Gruß
Dirk
Klar-Nachdenken ist immer gut.
Ich kann aber deine Argumente nicht nachvollziehn. Draum frage ich nach-ich seh einfach in deinen Ansätzen irgendwie keine Vorteile.
-Baken brauchen nicht "mehr Strom haben als der Roboter"- wenn der ans Ladegerät muss, haben auch die Baken Pause.
Meine Idee, die Baken _aufm_ Roboter wieder aufladen zu können, ist schon nen paar Stufen weiter gedacht und macht, zuegegebenermassen in der Wohnung, und mitm RP6, keinen Sinn.
Das bringt _erst_ dann was, wenn ich mit dem Ding wie andere mit Hunden, Gassi gehn kann. Dann will ich weder ne Kabelrolle hinterherschleppen, nach ne pfundschwere Bake am Gürtel hängen haben.
Ausserdem heisst outdoortauglich robust: je kleiner und leichter sowas wird, umso mehr steckts weg.
Dein Einwurf, dass mobile Roboter halbwegs ressourchenschonend arbeiten sollen (oder so ähnlich), dem stimme ich zu.
Was aber braucht mehr Ressourcen (Hardware, Strom) ? EIN US-Sender aufm Roboter oder sechse davon-einer in jeder Bake?
Da sollte man immer das Gesamtsystem im Auge behalten.
Sicher, die Baken müssen die Entfernung berechnen aber uns allen ist wohl klar: ohne nen Controller in den Baken wirds eh nichts. Den brauchst in jedem Fall (jedenfalls, wenn wirs nicht allzu primitiv lösen wollen)- wieso sollte der nicht auch das bisschen Entfernung berechnen?
Kommuniziert werden muss sowieso, also kann die Bake, neben ihrem Namen, auch gleich noch die Entfernung mit senden. Das sind nen paar Morsezeichen mehr....
Softwaremässig nicht schlimm, da das einzige, was bei jeder Bake anders sein sollte, die "Seriennummer" ist-alles andere nicht. Eine Konstante im Code verändern und ab auf die nächste damit.
Da du von 5m Reichweite sprichst komm ich noch mal auf die spottbilligen hc-sr04 zurück: Stromverbrauch weiss ich jetzt nicht (wart immer noch auf den Sack voll), aber das Ding ist gaaanz easy anzusteuern: einen Pin brauchst zum triggern, einen zum Echolaufzeit messen. Mehr isses nich...
Dürft sich nahezu an _jedem_ Roboter verbauen lassen. Schöner wäre natürlich I2C-aber das ist für den Preis dann wohl nicht zu haben.
Und 5m schaffen die Dinger ungefähr (angegeben sind sie mit 4).
Grüssle, Sly
..dem Inschenör ist nix zu schwör..
Hi Rabenauge,
Ich hatte nicht über die ökologische Bilanz des Gesamtsystems gesprochen, sondern nur über einen möglichst stromsparenden Aufbau von mobilen Robotern.Was aber braucht mehr Ressourcen (Hardware, Strom) ? EIN US-Sender aufm Roboter oder sechse davon-einer in jeder Bake?
Wahrscheinlich liegt da der "Hase im Pfeffer": Ich will mit dem RP6 nicht outdoor Gassi gehen, sondern eine indoor Navigation einfach und kostengünstig aufbauen.Meine Idee, die Baken _aufm_ Roboter wieder aufladen zu können, ist schon nen paar Stufen weiter gedacht und macht, zuegegebenermassen in der Wohnung, und mitm RP6, keinen Sinn.
Das bringt _erst_ dann was, wenn ich mit dem Ding wie andere mit Hunden, Gassi gehn kann. Dann will ich weder ne Kabelrolle hinterherschleppen, nach ne pfundschwere Bake am Gürtel hängen haben.
Ausserdem heisst outdoortauglich robust: je kleiner und leichter sowas wird, umso mehr steckts weg.
Wenn unsere Ziele nicht identisch sind, können Argumente leider auch aneinander vorbei gehen oder gegenseitig unverständlich sein.
Es geht um eine möglichst einfache Kommunikation. Bei dem von mir vorgeschlagenen Ablauf (IR-Ping Anforderung durch den RP6, adressierte Bake sendet US-Ping, dessen Laufzeit durch den Roboter gemessen wird) ist die Kommunikation minimal und besteht nur aus dem IR-Versand einer Adresse gefolgt ggf. von einem "Startsignal". Im Idealfall ist keinerlei weitere Kommunikation nötig.Kommuniziert werden muss sowieso, also kann die Bake, neben ihrem Namen, auch gleich noch die Entfernung mit senden. Das sind nen paar Morsezeichen mehr....
Sehe ich auch so. Die Dinger sind gut und billig.Da du von 5m Reichweite sprichst komm ich noch mal auf die spottbilligen hc-sr04 zurück: Stromverbrauch weiss ich jetzt nicht (wart immer noch auf den Sack voll), aber das Ding ist gaaanz easy anzusteuern: einen Pin brauchst zum triggern, einen zum Echolaufzeit messen. Mehr isses nich...
Gruß
Dirk
Lesezeichen