ASURO ... ein kleiner Wettbewerb

**recycle** · 27.06.2005, 18:37

Ich stimme für izaseba. Sein Bild hat einfach den schöneren Hintergrund und mit einer Frau im Rücken,
die überwacht, dass er nicht auf den Fußboden malt, hatte er eindeutig erschwerte Bedingungen

**stochri** · 27.06.2005, 20:16

Tja, das ist ja sehr schön, wenn ich richtig gezählt habe, dann hat jeder von uns zwei Stimmen bekommen, die vom jeweils anderen und noch eine.

Damit steht es UNENTSCHIEDEN !!!!

Aber das es ging ja um den Spass bei der Sache.

Was mich noch rein programmtechnisch interessieren würde: izaseba, wie hast Du den Gleichlauf der Motoren und den korrekten Winkel hingekriegt? Bei meinem Programm sind es ja die Kallibrierroutinen.

Was mich mal interessieren würde: hat mal jemand das Programm von mir in seinen ASURO geladen und ausprobiert ? Mich würde interessieren ob man die Winkelroutine anpassen muss.

Schade das linux_80 nicht mitmachen konnte und ICH_ hat sich angemeldet, aber konnte wohl auch nicht teilnehmen ( war ja auch ein zu schönes Wochenende)

Gut, das Wetter macht einem im Moment nicht so an, um was zu programmieren.
Aber meine Frage: Sollen wir noch mal so einen Wettbewerb veranstalten ? Ich denke es ließen sich sogar ein paar Preise organisieren. Wäre das ein Anreiz ?

viele Gruesse,
stochri

**stochri** · 27.06.2005, 20:19

Oh, halt, "unentschieden": Ich habe vergessen, dass die Bewertungsphase ja eigentlich erst morgen um Mitternacht endet

Tschuldigung,
stochri

**izaseba** · 27.06.2005, 21:00

Hallo stochri,
Ich habe einfach alles über die Odometrie gemacht,
Geradefahren tut mein Asuro schon so, da habe ich gottseidank nichts machen brauchen
(hatte auch nicht viel Zeit um das auch noch zu programmieren)
und die Winkel, ich habe gezählt wieviele schwarz-weiß Übergänge bei 90 grad stattfinden (ich habe die scheiben mit 4 weißen und 4 schwarzen Feldern drauf) und das waren genau 50.
Na ja dann kamen noch 75 für 135 grad und Fertig.
Für die Strecke habe ich 100 Übergänge genommen und für die diagonale und das Dach habe ich den Herrn Pytagoras befragt, stimmte zwar nicht ganz genau, wegen dem Schlupf (Theorie und Praxis) also noch etwas angepasst und fertig.
Anbei mein Programm, da ich ein Purist bin und C an meinem Rechner schon immer benutze, habe ich das Programm im Assembler geschrieben.
Ist zwar nicht ganz perfekt, aber wie Du schon sagtest, schönes Wetter, noch Kirmes im Dorf, die Bruderschaft hat gerufen, naja nicht viel Zeit gehabt.

Code:

