Kurve fahren

Hallo hai1991,

entschuldie bitte, dass ich dich vergessen habe.
Ich habe dein Programm immer noch nicht bei mir probiert.

Zu deiner Frage mit int und Werten größer 255 kann ich aber schon etwas sagen:

Code:

---

Typ  Bitanzahl  unsigned [Typ]      signed [Typ]
char    8        0 bis 255          -128 bis 127
int    16        0 bis 65535        -32768 bis 32767
long    32        0 bis 4294967295    -2147483648 bis 2147483647

---

Um bei Vorzeichen-Variablen rauszubekommen wie weit sie nun nach minus bzw. plus gehen muss du so rechnen:
minus: 2 ^ Bitanzahl / 2 * -1
plus: 2 ^ Bitanzahl / 2 - 1

Zu dem Thema hatte ich schon mal ein kleines Programm für den Asuro geschrieben. Und auch wiedergefunden ;-).
Es gibt die Byte-Anzahl aller Datentypen per IR am PC aus.
Auch gut, dass ich da eine Bedienungsanleitung reingeschrieben hatte:
"Nach dem Loslassen irgendeiner gedrueckten Taste wird die benutzte Byteanzahl aller Datentypen ueber IR ausgegeben."

Ich hoffe, dass ich dein Programm in nächster Zeit mal wirklich testen werde.
Gruß Sternthaler

hallo sternthaler

danke für deine antwort.
aber ich muss zugeben dass mir in der zwischenzeit auch schon eingefallen ist, dass ich da irgend wie die werte vertauscht habe und es daher auch nicht daran liegen kann. trotzdem danke für die antwort

es ist eben so, dass ich einfach nicht mehr weiß was an meinem code falsch bzw. nicht ganz optimal ist. und ich möchte es so gerne auch einmal schaffen, dass er ein vorgegebene kurve fährt.

hat wirklich niemand mehr eine idee woran es liegen kann

hi hai1991,

hab mal Deine letzte Version getestet,
mit folgenden Änderungen:
Motorstarten hinter Anfang der while ( count_a ... ) Schleife gesetzt,
anschliessnde EncoderSet(0,0);
dann mal 10 ms warten: Msleep (10);



am Ende der Schleife das Setzen von MotorSpeed eliminiert.

Bis auf die 10ms warten wohl nur formale Änderungen.

Ich denke, Du musst dem Encoderzähler mehr Zeit lassen,
das Rad braucht ein paar ms zum zählen.

Die Übergabeparameter könnte/sollte man auch irgendwo prüfen (Radius gösser halber Spurweite ?, Winkel(basolut) < 360 ? ,speed < 255 ?)
Ich hab's mit einem Rückkgabeparameter (char anstelle von void) gemacht, den ich im aufrufenden Programm auswerten kann.

Vielleicht irre ich mich ja, aber zumindest hat mein ASURO
im Test je nach Winkel und Durchmesser Links- bzw. Rechtskurven
ausgeführt.

Ich hab dabei aber Deinen Wert (MY_GO_ENC.. 21240L ) übernommen .
Ich komme aber, bei den Werten , bei meinem ASURO nicht aus der
while-Schleife raus, da count_a bzw. encoder[0] bzw. [1] auch bei 10 ms deulich unter count_a_soll liegt.
Im Asuro Original-Programm (GoTurn in encoder.c ) geht der Schleifen-Abbruch über tot_count, das pro Schleifendurchlauf um encoder[LEFT] erhöht wird.

Am besten baust Du mal ein paar PrintInt ein, um dir die Encoder, speed und count-Werte anzusehen.

Auch dei 10 ms für den Encoder müsste man mal überprüfen.

Vielleicht hast Du aber ein anders Problem

Gruss

mausi_mick

Hallo mausi_mick, hallo hai1991,

ja mausi_mick, das scheint mir eine sehr gute Sicht auf die Dinge zu sein. (Jetzt wo du es sagst kommt man da "wie von selbst" drauf ;-))

Wenn man mal nachrechnet:
ca. max Speed : 450 [mm/s]
ca. min Speed : 180 [mm/s]

Bei 8 schwarz- / 8 weiß-Teilen auf der Odoscheibe:
1 Tick entsprich ca. 1,5 [mm]

Bei "max Speed" somit ca.: 450 [mm/s] / 1,5 [mm] = 300,0 [Tiks/s] = 3,3 [ms/Tik]
Bei "min Speed" somit ca.: 180 [mm/s] / 1,5 [mm] = 120,0 [Tiks/s] = 8,3 [ms/Tik]

