Probleme mit 22er-Lochscheiben

[inka]

hi sternthaler,

ich habe ja bereits geschrieben, dass an neuen lochscheiben gearbeitet wird. Die sind nun fertig und es gibt probleme:
- anzahl löcher - 22, ursprünglich 4 sw segmente und 4 ws segmente, die dann durch 8 löcher ersetzt wurden
- verhältnis alt/neu = 1:2,75, in dem verhältnis verringerte ich auch die variable MY_GO_ENC_COUNT_VALUE auf 5723L . das war notwendig, weil mein asuro schon beim versuch die go funktion mit diesem programm zu testen fast vom tisch gefallen wäre. trotz der vorherigen ermittlung von ODO DARK und LIGHT werten, die nun so groß sind:
MY_ODO_LIGHT_VALUE_L 76
MY_ODO_DARK_VALUE_L 47
MY_ODO_LIGHT_VALUE_R 87
MY_ODO_DARK_VALUE_R 55

und nun zum problem: TURN

-die funktion lässt sich auf dem asuro nicht starten
- manuelle verändeung in der myasuro.h lassen sich zwar durchführen, aber:

sollte der wert im gleichen verhältnis 2,75 angepasst werden, wäre es 69 (ursprünglich bei 8 löchern 192)...
Diese veränderun bewirkt aber nicht, dass der asuro beim turn(90,150) auch ein 90° winkel dreht, sondern einen viel kleineren. Manuelle veränderungen (erhöhungen) des wertes bewirken eine gewisse vergrößerung des winkels, ab dem wert 350 dreht der asuro überhaupt nicht, beim einsatz des test programms aus der encoder.c (quadrat fahren) fährt er vor, zuckt kurz und fährt wieder vor...
was kann ich machen???

[Sternthaler]

Hallo inka,
für MY_TURN_ENC_COUNT_VALUE muss auf alle Fälle ein größerer Wert benutzt werden.
Wenn du also vorher 192 hattest, sollten dann so ca. 530 benutzt werden.
Ich habe mal in allen mir vorliegenden LIB-Version nachgeschaut. An den Variablen-Definitionen kann es eigentlich nicht liegen. Die sind immer mindestens mit int definiert worden.

Was mich aber stark wundert ist der alte Wert von 192 bei 4/4-er Scheiben bei dir.
Ich habe die 8/8-er Scheiben am Asuro. Bei mir habe ich ca. einen Wert von 215. Somit liegen wir nicht weit auseinander. Warum?
Im Verhältnis zu meinen Scheiben sollte dein alter Wert dann nur bei ca. 108 liegen. Multipliziert mit den 2,75 also bei 300. Und damit schon viel zu weit weg von deinem Versuch mit 350.
Könnte es sein, dass bei dir der Asuro bei Test 4 (Turn) 180° Grad dreht? Er soll nur 90° Grad drehen! (Alte SW-Scheiben)

Was passiert überhaupt beim ausprobieren mit diesem Ermittlungsprogramm?
Du solltest auf alle Fälle immer Test 1 (Tasten) und Test 2 (Hell-/Dunkel-Werte) machen.
Test 3 (Go) und Test 4 (Turn) sind unabhängig voneinander.

Liefert Test 3 (Go) funktionsfähige Werte?
Bei Test 4 (Turn) wird beim Drücken der Tasten 'zu groß' bzw. 'zu klein' am Asuro der aktuelle Wert im PC-Programm rechts unter 'Daten' ausgegeben. Das sind die Werte in <>-Klammern. Was kommt da?


