RoboterNetz.de :: Thema anzeigen

m.a.r.v.i.n · Verfasst am: 29.03.2008, 20:41

Hallo,

Eine neue Release der ASURO Library steht zum Download auf Sourceforge bereit. Noch ist es keine endgültige Version sondern nur ein Release Candidate. Große Änderungen sind aber nicht mehr zu erwarten.

Die wichtigsten Änderungen gegenüber der Vorgänger Version sind:

* Unterstützung für ATmega168 Prozessoren
* neue Funktion ReadADC zur A/D Wandler Abfrage
* neue Funktion PrintLCD_p zur Ausgabe von Strings aus dem Programmspeicher
* neue Funktion SetCharLCD zum Setzen von Sonderzeichen
* neue Funktion PollSwitchLCD zur Abfrage der Tasten des Arexx LCD
* neue Funktion MyMotorSpeed die Korrekturwerte aus der myasuro.h berücksichtigt.
* neue Funktion SerPrint_p zur Ausgabe von Strings aus dem Programmspeicher
* UART Baudrate einstellbar durch Define
* Interrupt User Funktionen für Timer und A/D Wandler
* AVR Studio Projektfiles für alle Beispielprojekte

Viel Spaß beim Ausprobieren.
Eine Exe Installer Version mit der AsuroFlash IDE folgt in Kürze.

damaltor · Verfasst am: 30.03.2008, 20:52

schöne sache. soll ich den "wichtigste dateien..." thread schon ändern oder hat das zeit bis zum endgültigen release?

m.a.r.v.i.n · Verfasst am: 01.04.2008, 22:02

Zitat:

schöne sache. soll ich den "wichtigste dateien..." thread schon ändern oder hat das zeit bis zum endgültigen release?

Ich denke das hat noch Zeit.

Die Win32 Installer Version der Version 2.8.0rc1 mit der AsuroFlash IDE (aka eierlegende Wollmich-Sau) von Osser steht nun ebenfalls zum Download bereit.

Valen · Verfasst am: 11.04.2008, 12:11

Hallo,

(... Nachbarn, bitte verzei mir fur meiner deutch. Englisch geht mir ganz leichter ab, und ich habe keine ahnung wo ich die deutche special zeichen wie umlaut und so auf mein klavier finden kan. Ich hoffe sie konnen es ohne auch verstehen.)

Also, zur sache. Die AFSetup_v280rc1.exe sagt er wurde Asuro Library 2.7.1 installieren wenn ich mit meiner maus uber dieser component bewegt. Dah stimmt etwas nicht, oder?

m.a.r.v.i.n · Verfasst am: 11.04.2008, 13:26

Hallo,

danke für die Info. Das ist noch ein kleiner Fehler im Install-Skript. Es wird aber die richtige Version installiert.

Valen · Verfasst am: 11.04.2008, 13:32

Hallo,

Gut, ich werde es mal weiter ausprobieren.

damaltor · Verfasst am: 11.04.2008, 15:05

Hello Valen. if it is easier for you, you can speak english also, most of us will understand and ill try to translate. Welcome to the forum!

---

Hallo Valen. wenn es einfach er ist, kannst du auch gern eglisch sprechen. die meisten von uns werden es wohl verstehen, und ich werde versuchen zu übersetzen.

Valen · Verfasst am: 11.04.2008, 16:14

Danke, aber ich wölte doch versuchen deutsch zu schreiben. Ich bin auch schön for einiger zeit angefangen 'Das Boot' von Lothar-Günther Buchheim zu lesen. Geht leider nicht so schnell wie english aber gut genug. Und habe nuhn auch herausgefunden wie ich die korrekte zeichen aus meinen UK-klavier tasten zauberen muß. Ich denke ich werde es schön klappen. Übung, übung, übung.

rossir · Stammmitglied Anmeldungsdatum: 09.05.2007 Beiträge: 63

Hallo m.a.r.v.i.n,

ich finde es schade, dass man immer noch die Werte für

selbst ermitteln muss. Dabei wurden doch im Thread "Regelung fürs Geradeausfahren" schöne Ideen gesammelt wie's besser gehen könnte. Und dabei auch noch Umgebungslichtstabil ist. Hier einfach mal mein Vorschlag. Vielleicht findet er ja seinen Weg in die nächste Lib ?!

SIGNAL (SIG_ADC)
{
const static unsigned char admux[]={
(1 << ADLAR) | (1 << REFS0) | WHEEL_LEFT,
(1 << ADLAR) | (1 << REFS0) | WHEEL_RIGHT};

static int tmp [2], flag [2]={1,1};
static unsigned char toggle = FALSE;

if (autoencode)
{
int sensor = ADCH;
ADMUX = admux[toggle];

tmp[toggle]+=(sensor-tmp[toggle])>>2;
if (flag[toggle]*(sensor-tmp[toggle]) > 2)
{
encoder[toggle]++;
flag [toggle] = -flag [toggle];
}
toggle^=1;
}
}

