Algorithmen zur Bahnplanung [Archiv]

Sternthaler

16.09.2007, 00:22

Hallo mare_crisium.
Na das ist doch auch für einen Mathe?-Hab-mal-davon-gehört-User lesbares Zeug. Wenn also der Handesvertreter seinen Weg mit A* plant, kommt er bestimmt leichter am Ziel an, als mit dem ersten Artikel von dir.

Eigendlich hatte ich bei der Frage von JackBauer eher an die geometrischen Grundlagen zum Einstellen von Radlenkung und/oder Geschwindigkeiten bei 2-rädriger Fortbewegung á la Asuro gedacht.
In den von dir geposteten Artikeln (ja, auch im ersten, so weit ich den überhaupt verstanden habe.) ist nichts dazu beschrieben, wie ich z.B. einen vorgegeben Kreis in Teilen abfahren kann, wenn ich die Geometrie meines Fahrzeugs kenne und diese Daten nutzen muss.

Jetzt auch mal ein Anhang von mir.
Im Excel-Blatt berechne ich anhand geometrischer Daten die zu fahrenden "Tik's" vom Asuro. Ein Tik ist ein messbarer Farbwechsel an der Odometrie, und gibt somit die gefahrene Wegstrecke an. (mal besser, mal schlechter) Die gesamte Berechnung beruht mehr oder weniger nur auf Pythagoras und PI, auch wenn die Formeln darin etwas 'verstrubbelt' sind. Ist vor allem auf eine INT-Berechnung getrimmt. Deshalb die oben rechts stehenden 'Zeilen' um 2 Faktoren zu ermitteln, die aus der Rad-Geometrie abgeleitet werden.

In Kombination mit dem A*-Dingsda, sollte nun alles beisammensein um Wege zu planen und auch auszuführen.

mare_crisium

16.09.2007, 23:37

Buona notte Sternthaler,

danke für die Tabelle - jetzt verstehe ich besser, worauf JackBauer aus war. Trotzdem würde ich's gern nochmal mit Mathe versuchen. Ich hatte mir vor einiger Zeit 'mal die Formeln für die Koppelnavigation eines Roboters von der Art eines Asuro zusammengestellt. In der angehängten pdf-Datei habe ich die ganze Herleitungsorgie weggelassen und nur das Endergebnis aufgeschrieben. - Ich weiss, meine didaktischen Fähigkeiten sind stark unterentwickelt, aber es würde mich interessieren, ob Du das lesen und verstehen kannst!

Der Witz an der Geschichte ist, dass man mit diesem Algorithmus das Fahren in vorbestimmten Richtungen und das Ansteuern von Zielorten mit einfachen Regelkreisen (ein Fahrgeschwindigkeits- und ein Richtungsregler) verwirklichen kann. Und das ist wesentlich eleganter, als die gesamte Bahnkurve mit Hunderten von Zwischenorten festzunageln. Dabei bleibt nämlich meist unbeantwortet, was der arme Roboter machen soll, wenn er einen der Zwischenpunkte verfehlt! Mit einem geschickt gewählten Regelkonzept erledigt sich diese Frage ganz von alleine.

Ciao,

mare_crisium

Edit: Anhang gelöscht wg. Upload-Quota

Sternthaler

17.09.2007, 18:49

Hallo mare_crisium, (noch eine Nachteule ;-) )
noch in der Firma, deshalb nur kurz mein 'Überflug'.
Im ganzen (auch für mich) recht gut verständliche.
Hier aber trotzdem ein paar Anmerkungen/Fragen:

- Bei Formel (1) wird angenommen, dass Nr und Nl bzw. Rr und Rl gleich sind? (gehe ich von aus, suche nur Bestätigung)

- Mir helfen bei Formeln allgemein die Einheiten. (1) also m/s und dann bei (2) bestimmt 1/s. (Nicht lebenswichtig, aber für Dummy's wie mich hilfreich)

- In Formel (7) verstehe ich absolut nicht, warum die px- und py-Anteile zur Berechnung von px' und py' gekreuzt werden und mal mit minus bzw. plus berechnet werden. (Grübel heute Nacht)
--- Ich sehe gerade, dass es doppelte Formelnummern gibt. Ich meine hier Formel (7) für die neue Fahrtrichtung ep'

- Bei der Berechnung der Abweichungen zur Ziel-Bestimmung ist mir klar wie es mit der Fahrt-Richtungs-Abweichung vor sich geht.
Bei der Ziel-Positions-Abweichung kann ich nicht folgen:
-- Start-Pos und Ziel-Pos berechnen eine Abweichung zum Startzeitpunkt. OK
-- Aktuelle Position wird laufend berechnet. OK
-- Ziel-Positions-Abweichung nun in Bezug zum ursprünglichen Start-Punkt? (Komme ich mit den Indices durcheinander?)

-- Und noch bei Formel (11): Als Fazit bedeutet dies doch, dass der Roboter dann je nach Entfernung zum Ziel die Geschwindigkeit anpasst? Somit müsste das letzte Stück Weg im 'Schneckentempo' zurückgelegt werden? Sollte hier eine Reglung mit Schwellwert sinnvoll sein?

Sonst ist das Ganze sehr lesbar. Kopie schon angefertigt ;-)

Gruß Sternthaler

[Edit 23:30]Was ich noch vermisse, sind Angaben über die X-, Y-Koordinaten bzw. die Einheiten von Start- und gewünschter Ziel-Position. Ist die ganze Mathematik da Einheitentolerant? Mein Startpunkt liegt bei 0/0, mein Ziel bei X/Y. Aber wie weit ist das weg? Meter / Dezimeter /Kilometer?
Wenn ich die Geschwindigkeit in m/s berechne, müsste dann wahrscheinlich meine Zielkoordinate auch in Metern als Abstand/X/Y angegeben werden. Richtig?

mare_crisium

17.09.2007, 23:32

@Sternthaler,

freut mich sehr, dass Dir meine Rechnerei verständlich ist! Deine Fragen bestätigen das. Hier sind die Antworten:

Formel (1): Nee, Rr und Rl müssen nicht gleich gross sein. Das ist einer der Vorteile dieses Algorithmus, das man damit auch Asuros lenken kann, die unterschiedlich grosse Räder und unterschiedlich starke Motoren haben. Man kann den Algorithmus praktisch an jeden Dreirad-Roboter anpassen.

Einheiten: Können ganz nach Belieben gewählt werden, müssen dann aber durchgängig eingehalten werden. Wegen der üblichen Dimensionen heutiger Wohnzimmer oder Küchentische würde ich für die Längen Zentimeter und für die Zeiten Sekunden verwenden. Aber wie gesagt, Meter und Minuten geht auch.

Formel 7: Vektoren in der x-y-Ebene kann man um 90° drehen, indem man x- und y-Komponente vertauscht und dann das Vorzeichen der neuen x-Komponente umkehrt. Diesen Trick verwende ich hier, um aus der Längs- (sprich: der Fahrtrichtung ep) die Querrichtung eq auszurechnen. Die Drehung der Fahrtrichtung durch die unterschiedlich schnell laufenden Räder stelle ich dar, indem ich zum Einheitsvektor in Längsrichtung ein bisschen vom Einheitsvekor in Querrichtung dazuzähle. Das dreht den Längsvektor, macht ihn aber auch ein bisschen zu lang. Deshalb muss er anschliessend wieder neu normiert werden.

Doppelte Formelnummern: Ächz! Es war schon spät. Hab sie in Version V02 korrigiert.

Zielpositions-Abweichung: Ja, in der Formel (jetzt Nr. 12) wird der Zielort immer mit denselben Koordinaten xs und ys eingesetzt. Was sich verändert , sind die Koordinaten xi und yi des Roboters und seine Fahrtrichtung, ausgedrückt durch px und py. Formel (12) verwendet das Kreuzprodukt zwischen der Fahrtrichtung und dem Differenzvektor vom Ort des Roboters zum Zielort.

Schneckentempo: Ja, Du hast recht. Es ist so wie mit Achilles und der Schildkröte: Je näher der Roboter dem Ziel kommt, desto langsamer wird er und er wird wegen der Reibung auch vor Erreichen des Zielorts zum Stehen kommen. Man kann diese Restdistanz in Grenzen mit dem P-Parameter des Fahrtgeschwindigkeits-Reglers einstellen. Oder aber man lässt den Regler die Fahrtgeschwindigkeit nur bis zu einem Minimalwert absenken und schaltet dann bei Erreichen des Ziels die Motoren ganz ab. Hängt ganz davon ab, ob man danach noch weitere Ziele anfahren will oder sonst noch was vor hat.

Ich habe die korrigierte Version 02 wieder angehängt. Darin präzisiere ich auch die Impulszählung (nr und nl) besser: Es dürfen ja immer nur die Impulse in die Berechnung eingehen, die seit der letzten Ablesung dazugekommen sind.

Jetzt ist nur noch die Frage, wie sich sowas mit dem Reglungskonzept eines Asuro verträgt.

Ciao,

mare_crisium

Edit: Anhang gelöscht wg. Upload-Quota

Sternthaler

18.09.2007, 00:32

Hallo mare_crisium,
oh kopfschüttel,
klar einen senkrechten Vektor kann man ja genau so ausrechnen. (Ist ganz einfach, wenn man einen gut erkläten Tritt in den Hintern bekommt.)

Mit den Einheiten bin ich einverstanden. Auch bei uns läßt sich der Küchentisch noch locker in cm ausdrücken, ohne den "unsigned char"-Bereich zu verlassen.

Mit den Rr und Rl bzw. N(rl) und n(rl) komme ich zu dieser Uhrzeit noch nicht klar. Im Moment sehe ich in (1) nur, dass du (PI * Rr / Nr) ausklammerst aus den beiden Geschwindigkeiten vr und vl. Weiters Grübeln ist da bei mir angesagt.

Zielpositions-Abweichung: Gut gebrüllt Löve. Ähh, gut erklärt. Ist mir nun auch klar geworden. Danke.

Zum Reglungskonzept im Asuro kann ich nur auf den Beitrag von waste hier (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=11818) hinweisen. Den von waste erstellten Code kann man sehr schön als allround-Code nutzen. Das Geheimnis bleibt natürlich in den PID-Parametern für die entsprechende Aufgabe.

Hier ist mal meine aktuelle Version vom Regelcode:

/************************************************** ***************************
FUNKTION: MotorPID
Aufgabe: Funktion zur Reglung der Motoren.
Diese Funktion bzw. die eigendliche Berechnung fuer die
Reglung wurde im Forum unter www.roboternetz.de von waste
entwickelt.
Von Sternthaler ist die Moeglichkeit hinzugefuegt, die
Reglerberechnung fuer unterschiedliche Regelaufgaben zu
nutzen.
Die Parameter steuern, welche Sensoren zur Reglung benutzt
werden sollen. Zum einen koennen es die Liniensensoren sein
um eine Linienverfolgung zu realisieren, zum anderen kann
der Regler zur Ueberwachung der Raddecoder genutzt werden.
Parameter:
************************************************** ***************************/
unsigned char MotorPID (
unsigned char regler,
char speed,
int links,
int rechts)
{
int LWert = 0, RWert = 0;
int absLinks = 0, absRechts = 0;
float faktor;
static int x, x1, x2, x3, x4;
static int xalt, drest, isum;
int kp = 0, kd = 0, ki = 0;
int yp, yd, yi, y, y2;
int LSpeed, RSpeed;
unsigned char LDir, RDir;
unsigned char use_regler = TRUE;

switch (regler)
{
case PID_LINIE:
links = rechts = 1; // erzwingt vorwaertsfahrt
LineData (); // Liniensensoren
LWert = sens.linie [LINKS_DUNKEL] - sens.linie [RECHTS_DUNKEL];
RWert = sens.linie [LINKS_HELL] - sens.linie [RECHTS_HELL];
/* DIESE PARAMETER WURDEN VON waste IM FORUM UNTER
https://www.roboternetz.de
ENTWICKELT.
*/
kp = 5; // Parameter kd enthält bereits Division durch dt
ki = 5;
kd = 70;
break;
case PID_ODOMETRIE:
if (links == 0 || rechts == 0)
use_regler = FALSE;
else
{
absLinks = abs (links);
absRechts = abs (rechts);
/* Odometrie-Zaehler so justieren, dass fuer eine Kurvenfahrt
die Tic-Anzahl auf beiden Seiten identisch aussehen.
Die Seite auf der weniger Tic's zu fahren sind wird auf die
hoehere Anzahl 'hochgerechnet'.
*/
if (absLinks < absRechts)
{
faktor = (float)absRechts / (float)absLinks;
LWert = sens.rad_tik [LINKS] * faktor;
RWert = sens.rad_tik [RECHTS];
}
else
{
faktor = (float)absLinks / (float)absRechts;
LWert = sens.rad_tik [LINKS];
RWert = sens.rad_tik [RECHTS] * faktor;
}
/* Diese Parameter wurden von Sternthaler durch probieren ermittelt.
*/
kp = 65;
ki = 6;
kd = 90;
}
break;
}

LSpeed = (int)(speed - hw.motor_diff / 2); //Wunschgeschwindigkeit vorgeben
RSpeed = (int)(speed + hw.motor_diff / 2); //Hardware beruecksichtigen

if (use_regler == TRUE)
{
/* AB HIER IST DIE BERECHNUNG VON waste IM FORUM UNTER
https://www.roboternetz.de
ENTWICKELT WORDEN.
*/
x1 = RWert - LWert; // Regelabweichung

x = (x1 + x2 + x3 + x4) / 4; // Filtert die 4 letzten Werte
x4 = x3; x3 = x2; x2 = x1; // Pipe ueber die letzten 4 Werte

isum += x; // I-Anteil berechnen
if (isum > 16000) isum = 16000; // Begrenzung: Überlauf vermeiden
if (isum < -16000) isum = -16000;
yi = isum / 625 * ki;

yd = (x - xalt) * kd; // D-Anteil berechnen und mit nicht
yd += drest; // berücksichtigtem Rest addieren
if (yd > 255) drest = yd - 255; // Eventuellen D-Rest merken
else if (yd < -255) drest = yd + 255;
else drest = 0;

yp = x * kp; // P-Anteil berechnen

y = yp + yi + yd; // Gesamtkorrektur
y2 = y / 2; // Aufteilung auf beide Motoren
xalt = x; // x merken

if (y > 0) // Abweichung nach rechts
{
LSpeed += y2; // links beschleunigen
if (LSpeed > 255) // wenn Wertebereich ueberschritten
{
y2 += (LSpeed - 255); // dann Rest rechts berücksichtigen
LSpeed = 255; // und Begrenzen
}
RSpeed -= y2; // rechts abbremsen
if (RSpeed < 0) // Auch hier Wertebereich
{
RSpeed = 0; // beruecksichtigen
}
}
if (y < 0) // Abweichung nach links
{
RSpeed -= y2; // rechts beschleunigen
if (RSpeed > 255) // wenn Wertebereich ueberschritten
{
y2 -= (RSpeed - 255); // dann Rest links berücksichtigen
RSpeed = 255; // und Begrenzen
}
LSpeed += y2; // links abbremsen
if (LSpeed < 0) // Auch hier Wertebereich
{
LSpeed = 0; // beruecksichtigen
}
}
}

/* Und wieder (fast) waste
*/
if (links >0) LDir = FWD; else if (links <0) LDir = RWD; else LDir = BREAK;
if (rechts>0) RDir = FWD; else if (rechts<0) RDir = RWD; else RDir = BREAK;

if (LSpeed < 20) LDir = BREAK; // richtig bremsen
if (RSpeed < 20) RDir = BREAK;
MotorDir ( LDir, RDir);
MotorSpeed (abs (LSpeed), abs (RSpeed));

return 0;
}

Ist so angepasst, dass sowohl der ehemalige von waste programmierte Zweck zur Linienverfolgung, als auch eine Reglung für ein Geradeausfahren, nun möglich sind. Klar, der Aufrufer muss ein abgestimmtes Timing haben, sonst stimmen die zeitabhängigen PID-Parameter nicht zur Regelungsaufgabe. Da waste im 2ms-Raster rechnete, sollte das Ding halt alle 2ms aufgerufen werden.
Aktuell geht es in dieser Version nicht, dass beide Regler gleichzeitig nutzbar sind, da innerhalb der Funktion die genuzten static-Variablen nur einmal vorhanden sind. Erzeugt man ein Array für die Variablen mit Variable/Parameter regler als Index, sollte das auch erledigt sein.
Ich sehe gerade, dass noch ein bisschen 'Beiwerk' fehlt.
- Variable hw.motor_diff kann mit 0 ersetzt werden.
- Variablen sens.linie[0-3] sind die automatisch im Interrupt ermittelten Messwerte der Liniensensoren für links/Rechts Hell-/Dunkelmessung
- Variablen sens.rad_tik[0-1] sind die, auch im Interrupt, ermittelten Hell-/Dunkelwechsel an den Odometriescheiben.
(Bei Bedarf poste ich den kompletten Code)

Mal sehen, wann wir google mit einem Asuro auf dem Mond überraschen ;-)

Eine Gute Nacht wünscht Sternthaler

mare_crisium

18.09.2007, 18:16

Guten Abend (diesmal nicht Nacht!!), Sternthaler,

danke für Deine Anmerkungen zu meinem Algorithmus! Oh, Mann, hätte ich Deine erste Mail gleich richtig gelesen, dann hätte mir der Fehler schon gestern auffallen müssen! Natürlich kann man die Radien nur vor die Klammer ziehen, wenn sie gleich sind. -

Ich habe den Fehler in der angehängten Version 03 verbessert und auch die Erklärung für das Vertauschen der Komponenten eingefügt. Als Goodie habe ich noch eine Erweiterung angefügt, mit der man den Roboter dazu kriegt, einen Zielort anzusteuern und ihn in einer vorbestimmten Richtung zu durchfahren.

- Dein Programm kann ich nicht so gut lesen, weil ich mich bisher immer geweigert habe, C auch nur mit spitzen Fingern anzufassen. Ich mache auf dem AVR alles in Assembler und auf dem PC mit Delphi oder Lazaraus. Aber ich versuch's mal.

Ciao und schönen Abende,

mare_crisium

Edit: Anhang gelöscht, wg. Upload-Quota

Sternthaler

18.09.2007, 22:01

Hallo mare_crisium, irgendwie schwächeln wir so mitten in der Arbeitswoche. Auch bei mir wird es immer früher.

Deine Erklärung mit dem Jadhund ist für mich total einleuchtend. So stelle ich mir angewande Mathematik vor \:D/

Bei der Ermittlung der Regelabweichung, bzw. welche benutzt werden soll, in Formel (14) könnte es eventuell ein Problem geben, wenn beide Abweichungen genau den gleichen Betrag haben, aber die Vorzeichen unterschiedlich sind. Dann liefert die Funktion doch eine Abweichung von 0.
Mach dies Sinn, oder ist dieser Zustand nur kurzfristig zu erwarten, da die Maschine ja noch fährt und alles im Fluß ist?

Sonst kann ich nur sagen: Das ist endlich mal etwas handfestes.

Ich glaube, ich muss demnächst ein paar Regler mit Parametern füttern.
Bei mir dauert so was aber immer etwas. ;-)

Noch einen schönen Abend wünscht Sternthaler

P.S.: Heißt das wirklich Lazaraus und nicht Lazarus? Unter Lazarus kenne ich eine IDE für Pascal, glaube ich.

mare_crisium

18.09.2007, 23:47

Nur um die Nachteulen-Ehre zu retten: Buona notte, Sternthaler,

es freut mich richtig, dass Du was damit anfangen kannst! - Der Zustand, in dem sich in Formel (14) beide Stellsignale kompensieren, ist nur vorübergehend. Es wäre ein grosser Zufall, wenn bei der nächsten Berechnungsrunde, nachdem sich der Roboter weiterbewegt hat, wieder eine Null herauskommt.

Ja, natürlich hätte es Lazarus heissen müssen und es ist eine IDE für Free Pascal. Ich habe mal in der Schweiz gearbeitet und seither habe ich eine Schwäche für die Sprachen von Herrn Wirth ;-).

Mit dem Einstellen von Reglerparametern habe ich ziemlich viel Erfahrung. Wenn Du so weit bist, meld' Dich nochmal!

Ciao,

mare_crisium

JackBauer

19.09.2007, 09:58

So, erstmal danke für die vielen Antworten. War ein paar Tage weg und hab sie erst jetzt gesehen. Der A* Pathfinding for Beginners Artikel und die Webseite davon sehen vielversprechend aus, der Rest etwas kompliziert. Aber ich werde mir jetzt erstmal alles genauer anschauen.

Nochmal zu meiner Frage. Der Roboter soll:
1. einzelne Punkte im Raum anfahren können
2. den ganzen Raum möglichst vollständig abfahren

So wie ich das bis jetzt sehe ist der A* ist für Punkt 1 gut. Was gibt es für Punkt 2?

mare_crisium

19.09.2007, 18:50

@JackBauer,

schön, dass Du noch dabei bist! Einen Vorschlag für Deinen Punkt 2 habe ich noch nicht, weil ich dazu mehr Details über Deine Aufgabenstellung wissen müsste. Meld' Dich mal, wenn Du Dir alles genauer angesehen hast. -

Übrigens: Der A*-Algorithmus allein wird Dir nicht helfen, denn um den zur Navigation anzuwenden zu können, muss Dein Roboter wissen, in welchem Planquadrat er sich gerade aufhält und was seine augenblickliche Fahrtrichtung ist. Das kann er nur, wenn Du in Dein Projekt auch etwas "Kompliziertes", mindestens eine Koppelnavigation, einbaust.

Ciao,

mare_crisium

mare_crisium

22.09.2007, 05:33

@Sternthaler,

bin heute morgen aus dem Bett gefallen :-( und hatte dann Zeit genug, mir was zu Deiner Programmstruktur auszudenken :-). Ich hänge das kommentierte Programm als pdf-Datei an.

Ciao,

mare_crisium

Edit: Anhang gelöscht wg. Upload-Quota

Sternthaler

23.09.2007, 16:46

@mare_crisium,
ach du Ärmster. Am Wochenende um 6:33 schon am PC hocken? Mir würde man dann eher nachsagen, dass ich durchgemacht hätte. Hatte ich eigendlich auch von dir angenommen ;-)
Jedenfalls hast du die Zeit gut genutzt und dich in C perfekt eingearbeitet um dann so viel Mathe und Vorschläge in das Programm zu bringen, dass mir die Ohren flattern.

Ja, das mit dem Datenrecorder wäre schon genau das Richtige. Nur würde ich diese Möglichkeit keinesfalls auslagern, sondern bewußt in der MotorPID()-Funktion integrieren. Dann kann auch auch nicht vergessen werden diese Datenrecorder-Funktion aufzurufen.
Etwa folgendermaßen:

unsigned char MotorPID (
unsigned char regler,
char speed,
int links,
int rechts)
{
/* Speicher für den Datenrecorder */
static int x [ANZ_REGLER], xalt [ANZ_REGLER];
static int x1 [ANZ_REGLER], x2 [ANZ_REGLER];
static int x3 [ANZ_REGLER], x4 [ANZ_REGLER];
static int drest [ANZ_REGLER];
static int isum [ANZ_REGLER];

/* Die lokalen Arbeitsvariablen */
int x, xalt;
int x1, x2;
int x3, x4;
int drest;
int isum;
.
.

/* Die lokalen Arbeitsvariablen mit den 'Recorderdaten' füttern. */
x = x [regler];
xalt = xalt [regler];
x1 = x1 [regler];
x2 = x2 [regler];
x3 = x3 [regler];
x4 = x4 [regler];
drest = drest [regler];
isum = isum [regler];

switch (regler)
{
case PID_LINIE:
.
.
break;
case PID_xxxx:
.
.
break;
case PID_yyyy:
.
.
break;
}
.
.

/* Die lokalen Arbeitsvariablen in den 'Recorderdaten' sichern. */
x [regler] = x;
xalt [regler] = xalt;
x1 [regler] = x1;
x2 [regler] = x2;
x3 [regler] = x3;
x4 [regler] = x4;
drest [regler] = drest;
isum [regler] = isum;
}

Das ist aber nur technischer Schnickschnack.

Zu den anderen Anmerkungen kann ich leider nichts sagen. Da ist mir die Mathematik zu weit weg, von meinem Hausgebrauch-Rechnen.
Ein Hinweis evl. zu der Halbierung des berechneten y-Korrekturwertes. Waste teilt hier, so wie ich es Verstanden hatte, ja den Gesamt-Korrekturwert doch nur auf beide Motoren auf. Da mir dies bei der 'Verfolgung der Zusammenhänge' in seinem Thread eigendlich recht einleuchtend vorkam, ist das doch dann die logische Konsequenz daraus. Warum also den Weg zur Ermittlung der Parameter schon so gestalten, dass man hinterher nicht mehr 'nur' durch 2 teilen muss?

Auch hätte ich Probleme beim Auslagern der endgültigen 'Einstellerei' der Motor-Leistung und den Motor-Richtungen. Wobei die Berechnung der linken/rechten Motorwerte wieder über 'Summen', 'Quotienten' und 'sonstig kompliziertem' ausserhalb erfolgen muss.
Das halte ich für kritisch, da ich es eher sehen würde, dass sich eine Funktion (von mir aus auch mit Hilfsfunktionen, die ich aber nie in meinem Hauptprogramm aufrufe) um ihren Kram komplett alleine kümmern soll.
Ich selbst würde die Parameter so halten, dass meine Wünsche da rein gehen. Hier also etwa: 'Mittlere Geschwindigkeit'; 'Absolute Anzahl Tiks links+Absolute Anzahl Tiks rechts'; oder 'Zielkoordinate X+Zielkoordinate Y'. Das Ganze sollte dann die Funktion 'von alleine' auflösen und sich dann die benötigten Messwerte holen, berechnen und irgendwie sinnvolle 'Summen' und 'Quotienten' bilden.

Natürlich kann man deinen Vorschlag ja auch in einer Funktion 'verpacken' und hätte dann meine Vorstellung erhalten. (Wie viel Wege führten nochmal nach Rom?)

Ob die Mittelwertbildung durch eine Anpassung an dem P-Regelwert überflüßig ist kann ich nicht beurteilen. Allerdings würde ich nicht so pauschal sagen, dass nur die Liniensensoren streuen. Auch die Odometriedaten sind nicht so richtig sauber.
Aber wenn ein neuer P-Wert das alles ausbügeln kann, dann nichts wie weg mit dem Mittelwert.

