IR-bake

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

[Dirk]

Hi inka,

es wäre -glaube ich- gut, wenn du erst einmal zur Abstimmung stellst, was wir hier wollen.
Danach können Einzelfragen (z.B. welche LED leuchtet am besten, welche US-Sensoren nehmen wir) beantwortet oder in Steckbrettform ausgetestet werden.

Übrigens zum Thema "Theoretisieren": Ich bin die ganze Zeit bei der praktischen Planung! Ohne genau solch eine Planung wäre z.B. das MultiIO Projekt von fabqu nicht möglich gewesen,- und ohne Planungs-Ergebnis entsteht auch keine Bake (zumindest keine gemeinsam dann nutzbare).

Also: Was wollen wir in diesem Thread noch erreichen?
Denken wir zurück an die Anfänge (Posts 123..126). Da wollten wir eine Bake V2.0 entwickeln. Aktuell tauschen wir Gedanken und Ideen zu Baken aus.
Wo stehen wir da und wer macht noch mit?
Wo soll es hingehen?

Wenn sich jeder nur eigene Ideen aus diesem Thread zieht, dann ist das Ergebnis, dass der eine 5 der nächste 9 IR-LEDs nimmt, der eine arbeitet mit dem HC-SR04, der nächste mit einer oder mehreren US-Kapseln, jeder entwickelt seine eigene IR-Kommunikation ...
Das ist natürlich völlig ok, ich bin dann aber hier raus, weil dann klar ist, dass ein gemeinsames Ergebnis, das alle (mit eigenen Veränderungen) nutzen können, HIER nicht heraus kommt.

[Rabenauge]

Fertige Komplettlösungen sind meist unflexibel-oder hoffnungslos überladen. Anders gehts nunmal nicht: entweder hab ich den Anspruch: es funktioniert mit geringstmöglichem Aufwand, oder aber es funktioniert in jeder denkbaren Situation.Ich hab hier den Eindruck, dass manche letzteres wollen-sehe da aber keinen Sinn drin, denn eine einfache SchnittLeute: ich denke gar nicht dran, mit nen US-Sender oder Empfänger selber zu bauen, wenn ich nen fertigen für weniger als nen Euro bekomme, falls der die Ansprüche erfüllt.
Für meinen Teil werd ich vorerst die Klappe halten (mir wirds hier echt zu kompliziert), aber lesenderweise bei der Stange bleiben.

[inka]

Hi Dirk,

es wäre -glaube ich- gut, wenn du erst einmal zur Abstimmung stellst, was wir hier wollen.

ich weiss nicht was wir hier wollen bzw. hinter welchem vorschlag sich ausreichend interessenten versammeln lassen, solange es nicht konkret wird, werden wir es auch nicht erfahren. Das ist ja das, was ich vorhin meinte, vielleicht habe ich das nicht klar genug zum ausdruck gebracht...

Ich muss zugeben ich hatte es bei bake 1.0. einfacher, ich musste niemanden von meiner idee überzeugen, habe "einfach" mit try & error gemacht und wenn es ging, wars gut, wenn nicht, habe ich es halt wieder auseinander genommen oder in den müll geworfen (war aber nicht viel) und im forum hilfe gesucht. Und gefunden...

Hier kann ich nicht sagen - das machen wir jetzt so.

Das hier war Dein vorschlag. Den sollten wir jetzt als basis nehmen. Ich habe mich zwar noch nicht dazu geäußert, wäre mit ein paar ausnahmen damit einverstanden. Ich bin der meinung, dass bei einem gemeinsamen projekt auch eine gemeinsame hardware und software als basis verwendet werden muss. Ergänzugen/erweiterungen kann jeder einzelne ja machen...

meine bemerkungen/fragen habe ich farblich markiert...

vielleicht sollte das jeder mal so machen und die auflistung im post 175 so kommentieren damit wir weiter kommen...

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

keine 12 oder 24 sender/empfänger, maximal zwei

-- 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!

siehe oben

-- e) Parallel zu d) die Entscheidung, ob ein/zwei Kegelreflektor(en) zum Einsatz kommt/kommen (bei nur 1 US Sender/Empfänger)

wie funktioniert das? Im forum habe ich nichts dazu gefunden...

-- f) IR-Sender und -Empfänger mit Rundumsicht bzw. mind. 180° Sicht zur Kommunikation in einem 5x5m Raum (z.B. über Decken-Reflexion)

auch nur maximal zwei, könnte auf einem gemeinsamen träger mit dem US-sender/empfänger sitzen

-- g) IR-Kommunikation z.B. als RC5-Code oder eigener Code

RC5

-- 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!)

was meinst Du mit lichtkennung?

-- 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)

keine farberkennung auf dem roboter

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

glaube nicht dass das gutgeht (gemeinsame basis!)

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

[Besserwessi]

Die Punkte die zuerst festgelegt werden sollten sind eher die Sensoren Sender. So etwas wie Stecker / Versorgung ergibt sich dann daraus.