Es gibt aber noch eine andere Variante, die dich wahrscheinlich zum heulen bringen würde. :(
Du schreibst:

anzahl löcher - 22
Wenn auf der Scheibe nun 22 Löcher sind, ist es nämlich möglich, dass die Abfrage der Sensoren in der Lib zu langsam ist um die Löcher alle mitzubekommen. (Auf dem Foto gehe ich aber doch nur von 8 Löchern aus.)
Eigentlich sollte dann aber das drehen/fahren immer viel zu weit sein, da ja 'angeblich' noch keine Tik's gefahren wurden, wenn sie nicht gemessen werden konnten. Also weiterfahren wäre angesagt.

Im Moment bin ich mit meinem Latein am Ende.
Poste mal ein paar Daten aus dem PC-Programm vom Test 4(Turn) und evl. auch mal deinen Programmcode.

Gruß Sternthaler

P.S.: Hier muss ich mal Reklame für inkas tollen Umbau (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=322643#322643) machen.

[inka]

hi sternthaler,

momentan habe ich noch größere probleme, nicht einmal das go(200,150) geht, er fährt einfach nur geradeaus ohne anzuhalten...Ich poste hier mal die myasuro.h:

/* Tastaturabfrage */
/*! Faktor zur Berechnung der gedrueckten Tasten.\n
Der Originalwert ist \b 61L und koennten im Bereich zwischen ca. 58L und
65L schwanken. Dieser Wert gleicht Toleranzen der Wiederstaende an den
Tastern aus.
*/
//#define MY_SWITCH_VALUE 61L /*!< Multiplikator fuer Tasterwerte */
#define MY_SWITCH_VALUE 63L //20_08_2007

/* Odometrie / Encoder */
/*! Wert, der in der Odometrie ueberschritten werden muss, um zum
weiterzaehlen der Ticks in encoder[] zu fuehren bei aktivierter
Automatik\n
Die Originalwerte (links, rechts) sind \b 160.
Diese Werte sind sehr stark vom Umgebungslicht abhaengig.
Sie MUESSEN GROESSER als die Werte fuer MY_ODO_DARK_VALUE_L sein.
*/
//#define MY_ODO_LIGHT_VALUE_L 160 /*!< Encoderschwellwert fuer Hell (linke Seite) */
//#define MY_ODO_LIGHT_VALUE_L 97 //20.08.2007
//#define MY_ODO_LIGHT_VALUE_L 105 //16.10.2007
#define MY_ODO_LIGHT_VALUE_L 76 //24.10.2007
/*! Wert, der in der Odometrie unterschritten werden muss, um zum
weiterzaehlen der Ticks in encoder[] zu fuehren bei aktivierter
Automatik\n
Die Originalwerte (links, rechts) sind \b 140.
Diese Werte sind sehr stark vom Umgebungslicht abhaengig.
Sie MUESSEN KLEINER als die Werte fuer MY_ODO_LIGHT_VALUE_L sein.
*/
//#define MY_ODO_DARK_VALUE_L 140 /*!< Encoderschwellwert fuer Dunkel (linke Seite) */
//#define MY_ODO_DARK_VALUE_L 59 //20.08.2007
//#define MY_ODO_DARK_VALUE_L 65 //16.10.2007
#define MY_ODO_DARK_VALUE_L 47 //24.10.2007
/*! Wert, der in der Odometrie ueberschritten werden muss, um zum
weiterzaehlen der Ticks in encoder[] zu fuehren bei aktivierter
Automatik\n
Die Originalwerte (links, rechts) sind \b 160.
Diese Werte sind sehr stark vom Umgebungslicht abhaengig.
Sie MUESSEN GROESSER als die Werte fuer MY_ODO_DARK_VALUE_R sein.
*/
//#define MY_ODO_LIGHT_VALUE_R 160 /*!< Encoderschwellwert fuer Hell (rechte Seite) */
//#define MY_ODO_LIGHT_VALUE_R 107 //16.10.2007
#define MY_ODO_LIGHT_VALUE_R 87 //24.10.2007
/*! Wert, der in der Odometrie unterschritten werden muss, um zum
weiterzaehlen der Ticks in encoder[] zu fuehren bei aktivierter
Automatik\n
Die Originalwerte (links, rechts) sind \b 140.
Diese Werte sind sehr stark vom Umgebungslicht abhaengig.
Sie MUESSEN KLEINER als die Werte fuer MY_ODO_LIGHT_VALUE_R sein.
*/
//#define MY_ODO_DARK_VALUE_R 140 /*!< Encoderschwellwert fuer Dunkel (rechte Seite) */
//#define MY_ODO_DARK_VALUE_R 66 //16.10.2007
#define MY_ODO_DARK_VALUE_R 55 //24.10.2007
/* Werte für 12 Segmente Encoder */
/*! Faktor zur Berechnung von Ticks um aus den in mm angegebenen Parameter
umzurechnen.\n
Der Originalwert ist \b 19363L und ist von der Anzahl der schwarz/weiss
Teilstuecke auf den Odometriescheiben abhaengig.\n
Der Originalwert wurde durch stochri ermittelt.
*/
//#define MY_GO_ENC_COUNT_VALUE 19363L /*!< GO Funktion, Divisor fuer Entfernung */
#define MY_GO_ENC_COUNT_VALUE 15740L //20.08.2007
//#define MY_GO_ENC_COUNT_VALUE 5723L //24.10.2007
/*! Faktor zur Berechnung von Ticks um aus den in Grad angegebenen Parameter
umzurechnen.\n
Der Originalwert ist \b 177L und ist von der Anzahl der schwarz/weiss
Teilstuecke auf den Odometriescheiben abhaengig.\n
Der Originalwert wurde durch stochri ermittelt.
*/
//#define MY_TURN_ENC_COUNT_VALUE 177L /*!< Turn Funktion, Mutiplikator fuer Winkel */
//#define MY_TURN_ENC_COUNT_VALUE 197L //20.08.2007
//#define MY_TURN_ENC_COUNT_VALUE 210L //06.09.2007
#define MY_TURN_ENC_COUNT_VALUE 192 //16.10.2007
//#define MY_TURN_ENC_COUNT_VALUE 500 //24.10.2007
/* Werte zum ausgleichen unterschiedlicher Motoren */
/*! Differenzangabe zwischen den beiden Motoren.\n
Der angegeben Wert verteilt sich je zur Haelte auf die Vorgaben fuer die\n
Motorgeschwindigkeit.\n
Bei einem \n positiven Wert, wird der \n rechte Motor \b verstaerkt.\n
Bei einem \n negativen Wert, wird der \n linke Motor \b verstaerkt.
*/
#define MY_MOTOR_DIFF 0 /*!< 1/2 PLUS fuer Rechts, 1/2 MINUS fuer Links */

#endif /* MYASURO_H */

den test mit deinem programm für die ermittlung der myasuro werte werde ich noch einmal durchführen, beim letzten mal habe ich die werte für die hell/dunkel übergänge ermittelt, dann beim go test fuhr der asuro gleich stark nach rechts (musste ihn einfangen), es wurde die möglichkeit zum "zu kurz, zu lang ok nochmals" überhaupt nicht angeboten - (durch eine unterbrechnung der IR verbindung?), das turn testprogramm liess sich dann, als ich den asuro wieder so hinstellte, dass er in sichtweite des IR-transceivers war nicht starten, die status LED blinkte so weit ich mich erinnern kann nur kurz in rot und dann wieder grün.

edit2: den taster-test habe ich vorher nicht durchgeführt - kann es sein, dass dann die tasten bei den darauffolgenden tests (go/turn) nicht/nicht richtig erkannt werden?

auf dem neuen foto hier kann man die 22 löcher sehen denke ich und in der code tabelle sind die mit dieser 22er scheibe über ein ausgabeprogramm festgehaltenen werte:

L: 21 R:340 Lmax:10 Lmin:523 Rmax:170 Rmin:682
L: 21 R:328 Lmax:15 Lmin:272 Rmax:249 Rmin:505
L: 27 R:658 Lmax:21 Lmin:150 Rmax:453 Rmin:505
L: 43 R:261 Lmax:32 Lmin:97 Rmax:453 Rmin:383
L: 84 R:557 Lmax:58 Lmin:91 Rmax:505 Rmin:383
L: 20 R:130 Lmax:58 Lmin:56 Rmax:505 Rmin:257
L: 134 R:475 Lmax:96 Lmin:56 Rmax:505 Rmin:257
L: 23 R:507 Lmax:96 Lmin:40 Rmax:506 Rmin:257
L: 627 R:293 Lmax:361 Lmin:40 Rmax:506 Rmin:257
L: 23 R:51 Lmax:361 Lmin:32 Rmax:506 Rmin:154
L: 18 R:54 Lmax:361 Lmin:25 Rmax:506 Rmin:104
L: 19 R:348 Lmax:361 Lmin:22 Rmax:506 Rmin:104
L: 15 R:124 Lmax:361 Lmin:19 Rmax:506 Rmin:104
L: 641 R:32 Lmax:501 Lmin:19 Rmax:506 Rmin:68
L: 45 R:37 Lmax:501 Lmin:19 Rmax:506 Rmin:53
L: 631 R:476 Lmax:566 Lmin:19 Rmax:506 Rmin:53
L: 22 R:322 Lmax:566 Lmin:19 Rmax:506 Rmin:53
L: 654 R:546 Lmax:610 Lmin:19 Rmax:526 Rmin:53
L: 36 R:569 Lmax:610 Lmin:19 Rmax:547 Rmin:53
L: 28 R:519 Lmax:610 Lmin:19 Rmax:547 Rmin:53
L: 24 R:620 Lmax:610 Lmin:19 Rmax:583 Rmin:53
L: 27 R:419 Lmax:610 Lmin:19 Rmax:583 Rmin:53
L: 20 R:489 Lmax:610 Lmin:19 Rmax:583 Rmin:53
L: 509 R:243 Lmax:610 Lmin:19 Rmax:583 Rmin:53
L: 308 R:280 Lmax:610 Lmin:19 Rmax:583 Rmin:53
L: 24 R:723 Lmax:610 Lmin:19 Rmax:653 Rmin:53
L: 33 R:376 Lmax:610 Lmin:19 Rmax:653 Rmin:53
L: 634 R:215 Lmax:622 Lmin:19 Rmax:653 Rmin:53
L: 38 R:412 Lmax:622 Lmin:19 Rmax:653 Rmin:53
L: 41 R:566 Lmax:622 Lmin:19 Rmax:653 Rmin:53
L: 18 R:626 Lmax:622 Lmin:19 Rmax:653 Rmin:53
L: 22 R:33 Lmax:622 Lmin:19 Rmax:653 Rmin:43
L: 575 R:544 Lmax:622 Lmin:19 Rmax:653 Rmin:43
L: 40 R:492 Lmax:622 Lmin:19 Rmax:653 Rmin:43
L: 24 R:649 Lmax:622 Lmin:19 Rmax:653 Rmin:43
L: 37 R:596 Lmax:622 Lmin:19 Rmax:653 Rmin:43
L: 27 R:39 Lmax:622 Lmin:19 Rmax:653 Rmin:41
L: 36 R:160 Lmax:622 Lmin:19 Rmax:653 Rmin:41
L: 211 R:367 Lmax:622 Lmin:19 Rmax:653 Rmin:41
L: 31 R:544 Lmax:622 Lmin:19 Rmax:653 Rmin:41
L: 92 R:586 Lmax:622 Lmin:19 Rmax:653 Rmin:41
L: 507 R:313 Lmax:622 Lmin:19 Rmax:653 Rmin:41
L: 235 R:575 Lmax:622 Lmin:19 Rmax:653 Rmin:41
L: 27 R:706 Lmax:622 Lmin:19 Rmax:679 Rmin:41
L: 637 R:575 Lmax:629 Lmin:19 Rmax:679 Rmin:41
L: 28 R:568 Lmax:629 Lmin:19 Rmax:679 Rmin:41
L: 625 R:344 Lmax:629 Lmin:19 Rmax:679 Rmin:41
L: 374 R:577 Lmax:629 Lmin:19 Rmax:679 Rmin:41
L: 20 R:707 Lmax:629 Lmin:19 Rmax:693 Rmin:41
L: 33 R:553 Lmax:629 Lmin:19 Rmax:693 Rmin:41
L: 184 R:462 Lmax:629 Lmin:19 Rmax:693 Rmin:41
L: 20 R:600 Lmax:629 Lmin:19 Rmax:693 Rmin:41
L: 28 R:538 Lmax:629 Lmin:19 Rmax:693 Rmin:41
L: 646 R:45 Lmax:637 Lmin:19 Rmax:693 Rmin:41
L: 18 R:47 Lmax:637 Lmin:19 Rmax:693 Rmin:41
L: 383 R:35 Lmax:637 Lmin:19 Rmax:693 Rmin:38
L: 651 R:710 Lmax:644 Lmin:19 Rmax:701 Rmin:38
L: 18 R:510 Lmax:644 Lmin:19 Rmax:701 Rmin:38
L: 25 R:43 Lmax:644 Lmin:19 Rmax:701 Rmin:38
L: 22 R:247 Lmax:644 Lmin:19 Rmax:701 Rmin:38

danke...

edit, 25.10. 13:59 - entspricht meine scheibe mit 8 löchern nicht eher der 8/8 reflektionsscheibe als der 4/4er?

[inka]

hi allerseits,

jetzt nicht mehr über edit, weil das ja leicht übersehen werden kann. ich habe jetzt den asuro wieder so weit, dass er gerade stückchen mit go(200,150) fährt. so weit so gut.
hier erstmal mein programm:

/*ladestation_anfahren*/

#include "asuro.h"
#include "inka.h"
#include "stdio.h"
int i;
int main (void)

{

Init();

WaitforStart();


while(1)
{
batt_abfrage();

{
EncoderInit();
void links_ausw();
if (PollSwitch()>0) {
StatusLED(RED);
Go (-100,150);
Turn (-90, 150);
}
else {
Go (200, 150);
StatusLED(GREEN);
Msleep(500);
}
void links_ausw();
if (PollSwitch()>0) {
StatusLED(RED);
Go (-100, 150);
Turn (-90, 150);
}
else {
Turn (180, 150);
StatusLED(YELLOW);
Msleep(500);
}
}
}
return 0;
}
-------------
void links_ausw(); ist aufruf einer routine aus der inka.c, die die IR sensoren als entfernungsmessung verwendet, die sind momentan außer betrieb
--------------
jetzt habe ich - pragmatisch wie ich nun mal bin - versucht das problem mit dem TURN damit zu umgehen, dass ich ihn halt dabei lasse, wenn er per vorgegebenen wert in der myasuro.h nur ca. 45° winkel drehen will und ihn halt mit "turn(180,150) einen 90° winkel drehen lasse.
Und die reaktion
ist die gleiche, wie auf eine zahl in der asuro.h die >350 ist, nämlich ein kurzes aufblinken der statusLED (gelb), möglicherweise durch mein programm bedingt - und weiteres geradeaus fahren (das nächste go in der while schleife). Deutet sowas nicht auf einen - nennen wir es mal sowas wie einen überlauffehler durch eine zahl, die entsteht bei/durch die 22/22 scheibe?

[damaltor]

sollte die anzahl der löcher wirklich zu viel sein? das sollte sich doch mit einer langsameren geschwindigkeit testen lassen... fährt der asuro mit 22 löchern bei niedrigen geschwindigkeiten normal, und mit großen geschwindigkeiten eigenartig? oder scheinen die probleme geschwindigkeitsunabhängig zu sein?

[inka]

hi damaltor,
bei programmen wie diesem:

//Programm zum Umfahren von Hindernissen mithilfe der Infrarot-Hinderniserkennung von waste
//zusammengestellt und programmiert von julien

#include "asuro.h"
#include <stdlib.h>
#include "inka.h"

int main(void)
{
float puls;
int hindernis=0;
int richt=0, wegr=0, wegl=0, vorher=0, auswl=0, auswr=0, schritt=0;
unsigned int Rmin = 1024, Rmax = 0, Lmin = 1024, Lmax = 0, Rmitte = 512, Lmitte = 512, lspeed=185, data[2];
unsigned char flagl=FALSE, flagr=FALSE;
Init();
WaitforStart();
DDRD |= (1 << DDD1); // Port D1 als Ausgang
PORTD &= ~(1 << PD1); // PD1 auf LOW
puls = 1;
while(1)
{
if (PIND & (1 << PD0)){
StatusLED(GREEN); // kein Hindernis
} else {
vorher=(int)(puls);
hindernis=1;
StatusLED(RED); // Hindernis erkannt
}

puls = 1.02 * puls; // Pulsbreite wird um 2% erhöht
if (puls > 10){
if (PIND & (1 << PD0)) hindernis=0;
puls = 1;
}
OCR2 = 255 - (int)(puls);

if(hindernis==1){ //"gucken", wo noch ein freier Weg ist und diesen dann fahren
if(schritt==0){ //nach rechts "gucken"
MotorDir(FWD,RWD);
Msleep(100);
}
if(schritt==1){
auswr=(int)(puls);
}
if(schritt==2){ //nach links gucken
MotorDir(RWD,FWD);
Msleep(100);
}
if(schritt==3){
auswl=(int)(puls);
}
if(schritt==4){ //richtigen weg fahren
if(auswr>auswl) richt=1;
if(auswr<auswl) richt=2;
if(auswr==auswl) richt=3;
}
if(schritt<4) schritt++;
}

if(hindernis==0){ //kein Hindernis in Sicht - geradeaus fahren
richt=0;
schritt=0;
OdometrieData(data); // 0. links, 1. rechts
// max links
if (data[0] > Lmax)
Lmax += (data[0] - Lmax) / 2;
// min links
if (data[0] < Lmin)
Lmin -= (Lmin - data[0]) / 2;
// max rechts
if (data[1] > Rmax)
Rmax += (data[1] - Rmax) / 2;
// min rechts
if (data[1] < Rmin)
Rmin -= (Rmin - data[1]) / 2;
Rmitte=(Rmax+Rmin)/2;
Lmitte=(Lmin+Lmax)/2;
if ((data[0] < Lmitte) && (flagl == TRUE)) {
flagl = FALSE;
wegl++;
}
if ((data[0] > Lmitte) && (flagl == FALSE)) {
flagl = TRUE;
wegl++;
}
if ((data[1] < Rmitte) && (flagr == TRUE)) {
flagr = FALSE;
wegr++;
}
if ((data[1] > Rmitte) && (flagr == FALSE)) {
flagr = TRUE;
wegr++;
}
if(wegl<wegr) lspeed++;
if(wegl>wegr) lspeed--;
if(wegl>=1000){ wegl=0; wegr=wegr-1000; } //zurücksetzen, damit kein Überlauf nach
if(wegr>=1000){ wegr=0; wegl=wegl-1000; } //längeren Fahrten passiert
}
if(richt==0) MotorDir(FWD,FWD); //geradeaus
if(richt==1) MotorDir(RWD,FWD); //links
if(richt==2) MotorDir(FWD,RWD); //rechts
if(richt==3) MotorDir(RWD,RWD); //zurück

MotorSpeed(lspeed,170);
}
return 0;
}
fährt er einwandfrei, es werden aber auch weder go, noch turn verwendet...
im gegenteil, der ist noch nie so geradeuas gefahren wie mit den roten 22er scheiben...

[Sternthaler]

Super Ansatz von damaltor dem Problem so auf die Schliche zu kommen.

Im Source selber kann ich nämlich nichts entdecken. Auch das, von dir inka, angedeutete Problem einer eventuell zu klein definierten Variable ist nicht zu sehen.

Gruß Sternthaler

[EDIT] Da habe ich wohl die Antwort von inka gerade nicht mitbekommen.

[damaltor]

hmm... mahc doch mal die probe aufs exempel... einmal mit speed 100 geradeaus, links drehen, rechts drehen und dann einmal mit 255... was passiert?

[inka]

hi damator,

mit folgendem programm:

#include "asuro.h"
#include "inka.h"


int main (void)

{

Init();
WaitforStart();
EncoderInit ();
Go(100,100);
Turn(100,100);
Go(100,100);
Turn(-100,100);

Go(100,150);
Turn(100,150);
Go(100,150);
Turn(-100,150);

Go(100,200);
Turn(100,200);
Go(100,200);
Turn(-100,200);

return 0;
}
ruckelt er 6x 100mm vor, mit ansteigenden geschwindigkeiten, beim start mit 100 braucht er einen kleinen schubs, um die Turns kümmer er sich nicht...

[damaltor]

das ist deprimierend. hast du noch andere odo scheiben für die gegenprobe? also nur testweise, um zu sehen ob sich überhaupt was tut, egal wie viel er dreht. interessant wäre, OB er dreht. das problem wird interessant... ;)

[inka]

hi damaltor,

habe die 22er räder gegen die 8er gewechselt - das geht inzwischen wie beim ferrari team - die werte in der asuro.h wurden zunächst unverändert übernommen:

/* Tastaturabfrage */
/*! Faktor zur Berechnung der gedrueckten Tasten.\n
Der Originalwert ist \b 61L und koennten im Bereich zwischen ca. 58L und
65L schwanken. Dieser Wert gleicht Toleranzen der Wiederstaende an den
Tastern aus.
*/
//#define MY_SWITCH_VALUE 61L /*!< Multiplikator fuer Tasterwerte */
#define MY_SWITCH_VALUE 63L //20_08_2007

/* Odometrie / Encoder */
/*! Wert, der in der Odometrie ueberschritten werden muss, um zum
weiterzaehlen der Ticks in encoder[] zu fuehren bei aktivierter
Automatik\n
Die Originalwerte (links, rechts) sind \b 160.
Diese Werte sind sehr stark vom Umgebungslicht abhaengig.
Sie MUESSEN GROESSER als die Werte fuer MY_ODO_DARK_VALUE_L sein.
*/
//#define MY_ODO_LIGHT_VALUE_L 160 /*!< Encoderschwellwert fuer Hell (linke Seite) */
//#define MY_ODO_LIGHT_VALUE_L 97 //20.08.2007
#define MY_ODO_LIGHT_VALUE_L 105 //16.10.2007 - 8er räder
//#define MY_ODO_LIGHT_VALUE_L 76 //24.10.2007 - 22er räder
/*! Wert, der in der Odometrie unterschritten werden muss, um zum
weiterzaehlen der Ticks in encoder[] zu fuehren bei aktivierter
Automatik\n
Die Originalwerte (links, rechts) sind \b 140.
Diese Werte sind sehr stark vom Umgebungslicht abhaengig.
Sie MUESSEN KLEINER als die Werte fuer MY_ODO_LIGHT_VALUE_L sein.
*/
//#define MY_ODO_DARK_VALUE_L 140 /*!< Encoderschwellwert fuer Dunkel (linke Seite) */
//#define MY_ODO_DARK_VALUE_L 59 //20.08.2007
#define MY_ODO_DARK_VALUE_L 65 //16.10.2007 - 8er räder
//#define MY_ODO_DARK_VALUE_L 47 //24.10.2007 - 22er räder
/*! Wert, der in der Odometrie ueberschritten werden muss, um zum
weiterzaehlen der Ticks in encoder[] zu fuehren bei aktivierter
Automatik\n
Die Originalwerte (links, rechts) sind \b 160.
Diese Werte sind sehr stark vom Umgebungslicht abhaengig.
Sie MUESSEN GROESSER als die Werte fuer MY_ODO_DARK_VALUE_R sein.
*/
//#define MY_ODO_LIGHT_VALUE_R 160 /*!< Encoderschwellwert fuer Hell (rechte Seite) */
#define MY_ODO_LIGHT_VALUE_R 107 //16.10.2007 - 8er räder
//#define MY_ODO_LIGHT_VALUE_R 87 //24.10.2007 - 22er räder
/*! Wert, der in der Odometrie unterschritten werden muss, um zum
weiterzaehlen der Ticks in encoder[] zu fuehren bei aktivierter
Automatik\n
Die Originalwerte (links, rechts) sind \b 140.
Diese Werte sind sehr stark vom Umgebungslicht abhaengig.
Sie MUESSEN KLEINER als die Werte fuer MY_ODO_LIGHT_VALUE_R sein.
*/
//#define MY_ODO_DARK_VALUE_R 140 /*!< Encoderschwellwert fuer Dunkel (rechte Seite) */
#define MY_ODO_DARK_VALUE_R 66 //16.10.2007 - 8er räder
//#define MY_ODO_DARK_VALUE_R 55 //24.10.2007 - 22er räder
/* Werte für 12 Segmente Encoder */
/*! Faktor zur Berechnung von Ticks um aus den in mm angegebenen Parameter
umzurechnen.\n
Der Originalwert ist \b 19363L und ist von der Anzahl der schwarz/weiss
Teilstuecke auf den Odometriescheiben abhaengig.\n
Der Originalwert wurde durch stochri ermittelt.
*/
//#define MY_GO_ENC_COUNT_VALUE 19363L /*!< GO Funktion, Divisor fuer Entfernung */
#define MY_GO_ENC_COUNT_VALUE 15740L //20.08.2007 - 8er räder
//#define MY_GO_ENC_COUNT_VALUE 5723L //24.10.2007 - 22er räder
/*! Faktor zur Berechnung von Ticks um aus den in Grad angegebenen Parameter
umzurechnen.\n
Der Originalwert ist \b 177L und ist von der Anzahl der schwarz/weiss
Teilstuecke auf den Odometriescheiben abhaengig.\n
Der Originalwert wurde durch stochri ermittelt.
*/
//#define MY_TURN_ENC_COUNT_VALUE 177L /*!< Turn Funktion, Mutiplikator fuer Winkel */
//#define MY_TURN_ENC_COUNT_VALUE 197L //20.08.2007
//#define MY_TURN_ENC_COUNT_VALUE 210L //06.09.2007
#define MY_TURN_ENC_COUNT_VALUE 192 //16.10.2007 - 8er räder
//#define MY_TURN_ENC_COUNT_VALUE 350 //24.10.2007 - 22er räder
/* Werte zum ausgleichen unterschiedlicher Motoren */
/*! Differenzangabe zwischen den beiden Motoren.\n
Der angegeben Wert verteilt sich je zur Haelte auf die Vorgaben fuer die\n
Motorgeschwindigkeit.\n
Bei einem \n positiven Wert, wird der \n rechte Motor \b verstaerkt.\n
Bei einem \n negativen Wert, wird der \n linke Motor \b verstaerkt.
*/
#define MY_MOTOR_DIFF 0 /*!< 1/2 PLUS fuer Rechts, 1/2 MINUS fuer Links */

#endif /* MYASURO_H */

asuro dreht nicht.
ich habe das testprogramm etwas erweiter, die LED´s leuchten brav:

#include "asuro.h"
#include "inka.h"


int main (void)

{

Init();
WaitforStart();

EncoderInit ();

Go(100,100);
StatusLED(GREEN);
Msleep(500);
Turn(100,100);
StatusLED(RED);
Msleep(500);
Go(100,100);
StatusLED(GREEN);
Msleep(500);
Turn(-100,100);
StatusLED(RED);
Msleep(500);

Go(100,150);
StatusLED(GREEN);
Msleep(500);
Turn(100,150);
StatusLED(RED);
Msleep(500);
Go(100,150);
StatusLED(GREEN);
Msleep(500);
Turn(-100,150);
StatusLED(RED);
Msleep(500);

Go(100,200);
StatusLED(GREEN);
Msleep(500);
Turn(100,200);
StatusLED(RED);
Msleep(500);
Go(100,200);
StatusLED(GREEN);
Msleep(500);
Turn(-100,200);
StatusLED(RED);
Msleep(500);

return 0;
}
Dann veränderte ich die werte in die für 8er räder, asuro dreht...

Ich kann mich immer noch nicht des eindrucks erwehren dass es mit der interpretation des turn wertes in der myasuro.h zu tun hat...

[inka]

hi sternthaler,

habe noch einmal die 22er räder aufgezogen und noch einmal den versuch gemacht mit wertermittlung für die myasuro.h mit deinem programm:

- die werte in der myasuro.h habe ich dafür nicht verändert, für die fertige test.hex spielt das wohl aber kaum eine rolle...

alle tests durchgeführt:

- tastertest ergab 63, wie schon gehabt
- hell/dunkel werte kannte ich auch schon
- beim go test bricht der asuro nach rechts aus, spielt hier aber keine rolle, das go(xxx, 150) geht ja
- beim turn-test konnte ich 2x "zu klein" angeben, anschliessend wiederholen, der gedrehte winkel war größer, beim dritten versuch "zu klein" per taster einzugeben streikte die systemLED, sie blieb rot. beim bestätigen mit OK taster erschien im feld für den turnparameter eine "1"!!!

hilft das?

[inka]

hi allerseits,

ich habe noch ein bischen mit den 22er rädern experimentiert, unter umgehung der turn-funktion, sprich mit etwas abgewandelten code aus dem band II-asuro (aufgrund des fast rechteckigen verlaufes des odo-signales kann ich die hysterese vergrößern und den wert für triggerlevel auf 300 legen) lässt sich ein ziemlich genaues quadrat fahren :-). Durch die vergrößerung des abstandes zwischen den dunkel/hell werten ist die justage der doch relativ weich aufgehängten lichtschranken auch nicht mehr so difizil und störungsanfällig...

