IR-bake

[inka]

Hallo allerseits,


Ich glaube wir werden nicht mehr allzuviele reaktionen auf meinen vorschlag bekommen...


danke erstmal für die antworten auf meine frage nach der realisierung einer bake v2.0. und für das vertrauen in meine fähigkeiten als projektleiter. Werde mein bestes geben.

Die rückkehr zum normalen ton im RN-forum ist mir auch sehr wichtig, deshalb auch der vorschlag den ich in meinem letzten post gemacht habe. Damit sollte eine konstruktive zusammenarbeit zwischen den „streithähnen“ ermöglicht werden...

Aus den posts zu meinem vorschlag kann man schon die unterschiedlichen meinungen zur lösung der technischen probleme erkennen, bin mir nicht ganz schlüssig wie man solche sich schon sehr widersprechenden erfahrungen in das projekt aufnehmen kann. Es werden im laufe des projektes sicher auch noch andere ideen und vorschläge kommen, die natürlich auch willkommen sind und werden, sofern in der laufenden projektphase noch möglich, berücksichtigt...

Als hauptbeteiligte würde ich die user vorschlagen, die sich bereits zu wort gemeldet haben:
Besserwessi, Dirk, Michael, Radbruch, RolfD und ich. Jeder nach seinen zeitlichen und fachlichen möglichkeiten. Dazu sollten sich alle hier genannten noch einmal äußern, damit das im neuen thread (siehe weiter unten) berücksichtigt werden kann...

Da ich als projektleiter keine entscheidungen allein treffen möchte, würde ich ein verkleinertes „gremium“ vorschlagen, das diese entscheidungen über die qualität des erreichten bzw. den weiteren verlauf des projektes trifft: RolfD, Dirk und ich.

Es wird sicher nicht möglich sein eine bake für alle anwendungen und user zu entwickeln, man sollte versuchen das optimum zwischen funktion und kosten/aufwand zu erreichen...

Zum brainstorming würde ich vorschlagen, dass es noch hier in diesem thread stattfindet, ich würde dann anschließend einen neuen thread eröffnen mit den punkten auf die sich die hauptbeteiligten geeinigt haben (quasi die projektvorgaben) und gleichzeitig einen RN-artikel aufmachen, in dem der entwicklungsprozess beschrieben wird, das ist dort meiner meinung nach übersichtlicher darstellbar.

Folgende punkte würde ich zum brainstorming zum projekt bake 2.0. beisteuern (die basieren natürlich ausschließlich auf meinen erfahrungen bei bake 1.0.!):

• IR – ja/nein
• wenn kein IR was dann?
• Laserdiode? siehe z.b. hier (würde auch mit dem RP6 lichtsensor funktionieren, habe ich kurz angetestet), würde wahrscheinlich keinen reflektor brauchen (sendet punktförmig, reichweite von sich aus schon sehr groß)
• microprocessor atmega 8 (weil ich ihn vom asuro her kenne) um die bake z.b. über I2C oder BT einbinden zu können
• wenn kein atmega 8 was dann?
• 5 (im halbkreis angeordnete) leds, nacheinader sendend (Ir – oder laser), oder
• eine led drehbar (servo), blinkend sendend
• spannungsversorgung über USB
• maximaler verbrauch der bake 400mA
• den anschlus eines BT-moduls vorsehen

[RoboHolIC]

Hallo inka.

Ich möchte Dich bzw. Euch ermutigen, ruhig noch einen Schritt mehr zurück zu treten und grundsätzlichere Betrachtungen anzustellen, so wie man das in einem Lasten-/Pflichtenheft macht. Welcher Controller und welche Funktechnologie, das ist in diesem Moment doch schnurz; manches wird sich aus der Anforderungen ergeben bzw. von selbst verbieten.

Die Fragen sollten momentan eher in diese Richtungen gehen:
- Was genau soll(en) die Bake(n) können
- Bake als Einzelsystem oder ein komplexerer Navigationsverbund?
- Wird ein Routing des mobilen Fahrzeugs durch die Baken gewünscht
- Indoor oder/und Outdoor?
- Welche Technologie ist die geeignetste für die Übertragung?