Bei mir macht der Code (auch bei schlechten Sensorwerten) eine gute Figur und ist auch bei allen Lichtverhältnissen und sogar bei starken und plötzlichen Lichtschwankungen stabil. (Also, mechanisches abdecken der Sensoren, um sie vor störendem Umgebungslicht zu schützen, ist nicht mehr nötig.)

m.a.r.v.i.n · Verfasst am: 16.04.2008, 12:10

Hallo rossir,

Zitat:

Vielleicht findet er ja seinen Weg in die nächste Lib ?!

Die Chancen, dass eine Funktion in die Asuro Lib übernommen wird, steigen natürlich, je besser diese dokumentiert ist. In deinem Fall also praktisch 0 Wink

Schließlich sollen gerade auch Anfänger die Lib nicht nur benutzen, sondern auch verstehen, wie die Funktionen arbeiten.

rossir · Stammmitglied Anmeldungsdatum: 09.05.2007 Beiträge: 63

Hallo m.a.r.v.in,

nichts leichter als das:

/****************************************************************************/
/*
\brief
Interrupt-Funktion fuer den AD-Wandler. Kann ueber autoencode gesteuert\n
die Odometrie-Zaehler in encoder hochzaehlen.

\param
keine

\return
nichts

\see
Die globale Variable autoencode wird hier ausgewertet. Ist sie nicht FALSE,\n
dann wird der AD-Wandler-Wert zum Zaehlen der Odometriewerte in der globalen\n
Variablen encoder benutzt.\n
Es wird auch der AD-Wandler-Kanal auf die 'andere' Seite der Odometrie\n
umgeschaltete und der AD-Wandler neu gestartet.\n
Somit wird erreicht, dass zumindest die Odometriemessung automatisch erfolgt.

\par Beispiel:
int main(void) {
int lSoll=60, rSoll=30, lPwm=lSoll, rPwm=rSoll, delta=50;
Init();
EncoderInit();
EncoderStart();

while(1) {
   int lIst=encoder[LEFT], rIst=encoder[RIGHT];
   EncoderSet(0, 0);

   lPwm+=(delta*lSoll - 1000*lIst)/300;
   rPwm+=(delta*rSoll - 1000*rIst)/300;

   SetMotorPower(lPwm, rPwm);
   Msleep(delta);
}
}
*****************************************************************************/
SIGNAL (SIG_ADC)
{
const static unsigned char admux[]={
(1 << ADLAR) | (1 << REFS0) | WHEEL_LEFT,
(1 << ADLAR) | (1 << REFS0) | WHEEL_RIGHT};

static int tmp [2], flag [2]={1,1};
static unsigned char toggle = 0;

if (autoencode)
{
// Aktuellen Sensorwert vom AD-Wandler entnehmen (hier nur high-order-byte).
int sensor = ADCH;
// Der AD-Wandler wird schon mal auf den übernächsten Analogkanal eingestellt.
ADMUX = admux[toggle];

// In tmp wird ein gleitender Mittelwert mitgeführt.
tmp[toggle] += (sensor-tmp[toggle])>>2;

// Weicht der aktuelle Sensorwert um mehr als +/- 2 vom gleitenden Mittel ab?
if (flag[toggle]*(sensor-tmp[toggle]) > 2)
{
// Dann zähle einen Tick weiter.
// Und nächster Tick erst wieder bei -/+ 2 Abweichung vom gleitenden Mittel.
encoder[toggle]++;
flag[toggle] = -flag [toggle];
}
toggle ^= 1;
}
}

Besser so? Auf jeden Fall deutlich besser kommentiert als das Lib-Orginal Zwinkern

Sternthaler · Anmeldungsdatum: 29.05.2005 Beiträge: 989

Hallo m.a.r.v.i.n

schöne neue Funktionen vor allem auch für die LCD-Erweiterung.
Ich selbst nutze diese Erweiterung zwar nicht, aber die Attraktivität der LIB wird dadurch ja nur größer.

Was ich aber besonders gut finde ist der Punkt:
* Interrupt User Funktionen für Timer und A/D Wandler
Damit kann ja wunderbar in das Interruptgeschehen eingegriffen werden, ohne jedesmal die LIB neu zu übersetzen.
Projektbezogene INT-Funktion wird super möglich. Klasse Idee, diese Technik in die LIB zu bringen Dancing

.

Hallo rossir,