Was kann es mit der turn funktion sein? Das einzige was mir bei dem code aus dem buch auffiel, ist folgendes:
am anfang: unsigned int distance=0;
wenn es dann komplizierter wird: unsigned long int distance=0;

distance ist dort die variable (switch) wo die ticks gezählt werden...


*im quadrat - 22er räder*/

#include "asuro.h"
#include "inka.h"

//schwellwert für die hell/dunkel unterscheidung
//evtl. muss damit etwas variiert werden

#define TRIGGERLEVEL 300
#define HYSTERESIS 50

#define LOW 0
#define HIGH 1

int main (void)
{
unsigned int data[2];
signed int status[2]={0,0};
signed int difference=0;
unsigned long int distance=0;
signed int speed=0;
// int i;

Init();
WaitforStart();

while(1)
{
switch (distance)
{
//am anfang der strecke langsam anfahren
case 0: MotorDir (FWD,FWD); speed=150; break;
case 50: MotorDir (FWD,FWD); speed=200; break;
case 100: MotorDir (FWD,FWD); speed=255; break;
//am ende langsamer werden
case 750: speed=200; break;
case 800: speed=150; break;
//und stehebleiben
case 860: MotorDir(BREAK,BREAK);
//distance=861;
//etwas warten bis der asuro wirklich steht
Msleep(200);

MotorDir(RWD, FWD);speed=150;
distance=861;
case 900: speed=255; break;
case 950: speed=200; break;
case 980: speed=150; break;
case 1019: MotorDir(BREAK,BREAK);
//etwas warten bis der asuro wirklich steht
Msleep(200);
MotorDir (FWD,FWD); speed=150;
//und von vorne
distance=0;

break;
}

//helligkeitswerte der lichschranke auslesen
OdometrieData(data);

//wechsel linker sensor von weiss (low) auf schwarz(high)?
if ((status[0]==LOW) && (data[0]>TRIGGERLEVEL + HYSTERESIS))
{
status[0]=HIGH;
difference++;
distance++;
}

//wechsel linker sensor von schwarz (high) auf weiss(low)?
if ((status[0]==HIGH) && (data[0]<TRIGGERLEVEL - HYSTERESIS))
{
status[0]=LOW;
difference++;
distance++;
}

//wechsel rechter sensor von weiss (low) auf schwarz(high)?
if ((status[1]==LOW) && (data[1]>TRIGGERLEVEL + HYSTERESIS))
{
status[1]=HIGH;
difference--;
}

//wechsel rechter sensor von schwarz (high) auf weiss(low)?
if ((status[1]==HIGH) && (data[1]<TRIGGERLEVEL - HYSTERESIS))
{
status[1]=LOW;
difference--;
}

//zur sichreit: verhindern, dass der differenzzähler
//den erlaubten wertebereich verlässt
if (difference<-speed) difference=-speed;
if (difference>speed) difference=speed;

//status LED entsprechend der erkannten segmente aufleuchten lassen
//grün für links, rot für rechts
StatusLED(status[0]+status[1]*2);

//Zählerdifferenz passend auf die motoren verteilen
if (difference>0) MotorSpeed(speed-difference,speed);
else MotorSpeed(speed,speed+difference);
}
return 0;
}

