Kommentare

Der (ATtiny861A) ist ein bißchen zickig bei den Pinchange Interrupts. Irgendwie verhalten die sich nicht so, wie im Datenblatt angegeben. Hab ich erstmal umgangen und die INT0/1 Interrupts zum Testen benutzt.

Mittlerweile habe ich erkannt, daß der ATtiny861A (461,261) nur ein Interruptflag für alle seine PCINT Pins hat. Ist anders als beim ATtiny44 (ATtiny24,84). Der hat für seinen PORTA ein Interruptflag und für PORTB ein zweites. Beim 861 kann man aber trotzdem zwei Portpingruppen getrennt enablen (mit PCIE0, PCIE1). Die beiden Gruppen sind aber nicht nach Portregistern getrennt. Man kann also nicht sagen PCIE0 ist nur für PORTA zuständig. Der 861 hat dafür aber zwei externe Interrupts (INT0 und INT1). Im Vergleich hat der Tiny44 nur einen, den INT0. Zusammen mit verwechselbaren Interruptnamen in BASCOM hat das bei mir zur Konfusion geführt. Bis jetzt habe ich nur die INT0/1 Interrupts für mich gut getestet.

Meine Encoderauswertung basiert auf einem Interrupt bei steigender oder fallender Flanke. Bei zwei Encodern wären zwei unabhängig auslösbare Interrupts vorteilhaft um nicht noch in SW nach der Auslösequelle suchen zu müssen. Da wären wegen der freien Pinauswahl die PCINTs wie im ATtiny44 optimal. Hier werde ich wohl bei den INT0/INT1 im ATTiny861A bleiben.

Danke witkatz!

Zitat von witkatz

Oh, hat sich da ein gepunkteter Passagier eingeschlichen?

Ja, hier gibt es viele dieser Bugs. Die fahren oft mit, sind aber meistens unauffälliger

Idee für ein Video wäre Synchronfahren. Wenn der TT auf die FB reagiert, kommen noch der Steppende Linienfolger und der Quadenc mit ins Bild. Linienfolger und Quadenc hatte ich schon mal gemeinsam ausprobiert - na ja, es ging, aber den ersten Preis im Synchronirgendwas gäbe es nicht

Beim Basteln bekomme ich immer neue Ideen. Bei der Überlegung, wie man die Anzahl der Encoderleitungen noch reduzieren könnte, hatte ich mich wieder an einen alten thread zur Quadratursignalauswertung von mir erinnert. Die Lösung würde den HW-Aufwand nicht verringern sondern erheblich erweitern, das Programm aber vereinfachen und schneller machen und fände es einfach nur interessanter. Werde noch ein wenig testen und möglicherweise einbauen

Gruß
Searcher

Das sieht schon mal super aus und ich freue mich schon auf's Video
Oh, hat sich da ein gepunkteter Passagier eingeschlichen?

Hallo PICture ,

ich habe mich schon auf derbe Kritik an meinen H-Brücken Versuchen gefaßt gemacht. Umso mehr Dank für den Hinweis! Weil ich den Hersteller auf dem Gehäuse der Transistoren nicht ausmachen konnte, habe ich bei http://datasheetcatalog.com/ den Hersteller "unknown" hergenommen, der auch C945 und A733 (ohne 2S) im Angebot hat . Außerdem haben die statt 100mA 150mA Maximalstrom Icm was mir auch entgegen kommt
C945: http://pdf.datasheetcatalog.com/datasheets2/12/1247641_1.pdf
A733: http://pdf.datasheetcatalog.com/datasheets2/99/999913_1.pdf

Die Brücke ist so schön klein geworden, hatte keine Lieferzeit und hat auch nichts gekostet (außer Bastelspaß). Mal sehen, wie lange sie hält. Bin beim überlegen, was für Features ich noch in den TT einbauen kann.

Gruß
Searcher

Hallo Searcher,

die Japaner schreiben am Anfang der Bezeichnung von Transistoren wegen Platzmangel keine "2S". Deine o.g. Transistoren heißen also 2SC945 und 2SA733 und sind in Datenblätter vom NEC zu finden.

Hallo RoboHolIC,

Zitat von RoboHolIC

Ich finde deine Methode total tricky, weil sie -zumindest im laufenden Bitstrom- ohne Wartezeiten auskommt, volles Handshake leistet und doch nur zwei Leitungen benötigt. Unaufwendig und ziemlich effizient. So wie du das gelöst hast, finde ich es genial mit hohem Nachahmungspotential.

