- MultiPlus Wechselrichter Insel und Nulleinspeisung Conrad         
Seite 8 von 11 ErsteErste ... 678910 ... LetzteLetzte
Ergebnis 71 bis 80 von 104

Thema: ASURO ... ein kleiner Wettbewerb

  1. #71
    Moderator Robotik Einstein Avatar von damaltor
    Registriert seit
    28.09.2006
    Ort
    Milda
    Alter
    38
    Beiträge
    4.068
    Anzeige

    Powerstation Test
    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.
    Read... or die.
    ff.mud.de:7600
    Bild hier  

  2. #72
    Benutzer Stammmitglied
    Registriert seit
    21.03.2004
    Ort
    73061 Ebersbach
    Alter
    56
    Beiträge
    52
    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
    Code:
    	//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.
    Code:
    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
    Das, was immer von jedermann und überall als richtig akzeptiert wurde, ist mit ziemlicher Gewißheit das Falsche.
    Paul Valéry (1871-1945), frz. Dichter

  3. #73
    Neuer Benutzer Öfters hier
    Registriert seit
    30.12.2006
    Beiträge
    19
    Zitat Zitat von Downad
    Code:
    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.

  4. #74
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    29.05.2005
    Beiträge
    1.018
    Zitat Zitat von Stallion
    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.
    Lieber Asuro programieren als arbeiten gehen.

  5. #75
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    12.06.2005
    Ort
    Südwestdeutschland
    Beiträge
    1.147
    Blog-Einträge
    3
    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

  6. #76
    Moderator Robotik Einstein Avatar von damaltor
    Registriert seit
    28.09.2006
    Ort
    Milda
    Alter
    38
    Beiträge
    4.068
    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.
    Read... or die.
    ff.mud.de:7600
    Bild hier  

  7. #77
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    29.05.2005
    Beiträge
    1.018
    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:
    Code:
    ---> 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?
    Lieber Asuro programieren als arbeiten gehen.

  8. #78
    Moderator Robotik Einstein Avatar von damaltor
    Registriert seit
    28.09.2006
    Ort
    Milda
    Alter
    38
    Beiträge
    4.068
    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? =)
    Read... or die.
    ff.mud.de:7600
    Bild hier  

  9. #79
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    12.02.2006
    Beiträge
    459
    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

  10. #80
    Moderator Robotik Visionär Avatar von radbruch
    Registriert seit
    27.12.2006
    Ort
    Stuttgart
    Alter
    62
    Beiträge
    5.799
    Blog-Einträge
    8
    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.
    Bild hier  
    Atmel’s products are not intended, authorized, or warranted for use
    as components in applications intended to support or sustain life!

Seite 8 von 11 ErsteErste ... 678910 ... LetzteLetzte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

fchao-Sinus-Wechselrichter AliExpress