Code III - Navigationsalgorithmus in Matlab

So, hier nun der Rest des Codes. Es gilt auch hierfür das bereits Gesagte: möglicherweise sind noch einige Schönheitsfehler in den Funktionen.

• init.m
• procfrm.m
• cog.m
• bav.m

Code II - Basisstation

Und hier nun der Bascom Code für die Basisstation. Tatsächlich habe ich nicht die Sorgfalt beim Aufräumen des Programms walten lassen, die ich eigentlich für angemessen halte. Im Ergebnis könnte es somit sein, dass noch eine ganze Menge Müll im Code rumliegt - etwa Dimensionierungen von Variablen, die dann doch niemals benutzt werden. Wie auch immer, voilà:

• vh1_basisstation.bas

Code I - Fahrzeug

Jetzt habe ich es endlich mal geschafft, zumindest das erste Drittel des Quellcodes meines vehikel[eins] Projektes aufzubereiten. Unten ist der Bascom-Code für das Fahrzeug verlinkt. Das Programm für die Basisstation sowie der Matlab-Code für die Bildverarbeitung fehlen noch. Leider habe ich zur Zeit ziemlich viel zu tun, ich werde trotzdem versuchen, den Rest zügig nachzureichen.

• vh1_fahrzeug.bas

Im Moment nichts Neues

Wenn schon mal ein Schaltjahr ist, will ich am 29.02. auch etwas posten. Allerdings kann ich nur den Hinweis machen, dass ich - so weit es meine Zeit zulässt - am Experimentieren bin, ich hoffe es gibt bei Zeiten mal wieder von kleinen Erfolgen zu berichten. Ach ja, den Quellcode vom aktuellen Stand hab ich immer noch nicht veröffentlicht – sorry, bin noch nicht dazu gekommen. Kommt bald. Wirklich.

vehikel[eins] als kamerabasierter Linienfolger

Kaum muss man ein paar Tage nicht arbeiten, schon kommt man endlich mal richtig zum arbeiten… Wie ja bereits angedeutet, waren meine Spielereien mit Ultraschall- und Infrarothindernisortung alles in allem etwas ernüchternd. Und da ich dieses Thema ja ohnehin nicht übermäßig spannend finde, habe ich es vorerst ad Acta gelegt und mich der meinem Geschmack nach wesentlich interessanteren Problematik der kamerabasierten („visuellen“) Navigation zugewandt. Mein erstes Projekt ist ein Linienfolger, also ein Fahrzeug, das eine auf dem Boden befindliche Line abfährt. Abgesehen von der recht simplen Algorithmik, eignet sich dieses Projekt gut zum Einstieg, weil es die verlässliche Funktion der gesamten, mittlerweile doch etwas komplex gewordenen „Infrastruktur“ des Systems erfordert, ich hier also zum ersten Mal alles „closed-loop“ betreiben muss - incl. Bildverarbeitung. Als neue Komponente dafür ist eine Frame-Grabber-Karte in meinen PC gekommen. Der Grabber digitalisiert das Videosignal vom Kameraempfänger und stellt es als einzelne Frames in MATLAB zur Verfügung, ich kann dann darauf rechnen und die extrahierten Informationen per RS-232 an meine Basisstation geben. Diese reicht die Steuerbefehle per Funk an das Vehikel weiter, das sich dann – wenn alles klappt – entsprechend verhält und dadurch wiederum den visuellen Input des Systems verändert.
Das über dem Bild verlinkte Video zeigt zum einen von oben, wie das Vehikel einen kleinen Parcours, den ich mit weißem Klebeband auf schwarze Pappe geklebt habe, „autonom“ abfährt. Das linke Bild des unteren Bilddrittels zeigt die Fahrt parallel aus Sicht des Vehikels. Um den zum „Erkennen“ der Linie verwendeten Algorithmus zur erleutern, sind noch ein paar weitere Dinge in dem Video dargestellt, die sogleich zur Sprache kommen sollen. Nach Spielereien mit wesentlich komplizierteren Ansätzen bin ich zu einem erstaunlich simplen Verfahren gekommen, um die Aktivierung der Motoren zu regeln. Nachdem ich per Schwelle ein 8-bit Graustufenframe von der Kamera in ein 1-bit Schwarzweißbild übersetzt habe, bestimme ich die Koordinaten des Schwerpunktes (center of gravity, COG) dieses Bildes und rechne dann die x-Koordinate des COG in die Aktivierung der Motoren um. Eine Abweichung der x-Koordinate des COG nach rechts von der Bildmitte führt dabei zu einer proportionalen Erhöhung der Drehgeschwindigkeit des linken Rades und einer proportionalen Verminderung Drehgeschwindigkeit des rechten Rades. Eine Abweichung des COG nach links von der Bildmitte hat entsprechend die umgekehrte Konsequenz. Befindet sich der COG in der Mitte der x-Dimension des Bildes, drehen beide Motoren gleich schnell. Links unten im Video ist nun die 1-bit Repräsentation des aktuellen Frames zu sehen, in grün eingezeichnet der COG, durch eine Linie verbunden mit der Mitte des unteren Bildrandes. Das original Kamerabild rechts zeigt in gleicher Weise den COG, dessen Koordinaten sind in den ersten beiden Zeilen angegeben, darunter die daraus errechnete Aktivierung des rechten und linken Motors in Prozent der Maximalgeschwindigkeit. In ein paar Tagen werde ich den BASCOM und MATLAB Quellcode posten.

