Abstandsmessung ähnlich wie IR-Schnittstelle des asuro

[oberallgeier]

Hinweis vom 01. Oktober 2008: eine abschließene Zusammenfassung gibt es hier. (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=399665#399665)

Titel am 22März08 editiert: "Probleme bei" wurde gestrichen, denn die Probleme sind ja eigentlich gelöst.
--------------------------------------------------------------------------------------

Hallo alle,

über Unklarheiten bei der IR-Schnittstelle zur Hinderniserkennung bzw. zur Abstandsmessung habe ich hier bereits kurz berichtet (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=348970#348970). Nun habe ich weitere Probleme damit. Was mache ich falsch?

Über die Schwierigkeiten des SFH5110 sich für "ein" oder "aus" zu entscheiden habe ich im genannten posting bereits berichtet. Ich kann aber auch die Ergebnisse zur Entfernungsmessungen nur schwer nachzvollziehen.

Hintergrund: ich will diese asuro-Abstandsmessung als irDME (IR-Entfernungsmesser) einsetzen - preislich ist es ja unschlagbar. Deshalb habe ich eine kleine Einheit aufgebaut, die genauso bestückt ist, wie die entsprechenden Schaltkreise beim asuro (Ausnahme: der 490R für Vcc-5110 ist hier nur 330 - die Drähte im Bild sind für einen Spindeltrimmer, mit dem ich die 415 trimmen konnte - alle hier genannten Messungen wurden mit 220R gemacht). Dass der Testaufbau auf einem m168/20MHz läuft, sollte meiner Meinung nix ausmachen ! ?

..........................https://dl.dropbox.com/s/d6jl728fndsqt1t/irDME_1465.jpg?dl=0

Erstmal habe ich festgestellt, dass ich wesentlich besser Abstände messen kann bei 38 kHz im Vergleich zu 36 kHz. (Wieweit die RS232 dabei besser ginge, habe ich noch nicht untersucht).

Um die Entscheidung auf "ein" oder "aus" auf etwas bessere Beine zu stellen, habe ich eine Art primitiver Statistik eingeführt:

for(uint16_t k=0; k<=1000; k=k+1)
{
for(uint16_t m=0; m<=2000; m=m+1) //
{ //
tmp = PINB; //
if (!(tmp & 0x08)) // Aktionen für gelöschtes Bit
if (istaus > 0)
istaus = istaus--; // heisst: Counter runterzählen
else // .. wenn Bit nicht gelöscht, dann ist es gesetzt
{
inix = istaus; // Dummyaktion
}
else // wenns nicht gelöscht ist, ist es gesetzt :)
if (istaus < 1000)
istaus = istaus++; // also Counter raufzählen bis 1 000
else
{
inix = istaus; // DD doofer Dummy, nix machen
}
// ##### danach vergleiche was größer ist:
// ##### wenn über xxx , Port einschalten, wenn unter xxx Port ausschalten
if (istaus < 10)
{ // hier die Anweisungen, wenn das Bit gelöscht ist
PORTC &= ~(1<<PC0); // lösche PC0
}
else // .. wenn Bit nicht gelöscht, dann ist es gesetzt
if (istaus > 990)
PORTC |= (1<<PC0); // Setze PC0
else
{
}
{
}
}
// waitms(1); //
}
Damit erreiche ich eine Hysterese von etwa 10 .. 20 % bezogen auf den Schaltabstand. Im Vergleich dazu beträgt die Hysterese ohne diese einfache Rechnerei rund 50 % des Schaltabstandes.

Schaltabstände über 40 cm konnte ich praktisch nicht messen. Ich bewerte die "Entfernung" erstmal mit dem von mir gesetzten Rampenwert der PWM und nenne das "AktRampe". Bei 36 kHz geht der 5110 auf low bereits bei einem Rampenwert von 17 (ich schalte mit dem Signal des 5110 eine "Kopier"-Led, um eine schnelle optische Kontrolle zu erhalten). Bei 38 kHz tritt ohne Statistik ein sichtbares Flattern (sichtbar an der LED, am Oskar schon früher) bei Rampenwert 20 auf, deutliches Flackern der Kontroll-LED bei 30, LED ist fast aus bei 50 und nicht mehr feststellbar bei 60. Dann ist am Oskar noch hin und wieder was zu sehen.

Mit "Statistik" 10/990 - siehe Code oben - bekomme ich:
AktRampe Schaltabstand ca. cm
5/263 5
10 11
15 17
20 17
30 40
36 low
Lasse ich die 415 frei nach vorne in den Raum strahlen - sie ist natürlich abgeschirmt mit einer Schlauchblende - bekomme ich folgende Terminalmitschrift:

.......................https://dl.dropbox.com/s/sbgqyurpsg2p5z7/testlauf-10feb08-2350.jpg?dl=0

Dabei ist mittendrin mal eine Bedämpfung des Messstrahls mit der Hand zu erkennen an dem Absinken der Statistikwerte "stt" unter 1000. Gegen Ende der Aufzeichung strahlt die SFH415 aber wieder unbedämpft und man sieht den aktuellen Statistikwert. Deutlich ist zu sehen, dass bei einer Ansteuerung mit "Rampe" 40 der 5110 praktisch auf low ist. Der maximale "Rampenwert", d.h. der Wert im ICR1 beträgt 263 - daher insgesamt eben maximal 264 Werte.

Fragen:
Habe ich Fehler gemacht? Wenn ja, welche?
Wieso messe ich nur maximale Entfernungen bis etwas 30 cm einigermassen vertrauenswürdig?
Wurde ähnliches Flattern am 5110 schon von euch beobachtet - aber bei mir machen es alle Aufbauten - auch der asuro.
Wieso funzt die Abstandsmessung am asuro so gut? Oder: wieso ist meine Messeinheit so anders?
Hat jemand auch schon mit Frequenzen "neben" der Nennfrequenz des SFH5110 experimentiert? Mit welchem Ergebnis?

Ok, etwas komplex, vielleicht findet jemand die Würmer? Danke im Voraus,

[Sternthaler]

Hallo oberallgeier,
habe dich gerade erst hier entdeckt. Ich hatte vor einer Minute in dem oben von dir angegeben Thread geantwortet.
Dies hier muss ich mir dann doch wohl etwas genauer ansehen. Aber nicht mehr heute.

Gute Nacht oder guten Morgen. Wie ihr gerade wollt.
Gruß Sternthaler

[oberallgeier]

Danke für Deinen Kommentar hier (und im Ursprungsthread). In meinem Datenblatt "Infineon / OSRAM" ID "2000-02-02" sah ich nichts von einem empfohlenen Tastverhältnis. Lediglich von der Burstlänge von min. 6 Pulsen ist die Rede und ein Tastverhältnis (duty cycle) von 50% ist beispielhaft genannt. Auch die ausführlichere General Application Note for SFH511X, die ich mir wegen Deines Hinweises gerade geholt hatte, Stand January 30, 2002, zeigt gleiche Werte.

Dafür war mir schon aufgefallen, dass die Datenblätter eine Peripherie des 5110 als typisch zeigen, die deutlich anders ist als beim asuro. Ich hatte die Beschaltung des asuro nachgebaut, weil ich mich auf die Erfahrungen dieses Forums stützen möchte.

Mit "Entscheidungsschwäche" meine ich die Tatsache, dass ich bei der Entfernungsmessung keine eindeutige Schaltschwelle bekomme. Der 5110 zittert in der Art:
___________ _ _ _ _ _ _ _ _ _ _
.....................\ _ _ _ _ _ _ _ _ _ _\___________ (Anmerkung: die hellen Punkte bitte wegdenken)

zwischen high und low, wenn ich ein Testobjekt, z.B. meine Hand, von "eindeutig high" z.B. bei 30 cm, zu "eindeutig low" z.B. bei 20 cm bewege. Dabei schwankt der high und der low-Anteil je nachdem, bei welchem Abstand ich näher bin.

Unklar ist mir dabei, ob vielleicht durch geeigntete Dimensionierung der erwähnten bursts (min 6 Pulse) eine bessere Messmöglichkeit für Entfernungen besteht. Ich habe das auf meinem Testprogramm, da ja (siehe die jüngere doc, S3, unten) die "typische" Empfindlichkeit spezifiziert wird für bursts von 600 µS Länge, also 23 Pulsen.

Aber das Eingangsbeispiel von waste (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=99791#99791) zeigt ja im Code auch (nur) die Änderung des OCR2, während PD1 nicht getaktet wird. Meine "AktiveRampe" variiert ebenso, es ist mein OCR1A mit ICR1 = 263 als TOP.

Mit meinem Posting hoffte ich (als elektronischer Blindgänger) zu erfahren, ob ich a) irgendwie falsch liege und/oder b) ähnliche Erfahrungen zu dem Thema vorhanden sind.

Andererseits könnte ich mit dem derzeitigen Zustand meiner Abstandsmessung garnicht so schlecht leben. Es wär nur interessant ....

[Sternthaler]

Hossa oberallgeier,
ach das meinst du mit der "Entscheidungsschwäche".

Ja, da hast du das gleiche Problem, das auch im Asuro bei den original Bauteilen vorhanden ist.

Hier mal die aus dem waste-Original-Thread (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=11114) gesammelten Daten:

robo.fr gibt in seinem Programm (http://www.roboterclub-freiburg.de/asuro/hardware/chAtmegaAdapter/SumoAdapter.html) und seiner Tabelle (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=342508#342508) folgendes an:


OCR2= 254-X Abstand[cm]
0 5
1 7
2 13
3 15
4 16
5 17
6 18
7 22
Ich hatte in der Tabelle (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=341341#341341) ungefähr so etwas:


OCR2= 254-X Abstand[cm]
0 6
1 14
2 20
3 28
4 32
5 38
6 42
7 47
. .
32 120
Und inka hat laut seinem Beitrag (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=341417#341417) die von mir ermittelten Abstände mathematisch halbiert auf:


OCR2= 254-X Abstand[cm]
0 3
1 7
2 10
3 14
4 16
5 19
6 21
7 23
. .
32 60

Unterm Strich sind die Programme extrem ähnlich.
Sternthaler und inka sind identisch, außer dass inka die Entfernungsberechnung (aber nicht die Ermittlung) angepasst hat.

robo.fr hat etwas umgebaut (Die Struktur sieht nach meinem Programm aus). Er hat vor allem in der Schleife zum testen von Pin D0, dahingehend geändert, dass 'nur' 30 mal geprüft wird. In der Schleife wird künstlich mit Sleep() gewartet.

Genau dieses Sleep()-Konstrukt hatte ich nach einigen eigenen Tests komplett aus meiner ersten veröffentlichen Version "Chirpen-über-IR" durch Massenmessungen ersetzt. Ich loope über der "teste Pin D0"-Stelle bewusst sehr häufig (1000 mal) ohne Sleep() damit die Statistik "erkannt / nicht erkannt" mit vielen Daten arbeiten kann. Das hatte sich bei mir mit höheren Messanzahlen bzw. mehr Statistik gut bewährt um relativ wenig "Entscheidungsschwäche" zu erhalten. Immerhin hatte ich damit bei mir festgestellt, dass ein 'Umschalten' von einem Entfernungsbereich in den Anderen, immer bei ca. 0,5 cm liegt. Bei einer Auflösung von ca. 3 cm ab ungefähr 40 cm hört sich das zwar nicht gut an, da der Chirp aber immer von 'Nah nach Fern' messen muss, nähern wir uns also immer aus der gleichen Richtung der 'tatsächlichen' Entfernung an, und somit gibt es dort keine Hysterese. Und das 'schlackern' vom Ergebnis am Umschaltpunkt ist nur relativ selten.

robo.fr und inka habe beide ungefähr die gleiche Beziehung zwischen OCR2-Wert und Entfernung. Bei mir ist 'nur' die Skalierung' anders.
Ich hatte ein graues Mauspad an die Wand gestellt und den Asuro, auf dem Fußboden stehend, die Messungen machen lassen.
robo.fr mag gerne Joghurt und nutzt diese Hindernisse.
Als logische Konsequenz muss inka somit auch Joghurt mögen.
Hier sollten wir eventuell mal eine genormte 'Test-Reflektorfläche' definieren und für teuer Geld verkaufen. Haben die Banken ja auch schon lange Zeit gute Erfahrung gemacht die Leute zu veräppeln. Früh genug aus dem Geschäft muss man halt nur aussteigen.



Wenn ich mir nun deinen Programmausschnitt ansehe, und deine Beschreibung dazu durchacker, dann bin ich mir relativ sicher, dass du auf den gleichen Mist gestoßen bist wie ich auch.

Die von dir angesteuerte "Kopier"-Led hängt an Port C0. Die Statistik, die du betreibst, liegt in deinen beiden for(k und n)-Schleifen. Aber auch die Auswertung ist noch innerhalb beider Schleifen. Somit sammelst du keine Daten in einer inneren Messschleife; betreibst Statistik; und schaltest dann nur die LED entsprechend. >= Ergo: Deine LED und natürlich der Oska 'flattern' wie die Weltmeister.

Genau das Problem hatte ich auch zu Anfang, bis ich eben diese Statistik eingebaut hatte und die Auswertung hinter die Statistik-Sammel-Loop gelegt hatte um dann erst daraus die Entfernung/Aktion ("Kopier"-Led) zu machen.

Ich habe das, wie oben schon angedeutet, mit 1000-fachem Statistik sammeln getan. Das entspricht deiner inneren for(m)-Loop. Und robo.fr hat weniger Statistik, verzögert mit einem Sleep() betrieben, und auch dann erst ausgewertet.
Somit ist ein 'flattern' der ermittelten Entfernung nur in der Frequenz reduziert, aber eben durch die Statistik besser 'untermauert'.

Hier noch mal dein Programmstück mit der von mir markierten Stelle, an der du ändern solltest für weitere Tests:

for (uint16_t k = 0; k <= 1000; k = k + 1)
{
for (uint16_t m = 0; m <= 2000; m = m + 1)
{
tmp = PINB;

if (!(tmp & 0x08)) // Aktionen für gelöschtes Bit
if (istaus > 0)
istaus = istaus--; // heisst: Counter runterzählen
else // .. wenn Bit nicht gelöscht, dann ist es gesetzt
{
inix = istaus; // Dummyaktion
}
else // wenns nicht gelöscht ist, ist es gesetzt :)
if (istaus < 1000)
istaus = istaus++; // also Counter raufzählen bis 1 000
else
{
inix = istaus; // DD doofer Dummy, nix machen
}

} // <==== Hier die Statistik-Sammlung OHNE AUSWERTUNG loopen lassen


// <==== Ab hier erst nach der Datenerhebung diese nun auswerten.

// ##### danach vergleiche was größer ist:
// ##### wenn über xxx, Port einschalten, wenn unter xxx Port ausschalten
if (istaus < 10)
{ // hier die Anweisungen, wenn das Bit gelöscht ist
PORTC &= ~(1<<PC0); // lösche PC0
}
else // .. wenn Bit nicht gelöscht, dann ist es gesetzt
if (istaus > 990)
PORTC |= (1<<PC0); // Setze PC0
else
{
}
// } // <==== Ist nun ueberfluessig
}
Als kleine 'Unschönheit' versaust du dir die Statistik auch noch an 2 Stellen:
1) Variable istaus wird bei dir zwischen 0 und 1000 begrenzt. Damit verlierst du Statistikinformationen.
2) Nach der Auswertung der Statistik machst du keinen Reset auf diese Variable. Du nimmst somit (das begrenzte) Vorgängerergebnis in die nächste Runde mit.

So, mehr Sermon kann ich im Moment nicht mehr von mir geben.
Berichte mal über deine Reflektorfläche(n), die du zum testen nutzt. Nicht die Hand, sondern so etwas wie Mauspads, Füchse oder Joghurtbecher meine ich ;-)

Gruß Sternthaler

P.S.: Das mit dem von mir angegebene 'Taktverhältnis von <40%' kommt aus dem I-Net von hier (http://www.mercateo.com/p/115-631573/SFH5110_38_950NM_IR_Diode.html).
Ob ich da mit dem Verstehen klar gekommen bin müßt ihr entscheiden.
Wahrscheinlich ist die Angabe '2theta½: 55 °' eher zuständig. Aber damit kann ich rein gar nix anfangen.

P.P.S.: (Wenn schon lang, dann richtig) Im übrigen gefällt mir deine Platine sehr gut. Stecker deutet auf viele Anwendungsideen hin.

[oberallgeier]

Hallo Sternthaler,

einfach klar: Deine Gedanken, Dein Urteil - sehr schön dargestellt. Vielen Dank. Ich hatte das Programm ja mal so als ersten Versuch zu diesem Thema geschrieben und die "Kopier-LED" eingeführt, weil der Oskar bei mir seitlich am Boden steht. So habe ich die Wirkung der Bedämpfung immer vor Augen.

Mittlerweile habe ich auch meine Lochrasterplatine verkleinert (um 20%) - LxBxH = 21x14x11,5 - Lüa incl. Steckkontakte 28,2 - und mit getrenntem GND für LED und Receiver versehen - so ist sie für die Testphase universeller. Da bei konkreten Anwendungen ein Stecker nicht dranmuss, können dann dieser und nochmal 10 % Lochreihen vermieden werden.

...............https://dl.dropbox.com/s/7ppqkinw2gx6a5a/irDME_1466.jpg?dl=0
Ein wesentlicher Grund für das neue Platinchen waren die Schaltungsbeispiele in den doc´s. Beim Vergleich beider Platinen konnte ich feststellen, dass die Peripherie recht unkritisch ist. In der kleinen Platine, im Bild oben, habe ich jetzt einen (klein geratenen) 100 µF, und den SIG-GND-Widerstand, der in den doc´s gezeigt ist! 47k sind hoffentlich >10k :). Die Ergebnisse sind nicht erkennbar besser, aber offensichtlich keinesfalls schlechter als früher mit der "asuro-like" Peripherie.

Wichtig erscheint mir folgendes Zwischenergebnis: "eure" OCR-Werte gehen ja von FE runter, meine gehen von 1 hoch! Und wenn ich das testweise vergleiche, stelle ich fest, dass bei meiner Fahrweise ein ziemlich gut abgestufter Nahbereich existiert, während die LED-Anregung von "oben herunter" offenbar im Fernbereich Vorteile bietet. Das muss ich noch ein bisschen besser untermauern. Und irgendwann werde ich aus diesen - schon eher spielerischen Variationen - eine konkrete Entfernungsmessung machen.

Meine gegenwärtige Reflektorfläche ist die verfügbarste, die ich kenne: die Hand. Ich hätte keinerlei Problem, das wirklich prädestinierte Normteil dafür zu nehmen - die Graukarte (Wozu ne gute Nikon, wenn die ohne Graukarte ist :)). Aber wer bitte kauft sich so ein Teil? Ich weiss nicht, ob es Graukarten über DINA5 gibt. Das würde bei der SFH415 (17° Öffnungswinkel) zwar bis über 400 mm reichen, aber der 5110 hat ein deutlich breiteres Gesichtsfeld, sodass sie von der Größe her für unsere Zwecke einfach zu klein wird (ok ok ok, die meisten Hände sind kleiner). Da die Albedo der Graukarte eben auch eher untypisch für die Praxis ist, habe ich sie ausdrücklich NICHT genommen. Wir könnten uns aber vielleicht drauf einigen, dass wir die verschiedenen Spielarten farbloser Papiertaschentücher nehmen. Obwohl die von Farbe und Albedo eben auch nicht typisch sind.

PS: mit ".. Schnittstelle des asuro" bin ich natürlich mittlerweile OT geraten, ist das noch akzeptabel?

[radbruch]

ist das noch akzeptabel?
Klar, ist interessantes OT

[oberallgeier]

