Der Weg zum eigenen Roboter: Tipps, Tricks und kleine Projekte

Von Peter Schneider

Sie haben den Roboter aus Band I nachgebaut und möchten diesen jetzt erweitern?
In Band 2 werden viele neue Möglichkeiten erklärt, wie Sie den Roboter mit analogen und digitalen Sensoren erweitern. Die dazugehörige Programmierung in C wird detailliert erklärt und zwar so, das auch der ungeübte Programmierer mit geringen Vorkenntnissen den Programmiercode versteht.

Aus dem Inhalt:
Rückblick auf Band I, was wurde erreicht?
Auswerten von Sensorsignalen (Polling, ISR)
Der Analog-Digital-Wandler
Timerprogrammierung, Teil II (der WatchDog)
Zusätzliche Sensoren für den Roboter
Steuern und Regeln mit dem Mikrocontroller (P-Regler)
Eine neue Steuerplatine auf Basis des ATmega32
Datenübertragung von PC zu Roboter (RS232, I²C-Bus)
Drahtlose Kommunikation via Bluetooth

Projekte:
Spannungsüberwachung des Akkus mit AD-Wandler
Liniensensor, folgen einer Linie auf dem Boden
Drehimpulsgeber, realisiert mit Gabellichtschranke
Gleichlauf der Räder (geradeaus fahren mittels P-Regler)
Roboter Steuerprogrammerweiterung um die Funktion AVIOD
Autonome Wegsuche durch ein Labyrinth
Ansteuern von Servos aus dem RC-Modellbau
Auslesen der Befehle von einem RC-Empfänger
Ansteuern eines bipolaren Schrittmotors

• Sprache: Deutsch
• Herausgeber: Books on Demand
• Erscheinungsdatum: 20. Sept. 2017
• ISBN: 9783744807951

Peter Schneider

Geboren 1941 in Treuen im Vogtland. Nach dem Abitur in Auerbach Pädagogikstudium für Geschichte und Russisch an der Martin-Luther-Universität in Halle/S. und anschließend Lehrer in Bad Lauchstädt und Güstrow. Zusatzstudium in Potsdam zum Diplompädagogen. Danach Inspektionsleiter für Wissenschaft, Bildung, Kultur beim Bezirkskomitee der Arbeiter-und-Bauern-Inspektion in Schwerin. Von 1986 bis 1990 Stadtrat für Kultur in Schwerin. Es folgten zwei Jahre im Historischen Museum Schwerin als Direktor und wissenschaftlicher Mitarbeiter. Beschäftigung mit den Hexenprozessen in Schwerin. 1996 Veröffentlichung der Ergebnisse Hexenwahn, Hexen und Hexenprozesse in Schwerin (Neuauflage April 2016 im Mecklenburger Buchverlag). Durch das Studium der Heilweisen der Heilerinnen des Volkes, der weisen Frauen, erste Bekanntschaft mit Heilungen auf geistigem Wege. 1992 Aufbau der Schuldnerberatungsstelle der Diakonie in Schwerin und Leitung derselben bis zum Eintritt des Rentenalters. 1996 Bekanntschaft mit den Möglichkeiten des therapeutischen Pendelns. 2003 Bekanntschaft mit den Lehren Bruno Grönings und der Heilung auf geistigem Wege. Nach einer Spontanheilung durch die Aufnahme des Heilstromes im Herbst 2004 seit Januar 2005 Leiter der Bruno Gröning-Gemeinschaft in Schwerin. Der Autor lebt in Banzkow bei Schwerin.

Buchvorschau

heilbar…

1. Rückblick auf die Arbeitsergebnisse des ersten Bandes

Das erste Kapitel soll einen Einblick geben welche Hardware, Software aus Band I übernommen wurde. Die wichtigsten Details des Roboters, der Platinen und Software werden noch einmal kurz wiederholt.

Folgende Lernziele sind Bestandteil dieses Kapitels:

Informationen zur verwendeten Roboterhardware.

Programmierhardware.

Verwendete Software zum Laden und Programmieren des Roboters.

1.1 Informationen zur verwendeten Roboterhardware