Vielen Dank!

Zitat von RoboHolIC

Hoffentlich war ich nicht negativ missverständlich.

Nein, gar nicht. Ich habe das schon sehr positiv aufgefasst und mich darüber gefreut. Da war ich wohl ein wenig mißverständlich. Meine "Entwicklungen" sind oft von der mir selbst auferlegten Not oder besser, selbst auferlegten Einschränkungen getrieben. Ich bin dann oft überrascht was da am Ende heraus kommt. Das betrachte ich dann gerne lustig mit viel Spaß und mit über mich selbst lachen, egal ob die Lösung 1a oder von hinten durch die Brust ist "interessante Lösung" kann man falsch verstehen wenn man unbedingt will, habe aber sicher nicht angenommen, daß Du es negativ gemeint hast. Ich konnte aber eben auch meinen Kommentar nicht unterdrücken, in dem ich eigentlich über mich selbst schmunzele aber leider auch diese Zweideutigkeit mitschwingt.

Gruß
Searcher

Hoffentlich war ich nicht negativ missverständlich. Ich finde deine Methode total tricky, weil sie -zumindest im laufenden Bitstrom- ohne Wartezeiten auskommt, volles Handshake leistet und doch nur zwei Leitungen benötigt. Unaufwendig und ziemlich effizient. So wie du das gelöst hast, finde ich es genial mit hohem Nachahmungspotential.

Zitat von RoboHolIC

Danke, eine sehr interessante Lösung, die ich garnicht mal naheliegend finde, weil Daten und Handshake zwischen den beiden Leitungen wechseln - cool!

Hab auch ziemlich dran gewerkelt um von den einfachen Lösungen wegzukommen Der Vorgänger war auch ein Zwangslaufverfahren aber über drei Adern. Zwei Signaladern, eine in jede Richtung ("Bit liegt an" und "Bit gelesen"), und eine Datenleitung nur in eine Richtung. Das war doppelt so schnell aber brauchte eben eine Ader/Verbindung mehr. Die ist noch beim steppenden Linienfolger zwischen FB-Tiny und Haupt-µC in Betrieb. War zu bequem da umzustellen; an der Stelle gab es ja noch genügend freie Pins.

Habe eben erst deine Antwort gefunden ( - trotz Stöber-Suche eher zufällig. Ich hatte gehofft, vom Forumssystem per Mail informiert zu werden. Jetzt hab ich aber die Einstellung dafür gefunden).

Die automatischen Benachrichtigungist mir auch nicht ganz klar. Im Blog ist es OK aber im Forum gibt es Threads (zB Erfolg der Woche), von denen bekomme ich bei neuen Antworten immer eine Nachricht obwohl ich da lange nicht aktiv war. Bei anderen nur einmal bis ich selbst wieder antworte - bißchen undurchsichtig, mag aber nicht suchen, da ich damit leben kann.

Gruß
Searcher

Hallo Searcher.

Habe eben erst deine Antwort gefunden ( - trotz Stöber-Suche eher zufällig. Ich hatte gehofft, vom Forumssystem per Mail informiert zu werden. Jetzt hab ich aber die Einstellung dafür gefunden).

Danke, eine sehr interessante Lösung, die ich garnicht mal naheliegend finde, weil Daten und Handshake zwischen den beiden Leitungen wechseln - cool!

Zitat von RoboHolIC

Wie überträgst du die Info vom IR-Empfänger an den Hauptprozessor des Targets? Bit-seriell, parallel, UART?
Hast du eine eigene "Hausnorm" geschaffen oder passt du die Übertragung an die jeweils freien Funktions- bzw. I-O-Pins an?

..., eine Standardlösung wäre aber schön.

Leider keine Standardlösung sondern bitserielles Zwangslaufverfahren als "Hausnorm" . Irgendwo in den Links unten findet man die Begründung. Dort findest Du auch was ich wie gemacht habe.