[damaltor]

na ein long INT ist immer noch ein int... denke nicht das das ein prolem werden könnte, wenn du auf die kommazahlen im long abzielst.

[Sternthaler]

Hallo inka,
hier erst einmal eine Betrachtung der Rechengeschwindigkeit und der Zeit am Rad.

Gute Nachricht (oder doch nicht, da es keine Erklärung für dein Problem liefert).

Ich habe mal die AD-Wandlergeschwindigkeit nachgerechnet.
Folgendes ist da rausgekommen (ATmega8-Doku von der CD):

Ab Seite 193 in der Doku
- Wandlerzeit zwischen 65 und 260 us
- prescaler Clock 50-200 kHz für 10 Bit
> 200 kHz für < 10 Bit
- prescaler bits in ADPS im Register ADCSRC
- normale Wandlung in 13 ADC-Clock's
erste Wandlung in 25 ADC-Clock's
- bei 'free running' sofortiger Start einer weiteren Wandlung

- prescaler auf Seite 205
ADPS2-0 Faktor Frequenz bei 8MHz
--------------------------------
0 2 4000000
1 2 4000000
2 4 2000000
3 8 1000000
4 16 500000
5 32 250000
6 64 125000
7 128 62500

Es gibt 2 verschiedene Einstellungen des Prescalers in den Asuro-Funktionen.
- Init(): Der Prescaler wird auf 6 (Teiler 64) gesetzt.
- Encoder_Init(): Der Prescaler wird auf 7 (Teiler 128) gesetzt.

Für die weitere Betrachtung nun der 128-Teiler:

- ADC-Clock: 8Mhz / 128 = 62,5 kHz
- ADC-Conversion: 62,5 kHz / 13 Clocks = 4808 Wandlungen pro Sekunde
- 2 Räder: 4808 / 2 Seiten = 2404 Wandlungen pro Sekunde pro Rad
- Zeit pro Wandlung pro Rad: 1 / 2404 = 416 us


Für deine Hardware (22 Löcher/22 Hindernis) ergibt sich folgendes:
- 1 - Max. Asuro Geschwindigkeit: 50 cm/sec
- 2 - Rad-Umfang: ca. 12 cm
- 3 - Umdrehung / sec: 4,16
- 4 - Getriebe Rad/Odo-Scheibe: 1/5
- 5 - Odo-Scheiben-Umdrehung / sec: 5 * 4,16 = 20,8
- 6 - Löcher/Hindernis / Umdrehung: 44
- 7 - Messpositionen / sec: 44 * 20,8 = 916
- 8 - Mindestens 2 Messungen erforderlich: 1832 Messungen / sec
- 9 - Zeit pro Messung: 1 / 1832 = 546 us


Es sieht so aus, dass die AD-Wandlerzeit mit 416 us so eben ausreicht, um die Zeit am Rad mit 546 us so gerade abzudecken.
Da ich von maximaler Asuro-Geschwindigkeit ausgegangen bin, ist auf alle Fälle genug Zeit bei niedrigeren Geschwindigkeiten vorhanden.

Fazit: Eben keine Erklärung, warum es bei dir nicht geht.
Über die Asuro-LIB sollte es möglich sein, deine 22-Löcher-ODO-Scheibe so gerade noch zu bearbeiten.

Aber:
Das Messprogramm von mir schafft die 22-ODO-Scheibe definitiv nicht mehr.
Da in dem Programm pro AD-Kanal immer 2 Messungen gemacht werden, alle 4 Sensoren (Rad, Linie / Rechts, Links) permanent bearbeitet werden, vervierfacht sich die Messzeit der oben angegeben Zeit von 416 us auf 1664 us.
Außerdem enthält das Messprogramm 'künstliche' Pausen zwischen den einzelnen Messungen, so dass die Messzeit noch länger wird.

Fazit Messprogramm:
Alle Werte, die dir bei den Tests 2, 3 und 4 geliefert werden, sind falsch.
Somit sind auch die im Test 2 ermittelten Werte für die MY_ODO_xxx_VALUE_[L|R] nicht korrekt.
Deshalb würde ich jetzt sagen, dass deine Mühe, die Werte aus dem Messprogramm für mich zusammenzustellen, mit Sicherheit überflüßig war. Trotzdem war's ja ein Versuch wert.

Es bleibt somit wohl bei der Turn()-Funktion, in der ihr ja gerade die Variablen-Längen betrachtet. Von mir dazu später Kommentare.

Gruß Sternthaler

[damaltor]

ich denke aber, dass man das hier beachten sollte:
http://de.wikipedia.org/wiki/Abtasttheorem
die abtastfrequenz muss mindestens doppelt so groß sein wie die frequenz des zu messenden signales. also reicht die geschwindigkeit absolut nicht aus.

[inka]

hi sternthaler, damaltor,

wenn ich das richtig verstehe müsste bei

- Zeit pro Wandlung pro Rad= 416 us

die minimale zeit für die messung 2x so groß sein, also etwa 850 us. Bei 22 löchern ist die messzeit 546 us. Die maximale anzahl löcher wäre demnach 546x22/850=14.

ist das in etwa so?

[damaltor]

stop, andersrum:

ein tick des rades dauert ca 550 µs. um alle tiks zu erfassen darf eine wandlung MAXIMAL 275 µs dauern. man könnte versuchen, den takt des adc zu erhöhen, über 200 khz hinaus (adc prescaler, siehe datenblatt). dadurch würde die messung weniger genau (bei den extrem guten werten kein problem) aber es würde schneller gehen.

[inka]

naja,
mir geht es ja nicht darum das 22er rad zu erhalten, die genauigkeit eines 16er rades mit einer durchlich-lichschranke wäre auch noch gut genug - und ich wäre wieder - was den rest des asuro betrifft - etwas näher an de algemeinheit...
Also höchsten änderungen/anpassungen in der myasuro.h und keine so grundlegende änderungemn wie z.b. die takterhöhung. Wie macht man sowas überhaupt? Würde dann andere software überhaupt noch gehen?

Eine andere frage. Mit der durchlicht-lichschranke und deren guten werten - erübrigt sich die mysuro.h nicht zum größten teil?

[Sternthaler]

Hallo?? Was habe ich übersehen?
bei der Berechnung der Anzahl Messungen am Rad habe ich doch in der dort angegebene Zeile "- 8 - Mindestens 2 Messungen erforderlich: 1832 Messungen / sec" schon eine doppelte Messanzahl berücksichtigt.
Dann sind nach meinem Taschenrechner da 1 / 1832 also die angegeben 546 us schon für das Theorem berechnet.

