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 ...
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.
1 | beide Motoren vorwärts |
2 | |
3 | für immer |
4 | wenn rechts ein höherer Wert gemeldet wird als links |
5 | ja -> rechten Motor etwas schneller fahren lassen |
6 | nein -> rechten Motor etwas langsamer fahren lassen |
7 | 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.
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.
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)
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
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
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.
stichwort: Regeler!!!! der macht das dann automatisch wenn du Ihn richtig einstellst, schneller als dein roboter fährt
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
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
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?
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
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
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.
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.
>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
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
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.
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
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.
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ß?
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
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?
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.
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?
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
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
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.
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.
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
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
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.
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.
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?
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
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.
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
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
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.
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
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
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
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
1 | ...
|
2 | |
3 | while( 1 ) { |
4 | int16_t Difference = SensorLeft - SensorRight; |
5 | |
6 | OCR1A = min( max( BasePWM + Faktor * Difference, 0 ), 255 ); |
7 | OCR1B = min( max( BasePWM - Faktor * Difference, 0 ), 255 ); |
8 | }
|
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.
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
Hier mal ein grober Schnellschuß für den Plausibiltätstest:
1 | x h d h x -> gerade |
2 | h d h x x -> links |
3 | x x h d h -> rechts |
4 | d h h x x -> scharf links |
5 | 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
@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
@ 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
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.:-)
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.
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
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...
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
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). :-)
> 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)
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.
wer schon sooo viele Line Follower gebaut hat MUSS solche Infos nicht preisgeben....
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
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)
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...
Angehängte Dateien:
-
HPIM1878.JPG
190 KB -
HPIM1879.JPG
120 KB
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
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
Hier ist das Handbuch zum Asuro http://www.produktinfo.conrad.com/datenblaetter/175000-199999/191164-an-01-de-Asuro_BS_Programmierbarer_Roboter.pdf 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. http://www.youtube.com/watch?v=V0VxL2VqIWQ
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.
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/Lichtsensor_/_Helligkeitssensor#Phototransistor 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
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.
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.
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.
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-SENSOR-APDS-9102-L22/0231042 @Brocken Sei Diese Teile arbeiten durchaus im 'Linearbetrieb'. Die Auflösung, in Bit, wird durch den AD-Wandler bestimmt. MfG Spess
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.
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
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.
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.
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.
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!
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
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.
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
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
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.
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
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.
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
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
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. :-)
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/Gleichstrommotoren/Hochleistungs_Gleichstrommotor_VALEO_EM1132.html gruß Tobias
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 ^^
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
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 ;-)
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.
1 | #include <stdio.h> //Standard input output |
2 | #include <stdlib.h> |
3 | #include <stdint.h> |
4 | #include <avr/io.h> |
5 | #include <string.h> |
6 | #include <util/delay.h> |
7 | #include <stdbool.h> |
8 | |
9 | //Definitionen--------------------------------------------------------
|
10 | #define ON 200
|
11 | #define OFF 0
|
12 | |
13 | //Deklarierte Funktionen----------------------------------------------
|
14 | void PWM_INIT_Timer1(unsigned short Bit_Modus, char Inverted_NotInverted1a[], char Inverted_NotInverted1b[], unsigned short Prescaler); |
15 | void ADC_Init(char Reference[], char Bitmodus, unsigned char Prescaler); |
16 | unsigned char GetADC_8bit(uint8_t Chanel); |
17 | |
18 | //Unterprogramme------------------------------------------------------
|
19 | #include "lcd-routines.h" |
20 | #include "Unterprogramme.h" |
21 | #include "Pwm_Init.h" |
22 | #include "ADC_Init.h" |
23 | //--------------------------------------------------------------------
|
24 | |
25 | //Hauptprogramm-------------------------------------------------------
|
26 | int main() |
27 | {
|
28 | int Sensor0, Sensor1, Sensor2, Sensor3, Sensor4; |
29 | //const double ADC_V = 0.01960784;
|
30 | char Buffer[100]; |
31 | int Summe; |
32 | |
33 | //LCD init:
|
34 | lcd_init(); |
35 | lcd_clear(); |
36 | |
37 | //ADC-Init:
|
38 | ADC_Init("Internal-AVCC", 8, 16); |
39 | |
40 | //PWM-Init
|
41 | PWM_INIT_Timer1(8,"NotInverted","NotInverted",1024); |
42 | |
43 | //Ein-/Ausgabe
|
44 | DDRB = 0b00001111; //Motoren |
45 | PORTB = 0b00001010; //Motoren in selbe Richtung drehen |
46 | |
47 | _delay_ms(3000); |
48 | OCR1A = ON; //Motoren testen |
49 | OCR1B = ON; |
50 | _delay_ms(3000); |
51 | |
52 | //Hauptschleife:*****************************************************************
|
53 | while(1) |
54 | {
|
55 | Summe = 0; |
56 | //lcd_clear();
|
57 | //Sensor0 = GetADC_8bit(0) * 2;
|
58 | Sensor1 = GetADC_8bit(1); |
59 | Sensor2 = GetADC_8bit(2); |
60 | Sensor3 = GetADC_8bit(3); |
61 | //Sensor4 = GetADC_8bit(4) * 2;
|
62 | |
63 | Summe = Sensor1 - Sensor3; |
64 | |
65 | if(Summe < 0) |
66 | {
|
67 | OCR1A = abs(Summe); |
68 | OCR1B = OFF; |
69 | }
|
70 | |
71 | else if(Summe > 0) |
72 | {
|
73 | OCR1B = abs(Summe); |
74 | OCR1A = OFF; |
75 | }
|
76 | |
77 | else
|
78 | {
|
79 | OCR1A = ON; |
80 | OCR1B = ON; |
81 | }
|
82 | |
83 | |
84 | /*lcd_setcursor(0, 1);
|
85 | sprintf(Buffer, "%d",Summe);
|
86 | lcd_string(Buffer);*/
|
87 | |
88 | //_delay_ms(100);
|
89 | |
90 | }
|
91 | //zurück*************************************************************************
|
92 | return 0; |
93 | }
|
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.