Die 10 [ms] scheinen somit eine gute Wahl gewesen zu sein. (Hast du bestimmt genau so wie ich berechnet mausi_mick. Nur dass du bestimmt der Devise 'Erst denken, dann handeln' gefolgt bist.)


Was passiert da aber, wenn man 'zu schnell' ist?
In jedem Schleifendurchlauf wird festgestellt, dass eine Seite nicht so läuft wie erwartet.
Dann wird Speed auf der entsprechende Seite um 10 reduziert/erhöht.
Weiterschleifen ohne Bremse.
Nun wird noch kein weiterer Tik festgestellt, somit wird wieder um 10 reduziert/erhöht. usw. usw.

Wenn man jetzt Pech hat, wird das Spiel so häufig wiederholt, dass Speed > 255 wird, oder Speed geht so weit zurück, dass der Motor stehen bleibt.
Beides dürfte recht fehleranfällig sein. Denn auch wenn speed_a und speed_i int-Variablen sind, werden ja, worauf mausi_mick ja schon mit der fehlenden Prüfung hinwies, nur die hinteren 8 Bits der Variablen als Wert in MotorSpeed() benutzt. Wer weiß schon wie die dann stehen.

Abraten würde ich aber, dass die Werte in der Schleife an den PC gesendet werden da die Übertragungsgeschwindigkeit pro Zeichen bei ca. 5 [ms] liegt.
Also bei 3-stelligem Werte und beiden Seiten, 7 Zeichen (3 + Leerzeichen + 3). Damit erzeugen wir eine Verzögerung von ca. 35 [ms].
Das ist prozentual aber schon extrem gegenüber den jetzigen 10 [ms].
Lieber die Daten in der Schleife speichern, und nach der Schleife, auf Tastendruck, an den PC senden.

Aber noch mal zurück zum Msleep() mit den jetzigen 10 [ms]
Bei langsamer Fahrt können wir dann schon ca. 3 Tiks 'verpasst' haben.
Das ist ein relativ großer Fehler bei jeweils 1,5 [mm] pro Tik.

Vorschlag:

Code:

---

long tik_summe;

  while (count_a<count_a_soll)
  {
      tik_summe = encoder [LEFT] + encoder [RIGHT];
      while (tik_summe == encoder [LEFT] + encoder [RIGHT])
        ;

      /*
        Hier weiter mit deinem Code.
        Msleep (xx); ist dann auch nicht mehr notwendig,
        da ja auf alle Fälle ein Tik gewartet wurde.
      */
  }

---

Dies würde die Problematik bei einer konstanten Wartezeit eliminieren.

Gruß Sternthaler
P.S.: Der Code war immer noch nicht in meinem Asuro. :oops:

Hallo Sternthaler,
hallo hai1991,

Danke für den Tip mit der Ausgabe der Messwerte.

