- HEMS Solar Speicher Tutorial    Werbung      
Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 255

Thema: IR-bake

Hybrid-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #1
    Erfahrener Benutzer Robotik Einstein Avatar von inka
    Registriert seit
    29.10.2006
    Ort
    nahe Dresden
    Alter
    78
    Beiträge
    2.180
    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...
    gruß inka

  2. #2
    Erfahrener Benutzer Robotik Visionär
    Registriert seit
    26.11.2005
    Ort
    bei Uelzen (Niedersachsen)
    Beiträge
    7.942
    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 ?

  3. #3
    Erfahrener Benutzer Robotik Einstein Avatar von Dirk
    Registriert seit
    30.04.2004
    Ort
    NRW
    Beiträge
    3.803
    Hi Leute,

    ich würde das auch so sehen, wie RolfD.

    Ich könnte mir folgendes US-IR Szenario vorstellen:

    BAKEN (mind. 2, max. 8 ):
    - Verfügen über einen IR-Empfänger (z.B. nach oben an die Decke gerichtet)
    - Verfügen über einen IR-Sender (z.B. nach oben an die Decke gerichtet)
    - Haben einen US-Sender (Flächig in den Raum gerichtet, also für den Fall der Bake in einer Zimmerecke mit 90° horizontalem Öffnungswinkel und für an einer Längsseite des Raums gelegene Bake mit 180° Öffnungswinkel)
    - Positionen der Baken im Raum sind dem Roboter bekannt oder können abgefragt werden (s.u.)

    Roboter (RP6):
    - Verfügt über einen IR-Sender (IRCOMM, nach oben an die Decke gerichtet)
    - Verfügt über einen IR-Empfänger (IRCOMM, nach oben an die Decke gerichtet)
    - Wird auf einer Experimentierplatine mit einem US-Empfänger mit Rundumsicht oder 180° Frontsicht ausgestattet

    Das System kann:
    - Eine Bake sendet auf ein für sie bestimmtes IR-Signal des RP6 hin einen US-Ping
    - RP6 empfängt den Ping und erkennt anhand der US-Laufzeit die Entfernung von der adressierten Bake
    - Das selbe erfolgt mindestens für eine 2. Bake im selben Raum.
    - Damit ist der Standort des Roboters im Raum bekannt.
    - Baken können untereinander über IR kommunizieren
    - RP6 kann mit den Baken über IR kommunizieren und z.B. die Position der Baken abfragen oder Settings der Baken verändern

    Das System kann nicht:
    - Wahrscheinlich kann ein solches System nicht eine Genauigkeit von +-5cm erreichen
    - Die Drehrichtung des Roboters (Yaw) ist so nicht direkt bestimmbar, aber zu errechnen, sobald sich der Roboter bewegt
    - Dafür ist es recht einfach umzusetzen und man müßte mit dem genannten Budget von 120,- € hinkommen
    Gruß
    Dirk

  4. #4
    Erfahrener Benutzer Roboter-Spezialist Avatar von RolfD
    Registriert seit
    07.02.2011
    Beiträge
    414
    ok.. das Forum hat mein halben Beitrag geschreddert... ich versuchs morgen noch mal.

    Nachtrag: Dirk hat mein Beitrag gerettet, Danke auch hier noch mal.

    Gruß
    Geändert von RolfD (10.06.2014 um 08:32 Uhr)
    Sind Sie auch ambivalent?

  5. #5
    Erfahrener Benutzer Robotik Einstein Avatar von Dirk
    Registriert seit
    30.04.2004
    Ort
    NRW
    Beiträge
    3.803
    Hi RolfD,
    Also es gibt noch eine weitere Varinte, man kann das IR Signal nicht nur als Start sondern auch als Stop-Signal nutzen. Also z.B. Bake sendet US und und sobald der RP6 das US signal hat antwortet er ASAP mit einem IR impuls. Die Bake emfängt den IR Puls und berechnet dann die Laufzeit.

    Aber wir nähern uns der Frage nach dem Aufwand und da ist zunächst die Geschichte mit den 8 Baken mal aufzunehmen. Ich behaupte... das müsste man dann noch mal verifizieren... das man nicht 8 einzelne Baken braucht.. es reicht wenn man eine Bake mit bis zu 8 Sateliten hat. Man kauft sich ja auch keine 6 Stereoanlagen mit je einem Speaker wenn man 5.1 sound haben will... sondern eine Anlage mt 6 Speakern! Wenn wir uns darauf einigen wären wir auch da ein Schritt weiter. Von mir aus können wir aber gern bei den Satelliten dann jeweils von Baken reden und diese auch mit 8 angeben. Zur Begriffsklärung, bisher habe ich die Steuereinheit der Satelliten als Bake bezeichnet.

    Ohne in diesem Textabschnitt eine Senderichtung für den US Impuls vorgeben zu wollen halte ich es grundsätzlich für einfacher, wenn immer nur ein Schallgeber sendet und nur ein Schallgeber empfängt. Dies minimiert Probleme mit Schallechos weil grundsätzlich der direkte Weg immer schneller ist als der umweg, man muss aber sicher und auch unter schlechten Bedingungen den ersten US Impuls feststellen können. Das hat zur Folge, das eine komplette Lokalisation (anmessen durch 2 bis max 8 Satelliten) ggf. quasi nacheinander erfolgt und damit bis zu 8 Messungen erfordert. Schall legt üblicher Weise 330m/sek oder 33m/100ms zurück. Bei einer Reichweite von 10m messdistanz und einer Abklingphase wo sich das US-Signal beruhigen/verstreuen kann, muss man also mit 50ms Messzeit und min. 50-70ms Abklingphase rechnen. Mit dem Ansatz lassen sich die 8 erforderlichen Messungen bequem auf 1 Sek. verteilen - das heisst im Umkehrschluss, eine vollständige Lokalisation ist innerhalb 1 Sek abgeschlossen.
    Der Schallpegel darf aber damit auch nur so laut sein das er 33m oder 100ms nicht signifikant überschreitet weil sonst echos aus der vorherigen Messung einstreuen. Daher muss der Schallpegel entweder des Senders und ggf. auch die Empfindlichkeit des bzw. der Empfänger(s) ggf. per Poti oder Steuerung in gewissen Grenzen anpassbar sein oder man muss länger zwischen den US Signalen warten bis sie sich im Raum garantiert totgelaufen haben.

    Dann betrachten wir uns die Informationen selbst, die übertragen werden. Man kann mit IR Informationen übertragen - wie der IR-Morsetreiber zeigt - aber schaut man sich die Übertragung genauer an, sieht man das der Treiber mit 9600 Baud arbeitet. Das bedeutet aber das auch ein Zeichen... z.B. als Startsignal... Zeit braucht. Daran ändert sich auch nichts, wenn man die Baudrate erhöhen würde. Diese Zeit muss man aber mit Berücksichtigen wenn man getimte Signale verschickt. Das gleiche gilt auch für Informationsübertragung per US was auch gehen würde. Da wir zunächst nur an der reinen Laufzeit des US Signals interessiert sind, stell sich die Frage, ob man in den eigentlichen Messzyklus auch noch zusätzlich Informationen übertragen muss zumal diese auch noch verarbeitet werden muss, also weitere Zeit benötigt. Mein standpunkt dazu: Ja aber nur wenn es nicht anders geht. Die Frage lautet also.. geht es anders? Ich denke ja.
    Die Steuereinheit der Bake sollte sich mit dem RP6 per IR unterhalten können. Soweit waren wir uns schon einig. Wärend einer Messung sollte sich der Informationsaustausch aber auf die reinen Messzeiten beschränken. Das bedeutet in der Umsetzung aber, das z.B. nur jede 2.te Sekunde Messungen ausgeführt werden und in der jeweils freien Sekunde ein Fenster besteht wo der RP6 die Kommunikation per IRDA zur Bakensteuereinheit aufnehmen kann. Diese Zeitscheiben Aufteilung ist wichtig damit keine IR-Pulse, welche zur Messung gehören, in den Datentransport zwischen Bake und RP6 einsteuen. Man könnte es sogar so ausbauen, das der RP6 immer per IRDA mit der Bake reden kann, und nur auf seine Anforderung hin ein US/IR-Messung erfolgt, in der der RP6 dann Ruhe sicherstellt. Hat man 2 oder mehr RP6, würde das Zeitscheibenverfahren mehr Sinn machen da sonst alle anderen RP6 überwachen müssten ob ein Nachbar-RP6 eine Messung anfordert - oder die Bake müsste eine Messung ankündigen da sie weiss, mit
    welchem RP6 sie grade redet, allerdings nicht ob RP6er unternander per IR reden. Mehrfachmessungen und Signalschedulling weichen aber jetzt etwas vom Anforderungsprofil mit einer Bake und einem RP6 ab. Die Schlussfolgerung aber bleibt - man sollte die Messung und Datenaustausch zeitlich voneinander trennen um möglichst präzise Messungen zu bekommen.

    Betrachten wir uns die eigentliche Messung noch mal genauer. Da wir aus vorherige Überlegung davon befreit sind, komplizierte Datenpakete wärend der Messung übertragen zu müssen, können wir das ganze sehr einfach gestalten. Es gibt 2 Ansätze.
    1. Man überträgt vom Sender gesehen einen US und einen IR Impuls (Startsignal) und am Empfänger misst man die Laufzeitunterschiede.
    2. Man überträgt vom Sender einen US Impuls und der Empfänger antwortet AS SOON AS POSSIBLE mit einem IR Impuls, der US Sender misst dann Laufzeit.

    Beide Verfahren gehen jeweils mit dem RP6 wie auch mit der Bake als US-Sender - wir haben also 4 Möglichkeiten.
    1. Bake sendet US + IR, RP6 misst US Laufzeit ausgelöst durch IR. (Triangulation der Messung auf RP6) 2. Bake sendet US, RP6 echot mit IR, Bake berechnet Laufzeit. (Triangulation der Messung auf Bake, Datentransport per IR-UART an RP6) 3. RP6 sendet US + IR, Bake misst US Laufzeit ausgelöst durch IR. (Triangulation der Messung auf Bake, Datentransport per IR-UART an RP6) 4. RP6 sendet US, Bake echot mit IR, RP6 berechnet Laufzeit. (Triangulation der Messung auf RP6)

    Aus der Liste ist ersichlich, das nur Lösung 2 und 3 der Anforderung aus den Wunschlisten entgegen kommen, wonach die Berechnung des Standortes auf der Bake passieren soll um dann an den RP6 per IR-UART transportiert zu werden. Dabei zu Bedenken ist, jedes Echo Verfahren birgt gewisse Ungenauigkeiten weil die Messgenauigkeit davon abhängt, wie schnell der echo Teil das Signal beantwortet. Lösung 2 MUSS also sicher stellen, das der RP6 Base wärend einer Messung das Signal sofort und unabhängig von dem was er sonst grade macht, 8 mal pro Sek per IR beantwortet. Leider kann da auch eine M32 nicht bei helfen denn das muss der RP6 selbst regeln da nur er direkten Zugriff auf die IR Anlage hat. Baut man sich eine IR-Sende/Empfangsanlage auf die M32, sieht das anders aus. Aber auch da müssen sich M32 und Base dann einig sein wer wann was sendet! Zusätzliche Laufzeitprobleme durch das TWI Interface zwischen RP6 und Base lass ich jetzt mal ganz ausser acht.

    Es bleibt damit eigentlich nur Lösung 3 übrig. Der RP6 muss dazu ca. 8x per Sek. ein IR und ein US Signal synconisiert abfeuern. Die Bake(n) messen den Lichtimpuls und warten dann jeweils mit einem Satellitenreceiver auf das Eintreffen des ersten US Signals. Da wir keine Informationen in den Signalen übertragen kann das Signal extrem einfach angelegt sein... es reicht im Prinzip ein einzelner analog erzeugter Klick/Blitz mit genügend großer Flankensteilheit aus da wir von möglichst ungerichteten Signalen ausgehen (hab ich vorher im Thread schon mal erklärt). Nach wenigen Durchgängen hat die Bake die Laufzeiten und kann daraus eine Position berechnen welche der RP6 per IR-UART dann abfragt.

    Es stellt sich dann noch die Frage, wie man möglichst ungerichtete Signale für IR und US erzeugt bzw. empfängt. Dazu gab es z.B. in dem verlinkten Thread die Lösung mit dem 120° Kegel über der US Kapsel. Ich will den Ansatz hier nicht kritisieren aber ich denke, das dies einfacher geht. Eine einfache kleine Piezzo-Hochtonkalotte für wenige Euros auf dem RP6 sollte schon genug Energie abgeben können, das man ein US Klick Puls im Bereich von 22KHz oder höher auch im Umkreis von 10m noch klar und deutlich messbar ist. Um es noch mal zu widerholen... wir müssen weder die Signalform auswerten, noch Impulse zählen, wir müssen nur die Zeit messen, indem irgendwas ultraschallartiges in einem Zeitrastrer von 100ms ab einem IR Blitz messbar ist (Thema geringe Anforderungen). Ähnliches gibt es zum Thema IR zu sagen. Man kann sich natürlich sowas selbst zusammen löten aber es gibt auch fertige IR-Scheinwerfer, die man modifizieren könnte. Eigentlich kann man den IR Puls sogar vom US Puls nehmen/ ableiten. Es braucht also keine komplizierte separate IR Steuerung für den IR Blitz, selbstverständlich kann man aber auch die IR Steuerung vom RP6 nutzen, mann müsste dann eben nur die vorhandene Schaltung um ein zuschaltbaren Ultraschallgeber erweitern. Baut man sich das ganze für die M32 auf, (wo eh ein eigener IR-Teil drauf müsste) , könnte man das direkt berücksichtigen.

    Ok.. wie schaut dann das Bakensystem aus? Es müsste in jedem Fall ein IR-Sender/Empfänger haben um mit dem RP6 reden zu können. Ansonsten besteht es eigentlich nur aus 8 verteilten Mikrofonen, welche das US-Schallsignal orten bzw nacheinander messen und einem IR-Empfänger für den Blitz. Um sicher zu stellen das die Bake das IR Puls Signal mitbekomt könnte man an jedes Mikrofon noch eine IR-Empfängerschaltung bauen falls die IR Abgabe der LEDs auf dem RP6 zu sehr gerichtet ist. Da der RP6 aber auch zur Decke strahlt, reicht meist Indoor ein gegen die Decke gerichtetes IR-Empfangssystem. Outdoor oder in einer Halle wird genau das Probleme machen! Wie umgeht man das?
    Am einfachsten indem in jedem Satellit je ein IR Empfangssystem verbaut ist welches sogar parallel geschaltet sein darf - und der Hoffnung das der RP6 immer zu mindestens einem Sateliten direkten Sichtkontakt hat. Dann kann man aber auch einen IR Sender pro Satelit (parallel) vorsehen, ist ja quasi nur eine Sendediode.

    Damit haben wir unsere Bake aber quasi zusammen.
    1 Bake mit Logik und 8 Satteliten welche je aus einem US-Mic bzw. Receiver und einem IR-Sender/Empfänger bestehen sowie dem RP6 welcher ein modifizierten IR sender bekommt, der mit dem IR Blitz ein US Klick abstrahlen kann. Die IR-Sender/Empfänger sind quasiparallel ausgelegt, die Mics sind besser einzeln anmessbar, könnten aber zumindest gemultiplext arbeiten. Auf dem RP6 wie auf der Bake muss zudem der IR-Uart laufen damit die Daten in einem Zeitfenster übertragen werden wo weder die Messung läuft noch das ACS aktiv ist. Wo man sich die Microfonsatelliten hinstellt ist dann nur noch eine Frage der Kabellänge, ggf. muss man noch ein NF-Verstärker für jedes Mic vorsehen... das wars schon.
    Gruß
    Ich hoffe, das war dein Beitrag von gestern ... Bild  
    Gruß
    Dirk

  6. #6
    Erfahrener Benutzer Robotik Visionär
    Registriert seit
    26.11.2005
    Ort
    bei Uelzen (Niedersachsen)
    Beiträge
    7.942
    IR Sendediode sind recht günstig - da ist das Rundum Senden sehr einfach, indem man einfach ein paar mehr Dioden hat, die gleichzeitig senden. Die IR Signale Stören sich auch nicht, sondern addieren sich.

    Mit der Ulraschallfrequenz runter auf vielleicht 22 kHz zu gehen, macht es es ggf. schwieriger den genauen Zeitpunkt zu bestimmen. Durch die niedrigere Frequenz wird es schieriger den Beginn eines Impulses zu detetktieren. Die kleine Frequenz hätte aber auch einen großen Vorteil - da gehen noch einige kleine, (und ggf. sehr günstige) Elektretmikrofone als Empfänger, und die Empfänger sind nicht resonant, was es wieder leichter mache kann den Zeitpunkt zu finden. Der Teil mit 22 kHz Ultraschall wäre sicher eine Option - sollte aber schon mal vorab getestet werden.

  7. #7
    Erfahrener Benutzer Roboter-Spezialist Avatar von RolfD
    Registriert seit
    07.02.2011
    Beiträge
    414
    @Besserwessi
    Die volle Wellenlänge eines 22khz Pulses liegt bei 1.561 cm wobei die volle Wellenlänge für 38 KHz bei 0.954 cm liegt.
    Die "Ungenauigkeit" auf Grund der Wellenlängen liegt also bei Lambda halbe (Halbamplitude) von ca. 0,7 zu 0,4 cm ... ich glaube die ~ 3 Millimeter Messfehler kann man getrost vernachlässigen und fliest ohne Auswirkung in die angegebenen +-5cm Toleranz der Bake.
    Nachzurechnen bei http://www.sengpielaudio.com/Rechner-wellen.htm
    Ich sehe eher das Problem, das man schon ordentlich Energie braucht um ein Rundstrahlimpuls zu senden im Vergleich zu einem gerichteten Puls. Hochtonkalotten werden nicht umsonst z.B. mit 80 Watt !!! angegeben.. klar braucht man solche Leistungen nur für ein Puls pro Messung von je ca. 0.04 ms .. aber trotzdem geht das auf den Accu. Mit einer Umlenkung ala 120° Kegel würde man aus einer zu beschallenden Halbkugel zumindest eine Schall-Scheibe machen was schon enorm Energie bei gleichem Schalldruck spart. Da würden wohl schon 10 W reichen um gleiches zu erreichen. Eine US Kapsel erreicht das auf Grund des Focus schon mit 1 Watt.
    Ich bin mit der Lösung so noch nicht zufrieden auch wenn der Weg richtig ist.
    Die Frage ist halt, wie empfindlich die Elektretmicros oder Ultraschallkapseln auf so ein Signal reagieren... das kommt sicher auch auf den NF Verstärker/Bandpass am Micro an, da habe ich keine Erfahrungswerte - leider aber auch die nächsten 2 Wochen keine Zeit da was zu probieren. Im Prinzip reicht ja ein Signal was 2-3 mal stärker ist als das normale Umgebungsgeräusch um es zu erkennen. Da mindestens!!! alle 2 Sek eine komplette Messung möglich ist und man die Ergebnisse korrelieren/validieren kann, fallen einzelne Ausbrecher im Signal bzw. falsche Signale natürlich auf. Misst man mit 3 Messtellen, so ist die dritte Messung schon bis auf 2 Punkte im Kreis redundant. Der Bot bewegt sich zudem ja auch nur mit max 30cm/sek, Messfehler die darüber hinaus gehen weil man grade gleichzteitig die Hütte staubsaugt oder die Sereoanlage volles Rohr aufdreht kann man komplett streichen. Aber selbst dann besitzt der RP6 immer noch eine Odometrie welche die Messergebnisse der Bake verifizieren/validieren kann.
    Ich weis halt nicht mit wie wenig Watt man senden müsste um ein 10x10m Raum oder Gelände so zu beschallen das der Ton/Klick mit entsprechend geeigneten Mics aus dem "normalen" Umgebungsgeräusch überall zu isolieren wäre ohne das all zu viel Echos aufkommen.
    Dazu müssten wir uns wohl den Empfangsteil genauer ansehen und testen .. und vielleicht auch festlegen was "normale Umgebungsgeräusche" sind.
    Ultraschall ist aus dem normal hörbaren Schallsprektrum schon etwas einfacher zu isolieren als hoher Schall sofern die Mics dafür geeignet sind. Letztlich kommt es aber auch drauf an, was die Kalotten und Mics können... ich weiss das Hörner durchaus auch mit 30KHz und deutlich mehr angegeben werden und auch mechanisch eher eine Scheibe senden (die wären praktisch gewesen wenn in den Satelliten die US-Sender stecken würden). Also es muss nicht zwangsweise 22khz sein obwohl das einiges vereinfacht. Die Lösung kann jedoch nicht darin liegen, ein US Impuls mit 130 Dezibel zu erzeugen nur weil die Mics unempfindlich bis störrisch wie sonst was sind. Bei einer focussierten US-Kapsel mag das gehen, bei einem Rundstrahler nicht. Daher hatte ich auch im letzten Beitrag explizit auf regelbare Sender/Empfänger hingewiesen.

    Ich denke, ich werde es in 3-4 Wochen mal mit dem hier als US-Sender probieren. http://www.conrad.de/ce/de/product/3...akt-Hochtoener ... und einfachen Elektretcapseln und NF-Operationsverstärker LM356 mit Pass im selbstbau ... sowie meinem Polin Board. Die Theorie zum Pass findet man z.B. dort: http://www.electronics-tutorials.ws/.../filter_7.html

    Gruß
    Geändert von RolfD (10.06.2014 um 23:38 Uhr)
    Sind Sie auch ambivalent?

  8. #8
    Erfahrener Benutzer Robotik Einstein Avatar von Rabenauge
    Registriert seit
    13.10.2007
    Ort
    Osterzgebirge
    Alter
    57
    Beiträge
    2.214
    Ich häng mich hier mal mit rein- weil mich das Problem (prinzipiell, hab keinen RP6 und werd auch so bald keinen haben) auch schon ne Weile beschäftigt.
    Im Grunde stimme ich den jetztigen Überlegungen weitgehend zu- aber ich möcht nen flexibleres System, was auch portabel ist (sollte auch outdoor funktionieren, drinnen brauch ichs nicht).
    Dazu müssen die Baken zum einen handlich bleiben (ich würd die gerne, wenns mal soweit ist, als Hundeleine ohne Leine benutzen können, so auf 10-15m), zum anderen sollten sie ne vernünftige Betriebszeit aufweisen.

    Daher: IR-Sender und Empfänger in die Bake, das ist gut. US NUR nen Empfänger. Der frisst kaum Strom, und in den Roboter passen einfach grössere Akkus.
    Kommunikation zwischen Roboter und Bake nur per Infrarot-das geht auch im freien und rundum auf 10-20m recht mühelos (die Battlesysteme der Modellpanzer arbeiten so), sogar ne gewisse Richtungserkennung ist damit machbar (einfach mehrere Sensoren im Kreis anordnen)-jedenfalls im Freien.
    Ortung läuft dann so: Roboter sendet IR-Signal, um die Bake "aufzuwecken" (die kann bis hierhin quasi schlafen), Bake wacht auf, meldet sich (was man da nun überträgt, ist prinzipiell egal, aber z.B. ne ID, das Ganze ist quasi als Handshake gedacht), DANN sendet der Roboter nen IR-Blitz UND zugleich ein US-Signal.
    Damit kann die Bake die Laufzeit und damit die Entfernung ermitteln, und die wiederum per IR zurückschicken.
    Somit braucht die Bake keinen nennenswerten Strom (paar Millisekunden die IR mal Vollgas), läuft schön lange und ist relativ klein.

    Auf dem Roboter ist der besagte "Ring" aus IR-Sensoren drauf, damit er die Richtung der Bake wenigstens grob ermitteln kann, und damit benötigt er auch nur _einen_ US-Sender. Er guckt einfach, aus welcher Richtung die Bake antwortet und kann da den Sender hin richten (wie auch immer das gelöst wird, drehbar oder die ganze Fuhre dreht sich-egal).
    Das Ganze ist dann problemlos auf nahezu beliebig viele Baken erweiterbar, wenn man jeder ne eigene ID vergibt, kann man den Roboter als Master entscheiden lassen, mit welcher Bake er reden will.

    Soweit mal mein Senf dazu...
    Falls ihr hier strikt beim RP6 und seinen Gegebenheiten bleiben wollt, sagt es, dann halt ich wieder die Klappe..
    Grüssle, Sly
    ..dem Inschenör ist nix zu schwör..

  9. #9
    Erfahrener Benutzer Robotik Einstein Avatar von inka
    Registriert seit
    29.10.2006
    Ort
    nahe Dresden
    Alter
    78
    Beiträge
    2.180
    hallo allerseits,

    das ist die quintessenz der beiträge ab meinem vorschlag eine bake 2.0 zu entwickeln. Bitte um nachsicht wenn ich etwas übersehen haben sollte und hinweis für eine korrektur (im originaldokument), es war wirklich viel text...

    zusammenfassung für stromsparende bake:


    • es ist (wie bake 1.0) primär eine bake für den RP6-base + m32, die hardware des RP6 (ACS? Und IRCOMM) soll auf der roboterseite primär zum einsatz kommen
    • programmtechnisch über RP6-base, aber auch über RP6-base + m32 betreibbar
    • durch geringe hardware- und software- anpassungen an der bake soll diese mit anderen systemen verwendbar sein (wie bake 1.0)
    • anzahl der baken soll bis 8 erweiterbar sein
    • hardware der bake so ausgelegt, dass sie keine software-unterstützung von außen braucht
    • outdoor und indoor einsetzbar, reichweite 10m
    • geringer stromverbrauch der bake, akku bei outdoor verwendung durch solarzellen aufladbar
    • indoor mit 5v (USB) stromversorgung
    • positionsgenauigkeit des roboters +- 5cm
    • bake hat US-empfänger (geringer stromverbrauch), roboter US-sender
    • kommunikation bake <-> roboter und/oder bake <-> bake mit IR
    • die bake „schläft“ im standby bis sie ein IR-signal vom roboter empfängt und antwortet dann per IR
    • für eine positionsbestimmung des roboters werden zwei baken gebraucht
    • wenn roboter die IR-signale der bake(n) empfängt, sendet er gleichzeitig ein IR und US-signal, die bake(n) errechne(n) aus der laufzeitdifferenz die entfernung zum roboter und teilen ihm seine position mit
    • kosten max. 150€ für zwei baken
    Geändert von inka (13.06.2014 um 15:41 Uhr) Grund: empfänger beim roboter entfernt, titel hinzu
    gruß inka

  10. #10
    Erfahrener Benutzer Robotik Einstein Avatar von Rabenauge
    Registriert seit
    13.10.2007
    Ort
    Osterzgebirge
    Alter
    57
    Beiträge
    2.214
    Ich würd mich, was die Lademöglichkeit der Baken angeht, nicht festllegen. Das sollte jeder selber lösen können-nach seinen Anforderungen.

    Weiter braucht der Roboter (für _die_ Geschichte) keinen US-Empfänger- die Bake kann eh nix senden.

    Und: so teuer wird das nicht. Da ich derzeit recht viel mit Arduinos rumspiele, weiss ich, dass man ne Miniausführung davon für 3-5€ bekommt.
    Dazu ne Lipo-Lader-Platine (um die 2€) kleiner LiPo (ne Smartwatch mit Bluetooth läuft mit nem 110mAh-Akku sechs bis acht Stunden), US-Sensor mal grob 1.50 (kann mehr werden, falls die billigen nich empfindlich genug sind, man _muss_ den Sender-Teil ja nicht nutzen), dazu noch die IR-Schnittstelle (paar ordentliche IR-Dioden, einige Empfänger)- ich schätze, das geht für nen 50er locker ab, pro Stück.
    Und: da wäre noch Platz für einige Optionen (einstellbare Adresse, Akkuanzeige z.B.). Viel mehr brauchts meiner Meinung nach in der Bake gar nicht.
    Oder?
    Grüssle, Sly
    ..dem Inschenör ist nix zu schwör..

Seite 1 von 2 12 LetzteLetzte

Ähnliche Themen

  1. IR-Bake
    Von tornado im Forum Elektronik
    Antworten: 9
    Letzter Beitrag: 05.07.2007, 17:37
  2. IR-Bake
    Von Bernd-das-Brot im Forum Sensoren / Sensorik
    Antworten: 38
    Letzter Beitrag: 13.12.2005, 16:14
  3. ir-bake
    Von pebisoft im Forum Vorstellungen+Bilder von fertigen Projekten/Bots
    Antworten: 8
    Letzter Beitrag: 17.01.2005, 13:41
  4. ir-bake
    Von pebisoft im Forum Sensoren / Sensorik
    Antworten: 2
    Letzter Beitrag: 17.01.2005, 07:01
  5. Bake
    Von techboy im Forum Elektronik
    Antworten: 6
    Letzter Beitrag: 02.11.2004, 10:17

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

    Werbung      Solar Speicher und Akkus Tests