Vielleicht gehen meine Fragen an der Realität vorbei, aber ich würde zunächst auf dieser Ebene brainstormen und ein Konzept erstellen.
Denkt ruhig groß (modular, universell) in Hard- und Software. Es ist ziemlich lästig, die ersten Erfolge mit 20 LOC (Lines of Code) zu erzielen und dann zu merken, dann die nächste Stufe bei 200 LOC, die übernächste vielleicht erst bei 2000LOC liegt und dazwischen wiederholt aufwendige Umbauten nötig sind.

[RolfD]

Fassen wir mal zusammen, was da ist...

Der RP6 hat ein IR System mit Sender und Receiver onboard. Dazu gibt es bereits den IR Morsetreiber, ich glaube von Dirk. http://www.rn-wissen.de/index.php/RP6_-_Morse-Code
Zudem sind Protokolle wie RC5 und ähnliche vorhanden wie sie jede Fernbedienung mit ca. 5-6m Reichweite produziert. Das Datenübertragungsformat für IRDA wie es manche IRDA-Sticks und ältere Handys nutzen ist komplizierter bzw. kommt auch auf Grund begrenzter Reichweite (30cm-1m) kaum in Frage.

Hat jemand 2 RP6, könnte er also zumindest schon mal einen als Bake in die Ecke stellen und den zweiten darauf reagieren lassen. (So hatte ich mal ein wenig rumprobiert)

Welche andere Lichtsorten haben wir noch? Natürliches Tageslicht, künstliches Licht im sichtbare Bereich und monchromes (Laser) Licht. Wärme (intensives IR) und UV lasse ich mal aussen vor obwohl man Wärme mit einem PIR-Sensor incl. prismatischer Linse auch gut anmessen kann... aber nachher facklet sich noch jemand mit Teelichtern die Hütte ab... lassen wir das also. Microwelle/Radar Langwellen kommt auch nicht in Frage, damit ist aber schon ein Großteil der elektrischen Schwingung abgedeckt. Die ersten beiden besitzen als Lichtquellen verwandte Eigenschaften, Laser ist dagegen meist extrem fokusiert, hat aber daher auch den Nachteil, das man es schlecht anvisieren kann. Laser wäre was für auf den Bot zu montieren, wenn zusätzlich eine Kamera den Lichtpunkt vermessen würde. Laser ist zudem als Lichtschrankensystem sehr gut geeignet. Laser macht also dann Sinn, wenn man weis wo der Strahl landen sollte...aber auch nur dann. Ich stelle mal die Arbeitsthese auf, das alle Lichtsorten ausser Laser im Prinzip als Kugelstrahler die gleichen Reflektions- und Brechungseigenschaften haben... und man daher z.B. auch normale LEDs oder Lampen verwenden _könnte_ .. zumindest um sich die Eigenschaften des unsichtbaren IR-Bündels vorstellen zu können. Daran ändert auch der Umstand nur wenig, das man zusätzlich Linsen und Reflektoren verwendet. Es gibt dann noch die Möglichkeiten per Kamera Licht zu detektieren, allerdings ist das zu aufwändig da dies nach Bildauswertung verlangt.

Es gibt ja grundsätzlich 2 Verfahren zur Entfernungsmessung. Triangulation von Feldstärke und Messung der Signallaufzeit. Für Leuchttürme spielt noch die Erdkrümmung bzw. Sichtachse über Horizont eine Rolle (wesshalb die auch so nette Streifen aufgemalt haben bzw. deren bekannte Höhe über n.N. so wichtig ist) aber die können wir in Zimmern und Gärten glaube ich vernachlässigen . Die Signallaufzeit ist bei Licht und Funk mit unseren Mitteln kaum zu messen.