... Wahrscheinlich ist die Angabe '2theta½: 55 °' eher zuständig. Aber damit kann ich rein gar nix anfangen ...Ohhh . :-k Na ja, ich bin da auch etwas durcheinander, weder kenne ich alle Datenblätter, noch habe ich Lust zu viele zu sammeln.

Mit θ wird ja allgemein auch der Polarwinkel benannt. Die General Application Note for SFH511X schreibt auf Seite 4:
In x-direction (horizontal, landscape) the half angle is bigger, even at 55° the transmission distance is still at 70% of it’s on axis figure ...
Nun haben ja manche englisch sprechende Wesen nix am Hut mit Azimut oder so, aber die Linse des 511x ist ja oval und landscape-weise länger als in "y-direction (vertical, portrait)". Daher denke ich, das ist ein Hinweis auf die Größe des Erfassungswinkels. Damit wäre der SFH5110 als IR-Empfänger in Unterhaltungselektronik gut, aber mit der SFH415 für UNSERE Zwecke schlecht abgestimmt. Durcheinander bin ich blos, weil unterschiedlich zur Gen App Note der Infineon/Osram flyer diesen Winkel mit φ benennt, z.B. "Vertical Directivity φy". Ok, viel Unklares über Unklares.

[Sternthaler]

Ok, viel Unklares über Unklares.
Na dann wollen wir doch die Datenblätter vergessen und uns wieder dem OT zuwenden.
Ach nee, im Moment interessiert mich eher, wie du dein komplettes Testprogramm gebaut hast. Wenn du hier davon sprichst, dass du die OCR-Werte bei 1 beginnen lässt, dann muss deine Signalauswertung ja 'umgedreht' arbeiten. (Männchen machen, wenn das Hindernis gerade nicht mehr gesehen wird.)
Ich hatte bei meinen Versuchen sehr schnell festgestellt, dass die Reichweite irgendwo bei 0xFE-60 schon über 2 Metern beträgt. Soll heißen, wenn ich bis 0xFE-253, zu deiner 1 kommend, messen würde, dann hätte ich eine, bestimmt nur theoretische, Reichweite von fast 8 Metern.
Ich hatte so für mich entschieden, dass ich mit dem Wert 0xFE-32, und damit erkennbaren Hindernissen in ca. 1,2 Metern, zufrieden bin. (Bis zu 2 Meter habe ich erfolgreich ausgetestete.)

Irgendwie habe ich im Ohr, dass du nur eine Reichweite von ca. 40 cm schaffst.
Kannst du mich aufklären, ob das so stimmt, und was dann vor allem bei dir ein "Fernbereich" ist, bei dem du von "oben herunter" Vorteile siehst.
Diesen Aspekt, Nah- und Fernsensor, finde ich recht spannend.

Gruß Sternthaler

@radbruch
Wie schaffst du es immer, dich so kurz und präzise auszudrücken? ;-) Ich kann das irgendwie nicht :-(

[oberallgeier]

Hallo Sternthaler, ok, ich geh mal drüber, brauche aber mindestens bis morgen.

[robo.fr]

Das Entscheidende an dem ganzen Aufbau ist, dass der Sender und der Empfänger ziemlich lichtdicht voneinander abgeschirmt sind. Das war im ersten Bild nicht der Fall. Beim 2ten Bild mit dem Schrumpfschlauch wäre die Frage, ob der Boden der IR-Sendediode zuviel Licht nach hinten abstrahlt.

Ach ja, ein kleiner Wermutstropfen bei dieser Art der Abstandsmessung gibt es: Die Empfindlichkeit des IR-Empfängers ist auch vom Umgebungslicht abhängig. Je nach eingeschalteter Umgebungsbeleuchtung wird der Detektionsabstand verändert.
Ausserdem vermute ich, dass die einzelnen SF5110 große Toleranzen haben. Beim Zusammenbau eines ASURO ging die Programmierung so schlecht, dass der SFH5110 ausgetauscht werden musste. Danach lief die Programmierung einwandfrei. Die Dantenübertragung bei der Programmierung nutzt den SFH5110 auch ausserhalb der Spezifikation.
Gruß,
robo

[oberallgeier]

hallo robo.fr,

korrekte Abschirmung setze ich als unabdingbar voraus. Hatte ich bereits beim asuro-Aufbau (http://oberallgeier.ob.funpic.de/asuro-torp.jpg). Das muss natürlich auch gesichert sein, klar.

[robo.fr]

Aber nicht vergessen: etwas Licht wird bei LED's auch nach hinten abgestrahlt ...

[M1.R]

Hallo,

wo ist der Denkfehler?

Mit diesem Programm wollte ich 3 verschiedene Abstände in Abhängigkeit von den distance-werten ermitteln. Aber irgendwie beeinflussen sich meine 3 Messungen gegenseitig.
siehe Kommentare im Quellcode:

//------------------------------------------------------------------
//ir_abstand_test
//------------------------------------------------------------------

#include "asuro.h"

/************************************************** ***********************

uint8_t objekt_sichtbar(uint8_t abstand)

return: TRUE falls Objekt gefunden
FALSE wenn nicht

Zeitbedarf: 5ms

author: robo.fr, christoph ( ät ) roboterclub-freiburg.de
date: 2008

************************************************** ***********************/
uint8_t objekt_sichtbar(uint8_t distance)
{
uint16_t j,z;

DDRD |= (1 << DDD1); // Port D1 als Ausgang
PORTD &= ~(1 << PD1); // PD1 auf LOW

OCR2 = 254-distance; // wenn OCR2=0xFE dann Objekt sehr nahe
z=0;
for(j=0;j<30;j++) // loop time: 5ms
{
if (PIND & (1 << PD0))z++;
Sleep(6); // 6*Sleep(6)=1ms
}
if (z>=29) return FALSE; // Objekt nicht gefunden
else return TRUE;
}


//------------------------------------------------------------------
//hauptprogramm

int main(void)
{
/*
// abstandsmessung weisses papier :
#define test_weit 10 // 70 cm
#define test_mittel 5 // 45 cm
#define test_nah 0 // 25 cm
*/

/*
#define test_weit 20 // 140 cm
#define test_mittel 5 // 70 cm
#define test_nah 0 // 30 cm
*/


#define test_weit 0 // 8 cm
#define test_mittel 0 // 8 cm
#define test_nah 0 // 8 cm


Init();
StatusLED(OFF);

while(1)
{
if (objekt_sichtbar(test_weit) == 1)
{
StatusLED(GREEN);
FrontLED(OFF);
Msleep (200);
}

if (objekt_sichtbar(test_mittel) == 1)
{
StatusLED(YELLOW);
FrontLED(OFF);
Msleep (200);
}

if (objekt_sichtbar(test_nah) == 1)
{
StatusLED(RED);
FrontLED(OFF);
Msleep (200);
}

StatusLED(OFF);
FrontLED(ON);
}
while (1);
return 0;
}

Kann mir jemand von euch weiterhelfen?

Gruss
M.

[damaltor]

hast du die led evtl vergessen wieder abzuschalten? wie merkst du dass die messungen sich beeinflussen?

[M1.R]

hast du die led evtl vergessen wieder abzuschalten?welche LED warum abschalten?

wie merkst du dass die messungen sich beeinflussen?ich versuchs nochmal zu erläutern:
ich mache 3 Messungen hintereinander mit verschiedenen distance-Werten: test_weit, test_mittel, test_nah. (OCR2 = 254-distance)
Dann messe ich die Entfernungen zwischen ASURO und einem weißen Blatt Papier bei den verschiedenen Farben in denen die StatusLED beginnt aufzuleuchten. Ich nähere mich von weit (StatusLED aus) bis die StatusLED grün blinkt, messe den Abstand für test_weit, gehe näher ran, bis sie grün-gelb blinkt, messe test_mittel, noch näher bis sie in allen 3 Farben blinkt und messe test_nah.

Meine gemessenen Entfernungen betragen für diese distance-Werte:

test_weit 10 // 70 cm
test_mittel 5 // 45 cm
test_nah 0 // 25 cm

und für diese:

test_weit 20 // 140 cm
test_mittel 5 // 70 cm
test_nah 0 // 30 cm

und für diese:

test_weit 0 // 8 cm
test_mittel 0 // 8 cm
test_nah 0 // 8 cm

man sieht also, dass sich bei verschiedenen Kombinationen auch bei den selben distance-Werten unterschiedliche Entfernungen ergeben.

Das Problem in der Praxis ist folgendes:
Der ASURO soll ein Objekt in einer einstellbaren Maximalentfernung finden, und dann feststellen, wenn er ganz nah (max. 10 cm) herangefahren ist.
Das funktioniert nun eben nicht bei größeren Maximalentfernungen.

Gruss
M.

[damaltor]

hab was verlesen, vergiss das mit der led...

du testest im moment nur 3 verschiedene distanzen. evtl solltest du die auflösung erhöhen. du hast 3 leds (back links, back rechts, status) zur verfügung, damit kannst du binär schonmal von null bis 8 zählen und kannst die auflösung der messungen erhöhen.

[robo.fr]

Einen Gegenstand in sehr großen Entfernungen mit dem Sesnor detektieren zu wollen, ist eher ungeeignet.
Weinn ein weises Blatt Papier in 1,4m Entfernung detektiert, wird eine weise Wand wahrscheinlich in 5 m Entfernung detektiert. So viel Platz ist in kleineren Räumen normalerweise nicht.
Das Verfahren funktioniert nur einigermaßen zuverlässig für Distanzen bis ca. 50cm. Sonst läuft man Gefahr, das man irgendwelche großen Gegenstände weiter weg erkennt.

Gruß,
robo

[M1.R]

Einen Gegenstand in sehr großen Entfernungen mit dem Sesnor detektieren zu wollen, ist eher ungeeignet.
aber warum bleibt die Entfernung beim distance-Wert 0 nicht gleich? Sie ist bei meinem Testprogramm abhängig von dem vorher gemessenen größerem distance-Wert.
Gruss
M.

[M1.R]

Hallo,

jetzt habe ich mein Problemchen mal auf das Entscheidende reduziert:

Wenn ich nur den nahen Abstand (distance=0) messe,
erhalte ich eine andere Entfernung ( 8 cm)


#define weit 10
#define nah 0
uint8_t objekt_nah, objekt_weit;

while(1)
{
//wird nicht gemessen: objekt_weit = objekt_sichtbar(weit);
objekt_nah = objekt_sichtbar(nah);

if (objekt_nah == 1)
StatusLED(RED);

else
StatusLED(OFF);
}
als wenn ich vorher noch die Messung mit distance=10 durchführe, dann sinds nämlich fast 40 cm und das ist ja Quatsch!!


while(1)
{
objekt_weit = objekt_sichtbar(weit); //wird gemessen !!!!!
objekt_nah = objekt_sichtbar(nah);

if (objekt_nah == 1)
StatusLED(RED);

else
StatusLED(OFF);
}
Gruss
M.

[robo.fr]

Mir fallen dazu 2 mögliche Usachen ein:
1. Bei den Experimenten herschen nicht immer die gleichen Bedingungen ( Abstand nicht gleich, Beleuchtungsverhältnisse nicht gleich )
2. Der IR-Empfänger hat eine AGC eingebaut ( AGC= automatic gain control, automatische Verstärkungsregelung ). Die Verstärkungsregelung passt sich mit der Zeit an die veränderten Lichtbedingungen an. Wenn man also zuerst ein Messung mit sehr hellem Licht durchführt, ist der Sensor bei einer darauffolgenden Messung mit sehr dunklem Licht quasi blind. Das ist so, wie wenn wir in die Sonne schauen und dann in einem dunklen Zimmer etwas sehen will. Unser Auge ist kurzzeitig unempfindlicher.

Was das Verhalten der Messung vielleicht ändern könnte:

PORTD |= (1 << PD1); // PD1 auf High

am Ende der Abstandsmessroutine setzen, um die Sendediode auszuschalten, damit die nächste Messung nicht beeinflußt wird.

Gruß,
robo

[M1.R]

Hallo robo,

ja - er hat eine AGC. Jetzt klappts mit LED auschalten und anschließendem Warten von 1ms. :)

Vielen Dank!
Gruss
M.

[damaltor]

dann hatte ich ja doch gar nicht soo unrechtmit dem abschalten der LED =)

[oberallgeier]

Hallo sternthaler.

Es gibt einen Zwischenbericht, aber eher keinen Zwischenstand und leider noch kein wirkliches Zwischenergebnis.

Ein Punkt kommt mir wichtig vor. Einmal schreibt das Datenblatt 2000-01-01 für den 5110 auf Seite 3 unten: Die volle Empfindlichkeit wird bei einer Burstlänge von mindestens 6 Pulsen erreicht. Und das Datenblatt General Application Note for SFH511X (January 30, 2002) sagt auf Seite 1, rechts unten: To improve the SNR (signal to noise ratio) further the filter has a certain time constant. This will make sure, that only light bursts with more than 4 pulses/bit are being detected.

Fazit1: ich muss für eine saubere Messung erst einmal abwarten, bis die PWM den eingegebenen Sollwert angefahren hat. Dann wird es einen Puls dauern, bis der Empfänger das gerafft hat. Und dann sind wohl noch weitere vier bis sechs abzuwarten.

Fazit2: Jetzt muss ich ein bisschen sparsam mit der Zeit umgehen. Immerhin brauche ich für eine komplette Entfernungsbestimmung mindestens 6, besser 7 Iterationen. Mit je sechs Pulsen mindestens :( :(!! Das sind schlappe 50 x 28 µs, insgesamt also 1,4 ms - für eine komplette Messung. Viel zu viel. Das geht nur experimentell zu optimieren. Die sieben Iterationen stammen aus einer einfachen Rechnung. Ich fahre derzeit mit einer phasenrichtigen PWM mit ICR1 = 265 (37,7kHz/26,5µs) -vereinfacht sind das 256 :). Da habe ich bis zur Mitte 128 (die beiden Enden der PWM verhalten sich ziemlich identisch - leider hatte ich das früher nicht richtig gesehen). Also step 1: 128. Das ist 2^7. Also - sieben Schritte.

Immerhin stelle ich fest, dass ich mit meiner derzeitigen Ausrüstung doch locker über 1,5 m Distanz komme. Das hatte ich aber noch nicht mit dem hier skizzierten Verfahren gemessen, sondern mit wesentlich längeren Messzyklen. Ausserdem scheint es ziemlich sicher, dass die Abweichung der "optimalen" Frequenz zu einer feineren Unterteilung im Nahbereich führt. Derzeit kenne ich aber auch noch nicht die Unterschiede bei unterschiedlicher Beleuchtung. Es ist ein dämlich langer Weg.

[oberallgeier]

Die erste Textfassung ging gründlich daneben - mitten im Bericht - Noteinsatz

Mehrere Dinge habe ich bei meinen Tests mit der Sensorplatine (siehe posting vom 12.Feb.) mittlerweile festgestellt. Einschränkend muss ich sagen, dass diese Ergebnisse (vorerst) nur mit ein und demselben Satz 415/5110 gefahren wurden, ich werde (vielleicht) später meine restlichen Bausteine unter meinen Standardbedingungen testen und dann auch weitere, übliche Flächen anstrahlen. Vermutlich werde ich vorrangig noch eine "Dauer-irLeuchte" anbauen, um die deutliche Funktion der AGC zu beeinflussen und zu stabileren Ergebnissen bei unterschiedlichen Bedingungen zu kommen.

Die Geschichte hatte meine dünnen C-Kenntnisse bloßgestellt - und es war wirklich recht Cäh. Vermutlich, nein: sicherlich, ist der Code, der erschreckend kurz für die lange Programmierarbeit ist, nicht optimal. Aber es läuft recht ordentlich.

1) Übersprechen der SendeLED auf Receiver ist durch Schrumpfschlauch nicht zu verhindern
2) Übersprechen der SendeLED auf Receiver ist durch ein Messingrohr zu verhindern, es muss der LED-Fuß zusätzlich z.B: durch einen (dickwandigen) Schrumpfschlauch abgeblendet werden. Der blanke Boden der 415 stört eindeutig nicht.
3) Übersprechen der SendeLED auf Receiver ist beim Aufbau nach 2) ohne Rückenblende des Receivers abgesichert.
4) Übersprechen tritt wieder auf, wenn vor das MSRohr ein Schrumpfschlauch gezogen wird (übersteht).
5) Deutliche Unterschiede der Entfernungsmesswerte zwischen Tages- und Kunstlicht und Dunkelheit.
6) Deutliche Unterschiede der Entfernungsmesswerte je nach Messkörperabmessung und -oberfläche.
7) Es sind wohl nur Bereiche definierbar, wenn man unabhängig von Tageslicht und Oberfläche bleiben will : Nah- Mittel- und Fernbereich.
8 ) Praktisch gleiche Entfernungsmesswerte (unter sonst gleichen Bedingungen) bei PWM-Plateau von „unten“ : 1, 2 …. und „oben“ (ICR1-1, ICR1-2 …).
9) Der 5110 schaltet nur korrekt, wenn die bursts die in den Datenblättern geforderten mind. 6 Pulse aufweisen. Es ist sicherer, mit 7 Pulsen zu arbeiten. 4 Pulse führen eindeutig zu Fehlmessungen.
10) Eine erste Messung bei Tageslicht ist hier vorgestellt, es wurden jeweils ca. 15 Messpunkte für eine Distanz erfasst. Ein Messpunkt besteht aus 100 einzelnen Messungen, deren PWM-Werte für diesen Abstand dargestellt sind. Als Zielfläche diente ein Standard-Papiertaschentuch, eben auf eine Plexischeibe aufgespannt; Ziel der SFH415 war Mitte der Taschentuchs.
11) Zur Frequenz der SFH415 ein Auszug aus meinen Projektnotizen:
Grob ist festzustellen: bei Zimmerbeleuchtung „Essecke“ (alles an, Hängelampe gedimmt) ist ein guter Lauf bei 37,7 kHz festzustellen. 40 kHz gibt praktisch ab 2..3 cm nur „high“. 34 kHz ist ebenfalls recht schlecht. 36kHz ergibt einen eher gröberen Nahbereich bei ähnlichen Werten im Fernbereich wie 37,7. 37,0 kHz (mit irDME_mo1_x14-37.h; ICR1 ist 270) scheint die beste Wahl für feinen Nah- und grossen/fernen Fernbereich zu sein.
12) Die ursprünglich geplanten 6-7 Iterationen zur Bestimmung des Messwertes sind mit meinen C-Kenntnissen nicht machbar - ich musste auf ein stufenweises Hochzählen der Pulsbreite der LED-PWM zurückgreifen. Hier überlege ich noch . . . .

..................................http://oberallgeier.ob.funpic.de/ms5110-TL1.jpg

Der Code. Wie gesagt - es war für mich als C-Anfänger schwer, zum Glück hat hier niemand meine anfängliche Stöpselarbeit gesehen. Es fehlte halt an allen Enden, z.B. wie funktionierte die while()-Abfrage ... Aber ich habe ein bißchen dazugelernt.