Um Codec Probleme zu vermeiden, habe ich das Filmchen als Blogger Video eingebunden - trotz der durch die hohe Kompression miesen Qualität. Hier ist zusätzlich aber auch noch ein Link zu einem avi mit etwas besserer Qualität:

Video: [link]

2007 und zweite Projektetappe abgeschlossen

Angemessen verkatert erkläre ich zum Jahreswechsel die zweite Etappe meines vehikel[eins] Projektes für abgeschlossen. Die Elektronik ist seit kurzem soweit fertiggestellt, dass ich mit Experimenten der dritten Etappe beginnen konnte – und ein bißchen visuelle Navigation funktioniert auch schon, wie der nächste Beitrag zeigen wird.

Infrarot Näherungssensoren

Es ist schon einige Zeit her, dass ich mein Vehikel an den Seiten vorne und hinten mit Näherungssensoren ausgestattet habe. Deren Erforderlichkeit hatte sich recht schnell aus meinen ersten Navigationsversuchen ergeben. Ich hatte zunächst mit einigem Aufwand versucht, während einer Drehung aus den verschiedenen vom Echolot gemessenen Entfernungswerten den Winkel, den das Vehikel aktuell zur Wand hat, zu bestimmen. Daraus hätte man dann eine neue Bewegungsrichtung von der Wand weg ableiten können. Das ist leider nur in der Theorie einfach, in der Praxis multiplizieren sich verschiedene Unzulänglichkeiten derart, dass im Falle meines Vehikels dieses Verfahren zwar manchmal, aber längst nicht immer funktioniert. Ich habe gerade keine Lust, auf Details einzugehen, im Endeffekt zeigte sich, dass ich eine Wand, die nahe und tendenziell parallel zum Vehikel verläuft, nicht sicher aus der Echolotinformation erkennen kann. Damit war klar, dass ich an den Seiten Näherungssensoren benötigte, wobei ich allerdings eine binäre Information über den Abstand für ausreichend erachtet habe (Wand oder nicht Wand, das ist hier die Frage). Ich habe mich für eine Infrarot-Variante auf Basis des IS471F (Datenblatt: [link], relativ günstige Bezugsquelle: [link]) entschieden. Der Sensorbaustein enthält neben einem IR-Detektor dessen Auswertungselektronik und die Ansteuerungselektronik für eine extern benötige IR-LED (hier verwendet: Siemens LD274, Datenblatt: [link]). Das Licht einer angeschlossenen LED wird von der sensorinternen Logik mit ca. 8 KHz moduliert, nur reflektiertes Licht dieser Modulation wird von dem Sensor als Signal aufgefasst, im Ergebnis ist er somit recht immun gegen Fremdlicht. Um einstellen zu können, ab welchem Abstand der Sensor schaltet, habe ich den Vorwiderstand für die LED als Spindeltrimmer ausgeführt. Somit kann ich den LED-Strom, damit deren Leuchtstärke und also auch die vom Hindernis reflektierte Lichtmenge variieren. Leuchtet die LED heller, werden also schon weiter entfernte Hindernisse erkannt. Wie sich bei Versuchen zeigte, führt der recht große Öffnungswinkel des Sensors dazu, dass auch Hindernisse detektiert werden, die sehr schräg zur Fahrzeugseite verlaufen. Um dieses Phänomen einzuschränken, habe ich die Sensoren mit kleinen Kappen versehen, die den Sensor seitlich etwas abschatten. Den konkreten Aufbau am Vehikel zeigen die folgenden drei Fotos.
Ergebnisse des ganzen Aufwandes? Naja. Ich habe zwischenzeitlich begonnen, mit der kamerabasierten Navigation zu spielen (dazu bald mehr), weshalb die Experimente mit dem Ultraschall- und den IR-Sensoren vorerst in den Hintergrund getreten sind. Ich kann deshalb nur in aller Kürze von einigen Problemen berichten, die die IR-Sensorik hat. Ein (vorhersehbares) Problem, das ich (dennoch) erheblich unterschätzt habe, ist die Abhängigkeit der Detektionsleistung der Sensoren von der spektralen Reflektanz („Farbe“) der Hindernisoberfläche. Wenn man die Sensoren anhand einer weißen Fläche auf eine Entfernung einstellt, kann eine blaue Fläche dazu führen, dass der Sensor sich nochmal um 50% der Strecke nähern muss, um zu schalten. Außerdem verfügt der Sensor über eine Hysterese, die in vielen Fällen zwar sicherlich sinnvoll ist, mich hier aber eher stört. Im Ergebnis schaltet er bei Annäherung bei einem bestimmten Abstand, bei anschließender Entfernung in der gleichen Achse aber erst deutlich später wieder zurück.

