IR-bake

[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

[Rabenauge]

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?

[Dirk]

Hi inka und alle,

danke für deine Zusammenfassung!

Hier noch kurz meine Meinung dazu:

outdoor und indoor einsetzbar, reichweite 10m

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.

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

Ü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.
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 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

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.
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?

[inka]

Hallo,
mein vorschlag wäre, dass wir die drei punkte um die es hier geht -
- reichweite
- US senden von der bake oder roboter
- stromverbrauch bake und roboter

so lösen, dass hardwaremäsig jeweils beide optionen möglich sind (einmaliger aufwand auf der leiterplatte) und softwaremäsig als option in der library zu- bzw. abschaltbar sind. Wir stochern ja momentan ohne ausnahmen m.e. nach im dunkeln, müssten eigentlich beide versionen testen. Zu hardware - und software wären wir hier bestens aufgestellt: rp6 - Dirk, RolfD und bake-seite (arduino) Rabenauge. Wäre das ein vorschlag?

[Dirk]

Hi,
guter Vorschlag. Weil ...
- Reichweite: Da können wir uns -denke ich- an erhältliche US-Module anpassen (z.B. HC-SR04), ohne eine 10m oder 5m Vorgabe.
- US Senden von der Bake oder Roboter: Hardwaremäßig können wir auf beiden Seiten (RP6 und Baken) die hc-sr04 vorsehen,- welche Richtung wir dann nehmen, können wir (nach Vorliegen der konkreten Hardware) ausführlich testen.
- Stromverbrauch: Ist eher ein Randthema und auch kaum noch von Bedeutung, wenn wir beide US-Senderichtungen eh einplanen.

Das Modul hc-sr04 habe ich mir nochmal genauer angesehen:
Erst hat mich der effektive Messwinkel von 15° irritiert (Datenblatt bei Elec Freaks). Das ist natürlich eigentlich toll,- ein sehr kleiner Messwinkel ist eigentlich gut.
Andererseits bräuchte man für eine "Rundumsicht" (zumindest für den Empfänger) dann 24 Module.
In einem anderen Datenblatt (ITead Studio) ist aber von 30° die Rede, in denen man gut messen kann.
Dann bräuchten wir theoretisch 12 Module im Kreis angeordnet.
Die müßte man dann senkrecht nebeneinander oder in 2 Ebenen waagerecht übereinander (um 30° versetzt) einbauen, damit der Kreis auf dem Roboter nicht zu groß wird.
Das selbe Thema entsteht auf der Bake:
Für Winkel von 90..180° (d.h. eine Bake steht immer am Rand und nie in der Mitte des Raums) bräuchten wir dann ja auch 3 oder 6 Module.

Sehe ich das richtig?

[inka]

Hi,Erst hat mich der effektive Messwinkel von 15° irritiert (Datenblatt bei Elec Freaks). Das ist natürlich eigentlich toll,- ein sehr kleiner Messwinkel ist eigentlich gut.
Andererseits bräuchte man für eine "Rundumsicht" (zumindest für den Empfänger) dann 24 Module.
In einem anderen Datenblatt (ITead Studio) ist aber von 30° die Rede, in denen man gut messen kann.
Dann bräuchten wir theoretisch 12 Module im Kreis angeordnet.
Die müßte man dann senkrecht nebeneinander oder in 2 Ebenen waagerecht übereinander (um 30° versetzt) einbauen, damit der Kreis auf dem Roboter nicht zu groß wird.
Das selbe Thema entsteht auf der Bake:
Für Winkel von 90..180° (d.h. eine Bake steht immer am Rand und nie in der Mitte des Raums) bräuchten wir dann ja auch 3 oder 6 Module.

Sehe ich das richtig?

ich glaube schon, allerdings würde ich dann 2 hc-sr04 (back to back) auf einem sich hin und her drehendem servo haben wollen. Die 12 module ist ja horror, von 24 ganz zu schweigen...

übrigens kenne ich SRF04 - ist es das gleiche?

[Rabenauge]

Deswegen war ich von Anfang an gegen die Richtungsbestimmung per Ultraschall...die Dinger haben irgendwas zwischen 15 und 30 Grad würd ich sagen.

Zugegeben: nen Dutzend der Teile kosten nur nen Zehner aber trotzdem ist das zu viel und-grad aufm RP-wohl auch bisschen gross.
Da ist doch ein Ring aus IR-Dioden entschieden handlicher?
Mit denen kann der Roboter bestimmen, aus welcher Richtung die gewünschte Bake sendet, und dann wahlweise den _einen_ US-Sensor dorthin richten (per Servo, oder wie mans möchte) oder sich im Ganzen drehn.
Auch sind IR-Dioden recht einfach optisch abzuschirmen, dass jede wirklich nur ihren Vektor abbekommt .

Damit _das_ nicht zu viele sind, würd ich z.B. sechs Stück vorschlagen. Wenn sich die Empfangsbereiche nen bisschen überlappen (ideal wären 15 Grad zur jeweils benachbarten, das ergibt praktisch die doppelte Auflösung), kann man damit schon ausreichend genau die Richtung feststellen, denke ich.

Nein, die SRF sind nicht die selben. Die hc-sr04 sind mit 4m angegeben, schaffen aber bis zu 5m, und kosten echt pro Stück 1.20 oder so.
Ich hab neulich von denen zehn Stück in China geordert für rund acht €.
Von der Handhabung her aber wohl identisch.

[Dirk]

@inka:

allerdings würde ich dann 2 hc-sr04 (back to back) auf einem sich hin und her drehendem servo haben wollen. Die 12 module ist ja horror, von 24 ganz zu schweigen...

Ja, das wären schon recht viele Module und man sollte eine Alternative überlegen. Vielleicht wäre es eine Option, einen Sender/Empfänger nach oben gerichtet einzubauen mit einem 120° Reflektor-Kegel darüber. Dafür gibt's ja im Netz auch Bauvorschläge.
Die "Drehlösung" finde ich nicht sooo gut, weil eine Ausrichtung viel Zeit braucht und problematisch ist, wenn man mehrere Baken anvisieren will (s.u.).

@Rabenauge:

Da ist doch ein Ring aus IR-Dioden entschieden handlicher?
Mit denen kann der Roboter bestimmen, aus welcher Richtung die gewünschte Bake sendet, und dann wahlweise den _einen_ US-Sensor dorthin richten (per Servo, oder wie mans möchte) oder sich im Ganzen drehn.
Auch sind IR-Dioden recht einfach optisch abzuschirmen, dass jede wirklich nur ihren Vektor abbekommt .

Das scheint das ja auf den ersten Blick eine Möglichkeit zu sein. In der konkreten Umsetzung habe ich da so meine Probleme:
Von einem fahrenden Roboter aus sollen Baken per IR geortet werden, um dann den US-Sender oder Empfänger auf dem Roboter in Richtung einer Bake zu drehen und dann per US die Distanz zu dieser Bake zu messen.
Das ist sehr schwer zuverlässig umzusetzen: Bei mehreren Baken ist der Bot ständig mit der "Sensor-Dreherei" beschäftigt. Die IR-Ortung ist wegen der Reflexionen im Raum sehr unzuverlässig. Die Baken müßten das IR-Licht auch gezielter in den Raum strahlen, damit eine Ortung möglich ist. Das würde aber die Nutzung von IR zur allg. Kommunikation unmöglich machen. Wenn man zudem die Baken addressiert anspricht, müßte jeder (der z.B. 6) Sektor-IR-Empfänger diese Adressen auch getrennt dekodieren können und ggf. eine Drehung des US-Sensors zur richtigen Bake veranlassen. Das System wird dann hoch fehlerträchtig und schwer zuverlässig zu programmieren.

[Rabenauge]

Hm ja, drinnen....könnt ihr die Robbis nicht bissle grösser machen und dann draussen...?

Was die Ortung bzw. die Identifikation angeht-da seh ich keine ernsthaften Probleme: wenn _einer_ der IR-Sensoren Signal hat, les ich den eben aus und lass die anderen in Ruhe.
Zudem: nen kurzer Stopp wird wohl drin sein, wenn du aus der Bewegung raus orientieren willst, hast du spätestens bei der US-Entfernungsmessung eh Probleme.

Im Grunde dachte ich daran, die IR-Sensoren einfach ringsum abzufragen, das geht allemal schnell genug (oder nich, aufm RP6?) das kann man ggf. permanent machen, wenn man eine Bake sucht, dann _müssen_ die eben länger als ne Millisekunde blinken.
Und wenn ich mal weiss, wo die gesuchte Bake steht-also nen Sensor per Servo schwenken dauert Sekundenbruchteile....
Wenn ich mehrere Baken empfange (per IR) und grob weiss, als welchen Richtungen, kann ich sogar während der Fahrt, völlig ohne Ultraschall, halbwegs triangulieren.
Aber stimmt: das Problem mit den Reflexionen bleibt. Bei Ultraschall übrigens auch, dort eher noch schlimmer.