// ================================================== ===============================
int ReDiM(void) // Relative Distanz Messung, Rückgabewert = Wert der PWM-Ansteuerung
{
uint8_t mpwm = 0; // mpwm ist der jeweis aktuelle "PWM-Stellwert" bzw. der
// endgültige Messwert
uint8_t tmp = 0; // temporärer Wert

tmp = PINB; // Test, ob ein Signal anliegt
mpwm = 1; // Sicherheitshalber PWM ganz klein
setSRV1(mpwm); // Ansteuerung der PWM auf

for(uint8_t n = 1; n <= 6; n = n + 1) //Es wird die LED auf n Pulse geprüft
// Warten, bis irLED dunkler/heller wird. Im Datenblatt des SFH5110 sind sechs Pulse
// je burst als Minimum gewünscht. Bei 36 kHz dann ca. 6*26 µs bis zum nächsten Test
{ // dies statt: // chk_irLED(); //Warte n Pulse der irLED ab
while (!(PINB & (1<<PINB1))); // Bit 1 (0..7) gelöscht? <==> irLED aus
while (PINB & (1<<PINB1)); // Prüfe, ob Bit 1 (0..7) gesetzt <==> irLED an
}

for (i = 128; i >= 2; i=i-1)
{
if (i > 6)
i = i-1;
if (i > 20)
i = i-2;
if (i > 40)
i = i-6;
mpwm = i;
setSRV1(mpwm); //PWM für irLED ansteuern

for(uint8_t n = 1; n <= 7; n = n + 1) //Es wird n Pulse lang geprüft
{ // dies statt: // chk_irLED(); //Warte n Pulse der irLED ab
while (!(PINB & (1<<PINB1))); // Bit 1 (0..7) gelöscht? <==> irLED aus
while (PINB & (1<<PINB1)); // Prüfe, ob Bit 1 (0..7) gesetzt <==> irLED an
}

tmp = PINB; //Der Empfänger müsste jetzt korrekt schalten
if (tmp & 0x08) //Bit 4 gesetzt? Input high? Freistrahl?
{ //Bit ist high = frei, PWM verstellen
break;
}
else // Bit ist low = bedämpft
{ }
}
return mpwm;
}
/* ================================================== ============================ */


/* ================================================== ============================ */
// Aufruf, z.B. aus main mit

mecho = ReDiM();

// ================================================== ==============================
Der zweimalige Aufruf dieser LED-Puls-Zähl-Zeilen wird nicht als Unterprogramm gefahren, das spart etwa 15 % der immer noch unsinnig langen Laufzeit. Die Routine braucht bei (m)einem mega168/20MHz etwa 6 ms bis ein korrekter Wert da ist - das hängt naturgemäß vom Messwert ab: hohe Messwerte brauchen drastisch weniger Zeit. Ich habe keine Ahnung, wie ich den Programmablauf in C schneller machen kann, allerdings läuft der Compiler noch mit -O0. Sicher wäre das auch eine Möglichkeit für Assembler, aber ich bin ja in die µC-Technik, bzw. embedded computing, eingestiegen, weil ich schon lange C lernen wollte.

Die Timerinitialisierung und PWM-Ansteuerung erfolgt so:

/* ================================================== ============================ */
/* == PWM-Routinen zur IRLED-ansteuerung auf OC1A/PB1 ======================= */
void TC1SRV_init(void) //Init Timer/Counter 1, PWM-Signal für Servo hin-her
{ // normale PWM aktivieren (nicht invertiert)
TCCR1A |= (1<<COM1A1); //Clear/set OC1A on Compare Match, doc S132.
// also Port PB3, vgl. auch PWM-routine unten
TCCR1B |= (1<<CS10); // cs10 <=> clk/1 => no prescaling doc S 134
TCCR1B |= (1<<WGM13); // PWM, Phase+Frequency correct doc S 134
ICR1 = 270; // =>PWM-Frequenz 20MHz/(2*nn) => 37,0kHz/
TIMSK1 &= ~(1<<OCIE1A)|(1<<OCIE1B); // Tmr/Cntr1 Oput CompA/B Mtch intrrpt disab
TIMSK1 &= ~(1<<TOIE1); // Tmr/Cntr1 Overflow interrupt disabled
}
/* ================================================== ============================ */
void setSRV1(uint16_t speed1) //Relative Pulslänge auf OC1A/PB1
{OCR1A = speed1;} // z.B. für SFH5110 oder Servo
/* ================================================== ============================ */
Für beide Abschnitte nehme ich Verbesserungen des Codes gerne an , wie gesagt ....

Variablen, die hier nicht deklariert erscheinen, sind in meiner COMMON-h enthalten. Diese ist hier nicht vorgestellt.

Nachtrag 23:28 Uhr: Diagramm aktualisiert mit "Kunstlicht"

[Sternthaler]

Hallo oberallgeier,
gerade wollte ich auf deinen ersten Beitrag antworten.
Nun macht es aber Sinn eher auf den aktuellen zu antworten.

1) Deine Auswertung, vor allem die mit dem Übersprechen auch mit Schrumpfschlauch, ist sehr hilfreich. Nun, da auch noch die Rückseite abgeschottet ist, scheint von der Seite nun kein Problem mehr zu kommen. Man muss es nur mal von dir vorgemacht bekommen.

2) Die Unterschiede zwischen Tageslicht / Kunstlicht / .. und bei unterschiedlichen Reflektoreigenschaften wurde hier ja schon vorausgesagt. Dies habe ich auch schon 'empirisch' selber nachvollziehen können/müssen. Da müsste man mal versuchen, ob man auch hier durch eine Dunkle-/Hellmessung eine Differenz ermitteln kann, an der man die Umgebungshelligkeit abschätzen kann.

3) So schlimm sieht deine Programmierkunst nun doch nicht aus. Bis auf ein paar winzig Kleinigkeiten ist das doch bestens.
In Cäh schreibt man i = i + 1; In C kann man das mit i++; abkürzen.
Das geht auch am Ende einer for (xxx; yyyy; n++)-Klammer.
In C kannst du i -= 6; schreiben, wenn du i = i - 6; meinst.
Das geht schon mal mit allen +-*/ - Zeichen: x *= 3; <=> x = x * 3;

4) Nun aber ein Problem in meinem Kopf:
Deine Konstruktion zum warten auf n Pulse will mir nicht so recht einleuchten. Ist sauber in C geschrieben, ich meine den Sinn dieser Warterei.
Du wartest mit der Schleife doch auf ein n-faches Pulsen vom Empfängersignal. Dieses Signal aber ist, so wie ich es sehe, schon vom SFH5110 am Ausgang geliefert worden. ****Hier kann mein Denkfehler sein, dass du am PINB1 nicht den Ausgang, sondern etwas anders misst****
Wenn der SFH5110 aber dein Datenlieferant ist, dann benötigst du an dieser Stelle keine Pulse mehr. So wie ich das Datenblatt interpretiere, hat sich da nämlich schon der Baustein drum gekümmert.
Als Datenblatt habe ich immer gerne die Infineon-Datenblätter, da die häufig Deutsch- und Englischsprachig sind. (Ist für mich zum üben der Deutschen äh ne, der englischen Sprache perfekt.)
Hier mal das Dingsda: SFH5110.pdf (http://www.asuro-sternthaler.de/bauteile/OptischeSensoren/SFH5110.pdf)
Unten im Bild habe ich den Ausschnitt zum Thema 6 Pulse rausgeholt.

Ich bin mir sicher, dass die Pulse nicht von der Software bearbeitet werden müssen.
Hier wird meiner Meinung nach nur mitgeteilt, dass die Bit-Länge eine gewisse Anzahl von Pulsen aufweisen muss. Und somit ergibt sich daraus die maximale Datenübertragungsrate.
Min. 6 Pulse bei 36 kHz für ein Bit sind dann irgendwelche ms oder us. Und das ist dann eben die Obergrenze der Bitgeschwindigkeit.

Ich hoffe, dass ich daneben liege, und du nicht gefrustest bist.
Auf alle Fälle hänge ich hier deine Programmstücke aber mal so dran, wie ich sie schreiben würde. Evl. hilft das beim Übergang von Cäh nach C.


/* ================================================== ====================== */
/* == PWM-Routinen zur IRLED-ansteuerung auf OC1A/PB1 ================= */


/*----------------------------------------------------------------------------
Init Timer/Counter 1, PWM-Signal für Servo hin-her
normale PWM aktivieren (nicht invertiert)
----------------------------------------------------------------------------*/
void TC1SRV_init (
void)
{
TCCR1A |= (1<<COM1A1); // Clear/set OC1A on Compare Match, doc S132.
// also Port PB3, vgl. auch PWM-routine unten
TCCR1B |= (1<<CS10); // cs10 <=> clk/1 => no prescaling doc S 134
TCCR1B |= (1<<WGM13); // PWM, Phase+Frequency correct doc S 134
ICR1 = 270; // =>PWM-Frequenz 20MHz/(2*nn) => 37,0kHz
TIMSK1 &= ~(1<<OCIE1A)|(1<<OCIE1B); // Tmr/Cntr1 Oput CompA/B Mtch intrrpt disab
TIMSK1 &= ~(1<<TOIE1); // Tmr/Cntr1 Overflow interrupt disabled
}



/*----------------------------------------------------------------------------
Relative Pulslaenge auf OC1A/PB1
----------------------------------------------------------------------------*/
void setSRV1 (
uint16_t speed1)
{
OCR1A = speed1; // z.B. für SFH5110 oder Servo
}



/*----------------------------------------------------------------------------
Relative Distanz Messung, Rückgabewert = Wert der PWM-Ansteuerung
----------------------------------------------------------------------------*/
int ReDiM (
void)
{
uint8_t mpwm = 0; // mpwm ist der jeweis aktuelle "PWM-
// Stellwert" bzw. endgueltiger Messwert
uint8_t tmp = 0; // temporaerer Wert
uint8_t n;


tmp = PINB; // Test, ob ein Signal anliegt
mpwm = 1; // Sicherheitshalber PWM ganz klein
setSRV1 (mpwm); // Ansteuerung der PWM auf

/*
Es wird die LED auf n Pulse geprueft. Warten, bis irLED dunkler/heller wird.
Im Datenblatt des SFH5110 sind sechs Pulse je burst als Minimum gewuenscht.
Bei 36 kHz dann ca. 6*26 µs bis zum naechsten Test
*/
for (n = 1; n <= 6; n++) // Warte n Pulse der irLED ab
{
while (! (PINB & (1<<PINB1))) // Bit 1 (0..7) geloescht? <==> irLED aus
;
while (PINB & (1<<PINB1)) // Bit 1 (0..7) gesetzt? <==> irLED an
;
}

for (mpwm = 128; mpwm >= 2; mpwm--)
{
if (mpwm > 6)
mpwm -= 1;
if (mpwm > 20)
mpwm -= 2;
if (mpwm > 40)
mpwm -= 6;

setSRV1 (mpwm); // PWM fuer irLED ansteuern

for (n = 1; n <= 7; n++) // Warte n Pulse der irLED ab
{
while (! (PINB & (1<<PINB1))) // Bit 1 (0..7) geloescht? <==> irLED aus
;
while (PINB & (1<<PINB1)) // Bit 1 (0..7) gesetzt? <==> irLED an
;
}

tmp = PINB; // Der Empfaenger muesste jetzt korrekt schalten
if (tmp & 0x08) // Bit 4 gesetzt? Input high? Freistrahl?
break; // Bit ist high = frei, PWM verstellen
}
return mpwm;
}



/* ================================================== ====================== */


/* ================================================== ====================== */
// Aufruf, z.B. aus main mit

mecho = ReDiM();

/* ================================================== ====================== */


Gruß Sternthaler

[oberallgeier]

Hallo Sternthaler,

schlimm, schlimm, schlimm. Da denke ich es sei ausführlich - aber danke, dass Du die missverständlichen Passagen so konstruktiv aufzeigst.


1) ... da auch noch die Rückseite abgeschottet ist, scheint von der Seite nun kein Problem mehr zu kommen ...NEIN - die Rückseite der LED ist nicht abgeschottet - aber es ist wichtig, diesen kleinen Bord vom Boden zum eigentlichen body der LED seitlich gegen Abstrahlungen abzudichten. Mein enges Messingrohr sitzt leider auf diesem Bord auf - einen grösseren Rohrinnendurchmesser wollte ich aber nicht nehmen. Dort am Boden ist die Intensität gering und es reicht eben ein Schrumpfschlauch - aber ohne dem müsste ich den 5110 abschotten. Ich verwende an dieser Stelle den dickwandigen, verschweissenden Schrumpfschlauchtyp ohne thermische Behandlung. Weder die Rückseite der LED noch irgendeine Fläche des 5110 ist abgeschottet - siehe Bild.
Nachtrag 29.2.08 22:38: Dieser Bord ist an der nackten LED im Bild im ersten Posting dieses Threads sehr gut zu erkennen.

....................................https://dl.dropbox.com/s/fu2qwfap749swlv/irDME-29feb.jpg?dl=0


2) Die Unterschiede zwischen Tageslicht / Kunstlicht / .. und bei unterschiedlichen Reflektoreigenschaften ... müsste man mal versuchen, ob man auch hier durch eine Dunkle-/Hellmessung eine Differenz ermitteln kann ...Sonne an und Sonne aus? Welcher Port am Mega168 schaltet mir die Sonne? Ernsthaft: wie messe ich die Beleuchtung (das Umgebungslicht) mit dieser Ausrüstung? Da habe ich keine Ahnung.


3)... deine Programmierkunst ... Bis auf ein paar ... Kleinigkeiten ... In Cäh schreibt man i = i + 1; In C kann man das mit i++; abkürzen ...Ja, danke, das kenne ich. Aber es gibt nur unwesentlich weniger Tastenanschläge, der Maschinencode ist derselbe und ich finde, dass die Leserlichkeit nicht verbessert wird. Genausogut könnte man das in UPN schreiben, oder, noch schlimmer, ohne Umkehrung, in PN ...


4) Nun aber ein Problem in meinem Kopf: Deine Konstruktion zum warten auf n Pulse will mir nicht so recht einleuchten. Ist sauber in C geschrieben, ich meine den Sinn dieser Warterei...Wie ich im Posting vom 22. Feb. geschrieben habe, erkennt der 5110 laut Datenblättern einen Burst erst nach ein paar Pulsen und reagiert mit einem low-Pegel am SigOUT. Wenn Du das von Dir eingestellte Bild im oberen Posting ansiehst, dann ist dort deutlich gezeigt, dass der Ausgangspegels des 5110 erst nach ein paar Pulsen auf low geht - der Transmitter rattert schon ein paarmal, bevor der Detector reagiert. Dieses feature ist ja ein Teil seiner Tages-/Fremdlicht-Unempfindlichkeit. Daher frage ich den Steuerport der irLED415 ab, und warte eine bestimmte Anzahl (Soll-) Pulse (leider ohne tatsächliche Kontrolle ob die LED an ist), bevor ich den 5110 nach seiner Meinung frage. Sorry, das hatte ich wirklich total missverständlich dargestellt. Und ich sehe in meinen Messungen deutlich: bei vier Pulsen schaltet der 5110 oder auch nicht. Total zufällig. Und bei fünf gehts ähnlich, wenn auch besser. Bei sechs ist die Schaltsicherheit gut - aber wer sagt mir, dass ich gerade am Anfang eines Pulses prüfe? Es könnte ja das Gerade-noch-an-Ende des LED-Pulses sein, daher meine sieben Pulse. Danach kann ich sicher sein, dass der 5110 mein Blinksignal durch die LED verstanden hat und entsprechend reagiert.

... Du wartest mit der Schleife doch auf ein n-faches Pulsen vom Empfängersignal ...Wie dargestellt - NICHT vom Detector - siehe auch Kommentar in meinem Code, z.B. "// Bit 1 (0..7) gelöscht? <==> irLED aus ".

Danke noch für Deine Cäh nach C - Übersetzung. Ich werde das durchgehen - bin eine Woche in den Tauern und wenn das Wetter schlecht ist oder ich eine lange Snowboardabfahrt habe, oder einen endlos langen Gleitschirmflug (Drachen bleibt in der Garage) - dann habe ich sicher Zeit zum Lesen und Lernen.

Warum sollte ich gefrustet sein? Im Gegenteil. Ich weiss ein bißchen besser Bescheid über diese ir-Geschichte mit der Entfernungsmessung mit dem asuro - oder ohne - und das war ja mein anfängliches Problem. Und vielleicht hilft diese Beschreibung anderen Kollegen weiter.

[oberallgeier]

Aber nicht vergessen: etwas Licht wird bei LED's auch nach hinten abgestrahlt ...Bei LED´s im Allgemeinen, vielleicht. Aber hier .... konnte ich weder vor Deinem Posting noch bis jetzt feststellen. Hattest Du das bei der SFH415 festgestellt? Wie?

[robo.fr]

Alle Achtung, ihr treibt die Untersuchung ja ganz schön weit. =D>


Hattest Du das bei der SFH415 festgestellt? Wie?
Es ist mehr eine Annahme. Früher habe ich einige Versuche mit LED's mit sichtbarem Licht gemacht.
Ich kann das Experimt mit einer ultrahhellen LED im Schrumpfschlauch empfehlen, das kann man richtig sehen, wo das Licht überall durchkommt. Auch interessant wäre, ob das Platinenmaterial das IR-Licht eventuell etwas durchläst.

Gruß,
robo

[oberallgeier]

Hallo robo.fr,

na ja, ich hatte schon sehr früh festgestellt, dass der von mir verwendete, ca. 1 mm dicke Schrumpfschlauch für die IR-Strahlung der SFH415 recht gut durchlässig ist. Erst mit dem Metallröhrchen wurde die Abschottung sehr gut - und erst mit dem bedeckten "Boden"bordring der LED sah ich über die gesamte Ansteuerungsrampe der LED keinerlei Übersprechen der LED auf den Detector - eine perfekte Strahlendichtheit, sicher auch wegen des elastischen Innenbelags des verschweißbaren Schrumpfschlauchs. Allenfalls ist diese Aussage so einzugrenzen: die durchgelassene Reststrahlung ist bei meiner vorgestellten Konstruktion unterhalb der Nachweisgrenze für den von mir verwendeten 5110 :). Da brauche ich mich um die Strahlendurchlässigkeit von relativ gut durchscheinendem Platinenmaterial (im sichtbaren Wellenbereich) nicht zu kümmern - das ist sicherlich IR-durchlässig. Meine Tests mit dem Schrumpfschlauch ÜBER dem Metallrohr - und über dessen vorderes Ende überstehend - zeigen ja auch so eine Art Lampioneffekt - der Schlauch strahlt so, dass der 5110 sich recht beeindruckt zeigt.

[Sternthaler]

Hallo oberallgeier,
oh je, dann fehlte mir also tatsächlich nur das genaue lesen und interpretieren deines Kommentars im Code: "Es wird die LED auf n Pulse geprüft"
Jedenfalls war ich schon auf dem Dampfer dies so zu interpretieren. ;-)

Nun also mit Volldampf zur Iteration.
Hier erst einmal nur die Idee dies zu realisieren.

Deine Hauptschleife läuft von 128 an abwärts. Wenn wir hier noch eins abziehen, dann kommen wir auf ein Bitmuster von "0111 1111".
Wenn wir nun in 7 Iterationen fertig sein wollen, brauchen wir somit nur die 7 1-en 'irgendwie' zu bearbeiten.
Um, wie es sich gehört, bei der ersten Iteration anzufangen, muss der zu prüfende Wert in der Mitte vom kompletten Bereich (127) liegen.
Bei unserem bisherigen Bitmuster reicht es also, die höchste, gerade zu bearbeitende, Bitstelle auf 0 zu setzen um den Bereich zu halbieren.
Dieses Bitmuster ist nun genau das, was wir für den zu iterierenden PWM-Wert benötigen.

Iteration 7-0:
- Schiebe ein Bit um 7-0 Stellen nach links
- Lösche an dieser Stelle aus dem aktuellen Bitmuster/PWM-Wert das Bit
- Ergibt Bitmuster/PWM-Wert "0011 1111"
- Messen
- Ergebnis: Hindernis (zu weit gemessen)
--- Lasse Iterations-Bit wie es ist ===> Fall 7-0.0
- Ergebnis: Kein Hindernis (zu kurz gemessen)
--- Setze Iterations-Bit wieder auf 1 ===> Fall 7-0.1

Iteration 7-1:
Fall 7-0.0
- Schiebe ein Bit um 7-1 Stellen nach links
- Lösche an dieser Stelle aus dem aktuellen Bitmuster/PWM-Wert das Bit
- Ergibt Bitmuster/PWM-Wert "0001 1111"
- Messen
- Ergebnis: Hindernis (zu weit gemessen)
--- Lasse Iterations-Bit wie es ist ===> Fall 7-1.0.0
- Ergebnis: Kein Hindernis (zu kurz gemessen)
--- Setze Iterations-Bit wieder auf 1 ===> Fall 7-1.0.1