leider muss ich auch m.a.r.v.i.n zustimmen. Seit gestern Nacht starre ich auf deine Funktion und erst durch ein heutiges ECEL-Blatt bin ich schlauer geworden.
Die in tmp[] gebildete Historie in dieser Form zu nutzen, da wollte ich schon vor 'Jahren' selber drauf kommen. Vor allem geht auch der erste Tik fast nie im Excel-Simulator verloren. (Wenn man nicht zu stark an den Schrauben dreht.)
Aber trotz mangelnder Kommentare: Hut ab
(Für den tmp-Startwert würde ich max(ADC-Wert - 20; 0) einsetzen, jedesmal wenn autoencode 'frisch' eingeschaltet wird. Damit wird die 'Anlaufphase' in tmp drastisch reduziert.
Auch den Teiler 2 bei der tmp-Berechnung würde ich auf 8 (mein Spielwert) erhöhen. Damit schrumpt der Abstand zwischen Min- und Maxwerten am ADC von ca. 40 auf nur noch 6 ADC-Einheiten.)
Als Dankeschön gibt es dafür mein EXCEL-Blatt Angel

.
Und ausserdem sehe ich gerade deinen Beitrag mit Kommentaren. Die allerdings sind auch nur knapp bemessen. Die Details stecken ja doch 'zwischen' den Semikolons. Motz, Mecker, Schimpf. Das ist leicht Zwinkern

Gruß Sternthaler

m.a.r.v.i.n · Verfasst am: 17.04.2008, 19:58

Hallo rossir,

Zitat:

Besser so? Auf jeden Fall deutlich besser kommentiert als das Lib-Orginal

ja, so gefällt mir das gleich viel besser. Da habe ich im Gegensatz zu sternthaler nichts mehr zu meckern. Angel

Hallo Sternthaler,

es freut mich, wenn du mal nichts zu meckern hast. Wink

Dein Diagramm macht den Programm Ablauf noch deutlicher.

Vielleicht sollte man den Teiler und den Startwert als Userdefinierbare Konstanten in die myasuro.h aufnehmen. Think

rossir · Stammmitglied Anmeldungsdatum: 09.05.2007 Beiträge: 63

Hallo Sternthaler,

ich bin da nicht so pingelig: So kannst Du gerne den Code um erhellende Kommentare ergänzen Zwinkern

. Vielleicht um Ausschnitte aus diesem Thread?

1)
Anmerkung: Ich habe keinen Teiler 2 zur tmp-Berechnung sondern ich shifte um 2 und deshalb einen Teiler von 4. (Also nicht mehr ganz so weit weg von Deiner 8.) Ich shifte hier, weil ich vermute, dass eine Division zu teuer ist.

2)
Ich wollte der Interruptroutine Platz und Zeit ersparen und habe deshalb auf eine Initialisierung von tmp verzichtet. Statt dessen habe ich den kleinen Teiler 4 gewählt. Dadurch passt sich tmp sehr rapide den ADC-Werten an. (Doppelt so schnell wie ein Teiler 8.) Und verliert in der Realität auch "nie" den ersten Tick. (So muss ASURO auch meist erst mal anfahren.)

3)
Bei Deiner starken Stauchung von 0,025 (im EXCEL-Simulator) kommt der Vorteil von einem Teiler 8 natürlich zur Geltung. Aber, erstens: ist in der Realität die tatsächliche Sensorkurve in solchen Fällen sowieso zu stark verrauscht und zweitens kommt so eine starke Stauchung in der Realität nicht vor. Dann ist eher was kaputt. Ich meine, selbst bei viel Pech beim Löten und mit den Bauteilen, liegt die kleinste realistische Stauchung bei ca. 0,2. ( Übrigens macht der Teiler 4 erst bei einer Stauchung von 0,06 schlapp. )

4)
Allerdings - und hier habe ich noch nicht probiert - könnte es damit (Teiler 8 ) zum ersten mal gelingen, bei Tageslicht, auch ohne eingeschaltetem Encoder-LED, Ticks zu sammeln (allerdings verrauscht). Und das spart Energie - falls es wirklich darauf ankommt.

5)
Vielen Dank für Deinen EXCEL-Simulator. Ich hatte das seinerzeit mit mitgeloggten Orginaldaten durchprobiert, die Daten und Grafiken aber weggeschmissen. Vielleicht reiche ich die noch nach.

Zusammenfassend: Teiler 8 (also shift um 3) geht auch Zwinkern

Und Dankeschön zurück.

Hallo m.a.r.v.i.n,

von den userdefinierbare Konstanten in myasuro.h will ich ja gerade weg Zwinkern

farratt · Stammmitglied Anmeldungsdatum: 23.08.2007 Beiträge: 63

Hallo Leute!

Auch auf die Gefahr hin zu nerven, möchte ich doch noch einmal auf den Schalter-im-Interrupt-Betrieb-Bug hinweisen, der im Thread "Asuro: PollSwitch im Interrupt betrieb" diskutiert wird/wurde. Es wäre sehr schön, wenn einer von den Lib-Leuten mal seine Meinung dazu kund tun könnte...