Tja, und bei dem Rest kann ich nur sagen: Der "Alzheimer"-Faktor ist bei mir auf alle Fälle > 1, wenn es um die ehemals im Studium gelernte Mathematik geht. ;-)

Einen schönen Rest-Sonntag wünsche ich noch.
Gruß Sternthaler

mare_crisium

24.09.2007, 18:00

Sternthaler,

oh, je! So heftig wollte ich am heiligen Sonntag Morgen Deine Ohren nicht misshandeln ;-)! - Mir kamen die paar Kommentare, die ich Dir ins Programm geschrieben habe, viel einfacher vor, als das Vektor-Jonglieren bei dem Du voher so tapfer mitgehalten hattest.

Es gibt nichts Schlimmeres, als ein gut laufendes Programm zu "verbessern". Deshalb habe ich vollstes Verständnis für Deinen Entschluss, es so zu lassen wie's jetzt ist. Hauptsache ist, die Beschäftigung mit dem Thema macht Spass!

Ciao,

mare_crisium

Sternthaler

24.09.2007, 18:15

Volles Programm: JA, MACHT SPASS (bewußtest Uppercase !)

Geistiger Input ist doch dann nur klasse, wenn man nicht sofort alles Versteht, aber man noch das Licht am Ende des Tunnels erahnen kann, bzw. man auch seine Grenzen kennt.
Meine Anmerkungen aber bitte nicht missverstehen. Ist kein "ich will das aber so", sondern nur meine persönliche Denke. Die (manchmal ;-) ) auch was neues, anders als besser akzeptiert.

Ich bin aber immer noch nicht so weit eine Zeile Code zu schreiben. Dieser Eintrag entsteht just gerade noch in der Firma. Und ob ich dann Zuhause noch Bock habe bezweifel ich jetzt schon.

Gruß Sternthaler

plusminus

30.09.2007, 22:34

> http://href.to/fQ3 <-- Hinführung zum Wegfindungs.Thema aus einem Uni-Vorkurs; Ameisen-Algorithmus & Dijkstra
> http://href.to/ki1 <-- Dijkstra mathematisch
> http://href.to/Yh3 <-- AStar Sehr einfach erklärt

grtz

Sternthaler

01.10.2007, 02:34

Hallo plusminus,
gute Lektüre (der letzte Link ist von mare_crisium schon am 13.09.2007 angegeben worden. Ähnliche Version)
Die Vorlesung aus dem ersten Link habe ich mal überflogen und kann dem ganzen sogar folgen. Was ich beim 2-ten Link zu dieser Stunde nicht mehr sagen kann.
Kleine Frage: Wie lange brauchen Ameisen eigendlich von Imstadt nach Oppenheim? ;-)

Jetzt gehe ich aber doch erst mal in's Bett.
Morgen berichte ich dann mal von meinen ersten Codezeilen zur Umsetzungen der mare_crisium-Version zum Zielanfahren. (Werden aber erst einmal mehr Fragen als Antworten.)

Gute Nacht, und/oder guten Morgen.

plusminus

01.10.2007, 07:43

gedopte Ameisen bitte ;)

Sternthaler

01.10.2007, 09:29

Hhhmmm, dann tippe ich darauf, das die Fahräder haben.

Sternthaler

03.10.2007, 23:45

Hier nun mal im Telegrammstil meine bisherigen Überlegungen: (beim Asuro, bei einer vorgegeben Odometriehardware)

- Bestimmung der Geschwindigkeit v= m/s

Wird m als Messwert genutzt, und s ist bekannt, dann liegt m beim Asuro bei ca. 0,15 cm pro Einheit.
Da nur ganzzahlige Einheiten bekannt sind, ergeben sich somit von Einheit zu Einheit relativ große Fahrstrecken, die prozentual einen großen Fehler darstellen, wenn in kleinen Zeitintervallen gemessen wird.
Werden die m-Einheiten erst nach einer relativ großen Fahrstrecke ausgewertet, dann ist das Fahrzeig aber auch schon sehr weit 'steuerlos' gefahren.

Deshalb der Ansatz m konstant zu halten und s als Messwert zu nutzen.
Wenn m mit einer Einheit ca. 0,15 cm darstellt, und der schon laufende Timer2-Zähler mit 36 kHz benutzt wird, kann pro Fahreinheit m je nach Geschwindigkeit ein Zählerwert von 100 (ca. 50cm/s) bis 550 (ca 10 cm/s) erwartet werden. Somit ist der Verlust des Nachkommanteils immer kleiner als 1%.
(Der EXCEL-Anhang stellt dies dar.) 2 Berechnungen daraus hier als Bildanhang.

Aber folgendes Problem tritt auf:
Der erkannte Wechsel der SW-Teilung auf der ODO-Scheibe erfolgt auch bei gleichmäßiger Fahrt nicht in gleichen Zeiteinheiten.
Soll heißen, dass der erwartete Wert von beispielsweise 256 bei einer Geschwindigkeit von 20cm/s beim Asuro nicht kontinuirlich zu messen ist.
Dieser Wert schwankt in 2 Zyklen.
1. Die zeitliche Breite von weis und schwarz auf den ODO-Scheiben ist unterschiedlich.
2. Durch wahrscheinlich nicht zentriertes Anbringen der ODO-Scheibe 'eiert' die Zeit pro Umdrehung derselbigen.
Beides hatte waste auch schon mal ermittelt. (Bin relativ sicher, das es waste war)

Hier stellt sich nun die Frage, wie man am besten diese beiden 'Eier'-Werte mitteln könnte, ohne möglichst viel Genauigkeit zu verlieren.
Ich hoffe auf reichliche Integrale und Ableitungen ;-)

mare_crisium

04.10.2007, 21:01

SternTahler,

nein, heute wird nicht integriert! :-)

Ich bin mit Deiner Tabelle nicht ganz klar gekommen; deshalb erzähle ich mal, wie ich Dich verstanden habe:

Du versuchst bei der Odometrie eine bessere Messgenauigkeit zu erreichen, indem Du anstelle der Anzahl Sektoren pro Zeiteinheit, die Zeiteinheiten zwischen zwei Sektorenflanken misst. Diese Zeitspanne ist genau definiert, während man bei der anderen Methode nie so recht weiss, an welcher Stelle zwischen zwei Sektoren man sich zum Zeitpunkt der Messung gerade befindet. - Richtig? Mit der Zeitmessung kann man auch sehr gut die aktuelle Umdrehungszahl des Rades abschätzen und im Prinzip daraus zu jedem beliebigen Zeitpunkt den aktuellen Drehwinkel des Rades, d.h. den zurückgelegten Weg, angeben.

Beim Messen der Zeitdifferenzen hast Du eine Streuung festgestellt, die Du auf einen Zentrierfehler zwischen den Mittelpunkten der Sektorenscheibe und des Zahnrades zurückführst. - So, wie die Konstruktion des ASURO auf den den Fotos aussieht, hast Du wahrscheinlich recht.

Die angehängte Tabelle zeigt, wie sich der Zentrierfehler (Zentrum der Sektorenscheibe ist um einen einstellbare Entfernung und einer einstellbaren Richtung vom Zentrum des Zahnrades verschoben) auf den Zeitpunkt der Sektorflanke auswirkt. Alle Zahlen in den grün unterlegten Zellen können verändert werden. Die letzte Spalte zeigt für jeden Sektor die vom Zentrierfehler verursachte Zeitdifferenz.

Im ASURO-Wiki

http://www.asurowiki.de/pmwiki/pmwiki.php/Main/Odometrie

ist auch ein Link auf den Thread im Roboternetz, in dem waste sich zu dem Problem äussert und eine Lösung für das Geradeausfahrt-Problem angibt.

Ehrlich gesagt, der Zentrierfehler sollte nicht so stark durchschlagen. Er mittelt sich ja bei Geradeausfahrt auch über jdede volle Umdrehung wieder aus. Das wird erst anders, wenn der ASURO seine Fahrtrichtung sehr schnell ändert. Ich tippe eher auf die mechanischen Einflüsse, die in dem Thread erwähnt werden (Zahnradspiel, Motoraufhängung usw.).

Ciao,

mare_crisium

Edit: Anhang gelöscht wg. Upload-Quota

Sternthaler

05.10.2007, 00:30

Hallo mare_crisium.

nein, heute wird nicht integriert! :-)
Uff, noch mal Glück gehabt.

... Du versuchst bei der Odometrie eine bessere Messgenauigkeit zu erreichen, ....
Hast du ja doch alles verstanden, was ich mit den Tabellen ausdrücken wollte. (Habe ich genau so bei dir erhofft.)

... eine Streuung festgestellt ...
hast Du wahrscheinlich recht.
Ist mir durch den Beitrag von waste erst bewust geworden. (Den Beitrag werde ich bestimmt noch mal wiederfinden. Es war definitiv nicht der aus dem von dir angegeben Wiki-Beitrag.)
Scheint aber tatsächlich so zu sein, da ich seine Messungen auch nachvollziehen kann.
Genau hier setzte ja nun meine Frage nach Intergralen und Ableitungen an.
Wenn ich es mir so überlege, müsste aber dieser ganze Fehlerkram über eine Anpassung beim I-Wert für einem Regler der Geschwindigkeit ausgebügelt werden können. (Ich glaube, dass I für 'ungleichmäßige' Veränderungen zuständig ist. Namentlich 'integriert', müsste es doch Flächen unter Kurven 'zusammenmitteln' und somit 'flatternde' Änderungen irgendwie glätten.)

Bei deiner Tabelle kann ich bis auf Eingaben <> 0 in E4 "Winkel <x-Achse|Mitte_Odo_Scheibe>" gut folgen. (Auch Spalte E macht mir Kummer, wenn bei negativem Bogenmaß noch 180 Grad addiert werden.)
Aber, ja, genau die in Spalte H ermittelte Zeitdifferenz ist das Problem, welche durch einen Regler 'gefiltert' werden muss.
Gerade die Zeitdifferenzen in der von dir ausgerechneten Spalte H sind meine 'Bauchschmerzen'. (Nix Mathe; Bauch ist bei mir der Maßstab. Pizza mit vielen Pilzen [fest und flüßig] kann ich immer vertragen. ;-) )

Im ASURO-Wiki ...
Schade, das in dem von dir angegeben Wiki-Beitrag 2 Links auf die gleiche Seite zeigen. Hat aber nichts mit meiner Haarspalterei zu tun.

Ehrlich gesagt, der Zentrierfehler sollte nicht so stark durchschlagen.
Ja, ja, ja, das genau wollte ich hören.

Ich werde also die weiteren Programmstückchen erst einmal mit diesen 'Bauchschmerzen' fortführen und weiter berichten/fragen.

Noch eine ruhige Nacht wünscht
Sternthaler

mare_crisium

08.10.2007, 16:50

Sternthaler,

so, jetzt kann ich die korrigierte Tabelle schicken. Mit der Eingabe "Winkel <x-Achse|Mitte_Odo_Scheibe>" wollte ich berücksichtigen, in welche Richtung die Sektorscheibe, relativ zur x-Achse, verschoben ist. Das habe ich jetzt einfach weggelassen, weil dieser Winkel das "Eiern" nur in der Phase verschiebt; die Grösse der maximalen Wegdifferenz bleibt davon unbeeinflusst. Die Addiererei mit 2*pi() usw. kommt von der Mehrdeutigkeit des arctan und sollte Dich nicht weiter beschäftigen. Oben habe ich jetzt die Summe der Wegdifferenzen über eine volle Radumdrehung eingestellt: Sie ist immer Null, wie Du schon vermutetest.

Das bedeutet: Bei Geradeausfahrt kann der ASURO wohl ein bisschen schlängeln, aber es geht nix schief. Aber wenn's um die Kurve geht und ein Rad schneller dreht als das andere, dann mitteln sich die Fehler nicht mehr aus. Am Ende der Kurve bleibt ein Restfehler, dessen Betrag ungefähr zur Differenz der Umdrehungsgeschwindigkeiten, also zum Kurvenradius, proportional ist.

Wenn Du das ausgleichen willst, musst Du nicht am Regler basteln, sondern an der Wegmessung (Odometrie): Der Fehler ist abhängig davon, welche Stellung die Räder beim Einleiten und am Ende der Kurvenfahrt hatten. Du müsstest also nicht nur die Umdrehungsgeschwindigkeit erfassen, sondern den echten Drehwinkel jeweils für jedes Rad. Das lässt sich bewerkstelligen, indem Du den ASURO immer mitzählen lässt, welche Nummer der Sektor hat, den seine Lichtschanken gerade erfassen. Dann müsstest Du ihm für jedes Rad eine Tabelle mitgeben, die für jeden Sektor die zurückgelegte Wegdifferenz angibt. Der ASURO muss dann bei einem Sektorwechsel anhand der Nummer des aktuellen und des vorhergehenden Sektors in der Tabelle nachgucken, welche Wegstrecke diesem Wechsel entspricht und die dann zum bereits zurückgelegten Weg dazuzählen. Im Grunde ist das einfach eine kalibrierte Wegstreckenmessung.

Das zu Programmieren ist eigentlich kein Kunststück. Aber zu diesem Zeitpunkt in Deinem Projekt geht's ja mehr um das Prinzip, als um den letzten Millimeter an Genauigkeit. Deshalb rate ich, diesen Schritt erst am Ende einzubauen, wenn sicher ist, dass alles andere richtig funktioniert.

Ciao,

mare_crisium

Edit: Anhang gelöscht wg. Upload-Quota

Sternthaler

10.10.2007, 03:20

Hallo mare_crisium,
damit es nicht langweilig wird, hier jetzt auch mal ein paar Messdaten.

Daten in den einzelnen Blättern:
daten-01:
Die Spannungsmesswerte der ODO-Sensoren bei ASURO-Speed 180

daten-02 bis daten-04:
Zeitwerte zwischen 2 Tik-Wechseln bei ASURO-Speed 180

daten-05 bis daten-07:
Zeitwerte zwischen 2 Tik-Wechseln bei ASURO-Speed 255 (Maximum)

Wie man sehen kann, ist die linke Sensorik (immer in blau dargestellt) nicht so gut wie die rechte Seite. Da habe ich schon zu viel an der Messscheibe 'herrumgemacht' für andere Test's.

Bei den daten-02 bis daten-07 habe ich die X-Achse mal in 16er-Schritte geteilt, da dies ja bei mir die Anzahl Tik's pro Umdrehung ist.
Hier kann man nun, vor allem auf der rechten/roten Seite, sehr schön sehen, dass die Scheibe 'eiert'.
Und natürlich sieht man bei dem kontinuierlichen hoch und runter der Messwerte, dass die Zeiten zwischen der weissen und schwarzen 'Messfläche' lustig vor sich hin hüpfen.

Um heute auch noch etwas kurz auf deinen Beitrag einzugehen:
Dieses 'hin und her hüpfen' der Messdaten wollte ich eventuell von dem Regler ausgleichen lassen. Das der Asuro keine Präzisionswege fahren kann, hatte ich schon beim Nikolausfahren festgestellt.
Im übrigen ist dein zuletzt geposteter Anhang sehr aufschlußreich was die zu erwartenden Fehler angeht. Ist ja nicht die Welt, so dass man hier auf alle Fälle weitermachen kann ohne nicht ein bisschen Erfolg (in Zukunft) zu erhaschen.

Zum staunen hier ein, von Manf an anderer Stelle geposteter Link, über fahrende CPU's: http://www.spiegel.de/videoplayer/0,6298,22553,00.html

Nächtliche/Morgendliche Grüße von
Sternthaler

oberallgeier

10.10.2007, 10:25

Hei, JackBauer,

hmm, ich trau´s mich fast nicht zu sagen. Vor 25 Jahren habe ich eine Arbeit geschrieben über Bahnberechnung (für den ToolCenterPoint eines Knickarmroboters). Dabei geht es um frei im Raum wählbare Bahnen, die durch Stützpunkte definiert sind. Die theoretische Bahn besteht also aus Geradenstücken - denk mal an ein windschiefes Gerüst (so ähnlich). Daraus wird die physikalisch mögliche Bahn berechnet durch Interpolation. Das ist in den (bei der Interpolation natürlich abgerundeten) Eckpunkten von Wichtigkeit, weil ich nur endliche Beschleunigungen vorgeben kann. Es betrifft also die Bahnplanung für das Gerät. Ich könnt die ersten zehn Seiten mit den Grundlagen posten - wenn das von Interesse ist.

Sternthaler

10.10.2007, 11:00

Hallo oberallgeier,
schön, wenn noch weitere Anmerkungen kommen. Da fühlt man sich nicht so alleine bzw. zu zweit ;-)
Ja, das Thema muss schon längst beschrieben, und gelöst, worden sein, denn sonst würde bestimmt kein einziger Industrieroboter die Tür am Türholm festschrauben können.

Du sprichst von 'endlicher Beschleunigung', die in den Eckpunkten von Bedeutung ist. Hat dies damit zu tun, dass z.B. bei der Verzögerung kurz vorm 'Abbiegen' die Kraft nicht ausreicht, um am vorgegeben Punkt zu stoppen. Also ein Überschwingen?
Wenn ich so halbwegs mitgekommen bin, dann würde mich auf alle Fälle deine Arbeit interessieren, da ich aus den Beschreibungen von mare_crisium's Ansatz eher das Gegenteil erwartet hatte. -> Vor dem Ziel stehen bleiben, da die Geschwindigkeit zum Zielpunkt ja mit der Distanz dorthin auch reduziert wird, was irgendwann zum 'stecken bleiben' wegen Reibung und so führen wird. (Wenn man nicht was dagegen macht.)

Gruß Sternthaler

oberallgeier

10.10.2007, 11:36

Hei Sternthaler,

hihihi - genau! Das ist ja der Trick beim Ganzen. Mal etwas beispielhaft:
Wenn Du mit dem Auto durch Mannheim fährst (oder sonst ein Dorf mit rechtwinkligem Strassennetz) - bretterst Du dann auch immer mitten in die Kreuzung um dort mit Notbremsung zu bleiben und die neue Richtung zu peilen? Neeeee! Eben. Ein bisschen Vorausschau tut schon gut.

Also wird VOR der Ecke (die ist ja bei diesen Raumbahnen - es sind keine als Funktion darstellbaren Kurven - ein singulärer Punkt) überlegt, wann ich mit welcher Beschleunigung abbremsen muss, um in die von mir geplante neue Richtung zu kommen - - die dann für sich selbst neue Beschleunigungen erfordert. Das geht im Raum ebenso wie auf der ebenen Strasse. Und man will ja eben nicht zum Stillstand kommen - müssen.

Es geht bei dieser Vorplanung weniger darum, dass nicht genug Kraft da ist, als vielmehr die Struktur nur soweit zu beschleunigen und zu belasten, dass Überschwingen, Schwingungen insgesamt, vermieden wird/werden. Daher hatte ich (in einer späteren Realisierung) statt einer Beschleunigungsrampe eine Rampe für die Beschleunigung zweiten Grades genommen (also für die Zunahme der Beschleunigung :) )

Ok, ich will mal meinen Scanner anwärmen - und dann kommt bald was.

PS: meine Bahnberechnung läuft in einigen IR´s - fahr mal nach Rastatt z.B.....

oberallgeier

10.10.2007, 13:45

... schön, wenn noch weitere Anmerkungen kommen Ok, dann also hier der Auszug. Es ist darin nicht so viel Gewicht auf die dahinterliegende Theorie gelegt, als vielmehr auf die Technik, wie das realisiert wird. Also weniger die Mathematik des Raumes, sondern mehr numerische Mathematik und Lösungssystematik. Aber ein bisschen (viel) theoretischer Hintergrund war schon dabei ...

Die Quellen sind in Fortran. War damals so.

Ich hoffe, dass das ein bisschen weiterhilft.

oberallgeier

10.10.2007, 14:23

Bahhhh, der pdf-Text ging nicht mit. Lag´s an den vier MB???

oberallgeier

10.10.2007, 17:30

Transpirier, transpirier, ohwehhh, oh OCR.

Aber jetzt hab ich den Text eingescannt, OCR-risiert, korrigiert (und gestöhnt, gestöhnt, gestöhnt).

Sternthaler

10.10.2007, 18:28

Hallo oberallgeier,
oh je, jetzt hast du dir aber eine Menge Arbeit gemacht.
Ich habe das Ganze erst einmal gespeichert (leider noch nicht im Kopf) und werde erst später zum lesen kommen. Im Badezimmer fehlen immer noch die Tapeten an den Wänden. :frown:

Einen kurzen Überflug habe ich schon versucht, aber um einen "masseloser tool center point" zu verstehen, muss man sich doch etwas mehr Zeit nehmen.

Bis später, und schon mal vielen Dank für deine Mühe.
Gruß Sternthaler

P.S.: Wieso muss man beim abbiegen bremsen? Ach stimmt ja, auch die Handbremse für rechtwinkliges 'Kurven' bremst ja ;-) .

oberallgeier

10.10.2007, 18:51

Hallo Sternthaler,

P.S.: Wieso muss man beim abbiegen bremsen? Ach stimmt ja, auch die Handbremse für rechtwinkliges 'Kurven' bremst ja ;-) .Ist doch einfach: Du fährst, sagen wir mal genau, nach Norden und biegst nach genau Osten ab (90 ° Rechtskurve). Dabei bremst Du in Richtung N total ab, und beschleunigst in Richtung O von 0 auf Dein Fahrtempo. Du hast es doch in der Schule gehört (und wie wir alle fast vergessen): Geschwindigkeit ist ein Vektor. Also Grösse UND Richtung ist wichtig. Und beim Abbiegen ändert sich die Richtung. Also wird die vektorielle Projektion (die Geschwindigkeit entlang einer Koordinate) geändert. Aber solche Dinge sind eh blos was für Polemiker wie mich ;-)

PS: Der Textteil sieht ja total nach einem altgriechischen Epos aus - ohne Absatz und so. Ist ja total unleserlich. Ich poste das nochmal als pdf. Sonst kriegt man ja Augenkrebs :(

mare_crisium

10.10.2007, 21:05

@ Sternthaler,

Du, die Schwierigkeiten mit dem richtigen Auslesen der Sektoren (mit dem CNY 70) hatte ich auch. Hier

Forum » Elektronik » Noobfrage zu CNY70 Optoreflexkoppler schaltung

habe ich eine Schaltung gebastelt, die mir geholfen hat. Vllt kannst Du ja diesen Teil Deines ASURO noch modifizieren. Übrigens mache ich mir meine Sektorscheiben selber (siehe Anhang). Wie Du schon sagst : Die Eierei kannst Du getrost zunächst mal vergessen.

- Gestern war ich hier im Museum für Kommunikation in der Ausstellung "Die Roboter kommen". War eine ziemlich interessante Sammlung aller möglichen Robotertypen ausgestellt. Auch wimmelte es von wissbegierigen Kindern, die ihren Eltern Löcher in den Bauch fragten. Nur war es peinlich zu hören, welche Antworten sie da bekamen! Sowas von ahnungslos! #-o

@Oberallgeier,

Sternthaler hat recht: Ich dachte schon, er und ich verrennen uns hier in ein Thema, das niemanden sonst interessiert. Dabei kann ich mir nicht vorstellen, wie jemand einen selbstlenkenden Fahrroboter bauen will, ohne den Algorithmus für die Navigation zu kennen. Oder gibt's da was ganz Einfaches, das ich übersehen habe?

Dein Roboterarm hat viele Parallelen zum Fahrroboter. Zentral ist der ähnliche, schichtweise Aufbau des Programms: Ganz oben ist die "Bahnplanung", die festlegt, welche Punkte nacheinander angefahren werden sollen. Sie gibt die Vorgaben an die nächst tiefere Ebene, auf der während der Fahrt überwacht wird, ob der aktuelle Zielpunkt schon erreicht ist und dann auf den nächsten Zielpunkt der Bahn umgeschaltet wird. Bei mir heisst das "Bahnsteuerung". Ganz unten ist die eigentliche "Lenkung". Die "Bahnsteuerung" gibt ihr den aktuellen Zielort vor. Die "Lenkung" vergleicht laufend die aktuelle Position mit den Koordinaten des Zielortes und regelt die Motorgeschwindigkeiten entsprechend. Über diese Ebene haben Sternthaler und ich uns bisher unterhalten.

Das mit dem Abbremsen in den Kurven habe ich mir so vorgestellt: Es braucht eigentlich gar nicht gebremst zu werden. Die Kurvenradien stellen sich frei über den Regler ein, der die Drehgeschwindigkeitsdifferenz der beiden Motoren regelt. Der minimale Kurvenradius wird von der maximalen zugelassenen Drehgeschwindigkeitsdifferenz bestimmt. - Ich habe sehr, sehr ausgiebig mit Reglern in der Industriepraxis arbeiten dürfen; deshalb schwöre ich auf die Dinger ;-).

mare_crisium

Edit: Anhang gelöscht wg. Upload-Quota

oberallgeier

10.10.2007, 21:57

Hei, mare_crisium,
Das mit dem Abbremsen in den Kurven habe ich mir so vorgestellt: Es braucht eigentlich gar nicht gebremst zu werden. Die Kurvenradien stellen sich frei über den Regler ein, der die Drehgeschwindigkeitsdifferenz der beiden Motoren regelt.Natürlich hast Du recht, soweit es sich um ein Gefährt handelt.

Bei meiner Arbeit hatte ich als Ziel Routinen für Gelenkroboter. Da kriegt man auch Kurven hin, wenn man den einen oder anderen Motor abbremst oder beschleunigt :-b . Aber das sind dann total chaotische Dinge #-o - weil der Gelenkroboter je nach aktueller Armstellung (Stellung der Teilarme, bzw. eben der Gelenke) eine völlig andere Übersetzung (einen anderen Einfluss) des einzelnen Gelenks auf die Gesamtkonfiguration hat ](*,) .

Also rechnet man dem Gelenkroboter erstmal eine Bahn vor, mit einer sinnvoll vermuteten Beschleunigung um die "Ecken". Dann guckt man, ob nach der Koordinatentransformation - also nach dem Berechnen der Gelenkstellungen, die zur vorgerechneten Teilstrecke gehören - die einzelnen Gelenke keine unsinnig hohe Beschleunigung erfahren. Ist das ok, dann kann die Bahn gefahren werden, sonst geht man mit einer korrigierten Beschleunigungsvorgabe für die Bahn in eine neue Iteration. Und im Hintergrund - damit es wirklich gut funzt, wird das zeitlich präzise interruptgesteuert - lässt man dann eine Regelung laufen, die die vorgerechneten Gelenkkoordinaten von den Motoren einstellen lässt.