Was gibts noch für Signalquellen für Nahortung? Datenfunk im 433MHz Band und Oberwellenbänder fallen eher flach da diese eine Reichweite von üblicher Weise min 100m haben. Blauzahn ist eher geeignet, allerdings bräuchte man ein Blauzahngerät, welches die Feldstärke anmessen und an den Prozessor durchgeben kann. Im Umkreis von 10m könnte man dann zumindest eine Triangulation versuchen, wie es Handyanbieter im großen mit mehreren Sendemasten und dem Handy auch machen können. Dazu wären aber 3 Blauzahn Sender (Mikroprozessorgesteuert) und ein Reciever auf dem RP6 nötig. Die Messgenauigkeit läge in einem normalen Raum von sagen wir mal 4x4m läge bei geschätzen 0,5 bis 1m in jede Richtung. Andere Funksignale sowie GPS kommen nicht in Frage, GPS schon deswegen nicht weil die Lokalvarianz selbst bei freier Sicht auf die Satelliten über Zeiten von mehreren Minuten um 2-10m wandert. Um das zu kompensieren müsste man ein großen Aufwand treiben, der nur für fix montierte Geräte und Geschwindigkeiten wie in der Gletscherforschung vertretbar ist. Für Flugroboter mit einem Aktionsradius von hunderte Metern bis Kilometer macht GPS Sinn, auf einem Kettenbot der magels Batterieleistung kaum weiter kommt als ein mal ums Grundstück zu fahren und dabei 25 mal vom Boardstein kippt weil der Satellit "mal wieder wandert..." - nicht! In wie weit GPS in Räumen Sinn macht kann jeder mit seinem Handy dann noch selbst austesten.

Dann gibts noch den Bereich Schall bzw. Ultraschall. Hier kommt nur Ultraschall in Frage obwohl man technisch auch normalen Schall verwenden könnte - zumindest um sich vorzustellen wie das geht. Nur Ultraschall ab ca. 30 khz hat eine genügend steile Signalflanke bzw. kurze Wellenlänge um daraus mit technischen Mitteln Laufzeitinformationen zu erfassen, das menschliche Ohr schafft das schon bei deutlich tieferen Frequenzen und in erster Linie über stereo hören und Laufzeitunterschieden durch die Kopfbreite/form bedingt. Stereoschallverarbeitung ist ebenfalls ein spannendes Thema aber hier für die Bake und einfache Mono-Systeme eher nicht relevant, wäre aber auch sehr gut nutzbar wenn man den Aufwand nicht scheut.

Mit einem SRF08 und ähnliche Reflexsensoren kann man recht genau und über Reichweiten von ca. 6-10m ... also Schallaufwege bis 20 m seine Umgebung erfassen. Man müsste sich eine Art Karte seiner Räumlichkeit anlegen und Bewegungen im Raum durch vermessen markanter Punkte festlegen. Ich persönlich halte dies für die effizienteste Möglichkeit zu navigieren, allerdings geht das am Konzept einer Bake vorbei und ist aufwändig in Software. Schall ansich eignet sich allerdings auch anders genutzt für Baken da Schall im Gegensatz zu Licht eine messbare Laufzeit hat. Produziert eine Bake z.B. einen Lichtpuls und gleichzeitig einen Schallimpuls, kann man durch die Laufzeit recht genau sagen, wie weit die Bake vom RP6 weg ist. Jeder kennt das Verfahren um zu ermitteln wie weit ein Gewitter weg ist. Elektrisch gesehen würde man dort aber den Funkimpuls zum starten der Zeitmessung verwenden da nicht vorhersagbar ist, wo der Blitz auftaucht. Mit 2 Baken der Art welche sich nicht behindern, kann man schon sehr genau seine Position im Raum festlegen. Problematisch daran sind Schallreflektionen aber da der schnellste Weg immer der kürzeste ist, darf man eben beim Schall messen nur das erste eintreffende Signal verwenden. Da man die Entfernung aus der Schall Laufzeit errechnet, entfallen auch Maßnahmen zum fokusieren und ausrichten wie bei Licht. Die Messgenauigkeit dürfte bei wenigen Zentimetern liegen und mit größerem Abstand abnehmen. Man muss jedoch mit dem nächsten Klick warten bis wieder "Ruhe" im Raum ist, das liegt aber in Räumen im Millisekundenbereich. Nutz man z.B. ein Impulspaket von 4 bis 16 dicht aufeinander folgenden Impulsen + Ein- und Ausschwingen , ist es auch recht eindeutig von Umgebungsschall zu isolieren.