;Version 1.0
;Odometrie nach dem Beispiel von Rechteck.c
.include "m8def.inc"
.equ fwd = PB5		;vor
.equ rwd = PB4		;zurück
.equ encodertrue = 7 	;Bit 7 von tooglereg für Odometrie an/aus
.equ kolisionflag = 6   ;Bit 6 von tooglereg für Kolisionerkennung
.equ toogleflagL = 2	;Hat eine Änderung am Rad Links stattgefunden ?
.equ toogleflagR = 1	;Hat eine Änderung am Rad Rechts stattgefunden?
.equ toogle = 0		;Bit 0 von tooglereg für Rad R "0" und Rad L "1" umzuschalten
.equ geschwindigkeit = 0xA0
.equ encoderon = 0x80
.equ encoderoff = 0x7F 
.equ rechterwinkel = 53 ; 90 grad rechts sind genau 53 schritte
.equ rechterwinkel2 = 54 ; 90 grad links sind genau 54 schritte
.equ halbrechterwinkel = 80 ;135 grad rechts
.equ weg = 100		;soll 300 schritte fahren
.equ weglang = 150      ;Langer Weg diagonal
.equ wegkurz = 50	;Kurzer Weg für das Dach
.def encoder_leftL = R1
.def encoder_leftH = R2
.def encoder_rightL = R3
.def encoder_rightH = R4
.def vergleicherL = R5
.def vergleicherH = R6
.def tmp = R16 	; Multipurose
.def tmpi = R17 ; Multipurose für Interrupts
.def tmpi2 = R19 ;Multipurose 2 für 16 Bit rechnen
.def tmp2 = R20  ;Multipurose für 16 Bit rechnen
.def geschlinks = R21	;geschwindigkeit linkes Rad
.def geschrechts = R22	;geschwindigkeit rechtes Rad
.def tooglereg = R18	;Toogle Register
.org 0x00
	rjmp reset	;ResetVector

.org ADCCaddr
	rjmp ADCcomplete	; ADC Interrupt Vector Address

reset:
	;Stack einrichten
	ldi tmp,HIGH(RAMEND)
	out SPH,tmp
	ldi tmp,LOW(RAMEND)
	out SPL,tmp
	;Stack fertig

	ldi tooglereg,0x00
	ori tooglereg,encoderon
	;PWM einstellen
	ldi tmp,(1<<WGM10) | (1<<COM1A1) | (1<<COM1B1)
	out TCCR1A,tmp
	ldi tmp,(1<<CS11)
	out TCCR1B,tmp
	;DDR für Tastenabfrage		
	

	;A/D Conversion
	ldi tmp,(1<< ADEN) | (1<<ADFR) | (1<<ADIE) | (1<<ADSC) | (1<<ADPS0) | (1<<ADPS1) | (1<<ADPS2)
	out ADCSRA,tmp
	ldi tmp,(1<<REFS0) | (1<<ADLAR) | (1<<MUX0)
	out ADMUX,tmp 
	; DDR für Motor Rechts und Statusled green
	ldi tmp,(1<<PB0) |(1<<PB1) | (1<<PB2) | (1<<PB5) | (1<<PB4)
	out DDRB,tmp
	;DDR für Motor Links,Statusled red, LED für Linienverfolgung und LEDs
	;Odometrie und Backleds
	ldi tmp,(1<<PD2) | (1<<PD4) | (1<<PD5) | (1<<PD6) | (1<<PD7)
	out DDRD,tmp
	cbi DDRD,PD3
	cbi DDRC,PC0	;schalte PC0 als eingang
	cbi DDRC,PC1	;schalte PC0 als eingang
	sbi PORTD,PD7 ;schalte Odometrie LEDs ein
	cbi PORTB,PB0	;Status LED aus
	cbi PORTD,PD2	;Dito
			;ldi tmp,LOW(weg)
			;mov vergleicherL,tmp
			;ldi tmp,HIGH(weg)
			;mov vergleicherH,tmp
			;sbi PORTD,PD6
	ldi geschrechts,geschwindigkeit
	ldi geschlinks,geschwindigkeit	
	sei
main:
	rcall motorengesch
	
	rcall ladeweg
	rcall fahre
	rcall drehe
	rcall ladeweg
	rcall fahre
	rcall drehe
	rcall ladeweg
	rcall fahre
	rcall drehe
	rcall ladeweg
	rcall fahre
	rcall drehehalb
	rcall ladeweglang
	rcall fahre
	rcall drehelinks
	rcall ladewegkurz
	rcall fahre
	rcall drehelinks
	rcall ladewegkurz
	rcall fahre
	rcall drehelinks
	rcall ladeweglang
	rcall fahre
	rcall motorenloeschen