Es ist genauso wie Du sagst: eine Arbeit von oben nach unten. Der Käptn gibt das Ziel grob vor, der Navi rechnet den Kurs aus, der Steuermann sieht zu, dass er den vorgegebenen Kurs einhält und Maschinist oder Heizer sehen zu, dass der Kahn überhaupt in Bewegung kommen kann.

mare_crisium

11.10.2007, 05:15

Oberallgeier,

Deine sehr anschauliche Beschreibung Deiner Arbeit gibt mir eine Ahnung davon, durch welchen transzendenten Mathe-Dschungel Du Dir einen Pfad freischlagen musstest. Puh! Euler lässt grüssen...

Daran gemessen, ist so ein einfacher Fahrroboter doch ein gutmütiger Einstieg in das Thema. Deine Analogie zwischen dem Programmaufbau und der Hierarchie auf einem Schiff trifft die Sache haargenau und ist sofort sinnfällig. Und ein kleiner Systemkern, der die Programme zeitscheibenweise verarbeiten kann, hilft enorm.

@Sternthaler,

danke für die Messdaten. - Wenn ich von meiner Reise zurückkomme, gucke ich sie mir genauer an!

Zum "Steckenbleiben": Ja, das kann passieren, wenn man mit dem Algorithmus den Roboter bis genau über das Ziel fahren lassen will. Mir fallen drei Gegenmassnahmen ein:
1. Wenn der Abstand zum Fahrziel einen Mindestwert unterschreitet bzw. die Fahrgeschwindigkeit zu gering wird, schaltet man zum nächsten Fahrziel weiter. Der Bursche fährt dann möglicherweise knapp am aktuellen Zielort vorbei.
2. Du sorgst dafür, das der Fahrgeschwindigkeits-Regler nie weniger als einen Mindestwert ausgeben darf, oder Null. Die "Null" (Stehenbleiben) darf er nur ausgeben, wenn auch der Abstand zum Ziel "Null" ist. Gemeint ist: Bis auf einen kleinen Restbetrag. Wenn noch weitere Fahrziele angefahren werden sollen, kann man, statt "Null" an die Motoren auszugeben, auch zum nächsten Fahrziel übergehen.
3. Du änderst die Methode zur Berechnung der Regelabweichung am Ortsregler: Bisher nahmen wir dafür die z-Komponente des Vektorproduktes aus Fahrrichtung und dem Abstandsvektor vom aktuellen Ort zum Zielort. Wenn Du nicht willst, dass die Fahrgeschwindigkeit vom Zielabstand unabhängig ist, dann kannst Du statt des Original-Abstandsvektors dessen Einheitsvektor nehmen. Die Geschwindigkeit bleibt dann immer gleich, aber die Fahrrichtung wird laufend angepasst. Musst nur aufpassen, dass Du rechtzeitig zum nächsten Fahrtziel weiterschaltest, sonst dreht das Ding um und fährt in Schleifen immer wieder über das aktuelle Fahrziel drüber! Solange die Batterie hält...

Das Gute an dem Einsatz von Reglern ist, dass es immer Möglichkeiten zur Anpassung gibt, ohne dass man den Überblick verliert.

mare_crisium.

oberallgeier

11.10.2007, 07:45

Hallo mare_crisium,

Erstmal vielen Dank für das verbale Fleißbildchen O:) . Sooo schlimm ist sowas auch nicht. Wenn man mal erst durch ist :cheesy: .
Die "Null" (Stehenbleiben) darf er nur ausgeben, wenn auch der Abstand zum Ziel "Null" ist. Gemeint ist: Bis auf einen kleinen RestbetragGenau! Klingt nach einem I-Regler. Und der wird IMMER schwingen, wenn er nicht ein kleines Gebiet um den exakten Sollwert hat, an dem er auf Null geschaltet wird.

Bedeutet: Wenn der I-Regler das nicht hätte, dann sieht er, dass er gerade um einen Minimalabstand neben dem Sollwert ist und gibt dem Antrieb das Signal mal anzufahren. Aber eigentlich sollte das System ja ruhen! Nun schaltet der Antrieb ein. Wenn der I-Regler dann sieht, dass er AM Sollwert steht, schaltet er den Antrieb aus. Es wäre jetzt Zufall, wenn das System NICHT auf der "anderen" Seite über den Minimalabstand hinausgeht - überschwingt. Daher wird der I-Regler in einem Bereich um den Nullpunkt ausgeschaltet, dessen Größe von der Steifigkeit des Reglers und der Dynamik des Systems abhängt. Aber da erzähl ich eh bekannte Dinge.

Apropos Reglersteifigkeit. Du musst mal bei einem nicht zu kleinen Verkehrsflieger von einem Kompass auf einen anderen umschalten :-k . Der P-Regler des Ruders ist dort so steif, dass durch die sehr geringe Abweichung der Kompasssysteme ein deutliches Signal kommt: Ich dachte damals, jemand wäre mit einem Riesenhammer gegen das Seitenleitwerk gedonnert. Es tut wirklich einen gewaltigen Schlag :) - - - - und dann ist wieder alles ruhig.

Sorry, ich komm ins labern und off topics...

Sternthaler

12.10.2007, 00:15

Hallo oberallgeier,
OT's in dieser kleinen Runde sind doch spannend. (Jetzt weiss ich, dass ich demnächst keinen Kompass mehr in den Urlaubs-Jet mitnehmen werde.)
Ich muss gestehen, meine Zeit erst noch mit den restlichen Renovier-Tapeten und noch einigen Betrachtungen der oben gepostetet Messdaten verbracht zu haben. Soll heissen, ich habe deine Ausführung immer noch nicht gelesen. :oops:
Im Moment bleibe ich dann ja wohl nur Heizer ;-)

So, nun für alle. Also auch ein: Hallo mare_crisium
Deine Vorschläge gegen das 'Steckenbleiben' sind natürlich wieder bestens.
Gibt es noch weitere Fahrziele: Und weiter.
Bin ich am Ziel: Jetzt ein bisschen Toleranz zeigen.
Wobei mir dein 3.ter Vorschlag mit dem Einheitsvektor irgendwie am besten gefällt, da ich dann selber eine Wunschgeschwindigkeit vorgeben kann, die dann ja auch eingehalten wird. (Und schon wieder werde ich wohl die Handbremse bei Kurven benötigen ;-) )

Als kurze Zusammenfassung der bisherigen Mess- und Datenprobleme folgende Bearbeitung:

---- HELL- bzw- DUNKEL-Zeiten der ODO-Scheiben:
Einfach nur die Zeiten zwischen HELL-nach-DUNKEL-Wechsel nutzen. OK, die Auflösung halbiert sich, aber es entfällt eine Mittelwertrechnung, die das gleiche erreichen würde.

---- Zeitdifferenzen immer nur in ca. 41er-Schritten vom 36-kHz-Counter
Die Differenzen zwischen den einzelnen Zeitwerten hatten sich immer nur mit einem Faktor von ca. 41 Einheiten des 36-kHz-Counters geändert.
Dies ist kein neuer Quanteneffekt. (Physik-Nobelpreis ist ja auch gerade weg.)
Liegt nur an meinem Messzyklus an der Odometrie.
Dies konnte ich auf ca. 11 Einheiten reduzieren.
Der Grund ist der relativ lahme AD-Wandler. Jede Wandlung benötigt ca. 5 Einheiten. Da natürlich immer nur nach einer Wandlung geprüft werden kann, ob die ODO-Scheibe einen Farbwechsel hat, also immer in Quanten.

---- Eiernde Odomeetriescheiben
Gleitende Mittelwertberechnung über eine Scheibenumdrehung wirkt Wunder.

Zur Anschauung ein Bildchen und schöne Grüße von Sternthaler

oberallgeier

12.10.2007, 08:51

Hallo, Nachschicht-Sternthaler

... OT's in dieser kleinen Runde sind doch spannend ... Ich muss gestehen, meine Zeit erst noch mit den restlichen Renovier-Tapeten ... Eiernde Odomeetriescheiben ...(aus Bildtext: Passt zu dem leichten Rechtsdrall)OT: Stimmt, hab mich schon lang nicht mehr so auf einen Beitrag gefreut.

Also der Zeitstempel Deines Beitrags (Verfasst am: Heute um 1:15) und der Rechtsdrall Deines (ist das ein Robby-?) Fahrwerks lässt mich Fürchterliches ahnen, was die Linearität Deiner Tapetenbahnen angeht. :-k

Na und wenn Dein Kompass die gleiche Linearität hat wie das "linke Rad" dann solltest Du den nicht in älteren Flugzeugen (=gealterte Struktur) an deren Navigationsnetz anschliessen. Obwohl . . so nach nem Vielstundenflug zu den Seychellen . . würde die Leute munter machen.

Ich wünsche Dir einen guten Wirkungsgrad und immer lotrechte, zumindest parallele, Tapetenränder

oberallgeier

12.10.2007, 09:05

Hi, Sternthaler,

nehmen wir an, dass Dein Exceldiagramm zu der Scheibe aus dem oberen Bild gehört (36 Sektoren). Dabei sind mir allerdings die Einheiten der Achsen nicht klar. Y = Weg und X ist Zeit?

Die Optik der Signale vom "Linken Rad" und Auszählen der beiden grösseren Plateaus deuten nach meinem Empfinden nicht auf eine Exzentrizität hin. Exzentrizität bei ansonstiger Stabilität müsste ja einen den Messwerten überlagerten Sinus von der Länge des gemessenen Radumfangs zeigen. Oder seh ich das so falsch?

Ausserdem sind die Sprünge positiv und negativ immer von etwa der gleichen Höhe - etwa 65+/- 10 Z-Einheiten !?

=P~ hihi - so käme ich wieder on topic =D>

mare_crisium

12.10.2007, 18:52

@Sternthaler,

wenn er recht hat, hat er recht! Oberallgeier, mein' ich...

Die Sprünge sind verdächtig. Sag' mal, liest der ASURO die Sektorscheibe wirklich über den ADC aus???!!!

@Oberallgeier,

den Regler eines Verkehrsflugzeugs in vollem Flug umschalten... da möchte ich lieber nicht im Fahrgastraum sitzen! Meine Erfahrungen beschränken sich auf Destillationskolonnen (bis 3m Durchmesser bis 20m hoch, 20-30t Produktinhalt). Die Regler an den Dingern habe ich immer nur ganz erfurchtsvoll gesteichelt, sonst ...

Bezüglich des Regelalgorithmus: Der Fahrtrichtungsregler braucht keinen I-Teil. Die Strecke wirkt ja schon integrierend! Wie scharf (stramm) man den P-Teil einstellen kann, ohne dass das System schwingt, muss das Experiment zeigen.

Aber erst müssen wir diese Sprünge verstehen und beseitigen. Mittelwertbildung ist gefährlich, weil das ein verkapptes I-Glied darstellt!

mare_crisium.

oberallgeier

12.10.2007, 22:00

´n Abend, mare_crisium
... den Regler eines Verkehrsflugzeugs in vollem Flug umschalten... da möchte ich lieber nicht im Fahrgastraum sitzen!Also eine ungute Erinnerung für mich ist der Donnerschlag über dem Ärmelkanal - der ganze Himmel blau, absolut ruhiger Flug vorher und danach. Und nach dem Schlag flogen hinten die Kaffeetassen und die Passagiere waren etwas sehr durcheinander. Aber bei dem erwähnten "Experiment" sass ich vorne, und es wurde nur von einem Kompass auf den anderen geschaltet. Das provozierte eben ein richtiges Sprungsignal - der TRAUM jedes Regeltechnikers.

... Meine Erfahrungen beschränken sich auf Destillationskolonnen (bis 3m Durchmesser bis 20m hoch, 20-30t Produktinhalt). Die Regler an den Dingern habe ich immer nur ganz erfurchtsvoll gesteichelt, sonst ... ;-) Also vom Durchmesser und Produktinhalt ist das meinem Beispiel doch ähnlich ;-) - aber bei Destillationskolonnen wär ich auch vorsichtig, kommt aber vielleicht auch auf den Inhalt drauf an.

M... - ich bin schon wieder am labern, sorry.

mare_crisium

13.10.2007, 00:09

@JackBauer,

für den Fall, dass Du den Thread noch verfolgst, hier ist ein Buchtitel, der Dir helfen könnte:

Patnaik, S.: "Robot Cognition and Navigation", Springer, ISBN-13: 9783540234463; 64,15EUR.

Der Teil über Bahnplanung war sehr anschaulich geschrieben und nur mit der notwendigsten Mathematik versehen. Die Hinweise auf die Programm- und Datenstruktur schienen mir auch sehr hilfreich zu sein. Unter anderen wurde auch der A*-Algorithmus speziell für Fahrroboter ausgearbeitet.

mare_crisium.

oberallgeier

13.10.2007, 07:48

@JackBauer,... Patnaik, S.: "Robot Cognition and Navigation", Springer, ISBN-13: 9783540234463; 64,15EUR... mare_crisium.Und wenn das (zu) teuer ist, dann frag in Deiner Stadtbibliothek - die können so etwas fast immer per Fernleihe holen für ein paar wenige Euro (ich zahle vier oder sechs Euro Jahresgebühr). Schneller, so mit 24-Stunden-Dienst, und teurer gehts bei der Uni-Bibliothek Hannover:
http://tiborder.gbv.de/services/?COOKIE=E1e293de4,%20%20U9896,D2.63,I0,C++++++++++ ,B8901+++
oder
http://www.tib.uni-hannover.de/

Sternthaler

15.10.2007, 00:22

Hallo, da bin ich wieder.
Tapeten sind alle an den Wänden und Decken (Deine lotrechten Wünschen haben sehr gut geholfen.). Fete ist gelaufen. Allerdings eine Geburtstagsfete bei einem Kumpel, nicht wegen der Tapeten natürlich.
Eure OT's finde ich, sind weiterhin spannend und lesenswert.
Deshalb habe ich extra für euch am Ende mal eine Zusammenfassung "in ungewöhnlicher" Form der bisherigen Dinge dargestellt.

... nehmen wir an, dass Dein Exceldiagramm zu der Scheibe aus dem oberen Bild gehört (36 Sektoren). Dabei sind mir allerdings die Einheiten der Achsen nicht klar. Y = Weg und X ist Zeit?
Nein, irgendwie hätte ich da vorher einen besseren Hinweis geben sollen, was dargestellt wird.

Die X-Achse zeigt die Tik's der Asuro-Odometriescheiben. Je 8 Tik's hat sie sich einmal gedreht. Deshalb hatte ich in der Richtung die 8-ter Teilung im Excelblatt.
Da jeder Tik der Auslöser zum messen der Zeit ist, ist auf der Y-Achse eine Zeitangabe in 36 kHz-Einheiten, wie lange es von einem Tik zum nächsten gedauert hat.

Beim "rechten Rad" kann man zu Anfang noch schön sehen, wie der Asuro beschleunigt, da die Zeiten immer kürzer werden. Von 575 Einheiten auf (leicht pendelnd) 500 bis 525 36-kHz-Einheiten.
Zur Umrechnung dieser Einheiten, ist links im Excel-Bild der Zähler mit 10789 angegeben.
Daraus ergeben sich im Mittel Geschwindigkeiten für links von 10789 / 476 = 22,7 cm/s und für Rechts dann 21,0 cm/s

Wie du schon sagtest, sind die Abweichungen auf der linken Seite keinesfalls durch das Eiern entstanden.
Sie müssten dann ja tatsächlich periodisch innerhalb jeder 8-er-Gruppe auftreten. Was es nun tatsächlich ist kann ich nicht sagen. Sie sind mal mehr und mal weniger vorhanden.
Mein Cheffe würde nun von Höhenstrahlung sprechen. Eventuell ist das Rad eigentlich von einem Flugzeug, und beim Kompasstausch mal abgerüttelt worden.

Ich hoffe, dass diese Erklärungen zum Diagramm passen und vor allem euch etwas sagen.

Hallo mare_crisium,
mal ein Wort zu deinen selbstgebauten Sektorscheiben.
Whow, die sind ja klasse. Vorwärts- und Rückwärtserkennung gleich 'on Board'.
Sind die aus Platinen geätzt? Wie groß sind die Scheiben? Ich tippe mal so auf 5 bis 8 cm Durchmesser. Wie groß sind deine Fahrzeuge? Doch nicht etwa Maschinen um damit in den Destillationskolonnen nach Leck's zu suchen.

Du fragst, ob die Sektorscheiben tatsächlich über den ADC ausgelesen werden. Ja, da ist eine Reflexlichtschranke konstruiert worden, bei dem der Sensor ein LPT80A ist. Beleuchte wird das ganze mit einer IR-LED IRL80A.
Gemessen wird also Sinnvollerweise kontinuierlich, um dann im Asuro ein über- bzw. unterscheiten eines Spannungspegels als Tik registriert zu werden. (Genau das ist Asuro's Schwäche, da man hier genügend Energie reinstecken kann, um die blöde Schwelle dynamisch zu bekommen. Sonst ist das Ding relativ stark Umgebungslichtabhängig.)

So, zum Schluss noch ein HURRA auf deine Beschreibung zur Berechnung der aktuellen Position und Richtung anhand der Daten.
Noch ein Excel-Blatt zeigt nun tatsächlich die Position und Richtung, die der Asuro gefahren ist. Ein Beispiel aus den Daten auch als Bild.
(Ja, ja, vorher ist besser: X- und Y-Koordinaten sind echte cm in der Landschaft.)

Viele Grüße und weitere OT's von
Sternthaler

mare_crisium

15.10.2007, 20:24

Sternthaler,

ja, genauso macht man sowas: Immer mit der Hand am Arm!

Deine Positionsdaten habe ich nochmal überarbeitet (nur die von "daten32"), weil Du vergessen hast, den Fahrtrichtungsvektor zu normieren. Wie Du in graphischen Darstellung sehen kannst, ist die Abweichung aber nicht gross. Will sagen, für eine Tapetenbahn würde das glatt als Präzisionsarbeit durchgehen ;-).

Diese Sprünge in Deinen Daten - mir fallen folgende Eigenheiten auf:
1. Die Einbrüche sind alle fast gleich lang: Immer ca. 6 Messungen
2. Die Einbrüche sind alle fast gleich tief: Immer ca. 32.
Das scheint mir eher auf den ATmega zu deuten: Vielleicht werden MSB und LSB manchmal in der verkehrten Reihenfolge ausgelesen?

Die Sektorscheiben ätze ich aus ganz normalem fotopositiv beschichtem Pertinax. Ich stelle mal ein paar Muster als pdf in den anderen Thread. Der Durchmesser dieser Scheibe ist 45mm. Das ist der kleinste Durchmesser, bei dem ich die CNYs noch ausreichend genau auf der Platine plazieren kann. Nach oben ist der Durchmesser nur durch das verfügbare Platinenmaterial begrenzt.

Nee, das ist nicht für die Arbeit gemacht! Und meine Kolonnen habe ich alle persönlich von innen inspiziert. - Is nix für Leute mit Klaustrophobie.

Mein Fahrroboter existiert noch gar nicht, bin noch ganz am Anfang mit dem Basteln.

Ciao,

mare_crisium

Edit: Anhang gelöscht wg. Upload-Quota.

oberallgeier

15.10.2007, 21:19

Hallo,

...Tapeten sind alle an den Wänden und Decken (Deine lotrechten Wünschen haben sehr gut geholfen)...Eine Sorge weniger.

...Nein, irgendwie hätte ich da vorher einen besseren Hinweis geben sollen, was dargestellt wird...Nein, nein, ich hatte nur bisher nicht ALLE Beiträge aufmerksam durchgelesen. Habs erst heute getan (und war nach einem ruhigen Flug recht aufnahmebereit).

Die X-Achse zeigt die Tik's ...jeder Tik der Auslöser zum messen der Zeit ist, ist auf der Y-Achse eine Zeitangabe...Ok, ich hoffe ich habs jetzt verstanden. Es ist aber ein Zeitbedarf, keine Zeitangabe.

Ich sitze über Deinem Excelsheet, insbes. "Nettodaten-31" (Diagramm) und überlege mir sinnvolle Fehlerquellen (ich hoffe, dass bei mir unterm Weihnachtsbaum ein Asuro liegt, bis dahin müsste ich viel fitter in (AVR-)Assembler und -Syntax werden - und Ähnliches wie Dein Problem wird bei mir haufenweise kommen :-( ). ICH schlage mich momentan mit einem Timerinterrupt für einen Servotester mit einem tiny13 herum ](*,) .

Ok, Du zeigst also im Diagramm Zeitdifferenzen (Z-Achse) pro Weg (genauer pro 45°-Umfang des Rades). Dargestellt wird somit eine inverse Geschwindigkeit (die umso grösser ist, je niedriger der Z-Wert).

Beobachtungen:
Im Diagramm "Daten-26" vom 12Okt2007,1:15 bin ich, ebenso wie ihr, über die nach unten um ähnliche Beträge verschobenen Punkte im Diagramm gestolpert. Wir sehen also, dass da die Geschwindigkeit über nahezu eine Umdrehung sprungweise ZUGENOMMEN (der Zeitbedarf hat um etwa gleiche offsets abgenommen) und danach über etwa den gleichen Sprung wieder abgenommen hat. Hmmmmmmm - grübel. Die Verschiebung erstreckt sich jeweils über etwa eine ganze Umdrehung (7 bis 8 ticks, einmal nur einer). Im Diagramm "nettodaten-31" haben wir ebenfalls eine annähernd gleiche, blockweise, Verschiebung mit entsprechender Rückkehr zum (der Anschauung nach) glaubhaften Wert. Hmmmmmmm - noch mehr grübel.

FMEA
-Reibung? Kann´s ja wohl nicht sein, weil die Geschwindigkeit zu Beginn des Fehlers zunimmt. Sprunghaft!
-Negative Reibung (Durchdrehen, Durchrutschen)? Aber doch wohl nicht mit der Konstanz!
-Exzentrizität (eiern)? Die einzige Exzentrizität die ich feststelle, ist dieses exzentrische (im Sinne von ausgefallen) Problem. Eiern hatten wir ja schon alle ausgeschlossen.

(Zwischenbemerkung: Die Zeitdifferenzen nehmen sprungweise ab - und danach ebenso sprungweise wieder zu.)

-Falsche Zeitmessung? Kann es sein, dass Du Deinem Timer einen Startwert einschreibst der manchmal >konstant anders< ist? Diese Erklärung ist mir sympathisch, weil sie einen repetierbaren Vorgang im Rechnerablauf beinhaltet (der als Fehlerursache bei meinen Experimenten schon mal auftritt).
-Falsche Zeitmessungdiezweite? Ich gehe davon aus, dass der Prozessortakt nicht geteilt wird. Auch nicht zeitweise.
-Falsche Zeitmessungdiedritte? Möglich wäre es, dass Dein OptoSensor mal einige Farbwechsel nicht erkennt. ABER dann gleich mehrere hintereinander? Und es ist ja nicht der DOPPELTE Zeitbedarf festgestellt worden, siehe oben.
-Falsche Zeitmessungdievierte? Möglich wären auch radiale, strahlenförmige Streifen auf der Codierscheibe. Wäre möglich, WENN Du die Scheibe selbst ausdruckst - beispielsweise mit einem Karusselldrucker - der druckt immer im Kreis und macht nicht horizontale sondern eben radiale Streifen.

Also mehr fällt mit im Moment nicht ein. Ich bin sicher, dass sich das Problem bald selbst löst und wenn dann ein Grund gefunden wird, ist der total simpel und keiner von denen, die ich mir überlegt hatte.

oberallgeier

15.10.2007, 21:22