@inka
Ob sich die myasuro.h deshalb erübrigt, möchte ich bezweifeln. Warte mal auf das Sommerlicht. Die Meswerte der ODO-Dinger gehen dann auf Werte um 50 runter. Differenzen zu der mickerigen LED-Beleuchtung kann man zwar mit dem Auge in einer EXCEL-Tabelle ausmachen, aber ich habe es noch nie geschafft daraus Tik's zu ermitteln.

Gruß Sternthaler

[damaltor]

oh oh das habe ich übersehen - sorry.

die takterhöhung (die sich ja damit erübrigt hat) bedeutet folgendes:
der adc braucht einen takt, am besten zwischen 50 und 200 kHz. dazu wird aus dem systemtakt mithilfe eines prescalers ein takt generiert, der prescaler ist wählbar. gwht die frequenz über 200 khz raus, wird die messung schneller, aber eben auch ungenauer.

[inka]

@sterthaler,
ok, im sommer ist ja vieles anders :-)

wie mache ich es aber jetzt mit der ermittlung der werte aus den tests 2-5? Mit deinem tollen programm geht es ja nun nicht, wobei beim go es ja noch zu funktionieren scheint...
gibt es eine möglichkeit die werte aus der myasuro.h bei der verwendung der lib 2.7 zu umgehen? Oder schiesse ich hier wieder mal übers ziel hinaus?

[Sternthaler]

Hallo inka,
im Moment wüsste ich auch nicht, wie du an sinnvolle Werte kommst. (Ich krame mal bei mir nach einem schnellen Messprogramm)
Du hast ja schon den Ansatz gewählt, dass du einfach versucht hast irgendwelche Werte einzutragen in der myasuro.h.

Ich habe gerade nochmal deine Messwerte aus diesem Post (https://www.roboternetz.de/phpBB2/viewtopic.php?p=323107#323107) von dir nach Excel geholt. Sie sehen meiner Meinung nach nicht besonders gut aus.
Deine Daten von hier (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=322593#322593) sehen da viel besser aus.

Über ein Ziel hinausschiessen ist beim Asuro nicht möglich ;-). Pech gehabt, du must weiter am Ball bleiben und nach Lösung dieses Problems, für alle die an diesem Thread beteiligt sind, rote Zahnräder mit 22 Löchern machen. ;-)

Kannst du mal von deinem letzten Programm (von hier) (https://www.roboternetz.de/phpBB2/viewtopic.php?p=323307#323307) mal die Datei *.lss posten.
Darin ist dann das komplette Programm in Assembler zu finden. Ich will mal sehen, was für eine Mathematik (char, int, float) in der Funktion Turn() und auch Go() vom Compiler eingesetzt werden. Hier scheint es ja irgendwie Unterschiede zu geben.


@damaltor
irgendwie bringst du mich jetzt aber auf eine Idee.
In der Encoder_Init() ist der Prescaler ja (warum auch immer) auf 128 gesetzt worden. Da die INT-Funktion für den ADC aber in der LIB nur die oberen 8 Bit nutzt, sollte es auf alle Fälle möglich sein den Prescaler zu ändern.
Mindestens 64 ist möglich. Wie oben angegeben ist der ADC-Takt dann ja erst bei 125 kHz
Und da die Genauigkeit ja nur mit 8 Bit genutzt wird, kann man bestimmt auch auf einen Prescaler von 16 mit einer Frequenz von 500 kHz runter-/hochgehen. inka, du kannst nochmal 22 Löcher dazubohren.

Gruß Sternthaler

[damaltor]

ist nen versuch wert denk ich... zumindest mal testen. und genau genug denke ich sollte das sien, oder?

[inka]

@sternthaler
also auf die schnelle - die anderen sachen dauern ein bischen - nochmal 22 löcher an dem umfang bohren, da bricht mir - dem feinwerktechniker - der kalter schweis aus :-)
@damaltor
das thema hat sich etwas vom sterthalers schönem programm entfernt - sollte/könnte man nicht daraus einen getrennten thread machen?

[inka]

so, jetzt habe ich ein paar daten zusammen. mit diesem programm aus dem asuro band II habe ich die daten aufgenommen:

//* -------- Programm zum Loggen der Odometriedaten ----*/

#include "asuro.h"
#include "inka.h"
#include <string.h>
#include<stdio.h>

int main(void) {
unsigned int data[200][2];
char c[12];
int i;

Init();
WaitforStart();

//motoren vorwärts
MotorDir(FWD,FWD);
MotorSpeed(160,160);
//warten bis motoren drehzahl erreicht haben
Msleep (1000);
//odo-werte einlesen
for (i=0; i<200;i++) {
OdometrieData(data[i]);
}
//motoren stop
MotorSpeed(0,0);
//formatiert ausgabe odo-werte
for (i=0;i<200;i++){
sprintf(c,"%4d\t%4d\n\r",data[i][0],data[i][1]);
SerWrite(c,12);
}
while(1);
return 0;
}
so sehen die daten der 22er scheiben aus:

35 22
25 21
31 26
20 24
19 31
20 32
21 71
28 407
29 617
43 643
313 624
599 501
646 273
644 43
485 28
125 37
33 22
24 23
27 21
20 22
31 27
21 25
27 31
28 32
32 86
111 438
478 628
626 649
635 626
637 490
475 237
135 39
32 28
26 33
27 22
21 23
25 22
21 22
35 29
28 28
39 39
224 222
546 586
631 673
632 648
530 500
194 252
41 38
26 27
30 28
22 21
21 31
26 21
26 30
35 25
58 27
428 35
600 62
632 409
626 637
518 659
198 549
32 351
31 66
24 30
27 29
24 22
31 26
28 21
34 33
172 22
500 31
634 26
647 29
588 39
311 164
39 501
28 641
24 655
26 596
21 470
27 230
24 36
35 32
36 25
244 27
536 21
652 30
653 22
633 29
427 25
48 28
39 38
24 174
23 536
20 643
20 658
25 639
24 564
31 366
38 86
301 34
575 25
669 27
656 21
492 34
82 23
29 31
29 28
22 33
30 102
20 476
28 628
24 623
26 493
36 227
128 39
496 28
642 24
647 26
518 21
167 26
32 23
25 33
25 26
20 38
24 48
20 401
35 625
28 634
46 507
314 280
586 50
638 29
601 31
330 23
34 21
31 24
24 21
23 27
21 24
20 36
25 32
24 71
34 386
48 630
437 685
634 696
597 645
303 503
34 289
30 38
22 31
24 25
18 22
24 24
20 20
23 26
26 22
36 30
250 28
571 39
625 76
417 452
44 641
28 655
31 578
20 400
20 161
22 32
20 31
27 24
26 22
38 24
165 22
547 27
653 24
649 32
455 34
57 212
33 535
24 648
27 646
20 587
27 423
22 160
24 42
30 27
34 29
217 21
561 20
648 24
495 22
93 29
28 27
24 37
24 70
19 447
23 597
das ist der letzter code des versuches mit go und turn. Mit der 3fachen ausführung des turn erreiche ich fast 90°, wie ihr sehen könnt, experimentiere ich weiter:-)

#include "asuro.h"
#include "inka.h"
int i;

int main (void)

{

Init();
WaitforStart();

EncoderInit ();

for (i = 0; i < 4; i++)
{
StatusLED(YELLOW);
Go(100,150);
StatusLED(GREEN);
Msleep(500);

Turn(75,150);

Turn(75,150);

Turn(75,150);

StatusLED(RED);
Msleep(500);
}
return 0;
}


Kannst du mal von deinem letzten Programm (von hier) mal die Datei *.lss posten.
Darin ist dann das komplette Programm in Assembler zu finden. Ich will mal sehen, was für eine Mathematik (char, int, float) in der Funktion Turn() und auch Go() vom Compiler eingesetzt werden. Hier scheint es ja irgendwie Unterschiede zu geben.

*.lss habe ich leider nicht gefunden, arbeite mit avr-studio: eep, elf, hex, o, o.d, zumindest i projektverzeichnis...

ansonsten, rote zahnräder habe ich genug, wer möchte ein paar? ein problem wird die lichtschranke...:-(

[damaltor]

thread getrennt; 28.10.07; 22:20h

gute idee =)

Inka: wenn du den Titel des Threads ändern möchtest, dann klicke bei deinem ersten Beitrag auf edit.

[radbruch]

Hallo

Die maximale Wandlungsgeschwindigkeit für den ATMega-ADC habe ich auch schon gesucht und gefunden:

https://www.roboternetz.de/phpBB2/viewtopic.php?t=33070

Hier die Anwendung:

https://www.roboternetz.de/phpBB2/viewtopic.php?t=33228

Schneller als der bas-Bildaufbau werden die Löcher der Codescheibe wohl nicht rotieren...

Gruß

mic

[Sternthaler]

Hallo radbruch,
na da soll mich doch der Schlag treffen, dass die Genauigkeit so gut ist, wie du in deinen Messungen rausbekommen hast:

Bei der Schrittweisen Erhöhung der Abtast- und Auslesegeschwindigkeit habe ich übrigens keine nennenswerten Fehllesungen festgestellt. Bei der verwendeten linksbündigen Darstellung des Ergebnisses betrug die Abweichung bei der Messung einer 1,5V-Batterie nur 0,02V gegenüber einer langsamen Messung mit prescaler /64.
Das hätte ich nie erwartet, dass dann noch immer ein Ergebnis rauskommt, bei dem man dann ja ca. 75 (1,5V Batterie / 0,02V Fehler = 75) verschiedene Werte bekommen würde.

Als Konsequenz für inka, ist dann ja ein Bohrer zu finden, der ungefähr einen Durchmesser von 0,031415 mm hat, damit er ca. 2613 Löcher bohren kann ;-)

Gruß Sternthaler

P.S.: Da hast du aber wieder eine klasse Anwendung zusammengebaut.

[damaltor]

ROFL.. =) inka, viel spaß! ;) da haste dann nach 16 umdrehungen des zahnrades einen überlauf in der ticks-zähl-variable... aber an sich hätte ich das nicht gedacht, muss ich ehrlich sagen!

[inka]