Im Band I wurde ein Roboter vorgestellt, der vollkommen im Selbstbau erstellt werden kann. Der nun folgende Abschnitt zeigt die wichtigsten Bauabschnitte und die dazugehörigen Baupläne. Sollte das zu kompliziert für Sie sein, alle z.B. Chassisteile aus 3mm Sperrholz oder PCV zu fertigen, dann können sie den kompletten Bausatz, inklusive Software bei Schneider-Engineerings bestellen. Siehe Weblink www.ps-robotics.de. In dem Roboterbausatz sind allerdings nicht die im weiteren verwendeten Programmier- und Testplatinen enthalten. Diese können allerdings separat bezogen werden.

Den prinzipiellen Aufbau der Roboters zeigt die Abbildung 1. Das Chassis besteht aus einer runden Holzplatte oder PVC in dem die Ausschnitte für die Räder eingelassen sind. Die Abbildungen 2 bis 6 zeigen die einzelnen Zeichnungen mit Maßangaben für die Bauteile der beiden Getriebe. Das Getriebe wird aus insgesamt drei Teilen zusammengesetzt und anschließend Messingrohre als Lagerung für die Achsen eingeführt. Die Messingrohre haben die Längen 26mm, 24mm und 22mm. Als Achsen können z.B. 3mm Gewindestange genutzt werden. Bitte beachten Sie, dass das Getriebe einmal für links und einmal für rechts aufgebaut werden muss. Das fertige Getriebe zeigen die Abbildung 7 bis 9. Alle zum Roboternachbau benötigten Materialien sind im Anhang dieses Buches aufgeführt.

1.1.1 Chassis Roboter R2PT3

Abb.: 1

Grundplatte des Roboters

Abb.: 2

Einzelteile des Getriebechassis:

Abb.: 3

Abb.: 4

Zusammenführen der einzelnen Getriebeteile

Abb.: 5

Halterung für Ladebuchse, Ausschalter und Resetknopf

Abb.: 6

Das fertige Chassis sieht nach Zusammenbau folgendermaßen aus:

Chassis mit Motorverkabelung

Abb.: 7

Chassis komplett inkl. Steuerplatine

Abb.: 8

Detailaufnahme des Getriebes

Abb.: 9

Stoßstange des R2PT3

Abb.: 10

1.1.2 Steuerplatine des Roboters

Für den Bau der Steuerplatine wurde eine handelsübliche Lochstreifenplatine mit den Maßen 90mm × 50mm verwendet. Mit einem 4mm Bohrer wurden die Leiterbahnen je nach Bedarf aufgetrennt. Die

Schaltplan

Abb.: 11

Zeichenerklärung zu den Platinenlayouts

Abb.: 12

Bohrplan der Steuerplatine

Abb: 13

Bestückungsplan der Steuerplatine

Abb.: 14

Die Abbildung 15 zeigt wie die einzelnen Komponenten miteinander verbunden werden. als Energieversorgung nutzen wir 6 × 1,2Volt 1100mAh Akkus vom Type AAA.

Somit liegen Ihnen alle Informationen vor, die Sie zum Nachbau des Roboters benötigen. Als nächstes folgt ein kurzer Rückblick in die Programmierung des Roboters.

Abb.: 15

1.1.3 Die Test- und Programmierplatine

Schaltplan der Test- und Programmierplatine

Abb.: 16

Die Programmierhardware wird benötigt, um den Bootloader „einmalig" auf den Mikrocontroller zu laden. Der Ladevorgang erfolgt mit dem Tool PonyProg2000 über ein spezielles Kabel, dass die RS232 des PCs mit der ISP Schnittstelle des Mikrocontrollers verbindet. Als Alternative stehen Ihnen für die Programmierung, als auch für das Aufspielen des Bootloaders, die von Atmel angebotenen, professionellen Programmierplatinen vom Type z.B. STK500 oder STK600 zur Verfügung. Die späteren Ladevorgänge der Software auf den Roboter erfolgen mit dem Programm Megaload. Die Software Megaload ist auf dem PC und lädt das zuvor kompilierte Programm mittels Bootloader in den Mikrocontroller. Als Compiler steht uns WinAVR zur Verfügung. Zur Programmentwicklung reicht ein einfacher Editor wie Notepad von Windows aus. Das C-Programm wird im Editor (z.B. Notepad) entwickelt, mit WinAVR kompiliert und anschließend mit Megaload auf den Mikrocontroller geladen.

Es gibt hier noch viel mehr zu erklären, aber das finden Sie ja alles in Band I erschöpfend erklärt.