stop:
	rjmp stop

ladeweg:
	cli
	ldi tmp,LOW(weg)
	mov vergleicherL,tmp
	ldi tmp,HIGH(weg)
	mov vergleicherH,tmp
	sei
	rcall odozaehlernull
	sbi PORTB,fwd
	sbi PORTD,fwd
	ret

ladeweglang:
	cli
	ldi tmp,LOW(weglang)
	mov vergleicherL,tmp
	ldi tmp,HIGH(weglang)
	mov vergleicherH,tmp
	sei
	rcall odozaehlernull
	sbi PORTB,fwd
	sbi PORTD,fwd
	ret

ladewegkurz:
	cli
	ldi tmp,LOW(wegkurz)
	mov vergleicherL,tmp
	ldi tmp,HIGH(wegkurz)
	mov vergleicherH,tmp
	sei
	rcall odozaehlernull
	sbi PORTB,fwd
	sbi PORTD,fwd
	ret


drehe:	
	rcall motorenloeschen	;motoren STOP
	ldi tmp,rechterwinkel	;Lade  90 grad Drehung 
	mov vergleicherL,tmp
	ldi tmp,0x00
	mov vergleicherH,tmp
	rcall odozaehlernull	;Wegezähler löschen
	sbi PORTD,fwd		;Jetzt Drehen wir uns was
	rcall fahre	;Jetzt warten bis wir uns um 90 grad gedreht haben
	rcall motorenloeschen	;motoren STOP
	ret

drehelinks:	
	rcall motorenloeschen	;motoren STOP
	ldi tmp,rechterwinkel2	;Lade 30 schritte für die 90 grad Drehung 
	mov vergleicherL,tmp
	ldi tmp,0x00
	mov vergleicherH,tmp
	rcall odozaehlernull	;Wegezähler löschen
	sbi PORTB,fwd		;Jetzt Drehen wir uns was
	rcall fahrelinks	;Jetzt warten bis wir uns um 90 grad gedreht haben
	rcall motorenloeschen	;motoren STOP
	ret


drehehalb:	
	rcall motorenloeschen	;motoren STOP
	ldi tmp,halbrechterwinkel	;135 grad Drehung 
	mov vergleicherL,tmp
	ldi tmp,0x00
	mov vergleicherH,tmp
	rcall odozaehlernull	;Wegezähler löschen
	sbi PORTD,fwd		;Jetzt Drehen wir uns was
	rcall fahre	
	rcall motorenloeschen	;motoren STOP
	ret

fahre:
	cli

	mov tmp,encoder_rightL
	mov tmp2,encoder_rightH
	cp vergleicherL,tmp	;Vergleiche gefahrenen Weg
	cpc vergleicherH,tmp2
	sei
	in tmp,SREG
	sbrs tmp,0
	rjmp fahre
	ret
fahrelinks:
	cli
	mov tmp,encoder_leftL
	mov tmp2,encoder_leftH
	cp vergleicherL,tmp	;Vergleiche gefahrenen Weg
	cpc vergleicherH,tmp2
	sei
	in tmp,SREG
	sbrs tmp,0
	rjmp fahrelinks
	ret
	 
.include "motoren.asm"
.include "LED.asm"

ADCcomplete:
	in tmpi,SREG
	push tmpi
	ldi tmpi2,0x00
	in tmpi,ADCL
	in tmpi,ADCH
	sbrs tooglereg,toogle		;Wenn Bit toogle = 1 Weiter bei Rechtem Rad
	rjmp radlinks
	;Rad Rechts
	sbrs tooglereg,toogleflagR
	rjmp flagRfalse
	;flagRtrue
	cpi tmpi,0x8C
	brsh ausR
	ldi tmpi,0x01
	add encoder_rightL,tmpi
	adc encoder_rightH,tmpi2
			;debug
	cbi PORTD,PD2
	sbi PORTB,PB0
			;ende debug
	andi tooglereg,0xFD
	rjmp ausR
