IR-bake

[Rabenauge]

Ok- das reicht. Offenbar mag hier _jemand_ meine Anmerkungen nicht- is ok.

Entweder _ich_ bin hier raus- und zwar ab sofort- oder Rolf!
Ganz so nötig hab ichs dann auch wieder nicht....sorry für die anderen.

[Besserwessi]

Der Ultraschall per Lautsprecher / Mikrofon im etwa 25 kHz Bereich selber aufzubauen, ist schon anspruchsvoll auf der Empfängerseite und die Senderseite auch relativ groß und leistungshungrig. Da es wohl auch mit dem US Kapseln und Reflektor geht sehe ich dafür keinen wirkliche Grund. Die US Kapseln sind halt günstig, klein, sparsam und haben schon die erste Filterung mit drin. Den Weg über Mikrofon würde ich erst gehen falls es wider erwarten mit den US Kapseln nicht funktioniert die Position genau genug (Fehler um ganze Perioden) zu bestimmen.

Der Weg mit dem gerichteten US Sender ist wegen der nötigen Drehung nicht Jedermanns Sache - den Einwand kann ich verstehen. Ich sehe da aber auch kein echtes Hindernis, sondern halt ein etwas umständliche Handhabung. Mit einem extra Servo für das Drehen bliebe der Nachteil bei der Handhabung in Grenzen. Langsamer bliebe der Teil aber immer noch. Der Hardware-Aufwand für das finden der Richtung ist klein: im Minimalfall einfach nur 1 zusätzliche IR LED am Bot mit relativ kleinem Öffnungswinkel. Der Nachteil bei der Richtungssuche ist vor allem das es Zeit kostet. Wenn es mit Rundum Ultraschall von der Intensität nicht ausreicht, hätte man die gerichtete Version noch als Backup, bzw. dann für große Entfernungen. An den Baken selber würde sich ja nichts ändern.

Irgendwie gehen auch die Ziele der bake hier etwas auseinander: Mit dem Ungerichteten Ultraschall und IR bekommt man mit 3 (ggf. auch 2) Baken eine Postionsbestimmung, aber noch keine Richtung - die Richtung gibt es erst nach Bewegung des Bots - das ist wohl so etwa RolfDs Ziel.
Das andere Ziel, etwa ganz vom Anfang war vor allem die Richtungsbestimmung und nur sekundär auch den Abstand - im Einfachen Fall einfach um den Weg nach Hause zu finden. Das sind verschiedene Wege. Um die Richtung ohne Vorwärtsbewegung zu gekommen geht es halt per "gerichtetem" IR Signal - wobei das wegen der Fehlenden Amplitudeninformation von den fertigen IR Empfängern auch nicht so einfach ist. Für eine grobe Richtung (z.B. +-5 Grad) sollte es aber gehen. Mit der groben Richtungsinformation könnte man dann auch den US gerichtet haben.

Es gibt halt verschiedene Möglichkeiten je nach gewünschter Anwendung. Möglich wäre etwa:
1) reine IR Baken, und IR Teil auf dem Bot zum drehen. Damit könnte man die Richtung und über Triangulation (Winkel vom Bot zu den Baken) auch in Grenzen die Position bekommen. Hierbei wird man um eine unabhängige Drehung der Sensoren kaum herum kommen. Je nach Aufbau wären etwa 10 Sekunden für eine volle Triangulation realistisch. Nur eine Richtung zu halten ginge schneller. Wegen der IR Streuung ist das System aber nicht so trivial wie es aussieht - vor allen weil die TSOP keine Amplitudeninformation liefern.
2) IR/US Baken, ungerichtet (egal ob 22 kHz oder 40 KHz): hier bekommt man relative schnell (z.B. 1 Sekunde) eine Postionsbestimmung über die Abstände, und über die Bewegung dann die Orientierung. Hier wurde vor allem das Senden vom Bot und Empfangen an den Baken Diskutiert. Die Berechnung der Postion könnte man auf den Baken (eine MasterBake) oder dem Bot machen - beides hat Vor/Nachteile.
3) Ähnlich wie 2), nur das von den Baken zum Bot gesendet wird. Diese Richtung hätte Vorteile wenn mehr als 1 Bot unterwegs ist. Allerdings ist es so langsamer weil der langsame US nacheinander senden muss, vor allem bei vielen Baken. Ein Vorteil dabei wäre ggf. das man nur einen US Empfänger braucht, und da dann ggf. auch mehr Aufwand für eine hohe Genauigkeit treiben könnte. Auch könnte man ggf. mit weniger IR Sendern/Empfängern auskommen - IR vom Bot zu den Baken kann man sich ggf. ganz sparen.
4) Der Bot hat eine grobe Richtungserkennung per IR und einen ggf. gerichteten Ultraschall für die Abstandsmessung. Durch die Drehung des US wäre das Systems aber wohl relativ langsam, vor allem wenn der Ganze Bot gedreht werden muss. Sofern man nur den Weg auf ein Bake halten will hält sich der Aufwand auch in Grenzen. Dafür hat man halt auch ohne Bewegung eine Richtungsinformation, und man kommt auch ggf. mit weniger Baken aus, weil man.

