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 ;-)
Druckbare Version
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 ;-)
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
Oh, halt, "unentschieden": Ich habe vergessen, dass die Bewertungsphase ja eigentlich erst morgen um Mitternacht endet;-)
Tschuldigung,
stochri
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
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'.
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.
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
@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.
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.Zitat:
Zitat von stochri
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. :-)
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 ? O:)
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
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...Zitat:
Zitat von stochri