Gruß farratt

Sternthaler · Anmeldungsdatum: 29.05.2005 Beiträge: 989

Hallo farratt,
genervt wird hier nicht.

Für die, die den Thread suchen: Asuro: PollSwitch im Interrupt betrieb
Und darin das Beispiel von farrett mit Lösungsvorschlag ist hier.

Die dort von dir gefundene Lösung ist mir nicht einleuchtend.
Spätestens wenn mit dem Aufruf von StartSwitch(), nachdem ein Schleifendurchlauf erfolgte, darin wieder SWITCH_OFF aufgerufen wird, sollte das Verhalten so sein, als ob dein eingebautes SWITCH_ON nicht ausgeführt worden wäre.
Außerdem wird mit dem SWITCH_xxx ja nur? die Datenrichtung vom Interrupt-Pin kontrolliert. Dies deutet mir auf ein Timing-Problem hin.
Ich habe gerade etwas mehr als nur ein Stündchen zu dem Thema hinter mir, und kann auch keine andere Lösung finden, die ich dann auch noch erklären könnte.

Eventuell hilft hier anderen der Hinweis, dass der Interrupt im über das Register MCUCR im Low-Level-Mode betrieben wird, und in diesem Mode das Interrupt-Flag INTF1 im Register GICR nie gesetzt wird. So hat man auch keine Chance dieses Flag selber zu beeinflussen.

@m.a.r.v.i.n
Hast du hier eine andere Lösung in der Tasche? Oder kannst du das erklären?

Gruß Sternthaler

m.a.r.v.i.n · Verfasst am: 21.04.2008, 21:56

Hallo,

ja ich hab ein andere Lösung, die ich auch schon im Thread PollSwitch im Interrupt Betrieb gepostet habe. Ich denke, diese Lösung ist einleuchtender. Wink

Die Änderung ist auch schon im SVN eingecheckt und damit in der nächsten Version drin.

Sternthaler · Anmeldungsdatum: 29.05.2005 Beiträge: 989

Danke m.a.r.v.i.n,

mit der Lösung, direkt unter die Nase gehalten, kann ich jetzt endlich wieder schlafen. Nur so kann sich das Brett vorm Kopf anfühlen Zwinkern

Gruß Sternthaler

Valen · Verfasst am: 29.04.2008, 23:29

Hallo wieder,

In die install.txt wird gesagt das nur auf einer stelle Pfad angabe geändert werden muß in de Makefile (sicher wenn neue projekte nicht in der gleiche Verzeichnisebene befinden):

# additional Include path for libraries
LIBPATH = C:/ASURO_SRC/AsuroLib/lib

Aber wenn leute die AVR Compiler auch auf eine 'nicht-default' platz installiert haben mussen sie auch die fölgende stelle ändern denke ich schön:

# Define directories, if needed.
#DIRAVR = C:/WinAVR

Richtig?

m.a.r.v.i.n · Verfasst am: 01.05.2008, 12:21

Zitat:

# Define directories, if needed.
#DIRAVR = C:/WinAVR

Richtig?

Nein, das ist nicht notwendig. Der AVR Compiler wird über die Pfadangaben in der Systemvariablen PATH gefunden. DIRAVR usw. werden zwar im Makefile gesetzt, aber nirgendwo verwendet.

Valen · Verfasst am: 01.05.2008, 12:52

Danke, ich habe mal in meiner eigener systemvariablen gekückt. Stimmt, genau. Ich wuste nicht das PATH automatisch eingestellt war.

RobotNeu · Öfters hier Anmeldungsdatum: 02.09.2008 Beiträge: 10

ich habe eine kleine Frage. Wo wird die F_CPU Variable, die in der Datei asuro.c bei der Funktion Init() benutzt wird, deklariert? es wäre sehr nett, wenn mir da jemand weiterhelfen könnte.

#if defined(__AVR_ATmega168__)
UBRR0L = (uint8_t)(F_CPU/(BAUD_RATE*16L)-1);
UBRR0H = (F_CPU/(BAUD_RATE*16L)-1) >> 8;
UCSR0B = (1<<RXEN0) | (1<<TXEN0);
UCSR0C = (1<<UCSZ00) | (1<<UCSZ01);
#else
UBRRH = (((F_CPU/BAUD_RATE)/16)-1)>>8; // set baud rate
UBRRL = (((F_CPU/BAUD_RATE)/16)-1);
UCSRB = (1<<RXEN)|(1<<TXEN); // enable Rx & Tx
UCSRC = (1<<URSEL)|(1<<UCSZ1)|(1<<UCSZ0); // config USART; 8N1
#endif