also ich bin schon froh, wenn ich es - mit euerer hilfe - mit den 22 löchern zum laufen krieg:-), die 0,03 löcher kriegt man ja kaum mit einem laser hin :-(
welches file ist es nun in dem beim compilieren mit AVR-Studio die übersetzung in den maschinencode gespeichert wird?

[damaltor]

wenn du das assembler-listing meinst, es hat die endung .lss oder .lst.
maschinencode ist im .hex-file!

[radbruch]

Hallo

So wirklich wissenschaftlich sind meine Messungen ja nicht, da ist noch die Frage offen, wieso mein ADC schneller wandelt als im Datenblatt angegeben (13 Zyklen).

Anstatt die Anzahl der Löcher zu erhöhen, könnte man das Rad auch schneller rotieren lassen. Entweder indem man die gelochte Scheibe direkt auf die Motorwelle klebt (wie als Aufbauvariante schon vorgesehen) oder indem man ein kleines Coderad mit wenigen Löchern zusätzlich anbaut und antreibt.

@inka:
Mal eine andere Idee: Warum wandelst du eigentlich die Werte mit dem ADC um? Würde es nicht ausreichen, einfach nur den Pin auf High/Low abzufragen? So Pi*Daumen würde ich meinen, Werte > 600 sind bestimmt ein Pegel, der als High erkannt wird, Werte <50 wiederrum ergibt wohl ein Low.

Ansonsten wäre meinerseits noch anzumerken: Beneidenswerte Werte in der Tabelle, scheint der rote Kunststoff durch? (Wenn ja, Alufolie drüberkleben), ist die IR-LED in der Sättigung bzw. bringt eine andere LED noch eine Erhöhung der Werte?

Da ich die erweiterte Lib nicht verwende, kann ich zu den Go/Turn-Effekten nichts sagen.

Gruß

mic

[damaltor]

das abfragen der pegel denke ich wird nichts helfen: der adc eingang ist so hochohmig, dass immer ein high pegel gemessen wird. ist aber nur ne schätzung, da kein großer umbau erforderlich ist sollte man das auf jeden fall mal versuchen.

[inka]

@radbruch:
nein der roter kunststoff ist lichtundurchlässig, ich habe noch im inneren bereich, also von innen bis zu den löchern, wo ursprünglich vier größere löcher waren weisse selbstklebende folie aufgeklebt. Also quasi weisse felgen...
andere lED´s? ich denke die beiden odo-sensoren sind aufeinander "abgestimmt" - oder ist es so wie damals bei den liniensensoren, wo man/du(?) damals die IR-LED eingesetzt hat?

@damaltor:
was müsste ich da umbauen oder messen? Du kannst doch so schön präzise und prägnant erklären - ich denke da immerb noch an das "das ist ein nein" von dir...

[radbruch]

...der adc eingang ist so hochohmig, dass immer ein high pegel gemessen wird
Einspruch! Die ODO-Sensoren T9/10 bilden mit den Widerständen R14/15 Spannungsteiler, da ist es gut wenn der Eingang PC2/3 hochohmig ist. Übrigens sind 50 bei 5V Reverenzspannung ca. 0,24V (5V/1024*50) und 600 sind ca. 2,9V. Das wird dann mit dem "High" etwas knapp, vielleicht würde zusätzlich der interne PullUp helfen. Oder 20k für R14/15 anstelle der 10k:

r(T9/10) = 5V/2,9V*10k-10k = 7,2K

Spannung an den Pins bei R14/15=20k:

U(Pin PC2/3) = 5V*20k / 27,2k = 3,6V.

Das dürfte wohl high sein. Messen kann man das bei "Loch" zwischen Pin 25/26 und GND. Oder eben mehr Licht...


...oder ist es so wie damals bei den liniensensoren, wo man/du(?) damals die IR-LED eingesetzt hat?
Ja, ich vermute, die Odo-Transistoren verhalten sich ähnlich.

Gruß

mic

[damaltor]

haste recht, der spannungsteiler müsste es retten.

inka, folgendes ist (war) gemeint: bei folgender schaltung

vcc -- (beliebig großes R, zB fotowiderstand) - Analogpin des meg8

also vcc ist über einen widerstand belibiger größe mit dem analogpin verbunden - wird grundsätzlich 1023 gemessen. der eingang des prozessors ist sehr hochohmig, es fliesst also (fast) kein strom. und wenn kein strom fliesst, kann auch keine spannung am widerstand abfallen, dshalb wird die volle spannung am pin des avr gemessen.

[inka]

Einspruch! Die ODO-Sensoren T9/10 bilden mit den Widerständen R14/15 Spannungsteiler, da ist es gut wenn der Eingang PC2/3 hochohmig ist. Übrigens sind 50 bei 5V Reverenzspannung ca. 0,24V (5V/1024*50) und 600 sind ca. 2,9V. Das wird dann mit dem "High" etwas knapp, vielleicht würde zusätzlich der interne PullUp helfen. Oder 20k für R14/15 anstelle der 10k:
r(T9/10) = 5V/2,9V*10k-10k = 7,2K

Spannung an den Pins bei R14/15=20k:

U(Pin PC2/3) = 5V*20k / 27,2k = 3,6V.

Das dürfte wohl high sein. Messen kann man das bei "Loch" zwischen Pin 25/26 und GND. Oder eben mehr Licht...



die widerstände R14/R15 sind ja schon 20k!, sollte ich sie versuchsweise durch 10k ersetzen?

[damaltor]

probiere es... tip: klemme einen weiteren 20k widerstand parallel, dann brauchst du nicht löten...

[radbruch]

Hallo


die widerstände R14/R15 sind ja schon 20k!
Grummel, tatsächlich, und da ich nun meinen asuro rausgekramt habe muss ich leider gestehen: Ich habe die Linien- und Odosensoren verwechselt. Peinlich, peinlich (ist aber auch im Schaltplan nicht gekennzeichnet). Am Besten streicht ihr alles oben beschriebene...

Abgesehen davon scheint mir das direkte Einlesen der Pins ohne ADC immer noch sinnvoll. Allerdings wird's dadurch a: kompliziert und b: vermutlich nicht besser. Also vergessen wirs...

Gruß

mic

[damaltor]

also ohne einen spannungsteiler macht das direkte einleden zu 99% KEINEN sinn. ist da jetzt einer oder nicht?

bin grad mitm pda online und hab keinen schaltplan zu hand...

edit: das direkte abfragen ist eigentlich völliger quatsch. der pin muss um einen eindeutigen pegel zu haben, auf high bzw low gezogen werden. auf high geht er, über den fotowiderstand (unabhängig von dessen aktuellem leitwert, der widerstand wird nicht unendlich.) aber auf low? sofern der pin nicht wirklich über einen widerstand mit masse verbunden ist, wird das nix, gar nix.

[Sternthaler]

So, da bin ich wieder. (Inbetriebnamewoche ist jetzt erst mal vorbei. Montag geht's weiter)

Erst mal Lob an Inka. Die zuletzt geposteten Messdaten und das dazu passende Programm liefern ja excelente Daten. (Weitere Bohrungen sind wohl doch nicht notwendig ;-) )

Um nochmal auf die *.lss-Datei zu kommen.
Im AVR-Studio wird die erzeugt, wenn man im Menü "Project" den Punkt "Configuration Option" anklickt. Und in der folgenden 'Kiste' unter 'General' unten die drei Klicker 'Create Hex File', 'Generate Map File' und 'Generate List File' AN macht.
Es müsste der Klicker 'Generate Map File' sein, der die *.lss-Datei erzeugt.
Hier wäre es total hilfreich, wenn du ein NICHT funktionierendes Programm mal sendest und das oben stehende Programm mit den 3-fachen Turn()-Aufrufen zur Gegenkontrolle.

So, das erst mal nur in Kürze.
Gruß Sternthaler

[radbruch]

Hallo


das direkte abfragen ist eigentlich völliger quatsch.
Danke für die ehrliche Einschätzung. Das man den Pin natürlich entsprechend beschalten muss ist ja wohl klar. Übrigens funktioniert z.B. das direkte (ohne ADC) Einlesen bei den Tastern problemlos:

http://www.arexx.com/forum/%76iewtopic.php?p=1321&highlight=#1321

Gruß

mic

[damaltor]

hmm hab grad den schaltpan nocmal angesehn, und muss mich korrigieren.

die beiden pins sind eigentlich schon entsprechend beschaltet, sie gehen über 4k7 an VCC. wenn der transistor voll durchschaltet, würde eine null zu lesen sein, sonst eine eins.

radbruch: streiche meinen letzten post =)

evtl könnte es helfen, den widerstand (deutlich?) zu vergrößern, so dass es reicht wenn der transistor "halb" durchschaltet. aber an sich sollte das wohl möglichsein. den internen pullup sollte man jedoch deaktivieren (PORTx) umm es dem transistor nicht zu schwer zu machen.

[Sternthaler]

Mal was zum Einlesen pur über den Port-PIN.

Es sollte auf alle Fälle bei inka funktionieren.
Auf Seite 237 der ATmega8-Doku sind die Spannungspegel beschrieben, die den Eingang als 0 oder 1 unterscheiden.
-- sicheres LOW bei U-Pin < 0,2*VCC => 1,0 Volt
-- sicheres HIGH bei U-Pin > 0,6*VCC => 3,0 Volt

Die zuletzt geposteten Daten von inka liefern umgerechnet in eine Spannung, Werte von 0,09 Volt bis 3,4 Volt.

In Excel 'übersetzt' ergibt dies folgende Signalverläufe:
Die Werte, die zwischen den 'sicheren' Pegeln liegen können vernachläßigt werden, da es a) relativ wenige sind, und b) der Pegel in der CPU dann ja irgendwo liegt. Aber er ist abhängig vom Vorgängerwert, und wird somit nicht flattern.
P.S.: Die internen Pull-up's sollten NICHT benutzt werden, da dadurch der Gesamtwiderstand reduziert wird. Nicht gut.

Gruß Sternthaler

[damaltor]

hmm die spitzen sind sehr schmal. aber einen versuche sollte es auf jeden fall wert sein.

[inka]

-- sicheres LOW bei U-Pin < 0,2*VCC => 1,0 Volt
-- sicheres HIGH bei U-Pin > 0,6*VCC => 3,0 Volt

Die zuletzt geposteten Daten von inka liefern umgerechnet in eine Spannung, Werte von 0,09 Volt bis 3,4 Volt.

P.S.: Die internen Pull-up's sollten NICHT benutzt werden, da dadurch der Gesamtwiderstand reduziert wird. Nicht gut.