Sinnvoll wäre also eine Bake, welche einen IR Puls aussendet und gleichzeitig einen Ultraschallklick. Der RP6 müsste diesen IR Blitz (bei dem es dann auch nicht auf Reflektion ankommt) einen Messvorgang starten und über einen Ultraschallsensor die Signallaufzeit ab Startblitz berechnen. Davon 2 Stück im Raum und der RP6 kann aus den Laufzeiten seine Position zu den Baken errechnen. Was er damit erst mal nicht rausbekommt ist seine Rotation zu den Baken. Dafür braucht man wieder ein Kompas oder müsste es als Messung über Zeit und Bewegung wie herkömliche Navis errechnen. Der Vorteil, das Ganze kann von einem Punkt aus (Bake) gesteuert werden denn man braucht keine 2 Baken, sondern nur eine sowie einen weiteren externen Ultraschallgeber, der im simpelsten Fall einfach nur an einem langen Kabel hängt. Die Steuerung muss dann abwechselnd die beiden Schallgeber betätigen und bei jedem Schallklick ein IR-Blitz abgeben.
Das System wäre mit 2-3 Ultraschallgebern und einem IR Geber recht einfach analog aufzubauen.
Baut man da jedoch ein Prozessor ein, kann man sich durchaus Erweiterungen überlegen. Z.B. kommunikation mit dem RP6, wobei es da nur auf eine "piepsen auf Anforderung" hinauslaufen kann da die kleinen (8, 16 und 20 Beine) Prozessoren für viel mehr nicht die Kapazitäten haben. Aber es wäre eine Anwendung, welche mit einem einfachen zusätzlichen Reciever auf der Bake a la RP6 Bauart machbar wäre.
Verbaut man einen leistungsfähigeren Prozessor (ab mega16 oder 32 wie M32/RP6) in der Bake, wäre auch eine umgekehrte Messung mit 1 Schallgeber auf dem RP6 und 3 Schallempfängern (über Kabel mit der Bake verbunden incl. Auswertung der triangulation und Übertragung der vermessenen Raumposition per IR an den rp6) möglich. Es hätte zudem den Vorteil, das der RP6 seine Position nicht selbst bestimmen muss und er daher auch diesen Code nicht braucht. Ohne eine räumliche Orientierung (z.b. per 2-dimensionales Array oder Vektoren) wird man da allerdings auch nicht auskommen.
Das Verfahren funktioniert übrigends auch in 2 oder mehr Räumen ... entweder mit mehreren Baken die sich versuchen zu syncronisieren.. per Blauzahn oder Datenfunk... oder eben mit einer Bake und weitere kabelgestützte IR-Blitzer und Schallwandler.

Man kann nun jetzt noch überlegen ob man sich ein SRF Reflexsensor auf den Bot baut um quasi das Ultraschallsignal passiv in der Bake auszuwerten. Diese haben aber doch recht starke Richtcharakteristika ähnlich der Lichtkegel von LEDs. Sinnvoller können da Hochtonkalotten als Signalgeber aus dem Hifi-Bereich sein da diese bessere Rundstrahleigenschaften haben. Es ist auch nicht ganz einfach, bei einem SRF08 den genauen Zeitpunkt des Signalstartes raus zu bekommen da dieser mit einem eigenen Prozessor autark misst. Das Ding hat zwar ein LDR Sensor onboard aber ein Lichtimpulsgeber wäre für die Anwendung sinnvoller gewesen. Die Formel lautet aber: Um so weniger "Richtung" die Komponenten haben, um so einfacher und zuverlässiger wird die Messung!

