Robotron T2

Hi,

Ich habe so mal eine kurze Frage:

Du sagst unter 10cm ist sowieso rückwärtsfahren angesagt. Aber wie unterscheidest du was unter 10cm ist? Vielleicht ist es dir aufgefallen, dass der Graph von den GPD-Sensoren nicht immer eindeutig ist. Ich weiß es nicht genau wie es bei deinen Sensoren ist aber bei den 120ern ist die Spannung für 4cm und 2m gleich. Auch bei 10cm und >2cm ist es gleich. Daher ist es o, das du beim Hochpunkt des Graphen dein Minimalabstand haben solltest weil ab dort es nicht mehr eindeutig ist.

Und wegen dem Grenzwert des IR-Sensors

Wieso bastelt ihr nicht eine kleine Funktion. Dann könntet ihr aus IR-Sensor und Stellung des Servos direkt die PWM Werte für die Motoren errechnen so könnte man Hindernissen viel schneller und effizienter ausweichen.

Das bietet sich bei euch ja richtig an.

Und achja...
Da ihr alles auf eine Karte setzt also auf einen Sensor...
Würde ich mir überlegen nen kleinen software Tiefpass zu bauen um falsche Messwerte zu filtern. Das bewirkt manchmal wunder.

Lg

@oratus sum :
Ich glaube jetzt habe ich das in Deinem Thread erst richtig verstanden.
Du meinst, wenn der Sensor auf der rechten Seite ein Hindernis entdeckt, dann soll er direkt den PWM-Wert für beiden Ketten setzen. In diesem Fall linke Kette langsamer, rechte Kette schneller, damit er sich nach links dreht. Dadurch würde der Bot direkt reagieren und das sehr flüssig. Hindernisse auf der linken Seite, würden dann die rechte Kette langsamer und die linke schneller werden lassen. Das scheint mir ne klasse Idee zu sein!!!
Meinst Du das bei Dir mit der Fuzzy Logic?

Was Rabenauge mit den 10cm meint, ist bei mir genauso. 10cm entsprechen bei mir 2,7V. Was nahezu dem maximal Wert entspricht. Bei 10cm heisst es also Stop in jedem Fall und dann rückwärts. <10cm ist nicht detektierbar, das haste recht.

Ja ganz genau so habe ich das gemeint.

Die Formel die ich in meinem Thread gepostet habe, habe ich aus den dort genannten gründen selbst aufstellen müssen.
Es funktioniert aber wirklich sehr gut. Das Drehen ist nämlich sogut wie nie nötig, das ist ja der Clou dabei. Würdest du ein Slalom aufstellen würde dein Bot mit dem Grenzwert zu nem Hindernis hinfahren, Drehen,Vorwärts, Drehen Vorwärts fahren.

Mein Bot fährt dann tatsächlich ein Slalom, da er die Kettengeschwinigkeit direkt über diese Funktion "regelt". Die Zahlen stimmen nicht mehr ganz von der Funktion, da ich den Messbereich erweitert habe.

Kurz zur Erklärung für die Zahlen:

49: Das ist die "Mitte" des Sensors. Ich messe den Bereich von 25cm (=Stoßstange des Bots) bis 72 cm, die Mitte ist 49cm. (eigentlich 48.5). Bei 49 habe ich meinen Wendepunkt der Funktion. Dort schlägt er von Vorwärts auf Rückwärts um. Also bei einer Kette.

/2 :
Das dvidiert durch 2 beweirkt eine Abflachung der Funktion. Je größer die Zahl desto langsamer schlägt er um. Aber desto weicher ist auch die Steuerung. Ich habe da 2 genommen weil bei mir die PWM-Werte nur von 150-255 die Motoren beschleunigen. Hast du eine höhere Auflösung solltest du unbedingt eine höhere Zahl nehmen.

0.5:
Einfach lassen. Die Sigmoid-funktion muss einen estimmten Bereich haben, damit Sie "funktioniert"

510:
Ist quasi der Verstärkungsfaktor.
Er sorgt dafür, das letztendlich die Werte wirklich von -255 bis 255 reichen. Du musst die 2 und die 510 aufeinander abstimmen.

Ist nicht so kompliziert wie es sich anhört.

Ich würde bei dir das folgendermaßen realisieren:

Dein Bot fährt Vorwärts. Anstatt deine gesamte Umgebung zu scannen würde ich abwechselnd Links/Rechts schauen, falls ein Hindernis entdeckt wird mit immer größeren Ausschlägen. Also:

Servo = 0° (Hindernis)
Servo = -5° (Hindernis)
Servo = +5° (Hindernis)
Servo = -10°(Hindernis)
Servo = +10°(frei)

So kannst du immer zwischen Links und Rechts unterscheiden und schaffst dir zwei "logische" Sensoren, einen für Links und einen für Rechts. Wenn du jetzt noch die gemessenen Werte mit meiner Funktion koppelst sollte das funktionieren.

Das setzt natürlich voraus, dass dein Servo schnell genug ist. Mit der Funktion kannst du sowieso aber die Geschwindigkeit begrenzen also wenn der Servo zu langsam ist.

Das mit dem Links/Rechts schauen hat den Vorteil, dass es viel schneller geht. Während du beim Scannen als von -90 bis +90 abscannst, was ja ein Winkel von 180° ist bzw bei dir ja 100 Schritte. Und hier kommt wieder der Vorteil des IR-Sensors: Es reicht nur eine kleine Drehung um eindeutige Ergebnise zu erlangen. Beim US Sensor müsstest du viel mehr drehen.

Hier nochmal die Funktion zu verdeutlichung:
Bild hier  
Bild hier  

falls du matlab hast, hier die Funktion:
y=(int32(((1.0 ./ (1.0+exp(-((x-49)/4))))-0.5)* 510))

bzw kannst so wie es ist für dein C übernehmen. Ich weiß nicht ob das so geht mit dem avgcc.
das int32() nimmt nun den Ganzzahligen Anteil. das exp() ist einfach e^() e ist ja eine Konstante.

Achja:
Nett ist auch, dass du vollkommen ohne if-Abfrage auskommst. Wie du beim Grpahen siehst, egal wie groß oder klein die Zahlen sind, aber einem geweisen Punkt bleiben sie immer in deinem Bereich (bei mir 255).
also quasi:
lim(f(x)) = 255
x->∞
und
lim(f(x)) = -255
x->-∞

Wenn du mir die PWM-Werte deiner Motoren sagst und die gewünschten Bereiche kann ich dir die Funktionsgleichung gerne aufstellen, du müsstest si dann nurnoch anpassen bzgl der Servogeschwindigkeit,

Falls noch Fragen offen sind einfach stellen. Ich drücke mich manchmal sehr ungeschickt aus :-D

Ich habs soweit verstanden. Ich komm auf Dein Angebot der Kontrolle zurück, sobald mein Servo an OCR2 läuft, meld ich mich...

Ohh man, sobald ich den zweiten Timer aktiviere mit
TCCR2 = (1<<WGM20)| (1<<WGM21) | (1<<COM21) | (1<<CS22) | (1<<CS20); scheint der kleine Atmega8 die Ohren anzulegen.

Ich bekomme übern UART nur noch halbe Befehle und kann auch keine absetzen die er versteht. Und die beiden PWMs die laufen, setz er beim Auslesen der jeweiligen ADC mit Verzögerung...argg das kann ja wohl nich sein...H I L F E!

Hast du schon nen Timer laufen?

Ich kenne mich mit den avgcc nicht aus. Halbe Befehle sehen nach zu kleinem auswärtspuffer aus und gleichfalls das er die Befehle nicht versteht.

Wie greifst du auf UART zu? Per Interrupt oder sub?
Wie oft wird denn dein Timer aufgerufen und was muss der alles machen? Sieht mir irgendwie danach aus, dass dein Timer alles blockiert.

Derzeit laufen 2 8-Bit Timer für 2 PWMs (für die Motoren).
Der UART ist Interrupt gesteuert. Kommt ein Zeichen an, dann wird es verarbeitet. Außerdem laufen 4 ADCs. 2 sind fürs Einstellen der PWM per Hand übern Poti (für Testzwecke, wird nachher anders gelöst) und 2 ADCs sind für das Einlesen der IR Sensoren.
Eigentlich laufen noch 2 ADCs,diese messen die Stromaufnahme der VNH2SP30, sind aber abgeschaltet.

Das wars soweit. Takt ist 8MHz, sollte auch ausreichen...
Ich weiß nicht wo das Problem ist.
Noch sind ja nicht mal alle Hardwareresourcen belegt :-k