Echolot

Soweit es meine Zeit zuließ, habe ich an meinem vehikel[eins] Projekt weitergearbeitet. Die Hardware ist ja mittlerweile fertiggestellt, sodass ich beginnen konnte, auf dem PC, der mit meiner Basisstation verbunden ist, erste simple Steueralgorithmen zu basteln. Ich verwende dafür nach wie vor Matlab, einfach weil ich es ziemlich stumpf runter schreiben kann – zum Experimentieren also genau das richtige. Ich habe mir zunächst die Routinen gebaut, die die Kommunikation mit dem Vehikel bewerkstelligen. Nachdem das akzeptabel funktionierte, habe ich begonnen, kleine Navigationsalgorithmen zu schreiben, die die über das Echolot gewonnenen Entfernungsinformationen verwenden. Einige Kleinigkeiten funktionieren schon, zufrieden bin ich damit allerdings längst nicht. Leider ist die Signalqualität des Ultraschallsensors nicht ganz so doll – aber zugegeben, mehr war auch realistisch gesehen wohl nicht zu erwarten. Um mal ein Gefühl für den Sensor zu bekommen, habe ich ein einfaches Experiment gemacht, dessen Ergebnis ich hier kurz vorstellen möchte. Ich habe mein Vehikel mittig (also auf dem Punkt x=y=40 cm) in einer 80 * 80 cm großen Box eine 360°-Wende machen lassen. Dabei habe ich die zum PC gefunkten gemessenen Entfernungen zur Wand während der Drehung mit den theoretischen (also aus dem Drehwinkel errechneten) Entfernungen verglichen. Das Ergebnis zeigt das unten stehende Bild. Da der Sensor einige Zentimeter vor dem Drehpunkt des Vehikels liegt, sind gemessene und berechnete Entfernung kleiner als 40 cm. Dass die gemessenen Peaks deutlich schärfer als die berechneten sind, zeigt, dass die Entfernung teilweise unterschätzt wird. Ich bin mir nicht im Klaren warum – die Box war zumindest wirklich quadratisch. Auch die „Asymmetrie“ der Antwort ist für meinen Geschmack größer, als es eine Ungenauigkeit in der anfänglichen Positionierung des Vehikels erklären kann. Was außerdem unangenehm auffällt, ist die teilweise Zerklüftung der gemessenen Peaks (siehe z. B. bei 135°, also der zweiten Ecke der Box). Die insgesamt etwas grobe Quantisierung in der Entfernungsdimension rührt daher, dass ich nur ein Byte für die Kodierung der Entfernung verwende und ein LSB dabei 1 cm entspricht – ggf. werde ich hier noch anders Skalieren. Auf jeden Fall wird deutlich, dass mögliche Orientierungsalgorithmen Mittelungen über einen gewissen Drehwinkel verwenden müssen, sonst gibt’s Gezappel. Daran bastel ich gerade… Quellcodes, BASCOM und Matlab, poste ich dann in kürze auch endlich mal, ich will sie vorher noch aufräumen.

