Hi damaltor,
nun hoffe ich aber [-o< , dass dieser zündende Gedankevon Sternthaler nicht dazu führt, dass dieser Thread wegen allgemeiner Personengefährdung geschlossen wird
. Obwohl die Kommunikationstechnologien gerade in diesen Tagen ihre Brisanz zeigen. Aber die IR-Schnittstelle ist zum Glück nicht geeignet, personenbezogene Daten auszuspähen . . .
Ciao sagt der JoeamBerg
Upps, irgendwie sind mir hier die letzten Beiträge durch die Lappen gegangen.
Deshalb nun mein OT dazu:
Da ich ja erwähnt wurde:
- muss ich natürlich zu zündenden Ideen Rechenschaft ablegen: Ich bereue.
- IR-Kommunikation, kann sehr wohl personenbezogene Daten ermitteln:
Ein darüber ermittelter differentieller Geschwindigkeitsverlauf eines Hindernisses, kann technisch bestimmt zwischen Fußgänger und Rollstuhlfahrer unterscheiden. Und ob man nicht, zumindest in Ansätzen, Fingerabdrücke damit scannen kann, ist noch nicht wiederlegt.
Weiterhin frohes Schaffen, wünscht
Sternthaler
Lieber Asuro programieren als arbeiten gehen.
Hallo Sternthaler,
Nochmal danke für die schicke CIRperei. Nach den anstrengenden letzten Tagen (Segeln ist auch bei den Kornaten bei Windstärke 8 nicht ganz easy - vor allem wenn mitfahrende Nichtsoganzprofis dabei Genua UND Gross vollständig rausrauschen lassen und nicht wieder selber bergen können. 100 m2 schlackerndes Segeltuch knallt fürchterlich. Aber immerhin sind knapp 10 kn bei achterlichen 8 Bft mit nix mehr als einer Viertel Genua, ok ich gab als Steuermann auch noch Segelfläche, schon ein Erlebnis!) war ich total neugierig, ob ich die interruptgesteuerte Entfernungsmessung hinkriege. Daher hatte ich mir die Sache mithilfe Deines schönen, praktischen Codes leicht gemachtZitat von Sternthaler
. Die CIR-module laufen nach Anpassungen und Deinem Kommentar einigermassen auf zwei von meinen drei DME-Kanälen. Port C0 gibt noch keinen Messwert her und die Rechnerauslastung durch die ISR ist mir noch nicht klar. Aber es geht voran.
Fazit: ich bin auf dem Weg, aber es wird noch ne Weile dauern, bis es sauber funktioniert. Die Messung der Beleuchtungsstärke habe ich abgehakt, siehe oben.Code:irDME-Test nach Adaption des CIR-Codes von Sternthaler, Einarbeiten der Kommentare, erster Fehlersuche und -behebung. irDME-Kanal 0 ist inaktiv. Die Kanäle 1 und 2 sind aktiv und werden korrekt ausgegeben, siehe die nachstehenden Terminalausgabe. Die Messwerte schwanken in einem deutlichen Bereich. Bei dieser Terminalausgabe ist der ADC/GP2D120 nicht beschaltet - der schwimmende Eingang führt zu fehlerhaften Angaben. =========================================================================== Pm168D/20 MHz m168D_10x30.c *libs x30/331 23juni08 0948 Erste ISR für TC0CMPA - für irDME irPort 12+3+4 irLED 36,0 kHz Messen im Interrupt ir12-4 0/ 24/ 15 Isvs 27 Ipwm 0 ADCmm 380 ir12-4 0/ 24/ 5 Isvs 27 Ipwm 0 ADCmm 369 ir12-4 0/ 21/ 2 Isvs 27 Ipwm 0 ADCmm 999 ir12-4 0/ 20/ 2 Isvs 27 Ipwm 0 ADCmm 207 ir12-4 0/ 19/ 3 Isvs 27 Ipwm 0 ADCmm 306 ir12-4 0/ 19/ 2 Isvs 29 Ipwm 0 ADCmm 421 ir12-4 0/ 26/ 14 Isvs 29 Ipwm 0 ADCmm 465 ir12-4 0/ 24/ 18 Isvs 29 Ipwm 0 ADCmm 375 ir12-4 0/ 2/ 18 Isvs 29 Ipwm 0 ADCmm 450 ir12-4 0/ 2/ 16 Isvs 29 Ipwm 0 ADCmm 204 ir12-4 0/ 2/ 17 Isvs 29 Ipwm 0 ADCmm 360 ir12-4 0/ 3/ 15 Isvs 31 Ipwm 0 ADCmm 999 ir12-4 0/ 3/ 17 Isvs 31 Ipwm 0 ADCmm 999 ir12-4 0/ 21/ 15 Isvs 31 Ipwm 0 ADCmm 692 ir12-4 0/ 24/ 15 Isvs 31 Ipwm 0 ADCmm 999
Wie läuft die CIR mit dem asuro? Gibt es da Rückmeldungen?
Nachtrag 14:00 Uhr: Ich hab mal auf die Schnelle eine Zeitmessung gemacht über 4 sec. Mit initialisierter ISR brauche ich für eine kleine Schleife mit Datenausgabe und 5000 waits rund 4,16 sec, ohne Initialisierung, also ohne ISR, dauert das 3,96 sec. Das heisst ich brauche für die ISR in jeder Sekunde rund 50 ms bzw. 5% der CPUzeit. 6 Iterationen mit je 10 Messwerten und 3 Messkanälen wären je Sekunde rund 27 Messwerte für jeden Kanal. Bei der erreichbaren Genauigkeit ist das fast eine Größenordnung zu viel. Auch hier werde ich nochmal genau nachsehen/-messen/-rechnen.
Ciao sagt der JoeamBerg
Hallo oberallgeier,
hübscher Farbton für das OT. Blau (also der Inhalt) ist wie immer lesenswert. Aber trägt das nicht sehr stark auf? Man kann sein OT dann ja nicht mehr so gut in unwichtigen sachlichen Infos verstecken
Ende Blau.
Nein, es gibt keine Rückmeldung. Sowohl hier als auch unter "Asuro: Umbau der IR-Schnittstelle zur Hinderniserkennung" von waste. Dort hatte ich noch einen Hinweis als Link hier hin verlegt, dass hier geCIRt wird. Und irgendwo anders hatte ich noch einem IR-Hindernis-Assembler-Progger dieses geCIRce verlinkt.
Deiner Aussage, dass der Interrupt ca. 5% der Rechenleistung benötigt, würde ich grob erst einmal PI*Daumen zustimmen. In der von mir geschriebenen CIR liegt man bei ca. 15%. Aber ich rufe das ja auch mit 36 kHz auf und du nur mit 4,88 kHz.
Wenn du mal die Datei *.lss postest, kann man die einzelnen Assemblerbefehle in der ISR zusammenzählen. Das würde dann eine schöne Gegenrechnung zu deiner Zeitmessung ergeben.
Wenn du die 27 Messwerte nicht benötigst, dann ist es deinem Hauptprogramm überlassen diese Information NICHT zu nutzen.
Um weniger Messwerte zu erhalten, könntest du 3 Varianten bedenken:
1: Mehr Messwerte als die 10 angegeben pro OCR2-Wert fordern.
2: Die ISR nur dann aktivieren, wenn das Hauptprogramm Daten benötigt.
3: Die 4,88 kHz reduzieren.
Bei 1: veränderst du in Grenzen die Messgenauigkeit, aber die verbrauchte CPU-Zeit in der ISR bleibt bei den 5%. (Sie sinkt etwas)
Bei 2: hast du wieder den Nachteil einer einzelnen Messung, da du ja nach dem Einschalten der ISR im Hauptprogramm erst wieder auf ein gültiges Ergebnis warten musst. Damit ist aber der Vorteil, dass die Messwerte "einfach so da sind" hinfällig.
Bei 3: habe ich keine Ahnung, ob deine Motorfunktionalität das verträgt.
Zu deinen Messergebnissen oben aus dem Screenshot hast du nicht angegeben ob die Daten im Stand von deinem Robi, oder mit einer Änderung der Umgebung aufgenommen sind.
Ich vermute, dass es sich um eine 'Standaufnahme' handelt. (Du hättest da sonst ja drauf hingewiesen.)
Dann ist es tatsächlich etwas merkwürdig, dass die Werte so pendeln.
Zwischen 2 (sehr nah) und 26 (sehr weit) wäre es ja mit meiner Umrechnung in cm dann zwischen 12 cm und 151 cm.
Ne, ne, da ist etwas faul.
=> Code posten ist wohl angesagt
Gruß Sternthaler
P.S: in Blau: Hätteste du mal das Fock anstatt des Genua eingepackt. Dann wäre auch nichts passiert
Wurden bei 8 Bft schon Tüten verteilt, oder ist der Weg über die Reling die Lösung? Bis 6 halte ich nur durch.
Lieber Asuro programieren als arbeiten gehen.
Hallo Sternthaler,
Ich hab mal vorerest die Variante 4 genommen, postscaler - also NACH Aufruf der ISR - statt prescaler. Leider kostet das dann den ganzen Verwaltungsaufwand eines ISR-Aufrufes. Ansonsten, zugegeben etwas rustikal, aber wirksam:
damit kam ich gestern schon auf 2 % - eher wenigerCode:/* ============================================================================== */ /* === Nicht unterbrechbare ISR für TIMER0_COMPA_vect _VECTOR(14) ============ */ /* ISRoutine wird vom TimerCounter 0 getaktet mit 4,88 kHz, wertet irDME´s aus */ ISR(TIMER0_COMPA_vect) // _VECTOR(14) { // Klammerebene 1 ISR_post_sclr--; if (ISR_post_sclr > 0) return; else ISR_post_sclr = 8; PORTC ^= (1<<PC4); // LED auf Port PC4/I2C/SCA toggeln /* - Lese das Datenbit vom IR-Empfaenger Y-fach */ . . . . .. Die PWM will ich nicht mehr ändern, das scheint ein guter Wert zu sein, vgl. auch den entsprechenden Thread.
Ja - aber erstmal will ich ihn so weit fehlerfrei machen, wie ich es vermag. Ist ja kein Bananencode (wird unreif geliefert - reift beim Kunden/Kollegen/Forumsmitglied).
Trägt auf, stimmt schon - aber ich hab jetzt eine hübsche Version gefunden: blau und doch nicht blau - gut gell?
Es ist eine Rollgenua - da müsst ich noch einen extra Fock-Stag einbauen (lassen). Ach - bei den 8 Bft hatte ich morgens schon M....sausen, aber wenn das Boot erstmal auf einer Seite bis zur Reling im Wasser krängt, dann steht sichs am Ruder auch wieder recht bequem und locker. Nur bei dem Spektakel mit den losen Segeln hatte ich mit mir gehadert, weil die Rettungswesten in den Spinden hingen ...
Ciao sagt der JoeamBerg
Hallo Maler (die Farbe für OT ist ja schrecklich),
wenn die ISR(TIMER0_COMPA_vect) die 4.88 kHZ-Routine ist, dann kommst du mit dem Pre-/Postscaler ja immer mehr an die Variante von meinem geCIRpe ran. Ich hatte dort ja als 2.tes das Warten auf die mindestens 6 Take für die Sende-LED vorgesehen. (Das 1.te war die Prüfung, ob überhaupt geCIRpt werden soll. Frisst auch Zeit.)
Du reduziert nun schön um den Faktor 8 mit deiner Variablen ISR_post_sclr.
Unterm Strich, müssten ca. 8 Takte innerhalb der ISR vergehen, wenn die Variable ISR_post_sclr eine voilate uchar_t ist.
Mist, Server in der Firma ist wieder am Netz. Ich muss weiter schaffen.
Gruß Sternthaler
Lieber Asuro programieren als arbeiten gehen.
Schönen Sonntag
allen, die hier mitlesen wollen. So nach dem Motto Lk 8-8 (".. Wer Ohren hat zu hören ..").
Fazit: die Abstandsmessung mit mehreren irDME´s läuft zu meiner Zufriedenheit.
Mit meiner Abstandsmessung bin ich vorangekommen, daher wieder einmal ein Bericht. Eine ganz wesentliche Hilfe war für mich Sternthalers Code zum chirpen und seine Hilfe bei der Implementation. Danke Sternthaler!
Die CIR-Routine von Sternthaler konnte ich fast unverändert übernehmen und messe nun mit vier Ports an (m)einem mega168/20MHz für eine Batterie mit drei LED´s an einem BC337 und drei Sensoren SFH5110-36 im Interrupt. Der LED-Port ist PB1/OC1A, die SFH5110er hängen an PC0 bis 2 (siehe Auszug aus meinem "Code"):Hier noch die Schaltung (es gibt ein paar wenige Änderungen+Ergänzungen darin, die aber nicht von Bedeutung sind.Code:/RESET 1 28 PC5,(SCL) RxD,(PD0) 2 27 PC4,(SDA) TxD,(PD1)___3 26___PC3, ADC3 / Sharp GP2D120 SigMot1=ExtINT0,(PD2) 4 25 PC2, SFH 5110, IN irDME 4 } vorgesehen SigMot2=ExtINT1,(PD3) 5 24 PC1, SFH 5110, IN irDME 3 } evtl. auch in _|-- 3,4 Guz, PD4___6 23___PC0, SFH 5110, IN irDME 1-2 } ´168 n VCC 7 22 GND GND 8 21 AREF XTAL1 PB6___9 20___VCC XTAL2 PB7 10 19 PB5, Startblink, Mehrzweck PWM 1,2 uz+Guz,PD5 11 18 PB4 _|-- 3,4 uz PWM 3,4 uz+Guz,PD6__12 17___PB3, Reserve 2 _|-- 1,2 uz,PD7 13 16 PB2, Servo _|-- 1,2 Guz,PB0 14 15 PB1 SFH 415, OUT (irDME)
Die ISR-Frequenz ist 1220 Hz und eigentlich für die Ansteuerung/PWM der Motoren vorgesehen. Die niedrige Frequenz ist sehr praktisch, weil ich damit Warteschleifen für das Ansprechen des 5110 nicht mehr benötige. Dieses Ansprechen des 5110 durch bursts mit mehreren, mindestens sechs, Pulsen hatte ich schon hier beschrieben. Der Abstand zwischen den einzelnen ISR-Aufrufen ist so lange, dass die erforderlichen Pulse "von selbst" ablaufen.
Ursprünglich hatte ich 4,88 kHz verwendet, dabei nahm mir die ISR für die Abstandsmessung einfach zu viel CPU-Zeit, rund 5%, in Anspruch. Mit der geringeren Frequenz laufen die Motoren prächtig (Integerregelung, der Geradeauslauf ist für mich total überraschend sehr gut) und die CPU-Auslastung ist bei
ISR-Frequenz 1,22 kHz 1,2 %
ISR-Frequenz 0,6 kHz 0,87 %
Der geringe Gewinn durch die 600 Hz-PWM wird zugunsten der höherfrequenten Motoransteuerung nicht genutzt. Sicher habt ihr schon mitgerechnet: das ergibt in jeder Sekunde bei 1,22 kHz rund sechs gesonderte Messwerte für jede der drei Messstellen. Da mein Mini kaum mehr als 60 mm pro Sekunde fährt (rund 0,2 kmh) ist das eine sinnvolle Auflösung.
Es werden 7 Iterationen durchlaufen, um die Chirperei der LED von 127 herunter bis auf 1 digit abzuarbeiten. Dabei werden jeweils 10 Messungen bei gleicher Pulslänge (OCR..) durchgeführt, sodass jeder einzelne Messwert innerhalb der Chirperei über 10 getrennte Messungen gemittelt wird. Auch hier bringt die relativ langsame ISR-Frequenz einen Vorteil und führt zu einer hübschen (relativen) Genauigkeit - besser gesagt: Reproduzierbarkeit.
Erhebliche Unterschiede beim Messergebnis bringt natürlich die angemessene Oberfläche. Das ist klar, weil es erhebliche Unterschiede in der Albedo der üblichen Oberflächen im häuslichen Bereich gibt. Eine etwas bessere Auflösung im Nahbereich scheine ich mit der Verwendung der CQY99 zu bekommen, da stehen mir noch Messungen bei GLEICHEN Messbedingungen aus. Diese werden noch folgen zusammen mit einem Diagramm über gemessene Entfernungen bei verschiedenen Beleuchtungsbedingungen.
Eine interessante Tatsache ist mir noch aufgefallen. In einem anderen Thread über Schaltung und Widerstände beim Einsatz von mehreren, parallel betriebenen LED´s kam ich nach einigen Diskussionen mit Mitch64 darauf, dass die Lichtleistung der irLED bei kurzen Pulsen im Bereich zwischen OCR.. = 1 bis 5 ziemlich an Fülligkeit verliert (Lichtleistung abgeleitet vom zeitlichen Verlauf des Spannungsabfalls durch den Vorschaltwiderstand der LED).
Nach einem Ratschlag von Mitch64 habe ich bei meinem R5 (siehe Schaltung) einen Kondensator verpasst und dieses Ergebnis gefunden für die Ansteuerung der irLED-PWM mit OCR1A = 5 bis 1 - links ohne, rechts mit KerKo 100nF (0,5 µs/DIV, 2V/DIV):
..........................Bild hier Bild hier
Beachtlich, wie sich die Stromanstiegsgeschwindigkeit durch die LED´s damit verbessern ließ. Allerdings war das Ergebnis nicht in die gewünschte Richtung: die erhöhte Lichtleistung nach Einbau des Kondensators führte dazu, dass ich im Nahbereich eine wesentlich schlechtere Auflösung bekam als bisher. Dabei hatte ich ja im Vorfeld schon einige Variationen getestet, um innerhalb meines Messabstandes zwischen ca. 80 mm und 300 mm eine gute und feine Auflösung, nicht zuletzt im Nahbereich, zu bekommen. Also ist der Kondensator wieder entfernt worden. Aber es ist gut zu wissen, dass es da noch Feinheiten gibt. Wer weiß, wozu das noch gut sein kann. Danke Mitch64.
Ja - und nun läuft also mein einfacher Zweiräder zwar minimalistisch aber doch schon autonom und macht vor jedem Hindernis, das er vor und 90° links und rechts von sich erkennt eine kurze 60°-Rückwärtsdrehung und fährt danach in die neue Richtung weiter - ausser es ist noch immer etwas in "Sichtweite". Die eigentlich vorgesehene "Blindenstock-Funktion" der DME´s ist noch nicht realisiert, da muss ich noch etwas an der Mechanik des Mini´s machen. Aber ich bin recht stolz drauf, dass ich nach einigen Monaten (angefangen als Nobody in "C" und Elektronik) ein einfaches, selbst entworfenes Projekt doch gut vorangebracht habe.
Geändert von oberallgeier (05.09.2017 um 11:55 Uhr)
Ciao sagt der JoeamBerg
Hallo oberallgeier,
herzlichen Glückwunsch zu deinem Erfolg.
Nun lass dich aber nicht weiter abhalten, sondern mach dich an die "Blindenstock-Funktion". Was auch immer man sich da nun wieder drunter vorstellen muss.
Gruß Sternthaler
Lieber Asuro programieren als arbeiten gehen.
Danke Sternthaler. Ganz einfach - ein Blindenstock zeigt bei bestimmungsgemäßem Gebrauch (meist) so schräg nach vorn unten. Und das sollen die DME´s auch. Dann kann ich sie als Absturz- und als Kollisionssensoren verwenden. Nur - im Moment bin ich auf diesen Augen wirklich blind - alle irLED´s kaputt gekriegt... Glückwunsch ... mach dich an die "Blindenstock-Funktion". Was auch immer man sich da nun wieder drunter vorstellen muss- also wirds ein lang(weilig)es Wochenende.
Ciao sagt der JoeamBerg
Berechtigungen
Zitieren
Lesezeichen