Bei den Baken ist noch möglich das die alle unabhängig sind, oder ggf. per Kabel verbunden sind. Dabei muss man auch nicht an jeder Position einen µC haben. Verbunden könnte man ggf. IR Sender / Empfänger einsparen. Ich wäre für ein gemischtes System - also vorsehen, dass ein µC mehr als eine Position versorgen kann, aber auch so, dass die Baken nicht alle per Kabel verbunden sein müssen.

Mein persönlicher Favorit wäre die Version 2 , ggf. auch 3. Eine grobe Richtungsmessung über die IR Diode am Bot könnte man ggf. zusätzlich machen - der Aufwand wäre eher gering.

[Rabenauge]

Ich will ggf. (darauf liegt eigentlich sogar der Schwerpunkt) mit _einer_ einzigen Bake auskommen können.
Aber so, dass mans erweitern kann (wie ich schon sagte, mal eben ne Handvoll Baken als "Weidezaun" benutzen können.
Letzteres ist mehr oder weniger das, worum es euch geht.

Ersteres ist mit ner reinen IR-Bake praktisch kaum machbar: sie muss dann ja ringsrum senden können, und der Roboter kann _nicht_ wirklich die Entfernung feststellen. Sowas klappt z.B. als Ladestation (wenn er drauf ist kann er das ja anders detektieren), mir aber würd er dann regelmässig in die Haxen fahren.
Also _brauchts_ ne vernünftige Entfernungsmessung einfach (nebenbei bietet die bei mehreren Baken weitere mögliche Szenarien, beispielsweise eine im Bot abgelegte Umgebungskarte, mittels der er jederzeit seinen Standort finden kann usw.)
Damit ist Version 1 raus.

2. dürft genau das sein, was ich die ganze Zeit rede. Warum nöchte ich die Baken nicht per US senden lassen?
Weils mehr Strom braucht. Sicher: die Masse ists auch nicht, aber ich will versuchen, den grossen Bot später auf möglichst lange Betriebstzeiten auszulegen, blöd, wenn dann die Baken vorher schlapp machen- Netzteil für die Baken ist für mich _keine_ Option.
Letzten Endes aber würd auch _das_ (das US-Senden) gehen. Macht aber eventuell die Bake wiederum grösser, und die muss dann auch US ringsum senden können.
Ich möchte zumindest eine so klein wie möglich haben, eben, um sie mir wie nen Stift (zugegeben, soo klein wirds auch nicht, aber für viel mehr seh ich auch keine Notwendigkeit) an den Gürtel hängen zu können.

für 3. sehe ich keinerlei Vorteile: auch dann nicht, wenn es mehrere Roboter gibt. Die Entfernungsmessung muss sowieso individuell ausgelöst werden: Bot ruft Baken, sucht sich eine aus und fragt dann: wie weit isses zu dir? Das geht auch mit mehreren, wenn ein und dieselbe Bake von mehreren Robotern angesprochen wird, kann sie immer noch die nächsten warten lassen.
Schlecht wärs hier, wenn mehrere Baken zeitgleich antworten (weil mehrere von verschiedenen Robotern angesprochen werden zur selben Zeit), dann müsste die US-Schiene auch noch moduliert werden, um auch dort die Baken unterscheiden zu können-> unnötig.

Ja zugegeben: die Drehung des Bots (oder auch eines Sensors) ist etwas langsam. Andererseits sparts einiges an technischem Aufwand. Es ist ja nicht damit getan, ein ganzes Array an "Antennen" (sei es IR oder US) zu montieren, es muss ja auch noch angeschlossen&programmiert werden.
Und: ihr redet vom RP6- so kompliziert isses auch nicht, den mal eben auf dem Punkt zu drehen oder?
Ich würde betreffs Ultraschall halt einfach die Möglichkeit offen lassen, da nen ganzen Ring von zu installieren, aber eben ggf. mit einem -drehbar- auskommen wollen.
Wenn man die, auch schon vorgeschlagene Möglichkeit, den Schall mittels kegelförmigem Reflektor noch dazu nimmt, brauchts das gar nicht mehr, da man per US gar keine Richtungsangabe benötigt!
Das drehen (schwenken, wie auch immer) ist ja nur nötig, wenn die Baken US-passiv sind. Dann (und nur dann) muss der Roboter halt in Richtung der Bake quäken.Ich selber find die Lösung mit dem Schall-Kegelreflektor nicht so gut: ich schätze, das wird mechanisch etwas empfindlich, aber für drinnen, warum nicht.

Was man meiner Meinung nach nicht braucht ist eine allzu präzise Richtungsortung denn: das Ganze geht immer kegelförmig (je weiter weg, umso breiter der Empfangsbereich). Schon bei 90Grad Öffnungswinkel _kann_ ich die Bake sehr genau finden, weil auf kurze Entfernung da nur noch nen paar Zentimeter übrig bleiben.
Zudem lassen sich, wie ich schon sagte, die einzelnen Erfassungsbereiche noch überlappen, und ich hab die doppelte Auflösung (spricht der linke an, der rechte, oder beide).
Das funktioniert, ich mach das grade (noch testweise, aber die Tage ernsthaft) bei einer anderen Geschichte. Klappt gut, wie es aussieht.

[Thorben W]

@Rabenauge wenn ich dich richtig verstanden habe, dann hattest du die Idee von einzelnen Baken, die einen eigenen µC haben und jede einzelne dem Roboter auf Anfrage mitteilen welchen Abstand der Roboter zu ihnen hat.

Die anderen, wenn ich es richtig verstanden habe, wollten eine Bake mit Satelliten, die Bake überträgt die Entfernungen des Roboters zu allen Satelliten an den Roboter. Der Roboter hätte in diesem Fall einen Rund um sender für US und für IR (wie gelöst ist im Moment ein anderes Problem), die Bake hat eine Auswertelektronik (µC) und Bake und Satelliten haben jeweils US und IR Empfänger.
Der Roboter sendet IR und US ab und die Satelliten nehmen es auf und die Bake errechnet die Entfernungen und Überträgt sie zum Roboter (Komunikationssystem: Verschiedene Ideen)

Grüße
Thorben

[Rabenauge]

Unflexibel.
Wenn nämlich die "intelligente" Bake ausfällt, bricht das gesamte System zusammen. Sie muss ja noch nicht mal ausfallen, es reicht, wenn es Kommunikationsprobleme gibt.
Ich halts für besser (und der Aufwand ist nicht viel mehr, um miteinander kommunizieren zu können braucht eh jede Bake nen Rechenknecht), wenn jede Bake alles kann. Dann kann man die ausgefallene nämlich einfach austauschen, bzw. ungerührt weiter machen, so lange noch "genug" Baken online sind.
Zudem: wie soll die Bake die Entfernung des Roboters zu den Satelliten wissen?
Dazu müssen die auch gegenseitig Daten austauschen- vom Aufwand her find ich das nicht geringer. Aber anfälliger, weil dann sämtliche Satelliten auch noch mit der Bake reden müssen. Da ist einfach irgendwann zu viel "IR-Müll" im Raum.
Das ist in Griff zu bekommen, aber umständlich:

-Roboter weckt alle Satelliten auf (mit nem IR-Blitz und gleichzeitig nem US-Rundruf
-jeder Satellit misst nun die Entfernung, und muss die an die Bake weiter geben
-jetzt kann die Bake alles an den Roboter schicken.

Das ist nicht mal schnell, denn die Bake muss warten, bis sie von allen Satelliten die Werte bekommen hat.
Weiter muss es gut getimed werden, damit die Satelliten nicht gleichzeitig mit der Bake reden.
Ich hab da also entweder irrsinnige Verzögerungen drin (es kann vorkommen, dass die Bake nen Satellit nicht richtig versteht, und die Werte neu anfordert, aber auch, dass mal ein Satellit ganz ausfällt, das kann ich _nur_ mit ner gewissen Wartezeit rausfinden), oder aber ich muss vor jedem Start des Systems sicher stellen, dass die Bake sämtliche, im Einsatz befindlichen Satelliten kennt und auch mit ihnen einwandfrei kommunizieren kann.

Nen paar der Probleme kann man umgehen, indem man die Bake und die Satelliten miteinander per Kabel verbindet (ne Art Bussystem) aber dann wird das Ganze dermassen unflexibel...richtig schick geht das dann wohl nur noch mit nem Funknetzwerk-Blauzahn oder so.

Bei der von mir bevorzugten Lösung kann man von einer bis-beliebig viele Baken benutzen. Der einzige Unterschied zwischen ihnen ist ne eigene Adresse.
Nach dem "Rundruf" vom Roboter melden sich einfach alle, die es mitbekommen und schon weiss der Roboter, wer alles da ist bzw. im Bereich.
Dort kann man noch ne Differenzierung einbauen: Bake Addr.1 antwortet 10ms nach dem "Weckruf", Bake Addr.2 20ms danach usw. Auch das kann man in die Baken fix gleich mit einprogrammieren, so braucht der Roboter auch das nicht mehr managen.
Fällt _hier_ irgendeine Bake aus, ist das nicht soo tragisch: solange noch _irgendeine_ mitspielt, kann der Roboter zumindest diese noch lokalisieren.
Und: man kann klein anfangen-wenn das Budget eben grade nicht die eigentlich nötigen 15 Baken hergibt, kann man mit zweien schon sehr viel anfangen, und später nach und nach einfach neue hinzufügen, _ohne_ am System selber irgendwas zu ändern.
Bauch ich mal nur vier, stell ich eben nur die viere auf und gut. Ich muss dann nicht eine Zeile Code ändern.

[Besserwessi]

Das Senden von US Pulsen sollte vergleichsweise wenig Leistung benötigen, deutlich weniger als Sende von IR-Signalen. Anders wäre das nur wenn man einen Lautsprecher nutzen will. Der Fall 3) mit dem Senden von den Baken an den Bot (die Bots) wäre dann eher so, das ein Senden Angefordert wird, und dann alle Baken der Reihe nach Senden, das ganze ggf. 2 oder 3 mal wiederholt. Das Signal könnten dann alle Bots parallel aufnehmen. Der Vorteil wäre dabei, dass der Bot bereits die Zeiten misst und das Ergebnis nicht noch erst übertragen werden muss. Die IR Übertragung beschränkt sich dann auf die Zeitmarken zu den US Pulsen.

Beim Fall 2. (US vom Bot zu den Baken) muss man die Baken auch nicht unbedingt einzeln adressieren. Die Baken können den US Puls Unabhängig empfangen, nur beim Senden des Ergebnisses muss man ggf. durch Verzögerungen darauf achten das nicht 2 Baken gleichzeitig das Ergebnis senden. Dabei wäre ich eher dafür nur die Zeiten zu senden - die Berechnung der Position kann man dann auf dem Bot machen - damit wird man dann vor allem unabhängig davon wie viele Baken Antworten, und die Baken müssen nicht noch die Werte zusammenfügen. Das einzige ist das der Bot noch die Position der Baken braucht, aber die sollte nicht nicht so oft ändern. Bei den Baken wird es vermutlich darauf hinauslaufen das man je Position einen eigenen µC hat. Mit einem µC mehr als Postionen zu versorgen wäre ggf. interessant um Strom zu sparen (nicht so sehr um µCs zu sparen), denn man muss dann nicht an jeder US Empfangsposition auch IR Sender / Empfänger in alle Richtungen haben. Die Kabelverbindung ist dann mehr etwas um IR Kommunikation (insbesondere Strom) zu sparen. Für den Anfang würde ich aber pro Postion von 1 µC, 1 US Empfänger, ca. 2-4 IR Empfängern und etwa 3-8 IR Dioden ausgehen. Der nächste Schritt wäre dann ggf. ein 2. US Empfänger am selben µC und ohne zusätzliche IR Komponenten. Wie viele IR Sender bzw. Empfänger man nutzt ist ohnehin ggf. variabel, je nach Aufstellungsort der Bake (in der Raummittel viele, in einer Ecke eher weniger) - das wäre eine Sache die man ggf. per Jumper oder Software einstellen sollte, auch wenn ein IR Sender gegen die Wand nur mehr Stromverbrauch bedeutet aber noch nicht stört.

So hoch sollte der Stromverbrauch der Baken nicht sein. So grob geschätzt etwa 2-3 mA für 2-3 IR Empfänger um den nötigen Raumwinkel abzudecken, vielleicht 1-2 mA für den den µC und anderes im Ruhezustand. Für eine Messung kommt man dann vielleicht noch mal auf 50 ms mit 10 mA für den US Empfänger und vielleicht 20 ms mit 500 mA für den IR Sender. Bei einer Messung jede Sekunde wäre das auch nur noch einmal rund 10 mA im Mittel. In der Summe wären das weniger als 20 mA - damit könnte man mit 4 AA Akkus oder Batterien noch einige Tage auskommen, bzw. man hätte einiges an Reserve etwa für mehr IR Sendeleistung oder ggf. 2 oder mehr Baken aus einem Satz Akkus. Wenn man sich Anstrengt könnte man ggf. auch da noch sparen, etwa indem nur dahin gesendet wird wo auch empfangen wurde und ggf. je nach Abstand auch weniger stark gesendet wird - den Abstand zum Bot kennt die Bake ja.

Ob der Bot gerichtet sendet, oder in alle Richtungen ist dabei egal - das kann jeder halten wie er will, ggf. sogar gemischt mit 1 Bot der Rundum sendet und einer gerichtet. Gerichtet muss man dann ggf. damit Leben das einige Baken das Signal nur über ein paar Ecken empfangen - da braucht man dann ggf. eine nicht ganz triviale Fehlererkennung, denn auch das IR Signal kann man ggf. indirekt per Streuung empfangen. Für die billigen US Module könnte sich das Problem ergeben, dass man gerichtet ein sehr hohe Leistung hat, und so auch noch die 2. oder 3. Refelxion mitbekommt.

[Rabenauge]

Du willst-optional-also die Baken(mehrere ggf.) noch mit zusätzlichen Satteliten erweitern können?
Hm, da geh ich mal mit (ich denke nicht, das _ichs brauche, aber ich kanns ja einfach weglassen)- das macht Sinn, um ein dichteres Netz zu haben, falls nötig.
Die Satelliten kann man dann wirklich per Kabel einfach anstecken, oder eben nicht.

Das jede vernünftige Bake nen Rechenknecht benötigt, ist eh klar- muss ja nun nix tolles sein.
Kann man denn mit vier IR-Empfängern ringsherum empfangen? Klappt das wirklich?
Ich hab _einen_ hier- daher kann ichs nicht wirklich testen.

[Vitis]

ja hab ich...



Definiere bitte mal "transportabel".. Unter 25 Kg oder was meinst du damit?
Ich sprach in meinem Vorschlag von EINER Bake mit der Logik drin und bis zu X mit Kabel angeschlossenen Satelliten die je ein US-Empfänger, ein IR-Sender (DIODE) und ein IR Empfänger enthalten.
Was ist daran nicht Transportabel? Sind wir immer noch bei der Begriffsklärung was eine Bake bzw. was ein Satellit ist? Ich verweise da noch mal auf meinen Beitrag, den Dirk netter Weise gerettet hatte!



Und wie erfährt die Bake von dem IR-Blitz?

Da der RP6 das US-Signal wie auch das IR Signal aussendet und nur der jeweilige Satellit ein US-Signal und eine der Satelliten ein IR Impuls erkennen muss, gibts da keinen "Ultraschall-Müll" solange man nicht mit 130 Dezibel sendet... auch da verweise ich auf meinen Beitrag. Der aktive Messzeitraum liegt übrigens auch nur im Millisekundenbereich da sonst die Reichweite des US Signals signifikant überschritten wäre. Man kann sich das ganze US-Gebemsel sparen und mit einem Piezo-Hochtöner und ein paar Elektret-Micros das gleiche erreichen. Auch darüber hatte ich schon ausführlich geschrieben.



Ist ja auch ein uC-gesteuerter Reflexsensor und keine passive US-Kapsel... wie kommt man eigentlich auf das schmale Brett, das ein Reflexsensor geeignet wäre fremde Impulse aufzuzeichnen wo deren Störsicherheit.. und nichts anderes als Störungen sind fremde Impulse ... extra ausgefiltert werden? Wer hat dir diesen Schwachsinn eigentlich erzählt? Hättest du mein Post gelesen, wüstest du das es Ultraschallfähige Hochtöner für 5 Euronen beim großen C gibt! Und ein SR08 wäre eine deutlich bessere Inwestition gewesen wenns um Hinderniserkennung geht. So viel zum Thema Billig und Preiswert.



Da stimme ich dir mal zu.. es wäre schön, wenn man einen lokal montierten US-Reflexsensor am Bot in der Bake-Geschichte mitnutzen kann.... wie ich ebenfalls schon angedeutet hatte... das wird aber leider nicht zuverlässig gehen! Und zwar weil US-Kapseln eine extreme Focussierung haben... wie oft soll ich das noch schreiben? Das bedeutet logisch.. der Bot müsste sich erst auf ein US-Empfänger zu drehen damit der Empfänger den Impuls zuverlässig erkennt! Etwas unpraktisch oder nicht?


Siehe vorherigen Quote... das wäre ein Nachteil und kein Vorteil! Der Bot weis nämlich normal nicht wo die US-empfänger stehen.. also müsste er sie "suchen" und dazu bräuchte er ständig Rückmeldungen von der Bake... wärend er (irgend)einen Sateliten sucht soll er also mit der "Bake" reden und Feedbacksignale verarbeiten?
Du kommst um einen rundum sendenden US-Geber nicht rum und ich finde es gewagt, mal eben zu behaupten das man kein Rundumsender braucht .. ohne dir klar zu machen was der genaue Ablauf dahinter ist!


Wie will ein Bot, der seinen Weg abfährt und dabei nicht auf die Bake ausgerichtet ist, denn erfahren wie seine Position ist? Willst du das IR-Licht um Ecken lenken? Ne also hier wird es dann echt abstruß!


Achso.. die IR-Units die du bei den Sateliten einsparst willst du nun an den Bot hängen? Siiinvoll..... super...



Du hast da was ganz entscheidendes nicht kapiert! Nicht der Bot soll die Bake suchen, die Bake soll dem Bot sagen wo er ist!!! Jederzeit, egal wie er ausgerichtet ist und egal wie schnell er unterwegs ist. Der Bot ist das Gewitter ... und 3 Leute (Sateliten messen zählen den IR Blitz und "Knall" an...) um dann (in der Bake gerechnet) sagen zu können wo der Bot sich befindet. Da muss nix moduliert werden... Was verflucht ist daran so schwer zu verstehen? Wer hat das Gerücht in die Welt gesetzt, das ein Bot sich zur Positionsbestimmung oder Kommunikation erst irgendwo hin drehen muss? Gehts denn noch komplizierter?

Aber deswegen ist auch jede weitere Diskussion sinnlos hier...

Du hast schlicht und einfach nicht kapiert, was ein System erledigen muss, wenn es eine 2D-Ortung vornimmt. Ich empfehle auch dringend noch mal nachzulesen was "triangulieren" bzw. Trilateration bedeutet!!!
Aber ist ok... ich wollte es nur nicht unbeantwortet lassen. Ich bin trotzdem raus.
Gruß[/QUOTE]

Also Leuts kommt mal etwas runter ... es geht um Hobby

[RolfD]

Natürlich ist das ein Hobby. Darf man dann keine Auseinandersetzung führen? Interessanter Gedanke...

Es hat sich in diversen Posts gezeigt, das Rabenauges und meine Ansichten, wie man einem Bot eine 2D Orientierung bei bringt, nicht zusammen zu bringen sind.
Da ist soweit nichts verwerfliches dran und ich ziehe daraus die Konsequenz und ziehe mich aus der weiteren Entwicklung zurück da meines Erachtens die von Rabenauge angestrebte Lösung nicht zur gestellten Aufgabe passt. So... das heisst nicht, das ich mich jetzt aus dem Forum zurück ziehe.. und auch nicht das es nur einen im Thread geben kann wie Rabenauge fordert:

Entweder _ich_ bin hier raus- und zwar ab sofort- oder Rolf!

Ich lass mir auch nicht unterstellen, das ich was gegen Rabenauge hätte. Wir haben uns zusammen getan (siehe Thread) um sachlich eine Lösung zu erarbeiten. Nur weil ich Rabenauges Argumentation für falsch halte und dies inzwischen mehrfach und in verschienden Posts begründet habe, ist die gequotete Forderung nun legitim und ich werde aufgefordert runter zu kommen ? Gehts noch?
Ich hätte mir eine Antwort auf mein Post gewünscht in der auf die Punkte eingegangen wird... aber nicht bekommen. Ok. Stattdessen stellt Rabenauge Forderungen die ich schon längst als Konsequenz in Post 204 gezogen habe. Siehe Quote. Den Mund verbieten lasse ich mir jedoch nicht!
Ich habe es schon mal in einem anderen Tread und zu einer anderen Person gesagt: Ich trete hier nicht an um gegen die Dickköpfigkeit ander Leute zu kämpfen.
Lasst mich doch bitte einfach raus... auch mit Zitaten... und alles wird gut! Ok? Danke.
Gruß

[Besserwessi]

Mit nur einer Bake bekommt man nur eine eher eingeschränkte Position: Den Abstand, ggf. eher grob den Winkel von der Bake zum Bot und ggf. die grobe Orinentierung des Bots.
Mit nur einer Bake sollte man mehr Wert auf Bestimmung der Orientierung legen - der zusätzliche Aufwand (ggf. eine extra IR LED mit geringem Winkel, und etwas Software und halt das drehen des Bots) hält sich auch sehr in Grenzen, wenn man keine so hohen Anforderungen hat. Man es durchaus mit der Ultraschall Positionsbestimmung kombinieren.

Die Berechnung der Position würde ich nicht auf den Baken machen, sondern am Bot. So müssen die Baken nicht alle vernetzt sein. Bei der Berechnung auf einer Master-Bake bräuchte man eine Verbindung von den Baken zum Master und nur vom Master zum Bot. Wenn der Bot dann nicht mehr in Reichweite der Zentrale ist, braucht man dann aber doch wieder IR Sender an den meisten Baken.

Nach den Datenblättern haben die IR Empfänger schon einen recht breiten Empfangsbereich von etwa +-45 Grad, also 90 Grad im ganzen. Mit 4 der Detektoren hätte man dann 360 Grad abgedeckt - allerdings schon mit reduzierter (etwa 50%) Empfindlichkeit an den Grenzen. Für mehr Reichweite wären 5 oder 6 Empfänger besser. Bei einer Bake am Rand wird man den ganzen Winkel nicht brauchen und sollte mit 2 (ggf. 3) Empfängern auskommen.

Eine Bake sollte einen µC (etwa Arduino mit AVR) haben, wohl 2 - 4 IR Empfänger (TSOP..36), zum Senden etwa 5-10 IR Dioden und einen US Empfänger. Optional könnte man davon dann ggf. noch einen Satelliten betreiben mit nur einem US Empfänger. In der einfachen Version könnte man die IR Empfänger wohl direkt zusammenschalten (wired OR). Wenn man die Empfänger getrennt hat, könnt man je nach Empfänger für das Startsignal auch nur die entsprechenden IR Sender aktivieren. Es könnte auch von Vorteil sein nur dem Empfänger auszuwählen, der ein gutes Signal Empfängt - von daher würde ich schon getrennte Eingänge vorsehen. Bei den IR Sende-Dioden muss man nicht unbedingt alle einzeln Senden können, es kann aber helfen - vor allem bei nur einer Bake. Ich wäre da eher für ein paar mehr Dioden mit kleinem Winkel (z.B. LD274) da kommt man mit weniger Strom aus, weil weniger Licht nach oben und unten verloren geht.

Damit es mit der Richtung klappt sollte man wohl 2 Funktionen der Baken vorsehen:
1) Auf ein IR Signal Aufwachen, und einen US Puls Empfangen und dann die Zeit zurück senden. Mit Sattelit hätte man dann 2 Zeiten. Das IR Signal für den Start wird wohl erst aus einem Muster für die Funktion und dann ein Paar (z.B. 4) Pulsen für die Synchronisation bestehen.
2) Auf ein anderes IR Signal mit einem IR Signal antworten für die Richtungserkennung. Dabei könnte man ggf. auch nacheinander die IR Dioden für die Rückrichtung nutzen, so dass der Bot auch grob weiss in welchem Sektor der Bake er ist. Um Ärger mit Streulicht zu vermeiden müsste man da ggf. vorsehen die Intensität zu variieren: entsprechend muss man auch den Fall schwacher und damit fehlerhafter Signal berücksichtigen.