es ist immer wieder erstaunlich was ich alles nicht weiss. :-( Das macht einen richtig hilflos nicht einmal einen ansatz zu haben wo man suchen soll. Und wenn ihr es schon gefunden habt, weiss ich wiederum nicht was ich damit machen soll/kann...
Jetzt habe ich immerhin nach dem begriff pull-up im RN-wissen suchen können, was bedeutet aber das "Nicht gut"?

[radbruch]

Das "nicht gut" bedeutet, dass der interne PullUp den Spannungsteiler ungünstig beeinflussen würde. Dann würde der high-Pegel nicht mehr erreicht.

Ich versuche es nochmal, diesmal mit R18/20(4k7). Die sind in Reihe zu T11/12 und bilden den Spannungsteiler für die ADC-Eingänge. Wenn man nun die internen PullUp einschaltet, ergibt sich durch die Parallelschaltung zu R18/20 ein geringerer Gesamtwiderstand und damit kleinerer Spannungsabfall. Das müsste für den gewünschten High-Pegel günstiger sein als ohne PullUp. Oder irre ich mich da? Natürlich muss auch PD7 high sein, sonst wäre der Spannungsteiler auch gestört und die ODO-LEDs würden nicht leuchten.

Die schmalen Spitzen kommen von den kleinen Löchern. Optimal wäre wohl ein 1:1 Verhältniss. Aber das wird man wohl nur mit Schlitzen anstelle der runden Löcher erreichen. So sehen auch die "profesionellen" Codescheiben in Mäusen oder Druckern aus. Alternativ könnte man vielleicht eine Blende einbauen die das "Sichtfeld" der Sensoren auf einen Schlitz reduziert.

[damaltor]

es würde nur noch der high-pegel erreicht, oder? Pull-UP?

wenn der strom über ten transistor abfliesst, hat der pin einen LOW-pegel. wenn man ihn also (ohne den adc) einliesst, wird eine null ausgelesen. wenn der transistor sperrt, wird über den widerstan strom auf den pin gegeben - und es kann eine eins, also high ausgelesen werden. der pullup ist ein widerstand der im prozessor eingebaut ist, und den pin mit vcc verbindet. normalerweise nutzt man ihn, um sich den externen pullupwiderstand zu sparen. hier ist er jedoch schon eingebaut - dass heisst, es würde deutlich mehr strom zum pin fliessen als notwendig, und der transistor müsste wirklich voll durchschalten um einen low-pegel zu erzeugen. weisst du jetzt was wir meinen?

[radbruch]

Nein, ich weis nicht, was du meinst.

Der Transistor kennt nicht nur Sperren oder Durchschalten, der ändert seinen "Widerstandswert" stufenlos je nach Beleuchtung. Er bildet mit dem 4k7-Widerstand einen Spannungsteiler. Dieser liefert eine Teilspannung die im selben Verhältniss zur Gesamtspannung steht wie der Teilwiderstands des Transistors zum Gesamtwiderstand. Wenn nun der (übrigens recht hochohmige) interne PullUp aktiviert wird, ergibt sich eine Parallelschaltung zum 4k7 Widerstand, der Widerstand in diesem Teil des Spannungsteilers sinkt. Nun ist der Gesamtwiderstand im Spannungsteiler kleiner, der Widerstand am Transistor bleibt aber gleich (eigentlich steigt der Strom ja etwas) und es ergibt sich eine höhere Spannung am Pin.

[damaltor]

dich meinte ich doch nicht =) ich bezog mich auf inkas frage weiter oben.

aber eben das habe ich ja auch oben drüber gesagt, wird der pullup zugeschaltet ist die spannung am pin höher, und es wir schwerer den low pegel zu erreichen, und nicht wie du gesagt hast, der high pegel würde nicht mehr erreicht. und wie ich auch gesagt habe, müsste der transistor dann stärker durchschalten, also einen geringeren widerstandswert haben... ich denke wir meinen das gleiche, oder?

[radbruch]

Ich denke schon und hoffe, dass wir inka nun nicht zu sehr verwirrt haben.

[Sternthaler]

Ein Bild mal dazu. (Ach du meine Güte, hätte ich das mal mit dem Bleistiftt gemalt, 1/4 der Zeit hätte es wohl nur benötigt.)

Ansatz sind die Messdaten von inka.
1) Der kleinste Wert ist 18
2) Der größte Wert ist 696

Umrechnen in die Spannung am Prozessor-Pin:
5 Volt / 1023 * ADC-Wert
1) 5 Volt / 1023 * 18 = 0,088 Volt
2) 5 Volt / 1023 * 696 = 3,41 Volt

Die Spannung am Prozessor-Pin entspricht der Spannung über dem Foto-Transistor. Somit muss die restliche Spannung von den 5 Volt Versorgung am Widerstand R18 abfallen.
1) 5 Volt - 0,088 Volt = 4,912 Volt
2) 5 Volt - 3,41 Volt = 1,59 Volt

Entsprechend fließt dann folgender Strom durch diesen Widerstand R18
1) 4,912 Volt / 4,7 kOhm = 1,045 mA
2) 1,59 Volt / 4,7 kOhm = 0,338 mA

Da der Strom dann ja auch durch T11 muss, kann der Widerstand vom Transistor nun endlich berechnet werden. (U [Transistor=U-Pin] / I [R18])
1) 0,088 Volt / 1,045 mA = 84 Ohm
2) 3,41 Volt / 0,338 mA = 10088 Ohm


Und nun den Pull-Up-Widerstand parallel zum 4,7 kOhm.
Leider 2 Möglichkeiten, da die Angabe in der ATmega8-Doku (Seite 237 I/O-Pin Pull-up Resistor) von 20 bis 50 kOhm schreibt.

Nun die Spannung am AD-Eingang, wenn wir die beiden oben berechneten Widerstände vom T11 nutzen:
FALL 1 : 20 kOhm parallel zu 4,7kOhm = 3805 Ohm
1) 5 Volt / (3805 Ohm + 84 Ohm) * 84 Ohm = 0,108 Volt
2) 5 Volt / (3805 Ohm + 10088 Ohm) * 10088 Ohm = 3,63 Volt

FALL 2 : 50 kOhm parallel zu 4,7kOhm = 4296 Ohm
1) 5 Volt / (4296 Ohm + 84 Ohm) * 84 Ohm = 0,096 Volt
2) 5 Volt / (4296 Ohm + 10088 Ohm) * 10088 Ohm = 3,51 Volt

Und wie man nun sehen kann, habe ich mich mit den Pull-Up's vertan.
Die Spannung wird höher, je niedrieger der Pull-Up-Widerstand ist. Somit wird der minimale Erkennungs-Pegel von 3 Volt noch weiter überschritten, und es ist doch sinnvoll die Pull-Up's einzuschalten.

Es lohnt sich immer seinen eigen Quatsch mal nachzurechen.

Gruß Sternthaler


@damaltor
Ich kann keinen Upload mehr machen, da meine 3 MB voll sein sollen. Kannst du da was machen?
Aus diesem Grund doch kein Bild von mir. Und das obwohl ich das so toll gemalt habe ;-)

[EDIT] Ach du meine Güte, seit ihr schnell mit dem Schreiben und Erklären. Mittlerweile habt ihr schon 5 Posts eingetragen und ich sitze hier und versuche Bildchen zu malen :-s

[damaltor]

klar, schicks per email, ich hängs dann an... muss mal sehen ob ich deinen counter irgendwie resetten kann.

[Sternthaler]

Danke damaltor, die Mail ist unterwegs.

Und nun noch eine Frage an radbruch:

Die schmalen Spitzen kommen von den kleinen Löchern.
(Alle anderen schauen jetzt bitte mal weg)
Bevor ich hier nun auch daneben liege. Sollte es nicht genau andersrum sein?
Dunkel = Kein Loch = Hohe Spannung => HIGH-Pegel
Hell = Loch = Niedrige Spannung => LOW-Pegel

Gruß Sternthaler

[radbruch]

Ihr könnt gerne alle zuschauen. Ich bin doch nicht unfehlbar. Im Datenblatt (http://www2.produktinfo.conrad.com/datenblaetter/150000-174999/153470-da-01-ml-IR-Receiver_LPT80A_de-en.pdf) des Transistors (LPT 80 A, NPN-Silizium-Fototransistor, z.b.: C (http://www.conrad.de/goto.php?artikel=153470)) steht was von "Dunkelstrom" im nA-Bereich. Das ist dann wohl "Hochohmig" und bedeutet: die Spannung am Pin ist im Dunkeln am höchsten. Auch ich kann mich mal irren. *lol*

Erklärungsversuch2 für die Spitzen:

Weil die erreichten 3,6V näher am high-Pegel liegen als die ebenfalls erreichten 0,09V am low ergibt sich eine Häufung bei low? Mich würden mal die abgedeckt/freieSicht-Werte interessieren. Schöne Restnacht noch ...

mic

[inka]

Ich denke schon und hoffe, dass wir inka nun nicht zu sehr verwirrt haben.
naja, ich versuche mich mal durchzubeissen. Was ich noch nicht verstehe ist das mit dem (im prozessor?) eingebauten pull-up. Ich denke ob der nun benutzt wird oder nicht, darauf habe ich doch gar keinen einfluss, oder?

[inka]

Mich würden mal die abgedeckt/freieSicht-Werte interessieren. Schöne Restnacht noch ...
mic
meinst du die werte, die ich bei 22 löchern messen würde mit der von dir vorgeschlagenen blende an der (sende)diode?

[damaltor]

auf die pullups hast du natürlich einfluss. mit den datenregistern kannst du ja schon umgehen =)

wenn ein pin aus EINGANG gestellt ist, also das entsprechende bit im DDRx register 0 ist, kannst du mithilfe des PINx registers den wert einlesen. soweit klar. das register PORTx, welches ja eigentlich dazu da ist, um daten auf den ausgang (!) zu schreiben, wird jetzt zweckentfremdet: hat das register PORTx bei einstellung auf eingang eine gesetzte 1, so ist dieser pin über einen hochohmingen widerstand mit VCC verbunden.

hier im anhang noch sternthalers bild:

[inka]