Alle Verfahren, die nur rein auf Lichtauswertungen basieren, müssen spätestens dann scheitern wenn keine direkte Sichtverbindung besteht. Optisch-akustische Verfahren, welche sich zudem (Licht)Reflektionen auch noch zu Nutze machen, sind in der Nahbereichsnavigation (30cm bis 15m) immer im Vorteil. Allerdings braucht man ausreichend empfindliche Schallempfänger damit man auch garantiert den Ton/Klick (und natürlich auch den IR Blitz) mit definierten Eigenschaften zweifelsfrei mitbekommt. Für Navigaionen im freien (z.B. im Garten) würde man aber wohl besser Blauzahn/Datenfunk und Feldstärketriangulation nutzen da Schall ab ca. 30 m begrenzt ist, so wie auch IR-Licht dort schwieriger zu übertragen ist. Wo Sichtverhältnisse nicht gut sind kann man aber auch per Funk das Startsignal statt IR-Lichtimpuls verwenden wenn man die Datenübertragungszeiten mitberechnet. Auch hier gibts aber Beispiele wie eine DCF Funkuhr oder NTP Dämonen.
Bisher beschäftigen wir uns in Sachen Ultraschall aber nur mit den Signallaufzeiten, auch eine "Feldstärkemessung" über den Pegel des Signals wäre möglich um Störeinflüsse noch weiter zu begrenzen und das Signal zu validieren. Schall kann also 2 Werte aus Eigenschaften liefern die sich nicht widersprechen sollten. Man könnte das aber auch wieder nutzen um den Schallgeber an die Raumakustik anzupassen indem der RP6 den Pegel per IR an die Bake schickt und diese dann z.B. "leiser" oder "lauter" wird um Echos zu eliminieren.

Ansonsten wäre vielelicht die Vermessung mit Laserlicht noch eine Möglichkeit aber da dürften die Messgeräte und Sensoren den Etat der meisten Leute hier sprengen und das Ergebnis wird nicht zwangsläufig genauer. Reine Lichtgeber müssten im fokusierten Lichtstrom immer zusätliche Informationen wie z.B. den aktuellen Abstrahlwinkel übertragen und man kommt von der Kugelcharakteristik weg zu einer Strahlcharakteristik, was immer schwieriger wird zu finden und messen je mehr ich den Strahl fokusiere (extrem Laser). Wie genau man mit Funk und Signal Laufzeiten seine Position ermitteln kann, sieht man übrigends am GPS System. Hochgenaue empfindliche Empfänger können die Position in Langzeitmessungen millimetergenau feststellen, weniger genaue Empfänger nur mit Varianz und auf wenige Meter genau, was angesichts der Entfernung zu den Sendersatelliten schon enorm gut ist!
Mit Licht geht das theoretisch auch den Licht ist ja genau so schnell... praktisch hab ich da so meine Zweifel! Zumindest wenn man in Betracht zieht, das man für den Startimpuls der Messung bzw. zur Erkennung von Differenzen im Datenstrom des Signals kodiert schon eine Atomuhr im Sender oder zumindest einen hochexakten Startimpuls bräuchte... mit einer Auflösung kleiner der Distanz welches Licht in wenigen Zentimetern !!! zurück legt. Da Strom aber nicht schneller als Licht ist, spielen da neben Dämpfungen aber sogar Kabel und Leiterplatten Längen eine Rolle und wir bewegen uns mal eben im Gigaherz Frequenzbereich. Frequenzen die LEDs und in Sperrschichtsättigung gefahrene Transistoren nun mal nicht leisten! Es scheitert da also schon am Signalgeber.
Aus der Funktechnik kennt man noch die logarithmische Regel, das man zur verdoppelungder Reichweite das Signal vervierfachen muss - oder um den Faktor 4 abschwächen damit man die Reichweite halbiert. Man rechnet dort in Decibel - was man auch in der Schallmessung kennt. Es gibt da also durchaus Verwandschaften... und erklärt gewisse Reichweitenbeschränkungen.
Die einzigen Vorteile, die IR Licht für uns gegenüber anderen Lichtsorten hat, ist das es sich einfach durch optische Filter vom normalen Tageslicht abgrenzen lässt und das es leicht in kleinen Mengen herzustellen ist. Etwas was prinzipbedingt jedoch für alle LEDs gilt. Für klarweis ebenso wie rot,blau und grün oder gelb - wenn man jeweils die gleichen Lichtmenge (Lumen) voraussetzt. Spätestens wenn man Leuchtstoffröhren oder LCD-Bildschirme in der Hütte hat, wird man sich wundern, wie viel IR-Energie da zum Teil abgestrahlt wird. IR liegt immerhin recht nah an der Wärmestrahlung wie es Wärmebildkameras anmessen können.