flagRfalse:
	cpi tmpi,0xA0
	brlo ausR
	ldi tmpi,0x01
	add encoder_rightL,tmpi
	adc encoder_rightH,tmpi2
			;debug
	cbi PORTD,PD2
	sbi PORTB,PB0
			;ende debug
	ori tooglereg,(1<<toogleflagR)
ausR:
	sbi ADMUX,MUX0
	andi tooglereg,0xFE
	rjmp rausadc	
radlinks:
	sbrs tooglereg,toogleflagL	;ist toogleflagL gesetzt? wenn ja springe zu flagtrue
	rjmp flagLfalse			;wenn nicht springe zu flagLfalse
	;flagLtrue
	cpi tmpi,0x8C			;vergleiche mit 0xA0
	brsh ausL			;wenn größer oder gleich springe zu ausL
	ldi tmpi,0x01
	add encoder_leftL,tmpi		;encoder_left++
	adc encoder_leftH,tmpi2
			;Debug
	sbi PORTD,PD2
	cbi PORTB,PB0
			;Ende Debug
	andi tooglereg,0xFB		;Lösche flagL
	rjmp ausL
flagLfalse:
	cpi tmpi,0xA0
	brlo ausL
	ldi tmpi,0x01
	add encoder_leftL,tmpi
	adc encoder_leftH,tmpi2
			;Debug
	sbi PORTD,PD2
	cbi PORTB,PB0
			;ende debug
	ori tooglereg,(1<<toogleflagL)
ausL:	
	cbi ADMUX,MUX0
	ori tooglereg,(1<<toogle)
	rjmp rausadc
	
rausadc:
	pop tmpi
	out SREG,tmpi
	reti

**Sternthaler** · 19.03.2006, 01:06

Ok, ich bin jetzt etwas spät dran.
Trotzdem möchte ich meinen Nikolaus hier auch einbringen, da mich dieser Threat eigendlich dazu gebracht hat überhaupt mit dem Asuro weiterzumachen. (Natürlich verstehe ich es, wenn ich nicht mehr in die Wertung komme.)

Einmal vorweg:
Mein Asuro scheint eine echte Krücke zu sein. Wie ihr gleich am ersten Bild sehen könnt, hatte ich zwar keine Probleme mit dem Programm von stochri so halbwegs gerade Striche hinzubekommen, aber das gesamte Ergebnis war eher etwas für 'bildende Künste' als für den Nikolaus. Jedenfalls ist das mein bestes Ergenis, dass ich mit dem Program von stochri hinbekommen hatte.
Dann habe ich mich so ein paar Monate zurückgezogen und einige Infos hier aus dem Forum (waste sei Dank) und gründlichem Studium der Doku und einiger schlaflosen Nächte zusammengeschustert um meinem Asuro den Nikolaus zu entlocken.
Nachdem also der linienverfolgende PID-Regleger von waste zu einem Raddekoder-Regler umkonfiguriert war und alle Sensoren (außer der Empfangsschnittstelle) auf Interruptbetrieb umgestellt wurden, habe ich meine Willen durchsetzen können und dem vergammelten, verrosteten, und wahrscheinlich Vorgänger von R2D2 (soll heissen mein Asuro) doch noch einen Nikolaus so halbwegs malen lassen können.

So, nun der schlechteste Nikolaus in diesem Wettbewerb, und dann der nach monatelagen Versuchen entstanden 'Nachbau'.

**Sternthaler** · 19.03.2006, 01:19

So, damit ihr auch nachsehen könnt, was ich mir für eine Mühe gemacht habe, gibt es auch noch meinen Source dazu.

- asuro_st.c entspricht ca. der asuro.c mit 'kleinen' Umbauten
- asuro_st.h bringt auch 'ungefähr' das Gleiche mit
- asuro_hw.h enthält nur einen Hardwaredefine für meine unterschiedlichen (Krücken-)Motoren
- asuro_md.h enthält einige Defines zum sammeln von MessDaten
- test.c enthält den Nikolaus

