IR-bake

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

[Rabenauge]

Willst wirklich den Ultraschallkram selber bauen?

Wie ich schon sagte: die hc-sr04 sind _anschlussfertig_. Die brauchen noch ne Stromversorgung, und der Rest geht _direkt_ zum Controller!
Da brauchts einfach nix weiter. Klar: Treiber für die LED`s wären sicher nötig (wobei-ne LED packt ein Controllerpin auch, aber ob mit ausreichender Leistung?), was aber noch??
Fällt mir nix ein.
Irgendwie fängts an, mir zu kompliziert zu werden. Das Ganze sollte so simpel wie möglich sein.

Um das Beispiel mit dem MiniDuino mal zu bemühen: an das Ding noch (keine weitere Beschaltung, nur Strippen) einen oder mehrere HC-SR-04, ein Bündel LED`s (ggf. mit ner einfachen Transistorschaltung als Treiber), und die IR-Dioden plus das dazu nötige (Verstärker?) und FERTIG.
Nehmen wir jetzt den Dino weg, haben wir nen Dutzend Bauteilchen, und gut.
Nicht unnötig verkomplizieren, das soll preiswert und einfach abgehen.
Mag ja sein, dass manch einer (vermutlich sogar viele) da fitter sind als ich, aber ich seh keinen Grund, das unnötig zu verkomplizieren.

[inka]

hallo allerseits,

wir theoretisieren hier und drehen uns im kreis, meint Ihr nicht auch? Schaut doch einmal zurück in dem thread, so um post 8 herum - das hatten wir doch schon alles!

Ich diskutiere zwar auch gern (manche wissen das schon) aber ich bin nicht der große theoretiker. Sollten wir nicht langsam anfangen irgendwelche kleineren bereiche der bake (US / IR/ ...) mal aufzubauen und zu testen? Um überhaupt beurteilen zu können was geht und was nicht? Oder kann jemand aus dem stand etwas über die PRAKTISCHEN fähigkeiten und eigenschaften der verschiedenen elemente aus eigener erfahrung sagen und nicht nur datenblätter zitieren?

was wir jetzt brauchen sind kleine - aber m.e. nach wichtige - praktische ergebnisse. Das kann ein sehr primitiver aufbau sein, das kann auch ein miniduino sein, oder die m32 als standalone. Es ist eigentlich egal...

Wer könnte jetzt in der richtung was machen?

kennt Ihr den begriff der inneren kündigung? Auf dem weg befinde ich mich momentan und würde am liebsten bauteile zusammenstellen um nochmal eine bake 1.0. zu bauen, die auf einer anderen frequenz sendet als die bestehende - um mit zwei baken zu testen...