Generell ist bei allen Schallsensoren jedoch zu bedenken, das Tiere den Schall ggf. hören können und darunter auch leiden... wer also mit Schallimpulsen im Ultraschallbereich experimentiert, sollte auch sein Haustier im Blick behalten...

Das war mal eine kurze Zusammenfassung der Möglichkeiten ... natürlich mit Präferenz auf meine Vorstellungen dazu.
Gruß

[Christian H]

Hallo,

interessantes Thema und bei weitem nicht so einfach wie man zu Beginn meinen könnte. Je nach Anwendungsbereich (innen, außen, ein oder mehrere Räume, erforderliche Genauigkeit) kann mal US, IR oder Camera mit Objekterkennung am geeignetsten sein. Die eierlegende Wollmilchsau die universell anwendbar ist gibt es meiner Meinung nach noch nicht.

Falls Ihr noch nicht darauf gestoßen seid: Der TSOP7000 ist ein IR Sensor der mit 455 KHz arbeitet. Das ist schnell genug um die Winkel einer drehenden IR-Bake auszustrahlen.

Kombinierte IR-US Bake: https://www.roboternetz.de/community...ight=CHristian

2 IR Baken: https://www.roboternetz.de/community...ight=CHristian
Viel Spaß noch!

Beste Grüße

Christian

[oberallgeier]

... Der TSOP700 ist ein IR sensor der mit 455 KHz arbeitet. Das ist schnell genug um die Winkel einer drehenden IR-Bake auszustrahlen ...

Hi Christian, ja das Ding sollte man nicht ausser Acht lassen (Du meinst vielleicht aber den 7000er???). Obwohl ich die TSOP´s nicht nehme, die sind nämlich lausige Arbeiter - brauchen immer wieder ne Pause; der 7000er braucht nach 500µs Bestrahlung mit moduliertem Licht eine Pause ohne Modulation. Da ist die Kontinuität der Information dann doch erschwert.

Wie hattest Du dieses Problem bei Deiner Bake umgangen ?? In Deinen Posts habe ich nix dazu gelesen (oder überlesen???).

Aber Sigo hatte den 7000er ziemlich raffiniert benutzt, siehe seine 180°-Stoßstange. Und dazu das Test-Video.

[Christian H]

Hi Joe,

Du hast natürlich recht, ist der TSOP7000. Der arbeitet auch nicht im Dauerbetrieb, sondern sendet eine Folge von Bytes zwischen denen jeweils eine Pause von 800us ist. Bei 8 MHz lassen sich die 455 Khz folgendermaßen erzeugen:

I = 0 
Do         'do-loop für 14 bursts mit 455 KHz 
Toggle Portd.5     ' Übertragung von bit = 1 
nop  'IR-LED an Portd.5 
nop  'Zahl der nops bestimmt burst-Dauer 
nop  'ausprobieren evtl 5 oder 6 nop besser 
nop  
Incr I 
Toggle Portd.5 
nop  'ausprobieren evtl. 4, 5 oder 6 besser 
nop 
nop 
Loop Until I = 14

Das ergibt 14 Blitze mit etwa 455 Khz und entspricht einem bit=1. Für bit =0 bleibt die LED gleich lang aus. So kann man
ein Startbit =1
einen Winkel (1 bis 128 ), Stellung des Servos auf dem die LED sitzt
ein bit zur Kennung der beiden baken
und ein Stopbit =1 übertragen

14 Blitze mit 455 Khz dauern 30 us
10 bit dauern 300 us
dann 800us Pause >>> etwa jede ms wird ein Byte verschickt.

Die links sollen nur zu Ideen anregen. Ist sicher nicht der Weisheit letzter Schluß. Problem ist immer die Alltagstauglichkeit. Wer will denn schon, falls es um Navigation in mehreren Räumen geht, mehrere Baken aufstellen und betreiben.

Grüße

Christian

[Dirk]

Leute,