ok, heist also die pull-ups sind standarmässig abgeschaltet. Ich müsste also zusätzlich, VOR der verwendung der OdometrieData() funktion (der code stammt aus der adc.c)
00221 void OdometryData (
00222 unsigned int *data)
00223 {
00224 int ec_bak = autoencode; // Sichert aktuellen Zustand
00225
00226 /*
00227 Autoencode-Betrieb vom ADC-Wandler unterbinden.
00228 */
00229 autoencode = FALSE;
00230 /*
00231 Vorbereitung zum lesen der Odometrie-Sensoren.
00232 */
00233 DDRC &= ~((1 << PC0) | (1 << PC1)); // Port auf Input=>Back-LEDs gehen aus
00234 ODOMETRIE_LED_ON; // Odometrie-LED's einschalten
00235
00236 /*
00237 Linken Odometrie-Sensor lesen
00238 */
00239 ADMUX = (1 << REFS0) | WHEEL_LEFT; // Referenz mit externer Kapazitaet
00240 ADCSRA |= (1 << ADSC); // Starte AD-Wandlung
00241 while (!(ADCSRA & (1 << ADIF))) // Ende der AD-Wandlung abwarten
00242 ;
00243 ADCSRA |= (1 << ADIF); // AD-Interupt-Flag zuruecksetzen
00244 data [0] = ADCL + (ADCH << 8); // Ergebnis als 16-Bit-Wert
00245
00246 /*
00247 Rechten Odometrie-Sensor lesen
00248 */
00249 ADMUX = (1 << REFS0) | WHEEL_RIGHT; // Referenz mit externer Kapazitaet
00250 ADCSRA |= (1 << ADSC); // Starte AD-Wandlung
00251 while (!(ADCSRA & (1 << ADIF))) // Ende der AD-Wandlung abwarten
00252 ;
00253 ADCSRA |= (1 << ADIF); // AD-Interupt-Flag zuruecksetzen
00254 data [1] = ADCL + (ADCH << 8); // Ergebnis als 16-Bit-Wert
00255
00256 /*
00257 Autoencode-Betrieb vom ADC-Wandler wiederherstellen.
00258 */
00259 autoencode = ec_bak;
00260 }
irgendwo eine anweisung unterbringen die in das Register PORT 0 bzw. PORT 1 eine 1 reinschreibt und damit den eingang PC0 bzw PC1 hochohmig macht? Passiert aber nicht so etwas schon in der codezeile 233?

ganz was anderes. Im code oben steht OdometryData, in diesem programm z.b. steht OdometrieData

//* -------- Programm zum Loggen der Odometriedaten ----*/

#include "asuro.h"
#include "inka.h"
#include <string.h>
#include<stdio.h>

int main(void) {
unsigned int data[200][2];
char c[12];
int i;

Init();
WaitforStart();

//motoren vorwärts
MotorDir(FWD,FWD);
MotorSpeed(160,160);
//warten bis motoren drehzahl erreicht haben
Msleep (1000);
//odo-werte einlesen
for (i=0; i<200;i++) {
OdometrieData(data[i]);
}
//motoren stop
MotorSpeed(0,0);
//formatiert ausgabe odo-werte
for (i=0;i<200;i++){
sprintf(c,"%4d\t%4d\n\r",data[i][0],data[i][1]);
SerWrite(c,12);
}
while(1);
return 0;
}
wie passt das zusammen?

[radbruch]

Hallo

Ich hoffe, ich verzapfe nicht wieder Unsinn:


DDRC &= ~((1 << PC0) | (1 << PC1)); // Port auf Input=>Back-LEDs gehen aus
PORTC |= ((1 << PC0) | (1 << PC1)); // PullUps einschalten für PC0 und PC1
ODOMETRIE_LED_ON; // Odometrie-LED's einschalten


Das Setzen von PD7 ist so in asuro.h eingebaut:


#define ODOMETRIE_LED (1 << PD7)
#define ODOMETRIE_LED_ON PORTD |= ODOMETRIE_LED
#define ODOMETRIE_LED_OFF PORTD &= ~ODOMETRIE_LED


Gruß

mic

[inka]

aha,
jetzt habe ich was dazugelernt, danke mic



was ist aber mit Odometrie contra Odometry? Ich habe den oben dargestellten code mit avr-studio mit der neuen lib 2.7 compiliert, keine fehlermeldungen, die daten die ich weiter oben geliefert habe wurden auch damit aufgenommen, es funktioniert also.
Ist es nun egal, ob englisch, oder deutsch, oder ist da irgendwo ein "=" zeichen eingebaut???

[Sternthaler]

Hallo inka, und auch alle anderen.

Ja, es ist egal wie du die Funktion schreibst.
Irgendjemand hatte sich mal darüber ausgelassen, das der Original-Name der Funktion 'irgendwie' falsch geschrieben sei. (Hätte von mir sein können, da ich auch immer gerne Erbsen zähle.) m.a.r.v.i.n hat dann in der Asuro-LIB ein #define für den alten Namen angelegt, und die Funktion umbenannt (oder anders herrum). Diesen Define findest du in der asuro.h aus der LIB.

@radbruch
Volle Zustimmung (Erbsen lassen grüßen. Ich warte auf reichliche Retourkutschen. Ebsensuppe ist stets was für mich. Lecker, lecker ;-) )

@inka
Das mit der Funktion OdometryData() kannst du dir aber abschminken, wenn du auf den von radbruch vorgeschlagenen Weg gehen willst. Dann genau soll ja nicht mehr der ADC-Wandler zum Einlesen benutzt werden, sondern nur der der PINx-Status ermittelt werden.
Wie das nun 'in Summe' zu machen ist? Upps, ich bin noch in der Firma, da kann ich so was nicht.

Gruß Sternthaler

[inka]

also ich werde wohl zu den gut funktionierenden 8löcher scheiben zurückkehren, evtl. später nochmal die 22er probieren. hier sind noch einmal die gemessenen odo-werte:

475 850
881 853
883 834
889 802
890 745
889 672
891 572
886 419
892 259
888 68
892 35
885 33
867 29
761 29
544 25
242 33
37 23
28 27
28 22
24 22
31 25
20 22
21 25
19 22
20 31
22 21
19 23
23 21
19 22
30 26
20 24
23 27
21 25
22 34
27 27
27 31
33 32
39 38
263 125
556 355
776 548
871 697
887 781
886 821
891 828
885 830
887 833
880 829
883 832
880 828
879 831
882 828
878 831
884 832
880 834
884 839
869 837
805 843
628 842
319 848
39 845
32 850
26 844
27 815
22 767
31 681
21 563
23 398
20 214
20 51
22 32
20 31
23 27
21 24
28 26
20 22
23 25
22 22
25 31
29 22
30 23
42 22
251 22
556 24
755 22
856 25
879 21
886 31
883 21
887 23
880 21
883 22
878 26
882 24
880 28
882 26
885 36
884 32
890 39
888 184
894 465
886 655
851 775
716 812
446 825
104 824
32 829
27 827
27 828
22 831
31 828
20 833
23 832
19 838
20 838
22 844
20 848
23 851
20 855
29 852
20 847
23 813
20 763
24 678
28 555
29 402
38 208
168 43
528 35
767 29
864 30
885 25
892 31
892 22
895 23
890 21
893 22
885 25
889 22
888 25
887 22
889 27
886 23
889 23
888 22
891 23
880 26
835 24
693 29
447 27
149 38
35 32
28 47
28 221
24 457
31 628
21 747
23 804
20 824
21 822
22 826
21 824
24 823
21 825
25 821
22 825
30 821
24 827
27 825
32 831
39 832
230 837
533 843
750 843
847 850
864 848
873 842
879 811
877 762
881 683
876 560
879 407
872 222
879 49
880 36
881 30
886 35
885 26
890 31
880 24
830 24
666 25
380 24
47 25
28 22
26 27
26 22
22 23
24 22
20 24

und beim 2ten asuro, der jetzt dran ist, den aufbau der odo-sensoren noch einmal etwas verbessern...

[damaltor]

hmm naja die werte sind ja nicht schlecht. damit kann man doch sicher gut arbeiten...

[radbruch]

Hallo

Sind das die Werte mit internem PullUp? Wenn ja, dann würde ich den ADC über Bord werfen und es mal so versuchen:


void OdometryData (unsigned int *data)
{
Vorbereitung zum Lesen der Odometrie-Sensoren.
*/
DDRC &= ~((1 << PC0) | (1 << PC1)); // Port auf Input=>Back-LEDs gehen aus
PORTC |= ((1 << PC0) | (1 << PC1)); // PullUps einschalten für PC0 und PC1
ODOMETRIE_LED_ON; // Odometrie-LED's einschalten

/*
Linken Odometrie-Sensor lesen
*/
if (PORTC & (1<<PC1)) data[0]=1023; else data[0]=0;

/*
Rechten Odometrie-Sensor lesen
*/
if (PORTC & (1<<PC0)) data[1]=1023; else data[1]=0;

}
Die 1023 sind nur ein Beispiel, grundsätzlich würde wohl auch eine direkte Zuweisung funktionieren:

data[0]=(PORTC & (1<<PC1))/2;
bzw.
data[1]=(PORTC & (1<<PC0));

Nach "ODOMETRIE_LED_ON;" muss vermutlich eine kleine Verzögerung eingebaut werden weil die LEDs nicht sofort voll leuchten.

Noch eine Anmerkung zu übertriebenen Bitschiebereien. WHEEL_LEFT 1 wäre hier wohl übersichtlicher:

#define WHEEL_LEFT (1 << MUX0) //ADC1
#define WHEEL_RIGHT 0 //ADC0
Die Definition aus asuro.h

Gruß

mic

[inka]

hi mic,

die werte sind ohne die internen pull-ups gemessen worden. Warum? verglichen mit den sinuskurven der reflektionsscheiben ist das doch super, oder?

[damaltor]

ja, ist wohl wahr mit den bitschiebungen, aber so weiss man recht schnell was gemeint ist... allerdings sollte beides "ähnlich" aussehen. eine 1 wäre daher wohl angemessen.

[radbruch]

Klar sind die Werte super, die besten, die ich bisher gesehen habe. Mich würde nur interessieren, ob sich die PullUp-Theorie auch in der Praxis nachweisen läßt. Ich will meinen asuro nicht aktivieren nur um das zu testen.

mic

[damaltor]

meiner ist immernoch baustelle... also müssen wir wohl abwarten ;)

[Sternthaler]

Hai,
ich hatte mal die Anstiegs- und Abfallzeiten an meinem Asuro ausgemessen:

Linien-Sensoren
--- Anstiegszeit ca. 180us
--- Abfallzeit ca. 170us.
Rad-Sensoren
--- Anstiegszeit ca. 50us
--- Abfallzeit ca. 100us.

radbruch hat also Recht mit einer kleinen Verzögerungszeit.
Ein Sleep(2) überbrückt die 50us auf alle Fälle.

Gruß Sternthaler
P.S.: Zum Schluß kann man ja nun auch die Back-LED's wieder 'restaurieren', und somit einen Pollingbetrieb schaffen, so dass die Back-LED's auch funktionsfähig bleiben.

P.P.S.: Das mit dem geshifteten MUX0-Bit beim WHEEL_LEFT sehe ich auch als lesbarer an, da ich dann weiß welches Bit überhaupt gemeint ist.

[inka]

hi mic,

Klar sind die Werte super, die besten, die ich bisher gesehen habe. Mich würde nur interessieren, ob sich die PullUp-Theorie auch in der Praxis nachweisen läßt. Ich will meinen asuro nicht aktivieren nur um das zu testen.

könntest du mir vielleicht einen compilierbaren code zur verfügung stellen damit ich das testen kann? Ich habe mit c++ schon schwierigkeiten genug, obwohl wenn ich es mit den anfängen vergleiche...