Basisstation im 19-Zoll-Einschubrahmen (Kameraempfänger und Netzteil)

Jetzt sind auch die anderen beiden Module, Netzteil und Funkkameraempfänger, fertig. Die Bilder unten zeigen somit den vorläufigen Endzustand meiner Basisstation. Zu den beiden neuen Modulen ist wenig zu sagen. Der Kameraempfänger befand sich ja funktionsfertig in einem geschlossenen Gehäuse, ich habe dieses Gehäuse nur auf eine Eurokarte geschraubt und diese dann mit einer mit passenden Löchern versehenen Frontplatte verbunden. Die Antennenbuchse des ursprünglichen Gehäuses ragt direkt durch die Frontplatte hindurch. Da der Videoausgang sich auf der der Antenne gegenüberliegenden Seite befindet, habe ich diesen per Kabel zur Frontplatte verlängert. Ich habe mir in diesem Falle die Mühe gespart, ein Netzteil selbst zu bauen, ich habe mir ein billigst (3,95 €) Schaltnetzteil von Pollin besorgt (klassischer Restposten, gibt’s schon nicht mehr), und auch dieses auf eine Eurokarte geschraubt. Es liefert mir -5V, 5V und 12V mit ausreichender Belastbarkeit. Mit einer Frontplatte, einem Hauptschalter, einer Betriebs-LED und dem entsprechenden Wannenstecker für den Bus versehen, habe ich somit ein geeignetes Netzteilmodul.

Basisstation im 19-Zoll-Einschubrahmen (PC-Interface)

Nachdem ich die letzten eineinhalb Wochen für den Besuch zweier Tagungen verwendet habe, komme ich jetzt endlich wieder dazu, an meinem Roboter-Projekt weiter zu arbeiten. Ich habe heute den Umbau des PC-Interfaces der Basisstation abgeschlossen. Wie die Bilder zeigen, befindet sich das Interface jetzt - wie geplant - in einem 19-Zoll-Einschubrahmen. Das rechte Bild gibt einen Eindruck vom Aufbau. Die Platine ist mittels „Klötzchentechnik“ mit der Frontplatte verbunden – nicht schön aber selten. Ich habe darauf verzichtet, die einzelnen Module auf der Rückseite über die für dieses Gehäusesystem eigentlich vorgesehenen Stecker zu verbinden, stattdessen verwende ich einfache Wannenstecker. Die entsprechenden Gegenstücke gibt es als Quetschverbinder für Flachbandkabel, und da ich natürlich mehrere Verbinder auf ein Kabel setzen kann, ergibt sich somit eine einfache Möglichkeit ein Bussystem aufzubauen. Nach dem jetzigen Stand findet über diesen Bus nur die Verteilung der Versorgungsspannungen statt. Die beiden noch fehlenden Module (Kameraempfänger und Netzteil) sind in Arbeit und hoffentlich auch im Verlauf der nächsten Woche fertiggestellt.

Ultraschall

Das Ultraschallmodul zur Abstandsmessung ist mittlerweile da, montiert, angeschlossen und in Funktion. Die mechanische und elektrische Integration war denkbar simpel. Ich verwende das SRF05 Modul von Devantech [link], in Deutschland vertrieben durch robotikhardware.de [link]. Die Fotos zeigen, wie ich das Modul angebaut habe: es ist auf eine Lochrasterplatine geschraubt, in die Platine sind rechts und links oben zwei Elemente einer doppelreihigen Buchsenleiste gelötet. Auf der Hauptplatine befinden sich als Gegenstücke entsprechend zwei gewinkelte Pfostenstecker. Über die Kontakte der einen Seite ist das Ultraschallmodul elektrisch mit der Hauptplatine verbunden. Da das Modul leicht und keinerlei mechanischen Belastungen ausgesetzt ist, ist dies eine praktikable Befestigung, ich kann das Modul somit einfach abziehen. Sollte ich doch mal den Akku wechseln wollen, wäre das von Vorteil, dieser ist nämlich (ohne Rumgeschraube) nur von vorne zugänglich. Wie ich das Antwortsignal des Moduls softwareseitig auswerte, wird man in Bälde dem Quellcode entnehmen können. Schonmal in Kürze: der Objektabstand wird von dem Ulstraschallmodul in der Länge eines Antwortpulses kodiert. Also löse ich bei jedem Flankenwechsel dieses Signals einen Interrupt aus, und messe mit Timer0 des AVR (ja, ist nur ein 8 Bit Timer, reicht aber an Genauigkeit für meine Zwecke) den Abstand zwischen den Interrupts (d. i. Flankenwechseln). Erfreulicherweise verhält sich das Modul einigermaßen linear, sodass ich die gemessene Zeit schlicht über einen (empirisch ermittelten) Faktor in den Abstand umrechnen kann. Das Ergebnis verschicke ich dann per Funk an die Basis. Funktioniert prima.