Ein offener Punkt beim Ultraschall ist noch die Frage des Öffnungswinkels - die Transducer sind halt gerichtet, und das stört hier. Bei einer Seite könnte man wohl mit einem Reflektor auf ein Größeren Winkel kommen, ggf. sogar als Rundumsicht. Das kostet einiges an Signalstärke, aber so viel sollte drin sein, weil die Reflexion der Abstandsmessung wegfällt - das gibt im Extremfall ja auch eine mehr oder weniger Rundumstreuung. Ich fürchte bei der anderen Seite wird man wohl bei den gerichteten Verhalten bleiben müssen, und z.B. den Sender (oder Empfänger) am Bot drehen müssen, damit genug Signal ankommt. Die Alternative von mehreren Empfängern (bzw. Sendern) je Bake gefällt mir da weniger.

Wenn die fertigen US Module wirklich so günstig sind, könnte man es damit versuchen. Man sollte aber bei dem Design nicht total von einem Sonderangebot eines Chinesen abhängig sein. Ein Eigenbau als Alternative zum fertigen Modul bleibt ja immer noch möglich.

Beim US ist auch noch die Frage in welche Richtung: der Sender am Bot hätte den Vorteil, das es ruhig bleibt weil nur 1 Sender da ist, und ggf. mehrere Baken parallel Empfangen können. Der Empfänger auf dem Bot hätte den Vorteil, dass nur 1 Empfänger gebraucht wird, und die Sender sehr einfach (da braucht man nicht unbedingt ein Modul) sind. Damit könnte man für den einen Empfänger ggf. mehr Aufwand treiben und ggf. Empfindlicher werden. Mit fertigen Modulen wäre das egal, aber beim Eigenbau würde es einen Unterschied machen.

[Dirk]

Hi inka,

nur kurz zu den Fragen:

1. Kegelreflektoren
Im Projekt von (Stephan Höhrmann) kann man das schön auf dem Titelbild sehen: Die US-Kapsel ist nach oben gerichtet, darüber liegt ein Kegel, der den US quasi horizontal in alle Richtungen in den Raum reflektiert.

2. Lichtkennung
Das war ein Vorschlag von Rabenauge: Der Roboter kann eine Bake per Licht (er hatte glaube ich IR vorgeschlagen) orten, damit man den US-Sensor in die Richtung der Bake drehen kann.

[Besserwessi]

Der Link zur Arbeit von Stephan Höhrmann ist interessant: die Intensität reicht da sogar mit 2 Kegelförmigen Reflektoren und das sogar mit einem einfachen Empfänger. Das vereinfacht die Sache natürlich deutlich, und erspart ein paar Vorversuche. Damit hätte man die Möglichkeit US rundum zu Senden und zu Empfangen. Das gerichtete Senden hätte man dann immer noch als Option für größere Reichweite, bzw. bei viel Hintergrundgeräusch. Wie gut die Empfängerschaltung auf den fertigen Modulen ist, muss man noch sehen. Wenn wider Erwarten das Modul zu schlecht ist, hätte man da schon mal einen Ansatz für den Eigenbau, wobei ich eher die Version hier aus dem RN-Wissen, mit variabler Verstärkung bevorzugen würde.

Der wesentliche Unterschied ist hier wohl das die Synchronisation hier wohl über IR statt Funk ablaufen soll (ist günstiger ?). Beim Senden in alle Richtungen wäre ich eher gegen die Reflexion an der Decke (geht draußen nicht), sondern eher für ein paar mehr Sendedioden + ggf. Optik und mehrere (3 oder 4) Empfänger Chips. Wenn der Bot in alle Richtungen IR sendet, muss ja auch nicht jede Bake jede Richtung empfangen, sofern die Baken unter sich verbunden sind. Für das eigentliche System macht es aber nicht viel Unterschied wie die LEDs ausgerichtet sind. Man wird wohl parallel zum US Puls ein IR Signal senden müssen, um die Empfänger synchron zu starten. Also wohl am Bot US + IR Senden und dann von den Baken ein Rücksignal (verzögert vom IR Signal - je Bake Unterschiedlich - mit der Zeitmessung oder der berechneten Position).

Die Alternative wäre sonst von den Baken US und IR im festen Takt zu senden (z.B. alle 100-200 ms eine Bake mit US, so dass etwa jede Sekunde alle einmal gesendet haben) und am Bot nur empfangt. Damit bräuchte man nur IR Kommunikation in eine Richtung, hätte aber eventuell mehr Stromverbrauch bei den Baken und halt immer ein Hintergrund Signal. Ob das wirklich mehr Strom ist müsste man sehen - nur US Senden kostet nicht viel, und man spart sich damit die meisten IR Empfänger an den Baken, die immer laufen müssten. Da könnte man auch überlegen das Signal zum US Senden extra zu erzeugen und zum Senden kein fertiges Modul zu nutzen. Als Vorteil würde das System auch für mehr als einen Bot Gleichzeitig gehen. Was einem damit aber weitgehend fehlt, ist aber die Orientierung des Bots. Das ginge ggf. mit einem Empfänger, der die Richtung bestimmen kann - ggf. als 2. , gerichteter US Empfänger.