Im Source asuro_st.c sind vor allem die Umbauten zum Interruptbetrieb und ich habe dort den PID-Regler von waste so eingebaut, dass sowohl eine Linienverfolgung als eben auch eine Nutzung für die Raddekoder möglich ist.

[Edit 30.04.2010] Eine angepasste Version (V10-2) hinzugefügt, da es bei neueren Compilern Probleme mit dem #include <string.h> gibt. Die scheint nicht mehr notwendig zu sein.

**stochri** · 19.03.2006, 08:44

GRATULATION ZU DISEM ERGEBNIS !!

Hallo Sternthaler,
Dein Nikolaushaus ist wirklich das Beste im ganzen Wettbewerb.
Und das Ziel des Wettbewerbs war es ja eingentlich, gute Verfahren für die Asuorwegsteuerung zu finden.

Bei meinem Programm muss man erst ein paar mal die Kallibrierroutinen laufen lassen, bis der ASURO um den richtigen Winkel dreht und eine gerade Linie fährt. Erst wenn man das gemacht hat, kann man das Ergebnisbild erreichen, welches ich gepostet habe.

Beim Wettbewerb stand ich vor der Entscheidung, einen Regler zu entwerfen, oder einfach nur eine Steuerung zu implementieren. Da ein hoher Zeitdruck ( fast wie im richtigen Entwicklerleben ) vorhanden war, habe ich mich für die Steuerung entschieden, weil ich davon ausgegangen bin, dass für eine kurze Zeit die Batteriespannung einigermaßen konstant bleibt und die Motoren gliechbleibend laufen.

Bei diesem Verfahren ist natürlich die Kallibrierung etwas umständlich und für ein gutes NIkolaushaus bedarf es dann einiger Versuche.
Das Programm ist deshalb für eine Wegsteuerung nicht allgemein verwendbar, aber für den Wettbewerb durchaus ausreichend.
Bei der Implementation des Reglers hätte ich die Schwierigkeit erwartet, beim Zeichnen einer geraden Linie einen Einschwingvorgang auf der Linie zu sehen. Und wenn der ASURO einmal seine Position leicht verloren hat, wird es mit dem Nikolaushaus nichts.

Deshalb halte ich Dein Ergebnis für super, nur mit dem Zeitkriterium ist es halt etwas knapp. Aber Dein Ergebnis ist sicherlich allgemein verwendbar und deshalb ist das Ziel, für den ASURO eine vernünftige Motorsteuerung zu realisieren wohl erreicht.

Bin mal gespannt, was Waste zu Deinerm Ergebnis meint.

Beste Grüße,
stochri

**Sternthaler** · 19.03.2006, 23:16

@stochri
Danke für die Blumen.

Eigendlich kann ich dir nicht zustimmen, dass der Nicolaus von mir der Beste sein soll. Bei deinem passen die Ecken besser, und izaseba's Ansatz die Kringel beim Wenden durch eine Bogenfahrt zu vermeiden, ist zwar nicht der 'klassische' Nikolaus, aber alleine der Mut zu diesem Ansatz hatte mich damals schon überrascht. Da wäre ich nie im Leben selber drauf gekommen.

Zitat von stochri

einen Einschwingvorgang auf der Linie zu sehen

Da hast du vollkommen Recht. Wenn ihr euch mal die rechte, obere Ecke, bzw. die obere waagerechte Linie an der rechten Seite anseht (Ausschnitt siehe unten), dort ist das Schwingen sehr gut zu sehen.
Der Bogen geht erst nach unten, das heisst der Asuro fährt erst mit dem linken Motor los, die Linie pendelt dann tatsächlich erst etwas bis der Regler alles in den Griff bekommen hat. Eigendlich ist bei allen Linien dieser Effekt zu sehen. Klar, ich hatte ja schon davon gesprochen, das mein linker Motor wesentlich besser ist.
Was ich aber nicht feststellen konnte, ist deine Vermutung, das der Asuro dann komplett seine Positionen verliert. Wahrscheinlich liegt es hier aber am großen Verhältnis zwischen der gut geregelten Strecke und dem ersten Stück Weg, an dem der Asuro noch schwingt.