Hab nochmal ein wenig getestet und das Progamm modifiziert,
auch Richtung Sicherheit (z.B. winkel 0 nicht zulassen) Auch hab ich einen
Wert für die Tiks vorgegeben, ab dem erst die Geschwindigkeit verändert werden soll (z.B. 10 oder 20 Tiks.
Scheint bei mir zu laufen, nur etwas ruckhaft. Vielleicht muss man die Geschwindigkeitsänderung (+-10) auch in Abhängigkeit der Tik-Differenz modifizieren.
Ich versuch mal , den Code einzubinden, weiss aber (noch) nicht, wie das geht

Gruss mausi_mick

hallo ihr beiden

schön, dass sich noch jemand zu uns gesellt (ich glaube zu dritt hat man mehr ideen und hoffe, dass es bei mir auch bald klapt)

nur kurz als info:

Zitat:

---

winkel 0 nicht zulassen

---

das habe ist meiner meinung nach nicht nötig, da 0° immer ein count_a_soll=0 ergebt, und er somit nicht in die schleife eintritt, aber man kann es natürlich als sicherheit noch hinzufügen

Zitat:

---

Winkel(basolut) < 360 ? ,speed < 255 ?

---

winkel>360° kann vl. auch gewollt sein, darum kontrolliere ich das nicht
und speed>255 vermeide ich hier:

Code:

---

          if (count_a <(count_i*quot))
          { /*außen zu langsam */
                if ((speed_a > speed) || (speed_a > 244))
                  speed_i -= 10;
                else
                  speed_a += 10;
          }

---

da ich außen nur erhöhe falls speed_a<244 (244+10=254, also <255)


so, genug geschrieben. jetzt bin ich wieder zum ausprobieren dran
sobald ich was neues weiß lasse ich es euch sofort wissen

hallo hai1991,
mit dem Winkel und der Speed sind nur formale Sachen,
aber Du solltest entweder in der Funktion oder vom Hauptprogramm solche Werte verhidern, da Du z.B. durch den Winkel teilst, und das ist bei Winkel = 0 nicht so doll.
Mit der speed meine ich nicht speed_a bzw. speed_i, sondern den Übergabewert speed.

Die Winkelbegrenzung nach oben hab ich auch nicht realisiert, so kann ich auch z.B. mal 2 oder 1,5 Kreise fahren.

Wäre eigentlich nicht schlecht, wenn man das Programm auch zum
exakten Geradeausfahren verwenden könnte (Radius = 0), aber dann hat man Probleme mit dem Fahrtende über den Winkel, oder man müsste dann den Winkel als Fahrzeit (Msleep) interpretieren.
z.B: kurve(0,-450,170) bedeutet:
fahre geradeaus, rückwärts 450 sec lang, mit speed 170.

Und übrigens: mein Programm läuft auch nicht mehr, oder ähnlich wie Deins:
Die erste Kurve macht er noch richtig, bei der zweiten macht er irgendwas und das fast Geradeausfahren (mit dem grossen Radius) fuktioniert auch nicht.
Ich glaube, ich hab mir die Parameter MY_ODOMTERIE_DARK ... Parameter (in My_ASURO.H) zerschossen (ich hab einen Original-Asuro und einen umgebauten Asuro, der andere Radsätze/Übersetzungen und andere (bessere?) Sensoren (CNY70), die nicht so Umgebungslicht empfindlich sind, verwendet).

Ich muss mal sehen, dass ich da bessere Werte bekomme, damit die ADC's der Encoder wieder vernünftige Werte liefern.

Gruss
mausi_mick

Guten Morgen.

Hallo mausi_mick,
kannst du mir den Sinn bez. die Idee erklären, die du mit dem Code bewirken möchtest:

Code:

---

        Msleep (dauer);
        count_a = encoder [RIGHT];
        if (count_a == enc_ad)
            dauer = dauer + 1;
        enc_ad  = count_a - enc_ad;
        if (enc_ad >= min_tik)        // ab z.B 10 tiks prüfen
        {

---

Du erhöhst ja ab und zu die Variable dauer. Passt sich der Wert im Laufe der Zeit von alleine an einen sinnvollen, zur Geschwindigkeit passenden, Wert an?

Ich habe mal Excel etwas bemüht, um rauszubekommen, wie sich der Wert in dauer verändert könnte.
Auch der Wert in enc_ad ist mir bei meinen Excel-Versuchen noch nicht so richtig sinnvoll vorgekommen. Meistens bleibt er bei mir unter den 10 aus min_tik.
Hilfe, mir gehen die Ideen aus, wie sich die Dinger verhalten sollten.

Gruß Sternthaler

Hi Sternthaler,

hab das nur mal mit dem Erhöhen der dauer probiert, falls der Encoderwert zwischen zwei Aufrufen nicht hochgezählt wird.
Hab das aber wohl nicht sauber ausgetestet.

Anders als bei hai1991 wollte ich auch nicht mehr zur Geschwindigkeitsberechnung die Encoderwerte von Anfang an (EncoderSet(0,0) ist wohl nur vor der Schleife gesetzt) berücksichtigen,
sondern nur die seit dem letzten Aufruf (-dauer).
Wenn in dem Zeitraum aber nur wenige Tiks anfallen, wird wohl die Ungenauigkeit recht gross.
Auch müsste man sich überlegen, ob nicht bei kleinen Differenzen links/rechts die Speed-Änderung kleiner als 10 ausfallen müsste.


Gruss
mausi_mick

hallo

gleich vorweg:
jetzt funktioniert es bei mir auch schon recht gut (vl. noch die werte in myasuro.h etwas umändern/anpassen, dann müsste er hoffentlich schöne kurven fahren)

@mausi_mick
die idee mit der kombination aus kurve und gerade faheren hatte ich auch schon, nur habe ich mir das etwas anders vorgestellt:
was wäre wenn an einfach die GoTurn() hernimmt und etwas abändet?
wenn winkel=0: eine gerade streche fahren
distance=0: drehen
winkel und distance haben einen anderen wert als 0: dann könnte man distance als radius interpretieren und eine kurve fahren

somit hätte man alles in was man so zum fahren braucht in einer funktion und könnte sie natürlich dementsprechend auch umbenennen auf Drive()

dann müsste man aber natürlich auch die von dir angesprochenen sicherheitsabfragen bezüglich zu hoher geschwindigkeit einbauen