Kurz:
HW-I2C und SPI (wollte mich nicht einarbeiten, BASCOM-Demo mangelnde Libs. UART - hängt an übereinstimmendem Takt zwischen Sender und Empfänger.

Zwangslaufverfahren: kann von Interrupts unterbrochen werden was mir beim Steppenden Linienfolger wichtig war, da der Mega88 auch die komplette Steuerung zweier Stepper ohne speziellen Steppercontroller gemacht hat.

Verbunden bei mir über zwei Adern (+GND) über zwei 1k Angstwiderstände. Kein Bus. Jede weitere Verbindung braucht zwei zusätzliche Verbindungen (Portpins)

Kein Overhead. Wenn angestoßen, geht es sehr schnell (wenn nicht durch Interrupt unterbrochen)

Der Code (ASM Code) muß leider immer an die HW Ports angepaßt werden. Daten nur in eine Richtung aber mit Quittungsmöglichkeit in Rückrichtung. (Wahrscheinlich ist Halbduplex möglich, habe ich jedoch nicht weiter verfolgt)

Ich glaub hier im Kommentar kann ich keine Anhänge absetzen. Im Blogeintrag oben habe ich noch die beim Quadenc aktuell eingesetzten Codestücke angehangen.

http://www.roboternetz.de/community/...en-frei-machen

http://www.roboternetz.de/community/...mit-zwei-Adern

http://www.roboternetz.de/community/...st%C3%A4tigung

Wie überträgst du die Info vom IR-Empfänger an den Hauptprozessor des Targets? Bit-seriell, parallel, UART?
Hast du eine eigene "Hausnorm" geschaffen oder passt du die Übertragung an die jeweils freien Funktions- bzw. I-O-Pins an?

Ich habe nämlich aus ähnlichen Erwägungen heraus endlich (seit ein paar Wochen, die ersten Vorarbeiten sind aber aus dem Jahr 2010) eine RC5/6-Empfangseinheit als Standalone-Modul programmiert. Die könnte meine Standard-drei-Tasten-Auswertung von außen stimulieren - oder eben noch was einfacheres. Ideen gibt es viele, eine Standardlösung wäre aber schön.

Hi, ja der Linienfolger mit den Steppermotoren war ja auch schon eine Wiederbelebung und das Chassis, daß der Quadenc im Video aus dem Bild befördert hat, ist auch noch dran. Das hat auch schon lange im Stillen ausgehalten und da halte ich jetzt nach dem Erfolg mit dem Quadenc noch verstärkt Ausschau nach unkomplizierten Anbringungsmöglichkeiten von noch zu wählenden Encodern aus noch zu findenden Computermäusen, die ich hier noch irgendwo rumliegen habe. Was käme danach? Im Teenageralter? Die nächste Evolution wäre vielleicht eine Kommunikation unter den Dreien (dem Stepper, dem Quadenc und dem Winkelgetriebenen). Träume ...

Das letzte Video von Deinem WR02 habe ich irgendwie gar nicht mitbekommen und ihm jetzt erstmal einen Daumen hoch verpaßt. Man erkennt förmlich, daß er durch weiche Bewegungen auf keinen Fall seine wertvolle Nutzlast in Gefahr bringen möchte Je mehr man bastelt und liest und sieht, desto mehr Ideen bekommt man für seine eigenen Projekte. Daß, was ich mal liegen gelassen habe wird plötzlich wieder interessant und wo man sich schwer getan hat geht plötzlich wie von selbst. Mir macht das Hobby einfach sehr viel Spaß und kann auch mit unvollkommenen Lösungen leben - wenn es manchmal auch nur nur eine Weile ist

Wenn ich mich recht entsinne, war die Infrarotbedienung bei mir mal dafür gedacht beim Testen unkompliziert Parameter im Programm einzustellen und auszuprobieren ohne immer neu programmieren zu müssen. Mit der Verwendung eines eigenen µCs für den Empfang der IR FB Pakete stört die FB den eigentlichen Haupt-µC fast überhaupt nicht mehr (das hatte ich früher nie richtig in den Griff bekommen) und hat sich deshalb schon fast als Standard bei mir entwickelt; ist fast so praktisch geworden wie die Fernbedienung für den Fernseher Kann ich nur empfehlen.

Cool wie sich dein Quadenc über die Jahre entwickelt hat. Der ist jetzt bald im Vorschulalter, oder ? Da sieht man, dass man an den erfolgreichen Bastelprojekten jahrelang Spaß haben kann.
Läuft nun wirklich super und das Video macht gute Laune

Mein Kleinstlaster WR02 ist jetzt schon im 2ten Entwicklungsjahr und hat noch für etliche Spielereien Platz auf der Steuerungsplatine und im Flash. Odometrie und IR Fernsteuerung kommen vielleicht auch irgendwann dran - das hast du mir mit deinem Video schmackhaft gemacht

Hallo Searcher,

dynamische Regelalgorithmen wie PD oder PID würden einen deterministischen Zeittakt voraussetzen. Mein Roboter rechnet z.B. alle 4ms den PID Linienrregler. Hab leider k.A., wie so eine Task in Bascom zu realisieren wäre, deshalb sorry - vergiss wieder meinen "Verbesserungsvorschlag"

Für mehr Performance könnte es sich vielleicht lohnen bei Berechnungen möglichst in 16bit Arithmetik zu bleiben. Z.B. ((int16_t)Gst * (int16_t)Sensor) / 45 ist ugf das gleiche wie (single)Gst * (single)Sensor * 0,022, wird aber schneller gerechnet und wahrscheinlich reicht die Genauigkeit aus. Vielleicht kann das Compilat dadurch schrumpfen, wenn Bibliotheksfunktionen für Fließkommaoperationen nicht mitgelinkt werden (müssen).
Das ist jetzt von mir ohne Ahnung von BASCOM nur geraten.

An der Stelle noch mal vielen Dank für deine tollen Blogbeiträge. Ich wünsch dir weiterhin viel Spaß beim B&B (Basteln und Bloggen )

Gruß
witkatz

Hallo witkatz,

vielen Dank. Auch zu Deinen Ideen. Bin schon am überlegen, wie ich den Steueralgorithmus abändern kann. Unvorsichtigerweise hast Du geäußert, daß Du die Regelstruktur nicht kennst. Was nun folgt ist mir etwas aus dem Ruder gelaufen und sollte nicht so lang werden. Also:

Die Lenkung beruht zur Zeit auf einer möglichst schnellen Abtastung der Linie und daraufhin möglichst schneller Ansteuerung der Motore, damit der SLF (Stepping Line Follower) gar nicht anders kann als der Linie zu folgen.

Es steht eigentlich eine genaue Untersuchung über den Verlauf der Werte aus, die der ADC über die Breite der Linie eigentlich liefert. Es haben die Ausleuchtung der Linie, Abstand der Photodioden voneinander und von der Linie und natürlich der Kontrast Linie - Hintergrund Einfluß. Vorteil scheint mir ein einfacher Aufbau, wenig Einfluß von Fremdlicht durch differentielle Auswertung, Relativ unempfindlich gegenüber verschiedener Linienbreiten. Wohl weniger geeignet für Regelschleifenanwendung. Damit habe ich mich aber noch nicht ernsthaft beschäftigt. Es gibt also keine P, I, D oder sonstige Regelung des Vehikels. Nachfolgend mal Beschreibung des Programms und wie SLF gesteuert wird. Möglicherweise gibt es noch Bugs in der Realisierung.

Im Augenblick funktioniert der Normallinienmodus also so:

1. Die Werte der differentiellen Messung des ADCs werden in eine Zahl von 0 bis 126 ohne die Proportionen der eigentlichen Messung zu verändern umgeformt. Sie dienen zusammen mit der Grundgeschwindigkeit, die über die Fernbedienung eingegeben wird, als Eingabe für der Erzeugung der Schrittfrequenz für die Schrittmotore.

Der Wert 63 ist die Neutralstellung und bedeutet, daß sich das Vehikel mittig über der Linie befindet. Bei Übergabe an die Schrittmotorsteuerung soll der SLF damit geradeaus fahren. Liniensensorprogramm wie im vorletzten Blogeintrag mit Ausnahme der CNY Auswertung gepostet. Die ADC Werte werden vor der Übergabe nur etwas geglättet. Und zwar wird jede neue Messung in einem Array mit 8 Elementen abgespeichert. Die älteste Messung wird überschrieben und die verbleibenden acht Werte addiert und 3 mal nach rechts geschoben, also durch 8 geteilt. Das unterdrückt sporadisch auftretendes Zittern vom SLF. Wird der Mittelwert über 16 oder 32 Werte gebildet, kann man schon ein trägeres Lenkverhalten beobachten.

2. Die Ansteuerung für die Schrittmotore erfolgt folgendermaßen:
a. Grundgeschwindigkeit von der Fernbedienung vorgegeben. Es gibt Werte von 0 bis 126(127). Als Beispiel mal Wert 60 hergenommen und im Folgenden GStufe genannt.
Das Vehikel bewegt sich ohne Einlenkung dann mit ca. 25cm/s geradeaus.

Berechnung:
16Bit Timer1 des Mega88 läuft mit 1Mhz.
Schrittmotore haben pro Vollschritt 18° Drehwinkel und laufen im Halbschritt (40 Halbschritte für eine Motorwellenumdrehung)
Getriebeübersetzung = 15:1, Raddurchmesser ist ca. 4cm entspricht etwa 12,6cm Umfang.

Code:

50000/GStufe = 50000 / 60 = 833,333 auf 833 abgerundet und als Vergleichswert zur Erzeugung eines Halbschritts im Timer1 benutzt.
833 Timer1 Ticks entsprechen einem Halbschritt pro 833 * 1/1000000Hz = 0,000833s
In einer Sekunde gibt es dann 1 / 0,000833s = 1200,48 Halbschritte
1200,48Hz / 40 = 30,01 rps (revolutions per second wg. 40 Halbschritte für eine Umdrehung)
30,01rps / 15 = 2rps (Getriebeübersetzung eingerechnet gibt es 2 Radumdrehungen pro Sekunde)
2rps * 12,6cm = 25,2cm/s (Radumfang eingerechnet ergibt das die Geschwindigkeit)

Diese Geschwindigkeit ist auch die Maximalgeschwindigkeit, auf die ein kurvenäußeres Rad eingestellt wird und immer versuchen wird zu erreichen. Beim Einlenken von einer Geraden in eine Kurve wird das kurveninnere Rad verlangsamt - das kurvenäußere Rad bleibt bei seiner Maximalgeschwindigkeit. Wird eine direkte Folge von engegengesetzten Kurven abgefahren, wird gleichzeitig beide Räder in der Geschwindigkeit verändert. Das kurvenäußere Rad mit der Maximalgeschwindigkeit wird verlangsamt und das langsamere Rad auf Maximalgeschwindigkeit beschleunigt.

Die Dauer der Beschleunigung (und Verlangsamung = negative Beschleunigung) wird durch eine Rampe bestimmt und ist auf ein GStufe alle 4,8ms eingestellt. Ist die gegenwärtige Geschwindigkeit GStufe=50 und soll auf 60 beschleunigt werden, dauert es 4,8ms * (60-50) = 48ms bis die GStufe 60 erreicht ist. Falls eingelenkt werden muß und neben der Beschleunigung des einen Rades von 50 auf 60 gleichzeitig das andere Rad um 20 gebremst werden muß, dauert das 4,8ms * 20 = 96ms (Ich bin mir nicht im Klaren, ob sich die ungleiche Dauer der Beschleunigungszeiten von 48ms und 96ms sehr negativ auf das Fahrverhalten auswirken kann?) Falls während der Beschleunigung, also innerhalb der Rampe und vor vor Erreichen der Endgeschwindigkeit, neue Endgeschwindigkeiten gefordert werden, wird die neue Endgeschwindigkeit innerhalb der Rampe sofort wieder mit einer GStufe alle 4,8ms pro Rad zu erreichen versucht.

b. Einlenken. Bisher gab es eine Einstellung von der FB für die Geschwindigkeit, hier als Beispiel 60.
Von dem Liniensensor kommt als Einlenkgröße ein Wert von 0 bis 126 zur Schrittmotorsteuerung. Davon wird erstmal 63 subtrahiert und ergibt Werte von (-63) über 0 bis (+63). 0 für geradeaus und die negativen bzw. positiven Werte für Stärke der Lenkeinschläge nach links bzw. rechts.

Dieser Wert wird mit einem experimentell bestimmten Wert multipliziert. Im Normallinienmodus ist die Konstante 0,022 (Leider eine Fließkommazahl - Single in BASCOM). Sie ist praktisch das Übersetzungsverhältnis des Lenkgetriebes. Je größer die Konstante, desto kräftiger reagiert das Vehikel auf die Einlenkwerte vom Liniensensor. Mal angenommen vom Liniensensor kommt eine 30.

30 - 63 = (-33)
(-33) * 0,022 = (-0,726)
(-0,726) ist negativ, also Vehikel soll nach links lenken.

c. Die vorher eingestellte Geschwindigkeit war 60 und beide Motore drehen also mit dieser GStufe. Nun wird einfach von der GStufe des linken Motors das Produkt von 0,726 und der GStufe subtrahiert. 60 - (0,726 * 60) = 16,44. 16,44 ist also die GStufe der neuen Endgeschwindigkeit des linken Motors nach Ablauf der Bremsvorgangs in der Rampe. Der rechte Motor bleibt auf GStufe 60.

Code:

Gstufe 60 entsprach einer Geschwindigkeit des Vehikels von 25cm/s.
GStufe 16,44 entspricht
50000/GStufe = 50000 / 16,44 = 3041,36 abgerundet = 3041. (Vergleichswert für Timer1)
3041 * 1/1000000Hz = 0,003041s (pro Halbschritt)
1 / 0,003041s = 328,83Hz (Halbschritte pro Sekunde)
328,83Hz / 40 = 8,22rps (Motorwellenumdrehungen pro Sekunde)
8,22rps / 15 * 12,6cm = 6,9cm/s

Die linke Seite des Vehikels fährt also langsamer als die rechte Seite und wird wegen der starren Verbindung der beiden Seiten in eine Kurve gezwungen

Grobe Rechnung im Dreisatz wegen linearer Abhängigkeit aber ohne Rundung auf Ganzzahlen für Timer1 Vergleichswerte:
GStufe 60 entspricht 25,2cm/s
Gstufe 1 entspricht 25,2cm/s / 60 = 0,42cm/s
Gstufe 16,44 entspricht 16,44 * (25,2cm/s / 60) = 6,9cm/s


Ich hatte auch andere Lenkalgorithmen, nicht Steuer- oder Regelalgorithmen versucht, jedoch wieder verworfen. Sie hatten einen größeren Code und damit auch mehr Rechenzeit verursacht. Da ich immer noch die BASCOM Demoversion benutze, bin ich da begrenzt und die Rechenzeit darf auch nicht ins Unendliche wachsen, da ich bei einigen Versuchen meine schon an Timingprobleme in der Zusammenarbeit mit Hauptschleife - Rampe - Stepperinterrupts war. Steht außerdem der schnellen Datenanforderung vom Liniensensor-µC und deren Verarbeitung entgegen.

Im ATTiny für den Liniensensor ist jedoch noch einiges frei für das Aufbereiten der Lenksignale. Da könnte ich Deinem Vorschlag folgen und an dem Verhältnis von ADC-Messung und Lenkwerten drehen.

Hoffe es gibt Dir eine Vorstellung von der Funktion. Ist im Grunde sehr simpel und der Teufel steckt NUR im Detail. Keine Ahnung wie oft ich geflasht habe, bis offensichtliche Bugs beseitigt waren und das Ding so läuft wie es im Video zu sehen ist. Bin gerade dabei den Liniensensor, also den Kabelverhau vorne auf einer Platine zu zivilisieren. Grundplatte, das, wo der Batterietrog draufsteht und die Elektronik und Antriebsblock dranhängt, ist schon erneuert. Die war bei einem unfreiwilligen Sturz vom Tisch angebrochen. Zum Glück keine sonstigen Schäden.

Außerdem überlege ich das Poti für die Lenkung auf der Fernbedienung durch einen Drehencoder zu ersetzen. Das Poti gibt absolute Werte aus und wenn man den Linienmodus des SLF abschaltet, also wieder zur Fernbedienung zurückkehrt, macht sich das manchmal durch abrupte Lenkbewegungen bemerkbar. Das Poti steht eben manchmal ganz anders als der momentane Lenkeinschlag aus der Linien(ver?folgung. (Verfolgung manchmal, wenn die geringe Bodenfreiheit die losen, auf dem Boden liegenden Papplinien mal wieder vor sich her schiebt) Es gibt echt noch viel zu tun ...

Gruß
Searcher

Hallo Searcher, es gefällt mir ganz gut, wie dein Vehikel fährt. Ein super Video! =D>

Ohne jetzt die Regelstruktur zu kennen ist es schwierig einen Tipp zu Verbesserung zu geben. Nur so auf Verdacht vielleicht mal etwas zum Ausprobieren.
Wenn im normalen Linienbetrieb der Regler einen Regelanteil zu den beiden Winkelgeschwindigkeiten der Antriebsräder addiert/subtrahiert, dreht sich das Fahrzeug in Bezug zu der Linie. D.h. die Regelabweichung wächst kontinuierlich, wenn man die Richtung als Regelgröße annimmt. Das ist ein I-Verhalten der Regelstrecke. Das Schlingern ließe sich mit einem D-Anteil vielleicht etwas minimieren. Würde dann in der Praxis bedeuten - und das ist mein Tipp zum Ausprobieren - Gegensteuern proportional zu Änderung des Sensorwertes.

Zitat von witkatz

Eine interessante DÜ Technik und verspricht auch vom Ansatz her störungssicher zu sein.

Die Technik wurde zB in der Telekommunikation eingesetzt. Find ich auch interessant und weiß noch nicht so recht was ich hier auf meinem Linienstepper davon halten soll.

Denke auch das es störungssicher ist. Ich habe noch 1kΩ Widerstände in Reihe in den Verbindungsleitungen zwischen den µC falls mal durch Programmfehler zwei Ausgänge gegeneinander arbeiten. Die können noch entfallen und die relativ hochohmigen internen Pullup-Widerstände könnten noch durch externe unterstützt werden. Dadurch, daß jedes Bit quittiert wird, ist es vermutlich sehr schwer die Verbindung zu stören. Man könnte noch Zeiten einbauen, die ein Bit anstehen muß um als sicher erkannt zu gelten. Soviel will ich aber gar nicht und bis jetzt läuft es mit meiner wackeligen Stromversorgung im Linienstepper mit den stromfressenden Schrittmotoren prima. Weiß allerdings nicht, wieviele Bits verfälscht werden. Durch die pure Anzahl der Meßwerte gehen die möglicherweise unter und schlagen nicht sichtbar auf die Lenkung des Linienfolgers durch.

Die 4Bit Codierung könnte eigentlich entfallen, weil es sowieso nur Point-To-Ponint geht, oder?

Stimmt. Hab ich bisher noch nicht näher drüber nachgedacht. Wenn auf der Sende- und der Empfangsseite klar ist, wieviele Bits übertragen werden und welche Bedeutung die haben kann der "Funktionscode" wegfallen. zB nutze ich vom ADC nur ein 8 Bit Ergebniswert, der auch noch durch 2 shifts auf 6 Bit beschitten wird. Es würde reichen, nur diese 6 Bits, vielleicht 7 zu übertragen - müßte da in der Aufbereitung und im Fahrprogramm noch was anpassen, aber die 6 Bit würden reichen.

Den Funktionscode habe ich ja noch von der Fernbedienung mitgeschleppt. Da werden ja über Infrarot mit RC5-Code mittlerweile fünf Funktionen übertragen: Motorstrom ein-/ausschalten, vorwärts/rückwärts, Lenken, Geschwindigkeit und Linienmodus ein/aus. Dort möchte ich nicht auf den Funktionscode verzichten.

Mal sehen, ob es notwendig wird, die Paketlänge zu kürzen. Dadurch, daß Sende- oder Empfangsseite die Übertragung unterbrechen kann um dringendere Aufgaben zu erledigen, sehe ich das im Augenblick noch nicht.

Grund für die Einführung eines solchen Protokolls bei mir war ja, daß vom Mega88 die Schrittmotore über ISRs gesteuert werden. Damit die ISRs einen gleichmäßigen Takt liefern können, sollten sie nicht durch anderes gestört werden. Bei BASCOM kam die Störung durch die RC5 Empfangsroutine, die ja jetzt auf den RC5-Tiny ausgelagert ist und die Datenübertragung von dort getrost durch die Stepper ISRn unterbrochen werden kann.

Eine interessante DÜ Technik und verspricht auch vom Ansatz her störungssicher zu sein. Die 4Bit Codierung könnte eigentlich entfallen, weil es sowieso nur Point-To-Ponint geht, oder?

Mittlerweile habe ich auch die Empfangsseite der zweiadrigen seriellen Übertragung fertig geschrieben. Leider noch nichts Positives zu berichten. Geht natürlich nicht ABER positiv bei der Fehlersuche ist, daß man auch Fehler findet, die man gar nicht gesucht hat

Gruß
Searcher

Ich mach dich nur drauf aufmerksam, dass ich deine Idee, eine Art asynchrones Handshakeverfahren zur Datenübertragung zu nutzen unbedingt interessant finde und mit Zuversicht auf positive Errfahrungsberichte warte.

Gruß
witkatz