Fall 7-0.1
- Schiebe ein Bit um 7-1 Stellen nach links
- Lösche an dieser Stelle aus dem aktuellen Bitmuster/PWM-Wert das Bit
- Ergibt Bitmuster/PWM-Wert "0101 1111"
- Messen
- Ergebnis: Hindernis (zu weit gemessen)
--- Lasse Iterations-Bit wie es ist ===> Fall 7-1.1.0
- Ergebnis: Kein Hindernis (zu kurz gemessen)
--- Setze Iterations-Bit wieder auf 1 ===> Fall 7-1.1.1


Und schon können wir über die 7 zu bearbeitenden Bits loopen. (Vornehm sagen wir nun iterieren.)
Klar, für "Iteration 7-x" machen wir eine for()-Schleife mit "for (n = 7; n > 0; n--)"
Damit haben wir im Zähler n dann den Schiebewert um uns eine Bit-Maske zu basteln: Bit-Maske = (1<<n)
Und nun noch das Bit-Masken-Bit im Bitmuster/PWM-Wert löschen mit: Bitmuster/PWM-Wert &= ~Bit-Maske
Wenn wir bei "Ergebnis: Hindernis .." nun das Bit wieder setzen sollen, nutzen wir wieder die Bit-Maske um die 1 an der richtigen Stelle im Bitmuster/PWM-Wert wieder einzutragen. Bitmuster/PWM-Wert |= Bit-Maske

Eine Besonderheit gibt es noch.
Die übliche Extremwertbetrachtung kann uns zu einem Bitmuster/PWM-Wert von "0000 0000" bringen.
Hier musst du überlegen, ob es a) zulässig ist, und b) wie man diese Situation sonst abfängt.

That's all.

Cäh in C-Wandlung die 2.te:
Bei der Bitmanipulation wird nun auch mit dem Bit-bezogenem & (and) und dem Bit-bezogenem | (or) eine Kombination bei der Zuweisung mit dem = gemacht. Geht hier somit auch, und wird in C immer wieder gerne genutzt.
Zu der Kurzform n++ kommt noch die Form ++n hinzu. Unterschied? Bei n++ wird 'hinterher', bei ++n 'vorher' an n manipuliert. Lustig wird es damit bei Dingen wie einem Funktionsaufruf á la "TuWas (n++);" oder eben "TuWas (++n);"

Und nun noch ein bisschen smalltalk: Ich wünsche dir/euch? viel Spaß, guten Schnee und angenehmen Aufwind für den Tauern-Aufenthalt. Lass den Schlapptop zu Hause und brich dir nicht die Knochen.

P.S.:Wenn du beim Umsetzen in C Kummer haben solltes, kann bestimmt geholfen werden.


@robo.fr
Da kann man mal sehen, was so alles aus der Kombination waste-IR-Decoder und US-Cirp und Erweiterungsplatine an Arbeit entstehen kann. Irgendwie hatte ich es im Blut, als ich mich doch erst geziert hatte deine Erweiterungsplatine zu nutzen. Das hat man nun davon ;-) Nur gut, dass oberallgeier hier die ganze Arbeit macht!

Gruß Sternthaler

Da fällt mit noch ein, dass ich etwas zur Sonne schreiben wollte.
Genormt ist der Pin 3 am Port B laut CCG. Im Moment sind da wohl einige abgeschaltet. Zumindest auf der Nordhalbkugel.
Um aber Sonne an und aus zu simulieren, könnte es doch ausreichen, eine Messung mit ganz großer Lichtleistung zu machen und eine Messung mit reduziertem Licht. Irgendwo wird sich bestimmt ein Reflektor finden. Eine Messung sind dann natürlich wieder ein paar 100 Bits die jeweiles gezählt werden. Wenn nun die gezählten Hell-/Dunkelmessungen irgendwie in ein Verhältnis gesetzt werden können, wäre das eventuell die Lösung.

Nun aber Schluß

[oberallgeier]

Nach einer längeren Pause wollte ich meinen Ausflug in die Entwicklung eines preisgünstigen DME auf Infrarotbasis vorerst einmal abschließen. Offen war für mich die Möglichkeit der feineren Auflösung im Nahbereich und die Abstandsmessusng zu verschiedenen Werkstoffen und Körperformen.

Die Werkstoffuntersuchung zeigte naturgemäß deutliche Abweichungen gegenüber meinem Standard mit Papiertaschentuch. Insbes. Glas ergab einen teilweise fünfmal höheren PWM-Wert - hier ist die Spielwiese so riesig, dass ich die Messungen nicht mehr systematisch weitergeführt hatte. Gleiches gilt auch für schräge Flächen - hier zeigt z. B. mein Standardobjekt bei 45° Schrägstellung etwa eine Verdoppelung der Messwerte. Ähnlich weit ist natürlich die Spielwiese für Gegenstände unterschiedlich flächiger Ausbreitung. Der Öffnungswinkel der SFH415 ist +/- 17° - entsprechend werden dünne Gegenstände schlecht erkannt. Da ich bei den noch offenen Fragen bin: (noch) nicht gemessen habe ich die Eingangsempfindlichkeit des SFH5110 in vertikaler und horizontaler Richtung - hier verlasse ich mich (vorerst) auf das Datenblatt. => Es nützt bei mir nichts, die PWM NACH dem chirpen wieder auszuschalten – dadurch werden die Ergebnisse bei meinen Messungen NICHT stabiler.

Für die Abstimmung der Empfindlichkeit gibt es eine (vermutlich für viele hier) fast triviale Möglichkeit, die Auflösung des Messverfahrens im Nahbereich deutlich feiner zu machen. Dazu hatte ich zum bestehenden Vorschaltwiderstand der irLED von 330R einen zweiten mit 1k in Reihe geschaltet. Die Ergebnisse sind im nachstehenden Diagramm zusammengefaßt.

..................................https://dl.dropbox.com/s/cmhwlqkn428vme8/irDME-1k33.jpg?dl=0

Interessanterweise liegen nun die Messungen für nicht zu helles Kunstlicht und die für helles Tageslicht gut übereinander. Zur besseren Vergleichbarkeit der Ergebnisse habe ich die neuen Messwerte (grün und blau) in das Diagramm aus dem Posting vom 28 Feb 2008 (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=355675#355675) (mit den roten und schwarzen Werten) eingefügt.

Die erste Messung mit dem größeren Vorschaltwiderstand (E-Ecke, Kunstlicht bei Dämmerung) ergibt eine gute Auflösung im Nahbereich – etwa ab 2 cm, steigend grob gerechnet mit etwas über 1 PWM-Wert pro cm bis rund 30 cm Abstand. Vergleich: die Messung mit 330R ergibt bei einem bestimmten Abstand einen stabilen Wert 1 (PWM-Ansteuerung) während in der gleichen Messfahrt – nur durch Zuschalten des 1k – der PWM-Wert 6..9 erzielt wird.

Bei Fragen stehe ich natürlich gern zur Verfügung.

Ich vermute, dass diese Schaltung zur Entfernungsmessung im Bereich von 2-3 cm bis etwa 50 cm mit einem Ul traschalls ensor gut mithalten kann. Ich werde es sowohl als Absturzsicherung bzw. Stolperkantenerkennung im Nahbereich als auch für die gröbere Gegenstandserkennung im Bereich bis einen halben Meter einsetzen. Die Feinmessung übernimmt dann bei Bedarf ein Sharp.

[Sternthaler]

Da kommt schon die erste Frage ;-)

Hallo oberallgeier,
wenn du im Nahbereich doch auf den Sharp umschalten möchtest, dann frage ich mich jetzt, warum du den IR-Messbereich durch den weiteren Vorwiderstand künstlich reduziert hast? Oder ist das jetzt nur als 'Nebenprodukt' deiner Untersuchungen zu sehen?

Interessant ist es auf alle Fälle, da durch deine Messreihen und der hier erklärten Auswertung derselben, es nun logisch erscheint aus deinem Festwiderstand einen Trimmer zu machen.
So ergibt sich dann nun die Möglichkeit eine 'genormte' Messkurve auch bei mehreren Asuros/Coladosen einzustellen.
In etwa mit dem Ziel: "1-PWM-Wert pro cm" bei Normreflektor. (Wie stellst du eigentlich ein Papiertaschentuch senkrecht auf?)

Gruß Sternthaler

P.S.: Iteration eingebaut? Code zum posten vorhanden?

[oberallgeier]

... im Nahbereich doch auf den Sharp umschalten ?Ich mache in der ersten Ausbaustufe (noch ohne Slave) Folgendes:
Von meinem Gefährt schauen drei ir´s von "oben" etwa in Blindenstock-Manier nach unten - linke, mittlere und rechte Blindenstock-Position - bei mir rund 100 mm vor dem Gefährt (Achsmitte). Dabei ist das erkannte Feld des irDME´s auf Fahrebene von der gleichen Breite wie das Gefährt. Abstand ca. 160 mm - daher brauche ich in diesem Bereich eine gute Auflösung.

..................................https://dl.dropbox.com/s/acfavneq5rrymzl/tast_1-3.jpg?dl=0

Zeigt einer der 3 Sensoren etwas Verdächtiges UND es wird dabei eng, dann sollte mithilfe des Sharp eine genauere Untersuchung der Umgebung erfolgen (so stell ich mir das in meiner Blauäugigkeit vor) - ansonsten reichen die Informationen der drei ir´s um eine Umleitung zu planen - oder um einen Absturz zu verhindern.


... Möglichkeit eine 'genormte' Messkurve ... einzustellen.Stimmt - Gleiche Fläche im gleichen Abstand wird jetzt gleichen Messwert(bereich) ergeben - damit wird die Abtasterei nicht ganz so "blind" im Sinne von zufällig - denn die wirklich Blinden könnten extrem genau abtasten. (Nachtrag:) Allerdings "strahlt" der asuro ja mit voller Power - R16 = 220R - denn er ist ja auf Datenaustausch und nicht auf Abstandsmessen optimiert. Andererseits - wenn ich die gewünschten 6 Pulse Minimum für einem Burst = ein Bit rechne, kommt mir die gewünschte Datenrate etwas hoch gegriffen vor.

Die Sache mit dem Papiertaschentuch. Erste Möglichkeit wäre die traditionelle Wäscheleine-Klammer-Version, die aber wegen ihrer Instabilität abzulehnen ist. Meine Variante wurde mit einer PMMA-Platte und vier Streifen Tesa etc. realisiert.

..................................https://dl.dropbox.com/s/o378b1gp17hs5uo/ptt-steht.jpg?dl=0


P.S.: Iteration eingebaut?NOCH schlimmer - die Messungen habe ich langweilig und zeitraubend, aber eben gut aufgelöst durchgeführt :
for (mpwm = 128; mpwm >= 1; mpwm--) //Chirpen von 128 abwärts
an einer optimalen Interpolation hänge ich noch (die ist aber nicht so hoch priorisiert). Dann kommt auch noch ein Nachtrag mit Code. Aber die anderen Änderungen sollten Dir gefallen:
// ================================================== ===============================
// Aktuell erfolgt die Messung "von oben herunter"
int ReDiM(void) // Relative Distanz Messung, Rückgabewert = PWM-Ansteuerung
{
uint8_t mpwm = 0; // der "PWM-Stellwert" = gültiger Messwert;
uint8_t tmp = 0; // temporärer Wert
uint8_t n = 0; // Zählvariable bei Pulszählung

/* Es wird die LED auf n Pulse geprüft. Warten, bis irLED dunkler/heller wird.
Im Datenblatt des SFH5110 sind sechs Pulse je burst als Minimum gewünscht.
Bei 36 kHz dann ca. 6*26 µs bis zum jeweils nächsten Test */

for (n = 1; n <= 6; n++) //Warte n Pulse der irLED ab
{ // dies statt: // chk_irLED();
while (!(PINB & (1<<PINB1))); // Bit 1 (0..7) gelöscht? <==> irLED aus
while (PINB & (1<<PINB1)); // Bit 1 (0..7) gesetzt ? <==> irLED an
}

for (mpwm = 128; mpwm >= 1; mpwm--) //Chirpen von 128 abwärts
{
setSRV1(mpwm); //PWM für irLED ansteuern

for(n = 1; n <= 6; n++) //Warte n Pulse der irLED ab
{
while (!(PINB & (1<<PINB1))); // Bit 1 (0..7) gelöscht? <==> irLED aus
while (PINB & (1<<PINB1)); // Bit 1 (0..7) gesetzt ? <==> irLED an
}
tmp = PINC; //Der Empfänger müsste jetzt korrekt schalten
if (tmp & 0x01) //Bit 1 gesetzt? PINC0? Input high? Freistrahl?
break; //Bit ist low = frei, PWM verstellen
}

return mpwm;

}
// ================================================== ===============================
NochnpaarNachträge: Mein irDME (das aber vielmehr ein forum-basiertes DME ist) kostet einen Bruchteil vom Sharp - und macht weniger EMV-Probleme. Dieses irDME ist kompakter als der Sharp - zumal ich am Messgeräte-Ort nur die beiden SFH´s anbringen will - der Rest ist auf der Platine. Mein irDME hat eine gewisse Ausdehnung des erkennbaren Feldes - der Sharp hat theoretisch nur einen Punkt. ABER der Sharp wäre natürlich für eine "Eichmessung" zusammen mit einer in die gleiche Richtung messenden SFH415/5110-Kombination zu verwenden - dann wüsste ich auch was über das Maß der Sonneneinstrahlung.

[Sternthaler]

Upps, ich stelle gerade fest, dass ich hier wohl vor ein paar Nächten vergessen hatte auf 'Absenden' zu drücken.
Jetzt aber nun hurtig im (Sternthaler-untypischen) Telegrammstil:

- Blindenstock-Version:
Tolle mechanische/technische/mathematische Idee

- Änderungen sollten Dir gefallen
Ja. Nur eine Frage: Warum wartest du vor der for()-Schleife auch die 6 Pulse ab? Was habe ich diesmal übersehen?

- gewünschte Datenrate etwas hoch gegriffen
Hier kann ich nicht folgen. Welche Datenrate?

- Papiertaschentuch
Plexiglas! Bööh, ist das banal. Aber wofür dann noch die rote Wäscheklammer unten links im Bild ;-)? Sind die Sterne zum zielen notwendig, oder nur Dekoration? Und noch ein: :P

- Iteration
Geht ja auch ohne.

- Eichmessung
Super, super Ansatz.

Gruß Sternthaler

[oberallgeier]

Hallo Sternthaler,

Upps, ich stelle gerade fest, dass ich hier wohl vor ein paar Nächten vergessen hatte auf 'Absenden' zu drücken ...Kein Problem. Ich bin gerade dabei, (m)eine Platine für die erste Version (m)eines Einachsroboters zu bearbeitenbearbeitenbearbeiten - erstmal nur master, no slave.


- Blindenstock-Version:
Tolle mechanische/technische/mathematische Idee
Höre ich da Spott heraus?


Warum wartest du vor der for()-Schleife auch die 6 Pulse ab?
Stimmt, das war mal sinnig, ist aber jetzt überflüssig. Das stammt aus der Zeit, als ich in die eigentliche Routine mit einer Messung "in Messbereichsmitte" angefangen hatte, um von dort aus weiterzuiterieren. Sorry, dass Du wegen meiner unsauberen Arbeit Zeit mit Nach-Denken verplempert hast.


- gewünschte Datenrate etwas hoch gegriffen
Hier kann ich nicht folgen. Welche Datenrate?
Der asuro soll sich ja mit dem Transceiver mit 2k4 Baud unterhalten. Bei 36 kHz ist ein Puls 27,7 µs, nach 6 Pulsen geht der 5110 SICHER auf low ( --- siehe Datenblatt!!) => wären also 166 µs für ein Bit.
Verlangt wird von der Richtfunkstrecke 2400 Baud => ca. 417 µs pro Byte. 8n1 sind grob gerechnet 10 Bit pro Byte => ca. 42 µs pro Bit. Beim asuro wird also davon ausgegangen, dass der 5110 bereits nach knapp zwei ! ! Pulsen auf low geht - das mag vielleicht bei direkter ir-Einstrahlung gelten - aber für (meine) Reflexionsmessung und laut Datenblattspezifikation stimmts nun wirklich nicht. Ganz abgesehen davon, dass das asuro-Protokoll auch noch Rückmeldefunktionen hat. Aber das ist alles rein theoretisch gerechnet - ich habe dazu keinerlei Messungen gemacht so nach dem Motto: wann geht der 5110 bei direkter IR-Bestrahlung wirklich und sicher auf low. Aber ich denke, dass er auch beim spezifizierten 50%-Tastverhältnis nicht viel früher schaltet als bei der Entfernungsmesserei nach waste.


Plexiglas! Bööh, ist das banal.
Banal - ist oft ideal. Ist im normalen Leben so ne Art Kniebrett für mobile Aufschriebe (oder auf dem Sofa).
Die rote Wäscheklammer heißt in der Elektrotechnik Krokodilklemme (Hirschmann-Krokoklemme 4mm, rot) und dient dazu, die Plexiglasplatte mit ihrem "Fuß" - einer stern-übersäten Geschenkschachtel (weihnachtliche Sternmotive) - zu verbinden. Diese Schachtel dient mir im Normalfall als Utensilo für allerlei elektronische Kleinteile. Die Sterne sind Zierde - nicht Zielhilfen.


- Iteration
Geht ja auch ohne.
Na ja, ich werde daran arbeiten, weil es doch bei geschickter Iteration - beginnend von der Messbereichsmitte - fast doppelt so schnell gehen wird. Aber da muss man mal "aufwärts" prüfen (PWM-Wert nimmt zu) und mal "abwärts". Und im Moment habe ich eben andere Prioritäten.


- Eichmessung
Super, super Ansatz.
Danke für das Lob. Ja, ich hoffe schon, dass hier ein passabler Ansatz vorliegt. Aber auch das steht auf meiner Warteliste leider nicht ganz oben.

