ASURO ... ein kleiner Wettbewerb

[damaltor]

naja... einen unterschied machts. wenn du fremde hex-files flasht, dann macht dein asuro nicht was er soll. und andere können mit deinen hexfiles nicht viel anfangen...

aber ansonsten ist es nicht so schlimm.

[Downad]

so nun hab ich mich auch am Haus probiert.

dabei musste ich folgendes beachten:
mein asuro macht sehr ungenaue Turn und ich habe nur die 8er scheiben drauf
--> ich habe eine MyTurn geschrieben die alle winkel in 60grad häppchen zerlegt
-->in Stallions Turn habe ich enc_count um 2/3 redziert

	//falls 8er Scheibe
	enc_count =(unsigned int) ((((long)abs(degree) * (long)4080) / (long)10000) * (long)2 / (long)3);

mein kleiner macht nun die kurven ganz gut bis auf....
.. er rechnet müll.

ich gebe die Seite (iSeite) und den Dachwinkel (iWinkel_Dach1) vor und berechen nun die Diagonale und die Dachseiten.

int iDiagonale= sqrt(2*iSeite*iSeite);
int iDach=(iSeite/2)/cos(iWinkel_Dach1/180*3.1415926535);

für iSeite = 100 geht das auch super idiagonale = 141
für iSeite = 150 ist iDiagonale 28672 --<<<<<<<WARUM?
für iSeite = 200 ist iDiagonale 120 --<<<<<<<<WARUM?

pythagoras 150*150+150*150 = 2* 150*150 daraus die Wurzel->212
und bei iSeite 200 wäre 282 das richtige

gruß
downad

[Stallion]

int iDiagonale= sqrt(2*iSeite*iSeite);
int iDach=(iSeite/2)/cos(iWinkel_Dach1/180*3.1415926535);

für iSeite = 100 geht das auch super idiagonale = 141
für iSeite = 150 ist iDiagonale 28672 --<<<<<<<WARUM?
für iSeite = 200 ist iDiagonale 120 --<<<<<<<<WARUM?

Dann rechnen wir mal:
für 100:
sqrt(2*100*100) = sqrt(20000) = 141
für 150:
sqrt(2*150*150) = sqrt(45000)
signed int geht aber nur bis +32767 -> overflow -> sqrt(-20535)...
Also kannst eigentlich froh sein, dass dir der Prozessor überhaupt etwas ausspuckt. Also sollte man in dem Fall (long) verwenden um sinnvolle Ergebnisse zu bekommen.

Zweitens kann man die Formel vereinfachen in iSeite*sqrt(2) = iSeite*1,414... (float verwenden nicht vergessen!)

Und drittens hab ich es vorher ausgerechnet und direkt in Programm geschrieben, damit sich der Asuro die Arbeit sparen kann.

[Sternthaler]

Hier mal ein kleines Video meines Asuros:

Hallo Stallion,
gratuliere, das ist ja wirklich auch eine sehr schöne Nikolaus-Fahrt.

Ich habe mal gezählt, wie häufig du bei deinem Nikolaus mal nach rechts bzw. nach links drehst. Du drehst 6 mal links und nur ein mal rechts. (oder anders rum)
Bei meinem Asuro hatte ich festgestellt, dass sich die Fahrfehler beim Drehen am besten aufheben, wenn man möglichst gleich viele Drehungen in beide Richtungen macht. Bei dir sieht aber das Ergebniss trotzdem recht gut aus.
Deshalb fände ich es auch gut, so wie stochri vorgeschlagen hat, die Fahrt mal öfters hintereinander zu zeigen um zu sehen wie die Wiederholgenauigkeit ist.

Weiter so.

[stochri]

Hallo Zusammen,

gerade eben habe ich im Netz einen Zeichenroboter gefunden:

http://www.hobbyrobotik.de/Kritzler.htm

Er unterscheidet sich in der Größenordnung nicht so sehr vom ASURO. Die Bilder sind allerdings doch um einiges komplexer. Das gibt mir doch etwas Hoffnung, dass bei Verbesserung der Odometrie aus dem ASURO doch noch etwas mehr herauszuholen ist.

Gruss,
stochri

[damaltor]

schrittmotoren sind natürlich eine feine sache für sowas... leider hat der asuro sowas nicht. da müsste man dann irgendwie die odometrie sehr exakt ansprechen.