Und ich stell noch was fest - mare_crisium kann sich viel kürzer ausdrücken für ähnliche Gedanken - und braucht daher auch nicht sooo lang wie ich :(

oberallgeier

15.10.2007, 21:28

... Vielleicht werden MSB und LSB manchmal in der verkehrten Reihenfolge ausgelesen? ...Ach Gott müsst das schön sein .... (sorry, soll nicht spöttisch sein, nur spessartisch) ... aber ginge das dann mit der schon mehrfach festgestellten Konstanz?

mare_crisium

15.10.2007, 21:40

@oberallgeier,

guck' doch mal bei einem Flieger-Kollegen vorbei:

www.voidpointer.de

Der hat sich mit 'nem ATmega8 einen Verteiler für Servosignale gebaut. Vllt. kannst Du Dir da das eine oder andere ausborgen. Bevor ihm sein Flieger abschmierte, hat voidpointer übrigens eine sehr schöne, vollautomatisch geflogene Platzrunde hingekriegt.

Ciao,

mare_crisium

oberallgeier

15.10.2007, 22:36

...guck' doch mal bei einem Flieger-Kollegen vorbei: ...Danke, das ist ja wirklich eine hübsche Seite. Na ja, eigentlich muss ich aber doch selber da durch, sonst lern ich doch nix.

Ausserdem bin ich in diesem Fall ein Fan von "je kleiner, desto feiner" - also will ich vorerst einen tiny13 "auslutschen". Mal sehen was da geht.

mare_crisium

16.10.2007, 21:35

@oberallgeier,

... Vielleicht werden MSB und LSB manchmal in der verkehrten Reihenfolge ausgelesen? ...Ach Gott müsst das schön sein .... (sorry, soll nicht spöttisch sein, nur spessartisch) ... aber ginge das dann mit der schon mehrfach festgestellten Konstanz?

nee, da hast Du mich verstanden mis: Ich meinte nicht, dass MSB und LSB vertauscht wurden, sondern dass die beiden in der Reihenfolge MSB-LSB aus dem ADC ausgelesen und danach richtig zugeordnet wurden. Das hat nämlich zur Folge, dass sich während des Auslesens des MSB das LSB noch ändert. - Gemeiner, weil leicht zu übersehender Fehler, kann auch beim Auslesen von 16-Bit-Timern passieren.

mare_crisium.

oberallgeier

16.10.2007, 22:56

Ok, danke, das habe ich jetzt verstanden. Und - danke, dass ich durch Deine geduldigen Erläutreungen immer wieder was dazulerne.

Trotzdem die Frage: Hat das zeitliche Konsequenzen? Ich vermute, dass hier ein "mega"µC am Arbeiten ist. Und der ist MEGAgetaktet. Auslesen dürfte wenige Takte ---- ach Du liebe Zeit ---- nein, da läuft ja die ganze Zeit vermutlich ein Vorteiler (das scheint hier nachteilig zu sein) - und der bringt das durcheinander. Stimmts? Neee, kann nicht stimmen, der Zähler kann ja nur gleichschnell oder langsamer hochzählen als der Prozessor taktet. WENN nicht grad beim Auslesen der beiden Halbworte - in der von Dir befürchteten Reihenfolge MSB LSB - ein Interrupt abgearbeitet werden muss.

Ich fürchte, ich versteh es doch nicht.

Leider habe ich keine ATMega8-doc zur Hand. In meiner tiny13-doc steht als Wandlungszeit für den ADC 13 bis 260 µs. Hmmm, nun kann ich mir natürlich vorstellen, dass ein Fehler auftaucht, wenn ich auslese, während der ADC grad beim REINSCHREIBEN ist. Und da der binär schreibt und nicht gray - - - es lebe der einschrittige Code. Aber damit kann ich mir die beobachtete Konstanz nicht erklären.

Aber ich bin nicht sicher, dass ich das wirklich blicke.

Sternthaler

17.10.2007, 01:57

Hallo ihre Rätzelrater.
Ich muss euch beide leider entäuschen, es kann nicht ein vertauschtes MSB-LSB oder ein falscher Gray-Code sein.
Wie sollte sonst die rechte Seite recht gute Werte liefern können.

Hier mal das Codestück im Interrupt SIG_ADC um zu zeigen, dass rechts und Schrott-Links identisch bearbeitet werden:

SIGNAL (SIG_ADC)
{
static unsigned int adc_val;
unsigned char v_tik = KEIN_TIK;
unsigned char v_seite;
int v_rad_zeit;

/* Mindestens ein ADC muss aktiv gewesen sein, sonst haetten wir den
Interrupt nicht bekommen.
Also den ADC-Wert holen.
*/
adc_val = ADCL + (ADCH << 8);

UND ETWAS WEITER

case ADC_DO_RAD_LH: // Links Hell-Messung speichern
MD_RAD_LH (adc_val);
MD_RAD_LH_HIST (adc_val);
sens_i.rad [LINKS_HELL] = adc_val;
if (sens_i.rad_toggle [LINKS] == TRUE)
{
if (sens_i.rad [LINKS_HELL] > hw_i.rad_schwelle_oben [LINKS])
v_tik = LINKS_TIK_OBEN;
}
else
{
if (sens_i.rad [LINKS_HELL] < hw_i.rad_schwelle_unten [LINKS])
v_tik = LINKS_TIK_UNTEN;
}
break;
case ADC_DO_RAD_RH: // Rechts Hell-Messung speichern
MD_RAD_RH (adc_val);
MD_RAD_RH_HIST (adc_val);
sens_i.rad [RECHTS_HELL] = adc_val;
if (sens_i.rad_toggle [RECHTS] == TRUE)
{
if (sens_i.rad [RECHTS_HELL] > hw_i.rad_schwelle_oben [RECHTS])
v_tik = RECHTS_TIK_OBEN;
}
else
{
if (sens_i.rad [RECHTS_HELL] < hw_i.rad_schwelle_unten [RECHTS])
v_tik = RECHTS_TIK_UNTEN;
}
break;

UND DANN NOCH

/* Bei einem erkannten Tik an der Odometrie muss nun auch der entsprechende
Tik-Zaehler erhoeht werden.
Auch die Zeit zwischen 1.er bzw. Doppel-Tik wird hier erfasst um hierraus
die Geschwindigkeit abzuleiten.
*/
if (v_tik != KEIN_TIK)
{
v_seite = (v_tik & 0x01);

sens_i.rad_toggle [v_seite] ^= 1;
sens.rad_tik [v_seite] ++;

if (RAD_ZEIT_ERFASSEN == 1 ||
(v_tik & 0x02) == 0x02)
{
v_rad_zeit = (int)(timebase * 256 + count36kHz);
sens.rad_zeit [v_seite] = v_rad_zeit - sens_i.rad_zeit [v_seite];
sens_i.rad_zeit [v_seite] = v_rad_zeit;

/* Mittelwert der RAD-ZEIT bilden.
Einen 'glatten' Mittelwert gibt es am besten wenn über eine ODO-
Scheibenumdrehung gemittelt wird.
Hier machen wir aber immer nur eine 8-er Pipe.
*/
sens_i.rad_zeit_pipe_sum [v_seite] -= sens_i.rad_zeit_pipe [v_seite][sens_i.rad_zeit_pipe_pos [v_seite]];
sens_i.rad_zeit_pipe [v_seite][sens_i.rad_zeit_pipe_pos [v_seite]] = sens.rad_zeit [v_seite];
sens_i.rad_zeit_pipe_sum [v_seite] += sens_i.rad_zeit_pipe [v_seite][sens_i.rad_zeit_pipe_pos [v_seite]];
sens_i.rad_zeit_pipe_pos [v_seite] = ++sens_i.rad_zeit_pipe_pos [v_seite] & 0x07;
sens.rad_zeit [v_seite] = sens_i.rad_zeit_pipe_sum [v_seite] / RAD_ZEIT_PIPE_LEN;
MD_RAD_ZEIT_HIST (v_seite, sens.rad_zeit [v_seite]);
}
}

Zu sehen in den EXCEL-Blättern ist immer das Datengeraffel, welches mit der letzten Zeile "MD_RAD_ZEIT_HIST (v_seite, sens.rad_zeit [v_seite]);" als MessDaten gesammelt wird.

Bis jetzt ist mir selber allerdings auch nichts passendes eingefallen. Ich glaube, ich muss mal die ODO-Scheibe nur putzen.
Oder ich tausche die ODO-Scheiben einmal von rechts nach links, um nur mal zu sehen, ob es tatsächlich die Hardware ist.
Das aber erst morgen, oder heute, oder gleich.

Gruß und vielen Dank für eurer Erklärungensbemühungen.
Sternthaler

oberallgeier

17.10.2007, 11:14

... ich tausche die ODO-Scheiben einmal von rechts nach links, um nur mal zu sehen, ob es tatsächlich die Hardware ist ...... das ist nicht nur für 02:57 eine hervorragend gute Idee. Mir fällt sowas nicht mal tagsüber ein :Haue ](*,)

aber ich kenn ja den asuro (noch) nicht, und weiss nicht, was das für ein Aufwand ist.

Sternthaler

17.10.2007, 22:29

Hallo ihr Fleißigen.

Gute Ideen kommen immer wenn alles ruhig ist.
Aber ich war danach noch lange nicht im Bett da ich unbedingt noch die Mathematik von mare_crisium im Asuro unterbringen wollte. Gegen 4:00 kam meine Frau um die Ecke und meinte ich sollte dem Asuro nun endlich 'Gute Nacht' sagen. Ich müsste ja schließlich um 8:00 wieder raus. Gegen 4:30 bin ich dann auch noch auf die Lösung gekommen warum der blöde Compiler meine ganzen Flieskommaberechnungen nicht übersetzt hat. Aber das dann auch noch fehlerfrei !
Klar, wenn man das Ergebnis der berechneten X- und Y-Koordinate nirgendwo benutzt, oder in einem Array speichert, optimiert der gar nicht so blöde Compiler das Zeug halt weg. ](*,)
Da ich heute dann natürlich weitermachen muss, jetzt also erst mal ein Asuro für euch zur Ansicht. Schließlich muss man ja mal sehen worüber man spricht.
Die kleine weiße Pappkiste zwischen Batterie und Odo-Scheibe ist ein von mir geklebtes 'add-on' zur Reduzierung des Umgebungslichtes. Darunter sind die beiden Bauteile: IR-LED und IR-Empfänger.
Getriebeuntersetzung:
Motor zu Odo-Scheibe: 5:1
Odo-Scheibe zu Antriebsrad: 5:1

Gruß Sternthaler

P.S.: Den Umbau mache ich erst heute Abend.
P.P.S.: Kompass ist nun unter der Platine angebracht. Steuer-Arm ist aufgerollt und um eine Batterie gewickelt ;-)

oberallgeier

17.10.2007, 23:32

Hei, ein hübsches Bild! Wieder mal wünsch ich einen hohen Wirkungsgrad.

Aber - der Asuro ist ja nicht wirklich klein! Ich hatte mir vorgestellt, dass der mit Allem in eine Getränkeflasche passt. Hmmm, µC aber mM (µC mit meterMechanik :( ). Und die Platine sieht nicht so aus, als könnte die man einfach teilen. Da seh ich eine Menge Arbeit auf mich zukommen - und wollte doch im März fertig sein.

Immerhin - mach(t)´s gut

mare_crisium

18.10.2007, 15:45

Sternthaler,

gut, dass unsere Frauen den wirklich wichtigen Dingen im Leben soviel näher stehen als wir! Deshalb bin ich nicht so sicher, ob der Steuerarm nicht um 'was anderes als ausgerechnet um die Batterie gewickelt sein sollte. ;-)

Bin gespannt auf das Verhalten nach dem Reinigen/Vertauschen der Sektorscheiben. Ausserdem ist mir noch eine Möglichkeit zur Verbesserung der Schätzgenauigkeit des Algorithmus eingefallen. - Aber die krieg'n wir erst später!

Ciao,

mare_crisium

PS: Meine Frau, die gerade hereinguckte, meinte nur: "Das ist also Euer elektronischer Sandkasten." - Sic!

oberallgeier

18.10.2007, 23:26

hi mc - mir gehts ähnlich ... das ist dann der wei(bli)che Algorithmus zur Bahnplanung

Sternthaler

19.10.2007, 00:40

Ja, ihr hab gut reden.
Weiche Algorithmen und Arme woanders wickeln :D
Ich muss zusehen, dass der Sandkasten endlich mal wieder Output macht. Schliesslich habe ich nun die Scheiben getauscht.

Der Asuro ist leicht nacht rechts gefahren, und nicht wie man meinen könnte gut nach links im Bogen. Blaue Linie wie immer linkes Seite. Klar bleibt für rot dann nur die rechte Seite.
Ich muss die Scheibe wohl doch mal baden. Oder mit Sand abschmirgeln? Ist auf der Rückseite echt stark mit Uhu eingekleistert von meinen letzten Versuchen.

@mare_crisium
Eine "Verbesserung der Schätzgenauigkeit" kann mir bestimmt enorm weiterhelfen. Schätzen kommt mir ja besonders entgegen solange da keine Mathematik beteiligt ist. ;-)

Gruß Sternthaler
Hier das ernüchternde Ergebnis:

Gemessener Zahlensalat:
Links Rechts
338 280
338 240
341 260
336 270
335 270
335 270
335 241
336 255
337 272
336 305
336 309
336 269
338 257
336 253
337 285
337 302
336 304
336 307
338 307
337 320
334 304
336 273
334 256
333 251
333 253
332 219
327 216
330 242
333 235
331 253
330 226
331 219
330 215
331 248
335 217
331 209
331 241
330 226
331 256
331 263
331 242
330 220
330 254
331 258
327 254
332 256
331 251
330 252
332 255
331 258
331 226
332 220
337 220
334 245
336 256
336 214
338 229
338 249
339 255
339 252
339 257
339 261
339 261
339 299
338 301
339 270
338 283
338 255
339 248
337 248
338 255

mare_crisium

19.10.2007, 01:20

SternThaler,

sieht so aus als sei getrockneter UHU ist ein guter IR-Absorber. Das ist nicht ungewöhnlich: Wasser ist auch im sichtbaren Licht durchsichtig, im IR aber ein starker Absorber. Du musst die Kleberreste beseitigen.

UHU sollte sich in Azeton lösen. Zum Schmirgeln würde ich kein rauheres Papier als 800er nehmen, sonst ist die Alu-Schicht im Nu weg. Wenn's Dir hilft, kann ich Dir neue Scheiben machen (Dicke ca. 1,5mm, Reflektor: Cu).

mare_crisium

oberallgeier

19.10.2007, 16:06

Hei Sternthaler,

leider hatte ich doch recht

Verfasst am: 15 Okt 2007, 22:19 ... und wenn dann ein Grund gefunden wird, ist der total simpel und keiner von denen, die ich mir überlegt hatte.denn

Verfasst am: Heute um 1:40 ODO-Scheiben getauscht. Nun spinnt tatsächlich die rechte Seite. OK, Datensalat liegt wohl nicht am Programm.

... kann ich Dir neue Scheiben machen.
Kann man beim Asuro denn nicht gleich die Zähne der Zahnräder mit einer Gabellichtschranke abfragen? Entschuldige die Frage, ich kenn das Teil ja leider nur von dem Bild von Sternthaler (na ja, kennen nicht wirklich).

Sternthaler

21.10.2007, 00:33

Hallo ihr beiden.
Dank für dein Angebot mare_crisium, neue Reflektorn machen zu wollen.
Das wird leider nicht funktionieren, da die 1,5mm viiiiel zu dick sind. Beim Asuro sind dünne Kunststoffolien auf dem Getriebezahnrad aufgeklebt, und die Achse selber schaut gerade mal noch so ein winziges Stück aus dem Zahnrad raus um einen Klemmring draufzubekommen.
Die 1,5mm würden einfach nicht passen.

Deine Idee oberallgeier, eine Gabellichtschranke an den Zähnen zu nutzen wird beim Asuro, zumindest an dem mittleren Zahnrad und einer AD-Messung, nicht funktionieren.
Die Rechenleistung bzw. die Geschwindigkeit vom AD-Wandler ist zu klein um die Zähne noch 'sehen' zu können.
Aber dann bliebe ja noch die Möglichkeit einfach nur anhand der Zähne und der Gabellichtschranke ne'n popeliegen Interrupt zu erzeugen. Grübel, Umbau?, grübel :-k
Eigendlich möchte ich den Asuro nicht umbauen, da dann ja die Umsetzung von mare_crisium's Funktionen nicht mehr für die Asuro-Gemeinde allgemein bleibt. Mal sehen.

@mare_crisium
Danke für deine Korrektur der X-Y-Positions-Berechnung in einem der letzten Excel-Blätter. Irgendwie habe ich das erst heute so richtig mitbekommen. Du hast da zwar Recht, dass es sich nur um winzige Differenzen handelt, aber es wird sich schon noch zusammenläppern.

Um euch nicht mit einem weiteren Bild zu langweilen, heute einfach mal den ganzen Code-Haufen. (Komentare inside)
Ziemlich am Ende der Datei test.c steckt im Moment die Berechnung, um aus den Raddaten die X-/Y-Position usw. zu bekommen. (Noch ohne normiertem Fahrtrichtungsvektor)
Da ist noch alles im Umbruch und erst einmal nur in einer Schleife verpackt für die Statistik. So kann man schon sehen, das die Rechenleistung vom Asuro mit ca. 15 bis 40% Prozent nur zur Koordinatenberechnung benutzt wird. Aber was soll's, reicht ja bis jetzt.

Gruß Sternthaler

P.S.: Werde jetzt Arme woanders wickeln gehen. ;-)

oberallgeier

21.10.2007, 13:31

Hei Sternthaler,

ich hab das Rad nachgemessen (Du hast ja praktischerweise im Bild vom 17 Okt 2007, 23:29 gleich einen Meterstab mitfotografiert). Rund D 25 mm und 8 Paar Sektoren (8 schwarz und 8 weiss) auf Hochglanzpapier (oder ist das Glänzende der UHU???).

In meinem CAD habe ich schon eine Scheibe konstruiert mit deutlich grösserem Durchmesser und als pdf ausgedruckt. Ausdruck liegt hier bei :). Du könntest die selber ausdrucken und aufkleben. Alternative: ich drucke die Scheibe auf selbstklebendem Hochglanzpapier mit einem recht genauen Drucker aus und schick Dir das zu (als Nachtschichtzulage :) ).

PS (soll keine Spitze sein, eher vergnügt): ...und schön zentrisch arbeiten ...

Sternthaler

21.10.2007, 19:25

Hi, hi.
Ja das Lied kenne ich. Meine Mutter muss mir das schon damals vorgesungen haben. (Ich glaube, dass es dazu 10 Strophen gibt.)
Hier bei ASURO DDS (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=31867) kannst du es ja mal vertonen lassen. (Bestell Grüße von mir, und es kann sein, dass M1.R oder Rasias Mitleid haben und es machen.)

Zu selbstgemachten ODO-Scheiben gibt es schon den Thead Verschiedene Muster für die Odometriescheiben (https://www.roboternetz.de/phpBB2/viewtopic.php?p=322409). Der ist mal wegen meiner Idee zu einer anderen Geometrie der Segmente beim Asuro unter Projekt "Robby will nach Hause":Wer will mitmachen (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=246988#246988) entstanden. Das ist leider ein 'eingeschlafener' Thread mit dem gleichen Thema wie bei uns dreien hier.

Sonst gibt es bei mir zuhause, außer 'John Travolta' im Fernsehn, nix neues. Auch nicht beim Asuro-Navigator.

Bis nachher
Sternthaler

P.S: PDF von dir habe ich natürlich trotzdem gezogen.
Im Übrigen kann ich sagen, dass du mit dem Durchmesser von 2 cm super Recht hast. Perfekt ausgemessen.

oberallgeier

21.10.2007, 23:55

Hi, Sternthaler!

Ach Du heilige Kuh, hab die referenzierten Threads gelesen. Ich komm mit meinen Vorschlägen ja total zuspät :( - und wenn Du/ihr schon seit Monaten rumbastelt - ich wollte eigentlich in drei, vier Monaten so ein Ding ans Laufen kriegen (mit Ausweichen). Diese Vorstellung scheint ja ziemlich aussichts-hoffnungs-sinn-los zu sein.

Trotzdem - gute Nacht!

mare_crisium

22.10.2007, 12:18

@Oberallgeier,

nu wirf' mal die Flinte nicht gleich in den Gen-Mais! Zum Laufen kriegst Du den ASURO sicher sehr schnell, z.B. als Linienfolger, als der er wohl ursprünglich auch konzipiert war. Keine Bange! Und danach hast Du dann die Kenne für die Kür!

@Sternthaler,

danke für die interessanten Threads, die Du angefügt hast. Dorothea hat für die Navigation im Grunde denselben Algorithmus gefunden wie ich. Logik ist halt eindeutig (meistens, jedenfalls ;-)). Sie ist dabei nur einen schwierigeren Weg gegangen.

Dass das Auslesen der Sektorscheiben beim ASURO so vielen Leuten das Leben schwer macht, hätte ich mir nicht träumen lassen! Für die Navigation werde ich die Scheibe direkt auf die Innenseite des Rades montieren und über meine CNY70 + 1-Tansistor-Schaltung direkt an die Pins von digitalen Eingangsports anschliessen.

mare_crisium

oberallgeier

22.10.2007, 12:59

Hallo, mare_crisium,

@Oberallgeier,
nu wirf' mal die Flinte nicht gleich in den Gen-Mais! ...Danke für die Unterstützung - aber ich bin in dieser Hinsicht eh zäh ... denke ich. Und komme auch mit längeren Projektlaufzeiten zurecht.

[quote="mare_crisium... Für die Navigation werde ich die Scheibe direkt auf die Innenseite des Rades montieren und über meine CNY70 + 1-Tansistor-Schaltung direkt an die Pins von digitalen Eingangsports ...[/quote]Also bei meinem Fahrrad und bei meinem Moped ist das VIEL einfacher gelöst - und DIGITAL - vermutlich bei Deinem auch.
==>> WARUM klebt man denn nicht kleine Magnete dran und liest das mit nem Reedkontakt aus? Oder raff ich schon wieder was nicht? Ich vermute nicht, dass die Drehzahl der Räder am Asuro höher ist als das Rad von meiner Bandit bei 200 kmh (ca. 30 1/sec) - und dort fliegt der Magnet auch nicht weg....

oberallgeier

22.10.2007, 13:07

Hallo, mare_crisium,

@Oberallgeier,
nu wirf' mal die Flinte nicht gleich in den Gen-Mais! ...Danke für die Unterstützung - aber ich bin in dieser Hinsicht eh zäh ... denke ich. Und komme auch mit längeren Projektlaufzeiten zurecht.

... Für die Navigation werde ich die Scheibe direkt auf die Innenseite des Rades montieren und über meine CNY70 + 1-Tansistor-Schaltung direkt an die Pins von digitalen Eingangsports ...Also bei meinem Fahrrad und bei meinem Moped ist das VIEL einfacher gelöst - und DIGITAL - vermutlich bei Deinem auch.
==>> WARUM klebt man denn nicht kleine Magnete dran und liest das mit nem Reedkontakt aus? Oder raff ich schon wieder was nicht? Ich vermute nicht, dass die Drehzahl der Räder am Asuro höher ist als das Rad von meiner Bandit bei 200 kmh (ca. 30 1/sec) - und dort fliegt der Magnet auch nicht weg....

mare_crisium

22.10.2007, 19:42

Buona sera, Oberallgeier,

es gibt ebensoviele Sensoren für die Drehzahl/Drehwinkel wie Wege nach Rom. Aktuell wird im Forum gerade der hier ausgiebig diskutiert:

Forum » Sensoren » Magnetischer Drehwinkelgeber

Gegen Reedkontakte ist nix zu sagen, solange die Bandbreite ausreicht und für Entprellung gesorgt ist. - Na, Du weisst ja wie das ist: Man muss versuchen, unter den vielen in Frage kommenden Messverfahren das mit den wenigsten Nachteilen herauszufinden. Den idealen Sensor gibt's für keine Messaufgabe.

mare_crisium

Sternthaler

22.10.2007, 19:50

Hallo oberallgeier,
auch ich stimme mare_crisium zu, dass der Gen-Mais keinesfalls das Ziel der Flinte werden soll.
Zäh sein, ist tatsächlich der spannendere Weg. Zum Glück ist bei mir der Asuro nur ein Hobby und ich mache mir da keine Projekte raus. Was mir in den Sinn kommt, lasse ich oder gehe da mal dran. Dann können es eben auch 2 1/2 Jahre werden, um die ODO-Dinger (und den Rest) möglichst komplett auszuquetchen. (Genau das liebe ich am Asuro. Das Forum hier hat gute Ideen und so kann man ewig dran bleiben.)

Hallo mare_crisium,
na ja, ob man denn wirklich so lange an einer ODO-Scheibe verbringen sollte wie ich, möchte ich bezweifeln. Deine Idee bzw. die Magnet-Idee von oberallgeier, die Bewegung etwas einfacher zu ermitteln ist ja nun mal nicht im Asuro realisiert. Wahrscheinlich wollten die Erfinder noch die letzten beiden AD-Wandler nutzen und etwas Spielraum zum spielen mit einer weiteren Sensorik einbauen. Bei mir haben sie damit wohl einen treuen Anhänger gefunden ;-)

Zum Prinzip der ODO-Scheiben beim Asuro mal ein Wort.
Wenn man sich in einer Umgebung mit so halbwegs gleichbleibender Beleuchtung aufhält, dann ist da eigendlich überhaupt kein Problem. Von total dunkel bis zu einem taghellen Raum, allerdings ohne direktes Sonnenlicht, decken die Sensoren alle Umgebungslichverhältnisse ab, ohne dass man sich die Finger brechen muß.
Unter ASURO emittelt Werte für Lib V2.70 myasuro.h selber (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=31073) habe ich mal ein Programm zum Ermitteln von optimalen Schwellwerten der ODO-Daten (und anderen Werten für die Asuro-LIB) abgelegt.
(Ist übrigens mein erster eigener Thread (von 2-en) nach 2 Jahren hier im Forum. Da sieht man mal wie wenig ich hier mache. :oops: )

Gruß Sternthaler

Sternthaler

23.10.2007, 23:52

Hallo zusammen,
hier hat inka gestern eine schöne Lösung (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=322643#322643) für die Asuro-Odometrie mit einer Durchlichtmessung (oder wie auch immer das heißen mag. Gabellichtschranke?) gezeigt.
Etwas weiter oben sind seine Messdaten dazu.

Ich selbst bin dabei die X-, Y-Koordinatenberechnung nun im Interrupt zu 'versenken'. Ist etwas fummelig und dauert bei mir immer etwas länger.

Mit Gruß und 'Gute Nacht'-Wünschen
Sternthaler

mare_crisium

29.10.2007, 22:04

Buona sera, Sternthaler,

nur damit die Zeit während des Bastelns nicht zu lang wird: Hier ist der Algorithmus mit verbesserter Schätzgenauigkeit. Jetzt ist schon in Formel (8) die Geschwindigkeitsdifferenz der Räder berücksichtigt, was eine deutliche Verbesserung bringen sollte. Dann gibt es noch eine Formel (8a), die auch die Änderungen der Radgeschwindigkeiten (also die Beschleunigung) während der Zeit zwischen zwei Berechnungsläufen berücksichtigt, das ist interessant, wenn man grössere Zeitintervalle zwischen den Berechnungen braucht. Für's erste sollte es aber die neue (8) tun.

Wie geht's denn so voran?

Ciao,

mare_crisium

P.S.: Das System erlaubt mir keine Uploads mehr, weil ich meine "Upload Quota Grenze von 3 MB erreicht" hätte. Weisst Du, was ich da machen muss?

Sternthaler

30.10.2007, 08:23

Guten Morgen mare_crisium,

ich schätze mal, dass du dich an Frank oder einen anderen Systembetreuer wenden musst, wenn du die 3 MB voll hast. Bei mir hatte sich damaltor um meine Sorgen gekümmert.
Prinzipiel kannst du Dateien auch auf eigenem Speicher im Internet ablegen, und einen Link da hin machen.

So, ich muss zur Arbeit.
Gruß Sternthaler

P.S.: Interrupt ist noch nicht fertig. Im Moment bin ich der Retter in der Firma für 3 Inbetriebnametrupps beim Kunden. Wird immer so 20 - 22 Uhr bevor ich zu Hause bin.

Sternthaler

18.11.2007, 04:04

So, da bin ich mal wieder.
2 Trupp's sind erfolgreich von der Front wieder im Büro. Spätschichten reduzieren sich somit auf ein Drittel.

Am Interrupt konnte ich somit noch nicht viel weiter machen. Allerdings bin ich auf ein Problem gestoßen, das mir Kummer macht.
Da nun mal 2 Räder gleichzeitig betrachtet werden wollen, um zu X- und Y-Koordinaten berechnet zu werden, stehe ich vor folgendem Problem:
- Ein Rad meldet einen Tik.
- Die verstrichene Zeit ist dann bekannt.
- Was aber muss für die andere Radseite in den Formeln eingesetzt werden?
Noch ist ja keine neue Messung gültig, da die Drehung vom Rad bis zum erreichen des nächsten Tik's ja noch ungewiss ist. Also kann man auch nicht einfach die bis dahin vergangene Zeit dieser (anderen) Seite nutzen.
Also kann ich auch noch nichts ausrechnen. :frown:

Meine Überlegung geht dahin, dass ich eine 'unendlich' große Zeit, und somit einen Fahrweg von 0, annehme.
Excel liefert mir dann aber nur ein Eiern vom ganzen Asuro, oder bei zu groß geratenem 'unendlichen' Wert, mir unverständlich gigantisch große Koordinaten als Ergebnis.
(Ja, ja, erst eiert nur die Odo-Scheibe, und nun der ganze Asuro. Bald behaupte ich noch, dass die Erde um die Sonne eiert. Äh, Kopernikus hat da schon ein Copyright drauf.)

Zur Anschauung mal ein Excel-Blatt im Anhang (was auch sonst).

@mare_crisium
Es gibt eine Lösung für das Problem mit den 3MB. Hier (https://www.roboternetz.de/phpBB2/groupcp.php?g=18640) kannst du darüber etwas lesen. Im Vorfeld hatte ich mit Frank eine sehr zuvorkommende Korrespondenz. Deshalb habe ich hier auch kein schlechtes Gewissen den Link zu legen. (Sagt man so?)

Gruß Sternthaler

mare_crisium

19.11.2007, 06:09

@SternThaler,

da fällt mir aber ein Stein vom Herzen, wenn ich höre, dass Dein Kriseneinsatz ohne Blessuren beendet ist!

Deine ASURO-Sorgen? - frowning? - No sweat! Da greifen wir doch kühn zum Bleistift und schwingen ihn ein wenig, so wie weiland Don Quijote seine Lanze:
Die Antwort auf Deine Fragen findest Du in angehängter pdf-Datei!

Ciao,

mare_crisium

P.S.: In der Hitze des Gefechtes hat es Don Quijote mit der deutschen Rechtschreibung nicht immer sooo genau genommen! ;-)

Edit: Anhang gelöscht, wg. Upload-Quota

Sternthaler

20.11.2007, 00:15

Hallo Don Quijote,
ja, ich bin es, Sanchos Panza. Man könnte mich auch mit Rucio verwechseln.

Deine Ausführungen sind wieder sehr lesenswert. Diesmal konnte ich keine Rechtschreifehler oder sonstige Prolbeme feststellen, da ich gerade mal den ersten Absatz gelesen habe. Dies reichte, um mir Rucio, genügend Input zu geben. (Der Rest ist trotzdem mal wieder gut.)

Klar, wenn schon nicht ein ganzer Tik da ist, machen wir halt halbe Sachen.
Das werde ich die nächsten Nächte erst mal wieder mit Excel umsetzen und dann nochmal den Interrupt und die Zähler anpassen.

Danke, und einen lieben Gruß an dich mein Don Quijote
Rucio

P.S.: Hast du mit Frank 'telefoniert'? Du kannst ja zum Glück wieder uploaden.

mare_crisium

20.11.2007, 16:50

Rucio,

nee, ich hab' einfach soviele meiner früheren Posts gelöscht, bis wieder genug Quota frei war! ;-)

Ciao,

mare_crisium

jeffrey

20.11.2007, 17:55

Hallo,
will mich jetzt hier auch mal einmischen ;-)
Leider seid ihr ja vom ursprünglichen Thema Bahnplanung inzwischen auf Geschwindigkeitsschätzen gewechselt.
Hab mal kurz paar Fragen.
Ihr schreibt, dass der regler mit Abtastzeit 2ms läuft, aber selbst bei Topspeed habt ihr 500 36kHz Ticks, also 13 ms Messzeit. Es ist doch sinnlos den regler schneller laufen zu lassen, als man messen kann.
Warum habt ihr eigentlich nur 8 Ticks pro Umdrehung? Ihr hobt doch 8 Flächen, also 16 farbwechsel.
so jetzt auch mal paar anmerkung zur geschwindigkeitsschätzung. wie wäre es einen beobachter oder kalmanfilter zu verwenden, um die geschwindigkeit des anderen rades zu schätzen. das eingangssignal für die motoren ist ja bekannt, mit einem modell des motors kann man dann aus den letzten messungen und dem eingangsignal die motorgeschwindigkeit schätzen. das ergebnis wird natürlich umso besser, je kleiner die störungen sind.
mfg jeffrey

Sternthaler

20.11.2007, 23:45

Wow, ein Spion in unserem Thread ;-)