Das war es nun mit dem Rückblick auf den Band I und Sie sollten nun einen Überblick über die genutzte Software und Hardware haben. Somit können wir uns nun ganz und gar auf den Inhalt des eigentlichen Band II konzentrieren. Anfangen wollen wir mit dem Analog-Digital-Wandler des ATmega8.

2. Auswerten von Sensorsignalen

Folgende Lernziele sind Bestandteil dieses Kapitels:

Flussdiagramme, auch Programmablaufpläne genannt

Signalauswertung über Polling

Signalauswertung über Interrupt

2.1 Flussdiagramme, auch Programmablaufpläne genannt

Mit einem Programmablaufplan werden die Auflistung der Programmabschnitte visualisiert und Verbindungen der einzelnen Funktionen aufgezeigt. Einen Programmablaufplan kann man beliebig detailliert gestalten. Ich habe mir folgende Vorgehensweise für das weitere Vorgehen überlegt in Bezug auf die Programmierung des Roboters. Bei komplexeren Funktionen möchte ich Ihnen die Abläufe bei der Programmabarbeitung mittels Flussdiagramm näher bringen. Die in Abbildung 17 gezeigte Visualisierung von Funktionen, Entscheidungen und Anweisungen müssen nicht zwangsläufig einer ISO Norm entsprechen und sind zum Teil auf meine Zwecke angepasst worden. Ganz wichtig, der Eine oder andere Leser wird sich jetzt sicher denken, was das doch für eine veraltete Darstellungsweise von Programmablaufplänen ist. Heute benutzt man schließlich XML. Gut, aber ich bin auch nicht mehr der Frischeste und für unsere Zwecke reicht ein Flussdiagramm völlig aus.

Somit steht uns ein Hilfsmittel zur Verfügung, das wir von nun an nutzen wollen. Beginnen werden wir bereits im nächsten Unterkapitel, in dem der Sourcecode für die Spannungsüberwachung beschrieben wird.

Abb.: 17

2.2 Signalauswertung über Polling

Eigentlich haben wir die Signalauswertung über Polling bereits unbewusst genutzt. Unter Polling versteht man die nicht zeitgesteuerte Abarbeitung von Funktionen oder Befehlen. Als Beispiel könnten wir hier den ständigen Aufruf der Funktion check_bat() in der while-Schleife des Hauptprogrammes nehmen. Immer, wenn der Mikrocontroller an dieser Programmzeile vorbeikommt, wird die Funktion aufgerufen und die Signale an dem Port PC3 abgefragt. Richtig? Nicht ganz, da noch eine Zeitsteuerung nachgeschaltet ist. Aber der Aufruf der Funktion check_bat() wäre ein klassisches Polling. Schauen wir uns das Flussdiagramm zum Thema Polling (Abb. 18) einmal an und ich denke, dann sollte es klar sein, das die Funktionen in einer Endlosschleife immer wieder abgefragt werden, ganz ohne Zeitsteuerung oder zeitlicher Kritikalität.

Abb.: 18

2.3 Signalauswertung über Interrupt

Schauen wir uns dazu einmal einen gewöhnlichen Programmablauf an. Das Programm wird gestartet, der Mikrocontroller wird initialisiert und geht dann in die Endlosprogrammschleife. In dieser Schleife werden alle Befehle und Funktionen abgearbeitet. Es werden Ports abgefragt und Befehle aufgerufen. Das ist auch alles so richtig, solange es keine zeitkritischen Vorfälle gibt, die umgehend, also ohne jeglichen Aufschub, bearbeitet werden müssen. Zum Beispiel an den Eingängen des Mikrocontrollers, also den Ports (z.B. die Sensoren melden etwas), kommt es zu einem äußeres Ereignis, auf das sofort reagiert werden muss (z.B. der Roboter stößt mit seiner Stoßstange gegen ein Hindernis). Zur Abarbeitung von zeitkritischen Ereignissen dieser Art benötigt man eine Interrupt Service Routine (ISR). Diese Routine wird durch ein Signal an dem INT0-oder INT1-Port des Mikrocontrollers aufgerufen (von z.B. einem Sensor kommend) und zwar so, dass das laufende Programm hart unterbrochen wird, die Daten gespeichert werden und die ISR abgearbeitet wird. Eine ISR sollte demzufolge recht kurz sein, so dass umgehend das laufende Programm weiter abgearbeitet werden kann. Welche Arten von Interrupts es gibt, zeigt die folgende Tabelle (siehe Abb.