Nun hoffe ich, dass meine Platine bald etwas aufgeräumter wird (die Leitungsführung sieht im Moment total murksig (http://oberallgeier.ob.funpic.de/m168D-x50.jpg) aus :() - aber ich willkann eben keine geätzte nehmen. Und dann kommt irgendwann (nach dem WFC10) der Komplettaufbau soft- und hardwaremässig. Wenn die Thermik- (oder Motorrad-) saison nicht zu schön wird . . . .

[Sternthaler]

Hallo oberallgeier,
ich hoffe, dass ich auf 'Absenden' drücken werde.


Höre ich da Spott heraus?
Definitiv nicht.
Das gilt natürlich nur dann, wenn es so geplant war, dass der Boden-Durchmesser des Mess-Lichtkegels der Roboterbreite entsprechen soll.
Wenn es nicht geplant war, dann ist es halt erst ab jetzt eine tolle Idee so vorzugehen. Und das meine ich tatsächlich sehr ernst!



... 2400 Baud => ca. 417 µs pro Byte. ...
Rechenfehler bei dir oder bei mir? Ich kommen auf ca. 4167 µs pro Byte.
1 / 2400 pro Bit * 10 für Start-/Stop- + 8 Datenbits
So komme ich auf (1 / 36000) / (1 / 2400) = 15 Pulse pro Bit.


Dieser Absatz kann nun unter dem Begriff OT einsortiert werden:
Ja, das mit dem Papiertaschentuch kann bestimmt auch ganz kompliziert gelöst werden. Im Orient gab es mal eine Technik zum Aufrichten von Schlangen über Sound. Ob da schon MP3-Flöten genutzt wurden ist mir allerdings nicht bekannt. Wahrscheinlich wäre das auch keine ideale Variante für das Tuch. Eventuell das indische Tuch nehmen?
Hhhmmmm?. Den Begriff Silo kenne ich aus der Lagertechnik. Utensilo? Da muss ich ein bisschen googeln.





- Iteration
Geht ja auch ohne.
Na ja, ich werde daran arbeiten, weil es doch bei geschickter Iteration - beginnend von der Messbereichsmitte - fast doppelt so schnell gehen wird. Aber da muss man mal "aufwärts" prüfen (PWM-Wert nimmt zu) und mal "abwärts". Und im Moment habe ich eben andere Prioritäten.
Fast doppelt so schnell?
Im Nahbereich würde ich von wesentlich schneller sprechen.
Beim Iterieren bist du immer in 7 Schritten fertig. In der Schleife musst du dich erst von 128 'runterarbeiten' auf sagen wir mal 15 Einheiten. Somit benötigst du dann ein paar Schritte mehr.


Und dann hätten wir noch die Lobesorgie.
- Du hast die Frage in den Raum geworfen.
- Du hast einen Lösungsansatz für das Sonnenproblem gefunden.
Ich bin unbeteiligt.
Ist nur dein Verdienst und Lob.


Und noch etwas OT:
Wenn die Motorradsaison beginnt solltest du aufpassen das du nicht zum Monowheelfahrer wirst. Ist bestimmt nur mit Übung und entsprechender Reglung halbwegs ungefährlich. ;-)


Noch ein sonniges Restwochenende
wünscht allen und vor allem dir oberallgeier
der Sternthaler

[oberallgeier]

Hallo Sternthaler,

... Spott ... nicht ... wenn ... Roboterbreite entsprechen soll ...An den strichlierten Linien in der Handskizze kann man meine graphischen Überlegungen dazu erkennen. Klartext: das ist so geplant.



... 2400 Baud => ca. 417 µs pro Byte. ...
Rechenfehler bei dir oder bei mir? Ich kommen auf ca. 4167 µs pro Byte.
1 / 2400 pro Bit * 10 für Start-/Stop- + 8 Datenbits
So komme ich auf (1 / 36000) / (1 / 2400) = 15 Pulse pro Bit.
Sagen wir mal so - ein Anfänger-Denkfehler. 2400 Baud hatte ich gerechnet als 2400 Byte /sec *brrrrrrrrrrr*. Bitte wieder aufhören zu Lachen. Danke.


Fast doppelt so schnell?
Im Nahbereich würde ich von wesentlich schneller sprechen.
Stimmt - aber ich habe noch weitere Optimierungsabsichten und schätze die erhofften Vorteile lieber niedrig ein. Da ich bei Realisierung der Iteration mit dem letzten PWM(i)-Wert beginnen werde, dürfte es deutlich schneller werden. (Anm.: i ... Index des i-ten irDME´s). Du weißt ja, dass mir die schrittweise Annäherung an den Messwert schon anfangs ziemlich doof lang vorkam.

Danke für das Lob. Aber ohne Deine konstruktive Kritik wär die Arbeit wohl nur halb so gründlich geworden. Ach so - ja - die Werkstofffrage ist doch deutlich wichtiger als ich dachte: das Papiertaschentuch in Konkurrenz zum grauen Standard-Ordner-Rückseite (= 4te Umschlagseite, gebraucht) gibt in einem orientierenden Versuch nur ein Viertel des Wertes . . . . . Da müsste ich doch noch mal was an Messungen und Informationen nachlegen. Später mal . . . .


MonoWheel - tja, mein Motorradguru hatte auf meine Frage "wie taste ich mich an einen Wheely ran..." neben Anderem geantwortet: "... das machst Du am Besten so, Du fährst mit in die Wüste ..." Leider ging sich das letztes Jahr bei ihm nicht mehr aus in die Sahara - mal sehen, was dieses Jahr draus wird... und Wheely wär ja schon mal ein Anfang fürs MonoWheel-Fahren ....

[damaltor]

dieser thread ist ausgesprochen lustig zu lesen... da wird der tag gleich wieder shcön =)


wie siehts eigentlich mit wirklich unebenen flächen aus? gibts da erfahrungen die ich übersehen habe oder soll zuerst das glatte, weihnachtliche tascheintuch erkannt werden bevor wir auf eine österliche rauhfasertapete umsteigen?

[oberallgeier]

... ausgesprochen lustig zu lesen... da wird der tag gleich wieder shcön =) Als einer der Hauptverdächtigen bedanke ich mich für dieses Lob (hmmm, wie geht bei so etwas die Seele auf ...). Und hoffe, dass wir nicht nur Lustigkeit herüberbringen.


wie siehts eigentlich mit wirklich unebenen flächen aus? gibts da erfahrungen die ich übersehen habe oder soll zuerst das glatte, weihnachtliche tascheintuch erkannt werden bevor wir auf eine österliche rauhfasertapete umsteigen?Also "Tapeten" könnte für einige hier ein Reizwort sein (ich lasse solche Arbeiten auch lieber outgesourcet machen).

Das Papiertaschentuch hatte ich aus mehreren Gründen gewählt.
1) Die universelle Verfügbarkeit in hoffentlich gut vergleichbarer Qualität. Das ist aber eine Vermutung.
2) Die diffuse Reflexion der Oberfläche - vermutet, nicht gemessen.
3) Die mäßige Eindringtiefe für IR in das mehrschichtige, dünn-gefaserte Papier - vermutet, nicht gemessen. Verbunden damit vermutete ich im Papiertaschentuch auch eine sehr gute Absorption.
4) Die Messwerte sind eher "gut", d.h. für eine feine Auflösung im Nahbereich muss ich einiges Gehirnschmalz aufwenden. Das ist für meinen eigentlichen Anwendungsfall wichtig.

Einige eher orientierende Messungen an einer weißen Rauhputz-Wohnzimmerdecke (sehr grob) und der ebenso weißen Wohnzimmerwand mit rustikalem Streichputz (glatt, etwas stufig, mäßig rauh) ergeben ähnliche Werte wie das PTT. Messungen an Glas (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=363708#363708) (mehrkantig, 33cl) ergaben bis zu fünfmal höhere PWM-Werte, offenbar geht viel Licht durch Reflexion verloren. Dieser Einfluss der Reflexion schräger Flächen (sozusagen der Übergang zur Diffusion und damit zu der von Dir nachgefragten wirklich rauhen Oberfläche) ist markant: das PPT erfordert bei 45°-Anstrahlung (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=363708#363708) bereits doppelte PWM-Werte für das Signal bei gleichem Abstand. Die dunkelgraue Oberfläche eines Büroordners ergab auch rund vier mal höhere PWM-Werte (beim gleichen Abstand) wie das PTT - hier ist sicher die geringe Albedo schuld. Noch nicht gemessen hatte ich lasierte Eiche (kommt im Wohnbereich häufig vor) und andere Werkstoffe. Das wollte ich verschieben, bis mein erster "Versuchsträger" fertig ist - weil die simultane Erfassung der Signale von mehreren Sensoren, sozusagen im Alltagsbetrieb, doch auch Unterschiede ergeben wird.

Hauptsächliches Untersuchungsziel von mir war ja auch eher der preisgünstige Ersatz von US-Sensoren bei vergleichbarem Erfassungswinkel und einem eher betonten Nahbereich.

Wenn ich mit meinem Einachsroboter fertig bin und damit Erfahrungen vorliegen, kann ich gerne wieder berichten. Derzeit sehe ich das Vorhaben auf einem gewissen, wenn auch vorläufigen, Endstand - da soll mal die Sache ruhen und reifen...

[oberallgeier]

Nun bin ich über etwas Unschönes gestolpert.

Für meine Messungen hatte ich als "Standardoberfläche" ein Papiertaschentuch genommen, das auf einer PMMA-Platte weitgehend eben fixiert war. Dieser Aufbau schien mir problemgerecht und sicher. Yoghurtbecher - bzw. Material vergleichbarer Oberfläche - kamen mir wegen des Durchscheinens nicht so pfiffig vor, eine Standard-Graukarte hatte ich wegen des hohen Preises (vielleicht will jemand im Forum die Messungen nachfahren) nicht verwendet.

Diese Wpche hatte ich bei einer Tagung die Gelegenheit einen Wissenschaftler zu sprechen, der sich mit Papierphysik und ausserdem mit Messtechnik zum Thema Papier beschäftigt. Messtechnik ist dabei weniger Prozess-Messtechnik im herkömmlichen Sinn, sondern speziell abgestimmt auf Papier, also auf Qualitätsbeurteilung und -sicherung über den gesamten Produktionsprozess des Papieres. Den Menschen hätte ich früher fragen sollen.

Die von mir verwendete Standardfläche sieht er nicht sinnvoll für meine Messaufgabe. Tissuequalitäten - also diese fasrigen Papiere ohne viel Bindematerial und vor allem ohne Füllstoffe - sind ziemlich durchscheinend. Insbesondere wird nach seiner Aussage durch EIN Papiertaschentuch eine Menge Licht durchgehen. Das ist bei meinem Aufbau schlecht, weil das durchscheindende Licht von der PMMA-Platte zumindest teilweise reflektiert wurde und z.B. bei schräger Anmessung des Objektes die Richtungsabhängigkeit schwerer wiegt.

Der Wissenschaftler schlug mir als Messobjekt Folgendes vor: einmal den "unendlichen Block" - also einen Papiertaschentuch-Stapel, der so hoch/dick ist, dass alles Licht, bis auf das diffus gestreute bzw. reflektierte, in diesem Stapel bleibt. Na ja, klingt ein bisschen nach viel Aufwand, da sind einige Zentimeter Papiertaschentücher fällig - - DICKE, nicht Kantenlänge!! Alternativ gibt es die Möglichkeit, z.B. mehrere Blatt (3..5) übliches 80g-Kopierpapier (holzschlifffrei!) unter/hinter das Papiertaschentuch zu legen und so diesen unendlichen Block zu simulieren. Schließlich gäbe es noch die Möglichkeit, die paar Blatt Kopierpapier selbst als Meßfläche zu nehmen - eine Möglichkeit, die ich wegen der relativ glatten, wenig diffusen Oberfläche des Kopierpapieres nicht mag - dem hatte mein Gesprächspartner zugestimmt.

Ich habe daher noch ein paar orientierende Messungen wie beschrieben (PTT auf 5 Blatt Kopierpapier) nachgelegt und gefunden, dass wirklich die Messwerte erheblich geringer sind bei gleichem Abstand mit dem PTT auf der Kunststoffplatte, eine Bestätigung dafür, dass mit dem korrigierten Aufbau mehr Licht reflektiert wird.

Warum schreibe ich das: Der von mir vorgestellte Messaufbau ist deswegen schlecht, weil meine Messungen nicht einfach nachvollziebar sein dürften. Ich werde trotzdem keine neuen Messungen vorlegen. Ich meine, dass die Ergebnisse doch ein gewisser Fortschritt sind. Die Reproduzierbarkeit hat eher wissenschaftlichen Wert hat: im Normalfall misst man doch andere Oberflächen und es ging mir eingangs (nur) um eine Vergleichbarkeit an verschiedenen, unabhängigen Messorten. Da ich selber immer mit dem gleichen Aufbau gemessen hatte, sind aber meine Ergebnisse trotzdem im Rahmen meiner Möglichkeiten homogen.

[damaltor]

Ich muss sagen, das hätte ich wirklich nicht so erwartet. ich dachte eigentlich dass gerade durch das diffuse des PTT (auf der bemerkenswert weihnachtlichen befestigung) das diese reflexionen der Platte dahinter ausgeschlossen werden...

wie erheblich geringer ist denn erheblich geringer? halb so groß? ein viertel? oder immer 10 digits weniger?
kann man das als halbwegs propotional ansehen, oder ist nur ein gewisser offset festzustellen?

[oberallgeier]

Hallo damaltor,


... wie erheblich geringer ist denn erheblich geringer? ...Völlig richtig diese Frage. Ich hatte den beschriebenen Einwand gehört und daheim sofort eine Kontrollmessung gemacht - mit der genannten ungenügenden Vergleichbarkeit.

Das (mein) Problem mit der IR-Abstandsmessung hat sich ja zu meinem Ärger etwas verselbständigt - es geht mir aber einfach auf den Keks, dass so wirre Ergebnisse da sind. Ich hatte ebenfalls wie Du vermutet, dass die Reflexion durch das PTT zurück (oder die Transmission durch PTT und Träger) verschwindend gering ist. Die genannten Messungen zeigten aber mehrfach hörere Abstände bei gleicher Rampenbreite (PWM-Ansteuerung). Einen tragfesten Vergleich hatte ich aus Zeitnot (oder - ich war einfach sauer) nicht gefahren.

Diese Woche bin ich auf einem Kongress mit völlig anderer Thematik und werde erst wieder anfangs nächster Woche aktiv werden. Der IR-Abstandsmess-Frage werde ich danach weiter nachgehen, aber nicht mit erster Priorität. Bitte um Verständnis. Was mich ja mittlerweile interessiert ist, ob eine sehr preisgünstige Standard-Reflexionsfläche verfügbar oder einfach beschaffbar ist. Dies wäre für andere Messverfahren möglicherweise von Vorteil.

[Sternthaler]

Hallo Kongressteilnehmer und natürlich auch alle anderen.

@oberallgeier
Du schriebst, dass du das Abstand wahren im Moment nicht als erste Prio siehst. Deshalb hatte ich mich mal daran gemacht dem IR-Licht zumindest Softwareseitig auf die Sprünge zu helfen.

Im Anhang habe ich das Ergebnis beigelegt.
Im übrigen habe ich das ganze CIR getauft. Soll Chirpende IR-messung heißen.

- Gemessen wird kontinuierlich im Hintergrund über den Timerinterrupt.
---> Keine zeitkritischen Funktionen im Hauptprogramm.
---> Kontinuierliche Entfernungsinformation vorhanden.

- Die Messung wird mit der oben angegebenen Iterationsmethode gemacht.
---> Über ein define einstellbare Bitanzahl für das Ergebnis.
---> Konstante Zeit zum Ermitteln der Entfernung.
---> Die Messzeit ist somit unabhängig von der Entfernung.

- CIR kann über Funktionen gestartet und gestoppt werden.
---> Während CIR läuft, funktioniert die IR-Datenübertragung nicht.
---> Nach dem Stoppen vom CIR können Daten wieder übertragen werden.

- CIR kann mit 4 Defines in cir.h konfiguriert werden.
---> Ausführliche Beschreibung in der Datei
-----> Anzahl Pulse am IR-Sender (Pflicht bei der Harware)
-----> Anzahl Iterationen pro Messung (Bitanzahl für das Nettoergebnis)
-----> Anzahl Messungen bei ungeänderter Lichtleistung (Messgenauigkeit)
-----> Anzahl Messwerte, die als 'Ausrutscher' betrachtet werden. (Messfehler)

---- Funktionen:
====> CirIsr()
Muss vom Timerinterrupt SIGNAL (SIG_OVERFLOW2) in asuro.c aufgerufen werden.
====> CirStart()
Start der Messungen. Datenübertragung ist tot
====> CirStop()
Na was wohl.
====> unsigned char variable = CirRead()
Hiermit holt das Hauptprogramm den Nettoentfernungswert.


Wichtiger Hinweis zum test.c main()-Teil. (Beschreibung im Source)
In der Asuro-LIB Version 2.80 kann eine Funktion in den Timerinterrupt 'eingehängt' werden. Dann ist es nicht mehr nötig die Lib zu editieren und neu zu übersetzten.
Wenn noch eine alte Lib bzw. der Source von der CD benutzt wird, wird in test.c beschrieben was zu tun ist.


Zu meinen mit dem Testprogramm erfolgten Messungen:
- Ohne mehrfache Messung bei gleicher Lichtleistung ist kein vernünftiges Ergebnis zu erwarten. Unterhalb von 5 Wiederholungen ist die Wiederholgenauigkeit einer Messung eher zufällig.
- Nur bis zu einer gewissen Anzahl an Wiederholungen mit gleicher Lichtleistung wird das Messergebnis besser. Ab ca. 30 Wiederholungen ist keine Verbesserung mehr zu finden.
- Sowohl im Nahbereich bis 10 cm, als auch ab ca. 100 cm ist der Messfehler relativ hoch.

Die Messgeschwindigkeit mit den aktuell in cir.h angegeben Werten beträgt 10 ms. ---> Das sind 100 Messungen pro Sekunde. Bei vollem Speed vom Asuro mit ca. 50 cm/Sekunde ist also ein Entfernungswert alle 5 mm vorhanden. Diese Genauigkeit liefert das CIR-System absolut nicht.

So, genug erzählt. Probiert es aus oder lasst es sein ;-)
Gruß Sternthaler

[oberallgeier]

Hallo Sternthaler, hallo alle,

nicht als erste Prio siehstNa ja, ich hinke mit meinem Projekt schon Monate hinterher . . . .

Deshalb hatte ich mich mal daran gemacht dem IR-Licht zumindest Softwareseitig auf die Sprünge zu helfen.Ohhhh - sehr schöne Überraschung nach einem schönen, langen Wochenende an einem sonnigen Montag Morgen.

Lieber Asuro programieren als arbeiten gehen.Dein umfangreiches Posting lässt mich Einiges fürchten, du wirst das aber hoffentlich nicht wahr gemacht haben? Was soll sonst mit meiner Rente geschehen . . . ?
Zurück zu topics. Sehr schön. Die *c und die *h sehen ja so aus, als könnte ich sie direkt (bis auf meine Verdreifachung) verwenden. Trotzdem werde ich noch bei "mir" weitermachen: die Mechanik steht bis auf den Kopf-mit-Sensoren-wackel-Servo, die Teile sind alle da - und danach kann ich sehen, wie das Ganze mit der bei mir gedämpften SFH415 (1k Vorschaltwiderstand) und der geänderten 5110-Installation funktioniert. Auf meiner Experimentierplatine ging´s so ja feinfühliger. Also doch noch etliche Tage - abzüglich dieses Montags (es ist einfach Flugwetter....).

[Sternthaler]

Hallo Flieger,
nein, es kommt kein Spruch wie vom Nachwuchs ;-)

Schöner Ausschnitt aus deinem Projekt.
Zeigt natürlich, dass meine Lösung hier nur im Prinzip für dich in Frage kommen könnte.
Ich habe den Source 'natürlich' nur aus Sicht des Asuros geschrieben. Es sollte aber nicht allzu schlimm sein da aufzusetzen. Falls überhaupt 'fremder' Source genutzt werden will von dir.

By the way:
Die cir.c und cir.h sind so geschrieben, dass sie direkt in die Asuro-LIB eingebaut werden können.
Da muss ich aber noch mit m.a.r.v.i.n sprechen, da ich eigentlich die cir.h in der asuro.h oder teilweise in der myasuro.h unterbringen möchte.

Muss nun weiterarbeiten um deine Rente zu finanzieren ;-)

Gruß Sternthaler

[oberallgeier]

Lieber Sternthaler,

heute kann ich Dir mal einen Zwischenbericht geben über neueste Studien meinerseits zur IR-Schnittstelle und zu deren Verwendung als irDME.

In den letzten Wochen war ich angestrengt beschäftigt mit einer Tatsache, von der ich annehme, dass sie eine grossartige, neue Säule unseres physikalischen Wissens bilden wird. In naturphilosophische Überlegungen hatte ich - ausgehend von Newtons lex tertia

..................................http://upload.wikimedia.org/wikipedia/commons/5/5d/Newtons_laws_in_latin.jpg

