Archiv verlassen und diese Seite im Standarddesign anzeigen : IR-bake
hallo allerseits,
bei der induktiven ladestation muss ich wieder einmal auf teile aus China warten, das ist der nachteil des kleinen preises :-(, ich werde aber auch eine IR-bake brauchen...
es gibt viel zu viel geschriebenes im forum und netz überhaupt zum thema:
Astabile Kippstufe (Multivibrator) – Rechteckgenerator (http://www.ne555.at/timer-ic-ne555/grundschaltungen/146.html)
ir sender bauen // variabel gepulste signale auf 38khz - Mikrocontroller.net (http://www.mikrocontroller.net/topic/76768)
KHD Timer 555 (http://www.domnick-elektronik.de/elek555.htm)
NE555 - Der Herr der Zeiten (http://www.dieelektronikerseite.de/Elements/NE555%20-%20Der%20Herr%20der%20Zeiten.htm)
IR-Bake (https://www.roboternetz.de/community/threads/28886-IR-Bake) Infrared Emitter from CMOS 555 - Robot Room (http://www.robotroom.com/Infrared555.html)
NE555-Grundschaltungen (http://www.kreatives-chaos.com/artikel/ne555-grundschaltungen)
RP6 - Morse-Code - RN-Wissen (http://www.rn-wissen.de/index.php/RP6_-_Morse-Code)
[gelöst] Einfache IR-Kommunikation für den RP6 (https://www.roboternetz.de/community/threads/29313-gelöst-Einfache-IR-Kommunikation-für-den-RP6?highlight=36khz)
Anschluss von Infrarotsensoren - Seite 7 (https://www.roboternetz.de/community/threads/40321-Anschluss-von-Infrarotsensoren/page7)
AREXX.COM • View topic - RP6 Infrarot Sensor Abstand (https://www.arexx.com/forum/viewtopic.php?f=19&t=2370)
ACS und IR Sharp (https://www.roboternetz.de/community/threads/51418-ACS-und-IR-Sharp)
ich würde - rein gefühlsmäßig - diese variante wählen:
IR-Bake (https://www.roboternetz.de/community/threads/28886-IR-Bake) Infrared Emitter from CMOS 555 - Robot Room (http://www.robotroom.com/Infrared555.html)
26721
wäre sowas empfehlenswert? Oder hat schon jemand mit anderen ausführungen gute erfahrungen gemacht? Wer schubst mich in die richtige richtung?
Besserwessi
11.11.2013, 20:33
An sich ist der Ne555 schon keine so schlechte Lösung, allerdings sind 50% Tastverhältnis nicht optimal - besser (weniger Stromverbrauch) wären eher 25% und dafür etwas mehr Strom und ggf. 2 IR Dioden in Reihe.
Es kommt auch etwas darauf an womit man das Signal empfangen will. Die Üblichen Fernsteuerempfänger wie TSOPxx36 wären empfindlicher, wenn das Signal noch einmal zusätzlich moduliert ist, also etwa noch einmal ein 1 kHz Signal an den Reset Pin kommt. Anhand der Frequenz dieses 2. Signals könnt man ggf. auch verschiedene Baken unterscheiden.
Hallo...
Ich frage mich grade, was Du mit der IR Bake erreichen willst.
Eine IR-Bake als einfacher Sender mit NE555 schickt ja nur dauerhaft ein gepulstes IR Licht (meist stark gerichtet über LEDs 30-60°) raus. Hast du andere IR Quellen (Fernbedienung, IR Licht für cam), muss der Bot die falschen IR Signale ausfiltern um das Bakensignal identifizieren zu können. Ggf. stören sich diese aber auch gegenseitig denn auch ein IR Licht ist wie gesagt nur Licht und "hell" im Raum ist eben "hell". IR funktioniert deshalb gut weil es im IR Farbband normalerweise eben nicht hell ist (es sei denn, man hat Leuchtstofflampen). Stell dir statt einer IR LED einfach eine weiße LED vor... und nen 500W Strahler als Deckenlampe...und du weißt was du von einer IR Bake für Lichtausbeute .. und Zielgenauigkeit erwarten kannst.
Dann muss der Bot aus der Stärke des Signals abzüglich Reststrahlung und ggf. richtungsempfindlicher Empfänger auch noch ein Standort der Bake berechnen... um dann seinen eigenen entsprechend zu berechnen... dabei sind Entfernungsinfos nur aus der Signalstärke und nicht aus der Signallaufzeit wie bei Schall ableitbar.
Stellst du 2 oder mehr Baken auf, müssen sich die Baken per Signal auch noch beim Bot identifizieren... (hat man früher bei Leuchttürmen auch gemacht indem z.B. 2 oder 3 "Lichtimpulse" ala Morse an die Schiffe geschickt wurden)
Wesentlich schlauer sind da schon IR-Reflektionslichtschranken (der Bot benutzt selbst eine als Kombi aus IR-Senderdiode und IR-Reciver - und ist damit selbst ein "Lichtverschmutzer" im IR Band) welche z.B. eine Distanz zum Hindernis angeben können aber die sind eben zwingend auf eine Reflektion angewiesen. Und das hat auch nur eine Reichweite von 30 cm... Ich will damit sagen, es reicht nicht einen "dumm blitzenden" IR-Sender aufzustellen damit der Bot sich orientieren kann weil man halt daraus keinerlei Info über seine Lage oder die der Bake bekommt.
Sinnvoller wäre ein System wo ein Bot ein unidirektionalen IR-Blitz feuert und sagen wir mal 3 Baken empfangen das Signal und messen die Stärke. Darauf hin senden alle 3 Baken nacheinander die Messwerte an den Bot (per IR oder Funk) und der Bot trianguliert aus den 3 Werten seine Lage. Da die Sendebedingungen im Raum aber nicht überall gleich sind wird selbst das "komplizierte" Verfahren noch genug Fehler produzieren so das der Bot oft genug nicht weiß wo er sich befindet. Eine Funkpeilung funktioniert so ähnlich.
Ein anderes System würde auf 3 Baken nacheinander 3 unterschiedliche Signale versenden und am Bot müsste ein IR Empfänger alle 3 Signale zum einen den jeweiligen Baken zuordnen und zum anderen die genaue Stärke des Signals messen aus denen sich wiederum die Position triangulieren lässt. Da sich aber die 3 IR Sender nicht in die Quere kommen sollten (IR-Lichtverschmutzung), müsste man die Baken irgendwie synchronisieren oder takten. Quasi das Leuchtturmprinzip.
Noch ein Beispiel aus der realen Praxis zu IR. Es gibt für Bots so kleine blaue Fussbälle, die mit IR Dioden besetzt sind. Überleg dir mal was es schon für ein Aufwand ist, so ein Ball mit dem Bot auf dem Spielfeld zu finden, zu dribbeln... und dann noch ins richtige Tor zu bekommen. Es mag ja einfach sein, eine Art Linienfolger für IR-Signale zu schreiben... aber wenn der Bot mehr können soll als einfach nur anstubsen... wirds schwierig.
Allgemein halte ich IR-Baken für 1. kompliziert und 2. ungenau. Eine Schall-Laufzeitmessung wäre jedenfalls deutlich zuverlässiger. In jedem Fall steckt in einer Bake aber mehr als nur ein NE555... denn den kann man nur in dem besagten IR-Fußball einsetzen.
Gruß Rolf
Hi!
Da fällt mir gerade noch eine Möglichkeit ein:
Irgendwer hier im Forum (RolfD? Dirk? Radbruch??? ) hatte da mal eine andere Herangehensweise gewählt, die wohl sehr gut funktioniert hat.
Ein Laserstrahl wurde vom Zielpunkt (also deiner Bake, oder tankstelle oder was auch immer) ausgesendet, jedoch als Fächer aufgespalten. Das heißt durch das Zimmer war ein Fächer parallel zum Boden überall sichtbar (im Winkel 80° oder so).
Auf dem RP6 war dann eine pappröhre mit einer linse vorne drin. Hinten war die Röhre geschlossen und darin ein lichtsensitiver Widerstand eingeklebt.
Die Brennweite der linse musste so gewählt sein, dass der Abstand zum Widerstand genau passt.
"Schaut" diese Röhre dann mit der Linse direkt in den Fächerstrahl ist das Signal des Widerstands maximal. Die Röhre muss natürlich in derselben Höhe angebracht sein, in der auch der Fächerstrahl liegt.
Irgendwo hier im Forum müsste es dazu einen Artikel geben, aber frag mich bitte nicht wo das war. Aber von allen Möglichkeiten, die ich hier im Forum schon zum Thema "Orientierung im Raum" gelesen habe, erschien mir diese die einfachste und zielstrebigste.
Vielleicht kann man das dann mit zwei solchen Fächern in unterschiedlichen Höhen oder unterschiedlichen Farben (mit Filtern in der Röhre) noch verbessern.
nachteil: geht natürlich nur im Flachen Gelände.
radbruch
14.11.2013, 12:14
Hallo
Ja, das funktionierte recht gut:
http://www.youtube.com/watch?v=dmXwCAlR7OA
(Video aus https://www.roboternetz.de/community/threads/40752-Ladestation-f%C3%BCr-RP6?p=503096&viewfull=1#post503096)
Gruß
mic
Hammer ;)
Trinkt deiner aus dem Napf da links?
Hallo allerseits,
danke für die antworten...
ich habe alles sorgfältig und mehrmals gelesen, folgendes möchte ich nun machen:
beschreibung der ladestation:
die ladeschale ist auf dem boden angebracht (sie ist ca. 10mm hoch), mit der kürzeren seite an der wand, so dass der RP6 längs drüber fahren kann, die ladeschale befindet sich dann zwischen den ketten, das gegenstück (spule mit einem teil der elektronik ist von unter am gehäuse befestigt)
26742
oberhalb der ladeschale (ca. 25cm) ist eine 220V steckdose, aus der die versorgung über ein netzteil erfolgt
beschreibung der bake:
wird aus der gleichen steckdose über ein usb-netzteil versorgt
sendet modulierten IR-signal (36kHz) über 5 dioden in den raum
ausführung nach IR-Bake (https://www.roboternetz.de/community/threads/28886-IR-Bake) Infrared Emitter from CMOS 555 - Robot Room (http://www.robotroom.com/Infrared555.html)
Um die bake und die ladestation ist eine halbkreisförmige linie und eine (die halbkreisförmige linie kreuzend) linie, die senkrecht auf die wand – und die ladestation – hinführt. Die halbkreisförmige linie ist am kreuzpunkt unterbrochen.
26741
Der RP6 dreht sich an seinem standort langsam im kreis und sucht das IR-signal (das kann an mehreren standorten erfolgen), fährt dann in richtung des stärksten empfangs, so lange bis er auf die halbkreisförmige linie stößt.
Dann fährt er (es ist eigentlich egal, ob rechts oder links) links. Trifft er auf die unterbrechung der halbkreislinie, dreht er sich an der stelle, bis er die kreuzende linie findet und fährt dann auf die ladestation zu, hält über dieser mit hilfe der bumper an.
Schaltet sich dann ab (oder wenigstens die meisten verbraucher).
Hat er sich beim treffen auf die halbkreislinie die falsche richtung ausgesucht, wird er an der wand angehalten (bumper), dreht und folgt der halbkreislinie bis er die unterbrechung findet und fährt dann zu ladestation...
--------------------------------------
machbar? Kann man z.b. am NE555
26740
fünf parallel geschaltete dioden betreiben? Sonstige Gedankenfehler?
Hallo Inka,
wenn der Q1 stark genug ist kannst du 1000 LEDs damit schalten.... du setzt einfach parallel zu Led1/R3 weitere Leds/Widerstände von + gegen den Kollektor hinzu. Ob der Transistsor nun 1,2,5 oder 1000 LED/R Bündel schaltet, hängt allein von dem zulässigen C/E Strom ab und der liegt beim 2n2222 bei 800mA. http://en.wikipedia.org/wiki/2N2222
Bei der Schaltung ist R3 für 104mA pro Diode berechnet, also kann man 7 Dioden/R schalten, 5 sollten ohne große Probleme gehen. Allerdings solltest du 0,5 W oder besser 1W (falls dein Dutycycle nicht stimmt) Widerstände verwenden.
Ob die Konstruktion ansich funktioniert.. da hab ich so meine Zweifel. Siehe oben.
Ich frage mich auch grade, warum das IR Licht gepulst sein muss... ein reiner IR Emitter strahlt auch ungepulst. Es gibt zwar IR Reciver, die nur auf 38khz IR reagieren aber diese sagen dir im allgemeinen nicht, wie stark das IR Signal ist, sondern sind darauf optimiert Signalpakete einzulesen.
Was Du brauchst ist ja eher eine Schaltung, welche dir sagt wie stark das Licht aus einer bestimmten Richtung als solches ist.. ähnlich einem Tageslichtsucherprogramm mit den 2 boardeigenen LDRs. Also brauchst du sowas wie die LDR Geschichte.. nur eben IR-empfindlich. Wenn du das Signal unbedingt pulsen willst.. z.B. um es von natürlichen oder fremden IR Quellen unterscheiden zu können, dann musst du es zudem noch per Software auf die 38khz oder was auch immer prüfen...
Zur Technik der berührungslosen Ladestation ... in meinem Bot sind 6 Zellen a 2800mAh, das bedeutet ca. 27Wh ... diese in einer realistischen Zeit in einer Art "offener Trafo" übertragen zu wollen ohne das man sämtliche Radios & HIFI-Anlagen im Umkreis von 1500m stört halte ich für kaum machbar. Das wär genau so wie wenn du das Solarfeld aus ner LED-Wegbeleuchtung zum laden nimmst. Die Energieübertragung wie man sie bei Induktionsherden findet ist übrigends NICHT als Trafo ausgelegt, da dort enorm große induzierte Wirbelströme zur Wärmeerzeugung genutzt werden... Bei einem Trafo mit gutem Wirkungsgrad (viel Spannung/Strom, wenig Verlust) versucht man die Wirbelströme so gering wie möglich zu halten weshalb Trafos aus einzelnen Blechpaketen gebaut werden und nicht aus einem Einzelkern. Schon das allein zeigt wie gegensätzlich die Verfahren sind. Bei einer Elektrozahnbürste mit einem 900mA Accu die 23,9h läd und 5 min am Tag gebraucht wird, oder einem 3,7V Lithiumaccu mit 1200mA und einem grenzwertigen EMV Wert (http://de.wikipedia.org/wiki/Elektromagnetische_Vertr%C3%A4glichkeit) mag das alles noch gehen aber der Bot braucht min. 10-30 mal mehr Strom zum Laden... 10% gilt allgemein als reine Erhaltungsladung...
Wie man Energie durch die Luft überträgt hat übrigens schon ein gewisser Herr Tesla recht eindrucksvoll erforscht. http://de.wikipedia.org/wiki/Nikola_Tesla
Ich rate Dir von dem Projekt ab wenn es unter dem Aspekt "soll funktionieren" zu sehen ist... siehst du es unter dem Aspekt "nur durch Fehler kann man lernen" .. mach es... und berichte. Ich bin gespannt.
Gruß Rolf
oberallgeier
18.11.2013, 08:34
... gibt zwar IR Reciver, die nur auf 38khz IR reagieren aber diese sagen dir im allgemeinen nicht, wie stark das IR Signal ist, sondern sind darauf optimiert Signalpakete einzulesen ...Die üblichen IR-Receiver für Radio, TV, Photo (alle Consumer Elektronik) etc. rattern mit Trägerfrequenzen zwischen 30 kHz und 60 kHz, am verbreitesten sind wohl 36 kHz. Dabei sind zur Erkennung der Pulse immer mehrere Bursts notwendig, z.B. 6.
Diese Dinger sind für digitale Anwendungen gebaut, stimmt, ABER man kann sie auch zur Messung der Lichtstärke missbrauchen. Hintergrund ist die etwas träge AGC im Empfangsteil des Receivers. Ich wobble die Sendediode mit duty cycles zwischen 1 und 127 von 255 so lange bis ich den Wert finde, wo gerade kein Empfang mehr möglich ist (also grad mal sieben Iterationen). Diesen Wert nehme ich als "Entfernungssignal", Näheres hier mit Klick. (https://www.roboternetz.de/community/threads/33984-Abstandsmessung-ähnlich-wie-IR-Schnittstelle-des-asuro)
... wenn ... fremden IR Quellen unterscheiden ... 38khz ... prüfen ...Genau das, aber 36 kHz, macht bei mir der Receiver selber mit BPF und Demodulator. Die Toleranz gegen Frequenzabweichungen ist deutlich, man kann bei fünf Prozent Abweichung - 38 kHz statt 36 kHz - von zehn bis dreißig Prozent geringerer Empfindlichkeit ausgehen.
Hallo..
Ich wobble die Sendediode mit duty cycles
Ok.. quasi gePWMte IR LEDs... Das geht aber nur wenn Sender und Empänger Dioden beide auf dem Bot als Reflexlichtschranke arbeiten wobei die Reflektionseigenschaften von Material die Reichweite eben so beeinflussen wie die Signalstärke ODER die sendende Bake mit dem Impulspaket auch eine codierte Zahl versendet, aus der der Bot schließen kann mit welcher Leistung die Transmission erfolgte. Was man wiederum nicht mit einem NE555 hin bekommt, da braucht man schon z.B. ein kleinen (schlauen) ATiny4 oder ATiny9 als Hirn und Taktgeber um die senderleistungscodierten IR-Pakete abzusetzen. Ja das könnte besser funktionieren als die ne555 Geschichte. Siehe oben, Leuchtturmprinzip.
Gruß Rolf
oberallgeier
18.11.2013, 22:43
... Das geht aber nur ... ODER die sendende Bake ...Das "geht aber nur" war hier nicht gemeint, sondern das zuvor ausgeschlossene "ODER". Schon im Eingangspost ist ein Mikrocontroller erwähnt *gg*.
hi,
ich habe jetzt die bake auf einem exp-board aufgebaut:
26777
- ich würde jetzt das "glimmen" der IR-diode so interpretieren, dass die bake (auch) im IR bereich sendet (die rote LED ist nur als "kontrollleuchte" da, weil man ja das IR-licht nur mit der kamera "sieht")
- mit dem poti soll man ja die sendefrequenz einstellen können - kann ich die 36kHz irgendwie messen? In der beschreibung zu der schaltung steht:
--------------------------------------
Theoretical frequency can be calculated by:
f=1/(1.4 RC)
where f is frequency in kilohertz, R is resistance in kilohms, and C is capacitance in microfarads.
38 kilohertz = 1/(1.4 * 18.7969 kilohms * 0.001 microfarads)
Even if you could find a 18796.9 ohm resistor, it turns out the capacitance and resistance of the wiring and the wide tolerance (even at 1%) of the parts means a variable resistor (potentiometer) is a must! Also, the current being used to drive the transistor (Q1) alters the timing a bit.
Using a 1-nF (C1) [1 nF is same as 0.001 µF] capacitor and a 15-kilohm fixed resistor (R1) plus a 5-kilohm potentiometer (R2) does the trick. Not only does the potentiometer allow for hand tuning, but also the frequency can be varied from about 32 kHz up to about 42 kHz. The margin means the desired values of 36 kHz to 40 kHz should be attainable even with variations in parts and wiring.
----------------------------------------
ich habe die testdatei für das verwenden einer fernbedienung mit der m32 - hier (https://www.roboternetz.de/community/threads/40446-M32-Master-Problem-mit-RC5) - geladen und beim ein/ausschalten der bake verändert sich das LCD natürlich nicht, aber im terminal kann man veränderungen bei einigen werten beobachten, je nachdem ob die bake sendet oder nicht....
- welche variablen wären es wert beobachtet zu werden?
edit: die von mir beobachteten änderungen waren auf die rote LED zurückzuführen, um so wichtigen wird die frage - wie kannn ich mit dem RP6 verifizieren, ob die bake sendet und ob etwas vom RP6 empfangen wird? Vermutlich (sicher?) stimmt die sendefrequenz nicht...
Sendefrequenzen und vor allem Dutycycle (Abstand von low zu high im Schaltzyklus) wirst du Zuverlässig nur mit einem Oszi prüfen können. Oder mit einem IR Empfänger der die IR-Daten misst und auswertet. Das müsste die RP6 Base z.B. können. Manche Multimeter haben zudem eine Frequenzmessung (das Metex M-3650CR z.B.)
Ich hab mir für sowas mal den Polin Bausatz von der Netio mit nem AVR Atmega 1284 besorgt
http://www.pollin.de/shop/dt/MTQ5OTgxOTk-/Bausaetze_Module/Bausaetze/Bausatz_AVR_NET_IO.html
um ein "programierbares exBoard" für solche zwecke aufzubauen.. allerdings hab ich es derzeit nicht in Verwendung.. aber das würde ich nun verwenden...
Gruß Rolf
Hi inka,
deine Bake sendet ja zur Zeit nur mit etwa 36 kHz.
Zunächst gibt es da 2 Fragen:
1. Stimmt die Frequenz?
Man könnte sie z.B. messen: Messgerät (https://www.roboternetz.de/community/threads/47088-RP6Control-M32-Impulslängen-Messgerät)
2. Kann der RP6 die Bake empfangen?
Der IR-Empfänger auf dem RP6 (TSOP 34836) hat am Ausgang ein Low-Signal, wenn er 36 kHz empfängt, sonst High.
Bei ersten Tests helfen also nicht die Programme, mit denen man RC5-Code empfangen kann.
Man müßte den Portpin, an dem der TSOP hängt, direkt abfragen. Bei der RP6 Base ist das der Portpin PB2.
Dafür müßtest du ein eigenes Programm schreiben, das den Pegel von PB2 ausgibt.
Hi Dirk,
wenn das mit dem messgerät ginge, das wäre ja phänomenal!
kompilieren konnte ich das programm schon mal, jetzt noch eine frage:
ich komme nicht gut an die M32 ran, die I/Os sind doch auch auf die multi I/O ausgeführt - Du weisst es sicher aus dem stegreif - wo kann ich dort den PD6 abgreifen?
die zweite frage schliesst sich unmittelbar dran :-) - um die frequenz an meinem IR-testboard zu messen, muss ich den colector des 2N2222 mit dem PD6 verbinden und masse des test-boards mit masse des RP6, oder?
Hi inka,
ich komme nicht gut an die M32 ran, die I/Os sind doch auch auf die multi I/O ausgeführt - Du weisst es sicher aus dem stegreif - wo kann ich dort den PD6 abgreifen?
Ich muss (wie du auch!) nachsehen: Belegung Stecker IO-Mxxx (http://www.rn-wissen.de/index.php/RP6_Multi_IO_Projekt_-_Software#RP6_CONTROL_M32)
um die frequenz an meinem IR-testboard zu messen, muss ich den colector des 2N2222 mit dem PD6 verbinden und masse des test-boards mit masse des RP6, oder?
Ich habe die Schaltung der Bake nicht vor Augen. Wenn der 2N2222 der NPN-Treiber für die IR-LED ist und max. 5V anliegen, kann man die Frequenz am Kollektor abnehmen und natürlich die GNDs beider Schaltungen verbinden. Wenn man (wie ich) Grobmotoriker ist und auf Nummer sicher gehen will, dann kann man auch noch einen Serienwiderstand 220 Ohm zwischen PD6 und den Kollektor des Treibers tun.
hi Dirk,
danke für die antwort, sorry, dass ich mich nicht korrekt genug ausgedrückt habe:
Dass der PD6 auf dem I/O pin 8 des IO_m-xxx rauskommt habe ich gefunden, nur dieses wissen allein nutzt mir nicht viel, der stecker ist ja mit einem kabelstecker "zu". Mir ging es eher darum zu erfahren, wohin nun dieses signal RX (hört sich irgendwie nach ISP an?) auf der multi IO weitergeführt wird? Das habe ich auf dem stromlaufplan der multi IO nicht gefunden...
der 2N2222 ist der transistor von dessen colector die IR diode angesteuert wird, damit weiss ich dann was ich womit verbinden muss - bis auf dieses "RX" :-(
btw: den begriff "grobmotoriker" kannte ich so nicht, ich muss zusätzlich ständig die brille wechseln...
Hi inka,
der I/O Pin 8 vom IO-Mxxx landet am Jumperblock J_IO an dem Pin, der mit "8" beschriftet ist.
Das ist der 2. Pin von links,- oben drüber steht "Rx" (siehe auch Abbildung "Abweichende I/O-Jumperstellung für die M32" weiter unten in dem Absatz, den ich verlinkt hatte).
ich muss zusätzlich ständig die brille wechseln...
Selbst-eintönende Gleitsicht-Gläser, also etwa so -> :cool:
hi,
ich habe jetzt die bake aus dem exp-board in die nächste version umgebaut, das board hatte mir zu viele wackler...
2679026791
alle IR-dioden senden, probleme bereitet die messung / einstellung der frequenz:
hier noch einmal der schaltplan:
26792
für die messung habe ich folgende punkte verbunden:
- emitter des treibertransistors (masse) mit GND (XBUS2) auf einem exp.board des RP6
- collector des trebeitransistors (zu den vorwiderständen der LEDs) mit dem pin 8 auf dem jumperblock J_IO (RX) der multi-I/O platine
änderung gegenüber dem schaltplan: statt dem 15kOhm (R1) habe ich 2,2k und 12k in reihe geschaltet, 15k hatte ich nicht
- das messprogramm verhält sich folgendermassen:
- beim starten des programms bleibt die anzeige leer, auch wenn die bake bereits angeschlossen ist und sendet
- erst beim erneuten start der bake (ein/aus an der steckdose) wird die (eine?) frequenz angezeigt.
- die anzeige reagiert nicht auf veränderungen am poti
- in der stellung des poti=0 ohm werden beim ein bzw. ausschalten (220V - steckdose) folgende werte (vorm komma) angezeigt:
ein --- aus
28828 --- 15841
3822 --- 3822
5728 --- 68965
554 --- 51779
4421 --- 17562
ich bin nun unsicher was mir diese werte sagen...
frage:
ich habe einen oszi:
26793
hab damit aber noch nie was gemessen, nur ein paar anfangsversuche aus einem buch - wie messe ich mit einem osziloscop - gemacht. Würde sich jemand trauen mir anhand des bildes zu beschreiben wie ich was einzustellen habe um die frequenz zu messen?
Wow!
Du bist ja "professionell" ausgerüstet! Hut ab.
Zur Sicherheit:
1. Das "M32-Messgerät" hast du so kompiliert, dass die "//" am Anfang der Zeile "//#define FREQUENCY" entfernt wurden?
2. Der Anschluß PD6 auf Kollektor von Q1 und GND an GND ist ok?
3. Schwingt die Schaltung überhaupt? (sieht man dann ja mit dem Oszi)
Sonst kannst du natürlich auch mit dem Oszi die Frequenz messen:
1. Messfühler an Kollektor von Q1, Masse Oszi an GND
2. Volts/Div auf 0,5 oder 1V (Signale vertikal nicht abgeschnitten!)
3. DC/AC/GND-Schalter auf DC
4. Trigger auf DC, TV auf Off
5. Mit Time/Div und Hold so einstellen, dass eine gut zählbare Anzahl von Rechtecksignalen stabil (nicht wandernd) auf dem Schirm steht.
6. Dazu muss man die Position der Kurve mit X-Pos und Y-Pos sicher noch herumschieben, horizontal auch so, dass sich am li. Rand eine Signalflanke mit einem Raster auf dem Oszi-Schirm deckt.
Die Periodendauer [s] ist dann: Time/Div [s] * DIVs / Perioden
Die Frequenz [Hz] ist: 1 / Periodendauer
Dabei ist:
- DIVs -> Anzahl der horizontalen Unterteilungen auf deinem Oszi-Schirm
- Perioden -> Anzahl vollständiger Schwingungen in den o.g. DIVs
- Time/Div -> Stellung deines Oszi-Schalters umgerechnet in Sekunden
Wow!
Du bist ja "professionell" ausgerüstet! Hut ab.eigentlich wollte ich schon als junge elektronik studieren, leider ist es beim bergbau geblieben - warum auch immer...
1. Das "M32-Messgerät" hast du so kompiliert, dass die "//" am Anfang der Zeile "//#define FREQUENCY" entfernt wurden?
2. Der Anschluß PD6 auf Kollektor von Q1 und GND an GND ist ok?beidesmal ja...
3. Schwingt die Schaltung überhaupt? (sieht man dann ja mit dem Oszi)vermutlich nicht...
die aufnahme 1 entstand bei abgeschlateter, aber am oszi hängender bake, VOLTS/DIV 20
26794
aufnahme 2 bei eingeschalteter bake, beim einschalten der bake wird die ampitude so groß, dass die kurve verschwindet, bei VOLTS/DIV 1 und herunterholen mit Y-pos sieht man dann
26795
Sonst kannst du natürlich auch mit dem Oszi die Frequenz messen:
1. Messfühler an Kollektor von Q1, Masse Oszi an GND
2. Volts/Div auf 0,5 oder 1V (Signale vertikal nicht abgeschnitten!)
3. DC/AC/GND-Schalter auf DC
4. Trigger auf DC, TV auf Off
5. Mit Time/Div und Hold so einstellen, dass eine gut zählbare Anzahl von Rechtecksignalen stabil (nicht wandernd) auf dem Schirm steht.
6. Dazu muss man die Position der Kurve mit X-Pos und Y-Pos sicher noch herumschieben, horizontal auch so, dass sich am li. Rand eine Signalflanke mit einem Raster auf dem Oszi-Schirm deckt.
so eingestellt...
Hi inka,
manchmal kann man beim Hobby einiges nachholen, was sonst nicht möglich war. Ist doch gut ...
die aufnahme 1 entstand bei abgeschlateter, aber am oszi hängender bake, VOLTS/DIV 20
Das ist eine Streuspannung von ca. 100 mV. Die kommt aus dem 230V-Netz und ist hier unwichtig. Die Einstellung von VOLTS/DIV ist übrigens 20 mV ,- mal ca. 5 Kästchen vertikal = 100 mV.
bei VOLTS/DIV 1 und herunterholen mit Y-pos sieht man dann
Ist das Oszi auf 2-Kanal eingestellt? Wenn ja, ist die untere Linie womöglich der 2. Kanal. Stell den mal ab (DC/AC/GND des re. Kanals auf GND).
Wenn also die obere etwas breite blasse Linie der 1. Kanal ist, an dem deine Bake hängt, dann könnte das eine höherfrequente Schwingung sein, allerdings mit niedriger Amplitude.
Schau mal nach, wie die aussieht: TIME/DIV weiter nach rechts drehen, bis du einzelne Schwingungen identifizieren kannst.
Hi Dirk,
Hi inka,
manchmal kann man beim Hobby einiges nachholen, was sonst nicht möglich war. Ist doch gut ...
ja, wie wahr...
Ist das Oszi auf 2-Kanal eingestellt? Wenn ja, ist die untere Linie womöglich der 2. Kanal. Stell den mal ab (DC/AC/GND des re. Kanals auf GND).
Wenn also die obere etwas breite blasse Linie der 1. Kanal ist, an dem deine Bake hängt, dann könnte das eine höherfrequente Schwingung sein, allerdings mit niedriger Amplitude.
Schau mal nach, wie die aussieht: TIME/DIV weiter nach rechts drehen, bis du einzelne Schwingungen identifizieren kannst.
der zweite kanal stand auf DC, es veränderte sich aber beim umschalten auf GD nichts. Bei den einstellungen VOLTS/DIV = 10 (und weisser pfeil nach unten), TIME/DIV = 20micro sec kommt folgendes bild:
26796
was kann man da sehen:
Amplitude:
Bei 10V/DIV und so wie ich das sehe ca. 0,5 DIV Höhe -> 5V
Periodendauer:
Ich sehe ca. 2 Perioden auf 5 DIV, bei 20µs/DIV:
0,00002 * 5 / 2 = 0,00005 s = 50 µs
Frequenz:
1 / Periodendauer = 20000 Hz = 20 kHz
Dazu ist die Rechteckschwingung nicht symmetrisch, sondern der (positive) Impuls ist kürzer als die Pause (= Nulllinie).
Ich sehe ca. 0,8 DIV Impuls und 1,7 DIV Pause, also ein Impuls-Pausenverhältnis von 32% zu 68%.
Du misst da also eine unsymmetrische Rechteckspannung von 5V mit einer Frequenz von 20 kHz und einem Duty-Cycle von 32%.
hi Dirk,
die ergebnisse und die auswertung muss ich erst begreifen. Ich habe jetzt weiter experimentiert - juhuu - die erste echte messung mit dem oszi!
die einstellungen:
VOLTS/DIV = 1
TIME/DIV = 20micro sec
TV SEP = off
TRIG = HF
schalter neben dem input = DC
ein wirklich stehendes bild, in dem die kurve auf die drehung des potis reagiert.
poti 0 ohm
26797
poti 5K ohm
26798
also die schaltung ist wohl ok? Deine interpretation dieser zwei bilder würde meinem verständnis dieser messungen sehr helfen...
ich vermute die frequenz liegt in beiden fällen unterhalb der 36kHz...
Hi inka,
beim 1. Bild sehe ich eine Periode auf etwa 5,2 DIV
beim 2. Bild habe ich eine Periode auf etwa 6,9 DIV
Jetzt geht's bei 20µs/DIV ans Rechnen analog zu meiner Auswertung von 15:32.
Viel Erfolg!
Übrigens: Besser wird die Auswertung, wenn man viele gerade noch einzeln zählbare Perioden auf möglichst die ganze Breite (also möglichst viele DIVs) darstellen kann, weil man dann exakter rechnen kann.
RoboHolIC
24.11.2013, 18:49
einstellungen VOLTS/DIV = 10 (und weisser pfeil nach unten)
Bitte alle Mittelpotis mit den weißen Pfeilen bis zum Einrasten nach rechts drehen! Nur dann stimmen die Skalierungen des Stufenschalter! Andernfalls sind die Ablesungen quantitativ wertlos, weil unbekannte Skalierungsfaktoren mit drin sind.
hi,
beiden vorschlägen folgend (btw. bei meinem oszi ist der einrastende anschlag für den poti links) habe ich noch ein paar messungen und versuche gemacht:
bild 6:26811
bild 7:26812
bild 8:26813
bild 9:26814
die messergebnisse sind hier in der tabelle:
bild
Vorwiderstand [kOhm]
widerstand poti [kOhm]
gesamt widerstand [kOhm]
TIME / DIV [sec]
VOLT / DIV [V]
DIV
perioden
periodendauer [sec]
Frequenz [Hz]
Frequenz [kHz]
6
14,2
0,0
14,2
0,000020
1
9
5
0,000036
27777,78
27,78
7
14,2
5,0
19,2
0,000020
1
9
4
0,000045
22222,22
22,22
8
2,2
0,0
2,2
0,000005
1
8
6
0,000007
150000,00
150,00
9
2,2
5,0
7,2
0,000010
1
9
5
0,000018
55555,56
55,56
Ergebnis für 36,00 kHz
10
3,2 (gemessen)
13,2
0,000010
1
8
2,88
0,000028
36000,00
36,00
das ergebnis als bild 10, einstellungen in der tabelle, letzte zeile:
26815
habe ich die 36kHz geschafft?
Hi inka,
sieht gut aus. Ich habe nur die Abbildung 10 ausgewertet:
Ich sehe 2 Perioden auf etwa 6,0 DIVs (siehe Bild!). Bei TIME/DIV = 10 µs gilt dann:
Periodendauer = 0,00001 * 6,0 / 2 = 0,00003 s = 30 µs
Frequenz = 1 / Periodendauer = 1 / 0,00003 = 33333 Hz = 33,3 kHz
Also: Fast geschafft.
Bei deiner Schaltung würde ich das Poti R2 auf Mittelstellung lassen und mit dem Vorwiderstand R1 die Gesamtschaltung auf 36 kHz bringen.
Dann kannst du mit R2 die Frequenz genau abgleichen.
hi Dirk,
26820
im bild 11 wären es jetzt 6,5 perioden auf 9 DIVs . Bei TIME/DIV = 20 µs wäre:
Periodendauer = 0,00002 * 9 / 6,5 = 0,0000276 s = 27,6 µs
Frequenz = 1 / Periodendauer = 1 / 0,0000276 = 36231,9 Hz = 36,23 kHz
einverstanden?
ich glaube das messen (oder ist es eher ein schätzen?) einer frequenz ist relativ einfach - wenn man weiss, wie was einzustellen und zu lesen ist...
für das einstellen einer frequenz wäre es wichtig eine ganze zahl als DIV und eine ganze zahl von perioden zu bekommen. Ist das überhaupt möglich? Oder muss man sich mit 6,5 - wie ich hier aushelfen?
was würdest Du sagen - mit welcher genauigkeit kann man mit dem oszi die frequenz überhaupt messen? Und - mit welcher genauigkeit braucht der RP6 diese frequenz?
Kontrolle:
Ich sehe z.B. 6 Perioden auf 8,4 DIVs (Bild!) bei TIME/DIV von 20 µs:
Periode: 0,00002 * 8,4 / 6 = 0,000028 s = 28 µs
Frequenz: 35,7 kHz
Bei der Messung würde ich die Perioden immer ganzzahlig lassen und nur die DIVs auf +-0,1 ablesen.
ich glaube das messen (oder ist es eher ein schätzen?) einer frequenz ist relativ einfach - wenn man weiss, wie was einzustellen und zu lesen ist...
Ja, genau. Das Oszilloskop ist (wie sein Name schon sagt) auch kein idealer Frequenzmesser. Daher ist die Genauigkeit nicht hoch.
Vielleicht bekommst du ja doch auch noch Werte vom "M32-Messgerät", so dass du die Frequenz optimal einstellen kannst.
Für den IR-Empfänger auf dem RP6 ist eine leichte Abweichung nicht so dramatisch, wobei seine Hauptempfindlichkeit halt bei 36 kHz liegt.
Peter(TOO)
26.11.2013, 12:35
Hallo inka,
was würdest Du sagen - mit welcher genauigkeit kann man mit dem oszi die frequenz überhaupt messen? Und - mit welcher genauigkeit braucht der RP6 diese frequenz?
Die Zeitbasis sollte auf ein paar % stimmen, genaues steht im Handbuch.
Der Rest liegt dann beim Ablesen vom Schirm.
MfG Peter(TOO)
(Ot)
Hallo,
messen oder ist es eher ein schätzen?
Es gibt sicher bessere Möglichkeiten Frequenzen zu _messen_ ... im Sinn eines Takt- oder Nulldurchgangszählers ... aber nicht alle Signale sind immer digital.
Geht es um die Flankensteilheit (hier ist sie gut) oder um die Signalform allgemein (z.b. zur Berechnung von Filtern) , ist ein Oszi unverzicht- und unersetzbar. Aber aus der Physik ist bekannt, das man sowieso keine absoluten Werte messen kann sondern es nur mehr oder weniger genaue Näherungsverfahren gibt.
http://de.wikipedia.org/wiki/Heisenbergsche_Unsch%C3%A4rferelation
In sofern ist messen immer ein "schätzen" mit mehr oder weniger genauen Referenzen als Hilfsmittel.
Aber davon ab finde ich die Aktion mit der "Fernmessung" am Oszi hier mal richtig gut - zeigt es doch was man damit erreichen kann - was sonst nur im stillen Kämmerlein in der Hobbyecke passiert. 3 Daumen hoch!
Gruß RolfD
(/Ot)
RoboHolIC
26.11.2013, 17:58
mit welcher genauigkeit kann man mit dem oszi die frequenz überhaupt messen? Und - mit welcher genauigkeit braucht der RP6 diese frequenz?
Das Datenblatt zum Oszi "HM203-6" ist bei www.hameg.com (http://www.hameg.com) zu finden. Darin findet man Aussagen zur Genauigkeit der Vertikal-Anzeige, Bandbreite etc. und eben auch zur Zeitbasis, jeweils garantierte Werte für ein Neugerät nach Werkskalibrierung. Dazu kommt noch der Fehler durch die Ablesung, besonders dann, wenn man Zwischenwerte ohne Teilstrich ablesen muss.
Was den IR-Sensor betrifft, sollte auch hier im Datenblatt eine Angabe über den Empfindlichkeitsabfall in Abhängigkeit von der Lichtwellenlänge zu finden sein: wenigstens eine 50%-Bandbreite (oder 30% oder ...) oder sogar ein Diagramm.
hallo,
ich habe folgendes versucht um eine verifizierung des empfangs der signale der bake am RP6 zu bekommen, durchgeführt von der M32 aus:
verwendet habe ich das programm "RP6Control_06_I2CMaster.c"
/*
* ************************************************** **************************
* RP6 ROBOT SYSTEM - RP6 CONTROL M32 Examples
* ************************************************** **************************
* Example: I2C Master
* Author(s): Dominik S. Herwald
* ************************************************** **************************
* Description:
* Now we will use the I2C Bus Interface to send commands to the Controller
* on the Mainboard and read sensor values.
* This program does not do anything directly, it checks for pressed buttons
* and then runs a small I2C Bus example depending on which button has
* been pressed.
*
* You need to program the Controller on the Mainboard with the I2C Bus Slave
* Example program from the RP6Base examples! Otherwise it will not work!
*
* ################################################## ##########################
* The Robot does NOT move in this example! You can simply put it on a table
* next to your PC and you should connect it to the PC via the USB Interface!
* ################################################## ##########################
* ************************************************** **************************
*/
/************************************************** ***************************/
// Includes:
#include "RP6ControlLib.h" // The RP6 Control Library.
// Always needs to be included!
#include "RP6I2CmasterTWI.h"
/************************************************** ***************************/
#define I2C_RP6_BASE_ADR 10 // The default address of the Slave Controller
// on the RP6 Mainboard
/************************************************** ***************************/
// I2C Error handler
/**
* This function gets called automatically if there was an I2C Error like
* the slave sent a "not acknowledge" (NACK, error codes e.g. 0x20 or 0x30).
* The most common mistakes are:
* - using the wrong address for the slave
* - slave not active or not connected to the I2C-Bus
* - too fast requests for a slower slave
* Be sure to check this if you get I2C errors!
*/
void I2C_transmissionError(uint8_t errorState)
{
writeString_P("\nI2C ERROR - TWI STATE: 0x");
writeInteger(errorState, HEX);
writeChar('\n');
}
/************************************************** ***************************/
// Rotate function
uint8_t transmit_buffer[10]; // temporary transmit buffer
// A global variable saves space on the heap...
#define CMD_ROTATE 8
#define LEFT 2
#define RIGHT 3
/**
* Rotate function - you can define nearly the same functions as you have on
* the RP6 and just forward the commands with I2C Bus transfers...
* We will make an improved version of this and other functions in another example!
*/
void RP6_rotate(uint8_t desired_speed, uint8_t dir, uint16_t angle)
{
transmit_buffer[0] = 0;
transmit_buffer[1] = CMD_ROTATE;
transmit_buffer[2] = desired_speed;
transmit_buffer[3] = dir;
transmit_buffer[4] = ((angle>>8) & 0xFF);
transmit_buffer[5] = (angle & 0xFF);
I2CTWI_transmitBytes(I2C_RP6_BASE_ADR, transmit_buffer, 6 );
}
/************************************************** ***************************/
// Read all registers function
uint8_t RP6data[32]; // This array will contain all register values of RP6
// after you called readAllRegisters()
// It is better to keep such big arrays GLOBAL as
// they otherwise fill up the stack in memory...
/**
* This function reads ALL registers available in the standard I2C Bus Slave
* Example program for the Robot Base and outputs their values on the serial interface.
* You will see a lot of zeros when the Motors are not running. The main values that are not
* zero are the two Light Sensors and the two free ADC Channels.
*/
void readAllRegisters(void)
{
I2CTWI_transmitByte(I2C_RP6_BASE_ADR, 0); // Start with register 0...
I2CTWI_readBytes(I2C_RP6_BASE_ADR,RP6data, 31); // and read all 30 registers up to
// register Number 29 !
// Now we output the Data we have just read on the serial interface:
writeString_P("\nREADING ALL RP6 REGISTERS:");
uint8_t i = 0;
for(i = 0; i < 31; i++)
{
if(i % 8 == 0) // add some newline chars otherwise everything
writeChar('\n'); // is printed on ONE single line...
else
writeString_P(" | ");
writeChar('#');
writeIntegerLength(i,DEC,2);
writeChar(':');
writeIntegerLength(RP6data[i],DEC,3);
}
writeChar('\n');
}
/**
* Here we demonstrate how to read a few specific registers.
* It is just the same as above, but we only read 4 registers and
* start with register Number 13...
* We also show how to combine values from high and low registers
* back together to a 16 Bit value...
*/
void readLightSensors(void)
{
uint8_t lightSens[4];
I2CTWI_transmitByte(I2C_RP6_BASE_ADR, 13); // Start with register 13 (LSL_L)...
I2CTWI_readBytes(I2C_RP6_BASE_ADR, lightSens, 4); // and read all 4 registers up to
// register Number 16 (LSR_H) !
writeString_P("Light Sensor registers:\n");
writeString_P(" | LSL_L:"); writeInteger(lightSens[0], DEC);
writeString_P(" | LSL_H:"); writeInteger(lightSens[1], DEC);
writeString_P(" | LSR_L:"); writeInteger(lightSens[2], DEC);
writeString_P(" | LSR_H:"); writeInteger(lightSens[3], DEC);
writeString_P("\n\n Light Sensor Values:");
writeString_P(" | LSL:"); writeInteger(lightSens[0] + (lightSens[1]<<8), DEC);
writeString_P(" | LSR:"); writeInteger(lightSens[2] + (lightSens[3]<<8), DEC);
writeChar('\n');
setCursorPosLCD(1, 3);
writeIntegerLengthLCD(lightSens[0] + (lightSens[1]<<8), DEC, 4);
setCursorPosLCD(1, 11);
writeIntegerLengthLCD(lightSens[2] + (lightSens[3]<<8), DEC, 4);
}
/************************************************** ***************************/
// Main function - The program starts here:
int main(void)
{
initRP6Control(); // Always call this first! The Processor will not work
// correctly otherwise.
initLCD(); // Initialize the LC-Display (LCD)
// Always call this before using the LCD!
writeString_P("\n\nRP6 CONTROL M32 I2C Master Example Program!\n");
// IMPORTANT:
I2CTWI_initMaster(100); // Initialize the TWI Module for Master operation
// with 100kHz SCL Frequency
// Register the event handlers:
I2CTWI_setTransmissionErrorHandler(I2C_transmissio nError);
// Play two sounds:
sound(180,80,25);
sound(220,80,25);
setLEDs(0b1111); // Turn all LEDs on!
showScreenLCD("################", "################", "", "");
mSleep(500);
showScreenLCD("I2C-Master", "Example Program 1", "", "");
mSleep(1000);
// ---------------------------------------
setLEDs(0b0000); // All LEDs off!
uint8_t counter = 1;
while(true)
{
// We check the buttons - just like the buttons example - but here we
// generate several I2C Bus requests and commands when a key
// is pressed AND released again...
uint8_t key = checkReleasedKeyEvent();
if(key)
{
switch(key)
{
case 1: // Increment a counter and send value to LEDs of the
// Slave Controller:
setLEDs(0b0001);
showScreenLCD("INCREMENT", "LED COUNTER", "", "");
I2CTWI_transmit3Bytes(I2C_RP6_BASE_ADR, 0, 3, counter);
counter++;
break;
case 2: // Read and display ALL registers of the slave controller:
setLEDs(0b0010);
showScreenLCD("READ ALL RP6", "REGISTERS", "", "");
readAllRegisters();
break;
case 3: // Read the light sensors and show value on display:
setLEDs(0b0100);
showScreenLCD("LIGHT SENSORS:", "L: R:", "", "");
readLightSensors();
break;
case 4: // Rotate a very small distance to the left:
setLEDs(0b1000);
showScreenLCD("ROTATE A BIT...", "... LEFT!", "", "");
RP6_rotate(35,LEFT,40);
break;
case 5: // Rotate a very small distance to the right:
setLEDs(0b1001);
showScreenLCD("ROTATE A BIT...", "... RIGHT!", "", "");
RP6_rotate(35,RIGHT,40);
break;
}
}
}
return 0;
}
mit foltgenden änderungen:
in der "RP6Base_I2CSlave.c":
zeile
inhalt
85
uint8_t pb2_value;
hinzu
231
#define I2C_REG_PB2_VALUE 30
hinzu
272
I2CTWI_readRegisters[I2C_REG_PB2_VALUE] = (uint8_t)(pb2_value);
hinzu
483
pb2_value = (PINB & (1<<PINB2));
hinzu
in der "RP6Control_06_I2CMaster.c":
103
I2CTWI_readBytes(I2C_RP6_BASE_ADR,RP6data, 30);
von
I2CTWI_readBytes(I2C_RP6_BASE_ADR,RP6data, 31);
in
109
for(i = 0; i < 30; i++)
von
for(i = 0; i < 31; i++)
in
benutzt habe ich die fukntion zum ausdrucken aller register "void readAllRegisters(void)", hier das ergebnis:
ursprünglich 30 register:
READING ALL RP6 REGISTERS:
#00:000 | #01:000 | #02:000 | #03:000 | #04:000 | #05:000 | #06:000 | #07:000
#08:000 | #09:001 | #10:000 | #11:002 | #12:000 | #13:099 | #14:003 | #15:220
#16:002 | #17:000 | #18:000 | #19:000 | #20:000 | #21:023 | #22:003 | #23:217
#24:002 | #25:212 | #26:002 | #27:000 | #28:000 | #29:000
31 register, ohne signale der bake:
READING ALL RP6 REGISTERS:
#00:000 | #01:000 | #02:000 | #03:000 | #04:000 | #05:000 | #06:000 | #07:000
#08:000 | #09:001 | #10:000 | #11:002 | #12:000 | #13:098 | #14:003 | #15:225
#16:002 | #17:000 | #18:000 | #19:000 | #20:000 | #21:023 | #22:003 | #23:220
#24:002 | #25:216 | #26:002 | #27:000 | #28:000 | #29:000 | #30:004
31 register, mit signalen der bake:
READING ALL RP6 REGISTERS:
#00:000 | #01:000 | #02:000 | #03:000 | #04:000 | #05:000 | #06:000 | #07:000
#08:000 | #09:001 | #10:000 | #11:001 | #12:000 | #13:107 | #14:003 | #15:247
#16:002 | #17:000 | #18:000 | #19:000 | #20:000 | #21:019 | #22:003 | #23:242
#24:002 | #25:238 | #26:002 | #27:000 | #28:000 | #29:000 | #30:000
ist die änderung des reg '30 von 004 in 000 der erhoffte nachweis? Wenn ja, könnte ich doch jetzt abhängig vom inhalt des reg 30 verschiedenes an funktionen ausführen?
Hi inka,
nicht schlecht.
Das kann so klappen, wobei ich die Änderungen nicht im Detail angesehen habe.
Die 4 in Register 30 ist ok:
Wenn kein IR-Signal anliegt, hat der Empfänger High-Pegel, daher ist deine Variable pb2_value binär = 0b00000100 (dezimal 4), das heißt, dass PINB2 (also Bit 2) gesetzt ist.
Wenn ein IR-Signal anliegt, ist das Bit nicht gesetzt, also Register 30 = 0.
Noch 2 Ideen/Vorschläge zu deiner tollen Umsetzung:
1. Mit pb2_value = (PINB & (1<<PINB2)); aktualisierst du den Wert bei jedem Durchlauf der Hauptschleife im Slave. Das kann man machen,- von der Programmstruktur her gehört das aber eher ans Ende der Funktion task_update().
Das Ergebnis ist dasselbe, aber das ganze "sauberer".
2. Grundsätzlich kann man das machen, dass man ein weiteres Register ergänzt. Es gibt noch einen weiteren Weg: Im Status-Byte (Register 1) sind noch Bits frei. Man könnte da ein weiteres Bit definieren:
// Some status bits with current settings and other things.
union {
uint8_t byte;
struct {
uint8_t powerOn:1;
uint8_t ACSactive:1;
uint8_t watchDogTimer:1;
uint8_t wdtRequest:1;
uint8_t wdtRequestEnable:1;
uint8_t IRreception:1;
uint8_t unused:2;
};
} status;
... und auch im Master auswerten. Das muss man aber nicht so machen.
Im Grunde zeigst du ja mit deiner Lösung, wie man den Base-Slave um eigene (Lese-)Funktionen erweitern kann. Klasse! :)
Genauso kann man auch zusätzliche Befehle definieren.
Wir hatten es oben schon mal von Toleranzen... der Wertebereich am Port wird vermutlich 0-255 haben.. 10% übliche Fehler wären 25.. wenn dein Teil nur um 4 Punkte ausschlägt stimmt entweder etwas nicht.. oder es kommt nur ein vernachlässigbar kleines Signal an. Jedenfalls liegen 4 Punkte im Bereich normaler schwankungen.. und sind als Signal nicht überzegend auswertbar. Ich würde das ohne M32 und dem Slave-geraffelss versuchen.. und die Werte des Port schlicht und einfach über eine serielle Verbindung an den PC ausgeben. Für dich lesenswert dürfte dazu ein Codeschnipsel von Dirk sein, welcher mal hier rum ging und IR Signale als Morse zwischen 2 Bots übertrug.
http://www.rn-wissen.de/index.php/RP6_-_Morse-Code#Morse-Code_mit_RP6_IRCOMM_senden.2Fempfangen
Gruß
Nachtrag... ach so.. der Port schaltet nur digital.. stimmt ...nix mit 0-255 ... tja plöt .. mein Kommentar wie auch deine Ausgangslage! :)
@Dirk, @RofD:
vorschlag 1 werde ich durchführen, vorschlag 2 erstmal anschauen, für meine "quick & dirty" lösung habe ich schon einen tag gebraucht...
zwei weitere problemchen:
1) die reichweite der bake liegt bei 30cm, das ist ein bischen wenig
2) der treiber-transistor wird trotzdem recht warm (finger kann man nicht draulfassen)
hier noch einmal der schaltplan;
26834
zu 1)
- an den IR-dioden fließen 20mA, das kann man sicher erhöhen - die vorwiderstände haben 47 Ohm, auf wieviel sollte/könnte ich runter? Ich habe an der stelle schon recht viel rumgelötet :-(
(Ich habe dort 5 dioden parallel an dem transistor mit jeweils einem R)
zu 2)
- den 2N2222 könnte ich durch BD135, auch NPN und leistungsstärker (hatte ich noch in der kiste) ersetzen
- wie ist es mit dem basiswiderstand - wie könnte der zur leistungssteigerung der IR-dioden beitragen?
@RofD.
beruhigend, wenn auch profis mal daneben greifen :-) - nichts für ungut...
was meinst Du mit meiner ausgangslage?
Also ich bin bestimmt kein Profi... und mache selbstverständlich auch Fehler. Aber du beschreibst deine Lage selbst.. dein Bot kann nun in Umkreis von 30cm feststellen ... per 0 oder 1 ... ob die Bake sendet. Das ist weit von einer vernünftigen Raumortung entfernt und entspricht etwa den IR-Abstandssensoren, die es so zu kaufen gibt... vielleicht reicht dir das ja als Bake.
Jetzt kann man (z.B. aus der Funktechnik, Licht ist elektrisch gesehen auch eine art elektromagnetische Schwinung) wissen, das man für die Verdoppelung von Reichweiten eine 4-fache Leistung braucht - oder anders gesagt, die Leistung steigt zur Reichweite im Quadrat. D.H. um auf 60 cm Reichweite zu kommen muss du entweder 20 LEDs nehmen... oder irgendwie 80mA Durchschnittsstrom durch deine 5 LEDs schicken was auf dauer keine normale IR-LED überlebt! Um auch diese Leistung zu verdoppeln brauchst du wiederum das 4 fache... also 80 Leds auf 1,20 m ... usw usw... oder dir einen empfindlicheren Empfänger selbst bauen.
Vielleicht wird nun klar das es kaum möglich ist ein, Raum mit herkömlichen IR-Dioden von einem Punkt aus komplett auszuleuchten. Selbst mit modernen LED-Leuchtmitteln braucht man 5 Watt im normalen Lichtwellenbereich um ein Raum so zu beleuchten das einfache LDR-Sensoren das anmessen. Du arbeitest da derzeit mit ca. 50 Milliwatt .. also 1%! Und trotz aller Überlegung hast du bisher (noch?) keine Info über die Stärke des Lichtsignals im RP6...
Gruß Rolf
oberallgeier
27.11.2013, 18:55
... irgendwie 80mA Durchschnittsstrom durch deine 5 LEDs schicken was keine normale IR-LED überlebt...Wissen das auch Osram, Telefunken etc ?
...
Vergleiche....................................SFH 415.............CNY99.............SFH4600
Abstrahlwinkel °..............................± 17.................± 25................± 20
Strahlstärke mW/sr (IF100mA)........25 (U: 40)..............14.................>=16
Vorwärtsstrom IF mA........................ 100................. 150............... 100
Durchlassspng VF (IF100mA) V.........1.3 (<1.5).........1.4 (1.7)........1.5 (<1.8-)
An-/Abstiegszeit ns......................... 500................. 400.............. 10
...
Könnt man auch lesen als "Was ist normal?"
radbruch
27.11.2013, 19:11
Hallo
Ich vermute, die Trägerfrequenz des IR-Signals stimmt nicht. Mit einem 2-Kanal-Oszi könnte man zum Vergleich eine bekannte (mit dem RP6 erzeugte) Referenzfrequenz einspeisen. Als Vergleichswert für die Reichweite des IR-Signals könnte ich ein Zitat aus "meinem" Tiny13-RC5-Thread anführen:
"Ich habe nun einen 50 Ohm Vorwiderstand und kann aus ca. 1m Entfernung senden"
(Aus https://www.roboternetz.de/community/threads/32476-RC5-Senden-mit-Attiny13?p=308518&viewfull=1#post308518)
Zuviel Reichweite des Signals dürfte auch kontraproduktiv sein. Durch Reflexionen im Raum wird die Ortung der IR-Bake unmöglich!
Gruß
mic
hi,
also ich möchte jetzt hier keine theoretische disskusion vom zaun brechen von der ich nur ein drittel verstehe - bitte versucht mich zu verstehen...
auch was die einschätzung meiner ausgangslage betrifft, gibt es verschiedene blickwinkel, der meine ist sehr praktisch. Ich bin schon damit zufrieden, dass es mir mit vernünftigen aufwand gelang eine einfache IR-bake zu bauen, dass die funktioniert, vom rob erkannt wird und jetzt möchte ich, auch wieder ganz der praktiker - mit Euerer hilfe das ding verbessern:
- Also reichweite erhöhen: ich habe schon gelesen, dass manche fernbedienungen mit 3A pro 25 milisec arbeiten, also wie kann ich jetzt vorgehen um ein raum von 5x4m mit gepulstem IR-licht zu bestrahlen, vielleicht muss es ja nicht dauernd rennen, der roby hat ja zeit auch mal 2 minuten zu warten bis das nächste signal kommt...
- Leistung erhöhen: Transistor ersetzen? Vorwiderstände reduzieren?
aber noch einmal, ich betreibe es als hobby, ich "spiele" nur, freue mich aber auch über kleine erfolge wie mit der erkennung der bake durch den roby, auch wenn es nur auf eine distanz von 30cm war... und habe manchmal fast schlechtes gewissen Euere zeit zu sehr in anspruch zu nehmen...
Es macht aber mehr spass, als nur ein fachbuch zu lesen. Das mit dem oszi z.b. war einfach spitze, danke noch einmal Dirk...
@radbuch:
Ich vermute, die Trägerfrequenz des IR-Signals stimmt nicht. Mit einem 2-Kanal-Oszi könnte man zum Vergleich eine bekannte (mit dem RP6 erzeugte) Referenzfrequenz einspeisen.
welche frequenz ist es? Die 36kHz? Die hat doch der roby erkannt? An welchen punkten der base müsste ich die referenzfrequenz messen?
https://www.roboternetz.de/community/threads/32476-RC5-Senden-mit-Attiny13?p=308518&viewfull=1#post308518)sehr interessant, kannte ich noch nicht, allerdings - noch ein prozessor? Ich kämpfe ja schon mit dem atmega32...
Zuviel Reichweite des Signals dürfte auch kontraproduktiv sein. Durch Reflexionen im Raum wird die Ortung der IR-Bake unmöglich!
so habe ich es noch gar nicht gesehen...
radbruch
27.11.2013, 20:35
Hallo
Ja, ich meine die 36kHz-Trägerfrequenz. Der TSOP erkennt auch Signale die ein paar kHz neben der Nennfrequenz liegen. Mit zunehmender Frequenzungenauigkeit wird die Erkennung durch den TSOP aber rapide schlechter. Diesen Effekt hatten wir mal zur Verwendung beim ACS angedacht, der Oberallgeier hats auch mal umgesetzt (wenn ich mich nicht irre). Auch nicht moduliertes IR-Licht wird auf ein paar Zentimeter Abstand vom TSOP als gültig eingestuft.
Gruß
mic
[Edit]
Wie erzeuge ich einen 36kHz-Ausgang an der Base?
ISR (TIMER2_COMP_vect)
{
static uint8_t ircomm_pulse;
// ADC0 mit 72kHz toggeln
PORTA ^= (1<<ADC0); // Toggle ADC0
if(acs_state < 2) { // If ACS is not active, perform IRCOMM transmissions
(RP6RobotBaseLib.c ungetestet, ADC0 sollte zuvor als Ausgang definiert werden...)
Um die ISR einzuklinken muss man den Interrupt freigeben:
TIMSK |= (1 << OCIE2);
also ich denke ich habe genügend versuche am oszi gehabt um es relativ genau einzustellen (weiter oben nachzulesen :-)), aber nochmal die frage - wo könnte ich die frequenz an der RP6- base denn messen? Ich nehme an es wäre die sendefrequenz des ACS?
oberallgeier
27.11.2013, 21:28
... Mit zunehmender Frequenzungenauigkeit wird die Erkennung durch den TSOP aber rapide schlechter ...Vermutlich meint mic dieses Posting, Punkt 11). (https://www.roboternetz.de/community/threads/33984-Abstandsmessung-ähnlich-wie-IR-Schnittstelle-des-asuro?p=326640&viewfull=1#post326640) Ziel dort war aber die Menge des reflektierten Lichts quantitativ zu bestimmen mit nem SFH5110 - der ähnliche Arbeit macht wie der TSOP. Damals hatte ich die Frequenz verstellt, heute mache ich das bei der optimalen Frequenz und wobbel den duty cycle. Insgesamt ist meine Erfahrung, dass die von der Entwurfsfrequenz des Empfängers abweichende Modulation zu nicht wirklich quantifizierbaren Beeinträchtigungen des IR-Empfängers führt.
... Durch Reflexionen im Raum wird die Ortung der IR-Bake unmöglich ...Stimmt, ausserdem sehe die Gleichmässigkeit des Strahls über einen größeren Winkelbereich als Illusion an. Nichts ohne "aber": aber es ist der Unterschied eines direkten Strahls zur Reflexion schon ziemlich deutlich. Ich würde mich trotzdem, egal aus welchen hier angeführten Gründen, nicht auf eine Bake ohne "Zutaten" verlassen. Mit Zutaten meine ich z.B. die Lösung in einer Art Transponder, gekoppelt mit einem rotierenden Signalstrahl, wo die Zeit zwischen Funksignal (=> Lichtsignal startet bei "Winkel 0") und Lichtdetektion eine Winkelinformation gäbe.
ich habe jetzt das problem, dass das register 30 immer mit dem wert 004 ausgegeben wird. Habe alle änderungen rückgängig gemacht, dann wurde natürlich der wert des registers 30 nicht ausgegeben.
nach dem erneuten ändern des slave programms und des ausführenden programms in der m32 wird das reg 30 wieder sofort mit 004 ausgegeben, auch wenn die bake nicht mal in der nähe des RP6 ist!
wie werden die register behandelt, sind sie einmal definiert bleiben sie vorhanden? Auch mit dem wert? Werden irgendwo alle werte der register gelöscht? Das passiert evtl auch, nur nicht für das reg 30? Oder muss ich es im programm immer wieder auf 0 setzetn?
Hi,
wird das reg 30 wieder sofort mit 004 ausgegeben, auch wenn die bake nicht mal in der nähe des RP6 ist!
Das ist ja auch richtig so.
hi,
danke fürs aufwecken...
ich experimentiere jetzt mit verschiedenen varianten von bauteilen...
Um zu vermeiden, dass die IR-LEDs zu warm werden, möchte ich die IR schaltung jeweils für 1 sec einschalten und für zwei sec ausschalten, also quasi eine blinkschaltung, mit der die versorgungsspannung der bake an- und ausgeschaltet werden soll. Dieses etwa... (http://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=9&ved=0CFsQtwIwCA&url=http%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeR2 7OE7huV4&ei=XoCfUqT8E4ictAau0YGACA&usg=AFQjCNEf1G2JONJi-CESik3A8MDW9hXcfg&bvm=bv.57155469,d.Yms&cad=rja)
nur wo bringe ich die anschlüsse des blinkers, an denen die LED angeschlossen ist, an die schaltung der bake an?
26859
oder gibt es einfachere möglichkeiten?
Hi inka,
wenn die 2. Blinkschaltung auch einen Ausgangstreiber (NPN in Emitterschaltung, so wie der Q1 deiner jetzigen Schaltung) hat, kann sein Collector an die Basis von Q1. Wenn er dann durchgeschaltet wird, zieht er die Basis von Q1 gegen GND und die LEDs leuchten nicht mehr. Sperrt er, dann blinken die LEDs wieder mit 36 kHz.
Wenn man die LEDs mal komplexer modulieren will, sollte man eher an einen kleinen µC (anstelle des NE555) denken, mit dem man dann (fast) jede Impulsform (auch RC5) hinkriegt.
Um Leistung (an Q1) zu sparen und die IR-Reichweite zu erhöhen, gäbe es noch das:
1. Nicht jede LED einzeln mit Vorwiderstand betreiben, sondern je 2 in Reihe. Das halbiert schon mal die Leistung.
2. Q1 durch einen MOSFet ersetzen.
3. LEDs in eine Innenreflektor-Fassung setzen ("Scheinwerfer").
4. LEDs mit engem Öffnungswinkel nehmen (10°).
5. LEDs nicht zu stark gefächert anbringen, sondern gebündelt parallel ausrichten (z.B. mithilfe einer IR Karte (http://www.conrad.de/ce/de/product/120168/Universal-IR-Card-Burosch-IR-CARD-Sensorflaeche-20-x-10-mm)).
6. Als Lichtfarbe 940..950 nm nehmen (da hat der Empfänger auf dem RP6 die höchste Empfindlichkeit).
7. Hoch leistungsfähige IR-LEDs nehmen (teuer!).
Hi Dirk,
es gibt neuigkeiten:
- ich habe einige bauteile "gesockelt" um flexibler beim beuteiletausch zu sein
- reflektoren an den IR dioden angebracht
26875
und eine zweite platine "huckepack" , steckbar draufgesetzt mit einer zweiten blinkschaltung, die die IR bake ein und ausschaltet:
26876
mit den beiden potis kann ich fast beliebige schaltintervalle einstellen...
26877
26878
allein durch die reflektoren und das "blinken" der IR-LEDs ist jetzt die reichweite bis auf ca. einen meter gestiegen...
Nächste woche werde ich andere vorwiderstände an den dioden testen und andere transistoren...
Hi inka,
du bist ja wirklich hartnäckig da dran!
Wenn ich dein Projekt von Anfang an sehe, dann könnte/sollte daraus sicher mal ein RN-Wissen-Artikel werden.
hi Dirk,
zielstrebig ja, ich will ja schließlich eine ladestation - die auch gefunden wird - bauen...
schon wieder taucht eine frage auf:
ich dachte, ich könnte auf die gleiche art und weise die frequenz der zweiten schaltung (blinker) messen wie bei der ersten - zwischen dem anschluss 3 des zweiten ne555 und zwischen masse. Dort kann ich aber nur sehen wie die spannung zwischen 2 und 4 volt wechselt, kann ich so nicht die blinkfrequenz sehen und einstellen?
Hi inka,
Dort kann ich aber nur sehen wie die spannung zwischen 2 und 4 volt wechselt, kann ich so nicht die blinkfrequenz sehen und einstellen?
Dem Oszilloskop ist die Höhe der Spannung ja egal. Da müßtest du doch die Frequenz messen können.
Für die Verbindung mit der 1. Schaltung würde ich aber noch einen Transistor-Treiber (wie Q1 in der 1. Schaltung) dranbauen. Da der Transistor nicht viel leisten muss, genügt ein NPN-Universaltyp.
hi Dirk,
am kontakt 3 des blinker-NE555 habe ich über einen basiswiderstand einen NPN transistor, zu sehen im bild DSCI2529-1...
von der unteren (grünen) platine zapfe ich nur die versorgungsspannung ab und vom collector des treibertransistors (blinker) gehe ich an die basis des NPN transistors der die IR-Dionen (auf der grünen platine) ansteuert...
hallo,
habe jetzt die ganze schaltung gezeichnet:
26915
26912
kann man hier auch pdf als bild (und nicht als anhang) hochladen?
ich habe auch ein paar fotos:
2691326914
der zweiter USB-stecker war notwendig, weil beim neuen netzteil (zwei USB-ausgänge, weil ja auch die ladestation von dort versorgt werden soll) die orientierung des USB-steckers anders war, die dioden hätten gegen die wand gesendet :-(
das ganze funktioniert jetzt auf die entfernung von einem meter. Immer noch viel zu wenig und gefühlt mehr oder weniger vom zufall abhängig, ob der RP6 empfängt, oder nicht.
die blinkfrequenz kann ich "nach dem gefühl" auf ca. 2x/sec, 5x/sec und 10x/sec einstellen, das wäre jetzt erstmal genau genug, es geht mir ja hier nur darum, dass die IR-dioden ein bischen abkühlen können und ich den strom, der dort durchfließt erhöhen kann. Die vorwiderstände sind momentan 22 ohm und - da ich das schlecht messen kann - gefühlt ist die "lichtleistung" der blinkenden IR-dioden (in einer kamera beabachtet) dreimal so hoch, als mit den 47 ohm...
die abfrage (und die ausgabe im LCD display) des empfangs wird durch den aufruf dieser funktion in der main-schleife realisiert:
void read_IR_value(void)
{
I2CTWI_transmitByte(I2C_RP6_BASE_ADR, 30); // Start with register 30
I2CTWI_readBytes(I2C_RP6_BASE_ADR, ir_value, 1);
clearLCD();
setCursorPosLCD(0, 2);
writeStringLCD_P("pb2_value: ");
setCursorPosLCD(0, 13);
writeIntegerLengthLCD(ir_value[0], DEC, 4);
setCursorPosLCD(2, 1);
writeStringLCD_P("0000 = IR bake OK");
// setCursorPosLCD(2, 2);
// writeIntegerLengthLCD(ir_value[0], DEC, 4);
}
die ausgabe übers display ist m.e. nach viel zu langsam. Ich glaube auch, dass der sender und der RP6 sich gegenseitig austricksen, weil wenn der einer sendet, empfängt der andere gerade nicht und umgekehrt. Ich möchte folgenermassen vorgehen:
der IR- empfänger "füllt" ein array von der größe von 30-50 bytes(?) in seiner eigenen geschwindigkeit und überschreibt die werte wenn der platz voll ist. Die abfragefunktion sollte auf das array zugreifen und den inhalt auswerten. Das kann durchaus langsammer als das empfangen der IR-signale geschehen. Wenn die abfrage - das ist jetzt einfach nur eine hausnummer - 10 "ok" zeichen hintereinander als bestätigung eines IR-empfangs findet macht der RP6 irgendwas. Blebt stehen, piepst die ode an die freude oder was auch immer...
wie gehe ich das jetzt an? Mit arrays habe ich noch nichts gemacht :-(
hallo inka,
das schaut sehr gut aus. Danke für Deine Arbeit.
Ich wollte mir eben den Schaltplan anschauen und fand dort kein Dokument. Weißt Du, woran das liegen könnte?
Danke und Gruß
jetzt müsste das mit dem schaltplan gehen...
Hi inka,
Ich glaube auch, dass der sender und der RP6 sich gegenseitig austricksen, weil wenn der einer sendet, empfängt der andere gerade nicht und umgekehrt.
Die direkte Abfrage von PB2 beißt sich auf jeden Fall mit dem ACS. Das sollte also nicht parallel genutzt werden.
Wenn die abfrage - das ist jetzt einfach nur eine hausnummer - 10 "ok" zeichen hintereinander als bestätigung eines IR-empfangs findet macht der RP6 irgendwas. Blebt stehen, piepst die ode an die freude oder was auch immer...
Wenn man sich z.B. vorstellt, dass sich der RP6 am Anfang der Suche zwecks Orientierung auf der Stelle dreht, dann könnte man parallel die Positionen "merken", bei denen er die Bake erkennt. Er würde sich dann zur gemittelten Bakenposition drehen und losfahren. Auf dem Weg könnte er sich noch ein paarmal durch kleinere Rechts-/Links-Drehungen zur Bake ausrichten.
Anforderungen:
1. Der IR-Empfänger müßte in einer Röhre sitzen wegen der nötigen Richtwirkung.
2. Es muss einen erkennbaren Zusammenhang zwischen der gemittelten Bakenposition und der "Drehposition" des RP6 geben, damit er in die richtige Richtung fahren kann. Wenn man nicht rein nach Versuch und Irrtum vorgehen will, braucht man evtl. einen Kompasssensor oder Gyro.
3. Es macht wenig Sinn, einen sehr breiten IR-Licht-Fächer im Raum zu haben (so dass er fast den ganzen Raum füllt), sondern ein schmaleres IR-Licht-Feld wäre wohl besser.
4. ... das gibt's bestimmt noch was, aber mehr fällt mir jetzt nicht ein ...
hi Dirk,
wieder ein paar tests gemacht:
die vorwiderstände auf 10 ohm verringert, die blinkfrequenz der bake auf ca. 1/sec eingestellt und bei der abfrage im RP6 es so eingerichtet, dass er keine pausen beim messen macht, die reichweite ist nun bei 2m! Ansonsten die erfahrungen im text:
Die direkte Abfrage von PB2 beißt sich auf jeden Fall mit dem ACS. Das sollte also nicht parallel genutzt werden.
klar, läuft auch nicht mit...
1. Der IR-Empfänger müßte in einer Röhre sitzen wegen der nötigen Richtwirkung.
die 5 IR-dioden sind ja in einer art kranz, bzw. halbkreis mit lücken angeordnet. Bereits bei einer entfernung von 2 metern reicht eine sehr kleine verdrehung des RP6 (1 - 2 °) um das IR signal der empfangenen diode zu verlieren...
2. Es muss einen erkennbaren Zusammenhang zwischen der gemittelten Bakenposition und der "Drehposition" des RP6 geben, damit er in die richtige Richtung fahren kann. Wenn man nicht rein nach Versuch und Irrtum vorgehen will, braucht man evtl. einen Kompasssensor oder Gyro.
bei zwischenmessungen auf dem weg zu der bake verringert sich ja die entfernung, das signal wird besser, aber evtl. hast du recht...
3. Es macht wenig Sinn, einen sehr breiten IR-Licht-Fächer im Raum zu haben (so dass er fast den ganzen Raum füllt), sondern ein schmaleres IR-Licht-Feld wäre wohl besser. der fächer ist ja in vertikaler richtung ziemlich flach, und es ist in horizontaler richtung kein geschlossener kreis/halbkreis, die lücken zwischen den einzelnen IR-kegeln werden ja mit der entfernung zwischen sender und empfänger immer größer...
Ich habe noch verschiedene temperaturen gemessen:
die 10 ohm vorwiderstände - 55°
die IR-dioden selbst - 36°
der Q2 - 89°, mit kühlkörper (siehe foto) immer noch 60°
26923
ich habe beobachtet, dass, wenn die bake länger blinkt die leistung nachlässt, das signal wird offensichtlich mit wärmer werden des 2N222 immer schlechter. Durch welchen transistor könnte ich den ersetzen?
hallo,
inzwischen bin ich durch die verkleinerung des basiswiderstandes R13 von 4,7k auf 3,2k auf einer reichweite der bake von 3 metern angekommen, wohlgemerkt bei (noch) auf niedrigerer temperatur arbeitendem Q2, nach ca. 1 minute wird es schlechter...
jetzt möchte ich außer der reaktion auf dem LCD eine andere reaktion sehen und es klappt nicht:
mit dem aufruf dieser Funktion aus der while schleife (siehe weiter unten):
void read_IR_value(void)
{
I2CTWI_transmitByte(I2C_RP6_BASE_ADR, 30); // Start with register 30
I2CTWI_readBytes(I2C_RP6_BASE_ADR, ir_value, 1);
}
while-schleife:
while(true)
{
read_IR_value();
clearLCD();
setCursorPosLCD(0, 0);
writeStringLCD_P("dez: ");
setCursorPosLCD(0, 13);
writeIntegerLengthLCD(ir_value[0], DEC, 4);
setCursorPosLCD(1, 0);
writeStringLCD_P("bin: ");
setCursorPosLCD(1, 8);
writeIntegerLengthLCD(ir_value[0], BIN, 8);
setCursorPosLCD(2, 0);
writeStringLCD_P("hex: ");
setCursorPosLCD(2, 8);
writeIntegerLengthLCD(ir_value[0], HEX, 4);
/*
if (ir_value[0] = 0)
{
sound(180,80,25);
setLEDs(0b1000);
sound(220,80,25);
mSleep(500);
}
*/
readAllRegisters();
}
return 0;
werden die werte der variablen "ir_value", also 0 oder 4 je nachdem ob bake "gesehen" wird oder nicht auf dem LCD ausgegeben.
die if abfrage (hier auskommentiert) der variablen "ir_value" habe ich (bei abgeschalteter bake) mit den werten 1 bis 4 probeweise ausgeführt, die reaktion erfolgt richtig, es piepst. Frage ich nach dem wert "0", passiert nichts, auch bei eingeschalteter bake und auf dem display erscheinendem wert "0"
ich verstehe es einfach nicht. Frage ich die falsche variable ab? Oder nach falschen werten? Oder sind die abfrageabstände zu kurz? kann der beeper nicht so schnell reagieren?
Hi inka,
3 Sachen:
1. Die Abfrage if (ir_value[0] = 0) ergibt nie das gewünschte Ergebnis, aber if (ir_value[0] == 0) würde helfen.
2. Die Abfragefrequenz sollte man auch reduzieren, z.B. mit einer Stopwatch. 250 bis 500ms sind sicher ausreichend. Immerhin muss auch noch die I2C-Kommunikation zwischen RP6 und M32 erfolgen: Das braucht Zeit.
3. ir_value[0] ist ein Feld-Variable. Wo wird die gefüllt?
hi Dirk,
zumindest der punkt 1 hätte mir auffallen müssen...- jetzt reagiert die abfrage auf das empfangen des IR-signals...
die verzögerung habe ich mit "mSleep(500)" gemacht , das ist wohl blockierend - wenn ich es richtig in erinnerung habe - stört das hier?
3. ir_value[0] ist ein Feld-Variable. Wo wird die gefüllt?
oh, ich dachte das passiert hier:?
void read_IR_value(void)
{
I2CTWI_transmitByte(I2C_RP6_BASE_ADR, 30); // Start with register 30
I2CTWI_readBytes(I2C_RP6_BASE_ADR, ir_value, 1);
}
ist das nicht so?
ansonsten ist sie in der programmdatei so:
uint8_t ir_value[1];
deklariert...
Hi,
mSleep() ist leider blockierend.
Besser sind die Stopwatches, siehe Anleitung des RP6, 4.6.3. Delay Funktionen (...), Überschrift "Stopwatches". Da ist auch ein Beispiel mit 2 Stopwatches.
Die Feldvariable, die als uint8_t ir_value[1] deklariert ist, enthält letztlich nur EINE Variable, die heißt ir_value[0].
So muss man sie auch ansprechen.
Die beiden Variablen ir_value und ir_value[0] sind nicht identisch.
Hi Dirk,
Die Feldvariable, die als uint8_t ir_value[1] deklariert ist, enthält letztlich nur EINE Variable, die heißt ir_value[0].
So muss man sie auch ansprechen.
Die beiden Variablen ir_value und ir_value[0] sind nicht identisch.
das muss ich erstmal verarbeiten (und verstehen)...
in meinem programm (die basis war das "Example_06_I2CMaster") ist z.b:
// Read all registers function
uint8_t RP6data[32]; // This array will contain all register values of RP6
// after you called readAllRegisters()
// It is better to keep such big arrays GLOBAL as
// they otherwise fill up the stack in memory...
/**
* This function reads ALL registers available in the standard I2C Bus Slave
* Example program for the Robot Base and outputs their values on the serial interface.
* You will see a lot of zeros when the Motors are not running. The main values that are not
* zero are the two Light Sensors and the two free ADC Channels.
*/
void readAllRegisters(void)
{
I2CTWI_transmitByte(I2C_RP6_BASE_ADR, 0); // Start with register 0...
I2CTWI_readBytes(I2C_RP6_BASE_ADR,RP6data, 30); // and read all 30 registers up to
// register Number 29 !
// Now we output the Data we have just read on the serial interface:
writeString_P("\nREADING ALL RP6 REGISTERS:");
uint8_t i = 0;
for(i = 0; i < 30; i++)
{
if(i % 8 == 0) // add some newline chars otherwise everything
writeChar('\n'); // is printed on ONE single line...
else
writeString_P(" | ");
writeChar('#');
writeIntegerLength(i,DEC,2);
writeChar(':');
writeIntegerLength(RP6data[i],DEC,3);
}
writeChar('\n');
}
die variable (array) "uint8_t RP6data[32]", die auch so definiert wird und dann in der zeile:
I2CTWI_readBytes(I2C_RP6_BASE_ADR,RP6data, 30);
auch als RP6data beschrieben/gefüllt wird...
aber wie gesagt, das muss ich erstmal verstanden haben...
ein kleiner erfolg auf dem weg zu einer funktionierenden bake:
es ist mir gelungen mit der einstellung an den beiden potis des blinkers und an der mSleep-verzögerung im programm das so einzustellen, dass über einen längeren zeitraum einmal pro sekunde das IRsignal gesendet UND auch vom RP6 empfangen wird. Ohne aussetzer, das war bisher nicht der fall, war mehr oder weniger zufällig, wenns mal geklapt hat, zumindest nicht so regelmäßig..
Hi inka,
die variable (array) "uint8_t RP6data[32]", die auch so definiert wird und dann in der zeile:
I2CTWI_readBytes(I2C_RP6_BASE_ADR,RP6data, 30);
auch als RP6data beschrieben/gefüllt wird...
aber wie gesagt, das muss ich erstmal verstanden haben...
Das ist ja eine Funktion aus der RP6I2CmasterTWI-Library.
Im Header der Lib ist die Funktion als Prototyp so deklariert:
void I2CTWI_readBytes(uint8_t targetAdr, uint8_t * messageBuffer, uint8_t numberOfBytes);
Das heißt: Als 2. Parameter wird der messageBuffer als Adresse (im Speicher, also nicht als Wert) übergeben. In der Lib besteht der messageBuffer aus der Feldvariablen RP6data, so dass man die Funktion so aufrufen kann, wie du oben angeführt hast. Das geht so aber nur, wenn RP6data in der Parameterliste einer Funktion auftaucht.
Grundsätzlich würde ich einer einzelnen Variablen nicht den Namen einer Feldvariable geben, dann bleibt's übersichtlich.
Für dein Programm:
Ich würde die read_IR_value() Funktion so ändern:
uint8_t read_IR_value(void)
{ uint8_t temp;
I2CTWI_transmitByte(I2C_RP6_BASE_ADR, 30); // Start with register 30
I2CTWI_readBytes(I2C_RP6_BASE_ADR, temp, 1);
return temp;
}
Die Funktion hat dadurch einen Byte-Rückgabewert und wird so aufgerufen: Wert = read_IR_value();
Wenn du diese Werte dann in eine Feldvariable übernehmen willst:
i = 0;
// Schleife:
ir_value[i] = read_IR_value();
i++;
Wenn du diese zwei Zeilen mehrfach aufrufst (z.B. in einer Schleife), wird dein Wert (IR-Empfang ja oder nein) nacheinander in die Feldvariable ir_value gepackt.
Du must natürlich dafür sorgen, das sie ausreichend dimensioniert ist und i also nicht zu hoch wird.
ein kleiner erfolg auf dem weg zu einer funktionierenden bake
Klingt gut! :)
Hi,
mit den änderungen
case 2://
setLEDs(0b0010);
writeString_P("\n\n messung feldvariable\n");
initRP6Control();
initLCD();
while(true)
{
// rotate (20, RIGHT, 3, false);
// read_IR_value();
uint8_t i = 0;
for(i = 0; i < 499; i++)
{
temp_IR[i] = read_IR_value();
feld_IR[i] = temp_IR[i];
// feld_IR[i] = read_IR_value();
writeIntegerLength(temp_IR[i],DEC,4);
if(i % 7 == 0)
writeChar('\n');
else
writeString_P(" | ");
mSleep(100);
// move(50, FWD, DIST_MM(100), false);
}
clearLCD();
setCursorPosLCD(0, 0);
writeStringLCD_P("bin: ");
setCursorPosLCD(0, 8);
writeIntegerLengthLCD(temp_IR[0], BIN, 8);
mSleep(300);
setMultiIOLED3(0);
readAllRegisters();
mSleep(100);
/**************************/
uint8_t key_1 = getMultiIOPressedButtonNumber();
key_1 = getMultiIOPressedButtonNumber();
if(key_1 != 0) break;
/**************************/
}
break;
konnte ich nun herausfinden, wie oft, bzw. mit welchem muster meine IR-bake sendet - und empfangen wird. Hier ein teilinhalt der feldvariablen "uint8_t feld_IR[500]" :
27136
es ist folgendes muster, welches empfangen wird:
4x nichts / treffer / 3x nichts / treffer / 4x nichts / treffer usw, usw...
ich nehme an, dass der IR empfänger nicht dauernd empfängt, sondern in einem bestimmten rhythmus. Das würde evtl. erklären warum die optische anzeige (LED)
case 1://
setLEDs(0b0001);
writeString_P("\n\n messung einzelsignal\n");
initRP6Control();
initLCD();
// ---------------------------------------
WDT_setRequestHandler(watchDogRequest);
/************************************************** ***********/
while(true)
{
// rotate (20, RIGHT, 3, false);
temp = read_IR_value();
mSleep(100);
if (temp == 0)
{
setMultiIOLED3(1);
mSleep(100);
setMultiIOLED3(0);
// move(50, FWD, DIST_MM(100), false);
}
clearLCD();
setCursorPosLCD(0, 0);
writeStringLCD_P("dec: ");
setCursorPosLCD(0, 8);
writeIntegerLengthLCD(temp, DEC, 1);
mSleep(300);
// setMultiIOLED3(0);
readAllRegisters();
mSleep(100);
/**************************/
uint8_t key_1 = getMultiIOPressedButtonNumber();
key_1 = getMultiIOPressedButtonNumber();
if(key_1 != 0) break;
/**************************/
}
break;
zwar funktioniert (reaktion auf einzelne empfangene IR-signale), aber in wesentlich unregelmäßigen abständen als dieses 3 - 1 - 4 - 1 - 3 - 1 - 4 - 1 -...
Diesen rhythmuss möchte ich beibehalten, er scheint mir insofern günstig, weil man mit diesem rhythmus die IR-bake identifizieren könnte...
es beschäftigen mich nun folgende fragen:
- wie finde ich den IR-empfangsrhythmus des RP6 raus?
- Ist er irgendwo angegeben, muss ich ihn irgendwie berechnen/messen (stopwatches?)?
- wie passe ich die beiden frequenzen aneinander an?
für ideen und tipps bin ich wie immer dankbar...
Hi inka,
da bist du ja schon etwas weiter gekommen!
Diesen rhythmuss möchte ich beibehalten, er scheint mir insofern günstig, weil man mit diesem rhythmus die IR-bake identifizieren könnte...
Tatsächlich könnte man Baken mit unterschiedlicher Modulationsfrequenz so erkennen.
Dein Ausdruck der Werte scheint zu sagen, dass die Bake in regelmäßigen Abständen erkannt wird, wobei die AN-Phase nur kurz (1-3 Werte) erscheint und die AUS-Phase wohl etwa 4x so lang ist. Halt mal das Oszilloskop an den Treiber der Bake, um zu sehen, ob das so etwa auch gesendet wird (AN-AUS = 1-4).
Der "Leserhythmus" des IR-Signals wird im Wesentlichen bestimmt durch die zeitliche Länge der for(i = 0; i < 499; i++) - Schleife. Darin gibt es einerseits die feste Pause von 100ms (mSleep(100); ), dann die Zeit, die die UART-Ausgabe der Werte (writeIntegerLength(...) u.a.) braucht und die Zeit für die I2C-Kommunikation in der IR-Lesefunktion (read_IR_value(); ).
Messen kann man die Zyklusdauer der Schleife z.B. mit den Stopwatches:
1. Starten am Programmanfang mit: startStopwatch1();
2. Variable definieren: uint16_t zeitdauer;
3. Zurücksetzen auf 0 am Anfang der for(i = 0; i < 499; i++) - Schleife: if (i==498 ) setStopwatch1(0);
4. Lesen des Stopwatch Werts mit: if (i==498 ) zeitdauer = getStopwatch1(); am Ende der Schleife
5. Nach der Schleife den Wert von zeitdauer ausgeben.
Damit wird im letzten Schleifendurchlauf die Dauer in Millisekunden gemessen. Man kann das dann in die Frequenz umrechnen.
hi Dirk,
den "rest" dann in aller ruhe, zunächst zu der interpretation der IR-logdatei:
Dein Ausdruck der Werte scheint zu sagen, dass die Bake in regelmäßigen Abständen erkannt wird, wobei die AN-Phase nur kurz (1-3 Werte) erscheint und die AUS-Phase wohl etwa 4x so lang ist. Halt mal das Oszilloskop an den Treiber der Bake, um zu sehen, ob das so etwa auch gesendet wird (AN-AUS = 1-4).
das mit derm oszi funktioniert nicht, ich sehe bei allen möglichen einstellungen nur einen waagerechten strich, der seine lage im blinkinterwall der bake rauf und runter ändert, bekomme also keine darstellung der abwechselnden phasen in waagerechetn richtung aneinander gereiht, keine ahnung warum...
nun zu der logdatei:
ich würde die AN/AUS phasen anders interpretieren:
0004 bedeute kein signal
0000 bedeutet signal empfangen
in der reienfolge aus dem bild ist es dann doch so:
aus aus aus aus an aus aus aus an aus aus aus aus an aus aus aus an .............
also hätte die AN-phase jeweils nur ein wert und die AUS-phase abwechselnd 3 oder 4 werte. oder sehe ich da was falsch?
Hi,
also hätte die AN-phase jeweils nur ein wert und die AUS-phase abwechselnd 3 oder 4 werte. oder sehe ich da was falsch?
Ne, habe ich genau so gesehen. S.o.!
hi Dirk,
Die 4 in Register 30 ist ok:
Wenn kein IR-Signal anliegt, hat der Empfänger High-Pegel, daher ist deine Variable pb2_value binär = 0b00000100 (dezimal 4), das heißt, dass PINB2 (also Bit 2) gesetzt ist.
Wenn ein IR-Signal anliegt, ist das Bit nicht gesetzt, also Register 30 = 0.
frage zu diesem PINB2:
bleibt der nach dem empfang des IR-signals low und wird beim nächsten empfang wieder auf high gesetzt, oder bleibt er low nur solange IR-signal empfangen wird?
Hi,
... oder bleibt er low nur solange IR-signal empfangen wird?
Genau so.
hi,
nun habe ich mir das leben etwas einfacher gemacht, mit diesem
while(true)
{
for(j = 0; j < 120; j+=10)
{
writeChar('\n');
writeInteger(j, DEC);
writeChar('\n');
uint8_t i = 0;
for(i = 0; i < 199; i++)
{
temp_IR[i] = read_IR_value();
feld_IR[i] = temp_IR[i];
writeIntegerLength(temp_IR[i],DEC,4);
if(i % 12 == 0)
writeChar('\n');
else
writeString_P(" | ");
mSleep(20+j);
}
}
/**************************/
uint8_t key_1 = getMultiIOPressedButtonNumber();
key_1 = getMultiIOPressedButtonNumber();
if(key_1 != 0) break;
/**************************/
}
gewann ich "auf einen rutsch" diese ausgabe:
271712717227173
es hätte sicher mehrere auswahlmöglichkeiten für die größe des "mSleep" gegeben, ich habe mich für die variante 50 entschieden - die gefiel mir in ihrer regelmäßigkeit am besten - jetzt blinkt die kontroll-LED auf der bake mit diesem
while(true)
{
temp = read_IR_value();
mSleep(50);
if (temp == 0)
{
setMultiIOLED3(1);
setMultiIOLED3(0);
}
/**************************/
uint8_t key_1 = getMultiIOPressedButtonNumber();
key_1 = getMultiIOPressedButtonNumber();
if(key_1 != 0) break;
/**************************/
}
deckungsgleich - ca. 4x pro sekunde - zusammen mit der roten LED an der multiIO auf eine entfernung von 4m... :-)
hi,
jetzt habe ich versucht die abfrageschleife mit dem mSleep(50) verzögerung durch eine mit stopwatches zu ersetzen:
while(true) //start endlosschleife
startStopwatch1(); // start stopwatches
{
if(getStopwatch1() > 100) // messe IR empfang wenn 100ms abgelaufen sind
{
temp = read_IR_value(); //einlesen IR-empfang
// mSleep(50);
if (temp == 0) //abfrage treffer/empfang
{
setMultiIOLED3(1); //LED an
setMultiIOLED3(0); //LED aus
setStopwatch1(0); //stopwatches auf null stellen
}
}
/**************************/
uint8_t key_1 = getMultiIOPressedButtonNumber(); //tastenabfrage
key_1 = getMultiIOPressedButtonNumber();
if(key_1 != 0) break;
/**************************/
}
break;
die signale der bake werden offensichtlich nicht empfangen, die LED reagiert nicht...
muss ich die dauer der einzelnen funktionen in der whileschleife kennen, oder gibt es eine andere möglichkeit (außer try & error) herauszufinden warum der zeitpunkt der 100ms (aber auch bei 50ms geht es nicht) falsch ist?
Hi,
Kommentare im Codeblock!
while(true) //start endlosschleife
startStopwatch1(); // start stopwatches <== Das gehört VOR die while(true) Schleife
{
if(getStopwatch1() > 100) // messe IR empfang wenn 100ms abgelaufen sind
{
temp = read_IR_value(); //einlesen IR-empfang
// mSleep(50);
if (temp == 0) //abfrage treffer/empfang
{
setMultiIOLED3(1); //LED an
setMultiIOLED3(0); //LED aus
setStopwatch1(0); //stopwatches auf null stellen <== Gehört ans Ende der if(getStopwatch1() > 100) Klammer, siehe <<<>>> !
}
// <<<>>>
}
/**************************/
uint8_t key_1 = getMultiIOPressedButtonNumber(); //tastenabfrage
key_1 = getMultiIOPressedButtonNumber();
if(key_1 != 0) break;
/**************************/
}
break;
Hi Dirk,
danke für die korrekturen, es funktioniert nun...
Würde für mein verstzändnis der stopwatches bedeuten, dass man diese an einer beliebigen stelle im vorderen bereich des programmes startet (einmal) und dann im ersten durchlauf der while(true) schleife auf null stellt und dann im zweiten durchlauf den Ir-empfang prüft...
zwei dinge haben sich jetzt herausgestellt:
1) die probleme beim empfang der von der bake gesendeten signale gründeten nicht in der zu kleinen leistung der IR-LEDs, sondern in der schlechten koordination des senders mit dem empfänger. Ich habe jetzt die vorwiderstände der IR-dioden wieder auf 47 ohm erhöht, der empfang funktioniert nach wie vor über ca. 4 meter.
Im gegenteil: Ich habe nun beim erkennen der richtung aus der die IR-strahlen kommen probleme mit reflektionen, auch über zwei "ecken"! Der bereich um die 5cm über dem boden ist quasi IR-verseucht...
Da muss ich mir noch etwas einfallen lassen (bündeln des sendestrahls und einengen des empfangskorridors)...
2) hat zwar mit der IR-bake nur am rande zu tun, ein problem ist es aber:
das starten der vier teilprogramme über die 4 multiIO taster.
zwischen diesem
------------------------------------------
clearLCD();
pressedMultiIOButtonNumber = getMultiIOPressedButtonNumber();
setCursorPosLCD(0, 0);
writeStringLCD("1: test_einzelsignal");
setCursorPosLCD(1, 0);
writeStringLCD("2: test_feldvariable");
setCursorPosLCD(2, 0);
writeStringLCD("3: suche der bake");
setCursorPosLCD(3, 0);
writeStringLCD("4: test_button_4");
mSleep(1500);
uint8_t key = getMultiIOPressedButtonNumber();
----------------------------------------------
und diesem
-------------------------------------------------
uint8_t key_1 = getMultiIOPressedButtonNumber(); //tastenabfrage
key_1 = getMultiIOPressedButtonNumber();
if(key_1 != 0) break;
---------------------------------------------
liegen jeweils die vier programmteile. Die software reagiert sehr eigenartig auf das drücken der buttons: mal garnicht, mal mit kurzem start mit sofort erfolgtem break, mal richtig. Wie könnte ich da was verbessern? Verzögerungen in der tastenabfrage z.b.?
ich habe hier wegen der besseren verständlichkeit meiner frage bzw. meines problems den code einer schablobe für die abfrage der vier tasten eingefügt (obwohl das problem hier kaum auftritt) - hängt das mit der dauer des programms, welches ausgeführt wird zusammen?
btw: die korrekturwerte für die taster sind in der RP6Control_MultiIO.h eingetragen...
#include "RP6ControlLib.h"
#include "RP6I2CmasterTWI.h"
#include "RP6Control_MultiIOLib.h"
#include "RP6Control_I2CMasterLib.h"
#include "RP6ControlServoLib.h"
#include "standard.h"
#define I2C_RP6_BASE_ADR 10
/*********************I2C-fehlermeldungen******************/
/*
void I2C_transmissionError(uint8_t errorState) //gibt I2C fehlermeldungen über LCD aus
{
clearLCD();
writeStringLCD_P("I2C ERROR -->");
setCursorPosLCD(1, 0); // line 2
writeStringLCD_P("TWI STATE: 0x");
writeIntegerLCD(errorState, HEX);
}
*/
/*************** hauptprogramm ***********/
int main(void)
{
initRP6Control();
multiio_init();
initLCD();
//orientation_init();
setLEDs(0b1111);
mSleep(500);
setLEDs(0b0000);
I2CTWI_initMaster(100);
I2CTWI_setTransmissionErrorHandler(I2C_transmissio nError); //aktiviert I2C fehlermeldungen
showScreenLCD(" RP6Control M32", " schablone", " 4 taster " , " mit ruecksprung ");
mSleep(2500);
clearLCD();
while(true)
{
/*****************anzeige gedrückter buttons****************/
// clearLCD();
// accuspannung();
// mSleep(500);
clearLCD();
pressedMultiIOButtonNumber = getMultiIOPressedButtonNumber();
// setCursorPosLCD(0, 0);
// writeStringLCD("Button: ");
// writeIntegerLCD(pressedMultiIOButtonNumber, DEC);
setCursorPosLCD(0, 0);
writeStringLCD("1 - button_1_test");
setCursorPosLCD(1, 0);
writeStringLCD("2 - button_2_test");
setCursorPosLCD(2, 0);
writeStringLCD("3 - button_3_test");
setCursorPosLCD(3, 0);
writeStringLCD("4 - button_4_test");
mSleep(1500);
uint8_t key = getMultiIOPressedButtonNumber();
/********************funktion der buttons*********************/
if(key)
{
switch(key)
{
case 1://
setLEDs(0b0001);
while(true)
{
uint8_t key_1 = getMultiIOPressedButtonNumber();
clearLCD();
setCursorPosLCD(0, 0);
writeStringLCD("test button 1 ");
mSleep(1500);
clearLCD();
writeStringLCD("test break all ");
mSleep(1500);
key_1 = getMultiIOPressedButtonNumber();
if(key_1 != 0) break;
}
break;
case 2://
setLEDs(0b0010);
while(true)
{
uint8_t key_1 = getMultiIOPressedButtonNumber();
clearLCD();
setCursorPosLCD(0, 0);
writeStringLCD("test button 2 ");
mSleep(1500);
clearLCD();
writeStringLCD("test break all ");
mSleep(1500);
key_1 = getMultiIOPressedButtonNumber();
if(key_1 != 0) break;
}
break;
case 3://
setLEDs(0b0100);
while(true)
{
uint8_t key_1 = getMultiIOPressedButtonNumber();
clearLCD();
setCursorPosLCD(0, 0);
writeStringLCD("test button 3 ");
mSleep(1500);
clearLCD();
writeStringLCD("test break all ");
mSleep(1500);
key_1 = getMultiIOPressedButtonNumber();
if(key_1 != 0) break;
}
break;
case 4://
setLEDs(0b1000);
while(true)
{
uint8_t key_1 = getMultiIOPressedButtonNumber();
clearLCD();
setCursorPosLCD(0, 0);
writeStringLCD("test button 4 ");
mSleep(1500);
clearLCD();
writeStringLCD("test break all ");
mSleep(1500);
key_1 = getMultiIOPressedButtonNumber();
if(key_1 != 0) break;
}
break;
}
}
}
return 0;
}
Hi,
Würde für mein verstzändnis der stopwatches bedeuten, dass man diese an einer beliebigen stelle im vorderen bereich des programmes startet (einmal) und dann im ersten durchlauf der while(true) schleife auf null stellt und dann im zweiten durchlauf den Ir-empfang prüft...
Ja... Das startStopwatchX(); brauchst du nur EINMAL am Programmanfang, d.h. später normalerweise nicht wieder.
Die Benutzung geht dann so:
if(getStopwatchX() > 100) // mach was alle 100ms
{
// Was alles zu tun ist ...
setStopwatchX(0); // Stopwatch auf Null stellen
}
Die software reagiert sehr eigenartig auf das drücken der buttons: mal garnicht, mal mit kurzem start mit sofort erfolgtem break, mal richtig. Wie könnte ich da was verbessern? Verzögerungen in der tastenabfrage z.b.?
Ich würde 2 Sachen ändern:
1. In der SWITCH-CASE-Struktur sieh dir die while(true) Schleifen an: Alle Pausen (mSleep) dort und im Bereich "anzeige gedrückter buttons" müssen raus,- d.h.: Die Haupt-while(true)-Schleife muss ohne Unterbrechungen/Pausen ablaufen. Wenn man Texte länger lesen soll, müßte man das auch mit einer weiteren Stopwatch machen.
2. Die Zeile uint8_t key_1 = getMultiIOPressedButtonNumber(); brauchst du nicht. Es reicht: uint8_t key_1; (Grund: Weiter unten wird die Taste ja wieder eingelesen: key_1 = getMultiIOPressedButtonNumber(); )
Hi Dirk,
Die Benutzung geht dann so:
if(getStopwatchX() > 100) // mach was alle 100ms
{
// Was alles zu tun ist ...
setStopwatchX(0); // Stopwatch auf Null stellen
}
macht das programm wirklich ALLE 100ms etwas oder immer dann wenns mal größer als 100ms ist? Also 101/102/105 - wanns gerade abgefragt wird? Ich glaube, wenn die funktionen im ablauf länger/komplizierter werden klappt es mit der abfrage nicht mehr so genau?
ich habe nun den zweiten abschnitt meines
case 2:
setLEDs(0b0010);
writeString_P("\n\n messung feldvariable\n\n");
writeChar('\n');
initRP6Control();
initLCD();
startStopwatch2();//neu
while(true)
{
uint8_t i = 0;
for(i = 0; i < 199; i++)
{
temp_IR[i] = read_IR_value();
feld_IR[i] = temp_IR[i];
if(getStopwatch2() > 50)//neu
{
writeIntegerLength(temp_IR[i],DEC,4);
if(i % 12 == 0)
{
writeChar('\n');
setStopwatch2(0);//neu
}
else
{
writeString_P(" | ");
setStopwatch2(0);//neu
}
// mSleep(50);//entfallen
}
}
/**************************/
uint8_t key_1;
key_1 = getMultiIOPressedButtonNumber();
if(key_1 != 0) break;
/**************************/
}
break;
durch die stopwatches ergänzt, es läuft im prinzip, aber eben nur im prinzip. Mit dem mSleep(50) war die ausgabe so:
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
mit stopwatches ist sie so:
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
der code raegiert nun williger auf den druck auf die buttons, kann ich die ausgabe regelmäßiger machen?
RoboHolIC
22.01.2014, 17:41
macht das programm wirklich ALLE 100ms etwas oder immer dann wenns mal größer als 100ms ist? Also 101/102/105 - wanns gerade abgefragt wird? Ich glaube, wenn die funktionen im ablauf länger/komplizierter werden klappt es mit der abfrage nicht mehr so genau?
Genau SO ist es, so steht es ja auch im Code, nämlich >100. Versuche ruhig mal "=100", dann wird es noch schlimmer werden!
Was in einem harten Zeitraster abgearbeitet bzw. getestet werden soll, muss
- entweder schnell pollend, also häufiger als die Zeitzähleinheit angegangen werden
- oder besser noch: als (hochpriorer) Interrupt implementiert werden.
Hi inka,
macht das programm wirklich ALLE 100ms etwas oder immer dann wenns mal größer als 100ms ist? Also 101/102/105 - wanns gerade abgefragt wird?
Ja, genau. Es kann ja immer nur etwas alle 100ms gemacht werden, wenn die Hauptschleife, in der die if(getStopwatchX() > 100 steht, nicht regelmäßig wieder bei der Abfrage ankommt. Hat also die Hauptschleife so viel zu tun, dass sie z.B. für einen kompletten Durchlauf 200ms braucht, dann kann die o.g. Stopwatch-Abfrage natürlich auch nur alle 200ms laufen.
Ist die Hauptschleife schnell (das sollte sie!), dann kommt das mit den 100ms ganz gut hin. Der Ablauf ist dann in der if(getStopwatchX() Schleife:
- Stopwatch > 100 ?
- Alles, was gemacht werden muss
- Stopwatch = 0
Das bedeutet auch, dass wenn "Alles, was gemacht werden muss" etwas länger dauert, diese Zeit zum Intervall noch addiert werden muss.
Wenn du wissen willst, mit welchem Stopwatchwert du in die Abfrage gehst, dann gib den Wert der Stopwatch doch am Anfang der if(getStopwatchX() Schleife aus. Dann kannst du sehen, wie die Intervalle aussehen: writeInteger(getStopwatchX(), DEC);
Was kann man machen:
- Hauptschleife optimieren (Sleeps raus, keine UART/WiFi/LCD-Ausgaben, kein Warten auf Bedingungen ...)
- Auch in den if(getStopwatchX() Schleifen keine Verzögerungen, wenn sie NUR ZUM MESSEN dienen. Daneben kann es natürlich auch noch solche Schleifen zur Textausgabe geben,- die braucht man aber meist selten (alle 0,5 oder 1 s).
der code raegiert nun williger auf den druck auf die buttons, kann ich die ausgabe regelmäßiger machen?
Die Ausgabe wird "unregelmäßig", weil du in der for(i = 0; i < 199; i++) Schleife die Ausgabe mit einer Stopwatch machst. Dann passiert es manchmal, dass die for-Schleife schneller ist als die 50ms der Stopwatch, dann ist die Stopwatch noch <= 50 und eine Ausgabe wird übersprungen.
Du must die ganze Ausgabe in die Stopwatch-Abfrage bringen und darin nicht eine for-Schleife nehmen, sondern eine Schleife mit einem globalen Zähler.
hi,
erkenntnisse aus zahllosen tests:
die IR bake verursacht nach wie vor reflektionen die den empfänger irritieren. Sie sind schwächer als der direkter strahl und der empfang der reflektionen am RP6 ist unregelmässig. Dies habe ich in folgenden änderungen versucht zu berücksichtigen.
hardware:
strahlbegrenzung an der bake27355
hat eigentlich nichts gebracht...
abschirmung des IR-empfängers am RP627356
entstand sukzessive, zuerst der hintere reflektor am IR-empfänger, dann das dickere rohr (ist innen schwarz ausgekleidet), dann der zweiter reflektor mit der kleineren öffnung zum sender hin, dann das kleinere röhrchen, um die eintrittsöffnung noch ein bischen zu verkleinern. Wahrscheinlich funktioniert die hindernissmessung nun nicht mehr, aber darum kümmere ich mich später.
Der IR-empfang ist bei direkter ausrichtung auf die sendende bake noch gut, die empfansfrequenz unverändert, abfrage per software erfolgt immer noch im 50ms rhythmus. Bei einer ausrichtung weg von der bake ist kein empfang, wenn der Rp schräg zu bake steht kommt immer noch ab und zu mal was durch.
software:
case 3://
setLEDs(0b0100);
writeString_P("\n\n suche der bake\n\n");
writeChar('\n');
initRP6Control();
initLCD();
startStopwatch3();
while(true)
{
while(true)
{
if(getStopwatch3() > 50)
{
temp = read_IR_value();
/********************/
uint8_t i = 0;
for(i = 0; i < 199; i++)
{
// writeIntegerLength(temp,DEC,4);
writeInteger(getStopwatch3(), DEC);
if(i % 12 == 0)
{
writeChar('\n');
setStopwatch2(0);
}
else
{
writeString_P(" | ");
setStopwatch2(0);
}
}
/*******************/
if (temp == 0)
{
setMultiIOLED3(1);
setMultiIOLED3(0);
if (t<10)
{
t++;
setStopwatch3(0);
if (t == 10)
{
move(100, FWD, DIST_MM(100), false);
setStopwatch3(0);
t=0;
}
}
}
/*
else
{
setMultiIOLED1(1);
setMultiIOLED1(0);
rotate(80, RIGHT, 1, false);
setStopwatch3(0);
}
*/
}
}
/**************************/
uint8_t key_1;
key_1 = getMultiIOPressedButtonNumber();
if(key_1 != 0) break;
/**************************/
}
break;
der code - so wie er ist (also mit auskommentierter else-zeilen mit dem rotate befehl) - bewirkt, dass der RP6 nach jeweils 10 empfangenen signalen 100mm fährt, die abfrage der 10 empfangegen signale möchte ich noch zeitabhängig prüfen (t soll <10*51ms sein), ich müsste also die stopwatches vor der schleife und nach der schleife in zwei variablen speichern, diese dann voneinander abziehen und die weiterfahrt davon abhängig machen ob die 10 signale innerhalb der ca. 520ms empfangen wurden. Da bastle ich noch dran :-)
könnte die abfrage so aussehen -- if ((t==10) && (tg<520)) --? Ich werde sicher auch noch die passenden stellen für das speichern (und rücksetzen) der zwei variablen t1 und t2 finden, bisher klappte das nicht so ganz :-(
was mir mehr sorgen bereitet ist das zusammenspiel mit dem rotate befehl...
Wenn ich die else zeilen wieder einschalte, leuchtet nur noch die LED1 auf der multiIO und der RP6 dreht sich im kreis. Nur ganz sporadisch komt ein- zwei- mal ein auifleuchten der LED3, mehr aber nicht. Hängt das wieder mit den stopwatches zusammen?
ich habe mir folgendes im terminal ausgeben lassen, werde daraus aber nicht schlau:
suche der bake (ohne rotate)
51
51 | 53 | 54 | 55 | 57 | 58 | 59 | 61 | 62 | 63 | 64 | 66
67 | 68 | 69 | 70 | 72 | 73 | 74 | 76 | 77 | 78 | 80 | 81
82 | 83 | 84 | 86 | 87 | 88 | 89 | 91 | 92 | 93 | 95 | 96
97 | 98 | 99 | 101 | 102 | 104 | 105 | 107 | 108 | 110 | 112 | 113
114 | 116 | 117 | 119 | 120 | 122 | 124 | 125 | 127 | 128 | 130 | 131
132 | 134 | 135 | 137 | 139 | 140 | 142 | 143 | 145 | 146 | 148 | 150
151 | 152 | 154 | 155 | 157 | 158 | 160 | 161 | 163 | 165 | 166 | 168
169 | 170 | 172 | 173 | 175 | 177 | 178 | 180 | 181 | 183 | 184 | 186
187 | 189 | 190 | 192 | 193 | 195 | 196 | 198 | 199 | 201 | 203 | 204
205 | 207 | 208 | 210 | 211 | 213 | 215 | 216 | 218 | 219 | 221 | 222
223 | 225 | 226 | 228 | 230 | 231 | 233 | 234 | 236 | 237 | 239 | 241
242 | 243 | 245 | 246 | 248 | 249 | 251 | 252 | 254 | 256 | 257 | 259
260 | 261 | 263 | 264 | 266 | 268 | 269 | 271 | 272 | 274 | 275 | 277
278 | 280 | 281 | 283 | 284 | 286 | 287 | 289 | 290 | 292 | 294 | 295
296 | 298 | 299 | 301 | 302 | 304 | 306 | 307 | 309 | 310 | 312 | 313
314 | 316 | 317 | 319 | 321 | 322 | 324 | 325 | 327 | 328 | 330 | 332
333 | 334 | 336 | 337 | 339 | 340 | 343
343 | 345 | 346 | 348 | 349 | 351 | 353 | 354 | 356 | 357 | 359 | 360
361 | 363 | 364 | 366 | 368 | 369 | 371 | 372 | 374 | 375 | 377 | 379
380 | 381 | 383 | 384 | 386 | 387 | 389 | 390 | 392 | 394 | 395 | 397
398 | 399 | 401 | 402 | 404 | 406 | 407 | 409 | 410 | 412 | 413 | 415
416 | 418 | 419 | 421 | 422 | 424 | 425 | 427 | 428 | 430 | 432 | 433
434 | 436 | 437 | 439 | 440 | 442 | 444 | 445 | 447 | 448 | 450 | 451
452 | 454 | 455 | 457 | 459 | 460 | 462 | 463 | 465 | 466 | 468 | 470
471 | 472 | 474 | 475 | 477 | 478 | 480 | 481 | 483 | 485 | 486 | 488
489 | 490 | 492 | 493 | 495 | 497 | 498 | 500 | 501 | 503 | 504 | 506
507 | 509 | 510 | 512 | 513 | 515 | 516 | 518 | 519 | 521 | 523 | 524
525 | 527 | 528 | 530 | 531 | 533 | 535 | 536 | 538 | 539 | 541 | 542
543 | 545 | 546 | 548 | 550 | 551 | 553 | 554 | 556 | 557 | 559 | 561
562 | 563 | 565 | 566 | 568 | 569 | 571 | 572 | 574 | 576 | 577 | 579
580 | 581 | 583 | 584 | 586 | 588 | 589 | 591 | 592 | 594 | 595 | 597
598 | 600 | 601 | 603 | 604 | 606 | 607 | 609 | 610 | 612 | 614 | 615
616 | 618 | 619 | 621 | 622 | 624 | 626 | 627 | 629 | 630 | 632 | 633
634 | 636 | 637 | 639 | 641 | 642 | 644
645 | 647 | 648 | 650 | 651 | 653 | 654 | 656 | 657 | 659 | 661 | 662
663 | 665 | 666 | 668 | 669 | 671 | 673 | 674 | 676 | 677 | 679 | 680
681 | 683 | 685 | 686 | 688 | 689 | 691 | 692 | 694 | 695 | 697 | 699
700 | 701 | 703 | 704 | 706 | 707 | 709 | 711 | 712 | 714 | 715 | 717
718 | 719 | 721 | 722 | 724 | 726 | 727 | 729 | 730 | 732 | 733 | 735
736 | 738 | 739 | 741 | 742 | 744 | 745 | 747 | 748 | 750 | 752 | 753
754 | 756 | 757 | 759 | 760 | 762 | 764 | 765 | 767 | 768 | 770 | 771
772 | 774 | 776 | 777 | 779 | 780 | 782 | 783 | 785 | 786 | 788 | 790
791 | 792 | 794 | 795 | 797 | 798 | 800 | 802 |
suche der bake (mit rotate)
51
52 | 53 | 54 | 55 | 57 | 58 | 59 | 61 | 62 | 63 | 65 | 66
67 | 68 | 69 | 70 | 72 | 73 | 74 | 76 | 77 | 78 | 80 | 81
82 | 83 | 84 | 86 | 87 | 88 | 89 | 91 | 92 | 93 | 95 | 96
97 | 98 | 99 | 101 | 102 | 104 | 105 | 107 | 108 | 110 | 112 | 113
114 | 116 | 117 | 119 | 120 | 122 | 124 | 125 | 127 | 128 | 130 | 131
132 | 134 | 135 | 137 | 139 | 140 | 142 | 143 | 145 | 146 | 148 | 150
151 | 152 | 154 | 155 | 157 | 158 | 160 | 161 | 163 | 165 | 166 | 168
169 | 170 | 172 | 173 | 175 | 177 | 178 | 180 | 181 | 183 | 184 | 186
187 | 189 | 190 | 192 | 193 | 195 | 196 | 198 | 199 | 201 | 203 | 204
205 | 207 | 208 | 210 | 211 | 213 | 215 | 216 | 218 | 219 | 221 | 222
223 | 225 | 226 | 228 | 230 | 231 | 233 | 234 | 236 | 237 | 239 | 241
242 | 243 | 245 | 246 | 248 | 249 | 251 | 252 | 254 | 256 | 257 | 259
260 | 261 | 263 | 264 | 266 | 268 | 269 | 271 | 272 | 274 | 275 | 277
278 | 280 | 281 | 283 | 284 | 286 | 287 | 289 | 290 | 292 | 294 | 295
296 | 298 | 299 | 301 | 302 | 304 | 306 | 307 | 309 | 310 | 312 | 313
314 | 316 | 317 | 319 | 321 | 322 | 324 | 325 | 327 | 328 | 330 | 332
333 | 334 | 336 | 337 | 339 | 340 | 51
51 | 53 | 54 | 55 | 57 | 58 | 59 | 61 | 62 | 63 | 64 | 66
67 | 68 | 69 | 70 | 72 | 73 | 74 | 76 | 77 | 78 | 80 | 81
82 | 83 | 84 | 86 | 87 | 88 | 89 | 91 | 92 | 93 | 95 | 96
97 | 98 | 99 | 101 | 102 | 104 | 105 | 107 | 108 | 110 | 112 | 113
114 | 116 | 117 | 119 | 120 | 122 | 124 | 125 | 127 | 128 | 130 | 131
132 | 134 | 135 | 137 | 139 | 140 | 142 | 143 | 145 | 146 | 148 | 150
151 | 152 | 154 | 155 | 157 | 158 | 160 | 161 | 163 | 165 | 166 | 168
169 | 170 | 172 | 173 | 175 | 177 | 178 | 180 | 181 | 183 | 184 | 186
187 | 189 | 190 | 192 | 193 | 195 | 196 | 198 | 199 | 201 | 203 | 204
205 | 207 | 208 | 210 | 211 | 213 | 215 | 216 | 218 | 219 | 221 | 222
223 | 225 | 226 | 228 | 230 | 231 | 233 | 234 | 236 | 237 | 239 | 241
242 | 243 | 245 | 246 | 248 | 249 | 251 | 252 | 254 | 256 | 257 | 259
260 | 261 | 263 | 264 | 266 | 268 | 269 | 271 | 272 | 274 | 275 | 277
278 | 280 | 281 | 283 | 284 | 286 | 287 | 289 | 290 | 292 | 294 | 295
296 | 298 | 299 | 301 | 302 | 304 | 306 | 307 | 309 | 310 | 312 | 313
314 | 316 | 317 | 319 | 321 | 322 | 324 | 325 | 327 | 328 | 330 | 332
333 | 334 | 336 | 337 | 339 | 340 | 51
51 | 53 | 54 | 55 | 57 | 58 | 59 | 61 | 62 | 63 | 64 | 66
67 | 68 | 69 | 70 | 72 | 73 | 74 | 76 | 77 | 78 | 80 | 81
82 | 83 | 84 | 86 | 87 | 88 | 89 | 91 | 92 | 93 | 95 | 96
97 | 98 | 99 | 101 | 102 | 104 | 105 | 107 | 108 | 110 | 112 | 113
114 | 116 | 117 | 119 | 120 | 122 | 124 | 125 | 127 | 128 | 130 | 131
132 | 134 | 135 | 137 | 139 | 140 | 142 | 143 | 145 | 146 | 148 | 150
151 | 152 | 154 | 155 | 157 | 158 | 160 | 161 | 163 | 165 | 166 | 168
169 | 170 | 172 | 173 | 175 | 177 | 178 | 180 | 181 | 183 | 184 | 186
187 | 189 | 190 | 192 | 193 | 195 | 196 | 198 | 199 | 201 | 203 | 204
205 | 207 | 208 | 210 | 211 | 213 | 215 | 216 | 218 | 219 | 221 | 222
223 | 225 | 226 | 228 | 230 | 231 | 233 | 234 | 236 | 237 | 239 | 241
242 | 243 | 245 | 246 | 248 | 249 | 251 | 252 | 254 | 256 | 257 | 259
260 | 261 | 263 | 264 | 266 | 268 | 269 | 271 | 272 | 274 | 275 | 277
278 | 280 | 281 | 283 | 284 | 286 | 287 | 289 | 290 | 292 | 294 | 295
296 | 298 | 299 | 301 | 302 | 304 | 306 | 307 | 309 | 310 | 312 | 313
314 | 316 | 317 | 319 | 321 | 322 | 324 | 325 | 327 | 328 | 330 | 332
333 | 334 | 336 | 337 | 339 | 340 | 51
Hi inka,
...könnte die abfrage so aussehen -- if ((t==10) && (tg<520)) --? Ich werde sicher auch noch die passenden stellen für das speichern (und rücksetzen) der zwei variablen t1 und t2 finden, bisher klappte das nicht so ganz
Ich verstehe leider nicht so ganz, was du im Detail machen willst.
Ein Ablaufschema zum Finden der Bake könnte ja so aussehen:
1. Geht mein Akku zur Neige oder habe ich nichts mehr zu tun?
2. Nein: Meine Aufgabe erledigen oder herumstehen, weiter bei 1.
3. Ja: Zur Ladestation fahren:
4. Auf der Stelle so lange drehen, bis die Bake maximal zu empfangen ist.
5. Geradeaus fahren.
6. Bake erreicht?
7. Ja: Weiter bei 13.
8. Hindernis erkannt?
9. Ja: Ausweichen, dann weiter bei 4.
10. Signal weiter gut zu empfangen?
11. Ja: Weiter bei 5.
12. Nein: Weiter bei 4.
-------------------------------------------
13. Ladestation erreicht, Akku laden!
14. Akku voll geladen?
15. Ja: Losfahren und weiter bei 1.
16. Weiter bei 14.
-------------------------------------------
Mit weniger als das wird es nicht gehen...
ich habe mir folgendes im terminal ausgeben lassen, werde daraus aber nicht schlau:
In der Hauptschleife (Suchen der Ladestation) würde ich das machen:
1. task_IR-Empfang -> Einlesen der IR-Empfängerwerte z.B. alle 50ms per Stopwatch. Die Task gibt in einer Variablen z.B. eine 1 aus, wenn die Bake (z.B. mehr als 3x hintereinander) empfangen wird und 0, wenn nicht. In dieser Task keine Ausgaben ans Terminal oder sonstwo, keine Pausen. Die Task ist z.B. eine eigene Funktion, die in der Hauptschleife aufgerufen wird.
2. task_FahreZurLadestation -> Sucht nach der IR-Quelle und steuert dahin. Braucht intern Regeln, die sich nach o.g. Schema richten, und natürlich die permanenten Infos: IR sichtbar oder nicht (aus der task_IR-Empfang), Hindernis erkannt (ACS o.ä.), Ladestation erreicht, Akkustand.
3. task_Ladung -> Akku wird geladen, Ende erkannt. Braucht permanente Info: Akkustand.
Alle Tasks arbeiten autonom (jede z.B. mit eigener/eigenen Stopwatch(es) und teils abhängig von Infos der anderen 2 Tasks:
- task_IR-Empfang läuft immer
- task_FahreZurLadestation läuft nur, wenn task_Ladung gerade nicht läuft und umgekehrt
- Weitere Tasks können gebraucht werden für das hier:
-- Anzeige von Daten (z.B. zum Debuggen). Immer auch mit Stopwatch (0,5 oder 1s, schneller kann man eh nicht lesen)
-- Eigentliche Aufgabe des autonomen Roboters (wenn er nicht gerade zur Ladung muss oder lädt)
-- ...
hi Dirk,
danke für Deine ausführliche antwort...
ich habe wahrscheinlich, nein, sogar ziemlich sicher eine andere herangehensweise an die aufgabe, die ich mir hier gestellt habe, als ein erfahrener programmierer oder elektroniker - beides bin ich auch nicht, auch wenn ich schon einiges gelernt habe... leider geht das viel zu langsam...
Ich verstehe leider nicht so ganz, was du im Detail machen willst.
meine induktive ladestation besteht aus drei komplexen:
- ladestation - funktioniert soweit...
- ir-bake - an sich funktioniert sie auch...
- das zusammenspiel beim finden der ladestation mit hilfe des IR-empfängers am RP6 - fdunktioniert nicht...
ich kann jetzt einen ablaufplan erstellen wie Du es in Deinem post fantastisch gemacht hast - danke - so in groben zügen hatte ich es mir auch schon skizziert...
Nach Deiner erklärung weis ich (nein, ich ahne es nur) was ein Task ist - ich würde mich aber hier lächerlich machen, wenn ich ernsthaft über "Tasks" und ähnliches reden würde...
Es hilft mir nicht weiter mich mit dem großen plan (den ich ja im prinzip hab!) zu beschäftigen, wenn mir das handwerkszeug fehlt um eine funktionierende verschachtelte if-abfragen-schleife zu erstellen. Beispielsweise move- und rotate- funktion, in abhängigkeit von IR-empfang und abgelaufener zeit, ohne acs, accustand, hindernisse und ähnliches, in der skizzenhaft klar wird, ob meine ir-bake so bleiben kann, oder eben nicht. Zu diese erkenntnis muss ich ab zu mal auch ein paar sachen auf dem terminal ausgeben - das sind alles nur versuche die dinge "im kleinen" zu verstehen. Mit den worten eines feinwerktechnikers - ich kann kein flugzeug bauen, wenn ich von aerodynamik keine ahnung habe...
Und wenn ich ansatzweise weiss, dass die drei komponenten, die ich oben genannt habe auch funktionieren und zusammenspielen, können wir uns gerne über Tasks unterhalten :-)
Hi,
Es hilft mir nicht weiter mich mit dem großen plan (den ich ja im prinzip hab!) zu beschäftigen, wenn mir das handwerkszeug fehlt um eine funktionierende verschachtelte if-abfragen-schleife zu erstellen. Beispielsweise move- und rotate- funktion, in abhängigkeit von IR-empfang und abgelaufener zeit,...
Ich denke, es geht vielleicht nicht nur ums Handwerk. :-k
Erklär doch mal (als "Ablaufschema" oder Wenn-Dann-Abfolge), was du in der "verschachtelten if-abfragen-schleife" machen willst! Wenn (auch) ich die Logik verstehe, dann kommt die Umsetzung im 2. Schritt schon ... ;) ... irgendwie ... :-b ... oder ...
hallo Dirk,
ich habe den code von vorhin mit kommentaren versehen, so wie sie mir zutreffend scheinen...
der roboter steht zunächst im raum, ist eingeschaltet, weiss nicht wo er ist, weisst nicht wo die IR-bake ist.
und das sollte er tun:
- misst nach 50ms zuerst ob er IR empfang hat
- hat er empfang, misst er weiter bis er 10x empfang hatte
- dann prüft er, ob er diese 10 signale innerhalb von 520ms (tg) empfangen hat
- ist tg<520 fährt er 100mm
- ist tg>520 rotiert er um 1 grad
- fängt wieder mit IR messung an
case 3://
setLEDs(0b0100);
writeString_P("suche der bake \n");
writeChar('\n');
initRP6Control();
initLCD();
startStopwatch3();
t=0; //t, t1, t2, tg sind am programmanfang definiert (unint_8)
while(true) //schleife bis button gedrückt
{
while(true) //dauerschleife - wie komme ich da raus?
{
if(getStopwatch3() > 50) //wenn stopwatch3 > 50ms messe IR empfang
{
temp = read_IR_value(); //Ir empfang (PB2) messen
if (temp == 0) //wenn IR empfang dann schleifendurchlauf, sonst rotate
{
t1 = getStopwatch3(); // stopwatch3 wert beim ersten "treffer"
setMultiIOLED3(1);
setMultiIOLED3(0);
if (t<10) // schleife für 10 treffer
{
t++;
setStopwatch3(0); // stopwatch nach treffern 1 - 9 auf 0
if (t == 10) // wenn t=10 dann
{
t2 = getStopwatch3(); // stopwatch3 wert für den 10. treffer
tg = t2-t1;
if (tg<520) // wenn tg < 520 move
{
move(100, FWD, DIST_MM(100), false);
setStopwatch3(0); //stopwatch3 na 10 treffern auf 0
t=0;
}
}
}
}
else
{
setMultiIOLED1(1);
setMultiIOLED1(0);
rotate(80, RIGHT, 1, false); // drehe rechts um 1 grad, nicht blockierend
setStopwatch3(0); //stopwatch3 nach rotate auf 0
}
}
}
/**************************/
uint8_t key_1;
key_1 = getMultiIOPressedButtonNumber();
if(key_1 != 0) break;
/**************************/
}
break;
Hi inka,
der roboter steht zunächst im raum, ist eingeschaltet, weiss nicht wo er ist, weisst nicht wo die IR-bake ist.
und das sollte er tun: ...
Ok, das wären ja so etwa die Schritte 4,5,10,11,12 von meinem Ablaufschema. Klingt gut ...
while(true) //dauerschleife - wie komme ich da raus?
Du kannst die DO-WHILE Schleife nehmen, wenn in der Schleife irgendein Ergebnis zum Abbruch vor dem nächsten Durchlauf führen soll:
do
{
// ...
}
while (Bedingung);
Als "Bedingung" schreibst du dann den Test rein, der FALSE wird, wenn die Schleife verlassen werden soll.
rotate(80, RIGHT, 1, false); // drehe rechts um 1 grad, nicht blockierend
Geht, funktioniert aber nur mit der task_motionControl() der RP6 Library, die in der Hauptschleife dauernd aufgerufen werden muss. Das Drehen um 1° dürfte auch schwierig werden, fang mal mit 5° an.
hi Dirk,
rotate(80, RIGHT, 1, false); // drehe rechts um 1 grad, nicht blockierend
Geht, funktioniert aber nur mit der task_motionControl() der RP6 Library, die in der Hauptschleife dauernd aufgerufen werden muss. Das Drehen um 1° dürfte auch schwierig werden, fang mal mit 5° an.
mein programm läuft ja auf der m32. Läuft dieser "task_motionControl()" nicht schon in der slavesoftware der base?
Hi,
mein programm läuft ja auf der m32. Läuft dieser "task_motionControl()" nicht schon in der slavesoftware der base?
Stimmt, ... :oops:
hi Dirk,
im code werden die variablen t1, t2 und tg verwendet
wenn ich diese variablen t1, t2 und tg als uint8_t definiere (so wie sie im code nachher verwendet werden) passieren die seltsamsten dinge:
auch wenn diese variablen nur den abschnitt im case3 bertreffen, haben sie einfluss auf das verhalten im abschnitt case1 und case2 und zwar NUR die reine definition, auch wenn der code, wo sie verwendet werden auskommentiert wird!
im case1 wird z.b. die IR bake überhaupt nicht erkannt, auch wenn sie direkt vor dem IR-empfänger steht
im case2 werden im terminal statt 0000 (empfang) bzw. 0004 (kein empfang) die reinsten fantasiezahlen ausgegeben und die bake nicht erkannt
definiere ich statt "t1" z.b. "x" und statt "t2" z.b. "y" passiert das nicht, das programm läuft ganz normal ab. Der neue abschnitt case3 läuft noch nicht richtig, aber case1 und 2 laufen ganz normal...
ich konnte mir jetzt mit dem umdefinieren der variablen helfen, will Dich jetzt auch nicht mit dem ganzen code behelligen, gibt es aber dafür eine erklärung?
Hi inka,
schau dir noch mal die Datentypen in GCC an!
Hier die Wichtigsten:
uint8_t -> 0..255
int8_t -> -128..+127
uint16_t -> 0..65535
int16_t -> -32768..+32767
uint32_t -> 0..4294967295
int32_t -> -2147483648..+2147483647
float -> -3.4E38..+3.4E38 (Fließkomma)
Wenn du negative Zahlen brauchst, must du schon einen intX_t Typ nehmen, bei nur positiven Werten reicht ein uintX_t.
Deine Werte liegen teils ja schon über/bis 520, also kommst du mit uint8_t nicht hin (Werte passen nicht in die Variablen und machen dann Mist).
hi allerseits,
eigentlich wollte ich hier ein video reinstellen, dass alles klappt, klappt ja auch aber nur im prinzip. Der RP6 findet brav die bake, fährt hin, bleibt aber per abfrage der bumper nicht zuverlässig genung stehen. mal tut er das, dann wieder nicht, ich glaube, ich habe nun in dem code die möglichkeiten die bumperabfrage zu plazieren ziemlich ausgeschöpft...
task_checkINT0();
task_I2CTWI();
if(bumper_left && bumper_right)
{
break;
stop();
}
bzw. am ende der do-while schleife:
while(!bumper_left && !bumper_right);
break;
stop();
evtl. liegt dort das problem, die abfrage der beiden task liegt innerhalb (am ende) der do-whileschleife? Könnte sich bitte jemand den code anschauen?
das wird oberhalb der hauptschleife aufgerufen:
I2CTWI_initMaster(100);
I2CTWI_setTransmissionErrorHandler(I2C_transmissio nError);
I2CTWI_setRequestedDataReadyHandler(I2C_requestedD ataReady);
case 3://
setLEDs(0b0100);
writeString_P("suche der bake \n");
writeChar('\n');
initRP6Control();
initLCD();
startStopwatch3();
t=0;
while(true)
{
do
{
if(getStopwatch3() > 50)
{
temp = read_IR_value();
if (temp == 0)
{
x = getStopwatch3();
setMultiIOLED3(1);
setMultiIOLED3(0);
if (t<10)
{
t++;
if (t == 10)
{
y = getStopwatch3();
z = y-x;
t=0;
setStopwatch3(0);
if (z< 600)
{
move(100, FWD, DIST_MM(100), false);
setStopwatch3(0);
t=0;
mSleep(400);
task_checkINT0();
task_I2CTWI();
if(bumper_left && bumper_right)
{
break;
stop();
}
}
}
}
}
else
{
setMultiIOLED1(1);
setMultiIOLED1(0);
rotate(80, RIGHT, 1, false);
setStopwatch3(0);
}
task_checkINT0();
task_I2CTWI();
if(bumper_left && bumper_right)
{
break;
stop();
}
}
task_checkINT0();
task_I2CTWI();
}
while(!bumper_left && !bumper_right);
break;
stop();
/**************************/
uint8_t key_1;
mSleep(100);
key_1 = getMultiIOPressedButtonNumber();
if(key_1 != 0) break;
stop();
/**************************/
}
break;
Thorben W
03.02.2014, 16:16
Muss das break; nicht hinter das stop();?
Weil bei break wird die Schleife verlassen:
break Mit dem Schlüsselwort break können wir zu jeder Zeit eine Schleife verlassen, ohne auf den Kontrollpunkt warten zu müssen.
http://www.c-howto.de/tutorial-schleifen-break.html
gruß Thorben
hi Thorben,
ich bin da unsicher:
gerade an der stelle hatte ich glaube ich schon alle variationen getestet. Nur break, nur stop, break/stop, stop/break. Die variante break/stop schien mir noch die "erfolgreichste" zu sein - zumindest manchmal passierte beides - er veließ die schleife UND die motoren blieben stehen.
Ich glaube dass es etwas mit der dauer der betätigung der bumper zu tun hat, beim kurzen antippen dreht sich der RP6 anschließend im kreis, bei einer längeren betätigung bleibt er eher stehen...
- - - Aktualisiert - - -
ich hab jetzt die reihenfolge noch einmal geändert, zuerst stop(); und dann break;
so lange er nach rechts dreht, bleibt er beim betätigen des bumpers stehen
wenn er geradeaus fährt, fängt er nach der betätigung des bumpers sich nach rechts zu drehen, mal schneller, mal langsam, er misst nicht dabei, erst wenn ich den button3 betätige, also quasi den case3: noch einmal auslöse, fängt er auch an zu messen und fährt dann (nach empfang) geradeaus wieder richtung bake. Wo im code passiert das? verstehe ich nicht...
Thorben W
03.02.2014, 17:37
Könnte es sein das du in else Schleife Reinkommst da dort ja eine Rechtsbewegung ausgeführt wird?
case 3://
...
if (temp == 0)
{
...
}
else
{
setMultiIOLED1(1);
setMultiIOLED1(0);
rotate(80, RIGHT, 1, false);
setStopwatch3(0);
}
...
War nur eine Idee da dort ja ein Befehl für rechts gegeben wird.
gruß Thorben
du meinst, er führt den break in der schleife in der er geradeaus fährt aus und rasselt dann in die else-schleife mit der rechtsdrehung rein? Ist es nicht so, dass dieses else nur dann angesprungen wird wenn in der abfrage
{
temp = read_IR_value();
if (temp == 0)
{
......
eben temp != 0 ist?
Thorben W
03.02.2014, 18:16
eben temp != 0 ist?
Ja das ist richtig.
Kann es sein das wenn die Bumper ausgelößt werden, dass dann temp != 0 ist?
Thorben
hi,
jetzt bleibt der RP 6 zumindest stehen, wenn er mit dem bumper an der bake angekommen ist :-), das video muss noch ein bischen warten, die lichtverhältnisse sind beim bedeckten himmel nicht gut genug :-(
nun möchte ich weitermachen und in dem beispiel "RP6Control_10_Move2.c" habe ich ein dankbares objekt zum experimentieren gefunden. Komplett verstanden habe ich es noch nicht, aber deshalb will ich ja experimentieren...
dort wird auch auf einen niedrigen batteriestand reagiert:
// Behaviour check low Battery:
#define BATTERY_LOW 1
behaviour_command_t checkLowBattery = {0, 0, FWD,
false, false, 0, IDLE};
/**
* In this behaviour routine, we have nothing to do
*/
void behaviour_checkLowBattery(void)
{
}
/**
* This is a new Event Handler and it gets called when the Battery Voltage
* is getting low! The Parameter isVoltageLow is true, when the voltage
* is low and false, when the voltage is OK.
*/
void batteryVoltageLow(uint8_t isVoltageLow)
{
if(isVoltageLow)
checkLowBattery.state = BATTERY_LOW;
bake_suche();
}
die abfrage "if(isVoltageLow)" habe ich um die funktion bake_suche() ergänzt:
void bake_suche(void)
{
// accuzustand();
setLEDs(0b0100);
writeString_P("bake_suche_1 \n");
writeChar('\n');
initRP6Control();
initLCD();
startStopwatch3();
t=0;
do
{
if(getStopwatch3() > 50)
{
temp = read_IR_value();
if (temp !=0)
{
setMultiIOLED1(1);
setMultiIOLED1(0);
rotate(80, RIGHT, 5, false);
temp = read_IR_value();
if (temp == 0) stop(); //break;
if(bumper_left && bumper_right) //stop();//break;
{
stop();
// break;
}
}
temp = read_IR_value();
if (temp == 0)
{
x = getStopwatch3();
setMultiIOLED3(1);
setMultiIOLED3(0);
if (t<10)
{
t++;
if (t == 10)
{
y = getStopwatch3();
z = y-x;
writeInteger(x, DEC);
writeChar('\n');
writeInteger(y, DEC);
writeChar('\n');
writeInteger(z, DEC);
writeChar('\n');
t=0;
setStopwatch3(0);
if (z< 600)
{
move(100, FWD, DIST_MM(100), false);
setStopwatch3(0);
t=0;
mSleep(400);
task_checkINT0();
task_I2CTWI();
if(bumper_left && bumper_right)
{
stop();
// move(100, BWD, DIST_MM(200), false);
// break;
}
}
}
}
}
}
task_checkINT0();
task_I2CTWI();
}
while(!bumper_left && !bumper_right);
stop();
}
das ganze lässt sich auch kompilieren, also von daher steht dem experimentieren nur eines im weg: auf welchem weg holt sich das "Behaviour check low Battery:" die batteriewerte? Das habe ich leider nicht gefunden...
Um nicht so lange warten zu müssen bis der akku wirklich leer ist, möchte ich die abfrage irgendwie beeinflussen...
Hi inka,
ob die Akkuspannung niedrig ist, wird schon im I2C-Slave der Base in der Funktion task_update() erkannt und über ein Interrupt-Status Bit (interrupt_status.batLow) an den Master weiter gegeben.
Ich denke, du kannst das Bit in deinem Programm zum Testen manipulieren.
so, jetzt hats geklappt...
http://www.youtube.com/watch?v=HqvyWI0y8Z0&feature=youtu.be
Stark!!!
Und wie ich sehe mit Multi-IO im Einsatz ;)
manchmal geht es schneller als man erhofft hat:
ich habe das beispiel "RP6Control_10_Move2.c" in der mainschleife mit dieser funktion ergänzt (spannungsabfrage über die multiIO)
void accuzustand(void) // accuspannung abfragen und signalisieren
{
LTC2990_measure();
if (vbat < 6)
{
buzzer(330);
mSleep(200);
buzzer(330);
mSleep(200);
bake_suche();
}
}
dort kann ich direkt über die Vbat abfrage den wert festlegen bei dem die funktion "bake_suche" aufgerufen werden soll. Und es funktioniert!!!
Ich muss jetzt noch prüfen nach welcher funktion jetzt die reaktion auf die bumper erfolgt, ob das auf diese "behaviour_escape" oder auf die direkte abfrage in der "bake_suche" ist. Ich vermute es ist die "behaviour_escape" funktion...
weiter geht es dann mit der liniensuche: ich muss ja in einer bestimmten richtung (eigentlich senkrecht auf die wand) auf die ladestation zufahren...
TrainMen
11.02.2014, 12:16
Gratulation zum Etappensieg,
ich bewundere Deine hartnäckigkeit bei diesem Projekt.
Hi inka,
dem Glückwunsch zum "Etappensieg" schließe ich mich gern an.
ich habe das beispiel "RP6Control_10_Move2.c" in der mainschleife mit dieser funktion ergänzt (spannungsabfrage über die multiIO)
Man kann so was machen, allerdings muss ...
a) die Hauptschleife ohne Verzögerungen (d.h. ohne mSleep) ablaufen und
b) man kann nicht auch noch eine längere Suche nach der Bake dort durchführen (bake_suche).
Grund: Die weiteren Programmfunktionen reagieren dann kaum noch.
Ich muss jetzt noch prüfen nach welcher funktion jetzt die reaktion auf die bumper erfolgt,...
Der "Bumpers Event handler" (bumpersStateChanged) wird angesprungen, wenn sich der Bumper-Zustand ändert.
Wie du schon gesagt hast, passiert die Reaktion auf Bumper-Änderungen in der behaviour_escape Funktion.
Grundsätzlich zeigt die Demo "RP6Control_10_Move2.c", wie man "Verhalten" (behaviour) programmieren kann.
Die Demo:
1. Warte bis ein Geräusch gehört wird (behaviour_waitForStart).
2. Fahre dann herum (behaviour_cruise).
3. Weiche Hindernissen aus (behaviour_escape).
4. Vermeide Hindernisse (behaviour_avoid).
5. Achte auf leere Batterie (behaviour_checkLowBattery)
6. Gehe zu 2.
Die Demo ist eigentlich ideal für dein Vorhaben, das du ja auch in verschiedenes "Verhalten" aufteilen könntest:
1. Mache was (Herumfahren).
2. Achte auf leere Batterie.
3. Falls leer: Suche Bake
4. Fahre auf schwarzer Linie zur Ladestation
5. Lade Akku
6. Gehe zu 1.
Das bedeutet in der Demo:
Du müßtest eigene "Verhalten" (behaviours) nach dem Vorbild in der Demo schreiben. Dazu müßtest du z.B. auch die Rangfolge der Verhaltensweisen (siehe behaviourController) festlegen.
Das ist zwar nicht ganz einfach, aber es ist leider nicht damit getan, deine Funktionen (Akku überwachen, Bake suchen, auf der Linie zur Ladestation fahren ...) in die Hauptschleife dieser Demo zu packen.
TrainMen
12.02.2014, 15:04
Du müßtest eigene "Verhalten" (behaviours) nach dem Vorbild in der Demo schreiben. Dazu müßtest du z.B. auch die Rangfolge der Verhaltensweisen (siehe behaviourController) festlegen.
Ja genau so habe ich das gemacht. In der Funktion Akku überprüfen habe ich eine Variable auf Aktiv gesetzt wenn der Akku zur Neige ging. In einer anderen Funktion habe ich dann diese Variable überprüft. Wenn dies dann Aktiv war habe ich nach der hellsten Stelle im Raum (Solar-Projekt) suchen lassen. Am Ende der Funktion habe ich die Variable wieder auf inAktiv gesetzt. So konnte mein BOT auch auf dem Weg zu hellsten Stelle auch wieder die anderen Verhalten beachten. Das müsste doch mit der Bake auch funktionieren ?. Jedenfalls zum auffinden der Bake.
hallo,
ich musste die links und rechts IR-sensoren des linienfolgemoduls (einbaubedingt) in der lib tauschen:
RP6Control_MultiIO.h:
// Other ADC channel definitions:
// (Depending on jumper settings on the MultiIO Project Board!)
// (The ADC-Mxxx plug is connected to the M32 ADC plug!)
#define ADC_MULTIIO_LFS_L ADC_5 // ADC-Mxxx: ADC geändert von 3 in 5, (L=links in fahrtrichtung)
#define ADC_MULTIIO_LFS_M ADC_4 // ADC-Mxxx: ADC
#define ADC_MULTIIO_LFS_R ADC_3 // ADC-Mxxx: ADC geändert von 5 in 3 (R=rechts in fahrtrichtung)
das hat soweit gut funktioniert, verunsichert bin ich durch diese defines, was ist das?
RP6Control_LFSBumperLib.h:
// Define the use of the LFS Board here!
#define LFS // LFS Board is used
// ---------------------------------------------------------------------------
#define CH_LFS_L 1
#define CH_LFS_M 2
#define CH_LFS_R 3
... verunsichert bin ich durch diese defines, was ist das?
Das sind die Nummern der ADC-Kanäle (CHannel). Die müssen so bleiben.
hallo,
wieder einmal eine anfängerfrage...
folgende funktion funktioniert, beim empfang eines signals der IR-bake wird 000 angezeigt, wenn kein signal 004:
void read_Register_30(void)
{
I2CTWI_transmitByte(I2C_RP6_BASE_ADR, 0); // Start with register 0...
I2CTWI_readBytes(I2C_RP6_BASE_ADR,RP6data, 31); // and read all 30 registers
uint8_t i = 0;
for(i = 0; i < 31; i++)
{
// mSleep(8);
if (i == 30) IR_wert[0] = RP6data[30];
}
}
diese aber nicht. Da kommt immer nur 000, egal ob IR-bake sendet oder nicht:
void read_Register_30(void)
{
I2CTWI_transmitByte(I2C_RP6_BASE_ADR, 30); // Start with register 30...
I2CTWI_readBytes(I2C_RP6_BASE_ADR,RP6data, 1); // and read one register
IR_wert[0] = RP6data[30];
}
ich verstehe einfach nicht warum, hab doch nur die schleife rausgenommen?
Nur die Schleife rausgenommen? Ich vermute mal (Glaskugel) das ist ein Stück Code aus dem i2c-Slave der Base.
Du nimmst aber nicht nur die Schleife raus .. du nimmst dem System auch die benötigte Zeit um die Daten aufzuarbeiten.
Die i2C Datenverarbeitung ist zeitkritisch. Wie so vieles andere an den RP6 Libs auch.
Mach doch einfach mal:
void read_Register_30(void) {
I2CTWI_transmitByte(I2C_RP6_BASE_ADR, 30); // Start with register 30...
I2CTWI_readBytes(I2C_RP6_BASE_ADR,RP6data, 1); // and read one register
mSleep(x);
IR_wert[0] = RP6data[30];
}
und probiere mit Werten für x von 0 bis ... keine Ahnung.. 100 .. was die Funktion macht wenn du x bei sendender Bake erhöhst.
Eigentlich sollte sich experimentell ein Wert ermitteln lassen, ab wieviel x die bake gefunden bzw diese 004 übertragen wird.
Es würde mich auch nicht wundern, wenn Du bald die Erkenntnis hast, das sich die Motorsteuerung und die i2c slave lib jeweils als Zeitkritische Module sich im Prinzip gegenseitig in den Füßen stehen - weshalb es nicht ganz ist, das Base Slave Programm softwaremässig noch zu erweitern.
Gruß
I2CTWI_readBytes(I2C_RP6_BASE_ADR,RP6data, 1); // and read one register
IR_wert[0] = RP6data[30];
Bei dem Code wird das über I2C gelesene Byte in "RP6data" gespeichert.
Du must also mit: IR_wert[0] = RP6data; ... auslesen.
Vorsicht mit den Namen von Variablen (Var) und Arrays (Var[n])!
@Dirk,
bei genauerem hinschauen wars dann doch recht einfach:
void read_Register_30(void)
{
I2CTWI_transmitByte(I2C_RP6_BASE_ADR, 30); // Start with register 30...
I2CTWI_readBytes(I2C_RP6_BASE_ADR,RP6data, 1); // and read one register
IR_wert[0] = RP6data[30];
}
zum einen das "s", zum anderen das direkte auslesen in den IR-wert...
void read_Register_30(void)
{
I2CTWI_transmitByte(I2C_RP6_BASE_ADR, 30);
IR_wert = I2CTWI_readByte(I2C_RP6_BASE_ADR);
}
@RolfD,
der code hatte diesmal nichts mit code aus dem i2c (http://www.rn-wissen.de/index.php/I2C)-Slave der Base zu tun, war ein codeschnipsel aus einem der m32 beispiele...
mit dem mSleep (evtl. stopwatsches) geht es jetzt weiter zu angleichung der sende/empfangfrequenz. So weit war ich eigentlich schon mal...
danke Euch beiden...
hallo allerseits,
der RN-wissen artikel über die IR-bake ist online (http://www.rn-wissen.de/index.php/IR-bake_f%C3%BCr_den_RP6#IR-bake_f.C3.BCr_RP6_.28Baustelle.....29)...
die software - da bin ich noch nicht ganz fertig, der rest - auch ein paar videos - sind online...
Besserwessi
24.05.2014, 18:44
Die Sendeschaltung mit dem NE555 ist noch verbesserungsfähig:
Bei einer 5 V Versorgung kann man je 2 (ggf. sogar 3) IR LEDs in Reihe schalten - das spart Strom und macht keinen extra Aufwand.
Das Tastverhältnis für die IR LEDs sollte deutlich kleiner als 50% sein - eher so 25 %. Bei gleichem Impulsstrom für die LEDs gibt das 50% an Stromverbrauch bei 70% der Signalstärke, oder alternativ 70% des mittleren Stromverbrauchs bei der gleichen Signalstärke. Die IR LEDs sollten eine extra Abkopplung von der Versrogung bekommen (Widerstand und ELKO) um die Rückwirkungen auf den Rest der Schaltung zu reduzieren. Der 2N2222 ist mit den 5 oder 6 LEDs so auch etwas überfordert und braucht deshalb wohl den Kühlkörper. Mit weniger Widerstand an der Basis könnte er mehr Strom liefern und kommt ohne extra Kühlung aus.
Der Teil mit dem Blinker ist verdächtig: die Kopplung zum IR Sender sollte mit der LED nicht mehr Funktionieren. Also besser die rote LED direkt an den Ausgang des NE555, und den Transistor nur zur Kopplung mit der IR Stufe. Bei der LED sollten es auch mehr als 47 Ohm Vorwiederstand sein. Alternativ könnte man die Kopplung über den Reset Eingang des NE555 machen - das geht auch ohne den Transistor.
Und selbst dann ist das nichts anderes wie eine blinkende IR-Lampe die man anmessen könnte wie eine 60W Glühbirne mit LDRs. Oder von mir aus auch ein 3W LED Strahler. Der RP6 besitzt aber immerhin 2 LDRs die analog differentiell auszulesen sind, aber nur ein IR Empfänger mit unklaren Richtcharakteristiken. Klar kann man sowas incl. Türrahmen als "Linse" ähnlich einer camera obsura oder Lochkamera a la Leronardo da Vinci nutzen um eine gewisse Orientierung zu bekommen. Bau das Ganze in einer Turnhalle auf und du wirst sehen das es versagt. Ich erinnere nur an das Kerzenlöschprojekt mit dem snake eye (auch mit 2 Senoren). Für manche mag das reichen... aber es ist eben nichts weiter als eine Art IR-Glühbirne mit einem "einäugigen System" angemessen. Es geht nicht darum, die Lösung zu kritisieren welche umgesetzt wurde - sondern um die Frage ob man das Ergebnis verbessern kann und was es genau bedeutet. Dazu gab es auch reichlich Anregungen hier. Ich sehe das bisherige Ergebnis als den ersten Schritt und es wäre schade wen es dabei bliebe. Aber es ist bis hier hin sauber erarbeitet.. also Anerkennung. Da ist dann auch recht egal ob da nun 1, 2 oder 3 LEDs im Kirchhofschen Zweig hängen denn es ändert am bisherigen Grundprinzip der einfachen IR-Lampe nichts.
Zudem führen die Reflektorröhren am Sender nur dazu, das Bereiche entwerder stärker bzw garnicht ausgeleuchtet werden. Wenn ich 6 LEDS mit einem Strahlungswinkel von je 10 Grad habe, aber 100° ausleuchten muss, bleiben nach Adam Riese 40° dunkel! Einer der Gründe warum das Finden einer Position mit diesem Konzept meiner Meinung nach mehr reiner Zufall als wirkliche Orientierung ist. Wenn, dann müsste so eine Röhre auf den Empfänger aber es hätte vor allem einen eingeschränkteren "Sichtbereich" zur Folge. Ob das gut wäre.. müsste man mal testen. Ich denke ja denn immerhin erleichtert das eine Richtungserkennung wenn man die Intensivität des IR-Signals misst. Wenn...
Ich hab noch nichts mit dem IR-Reciever gemacht aber meines Wissens kann der Sensor nicht mal eine IR-Signalstärkemessung durchführen! Mit anderen Worten... er misst nur Licht an oder Licht aus.. seh ich das richtig? Wenn ja, kann die Konstellation sogar weniger als ein einäugiger LDR Sensor!
Schreibt doch mal ein Lichtsucher Programm per LDR und Sonne mit EINEM LDR-Sensor.. welcher im schlimmsten Fall aller angenommenen Fälle auch nur 100% hell oder 0% dunkel erkennt.. dann wisst ihr was ich meine.
Gruß
hallo Besserwessi,
danke für die hinweise zu verbesserung der IR-bake, werde es beim neuen aufbau (alles auf einer platine) versuchen zu berücksichtigen...
- - - Aktualisiert - - -
-------------------------------------------------------------------------------------
@RolfD,
Aber es ist bis hier hin sauber erarbeitet.. also Anerkennung. Da ist dann auch recht egal ob da nun 1, 2 oder 3 LEDs im Kirchhofschen Zweig hängen denn es ändert am bisherigen Grundprinzip der einfachen IR-Lampe nichts.
danke für Dein positives echo...
Zudem führen die Reflektorröhren am Sender nur dazu, das Bereiche entwerder stärker bzw garnicht ausgeleuchtet werden. Wenn ich 6 LEDS mit einem Strahlungswinkel von je 10 Grad habe, aber 100° ausleuchten muss, bleiben nach Adam Riese 40° dunkel! Einer der Gründe warum das Finden einer Position mit diesem Konzept meiner Meinung nach mehr reiner Zufall als wirkliche Orientierung ist. Wenn, dann müsste so eine Röhre auf den Empfänger aber es hätte vor allem einen eingeschränkteren "Sichtbereich" zur Folge. Ob das gut wäre.. müsste man mal testen.
Hast Du es wirklich gelesen, die beschreibung meine ich - der empfänger hat auch ein rohr zu abschirmung...
ansonsten weigere ich mich einfach den rest zu kommentieren, dein sinnloses gemeckere berücksichtigt nichts von den ursprünglichen vorgaben für das projekt (Ir-bake, nichts von LDR, 5-6m reichweite, keine turnhallenanwendung, usw...) Aber mach nur weiter so, das ist auch für andere sehr motivierend...
@RolfD,
danke für Dein positives echo...
Hast Du es wirklich gelesen, die beschreibung meine ich - der empfänger hat auch ein rohr zu abschirmung...
ansonsten weigere ich mich einfach den rest zu kommentieren, dein sinnloses gemeckere berücksichtigt nichts von den ursprünglichen vorgaben für das projekt (Ir-bake, nichts von LDR, 5-6m reichweite, keine turnhallenanwendung, usw...) Aber mach nur weiter so, das ist auch für andere sehr motivierend...
Inka es ist mir ehrlich gesagt egal was du über mich und mein "sinnloses Gemeckere" denkst. Hier kann immer noch jeder selbst entscheiden was er nachbaut und unter welchen Voraussetzungen. Du musst mich auch nicht mögen und ich muss technische Aspekte nicht Zugunsten deiner "Fan-Gemeinde" unter den Teppich kehren. Aber DU hast mein Beitrag anscheinend nicht mal richtig gelesen, ich VERGLEICHE deine "Bake" mit einem LDR-Empfänger für sichtbares Licht/Lampe denn es ist egal welche Farbe das Licht hat, es hat immer die gleichen physikalischen Grundeigenschaften und daher ist der Vergleich auch nicht so falsch. Auch wenn dir das nicht in den Kram passt!
Davon abgesehen könnte man den ganzen Aufbau auch einfachst nachstellen indem man den RP6 dazu bringt auf eine IR-Fernbedienung zu zu fahren auf der Tasten gedrückt sind. Das auch am IR Empfänger ein Reflektorröhrchen sitzt ist mir tatsächlich entgangen. Aber das ist nur ein Nebensatz/Aspekt aus meinem Post! Es ist echt zwecklos dir etwas vermittel zu wollen wenn du das in persönliche Angriffe ummünzt! Und bevor du dich komplett im Ton vergreifst, les dich erst mal schlau oder erkläre hier nach welchem physikalischen Grundprinzip ausser Try & Error deine "Bake" genau funktioniert! Und selbst wenn es nur Try & Error eines einäugigen IR-Lichtsuchers ist.. wieso hast Du ein Problem das offen zu sagen? Wieso ist das sinnloses Gemeckere wenn ich das sage?
http://de.wikipedia.org/wiki/Terrestrische_Navigation
http://de.wikipedia.org/wiki/Ortsbestimmung
http://archive.cone.informatik.uni-freiburg.de/pubs/masterthesis_wendeberg_2009.pdf
http://www.mechatronik-ev.de/media/files/06_OptischesMessen_Salzberger.pdf
Deine Bake funktioniert nur genau dann wenn der RP6 und EINE der Senderdioden genau aufeinander ausgerichtet sind weil der RP6 genau dann definierte Pulse erkennt. Wozu aber dann 5 Dioden in 5 Richtungen die sich gegenseitig kaum beinflussen aber die ganze Gegend mit IR Licht verschmutzen? Dummerweise reagiert dein RP6 nämlich auch auf IR-Streulicht welches du mit jeweils 4 Dioden zusätzlich produzierst um es dann elegant durch die Röhren abzuleiten damit es eben nicht auch auf den RP6 trifft! Dein Entwurf ist nicht durchdacht, Inka. Das kann man wie gesagt mit jeder Fernbedienung und im Kreis drehen bis der RP6 ein Signal bekommt, nachstellen... Versuch es doch einfach mal mit einem Reflektor und Linse aus einer Billig-led-taschenlampe und EINER (1) IRLED... Oder 5 leds genau in die gleiche Richtung. Nur schlecht wenn der RP6 dann nicht in der Leuchtachse der LEDs steht.. aber das kannst Du auch nicht mit 5 EinzelLEDS verhindern die in 5 verschiedene Richtungen zeigen! 2. Denkfehler! Und auch nicht mit einem Sensor anmessen, der nur Signal oder kein Signal kennt. 3.Denkfehler!
Um es klar zu sagen: Du versuchst hier im Sender die Eigenschaften eines omnidirektionalen und eines punktförmigen Strahlers in einem Gerät zu vereinen, und die grade aktuell vorherrschende Eigenschaft (quasi Winkel abhängig?) durch einen rein digital arbeitenden Sensor, welcher keine Information zur Signalstärke liefert, zu erkennen um daraus dann eine Richtung abzuleiten. Ein Ansatz der einem doppelten Paradoxon gleich kommt. Was ist daran nicht Try&Error? Weisst Du eigentlich warum die IR Sendedioden fürs ACS auf dem RP6 in der Leistung umschaltbar sind? Weil die damit dimmbar sind... und man dosiertes Licht auf dem IR-Chip geben kann! Wäre die Empfindlichkeit des Chips einstellbar oder sogar die Signalstärke zu messen, hätte sich Slyd diesen Kniff klemmen können... Fährst du eigentlich mit aktivem ACS da in den Videos rum, verträgt sich ACS mit deiner Bake? Auch keine ganz so uninteressante Frage...
Sieh es ein.. oder lass es...
Aber ... es gibt sogar eine "Anwendung" die ähnlich funktioniert wie deine "Bake"... der IR-Fußball (http://www.conrad.de/ce/de/product/191437/Arexx-Infrarot-Ball-fuer-Fussball-Roboter-IRB-35) von AREXX um Robofußball spielen zu können.
Ohne die Anleitung dazu je gelesen zu haben würde ich ja mal fast wetten, das da was von einer Messbrücke (http://de.wikipedia.org/wiki/Wheatstonesche_Messbr%C3%BCcke) und min. 2 IR-Fototransistoren/FotoDioden drin steht...
Gruß
Besserwessi
26.05.2014, 21:52
Der Einwand mit dem Extra Streulicht durch die 5 IR LEDs ist wirklich berechtigt. Hierfür gäbe es aber auch eine relativ einfache Lösung: die IR Diode sollten nicht alle gleichzeitig, sondern etwa Zeitversetzt je einen Puls senden. Je nach Breite der der Sendedioden können sich die Bereiche auch etwas überlappen. Die Ausrichtung der IR LED auf den RP wird dann nicht mehr wichtig. Für wenig Streulicht sollte man auch eher den Strahl noch oben und ggf. unten begrenzen.
Die IR Detektoren geben nicht viel mehr als die An/Aus Information - ein bisschen mehr kriegt man über die Länge des Impulses - ein starker Puls wird etwas länger sein. Den Effekt könnt man ggf. noch etwas verstärken, indem der Sender keine gleichmäßigen Impulse sendet, sondern etwa solche mit ansteigender Intensität (etwa das Tastverhältnis von 1% bis 30% hochfahren). Dann wäre es aber wohl einfacher wenn man den Sender auch mit einem µC ausrüstet. Über die Drehung des Detektors und den Winkelbereich über den man das Signal noch empfängt bekommt man eine grobe Schätzung der Intensität. Dafür ist dann die Optik beim Empfänger aber relativ wichtig. Wenn man die Intensität wirklich messen will, müsste man die IR Detektion wohl schon von Hand aufbauen: etwa Fototransistor/Fotodiode - Verstärker mit Filter - AD Wandler , und dann eher mit weniger Modulationsfrequenz (z.B. 10 kHz), damit der A/D und µc mit der Auswertung nachkommt. Ob man jetzt 1 oder 2 Detektoren nutzt macht keinen so großen Unterschied - mit 1 Detektor muss man halt ggf. den Bot als Ganzes drehen. Mit 2 Detektoren geht es vor allen schneller, weil man ohne Drehen für die Richtungssuche gerade auf das Ziel zufahren kann. Mit nur 1 Sensoren müsste man wohl eher so eine Art Schlangenlinie fahren - bei schlechtem (ungleichmäßigen) Untergrund wird dass ggf. schon eine Herausforderung, wenn man sich nicht zu 100% auf die Odometrie verlassen kann.
Gegenüber eine einfache Glühbirne hat der IR Sender aber schon auch noch Vorteile: Der Stromverbrauch kann relativ niedrig sein, und das Signal ist gut von Hintergrundlicht zu unterscheiden. Mit dem Hintergrundlicht dürften die LDRs so ihre Probleme haben.
Hi Rolf,
ob ich Dich mag oder nicht weiss ich nicht. Ist auch nicht kriegsentscheidend. Was ich definitiv nicht mag, sind Deine ANTWORT – beiträge. Von threads die Du angefangen hast kenne ich nur wenige, kann es also nicht beurteilen, Deine antwortbeiträge habe es aber ich sich.
Ich wurde hier mal gefragt – ich glaube sogar von Dir – was ich denn vom forum erwarte. Meine damalige antwort möchte ich etwas präzisieren:
wie schon gesagt - keine fertigen lösungen, das ist auch nicht der sinn eines forums, sondern hilfreiche, verständliche, nicht zu theoretische antworten und tipps
wenn jemand eine frage stellt, hat er ein problem oder weiss nicht weiter. Ihn dann zusammenzufalten und auf bildungslücken hinweisen hilft nicht weiter (wie beim transformer z.b.). Nach solcher behandlung kommen die leute nicht wieder.
wenn jemand ein projekt (wie die IR-bake z.b.) aufsetzt und an einem bestimmten punkt nicht weiter kommt und nach tipps fragt, hilft ihm ein vergleicht mit einer LDR-lösung nicht - er will ja eine IR-bake. Das kann man als eigensinnig, überheblich bis dumm bezeichnen, diese art von hilfe ist aber auch nicht hilfreich.
Der antwortender soll (muss!) sich auf den level des fragenden begeben, rückfragen zulassen und geduldig beantworten (gibt’s beispiele hier). Hinweise auf andere threads sind auch hilfreich. Wenn der hilfe leistender das nicht kann (gibt’s auch beispiele hier), sollte er besser nicht antworten.
Um zum „persöhnlich-nehmen“ zu kommen. Wir agieren hier alle - mehr oder weniger anonym durch unsere nicknames – als personen, es geht vordergründig um sachfragen und sachantworten. So weit so gut...
Es gibt aber kaum etwas in Deinen antworten wodurch man sich nicht persönlich angegriffen und runtergemacht fühlt. Und man muss schon eine menge selbstbewusstsein und courage haben um nach so einer „antwort“ noch eine eine frage zu stellen. Das müsste in einem forum aber auch anders möglich sein...
Und nun versuche ich doch noch auf Deine einzelnen punkte einzugehen:
Annahmen:
bauteile haben keine toleranzen
die strahlung der 5 IR dioden bildet in horizontaler richtung ein halbkreis mit relativ homogenem IR-licht
in der vertikalen richtung ist es im querschnitt eine keule, ich habe also im endeffekt eine „halbkreis-keule“, bei abgeschaltetem blinker in etwa gleichmäßig ausgeleuchtet
durch den einsatz von reflektoren und abschirmungen an den IR-dioden entstehen einzelne, sich teilweise evtl. überlappenden keulen in einem halbkreis
durch den einsatz des blinkers enstehen bereiche, die zeitweise intensiver leuchten als andere, dadurch wird das ansprechen des empfängers beim erreichen/überschreiten der ansprechschwelle des empfängers und das „ausrichten“ des empfängers auf die dioden möglich
die IR-dioden erzeugen an wänden / gegenständen reflektionen. Diese überlappen sich untereinander und auch mit den „original“ strahlen, sind aber unregelmäßiger als diese und auch schwächer
durch das anbringen der abschirmung am empfänger erleichtere und präzisiere ich die ausrichtung des empfängers auf eine der sendenden dioden (achsen deckungsgleich), ohne den RP6 daran zu hindern sich die am nächsten liegende der 5 dioden auszusuchen
ich nehme auch an, dass es aufgrund der o.g. unterschiede der original IR-strahlen und der streuungen und reflektionen reicht, wenn die software in einer bestimmten zeitspanne eine bestimmte anzahl von regelmäßigen signalen empfängt um zu erkennen – dass es die stahlung der bake war und keine reflektion...
btw: beim abnehmen der reflektoren an den sendedioden und am empfänger ist ein empfang mit der bake-such-software – auch auf geringere entfernung - nicht möglich, alle IR- signale werden dann offensichtlich schwächer und unregelmäßiger und damit den reflektionen ähnlicher
Du musst mich auch nicht mögen und ich muss technische Aspekte nicht Zugunsten deiner "Fan-Gemeinde" unter den Teppich kehren.
ich wusste garnicht dass ich hier eine „fangemeinde“ habe, ich schätze es ist eher nicht der fall. Auch wenn die beiden RN-artikel doch recht oft aufgerufen werden, was mich natürlich freut. Ansonsten siehe oben – meine erwartungen...
ich VERGLEICHE deine "Bake" mit einem LDR-Empfänger für sichtbares Licht/Lampe denn es ist egal welche Farbe das Licht hat, es hat immer die gleichen physikalischen Grundeigenschaften und daher ist der Vergleich auch nicht so falsch. Auch wenn dir das nicht in den Kram passt!
Der vergleich ist ja evtl. garnicht falsch. Wenn ich aber mit einem ultralite fliegen möchte nutzt mir ein vergleich mit einer cesna recht wenig. Ansonsten siehe oben – meine erwartungen...
Davon abgesehen könnte man den ganzen Aufbau auch einfachst nachstellen indem man den RP6 (http://www.rn-wissen.de/index.php/RP6) dazu bringt auf eine IR-Fernbedienung zu zu fahren auf der Tasten gedrückt sind. Das auch am IR Empfänger ein Reflektorröhrchen sitzt ist mir tatsächlich entgangen. Aber das ist nur ein Nebensatz/Aspekt aus meinem Post.
Im gegenteil, die abschirmung am empfänder spielt in meinen überlegungen eine entscheidende rolle.
Es ist echt zwecklos dir etwas vermittel zu wollen wenn du das in persönliche Angriffe ummünzt! Und bevor du dich komplett im Ton vergreifst, les dich erst mal schlau oder erkläre hier nach welchem physikalischen Grundprinzip ausser Try & Error deine "Bake" genau funktioniert! Und selbst wenn es nur Try & Error eines einäugigen IR-Lichtsuchers ist.. wieso hast Du ein Problem das offen zu sagen?
Ich habe nie behauptet dass es sich bei meiner IR-bake um eine bis zum letzten punkt durchgerechnete lösung handelt. Ich tue mich beim rechnen etwas schwer, ich probiere lieber und schätze ab. So, wie der RP6 in diesem fall: findet er die bake nicht, dreht er halt noch eine runde oder fährt ein stück weiter...
Deine Bake funktioniert nur genau dann wenn der RP6 (http://www.rn-wissen.de/index.php/RP6) und EINE der Senderdioden genau aufeinander ausgerichtet sind weil der RP6 (http://www.rn-wissen.de/index.php/RP6) genau dann definierte Pulse erkennt.
Nur dann. Genau so ist es... Und?
Wozu aber dann 5 Dioden in 5 Richtungen die sich gegenseitig kaum beinflussen aber die ganze Gegend mit IR Licht verschmutzen? Dummerweise reagiert dein RP6 (http://www.rn-wissen.de/index.php/RP6) nämlich auch auf IR-Streulicht welches du mit jeweils 4 Dioden zusätzlich produzierst um es dann elegant durch die Röhren abzuleiten damit es eben nicht auch auf den RP6 (http://www.rn-wissen.de/index.php/RP6) trifft!
Der roboter steht irgendwo im raum und weiss nicht wo die bake ist. Er fährt ein stück, dreht sich und versucht die IR-strahlung zu finden. Es ist sicher besser, wenn er die möglichkeit hat einen von 5 vorhandenen strahlen zu finden als einen einzelnen, daher die 5 dioden
Dein Entwurf ist nicht durchdacht, Inka. Das kann man wie gesagt mit jeder Fernbedienung und im Kreis drehen bis der RP6 (http://www.rn-wissen.de/index.php/RP6) ein Signal bekommt, nachstellen... Versuch es doch einfach mal mit einem Reflektor und Linse aus einer Billig-led-taschenlampe und EINER (1) IRLED... Oder 5 leds genau in die gleiche Richtung. Nur schlecht wenn der RP6 (http://www.rn-wissen.de/index.php/RP6) dann nicht in der Leuchtachse der LEDs steht.. aber das kannst Du auch nicht mit 5 EinzelLEDS verhindern die in 5 verschiedene Richtungen zeigen! 2. Denkfehler! Und auch nicht mit einem Sensor anmessen, der nur Signal oder kein Signal kennt. 3.Denkfehler!
O ja, der entwurf ist durchdacht:
bei der fernbedienung hätte ich schon probleme den knopf so lange gedrückt zu halten, aber spass bei seite...
5 in einer richtung ist zwar mehr leistung, aber wozu? Durch das pulsen /blinken habe ich doch meine reichweite...
Der RP6 dreht sich ja, damit er die beiden achsen (sender und empfänger) möchlichst deckungsgleich aufeinander bekommt
der IR-sensor am RP6 hat auch eine bestimmte ansprechschwelle ab der er erkennt, wann die diode für in „an“ ist, also wann die zwei achsen deckungsgleich sind. Das einzige problem hier ist, dass er evtl. zu schnell dreht und zu spät merkt, dass das eben der fall war...
Übrigens, das ausrichten der sende-diode und des empfängers aufeinander ist eines des schwierigsten probleme bei der bakesuche überhaupt. Auf die 5m bedeutet eine abweichung von 30'' wieviel in bogenmass? Genug um die bake zu verlieren, ohne es gerechnet zu haben – ich habe es erlebt...
Um es klar zu sagen: Du versuchst hier im Sender die Eigenschaften eines omnidirektionalen und eines punktförmigen Strahlers in einem Gerät zu vereinen, und die grade aktuell vorherrschende Eigenschaft (quasi Winkel abhängig?) durch einen rein digital arbeitenden Sensor, welcher keine Information zur Signalstärke liefert, zu erkennen um daraus dann eine Richtung abzuleiten.
Im gewissen sinne schon, nur muss ich die signalstärke nicht absolut messen, weil der RP6 am ansprechen des empfängers merkt – achsen deckungsgleich, oder nicht. In gewissen grenzen ist es auch egal mit welcher signalstärke er das merkt– von dieser hängt nur die überbrückbare entfernung ab. Die empfangene signalstärke muss nur über der ansprechschwelle liegen...
Ein Ansatz der einem doppelten Paradoxon gleich kommt. Was ist daran nicht Try&Error? Weisst Du eigentlich warum die IR Sendedioden fürs ACS auf dem RP6 (http://www.rn-wissen.de/index.php/RP6) in der Leistung umschaltbar sind? Weil die damit dimmbar sind... und man dosiertes Licht auf dem IR-Chip geben kann! Wäre die Empfindlichkeit des Chips einstellbar oder sogar die Signalstärke zu messen, hätte sich Slyd diesen Kniff klemmen können...
es ist try & error...und ich weiss nicht was SlyD gerade macht :-)
Fährst du eigentlich mit aktivem ACS da in den Videos rum, verträgt sich ACS mit deiner Bake? Auch keine ganz so uninteressante Frage...
da kommt es darauf an, aus welchem programm die bakensuche aufgerufen wird. Es wäre empfehlenswert die bakensuche und das ACS nicht gleichzeitig zu betreiben...
Sieh es ein.. oder lass es...
danke gleichfalls...
Ein Ansatz der einem doppelten Paradoxon gleich kommt. Was ist daran nicht Try&Error? Weisst Du eigentlich warum die IR Sendedioden fürs ACS auf dem RP6 (http://www.rn-wissen.de/index.php/RP6) in der Leistung umschaltbar sind? Weil die damit dimmbar sind... und man dosiertes Licht auf dem IR-Chip geben kann! Wäre die Empfindlichkeit des Chips einstellbar oder sogar die Signalstärke zu messen, hätte sich Slyd diesen Kniff klemmen können...
es ist try & error...und ich weiss nicht was SlyD gerade macht :-)
Der wundert sich, aber hält sich hier raus und hat hier auch nicht alles en detail gelesen ;)
Allerdings kurz dazu warum man verschiedene Sendestärken einstellen kann:
Je nach Oberflächeneigenschaften der Hindernisse ist die Reichweite des ACS unterschiedlich.
Man kann das damit anpassen.
(gab ja auch schon Tests oder zumindest die Idee die Entfernung zu Hindernissen damit in mehreren
Stufen abzuschätzen)
Sind übrigens sehr geringe Sendeleistungen, sonst wäre die Reichweite viel zu hoch gewesen.
Das kann man auch bei Baken so machen und die Sendeleistung einfach experimentell so anpassen dass
Reflektionen nicht mehr stören.
Übrigens ist diese Bauart mit mehreren Sendedioden und dem abgeschirmten Empfänger bei Baken ganz
normal und üblich.
Allerdings wird oft auch in der Bake ein Mikrocontroller verwendet und codiert gesendet.
Dann kann man teilweise sogar mehrere Baken gleichzeitig - oder zumindest in verschiedenen Bereichen
einsetzen und diese voneinander unterscheiden.
Das kann man beliebig weiter treiben - mehrere TSOP Empfänger, ggf. mehrere Sendefrequenzen,
mehrere Sendebaken, rotierend, jede Bake sektorweise unterschiedlich codiert usw.
Als Anfang passt das was Inka gebastelt (er macht das ja nicht als prof. Entwickler sondern zum Spaß!) hat aber schon.
Verbesserungspotential gibts immer.
Es wäre empfehlenswert die bakensuche und das ACS nicht gleichzeitig zu betreiben...
IRCOMM und ACS funktionieren auch parallel - aber wie gesagt da wäre eine
Codierung der Sendesignale notwendig und der Kram sollte kurze Pausen einlegen...
Mit dem IRCOMM (und für kürzere Reichweite ACS) könnte man übrigens sogar bidirektional mit den Baken
kommunizieren und sie nur bei Bedarf anschalten :p
MfG,
SlyD
@Inka
Ok deine technische Sicht hast Du dargelegt.. ich seh da ein paar Sachen anders und habe das auch begründet ausgeführt...aber gut... ich will nicht mit Dir diskutieren ob (d)eine Lösung funktioniert, schon deshalb weil DEINE Anforderungen zum Thema Bake kaum verallgemeinerbar sind. Und damit ist das auch schon erledigt.
"kriegsentscheidend" ist hier garnichts denn es gibt kein Krieg im Forum! Es geht hier nur um technisches bezüglich dem RP6 + Anbauten.
Ich persönlich - nicht anonym, jeder kann und darf mich hier per PN nach meinem vollen Namen fragen - bin der Meinung, das es besser ist wenn man jemandem den Weg zeigt sich selbst zu helfen als Lösungen vorzukauen oder ohne nachdenken zu übernehmen. User Transformer habe ich in dem Zusammenhang in 2 Posts deutlich darauf hingewiesen, das er sich erst mal mit Grundlagen beschäftigen soll bevor er Dinge anpackt mit denen er offensichtlich weit überfordert ist. Und auch da gabs wie in fast allen meinen Posts Ratschläge wie er es besser als bisher machen kann. Es ist allerdings nicht mein Job Leute von ihrer Dickköpfigkeit zu kurrieren und ich schreibe hier nicht um Leute zu triezen! Leider lesen sich deine Vorwürfe gegen mich aber so.
Wegen Probleme wie Verlust der Bake im Bogenmaß bekommst du von allen Seiten und nicht nur von mir alternative Vorschläge... vielleicht setzt du auch mal welche davon um. Ich sagte schon mal in einem meiner früheren Posts hier, das die Bake in dem Stadium nur der erste zaghafte Schritt sein kann. Wenn Dir das langt.. ok.
Kritik mit patzigen Reaktionen zu beantworten ist eine Unart von Leuten die meinen sie wüssten genug oder bräuchten sich sonst wie nichts sagen zu lassen.
Wer das so sieht.. ok.. warum nicht. In der Tat - wir beide hatten das Thema schon ... und ich hab den Fehler gemacht mich nicht an meinen Vorsatz zu halten. Es geht hier aber nicht um irgendwelche Deppen die sich um des kloppen Willens kloppen, sondern um technische Information, die man vielleicht auch in 1 oder 2 Jahren noch zu dem Thema nachlesen möchte!
Es geht hier nicht um Recht haben/bekommen sondern um das was "zu bedenken" ist wenn jemand seine eigene Lösung baut. Spätestens da ist deine Reaktion auf den einen oder anderen Post - insbesondere wenn er Kritik enthält, was auch immer Du als Kritik empfindest - äußerst unangebracht!
Bleiben wir also im Forum beim technischen Thema und lassen den persönlichen Kram und/oder schreib mir per PN wenn Du meinst das es nötig ist!
Mit dem IRCOMM (und für kürzere Reichweite ACS) könnte man übrigens sogar bidirektional mit den Baken
kommunizieren und sie nur bei Bedarf anschalten
Was aber eine aktive CPU a la ATtiny in der Bake erfordert ... das ist bereits mehrfach und aus verschiedenen Gründen vorgeschlagen worden. Unter anderem für Bake-Bake und Bake-RP6 Kommunikation. Ich würd sogar noch eins draufsetzen und die Bake ein Servo mit einem IR-Sende/Empfangskopf durch den Raum führen lassen so das auch das leidige Bogenmaßproblem erschlagen wird.. vielleicht noch ein Receiver aus 3 Fototransitoren für eine Art inverser 3-Punktnavigation auf dem RP6 ... aber dann bin ich wieder nur der böse Buhmann, der versucht andere User zu bevormunden und die "Designvorgaben" für die Bake nicht einhält!
Gruß
hallo Rolf,
ich hätte da eine idee:
ich selbst fühle mich nicht in der lage dazu mit meinen kentnissen und fähigkeiten die IR-bake im sinne Deiner vorschläge (oder denen von SlyD) zu erweitern....
Möchte Dich aber dazu einladen, mit mir zusammen - oder auch allein, an einer verbesserung zu arbeiten (ich persönlich würde die variante der zusammenarbeit bevorzugen). Man würde dann quasi das zweite kapitel des artikels "IR-bake" schreiben. Das angebot an fertigen, gut funktionierenden IR-baken ist wirklich sehr überschaubar und ich glaube es gibt hier bedarf an beiden versionen, die eine so zu sagen für den "hausgebrauch", für die anfänger und bastler, die andere für die fortgeschrittenen....
Was hälst Du davon? Was halten die mitlesenden davon?
Was halten die mitlesenden davon?
das Thema Bake ist eigentlich schon durch. Das Rad neu zu erfinden, halte ich für nicht nötig. Trotzdem ist es nicht verkehrt, eigene Erfahrungen zu machen.
Allerdings sollten sie dann nicht ungeprüft als neuer Standard stehen bleiben. Deswegen fand ich Rolfs Kritik angebracht, war aber abgeschreckt von der Reaktion darauf.
Mit 2 555ern kannst du eine leidlich funktionierende Bake bauen, ok, aber genaue Frequenzen ohne aufwendige Kalibrierung kriegt man damit leider nicht hin.
Die Bake selbst sollte punktförmig in alle Richtungen strahlen, Reflektoren oder Röhrchen schaden da nur. Reflexionen an Wänden sollten möglichst nicht detektiert werden, deshalb muss die Bake etwas mehr Leistung bringen als eine Fernbedienung und der Empfänger entsprechend unempfindlich gestaltet werden. Da kann man gleich eine Abschirmung für die Richtungserfassung anbringen.
Gruß, Michael
Besserwessi
28.05.2014, 17:30
Gegen die Reflexionen an Wänden hilft es nichts wenn man den Signalpegel ändert, indem man Stärker sendet und weniger Empfindlich detektiert. Es bleibt bei einem gewissen Anteil des Lichtes das auch über umwege ankommt.
Was hilft sind vor allem Änderung der Optik: Ein Empfänger mit geringem Öffnungswinkel, ein Sender der nur in der richtigen Höhe sendet und nacheinander Senden in verschiedene Richtungen. HIlfreich ist da auch ein Empfänger der über einen relativ großen Intensitätsbereich arbeitet, und nicht nur zwischen dunkel und genug Intensität unterscheidet.
Zur IR Bake gibt es sicher schon einiges - das muss nicht neu erfunden werden. Die Version im RN Wissen ist bis jetzt noch aller unterster Level - das sollte noch einiges besser werden um eine wirklich HIlfe zu sein. Der Thread hier ist aber schon reichlich lang, um auf Seite 13 noch einmal mit den Grundlagen und einem neuen Entwurf anzufangen.
Ich find den Vorschlag von Inka klasse!
Dabei gibts zu bedenken: Die Geschichte mit Seite 13.. wie auch schon einige Vorschläge hier im Thread .. eigentlich gibts ja schon Erfahrung mit Projekten die Userbeteiligung haben. Siehe Fabians alias fabqus io-board und die Thread dazu.. ich schreib mal die Seitenzahlen dabei um auch zu zeigen, das so ein Projekt mit 50 Seiten Forum normal ist wenn sich genügend User interessieren.
https://www.roboternetz.de/community/threads/59797-Kleinserie-hardware-f%C3%BCr-die-M256-WIFI (23 Seiten)
https://www.roboternetz.de/community/threads/60892-Kleinserie-Multi-IO-Platine-f%C3%BCr-das-Forum (4 Seiten)
https://www.roboternetz.de/community/threads/61293-Software-Fragen-zur-Multi-IO?highlight=fabian+io-board (21 Seiiten)
Dort ist aber nachzulesen, wie das IO-Board sich letztlich entwickelt hat, und kann daher auch als Beispiel für weitere Projekte dienen. Ich halte es auch für wichtig, das Du inka die Regie über das Projekt v2.0 machst einfach weil du schon Erfahrung mit Bake 1.0 hast.
Mein Vorschlag an Dich Inka daher... schau dir das Projekt io-board mal an... erstell dann ein neuen Forenthread ein.. zunächst mit dem Hinweis auf Bake v1.0 und allen verlinkten Infos dazu.. und ruf dann zu einem allgemeinen Brainstorming für eine Bake V2.0 auf. Mit etwas Glück und genügend Userbeteiligung bekommen wir alle gemeinsam hier dann vielleicht eine Bake hin, die man auch wirklich nachbauen will. Und geh mal davon aus, das wir alle hier noch lernen.. in der einen oder anderen Weise.
Ich unterstütz das gern wo es geht aber ich hab auch eigene Projekte an der Backe und werde ggf. zu denen gehören, die später dann ein Bausatz der Bake 2.0 bei dir erwerben (siehe io-board).
Überleg dir das mal in Ruhe...
Gruß
radbruch
28.05.2014, 19:22
Hallo
Ein sehr guter Vorschlag. Auch dass wir wieder zum RN-Umgangston zurückgefunden haben finde ich klasse. Wenn Bake 2.0 im RP6-Bereich eröffnet wird könnte ich das auch moderieren (,wenn's gewünscht/benötigt wird).
Gruß
mic
Hallo Baken-Interessierte,
ich würde mich auch an einem Baken-Projekt "V2.0" auf der RP6-Seite (Soft-/Hardware) beteiligen.
Eine Moderation von radbruch wäre klasse und als Projekt-Leitung ist inka die beste Besetzung.
Wünschen würde ich mir (erstmal unabhängig vom Projekt-Inhalt selbst):
- Einen lockeren Umgang miteinander (es geht um ein Projekt im Hobby-Bereich, das Spaß machen soll!)
- Eine "Gruppe" von Haupt-Beteiligten (vorab feststehend!)
- Eine Planung und "Leistungsbeschreibung"
- Eine gemeinsame Entwicklung (evtl. mit Aufgabenteilung)
- Ein Ergebnis, das in Form eines RN-Wissen-Artikels und ggf. bestellbarer oder nachbaubarer Hardware, allen im RN zur Verfügung steht
Hallo allerseits,
Ich glaube wir werden nicht mehr allzuviele reaktionen auf meinen vorschlag bekommen...
danke erstmal für die antworten auf meine frage nach der realisierung einer bake v2.0. und für das vertrauen in meine fähigkeiten als projektleiter. Werde mein bestes geben.
Die rückkehr zum normalen ton im RN-forum ist mir auch sehr wichtig, deshalb auch der vorschlag den ich in meinem letzten post gemacht habe. Damit sollte eine konstruktive zusammenarbeit zwischen den „streithähnen“ ermöglicht werden...
Aus den posts zu meinem vorschlag kann man schon die unterschiedlichen meinungen zur lösung der technischen probleme erkennen, bin mir nicht ganz schlüssig wie man solche sich schon sehr widersprechenden erfahrungen in das projekt aufnehmen kann. Es werden im laufe des projektes sicher auch noch andere ideen und vorschläge kommen, die natürlich auch willkommen sind und werden, sofern in der laufenden projektphase noch möglich, berücksichtigt...
Als hauptbeteiligte würde ich die user vorschlagen, die sich bereits zu wort gemeldet haben:
Besserwessi, Dirk, Michael, Radbruch, RolfD und ich. Jeder nach seinen zeitlichen und fachlichen möglichkeiten. Dazu sollten sich alle hier genannten noch einmal äußern, damit das im neuen thread (siehe weiter unten) berücksichtigt werden kann...
Da ich als projektleiter keine entscheidungen allein treffen möchte, würde ich ein verkleinertes „gremium“ vorschlagen, das diese entscheidungen über die qualität des erreichten bzw. den weiteren verlauf des projektes trifft: RolfD, Dirk und ich.
Es wird sicher nicht möglich sein eine bake für alle anwendungen und user zu entwickeln, man sollte versuchen das optimum zwischen funktion und kosten/aufwand zu erreichen...
Zum brainstorming würde ich vorschlagen, dass es noch hier in diesem thread stattfindet, ich würde dann anschließend einen neuen thread eröffnen mit den punkten auf die sich die hauptbeteiligten geeinigt haben (quasi die projektvorgaben) und gleichzeitig einen RN-artikel aufmachen, in dem der entwicklungsprozess beschrieben wird, das ist dort meiner meinung nach übersichtlicher darstellbar.
Folgende punkte würde ich zum brainstorming zum projekt bake 2.0. beisteuern (die basieren natürlich ausschließlich auf meinen erfahrungen bei bake 1.0.!):
IR – ja/nein
wenn kein IR was dann?
Laserdiode? siehe z.b. hier (http://www.ebay.de/itm/Neu-650nm-6-mm-DC-5V-5mW-Mini-Laserdiodenmodul-Laser-Head-Laser-Diode-Modul-Rot-/291034572699?pt=Licht_Effekte&hash=item43c303279b) (würde auch mit dem RP6 lichtsensor funktionieren, habe ich kurz angetestet), würde wahrscheinlich keinen reflektor brauchen (sendet punktförmig, reichweite von sich aus schon sehr groß)
microprocessor atmega 8 (weil ich ihn vom asuro her kenne) um die bake z.b. über I2C oder BT einbinden zu können
wenn kein atmega 8 was dann?
5 (im halbkreis angeordnete) leds, nacheinader sendend (Ir – oder laser), oder
eine led drehbar (servo), blinkend sendend
spannungsversorgung über USB
maximaler verbrauch der bake 400mA
den anschlus eines BT-moduls vorsehen
RoboHolIC
01.06.2014, 15:20
Hallo inka.
Ich möchte Dich bzw. Euch ermutigen, ruhig noch einen Schritt mehr zurück zu treten und grundsätzlichere Betrachtungen anzustellen, so wie man das in einem Lasten-/Pflichtenheft macht. Welcher Controller und welche Funktechnologie, das ist in diesem Moment doch schnurz; manches wird sich aus der Anforderungen ergeben bzw. von selbst verbieten.
Die Fragen sollten momentan eher in diese Richtungen gehen:
- Was genau soll(en) die Bake(n) können
- Bake als Einzelsystem oder ein komplexerer Navigationsverbund?
- Wird ein Routing des mobilen Fahrzeugs durch die Baken gewünscht
- Indoor oder/und Outdoor?
- Welche Technologie ist die geeignetste für die Übertragung?
Vielleicht gehen meine Fragen an der Realität vorbei, aber ich würde zunächst auf dieser Ebene brainstormen und ein Konzept erstellen.
Denkt ruhig groß (modular, universell) in Hard- und Software. Es ist ziemlich lästig, die ersten Erfolge mit 20 LOC (Lines of Code) zu erzielen und dann zu merken, dann die nächste Stufe bei 200 LOC, die übernächste vielleicht erst bei 2000LOC liegt und dazwischen wiederholt aufwendige Umbauten nötig sind.
Fassen wir mal zusammen, was da ist...
Der RP6 hat ein IR System mit Sender und Receiver onboard. Dazu gibt es bereits den IR Morsetreiber, ich glaube von Dirk. http://www.rn-wissen.de/index.php/RP6_-_Morse-Code
Zudem sind Protokolle wie RC5 und ähnliche vorhanden wie sie jede Fernbedienung mit ca. 5-6m Reichweite produziert. Das Datenübertragungsformat für IRDA wie es manche IRDA-Sticks und ältere Handys nutzen ist komplizierter bzw. kommt auch auf Grund begrenzter Reichweite (30cm-1m) kaum in Frage.
Hat jemand 2 RP6, könnte er also zumindest schon mal einen als Bake in die Ecke stellen und den zweiten darauf reagieren lassen. (So hatte ich mal ein wenig rumprobiert)
Welche andere Lichtsorten haben wir noch? Natürliches Tageslicht, künstliches Licht im sichtbare Bereich und monchromes (Laser) Licht. Wärme (intensives IR) und UV lasse ich mal aussen vor obwohl man Wärme mit einem PIR-Sensor incl. prismatischer Linse auch gut anmessen kann... aber nachher facklet sich noch jemand mit Teelichtern die Hütte ab... lassen wir das also. Microwelle/Radar Langwellen kommt auch nicht in Frage, damit ist aber schon ein Großteil der elektrischen Schwingung abgedeckt. Die ersten beiden besitzen als Lichtquellen verwandte Eigenschaften, Laser ist dagegen meist extrem fokusiert, hat aber daher auch den Nachteil, das man es schlecht anvisieren kann. Laser wäre was für auf den Bot zu montieren, wenn zusätzlich eine Kamera den Lichtpunkt vermessen würde. Laser ist zudem als Lichtschrankensystem sehr gut geeignet. Laser macht also dann Sinn, wenn man weis wo der Strahl landen sollte...aber auch nur dann. Ich stelle mal die Arbeitsthese auf, das alle Lichtsorten ausser Laser im Prinzip als Kugelstrahler die gleichen Reflektions- und Brechungseigenschaften haben... und man daher z.B. auch normale LEDs oder Lampen verwenden _könnte_ .. zumindest um sich die Eigenschaften des unsichtbaren IR-Bündels vorstellen zu können. Daran ändert auch der Umstand nur wenig, das man zusätzlich Linsen und Reflektoren verwendet. Es gibt dann noch die Möglichkeiten per Kamera Licht zu detektieren, allerdings ist das zu aufwändig da dies nach Bildauswertung verlangt.
Es gibt ja grundsätzlich 2 Verfahren zur Entfernungsmessung. Triangulation von Feldstärke und Messung der Signallaufzeit. Für Leuchttürme spielt noch die Erdkrümmung bzw. Sichtachse über Horizont eine Rolle (wesshalb die auch so nette Streifen aufgemalt haben bzw. deren bekannte Höhe über n.N. so wichtig ist) aber die können wir in Zimmern und Gärten glaube ich vernachlässigen :). Die Signallaufzeit ist bei Licht und Funk mit unseren Mitteln kaum zu messen.
Was gibts noch für Signalquellen für Nahortung? Datenfunk im 433MHz Band und Oberwellenbänder fallen eher flach da diese eine Reichweite von üblicher Weise min 100m haben. Blauzahn ist eher geeignet, allerdings bräuchte man ein Blauzahngerät, welches die Feldstärke anmessen und an den Prozessor durchgeben kann. Im Umkreis von 10m könnte man dann zumindest eine Triangulation versuchen, wie es Handyanbieter im großen mit mehreren Sendemasten und dem Handy auch machen können. Dazu wären aber 3 Blauzahn Sender (Mikroprozessorgesteuert) und ein Reciever auf dem RP6 nötig. Die Messgenauigkeit läge in einem normalen Raum von sagen wir mal 4x4m läge bei geschätzen 0,5 bis 1m in jede Richtung. Andere Funksignale sowie GPS kommen nicht in Frage, GPS schon deswegen nicht weil die Lokalvarianz selbst bei freier Sicht auf die Satelliten über Zeiten von mehreren Minuten um 2-10m wandert. Um das zu kompensieren müsste man ein großen Aufwand treiben, der nur für fix montierte Geräte und Geschwindigkeiten wie in der Gletscherforschung vertretbar ist. Für Flugroboter mit einem Aktionsradius von hunderte Metern bis Kilometer macht GPS Sinn, auf einem Kettenbot der magels Batterieleistung kaum weiter kommt als ein mal ums Grundstück zu fahren und dabei 25 mal vom Boardstein kippt weil der Satellit "mal wieder wandert..." - nicht! In wie weit GPS in Räumen Sinn macht kann jeder mit seinem Handy dann noch selbst austesten.
Dann gibts noch den Bereich Schall bzw. Ultraschall. Hier kommt nur Ultraschall in Frage obwohl man technisch auch normalen Schall verwenden könnte - zumindest um sich vorzustellen wie das geht. Nur Ultraschall ab ca. 30 khz hat eine genügend steile Signalflanke bzw. kurze Wellenlänge um daraus mit technischen Mitteln Laufzeitinformationen zu erfassen, das menschliche Ohr schafft das schon bei deutlich tieferen Frequenzen und in erster Linie über stereo hören und Laufzeitunterschieden durch die Kopfbreite/form bedingt. Stereoschallverarbeitung ist ebenfalls ein spannendes Thema aber hier für die Bake und einfache Mono-Systeme eher nicht relevant, wäre aber auch sehr gut nutzbar wenn man den Aufwand nicht scheut.
Mit einem SRF08 und ähnliche Reflexsensoren kann man recht genau und über Reichweiten von ca. 6-10m ... also Schallaufwege bis 20 m seine Umgebung erfassen. Man müsste sich eine Art Karte seiner Räumlichkeit anlegen und Bewegungen im Raum durch vermessen markanter Punkte festlegen. Ich persönlich halte dies für die effizienteste Möglichkeit zu navigieren, allerdings geht das am Konzept einer Bake vorbei und ist aufwändig in Software. Schall ansich eignet sich allerdings auch anders genutzt für Baken da Schall im Gegensatz zu Licht eine messbare Laufzeit hat. Produziert eine Bake z.B. einen Lichtpuls und gleichzeitig einen Schallimpuls, kann man durch die Laufzeit recht genau sagen, wie weit die Bake vom RP6 weg ist. Jeder kennt das Verfahren um zu ermitteln wie weit ein Gewitter weg ist. Elektrisch gesehen würde man dort aber den Funkimpuls zum starten der Zeitmessung verwenden da nicht vorhersagbar ist, wo der Blitz auftaucht. Mit 2 Baken der Art welche sich nicht behindern, kann man schon sehr genau seine Position im Raum festlegen. Problematisch daran sind Schallreflektionen aber da der schnellste Weg immer der kürzeste ist, darf man eben beim Schall messen nur das erste eintreffende Signal verwenden. Da man die Entfernung aus der Schall Laufzeit errechnet, entfallen auch Maßnahmen zum fokusieren und ausrichten wie bei Licht. Die Messgenauigkeit dürfte bei wenigen Zentimetern liegen und mit größerem Abstand abnehmen. Man muss jedoch mit dem nächsten Klick warten bis wieder "Ruhe" im Raum ist, das liegt aber in Räumen im Millisekundenbereich. Nutz man z.B. ein Impulspaket von 4 bis 16 dicht aufeinander folgenden Impulsen + Ein- und Ausschwingen , ist es auch recht eindeutig von Umgebungsschall zu isolieren.
Sinnvoll wäre also eine Bake, welche einen IR Puls aussendet und gleichzeitig einen Ultraschallklick. Der RP6 müsste diesen IR Blitz (bei dem es dann auch nicht auf Reflektion ankommt) einen Messvorgang starten und über einen Ultraschallsensor die Signallaufzeit ab Startblitz berechnen. Davon 2 Stück im Raum und der RP6 kann aus den Laufzeiten seine Position zu den Baken errechnen. Was er damit erst mal nicht rausbekommt ist seine Rotation zu den Baken. Dafür braucht man wieder ein Kompas oder müsste es als Messung über Zeit und Bewegung wie herkömliche Navis errechnen. Der Vorteil, das Ganze kann von einem Punkt aus (Bake) gesteuert werden denn man braucht keine 2 Baken, sondern nur eine sowie einen weiteren externen Ultraschallgeber, der im simpelsten Fall einfach nur an einem langen Kabel hängt. Die Steuerung muss dann abwechselnd die beiden Schallgeber betätigen und bei jedem Schallklick ein IR-Blitz abgeben.
Das System wäre mit 2-3 Ultraschallgebern und einem IR Geber recht einfach analog aufzubauen.
Baut man da jedoch ein Prozessor ein, kann man sich durchaus Erweiterungen überlegen. Z.B. kommunikation mit dem RP6, wobei es da nur auf eine "piepsen auf Anforderung" hinauslaufen kann da die kleinen (8, 16 und 20 Beine) Prozessoren für viel mehr nicht die Kapazitäten haben. Aber es wäre eine Anwendung, welche mit einem einfachen zusätzlichen Reciever auf der Bake a la RP6 Bauart machbar wäre.
Verbaut man einen leistungsfähigeren Prozessor (ab mega16 oder 32 wie M32/RP6) in der Bake, wäre auch eine umgekehrte Messung mit 1 Schallgeber auf dem RP6 und 3 Schallempfängern (über Kabel mit der Bake verbunden incl. Auswertung der triangulation und Übertragung der vermessenen Raumposition per IR an den rp6) möglich. Es hätte zudem den Vorteil, das der RP6 seine Position nicht selbst bestimmen muss und er daher auch diesen Code nicht braucht. Ohne eine räumliche Orientierung (z.b. per 2-dimensionales Array oder Vektoren) wird man da allerdings auch nicht auskommen.
Das Verfahren funktioniert übrigends auch in 2 oder mehr Räumen ... entweder mit mehreren Baken die sich versuchen zu syncronisieren.. per Blauzahn oder Datenfunk... oder eben mit einer Bake und weitere kabelgestützte IR-Blitzer und Schallwandler.
Man kann nun jetzt noch überlegen ob man sich ein SRF Reflexsensor auf den Bot baut um quasi das Ultraschallsignal passiv in der Bake auszuwerten. Diese haben aber doch recht starke Richtcharakteristika ähnlich der Lichtkegel von LEDs. Sinnvoller können da Hochtonkalotten als Signalgeber aus dem Hifi-Bereich sein da diese bessere Rundstrahleigenschaften haben. Es ist auch nicht ganz einfach, bei einem SRF08 den genauen Zeitpunkt des Signalstartes raus zu bekommen da dieser mit einem eigenen Prozessor autark misst. Das Ding hat zwar ein LDR Sensor onboard aber ein Lichtimpulsgeber wäre für die Anwendung sinnvoller gewesen. Die Formel lautet aber: Um so weniger "Richtung" die Komponenten haben, um so einfacher und zuverlässiger wird die Messung!
Alle Verfahren, die nur rein auf Lichtauswertungen basieren, müssen spätestens dann scheitern wenn keine direkte Sichtverbindung besteht. Optisch-akustische Verfahren, welche sich zudem (Licht)Reflektionen auch noch zu Nutze machen, sind in der Nahbereichsnavigation (30cm bis 15m) immer im Vorteil. Allerdings braucht man ausreichend empfindliche Schallempfänger damit man auch garantiert den Ton/Klick (und natürlich auch den IR Blitz) mit definierten Eigenschaften zweifelsfrei mitbekommt. Für Navigaionen im freien (z.B. im Garten) würde man aber wohl besser Blauzahn/Datenfunk und Feldstärketriangulation nutzen da Schall ab ca. 30 m begrenzt ist, so wie auch IR-Licht dort schwieriger zu übertragen ist. Wo Sichtverhältnisse nicht gut sind kann man aber auch per Funk das Startsignal statt IR-Lichtimpuls verwenden wenn man die Datenübertragungszeiten mitberechnet. Auch hier gibts aber Beispiele wie eine DCF Funkuhr oder NTP Dämonen.
Bisher beschäftigen wir uns in Sachen Ultraschall aber nur mit den Signallaufzeiten, auch eine "Feldstärkemessung" über den Pegel des Signals wäre möglich um Störeinflüsse noch weiter zu begrenzen und das Signal zu validieren. Schall kann also 2 Werte aus Eigenschaften liefern die sich nicht widersprechen sollten. Man könnte das aber auch wieder nutzen um den Schallgeber an die Raumakustik anzupassen indem der RP6 den Pegel per IR an die Bake schickt und diese dann z.B. "leiser" oder "lauter" wird um Echos zu eliminieren.
Ansonsten wäre vielelicht die Vermessung mit Laserlicht noch eine Möglichkeit aber da dürften die Messgeräte und Sensoren den Etat der meisten Leute hier sprengen und das Ergebnis wird nicht zwangsläufig genauer. Reine Lichtgeber müssten im fokusierten Lichtstrom immer zusätliche Informationen wie z.B. den aktuellen Abstrahlwinkel übertragen und man kommt von der Kugelcharakteristik weg zu einer Strahlcharakteristik, was immer schwieriger wird zu finden und messen je mehr ich den Strahl fokusiere (extrem Laser). Wie genau man mit Funk und Signal Laufzeiten seine Position ermitteln kann, sieht man übrigends am GPS System. Hochgenaue empfindliche Empfänger können die Position in Langzeitmessungen millimetergenau feststellen, weniger genaue Empfänger nur mit Varianz und auf wenige Meter genau, was angesichts der Entfernung zu den Sendersatelliten schon enorm gut ist!
Mit Licht geht das theoretisch auch den Licht ist ja genau so schnell... praktisch hab ich da so meine Zweifel! Zumindest wenn man in Betracht zieht, das man für den Startimpuls der Messung bzw. zur Erkennung von Differenzen im Datenstrom des Signals kodiert schon eine Atomuhr im Sender oder zumindest einen hochexakten Startimpuls bräuchte... mit einer Auflösung kleiner der Distanz welches Licht in wenigen Zentimetern !!! zurück legt. Da Strom aber nicht schneller als Licht ist, spielen da neben Dämpfungen aber sogar Kabel und Leiterplatten Längen eine Rolle und wir bewegen uns mal eben im Gigaherz Frequenzbereich. Frequenzen die LEDs und in Sperrschichtsättigung gefahrene Transistoren nun mal nicht leisten! Es scheitert da also schon am Signalgeber.
Aus der Funktechnik kennt man noch die logarithmische Regel, das man zur verdoppelungder Reichweite das Signal vervierfachen muss - oder um den Faktor 4 abschwächen damit man die Reichweite halbiert. Man rechnet dort in Decibel - was man auch in der Schallmessung kennt. Es gibt da also durchaus Verwandschaften... und erklärt gewisse Reichweitenbeschränkungen.
Die einzigen Vorteile, die IR Licht für uns gegenüber anderen Lichtsorten hat, ist das es sich einfach durch optische Filter vom normalen Tageslicht abgrenzen lässt und das es leicht in kleinen Mengen herzustellen ist. Etwas was prinzipbedingt jedoch für alle LEDs gilt. Für klarweis ebenso wie rot,blau und grün oder gelb - wenn man jeweils die gleichen Lichtmenge (Lumen) voraussetzt. Spätestens wenn man Leuchtstoffröhren oder LCD-Bildschirme in der Hütte hat, wird man sich wundern, wie viel IR-Energie da zum Teil abgestrahlt wird. IR liegt immerhin recht nah an der Wärmestrahlung wie es Wärmebildkameras anmessen können.
Generell ist bei allen Schallsensoren jedoch zu bedenken, das Tiere den Schall ggf. hören können und darunter auch leiden... wer also mit Schallimpulsen im Ultraschallbereich experimentiert, sollte auch sein Haustier im Blick behalten...
Das war mal eine kurze Zusammenfassung der Möglichkeiten ... natürlich mit Präferenz auf meine Vorstellungen dazu.
Gruß
Christian H
02.06.2014, 16:17
Hallo,
interessantes Thema und bei weitem nicht so einfach wie man zu Beginn meinen könnte. Je nach Anwendungsbereich (innen, außen, ein oder mehrere Räume, erforderliche Genauigkeit) kann mal US, IR oder Camera mit Objekterkennung am geeignetsten sein. Die eierlegende Wollmilchsau die universell anwendbar ist gibt es meiner Meinung nach noch nicht.
Falls Ihr noch nicht darauf gestoßen seid: Der TSOP7000 ist ein IR Sensor der mit 455 KHz arbeitet. Das ist schnell genug um die Winkel einer drehenden IR-Bake auszustrahlen.
Kombinierte IR-US Bake: https://www.roboternetz.de/community/threads/43533-Kombinierte-US-IR-Bake?highlight=CHristian
2 IR Baken: https://www.roboternetz.de/community/threads/43186-IR-Navigation-mit-TSOP7000-2-Drehbaken-15m-Reichweite?highlight=CHristian
Viel Spaß noch!
Beste Grüße
Christian
oberallgeier
02.06.2014, 17:01
... Der TSOP700 ist ein IR sensor der mit 455 KHz arbeitet. Das ist schnell genug um die Winkel einer drehenden IR-Bake auszustrahlen ...Hi Christian, ja das Ding sollte man nicht ausser Acht lassen (Du meinst vielleicht aber den 7000er???). Obwohl ich die TSOP´s nicht nehme, die sind nämlich lausige Arbeiter - brauchen immer wieder ne Pause; der 7000er braucht nach 500µs Bestrahlung mit moduliertem Licht eine Pause ohne Modulation. Da ist die Kontinuität der Information dann doch erschwert.
Wie hattest Du dieses Problem bei Deiner Bake umgangen ?? In Deinen Posts habe ich nix dazu gelesen (oder überlesen???).
Aber Sigo hatte den 7000er ziemlich raffiniert benutzt, siehe seine 180°-Stoßstange. (https://www.roboternetz.de/community/threads/31179-Schnelle-180%C2%B0-IR-Sto%C3%9Fstange-mit-Winkel-und-grober-Entfernung) Und dazu das Test-Video. (http://www.youtube.com/watch?v=AAdm9u9GZCo)
Christian H
02.06.2014, 18:31
Hi Joe,
Du hast natürlich recht, ist der TSOP7000. Der arbeitet auch nicht im Dauerbetrieb, sondern sendet eine Folge von Bytes zwischen denen jeweils eine Pause von 800us ist. Bei 8 MHz lassen sich die 455 Khz folgendermaßen erzeugen:
I = 0
Do 'do-loop für 14 bursts mit 455 KHz
Toggle Portd.5 ' Übertragung von bit = 1
nop 'IR-LED an Portd.5
nop 'Zahl der nops bestimmt burst-Dauer
nop 'ausprobieren evtl 5 oder 6 nop besser
nop
Incr I
Toggle Portd.5
nop 'ausprobieren evtl. 4, 5 oder 6 besser
nop
nop
Loop Until I = 14
Das ergibt 14 Blitze mit etwa 455 Khz und entspricht einem bit=1. Für bit =0 bleibt die LED gleich lang aus. So kann man
ein Startbit =1
einen Winkel (1 bis 128 ), Stellung des Servos auf dem die LED sitzt
ein bit zur Kennung der beiden baken
und ein Stopbit =1 übertragen
14 Blitze mit 455 Khz dauern 30 us
10 bit dauern 300 us
dann 800us Pause >>> etwa jede ms wird ein Byte verschickt.
Die links sollen nur zu Ideen anregen. Ist sicher nicht der Weisheit letzter Schluß. Problem ist immer die Alltagstauglichkeit. Wer will denn schon, falls es um Navigation in mehreren Räumen geht, mehrere Baken aufstellen und betreiben.
Grüße
Christian
Leute,
ich würde meine Wünsche an ein Bakensystem für den RP6 so zusammen fassen (Pflichtenheft):
1. Es soll indoor arbeiten.
2. Die Raumgröße beträgt bis zu 5 x 5 m
3. Mit Hilfe des Systems soll der RP6:
3.1 Seine Position im Raum auf +- 5 cm feststellen können
3.2 Seine Drehrichtung (Yaw) bestimmen können
3.3 Im Raum eigenständig manövrieren können
3.4 Einen Punkt im Raum (z.B. eine Ladestation) eigenständig anfahren können
4. Die Sensoren (ACS...) und die Aktoren (IRCOMM...) des RP6 sollen (soweit möglich) genutzt werden
5. Aktive Baken sollen so aufgebaut sein, dass sie auch durch eine RP6 CONTROL M32 oder CCPRO M128 Zusatzplatine (stand alone) betrieben werden können
6. Die Anzahl von Baken soll bis 8 erweiterbar sein
Das kommt mir alles sehr bekannt vor.................
Ich hole da mal einen alten Beitrag aus der Versenkung:
https://www.roboternetz.de/community/threads/54798-Laser-Positionsscanner
(https://www.roboternetz.de/community/threads/54798-Laser-Positionsscanner)Das ganze lässt sich für 5cm Auflösung viel einfacher aufbauen.
Die Lösung mit der Kombi aus IR und US aus Post #129 gefällt mir obwohl ich denke, das man sie noch deutlich verbessern bzw. vereinfachen kann.
(Rotierende) Laserbaken mögen auch funktionieren aber da halte ich den Bauteileaufwand für zu hoch gemessen an dem was man mehr erreicht als eine IR/US Bake kann.
Aber interessant sind alle Bauvorschläge.
Vielleicht sollten wir noch ein paar Wunschlisten für die Bake sammeln und dann mal durchsprechen, mit welchem Baken-Grundkonzepten man welche Wünsche am besten erfüllen kann.
Meine Wunschliste:
1. Es muss!!! indoor arbeiten, es wäre schön wenn man sie in gleicher Anordnung auch draußen verwenden kann.
2. Raumgröße bis zu 10 x 10 m
3. Position im Raum mit 3 Baken auf +- 5 cm feststellen können
4. ACS und IRCOMM des RP6 Base (http://www.rn-wissen.de/index.php/RP6) sollen genutzt werden
5. Alles so einfach wie möglich, alles was kompliziert oder schwierig anzufertigen ist wird die Verbreitung der Bake behindern.
6. Eine Bake sollte 2 Räume mit je 3 Messstellen/US sendern versorgen können - es reichen mir daher 6 Anschlüsse.
(wobei ich schon ausgeführt habe, das dazu mit dem IR/US Konzept nicht 6 einzelne Baken sondern nur 1 Bake mit insgesammt 6 "Satelliten" notwendig wären die lediglich die Schallgeber enthalten.)
7. Sollten wir uns auf einen Hardwareentwurf einigen können, wäre es auch schön wenn man die Software dazu gemeinsam hinbekommt oder zumindest eine Art Lib entsteht.
8. Die Bake sollte zunächst als Hardwareanforderung nur die RP6Base haben, es wird jedoch sicherlich Tendenzen geben, die M32 und andere Boards mit zu nutzen was ok ist.
9. Die Kosten für einen Raum auszustatten sollten nicht über 120-150 € liegen.
Wir sollten uns neben der Signaltechnologie jedoch auch darum kümmern, ob wir eine "Dumme Bake" und viel Code auf dem RP6 wollen, oder eine "schlaue Bake" mit eigenem Prozessor und Programm. Da ja mit Tochterboards noch zumindest ein TWIslave mit Motorsteuerung auf der Base laufen müsste, hat man nicht mehr so viel Platz.
Ich werde mir in den nächsten Wochen mal ein Versuchsaufbau der Bake mit einem AVR-Board von Polin http://www.pollin.de/shop/dt/MTQ5OTgxOTk-/Bausaetze_Module/Bausaetze
/Bausatz_AVR_NET_IO.html machen da dieses Board günstig zu bekommen und vom PC via Ethernet aus zu steuern ist. Zum Programmieren ist zwar ein ISP Adapter nötig aber den hab ich da. Damit kann ich sowohl "schlaue" wie "dumme" Baken simulieren und ggf. sogar später mal den PC mit einbinden. Ihr könnt natürlich andere Boards nutzen.
Gruß
das wären meine (erweiterten) wünsche und vorstellung an bake 2.0:
aktive, „schlaue“ bake
bake betreiben über die M32 als master
eine gemeinsame hardware und library
ACS und IRCOMM des RP6 sollten verwendet werden
hauptsächlich indoor, raumgröße 5x5m
outdoor 10x10m (gartengröße :-))
IR/US konzept
position im raum auf +- 5cm festsstellen können
eigenständiges manövrieren im raum, eigenständiges anfahren eines punktes im raum
einbindung des gyro (multiIO)?
„tochterbaken“ - wie eingebunden, anzahl begrenzen? BT?
spannungsversorgung über USB
anschluss- / einbaumöglichkeit eines BT-moduls
kosten bis max 120€ für einen raum (1 mutterbake / 2 tochterbaken)
die leiterplatte von Pollin sieht gut aus, wäre ein arduino (unmenge an zusatzmodulen, leicht zu handhaben, günstige kosten) eine alternative?
mit diesen satelliten-us-gebern – wie sind die mit der „mutter“-bake verbunden?
Als Logik-Board taugt eigentlich jede Hardware so lange ein paar Steuerpins abgreifbar sind und man ein Timer im Prozessor hat. Boards mit hoher Taktfrequenz haben es auch meist einfacher aber das relativiert sich ab 8MHz da meist nur schneller auf irgendwas gewartet wird. Wirklich zeitkritisch sind eher Boards unter 1MHz aber auch da kann man sich behelfen.
Das Polin Board gefällt mir deswegen besonders gut weil es noch eine erweiterung dafür gibt. http://www.pollin.de/shop/downloads/D810112B.PDF
Polin selbst hat noch weitere AVR Boards zu vertretbaren Preisen.. allerdings ohne LAN-Chip aber dafür verschiedene Sockel.
http://www.pollin.de/shop/downloads/D810038B.PDF
und
http://www.pollin.de/shop/downloads/D810046B.PDF
Man kann aber auch Arduino verwenden oder irgend eine andere AVR Plattform/Hersteller.
Unser Anbieter des Forums vertreibt z.B. auch ein Board:
http://www.rn-wissen.de/index.php/RN-Control
Wie schon mal gesagt.. wir werden mit solchen Dingen nicht die ersten sein... :)
Da gibts auch noch mal interessantes zum Thema ISP
http://www.rn-wissen.de/index.php/AVR-Einstieg_leicht_gemacht
Aber auch eine m32 oder m256 kann das. Die M128 kann es bedingt auch, da dort kein c läuft muss man gucken ob das in asm geht.
Es ist nur wichtig zu wissen, ob auf dem Prozessor schon ein Bootloader drauf ist, und man Programme wie bei AREXX/RP6 über eine serielle Schnittstelle bzw. USB flaschen kann oder ob ein Programmieradapter vom Typ MKII gebraucht wird. Letzterer kann auch zum onChip-Debuggen genutzt werden und benötigt meist ein spezielles Programm wie Ponyprog oder diverse andere incl. Atmel Studio. Beide Wege funktionieren. Man kann sich ja auch ein Prozessor in so einem Board programmieren und dann ein eigenes Leiterplattendesign mit dem Prozessor überlegen. Möglichkeiten gibts da reichlich. Die Polin Sachen sind halt in Steckwanne ausgeführt wie auch die RP6 Boards, aber es spricht nichts gegen andere Systeme.
Zudem ist der RP6 wie auch das M32 per ISP zu Programmieren wenn man ihn umbaut. Man könnte also sogar den Bootloader rauswerfen und alles über ISP machen.
http://www.rn-wissen.de/index.php/RP6#ISP_.28In_System_Programming.29
Würde ich smd-löten nicht scheuen wie der Teufel das Weihwasser, hätte ich mir auch schon längst eine pinkompatible m644 oder eine m1284 CPU auf den RP6 gelötet und würde auch über ISP proggen.
Die Frage ist halt... will man die 35 Euro für den MKii "sparen" und zahlt dafür wo anders drauf oder nimmt man doch einen und kann dafür auch sehr preiswerte/vielseitige Boards nutzen.
Ich will da niemand Vorgaben machen aber ich hab halt einen und ich könnt auch für andere CPUs mit Code vorladen.
Gruß
ich habe mir diese hardware (http://www.sainsmart.com/arduino/arduino-kits/sainsmart-mega-2560-r3-sensor-shield-v5-4wd-mobile-car-l298n-hc-sr04-for-arduino-robot.html) bestellt, ich wollte ja den RP6 mit rädern ausstatten, mit 4 antrieben und da es die RP6-base offensichtlich von der elektronik her nicht unterstützt halt mit arduino (als zweiten slave) für die motorsteuerung. Noch viel arbeit, auch mit I2C, mal schauen wie das läuft...
das arduino mega 2560 board (http://www.sainsmart.com/sainsmart-mega2560-r3-development-board-compatible-with-arduino-mega2560-r3.html) was dabei ist, war kinderleicht zu flashen: arduino IDE installieren (linux kein problem), per USB kabel mit dem PC verbunden und los gings. Ohne was dazwischen, kein adapter, nix. Bootloader ist schon drauf....
schaust Du Dir das bitte mal an? Was mich stört, ist die programmiersprache (processing) - aber angeblich gehts auch in c++
c++ ist lediglich eine Erweiterung von c und wirkt sich hauptsächlich durch Klassen aus. Der gnu c compiler (als Port für windows) (den auch winavr und Atmel Studio nutzt) kann beides. c++ brauchst du nur wenn du die Libs vom arduino nutzt oder z.B. den c't-bot ... , man kann das Ding (Arduino) aber auch in c oder asm proggen. Manche Puristen hier behaupten übrigends, c++ ist zu überladen als das man das auf einem Prozessor dieser größe verwenden könne... ich seh das anders. Man könnte auch den RP6 in c++ proggen.. aber dafür müsste man erst so schöne klassen wie auf dem Arduino bauen... und das ist laut der Puristen eben bäbä... *grinsels
Ich selbst schreib aber auch lieber in c für den AVR. c++ braucht nämlich eigentlich malloc() und malloc ist wirklich bäbä wenn man nicht grade min. nen 64MB Speicherriegel im System hat. Kann aber sein das malloc auf dem arduino anders gelöst ist.
Gruß
Nachtrag bzw. Korrektur:
Bei den Polin AVR Evaluation Boards ist schon ein Programmieradapter a la Ponyprog auf dem Board integriert. Zumindest auf dem Funkboard, auf dem anderen aber wohl auch. Man spart sich also sogar den MKii. Nur das Netio Board ggf. mit Erweiterung hat keinen.
Nachtrag:
Ein weiteren Vorteil kann c++ bei Muktitasking Systemen gegenüber c ausspielen da man mit c++ und dem new Operator bzw con-/destruktoren gut reentranten (http://de.wikipedia.org/wiki/Reentrant) Code bauen kann. Man kommt auf Kleinprozessoren aber selten in die Verlegenheit solchen Code zu nutzen und letztlich erreicht man mit bischen Nachdenken das Gleiche auch in c.
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 (http://www.sainsmart.com/sainsmart-mega2560-r3-development-board-compatible-with-arduino-mega2560-r3.html):
ich habe am montag ein board in D bestellt, geliefert wurde es heute, 14€, portofrei...
ist seehhrr weit verbreitet, kostengünstig, simpel, kein programmieradapter, wir würden damit eine „Brücke“ zwischen zwei AVR-Systemen (M32 und M2560) schlagen...
mir käme es entgegen, weil ich bereits beim Allradantrieb des RP6 solches Modul verwende...
@Rolf,
die ergänzung von beiträgen ist ungünstig, ich habe Deine zwei edits rein zufällig entdeckt...
schöne heisse pfingsten...
Besserwessi
06.06.2014, 18:59
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 ?
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
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ß
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 ... ;)
Besserwessi
10.06.2014, 20:34
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.
@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/335819/PH-59-Piezo-Kompakt-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/filter_7.html
Gruß
Rabenauge
11.06.2014, 15:28
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..
Christian H
11.06.2014, 15:56
Hi,
ganz kurz eine Anmerkung. US-Sender auf den Roboter und US-Empfänger in die Bake, wie ja bereits angedacht, ist deutlich besser als andersrum. Ich hatte ja den US-Empfänger auf dem Roboter und mußte um Störsignale zu vermeiden, den Empfänger extra mit Luftpolsterfolie dämpfen. Dies Schallisolation für den Empfänger ist für die Bake sicher einfacher und zuverlässiger zu realisieren. Das o.g. Konzept gefällt mir auch gut. Insb. auf den Stromverbrauch zu achten und die Bake nur bei Bedarf per IR zu aktivieren finde ich super. Vielleicht reicht dann für jede Bake eine kleine Solarzelle aus um die Akkus zu laden. Dann braucht man sich um die Baken, wenn sie einmal installiert sind, überhaupt nicht mehr zu kümmern.
Grüße
Christian
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. Falls ihr hier strikt beim RP6 und seinen Gegebenheiten bleiben wollt, sagt es, dann halt ich wieder die Klappe..
also ich weiss nicht wie ihr darüber denkt, es läuft zwar hier bei RP6, aber prinzipiell doch auf jedem system anwendbar, oder?
Besserwessi
11.06.2014, 19:03
Das Prinzip der Baken / Postionsbestimmung ist unabhängig vom Bot.
Wenn ich mir das recht überlegen sind die 22 kHz (oder ähnlich) gar nicht so schlecht. Die meisten kleine (z.B. 6 mm Druchmesser) Elektretmikrofone sind auch im Bereich bis 30 kHz noch recht empfindlich, und oft auch noch weitgehend Ungerichtet (zumindest über kanpp 180 Grad). Die Auflösung bei der Zeit hängt davon ab, wie man den Schallpuls detektiert. Dabei ist die Wellenlänge bzw. Periodenlänge keine Prinzipelle Grenze: bei den klassichen 40 kHz Kapseln hat man da mit dem resonanten Sendern und Empfängern ggf. schon Schwierigekiten die Richtige Peride zu erkennen, weil das Signal langsam anschwillt / Abklingt. Da können die Nichtresoanten Transducer (Piezo Hochtöner / Elektretmicrofon) Sogar besser sein. Es geht bei er Zeitmessung auch deutlich genauer als 1 Periode/Wellenlänge ( ich habe das für höherfrequenten Ultraschall schon mal ziehmlich auf die Spitze getrieben, da ging die Zeitauflösung bis auf etwa 1/10000 der Periode). Auch hier könnte man das mit wohl noch moderatem Aufwand wohl auch besser als eine Periode hinbekommen. Da man nicht die Bandpasswirkung des Empfängers hat, muss man da sowieso etwas Aufwand treiben um nicht so sehr auf Rauschen zu reagieren. Eine Weg wäre da halt ein Korrelationsempfänger, der nicht nur sehr gut bei der Rauschunterdrückung ist, sondern auch gleich noch eine sehr hohe Zeitauflösung erlaubt. Das Limit für die Laufzeit wird da eher das IR Signal und die Temperatur / Luftfeuchte. Die Temperatur wird man wohl messen und berücksichtigen müssen, wenn man besser als ein paar Prozent werden will. Outdoor hat man dann ggf. noch den Wind als Störgröße.
Die Leistungsangaben bei den Hochtönern sind Teils irreführend. Die Beziehen sich oft auf die Spannung für ein 8 oder 4 Ohm System, obwohl der Piezo hochohmiger ist. Man braucht also gar nicht so viel Leistung wie man meint. Ich würde man davon ausgehen das auch schon 0,1 W an Sendeleistung ausreichen kann, wenn der Empfänger gut ist. Der wesentliche Nachteil ist halt das die Hochtöner und der Umlenkspiegel relativ groß sind im Vergelich zu den Kapseln - sonst gefällt mir die Idee mit Hochtöner/Mikrofon gut.
Bei den TSOPxx38 Empfängern würde ich mal von einer Zeitauflösung so im Bereich 20-100 µs rechnen, ggf. etwas besser, wenn man mehr als eine Flanke nutzt, insbesondere nicht die ersten. Da sollte man nicht nur einen einfachen Puls nutzen, denn anfangs wird der Empfänger erst einmal die Empfindlichkeit einregeln und erst dann einigermaßen unabhängig von der Intensität des Signals sein. Der IR Puls für das Timing (sollte wegen nur einem Sender vom Bot zu den Baken sein) sollte daher eher schon so etwa 10-50 ms lang sein, auch wenn der Bot da eigentlich kaum Daten (ggf. ID des Bots, wenn man mehrere Bots erlauben will) zu übertragen hat.
Rabenauge
11.06.2014, 22:59
Warum die US-Sache denn selber frickeln? Ganz offen mal: ich bekomme beim Chinesen nen Zehnerpack der HC-SR04 für acht Euro!
Ich weiss: das Ding kommt nur ungefähr 5m weit-ist also noch nicht das optimale (wobei es in nem 10x10m-Raum reichen würde, es genügt ja wenn er _eine_ Bake erreicht), aber das geht mit läppischem Stromverbrauch.
Meine Tüte voll ist noch nicht da (und der eine, den ich hier hab, kaputt, den hab ich zermurkst) sonst könnt ich mal messen, was der beim Rufen an Strom braucht-aber dolle ist das nicht. Also nix mit abartiger Leistungsaufnahme-in der Bake würd ichs trotzdem sparen wollen, einfach, weils unnötig ist.
Womöglich kann man die in den Dingern verbauten Schallkapseln (bzw, eins wird wohl der Lautsprecher, und das andere das Mikrofon sein, oder?) kurzerhand ausbauen und mit bissle mehr Leistung ansteuern?
Oder zweie parallel rufen lassen?
Bin ich nich der Profi für...
Was _meine_ Vorstellungen angeht: wie gesagt, mir schwebt da eher ein Robbi-findet-Herrchen-System vor, was auch im Freien auf nen paar Meter funktioniert. Da ich beabsichtige, den Outdoor-Bot etwas grösser zu machen, wird der ohnehin eher mit mehr, als mit weniger Akku bestückt werden müssen. Von daher schwebt mir eben ne Lösung mit mehreren Baken vor: dann kann mans (Robo)-Hündchen auch mal im Garten rumwuseln lassen, indem man einfach in jede Ecke ne Bake wirft. Und zum Gassigehn genügt eine- wenn deren Akku schwächelt, nehm ich die nächste vom Roboter und tu die entladene drauf-wo sie wieder aufgeladen wird.
Somit dürft die Bake nich grösser als ne elektrische Zahnbürste werden, die ich mir bequem anheften kann.
Leute,
wo stehen wir gerade?
- Ist das noch ein Projekt mit dem RP6?
- Sind wir jetzt schon outdoor oder immer noch indoor?
- Wollen wir "dicke Batterien" auf einem Roboter und "schlanke Baken" oder den RP6 und Baken z.B. an einem USB-Netzteil?
- Wie relevant ist die Ultraschallfrequenz?
- Wer sendet was, wer empfängt was in IR oder US?
Ich blicke nicht mehr durch ... :(
Vorschlag: inka, würdest du mal sortieren, wo wir gerade stehen???
Also, ich steh im wald, versuche aber morgen zu sortieren. Weiss nicht ob mir das gelingt...
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
Rabenauge
13.06.2014, 10:11
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?
Hi inka und alle,
danke für deine Zusammenfassung!
Hier noch kurz meine Meinung dazu:
outdoor und indoor einsetzbar, reichweite 10m
Ich brauche keinen outdoor Einsatz, weil der RP6 dazu eh ungeeignet ist. Die Reichweite von 10m ist zwar schön, aber in einer "normalen" Wohnumgebung reichen auch 5m. Dafür kann man sicher auch billigere US-Sender/-Empfänger bekommen.
geringer stromverbrauch der bake, akku bei outdoor verwendung durch solarzellen aufladbar
indoor mit 5v (USB) stromversorgung
...
bake hat US-empfänger (geringer stromverbrauch), roboter US-sender und empfänger
Über das Thema Stromversorgung würde ich nochmal nachdenken wollen. Eigentlich sollte ein mobiler Roboter möglichst leicht und stromsparend aufgebaut sein. Dazu passt nicht, dass wir die Baken energetisch autonom machen wollen und den Roboter mit mehr Batteriekapazität ausstatten wollen, um z.B. den US-Sender da draufzubauen.
Ich würde es umgekehrt sehen:
Der Roboter sollte so wenig Strom wie möglich verbrauchen, um eine hohe Betriebszeit zu erreichen. Bei einer (indoor-) Bake ist mir der Stromverbrauch egal: Die kann auch mit einem Netzteil an einer Steckdose hängen.
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
Wenn man das Stromversorgungsthema (s.o.) mal außer Acht läßt, dann wäre die IR-Kommunikation einfacher, wenn der mobile Roboter selbst die Entfernung berechnen würde (d.h. er den US-Empfänger trägt). Mir ist dabei klar, dass man mit Störungen durch den Körperschall des fahrenden Roboter rechnen muss,- müßte man testen, ob ein Ping der Bake identifizierbar ist trotz des Störpegels. Auch die Tatsache, dass er überhaupt während einer Messung evtl. fährt macht das nicht leichter: Dies gilt aber für beide US-Richtungen.
Die "US-Ping-Anforderung" durch den mobilen Roboter per IR sehe ich unkritisch: Evtl. Verzögerungen durch Verarbeitungsprozesse auf dem RP6 und der Bake dürften sehr konstant sein und sich herausrechnen lassen.
Was denkt ihr?
ich habe jetzt in der zusammenfassung (post 153) den US-empfänger beim roboter rausgenommen und eine überschrift hinzugefügt, dass es eine zusammenfassung für eine stromsparende bake ist. Evtl. sollte ich die andere variante noch machen? Aber diskutiert jetzt erstmal - ich lausche zu:-)
Rabenauge
13.06.2014, 18:14
Dirk: hast du nen Testlabor, bei dem im Meterabstand Steckdosen am Boden verteilt sind? ;)
Ich nicht, und grad der RP6 ist nun sicher auch nicht von überall herumliegenden Kabeln begeistert.
Wenn das Ganze auch nur _einigermassen_ flexibel sein soll, ists am sinnvollsten, die Baken mit nem Akku zu bestücken. Auch für reinen RP-6-Betrieb.
Dennoch ist ja keinem die Möglichkeit genommen, meinetwegen externe Strombuchsen in den Baken zu verbauen, ganze Netzteile oder nen kleines Atomkraftwerk.
Das Thema Stromversorgung würd ich einfach mal hintenan stellen-kann sich jeder stricken, wie ers haben will. Wenn ihr (RP6-Besitzer) eben lieber Netzstrom benutzen wollt, macht ruhig- da bastele ich mir schon was, wenns soweit ist.
Ausserdem: wenn du mehrere US-aktive Baken hast, wirst du nicht umhin kommen, die gezielt einzeln abzufragen (grade Indoor!) weil sonst durch Echo usw. ein einziges Kauderwelch beim Roboter ankommt.
Du hast dann _mehrere_ US-Sender und musst die wieder koordinieren. Mit einer einzigen Schallquelle (vom Roboter) taucht das Problem gar nicht erst auf. Und mit Infrarot dürfte die Kommunikation um kleine Welten schneller sein als per Ultraschall.
Was die einfachere Kommunikation angeht: ich kenn den RP6 nicht persönlich (will sagen, angeguckt schon, hab aber keinen)- so schwer kann das doch nicht sein mit dem Ding? Sowas hab ich vor >10 Jahren schon mit LEGO-RCX`en gemacht.
Eine gewisse "Intelligenz" brauchen die Baken sowieso (schon, damit der Roboter sie voneinander unterscheiden kann), da ist also eh nen Rechenknecht drin. Und ob der nen Lämpchen irgendeinen Text blinken lässt, oder seine Ansage per Ultraschall trötet, ist dem Kerlchen egal.
Was ich nun nicht weiss: warum willst du diese Änderungen im Plan?
Gibt der RP6 das _so_ ohne grössere Basteleien nicht her?
Hi Rabenauge,
tatsächlich kann man die Stromversorgung ja individuell planen. Bei der Szenerie, in der der Roboter in einem Zimmer herumfährt, sehe ich bei 2 Baken z.B. in den Raumecken keine Gefahr von Kabelsalat. Aber klar: Das geht auch mit Akku.
Ausserdem: wenn du mehrere US-aktive Baken hast, wirst du nicht umhin kommen, die gezielt einzeln abzufragen (grade Indoor!) weil sonst durch Echo usw. ein einziges Kauderwelch beim Roboter ankommt.
Du hast dann _mehrere_ US-Sender und musst die wieder koordinieren. Mit einer einzigen Schallquelle (vom Roboter) taucht das Problem gar nicht erst auf. Und mit Infrarot dürfte die Kommunikation um kleine Welten schneller sein als per Ultraschall.
Ja, natürlich muss ich die Baken als US-Sender einzeln ansteuern, das würde ich vom RP6 aus über IR in Form einer Adresse machen. Ich muss dann eigentlich nichts koordinieren, bzw. der Roboter kann mit eigener "Intelligenz" auch entscheiden, welche Bake er ansteuern will (z.B. weil er erkannt hat, dass sie in der Nähe liegt und eine Positionsbestimmung durch sie aussichtsreich ist).
Gibt es nur einen US-Sender auf dem Roboter, wird das m.E. nicht zwangsläufig einfacher, weil man dann auch koordinieren muss, in welcher Form und Reihenfolge alle angepingten Baken ihre Ergebnisse dann über IR an den Roboter senden. Das ist sicher auch machbar, muss aber in Form eines Protokolls und eines Zeitschemas sicher gestellt werden.
Ich meine: Es ist nicht so eindeutig möglich, sich mit dem Aspekt der Koordination der Kommunikation für eine der beiden Optionen zu entscheiden.
FÜR den Sender auf dem Roboter spricht für mich fast nur das Argument der störungsfreieren US-Laufzeitmessung in den Baken. GEGEN diese Lösung spricht der höhere Strombedarf auf dem Roboter und die Tatsache, dass der Roboter nicht direkt selbst über das Messergebnis verfügt, sondern es erst noch von den Baken geschickt bekommen muss.
Was die einfachere Kommunikation angeht: ich kenn den RP6 nicht persönlich (will sagen, angeguckt schon, hab aber keinen)- so schwer kann das doch nicht sein mit dem Ding? Sowas hab ich vor >10 Jahren schon mit LEGO-RCX`en gemacht.
Eine IR-Kommunikation ist mit dem RP6 gut möglich, auch ohne weitere Hardware. Was meinst du?
Was ich nun nicht weiss: warum willst du diese Änderungen im Plan?
Gibt der RP6 das _so_ ohne grössere Basteleien nicht her?
Es gibt aktuell nur eine tolle Sammlung von Erfahrungen und Meinungen, aber noch keinen Plan.
Auf den RP6 kann man auch fast alles draufsetzen,- gar kein Problem.
Es geht mir nur darum, Lösungen nicht vielleicht zu schnell "festzustampfen", sondern ein Nachdenken noch zuzulassen.
Rabenauge
13.06.2014, 19:45
Klar-Nachdenken ist immer gut. :)
Ich kann aber deine Argumente nicht nachvollziehn. Draum frage ich nach-ich seh einfach in deinen Ansätzen irgendwie keine Vorteile.
-Baken brauchen nicht "mehr Strom haben als der Roboter"- wenn der ans Ladegerät muss, haben auch die Baken Pause.
Meine Idee, die Baken _aufm_ Roboter wieder aufladen zu können, ist schon nen paar Stufen weiter gedacht und macht, zuegegebenermassen in der Wohnung, und mitm RP6, keinen Sinn.
Das bringt _erst_ dann was, wenn ich mit dem Ding wie andere mit Hunden, Gassi gehn kann. Dann will ich weder ne Kabelrolle hinterherschleppen, nach ne pfundschwere Bake am Gürtel hängen haben.
Ausserdem heisst outdoortauglich robust: je kleiner und leichter sowas wird, umso mehr steckts weg.
Dein Einwurf, dass mobile Roboter halbwegs ressourchenschonend arbeiten sollen (oder so ähnlich), dem stimme ich zu.
Was aber braucht mehr Ressourcen (Hardware, Strom) ? EIN US-Sender aufm Roboter oder sechse davon-einer in jeder Bake? ;)
Da sollte man immer das Gesamtsystem im Auge behalten.
Sicher, die Baken müssen die Entfernung berechnen aber uns allen ist wohl klar: ohne nen Controller in den Baken wirds eh nichts. Den brauchst in jedem Fall (jedenfalls, wenn wirs nicht allzu primitiv lösen wollen)- wieso sollte der nicht auch das bisschen Entfernung berechnen?
Kommuniziert werden muss sowieso, also kann die Bake, neben ihrem Namen, auch gleich noch die Entfernung mit senden. Das sind nen paar Morsezeichen mehr....
Softwaremässig nicht schlimm, da das einzige, was bei jeder Bake anders sein sollte, die "Seriennummer" ist-alles andere nicht. Eine Konstante im Code verändern und ab auf die nächste damit.
Da du von 5m Reichweite sprichst komm ich noch mal auf die spottbilligen HC-SR04 zurück: Stromverbrauch weiss ich jetzt nicht (wart immer noch auf den Sack voll), aber das Ding ist gaaanz easy anzusteuern: einen Pin brauchst zum triggern, einen zum Echolaufzeit messen. Mehr isses nich...
Dürft sich nahezu an _jedem_ Roboter verbauen lassen. Schöner wäre natürlich I2C-aber das ist für den Preis dann wohl nicht zu haben.
Und 5m schaffen die Dinger ungefähr (angegeben sind sie mit 4).
Hi Rabenauge,
Was aber braucht mehr Ressourcen (Hardware, Strom) ? EIN US-Sender aufm Roboter oder sechse davon-einer in jeder Bake?
Ich hatte nicht über die ökologische Bilanz des Gesamtsystems gesprochen, sondern nur über einen möglichst stromsparenden Aufbau von mobilen Robotern.
Meine Idee, die Baken _aufm_ Roboter wieder aufladen zu können, ist schon nen paar Stufen weiter gedacht und macht, zuegegebenermassen in der Wohnung, und mitm RP6, keinen Sinn.
Das bringt _erst_ dann was, wenn ich mit dem Ding wie andere mit Hunden, Gassi gehn kann. Dann will ich weder ne Kabelrolle hinterherschleppen, nach ne pfundschwere Bake am Gürtel hängen haben.
Ausserdem heisst outdoortauglich robust: je kleiner und leichter sowas wird, umso mehr steckts weg.
Wahrscheinlich liegt da der "Hase im Pfeffer": Ich will mit dem RP6 nicht outdoor Gassi gehen, sondern eine indoor Navigation einfach und kostengünstig aufbauen.
Wenn unsere Ziele nicht identisch sind, können Argumente leider auch aneinander vorbei gehen oder gegenseitig unverständlich sein.
Kommuniziert werden muss sowieso, also kann die Bake, neben ihrem Namen, auch gleich noch die Entfernung mit senden. Das sind nen paar Morsezeichen mehr....
Es geht um eine möglichst einfache Kommunikation. Bei dem von mir vorgeschlagenen Ablauf (IR-Ping Anforderung durch den RP6, adressierte Bake sendet US-Ping, dessen Laufzeit durch den Roboter gemessen wird) ist die Kommunikation minimal und besteht nur aus dem IR-Versand einer Adresse gefolgt ggf. von einem "Startsignal". Im Idealfall ist keinerlei weitere Kommunikation nötig.
Da du von 5m Reichweite sprichst komm ich noch mal auf die spottbilligen HC-SR04 zurück: Stromverbrauch weiss ich jetzt nicht (wart immer noch auf den Sack voll), aber das Ding ist gaaanz easy anzusteuern: einen Pin brauchst zum triggern, einen zum Echolaufzeit messen. Mehr isses nich...
Sehe ich auch so. Die Dinger sind gut und billig.
Rabenauge
13.06.2014, 20:54
Es geht um eine möglichst einfache Kommunikation. Bei dem von mir vorgeschlagenen Ablauf (IR-Ping Anforderung durch den RP6, adressierte Bake sendet US-Ping, dessen Laufzeit durch den Roboter gemessen wird) ist die Kommunikation minimal und besteht nur aus dem IR-Versand einer Adresse gefolgt ggf. von einem "Startsignal". Im Idealfall ist keinerlei weitere Kommunikation nötig.
Hm-so einfach wird das nicht, fürchte ich.
Stell dir das Szenario vor: der Roboter steht, umgeben von Baken, in der Bude.
In dem Moment weiss er _nicht_, wo die Baken stehen! Falls er das weiss, bist du bereits bei nem fest installierten Parcours und somit völlig unflexibel.
Das heisst: er muss zuerst in die Runde fragen, welche Baken überhaupt "da" sind (in Reichweite z.B), und dann die Richtung der Bake ermitteln, mit der er reden will. Dann erst können die beiden sich über die Entfernung unterhalten.
Ich find das auch nicht wirklich einfacher.
Hi,
Stell dir das Szenario vor: der Roboter steht, umgeben von Baken, in der Bude.
In dem Moment weiss er _nicht_, wo die Baken stehen!
Ja, richtig.
Deshalb hatte ich hier (https://www.roboternetz.de/community/threads/63467-IR-bake?p=600350&viewfull=1#post600350) auch gesagt, dass die Positionen der Baken bekannt sind oder per IR abgefragt werden können. Letzteres wäre ja auch nur einmalig in einem neuen Raum nötig und nicht bei jeder Messung.
Das heisst: er muss zuerst in die Runde fragen, welche Baken überhaupt "da" sind (in Reichweite z.B), und dann die Richtung der Bake ermitteln, mit der er reden will. Dann erst können die beiden sich über die Entfernung unterhalten.
Ja, er muss am Anfang in einem neuen Raum wirklich fragen, ob eine Bake da ist (man könnte das über eine Art "general call" machen) und die Baken könnten mit ihrer ID und ggf. ihrer Position antworten. Das Konzept wäre auch für eine Navigation über mehrere Räume denkbar.
Die Richtung, in der sich die Bake befindet, ist dann unwichtig. Man würde durch Triangulation aus den Entfernungen zu mind. 2 Baken die Position des Roboters errechnen. Ggf. gibt es davon 2, so dass man noch eine 3. Bake braucht (man kann aber die Baken so aufstellen, dass es keine 2 identischen Positionen gibt).
Hallo,
mein vorschlag wäre, dass wir die drei punkte um die es hier geht -
- reichweite
- US senden von der bake oder roboter
- stromverbrauch bake und roboter
so lösen, dass hardwaremäsig jeweils beide optionen möglich sind (einmaliger aufwand auf der leiterplatte) und softwaremäsig als option in der library zu- bzw. abschaltbar sind. Wir stochern ja momentan ohne ausnahmen m.e. nach im dunkeln, müssten eigentlich beide versionen testen. Zu hardware - und software wären wir hier bestens aufgestellt: rp6 - Dirk, RolfD und bake-seite (arduino) Rabenauge. Wäre das ein vorschlag?
Hi,
guter Vorschlag. Weil ...
- Reichweite: Da können wir uns -denke ich- an erhältliche US-Module anpassen (z.B. HC-SR04), ohne eine 10m oder 5m Vorgabe.
- US Senden von der Bake oder Roboter: Hardwaremäßig können wir auf beiden Seiten (RP6 und Baken) die HC-SR04 vorsehen,- welche Richtung wir dann nehmen, können wir (nach Vorliegen der konkreten Hardware) ausführlich testen.
- Stromverbrauch: Ist eher ein Randthema und auch kaum noch von Bedeutung, wenn wir beide US-Senderichtungen eh einplanen.
Das Modul HC-SR04 habe ich mir nochmal genauer angesehen:
Erst hat mich der effektive Messwinkel von 15° irritiert (Datenblatt bei Elec Freaks). Das ist natürlich eigentlich toll,- ein sehr kleiner Messwinkel ist eigentlich gut.
Andererseits bräuchte man für eine "Rundumsicht" (zumindest für den Empfänger) dann 24 Module.
In einem anderen Datenblatt (ITead Studio) ist aber von 30° die Rede, in denen man gut messen kann.
Dann bräuchten wir theoretisch 12 Module im Kreis angeordnet.
Die müßte man dann senkrecht nebeneinander oder in 2 Ebenen waagerecht übereinander (um 30° versetzt) einbauen, damit der Kreis auf dem Roboter nicht zu groß wird.
Das selbe Thema entsteht auf der Bake:
Für Winkel von 90..180° (d.h. eine Bake steht immer am Rand und nie in der Mitte des Raums) bräuchten wir dann ja auch 3 oder 6 Module.
Sehe ich das richtig?
Hi,Erst hat mich der effektive Messwinkel von 15° irritiert (Datenblatt bei Elec Freaks). Das ist natürlich eigentlich toll,- ein sehr kleiner Messwinkel ist eigentlich gut.
Andererseits bräuchte man für eine "Rundumsicht" (zumindest für den Empfänger) dann 24 Module.
In einem anderen Datenblatt (ITead Studio) ist aber von 30° die Rede, in denen man gut messen kann.
Dann bräuchten wir theoretisch 12 Module im Kreis angeordnet.
Die müßte man dann senkrecht nebeneinander oder in 2 Ebenen waagerecht übereinander (um 30° versetzt) einbauen, damit der Kreis auf dem Roboter nicht zu groß wird.
Das selbe Thema entsteht auf der Bake:
Für Winkel von 90..180° (d.h. eine Bake steht immer am Rand und nie in der Mitte des Raums) bräuchten wir dann ja auch 3 oder 6 Module.
Sehe ich das richtig?
ich glaube schon, allerdings würde ich dann 2 HC-SR04 (back to back) auf einem sich hin und her drehendem servo haben wollen. Die 12 module ist ja horror, von 24 ganz zu schweigen...
übrigens kenne ich SRF04 - ist es das gleiche?
Rabenauge
14.06.2014, 10:40
Deswegen war ich von Anfang an gegen die Richtungsbestimmung per Ultraschall...die Dinger haben irgendwas zwischen 15 und 30 Grad würd ich sagen.
Zugegeben: nen Dutzend der Teile kosten nur nen Zehner aber trotzdem ist das zu viel und-grad aufm RP-wohl auch bisschen gross.
Da ist doch ein Ring aus IR-Dioden entschieden handlicher?
Mit denen kann der Roboter bestimmen, aus welcher Richtung die gewünschte Bake sendet, und dann wahlweise den _einen_ US-Sensor dorthin richten (per Servo, oder wie mans möchte) oder sich im Ganzen drehn.
Auch sind IR-Dioden recht einfach optisch abzuschirmen, dass jede wirklich nur ihren Vektor abbekommt .
Damit _das_ nicht zu viele sind, würd ich z.B. sechs Stück vorschlagen. Wenn sich die Empfangsbereiche nen bisschen überlappen (ideal wären 15 Grad zur jeweils benachbarten, das ergibt praktisch die doppelte Auflösung), kann man damit schon ausreichend genau die Richtung feststellen, denke ich.
Nein, die SRF sind nicht die selben. Die HC-SR04 sind mit 4m angegeben, schaffen aber bis zu 5m, und kosten echt pro Stück 1.20 oder so.
Ich hab neulich von denen zehn Stück in China geordert für rund acht €.
Von der Handhabung her aber wohl identisch.
@inka:
allerdings würde ich dann 2 HC-SR04 (back to back) auf einem sich hin und her drehendem servo haben wollen. Die 12 module ist ja horror, von 24 ganz zu schweigen...
Ja, das wären schon recht viele Module und man sollte eine Alternative überlegen. Vielleicht wäre es eine Option, einen Sender/Empfänger nach oben gerichtet einzubauen mit einem 120° Reflektor-Kegel darüber. Dafür gibt's ja im Netz auch Bauvorschläge.
Die "Drehlösung" finde ich nicht sooo gut, weil eine Ausrichtung viel Zeit braucht und problematisch ist, wenn man mehrere Baken anvisieren will (s.u.).
@Rabenauge:
Da ist doch ein Ring aus IR-Dioden entschieden handlicher?
Mit denen kann der Roboter bestimmen, aus welcher Richtung die gewünschte Bake sendet, und dann wahlweise den _einen_ US-Sensor dorthin richten (per Servo, oder wie mans möchte) oder sich im Ganzen drehn.
Auch sind IR-Dioden recht einfach optisch abzuschirmen, dass jede wirklich nur ihren Vektor abbekommt .
Das scheint das ja auf den ersten Blick eine Möglichkeit zu sein. In der konkreten Umsetzung habe ich da so meine Probleme:
Von einem fahrenden Roboter aus sollen Baken per IR geortet werden, um dann den US-Sender oder Empfänger auf dem Roboter in Richtung einer Bake zu drehen und dann per US die Distanz zu dieser Bake zu messen.
Das ist sehr schwer zuverlässig umzusetzen: Bei mehreren Baken ist der Bot ständig mit der "Sensor-Dreherei" beschäftigt. Die IR-Ortung ist wegen der Reflexionen im Raum sehr unzuverlässig. Die Baken müßten das IR-Licht auch gezielter in den Raum strahlen, damit eine Ortung möglich ist. Das würde aber die Nutzung von IR zur allg. Kommunikation unmöglich machen. Wenn man zudem die Baken addressiert anspricht, müßte jeder (der z.B. 6) Sektor-IR-Empfänger diese Adressen auch getrennt dekodieren können und ggf. eine Drehung des US-Sensors zur richtigen Bake veranlassen. Das System wird dann hoch fehlerträchtig und schwer zuverlässig zu programmieren.
Rabenauge
14.06.2014, 18:20
Hm ja, drinnen....könnt ihr die Robbis nicht bissle grösser machen und dann draussen...?;)
Was die Ortung bzw. die Identifikation angeht-da seh ich keine ernsthaften Probleme: wenn _einer_ der IR-Sensoren Signal hat, les ich den eben aus und lass die anderen in Ruhe.
Zudem: nen kurzer Stopp wird wohl drin sein, wenn du aus der Bewegung raus orientieren willst, hast du spätestens bei der US-Entfernungsmessung eh Probleme.
Im Grunde dachte ich daran, die IR-Sensoren einfach ringsum abzufragen, das geht allemal schnell genug (oder nich, aufm RP6?) das kann man ggf. permanent machen, wenn man eine Bake sucht, dann _müssen_ die eben länger als ne Millisekunde blinken.
Und wenn ich mal weiss, wo die gesuchte Bake steht-also nen Sensor per Servo schwenken dauert Sekundenbruchteile....
Wenn ich mehrere Baken empfange (per IR) und grob weiss, als welchen Richtungen, kann ich sogar während der Fahrt, völlig ohne Ultraschall, halbwegs triangulieren.
Aber stimmt: das Problem mit den Reflexionen bleibt. Bei Ultraschall übrigens auch, dort eher noch schlimmer.
Besserwessi
14.06.2014, 20:32
Der Stromverbrauch ist bei den US-Kapseln sehr gering, zum einen ist die Leistung gering (eher unter 100 mW) und dann sind auch die Pulse relativ kurz (z.B. 1-5 ms) und selten, weil man relativ lange Warten sollte bis die Echos verklungen sind. Für die Abstandsmessung sind die Refelxionen eigentlichnicht so das große Problem, solange die direkte Verbindung da ist. Es wird ja nur das Erste Signal ausgeweret, und alles was mehr als etwa 1 ms ( ca. 33 cm Umweg ) zu spät kommt kann verworfen werden. Am ehesten hat man da noch das Signal was am Boden Reflektiert wird - entpsrechend sollten die US Transducher wohl nicht zu tief hängen (zumindest die an den Baken, am Bot hat man da halt Limits).
Die Reichweite beim Ultraschall sollte nicht so das Problem sein. Im Gegensatz zur Abstandsmessung gibt es hier keine Refelxion, sonder den direkten Strahl. Wenn es in Reflexion bis 4 m geht, dann sind direkt Sender zum Empfänger deultich mehr als 10 m drin. Wie Empfindlich das ganze wird hängt aber auch stark von der Auswertung des US Signals ab - da gibt es schon einiges zu beachten. Es ist dabei auch sehr von Vorteil wenn vor dem US Puls per IR ein Startsignal gesendet wird (egal welche Richtung), damit der Empfänger die Verstärkung dynamisch anpassen kann. Vermutlich wird auch der US Empfänger (mit Auswertschaltung) mehr Strom brauchen als der Sender.
Das US Signal vom Bot zu den Baken zu schicken hat einfach den Vorteil, dass ein Puls ggf. von mehreren Baken Aufgefangen werden kann. Man muss also nicht nacheinander die Baken senden lassen, sondern kann ggf. mehr als eine Bake ansprechen.
Der Nachteil der der US Kaseln ist halt, dass sie gerichtet sind, man hat halt nur einen begrenzten Empfangswinkel. Und anders als bei IR kann man nicht einfach mehr Sender gleichzeitig für verschiedene Richtungen Senden lassen. Das müsste man schon nacheinnder machen. Auch Empfangen bräuchte ein mehr oder weniger komplette Empfangsschaltung je Sensor. Auch die Minimalversion hier aus dem Wissensbereich (einfach, aber nicht besonders genau) ist da schon relativ aufwendig um sie an jeder Bake 3 -6 mal zu haben.
Wenn es sein muss, könnte man bei Ulraschall die Richtung mit einem Empfänger mit 2 Transduchern feststellen, so als eine Art Richtungshöhren. Sonst ist US für die Richtung nicht so toll. Ein gerichter Strah geht als besser mit IR.
Rabenauge
14.06.2014, 20:53
Hm, direkte Reichweite=doppelte, ohne Reflexion, klar. Sehr schön. Hätte man selber drauf kommen können.
Die von dir angesprochene "komplette Empfangsschaltung" ist bei den HC-SR04 bereits eingebaut!
Die Dinger sind betriebsfertig: ein Pin löst das Signal aus, und der zweite wartet, was ankommt. Das kann man direkt mit nem Controller einlesen.
Ganz ehrlich: bei nem Stückpreis von 80pf (das komplette Modul!) denk ich über nen eigenbau gar nicht erst nach. Da land ich alleine vom Porto her beim fünffachen.
Stromverbrauch: die Dinger sind mit 50mA (andere Quellen sagen 40) angegeben-erträglich, da das Ding ja nicht pausenlos rumtröten muss.
@Rabenauge:
Hm ja, drinnen....könnt ihr die Robbis nicht bissle grösser machen und dann draussen...?
Da du dich hier so engagiert beteiligst eine Frage:
Was hast DU eigentlich für einen Roboter? Für welche Plattform suchst du ein Baken-System?
RoboHolIC
14.06.2014, 21:38
Die von dir angesprochene "komplette Empfangsschaltung" ist bei den HC-SR04 bereits eingebaut!
Die Dinger sind betriebsfertig: ein Pin löst das Signal aus, und der zweite wartet, was ankommt.
Ja und nein! Der Echo-Pin gibt ein Signal aus, das (grob) vom Triggerssignal beginnend so lange aktiv bleibt, bis ein Echo erkannt wurde, maximal jedoch bis zu einer TimeOut-Zeit von ca. ?50ms?, die deutlich über der Echozeit der spezifizierten Reichweite liegt.
Ist schon bekannt, wie dieser funktionale Verbund aufgetrennt werden kann, sodass Sender und Empfänger unabhängig voneinander nutzbar sind? Umprogrammierung? Hardware-Mod?
Rabenauge
14.06.2014, 22:29
@Dirk: so ein Bakensystem soll mein grosser bekommen. Den gibts noch nicht, er reift aber momentan in kopf und 3D allmählich vor sich hin.
Ursprünglich sollte es ein 1:16er Panzer-Chassis werden, aber das ist ne Nummer zu klein. Wird _ähnlich_ dem R`Rex-Chassis, nur nich so teuer, da ich zwar ähnliche Komponenten verwenden will, aber selber bauen.
Von kleinerem bin ich weg-hab auch ne etwas aufgerüsteten NiboBee (LiPo,DOGM-Display,Sharp IR-Sensor mit Servo), dafür ist meine Bude einfach bisschen eng, das macht nicht wirklich Spass hier.
Momentan bastle ich an nem Spielzeugbuggy, der Arduinisiert wurde, und an nen paar Sachen, die "Roboter" eher nich zu nennen wären, aber meist ist auch nen Arduino irgendwie in der Nähe.
Da mein Vorhaben etwas grösser (und kostspieliger) wird, plan ich das so weit als möglich durch und versuche, einzelne Sachen vorher zu testen.
Der Buggy ist im weiteren Sinne auch dafür: der soll auch mal draussen nen bisschen rumnavigieren (falls ich den Kompass brauchbar ans laufen bekomme) *grmbl
Ja und nein! Der Echo-Pin gibt ein Signal aus, das (grob) vom Triggerssignal beginnend so lange aktiv bleibt, bis ein Echo erkannt wurde, maximal jedoch bis zu einer TimeOut-Zeit von ca. ?50ms?, die deutlich über der Echozeit der spezifizierten Reichweite liegt.
Ist schon bekannt, wie dieser funktionale Verbund aufgetrennt werden kann, sodass Sender und Empfänger unabhängig voneinander nutzbar sind? Umprogrammierung? Hardware-Mod?
Wie das beim SR04 funktioniert weiß ich jetzt nicht. Ich kenne aber Module ähnlicher Bauart, bei denen die Empfindlichkeit des Empfängers aktiv geregelt wird. Die Intensität des Echos nimmt ja mit der Entfernung ab. Die Verstärkung des Empfängers wird nach dem Aussenden des Pings stetig erhöht, da ja das Echo immer schwächer wird. Außerdem wird der Empfänger währendes Pings deaktiviert, machmal auch der Piezo kurzgeschlossen, um Übersteuerungen zu vermeiden.
MfG Klebwax
Hi Leute,
nach den vielen Ideen hier würde ich euch fragen, ob eine Art "universelle" US-/IR-Bake denkbar ist.
Wenn ja, könnte man ja eine Platine designen, die einige unterschiedliche Navigations-Konzepte ermöglicht,- entweder dadurch, dass man sie nur jeweils teilbestückt oder bestimmte Funktionen de-/inaktiviert.
Dazu ein paar Fragen bzw. auch schon Design-Entscheidungen zur Bake:
1. Stromversorgung:
-- a) Versorgungsspannung 3,3..5V
-- b) USB-A-Anschluß zur Direktversorgung der Bake
-- c) Ladung eines internen Akkus über USB
-- d) Ergänzungsladung durch kleines Solarpanel (Anschluß vorsehen)
2. Sensorik/Aktoren:
-- a) US-Sender und -Empfänger mit Rundumsicht bzw. mind. 180° Sicht
-- b) US-Sender und -Empfänger einzeln direkt ansprechbar (keine I2C- oder seriellen Typen)
-- c) Reichweite US bis 5m
-- d) Vorabentscheidung, wie viele US-Sender/-Empfänger max. zum Einsatz kommen werden!
-- e) Parallel zu d) die Entscheidung, ob ein/zwei Kegelreflektor(en) zum Einsatz kommt/kommen (bei nur 1 US Sender/Empfänger)
-- f) IR-Sender und -Empfänger mit Rundumsicht bzw. mind. 180° Sicht zur Kommunikation in einem 5x5m Raum (z.B. über Decken-Reflexion)
-- g) IR-Kommunikation z.B. als RC5-Code oder eigener Code
-- h) IR-Kommunikation prinzipiell möglich als: Bake-Bake, Bake-Roboter, Roboter-Roboter
-- i) Entscheidung über die "Masterfunktion" einer Bake, über die nur die Kommunikation Baken-Roboter läuft (kann auch später entschieden werden, da dies die Hardware nicht beeinflussen dürfte)
-- j) Lichtkennung der Bake zur Lichtortung durch den Roboter mit mind. 180° Ausstrahlung horizontal in den Raum (ggf. nach oben und unten schlitzartig begrenzt!)
-- k) Lichtkennung z.B. fest impulscodiert oder mit festem RC5-Kenn-Code (bis zu 8 Codes möglich?)
-- l) Lichtkennung dimmbar zur Verminderung von Reflexionen
-- m) Evtl. Farbkennung der Lichtkennung (setzt Farberkennung auf dem Roboter voraus)
3. Ansteuerung der Bake:
-- a) Vorab definierter Stecker/Pinleiste mit allen Verbindungen zu den o.g. Sensoren/Aktoren und der Stromversorgung
-- b) Prozessorsystem mit 3,3..5V I/O-Ports oder GPIOs
-- c) Keine Festlegung auf ein bestimmtes Prozessorsystem
-- d) Mindestanforderungen: Laufzeitmessungen im µs Bereich müssen möglich sein, Anzahl der I/O-Ports muss ausreichend sein, gut wären einige Hardware-PWM-Ports, EEPROM-Speicherplatz für dauerhafte Settings (alles noch genauer anhand der Punkte oben zu spezifizieren!!!)
-- e) Ein Sleep-Modus mit minimalem Stromverbrauch
-- f) Externe Aktivierbarkeit durch die IR-Kommunikation
Rabenauge
15.06.2014, 10:59
Klingt toll. so stelle ichs mir vor- dann haben möglichst viele was davon.
Aber: eigene Platine?
Klingt wiederum teuer. Auch wenn man die in ner Kleinserie machen lässt wird das nicht soo preiswert. Drauf muss auch noch was.
Ich weiss: viele mögen die Arduinos nicht, aber ich werf mal http://arduino.cc/de/Main/ArduinoBoardProMini in den Raum.
Zu bekommen unter 5€ beim Chinesen...fertig aufgebaut.
13 digitale Pins, davon 6 als PWM-Ausgänge ohne weiteren Zauber nutzbar, 6 analoge Ausgänge, gibts sowohl für 3.3V als auch für 5V, Grösse 1.8cmx3,5cm.
Läuft ab 3.3V (Versionsabhängig, gibt auch die 5V-Variante), und mit bis zu 12V.
Wäre meine erste Wahl-nich, weils nen Arduino ist aber preiswerter geht nicht-auch nicht im Eigenbau.
Programmieren kann man das Ding bequem per USB, braucht dazu nen Adapter, der auch in der Gegend kostet (einen für egal wieviele Baken nur).
Durch die Möglichkeit, normale Steckleisten einzulöten, kann man die Zubehör-Platine einfach huckepack drauf löten, und gut.
Das Gleiche liesse sich als Roboter-Erweiterung bauen, I2C, SPI ist _auch_ vorhanden!
Anstecken, und läuft.
Aber: eigene Platine?
Klingt wiederum teuer. Auch wenn man die in ner Kleinserie machen lässt wird das nicht soo preiswert.
Alternative? Steckbrett? Freiverdrahtung?
Ich weiss: viele mögen die Arduinos nicht, aber ich werf mal http://arduino.cc/de/Main/ArduinoBoardProMini in den Raum.
Zu bekommen unter 5€ beim Chinesen...fertig aufgebaut.
Kann man nehmen. Wenn wir nach 3. c) uns aber nicht auf ein bestimmtes Prozessorsystem (das wäre ja der Arduino) festlegen wollen, müssen wir das nicht VOR der Konstruktion der Baken klären.
Rabenauge
15.06.2014, 13:39
Sowieso.
Von daher wärs am sinnvollsten, einfach nur die Peripherie (alles was nach dem Controller kommt) zu entwerfen. Dann kann den Rest jeder so machen, wie ers haben möchte. Vielleicht gar mit ner I2C-Schnittstelle? Das wäre ungefähr das Optimum, da man dann _noch_ weiter aufbohren kann, wenn mans will.
Passt dann an fast alles...
Aufbau: am besten wohl auf Loch-oder Streifenraster. Dann ist das jederzeit von jedem selber zu bauen. Bei einer Kleinserie muss sich irgendjemand erst die Mühe machen, Interessenten zusammenzusammeln (von denen dann die Hälfte wieder abspringt), das Dutzend Platinchen zu organisieren, und nach nem halben Jahr kommen wieder zweie an und wollen auch...
Daher ists besser, wenn mans so macht, dass jeder sich die Pläne schnappen, und loslegen kann, auch ohne ne Ätzanlage zu haben. Wer _die_ hat, hat diese Option ja trotzdem.
Besserwessi
15.06.2014, 14:30
Für den µC macht eine fertige Platine ggf. schon Sinn. Allerdings braucht man wohl schon etwas mehr als nur den µC. Die Ausgänge der µC Platinen sind in der Regel nicht kräftig genug um eine IR LED für eine größere Reichweite zu treiben. Auch beim US Transducher braucht es noch etwas dazu: Treiber für die Sendefunktion und eine Verstärkung für die Empfangsfunktion, Selbst die IR Empfänger brauchen noch Widerstand / Kondensator und müssen ja auch irgendwie fest gemacht werden.
Das fertige US Modul könnte man wohl so modifizieren das es nur empfängt, getriggert von einem Externen Signal (z.B. IR Signal das gleichzeitig ausgesandt wird). Im einfachsten Fall halt einfach den einen Transducer für das Senden entfernen und per IR das Startsignal erzeugen. Ob das allerdings lohnt ist eine andere Sache. So kompliziert ist die Empfängerschaltung in RN-wissensbereich auch nicht - es ist aber noch ein Frage, wie gut der Empfang ist. Im Prinzip wäre da einiges an Reserve (Empfindlichkeit und Zeitauflösung) drin mit einem sehr guten Empfänger.
Der Nachteil bei den Modulen (und ähnlichen Transducern) ist aber, dass der Ulraschall recht stark gebündelt ist: man braucht also viele Sender/Empfänger und / oder muss drehen - vermutlich eher so dass man viele Empfänger hat, und dann den Sender mechanisch dreht. Statt drehen wäre es ggf. auch möglich rundum zu senden, mit einem speziellen Reflektor. Allerdings geht dabei einiges an Intensität verloren - man hat zwar einige Reserven (nur 1 Weg und keine Verluste von der Streuung bei der Refexion). Im Idealfall bräuchte man Transducer die in der Vertikalen gebündelt sind, aber in der horizontalen eher einen breiten Winkel haben.
Hi Leute,
wenn wir uns hier die Mühe machen, eine US/IR Bake zu planen, dann sollte/muss das in einer gemeinsamen Hardwarelösung enden.
Grund: Wenn wir hier eine Indoor-Navi-Lösung mit Hard- und Software entwickeln wollen, brauchen wir eine gemeinsame Hardware-Grundlage.
Sonst kann es auch keine gemeinsame oder wenigstens für Bake oder Roboter geeignete Softwarelösung geben.
So habe ich aber diese Initiative hier verstanden: Wir wollen ein Bakensystem entwickeln, dass mit dem RP6 (oder mit anderen mobilen Plattformen) funktioniert.
An einer Baken-Lösung, die jeder auf Streifenraster irgendwie aufbaut, habe ich kein Interesse und ich denke auch, dass die Schaltung der Bake dafür zu komplex ist.
Stichworte:
- Stromversorgungsschaltung
- Akku-Ladeschaltung
- Sendetreiber (IR, Lichtkennung, US)
- ggf. Empfangsverstärker (US...)
- Multiplexer, falls mehrere Sensoren für US angeschlossen werden sollen
- evtl. Pegelwandler
- ...
Letztlich machen wir den Aufwand hier ja, um etwas zu erreichen. Spätere Anwendungen können hier im Forum nur entwickelt werden, wenn es eine gemeinsame Hardware-Basis dafür gibt.
Von daher wärs am sinnvollsten, einfach nur die Peripherie (alles was nach dem Controller kommt) zu entwerfen. Dann kann den Rest jeder so machen, wie ers haben möchte. Vielleicht gar mit ner I2C-Schnittstelle? Das wäre ungefähr das Optimum, da man dann _noch_ weiter aufbohren kann, wenn mans will.
Wenn du meine Liste mit Vorschlägen oben komplett wahrgenommen hast, bedeutet mein Vorschlag ja genau das. Schnittstelle zwischen den Sensoren/Aktoren, Stromversorgung der Bake und dem Controllerboard (Arduino, RP6 M32 ...) ist (siehe 3. a!) ein definierter Stecker, hinter dem "jeder so machen kann, wie ers haben möchte".
I2C (also ein I2C-Portexpander) ist nicht ohne weiteres möglich, zumindest dann nicht, wenn das Controllerboard die US-Laufzeiten selbst messen soll. Dafür ist I2C dann zu langsam. Oder: Man macht einige Funktionen über I2C-Portexpander und die Laufzeitmessungen über direkte Portpins des Controllers. Geht auch.
Dass man für eine Platine eine Gruppe zusammenbekommen muss, die diese gemeinsam und verbindlich bestellt, ist klar. Ich wäre dann auch dabei.
Wenn wir das hier NICHT wollen, bin ich an dieser Stelle raus und kann das Ganze dann auch für mich (sicher nicht so umfangreich) umsetzen.
Rabenauge
15.06.2014, 15:08
Willst wirklich den Ultraschallkram selber bauen?
Wie ich schon sagte: die HC-SR04 sind _anschlussfertig_. Die brauchen noch ne Stromversorgung, und der Rest geht _direkt_ zum Controller!
Da brauchts einfach nix weiter. Klar: Treiber für die LED`s wären sicher nötig (wobei-ne LED packt ein Controllerpin auch, aber ob mit ausreichender Leistung?), was aber noch??
Fällt mir nix ein.
Irgendwie fängts an, mir zu kompliziert zu werden. Das Ganze sollte so simpel wie möglich sein.
Um das Beispiel mit dem MiniDuino mal zu bemühen: an das Ding noch (keine weitere Beschaltung, nur Strippen) einen oder mehrere HC-SR-04, ein Bündel LED`s (ggf. mit ner einfachen Transistorschaltung als Treiber), und die IR-Dioden plus das dazu nötige (Verstärker?) und FERTIG.
Nehmen wir jetzt den Dino weg, haben wir nen Dutzend Bauteilchen, und gut.
Nicht unnötig verkomplizieren, das soll preiswert und einfach abgehen.
Mag ja sein, dass manch einer (vermutlich sogar viele) da fitter sind als ich, aber ich seh keinen Grund, das unnötig zu verkomplizieren.
hallo allerseits,
wir theoretisieren hier und drehen uns im kreis, meint Ihr nicht auch? Schaut doch einmal zurück in dem thread, so um post 8 herum - das hatten wir doch schon alles!
Ich diskutiere zwar auch gern (manche wissen das schon) aber ich bin nicht der große theoretiker. Sollten wir nicht langsam anfangen irgendwelche kleineren bereiche der bake (US / IR/ ...) mal aufzubauen und zu testen? Um überhaupt beurteilen zu können was geht und was nicht? Oder kann jemand aus dem stand etwas über die PRAKTISCHEN fähigkeiten und eigenschaften der verschiedenen elemente aus eigener erfahrung sagen und nicht nur datenblätter zitieren?
was wir jetzt brauchen sind kleine - aber m.e. nach wichtige - praktische ergebnisse. Das kann ein sehr primitiver aufbau sein, das kann auch ein miniduino sein, oder die m32 als standalone. Es ist eigentlich egal...
Wer könnte jetzt in der richtung was machen?
kennt Ihr den begriff der inneren kündigung? Auf dem weg befinde ich mich momentan und würde am liebsten bauteile zusammenstellen um nochmal eine bake 1.0. zu bauen, die auf einer anderen frequenz sendet als die bestehende - um mit zwei baken zu testen...
Hi inka,
es wäre -glaube ich- gut, wenn du erst einmal zur Abstimmung stellst, was wir hier wollen.
Danach können Einzelfragen (z.B. welche LED leuchtet am besten, welche US-Sensoren nehmen wir) beantwortet oder in Steckbrettform ausgetestet werden.
Übrigens zum Thema "Theoretisieren": Ich bin die ganze Zeit bei der praktischen Planung! Ohne genau solch eine Planung wäre z.B. das MultiIO Projekt von fabqu nicht möglich gewesen,- und ohne Planungs-Ergebnis entsteht auch keine Bake (zumindest keine gemeinsam dann nutzbare).
Also: Was wollen wir in diesem Thread noch erreichen?
Denken wir zurück an die Anfänge (Posts 123..126). Da wollten wir eine Bake V2.0 entwickeln. Aktuell tauschen wir Gedanken und Ideen zu Baken aus.
Wo stehen wir da und wer macht noch mit?
Wo soll es hingehen?
Wenn sich jeder nur eigene Ideen aus diesem Thread zieht, dann ist das Ergebnis, dass der eine 5 der nächste 9 IR-LEDs nimmt, der eine arbeitet mit dem HC-SR04, der nächste mit einer oder mehreren US-Kapseln, jeder entwickelt seine eigene IR-Kommunikation ...
Das ist natürlich völlig ok, ich bin dann aber hier raus, weil dann klar ist, dass ein gemeinsames Ergebnis, das alle (mit eigenen Veränderungen) nutzen können, HIER nicht heraus kommt.
Rabenauge
15.06.2014, 17:10
Fertige Komplettlösungen sind meist unflexibel-oder hoffnungslos überladen. Anders gehts nunmal nicht: entweder hab ich den Anspruch: es funktioniert mit geringstmöglichem Aufwand, oder aber es funktioniert in jeder denkbaren Situation.Ich hab hier den Eindruck, dass manche letzteres wollen-sehe da aber keinen Sinn drin, denn eine einfache SchnittLeute: ich denke gar nicht dran, mit nen US-Sender oder Empfänger selber zu bauen, wenn ich nen fertigen für weniger als nen Euro bekomme, falls der die Ansprüche erfüllt.
Für meinen Teil werd ich vorerst die Klappe halten (mir wirds hier echt zu kompliziert), aber lesenderweise bei der Stange bleiben.
Hi Dirk,
es wäre -glaube ich- gut, wenn du erst einmal zur Abstimmung stellst, was wir hier wollen.
ich weiss nicht was wir hier wollen bzw. hinter welchem vorschlag sich ausreichend interessenten versammeln lassen, solange es nicht konkret wird, werden wir es auch nicht erfahren. Das ist ja das, was ich vorhin meinte, vielleicht habe ich das nicht klar genug zum ausdruck gebracht...
Ich muss zugeben ich hatte es bei bake 1.0. einfacher, ich musste niemanden von meiner idee überzeugen, habe "einfach" mit try & error gemacht und wenn es ging, wars gut, wenn nicht, habe ich es halt wieder auseinander genommen oder in den müll geworfen (war aber nicht viel) und im forum hilfe gesucht. Und gefunden...
Hier kann ich nicht sagen - das machen wir jetzt so.
Das hier war Dein vorschlag. Den sollten wir jetzt als basis nehmen. Ich habe mich zwar noch nicht dazu geäußert, wäre mit ein paar ausnahmen damit einverstanden. Ich bin der meinung, dass bei einem gemeinsamen projekt auch eine gemeinsame hardware und software als basis verwendet werden muss. Ergänzugen/erweiterungen kann jeder einzelne ja machen...
meine bemerkungen/fragen habe ich farblich markiert...
vielleicht sollte das jeder mal so machen und die auflistung im post 175 so kommentieren damit wir weiter kommen...
1. Stromversorgung:
-- a) Versorgungsspannung 3,3..5V
-- b) USB (http://www.rn-wissen.de/index.php/USB)-A-Anschluß zur Direktversorgung der Bake
-- c) Ladung eines internen Akkus über USB (http://www.rn-wissen.de/index.php/USB)
-- d) Ergänzungsladung durch kleines Solarpanel (Anschluß vorsehen)
2. Sensorik/Aktoren:
-- a) US-Sender und -Empfänger mit Rundumsicht bzw. mind. 180° Sicht
keine 12 oder 24 sender/empfänger, maximal zwei
-- b) US-Sender und -Empfänger einzeln direkt ansprechbar (keine I2C (http://www.rn-wissen.de/index.php/I2C)- oder seriellen Typen)
-- c) Reichweite US bis 5m
-- d) Vorabentscheidung, wie viele US-Sender/-Empfänger max. zum Einsatz kommen werden!
siehe oben
-- e) Parallel zu d) die Entscheidung, ob ein/zwei Kegelreflektor(en) zum Einsatz kommt/kommen (bei nur 1 US Sender/Empfänger)
wie funktioniert das? Im forum habe ich nichts dazu gefunden...
-- f) IR-Sender und -Empfänger mit Rundumsicht bzw. mind. 180° Sicht zur Kommunikation in einem 5x5m Raum (z.B. über Decken-Reflexion)
auch nur maximal zwei, könnte auf einem gemeinsamen träger mit dem US-sender/empfänger sitzen
-- g) IR-Kommunikation z.B. als RC5-Code oder eigener Code
RC5
-- h) IR-Kommunikation prinzipiell möglich als: Bake-Bake, Bake-Roboter, Roboter-Roboter
-- i) Entscheidung über die "Masterfunktion" einer Bake, über die nur die Kommunikation Baken-Roboter läuft (kann auch später entschieden werden, da dies die Hardware nicht beeinflussen dürfte)
-- j) Lichtkennung der Bake zur Lichtortung durch den Roboter mit mind. 180° Ausstrahlung horizontal in den Raum (ggf. nach oben und unten schlitzartig begrenzt!)
was meinst Du mit lichtkennung?
-- k) Lichtkennung z.B. fest impulscodiert oder mit festem RC5-Kenn-Code (bis zu 8 Codes möglich?)
-- l) Lichtkennung dimmbar zur Verminderung von Reflexionen
-- m) Evtl. Farbkennung der Lichtkennung (setzt Farberkennung auf dem Roboter voraus)
keine farberkennung auf dem roboter
3. Ansteuerung der Bake:
-- a) Vorab definierter Stecker/Pinleiste mit allen Verbindungen zu den o.g. Sensoren (http://www.rn-wissen.de/index.php/Sensorarten)/Aktoren und der Stromversorgung
-- b) Prozessorsystem mit 3,3..5V I/O-Ports oder GPIOs
-- c) Keine Festlegung auf ein bestimmtes Prozessorsystem
glaube nicht dass das gutgeht (gemeinsame basis!)
-- d) Mindestanforderungen: Laufzeitmessungen im µs Bereich müssen möglich sein, Anzahl der I/O-Ports muss ausreichend sein, gut wären einige Hardware-PWM-Ports, EEPROM-Speicherplatz für dauerhafte Settings (alles noch genauer anhand der Punkte oben zu spezifizieren!!!)
-- e) Ein Sleep-Modus mit minimalem Stromverbrauch
-- f) Externe Aktivierbarkeit durch die IR-Kommunikation
Besserwessi
15.06.2014, 18:20
Die Punkte die zuerst festgelegt werden sollten sind eher die Sensoren Sender. So etwas wie Stecker / Versorgung ergibt sich dann daraus.
Ein offener Punkt beim Ultraschall ist noch die Frage des Öffnungswinkels - die Transducer sind halt gerichtet, und das stört hier. Bei einer Seite könnte man wohl mit einem Reflektor auf ein Größeren Winkel kommen, ggf. sogar als Rundumsicht. Das kostet einiges an Signalstärke, aber so viel sollte drin sein, weil die Reflexion der Abstandsmessung wegfällt - das gibt im Extremfall ja auch eine mehr oder weniger Rundumstreuung. Ich fürchte bei der anderen Seite wird man wohl bei den gerichteten Verhalten bleiben müssen, und z.B. den Sender (oder Empfänger) am Bot drehen müssen, damit genug Signal ankommt. Die Alternative von mehreren Empfängern (bzw. Sendern) je Bake gefällt mir da weniger.
Wenn die fertigen US Module wirklich so günstig sind, könnte man es damit versuchen. Man sollte aber bei dem Design nicht total von einem Sonderangebot eines Chinesen abhängig sein. Ein Eigenbau als Alternative zum fertigen Modul bleibt ja immer noch möglich.
Beim US ist auch noch die Frage in welche Richtung: der Sender am Bot hätte den Vorteil, das es ruhig bleibt weil nur 1 Sender da ist, und ggf. mehrere Baken parallel Empfangen können. Der Empfänger auf dem Bot hätte den Vorteil, dass nur 1 Empfänger gebraucht wird, und die Sender sehr einfach (da braucht man nicht unbedingt ein Modul) sind. Damit könnte man für den einen Empfänger ggf. mehr Aufwand treiben und ggf. Empfindlicher werden. Mit fertigen Modulen wäre das egal, aber beim Eigenbau würde es einen Unterschied machen.
Hi inka,
nur kurz zu den Fragen:
1. Kegelreflektoren
Im Projekt von (Stephan Höhrmann (http://www.informatik.uni-kiel.de/~railway/Downloads/hoehrmann1.pdf)) kann man das schön auf dem Titelbild sehen: Die US-Kapsel ist nach oben gerichtet, darüber liegt ein Kegel, der den US quasi horizontal in alle Richtungen in den Raum reflektiert.
2. Lichtkennung
Das war ein Vorschlag von Rabenauge: Der Roboter kann eine Bake per Licht (er hatte glaube ich IR vorgeschlagen) orten, damit man den US-Sensor in die Richtung der Bake drehen kann.
Besserwessi
15.06.2014, 20:42
Der Link zur Arbeit von Stephan Höhrmann ist interessant: die Intensität reicht da sogar mit 2 Kegelförmigen Reflektoren und das sogar mit einem einfachen Empfänger. Das vereinfacht die Sache natürlich deutlich, und erspart ein paar Vorversuche. Damit hätte man die Möglichkeit US rundum zu Senden und zu Empfangen. Das gerichtete Senden hätte man dann immer noch als Option für größere Reichweite, bzw. bei viel Hintergrundgeräusch. Wie gut die Empfängerschaltung auf den fertigen Modulen ist, muss man noch sehen. Wenn wider Erwarten das Modul zu schlecht ist, hätte man da schon mal einen Ansatz für den Eigenbau, wobei ich eher die Version hier aus dem RN-Wissen, mit variabler Verstärkung bevorzugen würde.
Der wesentliche Unterschied ist hier wohl das die Synchronisation hier wohl über IR statt Funk ablaufen soll (ist günstiger ?). Beim Senden in alle Richtungen wäre ich eher gegen die Reflexion an der Decke (geht draußen nicht), sondern eher für ein paar mehr Sendedioden + ggf. Optik und mehrere (3 oder 4) Empfänger Chips. Wenn der Bot in alle Richtungen IR sendet, muss ja auch nicht jede Bake jede Richtung empfangen, sofern die Baken unter sich verbunden sind. Für das eigentliche System macht es aber nicht viel Unterschied wie die LEDs ausgerichtet sind. Man wird wohl parallel zum US Puls ein IR Signal senden müssen, um die Empfänger synchron zu starten. Also wohl am Bot US + IR Senden und dann von den Baken ein Rücksignal (verzögert vom IR Signal - je Bake Unterschiedlich - mit der Zeitmessung oder der berechneten Position).
Die Alternative wäre sonst von den Baken US und IR im festen Takt zu senden (z.B. alle 100-200 ms eine Bake mit US, so dass etwa jede Sekunde alle einmal gesendet haben) und am Bot nur empfangt. Damit bräuchte man nur IR Kommunikation in eine Richtung, hätte aber eventuell mehr Stromverbrauch bei den Baken und halt immer ein Hintergrund Signal. Ob das wirklich mehr Strom ist müsste man sehen - nur US Senden kostet nicht viel, und man spart sich damit die meisten IR Empfänger an den Baken, die immer laufen müssten. Da könnte man auch überlegen das Signal zum US Senden extra zu erzeugen und zum Senden kein fertiges Modul zu nutzen. Als Vorteil würde das System auch für mehr als einen Bot Gleichzeitig gehen. Was einem damit aber weitgehend fehlt, ist aber die Orientierung des Bots. Das ginge ggf. mit einem Empfänger, der die Richtung bestimmen kann - ggf. als 2. , gerichteter US Empfänger.
Manchmal hab ich das Gefühl, ihr lest meine Posts nicht...
Ich hatte bereits beschrieben und durchargumentiert, das es ein ungreichteter Schallimpuls und ein ungerichteter IR Impuls vom Bot kommend gleichzeitig gesendet werden muss... und auch schon beschrieben das 2 bis 3 "Baken" bzw. Empfänger für beides dann die Impulse aufnehmen.. um dann die Schall Laufzeit zu triangulieren!
Das ist ein simpeles Konzept was auf dem Bot mit einem Transistor, einer oder mehrere IR Dioden als Rundstrahler angeordnet und einem kleinen Hochtöner gesteuert von einem ADC portpin auskommt.. und an den Baken im Prinzip eine (bis zu 8) IR-Empfängerdiode (diese ganzen IR-ICs sind dafür ungeeignet) mit einer elektretkapsel + nf verstärker und einem Logik Board auskommt. Zusätzlich braucht man noch ein IR Sendediode an der Bake damit der Bot mit der Bake reden kann... und das wars schon! Was bitte ist daran kompliziert? Wo ist das Problem?
Fertige Ultraschallkapseln bündeln den Impuls viel zu sehr... und schicken zudem Impulspakete und keine Einzelimpulse ... wer das ignoriert hat das Funktionsprinzip nicht verstanden! Das gleiche gilt für fertige IR-Empfänger, denn sie reagieren im allgemeinen nicht auf einen "IR-Blitz" sondern ebenfalls auf Impulspakete!
Der Kegelreflektor ist zudem eine optionale Erweiterung, welche man auch auf dem Hochtöner anbringen könnte. Darüber diskutier ich aber erst wieder wenn ich den Aufbau soweit zusammen habe. Und das ist noch ein Punkt - ich habe gesagt das ich derzeit keine Gelegenheit habe, selbst was aufzubauen da ich nun erst mal 2 Wochen in Urlaub bin.
Und auch noch mal zur Orientierung des Bot: DIESES SYSTEM IST NICHT GEEIGNET UM DEN YAW WINKEL ZU MESSEN, das kann ein i2c-Kompas für 20 € auf dem Bot besser!
So ich bin dann mal weg!
Gruß
Besserwessi
16.06.2014, 20:59
Die Ultraschall-kapseln sind etwas stärker gerichtet als ein Hochton Lautsprechern - mit dem Reflektor in Kugel oder Kegelform macht das dann aber keinen so großen Unterschied mehr. Der wesentliche Unterschied ist dann mehr dass die Kapseln günstiger und kleiner sind, und wohl auch mit weniger Energie auskommen. Die Kapseln sind resonant, und könnte damit keine Einzelpulse senden, das sollte aber dennoch ausreichen für einen Auflösung beim Abstand von besser als 1 cm, ggf. auch 1 mm. Die Schwierigkeit ist halt die Erkennung der Periode, also Stufen von 1 Wellenlänge - wenn man die hat, ist der Fehler danach eher klein. Im Vergleich zur Messung in Reflexion hat man hier den Vorteil, das die Intensität nur vom Abstand abhängt, nicht mehr vom Reflektor. Damit wird die Auswertung der Pulspakete vereinfacht und auch mit den Kapseln sollten genaue Messungen möglich sein - ggf. braucht es halt für jeden Empfänger eine Kalibrierung. Ob dafür die Auswerteschaltung in den einfachen US Modulen taugt kann man probieren.
Die fertigen IR Empfänger arbeiten mit Pulspaketen, aber das ist nicht unbedingt ein Nachteil. Man kann auch damit eine genaue Synchronisierung erreichen - etwa bis in den Bereich von 1 Periode der Modulation (z.B. 40 kHz). Es gehört schon etwas Überlegung und wohl auch die Auswertung von mehr als einer Flanke dazu, aber an sich geht das. Ein Empfänger für IR pulse ist auch nicht so trivial, wenn man keine Verzögerung abhängig von der Signalintensität haben will. Auch ist das ein ganz schöner Aufwand im Vergleich zu einem, fertigen Empfänger, den man für < 1 EUR bekommt. Wenn man eine sehr hohe Auflösung (besser 1-10 µs) bei der Zeit haben will, wäre ggf. ein Eigenbau des IR-Empfängers hilfreich, aber auch da würde ich erst einmal testen wie gut es mit der einfachen Version geht. Den wirklichen Nachteil haben die fertigen IR Empfänger darin, das man kaum Information über die Amplitude bekommt. Das wäre ggf. interessant wenn man den Yaw Winkel sehr genau über einen gerichteten Sender (oder Empfänger) am Bot bestimmen will. Mit ein paar Abstrichen (etwas mehr Zeit, nicht ganz so genau) geht das aber auch mit den fertigen Empfängern noch.
Die Nutzung von Pulspaketen erlaubt auch einen besseren Schutz vor Störungen. Auch mit der Kombination Lautsprechern - Mikrofon wird man eher kurze Bursts senden, wenn auch eher eine etwas andere Form.
Hi,
Manchmal hab ich das Gefühl, ihr lest meine Posts nicht...
Das Gefühl kenne ich! :p
DIESES SYSTEM IST NICHT GEEIGNET UM DEN YAW WINKEL ZU MESSEN
... wenn man den Yaw Winkel sehr genau über einen gerichteten Sender (oder Empfänger) am Bot bestimmen will
Wie gesagt: Richtig, solch ein System kann die absolute Drehrichtung (YAW) nicht messen. Wenn der Bot in gerader Linie in Bewegung ist, bekommt man nach mind. 2 Triangulationsergebnissen aber schon die Bewegungsrichtung und die ist bei gerader Vorausfahrt identisch mit YAW.
RolfD:
Das ist ein simpeles Konzept was auf dem Bot mit einem Transistor, einer oder mehrere IR Dioden als Rundstrahler angeordnet und einem kleinen Hochtöner gesteuert von einem ADC portpin auskommt.. und an den Baken im Prinzip eine (bis zu 8 ) IR-Empfängerdiode (diese ganzen IR-ICs sind dafür ungeeignet) mit einer elektretkapsel + nf verstärker und einem Logik Board auskommt. Zusätzlich braucht man noch ein IR Sendediode an der Bake damit der Bot mit der Bake reden kann... und das wars schon! Was bitte ist daran kompliziert? Wo ist das Problem?
Also wir hätten dann lt. RolfD:
==> Roboter:
- IR-Sender mit Rundumsicht
- US- oder Schallsender mit Rundumcharakteristik
- (Fehlt: IR-Empfänger???)
==> Baken:
- IR-Empfänger mit Rundumsicht
- US- oder Schallempfänger mit Rundumsicht
- IR-Sendediode mit Rundumsicht
Auch das war doch schon (z.B. von mir) vorgeschlagen worden, wobei ich für eine "universelle" Baken-Version nur ergänzt hatte:
- IR-Empfänger mit Rundumsicht auf dem Bot (muss ja, s.o.)
- US auch in die andere Richtung (Bot empfängt, Baken senden) optional vorsehen
- Lichtkennung der Bake optional
Dann könnten wir ja mit einem Schaltungsentwurf starten, oder inka?
hi Dirk,
nett dass Du fragst :-)...
Ich würde sagen ja, wobei ich selbst schon ein wenig die übersicht verloren habe, was der letzter stand war und wer bei der diskussion nun das letzte wort hatte...
Um das alles nun sauber zu trennen habe ich am anfang vorgeschlagen zu diesem zeitpunkt einen neuen thread anzufangen und auch - ansatzweise - bereits einen artikel im RN-wissen anzulegen. Auch um den stand beim entwicklungsstart festzuhalten, damit jeder weiss, welcher stand das war - und damit diese basis auch jederzeit erweitert, bzw. geändert werden kann...
Lieber Dirk, würdest Du das bitte übernehmen?
Als Du damals mich als projektleiter vorgeschlagen hast war das nett gemeint, aber inzwischen stolpere ich nur hinterher und komme mir wie jemand vor der zwar eine "wichtige" funktion innehat, aber ansonsten nur das aufschreibt was andere ihm sagen. In der industrie nannte man soetwas zun meiner zeit dort "frühstücksdirektor"...
Ich bin lesend und evtl. fragend und - wenn ich es kann - helfend immer noch dabei, am ende werden wir uns alle entscheiden müssen ob das entwickelte das ist was wir (jeder einzelne für sich) wollten und wieviel geld wir bereit sind dafür auszugeben...
In der zwischenzeit kostet es "nur" unsere zeit, sollte aber spassmachen...
Hi inka,
Als Du damals mich als projektleiter vorgeschlagen hast war das nett gemeint,...
Das war wohl RolfD (siehe Post #123) (https://www.roboternetz.de/community/threads/63467-IR-bake?p=600007&viewfull=1#post600007), aber ich habe dem natürlich auch gern zugestimmt und halte das weiter für sinnvoll, da du den praktischen Vorsprung mit einer eigenen Bake hast.
Tja, wie geht's weiter?
Ich bin da genauso ratlos wie du, vermute aber, dass wir eine gemeinsame Lösung weder letztlich alle wollen noch hinkriegen.
Ich merke bei verschiedenen Posts, dass die Kollegen teilweise eher selbst etwas ausprobieren wollen (z.B. RolfD nach seinem Urlaub) oder "nur" eine Art "Bastelanleitung" brauchen und dann alles im eigenen "Kämmerlein" so oder ganz anders umsetzen (z.B. Rabenauge), wieder andere beteiligen sich eher mit Grundlagen- und Wissens-Beiträgen, ohne dass klar ist, ob sie wirklich ein Bakensystem haben und nutzen möchten (z.B. Besserwessi).
Ich denke nicht, dass aus dieser Mischung ein Interesse für eine gemeinsame Hardware-Basis für eine Bake entstehen kann. Das soll keine Kritik sein, aber zu einem gemeinsamen Projekt gehört auch, sich wenigstens auf basale Fragen einigen zu können. Wenn das gelungen wäre, bräuchte es noch jemanden (=Projektleiter), der dann Vorschläge zur Schaltung macht, das Ergebnis dann irgendwann layoutet und bestellt.
Eine Möglichkeit wäre vielleicht noch einmal eine Rundfrage, wer daran interessiert ist, z.B. eine Platine anfertigen zu lassen, auf der die nötigen "Basisfunktionen" einer hier im Groben beschriebenen Bake aufbaubar sind. Eine Platinen-Herstellung lohnt sicher nur, wenn mind. 30 Einzelstücke (= Baken-Platinen) abgenommen werden, besser natürlich mehr.
Eine Alternative wäre, diesen Thread als Disskussionsforum weiter zu führen, aber ohne konkrete Absicht, daraus etwas Gemeinsames zu machen. Damit kann ich gut leben (du wohl auch im Sinne eines Beendens der Projektleitung).
Ich kann zwar auf Wunsch einen Artikel im RN-Wissen dazu anlegen, würde den aber nicht federführend abfassen und aktualisieren, weil ich schon eine "Handvoll" Artikel zum RP6 im RN-Wissen betreue.
Rabenauge
17.06.2014, 16:00
Ich hab durchaus Interesse dran, das zusammen mit anderen durchzuziehen.
Aber nur unter bestimmten Bedingungen, als da wären:
-das Ding musss _mir_ bei _meinem_ Vorhaben nutzen (kleine Anpassungen sind ok, aber nich nen kompletter Umbau)
-das Teil sollte so preiswert sein, wie es eben geht (ich glaub nich, dass mir _irgendwer eine Platine ätzten kann für das, was eben z.B. der MiniDuino kostet-lass mich da aber gern überzeugen. Ich hab das Ding nicht ins Rennen geworfen, weil ich Fetischist bin, sondern weil man wohl eine _einsatzfertige_ Platine für das Geld einfach nichs elber machen kann).
- es soll so einfach sein, dass ich mit meinem bescheidenen elektronischen Wissen nachher in der Lage bin, es mir zu modifizieren und auch Fehler finden kann
-KISS-Grundsatz. Sicher: es geht immer alles besser, grösser, toller-und unnötig komplizierter. Funktionieren solls, da ist im allgemeinen WENIGER dann mehr...
Momentan wird hier von Zeugs geredet (teilweise) dessen Sinn ich nicht nachvollziehen kann- und auch keine Notwendigkeit für sehe (oder sie eben einfach nich verstehe). Also halt ich mich da erstmal raus und warte ab.
So: heut kam mein Knautschpäckchen mit ner Handvoll HC-SR04-Sensoren an.
Hat denn schon mal _irgendjemand_ rausgefunden, ob die Dinger miteinander überhaupt kommunizieren _können?
Ich meine, zwei getrennte...?
Hi Rabenauge,
ich glaub nich, dass mir _irgendwer eine Platine ätzten kann für das, was eben z.B. der MiniDuino kostet-lass mich da aber gern überzeugen. Ich hab das Ding nicht ins Rennen geworfen, weil ich Fetischist bin, sondern weil man wohl eine _einsatzfertige_ Platine für das Geld einfach nichs elber machen kann
Ich stelle das nochmal klar:
Ich will keine Microprozessorplatine (wie MiniDuino) anfertigen lassen, sondern die Treiber und Auswerteschaltungen und die Stromversorgung einer universellen US-/IR-Bake auf eine Platine packen, um sie auch mehrfach für Baken nutzen zu können. An diese Platine werden auf der einen Seite die Sensoren/Aktoren und z.B. ein Netzteil oder Solarpanel, auf der anderen Seite eine Microprozessorplatine angeschlossen.
Auf dieser Platine sitzt also noch kein Microprozessor, so dass du deinen MiniDuino da anschließen must, damit das ganze als Bake funktioniert. Ich denke, du hast das aber auch schon verstanden.
KISS-Grundsatz. Sicher: es geht immer alles besser, grösser, toller-und unnötig komplizierter. Funktionieren solls, da ist im allgemeinen WENIGER dann mehr...
Wenn du mal z.B. meinen Post #191 liest, in dem ich z.B. die auch die Ideen von RolfD kurz zusammen gefaßt habe, dann ist das nur die Minimal-Ausführung einer Baken-Ausstattung. Was ist daran kompliziert? Wenn du etwas eigenes machen willst, wirst du diese Teile auch alle brauchen (wenns funktionieren soll).
Hat denn schon mal _irgendjemand_ rausgefunden, ob die Dinger miteinander überhaupt kommunizieren _können? Ich meine, zwei getrennte...?
Meine 10 Stk. sind noch unterwegs.
Wenn du sie hast, teste das doch schon mal. Wäre ja ein gutes Ergebnis, wenn es gehen würde. (Warum sollte das aber nicht gehen??? :confused: )
Rabenauge
17.06.2014, 23:03
Bin bei, bin bei...heute wird das aber nix mehr (meine Boards stecken alle in Projekten, da muss ich erstmal Adapter basteln um die mal schnell anzustecken) aber es gibt schon ne -wie ich finde-interessante Erkenntnis:
Einen hab ich nämlich laufen, am Buggy (sollt da eh ran): Laut "Anleitung" soll man den Trigger-Pin 10µs bestromen, und _dann_ aufs Echo horchen.
Damit dauert ne Messung mindestens 12µs plus Laufzeit: es geht schneller.
Momentan triggere ich lediglich 2µs- und das funktioniert genauso!
Also dauert ne komplette Messung eben nur 4µs plus die Laufzeit(=Entfernung).
Morgen (bzw. inzwischen isses ja schon morgen, also vermutlich heute noch) test ich mal, ob die sich untereinander hören, und wie gut.
Hi Rabenauge,
auf dieser Seite (http://uglyduck.ath.cx/ep/archive/2014/01/Making_a_better_HC_SR04_Echo_Locator.html) von "Emil" sind ein paar interessante Infos und der Schaltplan des HC-SR04.
Als Sendetreiber dient ein MAX232, durch den die Sendekapsel mit 20V angesteuert wird. Genial gelöst.
Der Empfänger ist mit LM324 (4 OPAMPS) aufgebaut.
Da gibt's auch noch einen µC,- und da fangen die Probleme an, wenn man Sender und Empfänger einzeln nutzen will.
Offenbar gibt es grob diesen Ablauf:
- Der Trigger-Impuls wird angelegt
- Der µC schaltet nach 10µs den MAX232 ein
- Nach 248µs (Zeit für den MAX232, seine Ladungspumpen hochzufahren) werden 8 Impulse abgegeben.
- Der MAX232 wird ausgeschaltet (weil er den Empfang stören würde)
- Es wird auf das 1. Echo gewartet
- Der Impulsausgang wird aktiviert
Aus meiner Sicht bedeutet das:
SENDER:
Die Nutzung als Sender ist einfach. Man legt den Trigger-Impuls an, nach wohl 258µs werden die Impulse erzeugt.
EMPFÄNGER:
Das ist komplizierter. Man kann das Echo-Signal an "Signal" (siehe Schaltplan) abnehmen. Ansteuern mit einem eigenen Microprozessor müßte man auch noch "Threshold". Damit kann man den Verstärker blocken. Den eingebauten µC auf dem HC-SR04 kann man dazu nicht gebrauchen ODER man speist das IR-Synchronisationssignal am Trigger-Eingang ein und trennt den US-Sender komplett ab.
Also: Viel Erfolg bei deinen Versuchen.
Hi Dirk,
Tja, wie geht's weiter?
Ich bin da genauso ratlos wie du, vermute aber, dass wir eine gemeinsame Lösung weder letztlich alle wollen noch hinkriegen.
das hat sich immer mehr zu einem problem herauskristalisiert. Es ist aber die frage ob es wirklich ein problem ist?
Eine Alternative wäre, diesen Thread als Disskussionsforum weiter zu führen, aber ohne konkrete Absicht, daraus etwas Gemeinsames zu machen. Damit kann ich gut leben. evtl. ist es sogar gut, diese verschiedenen konzepte versuchsweise nebeneinander laufen zu lassen? Jeder tut das was er für richtig hält und schreibt über erfolge oder misserfolge...
Eine Möglichkeit wäre vielleicht noch einmal eine Rundfrage, wer daran interessiert ist, z.B. eine Platine anfertigen zu lassen, auf der die nötigen "Basisfunktionen" einer hier im Groben beschriebenen Bake aufbaubar sind.ich glaube für diese frage ist es viel zu früh...
Ich kann zwar auf Wunsch einen Artikel im RN-Wissen dazu anlegen, würde den aber nicht federführend abfassen und aktualisieren, weil ich schon eine "Handvoll" Artikel zum RP6 im RN-Wissen betreue.das macht glaube ich - so wie sich das entwickelt - jetzt keinen sinn...
edit: und ich könnte neben dem lernen durch mitlesen an der bake 1.1. weiterarbeiten...
Hi inka,
evtl. ist es sogar gut, diese verschiedenen konzepte versuchsweise nebeneinander laufen zu lassen? Jeder tut das was er für richtig hält und schreibt über erfolge oder misserfolge...
Klingt gut für mich.
und ich könnte neben dem lernen durch mitlesen an der bake 1.1. weiterarbeiten...
Ok, viel Erfolg!
Rabenauge
19.06.2014, 17:29
Hm-ja, gefällt mir auch.
Wird allerdings dann bei mir noch dauern, ehe da mal was greifbares wird- immerhin gibts meinen Roboter noch nicht mal. Und auch für nen paar Baken (könnt ich evtl. im Buggy auch verwursten zum testen) fehlts momentan an "übriger" Hardware so bisschen.
Aber ich hab gestern noch mal mit den HC-SR04 rumgespielt: es stimmt. Ohne irgendwelche Tricks hört der eine den anderen nicht.
Das macht die Sache dann doch etwas komplizierter.
Mal sehen, was mir als Empfänger einfällt-mit irgendeinem Mikrofon plus Verstärkung ists ja auch nicht getan, dann würd das Ding ja jeden Mist hören.
Besserwessi
19.06.2014, 18:08
Damit das eine Modul das andere hört müsste man wohl beide etwa gleichzeitig starten, und bei dem das nur Empfangen soll den Sender lahm legen. Damit müsste es funktionieren.
Die Empfängerschaltung ist schon relativ einfach. Die Trennschärfe muss nicht so schlecht sein - der Transducer selber ist schon resonant und filtert die 40 kHz raus. Dazu kommt dann noch ein aktiver Bandpass. So schlecht ist das nicht, denn ein schärferer Filter würde auch mehr Verzögerung und damit Fehler bringen. Der Empfänger sieht aber nicht so aus als wäre er auch wenig Rauschen ausgelegt (der LM324 ist nicht gerade rauscharm, und die gewählte Schaltung auch nicht). Es wird also vor allem auf eine relativ große Amplitude des Signals gesetzt - auf schwache Signal reagiert der Empfänger eher nicht, dafür ist auch die Verstärkung noch relativ gering.
Eine viel besseren Empfänger hätte ich auch nicht erwartet - so ganz einfach ist das wohl auch nicht: Die Schwierigkeit ist es da einerseits nur das gewünschte Signal zu erkennen und trotzdem eine definierte Reaktionszeit zu bekommen. Um es wirklich gut zu bekommen wäre das etwas für eine digitale Auswertung - allerdings wohl etwas zu schnell für einen klassichen AVR - eher etwas für einen kleinen ARM. Das ist dann aber mehr ein extra Projekt - als ein Präzisions US Empfänger. Wenn man es einmal zusammen hat, muss der Aufwand nicht einmal so groß und aufwendig sein.
Rabenauge
19.06.2014, 20:22
Wenn man den Sender lahmlegt-vielleicht. Wollt natürlich nicht gleich wieder eins der neuen Module auseinander nehmen (brauch die im Ganzen).
Was ich versucht hab war folgendes:
Zwei räumlich (und physisch) getrennte Boards, jedes mit so nem Ding ausgerüstet. Der eine sendet nur (einfach immer triggern) und der andere "sendet" lediglich als Dummy- der Triggerpin war praktisch einfach nicht verbunden.
Dann "hört" das Ding allerdings auch nichts....
Natürlich waren beide Geräte nicht wirklich synchronisiert, ich hab aber beiden verschiedene Zeitintervalle gegeben, so dass sich zumindest gelegentlich was hätte ergeben müssen. Hats nicht.
Hi Rabenauge,
und der andere "sendet" lediglich als Dummy- der Triggerpin war praktisch einfach nicht verbunden. Dann "hört" das Ding allerdings auch nichts....
Das Modul, das du als Empfänger nutzen willst, kann auch nichts hören, wenn es keinen Trigger-Impuls bekommt.
Natürlich waren beide Geräte nicht wirklich synchronisiert, ich hab aber beiden verschiedene Zeitintervalle gegeben, so dass sich zumindest gelegentlich was hätte ergeben müssen. Hats nicht.
Da der Empfänger (ohne Trigger-Impuls) dauerhaft taub ist, wird sich da auch nichts tun.
Ich unterstütz das gern wo es geht aber ich hab auch eigene Projekte an der Backe und werde ggf. zu denen gehören, die später dann ein Bausatz der Bake 2.0 bei dir erwerben (siehe io-board).
Das war ich in Post 123.
Offensichtlich besteht bei Inka kein gesteigertes Interesse an Bake 2.0 und es wird sich mit Unwissenheit entschuldigt
edit: und ich könnte neben dem lernen durch mitlesen an der bake 1.1. weiterarbeiten...
und Rabenauge zieht sich auch auf Positionen zurück, die nicht förderlich sind.
Momentan wird hier von Zeugs geredet (teilweise) dessen Sinn ich nicht nachvollziehen kann- und auch keine Notwendigkeit für sehe (oder sie eben einfach nich verstehe). Also halt ich mich da erstmal raus und warte ab.
Stattdessen wird sich ohne jede Konzeption ersatzweise mit dem SR04 beschäftigt, einem US-Reflexsensor zur Hinderniserkennung in einem -+30° Öffnungswinkel ...
Leute, ich bin aus dem Projekt raus! So.. wird das nie was!
Aber wenn ihr unbedingt wissen wollt wie man den SR04 nutzt, guckt doch einfach mal nach... http://www.elecfreaks.com/store/download/product/Sensor/HC-SR04/HC-SR04_Ultrasonic_Module_User_Guide.pdf
Da gibts - oh Wunder - sogar ne Software Lib zu...
Rabenauge
25.06.2014, 00:01
Hm, verstehe dein Problem nicht.
Bisschen hab ich so den Eindruck, dass hier manche die Sache auf die urdeutsche Art angehen wollen: so wissenschaftlich und kompliziert wie möglich. Wenns dann trotzdem noch funktioniert-auch gut.
Das ist nicht so mein Ding, ich hatte nen Vorschlag gemacht, wie ich mir die Sache denke-so richtig hat keiner was dagegen sagen können (oder wollen, wie auch immer), warum es _so_ eben nicht funktioniert.
Ich bin also nach wie vor (vielleicht auf dem Holzweg...) relativ überzeugt davon: so gehts. Und noch einfacher wohl kaum.
Manch einer hier will scheinbar das ultimative Bakensystem: Ok-macht das (machen, nich bloss quatschen), da mir dazu schlicht das Können fehlt les ich eifrig mit und gucke dann, ob das, was dabei rauskommt, zu meinen Vorstellungen passt. Wenn ja: toll, wenn nicht mach ichs eben anders...
Ich _brauche_ nicht die ultimative Superlösung. Ich brauch was, das einfach nur _ausreichend_ funktioniert.
Dafür brauch ichs so "billig" wie möglich- sonst nämlich kann ichs mir nicht leisten und dann nutzt es mir auch nix.
Mein Problem?
so wissenschaftlich und kompliziert wie möglich
So ein durchgeknallter Quatsch! Was bitte ist an der Methode, ein Schallimpuls ab einem Blitz zu messen wissenschaftlich oder kompliziert? Sowas bringt man jedem Kind beim Gewitter mit zählen bei..
Begründe doch bitte mal, wie dein Bauvorschlag zur Bake mit einem SR04 funktioniert. Ich möchte zumindest sehen, in wie weit dein Bauvorhaben in die gesteckten Eckdaten passt bevor ich was nachbauen soll. Statt von 2 Leuten zu schreiben "ich peil das hier alles nicht, ich fummel mir selbst was zusammen" ... wäre es hilfreicher mal zu sagen was nicht verstanden wird. Da kann man dann auch drauf eingehen. Aber vielleicht kauft ihr euch erst mal nen Elektronik Experimentierkasten von Kosmos und lernt "urdeutsch" die Elektronik Grundlagen statt sr04 Module wie Lego zusammen zu stecken!
Ich wusste auch nicht, das strukturiertes Arbeiten mit der Nationalität zusammen hängt aber wenn du den Zusammenhang herstellst, wirst du es ja wohl wissen...
Der Projektleiter hat kein Bock auf das Projekt, nen Klugscheisser labert ohne jede Umsetzung von Kritik bzw. Hinweisen 90% Müll und der nächste meint absolut Ahnungslos mit Begriffen wie "Urdeutsch" rumwerfen zu müssen...
Ne tut mir leid... ich bin aus dem "Projekt" raus. Mit der Mannschaft hier wäre es nen Wunder, wenn mehr als 3 Leute überhaupt eine LED zum leuchten kriegen wobei einer schon damit zufrieden war (Bake 1.0) ... wenn ihr das anders seht, baut doch einfach ohne mich weiter :D Viel Erfolg
Rabenauge
25.06.2014, 10:36
So ein durchgeknallter Quatsch! Was bitte ist an der Methode, ein Schallimpuls ab einem Blitz zu messen wissenschaftlich oder kompliziert? Sowas bringt man jedem Kind beim Gewitter mit zählen bei..
Genau diese Methode schlug ich vor. Gast du meinen Beitrag dazu überhaupt gelesen?
Ok, ich mache mir die Mühe gerne noch mal.
Ich sagte: die Baken müssen transportabel sein (möglich, dass das nicht jeder braucht, ich aber schon).
Damit sollten sie so wenig Strom wie möglich verbrauchen also
-kommt in die Bake lediglich ein US-Empfänger
Vorteile: man braucht nur einen Sender und es gibt bei mehreren Baken keinen Ultraschall-Müll. Und das ohne viel Programmieraufwand
Dass die SR-04 als reine Empfänger nicht ohne weiteres taugen, hatten wir schon, aber ich sehe noch immer _nichts_ was gegen so ein Ding im Roboter spricht? Nen reiner Sender würde genügen aber: gibts den, für nen ähnlichen Preis??
Ich gehe sogar soweit, das Ding im Roboter _auch_ für andere Zwecke (Hinderniserkennung etc.) nebenher benutzen zu können/wollen.
-der Roboter braucht _keinen_ Rundum-Sensor für Ultraschall!
Er kann sich nämlich drehen-oder auch nur den Sensor drehen, das kann jeder bauen wie er will.
Synchronisiert wird, wie du _auch_ vorschlugst (ich ebenfalls) per Lichtblitz. Darüber sollte auch die restliche Kommunikation laufen, denn es ist einfach schneller (hab nix gegen Tempo, wenn es sich praktisch nebenher ergibt).
Die Bake braucht für Infrarot lediglich _einen_ Sender (ausreichend kräftig), und auch nur _einen_ Empfänger- sie muss nicht wissen, aus welcher Richtung der Roboter kommt. Dann nämlich muss sie auch entsprechend aufgestellt sein, sonst machts keinen Sinn.
Der Roboter verfügt über IR-Sender rundum, und über mehrere IR-Empfänger, die kreisförmig angeordnet sind.
Vorgehen: Roboter sucht Bake, also sendet er rundum nen kräftigen Lichtblitz(der natürlich moduliert sein sollte). Die Bake(n) registriert das, und alle Baken, die den Blitz empfangen haben, antworten nun.
Da der Roboter aufgrund seiner IR-Empfänger die Richtung grob weiss (ich halte da ne Auflösung von etwa 30 Grad für ausreichend, also soo viele braucht man gar nicht), kann er sich _jetzt_ ne Bake aussuchen, und die gezielt ansprechen.
Es wird nun die Entfernung per US ermittelt und schon kann er die Bake ansteuern. Je näher er kommt, umso schmaler wird der Kegel, in dem er sie empfängt, womöglich reichen da sogar noch weniger IR-Empfänger.
Bei Bedarf kann er in der Zwischenzeit durchaus auch mit den anderen Baken kommunizieren.
Das war das, was ich vorschlug (fanden zu der Zeit einige auch gut)- und was stört dich daran?
Das System ist fleibel denn, es funktioniert auch unter unbekannten Bedingungen: beispielsweise kann ich die Baken als "Pfad" anordnen, und den Roboter so von A nach B lotsen (theoretisch soger über grössere Entfernungen), ich kann die Baken an beliebigen Orten (Nachbars Garten, oder mein Keller) aufstellen als virtuelle Grenzlinie, ich kann mir eine der Baken an den Gürtel hängen, und sie so als virtuelle Leine benutzen...
Und all das mit ziemlich kleinem Aufwand, da zu den B aken nix zu ist- die dürften preislich bei nem Zwanziger pro Stück landen- von der Stromversorgung vielleicht abgesehen.
Meine würd ich mit nem kleinen Akku versehen, die dann auf dem Roboter sogar wieder aufgeladen werden könnten-um die Baken möglichst klein halten zu können. Aber das ist schon ne "Erweiterung", die sicher nicht jeder braucht.
Sag mir, was daran _nicht_ gut sein soll...und _warum_ nicht.
Besserwessi
25.06.2014, 16:38
Das Beschriebene System klinge schon sehr plausibel und sollte funktionieren. Als ganz kleine Abweichung würde ich eher die grobe Richtung über die IR Sender am Bot bestimmen, als über die IR Empfänger. Das kommt einfach daher, das die Empfänger einen großen Winkel haben (z.B. +-50-70 Grad), bei den IR Sendedioden hat man dagegen eher schmale Winkel (3 Grad ... 40 Grad je nach Type), Auch sind die Sendedioden billiger (ca. 30 Cent) als mehr Empfänger ( ca. 1 EUR) . Beim Winkel kann man bei den Diode auch mischen: z.B. Schmale nach vorne, und eher breite nach hinten zur Seite. So kann man zumindest nach Vorne die Richtung auch relativ genau bestimmen, ohne das man sehr viele Dioden braucht. Wichtig ist halt das man den Bereich abdeckt, den man auch mit dem Ultraschall ansteuert. Da hat man gerichtet hat etwa +-15 Grad (also eher Schmal) oder halt mit Reflektor auch rundum.
Ein reiner Sender ist relativ einfach: halt Wechselspannung an den Sendetransducer. Für den Bot kann man aber auch ruhig ein komplettes Modul spendieren : Zumindest in der gerichteten Variante kann man den zusätzlichen Empfänger auch gut gebrauchen für den Bot.
Rabenauge
25.06.2014, 17:38
Das mit dem IR und der Ortung: dort fehlts mir einfach noch an praktischer Erfahrung.
Wenn du sagst, so rum ists besser- ok, glaub ich eben.
Ich ging davon aus, dass (dort kenne ich das Prinzip so bissel) die Battlesysteme in Modellpanzern (funktionieren auch mit Infrarot) eben die Richtung erkennen, aus der der Gegner "geschossen" hat. Die Dinger senden aber _nur_. Also ists der Empfänger, der die Richtung erkennt. Allerdings werten das nur wenige Systeme wirklich aus (die ganz einfachen werten die Richtung z.B. gar nicht), und allzu genau kommts auch nicht drauf an da- wenn die wissen "vorne, hinten, seitlich" reicht das. Bisschen genauer hätten wirs wohl schon gerne.
Problematisch aber stell ich es mir vor, die Sendedioden zu justieren: idealerweise sollten die Bereiche, die jede abdeckt, sich zum Teil mit den Nachbarbereichen überdecken (ergibt ne höhere Auflösung, oder?). Das muss dann ganz schön genau aufgebaut werden.
Genau diese Methode schlug ich vor. Gast du meinen Beitrag dazu überhaupt gelesen?
ja hab ich...
Ich sagte: die Baken müssen transportabel sein (möglich, dass das nicht jeder braucht, ich aber schon).
Damit sollten sie so wenig Strom wie möglich verbrauchen also
Definiere bitte mal "transportabel".. Unter 25 Kg oder was meinst du damit?
Ich sprach in meinem Vorschlag von EINER Bake mit der Logik drin und bis zu X mit Kabel angeschlossenen Satelliten die je ein US-Empfänger, ein IR-Sender (DIODE) und ein IR Empfänger enthalten.
Was ist daran nicht Transportabel? Sind wir immer noch bei der Begriffsklärung was eine Bake bzw. was ein Satellit ist? Ich verweise da noch mal auf meinen Beitrag, den Dirk netter Weise gerettet hatte!
-kommt in die Bake lediglich ein US-Empfänger
Und wie erfährt die Bake von dem IR-Blitz?
Vorteile: man braucht nur einen Sender und es gibt bei mehreren Baken keinen Ultraschall-Müll. Und das ohne viel Programmieraufwand
Da der RP6 das US-Signal wie auch das IR Signal aussendet und nur der jeweilige Satellit ein US-Signal und eine der Satelliten ein IR Impuls erkennen muss, gibts da keinen "Ultraschall-Müll" solange man nicht mit 130 Dezibel sendet... auch da verweise ich auf meinen Beitrag. Der aktive Messzeitraum liegt übrigens auch nur im Millisekundenbereich da sonst die Reichweite des US Signals signifikant überschritten wäre. Man kann sich das ganze US-Gebemsel sparen und mit einem Piezo-Hochtöner und ein paar Elektret-Micros das gleiche erreichen. Auch darüber hatte ich schon ausführlich geschrieben.
Dass die SR-04 als reine Empfänger nicht ohne weiteres taugen, hatten wir schon, aber ich sehe noch immer _nichts_ was gegen so ein Ding im Roboter spricht? Nen reiner Sender würde genügen aber: gibts den, für nen ähnlichen Preis??
Ist ja auch ein uC-gesteuerter Reflexsensor und keine passive US-Kapsel... wie kommt man eigentlich auf das schmale Brett, das ein Reflexsensor geeignet wäre fremde Impulse aufzuzeichnen wo deren Störsicherheit.. und nichts anderes als Störungen sind fremde Impulse ... extra ausgefiltert werden? Wer hat dir diesen Schwachsinn eigentlich erzählt? Hättest du mein Post gelesen, wüstest du das es Ultraschallfähige Hochtöner für 5 Euronen beim großen C gibt! Und ein SR08 wäre eine deutlich bessere Inwestition gewesen wenns um Hinderniserkennung geht. So viel zum Thema Billig und Preiswert.
Ich gehe sogar soweit, das Ding im Roboter _auch_ für andere Zwecke (Hinderniserkennung etc.) nebenher benutzen zu können/wollen.
-der Roboter braucht _keinen_ Rundum-Sensor für Ultraschall!
Da stimme ich dir mal zu.. es wäre schön, wenn man einen lokal montierten US-Reflexsensor am Bot in der Bake-Geschichte mitnutzen kann.... wie ich ebenfalls schon angedeutet hatte... das wird aber leider nicht zuverlässig gehen! Und zwar weil US-Kapseln eine extreme Focussierung haben... wie oft soll ich das noch schreiben? Das bedeutet logisch.. der Bot müsste sich erst auf ein US-Empfänger zu drehen damit der Empfänger den Impuls zuverlässig erkennt! Etwas unpraktisch oder nicht?
Er kann sich nämlich drehen-oder auch nur den Sensor drehen, das kann jeder bauen wie er will.
Siehe vorherigen Quote... das wäre ein Nachteil und kein Vorteil! Der Bot weis nämlich normal nicht wo die US-empfänger stehen.. also müsste er sie "suchen" und dazu bräuchte er ständig Rückmeldungen von der Bake... wärend er (irgend)einen Sateliten sucht soll er also mit der "Bake" reden und Feedbacksignale verarbeiten?
Du kommst um einen rundum sendenden US-Geber nicht rum und ich finde es gewagt, mal eben zu behaupten das man kein Rundumsender braucht .. ohne dir klar zu machen was der genaue Ablauf dahinter ist!
Die Bake braucht für Infrarot lediglich _einen_ Sender (ausreichend kräftig), und auch nur _einen_ Empfänger- sie muss nicht wissen, aus welcher Richtung der Roboter kommt. Dann nämlich muss sie auch entsprechend aufgestellt sein, sonst machts keinen Sinn.
Wie will ein Bot, der seinen Weg abfährt und dabei nicht auf die Bake ausgerichtet ist, denn erfahren wie seine Position ist? Willst du das IR-Licht um Ecken lenken? Ne also hier wird es dann echt abstruß!
Der Roboter verfügt über IR-Sender rundum, und über mehrere IR-Empfänger, die kreisförmig angeordnet sind.
Achso.. die IR-Units die du bei den Sateliten einsparst willst du nun an den Bot hängen? Siiinvoll..... super...
Vorgehen: Roboter sucht Bake, also sendet er rundum nen kräftigen Lichtblitz(der natürlich moduliert sein sollte). Die Bake(n) registriert das, und alle Baken, die den Blitz empfangen haben, antworten nun.
Da der Roboter aufgrund seiner IR-Empfänger die Richtung grob weiss (ich halte da ne Auflösung von etwa 30 Grad für ausreichend, also soo viele braucht man gar nicht), kann er sich _jetzt_ ne Bake aussuchen, und die gezielt ansprechen.
Es wird nun die Entfernung per US ermittelt und schon kann er die Bake ansteuern. Je näher er kommt, umso schmaler wird der Kegel, in dem er sie empfängt, womöglich reichen da sogar noch weniger IR-Empfänger.
Bei Bedarf kann er in der Zwischenzeit durchaus auch mit den anderen Baken kommunizieren.
Du hast da was ganz entscheidendes nicht kapiert! Nicht der Bot soll die Bake suchen, die Bake soll dem Bot sagen wo er ist!!! Jederzeit, egal wie er ausgerichtet ist und egal wie schnell er unterwegs ist. Der Bot ist das Gewitter ... und 3 Leute (Sateliten messen zählen den IR Blitz und "Knall" an...) um dann (in der Bake gerechnet) sagen zu können wo der Bot sich befindet. Da muss nix moduliert werden... Was verflucht ist daran so schwer zu verstehen? Wer hat das Gerücht in die Welt gesetzt, das ein Bot sich zur Positionsbestimmung oder Kommunikation erst irgendwo hin drehen muss? Gehts denn noch komplizierter?
Aber deswegen ist auch jede weitere Diskussion sinnlos hier...
Sag mir, was daran _nicht_ gut sein soll...und _warum_ nicht.
[/QUOTE]
Du hast schlicht und einfach nicht kapiert, was ein System erledigen muss, wenn es eine 2D-Ortung vornimmt. Ich empfehle auch dringend noch mal nachzulesen was "triangulieren" bzw. Trilateration (http://de.wikipedia.org/wiki/Entfernungsmessung#Triangulation) bedeutet!!!
Aber ist ok... ich wollte es nur nicht unbeantwortet lassen. Ich bin trotzdem raus.
Gruß
Rabenauge
25.06.2014, 20:01
Ok- das reicht. Offenbar mag hier _jemand_ meine Anmerkungen nicht- is ok.
Entweder _ich_ bin hier raus- und zwar ab sofort- oder Rolf!
Ganz so nötig hab ichs dann auch wieder nicht....sorry für die anderen.
Besserwessi
25.06.2014, 21:59
Der Ultraschall per Lautsprecher / Mikrofon im etwa 25 kHz Bereich selber aufzubauen, ist schon anspruchsvoll auf der Empfängerseite und die Senderseite auch relativ groß und leistungshungrig. Da es wohl auch mit dem US Kapseln und Reflektor geht sehe ich dafür keinen wirkliche Grund. Die US Kapseln sind halt günstig, klein, sparsam und haben schon die erste Filterung mit drin. Den Weg über Mikrofon würde ich erst gehen falls es wider erwarten mit den US Kapseln nicht funktioniert die Position genau genug (Fehler um ganze Perioden) zu bestimmen.
Der Weg mit dem gerichteten US Sender ist wegen der nötigen Drehung nicht Jedermanns Sache - den Einwand kann ich verstehen. Ich sehe da aber auch kein echtes Hindernis, sondern halt ein etwas umständliche Handhabung. Mit einem extra Servo für das Drehen bliebe der Nachteil bei der Handhabung in Grenzen. Langsamer bliebe der Teil aber immer noch. Der Hardware-Aufwand für das finden der Richtung ist klein: im Minimalfall einfach nur 1 zusätzliche IR LED am Bot mit relativ kleinem Öffnungswinkel. Der Nachteil bei der Richtungssuche ist vor allem das es Zeit kostet. Wenn es mit Rundum Ultraschall von der Intensität nicht ausreicht, hätte man die gerichtete Version noch als Backup, bzw. dann für große Entfernungen. An den Baken selber würde sich ja nichts ändern.
Irgendwie gehen auch die Ziele der bake hier etwas auseinander: Mit dem Ungerichteten Ultraschall und IR bekommt man mit 3 (ggf. auch 2) Baken eine Postionsbestimmung, aber noch keine Richtung - die Richtung gibt es erst nach Bewegung des Bots - das ist wohl so etwa RolfDs Ziel.
Das andere Ziel, etwa ganz vom Anfang war vor allem die Richtungsbestimmung und nur sekundär auch den Abstand - im Einfachen Fall einfach um den Weg nach Hause zu finden. Das sind verschiedene Wege. Um die Richtung ohne Vorwärtsbewegung zu gekommen geht es halt per "gerichtetem" IR Signal - wobei das wegen der Fehlenden Amplitudeninformation von den fertigen IR Empfängern auch nicht so einfach ist. Für eine grobe Richtung (z.B. +-5 Grad) sollte es aber gehen. Mit der groben Richtungsinformation könnte man dann auch den US gerichtet haben.
Es gibt halt verschiedene Möglichkeiten je nach gewünschter Anwendung. Möglich wäre etwa:
1) reine IR Baken, und IR Teil auf dem Bot zum drehen. Damit könnte man die Richtung und über Triangulation (Winkel vom Bot zu den Baken) auch in Grenzen die Position bekommen. Hierbei wird man um eine unabhängige Drehung der Sensoren kaum herum kommen. Je nach Aufbau wären etwa 10 Sekunden für eine volle Triangulation realistisch. Nur eine Richtung zu halten ginge schneller. Wegen der IR Streuung ist das System aber nicht so trivial wie es aussieht - vor allen weil die TSOP keine Amplitudeninformation liefern.
2) IR/US Baken, ungerichtet (egal ob 22 kHz oder 40 KHz): hier bekommt man relative schnell (z.B. 1 Sekunde) eine Postionsbestimmung über die Abstände, und über die Bewegung dann die Orientierung. Hier wurde vor allem das Senden vom Bot und Empfangen an den Baken Diskutiert. Die Berechnung der Postion könnte man auf den Baken (eine MasterBake) oder dem Bot machen - beides hat Vor/Nachteile.
3) Ähnlich wie 2), nur das von den Baken zum Bot gesendet wird. Diese Richtung hätte Vorteile wenn mehr als 1 Bot unterwegs ist. Allerdings ist es so langsamer weil der langsame US nacheinander senden muss, vor allem bei vielen Baken. Ein Vorteil dabei wäre ggf. das man nur einen US Empfänger braucht, und da dann ggf. auch mehr Aufwand für eine hohe Genauigkeit treiben könnte. Auch könnte man ggf. mit weniger IR Sendern/Empfängern auskommen - IR vom Bot zu den Baken kann man sich ggf. ganz sparen.
4) Der Bot hat eine grobe Richtungserkennung per IR und einen ggf. gerichteten Ultraschall für die Abstandsmessung. Durch die Drehung des US wäre das Systems aber wohl relativ langsam, vor allem wenn der Ganze Bot gedreht werden muss. Sofern man nur den Weg auf ein Bake halten will hält sich der Aufwand auch in Grenzen. Dafür hat man halt auch ohne Bewegung eine Richtungsinformation, und man kommt auch ggf. mit weniger Baken aus, weil man.
Bei den Baken ist noch möglich das die alle unabhängig sind, oder ggf. per Kabel verbunden sind. Dabei muss man auch nicht an jeder Position einen µC haben. Verbunden könnte man ggf. IR Sender / Empfänger einsparen. Ich wäre für ein gemischtes System - also vorsehen, dass ein µC mehr als eine Position versorgen kann, aber auch so, dass die Baken nicht alle per Kabel verbunden sein müssen.
Mein persönlicher Favorit wäre die Version 2 , ggf. auch 3. Eine grobe Richtungsmessung über die IR Diode am Bot könnte man ggf. zusätzlich machen - der Aufwand wäre eher gering.
Rabenauge
26.06.2014, 10:59
Ich will ggf. (darauf liegt eigentlich sogar der Schwerpunkt) mit _einer_ einzigen Bake auskommen können.
Aber so, dass mans erweitern kann (wie ich schon sagte, mal eben ne Handvoll Baken als "Weidezaun" benutzen können.
Letzteres ist mehr oder weniger das, worum es euch geht.
Ersteres ist mit ner reinen IR-Bake praktisch kaum machbar: sie muss dann ja ringsrum senden können, und der Roboter kann _nicht_ wirklich die Entfernung feststellen. Sowas klappt z.B. als Ladestation (wenn er drauf ist kann er das ja anders detektieren), mir aber würd er dann regelmässig in die Haxen fahren.
Also _brauchts_ ne vernünftige Entfernungsmessung einfach (nebenbei bietet die bei mehreren Baken weitere mögliche Szenarien, beispielsweise eine im Bot abgelegte Umgebungskarte, mittels der er jederzeit seinen Standort finden kann usw.)
Damit ist Version 1 raus.
2. dürft genau das sein, was ich die ganze Zeit rede. Warum nöchte ich die Baken nicht per US senden lassen?
Weils mehr Strom braucht. Sicher: die Masse ists auch nicht, aber ich will versuchen, den grossen Bot später auf möglichst lange Betriebstzeiten auszulegen, blöd, wenn dann die Baken vorher schlapp machen- Netzteil für die Baken ist für mich _keine_ Option.
Letzten Endes aber würd auch _das_ (das US-Senden) gehen. Macht aber eventuell die Bake wiederum grösser, und die muss dann auch US ringsum senden können.
Ich möchte zumindest eine so klein wie möglich haben, eben, um sie mir wie nen Stift (zugegeben, soo klein wirds auch nicht, aber für viel mehr seh ich auch keine Notwendigkeit) an den Gürtel hängen zu können.
für 3. sehe ich keinerlei Vorteile: auch dann nicht, wenn es mehrere Roboter gibt. Die Entfernungsmessung muss sowieso individuell ausgelöst werden: Bot ruft Baken, sucht sich eine aus und fragt dann: wie weit isses zu dir? Das geht auch mit mehreren, wenn ein und dieselbe Bake von mehreren Robotern angesprochen wird, kann sie immer noch die nächsten warten lassen.
Schlecht wärs hier, wenn mehrere Baken zeitgleich antworten (weil mehrere von verschiedenen Robotern angesprochen werden zur selben Zeit), dann müsste die US-Schiene auch noch moduliert werden, um auch dort die Baken unterscheiden zu können-> unnötig.
Ja zugegeben: die Drehung des Bots (oder auch eines Sensors) ist etwas langsam. Andererseits sparts einiges an technischem Aufwand. Es ist ja nicht damit getan, ein ganzes Array an "Antennen" (sei es IR oder US) zu montieren, es muss ja auch noch angeschlossen&programmiert werden.
Und: ihr redet vom RP6- so kompliziert isses auch nicht, den mal eben auf dem Punkt zu drehen oder?
Ich würde betreffs Ultraschall halt einfach die Möglichkeit offen lassen, da nen ganzen Ring von zu installieren, aber eben ggf. mit einem -drehbar- auskommen wollen.
Wenn man die, auch schon vorgeschlagene Möglichkeit, den Schall mittels kegelförmigem Reflektor noch dazu nimmt, brauchts das gar nicht mehr, da man per US gar keine Richtungsangabe benötigt!
Das drehen (schwenken, wie auch immer) ist ja nur nötig, wenn die Baken US-passiv sind. Dann (und nur dann) muss der Roboter halt in Richtung der Bake quäken.Ich selber find die Lösung mit dem Schall-Kegelreflektor nicht so gut: ich schätze, das wird mechanisch etwas empfindlich, aber für drinnen, warum nicht.
Was man meiner Meinung nach nicht braucht ist eine allzu präzise Richtungsortung denn: das Ganze geht immer kegelförmig (je weiter weg, umso breiter der Empfangsbereich). Schon bei 90Grad Öffnungswinkel _kann_ ich die Bake sehr genau finden, weil auf kurze Entfernung da nur noch nen paar Zentimeter übrig bleiben.
Zudem lassen sich, wie ich schon sagte, die einzelnen Erfassungsbereiche noch überlappen, und ich hab die doppelte Auflösung (spricht der linke an, der rechte, oder beide).
Das funktioniert, ich mach das grade (noch testweise, aber die Tage ernsthaft) bei einer anderen Geschichte. Klappt gut, wie es aussieht.
Thorben W
26.06.2014, 11:39
@Rabenauge wenn ich dich richtig verstanden habe, dann hattest du die Idee von einzelnen Baken, die einen eigenen µC haben und jede einzelne dem Roboter auf Anfrage mitteilen welchen Abstand der Roboter zu ihnen hat.
Die anderen, wenn ich es richtig verstanden habe, wollten eine Bake mit Satelliten, die Bake überträgt die Entfernungen des Roboters zu allen Satelliten an den Roboter. Der Roboter hätte in diesem Fall einen Rund um sender für US und für IR (wie gelöst ist im Moment ein anderes Problem), die Bake hat eine Auswertelektronik (µC) und Bake und Satelliten haben jeweils US und IR Empfänger.
Der Roboter sendet IR und US ab und die Satelliten nehmen es auf und die Bake errechnet die Entfernungen und Überträgt sie zum Roboter (Komunikationssystem: Verschiedene Ideen)
Grüße
Thorben
Rabenauge
26.06.2014, 15:13
Unflexibel.
Wenn nämlich die "intelligente" Bake ausfällt, bricht das gesamte System zusammen. Sie muss ja noch nicht mal ausfallen, es reicht, wenn es Kommunikationsprobleme gibt.
Ich halts für besser (und der Aufwand ist nicht viel mehr, um miteinander kommunizieren zu können braucht eh jede Bake nen Rechenknecht), wenn jede Bake alles kann. Dann kann man die ausgefallene nämlich einfach austauschen, bzw. ungerührt weiter machen, so lange noch "genug" Baken online sind.
Zudem: wie soll die Bake die Entfernung des Roboters zu den Satelliten wissen?
Dazu müssen die auch gegenseitig Daten austauschen- vom Aufwand her find ich das nicht geringer. Aber anfälliger, weil dann sämtliche Satelliten auch noch mit der Bake reden müssen. Da ist einfach irgendwann zu viel "IR-Müll" im Raum.
Das ist in Griff zu bekommen, aber umständlich:
-Roboter weckt alle Satelliten auf (mit nem IR-Blitz und gleichzeitig nem US-Rundruf
-jeder Satellit misst nun die Entfernung, und muss die an die Bake weiter geben
-jetzt kann die Bake alles an den Roboter schicken.
Das ist nicht mal schnell, denn die Bake muss warten, bis sie von allen Satelliten die Werte bekommen hat.
Weiter muss es gut getimed werden, damit die Satelliten nicht gleichzeitig mit der Bake reden.
Ich hab da also entweder irrsinnige Verzögerungen drin (es kann vorkommen, dass die Bake nen Satellit nicht richtig versteht, und die Werte neu anfordert, aber auch, dass mal ein Satellit ganz ausfällt, das kann ich _nur_ mit ner gewissen Wartezeit rausfinden), oder aber ich muss vor jedem Start des Systems sicher stellen, dass die Bake sämtliche, im Einsatz befindlichen Satelliten kennt und auch mit ihnen einwandfrei kommunizieren kann.
Nen paar der Probleme kann man umgehen, indem man die Bake und die Satelliten miteinander per Kabel verbindet (ne Art Bussystem) aber dann wird das Ganze dermassen unflexibel...richtig schick geht das dann wohl nur noch mit nem Funknetzwerk-Blauzahn oder so.
Bei der von mir bevorzugten Lösung kann man von einer bis-beliebig viele Baken benutzen. Der einzige Unterschied zwischen ihnen ist ne eigene Adresse.
Nach dem "Rundruf" vom Roboter melden sich einfach alle, die es mitbekommen und schon weiss der Roboter, wer alles da ist bzw. im Bereich.
Dort kann man noch ne Differenzierung einbauen: Bake Addr.1 antwortet 10ms nach dem "Weckruf", Bake Addr.2 20ms danach usw. Auch das kann man in die Baken fix gleich mit einprogrammieren, so braucht der Roboter auch das nicht mehr managen.
Fällt _hier_ irgendeine Bake aus, ist das nicht soo tragisch: solange noch _irgendeine_ mitspielt, kann der Roboter zumindest diese noch lokalisieren.
Und: man kann klein anfangen-wenn das Budget eben grade nicht die eigentlich nötigen 15 Baken hergibt, kann man mit zweien schon sehr viel anfangen, und später nach und nach einfach neue hinzufügen, _ohne_ am System selber irgendwas zu ändern.
Bauch ich mal nur vier, stell ich eben nur die viere auf und gut. Ich muss dann nicht eine Zeile Code ändern.
Besserwessi
26.06.2014, 21:08
Das Senden von US Pulsen sollte vergleichsweise wenig Leistung benötigen, deutlich weniger als Sende von IR-Signalen. Anders wäre das nur wenn man einen Lautsprecher nutzen will. Der Fall 3) mit dem Senden von den Baken an den Bot (die Bots) wäre dann eher so, das ein Senden Angefordert wird, und dann alle Baken der Reihe nach Senden, das ganze ggf. 2 oder 3 mal wiederholt. Das Signal könnten dann alle Bots parallel aufnehmen. Der Vorteil wäre dabei, dass der Bot bereits die Zeiten misst und das Ergebnis nicht noch erst übertragen werden muss. Die IR Übertragung beschränkt sich dann auf die Zeitmarken zu den US Pulsen.
Beim Fall 2. (US vom Bot zu den Baken) muss man die Baken auch nicht unbedingt einzeln adressieren. Die Baken können den US Puls Unabhängig empfangen, nur beim Senden des Ergebnisses muss man ggf. durch Verzögerungen darauf achten das nicht 2 Baken gleichzeitig das Ergebnis senden. Dabei wäre ich eher dafür nur die Zeiten zu senden - die Berechnung der Position kann man dann auf dem Bot machen - damit wird man dann vor allem unabhängig davon wie viele Baken Antworten, und die Baken müssen nicht noch die Werte zusammenfügen. Das einzige ist das der Bot noch die Position der Baken braucht, aber die sollte nicht nicht so oft ändern. Bei den Baken wird es vermutlich darauf hinauslaufen das man je Position einen eigenen µC hat. Mit einem µC mehr als Postionen zu versorgen wäre ggf. interessant um Strom zu sparen (nicht so sehr um µCs zu sparen), denn man muss dann nicht an jeder US Empfangsposition auch IR Sender / Empfänger in alle Richtungen haben. Die Kabelverbindung ist dann mehr etwas um IR Kommunikation (insbesondere Strom) zu sparen. Für den Anfang würde ich aber pro Postion von 1 µC, 1 US Empfänger, ca. 2-4 IR Empfängern und etwa 3-8 IR Dioden ausgehen. Der nächste Schritt wäre dann ggf. ein 2. US Empfänger am selben µC und ohne zusätzliche IR Komponenten. Wie viele IR Sender bzw. Empfänger man nutzt ist ohnehin ggf. variabel, je nach Aufstellungsort der Bake (in der Raummittel viele, in einer Ecke eher weniger) - das wäre eine Sache die man ggf. per Jumper oder Software einstellen sollte, auch wenn ein IR Sender gegen die Wand nur mehr Stromverbrauch bedeutet aber noch nicht stört.
So hoch sollte der Stromverbrauch der Baken nicht sein. So grob geschätzt etwa 2-3 mA für 2-3 IR Empfänger um den nötigen Raumwinkel abzudecken, vielleicht 1-2 mA für den den µC und anderes im Ruhezustand. Für eine Messung kommt man dann vielleicht noch mal auf 50 ms mit 10 mA für den US Empfänger und vielleicht 20 ms mit 500 mA für den IR Sender. Bei einer Messung jede Sekunde wäre das auch nur noch einmal rund 10 mA im Mittel. In der Summe wären das weniger als 20 mA - damit könnte man mit 4 AA Akkus oder Batterien noch einige Tage auskommen, bzw. man hätte einiges an Reserve etwa für mehr IR Sendeleistung oder ggf. 2 oder mehr Baken aus einem Satz Akkus. Wenn man sich Anstrengt könnte man ggf. auch da noch sparen, etwa indem nur dahin gesendet wird wo auch empfangen wurde und ggf. je nach Abstand auch weniger stark gesendet wird - den Abstand zum Bot kennt die Bake ja.
Ob der Bot gerichtet sendet, oder in alle Richtungen ist dabei egal - das kann jeder halten wie er will, ggf. sogar gemischt mit 1 Bot der Rundum sendet und einer gerichtet. Gerichtet muss man dann ggf. damit Leben das einige Baken das Signal nur über ein paar Ecken empfangen - da braucht man dann ggf. eine nicht ganz triviale Fehlererkennung, denn auch das IR Signal kann man ggf. indirekt per Streuung empfangen. Für die billigen US Module könnte sich das Problem ergeben, dass man gerichtet ein sehr hohe Leistung hat, und so auch noch die 2. oder 3. Refelxion mitbekommt.
Rabenauge
26.06.2014, 22:13
Du willst-optional-also die Baken(mehrere ggf.) noch mit zusätzlichen Satteliten erweitern können?
Hm, da geh ich mal mit (ich denke nicht, das _ichs brauche, aber ich kanns ja einfach weglassen)- das macht Sinn, um ein dichteres Netz zu haben, falls nötig.
Die Satelliten kann man dann wirklich per Kabel einfach anstecken, oder eben nicht.
Das jede vernünftige Bake nen Rechenknecht benötigt, ist eh klar- muss ja nun nix tolles sein.
Kann man denn mit vier IR-Empfängern ringsherum empfangen? Klappt das wirklich?
Ich hab _einen_ hier- daher kann ichs nicht wirklich testen.
ja hab ich...
Definiere bitte mal "transportabel".. Unter 25 Kg oder was meinst du damit?
Ich sprach in meinem Vorschlag von EINER Bake mit der Logik drin und bis zu X mit Kabel angeschlossenen Satelliten die je ein US-Empfänger, ein IR-Sender (DIODE) und ein IR Empfänger enthalten.
Was ist daran nicht Transportabel? Sind wir immer noch bei der Begriffsklärung was eine Bake bzw. was ein Satellit ist? Ich verweise da noch mal auf meinen Beitrag, den Dirk netter Weise gerettet hatte!
Und wie erfährt die Bake von dem IR-Blitz?
Da der RP6 das US-Signal wie auch das IR Signal aussendet und nur der jeweilige Satellit ein US-Signal und eine der Satelliten ein IR Impuls erkennen muss, gibts da keinen "Ultraschall-Müll" solange man nicht mit 130 Dezibel sendet... auch da verweise ich auf meinen Beitrag. Der aktive Messzeitraum liegt übrigens auch nur im Millisekundenbereich da sonst die Reichweite des US Signals signifikant überschritten wäre. Man kann sich das ganze US-Gebemsel sparen und mit einem Piezo-Hochtöner und ein paar Elektret-Micros das gleiche erreichen. Auch darüber hatte ich schon ausführlich geschrieben.
Ist ja auch ein uC-gesteuerter Reflexsensor und keine passive US-Kapsel... wie kommt man eigentlich auf das schmale Brett, das ein Reflexsensor geeignet wäre fremde Impulse aufzuzeichnen wo deren Störsicherheit.. und nichts anderes als Störungen sind fremde Impulse ... extra ausgefiltert werden? Wer hat dir diesen Schwachsinn eigentlich erzählt? Hättest du mein Post gelesen, wüstest du das es Ultraschallfähige Hochtöner für 5 Euronen beim großen C gibt! Und ein SR08 wäre eine deutlich bessere Inwestition gewesen wenns um Hinderniserkennung geht. So viel zum Thema Billig und Preiswert.
Da stimme ich dir mal zu.. es wäre schön, wenn man einen lokal montierten US-Reflexsensor am Bot in der Bake-Geschichte mitnutzen kann.... wie ich ebenfalls schon angedeutet hatte... das wird aber leider nicht zuverlässig gehen! Und zwar weil US-Kapseln eine extreme Focussierung haben... wie oft soll ich das noch schreiben? Das bedeutet logisch.. der Bot müsste sich erst auf ein US-Empfänger zu drehen damit der Empfänger den Impuls zuverlässig erkennt! Etwas unpraktisch oder nicht?
Siehe vorherigen Quote... das wäre ein Nachteil und kein Vorteil! Der Bot weis nämlich normal nicht wo die US-empfänger stehen.. also müsste er sie "suchen" und dazu bräuchte er ständig Rückmeldungen von der Bake... wärend er (irgend)einen Sateliten sucht soll er also mit der "Bake" reden und Feedbacksignale verarbeiten?
Du kommst um einen rundum sendenden US-Geber nicht rum und ich finde es gewagt, mal eben zu behaupten das man kein Rundumsender braucht .. ohne dir klar zu machen was der genaue Ablauf dahinter ist!
Wie will ein Bot, der seinen Weg abfährt und dabei nicht auf die Bake ausgerichtet ist, denn erfahren wie seine Position ist? Willst du das IR-Licht um Ecken lenken? Ne also hier wird es dann echt abstruß!
Achso.. die IR-Units die du bei den Sateliten einsparst willst du nun an den Bot hängen? Siiinvoll..... super...
Du hast da was ganz entscheidendes nicht kapiert! Nicht der Bot soll die Bake suchen, die Bake soll dem Bot sagen wo er ist!!! Jederzeit, egal wie er ausgerichtet ist und egal wie schnell er unterwegs ist. Der Bot ist das Gewitter ... und 3 Leute (Sateliten messen zählen den IR Blitz und "Knall" an...) um dann (in der Bake gerechnet) sagen zu können wo der Bot sich befindet. Da muss nix moduliert werden... Was verflucht ist daran so schwer zu verstehen? Wer hat das Gerücht in die Welt gesetzt, das ein Bot sich zur Positionsbestimmung oder Kommunikation erst irgendwo hin drehen muss? Gehts denn noch komplizierter?
Aber deswegen ist auch jede weitere Diskussion sinnlos hier...
Du hast schlicht und einfach nicht kapiert, was ein System erledigen muss, wenn es eine 2D-Ortung vornimmt. Ich empfehle auch dringend noch mal nachzulesen was "triangulieren" bzw. Trilateration (http://de.wikipedia.org/wiki/Entfernungsmessung#Triangulation) bedeutet!!!
Aber ist ok... ich wollte es nur nicht unbeantwortet lassen. Ich bin trotzdem raus.
Gruß[/QUOTE]
Also Leuts kommt mal etwas runter ... es geht um Hobby
Natürlich ist das ein Hobby. Darf man dann keine Auseinandersetzung führen? Interessanter Gedanke...
Es hat sich in diversen Posts gezeigt, das Rabenauges und meine Ansichten, wie man einem Bot eine 2D Orientierung bei bringt, nicht zusammen zu bringen sind.
Da ist soweit nichts verwerfliches dran und ich ziehe daraus die Konsequenz und ziehe mich aus der weiteren Entwicklung zurück da meines Erachtens die von Rabenauge angestrebte Lösung nicht zur gestellten Aufgabe passt. So... das heisst nicht, das ich mich jetzt aus dem Forum zurück ziehe.. und auch nicht das es nur einen im Thread geben kann wie Rabenauge fordert:
Entweder _ich_ bin hier raus- und zwar ab sofort- oder Rolf!
Ich lass mir auch nicht unterstellen, das ich was gegen Rabenauge hätte. Wir haben uns zusammen getan (siehe Thread) um sachlich eine Lösung zu erarbeiten. Nur weil ich Rabenauges Argumentation für falsch halte und dies inzwischen mehrfach und in verschienden Posts begründet habe, ist die gequotete Forderung nun legitim und ich werde aufgefordert runter zu kommen ? Gehts noch?
Ich hätte mir eine Antwort auf mein Post gewünscht in der auf die Punkte eingegangen wird... aber nicht bekommen. Ok. Stattdessen stellt Rabenauge Forderungen die ich schon längst als Konsequenz in Post 204 gezogen habe. Siehe Quote. Den Mund verbieten lasse ich mir jedoch nicht!
Ich habe es schon mal in einem anderen Tread und zu einer anderen Person gesagt: Ich trete hier nicht an um gegen die Dickköpfigkeit ander Leute zu kämpfen.
Lasst mich doch bitte einfach raus... auch mit Zitaten... und alles wird gut! Ok? Danke.
Gruß
Besserwessi
27.06.2014, 14:01
Mit nur einer Bake bekommt man nur eine eher eingeschränkte Position: Den Abstand, ggf. eher grob den Winkel von der Bake zum Bot und ggf. die grobe Orinentierung des Bots.
Mit nur einer Bake sollte man mehr Wert auf Bestimmung der Orientierung legen - der zusätzliche Aufwand (ggf. eine extra IR LED mit geringem Winkel, und etwas Software und halt das drehen des Bots) hält sich auch sehr in Grenzen, wenn man keine so hohen Anforderungen hat. Man es durchaus mit der Ultraschall Positionsbestimmung kombinieren.
Die Berechnung der Position würde ich nicht auf den Baken machen, sondern am Bot. So müssen die Baken nicht alle vernetzt sein. Bei der Berechnung auf einer Master-Bake bräuchte man eine Verbindung von den Baken zum Master und nur vom Master zum Bot. Wenn der Bot dann nicht mehr in Reichweite der Zentrale ist, braucht man dann aber doch wieder IR Sender an den meisten Baken.
Nach den Datenblättern haben die IR Empfänger schon einen recht breiten Empfangsbereich von etwa +-45 Grad, also 90 Grad im ganzen. Mit 4 der Detektoren hätte man dann 360 Grad abgedeckt - allerdings schon mit reduzierter (etwa 50%) Empfindlichkeit an den Grenzen. Für mehr Reichweite wären 5 oder 6 Empfänger besser. Bei einer Bake am Rand wird man den ganzen Winkel nicht brauchen und sollte mit 2 (ggf. 3) Empfängern auskommen.
Eine Bake sollte einen µC (etwa Arduino mit AVR) haben, wohl 2 - 4 IR Empfänger (TSOP..36), zum Senden etwa 5-10 IR Dioden und einen US Empfänger. Optional könnte man davon dann ggf. noch einen Satelliten betreiben mit nur einem US Empfänger. In der einfachen Version könnte man die IR Empfänger wohl direkt zusammenschalten (wired OR). Wenn man die Empfänger getrennt hat, könnt man je nach Empfänger für das Startsignal auch nur die entsprechenden IR Sender aktivieren. Es könnte auch von Vorteil sein nur dem Empfänger auszuwählen, der ein gutes Signal Empfängt - von daher würde ich schon getrennte Eingänge vorsehen. Bei den IR Sende-Dioden muss man nicht unbedingt alle einzeln Senden können, es kann aber helfen - vor allem bei nur einer Bake. Ich wäre da eher für ein paar mehr Dioden mit kleinem Winkel (z.B. LD274) da kommt man mit weniger Strom aus, weil weniger Licht nach oben und unten verloren geht.
Damit es mit der Richtung klappt sollte man wohl 2 Funktionen der Baken vorsehen:
1) Auf ein IR Signal Aufwachen, und einen US Puls Empfangen und dann die Zeit zurück senden. Mit Sattelit hätte man dann 2 Zeiten. Das IR Signal für den Start wird wohl erst aus einem Muster für die Funktion und dann ein Paar (z.B. 4) Pulsen für die Synchronisation bestehen.
2) Auf ein anderes IR Signal mit einem IR Signal antworten für die Richtungserkennung. Dabei könnte man ggf. auch nacheinander die IR Dioden für die Rückrichtung nutzen, so dass der Bot auch grob weiss in welchem Sektor der Bake er ist. Um Ärger mit Streulicht zu vermeiden müsste man da ggf. vorsehen die Intensität zu variieren: entsprechend muss man auch den Fall schwacher und damit fehlerhafter Signal berücksichtigen.
radbruch
27.06.2014, 17:58
Hallo
Da ich zur Zeit sehr "ausgebremst" bin kann ich euch leider nicht liefern, was ich im Moment am meisten vermisse: Die Grundlagenforschung!
Wie sind denn nun die Abstrahl- und Empfangswinkel der IR- oder US-Verbindungen? Wie sind die Reichweiten, die Echos, die Reaktionszeiten, die Reproduzierbarkeiten, die Stromaufnahmen oder die Störempfindlichkeiten beim Außeneinsatz der vorgeschlagenen Ansätze? Und wie sollen dann die Bakenstandorte geteacht und die Fahrbereiche kartographiert werden?
Die Laufzeitmessung eines US-Impulses zur Abstandsbestimmung zur Bake halte ich auch für einen guten Ansatz, die Auslösung über ein IR-Signal allerdings nur für bedingt tauglich. Eine kostengünstige (=billige) Funklösung scheint mir besser geeignet. Mehrere autarke Baken, optionsweise solar versorgt, halte ich auch für dringen nötig. Aber ich möchte euch nichts aufzwingen...
Da ich ja selbst begeisterer Fan von KISS (http://de.wikipedia.org/wiki/KISS-Prinzip)-Umsetzungen bin wundere ich mich sehr über eure langatmigen Diskussionen (, die jetzt schon wieder zu eskalieren scheinen). Fangt doch einfach mal an, delegiert die Teilaspekte, zeigt eure Resultate und entscheidet dann, wie die entgültige Lösung aussehen wird. Meiner Meinung auch ist es auch das was KISS meint.
Da ich nach Jahren der Beschäftigung mit "Kleinroboter" nun auch in die Welt der echten Roboter vordringen möchte, benötige ich vermutlich auch einmal ein gutes und flexibles Bakensystem, dass unter anderem für Mäh-, Saug-, Schneeräum-, Bierbring- oder Serviceroboter geeignet wäre. Was immer eben eine Orientierung im Raum benötigt.
Gruß
mic
Rabenauge
27.06.2014, 19:25
@Besserweissi: ich stimme dir zu 98% zu:
Sechs Empfänger decken den Vollkreis etwas überlappend ab- ich denke, das reicht. Mit etwas Glück genügt das, um 12 Bereiche zu haben, das macht nen 30Grad-Winkel. Wenn nicht, gehts auch- die meisten hier werden mehrere Baken benutzen wollen, und damit sollt das klappen. Da das eh Kreisvektoren sind, hilft näher ranfahren.
Zu den übrigen 2%: meinst du wirklich, man braucht so viele IR-Sender für sagen wir, 10-15m im Freien?
Die Modellpanzer schaffen das mit _einer_...toll wärs natürlich, wenn man auf diese Weise 20m oder gar mehr schaffen würde, aber da fehlt mir die praktische Erfahrung. Wichtig wäre: IR muss weiter reichen aus US, so hat man noch nen Notprogramm: wenn US nicht ankommt, kann man immer noch näher zur Bake.
@radbruch: Funk _wäre_ Klasse aber in nem Funksignal hast du keinerlei Richtungsinformation. Das heisst, um den Standort _der_ Bake zu bestimmen, brauchst du ne Funkpeilung-glaub nicht, dass die weniger aufwendig wäre als IR..
Bei IR kann man einfach sehr simpel die grobe Richtung detektieren, und wenn es da nicht für US-Empfang reicht, kann man immerhin näher zur Bake tuckern.
Die Nobellösung wäre natürlich: GPS in der Bake _und_ ne anständige Funkbrücke-aber von sowas träum ich erstmal nur....;)
, benötige ich vermutlich auch einmal ein gutes und flexibles Bakensystem, dass unter anderem für Mäh-, Saug-, Schneeräum-, Bierbring- oder Serviceroboter geeignet wäre. Was immer eben eine Orientierung im Raum benötigt.
...hatte ich bereits im Post #133
https://www.roboternetz.de/community/threads/63467-IR-bake/page14?p=600199&viewfull=1#post600199 verlinkt.
Das Verfahren ist meiner Meinung nach genial dafür geeignet. Es kann universell ausgelegt werden. Zum Beispiel wäre ein einfacher IR-Empfänger auf einem sich drehenden Turm (Winkelmesser) auf dem Roboter ausreichend. Die Güte der Winkelerfassung bestimmt die Auflösung und ist das einzig schwierige daran.
Die Baken (min. 3 nötig für ein "Spielfeld" / können aber auch beliebig viele sein für mehrere "Spielfelder") sind IR-Sender und senden nur ihre Adresse. Der Empfänger (Roboter) wertet die Winkel aus und hat unmittelbar nach einer Turmdrehung seine Position und seinen Winkel im Raum !
Das vorgestellte System arbeitet dagegen mit passiven Baken (nur Reflektor).
Wenn das aber unbedingt mit IR und US realisiert werden soll bin schon wieder still.....................;)
Besserwessi
27.06.2014, 20:51
6 Empfänger für 12 Bereiche halte ich auch für realistisch. Etwas tückisch ist dabei, dass der Überlapp von der Intensität und Entfernung abhängt. Eine feinere Winkelauflösung sollte man aber über die Sendedioden bekommen - kostet zwar etwas Zeit, aber auch nicht so viel. Mit nur je wenigen aktiven LEDs ist auch der Einfluss von Streulicht geringer.
Wie viele der IR Dioden man braucht, hängt von den Dioden ab. Im Prinzip sind enger gebündelte Dioden sparsamer, weil weniger Licht verloren geht. Pollin hat z.B. billige (10 Cent) IR-Dioden, die +-10 grad Öffnung haben - davon bräuchte man schon etwa 15-20 Stück für einen vollen Kreis. Man muss die nicht alle einzeln ansteuern, und würde wohl auch mit vergleichsweise wenig Strom (z.B. 100 mA je Diode) auskommen. Es gibt auch IR LEDs für +-40 grad - da würden 5 für den vollen Kreis reichen - allerdings wird man da für jede Diode etwa den 16 fachen Strom brauchen, bzw. hätte bei gleichem Strom nur etwa 1/4 der Reichweite. Für ein kleines Zimmer wäre das wohl noch OK. Die vielen Dioden sind nicht nötig damit sich die Leistung addiert, sondern damit der Winkel auf den wesentlichen Teil (im wesentlichen Horizontal) begrenzt bleibt.
10-15 m Reichweite sind schon eine ganz schöne Hausnummer : die TSOP..38 Empfänger brauchen etwa 0,5 mW/m² - um die Leistung auf 10 m Entfernung zu bringen braucht es 50 mW/Sr. Die Leistung bekommt man mit einer auf +-10 Grad gebündelten LED (z.B. LD274) gut hin, aber schon mit der LD271 (+-25 Grad) wird man das kaum mehr erreichen. In wie weit das gestreute Licht ggf. auch noch ankommt, ist dabei nicht berücksichtigt, aber je nach Umgebung wird das nicht unbedingt viel sein (Gras sollte IR Licht gut absorbieren, und der Himmel ist weit).
Für eine große Reichweite ist der Pulsstrom schon nicht so ohne: 15 LEDs mit je 100-200 mA sind auch schon 1,5 - 3 A. Das ist zwar nur mit etwa 25% Tastverhältnis (über 1ms Zeit) bzw. 10-12,5% über die Zeit für ein Datenpaket - aber trotzdem ist das einiges an Leistung. Da sind weniger LEDs nicht so der Vorteil, wenn man dann größere Akkus und Treiber braucht. Auf wirklich rundum senden kann man ggf. auch verzichten und so den Strom noch reduzieren - es kostet dann halt ggf. etwas mehr Zeit.
Man muss also eher davon ausgehen das der Ultraschall weiter reicht als die IR Signale. Zumindest mit einer Seite gerichtet sollten da auch über 20 m kein Problem sein.
Zumindest wenn man draußen die über 10m Reichweite haben will, wären Funkmodule schon eine Alternative.
20 billige IR Dioden sind auch noch nicht so der Kostenfaktor. Etwas umständlich ist natürlich die Verkabelung, wenn man keine eigene Platine für die IR LEDs, Treiber und ggf. die IR Empfänger hat.
...hatte ich bereits im Post #133
https://www.roboternetz.de/community/threads/63467-IR-bake/page14?p=600199&viewfull=1#post600199 verlinkt.
Das Verfahren ist meiner Meinung nach genial dafür geeignet. Es kann universell ausgelegt werden. Zum Beispiel wäre ein einfacher IR-Empfänger auf einem sich drehenden Turm (Winkelmesser) auf dem Roboter ausreichend. Die Güte der Winkelerfassung bestimmt die Auflösung und ist das einzig schwierige daran.
Die Baken (min. 3 nötig für ein "Spielfeld" / können aber auch beliebig viele sein für mehrere "Spielfelder") sind IR-Sender und senden nur ihre Adresse. Der Empfänger (Roboter) wertet die Winkel aus und hat unmittelbar nach einer Turmdrehung seine Position und seinen Winkel im Raum !
Das vorgestellte System arbeitet dagegen mit passiven Baken (nur Reflektor).
Wenn das aber unbedingt mit IR und US realisiert werden soll bin schon wieder still.....................;)
Exakt ... das Gerödel mit US braucht es nicht zwingend. Drehender Turm ist ne gute Idee, hatte an Kompass oder Radumdrehungen gedacht, Turm ist eleganter. Turm mit Schrittmotor löst das Problem mit der Winkelmessung, dann brauchts nur noch ne Referenz.
Wenn der Roboter sich nach der ersten Messung um n kleines Stück versetzt und nachmisst hat er sogar die Positionen der Baken im Raum noch dazu.
Der Rest ist dann Mathe.
Die TSOP, die ich schon verarbeitete hatten so grob 90° Keule, das müsste dann per Linse oder ähnliches verkleinert werden. Auch n Röhrchen könnt ich mir vorstellen.
Die Triggerung der Baken kann ich mir zum Strom sparen schon gut vorstellen ...
Manche hier haben nen "geschliffenen" Umgangston.
Rabenauge
27.06.2014, 22:58
Infrarot alleine funktioniert _nicht_, wenn nur eine Bake im Spiel ist. gut-man kann da rumtriucksen, indem man aus der Geschwindigkeit, mit der sich der Einfallswinkel ändert, auf die Entfernung schliesst, aber das halt ich nun irgendwie für ineffektiv.
Im Stand isses dann unmöglich, irgendeine Entfernung zu ermitteln.
Dann braucht es zwingend mehrere Baken -damit wird das System sofort unflexibel.
@Besserwessi: stimmt natürlich, die Battlesimulationen arbeiten vermutlich mit ner recht gebündelten LED-die sitzt in der Geschützmündung, soll also gar nicht allzu sehr streuen (man muss schon so ungefähr auf den Gegner zielen, damit der Treffer dort erkannt wird).
Möglicherweise wird dort auch mit zu hohem Strom getrickst-wenn mans kurz genug macht, geht das ja.
Wäre auch noch ne Möglichkeit, die Reichweite zu erhöhen- falls die LED`s das dauerhaft mitmachen (immerhin ists nicht damit getan, einmal zu blitzen und dann 1/10s abzukühlen).
Wenn der Roboter sich nach der ersten Messung um n kleines Stück versetzt und nachmisst hat er sogar die Positionen der Baken im Raum noch dazu.
Die Positionen der (>=)!!! 3 Baken im Raum müssen bekannt sein und dem System parametriert werden ! Mit einem referenzierten Turm ist dann aber die Position und sein Winkel nach einer Turmdrehung eindeutig. Der Roboter muß nicht zwei Positionen nacheinander abfahren.;)
Der Rest ist dann Mathe.
Ist im Post beschrieben (Oberallgeier gedankt!).
Ich werde das Gefühl nicht los das das noch niemand richtig gelesen hat !!!:(:eek:
Die TSOP, die ich schon verarbeitete hatten so grob 90° Keule, das müsste dann per Linse oder ähnliches verkleinert werden. Auch n Röhrchen könnt ich mir vorstellen.
Genau, den Empfänger in ein (vertikal erweitertes) Röhrchen. Beim Drehen wird dann der Empfang über mehr oder weniger viele Winkelschritte erfolgen.
Den ersten und den letzten Winkel mit Empfang mitteln und damit ist der Bakenwinkel hinreichend genau.
Besserwessi
28.06.2014, 10:23
Nur IR würde schon auch gehen, nur nicht unbedingt mit den TSOP Empfängern. Eine grobe Messung der Entfernung könnt man über die Intensität bekommen, sofern der Sender/Empfänger Isotrop ist (nicht ganz trivial). Das ist dann halt ein anderes System.
Auch die verlinkte Version mit Drehbarem Turm und abtasten der Umgebung hat was für sind. Interessant ist vor allem die Variante mit passiven Bake (Retroreflektoren). Ist aber eine andere, machbare Lösung, die auch vor und Nachteile hat.
Ein andere Variante wäre auch eine Kamera (Ohne IR Sperrfilter) auf dem Bot und dann eine langsame Modulation der IR LEDs. Blinkende IR LEDs ließen sich noch vergleichsweise einfach und mit relativ geringer Intensität in den Bildern erkennen. Bildverarbeitung braucht aber halt einiges an Rechenleistung - so etwa ein Rasberry oder ähnliches. Mit der guten Auflösung würden dann auch schon 2 Baken mit wenig Abstand (z.B. 10 cm) gut für die Entfernungsmessung sein.
Ultraschall hat auch schon was für sich: die Leistung ist relativ gering, und der Aufwand (und Gewicht) ist im Vergleich zu einem drehbaren Turm recht gering. Die hier vorgeschlagenen Billigmodule sind aber auf der Empfangsseite vor allem billig und nicht unbedingt gut. Die zusätzliche Kommunikation per IR ist da fast der größere Aufwand.
Ganz einfach ist das mit der Intensität für den Rundumsender zwar nicht, aber der Aufwand bleibt im Rahmen. 20 Dioden (zu je 10 Cent bei Pollin) sind noch kein so großer Aufwand für den Sender. Der Stromverbrauch ist zwar schon relativ hoch, aber noch von Akkus in Größe AA zu schaffen. Es ginge wohl auch mit ein paar weniger LED, aber damit wird es eher nicht einfacher. Mehr Strom geht bei den LEDs auch nur begrenzt - so etwa 1-3 A ist üblicherweise das Limit für Pulse. Im Prinzip könnte man auch die Empfangsseite verbessern (größerer Empfängerfläche, weniger Bandbreite, ggf. effektivere Modulation) , aber das ist relativ aufwändig - da sind die TSOP.... schon nicht so schlecht und vor allem günstig.
Die Positionen der (>=)!!! 3 Baken im Raum müssen bekannt sein und dem System parametriert werden ! Mit einem referenzierten Turm ist dann aber die Position und sein Winkel nach einer Turmdrehung eindeutig. Der Roboter muß nicht zwei Positionen nacheinander abfahren.;)
nee, müssen sie nicht, Wenn der Roboter seine Raddrehung zählt zwischen Position 1 und 2 kann er per Winkeldifferenz zur Bake deren Position in der Fläche relativ zu sich selbst berechnen inklusive Entfernung.
28536
Der Rest ist dann nur noch GAGA HühnerHof AG und Pythagoras.
anders geschrieben:
G A G A
----------
H H A G
Sin, Cos, Tan, Cotan
Was den Standby der Baken angeht, ist das doch weiter kein Problem die Kommunikation per IR bidirektional zu machen. Hab IR-Kommunikation für n Projekt mal gemacht, ist nicht weiter schlimm.
Habe einfach per UART Bytecodes gesendet, die Modulationsfrequenz 38kHz hab ich per Timer vom µC realisiert. Man muss nur drauf achten, dass man die UART invertiert, am Einfachsten per Sourceschaltung mit nem FET, z.B. BSN20.
Für die Unterscheidung was nun Master und was Slave ist hab ich die Paritätsbits verwendet, der Master hatte even, der Slav odd. Ergo, wenn n Byte empfangen wurde und die Parität stimmte nicht, dann wars die Gegenstelle. Stimmte die Parität war es eben n anderer Slave. Per URXC-Interrupt kann man auch gut nen µC aus dem Sleepmode holen.
Empfangsbaustein war ein besagter TSOP, der macht die Demodulation selber.
Bei dem Röhrchen wäre eben nur darauf zu achten, dass das Material auch nicht IR-transparent ist und auch möglichst IR gut dämpft wegen Reflektion an den Innenwänden.
Besagte Kommunikation lief ohne viel Kunstwerk auf 9m stabil mit 2400 Baud.
Hallo allerseits,
ich melde mich nun um über ein paar änderungen / verbesserungen an der bake 1.0 zu berichten:
es ist immer noch „nur“ eine IR-bake, folgende änderungen sind eingeflossen:
NE556 als ersatz für die zwei NE555
alles auf einer platine
nur noch drei IR-LEDs
der blinker ist nicht mehr als platine steckbar, per jumper aber abschaltbar
die 36kHz baugruppe ebenfalls per jumper abschaltbar
3 IR-LED sind in reihe (ohne vorwiderstände), 3 IR-LED parallel (mit vorwiderständen) aufgebaut, beide LED gruppen sind für testzwecke um- und abschaltbar
die stromlaufpläne (alt & neu)
2857628581
auf die nachfolgenden verbesserungsvorschläge (post 112, Besserwessi) möchte ich detailierter eingehen.Und auch fragen stellen :-)...Es hat nicht alles so wie vorgeschlagen geklappt, es kann aber durchaus sein, dass ich etwas missverstanden habe...
Bei einer 5 V Versorgung kann man je 2 (ggf. sogar 3) IR LEDs in Reihe schalten - das spart Strom und macht keinen extra Aufwand.hier musste ich feststellen, dass das nur teilweise zutrifft. Um die leistung der LEDs zu variieren kann man hier nur mit „ganzen“ LEDs arbeiten, die möglichkeit mit vorwiderständen in verschiedenen größen zu arbeiten steht nicht zu verfügung. Bei der ausführung hier (siehe stromlaufplan) funktioniert es, die LEDs sind aber nur auf maximal 30cm für den IR-empfänger sichtbar.
Das Tastverhältnis für die IR LEDs sollte deutlich kleiner als 50% sein - eher so 25 %. Bei gleichem Impulsstrom für die LEDs gibt das 50% an Stromverbrauch bei 70% der Signalstärke, oder alternativ 70% des mittleren Stromverbrauchs bei der gleichen Signalstärke. Da meine bake an einerm steckernetzteil hängt ist wie in der ausführung oben der stromverbrauch eher zweitrangig, am tastverhältnis wird – abhängig auch von der empfangs- und erkennungssoftware – noch gearbeitet...
Die IR LEDs sollten eine extra Abkopplung von der Versrogung bekommen (Widerstand und ELKO) um die Rückwirkungen auf den Rest der Schaltung zu reduzieren. Das habe ich nun überhaupt nicht verstanden: Wie beeinflussen der IR-LEDs die restliche schaltung? Wie müsste konkret die zusätzliche beschaltung aussehen?
Der 2N2222 ist mit den 5 oder 6 LEDs so auch etwas überfordert und braucht deshalb wohl den Kühlkörper. Mit weniger Widerstand an der Basis könnte er mehr Strom liefern und kommt ohne extra Kühlung aus. der Q2 hat hier einen basiswiderstand von 2x 2.2 k in reihe. Bei nur einmal 2.2 oder bei 3.1k wurden die 22 ohm vorwiderstände der IR-LEDs heiß, bei dem 4.4k auch, aber nicht so sehr.
Bei der ersten version (5 IR-LEDs, 5 vorwiderstände a 22ohm) musste der strom in 5 vorwiderständen verbraten werden, jetzt müssten die drei, die jetzt vorhanden sind, einen gesamtwiderstand auch von ca. 100 ohm haben, oder? Wenn ich aber statt 22 nun 33 ohm einsetze, verrringere ich die leistung der IR-LED, oder? Hier bin ich noch – auch was die 5 bis 6 m entfernung betrifft – noch am testen...
Der Teil mit dem Blinker ist verdächtig: die Kopplung zum IR Sender sollte mit der LED nicht mehr Funktionieren. beim ersten versuch die zwei NE555 durch einen NE556 zu ersetzen ließ ich die LED samt vorwiderstand weg – die schaltung funktionierte nicht. Bei meiner bauweise der bake war an eine fehlersuche nicht zu denken (zumindest ich hätte es nicht gekonnt)- also müll....
Beim zweiten versuch war die LED wieder dabei – und die schaltung des blinkers lief...Denke jeder was er will :-)
Bei der LED sollten es auch mehr als 47 Ohm Vorwiederstand sein. es sind nun 150 ohm
Alternativ könnte man die Kopplung über den Reset Eingang des NE555 machen - das geht auch ohne den Transistor. . Bei dem umbau, den ich mir vorgenommen habe wollte ich nicht alles auf einmal ändern – never change a running system...
und so sieht die bake 1.1 aus:
28579
Besserwessi
09.07.2014, 20:11
Das die Vorwiderstände heiß werden ist in Grenzen normal. Bei je 1 LED fallen (sofern der Transistor genug Basisstrom bekommt) etwa 0,2 V am Transistor und 1,3 V an der IR LED an - das macht dann noch 3,5 V für den Widerstand. Bei 22 Ohm sind dass 160 mA oder gut 0,5 W. Das ist für die IR LEDs bei 50% Tastverhältnis OK - ein 1/4 W Widerstand wird damit aber halt auch schon richtig heiß (so dass man sich die Finger verbrennen kann). Der 2N2222 ist dann aber mit mehr als 3 LEDs schon definitiv überfordert. Über den reichlich großen Widerstand an der Basis wird halt der Strom zusätzlich reduziert. Mit den 4,4 K hat man noch rund 1 mA Basisstrom oder bei einer typisch 100 fachen Verstärkung noch 100 mA für alle LEDs zusammen. Weniger Strom bringt dann halt weniger Leistung und man darf sich damit auch nicht über die geringere Reichweite wundern.
Will man bei 50% Tastverhältnis bleiben sind die 160 mA OK. Der 2N2222 schafft das mit etwas Mühe für 2 LEDs parallel, wobei man bei 5 V auch je 2 in Reihe Schalten kann (die 3 LEDs in Reihe sind von der Spannung schon grenzwertig). Bei 2 LEDs in Reihe wäre der passende Vorwiderstand dann etwa 2,2 V / 150 mA also etwa 15 Ohm (11 Ohm = (2 mal 22 Ohm parallel) sollten auch noch reichen). Der Transistor sollte dafür aber auch einen Basistrom von mindestens 3 mA, besser 5 mA bekommen - als Widerstand als eher 1 K an der Basis. Sonst begrenzt der Transistor den Strom und nicht mehr die Widerstände.
Ein geschalteter Strom von gut 300 mA (für 2 LED Stränge parallel) kann die Stromversorgung stören - muss es aber nicht, aber man darf sich nicht wundern wenn es passiert. Spätestens wenn man für viel Leistung so etwas wie 3 Stränge mit je 400 mA Spitzenstrom (bei 25 % Tastverhältins) hat wird man die extra Entkopplung der LED Ströme vermutlich brauchen. Ein Elko direkt an der Versorgung (C3) in der Schaltung puffert ein wenig, ist aber nicht besonders Effektiv, weil er erst wirkt, wenn die Spannung schon einbricht. Mit einem extra Widerstand in Reihe (z.B. 4 Ohm nur für die LEDs) wird der Elko viel Effektiver - der Strom für die LEDs ist dann nicht mehr ganz konstant, aber die Taktgeberschaltung ist von den Stromspitzen getrennt. 100 µF sind da schon ausreichend, sollten aber ein LOW ESR Elko (ggf. auch ein Keramischer Kondensator >= 10 µF) sein - damit der Innenwiderstand des Elkos auch klein gegen die 4 Ohm ist. Der Strom für die LEDs kommt damit erst einmal aus dem Elko und der 4 Ohm Widerstand liefert nur den mittleren Strom nach. Der Elko C3 (ggf. auch kleiner und nur ein 100nF-1µF Kondensator) sollte trotzdem bleiben, denn auch der NE555 verursacht recht heftige Stromspitzen (von der internen Schaltung).
Ein kleineres Tastverhältnis reduziert nicht nur den Stromverbrauch, sondern auch die Wärmefreisetzung an den LEDs / Widerständen. Das lohnt also auch mit Netzbetrieb.
Wie die Schaltung mit der LED funktionieren soll, ist mir schleierhaft. Da werden die IR LEDs immer leuchten, und nur recht schwach (z.B. 160 zu 165 mA) moduliert. Dazu wird der Strom dann auch noch zu groß für den Dauerbetrieb. Die LED (mit Widerstand) kann man besser direkt an den Ausgang des NE555 anschließen, also vor den Transistor - da stört sie nicht die Modulation.
Wie wäre es denn mit ein paar anständigen Transitoren für die LEDs? BD135 oder vergleichbares z.B.
http://www.fairchildsemi.com/ds/BD/BD135.pdf
Dann kann man die bzw. alle LEDs zb. auch mit an der direkten Batteriespannung (9V? 12V?) in Reihe betreiben wenn die stabilisiert ist. Es macht wenig Sinn eine stabile 12V Spannung (Batterie/Accu/geregeltes Steckernetzteil) erst auf 5V runter zu setzen und erneut zu stabilisieren um sie dann in LEDs zu verbraten... das produziert nur unnötige Abwärme. Und man kann sich ggf. das gepfriemel mit der Absicherug per ELKO/R sparen. Für selbstgemachte / entkoppelte 5V eignet sich hervorragend der 7805L als 100mA Ausführung mit 2 Kondensatoren davor und dahinter um den NE zu versorgen.
http://www.elektronik-kompendium.de/sites/slt/0208031.htm
Hier ist ein Teil dessen, was Besserwessi erklärt auch noch mal schön dargestellt.
Ich komme übrigends bei 5V Versorgung, 3 IRLEDs mit 1,3V und zusätzlichen 0,3V für den Transistor auf 5 Ohm Vorwiderstand und 128mW Leistung... das ganze gibt eine IR-Impulsleistung von 160mA Dauerstrom.. also sollte das Tastverhältnis nicht größer als 1:8 per Sec sein da eine LED als Dauerstrom üblicher Weise nur 20mA haben darf. Dazu bitte Datenblätter der LED beachten.. wenn mehr geht, entsprechend umrechnen oder es kann das Tastverhältnis gesenkt werden... ich gebe jedoch zu bedenken, das die LEDs bereits nach ca. 0,5 -1 Sec durchgeschossen sind wenn sie nicht zuverlässig mit 1:8 getaktet werden. Grade beim einschalten/anschwingen von Analogschaltungen kann das ein dickes Problem sein - vor allem dann wenn zu viele Elkos in der Schaltung stecken welche beim einschalten alle mit geladen werden wollen.
Gruß
hallo Besserwessi,
habe mir Deine ausführungen mehrmals durchgelesen und werde versuchen sie betreffend der vorwiderstände der IR-LEDs und der basiswiderstände von Q2 umzusetzen...
zu der LED:
Wie die Schaltung mit der LED funktionieren soll, ist mir schleierhaft. Da werden die IR LEDs immer leuchten, und nur recht schwach (z.B. 160 zu 165 mA) moduliert. Dazu wird der Strom dann auch noch zu groß für den Dauerbetrieb. Die LED (mit Widerstand) kann man besser direkt an den Ausgang des NE555 anschließen, also vor den Transistor - da stört sie nicht die Modulation.
Ich habe dazu ein kleines video (http://youtu.be/qXHBNYFRYBc) gedreht. Ansonsten habe ich die vorgeschlagene änderung, die seltsammerweise auf dem steckbrett funktioniert hatte (allerdings blinkte die rote LED dauernd) auf der platine – da sie dort nicht funktionierte - wieder zurückgeändert...
Die ersten sekunden des videos zeigen die lötseite, dann wird die wirkung der aufgesteckten jumper gezeigt:
ich wiederhole mich: ich habe die schaltung nach dem stromlaufplan und nach bestem wissen und gewissen aufgebaut und versuche nun das im video gezeigte zu beschreiben:
Ausgang: die grüne LED leuchtet dauerhaft, anderes ist dunkel
JMP-1: die rote LED fängt an zu blinken, das blinkermodul ist an
JMP-2: das sendemodul übernimmt die 2Hz blinkfrequenz, die rote LED leuchtet dauernd, die grüne LED blinkt mit 2Hz
JMP-4: die parallel geschalteten IR-LEDs fangen an zu blinken
JMP-3 ist für die in serie geschalteten IR-LEDs gedacht gewesen. Weil diese nach meinen letzten lötversuch auf der platine nicht mehr leuchten und ich nicht weiss welche evtl. kaputt ist, werde ich auf den einsatz von in serie geschalteten IR-LEDs lieber verzichten...
Besserwessi
10.07.2014, 21:36
Die meisten IR LEDs sind für 100 mA Dauerstrom ausgelegt. Das geht aber nur gut, wenn über die Drähte auch einiges an Wärme abgeführt werden kann. Von daher sind die 160 mA bei 50 % Tastverhältnis (38 kHz) und zusätzliche noch eine langsamere Modulation mit noch einmal ca. 50% Tastung schon ganz passend. Für eine normale (z.B. rote) 20 mA LED wäre das aber zu viel.
Das Problem mit der roten LED am Kollektor von Q1 und Basis von Q2 ist, das darüber das Signal vom 38 kHz Takt einfach überstimmt wird - gegen die fast 20 mA von der LED macht der etwa 1 mA vom NE555 fast nichts aus. Deshalb geht die rote LED auch nicht mehr aus, wenn JMP2 geschlossen wird. Damit es funktioniert müsste die LED an den Ausgang OUT1.
ok, vielleicht einigen wir uns darauf, dass es in meinem sinne - einstellbare blinkfrequenz und 36kHz werden bis hin zu den IR-LEDs übertragen - funktioniert (auch wenn die rote LED nicht ausgeht) und ich mich nun auf die optimierung der signalerkennung auf eine größere entfernung konzentrieren kann?
Besserwessi
11.07.2014, 08:11
Das Problem ist nicht nur das die Rote LED nicht ausgeht - Wenn JMP2 geschlossen ist, sollten auch die 38 kHz nicht mehr bei den IR LEDs ankommen, sondern die IR LEDs dauernd an sein und dann im Dauerbetrieb ggf. auch noch zu viel Strom bekommen. Ohne die Rote LED kann die 2 Hz Modulation funktionieren.
also ich muss gestehen, ich bin mit meiner argumentation schon ziemlich am ende. Ich bin nicht der geborene elektroniker, bin auch schon etwas älter, aber zu alterssenilität oder altersstarrsinn fehlt doch noch ein stück. Ich suche nach der erklärung für den offensichtlichen widerspruch zwischen Deiner theoretischen begründung und meinen parktischen ergebnissen. Ich möchte aber auch nicht den unausgesprochenen vorwurf ich kann nicht richtig gucken so einfach auf mir sitzen lassen:
- im video ist deutlich zu sehen, dass auch die IR-LED blinken
- ich habe mir jetzt noch die mühe gemacht und das auswertungsprogramm (http://rn-wissen.de/wiki/index.php/IR-bake_f%C3%BCr_den_RP6#Anpassung_der_Sende_und_Empf angsfrequenz_zwischen_RP6_und_der_bake) für den IR-empfang am RP6 laufen lassen, das ergebnis ist im anhang. Beim empfang wird eine 0000 ausgegeben, kein empfang 0004. Das ergebnis ist für die auswertung des empfangs nicht regelmäßig genug, das programm muss noch angepasst werden, der empfang (und zwar ein blinkender) ist aber da.
28594
als letzten ausweg aus diesem widerspruch kann ich nur noch die eventualität anbieten, dass ich durch zwei sich gegenseitig auhebende lötfehler dieses ergebnis bekomme. Die wahrscheinlichkeit halte ich zwar für nicht sehr hoch, ausschließen kann ich es aber nicht.
Würdest Du bitte inn diesem sinne noch einmal über den schaltplan schauen und mit evtl. ein tipp geben wo ich sowas gemacht haben könnte? Ich kann das nicht...
aber zu alterssenilität oder altersstarrsinn fehlt doch noch ein stück.
aber nicht mehr viel, oder? ;)
Mal im Ernst, du bastelst hier an einer gefühlt 50 Jahre alten Schatung rum. Das kann man mal machen als Schüler, wenn das Geld nicht reicht.
Aber das ist doch nun wirklich nicht mehr zeitgemäß.
Eine ganze Zeit hier im Thread wurde über Mehrfachbaken und Orientierung im Raum philosophiert und du machst mit 555ern rum?
Heute steht dir eine ganze Welt von programmierbaren Chips offen, die am Ende billiger sind als das Gefrickel mit den 555ern.
Ganz nebenbei noch beliebig anpassbar, erweiterbar und das Ziel der Mehrfachbaken bleibt auch noch offen.
Das bissl 36kHz mit 2Hz Modulation kannst du ja schon in einen Tiny13 packen. Der ist mit seinem internen Oszillator vermutlich noch deutlich genauer als der Analogkram.
Just my 2 cent.
Gruß, Michael
ich liebe spontane antworten :-), auch wenn wir uns wieder dem OT-bereich nähern den wir hier bei diesem philosophieren auch schon teilweise hatten. Die analoge zeit hatte auch ihre reize, wenn ich daran denke, dass meine inzwischen volljährige tochter (und nicht nur sie - das passt für die iphone generation als ganzes) probleme hat im kopf das analoge restgeld was sie an der kasse zu bekommen hätte nachzurechnen, wird mir aus so viel digitalisierung unwohl...
btw: das "rumbasteln" kann man nur noch an einigen wenigen stellen machen - und es hat nichts mit schüler oder kein geld zu tun -, die digitalen dinger lötest Du ein und fertig....
Aber Du hast recht, ich sollte mich einfach darüber freuen, dass meine analoge bake (immerhin habe ich eine - wo sind die anderen?) funktioniert, auch wenn sie es eigentlich nicht dürfte...
Besserwessi
11.07.2014, 13:45
Im Video sieht man die IR LEDs und die grüne LED bilnken - aber das werden nur die 2 Hz sind, die 38 kHz Modulation kommt mit den geschlossenen Jumper 2 einfach nicht mehr an. Die Schaltung addiert einfach das kräftige (150 Ohm + LED) 2 Hz Signal mit einem schwachen (4,4 KOhm) 38 kHz Signal. Benötigt wird aber so etwas wie eine Multiplikation oder UND-Verknüpfung.
Hi inka,
wenn du die 2Hz Modulation mal abklemmst und nur die 36kHz laufen läßt:
Kannst du dann 36 kHz mit dem Frequenzmesser-Programm messen?
Das wäre ja (neben dem Oszi-Bild) der Beweis, dass deine Schaltung das macht, was du willst.
hi Dirk,
das abklemmen der 2Hz modulation bedeutet ja das auftrennen des JP1 oder JP2. Beim laufendem messprogramm auf dem RP6 wird nur 0004 ausgegeben, bedeutet kein empfang auf der 36kHz frequenz...
Nicht desto trotz steht das terminal protokoll im post nr. 237 dem entgegen, welches bei laufender blinkerfrequenz eindeutig ein empfang des 36kHz signal ausweist. Die häufigkeit des empfangs ändert sich, wenn ich die blinkerfrequenz variiere. Entferne ich die bake aus dem empfangsbereich des RP6 wird auch kein 36kHz signal empfangen und nur 0004 ausgegeben. Wie erkläre ich mir das?
Ja, das ist zunächst scheinbar nicht erklärbar.
Du kannst aber mit deinem Oszi und dem Frequenzmessprogramm definitiv Klarheit darüber bekommen, was deine Bake aussendet.
D.h.: Deine "Labor-Ausstattung" ermöglicht dir (ohne lange Exkurse hier im Forum) die Baken-Schaltung zu prüfen.
Checkliste:
- 36 kHz Grundfrequenz messbar/sichtbar (Messwert [kHz] hier einstellen!)?
- 2 Hz Modulation über der Grundfrequenz erkennbar (ggf. Foto des Oszi-Schirms hier einstellen!)?
- Wie sieht das Tastverhältnis der 2 Hz Frequenz aus (An:Aus-Verhältnis = 50:50, 60:40 ..., ggf. Foto des Oszi-Schirms!)?
Wenn du diese 3 Fragen beantworten kannst, kann man hier ggf. wieder mit Fragen zur Widerstandsberechnung für die IR-LEDs u.ä. durchstarten (aktuell ja alles nur Annahmen ohne Datenbasis) und später auch ein Programm schreiben, mit dem man die Bake auf dem RP6 identifizieren und ansteuern kann.
hi Dirk,
das abklemmen der 2Hz modulation bedeutet ja das auftrennen des JP1 oder JP2. Beim laufendem messprogramm auf dem RP6 wird nur 0004 ausgegeben, bedeutet kein empfang auf der 36kHz frequenz...
diese aussage muss ich korrigieren. Als ich dieses bild gemacht habe war ich offensichtlich blind:
2863728638
dieses oszi bild entstand am Q2, collector und emitter, alle jumper entfernt. Als ich es mir heute noch einmal angeschaut habe und es auf 36kHz eingestellt habe
28639
und dann noch den JP4 (stromversorgung IR-LEDs) gesetzt habe kam mit meinem messprogramm am RP6 folgende ausgabe:
28640
man sieht ganz deutlich wann ich die bake ein- und wieder ausgeschaltet habe. Bei eingeschaltetet 2hz frequenz (JP1, JP2 und JP4 gesetzt) kam das folgende bild:
28641
hier noch einmal die schaltung, damit man nicht wieder zurückblättern muss
28642
ich habe hier nur noch die reihenfolge der LEds und ihrer vorwiderstände der wirklichkeit (LED liegt am "+" und nicht der vorwiderstand) angepasst.
ich würde sagen, dass das der nachweis ist, dass meine schaltung das tut was ich wollte...
EDIT: noch etwas habe ich vergessen, da sich das ja jetzt wieder lohnt, habe ich mir eine halterung für die bake 1.1 gebaut:
28643
hallo allerseits,
ich hatte wieder etwas zeit und habe den artikel (http://rn-wissen.de/wiki/index.php/IR-bake_f%C3%BCr_den_RP6#IR-bake_1.1_f.C3.BCr_RP6) um bake 1.1 ergänzt...
demnächst ist das nächste kapitel dran - navigation mit zwei IR-baken, kompas und SRF02...
ich möchte meine strategie für die bakensuche etwas ändern. Der RP6 selbst ist mit seinem kettenantrieb für regelmäßige, gleich grosse drehungen nicht geeignet. Deshalb habe ich das ACS etwas umgebaut/ergänzt
29292
und zwar habe ich an den ACS-pin an der base noch einen IR-empfänger drangehängt. Dieser soll zusammen mit einem SRF02 per servo gedreht werden und wenn er die bake gefunden hat (oder auch nicht) dreht er wieder zurück in die ausgangsposition und der RP6 um einen etwas kleineren winkel vor. Dann folgt der nächste suchabschnitt...
das funktioniert jetzt erstmal, eine frage zu den zwei IR-empfängern:
Den unteren, direkt an der base eingelöteten empfänger (das abschirmungsröhrchen davor) habe ich zugeklebt (so gibt es keine störimpuse), jetzt sind aber elektrisch mit ihren ausgängen am PB2 zwei empfänger dran. Macht es etwas aus? Wird der PB2 dadurch evtl. irgendwie überlastet?
danke...
Besserwessi
31.10.2014, 19:08
Ich weiss, das ich mich wiederhole, aber der Fehler mit der Roten LED für die Anzeige der 2 Hz Modulation ist immer noch drin im Plan. Auch der Steckbrettschaltung ist der Fehler wenigstens nicht mehr ganz so groß weil der Widerstand vor der LED da 470 Ohm ist. So wie gezeigt ist die Schaltung einfach nur Murks, und soll so nicht im Wiki Artikel stehen bleiben. Wenn es mit dem realen Aufbau doch funktioniert, dann entweder weil die Schaltung anders als der Plan ist, oder halt nur mit vergleichsweise sehr wenig Intensität und dafür grenzwertig viel Stromverbrauch.
Interessant wäre ggf. sich das Signal (etwa Basis oder Kollektor von Q2) mit Jumper 2 geschlossen aber Jumper 1 offen auf dem Oszilloskop anzusehen - da wird man dann sehen was da falsch läuft. Das entspricht der Ein-Phase der 2 Hz Modulation.
Die 2 IR Empfänger parallel sind kein Problem. Für den µC pin als Eingang sowieso in keiner weise, weil das halt ein Eingang ist - als Ausgang ist ggf. schon ein Empfänger ein Problem, wenn auch mehr für den Empfänger. Die Empfänger haben einen Open Kollektor Ausgang mit internem Pull-up. Die kann man also parallel Schalten und bekommt so eine UND verknüpfung - d.h. ein Low Signal kommt raus wenn einer der Empfänger ein Signal empfängt. Ein Problem wird es wenn sehr viele Empfänger parallel sind, so ab etwa 15-20 Stück.
Hi Besserwessi,
Ich weiss, das ich mich wiederhole, aber der Fehler mit der Roten LED für die Anzeige der 2 Hz Modulation ist immer noch drin im Plan. Auch der Steckbrettschaltung ist der Fehler wenigstens nicht mehr ganz so groß weil der Widerstand vor der LED da 470 Ohm ist. Wenn Du die vorwiderstände der LEDs meinst, es tut mir leid Dich mit einem alten foto des steckbretts in die irre geführt zu haben, im neueren bild sind auch dort (also wie im stromlaufplan und der fertigen bake) die vorwiderstände 150 ohm...
So wie gezeigt ist die Schaltung einfach nur Murks, und soll so nicht im Wiki Artikel stehen bleiben. Also das trifft mich schon ein wenig. Ich wäre von mir aus nicht im traum auf die idee gekommen über die bake einen RN-artikel zu schreiben, man hat mir den vorschlag gemacht, weil auch hier im thread der ganze lange weg und die intensität mit der ich mich mit dem thema beschäftigt habe sichtbar sind. Und das jetzt als murks abzutun? Ich hoffe die entscheidung über den inhalt des RN-wiki liegt nicht bei Dir...
Wenn es mit dem realen Aufbau doch funktioniert, dann entweder weil die Schaltung anders als der Plan ist, oder halt nur mit vergleichsweise sehr wenig Intensität und dafür grenzwertig viel Stromverbrauch.
Manche der fotos die ich hier gepostet habe zeugen davon, dass ich beim aufbau des steckbrettmodels wie auch der leiterplatte jeden strich, jede verbindung zwei-, dreimal überprüft habe - auch deshalb weil ich zu wenig von elektronik verstehe. Auch diese gründlichkeit kann letztendlich fehler nicht ausschließen, klar, ich bin aber ziemlich sicher, dass die schaltungen (stromlaufplan) beider baken auch in den jeweiligen aufbau so wiederzufinden sind...
hier noch ein bild der leiterplatte, ein geübtes auge eines profis sieht evtl. den fehler?
2929629297
Was meinst Du mit intensität? Die signale der baken sind auf eine entfernung von 5 metern messbar, ist es das was Dir zu wenig ist?
Strom gemessen: am JP1 - 0,5mA, am JP2 - 5mA, am JP3 - stark schwankend zwischen 90 und200mA. Ist das zu viel?
Interessant wäre ggf. sich das Signal (etwa Basis oder Kollektor von Q2) mit Jumper 2 geschlossen aber Jumper 1 offen auf dem Oszilloskop anzusehen - da wird man dann sehen was da falsch läuft. Das entspricht der Ein-Phase der 2 Hz Modulation.
Ich habe das so gemessen, wie Du es vorgeschlagen hast, bzw. wie ich es verstanden habe: JP2 geschlossen, JP1 offen, am Q2 (basis gegen emitter). Hier sind ein paar fotos, evtl. kannst Du sie interprätieren, ich kann es nicht:
292932929429295
Und das jetzt als murks abzutun? Ich hoffe die entscheidung über den inhalt des RN-wiki liegt nicht bei Dir...
Vielleicht setzt Besserwessi den Anspruch auf einen Wiki-Artikel recht hoch an. Er soll ja schließlich von Anfängern als Referenz benutzt werden können.
Viele Poster schreiben ja keine Wiki-Artikel, weil sie sich selbst nicht für gut genug halten.
Falsche Infos in Wiki-Artikeln vermehren sich auch seltsamerweise schnell und manchmal hat man Mühe, einem Anfänger diese falschen infos wieder auszureden.
Vielleicht kannst du deinen Artikel vor dem Ablegen im Wiki hier im Forum das nächste mal zur Diskussion stellen. Dann können sich alle beteiligen und das kommt imho dem Sinn eines Wikis und Forums sehr nahe.
Ich möchte dir nicht zu nahe treten, aber ehrlich gesagt, genügt der Wiki-Eintrag meinen Erwartungen auch nicht. Schon die Grafik, bei der die Bezeichnungen der Bauteile auf dem Kopf stehen, entspricht nicht der allgemein üblichen Darstellung. Was natürlich nichts am Wert deiner Leistung schmälert, einen Artikel zu schreiben, das schaffen manche nie.
Und das jetzt als murks abzutun? Ich hoffe die entscheidung über den inhalt des RN-wiki liegt nicht bei Dir...
Murks ist natürlich kein schönes Wort und man hätte es auch sozialverträglicher umschreiben können. Leider suchst du hier die Koalition, was aber schon auf eine Win-Loose-Situation hinausläuft. Damit wäre keinem gedient. http://de.wikipedia.org/wiki/Konflikteskalation_nach_Friedrich_Glasl
Ich fände es gut, wenn du den Anstoss nimmst und konstruktiv betrachtest, kann doch nur besser werden?
Gruß, Michael
Hallo Michael,
Murks ist natürlich kein schönes Wort und man hätte es auch sozialverträglicher umschreiben können. Leider suchst du hier die Koalition, was aber schon auf eine Win-Loose-Situation hinausläuft. Damit wäre keinem gedient. http://de.wikipedia.org/wiki/Konflikteskalation_nach_Friedrich_Glasl
Ich fände es gut, wenn du den Anstoss nimmst und konstruktiv betrachtest, kann doch nur besser werden?
der link ist gut...
also das letzte was ich hier suche ist eine konfrontation - mir ist doch bewusst, dass ich immer wieder auf hilfe bei der lösung meiner probleme mit der elektronik oder software - die ich nun mal brauche um in meinen zielen weiter zu kommen - angewiesen bin...
Und das funktioniert ja auch, zumindest zum großen teil, dafür noch ein danke an dieser stelle an alle, die mir geholfen haben...
Wenn Du Dir meinen letzten post noch einmal anschaust, ich habe doch nur versucht zu erklären wie die dinge zustande kamen, habe mich mehr oder weniger nur gerechtfertigt, weil meine bake funktioniert und fragen gestellt. Was ich versuche, ist zu argumemntieren, ohne den partner "runterzumachen" und ein paar angebote zu einer disskusion sind ja auch dabei...
btw: Die darstellung der beschriftung in den stromlaufplänen ist nicht optimal, das stimmt, das kommt daher, weil sie ursprünglich im eagle im lanscapeformat waren und im artikel (weil A4-hochkant format) hochkant stehen. Das mit dem von "unten- und von rechts- lesbar" ist mir als ex-konstruktionsleiter schon ein begriff, ich wollte halt hier nicht so viel aufwand treiben. Beim nächsten artikel werde ich es bestimmt besser machen...
Gibt es noch mängel die ich korrigieren sollte?
EDIT: ich werde noch die stromlaufpläne der bake 1.0 und 1.1 mit einem hinweis auf Besserwessies bedenken wegen der roten LED mit einem link zum thema im forum mit aufnehmen...
hallo allerseits,
ich habe vor ein paar tagen hier (https://www.roboternetz.de/community/threads/66469-IR_bake_2_0_signal_verst%C3%A4rken?p=610541&viewfull=1#post610541) mal ein thema IR-bake 2.0 gestartet, da ich dachte, das thema wäre - weil mit einem arduino betrieben - dort besser aufgehoben, denke aber inzwischen, dass es doch hierher gehört...
inzwischen habe ich eine im grunde funktionierende schaltung (thx @besserwessi)
29661
allerdings wird sie von der an meinem RP6 vorhandenem empfangssystem nur auf eine entfernung von ca. 30cm empfangen...
Das hatte ich schon ganz früh bei der bake 1.0. - damals habe ich es letztendlich mit hilfe von kleinerem vorwiderstand an der IR-LED und ebenfalls kleinerem basiswiderstand am Q1 hinbekommen. Hier, wenn man sich die schaltung anschaut, geht ja nichts mehr mit "kleiner", oder? Und die leistung erhöhen sollte ich schon...
mit meiner idee eines zweistufigen transistorverstärker
29662
greife ich aber wahrscheinlich zu kurz?
Liefert womöglich der arduino am pin 12 nur die 20mA und schluss, egal was ich tue?
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.