Dirk (Diskussion | Beiträge) K (→Probleme) |
Dirk (Diskussion | Beiträge) K (→Probleme) |
||
| Zeile 2.242: | Zeile 2.242: | ||
====Probleme==== | ====Probleme==== | ||
| − | Bei meinem WTR kommt es selten zu einem Problem mit der Stromversorgung | + | Bei meinem WTR kommt es selten zu einem Problem mit der Stromversorgung in Form eines "Aufhängens" des Motor Controllers bei extremen Wechseln der Geschwindigkeit der Motoren, z.B. von 0% auf 100% PWM. Dies liegt offenbar an einem kurzzeitigen Einbruch der Versorgungsspannung VCC (5V) des Motor Controllers bei einem sehr raschen Anstieg des Versorgungsstroms der Motoren. |
| + | |||
| + | Es gibt für dieses Problem 3 mögliche Lösungen, wobei die Sicherheit, dass das Problem nicht mehr auftritt, von der ersten bis zur dritten Lösung zunimmt: | ||
| + | |||
| + | * 1. Die Motoransteuerung erfolgt nur mit einer verzögerten Beschleunigung: | ||
| + | ** Die Motor Library ab Version 2.0 ermöglicht eine "sanfte" Motoransteuerung. | ||
===Sensoren=== | ===Sensoren=== | ||
Version vom 10. Januar 2016, 15:22 Uhr
Inhaltsverzeichnis
- 1 Was bisher geschah
- 2 Allgemein
- 3 Eigenschaften
- 4 Aufbau
- 5 Inbetriebnahme
- 6 Stromversorgung und Akku-Ladung
- 7 Technik
- 8 Umbau-Optionen
- 9 Zubehör und Ersatzteile
- 10 Programmierung
- 11 Erfahrungsberichte
- 12 Siehe auch
- 13 Weblinks
- 14 Autoren
Was bisher geschah
- Februar 2009 - User "Oddbot" entwickelt im Forum Let's Make Robots eine vielseitige 6WD Roboter Plattform.
- Januar 2010 - Die Firma DAGU Hi-Tech Electronics, LTD in Zhongshan (ein Joint-Venture Unternehmen von AREXX (Holland) und DLR_School_Lab Oberpfaffenhofen) beginnt die Auslieferung der serienreifen Roboterplattform.
- 04.02.2010 - Russell Cameron zeigt ein DAGU Demo-Video.
- 04.02.2010 - Russell Cameron zeigt ein weiteres Video, in dem der Wild Thumper Roboter ("WTR") Treppen steigt.
- Auch bei Pololu wird der Wild Thumper in verschiedenen Varianten angeboten: 4WD (bei DAGU auch mit Greifer), 6WD, Ausführung Silber oder Schwarz, mit 34:1 oder 75:1 Getrieben und Felgen in Chrom, Gold oder Metallic-Rot.
- CONRAD, voelkner, CPC Farnell und weitere Händler bieten den WTR (Arexx Allrad Gelände Roboterplattform JSR-6WD) und eine passende Controllerplatine (Arexx Ansteuerungsmodul WTR-CK1) unter dem AREXX Hersteller-Label an.
- 29.06.2010 - User "TobiKa" erwähnt erstmals im RoboterNETZ Forum, dass der WTR bei CONRAD erhältlich ist.
- 19.11.2010 - User "oratus sum" stellt den WTR genauer vor.
- 13.08.2015 - User "Dirk" beginnt mit diesem Artikel zum Wild Thumper in RN-Wissen.
Allgemein
In diesem Artikel geht es um den AREXX Wild Thumper Roboter (JSR-6WD) mit AREXX Wild Thumper Controller (WTR-CK1). Zur Programmierung des Wild Thumper Roboters mit Controller WTR-CK1 gibt es eine eigene Seite: Wild Thumper - Programmierung
Das dauert und ist solange eine ...
BAUSTELLE ... BAUSTELLE ... BAUSTELLE ... BAUSTELLE ... BAUSTELLE ... BAUSTELLE
Eigenschaften
WTR
Beschreibung
(Laut Online-Katalog der Firma CONRAD!)
"Der "Wild Thumper" ist eine robuste Gelände-Roboterplattform, welche speziell für den Roboterliebhaber entworfen wurde. Eine ideale Plattform für Wettbewerbe wie die Rettungsroboter, Bombenentschärfung und Feuerbekämpfung. Zur Vereinfachung der Montage von Leiterplatten, Sensoren und Hardware verfügt die Plattform und das Oberdeck über 4 mm Löcher in 10 mm Rasterabständen. Die einzigartige "Supertwist"-Radaufhängung wurde so entworfen, dass zur maximalen Antriebsleistung alle Räder die Bodenhaftung beibehalten. Zur Optimierung des Antriebs bei unterschiedlicher Belastung bzw. Geländestruktur kann die Traktion justiert werden. Die sechs leistungsfähigen Motoren mit ihren Stahlboxgetrieben erleichtern den Einsatz auch in schwerem Gelände bei steiler Hanglage. Zwischen den Rädern befinden sich zwei geräumige Boxen zur Unterbringung von bis zu 4 x 7,2 V sub C Batteriepaketen, die normalerweise für RC-Fahrzeuge verwendet werden. Die Aufhängung besteht aus einfachen, jedoch robusten Torsionsfedern mit Gummibefestigung zur stabilen aber auch flexiblen Verbindung. Mehrfache Verbindungsstellen erlauben die Anpassung der Federkraft und des Federhubs. Die Getriebekästen enthalten jeweils ein robustes Stahlgetriebe mit langlebigen Messingbuchsen."
Ausstattung
- Korrosionsbeständiges, anodisiertes Aluminiumgehäuse
- Einstellbare "Supertwist"-Radaufhängung
- Riesige Gummireifen mit griffigen Stollen
- 6 leistungsfähige Motoren mit Stahlboxgetrieben
- 2 Batteriebehälter für 7,2 V sub C Batteriepakete
- Geräumiges Oberdeck zur Unterbringung der Verkabelung und Aufbauten.
WTR-CK1
Beschreibung
(Laut Online-Katalog der Firma CONRAD!)
"Das Ansteuerungsmodul bildet die komplette Ansteuerungselektronik für die "Wild Thumper“ Allrad Gelände Roboterplattform JSR-6WD Best.-Nr.: 19 14 28. Die Steuerungsbox basiert auf zwei ATMEL Mikroprozessoren, die miteinander kommunizieren. Einer dieser Prozessoren kümmert sich um die Kommunikation und das Ablesen der Sensoren. Der zweite Prozessor ist zuständig für die Ansteuerung der sechs Motoren mittels hocheffizienter H-Brücken. Zur Ansteuerungselektronik gehören standardmäßig zwei APC-220 Funktransceiver für das 433 MHz Frequenzband. Außerdem liefern wir zum System einen Programmieradapter einschließlich der benötigten Loader-Software, sodass beide Prozessoren auf einfache Weise programmiert werden können. Die Ansteuerungsprogramme werden in C geschrieben, mit Hilfe des WINAVR kompiliert und anschließend in eine HEX-Datei umgewandelt. Wie bei allen AREXX-Robotersystemen stehen auch für den "Wild Thumper" viele Anschlüsse für Ein-/Ausgänge und ein I2C-Bus zur Verfügung, damit sie am System selbst verschiedene Applikationen anschließen können. Die Programmerstellung für den "Wild Thumper" ist sicherlich keine Aufgabe für Anfänger. Wir stellen jedoch in der Lieferung ein komplettes Softwarepaket zur Verfügung, womit sie den "Wild Thumper" drahtlos mittels den zwei APC-220 Modulen steuern können. Diese Software enthält eine Option zur Umschaltung auf den sogenannten Autonomen Modus, in dem der Roboter selbstständig weiterarbeitet, autonom Objekte detektiert und aus dem Weg geht. Außerdem ist es in einer Computerapplikation möglich Bilder aus einem Funkkamerasystem dar zu stellen. Das Funkkamerasystem gehört nicht zum Lieferumfang dieses Ansteuerungsmoduls!"
Lieferumfang
- 2 leistungsfähige ATMEGA 644 Prozessoren
- 6 hocheffiziente Magnet Drehzahlgeber für Odometrie
- 6 Rad-Encoder-Module mit HALL Sensoren
- Motor Strom Überwachung für alle 6 Motoren
- Spannungsüberwachung
- Frontplatine mit Berührungsschalter, Licht- und Infrarot-Strahlungssensoren
- 12 integrierte LEDs
- Programmieradapter mit USB- und Funkkommunikation
- 2 APC-220 Module
- 6 Encoder-Magnetringe zur Befestigung auf der Radachse
- Montageteile
- Anschlusskabel
- Steckverbinder
- CD mit Bedienungsanleitung und Software.
Aufbau
WTR und WTR-CK1 kommen in einem großen Paket an. Der WTR ist komplett aufgebaut,- es müssen nur die 6 riesigen Räder (Durchmesser 12cm, Breite 6 cm, Chromfelgen, V-Profil mit Spikes!) montiert werden. Dazu müssen die 6 Achsadapter mit einem mitgelieferten 6-Kant-Schlüssel auf die Motorachsen geschraubt werden. Sie sollten etwas Spiel zum Messing-Lager haben, damit nichts klemmt. Dann werden die 6 Räder auf die Achsadapter geschraubt. Das war's. Wenn's perfekt werden soll, beachtet man die Laufrichtung der Reifen: Das V-Profil der Reifen sollte mit seiner Spitze nach vorn in Fahrtrichtung zeigen, wenn man von oben auf die Reifen sieht.
Der WTR ist so an einer 6-poligen Lüsterklemmen-Leiste verdrahtet, dass jeweils die linken 3 und die rechten 3 Motoren parallel geschaltet sind. Das ist sicher die häufigste Art, wie der WTR mit anderen Controllern betrieben wird: Man braucht dann nur 2 Motortreiber (mit H-Brücken), um den WTR zu steuern.
Da ich den WTR mit dem AREXX Controller WTR-CK1 nutzen will, sieht die Sache anders aus: Der WTR-CK1 kann jeden Motor einzeln ansteuern, hat also 6 Motortreiber. Man muss daher die Kabel der Motoren von der Lüsterklemme lösen. Dazu später mehr.
Erst einmal etwas Anderes: die Stromversorgung des WTR. Ich habe mir gleich die empfohlenen LiPo Akkus 7,4V 4600mAh (2 Stück) mit bestellt. Sie passen perfekt in die "Wannen" zwischen den Radachsen. Diese Akkus haben ein kurzes Anschlußkabel mit 3-poliger LiPo-Balancer Steckbuchse (XH) und einer Hochstrom-T-Buchse für den Stromanschluß. Da das Akku-Anschlußkabel zu kurz ist, um den Akku mit der Controller-Platine WTR-CK1 zu verbinden, braucht man ein "Verlängerungskabel". Ich habe mich für das Modelcraft T-Stecker-Akkukabel 2.5 mm² 300 mm (2 Stück) entschieden. An einem Ende sitzt ein Hochstrom-T-Stecker zur Verbindung mit dem Akku-Anschlußkabel, das andere Ende ist offen und wird später an die Akku-Schraubklemm-Buchse des WTR-CK1 angeschraubt.
Um die Akkus einzubauen, muss man die obere Lochplatte des WTR komplett abschrauben. Die Akkus habe ich in etwas Schaumstoff gelegt zur Abpolsterung. Dann kann die obere Lochplatte wieder aufgeschraubt werden, diesmal aber nicht mit den M3-Schrauben, sondern mit den 8 M3-Abstandhaltern, die zum Lieferumfang des WTR-CK1 gehören. Vor dem Aufschrauben der oberen Lochplatte beachten: Alle Motorkabel sollten schon von der Lüsterklemme gelöst sein (s. Abb. rechts)!
Nun ist der WTR perfekt vorbereitet, und es kann nahtlos mit dem Controller WTR-CK1 weiter gehen. Die große Controller Platine wird auf den 8 Abstandhaltern so mit M3-Schrauben befestigt, dass der Infrarot-Empfänger TSOP (U9) nach vorn zeigt. An der abgewinkelten Vorderseite der oberen Lochplatte wird nun auch die Bumper- und Sensor-Platine mit 4 Abstandhaltern, Schrauben und Muttern befestigt (siehe Anleitung Wild_Thumper_Steuerplatine.pdf, Version 0610, Seite 12!). Ich würde sie auch gleich mit dem mitgelieferten 14-poligen Flachkabel mit der Hauptplatine (HDR5) verbinden.
Jetzt gilt es, die Motorstrom-Kabel der 6 Motoren anzuschließen. Dazu gibt es 6 grüne 2-polige Motor-Schraubklemm-Buchsen. Das rote (+) und das schwarze (-) Kabel jedes Motors ist ja bereits abisoliert, und beide Kabel werden verdrillt in die Öffnungen der Motor-Schraubklemm-Buchse eingeführt (vorher aufschrauben!) und festgeschraubt. Dabei wird das schwarze (-) Kabel jeweils in Fahrtrichtung vorn des WTR angebracht. Dann werden die 6 Motor-Schraubklemm-Buchsen in die seitlich offenen Steckerleisten Motor 1 (J5) bis Motor 6 (J14) der Controller-Platine eingesteckt.
Bevor nun der Akku an den WTR-CK1 angeschlossen wird, muss der Ein-/Ausschalter (S1) auf der Controller-Platine in Stellung AUS gebracht werden (Hebel nach Fahrtrichtung vorn gekippt!). Die offenen Enden des "Akku-Verlängerungskabels" werden passend gekürzt, abisoliert und leicht verdrillt in die Öffnungen der 4-poligen Akku-Schraubklemm-Buchsen eingeführt (vorher aufschrauben!) und festgeschraubt. Das rote (+) Kabel wird in die Öffnung eingeführt, die auf der Controller-Platine mit "+" gekennzeichnet ist. Ich habe für jeden Akku eine eigene Akku-Schraubklemm-Buchse benutzt,- 2 Pole der 4-poligen Buchsen bleiben frei. Dann werden die T-Stecker der beiden Verlängerungskabel mit den Akku-Anschlußkabeln verbunden. Abschließend werden die beiden Akku-Schraubklemm-Buchsen in die seitlich offenen Steckerleisten J2 und J3 der Controller-Platine eingesteckt. Bitte VORHER unbedingt den Absatz Akku-Ladung komplett lesen! Damit ist nun auch die Stromversorgung verkabelt. Alle Kabel würde ich dann mit Kabelbindern am WTR Chassis befestigen, damit sie nicht in die Räder geraten können. Dabei müssen sich die Radaufhängungen nach oben und unten frei bewegen können.
So, es geht zum Endspurt des Aufbaus. Was noch fehlt sind die Radencoder-Anschlüsse. Anfangs wurde der WTR ohne Radencoder geliefert, so dass der Controller-Platine WTR-CK1 6 Bausätze von Radencodern beiliegen. Diese wurden zwischen Motor und Rad eingebaut. Inzwischen wird der WTR (unter dem AREXX Hersteller-Label) mit 6 Encoder-Motoren geliefert. Das schwarze Anschlußkabel der Encoder besitzt am Ende vier 1-polige Steckbuchsen für Stiftleisten mit RM 2,54mm. Diese kann man direkt einzeln auf die Innenstifte der Encoder-Wannenstecker (J4, 7, 8, 11, 12, 15) auf dem WTR-CK1 einstecken. Schaut man auf einen der Encoder-Wannenstecker (Stifte innen sichtbar), dann ist die Belegung:
- Links -> Plus (+)
- Mitte -> Signal
- Rechts -> Minus (-)
Die 1-poligen Steckbuchsen der Encoder steckt man also so ein:
- Links -> Rot (+)
- Mitte -> Weiß ODER gelb (Signal)
- Rechts -> Schwarz (-)
Wenn alles richtig verkabelt wurde, dann zeigen auf der linken WTR-Seite die roten Plus-Kabel nach vorn in Fahrtrichtung. Auf der rechten WTR-Seite zeigen die schwarzen Minus-Kabel nach vorn. Eine 1-polige Steckbuchse (gelb ODER weiß) wird nicht benutzt. Auch die Encoder-Kabel würde ich mit Kabelbindern am WTR Chassis befestigen, damit sie nicht in die Räder geraten können. Dabei müssen sich die Radaufhängungen nach oben und unten frei bewegen können.
Die Encoder-Kabel der beiden vorderen Motoren (3, 4) sind sehr knapp bemessen und bei mir sehr straff gespannt. Das werden wir später noch ändern. Die 1-poligen Steckbuchsen der Encoder passen auch nicht sehr gut zu den Encoder-Wannensteckern auf dem WTR-CK1. Auch das würde ich noch ändern. Die sechs Radencoder im Lieferumfang des WTR-CK1 nutze ich jedenfalls nicht,- sie bleiben im Karton.
Nun ist erst einmal alles für einen ersten Test bereit.
Inbetriebnahme
Vor dem Einschalten des WTR sollte man ihn aufbocken, so dass alle Räder den Boden nicht berühren und frei drehen können.
Schaltet man dann mit Kippschalter S1 EIN, sollte die grüne LED 1 leuchten, und die beiden grünen LEDs 7 und 8 sollten blinken. Sonst passiert nichts. Damit ist klar:
- Es liegt Akkuspannung an (LED 1)
- Der "Motor Controller" ATmega644 (U4) arbeitet (LED 7)
- Der "Main Controller" ATmega644 (U11) arbeitet (LED 8)
Hat alles bis hierher geklappt, können wir den WTR auch wieder ausschalten, denn es gibt zuerst noch einiges zu tun.
Software Installation
Die Software Installation wird nun nach Deutsch-sprachiger Anleitung (Wild_Thumper_Steuerplatine.pdf, Version 0610) Kapitel 7 (Seiten 23 ff.) durchgeführt und hier nicht näher beschrieben, da sie abhängig vom Betriebssystem erfolgt. Auch die Installation des USB-Treibers und der Anschluß des USB-Interfaces, sowie die Installation des RobotLoaders (Kapitel 8) erfolgen nach dieser Anleitung.
Am Ende dieses Prozesses sollten zwei Dinge sicher funktionieren (z.B. Windows):
- Programmer's Notepad (PN2 als Bestandteil von WinAVR) sollte aufrufbar sein und eine leere Bearbeitungsfläche zeigen
- Der RobotLoader sollte aufrufbar sein (vorher das USB-Interface mit dem PC verbinden). Im Fenster links oben "Schritt 1: Port wählen" steht bereits eine Port-Bezeichnung (z.B. USB0|RP6 USB Interface|ARV82BPV o.ä.)
Wenn diese Punkte erfüllt sind, ist die Software Installation erfolgreich abgeschlossen.
Einrichten der Demo Programme
- Für die WTR Programme legen wir auf der Festplatte z.B. unter ...\UserName ein neues Verzeichnis \WTR an.
- Von der Wild Thumper CD-ROM kopieren wir die Verzeichnisse \Firmware und \WTExamples in unser neues Verzeichnis \WTR auf der Festplatte.
- In \WTR legen wir ein neues Verzeichnis \WTRLib an.
- In \WTRLib legen wir 3 neue Verzeichnisse an: \Common, \Main und \Motor.
- Aus dem Ordner ...\Firmware\AVR\Wild_Thumper_Main kopieren wir die Dateien:
- WT_Config_Main.h in den Ordner \WTRLib\Main,
- WildThumperLib_Main.h in den Ordner \WTRLib\Main,
- WildThumperLib_Main.c in den Ordner \WTRLib\Main,
- WT_UART.h in den Ordner \WTRLib\Main,
- WT_UART.c in den Ordner \WTRLib\Main,
- WT_I2Cmaster.h in den Ordner \WTRLib\Common,
- WT_I2Cmaster.c in den Ordner \WTRLib\Common.
- Aus dem Ordner ...\Firmware\AVR\Wild_Thumper_Motor kopieren wir die Dateien:
- WT_Config_Motor.h in den Ordner \WTRLib\Motor,
- WildThumperLib_Motor.h in den Ordner \WTRLib\Motor,
- WildThumperLib_Motor.c in den Ordner \WTRLib\Motor,
- WT_UART.h in den Ordner \WTRLib\Motor,
- WT_UART.c in den Ordner \WTRLib\Motor,
- WT_I2Cslave.h in den Ordner \WTRLib\Common,
- WT_I2Cslave.c in den Ordner \WTRLib\Common.
- Im Ordner \WTExamples\Main examples befinden sich schon 5 Unterordner mit einzelnen Demos für den Main Controller. In diesen Unterordnern machen wir Folgendes:
- \Selftest -> nichts
- \WT_I2C -> alles löschen bis auf: WT_I2C.c
- \WT_LED -> alles löschen bis auf: WT_Led.c
- \WT_Move -> alles löschen bis auf: WT_Move.c
- \WT_UART0 -> alles löschen bis auf: WT_UART0.c
- Im Ordner \WTExamples\Main examples erstellen wir einen neuen Unterordner \WT_Main und kopieren die Datei Wild_Thumper_Main.c (aus dem Ordner \Firmware\AVR\Wild_Thumper_Main) hinein.
- Im Ordner \WTExamples\Motor examples befinden sich schon 3 Unterordner mit einzelnen Demos für den Motor Controller. In diesen Unterordnern machen wir Folgendes:
- \Selftest -> nichts
- \WT_LED -> alles löschen bis auf: WT_Led.c
- \WT_UART0 -> alles löschen bis auf: WT_UART0.c
- Im Ordner \WTExamples\Motor examples erstellen wir einen neuen Unterordner \WT_Motor und kopieren die Datei Wild_Thumper_Motor.c (aus dem Ordner \Firmware\AVR\Wild_Thumper_Motor) hinein.
- Den kompletten Ordner \Firmware brauchen wir nicht mehr und können ihn löschen.
- In alle Unterordner von \Main examples und von \Motor examples kopieren wir ...
- eine Textdatei make_all.bat mit dem Inhalt:
set LANG=C make all
- In alle Unterordner von \Main examples und von \Motor examples kopieren wir ...
- eine Textdatei make_clean.bat mit dem Inhalt:
set LANG=C make clean
- In alle Unterordner von \Main examples kopieren wir ...
- eine Textdatei makefile mit dem Inhalt:
# Hey Emacs, this is a -*- makefile -*- ############################################################################### # WTR MAKEFILE FOR WinAVR # Based on WinAVR Sample makefile written by Eric B. Weddington, # Jörg Wunsch, et al. # # # YOU NEED TO EDIT SOME SMALL THINGS IN THIS FILE IF YOU WANT TO USE # IT FOR YOUR OWN PROJECTS! # THESE LINES ARE ALL AT THE TOP OF THIS FILE AND MARKED VERY CLEARLY ! # BETTER DO NOT EDIT ANYTHING ELSE! # # To compile everything you can simply type "make all" on a command line in # this directory or simply use the supplied batch files! # To remove all the temporary files the compiler has generated you can use # "make clean" # See end of this file and "make" user manual for more details! # # # Note: Everything behind a '#' is interpreted as a comment in this file! # ############################################################################### ############################################################################### # Target file name (without extension). # This is the name of your main C source file! Do NOT append the ".c"! # Example: Let's assume your main source file is "WT_MyProgram.c", then # you would write: TARGET = WT_MyProgram TARGET = WT_I2C ############################################################################### ############################################################################### # Specify relative path to WTR library files here. # This is "../../WTRLib" or "../WTRLib" usually. WTR_LIB_PATH=../../WTRLib WTR_LIB_PATH_OTHERS= $(WTR_LIB_PATH)/Main $(WTR_LIB_PATH)/Common ############################################################################### #------------------------------------------------ # Main Source file is _automatically_ added here: SRC = $(TARGET).c # DO NOT EDIT THIS! ############################################################################### # If there is more than one source file, append them here separated by spaces. # Usually you have to add the Library files here! (ONLY add c files "*.c" here, # NO header files "*.h"!) # Don't forget to add relative paths! SRC += $(WTR_LIB_PATH)/Main/WildThumperLib_Main.c SRC += $(WTR_LIB_PATH)/Main/WT_UART.c SRC += $(WTR_LIB_PATH)/Common/WT_I2Cmaster.c # You can also wrap lines by appending a backslash to the end of the line # like this: #SRC += xyz.c \ #abc.c \ #asdf.c # ############################################################################### ############################################################################### # Optimization level, can be [0, 1, 2, 3, s]. 0 turns off optimization. # (Note: 3 is not always the best optimization level. See avr-libc FAQ.) OPT = s ############################################################################### # # #-----------------------------------------------------------------------------# ############################################################################### ######-------------------------------------------------------------------###### ###### DO NOT EDIT ANYTHING BELOW IF YOU DO NOT KNOW WHAT YOU ARE DOING! ###### ######-------------------------------------------------------------------###### ############################################################################### #-----------------------------------------------------------------------------# # # # MCU name - atmega644p for WTR Main processor MCU = atmega644p # Output format. (can be srec, ihex, binary) FORMAT = ihex # List Assembler source files here. # Make them always end in a capital .S. Files ending in a lowercase .s # will not be considered source files but generated files (assembler # output from the compiler), and will be deleted upon "make clean"! # Even though the DOS/Win* filesystem matches both .s and .S the same, # it will preserve the spelling of the filenames, and gcc itself does # care about how the name is spelled on its command-line. ASRC = # Debugging format. # Native formats for AVR-GCC's -g are dwarf-2 [default] or stabs. # AVR Studio 4.10 requires dwarf-2. # AVR [Extended] COFF format requires stabs, plus an avr-objcopy run. DEBUG = dwarf-2 # List any extra directories to look for include files here. # Each directory must be seperated by a space. # Use forward slashes for directory separators. # For a directory that has spaces, enclose it in quotes. EXTRAINCDIRS = $(WTR_LIB_PATH) $(WTR_LIB_PATH_OTHERS) # Compiler flag to set the C Standard level. # c89 = "ANSI" C # gnu89 = c89 plus GCC extensions # c99 = ISO C99 standard (not yet fully implemented) # gnu99 = c99 plus GCC extensions CSTANDARD = -std=gnu99 # DO NOT USE THIS FOR WTR PROJECTS! # # Processor frequency. # This will define a symbol, F_CPU, in all source code files equal to the # processor frequency. You can then use this symbol in your source code to # calculate timings. Do NOT tack on a 'UL' at the end, this will be done # automatically to create a 32-bit value in your source code. # F_CPU = 8000000 # Place -D or -U options here CDEFS = # -DF_CPU=$(F_CPU)UL # uncommented - caused a compile problem. # Place -I options here CINCS = #---------------- Compiler Options ---------------- # -g*: generate debugging information # -O*: optimization level # -f...: tuning, see GCC manual and avr-libc documentation # -Wall...: warning level # -Wa,...: tell GCC to pass this to the assembler. # -adhlns...: create assembler listing CFLAGS = -g$(DEBUG) CFLAGS += $(CDEFS) $(CINCS) CFLAGS += -O$(OPT) CFLAGS += -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums CFLAGS += -Wall -Wstrict-prototypes CFLAGS += -Wa,-adhlns=$(<:.c=.lst) CFLAGS += $(patsubst %,-I%,$(EXTRAINCDIRS)) CFLAGS += $(CSTANDARD) #---------------- Assembler Options ---------------- # -Wa,...: tell GCC to pass this to the assembler. # -ahlms: create listing # -gstabs: have the assembler create line number information; note that # for use in COFF files, additional information about filenames # and function names needs to be present in the assembler source # files -- see avr-libc docs [FIXME: not yet described there] # -listing-cont-lines: Sets the maximum number of continuation lines of hex # dump that will be displayed for a given single line of source input. ASFLAGS = -Wa,-adhlns=$(<:.S=.lst),-gstabs,--listing-cont-lines=100 #---------------- Library Options ---------------- # Minimalistic printf version PRINTF_LIB_MIN = -Wl,-u,vfprintf -lprintf_min # Floating point printf version (requires MATH_LIB = -lm below) PRINTF_LIB_FLOAT = -Wl,-u,vfprintf -lprintf_flt # If this is left blank, then it will use the Standard printf version. PRINTF_LIB = #PRINTF_LIB = $(PRINTF_LIB_MIN) #PRINTF_LIB = $(PRINTF_LIB_FLOAT) # Minimalistic scanf version SCANF_LIB_MIN = -Wl,-u,vfscanf -lscanf_min # Floating point + %[ scanf version (requires MATH_LIB = -lm below) SCANF_LIB_FLOAT = -Wl,-u,vfscanf -lscanf_flt # If this is left blank, then it will use the Standard scanf version. SCANF_LIB = #SCANF_LIB = $(SCANF_LIB_MIN) #SCANF_LIB = $(SCANF_LIB_FLOAT) MATH_LIB = -lm #---------------- External Memory Options ---------------- # 64 KB of external RAM, starting after internal RAM (ATmega128!), # used for variables (.data/.bss) and heap (malloc()). #EXTMEMOPTS = -Wl,--section-start,.data=0x801100,--defsym=__heap_end=0x80ffff # 64 KB of external RAM, starting after internal RAM (ATmega128!), # only used for heap (malloc()). #EXTMEMOPTS = -Wl,--defsym=__heap_start=0x801100,--defsym=__heap_end=0x80ffff EXTMEMOPTS = #---------------- Linker Options ---------------- # -Wl,...: tell GCC to pass this to linker. # -Map: create map file # --cref: add cross reference to map file LDFLAGS = -Wl,-Map=$(TARGET).map,--cref LDFLAGS += $(EXTMEMOPTS) LDFLAGS += $(PRINTF_LIB) $(SCANF_LIB) $(MATH_LIB) #---------------- Programming Options (avrdude) ---------------- # Programming hardware: alf avr910 avrisp bascom bsd # dt006 pavr picoweb pony-stk200 sp12 stk200 stk500 # # Type: avrdude -c ? # to get a full listing. # AVRDUDE_PROGRAMMER = stk500 # com1 = serial port. Use lpt1 to connect to parallel port. AVRDUDE_PORT = com1 # programmer connected to serial device AVRDUDE_WRITE_FLASH = -U flash:w:$(TARGET).hex #AVRDUDE_WRITE_EEPROM = -U eeprom:w:$(TARGET).eep # Uncomment the following if you want avrdude's erase cycle counter. # Note that this counter needs to be initialized first using -Yn, # see avrdude manual. #AVRDUDE_ERASE_COUNTER = -y # Uncomment the following if you do /not/ wish a verification to be # performed after programming the device. #AVRDUDE_NO_VERIFY = -V # Increase verbosity level. Please use this when submitting bug # reports about avrdude. See <http://savannah.nongnu.org/projects/avrdude> # to submit bug reports. #AVRDUDE_VERBOSE = -v -v AVRDUDE_FLAGS = -p $(MCU) -P $(AVRDUDE_PORT) -c $(AVRDUDE_PROGRAMMER) AVRDUDE_FLAGS += $(AVRDUDE_NO_VERIFY) AVRDUDE_FLAGS += $(AVRDUDE_VERBOSE) AVRDUDE_FLAGS += $(AVRDUDE_ERASE_COUNTER) #---------------- Debugging Options ---------------- # For simulavr only - target MCU frequency. DEBUG_MFREQ = $(F_CPU) # Set the DEBUG_UI to either gdb or insight. # DEBUG_UI = gdb DEBUG_UI = insight # Set the debugging back-end to either avarice, simulavr. DEBUG_BACKEND = avarice #DEBUG_BACKEND = simulavr # GDB Init Filename. GDBINIT_FILE = __avr_gdbinit # When using avarice settings for the JTAG JTAG_DEV = /dev/com1 # Debugging port used to communicate between GDB / avarice / simulavr. DEBUG_PORT = 4242 # Debugging host used to communicate between GDB / avarice / simulavr, normally # just set to localhost unless doing some sort of crazy debugging when # avarice is running on a different computer. DEBUG_HOST = localhost #============================================================================ # Define programs and commands. SHELL = sh CC = avr-gcc OBJCOPY = avr-objcopy OBJDUMP = avr-objdump SIZE = avr-size NM = avr-nm AVRDUDE = avrdude REMOVE = rm -f REMOVEDIR = rmdir COPY = cp WINSHELL = cmd # Define Messages # English MSG_ERRORS_NONE = Errors: none MSG_BEGIN = -------- begin -------- MSG_END = -------- end -------- MSG_SIZE_BEFORE = Size before: MSG_SIZE_AFTER = Size after: MSG_COFF = Converting to AVR COFF: MSG_EXTENDED_COFF = Converting to AVR Extended COFF: MSG_FLASH = Creating load file for Flash: MSG_EEPROM = Creating load file for EEPROM: MSG_EXTENDED_LISTING = Creating Extended Listing: MSG_SYMBOL_TABLE = Creating Symbol Table: MSG_LINKING = Linking: MSG_COMPILING = Compiling: MSG_ASSEMBLING = Assembling: MSG_CLEANING = Cleaning project: # Define all object files. OBJ = $(SRC:.c=.o) $(ASRC:.S=.o) # Define all listing files. LST = $(SRC:.c=.lst) $(ASRC:.S=.lst) # Compiler flags to generate dependency files. GENDEPFLAGS = -MD -MP -MF .dep/$(@F).d # Combine all necessary flags and optional flags. # Add target processor to flags. ALL_CFLAGS = -mmcu=$(MCU) -I. $(CFLAGS) $(GENDEPFLAGS) ALL_ASFLAGS = -mmcu=$(MCU) -I. -x assembler-with-cpp $(ASFLAGS) # Default target. all: begin gccversion sizebefore build sizeafter end build: elf hex eep lss sym elf: $(TARGET).elf hex: $(TARGET).hex #eep: $(TARGET).eep lss: $(TARGET).lss sym: $(TARGET).sym # Eye candy. # AVR Studio 3.x does not check make's exit code but relies on # the following magic strings to be generated by the compile job. begin: @echo @echo $(MSG_BEGIN) end: @echo $(MSG_END) @echo # Display size of file. HEXSIZE = $(SIZE) --target=$(FORMAT) $(TARGET).hex ELFSIZE = $(SIZE) --format=avr --mcu=$(MCU) $(TARGET).elf sizebefore: @if test -f $(TARGET).elf; then echo; echo $(MSG_SIZE_BEFORE); $(ELFSIZE); \ 2>/dev/null; echo; fi sizeafter: @if test -f $(TARGET).elf; then echo; echo $(MSG_SIZE_AFTER); $(ELFSIZE); \ 2>/dev/null; echo; fi # Display compiler version information. gccversion : @$(CC) --version # Program the device. program: $(TARGET).hex $(TARGET).eep $(AVRDUDE) $(AVRDUDE_FLAGS) $(AVRDUDE_WRITE_FLASH) $(AVRDUDE_WRITE_EEPROM) # Generate avr-gdb config/init file which does the following: # define the reset signal, load the target file, connect to target, and set # a breakpoint at main(). gdb-config: @$(REMOVE) $(GDBINIT_FILE) @echo define reset >> $(GDBINIT_FILE) @echo SIGNAL SIGHUP >> $(GDBINIT_FILE) @echo end >> $(GDBINIT_FILE) @echo file $(TARGET).elf >> $(GDBINIT_FILE) @echo target remote $(DEBUG_HOST):$(DEBUG_PORT) >> $(GDBINIT_FILE) ifeq ($(DEBUG_BACKEND),simulavr) @echo load >> $(GDBINIT_FILE) endif @echo break main >> $(GDBINIT_FILE) debug: gdb-config $(TARGET).elf ifeq ($(DEBUG_BACKEND), avarice) @echo Starting AVaRICE - Press enter when "waiting to connect" message displays. @$(WINSHELL) /c start avarice --jtag $(JTAG_DEV) --erase --program --file \ $(TARGET).elf $(DEBUG_HOST):$(DEBUG_PORT) @$(WINSHELL) /c pause else @$(WINSHELL) /c start simulavr --gdbserver --device $(MCU) --clock-freq \ $(DEBUG_MFREQ) --port $(DEBUG_PORT) endif @$(WINSHELL) /c start avr-$(DEBUG_UI) --command=$(GDBINIT_FILE) # Convert ELF to COFF for use in debugging / simulating in AVR Studio or VMLAB. COFFCONVERT=$(OBJCOPY) --debugging \ --change-section-address .data-0x800000 \ --change-section-address .bss-0x800000 \ --change-section-address .noinit-0x800000 \ --change-section-address .eeprom-0x810000 coff: $(TARGET).elf @echo @echo $(MSG_COFF) $(TARGET).cof $(COFFCONVERT) -O coff-avr $< $(TARGET).cof extcoff: $(TARGET).elf @echo @echo $(MSG_EXTENDED_COFF) $(TARGET).cof $(COFFCONVERT) -O coff-ext-avr $< $(TARGET).cof # Create final output files (.hex, .eep) from ELF output file. %.hex: %.elf @echo @echo $(MSG_FLASH) $@ $(OBJCOPY) -O $(FORMAT) -R .eeprom $< $@ #%.eep: %.elf # @echo # @echo $(MSG_EEPROM) $@ # -$(OBJCOPY) -j .eeprom --set-section-flags .eeprom=alloc,load \ # --change-section-lma .eeprom=0 -O $(FORMAT) $< $@ # Create extended listing file from ELF output file. %.lss: %.elf @echo @echo $(MSG_EXTENDED_LISTING) $@ $(OBJDUMP) -h -S $< > $@ # Create a symbol table from ELF output file. %.sym: %.elf @echo @echo $(MSG_SYMBOL_TABLE) $@ $(NM) -n $< > $@ # Link: create ELF output file from object files. .SECONDARY : $(TARGET).elf .PRECIOUS : $(OBJ) %.elf: $(OBJ) @echo @echo $(MSG_LINKING) $@ $(CC) $(ALL_CFLAGS) $^ --output $@ $(LDFLAGS) # Compile: create object files from C source files. %.o : %.c @echo @echo $(MSG_COMPILING) $< $(CC) -c $(ALL_CFLAGS) $< -o $@ # Compile: create assembler files from C source files. %.s : %.c $(CC) -S $(ALL_CFLAGS) $< -o $@ # Assemble: create object files from assembler source files. %.o : %.S @echo @echo $(MSG_ASSEMBLING) $< $(CC) -c $(ALL_ASFLAGS) $< -o $@ # Create preprocessed source for use in sending a bug report. %.i : %.c $(CC) -E -mmcu=$(MCU) -I. $(CFLAGS) $< -o $@ # Target: clean project. clean: begin clean_list end clean_list : @echo @echo $(MSG_CLEANING) # We want to keep the generated hexfiles: # $(REMOVE) $(TARGET).hex # $(REMOVE) $(TARGET).eep $(REMOVE) $(TARGET).cof $(REMOVE) $(TARGET).elf $(REMOVE) $(TARGET).map $(REMOVE) $(TARGET).sym $(REMOVE) $(TARGET).lss $(REMOVE) $(OBJ) $(REMOVE) $(LST) $(REMOVE) $(SRC:.c=.s) $(REMOVE) $(SRC:.c=.d) $(REMOVE) $(SRC:.c=.i) $(REMOVE) .dep/* $(REMOVEDIR) .dep # Include the dependency files. include $(shell mkdir .dep 2>/dev/null) $(wildcard .dep/*) # Listing of phony targets. .PHONY : all begin finish end sizebefore sizeafter gccversion \ build elf hex eep lss sym coff extcoff \ clean clean_list program debug gdb-config ############################################################################### # Based on WinAVR Sample makefile written by Eric B. Weddington, # Jörg Wunsch, et al. # Released to the Public Domain. # Please read the "make" user manual! # # On command line: # # make all = Make software. # # make clean = Clean out built project files. # # make coff = Convert ELF to AVR COFF. # # make extcoff = Convert ELF to AVR Extended COFF. # # make program = Download the hex file to the device, using avrdude. # Please customize the avrdude settings first! # # make debug = Start either simulavr or avarice as specified for debugging, # with avr-gdb or avr-insight as the front end for debugging. # # make filename.s = Just compile filename.c into the assembler code only. # # make filename.i = Create a preprocessed source file for use in submitting # bug reports to the GCC project. # # To rebuild project do "make clean" then "make all". # ###############################################################################
- In alle Unterordner von \Motor examples kopieren wir ...
- eine Textdatei makefile mit dem Inhalt:
# Hey Emacs, this is a -*- makefile -*- ############################################################################### # WTR MAKEFILE FOR WinAVR # Based on WinAVR Sample makefile written by Eric B. Weddington, # Jörg Wunsch, et al. # # # YOU NEED TO EDIT SOME SMALL THINGS IN THIS FILE IF YOU WANT TO USE # IT FOR YOUR OWN PROJECTS! # THESE LINES ARE ALL AT THE TOP OF THIS FILE AND MARKED VERY CLEARLY ! # BETTER DO NOT EDIT ANYTHING ELSE! # # To compile everything you can simply type "make all" on a command line in # this directory or simply use the supplied batch files! # To remove all the temporary files the compiler has generated you can use # "make clean" # See end of this file and "make" user manual for more details! # # # Note: Everything behind a '#' is interpreted as a comment in this file! # ############################################################################### ############################################################################### # Target file name (without extension). # This is the name of your main C source file! Do NOT append the ".c"! # Example: Let's assume your main source file is "WT_MyProgram.c", then # you would write: TARGET = WT_MyProgram TARGET = WT_LED ############################################################################### ############################################################################### # Specify relative path to WTR library files here. # This is "../../WTRLib" or "../WTRLib" usually. WTR_LIB_PATH=../../WTRLib WTR_LIB_PATH_OTHERS= $(WTR_LIB_PATH)/Motor $(WTR_LIB_PATH)/Common ############################################################################### #------------------------------------------------ # Main Source file is _automatically_ added here: SRC = $(TARGET).c # DO NOT EDIT THIS! ############################################################################### # If there is more than one source file, append them here separated by spaces. # Usually you have to add the Library files here! (ONLY add c files "*.c" here, # NO header files "*.h"!) # Don't forget to add relative paths! SRC += $(WTR_LIB_PATH)/Motor/WildThumperLib_Motor.c SRC += $(WTR_LIB_PATH)/Motor/WT_UART.c SRC += $(WTR_LIB_PATH)/Common/WT_I2Cslave.c # You can also wrap lines by appending a backslash to the end of the line # like this: #SRC += xyz.c \ #abc.c \ #asdf.c # ############################################################################### ############################################################################### # Optimization level, can be [0, 1, 2, 3, s]. 0 turns off optimization. # (Note: 3 is not always the best optimization level. See avr-libc FAQ.) OPT = s ############################################################################### # # #-----------------------------------------------------------------------------# ############################################################################### ######-------------------------------------------------------------------###### ###### DO NOT EDIT ANYTHING BELOW IF YOU DO NOT KNOW WHAT YOU ARE DOING! ###### ######-------------------------------------------------------------------###### ############################################################################### #-----------------------------------------------------------------------------# # # # MCU name - atmega644p for WTR Motor processor MCU = atmega644p # Output format. (can be srec, ihex, binary) FORMAT = ihex # List Assembler source files here. # Make them always end in a capital .S. Files ending in a lowercase .s # will not be considered source files but generated files (assembler # output from the compiler), and will be deleted upon "make clean"! # Even though the DOS/Win* filesystem matches both .s and .S the same, # it will preserve the spelling of the filenames, and gcc itself does # care about how the name is spelled on its command-line. ASRC = # Debugging format. # Native formats for AVR-GCC's -g are dwarf-2 [default] or stabs. # AVR Studio 4.10 requires dwarf-2. # AVR [Extended] COFF format requires stabs, plus an avr-objcopy run. DEBUG = dwarf-2 # List any extra directories to look for include files here. # Each directory must be seperated by a space. # Use forward slashes for directory separators. # For a directory that has spaces, enclose it in quotes. EXTRAINCDIRS = $(WTR_LIB_PATH) $(WTR_LIB_PATH_OTHERS) # Compiler flag to set the C Standard level. # c89 = "ANSI" C # gnu89 = c89 plus GCC extensions # c99 = ISO C99 standard (not yet fully implemented) # gnu99 = c99 plus GCC extensions CSTANDARD = -std=gnu99 # DO NOT USE THIS FOR WTR PROJECTS! # # Processor frequency. # This will define a symbol, F_CPU, in all source code files equal to the # processor frequency. You can then use this symbol in your source code to # calculate timings. Do NOT tack on a 'UL' at the end, this will be done # automatically to create a 32-bit value in your source code. # F_CPU = 8000000 # Place -D or -U options here CDEFS = # -DF_CPU=$(F_CPU)UL # uncommented - caused a compile problem. # Place -I options here CINCS = #---------------- Compiler Options ---------------- # -g*: generate debugging information # -O*: optimization level # -f...: tuning, see GCC manual and avr-libc documentation # -Wall...: warning level # -Wa,...: tell GCC to pass this to the assembler. # -adhlns...: create assembler listing CFLAGS = -g$(DEBUG) CFLAGS += $(CDEFS) $(CINCS) CFLAGS += -O$(OPT) CFLAGS += -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums CFLAGS += -Wall -Wstrict-prototypes CFLAGS += -Wa,-adhlns=$(<:.c=.lst) CFLAGS += $(patsubst %,-I%,$(EXTRAINCDIRS)) CFLAGS += $(CSTANDARD) #---------------- Assembler Options ---------------- # -Wa,...: tell GCC to pass this to the assembler. # -ahlms: create listing # -gstabs: have the assembler create line number information; note that # for use in COFF files, additional information about filenames # and function names needs to be present in the assembler source # files -- see avr-libc docs [FIXME: not yet described there] # -listing-cont-lines: Sets the maximum number of continuation lines of hex # dump that will be displayed for a given single line of source input. ASFLAGS = -Wa,-adhlns=$(<:.S=.lst),-gstabs,--listing-cont-lines=100 #---------------- Library Options ---------------- # Minimalistic printf version PRINTF_LIB_MIN = -Wl,-u,vfprintf -lprintf_min # Floating point printf version (requires MATH_LIB = -lm below) PRINTF_LIB_FLOAT = -Wl,-u,vfprintf -lprintf_flt # If this is left blank, then it will use the Standard printf version. PRINTF_LIB = #PRINTF_LIB = $(PRINTF_LIB_MIN) #PRINTF_LIB = $(PRINTF_LIB_FLOAT) # Minimalistic scanf version SCANF_LIB_MIN = -Wl,-u,vfscanf -lscanf_min # Floating point + %[ scanf version (requires MATH_LIB = -lm below) SCANF_LIB_FLOAT = -Wl,-u,vfscanf -lscanf_flt # If this is left blank, then it will use the Standard scanf version. SCANF_LIB = #SCANF_LIB = $(SCANF_LIB_MIN) #SCANF_LIB = $(SCANF_LIB_FLOAT) MATH_LIB = -lm #---------------- External Memory Options ---------------- # 64 KB of external RAM, starting after internal RAM (ATmega128!), # used for variables (.data/.bss) and heap (malloc()). #EXTMEMOPTS = -Wl,--section-start,.data=0x801100,--defsym=__heap_end=0x80ffff # 64 KB of external RAM, starting after internal RAM (ATmega128!), # only used for heap (malloc()). #EXTMEMOPTS = -Wl,--defsym=__heap_start=0x801100,--defsym=__heap_end=0x80ffff EXTMEMOPTS = #---------------- Linker Options ---------------- # -Wl,...: tell GCC to pass this to linker. # -Map: create map file # --cref: add cross reference to map file LDFLAGS = -Wl,-Map=$(TARGET).map,--cref LDFLAGS += $(EXTMEMOPTS) LDFLAGS += $(PRINTF_LIB) $(SCANF_LIB) $(MATH_LIB) #---------------- Programming Options (avrdude) ---------------- # Programming hardware: alf avr910 avrisp bascom bsd # dt006 pavr picoweb pony-stk200 sp12 stk200 stk500 # # Type: avrdude -c ? # to get a full listing. # AVRDUDE_PROGRAMMER = stk500 # com1 = serial port. Use lpt1 to connect to parallel port. AVRDUDE_PORT = com1 # programmer connected to serial device AVRDUDE_WRITE_FLASH = -U flash:w:$(TARGET).hex #AVRDUDE_WRITE_EEPROM = -U eeprom:w:$(TARGET).eep # Uncomment the following if you want avrdude's erase cycle counter. # Note that this counter needs to be initialized first using -Yn, # see avrdude manual. #AVRDUDE_ERASE_COUNTER = -y # Uncomment the following if you do /not/ wish a verification to be # performed after programming the device. #AVRDUDE_NO_VERIFY = -V # Increase verbosity level. Please use this when submitting bug # reports about avrdude. See <http://savannah.nongnu.org/projects/avrdude> # to submit bug reports. #AVRDUDE_VERBOSE = -v -v AVRDUDE_FLAGS = -p $(MCU) -P $(AVRDUDE_PORT) -c $(AVRDUDE_PROGRAMMER) AVRDUDE_FLAGS += $(AVRDUDE_NO_VERIFY) AVRDUDE_FLAGS += $(AVRDUDE_VERBOSE) AVRDUDE_FLAGS += $(AVRDUDE_ERASE_COUNTER) #---------------- Debugging Options ---------------- # For simulavr only - target MCU frequency. DEBUG_MFREQ = $(F_CPU) # Set the DEBUG_UI to either gdb or insight. # DEBUG_UI = gdb DEBUG_UI = insight # Set the debugging back-end to either avarice, simulavr. DEBUG_BACKEND = avarice #DEBUG_BACKEND = simulavr # GDB Init Filename. GDBINIT_FILE = __avr_gdbinit # When using avarice settings for the JTAG JTAG_DEV = /dev/com1 # Debugging port used to communicate between GDB / avarice / simulavr. DEBUG_PORT = 4242 # Debugging host used to communicate between GDB / avarice / simulavr, normally # just set to localhost unless doing some sort of crazy debugging when # avarice is running on a different computer. DEBUG_HOST = localhost #============================================================================ # Define programs and commands. SHELL = sh CC = avr-gcc OBJCOPY = avr-objcopy OBJDUMP = avr-objdump SIZE = avr-size NM = avr-nm AVRDUDE = avrdude REMOVE = rm -f REMOVEDIR = rmdir COPY = cp WINSHELL = cmd # Define Messages # English MSG_ERRORS_NONE = Errors: none MSG_BEGIN = -------- begin -------- MSG_END = -------- end -------- MSG_SIZE_BEFORE = Size before: MSG_SIZE_AFTER = Size after: MSG_COFF = Converting to AVR COFF: MSG_EXTENDED_COFF = Converting to AVR Extended COFF: MSG_FLASH = Creating load file for Flash: MSG_EEPROM = Creating load file for EEPROM: MSG_EXTENDED_LISTING = Creating Extended Listing: MSG_SYMBOL_TABLE = Creating Symbol Table: MSG_LINKING = Linking: MSG_COMPILING = Compiling: MSG_ASSEMBLING = Assembling: MSG_CLEANING = Cleaning project: # Define all object files. OBJ = $(SRC:.c=.o) $(ASRC:.S=.o) # Define all listing files. LST = $(SRC:.c=.lst) $(ASRC:.S=.lst) # Compiler flags to generate dependency files. GENDEPFLAGS = -MD -MP -MF .dep/$(@F).d # Combine all necessary flags and optional flags. # Add target processor to flags. ALL_CFLAGS = -mmcu=$(MCU) -I. $(CFLAGS) $(GENDEPFLAGS) ALL_ASFLAGS = -mmcu=$(MCU) -I. -x assembler-with-cpp $(ASFLAGS) # Default target. all: begin gccversion sizebefore build sizeafter end build: elf hex eep lss sym elf: $(TARGET).elf hex: $(TARGET).hex #eep: $(TARGET).eep lss: $(TARGET).lss sym: $(TARGET).sym # Eye candy. # AVR Studio 3.x does not check make's exit code but relies on # the following magic strings to be generated by the compile job. begin: @echo @echo $(MSG_BEGIN) end: @echo $(MSG_END) @echo # Display size of file. HEXSIZE = $(SIZE) --target=$(FORMAT) $(TARGET).hex ELFSIZE = $(SIZE) --format=avr --mcu=$(MCU) $(TARGET).elf sizebefore: @if test -f $(TARGET).elf; then echo; echo $(MSG_SIZE_BEFORE); $(ELFSIZE); \ 2>/dev/null; echo; fi sizeafter: @if test -f $(TARGET).elf; then echo; echo $(MSG_SIZE_AFTER); $(ELFSIZE); \ 2>/dev/null; echo; fi # Display compiler version information. gccversion : @$(CC) --version # Program the device. program: $(TARGET).hex $(TARGET).eep $(AVRDUDE) $(AVRDUDE_FLAGS) $(AVRDUDE_WRITE_FLASH) $(AVRDUDE_WRITE_EEPROM) # Generate avr-gdb config/init file which does the following: # define the reset signal, load the target file, connect to target, and set # a breakpoint at main(). gdb-config: @$(REMOVE) $(GDBINIT_FILE) @echo define reset >> $(GDBINIT_FILE) @echo SIGNAL SIGHUP >> $(GDBINIT_FILE) @echo end >> $(GDBINIT_FILE) @echo file $(TARGET).elf >> $(GDBINIT_FILE) @echo target remote $(DEBUG_HOST):$(DEBUG_PORT) >> $(GDBINIT_FILE) ifeq ($(DEBUG_BACKEND),simulavr) @echo load >> $(GDBINIT_FILE) endif @echo break main >> $(GDBINIT_FILE) debug: gdb-config $(TARGET).elf ifeq ($(DEBUG_BACKEND), avarice) @echo Starting AVaRICE - Press enter when "waiting to connect" message displays. @$(WINSHELL) /c start avarice --jtag $(JTAG_DEV) --erase --program --file \ $(TARGET).elf $(DEBUG_HOST):$(DEBUG_PORT) @$(WINSHELL) /c pause else @$(WINSHELL) /c start simulavr --gdbserver --device $(MCU) --clock-freq \ $(DEBUG_MFREQ) --port $(DEBUG_PORT) endif @$(WINSHELL) /c start avr-$(DEBUG_UI) --command=$(GDBINIT_FILE) # Convert ELF to COFF for use in debugging / simulating in AVR Studio or VMLAB. COFFCONVERT=$(OBJCOPY) --debugging \ --change-section-address .data-0x800000 \ --change-section-address .bss-0x800000 \ --change-section-address .noinit-0x800000 \ --change-section-address .eeprom-0x810000 coff: $(TARGET).elf @echo @echo $(MSG_COFF) $(TARGET).cof $(COFFCONVERT) -O coff-avr $< $(TARGET).cof extcoff: $(TARGET).elf @echo @echo $(MSG_EXTENDED_COFF) $(TARGET).cof $(COFFCONVERT) -O coff-ext-avr $< $(TARGET).cof # Create final output files (.hex, .eep) from ELF output file. %.hex: %.elf @echo @echo $(MSG_FLASH) $@ $(OBJCOPY) -O $(FORMAT) -R .eeprom $< $@ #%.eep: %.elf # @echo # @echo $(MSG_EEPROM) $@ # -$(OBJCOPY) -j .eeprom --set-section-flags .eeprom=alloc,load \ # --change-section-lma .eeprom=0 -O $(FORMAT) $< $@ # Create extended listing file from ELF output file. %.lss: %.elf @echo @echo $(MSG_EXTENDED_LISTING) $@ $(OBJDUMP) -h -S $< > $@ # Create a symbol table from ELF output file. %.sym: %.elf @echo @echo $(MSG_SYMBOL_TABLE) $@ $(NM) -n $< > $@ # Link: create ELF output file from object files. .SECONDARY : $(TARGET).elf .PRECIOUS : $(OBJ) %.elf: $(OBJ) @echo @echo $(MSG_LINKING) $@ $(CC) $(ALL_CFLAGS) $^ --output $@ $(LDFLAGS) # Compile: create object files from C source files. %.o : %.c @echo @echo $(MSG_COMPILING) $< $(CC) -c $(ALL_CFLAGS) $< -o $@ # Compile: create assembler files from C source files. %.s : %.c $(CC) -S $(ALL_CFLAGS) $< -o $@ # Assemble: create object files from assembler source files. %.o : %.S @echo @echo $(MSG_ASSEMBLING) $< $(CC) -c $(ALL_ASFLAGS) $< -o $@ # Create preprocessed source for use in sending a bug report. %.i : %.c $(CC) -E -mmcu=$(MCU) -I. $(CFLAGS) $< -o $@ # Target: clean project. clean: begin clean_list end clean_list : @echo @echo $(MSG_CLEANING) # We want to keep the generated hexfiles: # $(REMOVE) $(TARGET).hex # $(REMOVE) $(TARGET).eep $(REMOVE) $(TARGET).cof $(REMOVE) $(TARGET).elf $(REMOVE) $(TARGET).map $(REMOVE) $(TARGET).sym $(REMOVE) $(TARGET).lss $(REMOVE) $(OBJ) $(REMOVE) $(LST) $(REMOVE) $(SRC:.c=.s) $(REMOVE) $(SRC:.c=.d) $(REMOVE) $(SRC:.c=.i) $(REMOVE) .dep/* $(REMOVEDIR) .dep # Include the dependency files. include $(shell mkdir .dep 2>/dev/null) $(wildcard .dep/*) # Listing of phony targets. .PHONY : all begin finish end sizebefore sizeafter gccversion \ build elf hex eep lss sym coff extcoff \ clean clean_list program debug gdb-config ############################################################################### # Based on WinAVR Sample makefile written by Eric B. Weddington, # Jörg Wunsch, et al. # Released to the Public Domain. # Please read the "make" user manual! # # On command line: # # make all = Make software. # # make clean = Clean out built project files. # # make coff = Convert ELF to AVR COFF. # # make extcoff = Convert ELF to AVR Extended COFF. # # make program = Download the hex file to the device, using avrdude. # Please customize the avrdude settings first! # # make debug = Start either simulavr or avarice as specified for debugging, # with avr-gdb or avr-insight as the front end for debugging. # # make filename.s = Just compile filename.c into the assembler code only. # # make filename.i = Create a preprocessed source file for use in submitting # bug reports to the GCC project. # # To rebuild project do "make clean" then "make all". # ###############################################################################
- In jedem makefile müssen wir die Zeile:
- "Target = ..." an das jeweilige Demo Programm anpassen (Beispiel: Die Demo heißt "WT_Led.c", dann lautet die Zeile im makefile: "Target = WT_Led" [ohne .c!])
- und makefile wieder speichern.
Anlegen von Projekten im PN2
Jetzt sollten wir noch die erstellten Demo-Programme als Projekte im Programmer's Notepad (PN2) anlegen. Das müssen wir für jede Demo (d.h. für jeden Unterordner von \Main examples und \Motor examples) durchführen. So geht's:
- Im PN2 klicken wir auf File -> New -> Project.
- Im Fenster New Project ... geben wir einen Namen für das Projekt ein, z.B. "WT_LED" für die LED-Demo.
- Im Fenster New Project ... suchen wir unter Folder das Verzeichnis der Demo, z.B. \Dieser PC\Partition:\UserName\WTR\WTExamples\Main examples\WT_LED für die LED-Demo des Main Controllers und bestätigen mit OK.
- Im linken Fenster "Projects" des PN2 müßte jetzt zu sehen sein:
New Project Group |_ WT_LED
- Mit der rechten Maustaste klicken wir jetzt auf WT_LED und wählen aus dem Kontextmenü "Add Files".
- Im Fenster "Add Files" suchen wir wieder das Verzeichnis unserer Demo (z.B. \WTR\WTExamples\Main examples\WT_LED), markieren die Demo (z.B. WT_Led.c) und klicken auf "Öffnen".
- Im linken Fenster "Projects" des PN2 sieht es jetzt so aus:
New Project Group |_ WT_LED |___WT_Led.c
- Ein Doppelklick auf WT_Led.c öffnet jetzt die Demo. Man kann sie dann ansehen und verändern.
- Durch Klicken auf Tools -> [WinAVR] Make All kann eine fertige Demo kompiliert werden. Das Ergebnis ist eine sog. HEX-Datei (z.B. WT_Led.hex), die dann mit dem RobotLoader in den Main (oder Motor) Controller des WTR-CK1 geladen und dort ausgeführt werden kann.
- Will man später ein Projekt im PN2 wieder öffnen, klickt man auf File -> Open Projects..., sucht das Verzeichnis des Projekts (d.h. der Demo), markiert darin den Eintrag "ProjektName.pnproj" und klickt auf "Öffnen".
Hochladen und Starten von Programmen mit dem RobotLoader
So, endlich können wir uns nun wieder dem Wild Thumper zuwenden! Dazu schließen wir den USB-Adapter an den PC an und öffnen den RobotLoader. Den WTR schalten wir ein (Grüne LED 1 leuchtet, grüne LEDs 7 und 8 blinken!). Im RobotLoader ist ein Portname (z.B. USB0|RP6 USB Interface|ARV82BPV) im Fenster "Schritt 1: Port wählen" zu sehen. Sollte dies nicht der Fall sein, dann ist die Software Installation noch nicht vollständig erfolgt und muss geprüft und ergänzt werden. Wir verbinden die 10-polige Buchse des Flachkabels des USB-Adapters mit dem UART-Wannenstecker (HDR14) des Main Controllers. JP4 muss geschlossen sein: Ein Jumper ist dort aufgesteckt. Im RobotLoader klicken wir nun auf den Portnamen und auf "Verbinden". Im Status Fenster rechts unten müßte nun zu lesen sein:
Connected to: "Wild Thumper Main" FW Version: 1.4 Battery Voltage: 7.73V
Herzlichen Glückwunsch! Wir sind mit dem Main Controller des WTR verbunden und die Akkuspannung beträgt 7,73V, ist also sehr gut.
HINWEIS: Die Akkuspannung darf NIEMALS unter 6,0V
absinken!!! Die LiPo Akkus werden sonst
unwiederbringlich zerstört!!!
Zum Test wollen wir jetzt ein Night Rider Lauflicht mit den LEDs 8 bis 13 starten. Diese LEDs werden vom Main Controller gesteuert. Ein passendes Demo-Programm haben wir ja bereits: WT_Leds.c im Ordner \WTR\WTExamples\Main examples\WT_LED. Nachdem wir diese Demo kompiliert hatten (s.o.), befindet sich auch die HEX-Datei WT_Leds.hex in diesem Ordner.
Im RobotLoader klicken wir auf das [+] im Fensterbereich "Schritt 2: Hexfile hinzufügen/auswählen" und geben einen Namen für die Kategorie ein. Da wir den Main Controller programmieren wollen, kann man die Kategorie "Main" nennen. Die Kategorie (z.B. "Main" und "Motor") braucht man nur einmalig einzugeben. Durch Klicken auf "Hinzufügen" suchen wir das Verzeichnis der Demo. Im Fenster "Öffnen" klicken wir auf den Dateinamen WT_Leds.hex. Dann klicken wir auf "Upload" und anschließend auf "Start" oder gleich auf "Upload + Start". Die 6 LEDs auf dem WTR-CK1 zeigen jetzt ein Lauflicht,- David Hasselhoff wäre begeistert. Abbrechen kann man die Demo mit "Reset".
Dasselbe Lauflicht (LEDs 4 bis 7) gibt es auch für den Motor Controller im Verzeichnis \WTR\WTExamples\Motor examples\WT_LED (Demo WT_LED.c). Probiert das 'mal aus. Das Vorgehen ist identisch, die 10-polige Buchse des Flachkabels des USB-Adapters muss aber jetzt mit dem UART-Wannenstecker (HDR3) des Motor Controllers verbunden werden. JP3 muss geschlossen sein: Ein Jumper ist dort aufgesteckt.
Nun haben wir es zu 90% geschafft! Der WTR ist aufgebaut, die Software installiert, die Demo Programme sind eingerichtet, können kompiliert und in die beiden Controller des WTR geladen und dort ausgeführt werden. Wenn das nichts ist...!
Anpassen der Libraries
Eigentlich sollte man die Libraries des Main und Motor Controllers auf dem WTR-CK1 unverändert lassen. Eine Änderung muss aber leider erfolgen, wenn bestimmte Funktionen nicht das tun, was sie sollen.
Die beschriebenen Änderungen dienen nur dazu, den WTR mit den mitgelieferten Libraries nutzen zu können. Eine evtl. Weiter- oder Neuentwicklung der Libraries erfolgt im Artikel Wild Thumper - Programmierung.
Main Library
Die Main Library besteht aus den Dateien WT_Config_Main.h, WildThumperLib_Main.h und WildThumperLib_Main.c.
Hier brauchen wir keine Anpassungen vorzunehmen!
Motor Library
Die Motor Library besteht aus den Dateien WT_Config_Motor.h, WildThumperLib_Motor.h und WildThumperLib_Motor.c.
Mit den nachfolgend beschriebenen Änderungen gebe ich der Motor Library die neue Versionsnummer 1.1.
JTAG-Schnittstelle
Eine Anpassung der Motor Library ist zwingend, weil (zumindest bei meinem Exemplar des WTR-CK1) die JTAG-Schnittstelle des Motor Controllers eingeschaltet ist. Das hat den Vorteil, dass man Programme im Motor Controller über diese Schnittstelle "entwanzen" (debuggen) kann.
Der Nachteil ist, dass bei eingeschalteter JTAG-Schnittstelle (Standard bei neuen ATmega Prozessoren) einige Portpins von Port C (PC2..PC5) nicht wie üblich als Ein-/Ausgabe Pins (I/Os) funktionieren. Diese Pins werden aber für bestimmte Funktionen des WTR-CK1 als I/Os benötigt:
- PC2 -> I2C Interrupt
- PC3 -> Encoder-Signal von Motor 4
- PC4 -> Encoder-Signal von Motor 3
- PC5 -> Encoder-Signal von Motor 2
Schaltet man das JTAG-Interface also nicht aus, wird die Geschwindigkeitsregelung der Motoren 2 bis 4 nicht funktionieren. Zudem kann der Motor Controller als I2C Slave nicht signalisieren, dass Daten verfügbar sind und vom I2C Master (Main Controller) gelesen werden können.
Um die JTAG-Schnittstelle einzuschalten, müssen die beiden Fusebits JTAGEN und OCDEN programmiert werden,- zum Ausschalten entsprechend wieder umprogrammiert werden. Dazu braucht man einen sog. ISP-Programmer und Software, die Fusebits lesen und ändern kann (z.B. AVRDUDE). Hat man diese Ausstattung nicht, kann man die JTAG-Schnittstelle auch per Software ausschalten. Nachteil: Man muss das nach jedem Reset wieder machen.
Die Anpassung der Motor Library sieht dann so aus:
- Die Datei WT_Config_Motor.h kopieren, um sie im Original zu behalten.
- Änderung der WT_Config_Motor.h (v. 1.0 vom 30.06.2011):
- Wir öffnen die Datei im PN2 und schalten die Zeilennummern mit View -> Line Numbers ein.
- Im "I/O Port init macro" Abschnitt ändern wir die Zeile 168 wie folgt:
DDRD = INIT_DDRD; \
... und fügen ab Zeile 169 ein:
MCUCR = (1 << JTD); \ MCUCR = (1 << JTD);
Quadratur-Encoder
Wir müssen eine weitere Anpassung der Motor Library vornehmen, weil wir nicht die Radencoder benutzen, die mit dem WTR-CK1 mitgeliefert werden, sondern die Quadratur-Encoder der Motoren des WTR. Ein sehr knappes Deutsch-sprachiges Beiblatt über diese Encoder liegt dem WTR-CK1 bei. Was unterscheidet die Radencoder des WTR-CK1, an die die Motor Library angepasst ist, von den Quadratur-Encodern?
Eigentlich nichts. Beide bestehen aus Hall-Sensoren, die Impulsflanken erzeugen, wenn ein wechselndes Magnetfeld anliegt. Beide erzeugen 8 Impulsflanken pro Umdrehung des davor angebrachten Magneten,- beim Quadratur-Encoder unter Nutzung nur EINES der beiden Ausgänge.
Es gibt aber einen wesentlichen Unterschied: Die Radencoder des WTR-CK1 wären auf die Getriebeachse zwischen Motor und Rad montiert worden. Siehe die Abbildung rechts von Seite 4 der Anleitung (Wild_Thumper_Steuerplatine.pdf, Version 0610) zum WTR-CK1! Damit könnte man mit diesen Radencodern 8 Impulsflanken pro Radumdrehung messen.
Die Quadratur-Encoder der Motoren des WTR sind jedoch auf der Motorachse angebracht. Siehe Abbildung des Encoder-Motors rechts! Sie erzeugen also 8 Impulsflanken pro Motorumdrehung und nicht pro Radumdrehung. Da die Getriebe der WTR Motoren eine Übersetzung von 34:1 haben, bedeutet dies, dass die Quadratur-Encoder 272 Impulsflanken pro Radumdrehung an EINEM ihrer beiden Ausgänge erzeugen.
Daran muss die Motor Library nun angepasst werden:
- Die Dateien WildThumperLib_Motor.h und WildThumperLib_Motor.c kopieren, um sie im Original zu behalten.
- Änderung der WildThumperLib_Motor.h (v. 1.0 vom 18.07.2011):
- Wir öffnen die Datei im PN2 und schalten die Zeilennummern mit View -> Line Numbers ein.
- Im "Encoder" Abschnitt fügen wir ab Zeile 138 ein:
// --------------------------------------------- // Use motors with built in quadrature encoders: #define Q_ENC // If you make a comment of this definition, the // default wheel encoders of WTR-CK1 are used! // --------------------------------------------- // Motor gear ratio (34 [default] or 75): #define GEAR_RATIO 34 // --------------------------------------------- #ifdef Q_ENC volatile uint8_t SIG1_INT_Counter; volatile uint8_t SIG2_INT_Counter; volatile uint8_t SIG3_INT_Counter; volatile uint8_t SIG4_INT_Counter; volatile uint8_t SIG5_INT_Counter; volatile uint8_t SIG6_INT_Counter; #endif
Wenn "Q_ENC" definiert ist (wie im Code-Abschnitt oben!), unterstützt die Motor Library die Quadratur-Encoder des WTR. Wird "Q_ENC" zum Kommentar gemacht (// #define Q_ENC), wird davon ausgegangen, dass die Radencoder des WTR-CK1 genutzt werden (wie in der Original Motor Library!). Mit "GEAR_RATIO" (Getriebeübersetzung) kann man definieren, ob Motoren mit einer Getriebeübersetzung von 34:1 (Standard beim AREXX Wild Thumper) oder von 75:1 vorhanden sind.
- Änderung der WildThumperLib_Motor.c (v. 1.0 vom 18.07.2011):
- Wir öffnen die Datei im PN2 und schalten die Zeilennummern mit View -> Line Numbers ein.
- Im "Encoder Signals" Abschnitt löschen wir die Zeilen 746 bis 1028 komplett.
- Dafür fügen wir ab Zeile 746 ein:
// Interrupt PCINT16..23; SIG1..SIG4
ISR(PCINT2_vect)
{
if (SIG1 && SIG1_LastState==false) // Rising edge
{
// __ __ __ //
// __| |__| |__| |__ //
// ^ ^ ^ //
// Set the last state on TRUE, because its now rising edge
SIG1_LastState = true;
#ifdef Q_ENC
SIG1_INT_Counter++;
if (SIG1_INT_Counter >= GEAR_RATIO) {
SIG1_INT_Counter = 0;
#endif
// SIG1_Value is the value now and te last sigvalue divided by 2
SIG1_Value = (SIG1_Counter+SIG1_Value)/2;
// Recalculate this value to PID value
SIG1_PID = TIME_TO_PID/SIG1_Value;
if (SIG1_PID >255)
{
SIG1_PID = 255;
}
// Set the counter for SIG on 0
SIG1_Counter = 0;
// Set no puls on 0 (missing pulses)
SIG1_NoPuls = 0;
#ifdef Q_ENC
}
#endif
}
else if (!SIG1 && SIG1_LastState==true) // Falling Edge
{
// __ __ __ //
// __| |__| |__| |__ //
// ^ ^ ^ //
// Set the last state on FLASE, because its now falling edge
SIG1_LastState = false;
#ifdef Q_ENC
SIG1_INT_Counter++;
if (SIG1_INT_Counter >= GEAR_RATIO) {
SIG1_INT_Counter = 0;
#endif
// SIG1_Value is the value now and te last sigvalue divided by 2
SIG1_Value = (SIG1_Counter+SIG1_Value)/2;
// Recalculate this value to PID value
SIG1_PID = TIME_TO_PID/SIG1_Value;
if (SIG1_PID >255)
{
SIG1_PID = 255;
}
// Set the counter for SIG on 0
SIG1_Counter = 0;
// Set no puls on 0 (missing pulses)
SIG1_NoPuls = 0;
#ifdef Q_ENC
}
#endif
}
// Signal Encoder 2
// Check the last state
if (SIG2 && SIG2_LastState==false) // Rising edge
{
// __ __ __ //
// __| |__| |__| |__ //
// ^ ^ ^ //
// Set the last state on TRUE, because its now rising edge
SIG2_LastState = true;
#ifdef Q_ENC
SIG2_INT_Counter++;
if (SIG2_INT_Counter >= GEAR_RATIO) {
SIG2_INT_Counter = 0;
#endif
// SIG1_Value is the value now and te last sigvalue divided by 2
SIG2_Value = (SIG2_Counter+SIG2_Value)/2;
// Recalculate this value to PID value
SIG2_PID = TIME_TO_PID/SIG2_Value;
if (SIG2_PID >255)
{
SIG2_PID = 255;
}
// Set the counter for SIG on 0
SIG2_Counter = 0;
// Set no puls on 0 (missing pulses)
SIG2_NoPuls = 0;
#ifdef Q_ENC
}
#endif
}
else if (!SIG2 && SIG2_LastState==true) // Falling Edge
{
// __ __ __ //
// __| |__| |__| |__ //
// ^ ^ ^ //
// Set the last state on FLASE, because its now falling edge
SIG2_LastState = false;
#ifdef Q_ENC
SIG2_INT_Counter++;
if (SIG2_INT_Counter >= GEAR_RATIO) {
SIG2_INT_Counter = 0;
#endif
// SIG1_Value is the value now and te last sigvalue divided by 2
SIG2_Value = (SIG2_Counter+SIG2_Value)/2;
// Recalculate this value to PID value
SIG2_PID = TIME_TO_PID/SIG2_Value;
if (SIG2_PID >255)
{
SIG2_PID = 255;
}
// Set the counter for SIG on 0
SIG2_Counter = 0;
// Set no puls on 0 (missing pulses)
SIG2_NoPuls = 0;
#ifdef Q_ENC
}
#endif
}
// Signal Encoder 3
// Check the last state
if (SIG3 && SIG3_LastState==false) // Rising edge
{
// __ __ __ //
// __| |__| |__| |__ //
// ^ ^ ^ //
// Set the last state on TRUE, because its now rising edge
SIG3_LastState = true;
#ifdef Q_ENC
SIG3_INT_Counter++;
if (SIG3_INT_Counter >= GEAR_RATIO) {
SIG3_INT_Counter = 0;
#endif
// SIG1_Value is the value now and te last sigvalue divided by 2
SIG3_Value = (SIG3_Counter+SIG3_Value)/2;
// Recalculate this value to PID value
SIG3_PID = TIME_TO_PID/SIG3_Value;
if (SIG3_PID >255)
{
SIG3_PID = 255;
}
if (SIG3_PID < 0)
{
SIG3_PID = 0;
}
// Set the counter for SIG on 0
SIG3_Counter = 0;
// Set no puls on 0 (missing pulses)
SIG3_NoPuls = 0;
#ifdef Q_ENC
}
#endif
}
else if (!SIG3 && SIG3_LastState==true) // Falling Edge
{
// __ __ __ //
// __| |__| |__| |__ //
// ^ ^ ^ //
// Set the last state on FLASE, because its now falling edge
SIG3_LastState = false;
#ifdef Q_ENC
SIG3_INT_Counter++;
if (SIG3_INT_Counter >= GEAR_RATIO) {
SIG3_INT_Counter = 0;
#endif
// SIG1_Value is the value now and te last sigvalue divided by 2
SIG3_Value = (SIG3_Counter+SIG3_Value)/2;
// Recalculate this value to PID value
SIG3_PID = TIME_TO_PID/SIG3_Value;
if (SIG3_PID >255)
{
SIG3_PID = 255;
}
if (SIG3_PID < 0)
{
SIG3_PID = 0;
}
// Set the counter for SIG on 0
SIG3_Counter = 0;
// Set no puls on 0 (missing pulses)
SIG3_NoPuls = 0;
#ifdef Q_ENC
}
#endif
}
// Signal Encoder 4
// Check the last state
if (SIG4 && SIG4_LastState==false) // Rising edge
{
// __ __ __ //
// __| |__| |__| |__ //
// ^ ^ ^ //
// Set the last state on TRUE, because its now rising edge
SIG4_LastState = true;
#ifdef Q_ENC
SIG4_INT_Counter++;
if (SIG4_INT_Counter >= GEAR_RATIO) {
SIG4_INT_Counter = 0;
#endif
// SIG1_Value is the value now and te last sigvalue divided by 2
SIG4_Value = (SIG4_Counter+SIG4_Value)/2;
// Recalculate this value to PID value
SIG4_PID = TIME_TO_PID/SIG4_Value;
if (SIG4_PID >255)
{
SIG4_PID = 255;
}
// Set the counter for SIG on 0
SIG4_Counter = 0;
// Set no puls on 0 (missing pulses)
SIG4_NoPuls = 0;
#ifdef Q_ENC
}
#endif
}
else if (!SIG4 && SIG4_LastState==true) // Falling Edge
{
// __ __ __ //
// __| |__| |__| |__ //
// ^ ^ ^ //
// Set the last state on FLASE, because its now falling edge
SIG4_LastState = false;
#ifdef Q_ENC
SIG4_INT_Counter++;
if (SIG4_INT_Counter >= GEAR_RATIO) {
SIG4_INT_Counter = 0;
#endif
// SIG1_Value is the value now and te last sigvalue divided by 2
SIG4_Value = (SIG4_Counter+SIG4_Value)/2;
// Recalculate this value to PID value
SIG4_PID = TIME_TO_PID/SIG4_Value;
if (SIG4_PID >255)
{
SIG4_PID = 255;
}
// Set the counter for SIG on 0
SIG4_Counter = 0;
// Set no puls on 0 (missing pulses)
SIG4_NoPuls = 0;
#ifdef Q_ENC
}
#endif
}
}
// Interrupt PCINT24..31; SIG5..SIG6
ISR(PCINT3_vect)
{
// Signal Encoder 5
// Check the last state
if (SIG5 && SIG5_LastState==false) // Rising edge
{
// __ __ __ //
// __| |__| |__| |__ //
// ^ ^ ^ //
// Set the last state on TRUE, because its now rising edge
SIG5_LastState = true;
#ifdef Q_ENC
SIG5_INT_Counter++;
if (SIG5_INT_Counter >= GEAR_RATIO) {
SIG5_INT_Counter = 0;
#endif
// SIG1_Value is the value now and te last sigvalue divided by 2
SIG5_Value = (SIG5_Counter+SIG5_Value)/2;
// Recalculate this value to PID value
SIG5_PID = TIME_TO_PID/SIG5_Value;
if (SIG5_PID >255)
{
SIG5_PID = 255;
}
// Set the counter for SIG on 0
SIG5_Counter = 0;
// Set no puls on 0 (missing pulses)
SIG5_NoPuls = 0;
#ifdef Q_ENC
}
#endif
}
else if (!SIG5 && SIG5_LastState==true) // Falling Edge
{
// __ __ __ //
// __| |__| |__| |__ //
// ^ ^ ^ //
// Set the last state on FLASE, because its now falling edge
SIG5_LastState = false;
#ifdef Q_ENC
SIG5_INT_Counter++;
if (SIG5_INT_Counter >= GEAR_RATIO) {
SIG5_INT_Counter = 0;
#endif
// SIG1_Value is the value now and te last sigvalue divided by 2
SIG5_Value = (SIG5_Counter+SIG5_Value)/2;
// Recalculate this value to PID value
SIG5_PID = TIME_TO_PID/SIG5_Value;
if (SIG5_PID >255)
{
SIG5_PID = 255;
}
// Set the counter for SIG on 0
SIG5_Counter = 0;
// Set no puls on 0 (missing pulses)
SIG5_NoPuls = 0;
#ifdef Q_ENC
}
#endif
}
// Signal Encoder 6
// Check the last state
if (SIG6 && SIG6_LastState==false) // Rising edge
{
// __ __ __ //
// __| |__| |__| |__ //
// ^ ^ ^ //
// Set the last state on TRUE, because its now rising edge
SIG6_LastState = true;
#ifdef Q_ENC
SIG6_INT_Counter++;
if (SIG6_INT_Counter >= GEAR_RATIO) {
SIG6_INT_Counter = 0;
#endif
// SIG1_Value is the value now and te last sigvalue divided by 2
SIG6_Value = (SIG6_Counter+SIG6_Value)/2;
// Recalculate this value to PID value
SIG6_PID = TIME_TO_PID/SIG6_Value;
if (SIG6_PID >255)
{
SIG6_PID = 255;
}
// Set the counter for SIG on 0
SIG6_Counter = 0;
// Set no puls on 0 (missing pulses)
SIG6_NoPuls = 0;
#ifdef Q_ENC
}
#endif
}
else if (!SIG6 && SIG6_LastState==true) // Falling Edge
{
// __ __ __ //
// __| |__| |__| |__ //
// ^ ^ ^ //
// Set the last state on FLASE, because its now falling edge
SIG6_LastState = false;
#ifdef Q_ENC
SIG6_INT_Counter++;
if (SIG6_INT_Counter >= GEAR_RATIO) {
SIG6_INT_Counter = 0;
#endif
// SIG1_Value is the value now and te last sigvalue divided by 2
SIG6_Value = (SIG6_Counter+SIG6_Value)/2;
// Recalculate this value to PID value
SIG6_PID = TIME_TO_PID/SIG6_Value;
if (SIG6_PID >255)
{
SIG6_PID = 255;
}
// Set the counter for SIG on 0
SIG6_Counter = 0;
// Set no puls on 0 (missing pulses)
SIG6_NoPuls = 0;
#ifdef Q_ENC
}
#endif
}
}
Anpassen der Demo Programme
Teilweise funktionieren die Demo Programme nicht auf Anhieb. Sie müssen daher angepasst werden.
Die beschriebenen Anpassungen dienen nur dazu, den WTR mit den mitgelieferten Demo Programmen nutzen zu können. Eine evtl. Weiter- oder Neuentwicklung der Demo Programme erfolgt im Artikel Wild Thumper - Programmierung.
Auf ein Problem sowohl bei Programmen für den Main Controller als auch für den Motor Controller kann hinweisen, wenn bei Textausgaben über UART0 im Serial Terminal Fenster des RobotLoaders nur "merkwürdige Zeichen" zu sehen sind. Dies liegt dann daran, dass der RobotLoader eine höhere Baudrate über die serielle Schnittstelle erwartet, als der Controller des WTR-CK1 sendet. Mein RobotLoader Version 2.5a, den ich auch mit dem RP6 nutze, ist auf 38400 Baud eingestellt, der Controller des WTR-CK1 sendet jedoch mit 9600 Baud. Wenn dieses Problem auftritt, muss man die Zeile:
USART0_Init(9600); // Init USART0
... ersetzen durch:
USART0_Init(38400); // Init USART0
Damit müßte die Textausgabe auf dem RobotLoader Terminal wieder funktionieren.
Alternativ kann man die Baudrate für den RobotLoader ändern:
- Im Ordner ...\RobotLoader\config öffnet man die Datei rp6loader.cfg mit dem Editor.
- Man ändert die Zeile:
BootLoader.baudLow=38400
... in:
BootLoader.baudLow=9600
Das war's.
Main examples
WT_I2C
Das Beispiel WT_I2C.c für den Main Controller (v. 1.0 vom 14.07.2011) erzeugt ein Lauflicht mit den LEDs, die an den Motor Controller angeschlossen sind. Im Motor Controller muss das Programm Wild_Thumper_Motor.c laufen. In WT_I2C.c ist die I2C Master Library (WT_I2Cmaster) nicht eingebunden. Das muss man im Bereich "Include library" nachholen:
#include "WT_I2Cmaster.h"
Zusätzlich müssen einige Definitionen (z.T. aus Wild_Thumper_Motor.c) eingefügt werden:
////////////////////////////////////////////////////////////////////////////////////// // // // Defines // // // ////////////////////////////////////////////////////////////////////////////////////// #define I2C_WT_ADR 10 // The default address of the Master Controller #define INT0_STATUS_CHECK 0 #define WRITE_COMMAND 0 // //I2C Registers Read #define I2C_REG_STATUS 1 //Status of the motor controller #define I2C_REG_SPEED_MOTOR_1 2 //Actual speed of motor 1 #define I2C_REG_SPEED_MOTOR_2 3 //Actual speed of motor 2 #define I2C_REG_SPEED_MOTOR_3 4 //Actual speed of motor 3 #define I2C_REG_SPEED_MOTOR_4 5 //Actual speed of motor 4 #define I2C_REG_SPEED_MOTOR_5 6 //Actual speed of motor 5 #define I2C_REG_SPEED_MOTOR_6 7 //Actual speed of motor 6 #define I2C_REG_SPEED_ALL 8 //Actual speed of all motors #define I2C_REG_CURR_MOTOR_1 10 //Actual current of motor 1 #define I2C_REG_CURR_MOTOR_2 11 //Actual current of motor 2 #define I2C_REG_CURR_MOTOR_3 12 //Actual current of motor 3 #define I2C_REG_CURR_MOTOR_4 13 //Actual current of motor 4 #define I2C_REG_CURR_MOTOR_5 14 //Actual current of motor 5 #define I2C_REG_CURR_MOTOR_6 15 //Actual current of motor 6 #define I2C_REG_ENCODER_ERRORS 16 //Status from the encoders #define I2C_REG_MOTOR_ERRORS 17 //All error flags from the motors #define I2C_REG_CURRENT_ERRORS 18 //All error flags from the motors #define I2C_REG_LEDS 22 //Actual status of the four leds #define I2C_TEST_I2C 23 //This register is used for test the I2C communication //I2C Registers Write (commands) #define CMD_STOP_ALL 1 //Command Wild Thumper: STOP WILD THUMPER #define CMD_MOTORS_FORWARD_LEFT 2 //Command Wild Thumper: MOVE FORWARD / LEFT #define CMD_MOTORS_FORWARD_RIGHT 3 //Command Wild Thumper: MOVE FORWARD / RIGHT #define CMD_MOTORS_BACKWARD_LEFT 4 //Command Wild Thumper: MOVE BACKWARD / LEFT #define CMD_MOTORS_BACKWARD_RIGHT 5 //Command Wild Thumper: MOVE BACKWARD / RIGHT #define CMD_CHANGE_MOTOR_1 10 //Command Wild Thumper: CHANGE SPEED AND DIRECTION MOTOR 1 #define CMD_CHANGE_MOTOR_2 11 //Command Wild Thumper: CHANGE SPEED AND DIRECTION MOTOR 2 #define CMD_CHANGE_MOTOR_3 12 //Command Wild Thumper: CHANGE SPEED AND DIRECTION MOTOR 3 #define CMD_CHANGE_MOTOR_4 13 //Command Wild Thumper: CHANGE SPEED AND DIRECTION MOTOR 4 #define CMD_CHANGE_MOTOR_5 14 //Command Wild Thumper: CHANGE SPEED AND DIRECTION MOTOR 5 #define CMD_CHANGE_MOTOR_6 15 //Command Wild Thumper: CHANGE SPEED AND DIRECTION MOTOR 6 #define CMD_SET_LEDS 28 //Command Wild Thumper: CHANGE LEDS #define CMD_TEST_I2C 30 //This register is used for test the I2C communication #define CMD_PID_P 33 #define CMD_PID_I 34 #define CMD_PID_D 35
Motor examples
WT_UART0
Das Beispiel WT_UART0 für den Motor Controller (v. 1.0 vom 14.07.2011) gibt Zahlen und Text über UART0 aus. Leider gibt es folgende Funktionen, die die Demo verwendet, nicht in der WT_UART Library des Motor Controllers:
- USART0_WriteInt()
- USART0_WriteIntLength()
- writeStringLength()
Ihre Nutzung führt dann zu Fehlern beim Kompilieren. Man kann mit der WT_UART Library des Motor Controllers nur nutzen:
- USART0_WriteString()
- USART0_WriteINT()
Das Beispiel muss man also so umschreiben, dass man nur die beiden genannten Funktionen benutzt.
Installation der Windows Application
Auf der Wild Thumper CD-ROM AREXX WTR-CK1 befindet sich die Windows Application im Verzeichnis \Software\WT_install.
Die Datei heisst "setup.exe". Sie ist unter Windows XP mit Service Pack 2 nutzbar, mit nachfolgenden Windows Versionen ggf. nur im Kompatibilitätsmodus.
Unter Windows 10 Home (64-bit) sieht die Installation (laut Patrick WTR) z.B. so aus:
- Das Verzeichnis \Software\WT_install von der CD-ROM auf die Festplatte des PCs kopieren.
- Microsoft Visual Basic Power Packs 10.0 hier herunterladen und installieren.
- Virenscanner/Firewall (z.B. Avast) vorübergehend deaktivieren.
- Mit Rechtsklick auf setup.exe das Kontextmenü der Datei öffnen:
- "Eigenschaften" anklicken.
- Den Reiter "Kompatibilität" wählen.
- Unter "Kompatibilitätsmodus" im dortigen Kästchen einen Haken setzen und "Windows XP (Service Pack 2)" auswählen.
- Auf "Übernehmen" und "Ok" klicken.
- Eine Verknüpfung zu setup.exe erstellen und z.B. auf dem Desktop ablegen.
- Die Application als Administrator im Kompatibilitätsmodus ausführen.
HINWEIS: In Windows 10 gehört der dotNetFix 4.0 Client zum Betriebssystem. Wenn dies nicht der Fall sein sollte, muss der Client noch aus dem Verzeichnis \Software\WT_install\dotnetfx40client installiert werden.
Mit der Windows Application Wild Thumper kann der WTR nun ferngesteuert werden.
Voraussetzungen:
- Die APC-220 Dongles sind auf dem WTR und auf dem USB Programmier-Adapter montiert.
- Der USB Programmier-Adapter ist (via USB) mit dem Windows PC verbunden.
- Im Main Mikrocontroller läuft das Programm Wild_Thumper_Main.hex.
- Im Motor Mikrocontroller läuft das Programm Wild_Thumper_Motor.hex.
Verbinden:
- Main und Motor Programm mithilfe des RobotLoaders starten, danach das Flachkabel vom UART Stecker (HDR14) abziehen und den USB-Port schließen.
- Auf der Main Seite der Application den COM-Port wählen und auf "Connect" klicken.
- Im Feld "Status" unter "Wireless dongle" erscheint "Found", wenn die Verbindung zum APC-220 Dongle auf dem USB Programmier-Adapter hergestellt werden konnte.
- Wenn im Feld "Status" unter "Connection Wild Thumper" und "Status Wild Thumper" anstelle des Textes "No Signal" der Hinweis "OK" erscheint und unter "Battery Voltage" die Akkuspannung angezeigt wird, steht die Verbindung zum WTR.
Nun kann der WTR vom PC aus getestet und ferngesteuert werden.
Probleme
- Die Windows Application Wild Thumper kann nicht gestartet werden:
- Ein Virenscanner und/oder eine Firewall verhindert die Ausführung -> Die Application in die Ausnahmeliste des Virenscanners / der Firewall aufnehmen.
- Die Application wurde nicht als Administrator gestartet -> Anwendung als Administrator starten.
- Im Feld "Error" der Application erscheinen Hinweise, dass die Encoder der Motoren 2, 3 und 4 nicht funktionieren:
- Dies liegt an der aktiven JTAG-Schnittstelle -> Das Programm Wild_Thumper_Motor.c mit der geänderten Motor Library V1.1 neu kompilieren.
- Im Feld "Current" der Application steigt der angezeigte Motorstrom für "Front (4)" nicht an, auch wenn der vordere rechte Motor 4 mit voller Beschleunigung läuft:
- Dies liegt an einem falsch bestückten Widerstand auf der WTR-CK1 Platine. Der Widerstand R17 (6k2) wurde (auf meiner Platine!) mit 47k bestückt -> Dieser Fehler kann leider nur korrigiert werden, indem der falsche Widerstand ausgelötet und durch einen Widerstand 6k2 (SMD 0805) ersetzt wird.
- Im Feld "Communication test" zeigt der "Test RF" meistens an, dass der Test fehlerhaft verlaufen ist, obwohl die Funkverbindung mit den APC-220 Dongles anscheinend gut funktioniert:
- Dies liegt an einer zu kurzen Pause in der Funktion "RF-Test()" des Programms Wild_Thumper_Main.c -> Den Befehl "mSleep(110);" dort ändern in "mSleep(120);" und das Programm neu kompilieren.
Stromversorgung und Akku-Ladung
Die Schaltung der Stromversorgung und Ladeschaltung zeigt die Datei "Wild Thumper supply.pdf" (siehe Anleitung, Version 0610, Seite 63!). An der DC-Buchse J1 kann eine Gleichspannung 8-12V (2A) angelegt werden, mit der der/die Akku(s) im WTR geladen werden kann/können. Es eignet sich z.B. dieses Stecker-Netzteil.
Stromversorgung
Will man den WTR "stehend" an einer festen Stromversorgung betreiben (z.B. während des Entwickelns von Programmen), kann dies durch ein an J1 angeschlossenes Stecker-Netzteil erfolgen (s.o.). Dazu muss aber mindestens EIN geeigneter Akku an J2/J3 angeschlossen sein, der gleichzeitig geladen wird.
Eine zweite Möglichkeit ist, eine externe Gleichspannung von 7,2..7,4V an die 4-poligen Akku-Stiftleisten (J2 oder J3) anzuschließen. Dann dürfen aber keine Akkus mit J2 und J3 verbunden sein.
Akku-Ladung
Für LiPo-Akkus, wie ich sie in meinem WTR verwende, ist das dauerhafte Laden über die Ladeschaltung des WTR-CK1 ungünstig, da man die Ladeendspannung überwachen muss. Zudem ist die Ladeschaltung nicht in der Lage, die beiden LiPo-Zellen im Akku gleichmäßig (balanced) zu laden. Dies ist aber für ein "langes Akkuleben" und optimale Akkuleistung wichtig. Deshalb ist es zu empfehlen, die LiPo-Akkus in regelmäßigen Abständen mit einem LiPo-LiFe-Balancer Ladegerät einzeln zu laden.
Wie kann man nun die LiPo-Akkus einzeln laden, ohne sie auszubauen? Wenn ihr euch für das o.g. Balancer Ladegerät entscheidet, dann wird es u.a. mit einem Kabel mit offenen Enden geliefert. Aus diesem Kabel habe ich mir ein eigenes Akku-Ladekabel gebaut:
- Wir bestellen ein "Grundgehäuse DECA ME030-50804", das ist eine ähnliche 4-polige Stiftleiste, wie sie sich als J2 und J3 auch auf der WTR-CK1 Platine befindet. Dieses Grundgehäuse ist das Gegenstück zur Akku-Schraubklemm-Buchse.
- Das Kabel des Balancer Ladegeräts löten wir an 2 Stifte dieses Grundgehäuses so an, dass bei Einstecken einer der Akku-Schraubklemm-Buchsen die Plus- (rot) und Minuspole (schwarz) von Akku und Ladegerät passend miteinander verbunden sind.
Damit können wir jeden Akku einzeln laden, indem wir die jeweilige Akku-Schraubklemm-Buchse vom WTR-CK1 (J2 oder J3) abziehen und in das Grundgehäuse unseres Akku-Ladekabels einstecken.
Ein balanciertes Laden ist damit aber noch nicht möglich. Wir müssen dazu noch zwei XH-Balancer-Verlängerungskabel bauen:
- Wir bestellen zwei "XH-Stiftleisten 3-polig RM 2,5mm",
- zwei "XH-Buchsengehäuse 3-polig RM 2,5mm" mit den zugehörigen sechs "Crimpkontakten"
- und Flachkabel RM 2,5mm (z.B. wie dieses, von dem wir 3 Adern abtrennen). Wir brauchen einmal 50cm (für den vorderen Akku) und noch einmal 35cm (für den hinteren Akku) von diesem 3-poligen Kabel.
Aus diesem Material stellen wir zwei Balancer-Verlängerungskabel her.
Wichtig: Die 3 Adern nicht falsch polen!
Die Lötverbindungen an den Steckverbindern sollten mit Schrumpfschlauch überzogen werden. Die XH-Stiftleisten verbinden wir mit den XH-Buchsen der Akku-Anschlußkabel. Beim Laden des jeweiligen Akkus verbinde ich die XH-Buchse des Verlängerungskabels dann mit der XH-Stiftleiste des Ladegeräts. Damit können die Akkus nun auch balanciert geladen werden. Das ist bei LiPo-Akkus sehr wichtig.
- Man kann zwar die Akkus gemeinsam auch mit der Ladeschaltung des WTR-CK1 laden, sollte aber etwa jede 10. Ladung balanciert und für jeden Akku separat mit einem dafür geeigneten Ladegerät durchführen.
- WICHTIG: Die Ladeschaltung des WTR-CK1 beendet die Ladung der angeschlossenen Akkus bei etwa 9,7V. Dies ist passend für 7-Zellen-NiMH oder NiCd-Akkus, jedoch nicht für 2-Zellen-LiPo-Akkus! Daher muss bei Nutzung von LiPo-Akkus der Ladevorgang mit einem Spannungsmessgerät überwacht und bei 8,4V abgebrochen werden.
- Wenn man zwei oder mehr Akkus für den WTR verwendet, dürfen diese nur dann parallel geschaltet (d.h. an J2 und J3 angeschlossen!) werden, wenn sie denselben Ladezustand (z.B. balanciert voll geladen) haben. Beachtet man das nicht, können extrem hohe Ausgleichsströme fließen, die u.U. auch den WTR-CK1 beschädigen können!
Technik
Daten
| Mikrocontroller: | 2 AVR ATmega644 |
| Speicher: | 2x 64 kB Flash-Speicher, davon 1 kB bereits vom Bootloader belegt 2x 4 kB RAM |
| Programmierung: | Über AVR-Bootloader, belegt ca. 1 kB des Flash-Speichers |
| Vorhandene Sensoren: | 2 Bumper 2 Lichtsensoren (LDR) |
| Vorhandene Aktoren: | 6 Getriebe-Motoren 12 Status-LEDs |
| Abmessungen: | Roboter: (L × B × H) 381 × 310 × 131 mm (ohne Controller) Controller: (L × B × H) 364 × 121 × 32 mm (ohne Funkmodul) |
| Gewicht: | 3,8 kg (Roboter, Controller und Akkus) |
| Ausführung: | Nahezu fertig aufgebauter Roboter Dazu passende Controller Platine |
| Stromversorgung: | 2 LiPo Akkus 7,4V 4600mAh oder Festspannung 7,2V |
| Hersteller: | Arexx Niederlande |
Beschreibung
Stromversorgung
Die Schaltung der Stromversorgung und Akku-Ladung zeigt die Datei "Wild Thumper supply.pdf" (siehe Anleitung, Version 0610, Seite 63!). Bei meinem WTR-CK1 Controller sind die zwei Widerstände R1, R4 anders bestückt als im Schaltplan:
- R1: 330 Ohm (Schaltplan: 270 Ohm)
- R4: 2,2 kOhm (Schaltplan: 1,5 kOhm)
Mit dem Spannungsregler-IC LM317 ist hier eine einfache Ladeschaltung (siehe Schaltungsbeispiel "9.3.11 Current-Limited 6-V Charger Circuit", Seite 15 des LM317 Datenblattes!) umgesetzt. Dabei fließt ein Ladestrom, der durch die Ladewiderstände R6 bis R8 bestimmt wird. Mit den 3 Ladewiderständen sind insgesamt 4 Ladestromstärken wählbar. Die folgende Tabelle zeigt den Ladestrom abhängig von der Jumperstellung von JP1 und JP2.
Ladestrom:
| JP1 | JP2 | Widerstand | Ladestrom |
| 0 | 0 | 1,5 Ohm | 150 mA |
| 1 | 0 | 0,75 Ohm | 400 mA |
| 0 | 1 | 0,47 Ohm | 800 mA |
| 1 | 1 | 0,36 Ohm | 1350 mA |
Hinweise: Spalten JP1/JP2: 0 -> Jumper offen 1 -> Jumper geschlossen Spalte Ladestrom: Gemessen bei einer Akkuspannung von 8,0 Volt und bei der aktuellen Bestückung von R1, R4!
Die Ladeschaltung beendet die Ladung oberhalb von 9,69 Volt (für 7-Zellen-NiMH oder NiCd-Akkus). Diese Ladeendspannung ist festgelegt durch die schon oben erwähnten Widerstände R1 (330 Ohm), R4 (2,2 kOhm). Für die für den WTR empfohlenen LiPo-Akkus ist diese Ladeendspannung viel zu hoch: Ihre Ladeendspannung beträgt 8,4 Volt. Damit ist die Ladeschaltung in der (bei meiner WTR-CK1 Platine!) vorhandenen Dimensionierung des Spannungsteilers R1, R4 nicht für die Ladung von 2-Zellen-LiPo-Akkus geeignet!
Ladeendspannung:
| R1 | R4 | Ladeendspannung | Kommentar |
| 270 Ohm | 1500 Ohm | 8,27 Volt | laut Schaltplan |
| 390 Ohm | 2200 Ohm | 8,41 Volt | Empfehlung für LiPo-Akkus |
| 330 Ohm | 2200 Ohm | 9,69 Volt | aktuelle Bestückung! |
Probleme
Bei meinem WTR kommt es selten zu einem Problem mit der Stromversorgung in Form eines "Aufhängens" des Motor Controllers bei extremen Wechseln der Geschwindigkeit der Motoren, z.B. von 0% auf 100% PWM. Dies liegt offenbar an einem kurzzeitigen Einbruch der Versorgungsspannung VCC (5V) des Motor Controllers bei einem sehr raschen Anstieg des Versorgungsstroms der Motoren.
Es gibt für dieses Problem 3 mögliche Lösungen, wobei die Sicherheit, dass das Problem nicht mehr auftritt, von der ersten bis zur dritten Lösung zunimmt:
- 1. Die Motoransteuerung erfolgt nur mit einer verzögerten Beschleunigung:
- Die Motor Library ab Version 2.0 ermöglicht eine "sanfte" Motoransteuerung.
Sensoren
Bumper
Lichtsensoren
Infrarot ACS
Drehgeber
Radencoder
Quadratur Encoder
Der WTR besitzt 6 identische DC-Getriebemotoren. Jeder dieser Motoren verfügt über einen Quadratur-Encoder. Damit läßt sich die Drehzahl jedes Motors genau bestimmen. Diese Encoder bestehen aus 2 Hall-Sensoren des Typs A1120L, die um 90° versetzt unter einem Magneten angebracht sind, der auf der Motorwelle sitzt. Der Magnet ist aus 4 Magnetpolen aufgebaut. Rotiert er über den Hall-Sensoren, dann kann man je Motorumdrehung 8 Impuls-Flanken (4 fallende und 4 steigende) an ihrem Ausgang (A oder B) messen.
Der Vorteil von Quadratur-Encodern liegt in ihrer möglichen hohen Impulszahl pro Motorumdrehung: Verbindet man z.B. die Ausgänge (A und B) mit den beiden Eingängen eines XOR-Logikbausteins, dann kann man an dessen Ausgang 16 Impulsflanken pro Motorumdrehung messen.
Mit dem WTR wollen wir aktuell nur jeweils einen Ausgang der Quadratur-Encoder nutzen. Auch mit "nur" 8 Impulsflanken pro Motorumdrehung kann der WTR gut gesteuert werden: Bei der Getriebeübersetzung von 34:1 ergibt sich eine Gesamtzahl von 8 * 34 = 272 Impuls-Flanken pro Radumdrehung. Damit ist eine recht hoch auflösende Streckenmessung möglich.
Motor-Stromsensoren
Motor-Fehlersensoren
Akku-Spannungssensor
Temperatursensor
Aktoren
Getriebe-Motoren
Der WTR besitzt 6 identische DC-Getriebemotoren (siehe Abbildung rechts!). Laut Datenblatt handelt es sich um die Typen GA25Y370-34. Bezug z.B. über die Firma DAGU als Model No. RS003B-encoder. Hersteller ist offenbar die chinesische Firma HCS MOTOR Co.,LTD (Model No. GA25Y370-22170-103).
Technische Daten (lt. Datenblatt):
- Spannungsbereich: 6,0..7,2V
- Nennspannung: 6,0V
- Haltestrom: 5,5A
- Haltemoment: 4kg/cm
- Umdrehungen pro Minute: 294RPM
- Getriebe-Übersetzung: 34:1
- Geräuschentwicklung: < 80dB
Die technischen Daten nach (AREXX-) Datenblatt, Motor-Aufdruck und Angaben auf der Hersteller- bzw. Händlerseite unterscheiden sich z.T. erheblich.
Auf die Getriebeübersetzung soll hier noch eingegangen werden. Das vorhandene 34:1 Getriebe übersetzt wie folgt:
(22 x 20 x 22 x 22 x 23) / (12 x 12 x 10 x 10 x 10) = 34,014444 : 1
Zu den verbauten Quadratur Encodern siehe Abschnitt Quadratur Encoder!
Status-LEDs
APC-220 Funkmodul
Umbau-Optionen
Hier soll beschrieben werden, welche Umbau-Optionen es für den Wild Thumper gibt. Im Text gibt es Verweise auf die Schaltpläne des WTR-CK1 (Wild Thumper main controller.pdf, Wild Thumper motor controller.pdf, Wild Thumper bumper.pdf, siehe Anleitung, Version 0610, Seiten 65, 64, 66!) in der Form: (Main B1: Bauteil). Dies bedeutet, dass man das Bauteil im Schaltplan des Main Controllers im Feld B1 finden kann. Beispielhaft sind im folgenden Text Bestell-Nummern der Firma CONRAD genannt. Natürlich kann man die Teile auch bei anderen Versendern beziehen.
Bei den Materialangaben ist öfter die Rede von "Steckbuchsen mit Litze". Diese Steckbuchsen mit angelöteter Litze können auf die ein- oder zweireihigen Stiftleisten aufgesteckt werden. Leider gibt es sie nicht (mehr) fertig konfektioniert bei CONRAD. Die einreihigen Steckbuchsen (RM 2,54mm) kann man aber z.B. bei ELV bekommen: 2-polig (68-016635), 3-polig (68-022503) und 5-polig (68-023073); die 1-polige Form z.B. auch hier (mit zugehörigen Crimpkontakten). An sie muss man dann noch Litzen in der entsprechenden Länge selbst anlöten.
Innerhalb der Gewährleistung sollte man NICHT an der Platine des WTR-CK1 Veränderungen vornehmen, da man dann u.U. den Gewährleistungsanspruch verlieren kann!
Accelerometer
R17
Beim Testen des WTR fällt auf, dass (bei meinem Exemplar des WTR-CK1 Controllers) der gemessene Strom von Motor 4 kaum ansteigt, während dies bei allen anderen Motoren gut funktioniert. Z.B. steigt im Feld "Current" der Application Wild Thumper der angezeigte Motorstrom für "Front (4)" nicht an, auch wenn der vordere rechte Motor 4 mit voller Beschleunigung läuft.
Dies liegt an einem falsch bestückten Widerstand auf der WTR-CK1 Platine. Der Widerstand R17 (6k2) wurde (auf meiner Platine!) mit 47k bestückt.
Dieser Fehler kann leider nur korrigiert werden, indem der falsche Widerstand ausgelötet und durch einen Widerstand 6k2 (SMD 0805) ersetzt wird.
Innerhalb der Gewährleistung empfiehlt es sich, den falsch bestückten Widerstand zu reklamieren. Will man das Wechseln des Widerstands R17 selbst machen, muss man SMD-Bauteile (ent-)löten können und über ein ESD-Tischmatten-Set verfügen.
R1, R4
Die Schaltung der Stromversorgung und Ladeschaltung zeigt die Datei "Wild Thumper supply.pdf" (siehe Anleitung, Version 0610, Seite 63!). Bei meinem WTR-CK1 Controller sind die zwei Widerstände R1, R4 anders bestückt als im Schaltplan:
- R1: 330 Ohm (Schaltplan: 270 Ohm)
- R4: 2,2 kOhm (Schaltplan: 1,5 kOhm)
Die Ladeschaltung beendet die Ladung oberhalb von 9,69 Volt (für 7-Zellen-NiMH oder NiCd-Akkus). Diese Ladeendspannung ist festgelegt durch die Widerstände R1 (330 Ohm), R4 (2,2 kOhm). Für die für den WTR empfohlenen LiPo-Akkus ist diese Ladeendspannung viel zu hoch: Ihre Ladeendspannung beträgt 8,4 Volt. Damit ist die Ladeschaltung in der (bei meiner WTR-CK1 Platine!) vorhandenen Dimensionierung des Spannungsteilers R1, R4 nicht für die Ladung von 2-Zellen-LiPo-Akkus geeignet!
Ladeendspannung:
| R1 | R4 | Ladeendspannung | Kommentar |
| 390 Ohm | 2200 Ohm | 8,41 Volt | Empfehlung für LiPo-Akkus |
| 330 Ohm | 2200 Ohm | 9,69 Volt | aktuelle Bestückung! |
Will man eine Ladeendspannung von 8,4 Volt erreichen, weil 2-Zellen-LiPo-Akkus dauerhaft mit dem WTR-CK1 Controller genutzt werden sollen, dann muss man R1 (330 Ohm) auslöten und durch einen Widerstand 390 Ohm (SMD 0805) ersetzen. R4 bleibt 2,2 kOhm.
R38, R39
R35, R56
Anschlüsse
Main Ports
Q7, Q8
Mess-/Kontaktpunkte
Lochraster-Felder
Vorn links
Mitte rechts
Zubehör und Ersatzteile
Hier sollen Dinge aufgeführt werden, die außer dem WTR selbst und der WTR-CK1 Controller-Platine nötig sind, als Ersatzteile oder optional bestellt werden oder als Erweiterung dienen können.
Notwendig
- 2 Stück LiPo Akku 7,4V 4600mAh
- 2 Stück Modelcraft T-Stecker-Akkukabel 2.5 mm² 300 mm
- Stecker-Netzteil 12V 2A.
- Kabelbinder
Optional
- LiPo-LiFe-Balancer Ladegerät (zum balancierten Laden einzelner LiPo-LiFe Akkus)
- XH-Steckbuchse, 3-polig mit 3 Crimpkontakten (zum Anschluß der 6 Quadratur-Encoder an die XH-Stiftleisten des WTR-CK1 und für zwei XH-Balancer-Verlängerungskabel)
- XH-Stiftleiste, 3-polig (für zwei XH-Balancer-Verlängerungskabel)
- Flachkabel RM 2,5mm (für zwei XH-Balancer-Verlängerungskabel)
- Grundgehäuse DECA ME030-50804 (Gegenstück zur Akku-Schraubklemm-Buchse für ein Akku-Ladekabel)
Als Ersatzteil
- 2 Räder (Durchmesser 12cm, Breite 6 cm, Chromfelgen, V-Profil mit Spikes)
- Encoder-Motor mit 34:1 Getriebe
- Motor mit 34:1 Getriebe (z.B. als Getriebe-Ersatz)
- Motor mit 34:1 Getriebe (kompatibel, z.B. als Getriebe-Ersatz)
- 2 APC-220 Module und USB Programmier-Adapter V2
- Feinsicherung 16A träge (als Ersatz für Feinsicherung 15A träge)
- Motor-Schraubklemm-Buchse.
- Akku-Schraubklemm-Buchse
Zur Erweiterung
Anschlüsse
- Niedervolt-Stecker 5,5mm außen; 2,1mm innen (zur Verbindung eines Netzteils mit der DC-Buchse J1)
- Pfostenverbinder, 10-polig (zum Anschluß externer Schaltungen an die 2-reihigen Stiftleisten des WTR-CK1 mit Flachkabel RM 1,27mm)
- Stiftleiste RM 2,54mm gerade (zur Bestückung der vorgesehenen 1-reihigen Stiftleisten des WTR-CK1)
Accelerometer
- ADXL330 (Beschleunigungssensor anstelle des ADXL326: U13)
- Diode LL4148 SOD-80 (2 Stück: D4, D5)
- Keramik-Kondensator 0,1µF/50V/5% SMD 0805 (3 Stück: C62, C63, C64)
- Widerstand 1,8kOhm/0,125W/1% SMD 0805 (R50)
- Widerstand 3,3kOhm/0,125W/1% SMD 0805 (R54)
- Stiftleiste RM 2,54mm gerade (3-polige Stiftleiste: HDR9)
Programmierung
Um diesen Artikel zum Wild Thumper nicht immer länger werden zu lassen, habe ich den Teil zur Programmierung des WTR-CK1 Controllers ausgelagert: Wild Thumper - Programmierung
Erfahrungsberichte
Siehe auch
- Wild Thumper - Programmierung
- RP6
- RP6 - Programmierung
- RP6v2
- RP6 Sensor Board und Xtra Module
- RP6 Kamera - Mitmach-Projekt
- RP6v2 I2C-Portexpander
- RP6v2 USB-RS232-Adapter
- RP6v2 Orientierung
- RP6 Multi IO Projekt
- RP6 Multi IO Projekt - Software
- RP6 ArduIO
- RP6 ArduIO - Software
- Induktive Ladestation für den RP6
- IR-bake für den RP6
- CCRP5
- Yeti
- Asuro
- C't-Bot
Weblinks
- Wild Thumper bei CONRAD
- Wild Thumper bei voelkner
- Wild Thumper bei CPC Farnell
- Wild Thumper bei getgoods.de
- Wild Thumper bei digitalo.de
- Wild Thumper bei Reichelt
- Wild Thumper Controller bei CONRAD
- Wild Thumper Controller bei voelkner
- Wild Thumper Controller bei CPC Farnell
- Wild Thumper Controller bei getgoods.de
- Wild Thumper Controller bei digitalo.de
Autoren
--Dirk 19:10, 24. Nov 2015 (CET)