Hallo jeffrey,
sei mir nicht böse, aber wenn ich schon Filter, und dann noch von einem Kalmanfilter, höre, sieht mir das verflixt nach höherer Mathematik aus. Ich bin so froh, dass sich mare_crisium um meine mathematische Fortbildung kümmert und oberallgeier auch dabei ist, so dass ich mich nicht ganz alleine in der Klasse fühle, wäre ich dir dankbar, zumindest für mich einen Link zu einer Einführung zu geben. (Für oberallgeier, glaube ich, ist das nicht notwendig. Der fährt nämlich nicht mit angezogener Handbremse um die Kurve, sondern weiß was er tut.)
Alleine die unter http://de.wikipedia.org/wiki/Kalman-Filter aufgeführten Varianten machen mich schon ganz schwindelig.
Den Modellfehler Q hatte ich aber nur ganz selten bei meinen Fallerhäusern.

So, nun vergiss mein Gejammer ganz schnell wieder. Denn jetzt musst du in den sauren Apfel beißen und meine Antworten auf deine Anmerkungen lesen ;-)

- Abtastzeit 2 ms
Tja, da ist nun waste dran schuld. Nein, eigendlich liegt es nur daran, dass ich die PID-Parameter, die waste mal für die Linienverfolgung ermittelt hatte, nicht selber für andere Zeiten berechnen kann. Somit bin ich (erst einmal) an wastes 2ms gebunden. (mare_crisium gibt bestimmt noch weiteren Matheunterricht?)
Und die 13 ms sind nun mal im Moment der Ansatz, so einen 'langsamen' 8-er-Tik abzuwarten.

- 8 Tik's pro Umdrehung
Beim 'sehen' aller Kanten (16 Wechsel) ergeben sich unterschiedliche Zeiten zwischen schwarzen und weißen eingeschlossenen Flächen.
Ungefähr so: _______+++_______+++______
Bei 8 Tik's:.. ___________+++++++++______
(_ und + sollen bei 8 Tik's gleich lang aussehen.)
Das liegt wohl daran, dass der Triggerwert nicht immer genau die Helligkeit einer Kante representiert, und somit immer an der Kante 'vorbeischaut'.
Entweder macht man den Triggerwert auch noch dynamisch, oder man mittelt, oder man macht halt nur den 8-ter. (Habe ich mir jedenfalls so ausgedacht.)
- Dynamik ist heftig, da ich dann ja auch schon eine Historie kennen muss.
(Diesen Ansatz versuche ich beim Asuro seit ca. 2,5 Jahren ohne Historie zu realisieren.)
- Mitteln, da hat mare_crisium wegen der Mathematik etwas gegen.
- 8-ter reduziert die Genauigkeit von 1,5 mm auf 3 mm.

Sonst bleibt mir nur noch folgendes zu sagen:
Nur weiter mit Einwänden und Anregungen. Bei meinem Tempo, das zu programmieren, muss man ja zwischendurch auch was zu lesen (und schreiben) haben.

Leider seid ihr ja vom ursprünglichen Thema Bahnplanung inzwischen auf Geschwindigkeitsschätzen gewechselt.
Ich bin Schuld.
Aber es geht wohl auch eher in die Richtung keine Planung zu machen, sondern einfach nur zum gewünschten Punkt zu fahren.

Gruß Sternthaler

[EDIT]
Blödsinnige Formulierung entfernt. Entschuldigung.

mare_crisium

21.11.2007, 00:55

Howdy, jeffrey,

ich dachte schon, SternThaler, Oberallgeier und ich wären hier ganz allein im Thread! - Gute Fragen :-) stellst Du.

Also: Es geht uns darum, die Bahnplanung für einen Fahrroboter vom ASURO-Typ (zwei separat angetriebene Räder) auf die Beine zu stellen. Im Endzustand soll es eine Liste anzufahrender Punkte geben, eine Programmebene (um mit Oberallgeier zu sprechen: den Kapitän), die feststellt, ob der aktuelle Zielpunkt erreicht ist und welcher Zielpunkt als nächstes angefahren werden soll, eine nächste Programmebene (Oberallgeier: der Steuermann), die Fahrtrichtung und -strecke ausrechnet und einregelt.

Das alles soll mit einfachen mathematischen Mitteln funktionieren, ohne solche Nebelgranaten wie Kalmanfilter, Beobachter usw. Hast Du sowas schon in einem ATmega32 funktionieren gesehen? Ich meine: Selbst gesehen? Die Gefahr bei den mathematisch aufwendigeren Verfahren ist immer, dass sie die Schwierigkeiten nicht wirklich lösen, sondern nur an eine andere Stelle verschieben, wo sie nicht sofort auffallen. Meist werfen sie sogar noch zusätzliche Probleme auf.

Der Algorithmus, an der wir hier gemeinsam basteln, baut auf der Drehwinkelmessung an den Antriebsrädern auf. Jetzt hat SternThaler auf Probleme hingewiesen, die mit dieser Messung auftreten. Um den Algorithmus ausprobieren zu können, müssen wir also erstmal das Messproblem lösen. - So sieht es auf den ersten Blick aus, als wären wir vom Thema abgekommen - sind wir aber gar nicht. Und Mitstreiter sind allzeit willkommen!

Hast Du Dir unseren Algorithmus mal angeguckt? Was hältst Du davon? Wenn das hinhaut, dann kann man ihn selbst in Assembler programmieren und er passt vermutlich sogar in einen ATmega16.

Deine Einwände zum Verhältnis zwischen Abtastzeit der Messung und Frequenz der Reglerberechnung sind berechtigt.

@SternThaler,
hast Du gut erklärt! Wegen der Reglerparameter mach' Dir mal keine Sorgen, die kann man auch ohne Rechenmodelle experimentell anpassen. So habe ich das mit meinen Kolonnen auch gemacht. Und das funktionierte selbst in jenen fernen Zeiten, als die Regler noch mit Druckluft liefen (Tatsache, kein Schmäh!) sehr zuverlässig.

Ciao,

mare_crisium

oberallgeier

21.11.2007, 10:45

... anmerkung zur geschwindigkeitsschätzung. wie wäre es einen beobachter oder kalmanfilter zu verwenden, um die geschwindigkeit des anderen rades zu schätzen ... eingangssignal für die motoren ist ja bekannt, ... modell des motors .. aus den letzten messungen ... eingangsignal die motorgeschwindigkeit schätzen ... ergebnis wird natürlich umso besser, je kleiner die störungen sind.
mfg jeffrey
Hmmm, Beobachter - hmmm, schätzen - hmmm - umso besser - hhhhmmmm.

Hast Du schon mit Beobachtern gearbeitet? Also ICH habe das gemacht. Es ging (vor vielen Jahren) um einen hydraulisch angetriebenen Roboter. Und ich lag im Wettstreit mit dem damals führenden (heute wohl auch noch) Hochschulinstitut für hydraulische Antriebe und Regelungen. Die Fuzzies dort hatten Rechnerkapazität ohne Ende (und eine wirklich angetriebene Achse) - und hatten sagenhaft schöne, wissenschaftliche Arbeiten gemacht. Ich musste in der Industrie mit einem popeligen 8Bitter auskommen, zu dem ich mir aber noch einen Arithmetikprofessor leisten durfte. Selbst ohne meiner Minimalausrüstung (also in der Testumgebung, im Technikum) bin ich mit aufwendigen Rechnern und Rechenkonzepten bei meinem 5-achsigen Gelenkroboter nicht wirklich auf Tempo gekommen mit dem Sch...beobachter. Dauernd musste man dem Typen sagen what happens nur damit der grobe Vorhersagen machen konnte, die von der Wirklichkeit aber immer ein bisschen entfernt waren. Nicht sehr - aber es war ein ziemlicher Aufwand. Gebracht - für meine Industrieanwendung - hatte es dann ein ziemlich popeliger PIRegler - und eine s..gute Diplomarbeit.

:^o UND :-({|= :arrow: Das Institut hatte meinen Ansatz übernommen und den Beobachter über Bord geworfen.

Das ist nur ein isolierter Erfahrungsbericht. Sicher gibt es hier Fortschritte. Aber es bleibt immer noch viel Rechenaufwand mit meist transzendenten Funktionen. Du hast da sicher die Möglichkeit, neue Pfade zu beschreiten und Lorbeeren zu ernten . . . also los.

... ergebnis wird natürlich umso besser, je kleiner die störungen sind.Ok, das wolln wir mal nicht diskutieren. Es ist ja auch tagsüber heller als nachts.

Das alles soll mit einfachen mathematischen Mitteln funktionieren ... Meist werfen sie sogar noch zusätzliche Probleme auf. Na ja, steht ja schon da - ich brauch halt etwas mehr Wörter als mare_crisium für die gleiche Aussage. Aber die Kernaussage von mare_crisium "mit einfachen ... Mitteln" ist wichtig. Wir arbeiten mit Einchip-Rechnern, deren Vorteil in der Beschränkung liegt (will ich nun nicht weiter ausführen) - und die dadurch irre effektiv werden. Und ich hatte etliche Regelkonzepte gesehen, deren Einfachheit für manche Spezialisten erschreckend war - aber ebenso erschraken die gelegentlich über die guten Ergebnisse. Und nun kommt wieder Deine vorige Aussage ins Spiel:

... ergebnis wird natürlich umso besser, je kleiner die störungen sind.Die Störungen sind umso kleiner, je schneller Du reagierst. Aber auch das ist ziemlich simpel. Ich bin auch ziemlich simpel.

jeffrey

21.11.2007, 12:20

Hallo,
ja kalmanfilter in mega8,16,32, ka welcher es war habe ich schon gesehen, ging dabei um die messwerterfassung bei nen quattrocopter. wie er genau umgesetzt wurde weiß ich nicht, habe es gebaut.
Ich bin auch der Meinung, dass es so einfach wie möglich bleiben soll. Ich würde einfach die zuletzt gemessene Geschwindigkeit nehmen, ohne irgendwelche Schätzungen.
Die neuen Parameter auszurechnen sollte nicht das Problem sein.
Nehmen wir mal als diskreten Regler: y=Kp*(ek+Kd/Ta*(ek-e(k-1))+Ki*Ta*Sum(ei))
dabei sind die Ks die Reglerverstärkungen und Ta die Abtastzeit, und die ks Indizes hoff, dass ist so einigermaßen verständlich.
Jetzt kannst du ja jeweils mit deinen alten Werten von K und Ta Kd das reglerverhalten ausrechenen, und damit auch, wie du deine Verstärkungen ändern musst, wenn sich dein Ta ändert.
MfG Jeffrey

oberallgeier

21.11.2007, 16:20

Hey Sternthaler, hey mare_crisium,

... das ergebnis wird natürlich umso besser, je kleiner die störungen sind...Der Vollständigkeit halber muss ich dazu noch etwas sagen. Wir arbeiten digital (ja ja, das wisst Ihr), selbst floating point ist da von begrenzter Genauigkeit. Und das kann natürlich bei kleinen Messwerten (bei integer kanns fürchterlich werden) zu Problemen führen.

Das beiliegende Bild (aus einer völlig anderen Thematik) zeigt ein Beispiel. Der untere Graph ist eine Art Geschwindigket. Sieht relativ gut aus, nicht wahr? Der obere Graph ist - schon wieder, aber es zu erklären würde zu weit führen - eine Art Ableitung des ersten Graphen. Man sieht nun das jämmerliche Messrauschen. Durch kleine Incremente werden die nur finit langen Messwert-Differenzen teilweise so klein, dass Rundungsfehler eintreten (das ganze lief mit double precision - aber die Messwerte hatten eben keine 15 signifikanten Stellen), die zu einem Rauschen um den Nullpunkt führen. Insgesamt macht das nix aus - aber wenn man einen begrenzten Abschnitt betrachtet (oder auswertet), dann hat man wirklich Probleme!

Mit ähnlicher Problematik hat der integrierende Regler zu tun - der zwar allmählich irre genau werden kann, aber OHNE freigeschnittenen "Mittelstreifen" um den Sollwert zum Schwingen neigt.

Und bei kleinen "Störungen" - und/oder bei Schleichfahrt - könnten natürlich adaptive Algorithmen erst RICHTIG ihre Probleme zeigen.

Hab ich mich verständlich gemacht?

Sternthaler

21.11.2007, 19:06

Hallo Fach-Diskuskusionsrunde,
und nun mein OT dazu, da ich zwar gerne mitlesen, aber aktuell doch eigendlich den Rand halten sollte.

Wegen der Reglerparameter mach' Dir mal keine Sorgen.Sorgen? was ist das. Du bist doch da!

Also ICH habe das gemacht. Es ging (vor vielen Jahren) um einen hydraulisch angetriebenen Roboter.
...
Das Institut hatte meinen Ansatz übernommenDa habe ich wohl in's Fettnäfchen getreten. Ganz große Entschuldigung.

Ich bin auch ziemlich simpel.Das möchte ich bezweifeln!

y=Kp*(ek+Kd/Ta*(ek-e(k-1))+Ki*Ta*Sum(ei))Ist bestimmt nicht für meine Augen gedacht ;-)

Hab ich mich verständlich gemacht?Habe ich sogar verstanden, dass float nicht die Lösung aller Probleme ist.

Da ich zur Sache nichts beitragen kann, nun Ende.

Gruß Sternthaler

jeffrey

21.11.2007, 20:41

Hi

jeffry hat folgendes geschrieben::
y=Kp*(ek+Kd/Ta*(ek-e(k-1))+Ki*Ta*Sum(ei))
Ist bestimmt nicht für meine Augen gedacht

doch eigentlich scho.
damit kannst du dann deine neuen regelparameter ausrechnen, wenn sich ta ändert, musst natürlich schauen, wie waste damals den regler implementiert hat.
mfg jeffrey

Sternthaler

22.11.2007, 00:12

Hallo Jeffrey,
na gut, wenn ich das Verstehen soll, muss ich aber erst mal 'ein kleines bisschen' Fragen.

Zum sparen der Umblätterei:

Nehmen wir mal als diskreten Regler: y=Kp*(ek+Kd/Ta*(ek-e(k-1))+Ki*Ta*Sum(ei))
dabei sind die Ks die Reglerverstärkungen und Ta die Abtastzeit, und die ks Indizes hoff, dass ist so einigermaßen verständlich.
Jetzt kannst du ja jeweils mit deinen alten Werten von K und Ta Kd das reglerverhalten ausrechenen, und damit auch, wie du deine Verstärkungen ändern musst, wenn sich dein Ta ändert.

- sind die Ks die Reglerverstärkungen
Damit sind Kp, Ki und Kd gemeint, nicht eine neue Variable?

- Ta die Abtastzeit.
Sind das die besagten 2ms, oder tatsächlich die Zeiten, die sich durch die Tik's ergeben?
Ich tippe eher auf die 2ms.

- und die ks Indizes
Soll bestimmt auch eher k's sein? (k in Mehrzahl)

- Kp*(ek+Kd/Ta*(ek-e(k-1))
Hier verstehe ich die Multiplikation mit dem Kp nicht. Warum wird die gesamte Klammer, die den Reglerwert Kd enthält, auch mit Kp multipliziert?
Aufgelöst gibt das ja:
Kp*ek + Kp*(Kd/Ta*(e(k)-e(k-1))
Proportionaler Faktor mit Differenziellem Faktor multiplizieren?
Ich glaube, hier liegt überhaupt mein Problem, dass mir die Reglergrundlagen so verflixt, 'nur im Prinzip, geläufig sind.

- mit deinen alten Werten von K
Was sind alte Werte von K? Wo kommen neue Werte her? Bis jetzt hast du in der Formel ein y ausgerechnet, von dem ich annehme, dass es die 'Stellgröße' ist, die den Motor (oder was auch immer) so beeinflusst, dass alles am Ende gut ist.

- das reglerverhalten ausrechnen
ähm, muss ich ein Reglerverhalten ausrechnen? Wird das Verhalten nicht durch die PID-Parameter eingestellt? Klar, dass ich die erst ausrechnen muss, aber doch nicht mit der angegeben Formel. (Da bin ich mir relativ sicher.)

- das reglerverhalten ausrechenen, und damit auch, wie du deine Verstärkungen ändern musst
Ja genau, aber da stehe ich ziemlich auf dem Schlauch.

- ek, e(k-1) und Sum(ei)
Ist ek ein e(k)?
Was sind e und ei?
e(k) hört sich nach aktuellem error an. e(k-1) nach letztem error.
ei hört sich nach einem error-integrier-wert an.
Ist total geraten!

So, ich glaube, dass ich bewiesen habe, das ich erst einmal einen Grundlagenkurs benötige ;-).
Für mich aber bitte aktuell nicht deine Zeit verschwenden. Wahrscheinlich ist das alles ganz einfach, wenn man nur ein bisschen in der Materie steckt.
Ich werde erst einmal die Mathematik von mare_crisium umsetzen.

als die Regler noch mit Druckluft liefen (Tatsache, kein Schmäh!) sehr zuverlässig.Dazu kenne ich einen OT aus meiner Jugend.
- Lagersteuerung in England.
- Telefonische Fehlermeldung auf Englisch. (Geht so gerade, siehe unten ;-))
- Hubtisch wurde nicht angesteuert. Software von meiner Firma.
- In der Software nichts entdeckt.
- Hatte empfohlen, das die Jungs mal den Druckluftschlauch prüfen sollten.
-- Treffer. Da war ich ganz stolz, dass ich als Softwarefutzi an die Hardware gedacht hatte.

Gruß Sternthaler

jeffrey

22.11.2007, 00:39

Hi,
fürs raten war das ziemlich gut. Du hättest heute Lotto spielen sollen. Wären mindestens 6 richtige gewesen, ob es für die richtige Zusatzzahl auch noch gereicht hätte, muss ich mir mal morgen anschauen ;-)
Habe hier mal die Formel als Bild, so sollte es verständlicher sein. Wie gewünscht dieses mal Kp nicht vor der Klammer, ist völlig egal, dann hat man halt ein anderes Kd, bzw. Ki für das gleiche Reglerverhalten, das ist das gleiche, was ich meine, wie sich die Konstanten ändern, wenn man die Abtastzeit ändert.
e sind die Abweichungen vom Sollwert zum Zeitpunkt k, bzw k-1.
So jetzt dann aber gute Nacht.
Gruß Jeffrey

Sternthaler

22.11.2007, 01:29

Hallo Jeffrey,
ich hasse Werte, die man einfach so frei nach Schnauze ändern darf, und ich nicht weiß warum :Haue. Aber so erklärt, kann ich es verstehen, dass man auf ein gleiches Reglerverhalten kommt.

Auch eine ruhige, gute Nacht.
Gruß Sterntahler

jeffrey

22.11.2007, 11:17

hi,

Wären mindestens 6 richtige gewesen, ob es für die richtige Zusatzzahl auch noch gereicht hätte, muss ich mir mal morgen anschauen
seh grad was ich da für ein schwachsinn geschrieben hab, soll natürlich superzahl heißen, net zusatzzahl, war ja aber au scho spät ;-)

so jetzt aber zurück zum thema:
ich habe jetzt ers mal eine frage zu deiner realisierung vom d-anteil? du bekommst ja nur ca alle 10 regler durchläufe einen neuen messwert, hoff ich hab mich jetzt net verrechnet. das bedeutet ja, bei 9 durchläufen ist die änderung zum vorherigen 0, also der d-anteil auch 0, hast du das irgendwie kompensiert? sonst kannst du den d-anteil ja eigentlich gleich weg lassen.
so jetzt zum verändern der abtastzeit(das sind die 2ms). wenn du jetzt z.b. auf 20ms gehst, also Ta_neu=10*Ta_alt, dann musst du halt auch Kd und Ki verändern. Also Kd_neu=10*Kd_alt und Ki_neu=Ki_alt/10 K_alt sind die Reglerparameter, die du in deinem Programm verwendest, bei 2ms abtastzeit. K_neu sind dann die, die du verwenden solltest, wenn du die abtastzeit auf 20ms erhöhst. diese rechnung stimmt natürlich nur, wenn der regler nach der oben beschrieben gleichung arbeitet. aber das hat waste bestimmt beschrieben, welche gleichung er verwendet.
Ich hoffe, das war jetzt einigermaßen verständlich, ich wollte hier nur beschreiben, wie du da drauf kommen konntest. ich hoffe es hilft dir.
mfg jeffrey

Sternthaler

22.11.2007, 20:16

Hallo zusammen (es scheint sich nun bei 4-ren einzupendeln).
Alle Mitleser sind natürlich auch gegrüßt.

Um erst mal sicherzustellen, was ich immer mit dem waste-Regler meine:
Asuro: Linienfolger mit PD-Regler (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=11818)
So, das wäre erst einmal klargestellt.

Jetzt die Ungereimtheiten:
- Der Thread heisst "PD-Regler", ist aber ein waschechter PID-Regler geworden.
- Alle weiteren Ungereimtheiten gelten nicht.