ich würde meine Wünsche an ein Bakensystem für den RP6 so zusammen fassen (Pflichtenheft):
1. Es soll indoor arbeiten.
2. Die Raumgröße beträgt bis zu 5 x 5 m
3. Mit Hilfe des Systems soll der RP6:
3.1 Seine Position im Raum auf +- 5 cm feststellen können
3.2 Seine Drehrichtung (Yaw) bestimmen können
3.3 Im Raum eigenständig manövrieren können
3.4 Einen Punkt im Raum (z.B. eine Ladestation) eigenständig anfahren können
4. Die Sensoren (ACS...) und die Aktoren (IRCOMM...) des RP6 sollen (soweit möglich) genutzt werden
5. Aktive Baken sollen so aufgebaut sein, dass sie auch durch eine RP6 CONTROL M32 oder CCPRO M128 Zusatzplatine (stand alone) betrieben werden können
6. Die Anzahl von Baken soll bis 8 erweiterbar sein

[WL]

Das kommt mir alles sehr bekannt vor.................
Ich hole da mal einen alten Beitrag aus der Versenkung:
https://www.roboternetz.de/community/threads/54798-Laser-Positionsscanner
Das ganze lässt sich für 5cm Auflösung viel einfacher aufbauen.

[inka]

hallo,

zunächstmal würde ich feststellen, dass die mitgliederzahl in unserem team auf drei zusammengeschrumpft ist...

auf dieser basis sollten wir anfangen (punkte, die weitgehends in unseren auflistungen übereinstimmen)
--------------------------------------
1. aktive, „schlaue“ bake
2. eine gemeinsame hardware und library (Dirk?)
3. ACS und IRCOMM des RP6 sollten verwendet werden
4. hauptsächlich indoor, raumgröße 5x5m
5. IR/US konzept
6. position im raum auf +- 5cm festsstellen können
7. eigenständiges manövrieren im raum, eigenständiges anfahren eines punktes im raum
8. kosten bis max 120€ für einen raum (1 mutterbake / 2 tochterbaken)
----------------------------------------
Differenzen zwischen Team-Mitgliedern:
(über diese punkte sollten wir noch diskutieren und so definieren/beschreiben, dass sie dann oben aufgenommen oder gestriche nwerden können)
---------------------------------
Anzahl von baken soll bis 8 erweiterbar sein
Outdoor, dann Raumgröße 10x10m
Bake soll auch von einer M32 oder CCPRO M128 (standalone) betrieben werden können
Drehrichtungbestimmung (Yaw)
Eine Bake sollte 2 Räume mit je 3 Messstellen/US sendern versorgen können (6 anschlüsse)
Die Bake sollte zunächst als Hardwareanforderung nur die RP6Base haben
Die Bake betreiben über die M32 als master
Spannungsversorgung über USB
Anschluss- / Einbaumöglichkeit eines BT- Moduls
Definition Mutter- / Tochterbaken
Einbindung des gyro (multiIO)?
------------------------------------------

Was Hardware betrifft lege ich erst einmal vor – Arduino Mega 2560:

ich habe am montag ein board in D bestellt, geliefert wurde es heute, 14€, portofrei...

ist seehhrr weit verbreitet, kostengünstig, simpel, kein programmieradapter, wir würden damit eine „Brücke“ zwischen zwei AVR-Systemen (M32 und M2560) schlagen...
mir käme es entgegen, weil ich bereits beim Allradantrieb des RP6 solches Modul verwende...

@Rolf,
die ergänzung von beiträgen ist ungünstig, ich habe Deine zwei edits rein zufällig entdeckt...


schöne heisse pfingsten...

[Besserwessi]

Die Anforderungen an die µCs sollte man eher gegen Ende festlegen. Das ergibt sich im wesentlichen aus den Sensoren / Sendern die man verwendet. Das erste was man Festelegen sollte wären entsprechend die Signale die Gesendet werden. Was man dafür dann an HW bracht, sieht man dann - vermutlichwerden die Anforderungen für die Baken auch gar nicht so hoch werden. Beim mobilen Teil ist halt noch die Frage ob man einen eigenen µC braucht oder einfach nur etwas code und und einige IO Pins am Bot.

Bei den Zielen ist "eigenständiges manövrieren im raum, eigenständiges anfahren eines punktes im raum" schon eine eher höhere Softwareebene - das hat so direkt nichts mit der Barke zu tun.