[Sternthaler]

Es bleibt nicht aus, dass man immer mal wieder hier vorbei kommt.
Der Grund meines Besuchs hier ist der Code von Stallion, da ich mich erinnert habe, dass er eine Abbremsfunktion in Turn() eingebaut hatte.

Mein Problem: Ich verstehe nicht wie das gehen soll.
Ich habe mal (hoffentlich korrekt) den gekürzten code von Stallion nochmal wiedergegeben und meine Frage da reingeschrieben:

---> enc_count wird einmal berechnet.
---> Bei degree = 90 wird enc_count also 36,72 (36 oder 37 ist aber egal)
   enc_count = (unsigned int) (((long)abs(degree) * (long)4080) / (long)10000);
   
   // set direction
   // reset encoder
   // set speed
   // do until angel reached
   while(tot_count < enc_count)
   {
      tot_count += encoder[LEFT];
      
      // calculate speed difference
      // reset encoder
      // calculate new speed
      if (diff > 0)               //Left faster than right
      {
      }
      if (diff < 0)               //Right faster than left
      {
      }
      
      // set new speed, with slow down
---> Hier den nur einmal berechneten Wert von enc_count eingesetzt, ergibt fuer
---> mich keinen Sinn, da doch dann eigendlich nur [l|r]_speed durch diese
---> 'Konstante' geteilt und abgezogen wird.
---> Wenn Speed als so um 200 (plus/minus "calculate new speed") ist, und dann durch
---> 36 oder 37 geteilt wird, kommt da bei mir ein Wert um 200/36 = 5 raus.
---> Diese 5 werden nun aber einfach nur von den 200 abgezogen und wir fahren doch
---> 'nur' die gesamte Strecke etwas langsamer.
      MotorSpeed (l_speed - (unsigned char) ((unsigned int)(l_speed) / enc_count),
                  r_speed - (unsigned char) ((unsigned int)(r_speed) / enc_count));
      Sleep(36);
   }

War es so gewollt, und ich habe falsch verstanden, das am Ende der Fahrstrecke abgebremst werden sollte? Oder habe ich den Code nicht verstanden?
Mag hier noch einer Antworten?

[damaltor]

hat das evtl den zweck dass die ganze kurve in der mitt etwas langsamer gefahren wird? quasi schnell rein in die kurve, auf der ideallinie lang, etwas bremsen, und dann mit gas wieder raus? =)

[robo.fr]

Hallo Sternthaler,

Bei menen Experimenten hat sich gezeigt, dass die Motordrehzahl relativ unabhängig vom Untergrund ist. Ich hatte den Eindruck, dass der Schlupf auch nicht so stark Untergrund abhängig ist.
Allerdings treten in den Phasen der Geschwindikeitsänderung die größten Kräfte auf und deshalb ist in den Brems- und Beschleunigungsphasen der Schlupf auch am größten. Treten diese Phasen gehäuft auf, wird der Odometriefehler größter ( kann man einfach testen: eine Wegstrecke in kleinen Stücken und in einem großen Stück auf verschiedenen Untergründen fahren ).
Es ist also von sehr großem Vorteil für eine genaue Odometrie, sanft zu beschleunigen und zu bremsen ( besonders wenn man ein Nikolaushaus zeichnen will ).

Bei meinen Versuchen mit der Bluetoothübertragung konnte ich einen Fehler feststellen: Manchmal haben die Encoder ohne Bewegung hochgezählt. Da müsste also ein Fehler in den Odometrie-Interruptroutinen sein ( Das könnte man auch mit der Funktion PrintInt und der IR-Schnittstelle nachprüfen: einfach den Encoderwert zyklich auf der IR ausgeben und schauen, ob es eine Radstellung gibt, bei der die Encoder hochlaufen.

Gruss,
robo

[radbruch]

Da müsste also ein Fehler in den Odometrie-Interruptroutinen sein

Der Verdacht wurde schon mehrfach geäußert, aber bisher noch nicht bewiesen. Ich hatte auch schon solche Effekte bemerkt obwohl ich eine ältere Version der Libary verwende. Möglicherweise ist das eine "Altlast" die immer wieder in die neuen Releases mitkopiert wird.