Algorithmen zur Bahnplanung

**mare_crisium** · 15.10.2007, 21: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, 22:19

Hallo,

Zitat von Sternthaler

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

Eine Sorge weniger.

Zitat von Sternthaler

...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).

Zitat von Sternthaler

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 [polemik] ein Zeitbedarf, keine Zeitangabe[/polemik].

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, 22: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, 22:28

Zitat von mare_crisium

... 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, 22: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, 23:36

Zitat von mare_crisium

...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, 22:35

@oberallgeier,

Zitat von oberallgeier

Zitat von mare_crisium

... 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, 23: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, 02: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:

Code:

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