Basisstation

Auch wenn ich hier jetzt schon länger nichts habe von mir hören lassen, habe ich natürlich dennoch fleißig weitergearbeitet. Zu sehen gibt es heute mal ein Bild von meiner "Basisstation", also dem Interface zwischen PC und Vehikel. Der Aufbau ist aktuell noch provisorisch, bei Zeiten werde ich alles (Netzteil, Basisstation, Funkkameraempfänger) zu Modulen für ein 19-Zoll Einschubgehäuse umbauen.
Die bidirektionale Kommunikation zwischen Vehikel und PC funktioniert mittlerweile, das Prinzip dabei ist folgendes: Der PC sendet per RS-232 an die Basisstation Datenpakete à 16 Byte. Darin sind bisher die Schrittfrequenz für beide Motoren und die Stellung der Kamera kodiert (ich habe also noch einige Bytes übrig, um anderes zu übertragen). Die Basisstation sendet ein empfangenes Paket dann per Funk weiter an das Vehikel. Das Vehikel reagiert entsprechend der Befehle und antwortet seinerseits mit einem 16 Byte großen Datenpaket. Dieses wird wiederrum von der Basisstation über die serielle Schnittstelle an den PC übertragen. Darin enthalten sind "sensorische" Informationen, zum einen über die Akkuspannung, bald außerdem das Signal eines Ultraschallsensors, mit dem ich den Abstand zu Hindernissen messen möchte. Ein Vorteil dieser einfachen Kommunikationsform ist, dass die Updaterate der Datenpakete vom PC bestimmt wird: ich kann viel oder wenig Pakete pro Zeit verschicken. Da die Antwort des Vehikels durch den Empfang eines Paketes getriggert wird, ist somit auch die Antwortrate definiert. Im Moment arbeite ich mit einer Rate von etwa 100 Hz, d.h. ich verschicke ca. 100 Datenpakete pro Sekunde (man stelle sich das mal per Post vor...), und bekomme also auch 100 zurück. Daraus resultiert somit eine Reaktionslatenz des Vehikels von maximal etwa 10 ms - meiner Einschätzung nach ausreichend für die Maximalgeschwindigkeit, von der ich z. Zt. ausgehe. Um auf die Schnelle mal eine einfache Ansteuerung per Computer zu realisieren, habe ich ein paar kleine Matlab-Funktionen geschrieben, die mir die jeweils gewünschten Befehle per RS232 verschicken und die Antwortpakete einlesen und auswerten. Auf die Dauer ist Matlab natürlich zu lahmarschig, mittelfristig werde ich also auf eine andere Entwicklungsumgebung umsteigen. Wenn die Software insgesamt (also auch der Bascom-Code für Vehikel und Basisstation) "rund" ist, werde ich alles hier veröffentlichen – noch ist der Code definitiv zu schmutzig (ich bin da etwas gênant).
Neben der Computersteurung beitet die Basisstation außerdem einen "manuellen Modus", bei dem ich das Vehikel per Hand unabhängig vom PC steuern kann - nur für den Fall, dass die autonome Navigation irgendwann mal in eine Sackgasse geführt hat. Dazu habe ich zwei Joysticks (so Billigdinger für Gamecontroller) verwendet, allerdings benutze ich pro Steuerkreuz nur eine Dimension, mit der ich dann jeweils ein Rad aktiviere. Ich hatte erst eine Version mit nur einem Joystick aufgebaut, weil die Dinger aber sehr unpräzise sind, mangelte es dabei etwas an "Freude am Fahren". Jetzt steuert man das Vehikel wie einen Panzer - zumindest glaube ich als alter Zivi, dass man einen Panzer so steuert.
Noch ein paar Worte zur Technik: als µC verwende ich in hier einen AVR Mega162. Da dieser keine A/D-Wandler hat, digitalisiere ich das Joysticksignal mittels eines PCF8591, der über I2C am AVR hängt. Das sieht auf den ersten Blick etwas ungeschickt aus, schließlich hätte ich ja einfach einen Mega32 mit integrierten ADCs verwenden können. Der Grund, es dennoch so zu machen, ist schlicht: den Mega162 hatte ich noch rumliegen, außerdem wollte ich seit längerem mal was mit dem PCF8591 machen, so bot sich diese Variante an.
So, jetzt warte ich nur noch, dass der Ultraschallsensor endlich bei mir eintrifft, dann kann’s weitegehen. Langsam wird’s spannend…

