IR-bake

[Dirk]

@Rabenauge:

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

Da du dich hier so engagiert beteiligst eine Frage:
Was hast DU eigentlich für einen Roboter? Für welche Plattform suchst du ein Baken-System?

[RoboHolIC]

Die von dir angesprochene "komplette Empfangsschaltung" ist bei den hc-sr04 bereits eingebaut!
Die Dinger sind betriebsfertig: ein Pin löst das Signal aus, und der zweite wartet, was ankommt.

Ja und nein! Der Echo-Pin gibt ein Signal aus, das (grob) vom Triggerssignal beginnend so lange aktiv bleibt, bis ein Echo erkannt wurde, maximal jedoch bis zu einer TimeOut-Zeit von ca. ?50ms?, die deutlich über der Echozeit der spezifizierten Reichweite liegt.
Ist schon bekannt, wie dieser funktionale Verbund aufgetrennt werden kann, sodass Sender und Empfänger unabhängig voneinander nutzbar sind? Umprogrammierung? Hardware-Mod?

[Rabenauge]

@Dirk: so ein Bakensystem soll mein grosser bekommen. Den gibts noch nicht, er reift aber momentan in kopf und 3D allmählich vor sich hin.
Ursprünglich sollte es ein 1:16er Panzer-Chassis werden, aber das ist ne Nummer zu klein. Wird _ähnlich_ dem R`Rex-Chassis, nur nich so teuer, da ich zwar ähnliche Komponenten verwenden will, aber selber bauen.
Von kleinerem bin ich weg-hab auch ne etwas aufgerüsteten NiboBee (LiPo,DOGM-Display,Sharp IR-Sensor mit Servo), dafür ist meine Bude einfach bisschen eng, das macht nicht wirklich Spass hier.

Momentan bastle ich an nem Spielzeugbuggy, der Arduinisiert wurde, und an nen paar Sachen, die "Roboter" eher nich zu nennen wären, aber meist ist auch nen Arduino irgendwie in der Nähe.
Da mein Vorhaben etwas grösser (und kostspieliger) wird, plan ich das so weit als möglich durch und versuche, einzelne Sachen vorher zu testen.
Der Buggy ist im weiteren Sinne auch dafür: der soll auch mal draussen nen bisschen rumnavigieren (falls ich den Kompass brauchbar ans laufen bekomme) *grmbl

[Klebwax]

Ja und nein! Der Echo-Pin gibt ein Signal aus, das (grob) vom Triggerssignal beginnend so lange aktiv bleibt, bis ein Echo erkannt wurde, maximal jedoch bis zu einer TimeOut-Zeit von ca. ?50ms?, die deutlich über der Echozeit der spezifizierten Reichweite liegt.
Ist schon bekannt, wie dieser funktionale Verbund aufgetrennt werden kann, sodass Sender und Empfänger unabhängig voneinander nutzbar sind? Umprogrammierung? Hardware-Mod?

Wie das beim SR04 funktioniert weiß ich jetzt nicht. Ich kenne aber Module ähnlicher Bauart, bei denen die Empfindlichkeit des Empfängers aktiv geregelt wird. Die Intensität des Echos nimmt ja mit der Entfernung ab. Die Verstärkung des Empfängers wird nach dem Aussenden des Pings stetig erhöht, da ja das Echo immer schwächer wird. Außerdem wird der Empfänger währendes Pings deaktiviert, machmal auch der Piezo kurzgeschlossen, um Übersteuerungen zu vermeiden.

MfG Klebwax

[Dirk]

Hi Leute,

nach den vielen Ideen hier würde ich euch fragen, ob eine Art "universelle" US-/IR-Bake denkbar ist.
Wenn ja, könnte man ja eine Platine designen, die einige unterschiedliche Navigations-Konzepte ermöglicht,- entweder dadurch, dass man sie nur jeweils teilbestückt oder bestimmte Funktionen de-/inaktiviert.

Dazu ein paar Fragen bzw. auch schon Design-Entscheidungen zur Bake:
1. Stromversorgung:
-- a) Versorgungsspannung 3,3..5V
-- b) USB-A-Anschluß zur Direktversorgung der Bake
-- c) Ladung eines internen Akkus über USB
-- d) Ergänzungsladung durch kleines Solarpanel (Anschluß vorsehen)
2. Sensorik/Aktoren:
-- a) US-Sender und -Empfänger mit Rundumsicht bzw. mind. 180° Sicht
-- b) US-Sender und -Empfänger einzeln direkt ansprechbar (keine I2C- oder seriellen Typen)
-- c) Reichweite US bis 5m
-- d) Vorabentscheidung, wie viele US-Sender/-Empfänger max. zum Einsatz kommen werden!
-- e) Parallel zu d) die Entscheidung, ob ein/zwei Kegelreflektor(en) zum Einsatz kommt/kommen (bei nur 1 US Sender/Empfänger)
-- f) IR-Sender und -Empfänger mit Rundumsicht bzw. mind. 180° Sicht zur Kommunikation in einem 5x5m Raum (z.B. über Decken-Reflexion)
-- g) IR-Kommunikation z.B. als RC5-Code oder eigener Code
-- h) IR-Kommunikation prinzipiell möglich als: Bake-Bake, Bake-Roboter, Roboter-Roboter
-- i) Entscheidung über die "Masterfunktion" einer Bake, über die nur die Kommunikation Baken-Roboter läuft (kann auch später entschieden werden, da dies die Hardware nicht beeinflussen dürfte)
-- j) Lichtkennung der Bake zur Lichtortung durch den Roboter mit mind. 180° Ausstrahlung horizontal in den Raum (ggf. nach oben und unten schlitzartig begrenzt!)
-- k) Lichtkennung z.B. fest impulscodiert oder mit festem RC5-Kenn-Code (bis zu 8 Codes möglich?)
-- l) Lichtkennung dimmbar zur Verminderung von Reflexionen
-- m) Evtl. Farbkennung der Lichtkennung (setzt Farberkennung auf dem Roboter voraus)
3. Ansteuerung der Bake:
-- a) Vorab definierter Stecker/Pinleiste mit allen Verbindungen zu den o.g. Sensoren/Aktoren und der Stromversorgung
-- b) Prozessorsystem mit 3,3..5V I/O-Ports oder GPIOs
-- c) Keine Festlegung auf ein bestimmtes Prozessorsystem
-- d) Mindestanforderungen: Laufzeitmessungen im µs Bereich müssen möglich sein, Anzahl der I/O-Ports muss ausreichend sein, gut wären einige Hardware-PWM-Ports, EEPROM-Speicherplatz für dauerhafte Settings (alles noch genauer anhand der Punkte oben zu spezifizieren!!!)
-- e) Ein Sleep-Modus mit minimalem Stromverbrauch
-- f) Externe Aktivierbarkeit durch die IR-Kommunikation

[Rabenauge]

Klingt toll. so stelle ichs mir vor- dann haben möglichst viele was davon.
Aber: eigene Platine?
Klingt wiederum teuer. Auch wenn man die in ner Kleinserie machen lässt wird das nicht soo preiswert. Drauf muss auch noch was.
Ich weiss: viele mögen die Arduinos nicht, aber ich werf mal http://arduino.cc/de/Main/ArduinoBoardProMini in den Raum.
Zu bekommen unter 5€ beim Chinesen...fertig aufgebaut.
13 digitale Pins, davon 6 als PWM-Ausgänge ohne weiteren Zauber nutzbar, 6 analoge Ausgänge, gibts sowohl für 3.3V als auch für 5V, Grösse 1.8cmx3,5cm.
Läuft ab 3.3V (Versionsabhängig, gibt auch die 5V-Variante), und mit bis zu 12V.
Wäre meine erste Wahl-nich, weils nen Arduino ist aber preiswerter geht nicht-auch nicht im Eigenbau.
Programmieren kann man das Ding bequem per USB, braucht dazu nen Adapter, der auch in der Gegend kostet (einen für egal wieviele Baken nur).
Durch die Möglichkeit, normale Steckleisten einzulöten, kann man die Zubehör-Platine einfach huckepack drauf löten, und gut.

Das Gleiche liesse sich als Roboter-Erweiterung bauen, I2C, SPI ist _auch_ vorhanden!
Anstecken, und läuft.

[Dirk]

Aber: eigene Platine?
Klingt wiederum teuer. Auch wenn man die in ner Kleinserie machen lässt wird das nicht soo preiswert.

Alternative? Steckbrett? Freiverdrahtung?

Ich weiss: viele mögen die Arduinos nicht, aber ich werf mal http://arduino.cc/de/Main/ArduinoBoardProMini in den Raum.
Zu bekommen unter 5€ beim Chinesen...fertig aufgebaut.

Kann man nehmen. Wenn wir nach 3. c) uns aber nicht auf ein bestimmtes Prozessorsystem (das wäre ja der Arduino) festlegen wollen, müssen wir das nicht VOR der Konstruktion der Baken klären.

[Rabenauge]

Sowieso.
Von daher wärs am sinnvollsten, einfach nur die Peripherie (alles was nach dem Controller kommt) zu entwerfen. Dann kann den Rest jeder so machen, wie ers haben möchte. Vielleicht gar mit ner I2C-Schnittstelle? Das wäre ungefähr das Optimum, da man dann _noch_ weiter aufbohren kann, wenn mans will.
Passt dann an fast alles...

Aufbau: am besten wohl auf Loch-oder Streifenraster. Dann ist das jederzeit von jedem selber zu bauen. Bei einer Kleinserie muss sich irgendjemand erst die Mühe machen, Interessenten zusammenzusammeln (von denen dann die Hälfte wieder abspringt), das Dutzend Platinchen zu organisieren, und nach nem halben Jahr kommen wieder zweie an und wollen auch...
Daher ists besser, wenn mans so macht, dass jeder sich die Pläne schnappen, und loslegen kann, auch ohne ne Ätzanlage zu haben. Wer _die_ hat, hat diese Option ja trotzdem.

[Besserwessi]

Für den µC macht eine fertige Platine ggf. schon Sinn. Allerdings braucht man wohl schon etwas mehr als nur den µC. Die Ausgänge der µC Platinen sind in der Regel nicht kräftig genug um eine IR LED für eine größere Reichweite zu treiben. Auch beim US Transducher braucht es noch etwas dazu: Treiber für die Sendefunktion und eine Verstärkung für die Empfangsfunktion, Selbst die IR Empfänger brauchen noch Widerstand / Kondensator und müssen ja auch irgendwie fest gemacht werden.

Das fertige US Modul könnte man wohl so modifizieren das es nur empfängt, getriggert von einem Externen Signal (z.B. IR Signal das gleichzeitig ausgesandt wird). Im einfachsten Fall halt einfach den einen Transducer für das Senden entfernen und per IR das Startsignal erzeugen. Ob das allerdings lohnt ist eine andere Sache. So kompliziert ist die Empfängerschaltung in RN-wissensbereich auch nicht - es ist aber noch ein Frage, wie gut der Empfang ist. Im Prinzip wäre da einiges an Reserve (Empfindlichkeit und Zeitauflösung) drin mit einem sehr guten Empfänger.

Der Nachteil bei den Modulen (und ähnlichen Transducern) ist aber, dass der Ulraschall recht stark gebündelt ist: man braucht also viele Sender/Empfänger und / oder muss drehen - vermutlich eher so dass man viele Empfänger hat, und dann den Sender mechanisch dreht. Statt drehen wäre es ggf. auch möglich rundum zu senden, mit einem speziellen Reflektor. Allerdings geht dabei einiges an Intensität verloren - man hat zwar einige Reserven (nur 1 Weg und keine Verluste von der Streuung bei der Refexion). Im Idealfall bräuchte man Transducer die in der Vertikalen gebündelt sind, aber in der horizontalen eher einen breiten Winkel haben.

[Dirk]

Hi Leute,

wenn wir uns hier die Mühe machen, eine US/IR Bake zu planen, dann sollte/muss das in einer gemeinsamen Hardwarelösung enden.
Grund: Wenn wir hier eine Indoor-Navi-Lösung mit Hard- und Software entwickeln wollen, brauchen wir eine gemeinsame Hardware-Grundlage.
Sonst kann es auch keine gemeinsame oder wenigstens für Bake oder Roboter geeignete Softwarelösung geben.
So habe ich aber diese Initiative hier verstanden: Wir wollen ein Bakensystem entwickeln, dass mit dem RP6 (oder mit anderen mobilen Plattformen) funktioniert.

An einer Baken-Lösung, die jeder auf Streifenraster irgendwie aufbaut, habe ich kein Interesse und ich denke auch, dass die Schaltung der Bake dafür zu komplex ist.
Stichworte:
- Stromversorgungsschaltung
- Akku-Ladeschaltung
- Sendetreiber (IR, Lichtkennung, US)
- ggf. Empfangsverstärker (US...)
- Multiplexer, falls mehrere Sensoren für US angeschlossen werden sollen
- evtl. Pegelwandler
- ...

Letztlich machen wir den Aufwand hier ja, um etwas zu erreichen. Spätere Anwendungen können hier im Forum nur entwickelt werden, wenn es eine gemeinsame Hardware-Basis dafür gibt.

Von daher wärs am sinnvollsten, einfach nur die Peripherie (alles was nach dem Controller kommt) zu entwerfen. Dann kann den Rest jeder so machen, wie ers haben möchte. Vielleicht gar mit ner I2C-Schnittstelle? Das wäre ungefähr das Optimum, da man dann _noch_ weiter aufbohren kann, wenn mans will.

Wenn du meine Liste mit Vorschlägen oben komplett wahrgenommen hast, bedeutet mein Vorschlag ja genau das. Schnittstelle zwischen den Sensoren/Aktoren, Stromversorgung der Bake und dem Controllerboard (Arduino, RP6 M32 ...) ist (siehe 3. a!) ein definierter Stecker, hinter dem "jeder so machen kann, wie ers haben möchte".
I2C (also ein I2C-Portexpander) ist nicht ohne weiteres möglich, zumindest dann nicht, wenn das Controllerboard die US-Laufzeiten selbst messen soll. Dafür ist I2C dann zu langsam. Oder: Man macht einige Funktionen über I2C-Portexpander und die Laufzeitmessungen über direkte Portpins des Controllers. Geht auch.

Dass man für eine Platine eine Gruppe zusammenbekommen muss, die diese gemeinsam und verbindlich bestellt, ist klar. Ich wäre dann auch dabei.
Wenn wir das hier NICHT wollen, bin ich an dieser Stelle raus und kann das Ganze dann auch für mich (sicher nicht so umfangreich) umsetzen.