Hallo, ich habe hier mehrere Platinen die über einen Zeitraum von ca. 2 Minuten synchron laufen sollen. Es geht um Ultraschallbaken. Wenn ich das mit einem Uhrenquarz mit +/-10ppm mache habe ich nach 1:30 eine Abweichung von maximal 30cm. Und das ist eindeutig zu viel. Kabel ist keine Alternative und ich denke, dass es mit IR auch etwas schwer wird, da ich das dann RC5 Codieren MUSS und die Auswertung ist vermutlich nicht immer genau gleich schnell. Hat damit jemand Erfahrung oder noch ne andere Idee?
Laser/LED auf eine Photodiode, die mit einem Transitor auf einen Pin geht der einen externen Interupt auslöst und die Zeit auf eine Feste Zeit einstellt. Der erste µC sended bspweise genau alle x Takte per Timeroverflow Interupt den Strahl für genau einen Takt. Der andere µC wird per Interupt auf dieses Ereigniss getimed. Zu beachten ist nur die Verzögerung bis der Interupt eintritt und das Signal beim 2ten µC verwertet werden kann. Oder aber du lässt beide µCs mal mit ner Uhr ne Zeitlang laufen und schaust nach wie die genaue Abweichung ist und korregierst sie in Software. Außerdem erscheint mir die Abweichung recht hoch, dass das bei 2min schon einen solchen Fehler hervorruft. Gruß ErgoProxy und schöne Weihnachten noch.
Und in wie fern unterscheidet sich nun deine Laser-Technik vom RC5? Es geht ja um einen Roboter der sich auf einem Spielfeld zurechtfinden muss. Problem an der Sache ist, dass da noch mindestens ein weiterer auf dem Feld ist der mit Pech auch sowas verwendet. Wenn dann müsste man es so machen, dass durch den Impuls nur der Wert der mit dem Uhrenquarz erzeugt wurde korrigiert. Was die Abweichung angeht: Rechne das mal hoch auf nen Jahr, dann bist du bei nen paar Minuten. Viel genauer sind digitale Quarzuhren doch auch nicht oder? Und 30cm, sind 0,3m wären bei einer Schallgeschwindigkeit von 330m/s dann nur 9*10^-5 Sekunden! Das sind 90 mikro Sekunden! Ich finde das ist schon recht genau, aber eben nicht genau genug. Das mit der Software-Komensation wäre ne Alternative aber schwankt das dann nicht auch wieder unterschiedlich je nach Temperatur? Oder müsste die Abweichung bei allen dann in etwa gleich sein?
Könnte man auch eine Externe Taktquelle einsetzen die Per IR-Impuls jeweis den Takt angibt? Geht aber vermutlich nur wenn es recht dunkel ist, denn bei der Geschwindigkeit kann man keine Modulation verwenden.
Echt? Was meinst du mit Geschwindigkeit? Die Geschwindigkeit die von der Übertragung und Dekodierung her? Oder die Geschwindigkeit des Bots?
Du hattest wenn mich nicht alles täuscht nicht gesagt, dass es sich um Bots handelt oder aber andere IR-Quellen stören können. Und bei mir ist einfach die Unterscheidung gewesen, dass es nicht ausgewertet werden muss, es wäre damit allerdings störanfälliger, aber bei normalen sich nicht bewegenden Platinen unter immer gleichen Bedingungen würde das wohl nichts machen. Also Das nächste mal schreib doch bitte wofür es ist und nicht erst nachdem du eine Lösung hast die du dann auf Grund deiner Begebenheiten ausschließen kannst. Gruß ErgoProxy
die abweichung vom Takt sind nach 1:30 min ca 0,1 %. Das kompensieren mit software ist ne sehr ratsam weil jeder Quarz eine andere ungenauigkeit hat ist auch stark von der Temparatur abhängig! MFG Patrick
Hallo Fabian, du brauchst nur einen Master der z.B. alle 10ms ein Signal sendet. Der Start der Übertragung ist die Syncronisation und die Daten nur absicherung ob es eine gültige Übertragung war und Abgleichwert. Jede Platine kennt das Zeitraster und weis mit dem Abgleichwert die Zeit bei der nächsten Syncronisation. Jede Platine timt sich jedoch selber und ändert nur ihren internen Zähler so, daß er bei Syncronisation die 10ms genau erreicht. Das Prinzip ist ähnlich wie DCF77 nur schneller. Übertragen kannst du mit IR oder Funk (RFM?). gruß hans
Funk? Denke das wird nichts... Habe hier zwei Easy Radio Module und bis die die Daten immer verarbeitet haben vergeht in der digitalen Welt ne kleine Ewigkeit. Naja IR war eben meine Frage. Ich würde es ja codieren müssen (RC5?) und meine Befürchtung ist, dass die Auswerung der Daten ist so unterschiedlich schnell ist, dass das zu ungenau wird. Und ohne Codierung wird es schwer die Signale zu validieren, da da ja alles Mögliche andere von den anderen Bots noch zwischenfunken kann. Mir ist auch klar, dass die Abweichung der Quarze sich stark verändert bei Temperaturschwankungen, aber wenn man sagen kann sie steigt bei einter Temperaturveränderung bei allen Quarzen um genau den gleichen Faktor könnte man das ja kompensieren. Wie machen denn die GPS-Empfänger das? Die Sateliten senden doch auch in regelmäßigen Abständen EM-Impulse aus, wo die Uhr zwar nur für ein Bruchteil einer Sekunde genau gehen muss aber dafür SHER genau.
So ein GPS empfänger braucht ja nicht umsonst ein paar Minuten zur erst Positionierung. Die sateliten senden ihre Momentane Zeit Position usw (weiß ned wirklich wie der Frame aufgebaut ist). In den man mehrere Sateliten hat wird dann die Synchronisation vorgenommen (eigene Wissenschaft)
Dachte immer die Teile berechnen das auf Grund der Laufzeit. Was soll denn der Empfänger mit der Uhrzeit und Position?
Fabian S. wrote: > Mir ist auch klar, dass die Abweichung der Quarze sich stark verändert > bei Temperaturschwankungen, aber wenn man sagen kann sie steigt bei > einter Temperaturveränderung bei allen Quarzen um genau den gleichen > Faktor könnte man das ja kompensieren. Da gabs doch die Quarze, die sich selber heizen und konstant die Temperator halten...
Hört sich interessant an, bin dankbar für jeden Input ;) Ich geh erstmal schlafen und wünsche euch noch ne besinnliche Nacht :P
http://en.wikipedia.org/wiki/OCXO Ich glaube, das ist ne Nummer zu gross. Ich habe mich noch nie genauer mit den Dingern beschaeftigt und hielt die fuer kleiner, sorry.
Naja für die Laufzeit benötigt man ja ne Referenzzeit um die Entfernung zu bestimmen usw. MFG Patrick
Um mehrere Controller synchron laufen lassen zu koennen muss man denen den clock auch schon synchron mitteilen. zB als Harmonische, oder auch als Subharmonische. Es waere denkbar, das Signal Clock_div_128 als Infrarot auszustrahlen und jeder Slave hat einen PLL drauf laufen. Oder es wird ein Signal Clock_mal_16 als funk ausgestrahlt und die Controller haben einen Teiler nach einem PLL. Andersherum : Synchron bedeutet PLL.
6789 wrote: > Um mehrere Controller synchron laufen lassen zu koennen muss man denen > den clock auch schon synchron mitteilen. zB als Harmonische, oder auch > als Subharmonische. Es waere denkbar, das Signal Clock_div_128 als > Infrarot auszustrahlen und jeder Slave hat einen PLL drauf laufen. Oder > es wird ein Signal Clock_mal_16 als funk ausgestrahlt und die Controller > haben einen Teiler nach einem PLL. Andersherum : Synchron bedeutet PLL. Wiki: Als Phase-locked loop (PLL) wird allgemein eine elektronische Schaltungsanordnung bezeichnet, die die Frequenz eines veränderlichen Oszillators über einen geschlossenen Regelkreis so beeinflusst, dass eine möglichst kleine Phasenabweichung zwischen einem äußeren Referenzsignal und dem Oszillator- oder einem daraus abgeleiteten Signal erzielt wird. Öhhh wo habe ich denn einen veränderlichen Oszillator? Und woher nehme ich mein Referenzsignal? Das müsste dann doch genau genug sein dafür oder? >andere frage: welche controller verwendest du? Also die Slaves (Baken) wollte ich mit nem ATMega8 machen, den Master vermutlich auch aber da kann es sein, dass der Kram direkt mit an die Hauptplatine kommt, das wäre dann ein ATMega128.
wenn ich mich recht entsinne, hat der mega 128 doch eine "clock output" fuse, mit der man das interne taktsignal direkt auf einen pin rausschalten kann. mit diesem signal kannst du in die clock inputs der anderen controller gehn. du hast dann zwar die laufzeit des kabels drin, aber die ist ja fix.
Hatte ich nicht geschrieben das Kabel keine Alternatve ist? Kann ja schlecht übers ganze Spielfeld nen Kabel legen...
http://de.farnell.com/jsp/search/browse.jsp;jsessionid=PUP5UZJRUVQ1KCQLCIQZLTQ?N=1001189+341634&_requestid=426145 Das sind Oszillatoren mit 1ppm...
Fabian S. wrote: > ich habe hier mehrere Platinen die über einen Zeitraum von ca. 2 Minuten > synchron laufen sollen. Es geht um Ultraschallbaken. Wenn ich das mit > einem Uhrenquarz mit +/-10ppm mache habe ich nach 1:30 eine Abweichung > von maximal 30cm. Und das ist eindeutig zu viel. Mit 32kHz Uhrenquarzen wirst Du keinen Blumentopf gewinnen, die sind stark temperaturabhängig. Nimm normale Quarze (z.B. 10MHz), die sind wesentlich stabiler. Dann definiere einen als Master und lasse diesen z.B. 1s-Pulse ausgeben. Daran schließt Du die anderen Platinen an, damit sie den Korrekturwert für ihren Quarz ausmessen können. Nach dem Abtrennen der Synchronisationsleitung sollten 2min Gleichlauf zu schaffen sein. Peter
>http://de.farnell.com/jsp/search/browse.jsp;jsessi... >Das sind Oszillatoren mit 1ppm... Wow cool! Denke das sollte genau genug sein! Wären dann ja übern Daum gepeilt 3cm Abweichung. Ist denke ich ausreichend und das ist ja auch nur der worst-case. Damit entsteht aber ein neues Problem: Die Teile sind sehr Hochfrequent, sprich ich werde die wohl kaum an den Clock Pin für den Timer direkt anschließen können. Wenn ich nun damit direkt den Atmega betreibe und dem Timer halt nen Prescaler bzw Overflow Krams verpasse ist das dann noch genau? Ich meine mal was davon gehört zu haben, dass der Zähler in dem Atmega nur "abgeschätzt" ist. Stimmt das? Wenn ja wie kann ich das genauer bekommen? Gibt doch so Bausteine die den Takt verkleinern. Wäre das eine Lösung? @Peter: Meinst du also, dass die Slaves ihren Korrekturwert immer dynamisch bestimmen sollen, in der Hoffnung, dass es dann 2 Minuten hält? Wäre ne denkbare Lösung nur bleibt da auch die Frage wie genau die Timer sind mit ihren overflow.
Fabian S. wrote: > Meinst du also, dass die Slaves ihren Korrekturwert immer dynamisch > bestimmen sollen, in der Hoffnung, dass es dann 2 Minuten hält? Man könnte den Wert auch einmalig ermitteln und im EEPROM abspeichern. Aber Du mußt ja eh zu Anfang alle Platinen synchronisieren. > Wäre ne denkbare Lösung nur bleibt da auch die Frage wie genau die Timer > sind mit ihren overflow. Das ist ja der Witz an HW-Timern, daß sie auf den CPU-Zyklus genau sind, genauer geht nicht. Der Master erzeugt seinen Sync-Impuls zyklusgenau mit nem Output-Compare-Pin. Und die Slaves messen zyklusgenau mit dem Input-Capture-Pin. Peter
Ahh das ja super! Nur habe ich grade mal bei den Teilen auf den Preis geschaut, das ist natürlich nicht super. :( Was mir grade noch in den Sinn gekommen ist sind die Quarze die man im Modellbau verwendet für die Funkverbindungen. Die sind doch auch nicht ganz billig weil die exakt synchron laufen müssen oder? Könnte man da nicht einfach zwei 35Mhz Quarze nehmen und dann nen Teiler dahinter? Ich vermute mal, dass die so teuer sind weil sie eben genau diese Frequenz haben aber das ist bei mir ja nicht so wichtig, wichtig ist ja nur, dass sie gleich schnell sind.
Ich würde mich garnicht so sehr darum bemühen, alle Baken zu synchronisieren. Warum lässt Du nicht den Roboter ein Ultraschall-Signal senden, auf das dann alle Baken antworten? Der Roboter kennt dann den exakten Zeitpunkt von Sendung und Antwort. Jede Bake müsste natürlich eine andere, feste Wartezeit vor dem Senden des Antwort-Impulses haben, damit's nicht zu Kollisionen kommt.
Ja da habe ich auch schon drüber nachgedacht, habe es zum Anfang aber schnell verworfen da das relativ kompliziert werden würde im Vergleich zu einem RC5 codierten Signal, da das aber inzwischen alles flach fällt wäre das auch wieder eine denkbare Lösung.
Mich würd mal Jetzt genau interessieren was du mit den Ultraschallbaken machen willst und wie du es machen willst ? MFG Patrick
Ähhh naja was soll ich dazu noch mehr sagen? WIll halt ne 2D Positionsbestimmung machen die auf der Laufzeit von Schall basiert.
Du schickst also von fixen Stationen Schallimpulse aus und misst die Zeit bis zum eintreffen am Roboter? Der Roboter weiß wenn die Impulse gesendet werden und errechnet sich durch die differenzzeit von senden und empfangen die Zeit. Mit hilfe dann die entfernung ermittelt wird . Oder irre ich mich ? MFG Patrick
Jop, genau richtig. Wie das genau Mathematisch geht weiß ich nich nicht, bin aber nicht unbegabt was das angeht :P
>Mit 32kHz Uhrenquarzen wirst Du keinen Blumentopf gewinnen, die sind >stark temperaturabhängig. >Nimm normale Quarze (z.B. 10MHz), die sind wesentlich stabiler. Das ist leider nicht korrekt. Ein Uhrenquarz hat standardmaessig weniger als 10ppm, waehrend ein normaler Quarz 100ppm hat. Trotzdem denke ich dass unabhaengige clocks bei diesem Problem nie was werden. Um Ultraschallphasen zu messen benoetigt man PLL synchronisierte Clocks. Die kann man zB ueber Infrarot synchronisieren, synchron halten. Alternativ wuerde sich eine Industriefrequenz anbieten, zB 430MHz
@6789 Mag schon sein das die Taktabweichung beim "normalen" Quarz das 10 fache ist dafür ist die Frequenz etwa das 100-1000 fache wodurch sie prinzipiell gesehen genauer sind.
Wie schnell willst verfahren ? Wie groß ist das Spielfeld ? Mit was wird der Roboter abgetrieben ? Und die wichtigste Frage wie teuer darf es kommen ? MFG Patrick
@ Andreas K.: Die Frequenz spiel keine Rolle! Bei Reichelt gibt es "normale" QUarze mit 30ppm und Uhrenquarze mit 10ppm. die ppm sind ja eine "prozentuale" (nicht auf hundert sondern auf ne Million bezogen) Abweichung und da ist es egal wie schnell die sind. Das Spielfeld ist ca. 3x3m groß und der Bot wird mit zwei Schrittmotoren, 200 Schritt angetrieben. Was den Preis angeht sollte das System nicht teurer als 50€ werden.
Ok jetzt mal ein Vorschlag von mir. 1. Du kannst dir das Synchronisieren vereinfachen, denn du kannst ja den Bot an eine fixe Stelle auf dem Spielfeld geben, und somit mit ein paar Ultraschall Pulsen die Synchronisation machen. 2. Unter dem Spiel kannst ja alle 10 Pulse die Positions unterschiede mit Daten die durch die Schrittmotoren erhälst vergleichen und so eine Korrektur des Zeitsignals vornehmen. MFG Patrick
Ich soll was synchronisieren mit Ultraschall? Hört sich seltsam an... Verstehen tuh ich das nun nicht wirklich. Der Plan war es eigentlich die Positionsberechnung sowohl durch die Radticks als auch durch den Ultraschall krams zu machen. Im Grunde wollte ich die Positionierung nach den Radticks machen, da die aber driftet das ganze mit dem Ultraschall korrigieren.
Dann geh über Laufzeitdifferenzen. Ist glaub ich das einfachste für dein Problem denn du brauchst nix Synchronisieren usw MFG Patrick
Angehängte Dateien:
-
ipic_1862.jpg
7,8 KB
Es gibt auch sehr schöne Entfernungssensoren von Sharp auf IR-Basis, vielleicht würden die ja helfen. Siehe Bild, erhältlich bei CSD-electronics für gut 10 EUR.
@Patrick Weinberger: Meinst du mit Ultraschall hin und zurück? Hatte ich ja bereits gesagt, dass das die Ersatzlösung ist. @Travel Rec.: Ja kenne ich aber die sind relativ träge (irgendwo im Sekundenbereicht?) meiner Erfahrung nach und gibts denn da welche die weiter kommen als 80cm?
Wo sind die den die Ultraschallsender angebracht ? Also ich dachte so du bekommst einen Schallimpuls dann beginnt ein Timer zu laufen der beim eintreffen des nächsten Schallimpuls seinen Wert zwischenspeichert das machst so lang bis du von allen Basisstation die Schallimpulse hast. Was vielleicht nicht schlecht ist wenn du die Signale etwas Zeitversetzt versendest. Du bekommst dann eine Entfernung + x und als Entfernung für das erste Signal hast x. Dann kannst via Winkel das x berechnen. Durch das x kannst auf die X/Y Wert im Koordinatensystem schließen. (Bin aber zu faul mal das ganze durchzurechnen) VT: Es müssen nur die Basisstationen Synchron sein. Was aber sicher nicht das Problem sein würd. NT: Es erfordert enorme Rechenleistung von so einem ATmega wegen der Winkelfunktionen!!!! Aber ein paar mal müsste das so ein ATmega schon schaffen in der Sekunde. MFG Patrick P.S.: Das ist ein unerprobtes Konzept !!!
Watt Winkel? Wie soll ich von Schall den Winkel bestimmen? Und wenn ich meine Position nicht kenne kann ich auch keine Winkel zu den Baken kennen. Und wie der Master soll alleine synchron sein? Irgendetwas ist immer zu irgend etwas anderem synchron, aber niemals alleine...
Mhh ich weiß grade garnicht... kann sein, dass das nun ähnlich ist. Kann ich nicht die Baken alle mittels Kabel synchron halten (das geht ja) und einfach nur in regelmäßigen Abständen von jeder Bake ein US Signal senden. Nun kennt der Bot zwar nicht die Laufzeit aber die relativen Unterschiede zu den Baken. Kann ich das damit nicht auch berechnen?
Angehängte Dateien:
-
Spielfeld.PNG
8,5 KB
Die Trigometrischefunktionen brauchst und mindesten 3 Basisstationen. Natürlich auch etwas Hirnschmalz zum umformen der Formeln. Ich empfehle den Kosinussatz. MFG Patrick
Übrigens bedeuten Winkelfunktionen nicht zwangsläufig viel Rechenpower...
Naja Winkelfunktionen werden mit Polynomreihen gelöst wobei man ca 3 Polynom Glieder verwendet usw. Das dauert schon ein paar Takte besonders wenn man dann mit Float Werten rechnet. Für diese nicht sehr Zeitkritische anwendung spielt das nicht unbedingt eine Rolle(meine Meinung nach) MFG Patrick
Patrick Weinberger wrote: > Naja Winkelfunktionen werden mit Polynomreihen gelöst wobei man ca 3 > Polynom Glieder verwendet usw. Das dauert schon ein paar Takte besonders > wenn man dann mit Float Werten rechnet. Für diese nicht sehr > Zeitkritische anwendung spielt das nicht unbedingt eine Rolle(meine > Meinung nach) Siehste, und wenn man die Winkelfunktionen vorher berechnet, in Tabellen ablegt und Fixkomma verwendet dreht sich die ganze Sache zu Gunsten des Mikrocontrollers um.
Ich hab Ferien und mach für irgendjemanden das Denken ich bin echt krank!! Aja Tabelle ist immer so eine sache die Geschwindigkeit ist von der Genauigkeit abhängig. Wenn die Tabelle groß wird dauerts auch etwas. Dann müssen die Werte noch gerundet werden usw. Wobei man kann die Tabellen suche mit einfache Vorfilter extrem Beschleunigen MFG Patrick
Patrick Weinberger wrote: > Ich hab Ferien und mach für irgendjemanden das Denken ich bin echt > krank!! > > Aja Tabelle ist immer so eine sache die Geschwindigkeit ist von der > Genauigkeit abhängig. > Wenn die Tabelle groß wird dauerts auch etwas. Die Geschwindigkeit einer Array-Indizierung ist von der Größe der Tabelle abhängig? Das wäre mir völlig neu und überhaupt nicht logisch. EDIT: Achso, natürlich steigt die Prozessorlast, wenn statt einem, zwei Bytes geladen werden müssen. Aber nur ganz ganz leicht. > Dann müssen die Werte noch gerundet werden usw. Quark, kann man doch schon gerundet reinschreiben in die Tabelle. Bei weiteren Rechnungen muss man u.U. so oder so runden. Egal ob Tabelle oder nicht.
Wollte sagen die Anzahl der Einträge. Ich leid unter Koffein entzug.
@Patrick Weinberger: Danke für die Denkarbeit nur musst du mir nochmal auf die Sprünge helfen. So würde es ja nun aussehen wenn ich die absolute Laufzeit hätte. Die habe ich aber nicht. Ich weiß ja nur, dass Bake 1 und 3 etwa gleich weit weg sind und Bake 2 relativ dazu etwas weiter. Wie kann ich das nun umrechnen?
Hast mal eine Skizze von Spielfeld und Baken ? Wenn ich ehrlich bin war das mit Denkarbeit nur ein Scherz ein Konzept kann fast jeder aufstellen aber die Ausführung ist was anderes. MFG Patrick
Ufff, du fragst mich was. Wenn ich genau bin beschäftige ich auch nur mit dem Positions-Syastem für ein Team, welches am Eurobot 2009 teil nimmt. http://www.eurobot.org/commonfiles/docs/2009/E2009_rules_and_drawings-EN-final-v1.pdf (Siehe Seite 9)
Ich will jetzt ned lesen also was ist erlaubt zur Positionierung/was wird zur Verfügung gestellt ? MFG Patrick
Zur Verfügung gestellt wird garnichts. Lediglich Platformen soweit ich weiß. Und eine Plantform auf dem Gegner um seine Position bestimmen zu können. Man darf außerhalb alles aufstellen was man will, verkabel was man will halt nur nicht den Bot verkabeln.
Also es wär erlaubt 3 oder mehr Ultraschallsender aufzubauen? Gibt es eine Zeitbegrenzung zur Vorbereitung des Systems ?
Und genau da wären wir wieder beim GPS Prinzip: Für einen 3D-Fix brauchst du 4 Satelliten, da der 4. NUR für die Zeit zuständig ist. Die Laufzeit ist schnurzpiepe, der stellt bloß die Uhr vom GPS nach. Allerdings kann man das mit Ultraschall so nicht machen, da die Frequenzen viel zu tief sind... Was ich mich frage: Ist es mit 2 relativen Angaben nicht möglich, eine 2D Position in einem Rechteck eindeutig zu bestimmen? Als Beispiel: Senderpositionen sind bekannt und fix (eventuell Dreieck-Anordnung schlauer als 3 Seiten eines Rechtecks?) Alle Signale gleichzeitig -> Mitte des Spielfeldes (der einzige Punkt, wo der Abstand zu allen Kanten gleich groß ist). Nach etwas Überlegung: Position und Abstand der Sender sind im Roboter gespeichert (weitere Überlegung: Abstand ist egal, wenn es insgesamt um relative Positionierung im Spielfeld geht, also Position 1/5 X und 1/3 Y statt Rand +3cm und Rand +5cm) Nun betrachtet man nur die Signaldifferenzen: Nehmen wir A als Referenz, dann haben wir
und
.
bedeutet, dass der Roboter auf der AB-Achse in Richtung A verschoben ist.
bedeutet, dass der Roboter auf der AC-Achse in Richtung A verschoben ist. Das heißt schonmal, dass wir oberhalb der "Mittellinie" sind. Nun kann uns
noch die Verschiebung von der Mittelsenkrechten auf a (Strecke BC) angeben. Kommt B vor C an, so sind wir in Richtung B verschoben und umgekehrt halt Richtung C. Und was mir jetzt noch einfällt ist, dass das ganze absolut zum Mittelpunkt der Sensoren positioniert, da die Schallgeschwindigkeit ja eine Konstante ist. Eine Beispielrechnung: cSchall = 330 m/s. 1 Meter entspricht also 1/330 s also rund 3 ms.
Somit sind wir vom Punkt B 1 Meter weiter entfernt als von Punkt A: sB = sA+1. Punkt C ist 2 Meter weiter als Punkt A: sC=sA+2. Punkt C ist 3 Meter weiter als Punkt B: sC=sB+3. Dies sind 3 Gleichungen mit 3 Variablen. Aus irgendeinem Grund bin ich grad zu blöd die aufzulösen, wo ist denn hier mein Denkfehler? Das Prinzip sollte so aber funktionieren... Edit: Na klar, das Ding ist ja widersprüchlich... Hmm, vielleicht hätte ich mir keine Zeitwerte ausdenken sollen. Spricht aber immernochnichts gegen das Prinzip :-)
Für 2D Brauchst echt nur 2 Entfernungen, wenn die Sender Fixpunkte sind. Das Problem is das man nicht einen Synchronen Takt hat. Aber da wir bei der Differentiellen Positionierung eine Variable mehr haben Braucht man 3 Sender. MFG Patrick
Ufff... danke für die Überlegungen. Grübel auch grade darüber nach bin aber noch zu keiner Lösung gekommen und deinen Ansatz verstehe ich nur bis zu den deltas (einschließlich). Aber was du dann damit machst übersteigt grade meinen Horizont, bin auch etwas müde ;)
Ich komm auch grad ned mit :-) Also es gibt Flächen laut regelwerk wo man was aufbauen darf. MFG Patrick
Und was spricht dagegen, den DCF77 zu benutzen, um einen Uhrenquarz laufend zu korrigieren? Dann hättest du nur noch die Fehler, die sich durch Drift der Quarzoszillator-Frequenz während einer Sekunde ergeben, also absolut +/- 10 µs zu jedem Zeitpunkt. Man könnte auch den Frequenznormal des DCF77 verwerwenden - http://de.wikipedia.org/wiki/DCF77
Arghs klar, ich hab dann auch am Ende nen falschen Weg eingeschlagen. Also nun nochmal :-) 3 Sender. Ausgedachte Werte: A (0|0) B (0|-10) C (18|0) Nun empfangen wir A und nutzen das als Nullpunkt. B und C können also im Vergleich zu A negativ oder positiv sein. Beispiel ABSOLUTE Zeiten: A nach 100ms B nach 97ms C nach 136ms. Somit wäre (relativ) B=-3ms (-> -1 Meter) und C=36ms (-> + 12 Meter) :-) Nun wissen wir den Abstand von A und B: 10 Meter. Und den Abstand von A und C: 18 Meter. (Beide Werte an den Haaren herbei gezogen) Somit sehen wir nun, dass wir (10/2)-1 Meter von B entfernt und (18/2)+12 Meter von C entfernt sind.
und
. Grafisch würde ich nun Kreise um B und C ziehen, der Schnittpunkt ist das Ergebnis. Praktisch wird einer der beiden Schnittpunkte außerhalb des Feldes liegen :-) Mathematisch wird das ganze ne etwas komplexere Gleichung. Wir habne 2 Kreisgleichungen für B und C und müssen die gleichsetzen: b:
c:
So, mit der Hand auflösen tu ich das jetzt nicht, mein Maxima hat mir auch verraten, dass ich mir schon wieder blöde Zahlen ausgedacht habe... Aber das Prinzip sollte dieses mal wirklich passen :-) Es werden übrigens 2 Lösungen herauskommen (meistens), von denen eine außerhalb des gewünschten Spielfeldes liegen wird (hoffe ich), ansonten muss die wahre Position anhand der letzten eindeutigen Position (+ du weißt ja, wohin du dich bewegst) nachverfolgt werden.
Das ist doch der Kram für Funkohren oder? War das nicht viel seltener, also meine FUnkuhr braucht nen paar Minuten um nen Plan zu bekommen wir spät es ist. Und ich kann mir nicht vorstellen, das die Auswertung auf ne Millisekunde ganau ist...
Lies mal bei Wikipedia nach. Daß die Synchronisation aus dem Stand lange dauert, heißt nicht, daß ein synchronisierter Empfänger große Abweichungen hat. Der DCF77 sendet sehr präzise mit 77,5 kHz als Normalfrequenzsender- das mehr als die doppelte Frequenz eines Uhrenquarzes. Zitat Wikipedia: > Das Trägersignal von 77,5 kHz ist in Frequenz und Phasenlage mit der > steuernden Atomuhr synchronisiert und besitzt deshalb nur geringe > Abweichungen von der Sollfrequenz. Es kann auch ohne Auswertung der > Zeitinformation als Referenzsignal benutzt werden.
k, danke matze, ich gehe das morgen noch mal durch, bin grade total müde und verplant. Danke!
Naja, das Problem der Synchronisierung gibt sich ja wie gesagt durch den 3. Sender. Wenn es aber immer noch darum geht: DCF77 ist wirklich keine schlechte Idee, man müsste dann allerdings auf eine FLANKE des Sekundentakts synchronisieren (der ist keineswegs immer gleich! Die High/Low Zeiten sind nur in etwa 100/200ms mit relativ großen Toleranzen). Gut klar, wenn ich absolute Abstände direkt ermitteln kann, habe ich ohne Rechnerei meine 2D-Koordinaten, aber ich finde die Lösung mit dem 3. Ultraschallsender irgendwie feiner, universeller. Nachteil dabei ist eben, dass man die Koordinaten der Sender einstellen muss, bevor es funktioniert (dann also sogar variabel vor jedem Einsatz auf neuem Spielfeld). Ich hätte da übrigens mal ein neues Problem: Wie unterscheidet man bitte die verschiedenen Ultraschallsensoren? Klar, alle haben ne andere Frequenz. Aber kann man dieses Überlagerungsgemisch denn einwandfrei auswerten? Es muss möglichst genau von allen 3 Sensoren der Sendebeginn festgestellt werden (Die Auswertung darf ja auch ruhig einige 10 ms dauern, sofern dann eben der exakte Beginn ermittelt werden kann). Irgendwie find ich das Thema spannend und ich wäre sehr daran interessiert, welches Verfahren dann am Ende zum Einsatz kommt und wie gut es funktioniert. Jetzt geh ich aber schlafen, morgen gehts weiter. Frohe Weihnachten nochmal ^^
Matthias Larisch wrote: > Naja, das Problem der Synchronisierung gibt sich ja wie gesagt durch den > 3. Sender. Wenn es aber immer noch darum geht: DCF77 ist wirklich keine > schlechte Idee, man müsste dann allerdings auf eine FLANKE des > Sekundentakts synchronisieren (der ist keineswegs immer gleich! Nein, nimm die 77,5 kHz als Frequenznormal und schmeiß die Uhrenquarze weg. (Mein Beitrag oben ist Beitrag "Re: Zwei Controller synchronisieren" wieder iterativ entstanden ;-) )
Ähh... also die Sender haben ersteinmal alle die Gleiche Frequenz von 40kHz. Unterscheiden werde ich sie durch Zeitversetzung. Sprich wenn der 1. das Signal bekommt zum senden sendet er, der zweite hingegen wartet 20ms oder so und sendet dann, der 3. wartet 40ms. Der Bot "weiß" das und kann es ausrechnen, sprich von der gemessenen Zeit einfach die 20/40ms abziehen.
Noch mal zu dem DCF77 zurück: Willst du, dass ich da einen DFC77 Empfänger einsetze auf jeder Bake? Oder soll ich nur das Prinzip übernehmen? Und wenn ich da Toleranzen von 100/200ms habe, was zur Hölle bringt mir das? Da ist ein Quarz ja 100.000 mal genauer!
Zitat Wikipedia: > Das Trägersignal von 77,5 kHz ist in Frequenz und Phasenlage mit der > steuernden Atomuhr synchronisiert und besitzt deshalb nur geringe > Abweichungen von der Sollfrequenz. Es kann auch ohne Auswertung der > Zeitinformation als Referenzsignal benutzt werden. Vergiß die Uhrenquarze.
Du wolltest wohl mich zitieren? Klar, ich wollte nur sagen, dass DCF77 wohl nicht besser ist, oder?
Nein. Das Trägersignal des DCF77 ist in Frequenz und Phase hoch stabil - wie es sich für einen Normalfrequenzsender gehört. Nimm es als Taktquelle, statt der Uhrenquarze. Bau halt in jede Bake einen Empfänger ein, der den Takt von 77,5 kHz liefert - synchron für alle und hoch genau. Du mußt die Teile dann nur noch zu Beginn synchronisieren - per Kabel - und dann bleiben sie synchron.
Aha ok und wie komme ich an die 77,5kHz ran? Wird ja nicht der normale Output eines DCF77 Empfängers sein oder?
Im Prinzip ein Schwingkreis, der auf den Sender abgestimmt ist. Ob du ihn hast, das kannst du den Zeitzeichen entnehmen, aber ich schätze, daß das garnicht notwendig ist. Eine kleine Ferritantenne reicht aus. Lies dir den Wikipedia-Artikel durch - dann bist du im Bilde...
Nochmal für ganz Müde:
Der DCF77 sendet auf der Trägerfrequenz 77,5 kHz.
Da drauf sind die Zeitsignale moduliert. Die brauchst du aber höchstens,
um sicher zu sein, daß du deinen Normalfrequenzempfänger auch
tatsächlich richtig abgestimmt hast - ersatzweise reicht auch ein
einigermaßen genauer Frequenzzähler.
> ALso die 77,5 Khz sind die Trägerfrequenz?
Genau - muttu wiki lesen!
Gute Nacht...
Nacht...
Ich werde mir das alles mal durch den Kopf schwirren lassen... denke
aber die Lösung mit dem Kabel was alle Baken verbindet und dann nur den
relativen Abstnad bestimmen ist sicherlich am einfachsten, auch wenn ich
Mathematisch noch nicht dahintergestiegen bin ;)
>Genau - muttu wiki lesen!
erledigt!
Angehängte Dateien:
-
baken-berechnung.jpg
51 KB
So gestern abend habe ich mir im Bett noch den Kopf zerbrochen und bin auf die Lösung im Bild gekommen. Das ganze basiert nun auf keiner Synchronisation sondern legiglich der Tatsache, dass der Bot weiß in welchen Abständen die Signale kommen. Er kann so a,b,c berechnen (c ist hier 0) und hat somit 3 Gleichungen und 3 Unbekannte, sollte machbar sein. Jemand Einwände/Verbesserungsvorschläge? Edit: Wers nicht gleich sieht: das ganze basiert auf Pythagoras.
Joa nur ich rechne grade an den Gleichung rum und habe es inzwischen aufgegeben, mache es nun mit eine Matheprogramm was das kann nur der spuckt mir total den Scheiß aus. Wird schon richtig sein, sieht aber 1000 mal komplexer aus als es sein könnte :P
Irgednwie muss da nen Denkfehler drin sein. Wenn ich das ganze Zeugs zusammentuhe und nach x umstellen lasse ist es in Abhängigkeit von y und umgekehrt. Da das System aber eigentlich eindeutid ist sollte das nicht passieren oder?
Das Problem: Du kennst nur lx und ly und der Rob mißt a und b (c ist per Definition 0). Aus diesen Angaben kannst du d0 nicht berechnen. Es bleibt also nur, die Bakenpulse zu definierter Zeit loszuschicken, die auch der Rob kennt, um das d0 zu bekommen. Ergo: Du brauchst eine gemeinsame und zuverlässige Zeitbasis. Außerdem mußt du wissen, von welcher Bake der jeweilige Impuls kam - sonst gibt es 3 Lösungen. Diese Information erhälst du aber recht einfach, wenn die Baken nicht gleichzeitig, sondern zu jeweils einem eigenen definierten Zeitpunkt pulsen und die Pulslaufzeiten nicht überlappen.
Irgendwie drehen wir uns im Kreis. Das die Baken nicht alle gleichzeitig senden ist klar und wurde auch schon erwähnt. Und dass der Bot nen Impuls aussendet hatten wir auch mehr oder weniger verworfen, da das mit der Synchronität zu schwer wird. Die einzige Alternative wäre wiegesgt das DCF77 Signal, was ich aber auch erstmal ohne probieren wollte, weils einfach einfacher ist. Also, nochmal ne Frage: Ist in der Zeichnung die ich gemacht habe die Poition geometrisch bestimmt, wenn a,b,c,lx und ly bekannt sind? Ich meine ja und wenn das der Fall ist gibt es auch eine Mathematische Berechnung dafür, wir sind nur zu blöd sie zu finden.
Ich habs mit Maxima rechnen lassen - man kann x und y nicht isolieren und damit nicht ausrechnen. > Irgendwie drehen wir uns im Kreis. Das die Baken nicht alle gleichzeitig > senden ist klar und wurde auch schon erwähnt. Dann kommst du um synchrone Baken und Robo sowieso nicht herum. Sieh dir das mal an: http://www.prog-link.com/dcf77/dcf77-16.html Den Empfängerchip wirst du wohl nicht brauchen, aber die Testschaltung unten zeigt, wie man den Empfangskreis basteln kann. Der Rest wäre nur noch ein Verstärker, der das Signal am Schwingkreis abgreift und nachfolgend ein Schmittrigger, um einen Taktpuls draus zu machen.
Nein, die Gleichungen sind für sich richtig, aber die Information reicht nicht aus, aus lx, ly, a und b die Koordinaten x,y zu berechen. Wenn g1...g3 deine Gleichungen sind, ergibt solve([g1,g2,g3], [x,y]); die leere Menge - also ist es unlösbar.
Wenn du sagst die Informationen reichen nicht, heißt es, dass es geometrisch nicht bestimmt ist. Warum? Wo? Was fehlt?
Naja normal würde ich sagen, 3 Gleichungen, 3 Unbekannte, flutscht doch...
Um die Position zu berechnen brauchst du lx, ly und das Wissen, daß die Baken ein rechtwinkliges Dreieck aufspannen und in diesem Umfeld den Abstand des Robots von jeder der Baken. Indem du eine unbekannte(!) Pseudovariable d0 einführst - die eigentlich das C ist, wenn die beiden anderen Abstände A und B sind - bekommst du das fehlende C nicht - da hilft kein Heulen und kein Zähneklappern...
Wasn das für ne Mathematische Aussage? Weil etwas unbekannt ist bekommt man es nicht raus?
> Wasn das für ne Mathematische Aussage? Weil etwas unbekannt ist bekommt > man es nicht raus? Ja eben - das ist genau das, was du treibst...
Hä? mal angenommen du hast (x+2)^2=16, so und x bekommt man nun nicht raus, weil es unbekannt ist? Ist ja ne seltsame Mathematik...
Ok das geht aber GPS arbeitet nach dem Gleichen System ! (GPS-Grundgleichungen ohne Störeinflüsse http://de.wikipedia.org/wiki/GPS-Technologie#Ber.C3.BCcksichtigung_vermeidbarer_Signalst.C3.B6rungen ) Also Wenn die ned Stimmen würd GPS ned gehen. MFG Patrick
Fabian S. wrote:
> Oder du kannst nicht vermitteln was du mir sagen willst...
Ein Gleichungssystem mit drei Gleichungen und drei Unbekannten hat nicht
unbedingt eine Definierte Lösung. Es kann auch keine (Zum Beispiel wenn
die Gleichungen keinen Zusammenhang haben, also nicht alle zutreffen
können), oder mehrere haben (Beispielsweise wenn eine Gleichung nur eine
andere der vorhandenen Gleichungen ist, nur umgestellt.
Krasses Beispiel:
I) a = b+c
II) a = b+c
III) a = b+c
Was ist die Lösung? ;)
Würde ja heißen, dass die Gleichungen linear von einander abhängig sind, sind meine aber glaube ich nicht :(
leute wo ist das problem? die baken müssen nur kommunizieren. Wenn sich alles in einer Ebene abspielt , bei konstanter Signalausbreitungsgeschwindigkeit: Bake 1 sendet und Bake 2 wartet wenn das Signal bei Bake 2 eintrifft antworet diese. Aus der laufzeit ergibt sich die Distanz zwichen den Baken. Wenn jetz dieser parameter codiert gesendet wird kennt der Bot den Abstand der Baken zueinander. Wenn er beide Baken abhöhrt und laufzeitdifferenzen ermittelt gibt es genau 2 Punkte an denen er sich befinden kann. Spielt eine dritte Bake mit gibt es genau noch einen punkt. Zwei baken genügten bei Peilung bei Laufzeit brauchst du minimum 3 Signalquellen google nach Loran, Decca
Das Problem geht auf die Berechnung des Schittpunktes dreier Kreise
zurück, nämlich denen um die Baken.
Wenn man die drei Radien a, b, c nennt, ergeben sich daraus folgende
Kreisgleichungen:
g1: a² = x² + y²
g2: b² = (lx-x)² + y²
g3: c² = x² + (ly-y)²
Löst man das Gleichungssystem nach a, b, c auf, erhält man eine
Lösungsmenge mit 8 Lösungen, von denen mindestens eine für ein Paar x, y
sinnvolle Werte für a, b, c liefert.
Sinnvolle Werte sind positiv reell und es gilt:
lx²+ly² >= v mit v aus {a, b, c}
Man muß sich also die passende Lösung aussuchen.
Damit der Robo seine Position berechnen kann, muß die ganze Chose
umgedreht werden: Man mißt, a, b, c und sucht dafür ein Paar x,y, das im
oben definierten Sinn "sinnvoll" ist.
Man muß also die oben skizzierte Vorgehensweise umdrehen und in der
Lösungsmenge nach einem Paar x,y suchen, das zu den gemessenen a, b, c
"paßt", wobei schon kleine Meßfehler zu Unlösbarkeit führen - die Kreise
schneiden sich dann nicht in einem Punkt.
>Die Kreise schneiden sich dann nicht in einem Punkt.
uhu;
..man erhält dan ein Dreieck aus drei Schnittpunkten je zweier Kreise.
An der Stelle interpoliert der Seemann und definiert den Fehlerkreis.
Praktikablerweise bringt hier der Mittelpunkt des Dreiecks die
wahrscheinlichste Lösung
Klar, das ist die praktische Lösung, mit den Fehlern fertig zu werden. Ich wollte damit nur aufzeigen, daß man nicht hoffen kann, ein lineares Gleichungssystem mit drei Unbekannten ausgaußen zu können, um die richtige Lösung zu bekommen - es ist kein lineares Gleichungssystem. Die Definition für "sinnvolle" Lösung oben gilt nur für quadratische Spielfelder - bei rechteckigen wirds deutlich komplizierter.
Ich habe gerade nicht soviel Zeit dazu, aber ich habe mir vorhin nochmal Gedanken gemacht und meine eigentlich, zu einer sinnvollen Lösung gekommen zu sein, ähnlich (aber nicht genau) nach dem zuletzt von mir mathematisch beschriebenen Verfahren. Ich bin schon der Meinung, dass man das Problem auf 2 Gleichungen mit 2 Unbekannten reduzieren kann, da der 3. Sender ja nur zur Zeitfeststellung dient, d.h. durch die Kenntnis des 3. Wertes werden die anderen 2 Werte "absolut". (nicht ganz, aber sozusagen ^^). Ich werde das morgen mal verschriftlichen, heute abend komm ich nicht mehr dazu.
Ohh man seit ihr Experten :D (nicht böse gemeint) Also ersteinmal wenn die Baken mit dem bot kommunizieren reichen auch 2 Baken, sofern sie an einem SPielfeldrand stehen, denn die 2. Lösung wäre außerhalb des Spielfeldes und kann somit ausgeschlossen werden. Und mir ist klar, dass ich das damit machen KANN nur wollte ich den Technischen Aufwand möglichst gering halten.
Da kommt mir jetzt eine Idee. Wir haben ja Anfangswerte der Roboter beginnt das Spiel an einer Fixenposition. Und eine ansynchrone Uhr. Also 1. es wird auf den ersten Schalimpulse gewartet und dann die Uhr synchronisiert 2.nach den Schallimpulsen kommt heraus das die Uhr hinten oder vor ist. 3.Es wird die Uhr neue abgeglichen in dem man einen idealen Schnittpunkt der 3 Laufzeiten interpoliert. 4. Schrit 2 und 3 wird so lang wiederholt bist die Uhr synchron genug ist Das dauert hald eine Weile und die Interpolation muss werden des Spiels nur mehr minimal gemacht werden. Der Vorteil ist man bekommt nur einen kleinen Kreis mit möglickeiten wo man sich befindet. MFG Patrick
@fabian, dann ist ja alles klar: syncronisieren heist kommunizieren wer wie mit wem ist egal, die SW kann Hw z.T. ersetzen.
Ich kann Kommunikation nur mit Software machen, ohne Hardware? Cool! Ich gehe mal davon aus, dass ich was falsch verstanden habe ;)
...siehe oben z.T. bezog sich auf den HW-Aufwand zum Abgleichen der Quarze. Den kannst du dir schenken wenn mindestens eine Bake die Zeit der anderen kennt. Entweder muss sie die andere Bake hören, oder sehen können. Wobei sehen wohl besser ist. Funk allerdings wäre auf engem raum noch leichter. Eigentlich sollte eine Antenne am Ersten und ein Geradeausempfänger am 2.µC genügen, dann macht der master den Takt auch für den Slave?
Warum kann ich mir den Aufwand schenken? Klar kennen die Baken sich untereinander, habe ich ja gesagt, dass man die einfach mit nem Kabel verbinden kann und fertig.
Wenn die Baken verbunden sind, gibt die Masterbake die Zeit vor. Die Andere piebt nur auf befehl. Bleibt der Bot asynchron. Um ihn zu synchronisiern genügt es das er stehenbleibt und die Ultraschallfrequenz der masterbake(flanken detektieren) ermittelt bei 40KHz/10MHz sollte die Zeit zwischenden Flanken für das Errechnena/Auszählen des Korrekturwertes genügen. Diesen Wert kann er dann auch in der Bewegung kontrollieren. Da ich davon ausgehe, dass die Bots sich nicht nahe der Schallgeschwindigkeit bewegen eher v(bot) << v(Schall) sollte der Dopplereffekt irrelevant oder korrigierbar bleiben. ;)
irgendwie versteh ich die Welt nicht mehr, mein Ansatz funktioniert nicht... (Hatte eben doch noch etwas Zeit) Aber für
gilt immerhin schonmal (bei xC=yB und yC=xB=0)
für "geschätzte" X und Y Koordinaten. Wo da der Wurm drin ist weiß ich selbst nicht so genau, da fehlt noch irgendein unlinearitätsfaktor... Den Rest meines Ansatzes kann man total verwerfen (das hier eigentlich auch - aber ich wollts wenigstens noch schreiben)
@matze: hihi ;) geht mir ständig so :D
>Um ihn zu synchronisiern genügt es das er stehenbleibt...
NEIN!
Das Spiel hat 90 Sekunden, man muss Würfel einsammeln, die zu einem Turm
zusammenbauen und an bestimmen Orten ablegen, da bleibt absolut keine
Zeit zum stehenbleiben. Zumal das ablegen der Klötzchen Zentimetergenau
passieren muss!
So, ich sehe schon das mit den Gleichungen wird immer komplexer. Auch
wenn ihc immernoch der Meinung bin, dass es mit meinem auf dem Bild
vorgeschlagenen Methode gehen muss werde ich darauf verzichten und die
Teile mit DCF77 synchronisieren.
Jemand Einwände? :D
Weiß vorallem jemand wie ich an die 77,5kHz ran komme und wie ich sie
aufbereiten kann, so dass ich das direkt an den Interruptpin anschließen
kann?
zum Synchronisieren genügt die Sekundenflanke die 77,5 kHz hat keinen TTL_Pegel und auch in einem Geradeausempfänger wirst du kaum ein sauberes Signal bekommen. Üblicherweise wird auf 625 Hz herruntergemischt mit einem 78.125Khz VFO und PLL und dann das 1Hz signal demoduliert.
Aber den VFO der PLL könnte man anzapfen und verstärken. Das könnte ich suchen. Ich habe bisher nur den Sekundentakt ausgekoppelt, der die Quartzuhr synchronisiert.
Aha - ich versteh nur Bahnhof... Warum das 1Hz Signal rausholen, wenn ich auch gleich das 77,5er verwenden kann? Gestern hatte jemand diesen Link gepostet, dann aber wieder gelöscht: http://www.prog-link.com/dcf77/dcf77-16.html Da sind ja nun die beiden Quarze angebaut mit 77,5kHz. Ich gehe mal davon aus, dass die nicht das Maß der Dinge sind sondern intern an die 77,5kHz von dem Signal angeglichen werden (man kann Quarze doch ziehen oder so). Wenn das der Fall ist, kann ich mich dann da nicht einfach mit dran klemmen und fertig?
Das ist nen klassischer Geradeausempfänger mit 2 Quartzen, die hier als schmlabandige Bandfilter Serienschwingkreis ersatz hoher Güte) eingesetzt sind. Auch wenn die Selektion gut sein sollte dürfte das Signal nicht gerade üppig ausfallen, noch dazu in verschmutzter EM_Umgebung.
was möchtest du höhren? und warum so umständlich Darfst du erst wärend des spiels synchronisieren? oder kann das vor dem startsignal geschehen? zum Synchronisieren zweier Zeitbasen genügen 2 Flanken und 2 Zähler deren Differnz den Korrekturfaktor bezogen auf den Basiszählerwert gibt. Diese Faktor genügt für alle weiteren Berechnungen, sofern die Zeitbasis stabil bleibt, egal ob sie synchron ist. Sie wird in 2 Minuten kaum driften. andererseits Wenn du eine Bake mit 0.1 mW auf 0.15-30 oder auf 433 MHz am Spielfeld senden lässt hast du ein deutlich stärkeres und Stabileres Synchronsignal als mit irgendeinem DCF Emfänger
>Wenn das der Fall ist, kann ich mich dann da nicht einfach mit dran
klemmen und fertig?
nein nicht an den Quartz
Aber an Pin 16 liegt so empfangbar der 77,5 KHz Takt an.
Winfried J. wrote: > was möchtest du höhren? Keine Ahnung, eine Anregung? Habe kein Plan von sowas :( > > und warum so umständlich > > > Darfst du erst wärend des spiels synchronisieren? > oder kann das vor dem startsignal geschehen? > > zum Synchronisieren zweier Zeitbasen genügen 2 Flanken und 2 Zähler > deren Differnz den Korrekturfaktor bezogen auf den Basiszählerwert gibt. > > Diese Faktor genügt für alle weiteren Berechnungen, sofern die Zeitbasis > stabil bleibt, egal ob sie synchron ist. Sie wird in 2 Minuten kaum > driften. Ich soll ne Software-Korrektur einbauen? Und wie berechne ich den ganzen Kram mit Temperaturschwankungen etc??? > > > andererseits > Wenn du eine Bake mit 0.1 mW auf 0.15-30 oder auf 433 MHz am Spielfeld > senden lässt hast du ein deutlich stärkeres und Stabileres > Synchronsignal als mit irgendeinem DCF Emfänger Klar, vorallem weil ich Amateurfunker bin... denke da würden wir sofort disqualifiziert werden!
Winfried J. wrote:
> Aber an Pin 16 liegt so empfangbar der 77,5 KHz Takt an.
Aha...sicher? Sieht für mich eher aus wie das bereits dekodierte Signal,
mit den Sekunden-Flanken.
oops habe den dekoder nicht darin vermutet aber an Pin 7 sollte es klappen http://www.datasheetcatalog.org/datasheet/Temic/mXyzuryw.pdf
Und das Signal sie in etwa wie aus? Ist das ein Rechtecksignal oder noch Sinus? Welche Amplitude? Und was viel wichtiger ist: Hat jemand eine Idee wo ich das IC herkommen kann, nach Möglichkeit nicht für ein halbes Vermögen.
Fabian S. wrote: >> andererseits >> Wenn du eine Bake mit 0.1 mW auf 0.15-30 oder auf 433 MHz am Spielfeld >> senden lässt hast du ein deutlich stärkeres und Stabileres >> Synchronsignal als mit irgendeinem DCF Emfänger > Klar, vorallem weil ich Amateurfunker bin... denke da würden wir sofort > disqualifiziert werden! Falls das Ironie war: Für die angegebene Frequenz/Leistung muss man kein AFU sein.
Aha wusste ich garnicht... und was meintest du mit 0,15-30? Mhz? wären ja minimal 150kHz. Würde ja passen. Aber warum dann nicht einfach das DCF77 Signal verwenden? Meinst das ist zu schwach?
Nein muss man nicht, es war durchaus ernst gemeint. 27 und 433 Mhz CB/ISM währen durchshaus nutzbar. Außer dem, wen dein µC durch "ungünstige" Leitungsführung QRM erzeugt(im zulässigen Rahmen), so kannst du den durchaus für die Synchronistion nutzen ;-) oder ist das in den Spielregeln ausgeschlossen?
Weiß ich jetzt nich ob das ausgeschlossen ist. Ich würde es ja auch dann wohl nicht so machen, dass ich den Sender selber baue (habe ich zu viel Angst da ne Frequenzschleuder hinzustellen) sondern einfach en normales Funkgerät oder so dafür nehme. Sollte ja auch gehen oder?
Ja das Signal wird zwar mit 10KW gesendet ist aber ortsabhängig sehr schwach und wird stark gestört. Es gab mal ne CB-Freq für Lehrzwecke im LW-Band glaube 123kHz. Ein Elektronikbaukasten hatte da mal HF Experimente drauf. Weis aber nicht ob das noch aktuell ist.
Nochmal zum Mitdenken: Der DCF77 hat angefangen als Normalfrequenzsender - da hatte er noch kein Zeitzeichen aufmoduliert. Mittlerweile hat ers und auch noch Wetterinformation - aber er ist immer noch ein Normalfrequenzsender, der in Frequenz und Phase hoch genau mit einer Cäsium-Atomuhr synchronisiert ist. Einzelheiten hier: http://de.wikipedia.org/wiki/DCF77 http://de.wikipedia.org/wiki/Normalfrequenz Wenn man aus dem Trägersignal, das man mit einem Schwingkreis mit einer Ferritantenne empfangen kann, ein Rechtecksignal gewinnen kann, dann hat man zu mindest die Frequenz 77,5 kHz mit sehr geringer Abweichung, die man als Takt verwenden kann - denke ich zumindest. Den Empfängerchip braucht man dazu nicht wenn man das Zeitsignal nicht decodieren will.
868Mhz ISM module sender http://www.box73.de/catalog/product_info.php?cPath=112_113&products_id=117&osCsid=4cabfec120d3becf1cf5a0ed0fc0e296 empfänger http://www.box73.de/catalog/product_info.php?cPath=112_113&products_id=118&osCsid=4cabfec120d3becf1cf5a0ed0fc0e296
Ok und wozu soll ich die Module verwenden? Nur um die Tragerfrequenz zu erzeugen? @Kleber: Wenn ich das IC nicht einsetze, wie geht das dann? Schwingkreis?
@ uhu Das problem ist, das das Signal äußerst Schwach und nur sporadisch emfangbar und stark gestört ist nur eine aufwendige Fehlerkorrektur (Plausiblitätsprüfung) erlaubt, es überhaupt sinnvoll auszuwerten, wenn mann nicht unnmittelbar neben dem Sender steht. In einer Halle voller QRM braucht man schon fast Korellationsempfänger, das Signall in all dem Müll wiederzufinden.
Aha ok. Und wie mache ich das dann mit 433Mhz? Die kann ich ja schlecht an den Interrupt Pin hängen? Brauch ich da wieder son Frequenzteiler oder wie die heißen?
um eine eigene zetbasis zu senden, welche die slaves syncronisiert. einfach wie ein metronom tickenlassen in bake "A" empfänger in bake"B" und Bot
Du taktest den Sender, und die AM empfänger liefern dir den Takt in dem du den Sender ein und ausschaltest.
So... es gibt noch eine viel einfachere Lösung, auf die Patrick gekommen ist. Genau wie GPS es macht. Man synchronisiert einfach alle Baken untereinander mit Kabel. Tut auf beide Seiten ein Quarz. Wenn nun der Bot der Zeit vorauseilt werden die berechneten Entfernungen du den Baken immer kleiner werden als sie in wirklichkeit sind. Wenn man nun mehrere Baken einsetzt wird sich zeigen, dass die berechneten Schnittpunkte eine größere Streuung haben. Sellt man das fest kann man mit der Schallgeschwindigkeit berechnen um wie viel der Quarz im Bot falsch läuft und er korrigiert ihn. So einfach ist das ;)
Guten Morgen In diesem Falle wollte ich anzeigen, dass ich den Sendebetrieb einstellte. noch ein Funknahes Verfahren fällt mir da ein das aber kein Funk ist! mit eienr Induktionsschleife könntest du alle Bots syncronisieren. Ich besaß in meiner Kindheit vor 40 jahren ein Fahrzeug welches bei jedem Impuls innerhalb der induktionsschleife die Richtung wechselte. http://www.itwissen.info/definition/lexikon/Induktionsschleife-inductive-loop.html dabei wurde ein Verfahren benutzt wie bei der Höhrgeräte akustik die schleife begrenzte das aktionsfeld, und die signale wurden als NF eingespeist. innerhalb der schleife konnte das fahrzueg diese NF sigale empfangen. das ginge auch mit einem µ und einem Kleinem Verstärker sogar Phasenkorrekt, einfach ein flachbandkabelmit zehn inreihe geschalten adern um das Spielfeld legen und alle Bots kennen die Systemzeit.
Joa wäre auch ne Möglichkeit ;) Ich werde mich heute mit meinem Audio-Spezialisten treffen und den ganzen Krempel mal aufbauen. Melde mich dann wieder wenn es läuft oder noch mehr Probleme gibt.
Sorry ich muss hier nochmal für Unruhen sorgen ;) Ich brauche ja nun im Bot und in den Baken ein Quarz. Was würdet ihr mir empfehlen? Ein Uhrenquarz direkt an den Timer anschließen oder einfach nen normales 8/16Mhz Quarz nehmen, damit den µC antreiben und dann mit dem Timer auf die gewünschte Frequenz machen? Was ist verallem genauer?
Spar dir den Uhrenquartz. Wenn du serielle Comm(UART nutzen willst nim nen 11,0592 Mhz) der ist für 19.200 Baud geeignet Wichtig ist ansonsten das man eine ms(oder 100µs) genauae systemuhr hat, die alle systemkomponenten zu synchronisieren vermag und das alle systemekompnenten schnell genug sind dieser zu folgen.
Seriell? Kann ich doch auch mit nem 16er verwenden? Habe ich zumindest
bislang immer gemacht und ging wunderbar.
> Wichtig ist ansonsten das man eine ms(oder 100µs) genauae systemuhr hat, ...
Ja und meine Frage war, wie ich das am besten mache. Du sagst einfach
nen normales Quarz und Timer mit Prescaller/Overflow verwenden?
joop aber halt die baken und bots syncronisieren(z.B. Korekturfaktor für die autonomen)
Faktor? Ich wollte das nun wie zuletzt beschrieben immer zur Laufzeit neu korrigieren.
>Schallgeschwindigkeit berechnen um wie viel der Quarz im Bot falsch >läuft und er korrigiert ihn. ja mit einem Korrekturfaktor z.B. 1002/1000 oder 998/1000 heist bezogen auf die basis, muss der interne timer statt 100o takte 1002 takte zählen, Korrekturfaktor = 2 promille umgekehrt 998/1000 Korrekturfaktor = -2 promille oder genauer vielleicht -1958 pro µ
faktor= normierte differenz
Winfried J. wrote: > Spar dir den Uhrenquartz. > Wenn du serielle Comm(UART nutzen willst nim nen 11,0592 Mhz) der ist > für 19.200 Baud geeignet Oder 14,7456MHz. Aber damit gehen eigentlich alle Baudratenfrequenzen zwischen 1200-115200 Baud (theoretisch) Fehlerlos, nicht nur 19200Baud. Mit 16 MHz kommst du nur auf ein paar Frequenzen mit einem kleinen Fehler. (1200, 2400, 19200 usw.). Zumindest bei den normalen AVRs. Die XMega AVRs haben ja nun endlich auch fractional baud rate divider :-)
SO.... war bis grade beim Kollgen und wir haben mal den ganzen Hardware Krempel aufgebaut. Funktioniert auch relativ gut. Also die gesendeten Signale kommen beim Micro klar und deutlich an, man kann jeden Millimeter Bewegung auf dem Oszi erkennen, aber es gibt ein Problem: Irgendetwas schwingt extrem nach. Hier gibts nen Video: www.dirk-soft.de/CIMG3028.AVI Da sieht man es ein wenig. Oben der Sender, unten das Mic. Die Signaldauer der Mics ist deutlich länger als die des Senders. Reflektionen von Wänden etc sind es meiner Meinung nach nicht, da das ganze länger wird, wenn man es dichter an den Sender hält. Was ja bei Reflektionen von Wänden egal wäre. Das Signal bestand zu dem Zeitpunkt aus 10 Schwingungen, danach folgt eine lange Pause. Kann sich das jemand erklären? Braucht ihr mehr Infos wie die Beschaltung war?
Fabian S. wrote:
> Braucht ihr mehr Infos wie die Beschaltung war?
Das wäre sehr wünschenswert, denn was ihr da gebastelt habt,
erschließt sich mir überhaupt nicht.
Angehängte Dateien:
-
empfaenger.png
1,9 KB
Hier schon mal die Empfängerschaltung. Danach kommt dann noch ein Verstärker-OP mit Faktor 100 und ein analog Komparator. Das ist aber nicht wichtig, da das Problem bereits bei diesem Schaltungsaufbau besteht. Ich mach eben noch den Sender...
joop das hatte ich hier auch schon mal die Mikes müssen (glaube ich) eine entsprechende Bürde(Last)bekommen um gedämpft zu werden. Sieh mal ins Datenblatt.
erklärung: lasse einen Gummiball fallen. ... richtig ein Impuls reicht solange bis die Energie in Wärme umgewandelt wurde. Die Dämpfung ist umgekehrt proportional, der Sensiblität also macht man die Mikes so empfindlich wie möglich, und der nutzer muß eine entsprechende Bürde basteln. Dämpfen ist einfacher als empfindlicher machen ;)
wie belastet man einen generator? nen R(C) Glied nach Ground ? ein wenig üben... aktive gegenkopplung? datenblatt + versuch macht klug
Warum muss sich jeder so ausdrücken, dass ich es nicht verstehe? :D Meinst du das? http://de.wikipedia.org/wiki/B%C3%BCrde Und was ist mit dem Sender? Schwngt der nicht auch?
Ähh die Senderschaltung bekommt ihr nicht, ich blick da nicht durch. (Habe ich nicht selber gebaut, nur zugesehen^^) Wenn ichs recht verstanden habe einfach ein 40kHz Signal vom µC und ein Schmitt-trigger. Der Sender bekommt dann +/-5V Rechteck.
ja das wollt ich dir gerade schreiben. Die Transmitter schwingen auch nach sind aber insgesammt träger und unsensibler als die Reciver, da sie mehr Energie umsetzen(aushalten)sollen. Speichern also auch mehr Energie.
Fabian S. wrote: > Wenn ichs recht verstanden habe einfach ein 40kHz Signal vom µC und ein > Schmitt-trigger. Der Sender bekommt dann +/-5V Rechteck. Wohl eher ein Pegelwandler, der die µC-Signale sind ja schon ziemlich steil, aber eben nicht +/- 5V
Joh, so hatte ich das auch gemacht. Allerdings habe ich festgestellt das eine Erregung mit einem 1µS impuls am Sender den Empfäger ca. 20ms nachschwingen lies. Es handelte sich um Tests für einen US-Entfernungsmesser. Die maximale Entfernung lag bei ca 2,5 m. Die minimale auswertbare Entfernung bei ca. 10 cm.
Uhu Uhuhu wrote: > Wohl eher ein Pegelwandler, der die µC-Signale sind ja schon ziemlich > steil, aber eben nicht +/- 5V Ja ist auch nur so in etwa, haben zur Zeit ne Notlösung meinte er, mit einem NE555 ;) Winfried J. wrote: > Joh, so hatte ich das auch gemacht. Allerdings habe ich festgestellt das > eine Erregung mit einem 1µS impuls am Sender den Empfäger ca. 20ms > nachschwingen lies. Es handelte sich um Tests für einen > US-Entfernungsmesser. Die maximale Entfernung lag bei ca 2,5 m. Die > minimale auswertbare Entfernung bei ca. 10 cm. Und hast du das mit dem Nachschwingen in Griff bekommen oder einfach ignoriert?
Für die, die etwas rätseln wollen, hier ein paar Bilder vom Empfänger.
Aha, du bist also ein Wiedeholungstäter ;-) -- Sehr interessant.
ja ich habs schon vor nem jahr rumpiepsen lassen, weiß aber nicht wie weit michael noch kam.
> Um ein Nachschwingen zu unterdrücken muss während der letzten halbwelle > eines Microbursts eine genau die Schwingunsenergie zeherenden aktive > Dämpfung erfolgen. Sehr schön. Und wie kann ich mir das vorstellen?
Beitrag "Controller Synchronisation über FBAS-Signal" Beitrag "Synchronisation über Funk" Folgende Lösung wurde realisiert: Im Raum wurden 4 Ultraschall-Sender installiert (in jeder Ecke einer). Diese sind über eine Leitung synchronisiert. Sender 1 (X1/Y1/Z1): Sendet alle 02, 12, 22, 32, 42 und 52 Sekunden jeder Minute einen Impuls. Sender 2 (X2/Y2/Z2): Sendet alle 04, 14, 24, 34, 44 und 54 Sekunden jeder Minute einen Impuls. Sender 3 (X3/Y3/Z3): Sendet alle 06, 16, 26, 36, 46 und 56 Sekunden jeder Minute einen Impuls. Sender 4 (X4/Y4/Z4): Sendet alle 08, 18, 28, 38, 48 und 58 Sekunden jeder Minute einen Impuls. Der autonome Roboter kennt die Koordinaten der Sender 1..4 und hat einen Ultraschall-Empfänger. Aufgrund der Laufzeiten errechnet sich der Roboter alle 10 Sekunden seine Position neu (Koordinaten: Xr/Yr/Zr), und dies mit einer Genaugigkeit von +/- 5mm. Die ganze Berechnung wurde in Integer-Format realisiert und ist verdammt schnell...
Genau so will ichs auch machen, nur ohne Synchronisation, da es ja wie bereits mehrfach gesagt nicht nötig tut.
Irgendjemand hatte ja den Tipp gegeben, dass man das Mic belasten soll. Kann mir jemand sagen mit wie viel Ohm etwa? Der Pull-Up hat 10k, wenn ich da nun ne 10k Belastung dran mache hat das Mic ja nur noch die hälfte der Spannung, ist das schlimm?
Hab jetzt nur bis zur Hälfte des Threads gelesen... Bei uns an der Uni (JKU Linz) beschäftigen sich auch einige Leute mit so genanntem Local Position Measurement (LPM; Stichwort Hallen-GPS). Hab leider keine tieferen Einblicke in deren Arbeit, aber das alles ist nicht wirklich einfach. Mir scheint die Lösung mit relativer Zeitmessung am sinnvollsten.
Hat noch jemand eine Idee wie ich das Nachschwingen verhindern kann?
Das Nachschwingen kannst du nur mit sanfter Gewalt verhindern. Du hast einfach die falschen US-Wandler ausgesucht. Dein Wandler ist für hohen Wirkungsgrad gezüchtet, damit die umliegenden Schaltungsteile möglich billich billich sein können. Du brauchst eigentlich breitbandige Wandler, z.B. die von Polaroid bzw. suche dir welche mit möglichst hoher Arbeitsfrequenz. Es gibt auch welche mit 100kHz aufwärts. Der einfachste schnelle Fix wäre eine Miniatur-Mikrofonkapsel nur für den Empfänger. Nicht alle, aber viele, gehen locker bis 40kHz wenn man nicht die volle Empfindlichkeit nutzen muß. Gruß - A.
Was meinst du mit US-Wandler? Umwandler von Schall in Strom, sprich nen Mic? Also denkst du, dass es am Mic liegt? Was mir da grade noch seltsames einfällt: Als wir das ganze am Oszi hatten, hatte ich mal ein Programm geschrieben, was ein Burst von 20 Pulsen sendet und dann eine Pause macht. Nach den 20 Pulsen war wieder das nachschwingen. Aber: Ich hatte in der Mitte einen Impuls ausgelassen, also das Signal ein wenig kodiert. Hat auch funktioniert, da man es dann piepen hören konnte. So naja das interessante war nun, dass man auf dem Oszi (was am Mic hing) den fehlenden Impuls super sehen konnte! Wie kann das sein, wenn das doch nachschwingt?
Voll gegenkoppeln und den ersten OAmp (Verstärkung <= 1) lediglich als Puffer nutzen und erst am 2.OAmp verstärken. Die Leistung am Sender über Spannungsteiler reduzieren. Ich werd morgen mal tests dazu machen
Die Leistung zu minimieren ist keine Alternative, da der Schall schön weit kommen muss. Wieso zwei OPs? Bislang habe ich nur einen und wollte den jetzt durch ein L293d ersetzen, weil ich 4 Sender betreiben muss :( Der hat dann ja noch mehr Power.
US=Ultraschall-Wandler Ich dachte das wäre dein Problempunkt? Ich habe vor Jahren mal vermutlich die gleichen Kapseln wie du ausprobiert, in einer Plastikröhre. Man konnte die Laufzeit des Signals gut messen. Durch das Nachschwingen hat man aber eine räumliche Totzeit von ca. 10cm gehabt, wenn man es nicht irgendwie unterdrückt. Wie sieht dein Sender aus? Steuerst du den Wandler resonant an? Das wäre dann in deinem Fall schlecht. Du willst ja möglichst heftige kurze Impulse. Also einfach mit einem kräftigen Treiber den US-Geber 'rumreißen'. Der darf gar nicht mehr dazu kommen ein Eigenleben zu entwickeln. Dsa bessert das Verhalten wesentlich. Es bleibt aber bei der Aussage, das die Kapseln für hohe räumliche Auflösung ungeeignet sind! Am Empfänger kannst du einen Impedanzwandler verwenden. Die sind am Eingang sehr niederohmig und damit bedämpfen sie den US-Empfänger. Suche bei Google nach "Impedanzwandler OpAmp" z.B. als Fotodioden-Verstärker. Problemkreis der gleiche wie bei dir. Einfacher wäre ein passendes Mikrofon als Empfänger zu verwenden. Die sind von Natur aus breitbandiger. Merke: Bandbreite antiproportional Ein-/Ausschwingzeit Lese doch einfach mal über Schwingkreise bei Wiki. Dir fehlen die wichtigsten Grundlagen. Gruß - A.
Wenn du das signal gegengekoppelt zurückführst, kanst du die membran der Kapsel mechanisch nahe der Nullposition halten, was ein nachschwingen ausschliest. Du mist dann die Kraft mit dem OAmp, welche dazu nötig ist. Erst deren Stromäqivalent an einer Last führst du dem Spannungsverstärker als eingangsgröße zu. Die Transmitter mit viel Power zu übersteuern bringt keinen Leistungsgewinn. Lediglich die nichtabgestralte und nicht verheizte Energie schwingt im System weiter zwichen Feder und Masse hin und her, und behindert die Nahauflösung.
Ich glaube es geht ihn gar nicht um die Nahauflösung. Wer brauch schon Abstände zu den Baken unter ca. 10cm? Was er meint, ist wohl die 'spatiale' Auflösung, also die Genauigkeit seiner Position auf dem Spielfeld. Gruß - A.
>So naja das interessante war nun, dass man auf dem Oszi (was am Mic hing) >den fehlenden Impuls super sehen konnte! Wie kann das sein, wenn das doch >nachschwingt? Das spricht für ein Nachschwingen des unbelasteten Transmitters, ein ausgelassener Impuls scheint ihn schon schwach zu dämpfen solange die treibendestufe niederomig ist. Der Recive scheint in diesem Fall schon soweit gedämpft zu sein, das der Impulsausfall erfassbar wird.
jo mei Denn braucht er nur die erste Pulsflanke auszumessen und den Schwanz zu ignorieren Totzeit. Beschränkt aber auch die Pulsfolgefrequenz aber nur gering. Im Zeitschlitzverfahren jedoch verschlechtert sich dadurch die Messgenauigkeit am bewegten Objekt.,da er während der Totseit des geblendeten Snesors keinen neuen Impuls der Nächsten Bake aufnehmen kann. sorry Fabian Abdul hat den Durchblick
Oh ich blicks inzwischen nicht mehr. 1000 Meinungen und ich versteh nur die Hälfte. > Das spricht für ein Nachschwingen des unbelasteten Transmitters, ein > ausgelassener Impuls scheint ihn schon schwach zu dämpfen solange die > treibendestufe niederomig ist. Der Recive scheint in diesem Fall schon > soweit gedämpft zu sein, das der Impulsausfall erfassbar wird. Ähh wann ist er denn mal hochohmig? Soweit ich weiß nie. > Im Zeitschlitzverfahren jedoch verschlechtert sich dadurch die > Messgenauigkeit am bewegten Objekt.,da er während der Totseit des > geblendeten Snesors keinen neuen Impuls der Nächsten Bake aufnehmen > kann. Und genau das ist mein Problem. Der Bot bewegt sich mit bis zu 1m/s und wenn ich ne halbe Ewigkeit auf die Ultraschallsignale warten muss und dann auch noch 4 Stück davon. In der Zeit ist der Bot übers halbe Spielfeld gefahren... > Wie sieht dein Sender aus? Steuerst du den Wandler resonant an? Das wäre > dann in deinem Fall schlecht. Hmpf... Momentan mit einem gestuertem NE555 (weiter oben beschrieben). Und mein neuer Plan ist (auch schon beschrieben!) ein L293D zu verwenden.
Also wenn du schneller messen willst, ist "more power" und resonant keine alternative in geschlossenen Räumen. Du kannst da weder Mehrfachreflektionen ausschließen und mußt zudem abwarten bis der impulsvollständig im Rauschen untergegangen ist bevor du den nächsten senden kanst, weil sonst der Reciver einlaufende signal weder einer Bake noch einer zeitscheibe zuzuordnen vermag. Zum schnellen Messen must du also dissonante orts-und-zeit-codierte Pulsepakete auf unterschiedlichen Kanälen umlaufend senden und erfassen. So kann der Prozessor auf das jeweils jüngste signal jeder bake zugreifen und daraus den neuesten Standort errechnen, auch wenn sich der Bot in unmittelbarer nähe einer Bake und weit weg von einer Anderen befinden. Stichworte DSP FFT
Fabian, du kannst die physikalischen Grenzen nicht neu ziehen! Wenn du eine hohe Meßgeschwindigkeit brauchst, muß das dein Sensorsystem auch von seinen Eigenschaften her unterstützen. Du kannst das mit deiner Schaltungstechnik allerhöchstens verschlechtern oder dich sinnlos auf den Kopf stellen. Der L293 hat viel Leistung, interessiert sich aber nicht für seinen Ausgang! Der gibt dann einen kräftigen digitalen Impuls raus mit allen tollen Oberwellen und die soll dann der US-Wandler verdauen... Ein schneller Audio-Verstärker wäre besser! Den kannst du nämlich gegenkoppeln, so daß dieser was vom Eigenleben des US-Wandlers mitbekommt. Am Eingang bräuchtest du dann einen Sinus. Ich sehe schon, denn hast du natürlich auch nicht :-) Ich kann dir aus dem Kopf leider auch nicht sagen, WIEVIEL Bandbreite deine Wandler für deine gewünschte Geschwindigkeit brauchen. Das würde ich persönlich ausprobieren, man kann es aber sicherlich auch berechnen. Als Anhaltspunkt würde ich mal sagen, das man drei Wellenlängen des Nutzsignals für ein gutes erkennbares Ereignis brauch. Also rechne dir aus, wie lange das bei 40kHz in Luft dauert. Da fällt mir gerade ein Diplomarbeit ein, wo ein Typ deine Navigation mit US machte und alles exakt herleitete. Der hatte sogar extra Tütchen gebastelt, um den US kreisförmig abstrahlen zu können. Wenn es dir hilft, wühle ich mal auf der Festplatte. Gruß - A.
Ja ne ist klar, und nen kleines Atomkraftwerk bau ich auch noch eben mit ein, denn das ganze brauche ja mindestens 100mA :D Sorry, zu kompliziert :) Was mich eigentlich am meisten stört ist, dass ich nicht weiß was denn die Nachschwingungen verursacht. Habe ich schon zich mal gefragt und keiner hat mir bislang ne richtige Antworte gegeben, soweit ich mich erinnern kann.
Winfried, er ist zumindest schaltungstechnisch absoluter Anfänger! Ein Stichwort wäre auch noch Korrelation von Chirps. Fledermäuse kennen sich da super aus :-) - A.
Das Nachschwingen ist wie bei einem Feder-Masse-System. Der Wandler wird von dir angeregt, lädt sich mit jeder Schwingung mehr Energie in sein System und wird die dann genauso schlecht wieder los durch die Dämpfung deines Treibers nach dem gewünschten Impuls. Das ist doch nicht schwer zu verstehen! Und solange er da so rumschwingt, schwingt auch seine Membran und damit die Luft und das Ergebnis kennst du ja... Der grundlegende physikalische Hintergrund ist auch simpel: Der Wandler hat eine hohe mechanische Steifigkeit, weil er aus Keramik besteht. Die anzuregende Luft ist extrem weich. Sie ist zwar bei US-Frequenzen härter als in unserem Hörbereich, der Unterschied ist aber immernoch katastrophal groß! In dem Wandler ist eine runde kegelförmige Platte. Die zusammen mit einer lambda/4 resonsten Abstand zu einer Reflexionsschicht unterhalb des Sensors (Auf der Seite wo er die Pins hat), erzeugt einen Resonanzraum von 40KHz mit Anpassung an die Luft. So ein Wandler ist High-Tech auch wenn man es nicht vermutet! Die Anpassung ist nun aber immernoch schlecht, weil der Wandler einfach viel zu wenig Fläche hat! Deswegen schwingt er so dämlich nach. Er kriegt die Energie einfach nicht schnell genug in die Luft bzw. umgekehrt kann er sich nicht fest genug an die schwingende Luftsäule ankoppeln, wenn du ihn als Empfänger benutzt. Das allgemeine Prinzip dahinter ist einfach Brechung an unterschiedlichen Schichten. Gibt es auch bei Linsensystemen in der Optik. Die Gesetze von dort gelten hier auch. Sender und Empfänger sind fast gleich. Der eine wird in Parallelresonanz betrieben, der andere in Serienresonanz. Ansonsten kann man sie aber auch mit schlechteren Eigeschaften durchaus gleich machen oder vertauschen. Der für Sender war wohl in Serienresonanz. Ich weiß das nicht mehr aus dem Kopf. Ist egal, nimm halt den Sender fürs Senden und den speziellen Empfänger fürs Empfangen. Dann hast du die höchste Reichweite. Die beiden unterschiedlichen Kapseln kann man ja immer zusammen kaufen. - A.
d.h. doch ich könnte die Schwingung schon reduzieren, wenn ich weniger Impulse sende, vielleicht nur 2-4 oder so?
Ja! Aber mit weniger Schwingungen pro Meßimpuls-Ereignis sinkt auch die erreichbare Amplitude! Erinnere dich an das Feder-Masse-System. Weniger Amplitude bedeutet weniger Reichweite, da dein Empfänger eine feste erreichbare eigene Empfindlichkeit hat (Die wird hauptsächlich von den Umgebungsgeräuschen und dem Eigenrauschen bestimmt). Es ist ähnlich wie bei der Heisenbergschen Unschärferelation. Man kann nicht hohe Auflösung und hohe Empfindlichkeit gleichzeitig haben! Da mußt du einen Kompromiß finden. Man kann das nun technisch noch extrem viel weiter treiben. Du wärest erstaunt, was machbar ist. Als Beispiel nannte ich schon Fledermäuse. Die sind in der Lage im Dunkeln einen im Raum gespannten Bindfaden zu umfliegen! Ihre Sendefrequenz liegt je nach Art irgendwo im Bereich 15kHz bis vielleicht 300kHz. Viele Arten senden extrem breitbandig in Chirps. Jetzt wirst du zu Recht einwenden: Das kann ja nach den bisherigen Ausführungen dann kaum funzen! Die Viecher schaffen das aber, hatten aber auch über 100 Millionen Jahre Zeit für die Entwicklung und wer schlechter war, wurde zu früh gefressen ohen Spaß gehabt zu haben... Es gibt diverse Kreise vor allem beim Militär, die gerne wüßten wie die Tiere solche extremen Leistungen verbringen können. Soweit sind wir hier noch lange nicht. Aber es geht noch einiges! Aber sowas mache ich nur noch gegen Geld. Die vergangenen Jahre des Lernens müssen kompensiert werden :-) - A.
Ok dann wer ich mal die Platine bauen und mal alle mögliche Potis einbauen um alles einzustellen. In der Hoffnung, dass der richtige Hebel dabei ist :D
Mit Potis kommst du da nicht weit. Das wird schon mindestens Spulen und Hirnschmalz brauchen. Simuliere deine Ideen mit LTspice. Gute Nacht - A.
Kann man da Schall simulieren? Kannst du mit sagen was die Ersatzschaltbilder meiner US-Geräte sind? Und im Übrigen: Es geht ja schon, schwingt nur nach. Muss ich halt nen haufen Rechenaufwand betreiben um das zu kompensieren.
Man kann den Schall als schwach gekoppelten Trafo simulieren. Mechanische Größen lassen sich in elektrisch Äquivalente umrechnen. Ersatzschaltbilder habe ich irgendwo auf der Platte. Bevor du so tief einsteigst und sich das für dich vielleicht in dieser Anwendung gar nicht lohnt, schau hier mal rein: http://www.informatik.uni-kiel.de/~railway/Downloads/hoehrmann1.pdf Vielleicht reicht dir die dortige Leistung bereits aus? Sei dann aber nicht enttäuscht und auf mich sauer, wenn dir keine Arbeit außer Nachbauen mehr bleibt :-) Jetzt muß ich aber wirklich noch etwas arbeiten... Gruß - A.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.