mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Algorithmus für Linefollower mit 5 Sensoren


Autor: Algorithmus für Linefollower mit 5 Sensoren (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo liebe Leute, ich habe mich einmal zuhause an ein neues Projekt auf 
etwas höherem Niveau getraut, und die Hardware habe ich schon fertig.
Ich habe dazu einen Motortreiber L293D genommen und steuere die Motoren 
meines Linefollowers per PWM an.

Mein letztes Problem ist jetzt den Algorithmus in Assembler zu 
schreiben. Ich habe aber dazu ansatzweise keine Idee. Mein 
Assemblerprogramm ist bis jetzt so weit, dass ich alle Sensorwerte 
auslese und in 1 Byte schreibe.
Nun weiß ich echt nicht weiter, kann mir jemand helfen?

Gruß Bro

[edit]

Ich habe mir die Freiheit genommen, den wenig aussagekräftigen Titel des 
Threads ("Brocken sei") durch den des Autors zu ersetzen ...

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Algorithmus für Linefollower mit 5 Sensoren schrieb:

> Mein letztes Problem ist jetzt den Algorithmus in Assembler zu
> schreiben. Ich habe aber dazu ansatzweise keine Idee.

Na ja.
schwarze Linie auf hellem Grund?

Ich nehme jetzt einfach mal an, dass dein Sensor einen höheren Wert 
liefert, je heller der Untergrund ist.
beide Motoren vorwärts

für immer
  wenn rechts ein höherer Wert gemeldet wird als links
  ja -> rechten Motor etwas schneller fahren lassen
  nein -> rechten Motor etwas langsamer fahren lassen
ende Schleife

Ist sicher nicht perfekt. Aber es ist ein Anfang. Denk dir was aus. 
Genau da besteht ja schliesslich der Spass an der ganzen Sache: Sich was 
ausdenken und nachsehen obs funktioniert.

Autor: Algorithmus für Linefollower mit 5 Sensoren (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> schwarze Linie auf hellem Grund?

Ja, Schwarze Linie auf weißem Untergrund
Die Sensoren gehen auf den ADC und ich digitalisiere das Signal und 
schreibe das ganze dann in ein Byte.

Karl heinz Buchegger schrieb:
> beide Motoren vorwärts
>
> für immer
>   wenn rechts ein höherer Wert gemeldet wird als links
>   ja -> rechten Motor etwas schneller fahren lassen
>   nein -> rechten Motor etwas langsamer fahren lassen
> ende Schleife

Ich weiß nicht, kann das so einfach gehen?
Was ist denn rechts und links?
S0 S1     S2     S3 S4
10 5      0      -5 -10
Meinst du das so?

Wenn ja wie kann ich mir ausrechnen mit wieviel Prozent ich auf die 
Motoren gehe?

Gruß Bro.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Algorithmus für Linefollower mit 5 Sensoren schrieb:

> Ich weiß nicht, kann das so einfach gehen?

probiers aus.

> Was ist denn rechts und links?
> S0 S1     S2     S3 S4
> 10 5      0      -5 -10
> Meinst du das so?

Ist ganz einfach.
Wenn dein Robi droht nach rechts von der Linie runterzufahren, dann 
liefern die linke Sensoren einen dunkleren Wert als die rechten (weil ja 
dann die linken Sensor auf die schwarze Linie drauffahren, während die 
rechten runterfahren). Gegenmassnahme: der Robbi muss nach links fahren, 
d.h. der rechte Motor muss sich schneller drehen, damit links und rechts 
wieder in etwa dasselbe gemeldet wird.

> Wenn ja wie kann ich mir ausrechnen mit wieviel Prozent ich auf die
> Motoren gehe?

Gar nicht.
Probiers einfach aus. Beobachte deinen Robbi, zieh deine Schlüsse und 
erhöhe oder erniedrige den Wert um den du den Motor schneller drehen 
lässt. Oder probier aus, wie gut es funktioniert, wenn du die Differenz 
(mal einem Faktor) als Motordifferenz hernimmst oder ....

experimentieren ist angesagt!


(zum experimentieren ist IMHO Assembler nicht wirklich gut geeignet, 
weil du dich um zuviel Low-Level Kleinkram kümmern musst)

Autor: Björn R. (sushi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dazu eine lustige Pausenbeschäftigung:

http://www.gameshot.org/?id=4469

Einige Level sind gar nicht mal sooo einfach...
Hat bei mir für einige Stunden Kurzweil gesorgt.

Der Line Follower ist übrigens LEvel 4...
LG, Björn

Autor: Brocken Sei (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> Gar nicht.
> Probiers einfach aus. Beobachte deinen Robbi, zieh deine Schlüsse und
> erhöhe oder erniedrige den Wert um den du den Motor schneller drehen
> lässt. Oder probier aus, wie gut es funktioniert, wenn du die Differenz
> (mal einem Faktor) als Motordifferenz hernimmst oder ....

Aber dann müsste ich doch theoretisch 2^5 Möglichkeiten im Programm 
durchgehen.
Einpaar Möglichkeiten werden zwar nicht existieren aber trotzdem wird 
das Programm zu lange brauchen um zu reagieren, vorallem weil ich eine 
1:10 Übersetzung habe im GM und er ziemlich schnell davonsausen wird, 
soll ich trotzdem für jede Möglichkeit eine Bestimmte Ansteuerung 
vornehmen?

Groß Bro

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Brocken Sei schrieb:
> Karl heinz Buchegger schrieb:
>> Gar nicht.
>> Probiers einfach aus. Beobachte deinen Robbi, zieh deine Schlüsse und
>> erhöhe oder erniedrige den Wert um den du den Motor schneller drehen
>> lässt. Oder probier aus, wie gut es funktioniert, wenn du die Differenz
>> (mal einem Faktor) als Motordifferenz hernimmst oder ....
>
> Aber dann müsste ich doch theoretisch 2^5 Möglichkeiten im Programm
> durchgehen.

Such dir ein anderes Hobby.
Du bist zu sehr Beamter und viel zu wenig neugieriger Wissenschafter, 
der einfach mal macht und es drauf ankommen lässt was da rauskommen 
wird.

> vorallem weil ich eine
> 1:10 Übersetzung habe im GM und er ziemlich schnell davonsausen wird

Dann brems ihn ein.
Schiefahren lernt man auch nicht dadruch, dass man sich den steilsten 
Hang aussucht.

Autor: CAN_Anfänger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
stichwort: Regeler!!!!
der macht das dann automatisch wenn du Ihn richtig einstellst, schneller 
als dein roboter fährt

Autor: Brocken Sei (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> Such dir ein anderes Hobby.
> Du bist zu sehr Beamter und viel zu wenig neugieriger Wissenschafter,
> der einfach mal macht und es drauf ankommen lässt was da rauskommen
> wird.

Hehe, ich wusste ja das sowas kommt, und natürlich war ich schon von 
anfang an auf so etwas vorbereitet, da ich ein Dutzend ähnlicher 
Kommentare von dir und anderen Schlaumeiern durchgeschaut habe. Das ist 
nicht das erste Projekt, das ich angehe, und auch nicht mein erster 
Linefollower.
Und deshalb bin ich lieber Beamter als irgend einen scheiß zu bauen weil 
du glaubst, dass ich keine Erfahrungen habe und wenn wenigstens 
irgendwas funktioniert ich sehr dankbar sein werde, auf das biste doch 
hinaus oder?
Ein Dankeschön suchst du.
Ich gehe das lieber wie ein techniker an und überlege vorher lieber was 
bevor ich 20 Stunden in Schrott investiere, deshalb auch mein Beitrag.
PS: Klar bin ich auch wissenschaftler, aber die Wissenschaft besteht ja 
auch aus grundlegenden Sachen und nicht nur aus rumprobieren Kumpel

Gruß Bro

Autor: Brocken Sei (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> Dann brems ihn ein.
> Schiefahren lernt man auch nicht dadruch, dass man sich den steilsten
> Hang aussucht.

Du weißt schon, dass es jedes Roboterbauer Manns Ziel ist die Linie so 
schnell wie möglich zu verfolgen, und da reicht Einbremsen allein nicht, 
da ich jede us die ich sparen kann auch einsparen muss um etwas 
sinnvolles zu erreichen^^

Gruß Bro

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Brocken Sei schrieb:

> Kommentare von dir und anderen Schlaumeiern durchgeschaut habe. Das ist
> nicht das erste Projekt, das ich angehe, und auch nicht mein erster
> Linefollower.


Oh nein.
Das nehm ich dir nicht ab.

Du hast in deinem ganzen Leben noch nie einen Linefollower selber 
programmiert. Du hast dir vielleicht ein Programm aus dem Web geholt, es 
auf deinen µC gebrannt und es laufen gelassen. Aber selber gemacht, dir 
selber was ausgedacht hast du noch nie.

Verarschen kannst du jemanden anderen.

> Du weißt schon, dass es jedes Roboterbauer Manns Ziel ist
> die Linie so schnell wie möglich zu verfolgen,

Und?
Du kannst es noch nicht einmal, wenn der Robbi langsam fährt. Oder wie 
soll man ...

> Ich habe aber dazu ansatzweise keine Idee

... verstehen?

Autor: Brocken Sei (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> Du hast in deinem ganzen Leben noch nie einen Linefollower selber
> programmiert. Du hast dir vielleicht ein Programm aus dem Web geholt, es
> auf deinen µC gebrannt und es laufen gelassen. Aber selber gemacht, dir
> selber was ausgedacht hast du noch nie.

Du weißt schon, dass ich meine Sachen selber entwickle, das was du 
schreibst find ich ehrlich gesagt zum lachen^^

Karl heinz Buchegger schrieb:
> Verarschen kannst du jemanden anderen.

Ich würd nur sagen typisch Freaks die den ganzen Tag im Forum sitzen und 
sich weiß machen wollen anderen zu helfen. Damit hast du deine 
Ungewissheit nochmal quadriert.

Gruß Bro

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Brocken Sei schrieb:

> Du weißt schon, dass ich meine Sachen selber entwickle, das was du
> schreibst find ich ehrlich gesagt zum lachen^^

Na, dann präsentier doch mal deine Idee zu dem Thema

Autor: Brocken Sei (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> Und?
> Du kannst es noch nicht einmal, wenn der Robbi langsam fährt. Oder wie
> soll man ...

Das sind vorurteile, wieso sollte ich das nicht können, ich habe doch 
schon wie gesagt einen programmiert, der nicht so schnell ist, oder hast 
du das denn wieder vergessen?

Karl heinz Buchegger schrieb:
>> Ich habe aber dazu ansatzweise keine Idee
>
> ... verstehen?

Nun ja, das schrieb ich nur so rein weil ich alles aus denen die mir 
helfen wollen rausholen will. Jeder idiot kennt diesen Trick.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Brocken Sei schrieb:
> Karl heinz Buchegger schrieb:
>> Und?
>> Du kannst es noch nicht einmal, wenn der Robbi langsam fährt. Oder wie
>> soll man ...
>
> Das sind vorurteile, wieso sollte ich das nicht können, ich habe doch
> schon wie gesagt einen programmiert, der nicht so schnell ist, oder hast
> du das denn wieder vergessen?

Wo genau hast du das gesagt?

> Nun ja, das schrieb ich nur so rein weil ich alles aus denen die mir
> helfen wollen rausholen will. Jeder idiot kennt diesen Trick.

Aha. Du schreibst also nur so einfach irgendwas.
Ja, ne, ist klar.

Autor: Brocken Sei (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Na, dann präsentier doch mal deine Idee zu dem Thema
Weißt du was, ich wollte eigentlich nur einwnig Tipps bekommen und mich 
nicht auf so ein kindisches unkollegiales Niveau herabsetzen, aber wenn 
du es wissen willst dann bitte.

>Na, dann präsentier doch mal deine Idee zu dem Thema
Was willst du denn genaues wissen du Profi?

Groß Bro

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Erläutere mal diese Aussage:

>Mein letztes Problem ist jetzt den Algorithmus in Assembler zu
>schreiben. Ich habe aber dazu ansatzweise keine Idee.

MfG Spess

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Brocken Sei schrieb:

>>Na, dann präsentier doch mal deine Idee zu dem Thema
> Was willst du denn genaues wissen du Profi?

Einfach alles.

Also: wie ist die Idee, die hinter dem Algorithmus steckt, den du nicht 
benutzen kannst und was genau ist das Problem, dass du ihn nicht 
benutzen kannst?

Fang einfach mal damit an, den bestehenden Algorithmus zu beschreiben, 
damit man mal einen Eindruck davon bekommt, wie weit du bist.

Autor: Brocken Sei (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> Wo genau hast du das gesagt?

Beitrag 9, abissi nach oben schauen und auch zwischen den Zeilen lesen 
ist schon noch zu schaffen finde ich.

Karl heinz Buchegger schrieb:
> Aha. Du schreibst also nur so einfach irgendwas.

Das mache ich nicht ohne Grund, ich habe natürlich zu anderen 
Zeitpunkten auch anderes versucht, aber das noch nicht, wieso sollte ich 
nicht, ich hatte auch keine richtige Idee zu dem Algo, wieso bin ich 
dann hier?

Gruß Bro

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Brocken Sei schrieb:
> Karl heinz Buchegger schrieb:
>> Wo genau hast du das gesagt?
>
> Beitrag 9, abissi nach oben schauen und auch zwischen den Zeilen lesen
> ist schon noch zu schaffen finde ich.

Ne. nicht zwischen den Zeilen lesen.
Auch zwischen den Zeilen steht da nicht, dass du einen langsameren 
Follower selbst programmiert hast. Da steht nur, dass du einen gebaut 
hast. Das haben diejenigen die einen Asuro bauen auch. Und im Handbuch 
findet sich ein Linefollower. Fix, fertig. Draufspielen, laufenlassen. 
Das ist ungefähr so kreativ wie 'Malen nach Zahlen'.
Wenn ich zwischen den Zeilen lese, dann lese ich: Hilfe, ich will das 
gerne machen, hab aber noch nicht die leiseste Ahnung wie das 
prinzipiell gehen könnte.

Das lese ich zwischen den Zeilen.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also, was ist jetzt.

Kommt von dir eine Idee zu einem bestehenden Linefollower mitsamt den 
Problemen, die dich daran hindern, dieses Verfahren an deinem 
schnelleren Robot einzusetzen?

Vielleicht kann man ja die Probleme ausräumen. Wer weiß?

Autor: Brocken Sei (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
spess53 schrieb:
> Hi
>
> Erläutere mal diese Aussage:
>
>>Mein letztes Problem ist jetzt den Algorithmus in Assembler zu
>>schreiben. Ich habe aber dazu ansatzweise keine Idee.
>
> MfG Spess

Sry zu Spielerein habe ich echt keine Lust heute, wenn du von mir etwas 
wissen willst dann frag mich ganz offen spess. Aber ich vermute mal du 
willst darauf aus, dass ich Assembler überhaupt nicht beherrsche.
Wenn du etwas weiter gelsen hättest dann wäre folgendes gekommen:



>Mein
>Assemblerprogramm ist bis jetzt so weit, dass ich alle Sensorwerte
>auslese und in 1 Byte schreibe.

und wenn ich schon mal einen Linefollower gebaut und programmiert habe 
dann ist es doch logisch, dass ich programmieren muss oder?

Karl heinz Buchegger schrieb:
> Einfach alles.
>
> Also, wie ist die Idee, die hinter dem Algorithmus steckt, den du nicht
> benutzen kannst und was genau ist das Problem, dass du ihn nicht
> benutzen kannst.
>
> Fang einfach mal damit an, den bestehenden Algorithmus zu beschreiben.

Also ich wollte es so realisieren:
Sensorwerte ausmessen, in ein Byte schreiben, dann jedem Sensor 
Wertigkeit zuteilen, und dann rechne ich mir nach jedem ausmessen 
insgesamte Wertigkeit aus, und die Abweichung. Durch die Abweichung 
komme ich dann genau wie du schon sagtest auf die Prozent der Motoren.
Du hast mir aber empfohlen eine Liste zu machen und immer nachzuschauen 
welcher Zustand gerade aktiv ist um darauf zu reagieren, was ich für 
unsinnvoll hielt, da ich viel zu viel Zeit dafür brauche, und so kanst 
du zu deinen Annahmen.

Meine Problematik bei diesem Thread war es auf die Prozentwerte zu 
kommen und sie ist es immer noch, da ich einfach nicht weiß wann ich bei 
welchen Werten welchen Motor ansteuern soll, da ich nur negative und 
positive Werte habe.

Gruß Bro

Autor: Brocken Sei (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> Ne. nicht zwischen den Zeilen lesen.
> Auch zwischen den Zeilen steht da nicht, dass du einen langsameren
> Follower selbst programmiert hast. Da steht nur, dass du einen gebaut
> hast. Das haben diejenigen die einen Asuro bauen auch. Und im Handbuch
> findet sich ein Linefollower. Fix, fertig. Draufspielen, laufenlassen.
> Das ist ungefähr so kreativ wie 'Malen nach Zahlen'.
> Wenn ich zwischen den Zeilen lese, dann lese ich: Hilfe, ich will das
> gerne machen, hab aber noch nicht die leiseste Ahnung wie das
> prinzipiell gehen könnte.
>
> Das lese ich zwischen den Zeilen.

Also ich weiß echt nicht was der misst soll, scheinbar kannst du auch 
nicht richtig zwischen den Zeilen lesen, im ersten Beitrag steht da 
schon was von Assembler.
Was glaubst eig was du mit deinen Vorurteilen und Kritiken machst?

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Brocken Sei schrieb:

> Also ich wollte es so realisieren:
> Sensorwerte ausmessen, in ein Byte schreiben, dann jedem Sensor
> Wertigkeit zuteilen, und dann rechne ich mir nach jedem ausmessen
> insgesamte Wertigkeit aus, und die Abweichung. Durch die Abweichung
> komme ich dann genau wie du schon sagtest auf die Prozent der Motoren.
> Du hast mir aber empfohlen eine Liste zu machen

Von einer Liste war nirgends die Rede. Wenn µC etwas gut können, dann 
ist das rechnen. Da braucht es nicht unbedingt Tabellen.

> Meine Problematik bei diesem Thread war es auf die Prozentwerte zu
> kommen und sie ist es immer noch, da ich einfach nicht weiß wann ich bei
> welchen Werten welchen Motor ansteuern soll, da ich nur negative und
> positive Werte habe.

Man könnte ja zb die Differenz zwischen dem Seonsor links aussen und dem 
Sensor rechts aussen nehmen. Diese Differenz ist 0, wenn die Linie genau 
mittig zwischen den Sonsoren ist. Andernfalls bekommt man einen 
positiven bzw. negativen Wert für die Differenz, je nachdem auf welcher 
Seite der Linie man sich befindet.

Diese Differenz wird, mit einem Faktor gewichtet, auf die 
Nominaldrehzahl des linken bzw. rechten Motors aufgerechnet, so dass der 
Robot eine Kurve macht.

Und mein Vorschlag ist es, das einfach auszuprobieren. Wenn sich 
rausstellt, dass der Robbi nicht schnell genug dreht, dann erhöht man 
eben diesen Faktor. Dreht er zu schnell, verringert man den Faktor.
Vielleicht ist es sinnvoll den einen Motor zu beschleunigen und den 
anderen gleichzeitig zu bremsen um die Kurve zu kriegen, wenn die 
Differenz ein bestimmtes Mass überschreitet.

Aber das alles sind nur Zahlenwerte. Zahlenwerte die man anpassen kann, 
wenn man sieht, dass das Verfolgen der Linie nicht so funktioniert.

Der prinzipielle Algorithmus ist nach wie vor:
nimm die linken Sensorwerte, nimm die rechten Sensorwerte, setzte sie in 
eine Beziehung zueinenader (hier kann man kreativ sein) und bestimme aus 
der Sensordifferenz was du mit den Motoren machen willst.

Soweit waren wir vor einer Stunde schon.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Brocken Sei schrieb:

> Also ich weiß echt nicht was der misst soll, scheinbar kannst du auch
> nicht richtig zwischen den Zeilen lesen, im ersten Beitrag steht da
> schon was von Assembler.

Weißt du was.
Ich bin raus.
Vielleicht findet sich ja noch ein Hellseher, der so zwischen den Zeilen 
liest, wie du dir das vorstellst.

Die Chancen stehen aber schlecht. Denn genau das machen wir hier nur 
sehr ungern: zwischen den Zeilen lesen

Apropos: Über welchen Prozessor und damit welchen Assembler reden wir 
eigentlich? Oder stand das auch irgendwo zwischen den Zeilen?

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Wenn du etwas weiter gelsen hättest dann wäre folgendes gekommen:

>>Mein
>>Assemblerprogramm ist bis jetzt so weit, dass ich alle Sensorwerte
>>auslese und in 1 Byte schreibe.

Wenn das alles ist, bist du bei ca. 0,1 von 100. Träum weiter.

MfG Spess

Autor: Brocken Sei (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Brocken Sei schrieb:
> Von einer Liste wär nirgends die Rede.

Naja in deinen ersten Beiträgen war auch nie die Rede vom Rechnen 
gewesen, da war einfach nur das Ausprobieren und daraus schloss ich dass 
das einzige was du meinst mit ner Liste zu lösen wäre: Schauen welche 
Sensoren ansprechen --> entsprechende Reaktion durch nachschauen...

Karl heinz Buchegger schrieb:
> Der prinzipielle Algorithmus ist nach wie vor:
> nimm die linken Sensorwerte, nimm die rechten Sensorwerte, setzte sie in
> eine Beziehung zueinenader (hier kann man kreativ sein) und bestimme aus
> der Sensordifferenz was du mit den Motoren machen willst.

Das ist der Punkt auf den ich von vorn herein hinauswollte. Die 
Beziehungen kann man nicht irgendwie setzen, das muss schon ziemlich 
aussagekräftig für das Prgramm sein, die Motorwerte kann ich ja dann 
ausprobieren, da hast du recht.
Was ich aber erreichen will ist was besseres:

Sensorwerte messen
   |
   |
Digitalisieren
   |
   |
Abweichung ausrechnen (in möglichst kleinen effizienten Schritten)
   |
   |
Ausrechnen der PWM Werte für die Motoren
   |
   |
Wieder von vorn

Das wir meiner Meinung nach der effizienteste  Algorithmus und das 
schwierrige wo ich mir ein paar Tipps holen wollte sind die Schritte 3 
und 4.

Gruß Bro

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Brocken Sei schrieb:


> Das wir meiner Meinung nach der effizienteste  Algorithmus und das
> schwierrige wo ich mir ein paar Tipps holen wollte sind die Schritte 3
> und 4.

Du brauchst für eine Subtraktion bzw. Multiplikation und Addition Hilfe?

Ich zitiere:

Man könnte ja zb die Differenz zwischen dem Seonsor links aussen und dem
Sensor rechts aussen nehmen. Diese Differenz ist 0, wenn die Linie genau
mittig zwischen den Sonsoren ist. Andernfalls bekommt man einen
positiven bzw. negativen Wert für die Differenz, je nachdem auf welcher
Seite der Linie man sich befindet.

Diese Differenz wird, mit einem Faktor gewichtet, auf die
Nominaldrehzahl des linken bzw. rechten Motors aufgerechnet, so dass der
Robot eine Kurve macht.

Und mein Vorschlag ist es, das einfach auszuprobieren. Wenn sich
rausstellt, dass der Robbi nicht schnell genug dreht, dann erhöht man
eben diesen Faktor. Dreht er zu schnell, verringert man den Faktor.
Vielleicht ist es sinnvoll den einen Motor zu beschleunigen und den
anderen gleichzeitig zu bremsen um die Kurve zu kriegen, wenn die
Differenz ein bestimmtes Mass überschreitet.

Aber das alles sind nur Zahlenwerte. Zahlenwerte die man anpassen kann,
wenn man sieht, dass das Verfolgen der Linie nicht so funktioniert.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Brocken Sei schrieb:
> Brocken Sei schrieb:
>> Von einer Liste wär nirgends die Rede.
>
> Naja in deinen ersten Beiträgen war auch nie die Rede vom Rechnen
> gewesen,

OK. Geb ich zu.
Ich dachte eigentlich ein 'zwischen den Zeilen Leser wie du' schafft den 
gedanklichen Spaghat, dass man mit einem Computer rechnen könne.

Autor: Brocken Sei (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> Weißt du was.
> Ich bin raus.
> Vielleicht findet sich ja noch ein Hellseher, der so zwischen den Zeilen
> liest, wie du dir das vorstellst.
Ok, dann kann ich dir wohl nur für deine paar Tipps bedanken, auch wenn 
es mir wenig geholfen hat^^ gute nacht :)


> Die Chancen stehen aber schlecht. Denn genau das machen wir hier nur
> sehr ungern: zwischen den Zeilen lesen
Das habe ich nicht gewusst, dass ich auch jede Einzelheit, die nicht 
einmal zum Problem gehören so detalliert beschreiben muss, sry falls du 
dich jetzt verletzt fühlst.


>Apropos: Über welchen Prozessor und damit welchen Assembler reden wir
>eigentlich? AVR Assembler, Atmega 16

spess53 schrieb:
> Wenn das alles ist, bist du bei ca. 0,1 von 100. Träum weiter.
Spess, du bist aber der ärgste von allen^^

Grüße Bro

Autor: Brocken Sei (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> Man könnte ja zb die Differenz zwischen dem Seonsor links aussen und dem
> Sensor rechts aussen nehmen. Diese Differenz ist 0, wenn die Linie genau
> mittig zwischen den Sonsoren ist. Andernfalls bekommt man einen
> positiven bzw. negativen Wert für die Differenz, je nachdem auf welcher
> Seite der Linie man sich befindet.
>
> Diese Differenz wird, mit einem Faktor gewichtet, auf die
> Nominaldrehzahl des linken bzw. rechten Motors aufgerechnet, so dass der
> Robot eine Kurve macht.
>
> Und mein Vorschlag ist es, das einfach auszuprobieren. Wenn sich
> rausstellt, dass der Robbi nicht schnell genug dreht, dann erhöht man
> eben diesen Faktor. Dreht er zu schnell, verringert man den Faktor.
> Vielleicht ist es sinnvoll den einen Motor zu beschleunigen und den
> anderen gleichzeitig zu bremsen um die Kurve zu kriegen, wenn die
> Differenz ein bestimmtes Mass überschreitet.

Spitze, soetwas zB ist super. Ich hatte zwar nicht merhr damit 
gerechnet, dass du mir ein Beispiel zeigst aber in so einer ähnlichen 
Art hatte ich es vorgesehen.

>Aber das alles sind nur Zahlenwerte. Zahlenwerte die man anpassen kann,
>wenn man sieht, dass das Verfolgen der Linie nicht so funktioniert.
Das ist mir schon klar, das wäre ja nur das geringste Problem gewesen.

Danke für die Hilfe

Grüße Bro

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Brocken Sei schrieb:

> Das habe ich nicht gewusst, dass ich auch jede Einzelheit, die nicht
> einmal zum Problem gehören so detalliert beschreiben muss,

Na ja. Was erwartest du?

Du möchtest gerne Vorschläge haben. Noch weiß hier zb aber niemand was 
das für Sensoren sind. Haben die einen Erfassungskegel oder wechselt der 
Messwert schlagartig von 0 auf 1, wenn der Sensor sich über die Linie 
bewegt. Kann man aus dem Messwert ableiten, dass ein Sensor zu 1%, 5%, 
10% 50% oder gar zu 100% mit seinem Messkegel über der Linie ist.

Von all dem hängt letztende auch ab, was man im Schritt "die Sensoren 
für links und rechts in Beziehung zueinander setzen" machen kann und wie 
aussichtsreich das sit.

Der Prozessor und seine Taktfrequenz ist auch nicht ganz unwesentlich, 
denn davon hängt es ja schliesslich auch ab, was man sich an Formeln in 
einem Durchlauf durch die Regelschleife erlauben darf.

Wie schnell sind die Motoren? Wie schnell muss die Regelung greifen? Wie 
schnell können die Motoren bremsen? Wird überhaupt durch 
unterschiedliche Motordrehzahlen gelenkt oder gibt es wie bei einem Auto 
eine Lenkbare Vorderachse?

All das sind Dinge, die eventuell wichtig sein könnten.
Und du laberst hier rum, dass irgendwo zwischen den Zeilen steht, du 
hättest schon mal einen Linefollower programmiert.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Brocken Sei schrieb:

> Spitze, soetwas zB ist super. Ich hatte zwar nicht merhr damit
> gerechnet, dass du mir ein Beispiel zeigst aber in so einer ähnlichen
> Art hatte ich es vorgesehen.

Ähm.
Das ist ein Standard Linefollower, wie ihn 12 jährige auf ihrem Asuro 
nach 10 Minuten nachdenken implementieren.

Soviel zum Thema: Du hast sowas schon mal gemacht.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die eigentlich interessanten Punkte kommen dann nämlich noch :-)

Was tun, wenn der Robot die Linie verliert?

Wäre es möglich, dass der Robot sukzessive schneller wird, solange er 
keine Lenkkorrekturen machen muss und wieder langsamer wird, wenn er 
merkt das es in eine Kurve geht (Lenkbewegungen notwendig sind)?

Ganz fies sind auch:
Wie kommt man unbeschadet über eine sich gabelnde Linie drüber?

Was tun wenn die Linie in der Art eines T-Stücks in eine andere Linie 
einmündet?

Was ist bei einer Figur 8 im Kreuzungspunkt?

Kommt der Robot zurecht, wenn sich 2 parallel verlaufende Linien nahe 
kommen? Kann er eine Schlnngenlinie abfahren, wenn zwischen den Hin- und 
Rücklinien nur wenige Zentimeter liegen?

Autor: Brocken Sei (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> Ähm.
> Das ist ein Standard Linefollower, wie ihn 12 jährige auf ihrem Asuro
> nach 10 Minuten nachdenken implementieren.

Mir fehlte lediglich die Idee zu den 5 Sensoren und deren Auswertung, 
und das Programm sieht jetzt sicher nicht so aus, ich werde vermutlich 
meine Idee umsetzen, aber wie gesagt, Wenn man Beispiele gibt dann ist 
das 100 mal besser als ewig um den heißen Brei zu reden.

>Soviel zum Thema: Du hast sowas schon mal gemacht.
Ich glaube du willst und wirst es auch nicht verstehen, deshalb mache 
ich mir sicher nicht mehr die Mühe.

Karl heinz Buchegger schrieb:
> Du möchtest gerne Vorschläge haben. Noch weiß hier zb aber niemand was
> das für Sensoren sind. Haben die einen Erfassungskegel oder wechselt der
> Messwert schlagartig von 0 auf 1, wenn der Sensor sich über die Linie
> bewegt. Kann man aus dem Messwert ableiten, dass ein Sensor zu 1%, 5%,
> 10% 50% oder gar zu 100% mit seinem Messkegel über der Linie ist.

Ich hatte bereits erwähnt, dass die Sensorik schon fertig war, aber 
damit du mich nicht wieder mit einem Vorurteil angreifst, es sind cny70 
und deren Reaktionszeit ist ziemlich gut für meine Zwecke.

Karl heinz Buchegger schrieb:
> Der Prozessor und seine Taktfrequenz ist auch nicht ganz unwesentlich,
> denn davon hängt es ja schliesslich auch ab, was man sich an Formeln in
> einem Durchlauf durch die Regelschleife erlauben darf.

Richtig, das lass aber meine Sorge sein, ich möchte sicher nicht, dass 
du das ganze Projekt für micht machst, das wäre gerade bei dir unter 
meiner Würde, nichts für ungut.

Karl heinz Buchegger schrieb:
> Wie schnell sind die Motoren? Wie schnell muss die Regelung greifen? Wie
> schnell können die Motoren bremsen? Wird überhaupt durch
> unterschiedliche Motordrehzahlen gelenkt oder gibt es wie bei einem Auto
> eine Lenkbare Vorderachse?

Bremsen erfolgt bei meinen Motoren und dem L293D in 1 Sekunde, dann 
steht das Teil. Keine Vorderachse, nur Motor Links und Motor Rechts und 
über PWM, wobei ich mit PWM mittlereile auch shcon Probleme kriege, aber 
das ist eine andere Geschichte.

>All das sind Dinge, die eventuell wichtig sein könnten.
>Und du laberst hier rum, dass irgendwo zwischen den Zeilen steht, du
>hättest schon mal einen Linefollower programmiert.
Vielleicht bist ziemlich gut was Elektronik und MC angeht, aber ein 
schnellchecker bist du nicht unbedingt, ich habe einen programmiert und 
zwar genauso mit Assembler.

Gruß Bro

Autor: Grrrr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mein lieber Brocken,

Du bist einer der wenigen die es geschafft haben, Karl-Heinz Buchegger 
zur Aufgabe zu bringen. Er hingegen ist einer derjenigen Wenigen, die 
sich sonst alle Mühe geben auch dem Unbedarftesten zu helfen und wenn 
der sich noch so ungeschickt anstellt und das mit einer Geduld die ich, 
naja, überlegen läßt ob das Adjektiv "übermenschlich" hier nicht 
angebracht wäre.

Du darfst daraus schliessen, das es immer noch Steigerungs- um nicht zu 
sagen Erniedrigungspotential gibt.

Technik (egal ob als Hobby oder Beruf) ist vor allem erstmal eine 
Tätigkeit in der man mit "Verfahren", "Methoden", "Vorgehensweisen", 
meinetwegen auch "Kochrezepten" zu tun hat. Die muss man dann umsetzen, 
in einer Programmiersprache ausdrücken oder in eine Mechanik bzw. 
Elektronik umsetzen.

So wird man Dir auf Deine Frage hier, wie Karl-Heinz es getan hat, ein 
Verfahren erläutern. Sicherlich geht man da nicht in jedes Detail und 
auch wenn man tatsächlich "rechnen" muss, wobei man diesen Begriff noch 
weiter fasst, als das im Alltag der Fall ist, so wird das nicht immer 
ausdrücklich gesagt, genau wie aus der Auslassung diese Begriffes nicht 
zu schliessen ist, das eine Tabelle verwendet werden soll.

Ins Detail geht man deswegen nicht, weil das ja das wesentliche dieser 
Tätigkeit ausmacht. Einem Reiseleiter, der nicht weiss wie man nach 
Katar kommt, wird man ein oder zwei Zwischenstationen nennen, aber 
nicht, wie er in Budapest, das Anschlussticket kauft, weil das eine so 
grundlegende Tätigkeit ist, das man voraussetzt, das das nicht notwendig 
ist.
Genauso hat man bei Dir, der nach eigener Aussage, in Assembler 
programmiert, vorausgesetzt, das Du bei einer Beschreibung, wie dieser 
hier:

für immer
  wenn rechts ein höherer Wert gemeldet wird als links
  ja -> rechten Motor etwas schneller fahren lassen
  nein -> rechten Motor etwas langsamer fahren lassen
ende Schleife

von selbst weisst, wie man Werte vergleicht, wie man die Geschwindigkeit 
des Motors kontrolliert und das Dir klar ist, das die Beziehung zwischen 
dem, die Geschwindigkeit steuernden Zahlenwert und der Differenz der 
Werte von z.B. der Mechanik, den eingelesenen Werten etc. abhängt, die 
hier niemand wissen kann und die in der Praxis auch nur grob geschätzt 
und mit einem Korrekturfaktor von vorneherein in der Software 
berücksichtigt werden, so das man ihn durch Experiment bestimmen kann.
Ich wage zu behaupten, das absolut niemand den Versuch auch nur beginnen 
würden sämtliche Einflussfaktoren zur bestimmen und in eine Formel zu 
bringen damit der Korrekturfaktor von Anfang an stimmt. Das zu versuchen 
heisst aber, das man vielleicht mal in ein paar Sachen reinzuschnuppern, 
das grundlegene Problem der Differenz von Modell und Wirklichkeit aber 
nicht verstanden hat. Das man von bestimmten Aspekten der Welt zwar 
vollständige Modelle machen kann aber kein vollständiges Modell von 
allen Aspekten.
Und gerade das ist es was in dieser Tätigkeit getan wird: Modellieren 
und abschätzen welche Details man erfassen kann und sollte.

Wenn diese Gedankenwelt nicht Dein Ding ist, was ja sicherlich auch 
nicht sein muss, dann lass es besser.


Viel Glück beim nächstenmal.

Autor: Brocken Sei (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> Was tun, wenn der Robot die Linie verliert?
>
> Wäre es möglich, dass der Robot sukzessive schneller wird, solange er
> keine Lenkkorrekturen machen muss und wieder langsamer wird, wenn er
> merkt das es in eine Kurve geht (Lenkbewegungen notwendig sind)?
>
> Ganz fies sind auch:
> Wie kommt man unbeschadet über eine sich gabelnde Linie drüber?
>
> Was tun wenn die Linie in der Art eines T-Stücks in eine andere Linie
> einmündet?
>
> Was ist bei einer Figur 8 im Kreuzungspunkt?
>
> Kommt der Robot zurecht, wenn sich 2 parallel verlaufende Linien nahe
> kommen? Kann er eine Schlnngenlinie abfahren, wenn zwischen den Hin- und
> Rücklinien nur wenige Zentimeter liegen?

OK ziemlich nette Einwende von dir und das meine ich ernst, Gedanken 
habe ich mir schon deshalb gemacht, und mit meinem alten Linefollower 
kann ich da nicht ran, da ich die Motoren über ein Relais einschalte und 
kurzschließe, aber wie gesagt mein neuer Prototyp ist von der Hardware 
her schon beinahe fertig und Testversuche kommen erst im Laufe der 
nächsten Woche.

Aber wie gesagt danke ich dir für die Einwende.

Gruß Bro

Autor: Brocken Sei (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Grrrr schrieb:
> Mein lieber Brocken,
>
> Du bist einer der wenigen die es geschafft haben, Karl-Heinz Buchegger
> zur Aufgabe zu bringen. Er hingegen ist einer derjenigen Wenigen, die
> sich sonst alle Mühe geben auch dem Unbedarftesten zu helfen und wenn
> der sich noch so ungeschickt anstellt und das mit einer Geduld die ich,
> naja, überlegen läßt ob das Adjektiv "übermenschlich" hier nicht
> angebracht wäre.
>.
>.
>.
>.
>.
>.
>.
>
> Wenn diese Gedankenwelt nicht Dein Ding ist, was ja sicherlich auch
> nicht sein muss, dann lass es besser.
>
>
> Viel Glück beim nächstenmal.

Was soll denn das jetzt?
Ich fühl mich zwar sehr geschmeichelt über so manche Dinge die du gesagt 
hast, aber was bringt das den ganzen Thread zu analysieren und mich über 
die Punkte aufmerksam zu machen, die mir Karl schon erläutert hat?
Vermutlich denken alle hier ich verstehe nichts von Technik, und ich 
nehme es keinem übel weil mich ja keiner kennt, aber klar habe ich eine 
Ausbildung und das ist auch so langsam zu meinem Hobby geworden und ich 
finde es einfach falsch wenn man so kritisiert wird und mit Vorurteilen 
unter Druck gesetzt wird (was bei mir sowie so nie zum anschein kommt).

Das mal zu meiner Meinung.

Gruß Bro

Autor: Grrrr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mensch, Meier.

Dann mach es halt anders. Lass Dir die Sensorwerte auf ein Terminal 
ausgeben und halte und bewege die Sensoren über eine weisse Fläche mit 
einer schwarzen Linie. Versuche einen Zusammenhang zwischen den 
Sensorwerten und der Lage der Sensoren bzw. der Bewegung der Sensoren 
und der Veränderung der Sensorwerte zu formulieren.

Dann bist Du schon mal ein Stück weiter im Verständnis.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>>spess53 schrieb:
>> Wenn das alles ist, bist du bei ca. 0,1 von 100. Träum weiter.
>Spess, du bist aber der ärgste von allen^^

Ja. So etwas haben wir schon als (etwas grössere) Kinder vor etwa 40 
Jahren gebaut. Mit Taschenlampenbirne, zwei LDRs und ein paar 
Transistoren. Damit wurde ein Raupenlaufwerk mit 2 Motoren gesteuert.

Und ein paar Sensorwerte einzulesen und zu speichern ist nicht mehr als 
eine Fingerübung. Damit kann sich niemand brüsten.

Und wenn ich dann lese:

'es sind cny70...'

Das ist das Allerletzte, was ich an Reflexkopplern kenne.

MfG Spess

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich kann auch nicht glauben, daß der OP jemals einen Linefollower selber 
entwickelt hat. Dazu gibt er "zwischen den Zeilen" einfach viel zu wenig 
Ahnung preis.
Er hat uns ja nichtmal sagen können, welchen Assembler er hat (PIC, 
8051, AVR, ARM, MSP, C166, ...).
Ich würds aber eh nur in C proggen.

Wozu hat er überhaupt 5 Sensoren, wenn er nicht weis, was damit 
anzufangen ist.
Ich würde nur 3 Sensoren auswerten (Seiten gleichhell, Mitte dunkler).
Kriege ich nicht plausible Ergebnisse, dann verschiebe ich quasi die 
3-er Gruppe.

Der L293D mag zwar billig sein, dafür braucht man aber nen doppelt so 
großen Akku, weil er soviel selber verheizt.
z.B. der L6206 ist deutlich sparsamer und muß daher auch nicht gekühlt 
werden.


Peter

Autor: Brocken Sei (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
spess53 schrieb:
> Und wenn ich dann lese:
>
> 'es sind cny70...'
>
> Das ist das Allerletzte, was ich an Reflexkopplern kenne.

Achso? Welchen Reflexkoppler kennst du denn, der noch geeignet dafür 
wäre? ich kenne nur den und der ist ziemlich schnell und vom Preis her 
sehr billig, also wenn das nicht ausreicht weiß ich auch nicht weiter 
spess.

>Und ein paar Sensorwerte einzulesen und zu speichern ist nicht mehr als
>eine Fingerübung. Damit kann sich niemand brüsten.
Naja ich glaube ich habs schon 3/4 mal erwähnt, dass ich es bis zum 
Speichern habe. Denke an Schritt 3 und Schritt 4, vielleicht fällt dir 
sazu was ein^^

Peter Dannegger schrieb:
> Ich kann auch nicht glauben, daß der OP jemals einen Linefollower selber
> entwickelt hat. Dazu gibt er "zwischen den Zeilen" einfach viel zu wenig
> Ahnung preis.

Was willst du denn wissen?

Peter Dannegger schrieb:
> Er hat uns ja nichtmal sagen können, welchen Assembler er hat (PIC,
> 8051, AVR, ARM, MSP, C166, ...).

Doch habe ich, ist leider in einem Zitat reingekommen, aber wenn du dir 
die Beiträe anschaust dann wirst es finden.

Peter Dannegger schrieb:
> Ich würds aber eh nur in C proggen.
Damit war ja auch zu rechnen nachdem du mich auch kritisierst, also wenn 
man C nicht kann dann muss man schon beklopt sein.

>Wozu hat er überhaupt 5 Sensoren, wenn er nicht weis, was damit
>anzufangen ist.
Das habe ich nicht gesagt, wenn du dir die Beiträe genauer durchgelesen 
hättest dann wärst du draufgekommen, dass ich meine Idee schon 
presentiert habe, bei der Umsetzung hatte ich Probleme.

Peter Dannegger schrieb:
> Ich würde nur 3 Sensoren auswerten (Seiten gleichhell, Mitte dunkler).
> Kriege ich nicht plausible Ergebnisse, dann verschiebe ich quasi die
> 3-er Gruppe.
Naja damit wirst du bei einem Wettbewerb bestenfalls 40 ster, und nicht 
mal unter den Top 20.
So arbeitet auch mein alter LF, ist aber zu langsam die Sache, oder 
besser gesagt, dann musst du ja nur noch ein und ausschalten weil du nur 
mehr 2^3 Zustände hast, und somit auch nur wenige AUswertungen, und da 
hat PWM keinen Sinn, da ist sogar der Motortreiber den du später 
erwähnen wirst nicht vom Nutzen.

Peter Dannegger schrieb:
> Der L293D mag zwar billig sein, dafür braucht man aber nen doppelt so
> großen Akku, weil er soviel selber verheizt.
Da hast du vermutlich recht, ich hab mich aber für den L293D 
entschieden.

Gruß Bro

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Brocken Sei schrieb:

> Peter Dannegger schrieb:
>> Ich würds aber eh nur in C proggen.
> Damit war ja auch zu rechnen nachdem du mich auch kritisierst, also wenn
> man C nicht kann dann muss man schon beklopt sein.

Bekloppt nicht.
Aber es hilft.

In Assembler vernichtest du doch die meiste Entwicklungszeit mit 
unproduktiven Tätigkeiten, ohne dafür wirklich was zu kriegen
...

  while( 1 ) {
   int16_t Difference = SensorLeft - SensorRight;

   OCR1A = min( max( BasePWM + Faktor * Difference, 0 ), 255 );
   OCR1B = min( max( BasePWM - Faktor * Difference, 0 ), 255 );
 }

und fertig ist die erste Version zum testen.

Und wie lange brauchst du da in Assembler dafür, bis du soweit bist?

Genau dadurch, dass dir der Compiler den ganzen Kleinkram abnimmt, 
spielst du dir die Entwicklungszeit frei um unterschiedliche 
Algorithmen/Verfahren auszuprobieren bzw. zu variieren.

> Das habe ich nicht gesagt, wenn du dir die Beiträe genauer durchgelesen
> hättest dann wärst du draufgekommen, dass ich meine Idee schon
> presentiert habe,

Bei aller Nachsicht:
Idee hast du überhaupt keine präsentiert. Noch nicht einmal auf 
Nachfrage. Alles was gekommen ist, war allgemeines Bla Bla.

> bei der Umsetzung hatte ich Probleme

bei welcher Umsetzung?
Du hast weder eine Lösungsidee präsentiert, noch einen Algorithmus. Also 
nichts womit etwas anfangen könnte um zu sagen: Das implementierst du in 
Assembler am besten so und so. Oder: Wenn du diese Abfrage umdrehst, 
vereinfacht sich dieser Code.

Da war einfach nichts, womit man etwas anfangen könnte.

Hack, du hast ja noch nicht einmal eine Idee, wie du deine 5 Sensoren 
miteinander verrechnen könntest um daraus eine Aussage gewinnen zu 
können: mus ich links oder doch rechts, reicht ein bischen links oder 
dann doch eher scharf links.


Dein Ego in allen Ehren. Aber es wird Zeit, dass du vom hohen Ross 
herunter kommst und die Wahrheit akzeptierst. Wir sind hier kein 
Teeny-Forum bei dem man mit großer Klappe punkten kann. Hier zählt, was 
wer drauf hat! Und nicht was er gerne drauf hätte.

> Naja damit wirst du bei einem Wettbewerb bestenfalls 40 ster, und nicht
> mal unter den Top 20.

Sieh erst mal zu, dass dein Fahreug überhaupt fährt.

Noch glaubt dir hier nämlich keiner, dass du überhaupt je so etwas schon 
mal selbst gemacht hast. Dazu zeigst du dich zu unwissend, was die 
Details angeht.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Brocken Sei schrieb:
> Naja damit wirst du bei einem Wettbewerb bestenfalls 40 ster, und nicht
> mal unter den Top 20.
> So arbeitet auch mein alter LF, ist aber zu langsam die Sache, oder
> besser gesagt, dann musst du ja nur noch ein und ausschalten weil du nur
> mehr 2^3 Zustände hast, und somit auch nur wenige AUswertungen, und da
> hat PWM keinen Sinn, da ist sogar der Motortreiber den du später
> erwähnen wirst nicht vom Nutzen.

Du mußt schon etwas länger nachdenken. Wenn Du alles von Anfang an 
verwirfst, wir das nie was. 2^3 Zustände ist einfach lächerlich.

Die 3 Sensoren stellen erstmal fest, ob Du in der Spur bist und dann ist 
die Differenz der beiden äußeren Sensoren proportional zur Abweichung, 
d.h. geht zur PWM.
Bist Du nicht mehr in der Spur, testest Du die anderen Sensoren, dann 
wird die PMW eben 10µs später gesetzt. So ein paar Ifs kosten doch keine 
Rechenzeit.
Erst wenn Du nirgends plausible Werte kriegst, mußt Du eine Suchfahrt 
machen.

Also ganz einfach gesagt:
- Plausibilitätstest
- 2 Analogwerte in Abweichung umrechnen
- PWM


Peter

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier mal ein grober Schnellschuß für den Plausibiltätstest:
x h d h x -> gerade
h d h x x -> links
x x h d h -> rechts
d h h x x -> scharf links
x x h h d -> scharf rechts

Natürlich muß man noch Toleranzfenster drüber legen und Korrekturwerte 
(Gain, Offset jedes Sensors) einberechnen. Macht sich in C bedeutend 
leichter.


Peter

Autor: Brocken Sei (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Karl
Ich bin hier sicher nicht damit mir irgendjemand glaubt dass ich schon 
mal so etwas gemacht habe und es auch funktioniert hat. Ich muss ein 
Problem lösen und habe ein Verständnisproblem beim Ausrechnen der 
AUsweichung gehabt, daher habe ich einen Thread aufgemacht in der 
Hoffnung, dass mir jemand hilfreiche Tipps geben könnte. Ich bin der 
letzte der behauptet der beste von allen zu sein, denn damit macht man 
sich nur lächerlich, ich bin auch kein Beamter und Geschäftsmann oder 
ein möchtegern.
Ich habe mir ein Ziel vorgenommen und möchte das realisieren, egal 
wieviel kritiken und falsches Zeugs über mich gesagt wird, wie gesagt 
ich verstehe das weil mich keiner kennt und dass man sich hier scheinbar 
Hilfe hart verdienen muss war mir nicht klar.
Wahrscheinlich hast du damit Recht wenn du sagst C ist einfacher und 
Zeitsparender, das ist eine Tatsache, aber dass das eine Hochsprache ist 
ist auch eine Tatsache, und jedes Detail werde ich nie so kontollieren 
können wie in Assembler wurde mir gesagt, und da ich auch in Bascom 
Programmiere bestätige ich den Unterschied zwischen Hochsprache und 
Maschinennahespache.

>Die 3 Sensoren stellen erstmal fest, ob Du in der Spur bist und dann ist
>die Differenz der beiden äußeren Sensoren proportional zur Abweichung,
>d.h. geht zur PWM.
Stimmt, PWM geht da auch, da habe ich nicht viel möglichkeiten nur 
links, links-mitte, mitte, mitte-rechts und rechts. Ich habe das aber 
bei meinem alten anders gelöst. Ich habe nur drei Möglichkeiten 
betrachtet:
Ich habe zuerst den mittleren Sensor ausgemessen und dann in das Byte 
geschrieben, dann den linken und dann den rechten, durch diesen Trick 
konnte es nicht dazu kommen dass 2 Sensoren zur gleichen Zeit aktiviert 
aren, weil ich das Byte immer überschrieben habe und durch das Ein und 
Ausschalten(Das ausschalten erfolgt durch das Kurzschließen des 
Wechslers vom Realis das als Treiber verwendet wird) die PWM 
geschmissen.
Also hast du recht, mit 3 Sensoren könnte ich anfangen und werde es 
auch.

Gruß Bro

Autor: Wegstaben Verbuchsler (wegstabenverbuchsler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Brocken Sei (Gast)

irgendwie scheinst du die "Richtung" zu verwechseln, wer Informationen 
hat und wer welche haben möchte.

ISt es denn nicht so, daß DU Anregungen und Ideen haben möchtest, un 
arüber diskutieren möchtest?


> Mein letztes Problem ist jetzt den Algorithmus in Assembler zu
> schreiben. Ich habe aber dazu ansatzweise keine Idee.

Quelle: Wikipedia:
"Ein Algorithmus (auch Lösungsverfahren) ist eine formale 
Handlungsvorschrift zur Lösung eines Problems oder einer bestimmten Art 
von Problemen  in endlich vielen Schritten. "

--> Dein gesuchtes Lösungsverfahren hat NIX mit Assembler zu tun. Du 
kannst es auch in klingonisch oder als Programm-Ablaufplan oder in 
sonstewas beschreiben.


> Mein Assemblerprogramm ist bis jetzt so weit, dass ich alle Sensorwerte
> auslese und in 1 Byte schreibe.

Jau, das ist schon mal was. Einen Istwert einlesen und abspeichern. 
Deine Ausgaberoutine ist ja auch schon fertig: Einen Stellwert ausgebenn 
und den Transistor ansteuern. Dazwischen fehlt halt nur das 
"klitzekleine" Stückchen Code, der die richtigen Werte ausgibt. Aber 
macht ja nix, das "wichtigste", nämlich die Ein- und Ausgabe, hast du ja 
schon fertig.

Auch ein "Programm" zur Errechnung der Lottozahlen für die nächste 
Ziehung kann man kann man so ähnlich ansehen wie deine Aufgabenstellung: 
Vorne kommen die alten Lottozahlen rein, und hinten kommt eine 
Druckroutine, welche einen leeren Lottoschein mit den errechneten Zahlen 
bedruckt. Dazwischen fehlt halt nur das "klitzekleine" Stückchen Code, 
der die richtigen Werte ausgibt.Aber macht ja nix, das "wichtigste", 
nämlich die Ein- und Ausgabe, hast du ja schon fertig.

--> Deine Ein- und Ausgabesachen sind zwar notwendig, aber für die 
gegebene AUfgabenstellung eher total nachrangig.

> Nun weiß ich echt nicht weiter, kann mir jemand helfen?

ja, es kamen einige konstruktive Vorschläge von verschiendene 
Teilnehmern. Es gab auch konstruktive Rückfragen von einigen 
Teilnehmern. Beides hast du jedoch nicht als Hilfe wahr genommen, 
sondern als persönliche Kritik oder Angriff.

--> deswegen: Formuliere so genau wie du kannst das was du weißt, das 
was du nicht weist, und das was du wissen möchtest

Autor: Michael H. (michael_h45)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
2^3 Zustände... 2^5 Zustände... LOL

Autor: Floh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aus Erfahrung würd ich dir wie spess auch von den cny70 abraten. Nimm 
lieber Fototransistoren, die auf den Boden zeigen und beleuchte den 
Boden mit einer Glühbirne (ist besser als LEDs wegen dem breiten 
Spekrum).

Nun liest man sämtliche Werte periodisch ein und speichert sie ab.
Dann kommt eine Berechnug mit Gewichtung der ermittelten Werte, außen 
stärker als die inneren und dann raus auf die Motoren.
;-) Viel Spaß dabei.

Ps.: In der Robotik muss man viel testen, ein Programm, das am Anfang 
alles zu berücksichtigen versucht, wird nicht funktionieren.
Lieber stückweise schreiben, testen, schreiben, testen...
Und ein Programm ist nie vollständig perfekt.:-)

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Brocken Sei schrieb:

> Wahrscheinlich hast du damit Recht wenn du sagst C ist einfacher und
> Zeitsparender, das ist eine Tatsache, aber dass das eine Hochsprache ist
> ist auch eine Tatsache, und jedes Detail werde ich nie so kontollieren
> können wie in Assembler wurde mir gesagt,

Das ist zwar grundsätzlich in einem gewissen Sinne richtig. Und trotzdem 
benutzt du die falsche Voraussetzung für die Argumentation.
Die Kernfrage muss nämlich lauten: Brauche ich diese Kontrolle über den 
letzten Taktzyklus überhaupt, oder mache ich mir da etwas vor?


Ein etwas ungeübter Assemblerprogrammierer produziert Code, den der 
Compiler leicht schlagen kann.

Ein durchschnittlicher Assembler Programmierer liegt mit dem Compiler in 
etwa gleich auf

Lediglich ein guter Assembler Programmierer schlägt einen Compiler. 
Wobei man aber auch das relativieren muss. Wir reden hier von 
Laufzeitgewinnen im in-etwa-einstelligen Prozentbereich. Also so 5% bis 
vielleicht 10%. Mehr ist für einen guten Assemblerprogrammierer nicht 
drinnen und da muss er schon ziemlich gut sein.

Es gibt natürlich Ausnahmen. Will man ein FBAS Video-Signal erzeugen, 
bei dem es auf jeden Taktzyklus in einer ISR ankommt, führt kein Weg an 
Assembler vorbei. Es gibt sicherlich noch andere Anwendungen, die in 
dieselbe Kategorie fallen, aber die Mehrzahl der Anwendungen tun es eben 
nicht. Und nein, deine tut es mit Sicherheit auch nicht. Ob dein µC 
jetzt 1µS mehr oder weniger für den Rechenvorgang benötigt, spielt keine 
Rolle. So schnell kann dein Robbi physikalisch nicht fahren :-)

Dieses bischen Zeit holt man im übrigen meistens durch bessere 
Algorithmen leicht wieder herein. Wie überhaupt Optimierungen auf der 
algorithmischen Ebene anfangen müssen. Dort sind die spektakulären 
Optimierungs-Potentiale beheimatet. Und nicht auf der Ebene, auf der man 
vielleicht das T-Flag zum Transfer eines Bits von einem Register in ein 
anderes einsetzen kann.
Dazu muss ich aber mein Programm schnell und einfach ändern können. Und 
das geht nun mal bei komplexeren Programmen nicht, wenn ich ständig die 
Belegung aller Register im Hinterkopf halten muss und ob ich an dieser 
Stelle das Carry-Flag zerstören darf oder ob das 5 Anweisungen später 
noch gebraucht wird (nur um jetzt einmal stellvertretend 2 Problemkreise 
herauszupicken, mit denen man sich als Assemblerprogrammierer 
rumschlagen muss. Es gibt noch mehr davon)


> und da ich auch in Bascom
> Programmiere bestätige ich den Unterschied zwischen Hochsprache und
> Maschinennahespache.

BASCOM ist dahingehend ein eher schlechtes Beispiel, auch wenn ich das 
nur dem Hörensagen nach kenne. Die Optimierungen, die dieser Compiler 
anstellt sollen nicht so besonders die Wucht sein.

Autor: Brocken Sei (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wegstaben Verbuchsler schrieb:
> irgendwie scheinst du die "Richtung" zu verwechseln, wer Informationen
> hat und wer welche haben möchte.
>
> ISt es denn nicht so, daß DU Anregungen und Ideen haben möchtest, un
> arüber diskutieren möchtest?
>
>
>> Mein letztes Problem ist jetzt den Algorithmus in Assembler zu
>> schreiben. Ich habe aber dazu ansatzweise keine Idee.
>
> Quelle: Wikipedia:
> "Ein Algorithmus (auch Lösungsverfahren) ist eine formale
> Handlungsvorschrift zur Lösung eines Problems oder einer bestimmten Art
> von Problemen  in endlich vielen Schritten. "
>
> --> Dein gesuchtes Lösungsverfahren hat NIX mit Assembler zu tun. Du
> kannst es auch in klingonisch oder als Programm-Ablaufplan oder in
> sonstewas beschreiben.
>
>
>> Mein Assemblerprogramm ist bis jetzt so weit, dass ich alle Sensorwerte
>> auslese und in 1 Byte schreibe.
>
> Jau, das ist schon mal was. Einen Istwert einlesen und abspeichern.
> Deine Ausgaberoutine ist ja auch schon fertig: Einen Stellwert ausgebenn
> und den Transistor ansteuern. Dazwischen fehlt halt nur das
> "klitzekleine" Stückchen Code, der die richtigen Werte ausgibt. Aber
> macht ja nix, das "wichtigste", nämlich die Ein- und Ausgabe, hast du ja
> schon fertig.
>
> Auch ein "Programm" zur Errechnung der Lottozahlen für die nächste
> Ziehung kann man kann man so ähnlich ansehen wie deine Aufgabenstellung:
> Vorne kommen die alten Lottozahlen rein, und hinten kommt eine
> Druckroutine, welche einen leeren Lottoschein mit den errechneten Zahlen
> bedruckt. Dazwischen fehlt halt nur das "klitzekleine" Stückchen Code,
> der die richtigen Werte ausgibt.Aber macht ja nix, das "wichtigste",
> nämlich die Ein- und Ausgabe, hast du ja schon fertig.
>
> --> Deine Ein- und Ausgabesachen sind zwar notwendig, aber für die
> gegebene AUfgabenstellung eher total nachrangig.
>
>> Nun weiß ich echt nicht weiter, kann mir jemand helfen?
>
> ja, es kamen einige konstruktive Vorschläge von verschiendene
> Teilnehmern. Es gab auch konstruktive Rückfragen von einigen
> Teilnehmern. Beides hast du jedoch nicht als Hilfe wahr genommen,
> sondern als persönliche Kritik oder Angriff.

Ich verstehe einfach nicht wieso immer wieder Leute versuchen sich zu 
verbünden und stark zu sein und die schwachen angreifen(mit schwach 
meine ich noch nicht bekannt im Forum), obwohl sie nun überhaupt nichts 
sinnvolles dazu beitragen. Dein Beitrag war ein wirklich unnötiger 
Versuch mir weiszumachen dass ich keine Ideen und Versuche schon gemacht 
habe und dass ich keine Algorithmen schreiben kann oder geschrieben habe 
in verschiedenen Programmiersprachen, aber es ist ja immer das selbe.
Ich hoffe du wirst nie sowie ich jetzt runtergemacht (nicht dass es mich 
stört, ich bin ja selbstbewusst und ehrgeizig) aber wenn man schon so 
auf andere losgeht, dann ist das 100%ig ein Zeichen dafür dass man 
selbst kein Opfer sein will (nicht dass ich mich als eins empfinde).

> --> deswegen: Formuliere so genau wie du kannst das was du weißt, das
> was du nicht weist, und das was du wissen möchtest
Das ist nett ausgedrückt, aber ich glaube hier wurde alles schon gesagt, 
ich bin schon dabei meine Idee zu verwirklichen.

>Aus Erfahrung würd ich dir wie spess auch von den cny70 abraten.
Aus welchem Grund? Ich kann keinerlei Nachteile aufweisen, mein alter LF 
fährt ziemlich zuverlässig mit denen und ist noch nie rausgekommen.

Floh schrieb:
> Ps.: In der Robotik muss man viel testen, ein Programm, das am Anfang
> alles zu berücksichtigen versucht, wird nicht funktionieren.
> Lieber stückweise schreiben, testen, schreiben, testen...
> Und ein Programm ist nie vollständig perfekt.:-)

Ich weiß, das war mir schon Bewusst bevor ich den Thread erstellt habe 
:)

Gruß Bro

Autor: Floh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Brocken Sei schrieb:
>>
>>> Mein Assemblerprogramm ist bis jetzt so weit, dass ich alle Sensorwerte
>>> auslese und in 1 Byte schreibe.

Der Verdacht, der sich bei mir einschleicht mit 2^3 bzw 2^5 
Möglickeiten:

Speicherst du etwa nur die Information Linie da / nicht da pro Sensor 
als Bitstelle in dieses Byte?
Wenn ja kannste einen Regelalgorithmus in die Tonne treten...

Autor: Brocken Sei (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Floh schrieb:
> Speicherst du etwa nur die Information Linie da / nicht da pro Sensor
> als Bitstelle in dieses Byte?

Ja das ist richtig.

Floh schrieb:
> Wenn ja kannste einen Regelalgorithmus in die Tonne treten...

Wieso das? Meinst du mit Regelalgorithmus PID, P oder PI?
Naja das wäre dann mein zweites Ziel gewesen, aber zuerst will ich das 
durch fixe Motorwerte steuern und durch ausprobieren die ideale 
Steuerung dranlassen.

Wieso meinst du dass das mit PID nicht geht wenn ich feststelle welche 
Sensoren gerade auf der Linie sind  und das in ein Byte darstelle?
Ich habe mit 5 - 7 Sensoren genug Auflösung um PID oder meine jetzige 
Idee umzusetzen oder?

Gruß Bro

Autor: Floh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im Normalfall wertet man die Sensoren aus und gewichtet die 
Helligkeitsunterschiede, so nach dem Motto, der Sensor  mitte rechts ist 
ein bisschen dunkler als der Sensore mitte links, der Unterschied macht 
deutlich, dass die Linie nach rechts abdriftet, und dem regelt man dann 
entgegen.
Was du machst ist nichts anderes als ne verkümmerte Statusabfrage, kein 
Wunder das das langsam ist, da du ja erst reagieren kannst, wenn der 
Roboter schon nicht mehr richtig auf der Linie ist (sobald das Bit 
umklappt).
:-)

Autor: Wegstaben Verbuchsler (wegstabenverbuchsler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wieso meinst du dass das mit PID nicht geht wenn ich feststelle welche
> Sensoren gerade auf der Linie sind  und das in ein Byte darstelle?
> Ich habe mit 5 - 7 Sensoren genug Auflösung um PID oder meine jetzige
> Idee umzusetzen oder?

Schau dir mal einen Zweipunkt- oder Dreipunkt-Regler an, bsp:
http://de.wikipedia.org/wiki/Dreipunktregler

derartige unstetige Regler könenn halt nur "im Groben" einen 
vorgegebenen Sollwert einhalten.

Wo sitzen eigentlich deine 3, 5 oder 7 Sensoren in der gesamten 
Anordnung?

muß man sich das als lineare Anordnung vorstellen, welche "von links 
nach rechts" quer unter deinem Roboter sitzt?


Und welche Form ist der Antrieb (linkes/rechtes vorderrad angetrieben, 
Kette wie bei einem Panzer etc)

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bau doch deine Idee erst mal mit 2 oder 3 Sensoren.

Man kann übrigens auch einen Linefollower mit einem Sensor bauen, der 
stößt aber bei den von Karl genannten Situationen an seine Grenzen.

Brocken Sei schrieb:
> Wieso das?
lass die Bitknauserei. 5 Byte für separate Werte werden wohl da sein.

Wenns am Ende knapp wird, kannst du das immer noch optimieren, wenn der 
komplette Code fast da ist.
Außerdem kostet Bitschupserei extra Zeit.

außerdem hat ein 8bit Helligkeitswert doch mehr Informationen.
du kannst da quasi noch Subpixel-Infos rausziehen. Also Line Halb unter 
dem Sensor, oder nicht. Je nach Abstand, Öffnugnswinkel, Rauschen kann 
das nützlich sein.
Außerdem ermöglicht dir dies, dich an unterschiedliche 
Beleuchtungssituationen anzupassen. Wenn du im Laufe einer Fahrt merkst, 
das dunkel wird heller, oder das Weiß wird dunkler (Unterscheidliche 
Winkel zur Bahnbeleuchtung), kann man die Schwellenwerte angleichen.

Autor: Bohrer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wer schon sooo viele Line Follower gebaut hat MUSS solche Infos nicht 
preisgeben....

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Brocken Sei schrieb:
> Ich weiß, das war mir schon Bewusst bevor ich den Thread erstellt habe
> :)

Dir war offenbar schon alles bewusst, bevor Du den Thread erstellt 
hast. Nur ... warum hast Du ihn dann überhaupt erstellt? Um mich zu 
erheitern?

Danke, ist Dir gelungen :-)

Gruß,

Frank

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Brocken Sei schrieb:
> Floh schrieb:
>> Speicherst du etwa nur die Information Linie da / nicht da pro Sensor
>> als Bitstelle in dieses Byte?
>
> Ja das ist richtig.

Jetzt wird mir so einiges in diesem Thread plötzlich sonnenklar.

> Wieso meinst du dass das mit PID nicht geht wenn ich feststelle welche
> Sensoren gerade auf der Linie sind  und das in ein Byte darstelle?
> Ich habe mit 5 - 7 Sensoren genug Auflösung um PID oder meine jetzige
> Idee umzusetzen oder?

Du schenkst jede Menge 'Auflösung' her, indem du den ADC Wert auf 
schwarz/weiß festnagelst.

So ein Sensor tastet die Unterlage ja nicht in einem infinitesimal 
kleinen Punkt ab, sondern hat ein gewisses Gesichtsfeld. Wandert die 
Linie in dieses Gesichtsfeld hinein, so beginnt sich der ADC Wert zu 
verändern. D.h. Anhand des ADC Wertes kannst du schon eine Aussage 
treffen, ob der Sensor zu 10%, zu 40% oder zu 100% über der Linie (oder 
eben gleichermassen neben der Linie) ist.

Das heißt aber auch, du könntest damit eine leichte Abweichung vom Kurs 
von einer groben Abweichung vom Kurs unterscheiden. Eine leichte 
Abweichung liegt vor, wenn ein seitlicher Sensor nur wenig von der Linie 
sieht. Wird sie nicht korrigiert, so wandert die Linie 
selbstverständlich immer mehr von der Mittellinie des Robots aus. Aber: 
eine leichte Abweichung braucht auch nur eine leichte Korrektur.

Du fährst ja auch nicht Auto, indem es nur 2 Gassstellungen und entweder 
vollen Linksausschlag, vollen Rechtsausschlag oder Geradeaus_fahren 
gibt. Je nach festgestellter Abweichung von der Fahrbahnmitte fallen die 
Lenkkorrekturen mal zart und mal heftiger aus.

Dadurch das du dir die ADC Werte schon ganz am Anfang deiner 
Verarbeitung in ein schwarz/weiß Schema presst, wirfst du Information 
weg, die du auch mit mehr Sensoren nicht mehr oder nur sehr schwer 
wieder aufwiegen kannst. Und da hilft dir auch ein PID Regler nicht 
wirklich weiter. Denn auch der kann keine Wunder bewirken.


Und bitte entschuldige, dass ich deine Sensorbehandlung nicht gleich in 
deinem Urposting zwischen den Zeilen herausgelesen habe. (Sorry. Aber 
das konnte ich mir jetzt nicht verkneifen)

Autor: nefuas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
brocken
oder
broken ?

Autor: Zwei Fler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nefuas schrieb:
> brocken
> oder
> broken ?

Natürlich "brocken"
Vorname: "Sich was ein-"

:-)

Nach dem vierten oder fünften Posting hatte ich das Gefühl, dass jemand 
hier einen neuen Forums-Troll-Bot testet.
Erinnert irgendwie an das klassische "Elisa" Programm, das auf ein paar 
Stichworte regiert und ansonsten die beleidigte Leberwurst spielt.

Ist aber gut gemacht...

Autor: Brocken Sei (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Wegstaben Verbuchsler schrieb:
> Wo sitzen eigentlich deine 3, 5 oder 7 Sensoren in der gesamten
> Anordnung?
>
> muß man sich das als lineare Anordnung vorstellen, welche "von links
> nach rechts" quer unter deinem Roboter sitzt?
>
>
> Und welche Form ist der Antrieb (linkes/rechtes vorderrad angetrieben,
> Kette wie bei einem Panzer etc)

Siehe Bilder. Das würde ich sagen ist der Brockenator^^

Vlad Tepesch schrieb:
> 5 Byte für separate Werte werden wohl da sein.

Das ist mal sehr schön formuliert, und wenn ich jetzt nur noch so einen 
Sensor finde der mir mit deiner 8bit Auflösung auch noch sagt wie 
hell/dunkel das auch noch ist, dann wär das perfekt.
Nein ehrlich jetzt die Idee ist spitze, aber ich habe bisher noch nie 
von so einem Sensor gehört.

Vlad Tepesch schrieb:
> außerdem hat ein 8bit Helligkeitswert doch mehr Informationen.
> du kannst da quasi noch Subpixel-Infos rausziehen. Also Line Halb unter
> dem Sensor, oder nicht. Je nach Abstand, Öffnugnswinkel, Rauschen kann
> das nützlich sein.
> Außerdem ermöglicht dir dies, dich an unterschiedliche
> Beleuchtungssituationen anzupassen. Wenn du im Laufe einer Fahrt merkst,
> das dunkel wird heller, oder das Weiß wird dunkler (Unterscheidliche
> Winkel zur Bahnbeleuchtung), kann man die Schwellenwerte angleichen.

Mhm meinst du etwa sowas wien LDR? Ich hab mal gehört die sollen 
Reaktionszeiten im ms Bereich haben, mein gaaaaanz erster Linefollower 
(der alte ist eigentlich der zweite) hat mit 3 LDRs funktioniert, die 
zwar 1 Bit hatten aber der Robo ist beim Wettbewerb jedesmal irgendwo 
rausgekommen, und nicht nur beim Wettbewerb. Ich konnte einfach nicht 
die Einflüsse von aussen kontrollieren, das ist mords aufwendig gewesen. 
Also wenn du da einen guten schnellen Sensor kennst dann bitte ich darum 
ihn zu sagen.

Frank M. schrieb:
> Danke, ist Dir gelungen :-)

kP!

Karl heinz Buchegger schrieb:
> Du schenkst jede Menge 'Auflösung' her, indem du den ADC Wert auf
> schwarz/weiß festnagelst.

Ja aber das könnte ich mit sehr vielen Sensoren ausgleichen, 12 oder so, 
dazwischen einen Schmitttrigger und schon hat sich die Auswertung.
Jedoch gefällt mir der vorher erwähnte Sensor vom Vlad Tepesh sehr viel 
besser oder auch nicht weil der 5 Byte hat und ich dann wahrscheinlich 
per I2C auswerten muss, oder ich nehme einen 32 Bit uC, auf was ich 
nicht gerade aus bin.

Karl heinz Buchegger schrieb:
> So ein Sensor tastet die Unterlage ja nicht in einem infinitesimal
> kleinen Punkt ab, sondern hat ein gewisses Gesichtsfeld. Wandert die
> Linie in dieses Gesichtsfeld hinein, so beginnt sich der ADC Wert zu
> verändern. D.h. Anhand des ADC Wertes kannst du schon eine Aussage
> treffen, ob der Sensor zu 10%, zu 40% oder zu 100% über der Linie (oder
> eben gleichermassen neben der Linie) ist.

Das wär mir zwar eine Überlegung Wert, aber ich weiß jetzt nicht in 
wiefern ich den Algorithmus(Auswertung) damit verschlechtere bzw muss 
ich mir das ganze neu überlegen.
Bist du dir sicher dass das so ohne weiteres Funktioniert, weil die LED 
schaut ja nicht raus, die ist drinn und schaut mir eher wie ein Punkt 
aus als wie wenn sie viel ausstrahlen würde.

Karl heinz Buchegger schrieb:
> Und bitte entschuldige, dass ich deine Sensorbehandlung nicht gleich in
> deinem Urposting zwischen den Zeilen herausgelesen habe.
Du kannst es einfach nicht lassen Karl.

Zwei Fler schrieb:
> Nach dem vierten oder fünften Posting hatte ich das Gefühl, dass jemand
> hier einen neuen Forums-Troll-Bot testet.
> Erinnert irgendwie an das klassische "Elisa" Programm, das auf ein paar
> Stichworte regiert und ansonsten die beleidigte Leberwurst spielt.

puuuff, das ist aber weit hergeholt, findest du nicht?

Gruß Bro

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
2 Worte
Photo  Transistor

Autor: Brocken Sei (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> Photo  Transistor

Jetzt weiß ich warum die besten LF keine fertigen Sensoren haben.
Dh es scheitert bei mir schon an der Sensorik, na dann weiß ich was ich 
jetzt besser machen kann, danke dir Karl
die Auswertung wird halt ein bisschen komplizierter aber das wars ja 
auch schon, vielleicht bietet sich das ja doch an mit C zu schreiben 
damit das ganze übersichtlich bleibt...

Gruß Bro

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier ist das Handbuch zum Asuro

http://www.produktinfo.conrad.com/datenblaetter/17...

Auf Seite 74 ist der komplette Schaltplan. Die Transistoren T9 und T10 
sind die Senosren für die Linienverfolgung.

Und das reicht immerhin schon, das ein Asuro 'Köpfchen in der Höhe' 
balancieren kann, indem er die Motoren so ansteuert, dass die 
Liniensensoren einen immer konstanten Wert liefern.

Youtube-Video "Balancing ASURO"

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Brocken Sei schrieb:

> die Auswertung wird halt ein bisschen komplizierter

wird auch nicht komplizierter.

Ab damit an den ADC und vom ADC den Messwert (Spannung) auslesen lassen.

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Brocken Sei schrieb:
> Das ist mal sehr schön formuliert, und wenn ich jetzt nur noch so einen
> Sensor finde der mir mit deiner 8bit Auflösung auch noch sagt wie
> hell/dunkel das auch noch ist, dann wär das perfekt.

Häh?
was benutzt du denn für sensoren?

> Nein ehrlich jetzt die Idee ist spitze, aber ich habe bisher noch nie
> von so einem Sensor gehört.
Ich glaub du hast das falsche Hobby.

Brocken Sei schrieb:
> Mhm meinst du etwa sowas wien LDR?

nein, LDR ist fiel zu langsam.

Was spricht denn, gegen handelsübliche Phototransistoren?
Messen über Spannungsteiler.
Widerstand grob berechnen und ausprobieren, wie er sich unter dem 
Fahrzeug verhält und was er für Werte liefert - dann den Widerstand so 
anpassen, dass der ADC-Bereich möglichst gut genutzt wird.
http://www.mikrocontroller.net/articles/Lichtsenso...

Brocken Sei schrieb:
> Das wär mir zwar eine Überlegung Wert, aber ich weiß jetzt nicht in
> wiefern ich den Algorithmus(Auswertung) damit verschlechtere bzw muss
> ich mir das ganze neu überlegen.

vor allen Dingen, solltest du das in C coden, sonst wirst du nie fertig.

Brocken Sei schrieb:
> Bist du dir sicher dass das so ohne weiteres Funktioniert, weil die LED
> schaut ja nicht raus, die ist drinn und schaut mir eher wie ein Punkt
> aus als wie wenn sie viel ausstrahlen würde.
welche LED?

Brocken Sei schrieb:
> Ja aber das könnte ich mit sehr vielen Sensoren ausgleichen, 12 oder so,
> dazwischen einen Schmitttrigger und schon hat sich die Auswertung.
> Jedoch gefällt mir der vorher erwähnte Sensor vom Vlad Tepesh sehr viel
> besser oder auch nicht weil der 5 Byte hat und ich dann wahrscheinlich
> per I2C auswerten muss, oder ich nehme einen 32 Bit uC, auf was ich
> nicht gerade aus bin.

Nein, Nein, Nein!
die Sensoren werden über den Analog-Digital-Converter eingelesen.
Jeder an einen ADC-Pin und per Software abwechselnd einlesen.
Was wür einen µC nutzt du denn?
und was hat die Frage 32bitµC oder nicht damit zu tun?
Ein 8bit-AVR langweilt sich mit der Aufgabe zu tode.
5x AD-Wandlung, winzig kleines bisschen rechnen, neue Comparewerte an 
Timer übergeben, fertich

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Brocken Sei schrieb:

> per I2C auswerten muss, oder ich nehme einen 32 Bit uC, auf was ich
> nicht gerade aus bin.


Wenn ich das richtig sehe, dann betreibst du deinen Mega32 (Mega16?) 
ohne Quarz. Fang erst mal an, dem einen 16Mhz QUarz zu verpassen. 
Alleine das bringt dir schon Speed.
Aber dein µC langweilt sich sowieso zu tode mit dieser Aufgabe.

Autor: Zwei Fler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Algorithmus für Linefollower mit 5 Sensoren schrieb:
> Die Sensoren gehen auf den ADC und ich digitalisiere das Signal und
> schreibe das ganze dann in ein Byte.

Der CNY70 besteht ja im Prinzip aus einer IR-LED und einem 
Foto-Transistor der - wie Du oben schreibst - jeweils auf einen 
ADC-Eingang geht.

Da die Dinger nun mal drauf sind, kannst Du doch zum Test mal mit den 
Werten vom ADC weiterarbeiten.

Hast Du eine Debug-Möglichkeit (LCD oder Sserielle Ausgabe zum PC)? Dann 
lass Dir die Werte vom ADC mal anzeigen und vergleiche, wie es aussieht, 
wenn der Sensor auf / neben einer Linie steht.

Du müsstest dann ein Gefühl dafür kriegen, wie Du die Abweichung von der 
Führungslinie auswerten kannst.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch ein Hinweis:
DU hast schon Phototransistoren im Einsatz.
Die eine Hälfte vom CNY70 ist ein Phototransistor. Du musst ihn nur 
unter Umständen anders beschalten und auf einen anderen Eingang am µC 
gehen (nämlich den ADC)


Edit: zu langsam.

Autor: spess53 (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Ich würde etwas in der Art (Anhang) benutzen. Die werden in einer 
Baugruppe, die wir für einen Kunden entwickelt haben, zur Abtastung von 
Graukeilen verwendet.

Beim grossen C ist ein ähnlicher erhältlich:

http://www.conrad.de/ce/de/product/140268/IR-SENSO...

@Brocken Sei

Diese Teile arbeiten durchaus im 'Linearbetrieb'. Die Auflösung, in Bit, 
wird durch den AD-Wandler bestimmt.

MfG Spess

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zwei Fler schrieb:

> Hast Du eine Debug-Möglichkeit (LCD oder Sserielle Ausgabe zum PC)? Dann
> lass Dir die Werte vom ADC mal anzeigen und vergleiche, wie es aussieht,
> wenn der Sensor auf / neben einer Linie steht.
>

Full ACK

Ohne Ausgabemöglichkeit ist das alles stochern im Nebel.

Zur Not könnte man noch Messwerte ins EEPROM schreiben und die über den 
ISP Anschluss auslesen.

Aber ein LCD ist sicherlich kein Luxus, damit der µC aktuelle Werte 
rausgeben kann.

Autor: Brocken Sei (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> Hier ist das Handbuch zum Asuro
>
> http://www.produktinfo.conrad.com/datenblaetter/17...
>
> Auf Seite 74 ist der komplette Schaltplan. Die Transistoren T9 und T10
> sind die Senosren für die Linienverfolgung.
>
> Und das reicht immerhin schon, das ein Asuro 'Köpfchen in der Höhe'
> balancieren kann, indem er die Motoren so ansteuert, dass die
> Liniensensoren einen immer konstanten Wert liefern.

Ok, werd mir das anschauen!

Vlad Tepesch schrieb:
> Brocken Sei schrieb:
>> Das ist mal sehr schön formuliert, und wenn ich jetzt nur noch so einen
>> Sensor finde der mir mit deiner 8bit Auflösung auch noch sagt wie
>> hell/dunkel das auch noch ist, dann wär das perfekt.
>
> Häh?
> was benutzt du denn für sensoren?
>
>> Nein ehrlich jetzt die Idee ist spitze, aber ich habe bisher noch nie
>> von so einem Sensor gehört.
> Ich glaub du hast das falsche Hobby.
>
> Brocken Sei schrieb:
>> Mhm meinst du etwa sowas wien LDR?
>
> nein, LDR ist fiel zu langsam.

Hab gedacht du hast nen fertigen Sensor der 5 Byte liefert und die ich 
dann einfach auswerten kann und nicht per ADC einlesen und aufgrund der 
Spannung die 5 Bytes Platz für die Wertigkeit reserviere.

Vlad Tepesch schrieb:
> Brocken Sei schrieb:
>> Bist du dir sicher dass das so ohne weiteres Funktioniert, weil die LED
>> schaut ja nicht raus, die ist drinn und schaut mir eher wie ein Punkt
>> aus als wie wenn sie viel ausstrahlen würde.
> welche LED?

IR LED die am cny70 dran ist, weil Karl mir vorgeschlagen hat dass ich 
das mit meinen jetzigen Sensoren machen soll.
Wird wahrscheinlich mein erster Versuch sein da ich momentan keine 
Platinen mehr habe.

Vlad Tepesch schrieb:
> Nein, Nein, Nein!
> die Sensoren werden über den Analog-Digital-Converter eingelesen.
> Jeder an einen ADC-Pin und per Software abwechselnd einlesen.

Ja ok habs schon verstanden.

Vlad Tepesch schrieb:
> Was wür einen µC nutzt du denn?
> und was hat die Frage 32bitµC oder nicht damit zu tun?

Atmega16, die Frage war aufgrund den mysteriösen Sensor den du mir 
nanntest, der aber nicht existiert außer wenn man ihn selbst erstellt 
und im komplettpaket betrachtet.

Vlad Tepesch schrieb:
> Ein 8bit-AVR langweilt sich mit der Aufgabe zu tode.
> 5x AD-Wandlung, winzig kleines bisschen rechnen, neue Comparewerte an
> Timer übergeben, fertich

Naja ok, ihr wisst ja noch nicht dass das nicht nur eine schneller LF 
werden soll sondern auch noch auf die schnelle wenn ein Hinderniss 
auftaucht auszuweichen und wieder die Linie zu finden.
Wie das funktionieren soll da habe ich schon Visionen, also Ideen.
Und außerdem soll auch ein Funkmodul ran, damit der Robbi auch per 
Tastatur angesteuert werden kann (dies werde ich wahrscheinlich mit C# 
oder C++ realisieren). Dann soll da noch ein fettes Sprachmodul ran, das 
ich mittlerweile nicht vor mir liegen habe, jedoch schon einstudiert und 
am Programm arbeite ich gerade.
Und das soll mein neuer Roboter alles können, deshalb vielleicht nicht 
ganz das Verständniss wenn ich sage dass das eher aufwendiger wird von 
der Linienverfolgung etc...

Gruß Bro

Autor: Floh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Brocken Sei schrieb:
> am Programm arbeite ich gerade.

Zuerst soll das Ding der Linie nach! Alles Überflüssige macht den Code 
nur komplizierter und unübersichtlicher.

Brocken Sei schrieb:
> Wird wahrscheinlich mein erster Versuch sein da ich momentan keine
> Platinen mehr habe.

Als ob du nicht einfach die Ausgänge der cny70 an die ADC-Eingänge 
(siehe DB des Prozessors) anschließen kannst, sind doch nur n paar Kabel 
zum Umlöten.

Autor: Brocken Sei (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> Wenn ich das richtig sehe, dann betreibst du deinen Mega32 (Mega16?)
> ohne Quarz.

Also das sollte nur der Prototyp sein und nicht schon der richtige uC 
deshalb empfand ich das als eher nicht notwendig, aber langsam glaube 
ich auch dass ich da einen Quarz reinmachen sollte, ich werd aber erst 
schauen weil ich habe die Platine von unten zugemacht und wenn es nicht 
notwendig sein sollte dann lasse ich es.

Karl heinz Buchegger schrieb:
> Aber dein µC langweilt sich sowieso zu tode mit dieser Aufgabe.

Naja wenn ich 1,5 m/s fahre immer noch? Weil das wäre mein Ziel obwohl 
viele sagen dass das unrealistisch sei und man deshalb eine Regelung 
braucht, langsam verstehe ich auch warum.

Karl heinz Buchegger schrieb:
> Noch ein Hinweis:
> DU hast schon Phototransistoren im Einsatz.
> Die eine Hälfte vom CNY70 ist ein Phototransistor. Du musst ihn nur
> unter Umständen anders beschalten und auf einen anderen Eingang am µC
> gehen (nämlich den ADC)

Ja die sind schon auf dem ADC geführt.

Karl heinz Buchegger schrieb:
> Edit: zu langsam.

Hmm also ein Freund von mir hat diesen Sensor per Oszi ausgemessen und 
sagt der  braucht par zig us, und das reicht glaub ich auch, was 
schnelleres findet sich glaube ich nicht.

spess53 schrieb:
> Hi
>
> Ich würde etwas in der Art (Anhang) benutzen. Die werden in einer
> Baugruppe, die wir für einen Kunden entwickelt haben, zur Abtastung von
> Graukeilen verwendet.
>
> Beim grossen C ist ein ähnlicher erhältlich:
>
> http://www.conrad.de/ce/de/product/140268/IR-SENSO...
>
> @Brocken Sei
>
> Diese Teile arbeiten durchaus im 'Linearbetrieb'. Die Auflösung, in Bit,
> wird durch den AD-Wandler bestimmt.

ALso da müsste ich mir mal das Datenblatt raussuchen, guter Tipp danke.

Karl heinz Buchegger schrieb:
> Zwei Fler schrieb:
>
>> Hast Du eine Debug-Möglichkeit (LCD oder Sserielle Ausgabe zum PC)? Dann
>> lass Dir die Werte vom ADC mal anzeigen und vergleiche, wie es aussieht,
>> wenn der Sensor auf / neben einer Linie steht.
>>
>
> Full ACK
>
> Ohne Ausgabemöglichkeit ist das alles stochern im Nebel.
>
> Zur Not könnte man noch Messwerte ins EEPROM schreiben und die über den
> ISP Anschluss auslesen.
>
> Aber ein LCD ist sicherlich kein Luxus, damit der µC aktuelle Werte
> rausgeben kann.

Ich werde ein LCD reinmachen wenn es notwendig sein sollte, das Problem 
bei dem ist ich habe die Platine schon zu und die pins rauszuführen wäre 
etwas schwierig, aber ich arbeite daran die Platine wieder aufzumachen 
ohne die Drähte zu beschädigen.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Brocken Sei schrieb:

> Naja ok, ihr wisst ja noch nicht dass das nicht nur eine schneller LF
> werden soll sondern auch noch auf die schnelle wenn ein Hinderniss
> auftaucht auszuweichen und wieder die Linie zu finden.

Nur um das gerade zu rücken.
In der Zeit, in der dein µC programmtechnisch eine Runde durch die 
Regeschleife dreht, schafft dein Robot es noch nicht einmal einen ganzen 
Millimeter zu fahren!
Und da habe ich die Beschleunigung durch einen 16Mhz Quarz noch gar 
nicht berücksichtigt.

> Wie das funktionieren soll da habe ich schon Visionen, also Ideen.
> Und außerdem soll auch ein Funkmodul ran, damit der Robbi auch per
> Tastatur angesteuert werden kann (dies werde ich wahrscheinlich mit C#
> oder C++ realisieren). Dann soll da noch ein fettes Sprachmodul ran, das
> ich mittlerweile nicht vor mir liegen habe, jedoch schon einstudiert und
> am Programm arbeite ich gerade.

Bau ihm erst mal ein LCD drann, ehe du da jetzt phantasierst. Du hast du 
(und dein Robbi) erst mal mehr davon.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Brocken Sei schrieb:

> Naja wenn ich 1,5 m/s fahre immer noch?

Locker.
Dein µC arbeitet jetzt mit 1Mhz
1.5m/s bedeutet, dein Robbi bnötigt für 1 Millimeter 0.6ms.

0.6 Millisekunden sind für deinen µC ewig lang. In der Zeit arbeitet er 
in etwa 500 bis 550 Befehle ab.

Und das bei 1Mhz!

Autor: Brocken Sei (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Floh schrieb:
> Als ob du nicht einfach die Ausgänge der cny70 an die ADC-Eingänge
> (siehe DB des Prozessors) anschließen kannst, sind doch nur n paar Kabel
> zum Umlöten.

Nein es ging ja um den anderen Transistor der reingehört. Bei dieser 
Aussage gings mir nur darum die Sensoren zu behalten damit ich nicht 
erneut rauslöten muss.

Karl heinz Buchegger schrieb im Beitrag #1790683:
> LCD drann, ehe du da jetzt phantasierst.

Ich hoffe das war wieder nur ein Witz den du bei jedem machst. Das was 
ich aber gesagt habe war aber keiner, das soll wirklich so verwirklicht 
werden, ob dus glaubst oder nicht.

Gruß Bro

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Brocken Sei schrieb:

>> LCD drann, ehe du da jetzt phantasierst.
>
> Ich hoffe das war wieder nur ein Witz den du bei jedem machst.

Nein, das war keiner!

Wenn du einigermassen professionel deinen LF auf die Beine bringen 
willst, brauchst du eine Ausgabemöglichkeit! Ein Standard Text-LCD ist 
die simpelste und einfachste Möglichkeit dafür (abgesehen von 8 LED an 
einem Port). Und angeschlossen ist es auch schnell.

> Das was
> ich aber gesagt habe war aber keiner, das soll wirklich so verwirklicht
> werden, ob dus glaubst oder nicht.

Back erst mal kleine Brötchen.

Autor: Brocken Sei (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> Locker.
> Dein µC arbeitet jetzt mit 1Mhz
> 1.5m/s bedeutet, dein Robbi bnötigt für 1 Millimeter 0.6ms.

ok das mag schon sein aber andere Spezialisten sagen trotzdem 1,5-2m/s 
ist unrealistisch. Naja ich werds ja noch herausfinden.

Gruß Bro

Autor: Brocken Sei (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
>>> LCD drann, ehe du da jetzt phantasierst.
>>
>> Ich hoffe das war wieder nur ein Witz den du bei jedem machst.
>
> Nein, das war keiner!

Das bezog sich auf den rechten Teil nach dem komma.

Karl heinz Buchegger schrieb:
>> Das was
>> ich aber gesagt habe war aber keiner, das soll wirklich so verwirklicht
>> werden, ob dus glaubst oder nicht.
>
> Back erst mal kleine Brötchen.
ok

Nein, dann mach ich ein LCD rein, das wird wohl das beste sein.

Gruß Bro

Autor: Floh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Brocken Sei schrieb:
> ok das mag schon sein aber andere Spezialisten sagen trotzdem 1,5-2m/s
> ist unrealistisch. Naja ich werds ja noch herausfinden.

Diese Aussage hat eher was mit der Leistungsfähigkeit deiner Motoren zu 
tun.
Bei deinem Raddurchmesser von ca 5cm brauchst du für 2 m/s 13 
Umdrehungen/s, das sind 780 Umdreh/min. Unter Last für die Motoren nicht 
zu schaffen.

Autor: Brocken Sei (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So da nun alle Einzelheiten für mich geklärt sind möchte ich nun mal mit 
der Diskussion pausieren.
Ich muss ja auch was machen, wenn ich soweit bin den Algorithmus 
fertigzustellen und die Hardware überarbeitet habe werde ich vermutlich 
diesen Thread wieder aufwecken oder einen neuen aufmachen.

Ich möchte allen Bubies hier für ihre Hilfsbereitschaft danken und dass 
ihr mich auf die Sachen aufmerksam gemacht habt wie man sie richtig 
macht, obwohl ich nicht damit gerechnet hatte soviel aus diesem Thread 
rauszuholen.
Das ist jetzt nicht schlecht und gemein gemeint sondern es ist doch was 
positives das so etwas funktioniert.

Schönen Abend noch,

Gruß Brocken Sei

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das größere Problem, größere Geschwindigkeiten zu erreichen und auf der 
Linie zu bleiben, ist meinerMeinung nach weniger eine Problem der 
fehlenden Rechenzeit, sondern vielmehr der Motoren, oder nicht?
Wenn die in Fahrt sind und es kommt eine steile Kurve, kriegt man die 
halt nicht schnell genug gebremst und falls doch, dann wird die Traktion 
verloren gehen

Oder irre ich mich da? In dem Bereich hab ich gar keine Ahnung.

Autor: nefuas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sensoren:

ich rate dir 4 bis 6 TSL1401 Sensoren.
Damit, 4 - 6 mal 128 Bits gibst du deinem uC etwas Arbeit.
Dein Roboter faehrt damit MikroMeterGenau der Linie entlang.
Da machen deine Kumpel lange NasenAugenHalsundOhren.
Eine Superfeine Sache, wie es sich nur fuer Dich gehoert.

ciao

Autor: Tobi W. (todward)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Brocken Sei schrieb:
> oder einen neuen aufmachen.

Bitte nicht!!!! Hol den alten einfach wieder hoch.

Brocken Sei schrieb:
> ok das mag schon sein aber andere Spezialisten sagen trotzdem 1,5-2m/s
> ist unrealistisch.
Ja, du musst das ding ja irgentwann mal wieder bremsen! Auf gerader 
strecke wäre das vll möglich. Aber du musst ja immer so schnell fahren, 
das due problemlos eine Kurve fahren kannst, ohne von der linie 
abzukommen und da kommt dann auch eine gewisse trägheit der mechanik ins 
spiel. Somit haben deine "Spezialisten" teilweise(?) recht.

Floh schrieb:
> Bei deinem Raddurchmesser von ca 5cm brauchst du für 2 m/s 13
> Umdrehungen/s, das sind 780 Umdreh/min. Unter Last für die Motoren nicht
> zu schaffen.

Kommt auf den Motor an. Bei pollin gibts nen Motor der hat 300W, läuft 
mit 12V und schaft so an die 2000U/min meine ich :DDD also möglich wäre 
das

grüße
Tobias

Autor: Floh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
To W. schrieb:
> Kommt auf den Motor an. Bei pollin gibts nen Motor der hat 300W, läuft
> mit 12V und schaft so an die 2000U/min meine ich :DDD also möglich wäre
> das

Ich geh grad einfach von den Getriebemotoren aus, die auf dem Bild 
waren.
300W-Motoren sind ttteeeuuueeerr.
Die Ansteuerung wird dann nicht über nen L293D laufen, der brennt 
höchstens ab.
Außerdem hält sein 8 Wh Akku, den er verbaut hat, dann ca 96 sekunden. 
:-)

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du dir mal das angesehen?
http://elm-chan.org/works/ltc/report.html

Autor: Tobi W. (todward)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Floh schrieb:
> Ich geh grad einfach von den Getriebemotoren aus, die auf dem Bild
> waren.
> 300W-Motoren sind ttteeeuuueeerr.
> Die Ansteuerung wird dann nicht über nen L293D laufen, der brennt
> höchstens ab.
> Außerdem hält sein 8 Wh Akku, den er verbaut hat, dann ca 96 sekunden.
> :-)

Hier den mein ich ;) 12V,max. 25A, 300W, 3800U/min
Ist zwar ausverkauft, aber hätte nur 10 Takken gekostet :DD
http://www.pollin.de/shop/dt/Mjk1OTg2OTk-/Motoren/...

gruß
Tobias

Autor: Michael H. (michael_h45)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vlad Tepesch schrieb:
> fehlenden Rechenzeit, sondern vielmehr der Motoren, oder nicht?
> Wenn die in Fahrt sind und es kommt eine steile Kurve, kriegt man die
> halt nicht schnell genug gebremst und falls doch, dann wird die Traktion
> verloren gehen
Da muss man nur das Regelstrecken-Modell genau genug auslegen.
Totzeiten durch Rechenzeit oder auch mechanische Trägheiten kann man 
noch recht einfach in ein Modell bringen.
Bestimmt weiß Herr Brocken auch schon, ob Ziegler-Nichols oder Lyaponov 
zum Einsatz kommt ^^

Autor: Tobi W. (todward)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael H. schrieb:
> Bestimmt weiß Herr Brocken auch schon, ob Ziegler-Nichols oder Lyaponov
> zum Einsatz kommt ^^
Aber bestimmt doch ^^
Die Traktion kann man ja durch einen rauen untergrund erhöhen und die 
trägheit durch einen leichten aufbau minimieren, wobei sich das beide 
gegeneinander aufhebt...
Mach ich den robbi leichter verliere ich an traktion habe aber bessere 
trägheits eingeschaften -> regelung/geschwindigeit langsamer
Mach ich den robbi schwere gewinne ich an traktion habe aber schlechtere 
trägheitseigenschaften -> regelung/geschwindigkeit bleibt genauso 
langsam.
Ich könnte höchstens etwas gewinnen idem ich den aufbau so leicht wie 
möglich mache und das komplette gewicht versuche aus die achse zu 
verlagern.

Grüße
Tobias

Autor: Zwei Fler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Brocken Sei schrieb:
> Ich werde ein LCD reinmachen wenn es notwendig sein sollte, das Problem
> bei dem ist ich habe die Platine schon zu und die pins rauszuführen wäre
> etwas schwierig, aber ich arbeite daran die Platine wieder aufzumachen
> ohne die Drähte zu beschädigen.

Wenn es so schwierig ist, an die Platine zu kommen, denk auch gleich an 
ein paar Tasten, Du wirst sie sonst später vermissen.

Hilfreich wäre z.B. eine Start / Stop Taste oder das manuelle Auslösen 
eines Kalibriervorgangs (Robby auf hellen Grund stellen, Kalibrierung 
starten, die Sensoren "lernen" die AD-Werte für "hell" auf dem gegebenen 
Untergrund.

Brocken Sei schrieb:
> Ich möchte allen Bubies hier für ihre Hilfsbereitschaft danken

Selber ;-)

Autor: Brocken Sei (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich behaupte jetzt mal, dass ich mich mit den Grundlagen von C auskenne, 
außer die Zeiger machen mir noch Schwierigkeiten, aber wie ich auch 
erfahren habe sind Zeiger nicht immer notwendig.
Ich habe nun einen Algorithmus geschrieben der zwar funktioniert wenn 
ich den ROboter hochhalte und ihn von links nach rechts und umgekehrt 
über die Linie schiebe.
Wenn ich jedoch den Robocop auf die Grund lasse so fährt er ne Sekunde 
lang und die Versorgung spielt nicht mehr mit, also deswegen dieser 
Post, weil ich mir keinen 60€ teueren Akku leisten will, und ich sowieso 
in 2 Wochen einen im Labor zur Verfügung gestellt kriege.
#include <stdio.h>      //Standard input output
#include <stdlib.h>
#include <stdint.h>
#include <avr/io.h>
#include <string.h>
#include <util/delay.h>
#include <stdbool.h>

//Definitionen--------------------------------------------------------
#define ON 200
#define OFF 0

//Deklarierte Funktionen----------------------------------------------
void PWM_INIT_Timer1(unsigned short Bit_Modus, char Inverted_NotInverted1a[], char Inverted_NotInverted1b[], unsigned short Prescaler);
void ADC_Init(char Reference[], char Bitmodus, unsigned char Prescaler);
unsigned char GetADC_8bit(uint8_t Chanel);

//Unterprogramme------------------------------------------------------
#include "lcd-routines.h"
#include "Unterprogramme.h"
#include "Pwm_Init.h"
#include "ADC_Init.h"
//--------------------------------------------------------------------

//Hauptprogramm-------------------------------------------------------
int main()
{
  int Sensor0, Sensor1, Sensor2, Sensor3, Sensor4;
  //const double ADC_V = 0.01960784;
  char Buffer[100];
  int Summe;

  //LCD init:
  lcd_init();
  lcd_clear();

  //ADC-Init:
  ADC_Init("Internal-AVCC", 8, 16);

  //PWM-Init
  PWM_INIT_Timer1(8,"NotInverted","NotInverted",1024);

  //Ein-/Ausgabe
  DDRB = 0b00001111;  //Motoren
  PORTB = 0b00001010; //Motoren in selbe Richtung drehen
  
  _delay_ms(3000);
  OCR1A = ON; //Motoren testen
  OCR1B = ON;
  _delay_ms(3000);

  //Hauptschleife:*****************************************************************
  while(1)
  {
    Summe = 0;
    //lcd_clear();
    //Sensor0 = GetADC_8bit(0) * 2;
    Sensor1 = GetADC_8bit(1);
    Sensor2 = GetADC_8bit(2);
    Sensor3 = GetADC_8bit(3);
    //Sensor4 = GetADC_8bit(4) * 2;

    Summe = Sensor1 - Sensor3;

    if(Summe < 0)
    {
      OCR1A = abs(Summe);
      OCR1B = OFF;
    }

    else if(Summe > 0)
    {
      OCR1B = abs(Summe);
      OCR1A = OFF;
    }

    else
    {
      OCR1A = ON;
      OCR1B = ON;
    }


    /*lcd_setcursor(0, 1);
    sprintf(Buffer, "%d",Summe);
    lcd_string(Buffer);*/

    //_delay_ms(100);

  }
  //zurück*************************************************************************
  return 0;
}


Da ich noch keinen Funk reingemacht habe um den Robo per Funk über einen 
SIcherheitsschalter auszuschalten, und die Motoren !sehr! schnell drehen 
bei vollem Akku, habe ich Angst dieses Programm so ohne weiters laufen 
zu lassen wenn der Akku da ist, da sich sonst der Robo selbst zerstört. 
Die Taktfrequenz ist 8MHz da wenn ich dann den COntroller per STK500 
programmiere ich einen externen Quarz anschließen muss damit ich ihn 
programmieren kann.
Es geht mir rein um die Zykluszeit des Programms und da ich noch keinen 
Weg gefunden habe das Programm zu simulieren weder mit VMLAB noch mit 
Eclipse und AVR Studio, da immer etwas abstürzt(unsauber geschriebene 
Simulatorn kann ich schon fast sagen) möchte ich mal fragen ob mir 
jemand sagen kann ob das Prgramm effizient und schnell genug ist.
Ich will jetzt kein ja oder nein sondern eine Grobe Einschätzung wie es 
mit dem ausschaut und ob sich mit dieser AUswertung einen PID 
Algorithmus einbauen kann.

Natürlich habe ich mich in PID noch nicht 100% eingearbeitet aber der 
Grundsatz dass ein Algo schon funktioniert soll für mich die weitere 
Motivation sein ne Stufe höher auf PID/Regelungstechnik zu gehen.

Gruß Bro

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.