Die erste große Frage ist in welche Richtung IR und US gesendet werden. Sowohl für IR als auch US ist das Senden wohl etwas einfacher als Empfangen. Einer der Empfänger wird am Bot sein müssen. Beim Ultraschall hat man ein ggf. störendes Echo, und damit eine merkliche Totzeit nach dem Senden - da wäre es schon praktisch wenn man nur einen Sender und viele Empfänger hätte. Bis das Echo abgeklungen ist dauert es geschätzt 0,1-0,2 s. Beim Ultraschall ist auch noch die Frage nach der Ausrichtung: die US Kapseln sind etwas gerichtet - mit einem Reflektor für einen ungerichteten Empfang hat man dann ggf. keine so große Reichweite mehr - ob das noch ausreicht müsste man wohl testen. Die IR Signal können für so etwa wie TSOPxx38 etwa 5 ms kurz sein. Bei den IR Signalen könnt man ggf. die Intensität auswerten - allerdings bringt das vermultich eher wenig um daraus die Entfernung zu schätzen, jedenfalls kaum um auf 5 cm zu kommen.


Ich sehe einige mögliche Systeme:
1) Der Bot sendet ein US Signal und die Baken anworten als IR Signal. Eine kleine Schwierrigkeit bekommt man hier, wenn mehr als eine Bake antwortet - da müsste man ggf. mit Verzögerungen arbeiten, bzw. die Signale der Baken Synchronisieren. Einfach direkt nach Empfang Antworten klapt nicht. Da bräuchte es noch einige Überlagungen zum IR Protokoll.
2) Die Baken senden US und IR, der Bot empfängt nur. Die IR Signale können hierbei in kürzeren Abständen kommen als die US Signal: wenn man bis etwa 8 Baken annimmt. hätte man etwa 1 Sekunde für je 1 US Signal. Bei IR wäre dagegen ein Zyklus von etwa 50 ms möglich (6 ms je Puls-paket), in denen jede Bake einen Pulse gesendet hat - ein schnelles Senden ist hier für die Richtungssuche hilfreich, sonst muss man recht langsam drehen. Beim Ultraschall ist auch noch die Frage ob jede Bake Ultraschall senden muss - da reichen ggf. auch ein paar weniger, schon wegen der Kosten.

3) Der Bot sendet IR und Empfängt Ultraschall. Auch hier hat man wieder das Problem, dass ggf. mehr als eine Antwort kommt, auch wenn das mit einem gebündelten IR Strahl eher selten vorkommt. Die Baken müssten sich für den Fall wohl irgendwie absprechen.

Das wären eigentlich schon die 3 einfachen Möglichkeiten, ohne eine (IR) Kommunikation in beide Richtungen. An einfachsten davon ist klar der Fall 2. Eine wesentlichen Freiheiten die man da noch hat, ist Frage der Empfänger. Beim Ultraschall ist der teilweise gerichtete Empfang (so wie der Transducer es vorgibt) wohl einfacher und auch ohne Reichweiteproblem. Da sehe ich eher wenig Motivation für den extra Aufwand für rundum Empfang. Beim IR Empfang hätte der RP6 zwar schon einen Empfänger, aber der ist nicht wirklich gerichtet, gibt also kaum eine brauchbare Richtungsinformation. Für die genaue Richtung wird man einen besser gerichteten zusätzlichen Empfänger brauchen. Theoretisch könnt man man die Richtung auch über den US machen (mit 2 Empfängerkapseln)- der Aufwand ist aber wohl relativ groß, und echos könnten stören.
Die Frage die sich bei der Richtung noch stellt, ist ob man den ganzen Bot dreht, oder einen schwenkbaren Empfänger zum Abscannen der Richtungen baut. Der Vorteil wäre halt, das man schneller und wohl auch genauer schwenken kann - das Kettenfahrwerk des RP6 ist halt nicht so präzise. Für die Baken selber ist das aber egal - das ist eine Frage wie die HW und das Programm auf dem Bot aussieht.

Nach den Ausführungen hier, sehe ich vor allem den Fall mit Baken die nur Senden (IR und US) und nur Empfängern am Bot als interessant an - oder hat da einer noch einen anderen Vorschlag ?