Ein paar Einsprungpunkte zum Thread, von denen ich glaube, dass die irgendwie wichtig sind:
Hier (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=107109#107109) ist der Messaufbau von Manf zum Ermitteln des Trägheitsmomentes in Drehrichtung. (Heisst das so?)
Hier (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=107247#107247) berechnet Manf aus seinen Messungen das Trägheitsmoment.
Hier (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=108923#108923) setzte waste Bode-Diagramme in PID-Werte um.
Hier (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=109170#109170) werden die Ergebnisse von waste in ein Programmiermodell umgesetzt. Da müsste sich ja die eigendliche Formel von waste am einfachsten finden lassen.
Hier (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=110308#110308) ist die letzte, von mir gefundene, Programm-Version von waste für den Asuro.

Und wie ich gerade sehe Jeffrey, kennst du den Thread ja auch auswendig ;-)
Jeffrey was here (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=153371#153371)

Deiner Ausführung Jeffrey, zur Änderung an der Abtastzeit, konnte ich wohl folgen. Aber auch nun wieder mein Problem, dass ich nicht nachvollziehen kann, dass es überhaupt erlaubt sein soll so zu rechnen. Macht aber nix.
Vielleicht mal zum Unterschied zu dem, was ich von mare_crisium bis jetzt gelesen habe: Das habe ich verstanden, da dort Geometrie mit der Mathematik formuliert ist. Bei solchen Sachen kann ich mir das irgendwie vorstellen.

Gruß Sternthaler

jeffrey

22.11.2007, 21:45

Hallo,
oh, das ist ja schon ne ganze weile her. aber geht es da nicht um die linienverfolgung?
denke mal es wurde die reglergleichung verwendet, die steht auch im wiki.
probier doch mal aus, was passiert, wenn du die zeit veränderst und die parameter anpasst.
wie hast du denn jetzt das problem mit dem d-anteil und der langsamen messung gelöst?
mfg jeffrey

jeffrey

22.11.2007, 23:14

Hallo,
ich bin´s nochmal. Diesmal habe ich paar Fragen an mare_crisium zum Koppelnavigation_Algorithmus_V03.pdf. habe es mir gerade mal angschaut. Kann es sein, dass bei der Berechnung von vl und vr ein geteilt durch delta_t fehlt?
warum nimmt du für die winkelabweichung das kreuzprodukt, also den sinus? warum nicht einfach direkt die winkeldifferenz?
und dann noch ne frage zum anfahren eines punktes mit richtungsvorgabe. dieses regelungskonzept funktioniert aber nur, wenn der richtung ungfäh aus der richtung kommt, in die er den punkt durchfahren soll. unterscheiden sich die richtungen ist glaube ich doch eine bahnplanung notwendig. aber von der idee her nicht schlecht.
gute nacht jeffrey

Sternthaler

23.11.2007, 16:52

@Jeffrey
Es geht hier, in diesem Thread, nicht um die Parameter aus dem Linienverfolgungs-Regler!
Das ein Regeler hier mal benutzt werden soll, wurde erwähnt, um eine 'sanfte Kurve' hinzubekommen, um den Asuro (oder jedes andere Fahrzeug, oder auch Arme) von Punkt A zu Punkt B zu bewegen, ohne dass 'per Handbremse' oder 'mit schleuderndem Heck' um die Ecke gefahren werden muss.

Allerdings ist Programmcode zum Algorithmus eines PID-Reglers im Linienverfolgungs-Thread vorhanden. Der soll nur benutzt werden.
Neue Parameter wird dann mare_crisium irgendwann in Zukunft machen, oder, so wie er es vorgeschlagen hat, von mir durch 'Versuch, macht klug' geraten werden.

Gruß Sternthaler.

mare_crisium

23.11.2007, 17:47

jeffrey,

mit fehlenden der Division durch delta_t bei der Berechnung von v_r und v_l hast Du allerdings recht. Die neue, korrigierte Version ist schon in der Mache. - Danke für den Hinweis! :-)

Das Kreuzprodukt ist der wirkliche Clou an der Geschichte: Erstens ist es im Bereich kleiner Winkelabweichungen praktisch proportional zur Winkelabweichung; d.h. die Fein-Navigation wird sehr gut funktionieren. Zweitens kann man's in Assembler berechnen (ohne Winkelfunktionen bemühen zu müssen). Drittens spart man sich die grauen Haare, die es immer gibt, wenn man die Ist- und Sollwinkel in Grad rechnet und beide auf verschiedenen Seiten der 360°-Grenze liegen ;-).

Der einzige Nachteil ist das Abnehmen der Regelabweichung, wenn die Winkelabweichung 90° über- bzw. -90° unterschreitet. Das kann man aber auch richten, indem man als Regelabweichung die 1 nimmt, wenn das Skalarprodukt der Ist- und der Sollrichtung kleiner gleich 0 ist. Das Skalarprodukt ist auch wieder ein rein linearer Zusammenhang, wenn man Einheitsvektoren verwendet; also kriegt man's wieder ohne Winkelfunktionen hin.

@SternThaler,

yup, das "Versuch macht kluch" - Verfahren zum Ermitteln der Regelparameter werden wir dann anwenden. Meiner Erfahrung nach ist es schneller als wenn man erst ein mathematisches Modell entwirft, und es liefert robustere Einstellungen.

Ciao,

mare_crisium

BlackDevil

24.11.2007, 09:17

Sersn

ich muss mal ganz doof fragen ob es doch tatsächlich so super schwer ist einer Linie zu folgen? Hab mir ein paar Sourcecodes durchgelesen und das scheint ja in der Tat doch schwerer zu sein als ich erwartet hatte (und ja ich hab immer noch keinen µC daheim liegen und dümpel in der theorie rum) ^^

mare_crisium

24.11.2007, 19:40

BlackDevil,

doof ist Deine Frage auf gar keinen Fall :-). Mit Linienfolgern habe ich mich noch nicht beschäftigt und hier kümmern wir uns darum, ein Fahrzeug ganz ohne Linie zu vorbestimmten Wegepunkten fahren zu lassen. Wenn Du das Thema Linienfolger von der mathematischen Seite her aufziehen willst, solltest Du einen separaten Thread in diesem KI-Forum aufmachen. Ich würde mich beteiligen und Du kriegtest bestimmt auch Unterstützung von Leuten, die das Problem schonmal durchdacht und gelöst haben.

Meiner Meinung nach hängt der Schwierigkeitsgrad stark von der Art der Sensoren ab, mit der man die relative Lage von Fahrzeug-Längsachse und Linie misst: Oft sieht man nur drei Reflektions-Lichtschranken - das ist schwierig. Wenn man einen kompletten Liniensensor verwendet, etwa aus einem Scanner - das macht es viel einfacher. -

Ciao,

mare_crisium

oberallgeier

24.11.2007, 21:26

... fragen ob es ... schwer ist einer Linie zu folgen?Also es ist wirklich garnicht einfach. Beispiele: Das Allereinfachste - versuche mal GENAU auf der Mittellinie der Strasse zu fahren (bitte NUR wenn weit und breit kein anderes Fahrzeug da ist und Du noch VIEL Strasse einsehen kannst). Ich hab schon immer Schwierigkeiten in der Autowaschanlage, einigermassen die Mitte zu finden. Oder, nimm Dir nen Flieger (es reicht ein Flugsimulator) und fliege NUR nach dem CDI (Kursablaganzeiger, CDI = Course Deviation Indicator). Das ist eine Nadel, die anzeigt, ob Du links oder rechts vom Leitstrahl bist. Und da braucht man schon sehr viel Gefühl für die Trägheit des Dings, um wieder auf den Strahl zu kommen. Das Gleiche gilt für die Höhe über oder unterm Leitstrahl. Ähnliche Probleme, fast noch gravierender, hat man im U-Boot, wenn man eine bestimmte Höhe (ist ja auch ne Linie) halten will.

Jetzt haben wir aber einen roboter mit SEHR eingeschränkter Sensorik. Ich glaube das ist Dir dann ganz ohne Mathe klar, dass da ein Problem auftaucht. Als Mensch ist das einfach zu lösen: Du hast komplexe optische Sensoren, taktile (Deine Füsse wissen schon recht gut, ob DU linkslastig oder rechtslastig gehst), Gleichgewichtssinn (schwanke ich ...), eine komplexe "Datenverarbeitung" . . . Ich will das jetzt nicht zu sehr ausbreiten. Du verstehst es sicher.

Wie sehen jetzt Lösungen aus? Eine besonders pfiffige Lösung kenn ich vom U-Boot. Es ist von der Physik her praktisch eine Art Wurfparabel, die vorhersagt, in welcher Höhe ich in - sagen wir mal - in 20 Sekunden bin. Diese einfache Vorhersage erlaubt eine dramatisch verbesserte Steuerbarkeit. Und solche Vorhersagestrategien sind für die genaue Einhaltung einer Route das Thema des Threads: Algorithmen zur Bahnplanung. Natürlich gehört die Erfassung der Situation dazu:

... hängt der Schwierigkeitsgrad stark von der Art der Sensoren ab, mit der man die relative Lage von Fahrzeug-Längsachse und Linie misst: ...

Daher auch einige Diskussionen über Weg- und Geschwindigkeitsmessung hier. Aber diese Fragen sind lösbar - mehr oder weniger gut.

mare_crisium

25.11.2007, 07:05

@Alle,

so, jetzt ist die neue Version V06 fertig, allerdings noch ohne die Ergänzungen für die SternThaler-Methode zur Drehwinkelmessung an den Rädern. Dafür berücksichtigt sie die Korrektur von jeffrey und gibt auch eine modifizierte Rechenvorschrift für erhöhte Schätzgenauigkeit an.

Ciao,

mare_crisium

Edit1: Habe den Anhang "Koppelnavigation_Algorithmus_V06.pdf" gelöscht. Die korrigierte Version V07 ist im Post vom 28.11.2007 zu finden.

BlackDevil

25.11.2007, 09:10

Okay vielen dank. Wusste gar nich das das insgesamt so aufwendig wird, also Mathematisch...
Ich denke ich mach im laufe des Tages mal nen Mathethread auf hehe

Sternthaler

27.11.2007, 01:45

Hallo alle zusammen,
ja, es wird so langsam Weihnachten.

Genau aus diesem Grund, und weil der erste Ansatz nun im Asuro steckt, hier mal auf die schnelle das ganze Zeug.

Die rechnende Funktion als Ausschnitt aus asuro_st.c:
/************************************************** ***************************
FUNKTION: NaviCalc
Aufgabe: Funktion zur Berechnung der Navigationswerte.
Diese Funktion wird im ADC-Interrupt aufgerufen um die aktuellen
Positions-Koordinaten und Richtung vom Asuro anhand der Daten
der Odometrie zu berechnen.
Ausgewertet werden die globalen Variablen count36kHz_l .._r
Die Ergenisse werden in einer globalen Datenstruktur fuer die
Anwendung zur Verfuegung gestellt.
Parameter: seite Angabe, an welcher Rad-Seite der Tik gerade
aufgetreten war.
Global: count36kHz_l
count36kHz_r
V011 26.11.2007 Sternthaler
Funktion in erster Version
************************************************** ***************************/
unsigned char NaviCalc (
unsigned char seite)
{
static double speed_last_l = 0;
static double speed_last_r = 0;
double speed_l;
double speed_r;
double speed, omega, zeit;
double omega_zeit = 0, speed_zeit = 0;
static double phase_x = 0;
static double phase_y = 1;
static double pos_x = 0;
static double pos_y = 0;

if (seite == RECHTS)
{
speed_l = speed_last_l;
speed_r = 10789.0 / count36kHz_r;
speed_last_r = speed_r;
zeit = count36kHz_r / 36000.0;
count36kHz_r = 0;
}
else
{
speed_l = 10789.0 / count36kHz_l;
speed_r = speed_last_r;
speed_last_l = speed_l;
zeit = count36kHz_l / 36000.0;
count36kHz_l = 0;
}

/*
Mittelere Geschwindigkeit
*/
speed = (speed_r + speed_l) / 2;

/*
Drehwinkel. Die 10.36 sind der Radabstand.
*/
omega = (speed_r - speed_l) / 10.36;

/*
Neue Phasenwerte berechnen
*/
omega_zeit = omega * zeit;
phase_x = phase_x - phase_y * omega_zeit;
phase_y = phase_y + phase_x * omega_zeit;

/*
Und endlich auch die neuen X- und Y-Positonen
*/
speed_zeit = speed * zeit;
pos_x = pos_x + phase_x * speed_zeit;
pos_y = pos_y + phase_y * speed_zeit;

MD_RAD_POS_HIST ((int)(pos_x * 100), (int)(pos_y * 100));

return 0;
}
Ich weiß. Noch wird mit Fließkomma gerechnet. Noch sind nicht alle notwendigen Rechenschritte vorhanden. Und auch bei der Berücksichtigung der beiden Tik-Zeiten-Zähler ist bestimmt noch ein dicker Fehler vorhanden.
Aber, das Ergebnis ist schon nicht allzu schlecht.

Die besten Zahlen stecken zur Anschauung im Excel-Diagramm.

@mare_crisium
Deine neueste Version V06 ist noch nicht gelesen. Ich schätze, dass ich somit um das Schätzen dann demnächst auch nicht herrumkommen werde. Ich schätze aber, dass dies auch wieder etwas dauern wird :Ostern .

... für die Trägheit des Dings, ...
Ich fühle mich geradezu angesprochen. :cheesy:
P.S.: Ich glaube, der Asuro mit Taucheranzug ist noch nicht gebaut worden ;-). Du erklärst die Probleme immer sehr schön bildlich. Klasse.

So, viel Spaß mit dem Codehaufen.
Gruß Sternthaler

BlackDevil

27.11.2007, 07:31

Wie gut das mein Visual C++ auch C lesen kann :)
Dann les ich mal.

Generell in der Theorie würde mich das mal Interessieren. Ich bin nich doof oder sowas aber für das obige Scriptbeispiel muss man Maschbau oder Physik Studieren ums zu verstehen oder :D Ich weis Grob was da abgeht, Vektoren und so, das Verlässt aber mein Bisschen Hochschulwissen das dafür Ausreicht irgendwelche lustigen Elektronen in irgendwelchen Feldern zu Berechnen, Theoretisch... Felder kommen erst nächstes Semester ^^

Sternthaler

27.11.2007, 09:27

Hallo BlackDevil,
toll, dass C++ lesen kann ;-)

Wenn du alle Beiträge in diesem Thread auswendig kennst, dann kannst du das auch nachvollziehen. ;-)
Schlieslich habe ich es auch (teilweise) geschafft aus den guten, hier gegeben, Bedienungsanleitungen diesen Code zusammenzustricken.
Als kleiner Hinweis, woher die da angegeben Zahlen herkommen:

- 10789.0 [cm/s^2 (glaube ich)] ist ein Faktor, der die Geometrie vom Asuro an der ODO-Scheibe darstellt. In dem hinterlegtem EXCEL-Blatt (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=318741#318741), im Reiter 'v und Zählerberechnung', wird der Wert in Anhängigkeit zwischen Raddurchmesser, und Tik-Anzahl pro Radumdrehung, berechnet.

- 36000.0 [1/s] sind die 36 kHz, mit der ein Timer im Asuro rennt. Dieser liefert die Zählwerte zwischen 2 Tik's.

- 13.36 [cm] ist einfach der Radabstand. In mare_crisium's Ausführungen sind das 2*a.

Der Rest ist meine künstlerische Variante der Umsetzung aus dem Koppelnavigation_Algorithmus von mare_crisium.

Ich hoffe, das dies etwas hilft. Und lass die Elektronen schön an ihren Plätzen, nicht dass die Welt auseinander bröselt ;-).

Gruß Sternthaler

oberallgeier

27.11.2007, 12:03

... Und lass die Elektronen schön an ihren Plätzen, nicht dass die Welt auseinander bröselt ;-)...
Ja, wenn das nur ginge. Die Elektronen sind doch die, die alles durcheinanderbringen. Rennen von einem Pol zum anderen, kaum setzt man ihnen ein bisschen Widerstand entgegen, sind sie auf 180 und mehr aber wenn sie mal direkt aufeinandertreffen - also leider ist das Netzteile meines "Hauptrechners" gerade den Hitzetod gestorben (wo der vor 10 Tagen schon die SystemHDD unbrauchbar gemacht hatte).

Die Neutronen sinds, die´s bringen. DIE halten das Universum zusammen. Und dabei sind sie kaum zu erkennen . . . beneidenswert!

Sternthaler, eigentlich wollte ich mit "Danke für das Lob" anfangen. Aber ich neige eben zu solchen OT-Abschweifungen.

Ach ja - wieviel Tics pro Radumdrehung sind beim Asuro üblich? Ich frage nur, weil ich für mein Miniprojektchen die erforderliche Auflösung abschätzen möchte.

BlackDevil

27.11.2007, 14:06

Mir gings ja nich um die Direkte Umsetzung sondern die Überlegung

Problem --> Mathematik <--> Physik ==> Gleichungen

Nehmen wir mal das Beispiel das ich einen Motor mit dem Drehmoment M=2Nm, zwei Angetriebene Räder mit dem Durchmesser d=10cm, eine Strecke von s=1m habe wobei ich 56° um die Kurve fahren will welche eine länge von 20cm hat. Jetz hab ich ja eigentlich alles was ich wissen muss um mir Gleichungen aufzustellen.

v lässt sich aus der Frequenz der Räder errechnen. Ferner nehmen wir mal an das die räder Zylinder sind. Das machts einfacher das Trägheitsmoment auszurechnen.

Wenn wir v und s haben als Gleichung können wir wunderhübsch ausrechnen wielange wir zur Kurve brauchen.

Ab dann Verlässt mich die Überlegung.

So meinte ich das (= Wie man das denn am besten umsetzt. Klar hab ich meine "Algorithmen" wie ich bei sowas vorgehe, die Versagen nur bei Manchen Aufgaben in Physik.

JOa^^

edit: Ich glaube das Universum fände es schon nich so schön wenn ein C Atom oder ein O Atom aufeinma 2 ELektronen weniger und ein anderes dafür 2 Elektronen mehr hat ;)

oberallgeier

27.11.2007, 15:10

Nehmen wir mal das Beispiel das ich einen Motor mit dem Drehmoment ... ... Jetz hab ich ja eigentlich alles was ich wissen muss um mir Gleichungen aufzustellen.Ach weisst DU, das ist nicht sooo schwer - wenn man mal einen Ansatz für den Weg hat. Das wirst Du üben und dann hinkriegen. Zu Deiner Aufgabe oben (Problem --> ...) gehe ich so ran: (1) mechanisches Modell - (2) physikalisches Ersatzmodell - (3) Gleichungsansätze (erst ab hier ist Mathe angesagt) - (4) Lösung der Gleichungen - (5) technische Möglichkeiten - (6) Realisierung/Umsetzung. Manchmal sollte man (2) schon mit einem Blick auf (5) bearbeiten oder ähnliche Seitenblicke riskieren. Die Ausarbeitung von mare_crisium ist ja ein schönes Beispiel dazu. Negativ: Ich hatte mal eine Ausarbeitung von einer Uni zu einem schwingenden System (eine bestimmte, reale Maschine). Die hatten 22 Freiheitsgrade gefunden - das war vermutlich nicht falsch, trotzdem war es eine unsinnige, unnötige Arbeit, weil kein Mensch 30 bis 40 Parameter oder Randbedingungen bestimmen wird. Ich hatte daraus einen viergängigen Schwinger gemacht :). Und in Basic die Lösung der DGLn geschrieben.

Aber jetzt stehe ich an: kann kein C und will damit die AVR´s programmieren :( - nee, nicht so, eher :) :) :), dann gehts leichter.

Ich glaube das Universum fände es schon nich so schön wenn ein C Atom oder ein O Atom aufeinma 2 ELektronen weniger und ein anderes dafür 2 Elektronen mehr hat ;)
Hast Du in der Schule Chemie gehabt? Beim Thema "Ionen" warst Du vermutlich beim Billardspielen - wie ich dauernd in Geo!? Ich wollte das OT vorhin nicht ausbreiten, aber die Elektronen sind wirklich DAUERND Störenfriede. Wissen oft nicht, zu welchem Atom/Molekül sie gehören, hüpfen von einer Schale auf die andere, man hat auch nur eine UNGEFÄHRE Ahnung wo die sind (E-Wolke) usw usf - aber dem Universum ist das schnurzegal. Es besteht trotzdem.

BlackDevil

27.11.2007, 18:37

Ja aber die Anzahl Atome innerhalb eines Bestimmten ist trotzdem rel. bestimmt. Und wenn dem C atom ein Elektron Fehlt ist das ähnlich uncool als wenn ein Neutron fehlt. Oder ;)?

Auch in einem ELektrischen Leiter herrscht nur Ladungsträger Austausch

Sternthaler

27.11.2007, 22:09

Hallo oberallgeier
Grin, wir wissen doch alle, dass dies wahrscheinlich der Thread mit dem höchsten OT-Aufkommen ist.
Aber musstest du denn zur Bestrafung vom Netzteil gleich zum Kurzschlußstecker greifen, nur weil es deine Platte gegrillt hatte? ;-)

Ob es bei der Tik-Anzahl am Asuro einen Standard gibt, möchte ich bezweifeln. (Wahrscheinlich gibt es aber nur relativ wenige Varianten.)
Meiner wurde mit 2 Scheibenpaaren ausgeliefert. (2,5 Jahre alt)
je 8 schwarz- + weiss-Flächen -> 16'er-Scheiben
je 4 schwarz- + weiss-Flächen -> 8'er-Scheiben
Dann glaube ich noch irgendwo gelesen zu haben, dass es auch 12'er und 24'er gibt.
Da beim Asuro 'danach' noch eine Getriebstufe von 5:1 kommt, haben wir somit 16*5 oder 8*5 Tik's pro Raddrehung, wenn jeder Farbwechsel als Tik interpretieret wird.
Genau für diesen Thread nutze ich aber, wegen der unterschiedlichen Zeiten bei der schwarzen und weißen Fläche, nur die Wechsel von schwarz nach weiss. Also Tik-Anzahl halbiert. (Ich habe die 16'er-Scheiben drauf)

Hier kann man noch 2 Besonderheiten finden:
Probleme mit 22er-Lochscheiben (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=35109)
Verschiedene Muster für die Odometriescheiben (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=27081)
(Da ich bei beiden erwähnt werden, verfestigt sich so langsam mein Bild über mich selbst: Da habe ich wohl eine Manie ;-))

Hallo BlackDevil
Was du dir für Fragen stellt ;-) Bei mir ist das gaaanz, gaaanz anders.
Auch ich habe ab und zu das Problem, dass die Formeln manchmal versagen. (Bei mir liegt es dann aber eher daran, dass ich Elekronen und Neutronen durcheinander bringe. Äh, meine natürlich Äpfel und Birnen.)
Ja, du hast schon Recht. Erst mal Überlegen und dann Umsetzen, auch ich bin da meistens so orientiert.

Und natürlich auch ein Hallo an dich, mare_crisium
So, ich habe gerade deine Version 6 gelesen. Das wird ja eine richtige Vorlesung für Asuro-Kapitäne-und-Heizer. (Vor allem für Heizer, da die das ja nun auch verstehen können.)
Kleine Frage zur Formel direkt vor der modifizierten Formel (8a), in der v(i) * omega(i) berechnet werden.
Ist es da richtig, dass als Indice für R, n und N immer nur r angegeben ist? Beim Einsetzen von dem Zeug um (8a) zu bekommen würde ich jetzt Indice l vermissen.
(Irgendwie hätte ich bei PI * ( ((Rr*nr) / Nr) + ((Rr*nr) / Nr)) * (PI/a) * (....) hinter dem + bzw. - in den Klammern eher etwas mit Indice l erwartet.)

Ha, und dann noch die Angabe, dass man bei der Berechnung einer Zielfahrt, bei Richtingsabweichungen von mehr als 90Grad, höllisch aufpassen muss. (Wenn man bei deltaP = 0 in die falsche Richtung schaut, steht man ja vor einem dummen Problem.)
Diese Beschreibung kann ja nur direkt für mich gemacht worden sein. Danke.
Und zum Schluß: Du hast einen schönen, zusammenfassenden Schluß gefunden, der die Vorteile dieser Art der Wegberechnung, die ja eher eine Fahr-einfach-zum-Ziel-Berechnung ist, aufführt.
Echt Klasse.

Gruß Sternthaler

P.S.: Ich bin wieder zu lahm. 2 Beiträge seitdem ich hier tippe.
Fehlende Elektronen kann nur bedeuten, dass die noch bei mir im Akku sind. Somit fährt mein Asuro noch ;-)

jeffrey

27.11.2007, 23:06

hi,
@sternthaler: was war denn bei der fahrt, für die du die daten aufgezeichnet hast der sollwert? welcher zielpunkt und welcher winkel. kannst du mal bei einem nächsten versuch die wirklich gefahrene strecke messen. also zum beispiel als ziel einen punkt in 2m entfernung, und als winkel 80° und dann mal den punkt vom startpunkt aus ausmessen, damit wir mal sehen, wie gut er den punkt trifft. und den winkel nachmessen.
mfg jeffrey

mare_crisium

28.11.2007, 08:31

@SternThaler und @Oberallgeier,

danke für Eure Anmerkungen zu V06. Ich habe sowohl die Formel vor (8a) jetzt korrigiert, als auch die Vorzeichen-Vereinbarung für den Richtungswinkel der üblichen mathematischen Konvention angepasst (negativ entspricht dem Uhrzeigersinn und umgekehrt). - Nachdenken war in der letzten Woche etwas erschwert wegen der zwei Weisheitszähne, von denen ich mich verabschiedet habe... jetzt geht's aber wieder. Die neue Version V07 hänge ich an und lösche dafür die V06, der Upload-Quota wegen ;-).

mare_crisium

Sternthaler

28.11.2007, 22:34

@sternthaler: was war denn bei der fahrt, für die du die daten aufgezeichnet hast der sollwert?
- Keine Koordinaten-Sollwert-Vorgabe.
- Ziel war es, Messdaten bzw. Rechenergebnisse für die ersten 100 gefahrenene Tik's zu sammeln.
- Vorgegeben Fahrt waren 100Tik's * 3 mm/Tik.
--- Erste Fahrt: 100 Tik's geradeaus
-----> Die berechnete Abweichung ist zu groß.
--- Zweite Fahrt: 25 Tik's geradeaus. Den Rest in einem Linksbogen
-----> Die berechnete Abweichung ist zu groß. Der Bogen wurde nicht so weit gefahren.

Hallo mare_crisium,
ich hoffe, dass du die Weisheitszahn-Verabschiedung ohne Komplikationen überstanden hast. Auf alle Fälle wünsche ich dir eine Gute Besserung, und keine weiteren Zahnschmerzen. (P.S.: V07 ist schon kopiert)
Gruß, der Mitfühlende

.. aber dem Universum ist das schnurzegal. Es besteht trotzdem.Hoffentlich aber nicht in einer Nußschale, wie von Stephen postuliert. 8)

Tschaui, Sternthaler

mare_crisium

14.12.2007, 21:50

@SternThaler,

vielen Dank für Deine guten Genesungswünsche! Sie haben auch noch für die anschliessende Pflicht-Grippe gereicht :-)!

Also, hier ist eine nocheinmal überholte Version, in der ich versucht habe, die Idee mit der verbesserten Schätzgenauigkeit graphisch zu erklären.

Die Daten, die Du mit Jeffrey diskutiert hast, sind die schon mit dem Algorithmus gefahren? Wenn ja, dann hift vielleicht die Verbesserung noch ein bisschen, die Genauigkeit Deinen Vorstellungen näher zu bringen.

Ciao,

mare_crisium

Sternthaler

15.12.2007, 00:28