Funky!

Die Funkverbindung steht. Zwar habe ich noch kein endgültiges Protokoll entwickelt, bin aber immerhin schon mal sehr zufrieden, dass ich beliebige Daten drahtlos zwischen Vehikel und Basisstation übertragen kann – und zwar bidirektional. Es existieren im Netz mittlerweile einige BASCOM-Codefragmente, die die Ansteuerung der RFM12-Module bewerkstelligen. Die Software für meine erste Testfunkstrecke habe ich aus solchen Beispielprogrammen zusammengestöpselt, es waren nur kleinere Anpassungen an meinen Aufbau nötig. Wer einfach nur an Beispielcodes interessiert ist, bemühe google mit der entsprechenden Suchanfrage [link], so habe ich es auch getan.
Hier dann auch gleich mal ein paar Bilder vom jetzigen Aufbau. Für das RFM12-Modul habe ich mir eine kleine Adapterplatine gemacht, weil dessen Anschlüsse im Rastermaß 2 mm angeordnet sind. Die Antenne für das Modul habe ich mir aus dem obersten Glied einer alten Teleskopantenne gebastelt, ich habe dieses auf λ/4 ≈ 173 mm (f=433 MHz entspricht ca. λ=0.69 m) gekürzt und in einen dazu aufgebohrten M3 Sechskantbolzen gelötet. Wie man sieht, ragt aus der Platine eine M3 Schraube, auf die die Antenne geschraubt werden kann. Über eine Lötfahne auf der Platinenunterseite ist die Schraube - und damit die Antenne - an den Antennenpin des Moduls angeschlossen. Ansonsten befindet sich auf der Platine mittlerweile ein zweizeiliges LCD und ein PCF8574 über den ich (bisher nur) zwei Tasten abfrage. Der Aufwärtswandler, den ich für das Kameramodul aufgebaut habe, ist aus weiter unten genannten Gründen unbenutzt, ich werde ihn vorerst nicht abreißen, denn man weiß ja nicht, wozu man den nochmal zu gebrauchen kann.

Maximale Autonomie :)

Hier mal ein erstes kleines Video meines Vehikels in Bewegung. Das Vehikel ist im Moment in höchstem Maße autonom, es fährt stumpf seinen Weg ab, ohne sich auch nur im geringsten um seine Umwelt zu kümmern... im Ernst: ich habe es zum Testen so programmiert, dass es 500 mm geradeaus fährt und dann eine 90° Wende macht. Daraus resultiert das Verhalten, das man in der rechten Bildhälfte des Videos sehen kann. Die linke Bildhälfte zeigt den ganzen Vorgang parallel aus Sicht der Vehikelkamera - dies ist also die eigentlich interessante Information. Die Bildqualität ist im Original etwas besser als der Film vermuten lässt - aber trotzdem noch schlecht genug.

Nur der Vollständigkeit halber.

Es ist nun nichts besonderes, aber ich poste trotzdem noch schnell ein Bild (jaja, ich weiss, die Qualität ist mies...) von dem In-System-Programming (ISP) Interface für mein Vehikel. Ich verwende die STK200/300 kompatible Variante für den Druckerport, der Schaltplan findet sich z. B. hier [link]. Da beim Mega32 die Pins für das ISP-Interface direkt nebeneinander liegen, habe ich die Pins für mein Interface ebenso angeordnet - das minimiert den Verdrahtungsaufwand am Controller. Das Bild zeigt den fertigen Programmieradapter, oben links sind zwei Aufnahmen von der Schaltung, bevor ich sie mit Schrumpfschlauch eingepackt habe. Der Aufbau war simpel genug, um auf Anhieb zu funktionieren.