- einen Weg gesucht, wie ich zu einer Entsprechung bei Fragen zur Energie kommen könnte. Nun liegt ja schon von Einstein die herrliche Formulierung des Bezugs zwischen Energie und Masse vor. Dieses einsteinsche Postulat der Äquivalenz zweier so unterschiedlicher, physikalischer Größen wie Masse und Energie hatte meine Überlegungen in eine sehr erfolgreiche Richtung gebracht. Meine Entdeckung ist nun, dass ich ja aus beiden Gesetzen die Wechselwirkung von auslösender Erhaltungsgröße und beeinflusster Erhaltungsgröße ableiten kann - vulgo actio gleich reactio. Diese fundamentale Entdeckung, der zulässigen Erweiterung von Newtons Postulat, werde ich umgehend in den Annalen der Physik (http://de.wikipedia.org/wiki/Annalen_der_Physik) der Fachwelt vorstellen und hoffe, dass meine "Zweite Oberallgäuer Vermutung" - "2 OV" (es liest sich also NICHT ZOV - mit einem "z" zwei "f") - in der nächsten Zeit die angesprochene Säule unseres physikalischen Denkens werden wird. Nebenbei darf ich Dir anvertrauen, dass ich damit meine Habilitation oder gar eine unmittelbare Berufung auf einen namhaften Lehrstuhl in greifbare Nähe gerückt sehe.

Cui bono, wirst Du fragen. Klar.

Du hattest mich mit Deiner Bemerkung: "... 2) Die Unterschiede zwischen Tageslicht / Kunstlicht / ... " (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=355944#355944) ja schon auf die richtige Fährte (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=355976#355976) gebracht:
"... Sonne an und Sonne aus? Welcher Port ... schaltet mir die Sonne? ..." Leider hatte ich Deine kryptische oder sybillische Erläuterung: (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=356174#356174) "... etwas zur Sonne schreiben ... Genormt ist ... Pin 3 am Port B laut CCG. Im Moment sind da wohl einige abgeschaltet. Zumindest auf der Nordhalbkugel ..." nicht wirklich verstanden. Ich hoffe, dass ich aber nun, unabhängig davon, das Problem gelöst habe.

Weiter mit cui bono. Der von mir entdeckte Effekt beruht also darauf, dass die Reaktion unseres "Beobachters" - der SFH415 - auf das Aus- und Einschalten der Sonne - das so ja nicht problemlos, zumindest nicht in überschaubaren Zeiträumen - möglich ist, ersetzt wird durch das Aus- und Einschalten der SFH415. Aus meinen in den Annalen der Physik demnächst theoretisch begründetem Ansatz geht hervor, dass die Wirkung in beiden Fällen die gleiche ist - sein muss. Und sag selbst: ist das nicht ein ganz wunderbarer Gedanke, dass mein Schaltvorgang an eine LED dasselbe bewirkt, als würde ich die Sonne an- und wieder ausknipsen!

Instinktiv ist dies schon mal von jemandem vermutet worden (http://www.reaktivlicht.de/kochbuch.pdf) - der sich aber über die Tragweite der Tatsache nicht im Klaren war. Auf Seite 3 von dessen Schrift wird ein Prinzip der "Lichtmessung" - es handelt sich dabei offensichtlich um eine Messung der Beleuchtungsstärke - beschrieben, das GENAU meiner neuen, physikalischen Theorie entspricht. Hintergrund seiner Ausarbeitung ist es, die Entladekurve der Kapazität einer "aufgeladenen" LED zu messen, und aus dem zeitlichen Verlauf des Spannungsabfalls während des Entladens auf die Beleuchtungsstärke zu schliessen, da die Entladung mit unterschiedlich starker Beleuchtung der LED unterschiedlich schnell vor sich geht.

Ich hatte natürlich sofort diesen Aufbau nachvollzogen und war von der Schlichtheit und Klarheit des Experiments verblüfft. Irgendwie erinnert es mich an den Arbeitstisch von Otto Hahn ...

..................................https://dl.dropbox.com/s/k0iq0za6qw6qdus/pb3-pb4.jpg?dl=0

Mittlerweile habe ich umfangreiche Messungen gemacht mit einer Schaltung, die am mega168 ziemlich genau der Schaltung der SFH415 am asuro entspricht (na ja, zwei parallele 470R ergeben fast 220R) und die Beleuchtungsstärke durch die Entladungsgeschwindigkeit der LED-Kapazität gemessen. Am Oszilloskop hatte ich bei Auflösung in Microsekunden auch schön die Entladekurve gesehen (x = 0,5 µs/DIV).

..................................https://dl.dropbox.com/s/obekracj90wcxa4/oszi.jpg?dl=0

Leider musste ich (derzeit?) feststellen, dass diese Entladekurve darstellbar ist sowohl mit als auch ohne LED. Für meine Experimente verwendete ich einmal die irLED SFH415 und dazu auch eine "rote" 250 mcd von Lite-on (http://www.csd-electronics.de/data/pdf/LTL-1CHKxKNN.pdf) . Abgesehen nun davon, dass mir bei der Entladekurve nun der endgültige Beweis für den ursächlichen Zusammenhang zwischen dem Aus- und wieder-Anschalten der Sonne, sorry, der LED und dem Spannungsverlauf am µC fehlt, ist der beobachtete Spannungsabfall im Bereich von rund 0,1 µs zwar für meinen mit 20 MHz getakteten m168 noch "im limit" - aber real würde ein solcher Messvorgang doch Problem bringen. Schade. Ich arbeite daran.

Allerdings ist nun, zumindest vorerst, eine entsprechende Messung der Beleuchtungsstärke mit dem asuro und seiner SFH415 wohl nicht möglich und meine hervorragende Entdeckung ist für unsere beabsichtigte Eichung der Abstandsmesseinrichtung beim asuro nicht erfolgversprechend. Schade. Wirklich schade.

[robo.fr]

Tja, so ist das halt: Nur hochpräzise Meßtechnik ermöglciht die Entdeckung neuer physikalischer Effekte.
Da geht's Dir nicht anders wie den anderen? Physikern.

robo

[Sternthaler]

Hallo Newton,

da bleibt dann nur eins übrig:
Sibylle zu ihrer Schwester Pythia zurückschicken und auf Seite 4 vom Dokument des 'anderen Vermuters' zu blättern.
Die dort vorgestellt primitive Variante, die Umgebungshelligkeit mit einem LDR zu messen, entspricht zwar nicht den hohen Ansprüchen eines Anwärters auf einen namhaften Lehrstuhl, kann aber zur Not eben diesem 'anderen Vermuter', bei einem Fehlschlag des Experiments, in die Schuhe geschoben werden. Somit wär der Ruf des namenhaften Lehrstuhls auch niemals gefährdet.

Schade, dass diese Lösung erst im I-Net zu finden ist. Was wäre wohl gewesen, wenn diese Aufgabestellung, Entfernungsmessung für Kleinroboter, schon vor 200 Jahren diskutiert worden wäre. Die hätten ja niemals eine Lösung finden können, da es da ja kein I-Net gab ;-).

Sonst bleibt aber immer noch die Möglichkeit offen, dass man eine Linse über einer Zündschnur anbringt; an der CPU ein Micro anschliesst; und wenn es knallt, dann hat zu viel Umgebungshelligkeit die Ladung entflammt. Ein kleiner Roboterarm legt für eine weitere Messung eine neue chemische Ladung nach.
Somit kann man umgehen, dass physikalische Effekte neu entdeckt werden müssen. Das entspricht dann einer Transformation in den chemischen Lösungsraum.

Ich hoffe das liest keiner.
Gruß Sternthaler

[robo.fr]

Hallo zusammnen,


Mittlerweile habe ich umfangreiche Messungen gemacht mit einer Schaltung, die am mega168 ziemlich genau der Schaltung der SFH415 am asuro entspricht (na ja, zwei parallele 470R ergeben fast 220R) und die Beleuchtungsstärke durch die Entladungsgeschwindigkeit der LED-Kapazität gemessen.

was mir gerade noch beim Experiment auffällt: Die paar Elektronen, die bei Lichteinfall schneller durch die Potentialbarriere diffundieren, erfordern einen ziemlich großen Entladewiderstand ( in der Frößenordnung MegaOhm ) damit man einen messbaren Effekt erhält.

Gruß,
robo

[oberallgeier]

Hallo robo,

genau - allerdings hatte ich eben bei dieser Geschichte (mit Blick auf den asuro bzw. auf die Verwendbarkeit bei ihm) die asuro-Bestückung bzw. seinen Schaltplan zugrundegelegt.

[damaltor]

Sonst bleibt aber immer noch die Möglichkeit offen, dass man eine Linse über einer Zündschnur anbringt; an der CPU ein Micro anschliesst; und wenn es knallt, dann hat zu viel Umgebungshelligkeit die Ladung entflammt. Ein kleiner Roboterarm legt für eine weitere Messung eine neue chemische Ladung nach.
Somit kann man umgehen, dass physikalische Effekte neu entdeckt werden müssen. Das entspricht dann einer Transformation in den chemischen Lösungsraum.

oder man nimmt eine spraydose, und wartet ob diese explodiert... ich erinnere mich da an einen kürzlich geschlossenen thread XD

[oberallgeier]

Hi damaltor,
nun hoffe ich aber [-o< , dass dieser zündende Gedanke :Strahl von Sternthaler nicht dazu führt, dass dieser Thread wegen allgemeiner Personengefährdung geschlossen wird #-o . Obwohl die Kommunikationstechnologien gerade in diesen Tagen ihre Brisanz zeigen. Aber die IR-Schnittstelle ist zum Glück nicht geeignet, personenbezogene Daten auszuspähen . . .

[Sternthaler]

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

[oberallgeier]

Hallo Sternthaler,


... meine Lösung hier nur im Prinzip für dich in Frage kommen könnte ... sollte aber nicht allzu schlimm sein da aufzusetzen. Falls überhaupt 'fremder' Source genutzt werden will von dir. ...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 gemacht ;-). 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.


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

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.

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.

[Sternthaler]

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 ;-) (Wii langweilig)
Wurden bei 8 Bft schon Tüten verteilt, oder ist der Weg über die Reling die Lösung? Bis 6 halte ich nur durch.

[oberallgeier]

Hallo Sternthaler,


... Um weniger Messwerte zu erhalten, könntest du 3 Varianten bedenken: ...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:

/* ================================================== ============================ */
/* === 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
*/
. . . . .damit kam ich gestern schon auf 2 % - eher weniger :). Die PWM will ich nicht mehr ändern, das scheint ein guter Wert zu sein, vgl. auch den entsprechenden Thread. (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=345401#345401)


... ist es tatsächlich etwas merkwürdig, dass die Werte so pendeln. ... => Code posten ist wohl angesagt ...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).


... hübscher Farbton für das OT. ... trägt das nicht sehr stark auf? ...Trägt auf, stimmt schon - aber ich hab jetzt eine hübsche Version gefunden: blau und doch nicht blau - gut gell?


... P.S: in Blau: ... Fock anstatt des Genua ... Wurden bei 8 Bft schon Tüten verteilt ...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 ...

[Sternthaler]

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

[oberallgeier]

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"):
/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)

Hier noch die Schaltung (https://www.roboternetz.de/phpBB2/files/m168d-schaltung-x97.pdf) (es gibt ein paar wenige Änderungen+Ergänzungen darin, die aber nicht von Bedeutung sind.

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 (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=353905#353905). 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 (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=385277#385277) 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 (https://www.roboternetz.de/phpBB2/files/m168d-schaltung-x97.pdf)) 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):

..........................https://dl.dropbox.com/s/3yy9hv0u7kj8c2m/ohC%2BmC100nF.jpg?dl=0http://oberallgeier.ob.funpic.de/ohC+mC100nF.jpg (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=385343#385343)

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.

[Sternthaler]

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 :-k.

Gruß Sternthaler

[oberallgeier]

... Glückwunsch ... mach dich an die "Blindenstock-Funktion". Was auch immer man sich da nun wieder drunter vorstellen muss :-k .
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 (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=388755#388755)gekriegt ](*,) - also wirds ein lang(weilig)es Wochenende.

[oberallgeier]

Hallo Ihr IR - Abstandsmesser


... Das Entscheidende an dem ganzen Aufbau ist, dass der Sender und der Empfänger ziemlich lichtdicht voneinander abgeschirmt sind. ...
Aber nicht vergessen: etwas Licht wird bei LED's auch nach hinten abgestrahlt ...
... Ich kann das Experimt mit einer ultrahhellen LED im Schrumpfschlauch empfehlen, das kann man richtig sehen, wo das Licht überall durchkommt. Auch interessant wäre, ob das Platinenmaterial das IR-Licht eventuell etwas durchläst. ...
robo.fr - vielen Dank für Deine nützlichen Fragen und Einwände. Manche Ergebnisse lassen auf sich warten. Es gab etliche Steine auf dem Weg . . . waren aber grösstenteils selbst hingeworfen :(.

Nun ist es "amtlich". Die Ergebnisse beruhen auf verschiedenen Beobachtungen beim Aufbau von drei Abstandssensoren der hier beschriebenen Bauart, die bei meinem R2D03 (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=388981#388981) von oben chirpend auf den Weg blicken und auf Hindernisse oder Fallgruben achten. Es sind drei irDME´s : 12, 3 und 4 : 12=nach vorne, 3=45°links und 4=45°rechts. Abwärtsneigung 50° gegen die Waagrechte. In dieser Stellung wird die Situation "vor" dem Döschen im Winkel +/- 60° recht zuverlässig abgedeckt. Der optische Blindenstock ist hier zwar statisch, aber deckt einen Bogen von etwa +/- 15 cm, etwa 10 .. 15 cm vor dem R2D03 ab.

Platinenmaterial lässt Licht durch - zumindest verschiedene, braune Loch- und Streifenraster, die ich verwendet hatte. Eindeutig lichtdicht ist bei mir NUR das Metallröhrchen und NUR in der hier gezeigten Konfiguration (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=355976#355976) mit dem selbstverschweissenden, dickwandigen Schrumpfschlauch am Ende. Er soll nach hinten geringfügig überstehen und dient bei mir auch dafür, dass das Metallröhrchen auf der LED bleibt - nur leicht schrumpfen, dann hälts. Und das Metallröhrchen sitzt auf der unteren Schulter der LED auf. Leider ist mein Kameralack ausgetrocknet und ich konnte das Abdeckrohr innen nicht mattschwarz lackieren. Andere Rohre hatte ich nicht lichtdicht bekommen. Lichtdicht heisst hier: keine Messwertbeeinflussung von SFH415 auf SFH5110 beim Chirpen feststellbar.

Ich musste feststellen, dass andere Dinge statt des Schrumpfschlauches - z.B. ein Streifen ziemlich undurchsichtiges, dunkelgrünes, sehr stabiles Textilband, die Messung beeinflussten.

Die Messwerte schwanken im Bereich +/- 10 % bei gleicher Beleuchtung. Leider ist die Schwankungsbreite bei Änderung der Beleuchtung deutlich größer. So nimmt der Messwert bei "Blick in Richtung Hängelampe" sehr deutlich zu. Daher muss das Abstandsfenster für Hindernis- und Absturzsicherung mithilfe des Sharp (noch nicht implementiert und getestet) justiert werden.

Zum Schluss noch eine Liste Messwerte von heute mit einem älteren Testprogramm - Tischabstand ohne Fahrt gemessen. Beleuchtung "halbes Tageslicht" mit Kunstlicht gemischt. Messwerte der irDME´s sind die ersten drei Zahlenwerte in einer Reihe (der ADC ist unbeschaltet - daher die Unruhe). Die ersten drei Werte nennen die drei irDME´s 12, 3 und 4.

Pm168D/20 MHz m168D_10x61-64/613 09jul08 1610

i1-4 56 39 63 Isvs1 27 most12 129 ADCmm 483
i1-4 53 42 66 Isvs1 27 most12 123 ADCmm 336
i1-4 55 39 61 Isvs1 27 most12 133 ADCmm 825
i1-4 56 41 65 Isvs1 27 most12 125 ADCmm 640
i1-4 54 41 61 Isvs1 27 most12 133 ADCmm 284
i1-4 52 42 61 Isvs1 29 most12 133 ADCmm 800
i1-4 51 35 68 Isvs1 29 most12 119 ADCmm 243
i1-4 56 37 62 Isvs1 29 most12 131 ADCmm 775
i1-4 51 42 63 Isvs1 29 most12 129 ADCmm 465
i1-4 53 41 60 Isvs1 29 most12 135 ADCmm 297
i1-4 52 39 59 Isvs1 29 most12 137 ADCmm 640
i1-4 51 39 53 Isvs1 31 most12 149 ADCmm 258
i1-4 53 41 63 Isvs1 31 most12 129 ADCmm 999
i1-4 57 40 67 Isvs1 31 most12 121 ADCmm 278
i1-4 56 38 59 Isvs1 31 most12 137 ADCmm 371
i1-4 54 39 63 Isvs1 31 most12 129 ADCmm 457
i1-4 59 42 69 Isvs1 31 most12 117 ADCmm 376
i1-4 55 40 63 Isvs1 33 most12 129 ADCmm 376
i1-4 59 41 69 Isvs1 33 most12 117 ADCmm 512
i1-4 57 42 63 Isvs1 33 most12 129 ADCmm 284
i1-4 61 41 74 Isvs1 33 most12 107 ADCmm 393
i1-4 59 41 63 Isvs1 33 most12 129 ADCmm 304
i1-4 63 45 71 Isvs1 33 most12 113 ADCmm 544
i1-4 60 46 77 Isvs1 35 most12 101 ADCmm 492
i1-4 60 43 80 Isvs1 35 most12 95 ADCmm 287
i1-4 58 42 80 Isvs1 35 most12 95 ADCmm 556
i1-4 72 44 74 Isvs1 35 most12 107 ADCmm 232
i1-4 66 46 76 Isvs1 35 most12 103 ADCmm 948
i1-4 64 44 72 Isvs1 35 most12 111 ADCmm 376
i1-4 68 42 76 Isvs1 37 most12 103 ADCmm 324
i1-4 60 48 80 Isvs1 17 most12 95 ADCmm 308
i1-4 58 44 73 Isvs1 17 most12 109 ADCmm 284
i1-4 61 42 79 Isvs1 17 most12 97 ADCmm 474
i1-4 63 44 73 Isvs1 17 most12 109 ADCmm 371
i1-4 58 44 72 Isvs1 17 most12 111 ADCmm 365

[Sternthaler]

Mahlzeit oberallgeier,

mir kommt das etwas merkwürdig vor.
Wenn der irDME 12 der Mittlere ist, würde ich von der Geometrie der Sensoren eher darauf tippen, dass Links und Rechts ähnliche Werte liefern sollten, und der mittlere Sensor mehr nach vorne schaut.

Bei deinen Daten liegen aber Sensor 3 und 4 recht weit auseinander, und der 12'er ist eher mittig.
Sind die Sensoren schon mechanisch ausgerichtet gewesen? Messpunkt der Beiden auf gleichen Winkel nach unten?

Warum überhaupt kannst du wieder in die Ferne sehen? Am 01.08 waren die Teile doch noch blind. Neubau oder Reparatur? Was hat die Dinger eigentlich gekillt?

Und nun wieder weiterarbeiten.
Gruß Sternthaler

[oberallgeier]

Hi Sternthaler,


... etwas merkwürdig ... Bei deinen Daten liegen aber Sensor 3 und 4 recht weit auseinander, und der 12'er ist eher mittig.
Sind die Sensoren schon mechanisch ausgerichtet gewesen? Messpunkt der Beiden auf gleichen Winkel nach unten? ...Eigentlich sind die gleich ausgerichtet, aber schon geringe Änderungen ergeben andere Werte. Da ausserdem links von der Teststrecke ein Fenster zum Garten ist, vorn ein (leuchtender) Bildschirm und oben eine Lampe ist, sind die Werte doch einigermassen unterschiedlich - und sind es auf dem ganzen Weg über den Tisch. Daher muss das Fenster zwischen "Fallgrube erkannt" und "Hindernis erkannt" relativ weit offen sein :(. Es kommt bei der Sensorik noch der schon erwähnte schwenkbare Sharp dazu. Ich hoffe, dass ich mit dem die Justiererei hinkriege. Aber das wird wieder mal dauern :(. Immerhin soll ja der bestimmungsgemäße Gebrauch in ähnlich unausgeglichener Beleuchtung stattfinden.


... Warum überhaupt kannst du wieder in die Ferne sehen? Am 01.08 waren die Teile doch noch blind. Neubau oder Reparatur?
... überraschenderweise ist in der Neuteilekiste noch eine heile CQY99 gewesen und in einer kleinen Versuchsplatine eine SFH415.Das hatte ich dort über das ganze Projekt (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=388981#388981) geschrieben.


... Was hat die Dinger eigentlich gekillt? ...
... Kurzschluß im Steckverbinder? Wie konnte das geschehen? Lötbrücke?
... Mein Reststolz verbietet mir genauere Angaben ...Wie gesagt, es gibt noch diesen Thread über das ganze Projektchen (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=389187#389187). Auch ein kleines Projekt will gross rauskommen :).

[Sternthaler]

CQY99 zum Gruße,

schöner Thread mit der kompletten Beschreibung. Der ist mir doch tatsächlich durch die Lappen gegangen. Allerdings kann ich mich an die Frage von Klingon nach den Gleitpads doch noch erinnern. (Was behält man eigentlich im Kopf?)
Jetzt wird auch klar, warum du dich mit dem Spruch "... Mein Reststolz verbietet mir genauere Angaben ..." selber zitierst ;-).

Weiteres dann ab jetzt also im Projekt-Thread.
Gruß Sternthaer

P.S.: Immer noch nicht zu Hause.

[oberallgeier]

Eine unerwartete Fehlmessung der irDME´s wurde festgestellt.

Bei Testfahrten mit meinem R2D03 auf dem Tisch (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=390196#390196) hatte ich beim Zufahren auf den Bildschirm unsinnige Reaktionen festgestellt. Die Kontrolle der Messwerte durch Ausgabe über die RS232 zeigte, dass der Bildschirm schon bei deutlichem Abstand, ca. 50 cm, dazu führte, dass der kleine Roboter eine Fallgrube sah - sprich: der Messwert ist ausserhalb der messbaren Entfernung, also wird auf ein tiefes Loch erkannt. Ausschalten des Bildschirms ergab sofort glaubhafte Ausweichmanöver. Abdecken der angepeilten Oberflächen (die Sensoren peilen handtellergrosse Flächen etwa 200 mm vor dem Roboter an) mit dunkelgrauem Karton ergab keine Besserung.

Ein schneller Aufbau mit einem Fototransistor - SFH300 o.ä. - ergab bei Abstand Bildschirm-Sensor ca. 5 cm dieses Bild, 0,5V_1ms/DIV :

...................https://dl.dropbox.com/s/iboqyk94bsysoyr/flimm.jpg?dl=0

Seltsamerweise beeinflusst diese Frequenz von rund 300 Hz den SFH5110-36 so, dass er dauerhaft auf "Kein Signal erkannt" (Signalausgang ist high) schaltet. Dies wird bei meiner Auswertung interpretiert als tiefer Abhang.

[Christian H]

Hi Joe,

herzliche Gratulation zu Deiner wandelnden Cola-Dose!

Hast Du mal überlegt deine Sensorik unsichtbar zu machen ? Ich könnte mir vorstellen man bringt 4 oder mehr IR-Detektoren in der Dose fest an, z.B. nahe der Oberkante der Dose und läßt diese durch kleine Löcher nach aussen sehen. Eine IR-LED könnte man verdeckt vorne in den Strohhalm einbauen. Mit Drehung des Strohhalms per Servo könnte man die Umgebung gezielt ausleuchten bzw. abtasten.

Gruss Christian

[oberallgeier]

... herzliche Gratulation zu Deiner wandelnden Cola-Dose! ...Danke für die Blumen *ggg*.


... überlegt ... Sensorik unsichtbar zu machen ? ... IR-Detektoren in der Dose ... durch kleine Löcher nach aussen sehen ... IR-LED ... in den Strohhalm einbauen ...Ja das wäre hübsch. Ich hatte es anfangs überlegt, aber da ich die endgültige Größe und Funktion noch nicht kannte, hatte ich diese hässlichen Aufbauten gemacht. Ausserdem ist es innen reichlich eng geworden.

Ein wesentliches Argument spricht dagegen: das Streulicht. Siehe in diesem Posting (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=389332#389332) unter "... Kameralack ...". Ich hatte festgestellt, dass z.B. der gelegentlich verwendete Schrumpfschlauch zum Abdecken der irLED´s ungeeignet ist - das Licht strahlt einfach durch. Deshalb hatte ich die Abdeckung der LED´s mit Messingrohr gemacht, wie hier gezeigt wird. (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=355976#355976) Ich denke, dass die kompletten Sensoren innerhalb der Dose schlecht funktionieren - wenn die Öffnungen nicht total kameramattschwarz lackiert sind.

Deine Variante mit dem Suchscheinwerfer im Strohhalm - hmmm - daran hatte ich noch nicht gedacht. Müsste ich mal nachrechnen, wie das mit dem Timing im 5110 aussieht. Ich müsste sicher sein, dass die LED eine bestimmte Region ausstrahlt und dann die Chirperei sicher ablaufen lassen. Das könnte gehn. Danke jedenfalls für den Tip.

[Sternthaler]

Hallo oberallgeier,
das ist ja echt spannend!

Wenn der 36 kHz-Filter im Baustein nun doch nicht auf diese Frequenz, sondern nur auf Regelmäßigkeit schaut, ergeben sich ja allerlei Möglichkeiten.
Das würde mich allerdings wundern, wenn die Frequenz nicht die Rolle spielt, da es zu dieser Bauteileserie alternative Frequenzen gibt, bei der das Bauteil 'sehen' soll. Es muss also schon irgendetwas drin sein was mit der angegebenen Frequenz zu tun hat.

Hast du deinen 300 Hz-Pulse mal gezoomt, so dass nur einer der Einbrüche zu sehen ist? Sind im Einbruch, oder auch im High-Teil noch 'dünne' Pulse vorhanden? Zufälligerweise bei 36000 Hz?

Du findest ja immer schlimme Dinge ;-).


Die Idee von Christian H mit der LED im Strohhalm finde ich auch sehr schön. Als kleinen Nachteil würde ich den verstärkten Stromverbrauch sehen. Wenn deine irDME's keine eigene Lampe mehr haben und der Servo die ganze Zeit von einer Ecke in die Andere muss, ...
Das Chirpen müsste dann ja nur zur Servoposition S1, S2 und S3, weitere? synchronisiert werden. Falls der Servo so schnell ist, dass man alle Positionen anfahren, stoppen, messen und wieder anfahren muss, solltes du schon mal prüfen, ob das Drehmoment vom Servo die Dose dreht.

Gruß Sternthaler

[oberallgeier]

Hallo Sternthaler,


... Das würde mich allerdings wundern, wenn die Frequenz nicht die Rolle spielt ...Genau. Allerdings habe ich das reproduziert - bei passender Sicht des irDME-Trios in Richtung Bildschirm chirpen alle Drei unisono "127" - also dauernd high = keine Reflexion erkennbar = totaler Canyon.


... Hast du deinen 300 Hz-Pulse mal gezoomt, so dass nur einer der Einbrüche zu sehen ist? Sind im Einbruch, oder auch im High-Teil noch 'dünne' Pulse vorhanden? Zufälligerweise bei 36000 Hz?
Du findest ja immer schlimme Dinge ...Ich habe es auch mal reichlich gezoomt. Die gesamte Kurvenform ist wohl etwas abhängig von der Bildschirmfarbe bzw. Helligkeit, ich habe eher einen 50%-duty-cycle bei der geringen Frequenz statt der kurzen Einbrüche im gezeigten Bild. Bei sehr hoher Auflösung sehe ich eine ziemlich konstante, weiche Schwingung am Phototransistor - etwa 90 kHz. Dummerweise also keine Oktave sondern das dreifache. Ausserdem ist diese sehr sanfte Welligkeit deutlich unter 0,1V, vielleicht 0,02?

Seltsamerweise ist die beschriebene Störung auch durch Herunterfahren der Bildschirmhelligkeit nicht zu beheben . . .

Ich werde auch mal testen, was der Asuro bei der Abstandsmessung (und bei der IR-232) zu einem hellen Bildschirm sagt.


... Die Idee von Christian H mit der LED im Strohhalm finde ich auch sehr schön. ... Nachteil würde ... Stromverbrauch ... und der Servo die ganze Zeit von einer Ecke in die Andere muss, ...Ich hatte ja schon die schlechte Richtungsselektivität des 5110 bemängelt. Möglicherweise bietet die aber den Vorteil, dass ich mit dem 5110 nur ungefähr in die Richtung schauen muss. Darüber sollte ich nachdenken-gucken-testen-achschonwiedersoeineAbwandlungdieichgarnichtgesuch thatte.


... Falls der Servo so schnell ist, dass man alle Positionen anfahren, stoppen, messen und wieder anfahren muss, solltes du schon mal prüfen, ob das Drehmoment vom Servo die Dose dreht ...Das nächste Problem. Er fährt, wie viele Servos, rund 60° in 1/10 sec. Das Reaktionsmoment dreht die Dose nicht, das ist ja auf dem zweiten Video zu sehen, wenn sich der Strohhalm nach dem "kritischen" irDME dreht. Aber die Stellzeit ist mit Sicherheit eine unschöne Bremse, selbst beim langsamen Fahrtempo der Dose. Also müsste so eine Variante schon alles Unterputz haben. Mal sehen.

[Sternthaler]

Ja, ja, Probleme und Änderungswünsche steigen mit der Anzahl der Leser ;-)

Zum 300 Hz Blinki:
- Pixelfrequenze ist 'etwas' höher.
- Bildwiederholrate liegt darunter.
- Hintergundbeleuchtung?
Mach mal ein paar Oska-Messungen bei geänderter Beleuchtung. Tut sich da was?
Wenn ja, würde ich auf eine Helligkeitsreglung im 300 Hz-Takt per PWM tippen.

Nun aber www.abinsbett.de
Gruß Sternthaler

[oberallgeier]

Hallo Eule,

(nachtaktiv, klug).

Der 300 Hz Blink ist die HintergrundbeleuchtungsPWM (ich hasse es, wenn manche Menschen mitten in der Nacht um so viel besser denken als ich spät abends). Danke für den Hinweis. Unbeschadet davon bleibt die Welligkeit im 90 kHz-Bereich.

Hier mal vier CIR-Messungen mit meinem asuro, die beiden ersten messen die Tastatur im Abstand von 105 mm (DINA6) in Richtung Bildschirm hell / dunkel; Zielrichtung ist Mitte Tastatur mit einer steilen Neigung des Tastenfeldes wie die Bildschirmfläche (angelehnt an den Bildschirm), Zielpunkt ist in beiden Fällen so gleich wie möglich. Bildschirm ist ein acer AL1714 Flachbildschirm. Dritte Messung geht freistrahl ins Wohnzimmer. Die vierte ist ähnlich wie die erste, aber der Bildschirm ist von einem Philips 26PFL.

Bemerkenswert ist die Tatsache, dass der asuro in der Position wie Messung "1" unter gleichen Bedingungen (Bildschirm ist ein) sich problemlos flashen lässt und ebenso problemlos die Datenausgabe abwickelt.


CIR-Test "Sternthaler. Bildschirm, Wohnzimmer, Flachbildfernseher, 14. Aug. 2008
eingeschaltet ausgeschaltet "in die Ferne"/Fernsehbildschirm
15 4 13 12
16 4 12 12
15 4 11 12
17 4 13 12
11 4 14 12
17 4 13 12
10 3 12 12
16 4 12 12
16 4 12 12
13 4 13 12
16 3 12 12
15 4 12 12
16 3 13 12
15 4 12 12
16 3 12 12
15 4 12 12
16 4 12 12
11 3 12 12
16 4 12 12
10 4 11 12
16 4 11 12
16 3 13 12
16 3 12 12
16 4 12 12
15 3 12 12
17 4 12 12
15 4 13 12
16 4 12 12
11 4 12 12
17 4 12 12
10 3 12 11
17 3 13 12
18 4 13 12
17 3 14 12
16 4 12 12
15 4 13 12
16 4 12 12
15 4 13 12
17 4 14 12
11 4 12 11
17 3 13 12
10 4 14 11
17 4 12 12
10 3 12 11
17 4 14 12
16 3 13 11
15 4 12 12
16 4 12 12
15 4 12 12
16 4 12 11
15 4 12 10
16 4 12 11
11 4 12 12
17 4 12 12
10 4 12 12
17 4 12 11
16 4 10 10
13 4 12 11
15 3 11 11
15 3 13 12
16 4 14 11
15 4 12 12
17 4 12 11
11 4 12 10
17 4 13 11
10 4 12 9
17 4 12 11
16 3 12 11
13 3 12 10
16 3 12 9
15 4 13 10
16 4 13 10
15 4 11 10
17 4 13 11
11 4 12 10
17 4 12 10
10 3 12 10
17 4 13 10
10 4 14 10
17 4 12 10

Darüber sollten wir nachdenken. Mir fällt vorerst mal nichts dazu ein.

[Sternthaler]

Huh, huh!
Wenn ich schon tagsüber in der Firma (wie jetzt) nicht zum denken kommen, muss halt eine andere Zeit (für wichtige Dinge) gefunden werden.

Upps, deine Daten sind ja 'lustig'.
Messung 1 (TFT hell), 3 (Ferne) und 4 (Glasmonitor) liefern ja akzeptabel gleiche Werte.
Nur ein AUS-geschalteter TFT macht Probleme?

Um zu zeigen, dass denken (oder blöde Ideen?) auch tagsüber möglich sind:
- TFT's haben ja so ein Flüssig-Kristall zwischen den Scheiben.
- Die Kristalle (was auch immer) werden durch Spannungsfelder verdreht.
- Durch das Drehen geht mal mehr oder weniger Licht hindurch.
Was wäre, wenn die AUS-geschalteten Spannungsfelder das Kristall so richtig durchsichtig werden lässt?
Dann könnte ja unser IR-Messlicht 'einfach so' durch das Glas hindurch; findet also keinen Widerstand zum reflektieren. -> Entfernung ist ganz weit.

Ist ein Messwert von 4 eine weite Entfernung? Wie ich es verstanden hatte, ist da ja der Abgrund in Sicht.
Was habe ich durcheinander gewürfelt?

Gruß Sternthaler

[oberallgeier]

... Nur ein AUS-geschalteter TFT macht Probleme? ...Nein, Probleme sehe ich nur bei eingeschaltetem TFT.


... Messung 1 (TFT hell), 3 (Ferne) und 4 (Glasmonitor) liefern ja akzeptabel gleiche Werte. ...Gleich - ja, aber akzeptabel? Also wenn alle Flugschüler der Staffel ihre Maschinen bei der A-Prüfung zu Bruch fliegen - dann ist das Ergebnis ja auch gleichwertig aber doch nicht akzeptabel. Messung 1 und 4 hätte das gleiche Ergebnis bringen sollen wie Messung 2.


... Was wäre, wenn die AUS-geschalteten Spannungsfelder das Kristall so richtig durchsichtig werden lässt?
Dann könnte ja unser IR-Messlicht 'einfach so' durch das Glas hindurch; findet also keinen Widerstand zum reflektieren. -> Entfernung ist ganz weit ...
Hmmm, ich hatte es wieder missverständlich dargestellt. Messobjekt ist die Tastatur. Messfläche ist Mitte der Tastatur, die ist an der schmalsten Stelle 170 mm breit. Messabstand ist 105 mm (Schmalseite vom DINA6). Die Messfläche steht senkrecht zum asuro-Scheinwerfer-Empfänger-Ausrichtung. Messergebnisse:
bei eingeschaltetem Bildschirm 10 .. 18
bei ausgeschaltetem Bildschirm 3 .. 4 - sonst wurde nichts am Messaufbau verändert!
ins Wohnzimmer (>5m) 10 .. 14
bei eingeschaltetem Fernseher 9 .. 12

Die unmittelbar gleichen Ergebnisse erwarte ich also bei Messreihe 1, 2 und 4, die Reihe 3 darf den hohen Werte anzeigen - denn es geht ja tatsächlich tief in den Raum hinein (Sofa auf ca. 3 - 4 m, leicht unterhalb des Richtstrahls).

Und zur Demonstration der Messaufbau für die Messung mit Tastatur - bei eingeschaltetem Monitor. Ausschalten des Monitors bringt das Ergebnis, das ich bei der Oberfläche und Struktur der Tastatur erwarte, siehe Messung 2 . . . . Fazit: der Bildschirm streut seine Störungen von oben ein ! ! Und dies wo der 5110 die Tastatur unter einem vertikalen Bildwinkel +- 35° sieht. Ausserhalb der Tastatur (also Teile des Monitors) beträgt die Empfindlichkeit des 5110 (mehr als 35 ° vertical directivity) unter 30 %. Dabei müsste die AGC längst diese Helligkeit ausgeglichen haben, schließlich ist unter schlechteren Bedingungen (kein Tastaturschutzschild) die IR-232 funktionstüchtig. Aber die CIRperei bringt auch dann den Messwert "unendlich" - so bin ich ja über das Problem gestolpert.

[Sternthaler]

Hallo oberallgeier,

ne, ne, deine Ausdrucksweise war schon ganz ok.
Gewürfelt hatte ich da wohl etwas. (War halt noch zu früh!)

Nun stehe ich aber komplett auf dem Schlauch.
Überlegungen:

- Die Helligkeit vom EIN-geschalteten Monitor kann vom AGC nicht ausgeglichen werden.
--> Dagegen spricht deine Aussage, dass aber noch geflasht werden kann.

- Das IR-Lichtlein geht bei EIN-geschaltetem Monitor durch das Kristall.
--> Ja, ja, es muss dann auch erst noch durch die Tastatur.

- Die Raumzeit wird durch TFT's gekrümmt und das Messlicht muss erst durchs Universum.
--> Fällt unter OT oder helle Magie.

- Das Prinzip vom Chirpen ist, dass die Lichtleistung per PWM gesteuert wird. Hier treten somit extrem andere Dutycycle gegenüber einer 50%-PWM beim Datenübertragen auf.
Im Datenblatt gibt es keine Angabe darüber, wie der AGC reagiert wenn der dort angegebenen 50%-Dutycycle variiert wird.
Hier scheint die AGC dann die Füße durcheinander zu bekommen.
Was kann eine AGC eigentlich machen?
Sie muss eine 'Ahnung' davon haben was sie betrachten soll.
Wenn sie also darauf getrimmt ist einen 50%-PWM zu 'suchen', dann müssten eigentlich feste Zeiten im Bauteil vorhanden sein, die mit mindestens doppelter Taktfrequenz das Eingangssignal 'liest'.
Ist hier nun ein stetiger Wechsel, egal auf welchem Niveau durch Umgebungslicht 'hochgeschoben' zu finden, dann hat diese AGC ihre Arbeit erledigt.
Signalamplitude ist nicht relevant. Wechsel aber nur in einem bestimmten 'Raster' auffindbar.
Mein Tipp: Das ist das Problem.

Die Datenübertragung arbeitet mit 50%-Cycle. Da arbeitet die AGC mit riesengroßer Wahrscheinlichkeit am liebsten mit.
Anders kann ich mir die Angabe aus dem Datenblatt: "Die Reichweite bei Verwendung eines typischen Senders (SFH 4510/SFH 4515, IF = 500 mA) beträgt etwa 30 m." Hierbei ist die Differenz der ein-/aus-Lichtleistung vom Sender gegenüber einer 'normalen' Raumbeleuchtung extrem gering. Und trotzdem soll es noch funktionieren.
Warum dann aber die CIRperei überhaupt funktioniert kann ich jetzt aber gar nicht mehr sagen.

Als Gegenmessung sollte man eventuell mal im Sonnenlicht messen.
- Abschatten, so dass die Datenübertragung gerade noch gut geht. (Als Kontrolle der 50%-Theorie.)
- An dieser Position CIRpen. (Simuliert einen ausgeschalteten TFT.)
- Abschattung dann wegnehmen. (Simuliert nun einen eingeschalteten TFT, aber ohne diese ominösen 300 Hz.)

Ich vermute, dass dann auch ein 'Abgrund' auftreten wird, da der AGC jetzt einfach überfordert wird.

Ist das nicht ein schöner Grund mal an die frische Luft zu gehen?
Gruß und gute Nacht
Sternthaler

[oberallgeier]

Hi Sternthaler,


... Gegenmessung ... mal im Sonnenlicht ...Genau, das steht schon auf dem Arbeitsplan. Leider gibt´s heute Sonne erst über 10000, 15000 Füssen GND und gestern war auch nicht wirklich was da. Was mich aber ebenfalls (noch) interessiert wäre die spektrale Verteilung des LCD-Flutlichtes. Da fällt mir vielleicht noch was dazu ein . . . Übrigens bekomme ich bei einer Messung "weißer Rauhputz - gestrichen, nicht körnig") bei 105 mm Abstand bei mäßigem Kunstlicht konstant 3 CIR. Nach Deiner cir.h V001 - 05.05.2008 sollte das eher 2 sein.


... Ist das nicht ein schöner Grund mal an die frische Luft zu gehen?Bis ungefähr zwölf Stunden vor Deinem Posting war ich dort. Saß in total unbequemer Stellung in einem Laser (http://de.wikipedia.org/wiki/Bild:Laser_003.jpg) und freute mich darüber, dass ich Windstraßen und Flautenplätze auf dem Alpsee gut auseinanderhalten konnte und die Jolle schon mal prächtig in Fahrt und in Schieflage kam. (Auf dem Foto bin nicht ich, auch wenn die grüne Mütze stimmen könnte, aber ich seh in meinem Shorty viel besser aus *ggg*.)

[Sternthaler]

Hallo oberallgeier.


Nach Deiner cir.h V001 - 05.05.2008 sollte das eher 2 sein.Richtig. Da steht aber in der Datei: "Bei Sternthaler funktioniert folgende Berechnung:"
Insgesamt hatte sich ja schon anderer Stelle herrausgestellt, dass diese Formel nicht übertragbar ist. Inka hatte einen Faktor 2 zu meiner ursprünglichen Formel bei seinem Asuro festgestellt. Nur die Linearität beider Messung (meine und inka's) war dabei aber sehr ähnlich.

Gruß Sternthaler
P.S.: Auf dem Foto kann man dich ja überhaupt nicht erkennen. Wenn man das Gesicht anschaut, scheinen da Pixelfehler in der Kamera zu sein. Oder sind diese modernen Dinger mit Kopfsuchfunktion schon so weit, dass man sagen kann: "Bild ist für I-Nicht-Net. Bitte den Kopf verschleiern."? Hi,hi.

[mare_crisium]

Buona sera, ihr beiden,

ich habe (klammheimlich) Eure Diskussionen begierig verfolgt, weil ich an allem interessiert bin, was Entfernungen messen kann. Und auf OTs stehe ich sowieso :-) !

Nur der Vollständigkeit halber, Oberallgeier: Könntest Du mal eine Messung mit EIN-geschaltetem, aber abgedeckten LCD-Bildschirm machen? So ein Ding produziert jede Menge Hf; Du solltest ausschliessen, dass das Problem damit zusammenhängt.

Ciao,

mare_crisium

[oberallgeier]

Hallo mare_crisium,


... klammheimlich ...Komm ruhig raus, wir sagens schon nicht dem Schräuble. Und ich vermeide auch alle CIA-Schlüsselwörter.


... Nur der Vollständigkeit halber ... Messung abgedeckten LCD ... produziert ... jede Menge Hf ...
Danke, dass Ihr aufpasst, dass wir alle (uns allen bekannten) Fehlermöglichkeiten ausschliessen. Also - wenn HF von zwei, auf dem Bildschirm nebeneinanderliegenden A4-Blöcken mit je fünf Blatt holzfreiem, kariertem Papier und einem Rückenkarton aus 0,6 mm unverleimter Pappe abgeschirmt wird - dann ist es HF. Klartext: hatte ich gestern schon probiert. Die Messung ergab eine komplette Reihe 4en mit zwei Fünfen irgendwo drin - das könnte der Einfluss von ein paar Photonen gewesen sein, die seitlich an der nicht-verklebten Abdeckung durchdiffundierten.

[mare_crisium]

Jo, Oberallgeier,

wie pflegt doch weiland Sherlock zu sagen: "Danke, das genügt!" - Also keine EMF :-( . Beim Ansehen der graphischen Darstellung der Daten fiel mir etwas auf, was man mit etwas gutem Willen als eine Periodizität von ca. 11,5 Messzyklen interpretieren könnte. Guckt Euch doch 'mal das angehängt xls an.

Ciao,

mare_crisium

[oberallgeier]

... eine Periodizität von ca. 11,5 Messzyklen interpretieren ...UUUps - ich fürchte, das muss ich mal etwas mehr messen - und nachdenken. Danke für Deine Mühe

[Sternthaler]

Hallo Zykler,

kann bei den Messdaten davon ausgegangen werden, dass sie mit konstanter Frequenz abgetastet werden? Wenn ja, wie hoch ist sie?
Um diese Zeiten der einzelnen Messwerte zu erhalten hatte ich bei *meinem Problem die Tage* immer noch die Asuro-Zeit (36 kHz-Einheiten) mit übertragen.
Anhand der Zeiten könnte man ja nun auch bei dir oberallgeier auf die genaue Frequenz der Zyklen schliessen. Ist das eventuell ein 50Hz von Lampen, oder eine 'Zeilenfrequenz' bzw. schon wieder die PWM der Hintergrundbeleuchtung.

Um Messdaten wird gebeten ;-)
Gruß Sternthaler

[oberallgeier]

... kann bei den Messdaten davon ausgegangen werden, dass sie mit konstanter Frequenz abgetastet werden? Wenn ja, wie hoch ist sie? ...Ich bin recht sicher, dass die Datenerfassung nicht isochron läuft. Die Erfassung auf dem asuro erfolgte mit der hexdatei von Sternthaler in seinem originalen CIR-Paket V040-2.80-int.zip auf einem originalen asuro (Modifikationen sind: Beilagscheibe und IR-Schnittstelle auf Zusatzplatine, siehe Posting hier oben (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=391136#391136)).


... hatte ich bei *meinem Problem die Tage* immer noch die Asuro-Zeit (36 kHz-Einheiten) mit übertragen ...Sorry, das hatte ich (noch) nicht gemacht. Ich bin ja erst vor fünf Tagen drüber gestolpert. Das muss ich nacharbeiten. Aber leider nicht in den nächsten paar Tagen. Und es steht ja noch die Messung bei Sonnelicht an. Heute wäre DER Tag dazu gewesen. Leider hatte ich zum Fliegen weder den Oskar, noch den Bildschirm, noch die Coladose mitgenommen.


... 50Hz von Lampen, oder eine 'Zeilenfrequenz' bzw. schon wieder die PWM der Hintergrundbeleuchtung ...Die Messungen erfolgten ohne 50Hz-getriebene Beleuchtungskörper. Die PWM-Frequenz hatte ich wohl schon vorgestellt - unklar sind die 90 kHz. Andere Frequenzen hatte ich mit dem Fototransistor nicht entdeckt.


... Um Messdaten wird gebeten ...Genau das werde ich tun, siehe oben.

[Sternthaler]

Uff oberallgeier,

da bin ich aber froh, dass nicht du mit dem Fahrwerk in der Oberleitung im Allgäu hängen geblieben bist.
Wäre das eigentlich fahrlässig mit Oskar am Steuer noch zu fliegen? In D gibt es doch bestimmt ein Gesetzt dazu. So á la Nichtraucher-, Anschnall- und HandyhalterImAuto-Gesetz.

Und, gibt es schon Daten? ;-)


Hallo mare_crisium,
deine Sortierung der Daten in Zyklen halte ich für recht gewagt. Du hast es ja schon mit "etwas gutem Willem" selbst angedeutet.
Auch wenn man den 1. und 8. Zyklus komplett außer acht lässt, finde ich die unterschiedliche Länge der Zyklen von 9 bis 13 Messwerte doch recht groß. Von 9 bis 13 kommen da immerhin ca. 45% hinzu. oder es fehlen halt ca. 30 %.
Vielleicht sollte oberallgeier doch mal sein Testprogramm posten, damit deine Idee auch mal an meinem TFT gegengeprüft werden kann.
Und es scheint ja wirklich nur beim TFT einen "guten Willen"-Zyklus zu geben.

Gruß Sternthaler

[mare_crisium]

Einen wunderschönen Herbst-Morgen (mit Regen), Ihr Asuraner,


...dass die Datenerfassung nicht isochron läuft...

tja, wenn die Einzelmessungen nicht mit festem Zeitabstand erfolgten, wovon ich (klammheimlich) ausgegangen war, dann ist das auch kein Lösungsansatz für Dich, Oberallgeier. Schade - jetzt fällt mir auch nix mehr ein :-( .

@SternThaler:

Jo, diese Methode, die "arme-Leute-Fourier-Analyse" ;-) , ist schon ziemlich am Rande des Erlaubten. Mir fiel halt die eigenartige, wiederkehrende Folge von "zwei Zacken nach unten" auf, und ich dachte, da gäb's vielleicht einen Reim darauf.

Ciao,

mare_crisium

[oberallgeier]

Hallo Christian H, hallo alle,


... Hast Du mal überlegt deine Sensorik unsichtbar zu machen ? ... Eine IR-LED könnte man verdeckt vorne in den Strohhalm einbauen ...Gerade sind bei mir ein paar SFH4600 eingetrudelt. Leider nicht 0805 sondern nur etwa 1210. Leider habe ich die noch nicht zusammen mit dem IR-Empfänger getestet, so neu sind sie bei mir. Jetzt suche ich nur noch einen SFH5110 oder so was in SMD - weniger wegen des SM als vielmehr wegen des 0805 *ggg*.

Werde aber zwei Wochen offline sein. Cinque terre und danach département 2A und 2B. Bis wieder mal.

[oberallgeier]

Hallo Christian H, hallo alle,

nun habe ich die 4600 getestet. Eine (etwas popelige) Bedrahtung und ich konnte sie im direkten Vergleich mit einer SFH415 testen.

...http://oberallgeier.ob.funpic.de/4600_1611.jpg...http://oberallgeier.ob.funpic.de/4600_1612.jpg

Die Ergebnisse sind kaum überraschend, wenn man mal die Datenblätter verglichen hat. Die Messungen wurden unter gleichen Bedingungen (Messort = gestrichener Rauhputz-weiß, Beleuchtung=Mischlicht, Abstand ca. 32 cm) durchgeführt. Die stilvolle Metallblech-Trennwand ist notwendig, da die Buchse bei meiner Experimentierplatine leider deutlich hinter dem 5110 steht. Ohne Abdeckung ist das Messergebnis stets 1 - wen wunderts.

Vergleich SFH415 gegen SFH4600 auf asuro
Datenerfassung und -übertragung mitVergleich SFH415 gegen SFH4600 auf asuro
Datenerfassung und -übertragung mit
original - CIR - nach Sternthaler

Messung Nr. SFH 415 SFH 4600
1 8 5
2 9 7
3 10 7
4 10 6
5 10 6
6 9 6
7 8 6
8 9 6
9 9 6
10 10 6
11 9 6
12 10 6
13 9 6
14 10 6
15 9 7
16 9 6
17 9 6
18 9 6
19 8 6
20 10 6
21 9 6
22 8 6
23 9 6
24 10 6
25 10 6
26 11 6
27 8 6
28 8 5
29 8 5
30 8 6
31 10 6
32 12 6
33 11 6
34 12 6
35 10 7
36 12 6
37 10 6
38 10 5
39 12 6
40 12 6
41 8 6
42 11 6
43 9 6
44 9 6
45 11 6
46 10 6
47 9 6
48 11 7
49 9 6
50 8 6
51 10 6
52 8 6
53 9 6
54 9 6
55 8 6
56 9 6
57 10 6
58 9 7
59 8 6
60 10 6
61 10 6
62 10 7
63 9 6
64 10 6
65 10 6
66 12 6
67 10 6
68 10 6
69 9 6
70 9 6
71 10 6
72 9 6
73 9 6
74 10 6
75 8 8
76 10 6
77 9 5
78 12 6
79 8 6
80 10 6
Die kleinere kostet allerdings z.B. beim gross-R statt -.23 (für die 415) satte -.40.

[Sternthaler]

Hallo oberallgeier,

mal abgesehen von der 'Krösus oder Bettelmann'-Variante, scheint die Dynamik vom SFH 415 ja besser zu sein als vom SFH 4600. (Und SFH 4600 wird ja nicht für Neuentwicklungen empfohlen.)
SFH 415: 8-12 Bereich 4
SFH 4600 5-7 Bereich 2

Welcher der Beiden nun aber sinnvollere Ergebnisse liefert kann ich nicht interpretieren.
Deine angegebenen Messwerte, bei konstanten Abstand zum Hindernis, bevorzugen ja den SFH 4600, da der angegebene Messwert eben nur in dem kleinen Bereich (5-7 anstatt 8-12) schwankt. Im Grunde ist eine 'Entscheidungswilligkeit' im auswertenden Programm ja leichter/besser bei Messwerten die einen kleineren Schwankungsbereich/Dynamik haben.
Ich bin hier fast der Meinung, dass es nur eine Glaubensfrage ist, ob man Sensor X oder Y einsetzt. (Wie gesagt: fast. Schließlich kommt es nur auf das auswertenden Programm an, wie dynamisch es reagiert. wenn der Sonsor, oder das St.th.-CIR-Proramm Mist liefern.)

Ansonsten viel Spaß an der Küste, A, B oder C. Komm vor allem ohne Sonnenbrand zurück. Und mach ein schönes Foto vom E-Turm.
Gruß Sternthaler

[oberallgeier]

Grüß Dich, Sternthaler,


... SFH 4600 wird ja nicht für Neuentwicklungen empfohlen ...Bahhh - das alte, ärgerliche Leiden. Hier im Forum hatte ich vor einiger Zeit schon mal erbost angemeckert, dass unsere Lieferanten uns alte Dokumente zur Verfügung stellen. In meinem Datenblatt - Download von "R", Stand 2005-03-08, steht nichts davon drin. Erst in dem Datenblatt bei Osram, Stand 2008-01-14, das ich mir eben auf Dein Posting hin geholt hatte, ist diese Anmerkung zu finden.


... Dynamik vom SFH 415 ja besser ... als vom SFH 4600 ...Stimmt. Aber wenn man die irLED "verstecken" möchte, dann macht die SFH4600 schon Sinn. Mir ging es ja darum, an einer Standardanwendung zu testen, wie weit das SMD-Bauteil mit dem bedrahteten 5mm-Gerät vergleichbar ist. Ausserdem kann ich mir vorstellen, dass man bei einer Erweiterungsplatine dieses Miniteilchen schon prächtig anwenden kann.


... Ansonsten viel Spaß ... schönes Foto vom E-Turm ...E-Turm? Übrigens hat mein Orthopäde den Ausflug leider etwas verschoben.

[Sternthaler]

Pures OT

@oberallgeier
Upps, da habe ich mich doch glatt vertan. Dann kann natürlich auch ein E-Turm nicht als Eiffel-Turm erkannt werden.

Gruß Sternthaler

[oberallgeier]

Hallo Alle,

es wird wohl Zeit für mich das Thema abzuschließen.

Die irDME´s sind gut geeignet, um grobe Entfernungsabschätzungen zu machen. Es ist gut und sicher möglich mit diesen Sensoren ein Fenster zu definieren, innerhalb dessen mein Dottie fährt. (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=390006#390006) Durch dieses Fenster ist der R2D03 gegen Zusammenstöße und Abstürze (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=390196#390196) relativ gut gesichert - siehe insbes. den Lauf "Strohhalmsensorindikator".

Bei verschiedenen Versuchen funktionierte die (Nach-) Justierung der Entfernungsmesser mithilfe des GP2D120 nicht wirklich. Wieso? Die irDME´s werden beim Start kalibriert. Dazu wird der vom Sharp gemessene Abstand herangezogen und wenn dieser Wert dem üblichen Abstand entspricht - rund 160 mm vom Sensor zu einer ebenen Fahrfläche - dann wird dieser Wert als "Nullwert" für den jeweiligen Sensor genommen und Maximalwert (darüber herrscht Absturzgefahr) und Minimalwert (Zusammenstoßsensor) darauf bezogen. Beim Umherfahren bei unterschiedlichen Beleuchtungsverhältnissen ändert sich der Messwert z.T. erheblich - Schwankungen des Messwertes, der Beleuchtung und des Untergrundes - sodass das Fenster groß genug sein muss um ungestört fahren zu können. Fährt Dottie nun an einen Tischrand hinter dem jemand sitzt, dann ist ein Absturz trotz nachträglicher Justierung "unterwegs" durch den Sharp eher häufig abzusehen als selten. Mit oder ohne Nachjustieren des Fensters wird ein Absturz also nur vermieden, wenn niemand neben dem Tisch sitzt.

Diese Einschränkung stört mich nicht wesentlich. Bisher haben aber alle Tests gezeigt, dass mir eine Abhilfe kaum möglich ist. Eine zusätzliche Störmöglichkeit der irDME´s durch den Bildschirm (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=390902#390902) habe ich beschrieben. Trotz allem meine ich, dass ich die Möglichkeiten in diesem Aufbau recht gut ausgeschöpft habe. Ohne dass ich je mit US-Sensoren getestet hatte, bin ich weiterhin der Meinung, dass diese IR-Lösung bei entsprechenden Anforderungen durchaus eine mögliche Konkurrenz ist.

Vorteil: Schnell (theoretisch rund 85 Hz * ), günstig, breiter Streuwinkel von rund 45°.
Nachteil: Ports für LED und IR-Empfänger sind notwendig, ungenau, wird durch Bildschirmflimmern (LCD-Schirme) gestört.

*: SFH5110-36 => 36 kHz, 6 Pulse bis zum Signal, 10 Messwerte zur Durchschnittbildung und 7 Iterationen.

Meist hats Spass gemacht.

[Sternthaler]

Hallo oberallgeier,

deine schöne Zusammenfassung ist nun das i-Tüpfelchen auf diesem irDME-Thread.

Mit deinen herrausgepickten Positionen in die beteiligten Beiträge, findet man sehr schön den Zusammenhang, warum sich diese Mühe für deine irDME's gelohnt hat. (Und man fängt an in Erinnerungen zu schwelgen, wenn man den Links auch noch folgt ;-))

Mir hat es auch ohne 'Meist' Spass gemacht. (Ich hoffe, dass ich zu deinem 'Meist' nicht beigetragen habe.)

Gruß Sternthaler

[oberallgeier]

... Ich hoffe, dass ich zu deinem 'Meist' nicht beigetragen habe ...Und ob, und wie ! ! "Meist" ist ja so eine Art duty-cycle-Funktion. Da gibt es den "on"-Zustand und den "off" Zustand. Und denke bitte nicht, dass Du für die Lücken zuständig bist. - - Ich alleine hätte nie soooo viel konstruktive Dinge reingebracht - ganz abgesehen davon, dass ich alleine durch DEINE CIRperei tagelang beschäftigt war - und wer zählt die OT´s, die manchmal nicht nur "on´s" waren, sondern manchmal sogar Peaks *gggg*. Hoffentlich fällt uns bald was Neues ein.