Holla Mare Crisium (http://de.wikipedia.org/wiki/Mare_Crisium),
gut, dass das gute Genesungswünsche waren. Sonst hättest du ja zumindest noch den Schnupfen.
Ich hatte schon Angst, dass dich meine 'Geschwindigkeit', hier etwas umzusetzen, so gelangweilt hat, dass du in einen Dauerschlaf gefallen wärst. ;-)

Wie so üblich bei dir, ist es für mich wieder Verständlich geworden, was du beim Schätzen verbessert hast.
Das trifft sich auch ganz gut, da meine letzte Programmversion ja nur eine Version zum testen der Formeln war. Also, wie oben mit jeffrey, besprochen, noch nichts mit Zielvorgaben.
Außerdem hatte ich erst die einfachste Variante der Berechnung ohne Korrekturen benutzt.

Mittlerweile bin ich mir aber ganz sicher, dass die Abweichung zwischen Fahrt und XY-Berechnung nicht an der Formel liegt, sondern vor allem an meinem Testprogramm.

So mache ich da das Rechnen:

- Timerinterrupt
-- Zähler für beide Seite erhöhen.
-- AD-Wandler abwechselnd für die ODO-Scheiben anwerfen.

- AD-Interrupt
-- Wandlerergebnis auf schwarz-/weiss-Wechsel untersuchen.
-- Bei TIK-Erkennung die XY-Berechnung ausführen.
-- Diese Ergebnisse sammeln

- Hauptprogramm
-- Fahre N Tik’s geradeaus.
-- Fahre M Tik’s im Bogen.
-- Stoppe den Asuro, wenn der Datensammler voll ist.
-- Sende die gesammelten Daten auf Tastendruck zum PC.

Die Fahrt vom Asuro kann ich mir schön ansehen.
Somit weiß ich, was ungefähr berechnet sein sollte.

Die berechneten Daten zeigen aber eine recht hohe Abweichung.

Warum:
Ich hatte schon 'vor ein paar Tagen' geschrieben, dass meine Tests, in Bezug auf die Rechenleistung des AVRs, ausreichen sollte. Ich war so auf maximal 80% CPU-Zeit bei voller Asuro-Geschwindigkeit gekommen.
Also lag der Gedanke nahe, die Rechnung direkt im ADC-Interrupt machen zu lassen. Zeit reicht ja schließlich.
Das ist aber ein fataler Fehler, da dann keine anderen Interrupts mehr ausgeführt werden, und somit die Zähler für die beiden Seiten im Timerinterrupt nicht mehr bearbeitet werden. Dadurch wird kein neuer AD-Wandler gestartet, und dadurch gibt es auch keine Erkennung eines weiteren Tik’s.
Also kommt zu den falschen Zählerwerten auch noch hinzu, dass eventuell 2 Tik’s gefahren werden, aber nur als ein TIK in der nächste Berechnung berücksichtigt wird.

--> Alles durcheinander. Dafür ist das Ergebnis erstaunlich gut. #-o

Also schon mal eine neue Lösung ausgedacht.
Berechnung der XY-Werte außerhalb der Interrupts machen. Das gehört sich ja auch so, da man allgemein weiß, dass Interrupts möglichst schnell fertig sein sollen. Und nicht 80% CPU fressen dürfen.

Na ja, so weit bin ich schon. Habe aber noch keine Zeile Code für den Asuro angefasst, da der Code in der Firma eine höhere Priorität hat. (Die Prio ist nicht auf meinem Mist gewachsen. Wirklich nicht!)

Mal sehen, der nächste Urlaub ist geplant. Vielleicht schaffe ich es diesmal nicht die ersten Tage davon in der Firma rumzulungern. Dann kann es evl. mit dem Asuro weitergehen.

Gute Nacht und
viel Grüße vom Sternthaler.

mare_crisium

15.12.2007, 02:04

SternThaler,

... und ausserdem kommt jetzt erstmal Weihnachten.

Ciao,

mare_crisium

Sternthaler

20.07.2008, 03:02

Hallo zusammen.
Nun, Weihnachten ist definitiv vorbei.

Also, das Thema ist noch lange nicht vom Tisch und mit der Hartnäckigkeit eines verzweifelten Asurobesitzers geht es nun weiter.

Zur Erinnerung:
- Mathematik zur XY-Berechnung ist vorhanden (Dank mare_crisium)
- Rechenleistung zur Umsetzung im AVR scheint gegeben zu sein.
- Verlagerung in Interrupt steht an. (Sternthaler (ich) behauptet dies.)

Mein Problem ist folgendes:
Das im Anhang vorliegende Testprogramm liefert nicht immer Geschwindigkeitsdaten von 0, wenn die Motoren NICHT drehen. Das ist definitiv falsch. Ich habe aber keine Vorstellung, wo der Fehler steckt.

Vorgehen im Programm:
- Timerinterrupt zählt 1/36000 Sekunden.
- Timerinterrupt startet Odometrie-Messungen (AD-Wandler).
- AD-Interrupt zählt Odometriewechsel .
- Hauptprogramm sendet per asuro_st.c/NaviPrint() Odo-Daten und Zählerdaten alle 500 ms an PC.
- PC wertet diese Daten in Excel aus, und kommt bei stehenden Motoren mit den übertragenen Daten NICHT zum Ergebnis, dass die Motoren stehen.
--> Somit würden XY-Koordinaten berechnet, die falsch sind.

Die Messdaten sind so zustande gekommen, dass die Motoren:
- nicht drehen
- langsam drehen
- nicht drehen
- schnell drehen
- nicht drehen
- langsam drehen
- nicht drehen

In den Exceldaten sieht man aber:
- "nicht; langsam; NICHT nicht; schnell; nicht; mittel; NICHT nicht"
- "nicht; langsam; nicht; schnell; NICHT nicht; langsam; nicht"

In keiner meiner unendlichen Messreihe schaffe ich es, dass beim "nicht drehen" eine Geschwindigkeit von 0 reproduziert werden kann.
So lange die Motoren drehen, scheinen korrekte Daten erzeugt zu werden. Nur bei einer Geschwindigkeit von definitiv 0 werden meistens falsche Daten erzeugt.
Irgendwo ist da von mir ein Wurm eingebaut worden.
HILFE, wer findet den Wurm?

Auch wenn oberallgeier in einem anderen Thread sagt, dass ich "nebenher" noch beschäftigt bin, so ist dieses Thema immer noch eine 'Herzensangelegenheit' bei mir :).
Ich könnte euch mittlerweile auch noch Fotos vom Flur ohne Tapeten beilegen, aber ich glaube, dass ihr schon lange wisst, dass ich gerne und viele neue Tapeten an Wände pappe. (Zumindest will dies meine Frau so.)

Gruß Sternthaler

Sternthaler

22.07.2008, 02:08

Jetzt geht es ja wieder Schlag auf Schlag. Scheint irgendwie mit Tapeten zusammenzuhängen ;-).
Und die Decke hat heute auch schon wieder ihr Papier bekommen.

Und natürlich ein Hallo an alle.

Ich habe zwar immer noch nicht gefunden warum der Asuro mathematisch noch fährt wenn die Motoren stehen, aber zumindest weiß ich nun, dass auch die Werte beim Drehen der Motoren nicht korrekt sind.
Es werden sporadisch fehlerhafte Messwerte eingestreut, die bei Motorstillstand zu einer angeblichen Fahrt führen. Bei drehenden Motoren fällt es nur nicht auf, da die dann berechnete Geschwindigkeit ja nicht exakt nachgemessen werden kann.
Diese fehlerhaften Daten haben immer einen ähnlichen Wert um 435. Sie sind nur leicht gestreut. (ca. 430 - 440)
Die Werte entstehen nicht durch die 50 Hertz von flackernden Lampen. Dies ist in absoluter Dunkelheit ermittelt. Außerdem ist kein 50 Hz-Rhythmus festzustellen.

Somit ist mir klar, dass ich irgendwo bei meinen Variablenhaufen und / oder beim Speicherplatz für den Stack Mist gebaut habe.
Die Programmlogik habe ich am Sonntag einen geduldigen, sachkundigen Freund (ich hoffe, dass er das nun noch immer ist) mal nachvollziehen lassen. Auch er konnte dort nach ca. 6 Stunden programmcodeanstarren nichts am Ablauf feststellen.

Wer also die Geduld hat, meinen Fehler mit zu suchen, sollte sich mit ganz hoher Wahrscheinlichkeit auf die Speichernutzung konzentrieren.

Gruß Sternthaler, der Verzweifelte.

oberallgeier

22.07.2008, 09:43

Hallo Du verzweifelter Sternthaler,

... Dies ist in absoluter Dunkelheit ermittelt. Außerdem ist kein 50 Hz-Rhythmus festzustellen. ...Jetzt weiß ich endlich, warum Deine Posts so oft zu nächtlicher Stunde entstehen. Du arbeitest bei absoluter Dunkelheit! Klar - da hat man nicht sooo viel Probleme beim Ausrichten der Tapeten. Aber 50Hz-Rhythmus - - - pulst bei euch die Dunkelheit?

Na ja, erstens hab ich von Speichernutzung sowieso keine Ahnung. Aber es sieht mir doch ein bisschen nach einer elektrischen Störung aus, oder? Der simultane Einbruch bei 28o, 44o und 19u hat doch sicher etwas zu bedeuten! Und bei 25u und 50u gibts einen Durchgriff von "Totaleinbruch" auf "rot" zu einer deutlichen Verletzung der Monotonie auf "blau". Ausserdem zeigt die Monotonieverletzung auf 25u eine deutliche Erholungsphase von mindestens zwei Abfragen auf blau. Könnte das Alles nicht ein (elektrisches) Übersprechen von anderen Signalen sein? Woher käme sonst diese eindeutige Erholungsphase bei 25u-blau?

Wenn ich mir die Signale meiner Odometrie ansehe - bei (Tages-?) Licht, ohne Abdeckung, aber mit einer Beilagscheibe am Odometerrad, dann finde ich solche Störungen nicht mal andeutungsweise. Vielleicht - DAS ist die Idee - ich brenn mir mal Deinen Code auf meinen Asuro - und wenns ein Speicherfehler ist . . . dann hätten wir doch das gleiche Ergebnis ! ? ! ?

... Wer also die Geduld hat, meinen Fehler mit zu suchen, sollte sich mit ganz hoher Wahrscheinlichkeit auf die Speichernutzung konzentrieren ...Was tut mann denn nicht alles gegen die Verzweiflung auf dieser Welt . . . .

Dann blasen wir mal zur Jagd, oder? Schick doch mal den hex rüber.

mare_crisium

02.08.2008, 09:50

Buon giorno, SternThaler,

nur, damit Du nicht denkst, ich würde nächtlichen Eskapaden nicht weiterverfolgen :-) !

In Deinem Diagramm scheinen mir die Abstände zwischen den Ausreissern ganzzahlige Vielfache einer einzigen Grundperiode von etwa 6,65 Einheiten zu sein. Es könnte sich also um eine Störung handeln, die nach Art einer "Schwebung" durch das unglückliche Zusammentreffen zweier periodischer Vorgänge entsteht. Die 6,65 Einheiten entsprechen dann der Differenzfrequenz beider Vorgänge.

Bin natürlich sehr daran interessiert, dass Dein Asuro ohne zu humpeln zum Ziel findet!

Ciao,

mare_crisium

P.S.: Oberallgeier, Du alter Schwede: So ganz sauber sind Deine Kurven aber auch nicht! Guck' mal die Maxima #2 und #3 der blauen Spur an ;-) !

Sternthaler

04.08.2008, 19:58

Hey mare_crisium, holla Oberallgeier,

ich bin noch dran, habe aber noch kein Programm gesendet, da mir diese blöde Idee mit der Regelmässigkeit auch schon gekommen war.

Mein Ansatz geht / ging eher in die Richtung, dass ich die Störungen selber verursache, da ich, per Timer gestartet, ca. alle 2 Sekunden noch die Batterie messen lassen. (Auch die Taster können im Timer-Interrupt zu einer AD-Wandlung auf dem entsprechenden MUX-Kanal führen.)
Da aber die Messwertaufnahme aller oben angegeben ca. 50 Messwerte innerhalb von ein paar Millisekunden fertig ist, könnte dann höchstens nur eine einzige Störung über die Batteriemessung kommen.

Mittlerweile habe ich auch schon die Batteriemessung und auch die Taster weggelassen, aber nix da: Müll kommt immer noch.
Aktuell sieht es so aus, als ob der AVR einen INTERNEN Fehler hätte.
Ist ja so einfach, die Schuld auf andere zu schieben ;-).

Los geht es zum starten der ADC-Messung im Timer-Interrupt:
- SIGNAL (SIG_OVERFLOW2)

Über die dort verwaltetet Variable "sens_i.adc_do_akt" versuche ich aber jede weitere 'Umstellerei' am einmal ausgewählten und gesetzten ADMUX-Wert zu verhindern.

Der Timer ermittelt (so mein Plan) nur dann den nächsten AD-Kanal, und würde den ADMUX ändern, wenn halt die gerade angestossene AD-Wandlung abgeschlossen ist.
Dafür ist am Ende der ADC-Interrupt-Funktion die Zuweisung:
- sens_i.adc_do_akt = ADC_DO_NICHTS;
vorhanden.

Sohnematz der 'Kleine' hatte eine gute Idee, dass ADC-Werte nur dann ausgewertet werden, wenn der geholte Wert auch zu dem erwarteten MUX-Kanal passt.
Meine 'Erwartungshaltung', welchen Kanal ich meine gestartet zu haben, halte ich ja in der Variablen "sens_i.adc_do_akt" fest.
Hierzu kann es dann nur einen MUX-Kanal geben, und wenn der halt nicht passt: Weg mit den Daten und neu versuchen.

Mittlerweile habe ich ein Test-Programm, mit dem man sowohl beim Starten (im Timer-Interrupt), als auch beim Abholen der AD-Werte (im ADC-Interrupt) Daten sammeln kann.
Es werden ca. 50 'Datensätze' gesammelt und dann zum PC gesendet.
In der Sendezeit werden alle Interrupt disabled, bzw. die Sensoren werden deaktiviert.
Nach dem Senden der 50 'Datensätze' geht das Spiel wieder weiter.
So kann ich nun kontinuierlich Daten bekommen.

Aber leider, leider sieht es so aus, dass immer noch nicht immer alles passt.
Da ich mal wieder immer noch in der Firma sitze, sende ich euch das Progrämmchen heute Nacht zu gewohnter Stunde.

Gruß Sternthaler

oberallgeier

04.08.2008, 22:46

Hei mare_crisium, grüß Dich Sternthaler,

... So ganz sauber sind Deine Kurven aber auch nicht! Guck' mal die Maxima #2 und #3 der blauen Spur an Ja, Du hast recht. Aber - würdest Du einer total sauberen Kurve trauen? Ich nicht. Scherz beiseite - die Kurve stammt aus meinen ersten Erfahrungen mit dem asuro - und ich habe mit dem herzlich wenig gemacht. Vermutlich hatte ich damals noch nicht mal ne Beilagscheibe drauf. Als Ausrede für meine asuro-Abstinenz: dafür läuft mein eigenes Mini-Projekt schon die ersten Meter :).

@Sternthaler: ich will Dir jetzt nix erzählen, welche festen Qualitätsschwüre ich die letzen Tage geschworen hatte und danach widerrufen musste. Soll kein Vorwurf an Dich sein - nur ich traue mir nicht über den Weg. Oder, wie ich es mal zum Entsetzen meiner Bosse (m)einem technischen Vorstand sagte: meine Fehler sind die hässlichsten, die finde ich leider erst ganz zum Schluss . . .

Trotz allem - das wird schon werden - es funktioniert bestimmt gut, wir wissen nur noch nicht, wo es verbessert werden muss.

mare_crisium

04.08.2008, 23:41

Buona notte, Sternthaler,

tja, das mit der Grundeinheit führt offenbar nicht zu einer schnellen Lösung des Problems :-( . Die andere Aufälligkeit ist, dass alle Ausreisser denselben Wert haben (sieht aus wie 440, also 0x1B8). Die Zahl ändert sich nicht, selbst, wenn die richtigen Messwerte sich verändern. Hab' mir schon das Bitmuster aufgeschrieben, das führte aber auch zu keiner zündenden Idee. Ist das vielleicht ein Fehlercode Deines Betriebssystems?

Wir werden's schon 'rauskriegen - spätestens, wenn Oberallgeier den Code auf seinem Asuro testet!

Ciao,

mare_crisium

Sternthaler

05.08.2008, 02:49

Einen schönen Guten Morgen wünsche ich euch.

Und hier wie versprochen zu meiner besten (oder doch nicht?) Arbeitszeit Code und Daten.

Die andere Aufälligkeit ist, dass alle Ausreisser denselben Wert haben (sieht aus wie 440, also 0x1B8). Die Zahl ändert sich nicht, ...
Leider, leider pendeln diese Mistdinger doch. Sie gehen in den angehängten Daten von 448 bis 455 (ohne 454)
Nun könnte man meinen, dass dies der Messwert für die Batterie darstellt.
Leider scheint das aber nicht der Fall zu sein, da die Batteriemessung 2 mal 'erwischt' wurde und da 913 bzw. 914 ermittelt wurden.
--> 914 / 2 = 457 <-- Liegt verteufelt nah an den Mistdingern. Und die sind ja auch wie eine Batteriespannung recht konstant.
Aber warum durch 2 teilen? Wäre es eine 8 Bit anstatt 10 Bit Messung, muss ja durch 4 geteilt werden. (P.S.: Der AVR kann 8 oder 10 Bit)

... es funktioniert bestimmt gut, wir wissen nur noch nicht, wo es verbessert werden muss.
Nee, es funktioniert eben nicht gut. (Ich immer mit den gespaltenen Haaren.)
Das Problem hier ist ja, dass durch diese Mistdinger Tiks entstehen. Somit fährt der Asuro datentechnisch und rechnet eine Positon und einen Drehwinkel aus, der innerhalb kürzester Zeit zu ziemlich falschen Koordinaten führt. Und das obwohl der Asuro physikalisch keinen mm gefahren ist. (OK, die angehängten Daten zeigen drehende Räder. Das Problem ist aber auch bei Radstillstand vorhanden.)

Wir werden's schon 'rauskriegen - spätestens, wenn Oberallgeier den Code auf seinem Asuro testet!
Einen zweiten Asuro habe ich mir vom Nachbarn geliehen. Auch auf dem ist das gleiche Problem vorhanden. (Es liegt eben doch wohl an der Software.)
Sind nette Nachbarn. Also hockt man ab und zu bei Kaffee oder Wein zusammen; natürlich auch bei jeder Fete (@oberallgeier: Man kommt hier in der Straße wirklich zu nichts anderem). Selbstverständlich kommt man von Hölzchen über Stöckchen auch auf den Asuro.
Wer hat Spaß am Asuro bekommen? Sie natürlich. Totale Begeisterung.
Da Sie aber nicht mit Lötkolben und C umgehen kann, läßt sie mich einen Asuro zu Weihnachten für ihren Mann bestellen. Soll ja eine echte Überraschung werden.
Er hat vielleicht aus der Wäsche geschaut. Mittlerweile hat er auch schon einige Erweiterungen und fummelt nun auch heftig in C rum.

----> Was für Daten sind in der Exceltabelle?
- T0, C0, M0, A0
Datensatz, der zum Zeitpunkt des ADC-Starts in der Timer-Interruptfunktion geschrieben wird.
Suche nach: MD_ADC_HIST_I_TIM in asuro_st.c

- T1, C1, M1, A1, V1
Datensatz, der am Anfang des ADC-Interrupts hinter die x0-Daten geschrieben wird.
Suche nach: MD_ADC_HIST_I_ADC in asuro_st.c
Erst starten, dann ADC-Wert abholen ist die Logik. Ob ADC-Werte ohne Start kommen wird festgestellt. Dann wären alle x0-Daten auf 0.

Beide MD_ADC_HIST_I_xxx-Dinger kommen aus asuro_md.h ganz am Ende.

Tx und Cx geben die Zeit in 1/36000 Sekundeneinheiten an.
Zeit[sec] = (Tx * 256 + Cx) / 36000

Mx ist der Multiplexer-Kanal aus dem Register Atmega-ADMUX
Ax ist der logische Multiplexer-Kanal aus der Variablen sens_i.adc_do_akt

In Excel berechnete Spalten sind:
P, F, T1-T0 und T0-T0
- P zeigt Probleme, bzw. die Batteriespannung.
- F würde einen Fehler markieren, wenn Mx oder Ax zwischen Start und ADC-Wert abweichen. ---> Meine Vermutung, dass der AVR eine Macke hat ist hinfällig. Meine Defines für MD_ADC_HIST_I_xxx hatten einen Fehler.
- T1-T0 zeigt die verstrichene Zeit in 1/36000[s] an zwischen Messergebnis und Start.
- T0-T0 zeigt die Zeit zwischen 2 Starts. Hier ist eine Softwareverzögerung vorhanden, damit vor allem die LED's genügend Zeit bekommen komplett an bzw. aus zu gehen. (Mit Oska geprüft, ob diese Zeit ausreicht.)

----> Wie können die Daten in Excel angezeigt werden?
Die Werte für Mx und Ax sind in Excel im Reiter 'Tabelle1' angegeben.
Oben die Ax-Werte (logischer Kanal)
Unten die Mx-Werte (echter ADMUX-Kanal)

Sinnvoll ist es, wenn man den Excel-Filter der Spalte M0 nutzt.
Hier den ADC-Kanal auswählen, und nur die dazugehörenden Daten betrachten.
Beide Radseiten können mit dem M0-Filter 'Benutzerdefiniert' mit 'Zeilen anzeigen' 'ist kleiner oder gleich' und als Wert eine 1 eintragen, angezeigt werden.

----> Hier noch ein paar Dinge, die mir in den Daten aufgefallen sind.
- Werden beide Radseiten angezeigt, dann treten die Mistdinger entweder einzeln, oder immer direkt zusammen auf.

- Die Mistdinger treten nur in der Nähe des 'Umschlagens' vom 8-Bit-Zähler aus C0 auf.
Wenn man den Filter P einstellt, dass nur 'X'-Daten angezeigt werden, liegt C0 von 252 bis 255 und von 0 bis 17.
Genau in diesem Bereich, nämlich genau beim 'Umschlagen', kann im Timer-Interrupt die Batteriemessung vorbereitet werden.
--> Ist hier doch der Zusammenhang? Warum dann aber auch vor dem 'Umschlagen'? Und warum dann nicht immer?
Ich habe getestet, dass die Batterie-Vorbereitung im Code auskommentiert ist. -> Keine Änderung bei den Daten. Weiterhin Mistdinger.

So, nun habt ihr den vollen Durchblick und könnt mir meinen Programmfehler zeigen ;-).

Frohes Schaffen und immer gute Laune wünscht euch
Sternthaler

Hier die Exceldaten (415 kB): http://www.asuro-sternthaler.de/asuro/navigation/Daten-11-00.xls

P.S.: Es gibt, unter anderem auch von mir, in anderen Threads auch schon die Frage nach 'unerwartet' auftretenden Tik's.
Mir ist es beim Nikolaus aufgefallen, und ich meine, dass andere auch beim Messen per Interrupt das Problem hatten. Könnte aber auch ohne Interrupt gewesen sein.

oberallgeier

07.08.2008, 23:54

!) Ich bin noch am grübeln und 2) ich bin nicht annähernd firm im asuro-code. Aber . . . .

Einerseits sind 36 kHz für den ADC nicht so hoch, das Handbuch spricht von 200 kHz für 10bit-Wandlung. Andererseits wird (wohl) der Eingang bei der Odometrie gemultiplext (da muss ich nacharbeiten an der asuro-Software, um besser urteilen zu können). Nun heßt es:

Once the conversion starts, the channel and reference selection is locked to ensure a sufficient sampling time for the ADC.
• 13 - 260 μs Conversion Time
Kann es da nicht doch zu ungenügenden Wandlungszeiten kommen? ...wenn eine Wandlung gestartet wird - die vorherige sehr lange braucht, zurückgestellt und erst viel später zur Wandlung zugelassen wird als der Softwarer denkt.

Mache ich mich verständlich? Irgendwo wird doch dann ein Engpass entstehen. Aber, wie gesagt, ich muss erst mal den asuro-ADC-Code durchlesen und verdauen.

Sternthaler

08.08.2008, 01:00

Hallo oberallgeier,

um ein bischen beim verdauen zu helfen hier einmal die Kurzversion:

// Dabei sind (in der Reihenfolge ihres Auftretens):
- "Zeit-Variablen"
count36kHz und timebase (Asuro-LIB-Konform)
- "Logische-Kanal-Variable"
sens_i.adc_do_akt
Für den Begriff 'frei' wird ADC_DO_NICHTS benutzt
- "Verzögerungs-Variable"
sens_i.adc_delay
- "Taster-Interrupt-Variable"
interne Variable, die im Tasten-Interrupt gesetzt wird.
- ADMUX
Ist das im AVR enthaltene Register

Timer-Interrupt (1/36000 Sekunden)
{
Erhöhe "Zeit-Variable[n]"
WENN "Logische-Kanal-Variable" 'frei' ist
und (weitere Bedingungen)
DANN
Bestimme Wert für "Logische-Kanal-Variable"
- Berücksichtige Batterie anhand "Zeit-Variable"
- Berücksichtige Taster anhand "Taster-Interrupt-Variable"
Setze ADMUX auf entsprechenden pysikalischen Kanal
Setze "Verzögerungs-Variable"
ENDE-WENN

WENN "Logische-Kanal-Variable" NICHT 'frei' ist
und "Zeit-Variable" > "Verzögerungs-Variable"
DANN
Speicher die Daten in den x0-Werten (für IR-Übertragung)
Starte ADC-Wandler
ENDE-WENN
}

ADC-Interrupt (Nur nach einem Start aus Timer-Interupt möglich)
(Oder etwas doch nicht?)
{
Hole 16-Bit-ADC-Ergebnis
Speicher die Daten in den x1-Werten (für IR-Übertragung)
CASE "Logische-Kanal-Variable"
TASTER:
ADC-Wert intern merken
BATTERIE:
Bilde Mittelwert und intern merken
LINIE (4 logische Kanäle):
Hell-/Dunkelmessung intern merken
RAD (2 oder 4 logische Kanäle über ADC_RAD_VERHALTEN):
Berechne TIK und speicher in internen Variablen
ENDE-CASE
Setze "Logische-Kanal-Variable" zurück auf 'frei' für Timer-Interrupt
}

