Flight-Control vorne	Flight-Control hinten
Sensor-Board vorne	Sensor-Board hinten

Achtung: Beide Boards sind nicht vollständig und haben Fehler (siehe Text)

Batteriestecker

Die Sensoren wollte ich nicht fest ein löten sondern Steckbar machen wie es einige der Entwickler auch haben. Leider hatte ich zu wenig Stiftleisten, und vor allem keine abgewinkelten Stiftleisten zur Hand, weshalb ich diese, bis auf den LIS3L, noch nicht anlötete. Der erste Start konnte ich nicht wie in der Anleitung mit begrenztem Strom durchführen, da ich kein Labornetzteil habe. Ich habe als Work-Around mein Multimeter dazwischengehängt. Dies hat bei der Strommessung beim kleinen Anschluss (für Mikro/Milliampere) eine 400mA Sicherung.Vorsicht: Beim vor konfektionierten Stromkabel entspricht die Farbe der Drähte nicht der Polung am Stecker. Die einzelnen Drähte können aber vom Stecker entfernt werden und in der korrekten Anordnung wieder eingesteckt werden. Nachdem ich Spannung angelegt habe und den On-Button gedrückt habe leuchteten die LEDs, alles schien in Ordnung zu sein. Die unter Initialization genannten Testpunkte hatten die richtige Spannung.

Um den LPC-2148 flashen habe ich den Stecker tty0 mit dem erstellten Kabel am SerCon SIO eingesteckt. Das zum Download angebotene Tool lpc21isp kann aus der Linux-Konsole gestartet werden.

$ lpc21isp -verify -wipe wolferl-ng.hex /dev/ttyUSB0 38400 12000
Verify after copy RAM to Flash.
lpc21isp version 1.48
File wolferl-ng.hex:
 loaded...
 converted to binary format...
 image size : 288296
Synchronizing (ESC to abort). OK
Read bootcode version: 12
2
Read part ID: LPC2148, 512 kiB ROM / 40 kiB SRAM (67305253)
Will start programming at Sector 1 if possible, and conclude with Sector 0 to ensure that checksum is written last.
Wiping Device. OK
Sector 1: ...........................................................................................
...
Download Finished and Verified correct... taking 161 seconds
Now launching the brand new code

Die erste Ausgabe war aber wirklich ernüchternd

Wolferl-NG, Version 0.54, Revision r4022

Type 'show license' for software license
Type 'help' for a list of commands

# show devices

Detected devices: 

 No devices detected!

SerCon zu NG UAVP

Mit einem Flachbandkabel, einem 6-Pin Stecker und einem 10-Pin Stecker habe ich ein Atmel-ISP-Programmierkabel für die SerCon erstellt. Dabei ist mir aufgefallen dass ich den Wannenstecker auf dem Flight-Control-Board verkehrt aufgelötet habe (Kerbe müsste nach unten sein). Zudem ist die Pinfolge auf dem SerCon nicht dem Standard entsprechend, weshalb ich den Adapter wie folgt verbunden habe:

NG UAVP        SerCon ISP1
1        =>    9
2        =>    2
3        =>    7
4        =>    1
5        =>    5
6        =>    10

Damit konnte ich den Atmel auf dem Flight-Control PCB flashen, was jedoch etwas lange ging (ca. 1h mit verify)

$ avrdude -p m644p -c ponyser -P /dev/ttyUSB0 -V -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m
...
$ avrdude -p m644p -c ponyser -P /dev/ttyUSB0 -U flash:w:rc-ctrl.hex
...

Der Atmel auf dem Sensor-Board benötigt jedoch nur 3.3V, weshalb ich die Zehner-Dioden auf dem SerCon mit 3.3Volt Zehner-Dioden ersetzt habe. Leider funktionierte das Flashen immernoch nicht. Ich konnte ein Atmel STK500 Programmierer organisieren, mit welchem das Programmieren ganz schnell funktionierte. Zuerst musste ich aber auch da die Spannung senken:

$ avrdude -p m328p -c stk500 -P /dev/ttyUSB0 -t -F

avrdude: stk500v2_command(): command failed
avrdude: stk500v2_recv(): checksum error
avrdude: stk500v2_program_enable(): bad STK600 connection status: Unknown (0x64)
avrdude: initialization failed, rc=-1
avrdude: AVR device initialized and ready to accept instructions
avrdude: Device signature = 0x000000
avrdude: Yikes!  Invalid device signature.
avrdude: Expected signature for ATMEGA328P is 1E 95 0F
avrdude> vtarg 3.3
>>> vtarg 3.3
avrdude: stk500v2_set_vtarget(): reducing V[aref] from 5.0 to 3.3
avrdude> quit
>>> quit

Die Fehlermeldungen können ignoriert werden… Nun sollte zwischen Pin 2 und 6 am Stecker ISP6PIN 3.3Volt gemessen werden. mit dem beigelegten Kabel kann nun das Sensorboard angeschlossen und geflasht werden:

$ avrdude -p m328p -c stk500 -P /dev/ttyUSB0 -V -U lfuse:w:0xff:m -U hfuse:w:0xde:m -U efuse:w:0x00:m
...
$ avrdude -p m328p -c stk500 -P /dev/ttyUSB0 -U flash:w:sb-ctrl.hex
...