@oratus sum : so ganz habe ich deine Erklärung noch nicht verstanden, aber für reinen Hindernislauf klingt das recht gut. Das schaue ich mir auf jeden Fall noch mal gründlich an nachher.
Funktioniert das auch, wenn "etliche" Hindernisse im Weg sind, in verschiedenen Entfernungen?

Mir geht es nämlich mittelfristig schon darum, auch die Positionen der Hindernisse genau zu detektieren, um später beispielsweise Hindernisse ganz gezielt (und möglichst genau) anfahren zu können.

@Kellerkind: hast du in den ISR`s irgendwelche zu lang dauernden Geschichten drinnen?
Das Problem hatte ich auch schon mal, während eine ISR läuft, geht nix anderes.
Hast an meinem Beispiel ja gesehen, wie knapp ich die halte- das _ist_ die komplette ISR. Soweit ich weiss, werden Interrupts, die während einer ISR auftreten, auch aufgehoben und danach abgearbeitet, also liegt dort vielleicht der Hase im Pfeffer (die ISR wird_wieder_ aufgerufen, ehe der Rechner zu was anderem kommt).

Ich habe drei Timer laufen (Timer0 für allgemeines, Timer1 ist für die PWM beim NiboBee und Timer2 fürs Servo)-> keine Probleme.

Mahlzeit :-D

Ich habe noch ein wenig rumgebastelt und meine Funktion etwas angepasst. Ich habe dir ja erzäht, dass meine Motoren erst so ab 150 losrollen. Dem entsprechend habe ich die Funktion angepasst.

Klar man hätte einfach sagen können wie mit Grenzwert,

wenn PWM unter 150 dann PWM = 150

bäh sowas mag ich nicht :-D
Das ist danna uch eine gerade Strecke im Graphen schaut unschön aus.

Deshalb habe ich diese gerade Strecke abgerundet. So sind zwar in der FUnktion zwei if-Bedingungen aber dafür reagiert er jetzt noch schöner.

Ich muss sagen ich bin nicht so gut in Mathe, das:
[0:150] soll heißen 0 bis 150. Also das Intervall 0-150

War mir jetzt unsicher ob das ein - oder : Zeichen ist.

Also hier:

Die Zahlen habe ich auch verändert... weiterhin gilt falls was unklar ist einfach Fragen :-D ich weiß ja nciht ob jeder meine chaotischen Gedanken nachvollziehen kann :-D


[edit]
@Rabenauge
Nunja das ist vorerst ein Antikollisonssystem. Es funktioniert mit dem Objekt die vor dem Sensor. Beim Ultraschall wirst d direkt nciht feststellen können wo sich das Objekt befindet. Es sei denn du machst eine Triangulation mit zwei Sensoren.

Mit dem IR weißt du schon wo sich das Objekt befindet, unzwar direkt vor dem Senor :-D. Da kannst du auch ur das messen was sich vor dem Sensor befindet.

Wieso willst du wissen wei viele Objekte es gibt? Wichtig ist ja nur ob du fahren kannst oder nicht.

Willst du eine Karte erstellen muss man die Sache anders angehen. Da ist dann wieder scannen angesagt aber die zwei Sachen sind von Grund auf verschieden. Entweder du erstellst eine Karte, berechnest den Weg und fährst oder du hast ein ACS, Antikollisionssystem, fährst und erstellst derweil die Karte, so werde ich es machen.

Also die Frage ist wieso du wissen willst wie viele Objekte vor deinem Roboter sich befinden.

Also mir hat deine Erklärung wunderbar weiter geholfen (ich bin die letzten Tage nicht zu gekommen), allerdings habe ich es erstmal mit einer, sagen wir, einfacheren, Formel versucht.
Im Grunde wird nur aus dem aktuellen Sensorwert immer dann ein Offset errechnet, wenn der Sharp was findet- das ergibt von ganz alleine eine Abhängigkeit (bei entfernteren Hindernissen ergibt sich also automatisch eine kleinere Abweichung der Soll-Geschwindigkeit).
Funktioniert _so_ primitiv bereits erstaunlich gut, wenn auch noch nicht wirklich praxistauglich (bis jetzt habe ich den Winkel, in dem der Sensor wirklich steht noch gar nicht weiter gewertet), kommt noch.