Der ADC wird NICHT im Free-Running-Mode gestartet.
Somit startet eine weitere Wandlung nur dann, wenn der Timer-Interrupt dies macht.
Auch die Änderung am ADMUX wird im Timer gemacht, und kann somit frühestens nach 1/36000 Sekunden erfolgen. Nämlich erst im nächsten Timer-Interrupt.
Das von dir angesprochenes Problem, dass eine Änderung am ADMUX direkt nach einem Start erfolgt, sollte somit nie auftreten.
Genau dieses 'Unschärfe' ist mir bekannt, und deshalb kontrolliere ich den ADC und das Timing komplett selber. (Zumindest versuche ich es)

Die 36kHz und die 200kHz haben meiner Meinung nach nichts miteinander zu tun.
Der Timer ackert so vor sich hin und startet eine ADC-Wandlung im "36kHz * 'Verzögerungs-Variable'"-Raster.
Dann kommt die ADC-Wandlergeschwindigkeit mit der konfigurierten Geschwindigkeit erst ins Spiel. Es dauert halt ein bisschen, bis der ADC-Interrupt sich meldet. Vor allem, da ich den Start der Wandlung ja künstlich in Timer-Einheiten verzögere.
In dieser ADC-Wandler-Zeit will/darf ich natürlich keine Änderungen an der Variablen "Logische-Kanal-Variable" und am Register ADMUX haben. Sonst bekäme ich ja genau das von dir angesprochene Problem.
Deshalb die Belegung der "Logische-Kanal-Variable" mit 'frei' bzw. bei dem Wunsch eine Wandlung zu starten mit dem im Timer bestimmten Wert für den logischen Kanal. Aber eben nur dann, wenn der ADC 'frei' ist.
Und erst nach der ADC-Wandlung im ADC-Interrupt wieder die 'frei'gabe.

Ich hoffe, dass dies etwas Überblick gebracht hat,
Trink nen leckeren Roten dazu. Am besten ein Glas für mich mit.

Gruß Sternthaler

mare_crisium

08.08.2008, 11:03

Also SternThaler,

das Brüten über der Datentabelle hat mir keine zündende Idee über die Ursache des Fehlers eingebracht :-( . Daraufhin habe ich noch einmal das Datenblatt des ATmega8 vorgenommen und das Kapitel ADC (S. 192 - 208) nach Art einer FMEA durchgeforstet. Hier ist das Resultat:

Mögliche Fehlerquellen am ATmega ADC:

1. Frequenz der ADC-Wandlung tiefer als Auslesefrequenz:
Dauer Sample-and-hold: 1,5 - 13,5 ADC-Takte, normalerweise 1,5 Takte (Abs. 2, Seite 199)
Dauer ADC-Wandlung: 13 - 25 ADC-Takte, normalerweise 13 Takte (Abs. 2, Seite 199)
Dauer Vref-Umschaltung: nicht spezifiziert
Dauer Kanal-Umschaltung: abhängig vom Ende der laufenden ADC-Wandlung (Abs. 3, S. 200).

In Deinem Fall (ADC-Betriebsart nicht freilaufend, Kanal-Umschaltung unmittelbar vor Löschen des INT-Flags, Vref-Quelle unverändert) sind das 14,5 Takte (Tabelle 73, S. 200); bei einem ADC-Takt von 36kHz also 0,4 ms. Leider habe ich keine Formel zum Berechnen des ADC-Taktes aus MC-Takt und ADC-Vorteiler gefunden.
Möglicher Fehler: Die Wandlung wird durch das Timerinterrupt-Dienstprogramm gestartet (ADSC=high). Anschliessend wird versucht, ebenfalls vom Timer gesteuert, das Ergebnis vor Ende der Wandlung (ADSC=low bzw. ADIF=high in ASCSRA Abs.2, S. 206) auszulesen. Das liefert nicht den gewünschten Messwert sondern die vorherige Messung wird noch einmal gelesen.
Anderer möglicher Fehler: Die Wandlungszeit wird unerwartet lang, weil bei jedem Start der Wandlung das ADEN-Flag in ADCSRA gesetzt wird. In diesem Fall gilt die verlängerte Sample-and-Hold und Wandlungszeit von 38,5 ADC-Takten (Abs. 1, S199). Ergebnis ist wieder ein wiederholtes Auslesen des alten Messwertes.

2. Störfreies Auslesen nur, wenn zuvor vorheriges Ergebnis vollständig ausgelesen wurde: Bei 10-Bit-Wandlung immer erst ADCL, dann ADCH auslesen (Abs 2, S.198). Wenn die nächste Wandlung endet, bevor ADCH gelesen wurde, dann geht das neue Ergebnis verloren und stattdessen wird das alte erneut ausgegeben.
Möglicher Fehler: Es wird zu früh ausgelesen und statt des gewünschten das Ergebnis der vorhergehenden Wandlung nochmals gelesen.

3. ADMUX schaltet nie vor letztem Takt der laufenden ADC-Wandlung um: Während laufender Wandlung bleiben Änderungen von ADMUX unwirksam. Tatsächlich umgeschaltet wird erst beim letzten Takt der Wandlung (Abs. 1, S. 200).
Möglicher Fehler: Der Kanal wird zu spät, d.h. während der laufenden Wandlung in das Register ADMUX geschrieben. Weil die Umschaltung erst bei Ende der laufenden Wandlung wirksam wird, wird nochmals das Ergebnis der vorherigen Wandlung (alter Messwert aus altem Kanal) ausgelesen. Empfohlen wird Kanalumschaltung nach Auslesen des jüngsten Ergebnisses, unmittelbar vor Starten der nächsten Wandlung.

4. Mess-Spannung höher als Vref : Wenn die Messspannung ausserhalb des zulässigen Bereichs liegt, werden ADC-Werte "in der Nähe von" 0x03FF ausgegeben (Abs. 4, S. 201).
Möglicher Fehler: Es gibt Spitzen in der Ausgangsspannung des Fototransistors oder kurze Einbrüche in der Versorgungsspannung des MC (mit Einfluss auf die interne Referenzspannung).

5. Versehentliche Anwahl von ADMUX-Kanal 0b1110=0x0E: Mit diesem Kanal wird die interne Spannung von 1,23V umgewandelt (Tabelle 75, S. 206).
Möglicher Fehler: Der Kanal 0x0E wird versehentlich angewählt und die interne Referenzspannung ausgewertet.

Noch ein Test-Vorschlag: Versuchsweise mit 8-Bit Wandler arbeiten (ADLAR=1, nur ADCH auslesen). Das sollte schneller gehen und die Zeitkonstante, mit der die Ausreisser erscheinen müsste sich verändern (Wenn die Ursache in einer "unglücklichen" Koinziendenz liegt).

Irgendwie werdern wir's doch noch 'rauskriegen :-) !

Ciao,

mare_crisium

oberallgeier

08.08.2008, 11:23

...
2. ... Bei 10-Bit-Wandlung immer erst ADCL, dann ADCH auslesen (Abs 2, S.198). ...
Das Datenblattgerechte Auslesen sollte der Compiler erledigen. Auszug aus meiner *.lls :

adc3_sum = adc3_sum + ADC; // ADC-Werte aufsummieren
8aa: 80 91 db 01 lds r24, 0x01DB
8ae: 90 91 dc 01 lds r25, 0x01DC
8b2: 20 91 78 00 lds r18, 0x0078
8b6: 30 91 79 00 lds r19, 0x0079
8ba: 82 0f add r24, r18
8bc: 93 1f adc r25, r19
8be: 90 93 dc 01 sts 0x01DC, r25
8c2: 80 93 db 01 sts 0x01DB, r24
Es wird also zuerst 0x0078, das lowbyte und danach 0x0079 gelesen.

Ich dachte (was man so alles denkt - *kopfschüttel*) ich hätte irgendwann irgendwo gelesen, dass das erste Ergebnis nach dem Umschalten von einem ADC-Kanal auf den anderen von zweifelhafter Güte ist. Leider weiss ich die Quelle nicht mehr. Daher hatte ich das oben nicht erwähnt.

jeffrey

08.08.2008, 13:04

Ich dachte (was man so alles denkt - *kopfschüttel*) ich hätte irgendwann irgendwo gelesen, dass das erste Ergebnis nach dem Umschalten von einem ADC-Kanal auf den anderen von zweifelhafter Güte ist. Leider weiss ich die Quelle nicht mehr. Daher hatte ich das oben nicht erwähnt.
ja, das stimmt. aber bei bascom z.b. wird das bei entsprechender einstellungen für den adc direkt von der routine gemacht. ka wie das in c ist.
mfg jeffrey

Sternthaler

09.08.2008, 02:51

Nur ganz kurz.

@mare_crisium
Oh je, wer auch immer FMEA erfunden hat. Den soll der Teufel holen.
Da muss ich noch ein wenig grübeln.

@oberallgeier
Dein ".. adc3_sum + ADC;" erinnert mich daran, dass ich meinen Code wieder umstellen muss.
Ich hatte da auch schon mit der Reihenfolge gespielt und tatsächlich massives Fehlverhalten festgestellt, wenn die Reihenfolge nicht stimmt.
Hier scheint deine Vermutung, dass der C-Compiler sich drum kümmert, bestätigt zu sein. Beim Nutzen von ADC anstatt ADCL und ADCH hatte ich noch nie (weiter) Probleme.

@jeffrey
Hmmm, in bascom kann man da etwas einstellen? Dann kann das ja bei Unwissenheit zu fatalen Problem führen.
Wie ich zu oberallgeiers Beitrag schrieb, scheint es bei C immer richtig zu sein. Für C ist es mir nicht bekannt, ob da etwas einstellbar ist.

Dann wäre es ja in Summe interessant, tatsächlich die von mare_crisium vorgeschlagen Variante zum 8-Bit messen zu testen.
Damit würde sich auf alle Fälle eine 'versehentliche' falsche Reihenfolge wohl umgehen lassen.

Bis die Nächte
Gruß Sternthaler

Sternthaler

10.08.2008, 03:11

Hallo mare_crisium, und natürlich an alle anderen Unterstützer auch ein Hallo.

Da es auch heute kurz bleiben soll, nur kleine Anmerkungen zu deinen Punkten (die natürlich nur aus meiner Sicht, und damit schon fehlerhaft sein können):

1. Frequenz der ADC-Wandlung tiefer als AuslesefrequenzAuslesen erfolg nur im ADC-Interrupt nach der einen Wandlung.
Frequenz ist somit identisch.

2. Störfreies Auslesen nur, wenn zuvor vorheriges Ergebnis vollständig ausgelesen wurdeAuch hier, wie bei 1., wird nur im ADC-Interrupt genau einmal ausgelesen.
'Vorheriges Ergebnis' entstand somit durch vorherige Wandlung und muss dann natürlich schon vorher ausgelesen worden sein.
Da dies aber für alle Messungen die identische Codestelle ist, müssten dann alle, bzw. viel mehr, Ergebnisse falsch sein.

3. ADMUX schaltet nie vor letztem Takt der laufenden ADC-Wandlung umDa ich ja durch eine belegte "Logische-Kanal-Variable" != 'frei' nicht zum setzen von ADMUX komme, dürfte dies nicht zu einer weiteren Wandlung mit noch nicht umgeschaltetn MUX kommen.

4. Mess-Spannung höher als Vref--> Noch nicht richtig bedacht ob dies der Fall sein könnte.
Bei den Messungen müssten es dann ja ADC-Werte größer als 1023 ergeben.
Ob dann der fast konstante Wert von meinen fehlerhaften ca. 450 entstehen kann, ist mir nicht bekannt.

5. Versehentliche Anwahl von ADMUX-Kanal 0b1110=0x0EDas hätte ich nie im Leben geprüft.
Hier sollte dann aber ein ADC-Wert von 1024 / 5V * 1,23V = ca. 252 gemessen werden.

Und nun etwas Erfreuliches.

Umgekehrt proportional zu meiner durchschnittlichen Beitragslänge ist nun das Programm radikal gekürzt worden.

Soll heissen, dass ich alles aus den beiden Interrupts entsorgt habe, was nicht zur Messung der beiden Räder mit LED-Beleuchtung gehört.

- Batterie, Taster, Rad-Dunkelmessung und Liniensensoren weg
So geht es wieder!
- Taster, Rad-Dunkelmessung und Liniensensoren weg
So geht es immer noch.

Nun aber erst einmal Feierabend, da ich sonst die Nacht duchmachen würde um meinen Fehler genau eingekreist zu haben.

Hier schon einmal vielen Dank für alle eure Anregungen und seelischen Unterstützungen. Ohne euch hätte ich es wahrscheinlich nicht durchgehalten mittlerweile 108 Messreihen aufgenommen und ausgewertet zu haben.
Gruß Sternthaler

P.S.: Daten und 'Kurz-Programm' bei Bedarf bitte anfordern.

mare_crisium

10.08.2008, 15:32

Buon giorno, SternThaler,

na, da hast Du ja zu später Stunde noch einen grossen Schritt vorwärts gemacht :-) !

Nach Datenblatt Seite 10, Abs. 7 haben Interrupts mit niedriger Adresse Vorrang vor denen mit höherer. D.h. wenn ein Timer-Interrupt eintritt, während der ADC-Interruptdienst noch läuft, dann unterbricht er ihn erbarmungslos. Ober sticht Unter, kennen wir ja ;-).

Weil sich der freche Timer-Interrupt immer vordrängelt und das laufenden ADC-Interrupt-Dienstprogramm unterbricht, kann er auch den Beginn einer neuen ADC-Wandlung starten, auch wenn die Abfrage des alten noch in Gange ist! Und wenn der Timer-Interruptdienst besonders viel zu tun hat und es deshalb lange dauert bis der ADC-Interruptdienst wieder zum Zuge kommt, kann es sogar vorkommen, dass ein ADC-Interrupt den noch laufenden ADC-Dienst unterbricht. Was dann passiert, ist im Datenblatt nicht spezifiziert.

Durch Dein radikales Abspecken der Interruptdienste gibt's dort jetzt viel weniger zu tun. Damit ist die Wahrscheinlichkeit gross, dass die Interrupts und -dienste sich zeitlich nicht mehr die Quere kommen.

Ciao, bis heut' nacht!

mare_crisium

oberallgeier

10.08.2008, 17:02

Hallo Ihr,

... Interrupts mit niedriger Adresse Vorrang vor denen mit höherer ... Ober sticht Unter...Da sag ich jetzt mal ganz pingelig: bei den Interrupten sticht der Unter (die untere Adresse) den Ober. Einfacher ausgedrückt: wer zuerst (in der Vektorliste) kommt, mahlt zuerst.

... Weil sich der freche Timer-Interrupt immer ... ... deshalb bin ich bei meinem Programm bemüht:
a) Hohe Quarzfrequenz. Ist bei mir ein Entscheidungskriterium für den m168! Damit kann ich in einer Zeiteinheit 25 % mehr Arbeitstakte erledigen als mit einem M16 oder M32 *gggg* - und noch etwas mehr, als mit dem doch sehr pfiffigen asuro-Controller.
b) Alle ISR müssen in kürzerer Zeit abzuarbeiten sein, als der kürzeste Interruptabstand. Ausserdem: meine sehr hoch priorisierten extINT0 und ~1 sind theoretisch garnicht in der Lage, den Timerinterrupt - Mittelfeld der Priorisierung - zu überholen; sonst wäre ja bei denen die Zeitmessung fehlerebehaftet. Wobei ich als Zeitbasis den Timer2 genommen hatte - das ist der höchstpriorisierte Timer!
c) Meine Interruptroutinen (derzeit bis auf die CIR) habe ich zeitlich ausgemessen als Nicht-ISR und zwar: Pin(x=test) einschalten, Routine aufrufen, Pin(x=test) ausschalten. Das heisst, ich messe die Zeitdauer mit dem kompletten "Routinen-Register-Rettungs-Aufwand". Das in einer for( ; ; ) gibt ein hübsches Flimmern im Oskar *ggggg*.
d) Schließlich habe ich noch ein ungutes Gefühl und noch keine klare Meinung über die Verwendung von cli(); und sei();. Wenn ich diese Kombination verwende und vorher war kein sei(); - dann sind die jetzt die Interrupts global zugelassen . . . . . ich glaube, dass müsste ich mit einem eigenen Verwaltungsflag abfangen. Derzeit versuche ich, ohne diese Kombination auszukommen.

... radikales Abspecken der Interruptdienste gibt's dort jetzt viel weniger zu tun. ...Die ISR sollte doch immer nur gerade das Allernötigste machen!? Der "Rest" muss anderswie organisiert sein. Ok, ich bin noch nicht so sehr in die ganze µC-Technik eingestiegen, aber ich glaube diese Regel ist sehr wichtig.

Sternthaler - viel Glück, ich halte Dir die Daumen - auch wenn ich jetzt auf eine Löwenfete gehe (beim Segelklub - oh jeeee, hoffentlich falle ich nicht ins Wasser) .

Sternthaler

10.08.2008, 23:26

Hallo ihr Ober-Unter-Ober-Stecher,

@oberallgeier
lass den Ober beim Segelclub in Ruhe, sonst drückt er dich ins Wasser Unter ;-)

Kleines Zurechtrücken der ISR-Unterbrechbarkeit in meinem Programm bzw. i.d.R. beim Asuro.
Die ISR-Funktionen werden nicht durch andere ISR-Anforderungen unterbrochen. Dies ist bewusst durch die Funktionsangabe über "SIGNAL (SIG_Name)" gemacht worden.
=> In meinem Asuro wird nicht vorgedrängelt! <= (Sag ich immer zu ihm im gleichen Ton wie bei der Kindererziehung.)

Nun ist folgender Stand erreicht: Alles ist gut

Schuld sind Medien-Markt und KOkg.
"Ich bin doch blöd" und "Geiz ist Schrill" hat sich in meinem Hirn so weit eingebrannt, dass folgender Code entstand:
if (! sens.aktiv & SENS_RAD)
LED_RAD_OFF; // Sensor deaktiviert; Strom sparenMan beachte den Kommentar!
Zu finden ist das Desaster im Timer-Interrupt recht weit vorne.

Hier noch kurz die nun aufgenommenen Geschwindigkeit mit:
- nicht drehen
- langsam drehen
- nicht drehen
- schnell drehen
- nicht drehen
- langsam drehen
- nicht drehen
-- und dann auch mal für das linke Rad

Die 'wackelnden' Geschwindigkeiten kommen vor allem durch das Aufbocken des Asuros. Kein Rollwiderstand und somit 'flatternde' Raddrehungen in den Lagern.

Danke für eure Mühe, und wartet mal ab, was als nächstes Problem noch kommen wird ;-).
Gruß Sternthaler

@oberallgeier
Das mit cli(); und sei(); kann ich dir beschreiben, wenn du magst.

mare_crisium

11.08.2008, 10:01

Buon giorno, alle zusammen,

...Da sag ich jetzt mal ganz pingelig: bei den Interrupten sticht der Unter (die untere Adresse) den Ober...
da hast Du recht. - Es gibt offenbar noch Bereiche wo' anders läuft, als in der Firma :-). Und mit dieser Feststellung liegst Du auch goldrichtig:

...
b) Alle ISR müssen in kürzerer Zeit abzuarbeiten sein, als der kürzeste Interruptabstand...

@SternThaler,

prima, dass Du den Fehler gefunden hast: Ich meine, bei einem Befehl wie

...LED_RAD_OFF... = "LED-Rad-ab"
da kann ja nur ein Asuro mit appem Rad 'rauskommen :-) !

Wenn ich die Periodendauer zwischen zwei Sektorflanken an meinem Eigenbau-Motor messe, kommt ein ganz ähnliches Diagramm heraus. Das ist in sofern bemerkenswert, als ich nur 0- und 1-Pegel unterscheide und dazu den ADC nicht bemühe. Das "Leerlauf-Geflatter" sehe ich auch.

Dann bleibt uns nur zu hoffen, dass Oberallgeier (äusserlich!) trocken nach hause kam...

Ciao,

mare_crisium

oberallgeier

11.08.2008, 12:10

Hallo Sportsfreunde und asurofahrer,

... Nun ist folgender Stand erreicht: Alles ist gut ...Herzlichen Glückwunsch. Manchmal sind ja die Details, in denen der sprichwörtliche Teufel steckt, so klein oder der ist so versteckt - sagenhaft! Aber schön, dass wieder ein Fehler ausgemerzt ist.

... Dann bleibt uns nur zu hoffen, dass Oberallgeier (äusserlich!) trocken nach hause kam ....Er kam.

... bei einem Befehl wie

...LED_RAD_OFF... = "LED-Rad-ab" ...... und ich dachte, dass es dabei um eine persönliche Schreibweise von OFF_ROAD ginge.

@Sternthaler: nur um (pingeligerweise) ganz sicher zu gehen: die Spikes sind wirklich weg? Alle? Komplett (soweit Du es bisher kontrolliert hast)?

... Das mit cli(); und sei(); kann ich dir beschreiben, wenn du magst.Erstmal vielen Dank. Ich habe praktisch alles aufgeräumt und es läuft und läuft . . . . never change a .... Aber ich werde das noch mal durchgehen und mich dann melden. Danke.

Sternthaler

11.08.2008, 19:30

Hallo ihr Erfinder,

... bei einem Befehl wie

...LED_RAD_OFF... = "LED-Rad-ab" ...... und ich dachte, dass es dabei um eine persönliche Schreibweise von OFF_ROAD ginge.
Ja, lacht ihr nur. Aber da kann ich zum Glück, vor allem über euren Reichtum an Alternativ-Funktionalität, natürlich mitlachen. :cheesy:

@Sternthaler: nur um (pingeligerweise) ganz sicher zu gehen: die Spikes sind wirklich weg? Alle? Komplett (soweit Du es bisher kontrolliert hast)?
Im Anhang habe ich (natürlich) ein EXCEL-Blättchen mit allen mittlerweile 142 Testfällen. Du kannst ja mal nachsehen. ;-)
Im Ernst: Es sind nur noch Testfälle mit korrigierter Software vorhanden, und da kann ich bei allen per ISR ermittelten ADC-Werten keine Spikes mehr finden.
Die ADC-Werte der Tasten lassen sich mit dem Testprogramm allerdings nicht in den Daten nachweisen. Dass sie funktionieren, habe ich noch mit einem anderen Programm und dem korrigierten asuro_st.c getestet.

Ich gehe jetzt erst mal nach Hause. Mal sehen, ob ich heute noch am Asuro weitermache.
Gruß Sternthaler

Sternthaler

01.04.2009, 01:05

Upps, schon wieder ist ein halbes Jahr verstrichen.

Hallo zusammen,

ich wollte nur einmal kurz ein kleines Zwischenergebnis vorstellen.

- Interrupts arbeiten weiterhin
- Die erste, einfache Version der Wegberechnung von mare_crisium ist vorhanden.
- Die komplette Grund-Datenermittlung läuft im Interrupt.
- Wegberechnung wird noch im main() zyklisch aufgerufen. Funktion NaviCalc() in asuro_st.c

Das Testprogramm macht folgendes:
- Warte auf Taste 1 (Von vorne gesehen die linke Taste)

- Asuro ca. 0,8 Meter gerade fahren lassen.
- Dann ca. 90 Grad-Bogen links.
- Nun ca. 1,2 Meter geradeaus
- Bogen rechtsrum fast 90 Grad
- Und noch ein gutes Stück ca. 1,2 Meter gerade.
- Asuro stoppt

- Warte auf Taste 2
- Daten an den PC senden. ==> Das sind die Positionsdaten!

Alle Bewegungen sind ohne Reglung und sollen genau so in den Positionsdaten wiedergefunden werden.
Alle Bewegungen sind noch NICHT zielorientiert. Hier ging es mir erst einmal darum die Messdaten zu ermitteln und darüber die Wegberechnung zu zeigen.
Und was ist? Das funktioniert recht überzeugend!

Gruß Sternthaler
P.S.: Ich hoffe, dass ich nicht erst wieder in einem halben Jahr schreibe ;-(.
P.P.S. Mittlerweile sind Bad, Gästetoilette, Flur, Küche und seit gestern auch das Wohnzimmer überarbeitet.

mare_crisium

01.04.2009, 13:22

Buon girono, SternThaler,

schön, dass Du wieder aus der Arbeit auftauchst :-) ! In Amerika nennt man sowas "honey dew". So wird das jedenfalls ausgesprochen. Gemeint ist damit aber "honey, please do...".

Es freut mich auch, dass Du mit der Navigation weiterkommst. In der Zwischenzeit konnte ich auch noch ein bisschen 'rumgeknobelt mit diesem Ergebnis hier

https://www.roboternetz.de/phpBB2/viewtopic.php?p=433782#433782

Das können wir auch auf den Asuro übertragen, wenn Du Lust hast.

Ciao,

mare_crisium[/php]

Sternthaler

02.04.2009, 00:10

Hallo mare_crisium,

danke für die freundliche ‚Wiederaufnahme’ im Thread.

Ach du meine Güte, was hast du denn da hinter dem Link wieder angerichtet ;-).
Wahrscheinlich wusstest du genau, dass ich mich erst einmal auf das EXCEL-Blatt stürze um ein wenig zu 'blättern'.
Gleich eine Frage: Was machen die Spalten L und M (Überschrift: Quer-Fahrtrichtung)? (Rechter Winkel zur 'Fahrtrichtung' ist das ja diesmal nicht.)
OK, ich sehe noch, dass das als Faktor für die Stellgröße s benutzt wird.
Sollte ich dein PDF erst einmal lesen und verdauen?
Dort finde ich aber nicht den Begriff 'quer', außer bei der 'ganz verqueren Richtung', und das hat ja nix mit den EXCEL-Spalten zu tun.

Dein PDF werde ich auf alle Fälle für das nächste "honey dew" nutzen. Ich muss halt noch wichtige Dinge für die Firma durcharbeiten ;-).
Mal sehen, ob das die nächste Aufgabe für den Asuro werden kann. Erst mal dieses hier abschließen. Und vorher muss ich das natürlich noch ausgiebig verinnerlichen.

Auftauchen ist gut. Kennst du den Film "The Deep"? Die haben unten in der Stadt noch eine Treppe in den Keller. Von da ist es ein weiter Weg wieder nach oben.

So, jetzt tauche ich aber erst einmal ab, da ‚in Company’ nur noch 2 Tage Zeit bleiben eine Wochenaufgabe zu lösen.

Schöne Grüße, und weiterhin viele gute Abhandlungen mit Openoffice.
Sternthaler