Ich hatte noch vergessen anzugeben, wie ich auf die Zahlen für die Wegliste (in test.c) gekommen bin.
Ich habe (mal wieder) ein EXCEL-Blättchen gemacht und dort ein bisschen die Geometrie von dieser 2-rädrigen Art der Fortbewegung hinterlegt.
Mittlerweile gibt es in der Zelle [P4] einen sehr wichtigen Prozentwert, der angibt wie viele der Farbwechsel auf der Dekoderscheibe tatsächlich vom Asuro registriert werden. Ich komme mit den dann berechneten Tick-Werten am besten an das gewünschte Ergebnis, wenn ich nur 96% der eigendlich zu erwartenden Tick's in den Berechnungen berücksichtige.
Meine Vermutung ist, dass trotz konstantem, nächtlichem Licht über dem Küchentisch, die leider immer noch festen Schwellwerte zur Hell-/Dunkelübergangsbestimmung die Ursache sind.
Jetzt also auch noch das EXCEL als Tick-(Trick- und Track)-Berechner.

Nochmals vielen Dank für das große Lob. Bekommt mir sehr gut.

**stochri** · 21.03.2006, 22:35

Ist ja lustig, dass der ASURO trotz des Einschwingvorgangs seine Richung beibeihaelt.

Woher kommen eigentlich die leicht verdelten Kreise? Ist es moeglich, dass der Stift ein wenig in seiner Halterung wackelt ?

Bei einem der Versuche habe ich einen 1.5mm Kupferdraht genommen und damit eine Halterung zurecht gebogen. Wenn man den Draht an den Enden abisoliert, kann man ihn in die Loecher der Batteriehalterung einhaengen:

https://www.roboternetz.de/phpBB2/ze...ht=servo+asuro

Das Servo braucht man natuerlich nicht unbedingt.

Dass die Encoderscheiben immer ungenaue Werte liefern, ist irgendwie seltsam. Vielleicht liegt es ja gar nicht unbedingt am Stoerlicht, sondern aus irgendwelchen Gruenden koennte der AD-Wandler ja auch ab und zu mal einen elektrischen Stoerpeak abkriegen.
Oder es ist ein Konflikt im Timing des Programms. Ich verwende AVR-Studio und mir ist aufgefallen, dass die 72kHz Interruptroutine relativ viel Rechenkapazitaet des Atmega auffrisst. Vielleicht koennte es ja bisweilen auch einen Konflikt mit der AD-Wandlung geben.

Deine Routinen scheinen sehr genau zu funktionieren. Da waere es doch lustig, mal etwas komplizierteres als ein Nikolaushaus zu malen. Oder wie waers, das Nikolaushaus einfach 4x in die 4 unterschielichen Himmelsrichtungen zu zeichnen. Sieht bestimmt auch gut aus.

Gruss,
stochri

**nabla** · 22.03.2006, 12:39

Zitat von stochri

Vielleicht liegt es ja gar nicht unbedingt am Stoerlicht,

Also ich habe mal irgendwo gelesen, dass einer um die Photdioden und die Scheibe irgendwie ein Gehäuse gebastelt hat (siehe Bild) und dann diese Probleme weg waren... Also liegt es wohl mit ziemlicher Sicherheit am Störlicht...

Thema: ASURO ... ein kleiner Wettbewerb

Themen-Optionen

Thema durchsuchen

Anzeige

Lesezeichen

Lesezeichen

Berechtigungen