Die Aktoren antworteten nicht auf anhieb (“show devices” listete nicht alle Aktoren auf, auch “scan actors” fand keine Aktoren). Der Fehler lag bei einem nicht richtig angelöteten Pin beim IC4. Danach wurden alle Brushless-Controller erkannt. Diese habe ich dann später auch mit einigen Befehlen in der NG UAVP Konsole getestet:

set defaults mlx10"
...
set controller rc-test
...
set HW.HAL quadcopter
...
set RC.dev.primary dsl0
...
# show actors

Detected actors in current se
Needed actors in current HAL:

Actor addresses used:        

Actor Activation Status:

 Actor 1: enabled (front)
 Actor 2: enabled (back)
 Actor 3: enabled (right)
 Actor 4: enabled (left)

Nun kann mit den Befehlen “disable actor” und “enable motors” getestet werden. Vorsicht: Die Motoren drehen damit!

disable actor 2
disable actor 3
disable actor 4

enable motors

Momentan sind einge Baustellen offen bei mir: Zum einen Antwortet der LIS3L nicht. Ich nehme an dass dieser den Lötvorgang nicht überstanden hat. Strom ist auf dem Breakout-Board vorhanden. Die Gyrometer habe ich inzwischen mit Stiftleisten montiert. Um den OPA4350 sind viele Kondensatoren und Widerstände nahe beieinander. Ich habe insgesamt vier Bauteilen verdreht aufgelötet.  Es empfiehlt sich in diesem Bereich die Fotos auf dem Wiki zu beachten (welches auch Fehler beinhalteten, inzwischen jedoch korrigiert sind). Daraufhin antworteten die Gyros, ich hatte jedoch leider  beim Befehl “loop adc12″ Unregelmässigkeiten beim Yaw-Gyro. Auch ein tauschen der Gyros hat nichts gebracht, es deutet momentan alles daraufhin das der 12-Bit-AD-Wandler ein Problem hat. Auch der ADS1255 sollte unter “show devices” sichtbar sein, was er aber nicht ist. Noch weiss ich nicht weshalb er dies nicht macht.

In der Zwischenzeit habe ich meine Brushless Controller etwas unter die Lupe genommen. Bei der Bestellung habe ich mich für günstige “China-Controller” gegenüber den teureren BC’s von Mikrokopter.de entschieden. Die TowerPro w25A ESC (Electric Speed Controll) habe ich bei HobbyKing gekauft, und sollten mit ein paar Modifikationen ohne weiteres zur Zusammenarbeit mit dem NG UAVP bewegt werden. Zudem sollen sie Leistungsfähiger sein als die BC’s von Mikrokopter.de.

Nun, warum sind die Modifikationen notwendig? Normalerweise werden die Brushless Controller mit einem PWM-Signal angesteuert. Bei einem PWM-Signal (Pulsweitenmodulation) wird mit der Länge der Einschaltdauer des Stroms der “Wert” bestimmt (mehr dazu hat die Wikipedia). Bei einem Brushless Controller heisst dies, je länger der Strom eingeschaltet ist, desto schneller soll sich der Motor drehen. PWM ist im RC-Modellbau sehr gebräuchlich: Normalerweise werden damit Servo-Motoren angesteuert. Die Lage des Servos wird dabei durch die Einschaltdauer bestimmt. Dies wurde nun auch bei den BC’s so angewendet, weshalb auch die TowerPro w25A direkt an einem RC-Empfänger angeschlossen werden können um so den Motor zu steuern.

Da die Motoren bei einem Mikrokopter vom Mikrokontroller gesteuert werden, ist ein PWM Signal eher ungünstig. Zudem können die meisten BC’s mit einem PWM-Signal nur 150 mal pro Sekunde geregelt werden. Für einen stabilen Flug eines Mikrokopters haben sich jedoch raten von ca. 300 Regelungen pro Sekunde bewährt (der NG UAVP regelt übrigens mit 1000Hz). Deshalb ist ein Umstieg auf eine andere Kommunikation mit den BC’s notwendig. Dafür hat das Mirkokopter.de Projekt bereits den Weg angebahnt, und ihren BC mit I2C ausgestattet. I2C ist ein serieller Datenbus (siehe Wikipedia). Dabei hat jedes Gerät am Bus eine eigene Adresse. Alle BC’s müssen deshalb nebst dem Umbau mit einer eigenen, neuen Firmware versehen werden, welche I2C spricht und die Motoren-ID kodiert hat.

Im RCGroups-Forum wurde dieser Umbau publiziert und dokumentiert. Zuerst wurde der TowerPro w25A Type 2 konvertiert. Der User Quax hat dazu die Software modifiziert. Später gab es jedoch eine neue Version, den TowerPro w25A Type 3 (mit dem H Kleber auf der Rückseite). Die Konvertierung dieses Typs ist ab Seite 21 im selben Forum dokumentiert. Als ich nun mein TowerPro w25H aufschlitzte kam jedoch eine neue Revision zum Vorschein: Type 3/H Revision 1.1.

Ab Seite 43 im Forum fand ich jedoch Entwarnung, auch diese Revision sollte sich ohne weiteres modifizieren lassen…

Trotzdem hab ich mich noch nicht ans Konvertieren gewagt. Ich möchte zuerst einen konvertieren und testen, habe jedoch gerade nichts zur Hand, was I2C spricht.  Das I2C-Protokoll für die BC’s ist übrigens sehr einfach: Als Adresse wird 0×50 + 2 * Motoren-ID (z.B. 0×52 für den 1. Motor) und dann die Kraft zwischen 0 und 250.