ZitierenÄhm, meiner Meinung kann man den Test sehr einfach machen:
while(1)
{
PrintInt(encoder[left]);
Msleep(1000);
}
in groben Zügen.
Hallo damaltor, robo.fr und radbruch.
Hatt ein bischen gedauert eure Einträge zu bedenken.
Zum Thema Beschleunigen, Abbremsen und die dann auftretende Kräfte:
Ich kann diesem (schon wieder) nicht folgen. Wenn man sich den Beitrag von waste zur Lienienverfolgung über den PID-Regler ansieht, dann wird dort ja genauestens auf diesen Umstand eingegangen. Dort werden ja Massen und Trägheitsmomente bestimmt, berechnet und verknüpft, dass einem nur die Ohren schlackern. (Und schon wieder: Kann ich auch nicht nachrechnen)
Hier in dem von Stallion angepassten Turn() ist ja von stochri kein PID-Regler vorhanden. Ist auf alle Fälle ein Regler, da ja Abweichungen (encoder-Werte) zur Korrektur des Systems in einer echten Regel-Schleife genutzt werden. Aber ich kann hier nicht so richtig auf Regler-Parameter kommen. (Nix für ungut, das Ding macht bei mir schon alles ganz OK)
Um aber da zu optimieren, z.B. Beschleunigungen/Verzögerungen für Drehbewegungen, zu berücksichtigigen, muss bestimmt ein ähnlicher Rechenaufwand wie bei waste betrieben werden.
Und trotzdem: Es sieht also nicht so aus, als ob die Anpassungen im Code von Stalion zur 'sanften' Verzögerung am Ende der zu fahrenden Drehung geeignet ist?
Und nun zu den Tiks
Mal 2 Annahmen:
1: Der Programmcode ist fehlerhaft:
Ich kann nichts entdecken. Also alle sind gefragt.
2: Der Programmcode ist OK:
Jetzt stellt sich die Frage, wo die Tiks dann herkommen.
Wenn der Asuro steht, werden eigendlich keine Tiks erwartet.
Wenn aber Stromnetzbetriebe Beleuchtung vorhanden ist, kann es m.M. nach passieren, dass da mal Messungen reingeraten, bei der die Netz-Lampen-Beleuchtung gerade aus ist, da die Spannungsphase so gerade bei 0 Volt liegt.
Da bei der Odometrie ja offiziell keine Differenz-Messung mit ein-/ausgeschalteter LED-Beleuchtung vorhanden ist, sind wir hier also schon recht stark vom Umgebungslicht abhängig.
Sind es nun die 50 Hertz? Wie testen?
Als Idee hätte ich folgendes vorzuschlagen:
- Man misst einfach die ODO-Werte und schreibt sie in einen Ringbuffer. Sagen wir mal so 20 bis 30 Werte. Die alten Werte werden kontinuirlich überschrieben.
- Man macht die normale Auswertung zur Tik-Berechnung.
- Stellt man nun fest, das ein Tik erkannt wurde, werden die Daten aus dem Buffer an den PC gesendet.
Hier kann man dann ja mal versuchen dem Geheimnis auf den Grund zu gehen. Historie ist bekannt, Tik-Berechnung ist bekannt und die Schwell-Werte sind auch bekannt.
Nach diesem Ansatz müssen es meiner Meinung nach die Daten/Messwerte sein.
Wenn nicht, fangen wir halt von vorne an, oder gehen zu Punkt 1
Lieber Asuro programieren als arbeiten gehen.
Ähm, meiner Meinung kann man den Test sehr einfach machen:
while(1)
{
PrintInt(encoder[left]);
Msleep(1000);
}
in groben Zügen.
Hallo robo.fr,
wenn du nur den Wert aus encoder jede Sekunde sendest, kannst du nicht rausbekommen was dazu geführt hat, dass der Zählerstand hochgezählt wurde.
Ich möchte mit meinem Vorschlag aber die vom ADC gelesenen Odometrie-Werte zum PC senden. Denn aus diesen 'Netto'-Daten wird ja erst berechnet ob der Zähler in encoder weitergezählt werden soll oder nicht.
Der von mir angesprochene Ringbuffer soll dazu dienen die Historie der ODO-Daten aufzunehmen, ohne durch eine 'extrem' langsame PrintInt()-Funktion die Geschwindigkeit beim Datensammeln zu stören. Was ja passieren würde, wenn ich die Daten sofort senden würde.
('extrem' langsam ist das Verhältnis zwischen der Zeit zum Ermitteln der Daten über den ADC und dem Senden der Daten über IR. Micro-Sekunden zu Milli-Sekunden)
Lieber Asuro programieren als arbeiten gehen.
Hallo Sternthaler,wenn du nur den Wert aus encoder jede Sekunde sendest, kannst du nicht rausbekommen was dazu geführt hat, dass der Zählerstand hochgezählt wurde.
bei der obigen Funktion geht es ja nur darum festzustellen, ob der Encoder im Stillstand hochzähtl.
Bei meinem ASURO ist das der Fall und ich vermute, dass der nicht der einzige ist.
Hallo
Ach, der steht? Das kann man doch nicht wissen, wenn du nur den Codeschnippsel anbietest. Davor könnte ja auch ein lockeres MotorSpeed(255,255), stehen....bei der obigen Funktion geht es ja nur darum festzustellen, ob der Encoder im Stillstand hochzähltl.
mic
Bild hier
Atmel’s products are not intended, authorized, or warranted for use
as components in applications intended to support or sustain life!
Du hast recht, ich habe auch schon daran gedacht, dass es etwas missverständlich sein könnte. Wahrscheinlich ist es halt doch besser, ein ganzes Programm hinzuschreiben. Aber eigentlich fehlt nur noch Init(); und EncoderInit(); dann ist das Programm komplett.Ach, der steht?
Und noch was fehlt: vielleicht sollte man es für die linke und die rechte Seite probieren.
Wie sieht es bei euch aus? Gibt es bei eurem ASURO auch Encoderstellungen, bei denen im Stand hochgezählt wird?
Zitat von robo.fr
Ich dachte ja auch daran, nun mal dem Problem auf die Spur zu kommen. Und nicht nur die Auswirkungen bei den Tik-Zählern zu sehen.
Auch radbruch weist in seinem Beitrag darauf hin, dass er Tik's ohne sichtbaren Grund bekommt. Bei mir habe ich das auch schon vereinzelt bemerkt.
Auf alle Fälle stimme ich dir zu, dass man linke und rechte Seite untersuchen muss.
Lieber Asuro programieren als arbeiten gehen.
Hallo
Ich möchte euch ja nicht unnötig verwirren, aber ich verwende doch die erweiterten Odo-Funktionen gar nicht. Bei mir gab es schon mit den alten Libraries seltsame Effekte. Ich verwende meist die Version mit Wastes IR-PWM-Erweiterung. Wenn ich mir z.B. die Linedaten senden lasse, kommt bei stehendem asuro immer wieder ein Wert, der völlig aus der Reihe tanzt. Vom Timeing her würde ich auf einen 16-Bit Überlauf tippen, ich habe das aber nie näher untersucht, sondern per Filter abgefangen. Mein Testprogramm für die Linedaten ist im Anhang, den Quellcode dafür kann ich blöderweise grad nicht finden (das wäre ja wichtig). Aber ihr könnt euch ja selbst einen kurzen Code dafür schreiben. Es werden endlos die Linedaten eingelesen und per IR zum PC geschickt. K6 (in Fahrtrichtung links) schaltet die LineLED an, K5 schaltet sie wieder aus. Hier mein Output:
Ähm, das ist mir jetzt echt peinlich, aber der Effekt tritt scheinbar nicht mehr auf. Bei 0-Werten ist die LineLED aus, die Werte sind so hoch, weil ich eine IR-LED aus einem alten Videorekorder eingebaut habe und der asuro auf einem weisen Blatt stand.Code:0 0 0 0 0 0 0 0 0 0 457 493 446 487 446 486 445 485 445 484 444 485 444 484 444 484 443 484 443 484 443 484 443 483 443 483 443 483 443 483 442 483 442 482 442 482 442 482 442 482 442 482 442 482 442 482 442 482 441 482 440 482 441 482 441 482 441 481 441 481 441 482 441 482 441 481 441 481 441 481 441 481 441 481 441 481 441 481 440 481 441 481 441 481 441 481 440 481 440 481 440 481 440 481 440 481 440 480 440 481 440 481 440 481 440 481 440 481 440 481 440 480 440 480 440 480 440 480 440 480 440 480 440 480 438 480 441 480 440 480 440 480 440 480 440 480 439 480 439 480 440 480 440 480 440 480 440 480 440 480
Eigentlich sollte ich diesen Beitrag ja löschen, aber jetzt habe ich soviel Zeit investiert, dann sollt ihr das auch sehen. In der Zeit hätte ich das auch mit der Odometrie machen können, dass werde ich noch nachreichen, für heute reichts mir mal mit rumrobotern.
Gruß
mic
Bild hier
Atmel’s products are not intended, authorized, or warranted for use
as components in applications intended to support or sustain life!
Guten morgen.
Hallo radbruch und alle anderen natürlich auch,
als Jäger und Sammler kann ich bei mir auf der Platte als erste Version mit Dateidatum vom 20.07.2005 folgendes finden:
Bis auf die Berechnung vom Wheelspeed ist aber der Code noch komplett in der aktuellen Forum-LIB vorhanden.Code:SIGNAL (SIG_ADC) { static unsigned char tmp[2],flag[2],toggle; static int speedcounter[2]; if (autoencode) { tmp[toggle]= ADCH; if (toggle) ADMUX = (1 <<ADLAR) | (1 <<REFS0) | WHEEL_RIGHT; else ADMUX = (1 <<ADLAR) | (1 <<REFS0) | WHEEL_LEFT; // Hysteresis included 25.6.2005 stochri if ( (tmp[toggle] < 150) && (flag[toggle] == TRUE)) // falling edge { encoder[toggle] ++; Wheelspeed[toggle]=speedcounter[toggle]; speedcounter[toggle]=200; // preset speedcounter to maximum speed flag[toggle] = FALSE; } if ( (tmp[toggle] > 160) && (flag[toggle] == FALSE)) // rising edge { encoder[toggle] ++; flag[toggle] = TRUE; } toggle ^= 1; if(speedcounter[toggle]) speedcounter[toggle]--; // if speecounter not zero else Wheelspeed[toggle]=0; } }
Zwei kleine Änderungen:
- Variable toggle wird mit FALSE initialisiert
- Der kleine Hysteresewert wurde von 150 auf 140 reduziert. (Etwas größere Hysterese zum oberen Wert von 160.)
Somit ist es erst einmal egal welche Version benutzt wird.Code:SIGNAL (SIG_ADC) { static unsigned char tmp[2],flag[2],toggle=FALSE; if (autoencode) { tmp[toggle]= ADCH; if (toggle) ADMUX = (1 <<ADLAR) | (1 <<REFS0) | WHEEL_RIGHT; else ADMUX = (1 <<ADLAR) | (1 <<REFS0) | WHEEL_LEFT; if ( (tmp[toggle] < 140) && (flag[toggle] == TRUE)) { encoder[toggle] ++; flag[toggle] = FALSE; } if ( (tmp[toggle] > 160) && (flag[toggle] == FALSE)) { encoder[toggle] ++; flag[toggle] = TRUE; } toggle ^= 1; } }
Aber interessant ist, dass nur der ADCH-Wert, also nur die oberen 8 Bit vom ADC-Wandler, benutzt werden. Dies war zumindest mir nicht so richtig bewußt.
OK, dein Testprogramm für die Liniensensoren ist hier ohne Source nicht so richtig.
Trotzdem ist deine Aussage: "Ähm, das ist mir jetzt echt peinlich, aber der Effekt tritt scheinbar nicht mehr auf." sehr interessant, da dann ja auch bei den Liniensensoren wohl irgendetwas nicht ganz in Ordnung ist.
Deshalb mal eine Frage: Sind die von dir geposteten Daten heute bei Sonnenlicht gewonnen worden? Und, kann es sein, dass du die ersten Tests mit deinem Programm bei Lampenlicht gemacht hast?
Dies würde ja für meine Theorie mit den 50 Hertz sprechen.
Mit deinem Programm bekomme ich nun, ohne Sonne, folgende Messdaten: (Hattest du heute so etwas erwartet, als du vom 'nicht mehr auftretenden Effekt' sprachst?)
Und nun, Trommelwirbel, 50 Hertz betriebene Schreibtischlampe ausgeschaltet:Code:83 94 115 132 116 137 104 126 91 111 79 95 82 93 97 109 113 128 117 138 107 129 94 114 81 98 81 93 94 105 110 124 118 138 110 133 97 118 83 102
Dies ist der Effekt, den ich eben auch bei den Odometrie-Messung erwarte, und für den man halt noch ein Testprogramm schreiben muss. Aber nicht mit einem Messen, und sofort-Senden Zyklus, sondern wie oben beschrieben.Code:Ohne LED-Beleuchtung (Nur LCD-Monitor an) 1 1 1 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 Mit eingeschalteter LED-Beleuchtung 34 40 35 38 35 38 35 38 35 38 34 38 35 38 35 38 35 39 35 39 35 39 35 39 35 39
Lieber Asuro programieren als arbeiten gehen.
Hallo
Das scheint die einzige Erklärung für den Effekt zu sein, der übrigens so ähnlich aussah wie dein 50Hz-Effekt. Die Ausreiser waren nur kürzer und seltener. Das kann dann nicht nur an einer anderen Abtastfrequenz liegen, denn bei mehr Werten pro Zeit sollten ja dann auch mehr Fehler pro Zeit auftreten. Meine Werte von gestern habe ich unter Kunstlicht bei für mich "normalen" Lichtverhältnissen eingelesen. Hier noch meine Odo-Werte bei stehendem (,weil festgeklebten,) Ritzel:
(Man sieht auch schön den Lesefehler beim ersten Wert)Code:Senden der Odometriedaten 16.7.07 mic 456 667 214 670 214 670 215 671 215 671 215 671 215 671 215 671 216 671 216 671 216 671 216 671 216 671 216 671 216 671 216 671 216 671 216 671 216 671 216 671 217 671 217 671 217 671 217 671 217 671 217 671 217 671 217 671 217 671 217 671 217 671 217 671 217 671 217 671 217 671 217 671 217 671 218 671 218 671 218 671 218 671 218 671 218 671 218 671 218 671 218 671 218 671 218 671 218 671 218 671 218 671 218 671 218 671 218 671 218 671 218 671 218 671 218 671 218 671 218 671 218 671 218 671 218 671 218 671 218 671 218 671 219 672 220 672 220 672 220 672 220 672 220 672
Hier noch das Programm:
Und noch die Version meiner Library:Code:#include "ir-asuro.h" uint16_t data[2]; int main(void) { Init(); StatusLED(RED); SerWrite("\n\n\rSenden der Odometriedaten 16.7.07 mic\n\n\r",43); StatusLED(YELLOW); while(1) { OdometrieData(data); PrintInt(data[0]); SerWrite(" ",1); PrintInt(data[1]); SerWrite("\n\r",2); } return(0); }
Schade (oder gut?), dass man nichts mehr vom Effekt sieht.Code:/******************************************************************************* * * File Name: asuro.c * Project : ASURO * * Description: This file contains ASURO main features * * Ver. Date Author Comments * ------- ---------- -------------- ------------------------------ * 1.00 14.08.2003 Jan Grewe build * 2.00 14.10.2003 Jan Grewe LEFT_VEL, RIGHT_VEL -> MotorSpeed(unsigned char left_speed, unsigned char right_speed); * LeftRwd(),LeftFwd(),RightRwd(),RigthFwd() -> MotorDir(unsigned char left_dir, unsigned char right_dir); * GREEN_ON,GREEN_OFF,RED_ON,RED_OFF -> StatusLED(unsigned char color); * LED_RED_ON, LED_RED_OFF -> FrontLED(unsigned char color); * Blink(unsigned char left, unsigned char right) -> BackLED(unsigned char left, unsigned char right); * Alles in Funktionen gefasst => leichter verständlich ?!?! * 2.10 17.10.2003 Jan Grewe new Timer funktion void Sleep(unsigned char time36kHz) * * Copyright (c) 2003 DLR Robotics & Mechatronics *****************************************************************************/ /**************************************************************************** * * File Name: asuro.c * Project : asuro library "Robotrixer Buxtehude" * * Description: This file contains additional functions: * * signal (SIG_ADC) interrupt/signal routine for encoder-counter * signal (SIG_INTERRUPT1) signal for switches * Encoder_Init() initializing encoder-counter * Encoder_Start() start autoencoding * Encoder_Stop() stop autoencoding * Encoder_Set(int,int) set encodervalue * Msleep(int delay) wait for delay in milliseconds * Gettime() get systemtime in milliseconds * PrintInt(int) * * modifications in Sleep, SIG_OUTPUT_COMPARE2, PollSwitch, LineData * * Ver. Date Author Comments * ------- ---------- -------------- ------------------------------ * beta1 31.03.2005 Robotrixer asuro library * ------- ---------- -------------- ------------------------------ * the encoder source is based on RechteckDemo.c ver 2.0 by Jan Grewe 22.10.2003 * Copyright (c) 2003 DLR Robotics & Mechatronics *****************************************************************************/ /**************************************************************************** * * File Name: asuro.c * Project : asuro library modified for IR collision detector * * Description: modifications made in following functions: * * SIGNAL (SIG_OUTPUT_COMPARE2) -> SIGNAL (SIG_OVERFLOW2) * Gettime() counts now 36kHz * Init() timer2 modified for adjustable duty cycle * Batterie() bug fixed * Sleep() counts now 36kHz * Msleep() counts now 36kHz * * Ver. Date Author Comments * ------- ---------- -------------- ------------------------------ * beta2 11.06.2005 Waste asuro library * ------- ---------- -------------- ------------------------------ *****************************************************************************/ /*************************************************************************** * * * This program is free software; you can redistribute it and/or modify * * it under the terms of the GNU General Public License as published by * * the Free Software Foundation; either version 2 of the License, or * * any later version. * ***************************************************************************/
Gruß
mic
Bild hier
Atmel’s products are not intended, authorized, or warranted for use
as components in applications intended to support or sustain life!
Berechtigungen
Lesezeichen