Bereits seit einigen Tagen hatte ich die Leiterplatten der beiden Konnektivitätsgeräte NGcon und NGusb. Inzwischen sind auch die dazu benötigten Bauteile angekommen und verbaut. Jedoch funktionierte weder das NGusb noch das NGcon auf anhieb: Beim NGusb stellte sich heraus dass ich die LED verkehrt aufgelötet habe. Die LED sollte beim Einstecken kurz aufblicken, was sie nicht tat. Danach hab ich fälschlicherweise den Jumper gesetzt um das verbundene Gerät mit Spannung zu versorgen. Da der NG jedoch selbst versorgt ist, funktionierte das NGusb nicht. Danach wurde es von Linux erkannt und funktionierte einwandfrei. Die Ausgabe von “dmesg” zeigt das der FTDI Converter auf dem NGcon erkannt wurde:

[15642.821825] usb 8-1: new full speed USB device using uhci_hcd and address 54
[15643.022980] usb 8-1: configuration #1 chosen from 1 choice
[15643.029828] ftdi_sio 8-1:1.0: FTDI USB Serial Device converter detected
[15643.029884] usb 8-1: Detected FT232RL
[15643.029889] usb 8-1: Number of endpoints 2
[15643.029894] usb 8-1: Endpoint 1 MaxPacketSize 64
[15643.029899] usb 8-1: Endpoint 2 MaxPacketSize 64
[15643.029903] usb 8-1: Setting MaxPacketSize 64
[15643.033485] usb 8-1: FTDI USB Serial Device converter now attached to ttyUSB0

Beim NGcon stellte sich heraus dass zwischen dem RS232 und dem MAX3232 die RX-/TX-Leitungen falsch verbunden sind. Dies kann behoben werden indem die Verbindung zwischen den Via’s (Durchstichlöcher) und dem MAX3232 mit einem Cutter-Messer durchtrennt und mit Lackdraht gekreuzt verbunden wird.

Die neuen Akkus sollten nächste Woche ankommen, diese wurden heute Nacht versendet. Auch die LIS3L Breakouts sind nun im NG UAVP Shop verfügbar. Obwohl der Erstflug auch ohne diese möglich gewesen wären, ist mir ein komplettes System viel lieber!

Leider stellte sich die Kombination der TowerPro w25A mit den Turnigy 28-30 1100KV Motoren als eine nicht zuverlässige Kombination. Gleich drei Motoren hatten Startschwierigkeiten. Auch das Bewegen des NG’s oder aufdrehen der Kraft der Motoren hat sie nicht zum starten gebracht.

Ich habe mich deshalb entschieden die Motoren mit dem MK-BL-Controllern zu betreiben da diese deutlich bessere Startroutinen haben. Inzwischen sind die BL-Controller angekommen, eingebaut und getestet. Allerdings hatte ich während meinen Ferien den Akku am NG angeschlossen gelassen, was zur totalen Entladung führte. Was ich nicht wusste, dass der Akku dadurch zerstört wird: Ab einer gewissen Zellenspannung ist der Akku unterladen und nicht wieder aufladbar… Die neuen Lipo-Akkus sind bereits bestellt muss ich mich bis zum Erstflug weiter gedulden.

Meine Steuerung ist inzwischen fertig. Fast, bis auf das eine Manko: Der LIS3L. Auch ein zweiter Versuch hat der LIS3L nicht überstanden. Nun ist es definitiv Zeit Hilfe von Profis anzunehmen: Im NG UAVP Forum wird diskutiert ob der LIS3L fertig per Reflow-Prozess gelötete Breakout-Boards angeboten werden soll. Nachdem Sparkfun diese Beschleunigungssensoren nicht mehr anbietet, ist die Hauptquelle der gelöteten Headerboards versiegt. Es existieren noch Restposten auf lipoly.de. Der ADS1255 funktioniert inzwischen, ein Pin zum Quarz war nicht korrekt angelötet. Den AD7924 für die Drehratensensoren habe ich inzwischen ausgetauscht, und siehe da, alle Drehratensensoren funktionieren einwandfrei! Auch der Magnetkompass funktioniert, wobei dieser noch nicht kalibriert ist. Die Kalibrierung muss gemäss Entwickler direkt via UART-Schnittstelle X1 auf dem Sensorboard vorgenommen werden. Der Befehl “show ngpp” zeigt aber bereits Werte.

Weiter haben mein Bruder und ich den Rahmen geplant. Aluprofil der Stärke 1cm ist vorhanden und wurde bereits nach diesem Plan zugeschnitten. Die Löcher sind vorgebort so dass die Motoren und der Rahmen nur noch verschraubt werden müssen. Die Kabellänge der Motoren habe ich inzwischen verlängert: Die Motoren habe ich direkt an den Brushless Controller angeschlossen, also die Kabel des Brushless-Controllers auf der Motorenseite entfernt. Die Stromzuleitungen habe ich auch entfernt und durch etwas längere ersetzt. Die Brushless-Controller werden so relativ nahe bei den Motoren, also auf den Armen montiert. Die Stromverteilung werde ich für den Erstflug einfach machen, also die Kabel direkt zusammen löten.Den LiPo habe ich geladen und ist ebenfalls bereit für den Erstflug. Die Konfiguration und die Initialisierung habe ich noch nicht gemacht, dies werd ich machen sobald ich den Quadrocopter zusammengebaut habe. Wenn alles Glatt geht sollte morgen der grosse Tag sein, der Erstflug. Berichten werde wahrscheinlich erst später… Stay tuned!

Letzte Woche habe ich an zwei Abenden die beiden Leiterplatten bestückt. Beim Löten ging alles glatt, ich hätte nicht erwartet das SMD-Löten so einfach ist. Ich habe mich auch etwas informiert wie SMD-Löten am besten gelingt. Insbesondere das PDF “Der richtige Umgang mit SMD” und der Artikel “SMD Löten” von microcontroller.net haben mir geholfen. Nicht zu vergessen natürlich die Anleitungen für das Sensor-Board, die Flight-Control und die Mounting-Order-List. Während des Lötens ist mir aufgefallen dass ich beim Bestellen die SMD-Duo-Leds vergessen habe. Zudem haben mir noch zwei Teile gefehlt (der ADS1255 und der SN74LVC32). Der ADS1255 wird für den Luftdrucksensor verwendet und ist daher relativ wichtig. Der SN74LVC32 wird für den Extension-Bus benötigt, ist also für die Flugfähigkeit nicht wichtig. Den ADS1255 scheint unter allgemeiner Verknappung zu leiden, selbst der Hersteller TI meldet dass sie diesen erst ende Februar liefern können. Ich konnte ihn von einem der Entwickler ausleihen, vielen Dank nochmals.

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

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

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!

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.

Der Beschleunigungssensor des NG UAVP (der LIS3LV02DQ, kurz LIS3L) hat auch auf dem Bauch ein Kontakt. Deshalb ist das Löten mit dem Lötkolben nicht möglich. Da der ansonsten übliche Reflow-Lötprozess teure Geräte benötigt muss eine andere Lösung gefunden werden. Die eine Möglichkeit ist ein Headerboard zu kaufen auf welchem der LIS3L bereits bestückt ist. Als “Work-Around” kann auch eine Heissluftgebläse verwendet werden, mit dem Risiko dass der Chip den “Lötprozess” nicht überlebt. Wie in einem vorherigen Beitrag bereits erwähnt, wollte ich das Risiko bewusst eingehen und den Chip selber löten. Nachdem ich diese Woche das dafür benötigte Flussmittel bekommen habe, ging es gestern ans Werk. Wie in der ausgezeichneten Anleitung auf dem NG UAVP-Wiki erwähnt, habe ich die Pads zuerst mit Lötzinn verzinnt und etwas Flussmittel drauf gegeben. Auch den LIS3L habe ich mit Flussmittel beschmiert. Danach habe ich den Lötzinn und die Leiterplatte mit dem Heissluftgebläse erhitzt, den LIS3L auf den heissen Lötzinn platziert, und nochmals etwas erhitzt bis er sich setzte. Ich habe den ganzen Prozess in einem Video festgehalten…

Ob es funktioniert hat, also ob der LIS3L noch funktioniert, weiss ich noch nicht. Weiter habe ich auch noch die Drehratensensoren (die MLX90609EEA-R2, kurz MLX) gemäss der Anleitung aus dem NG UAVP-Wiki gelötet. Auch hier habe ich mit Flussmittel gearbeitet, was die Arbeit sehr erleichterte. Heute ist die letzte Bestellung mit den Atmels angekommen, es heisst also gleich weiter löten, so dass ich hoffentlich bald meine Sensoren testen kann!

Obwohl ich eigentlich warten wollte bis ich ein Gerät habe welches I2C spricht hab ich mich nun doch ans konvertieren der Brushless Controller gewagt. Der Umbau war etwas kniffliger als ich erwartet hätte, denn die Beine des Atmel-Mikrokontrollers sind sehr klein und nahe beieinander. Die Konvertierung wurde bereits von vielen Personen durchgeführt, mit unterschiedlichen TowerPro-Typen und Tools. Daher musste ich zuerst einige Informationen aus den Foren zusammenzutragen. Ich dokumentiere hier deshalb die Konvertierung und Programmierung mittels SerCon und AVRDude der aktuellen TowerPro w25A, Type H Revision 1.1. Wie im letzten Blogbeitrag erwähnt geht es darum diese Brushless Controller I2C fähig zu machen, damit diese für Multikoptern verwendet werden können.

Voraussetzungen

• gelandener Akku (oder andere Speisung für den Brushless Controller)
• düne (~0.1mm2), isolierte Drähte oder Lackdrähte
• Lötkolben und Lötzinn
• SerCon
• Computer mit RS232 Schnittstelle oder USB-RS232 Adapter
• Motor und NG UAVP zur Verifizierung der Lauffähigkeit
• TowerPro w25A, Type H Brushless Controller

Schritt 1 – Entfernen nicht benötigter Bauteile

Die kleinen Bauteile sollten ohne Probleme zu entfernen sein. Die Spannungswandler (die grossen schwarzen) sind etwas mühsam, da diese sehr viel wärme ableiten können. Mit folgender Methode hatte ich die besten Ergebnisse: Zuerst die Beine durch anheben befreien. Danach mit etwas mehr Power (ein Lötkolben mit mehr als 40 Watt ist da von Vorteil) die Spannungswandler beim Kopf erhitzen und ablösen. Zum Teil musste ich ein wenig bleihaltigen Lötzinn dazugeben, damit die Wärme besser verteilt wurde und der Schmelzpunkt des Lötzinns etwas sank…

Schritt 2 – Entfernen nicht benötigter Leiter

Weiter müssen zwei Leiterbahnen unterbrochen werden. Diese befinden sich unter den hellgrünen Linien auf der Leiterplatte. Dafür muss zuerst der Lack entfernt werden, wodurch Kupfer zum Vorschein kommt. Dieser muss dann getrennt werden indem ein Stück entfernt wird. Ich habe dies mit einem Cutter getan, einige berichten von guten Ergebnissen mit einem 1er Bohrer welchen Sie von Hand gedreht haben. Wichtig ist dass die angrenzende Leiterbahn unten nicht durchtrennt wird!

Schritt 3 – Neue Verbindungen erstellen

Nun müssen neue Verbindungen erstellt werden. Dafür ist eine ruhige Hand und Geduld notwendig. Ich ging jeweils so vor: Zuerst den Draht ablängen, zurecht biegen und die Isolation entfernen. Danach beim Bein des Mikrokontrollers etwas Lötzinn hinzufügen und den Draht anlöten. Dabei muss beachtet werden das die angrenzenden Beine nicht verbunden sind. Zur Sicherheit habe ich dies mit einem Durchgangsprüfer überprüft.

Schritt 4 – Programmierer verbinden

Nun müssen die Programmier-Pins angeschlossen werden. Dafür habe ich Stiftleisten verwendet welche ich mittels vorkonfektionierten Drähten (diese werden für den NG UAVP benötigt) mit dem SerCon am ISP1 verbunden habe. Auch die Stromversorgung (GND, +5V) müssen verbunden werden, damit SerCon mit Strom versorgt wird. Kriegt der Brushless-Controller Strom, sollte das grüne LED auf dem SerCon-Print leuchten.

Programmier-Pins

Programmier-Pins verbunden

Schritt 5 – Quax/Aggressiva Software Programmieren

Die für I2C angepasste Software wurde ursprünglich von Quax geschrieben. Aggressiva hat die Anpassung für den 25 Ampere Type H Variante gemacht. Die Software kann hier heruntergeladen werden. Die Software ist in kompilierter Form als “.hex” Dateien für mit unterschiedlichen Motorenadressen vorhanden. Nun kann mit dem Tool avrdude (welches ich unter Ubuntu mit “aptitude install avrdude” installiert habe) neu programmiert werden.

$ avrdude -p m8 -c ponyser -P /dev/ttyUSB0 -v -e
...

$ avrdude -p m8 -c ponyser -P /dev/ttyUSB0 -v -U flash:w:tp-25a-new-m1.hex
...

avrdude: Device signature = 0x1e9307
avrdude: safemode: lfuse reads as A4
avrdude: safemode: hfuse reads as DF
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
 To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "tp-25a-new-m1.hex"
avrdude: input file tp-25a-new-m1.hex auto detected as Intel Hex
avrdude: writing flash (2132 bytes):

Writing | ################################################## | 100% 214.23s

avrdude: 2132 bytes of flash written
avrdude: verifying flash memory against tp-25a-new-m1.hex:
avrdude: load data flash data from input file tp-25a-new-m1.hex:
avrdude: input file tp-25a-new-m1.hex auto detected as Intel Hex
avrdude: input file tp-25a-new-m1.hex contains 2132 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 208.78s

avrdude: verifying ...
avrdude: 2132 bytes of flash verified

avrdude: safemode: lfuse reads as A4
avrdude: safemode: hfuse reads as DF
avrdude: safemode: Fuses OK

avrdude done.  Thank you.

Nach einigen Minuten sind die beiden Befehle abgearbeitet und der Brushless Controller läuft mit neuer Software. Die ungekürzte Version der Ausgabe gibt es hier. Nach dem flashen habe ich ein Motor angeschlossen, wodurch beim Start ein charakteristischer Ton hörbar sein sollte, welcher sich von der Originalsoftware etwas unterscheidet. Hier die beiden Töne:

• TowerPro 25A original
• TowerPro 25A Quax

Leider konnte ich die Funktionstüchtigkeit über I2C noch nicht überprüfen, da ich noch immer auf eine Bestellung von CSD warte. Wenn die Brushless Controller an den I2C-Stecker der Flight-Control angeschlossen sind sollten sie durch das NGOS erkannt werden.  Da die Quax-Töne bei allen vier Brushless Controller hörbar waren bin ich zuversichtlich dass die Konvertierung gelungen ist

Danke an Quax, Aggressiva, Mis_b und allen anderen die an der Konvertierung gearbeitet haben. Wer sich etwas mehr über Brushless Controller und die Konvertierung informieren will, dem lege ich den RC-Groups-Thread nahe. Das neue Schema eines konvertierten TowerPro 25A gibt es dort auch zu finden. Mehr Informationen zu Brushless Controller im allgemeinen habe ich einem Wiki gefunden. Auch dies fand ich sehr interessant und ist definitiv Lesenswert.

Update 27.01.2009:

Ich konnte die Brushless Controller inzwischen testen. Für den NG UAVP hab ich in der Anleitung SDA und SCL verwechselt. Dies ist nun behoben, so dass der Stecker direkt auf das Flight-Control-Board aufgesteckt werden kann.

Am 27. Dezember 2009 war es soweit, der Shop zum NG UAVP wurde eröffnet! Somit ist es für jedermann (mit entsprechendem Know-How und/oder Willen ) möglich ein NG UAVP zu bauen. Natürlich habe ich die Hardware gleich bestellt. Die nackten Boards werden zu einem guten Preis von 23€ (plus Versand) verkauft. Versendet wurde sie erst nach dem 26c3 Kongress sind aber heute bei mir angekommen!

In der Zwischenzeit habe ich die letzten Bestellungen für die Bauteile aufgegeben. Dies war einige Stunden Arbeit und barg eine Überraschung: Reichelt, der vorgeschlagene Distributor für viele Bauteile, liefert nur ab 150€ in die Schweiz, und das mit rund 30€ auch noch hohen Lieferkosten! Einige der Bauteile sind bei den anderen beiden vorgeschlagenen Distributoren erhältlich (Farnell/CSD), oder aber bei weiteren Distributoren (die Bauteilliste der HW 0.21 beinhaltet weitere Alternativen). Da ich die anderen Bestellungen jedoch schon abgesendet habe, und nicht alle Bauteile bei den anderen Distributoren erhältlich sind, habe ich mich dazu entschieden zusätzlich andere Dinge bei Reichelt zu bestellen. Trotzdem bin ich ziemlich sauer auf Reichelt, die Versandkosten und der hohe Mindestbestellwert fürs Ausland ist übertrieben, insbesondere für die angrenzenden Länder!

Weiter waren einige Artikel bei Farnell nicht an Lager, was im NG UAVP Forum bereits bemerkt wurde. Ein Teil der Bauteile sind nicht bei anderen Distributoren zu finden. Es sind aber nicht alle Bauteile für den Erstflug notwendig, weshalb diese Bauteile auch später bestückt werden können. Apropos Farnell: Ein Teil der Bauteile haben Mindestbestellmengen. Da hab ich zum Teil ein vielfaches der benötigten Bauteile bestellt, da ich hoffe in der Zukunft weitere NG UAVP’s zu bauen .

Alles in allem empfiehlt es sich die Bestellung bei einem Lieferant erst abzusenden wenn man die Lagerbestände und Lieferkonditionen der anderen Lieferanten überprüft hat! Diese Listen entsprechen nicht ganz der offiziellen Bauteilliste, da ich noch ein SerCon zu bestücken habe. Die offizielle Bauteilliste eignet sich besser zur Bestellung, trotzdem führe ich hier meine Bestelllisten aus Vollständigkeitsgründen auf. Der NG UAVP hat mich nun schon gut 1500 Schweizer Franken gekostet, aber damit bin ich nun vorläufig an einem ende Angelangt. Man muss dazu auch sagen das einige Dinge nicht direkt mit dem NG UAVP zu tun haben (wie Messgerät um die 150€ bei Reichelt zu erreichen oder Ladegerät von Hobbyking). Der zweite NG UAVP wird also um einiges günstiger werden .

Qty	Bezeichnung	Bestellort	Einzelpreis	Total
1	ATMEGA644P-20AU	CSD	6.95	6.95	EUR
1	Elektromagn. Summer 5V	CSD	0.75	0.75	EUR
3	Mini-Taster 6×6 SMD 4,3mm	CSD	0.21	0.63	EUR
1	LPV Stiftleiste 3 polig gerade	CSD	0.07	0.07	EUR
2	LPV Stiftleiste 4 polig gerade	CSD	0.07	0.14	EUR
4	Wannenstecker 6pol winkel	CSD	0.25	1	EUR
1	Wannenstecker 6pol gerade	CSD	0.14	0.14	EUR
2	Wannenstecker 14pol gewinkelt	CSD	0.12	0.24	EUR
2	Wannenstecker 26pol gerade	CSD	0.12	0.24	EUR
1	ATMEGA328P-AU	CSD	3.79	3.79	EUR
1	LM1117IMP-3,3	CSD	1.25	1.25	EUR
2	Pfostenverbinder 14 polig *	CSD	0.14	0.28	EUR
6	Pfostenverbinder 6 polig	CSD	0.21	1.26	EUR
1	LPV Buchse 4 polig inkl. Kabel	CSD	0.37	0.37	EUR
1	LPV Buchse 3 polig inkl. Kabel	CSD	0.32	0.32	EUR
1	Flachbandkabel 14 pol gr.	CSD	1.89	1.89	EUR
10	Jumper schwarz Lasche	CSD	0.06	0.6	EUR
2	0805 KerKo 220 nF	CSD	0.05	0.1	EUR
3	0603 KerKo 3,3 nF	CSD	0.04	0.12	EUR
9	0603 KerKo 100 nF	CSD	0.04	0.36	EUR
1	Tantal 10µF 10V -A-	CSD	0.17	0.17	EUR
3	Pfostenverbinder 10 polig *	CSD	0.06	0.18	EUR
	Shipping			3.59	EUR
	Paypal			1.00	EUR
			Total:	40.70	CHF
1	ACCELEROMETER 3 ACHSEN QFPN-28	Farnell	23.15	23.15	CHF
2	TRANSLATOR, 8 CH, 15KV ESD, 3002	Farnell	7.40	14.80	CHF
1	POWER MODULE, MINI, 18V WIDE ADJ	Farnell	15.50	15.50	CHF
1	MOSFET, P, 20V, SO-8	Farnell	3.30	3.30	CHF
5	DIODE, TVS, 18V, 600W, SMB	Farnell	0.59	2.97	CHF
10	DIODE, TVS SMB 3,3V	Farnell	0.86	8.58	CHF
5	MULTIFUSE, RADIAL, 0.3A, 72V	Farnell	0.44	2.18	CHF
10	STECKERLEISTE MICRO SMT 90GRAD 4POL	Farnell	2.85	28.50	CHF
1	SENSOR, ABS PRESS 16.7PSI	Farnell	18.10	18.10	CHF
1	12BIT ADC, SMD, 7924, TSSOP16	Farnell	16.05	16.05	CHF
1	24BIT ADC, 30KSPS, SMD	Farnell	23.90	23.90	CHF
1	OPVERSTAERKER,DUAL CMOS RRI/O,SMD,2350	Farnell	6.50	6.50	CHF
1	OPVERSTAERKER,QUAD CMOS 3V,4350,SOIC14	Farnell	14.50	14.50	CHF
1	LOGIK, QUAD 2IN POS OR GTE, 14TSSOP	Farnell	0.37	0.37	CHF
5	MULTIFUSE, SMD, 1.50A	Farnell	1.15	5.75	CHF
1	CRYSTAL, HC-49/S, 7.68MHZ	Farnell	3.80	3.80	CHF
10	WIDERSTAND, 0805, 10K	Farnell	1.55	15.50	CHF
11	KONDENSATOR, BAUFORM A, 10UF, 10V	Farnell	1.35	14.85	CHF
1	LEITUNG KABELBUCHSE/KABELBUCHSE 150MM	Farnell	21.30	21.30	CHF
10	CRIMPGEHAUESE 4POLIG FUER KABELMONTAGE	Farnell	0.41	4.07	CHF
1	Shipping		15.00	15.00	CHF
1	MWST			19.66	CHF
			Total:	278.32	CHF
1	Transistor NPN TO-92 45V 0,5A 0,625W *	Reichelt	0.04	0.04	EUR
1	D-SUB-Buchse, 9-polig, Lötkelch *	Reichelt	0.12	0.12	EUR
1	Kurzschlussbrücke, rot, RM 2,54, vergoldet *	Reichelt	0.05	0.05	EUR
1	LED, 3mm, Low Cost, grün *	Reichelt	0.07	0.07	EUR
1	RS232-Driver, DIL-16 *	Reichelt	0.39	0.39	EUR
1	Metallschichtwiderstand 1,00 K-Ohm *	Reichelt	0.08	0.08	EUR
1	Widerstands-Netzwerk, 4Wid./8Pins, 4,7 K-Ohm *	Reichelt	0.14	0.14	EUR
1	2×17pol.-Stiftleiste, gerade, RM 2,54 *	Reichelt	0.11	0.11	EUR
4	Vielschicht-Keramikkondensator 100N, 10% *	Reichelt	0.04	0.16	EUR
2	Zener-Diode 1,3W 5,1V *	Reichelt	0.07	0.14	EUR
2	Philips I²C-Bus Microcontroller & Peripherie	Reichelt	2.85	5.7	EUR
2	Low Drop Out-Regler SO-8	Reichelt	2.65	5.3	EUR
5	Transistor SMD NPN SOT-23 45V 0,5A 0,25W	Reichelt	0.04	0.2	EUR
1	Gleichrichterdiode SMD, DO213AB, 50V, 1A	Reichelt	0.05	0.05	EUR
1	Temperatur-Sensor, SO-8	Reichelt	1.05	1.05	EUR
1	CHIP-Leuchtdioden, Bauform G0805, grün	Reichelt	0.08	0.08	EUR
1	CHIP-Leuchtdioden, Bauform G0805, rot	Reichelt	0.08	0.08	EUR
1	CHIP-Leuchtdioden, Bauform G0805, blau	Reichelt	0.26	0.26	EUR
1	Fotowiderstand	Reichelt	1.75	1.75	EUR
1	SMD-Quarz, Grundton, 20,000000 MHz	Reichelt	0.24	0.24	EUR
1	Standardquarz, Grundton, 20,0 MHz	Reichelt	0.18	0.18	EUR
1	SMD-Induktivität, Murata Chip Coil, 10µ	Reichelt	0.13	0.13	EUR
2	SMD-Power-Induktivität, PIS2408, Ferrit, 47µ	Reichelt	0.73	1.46	EUR
1	SMD-Chip-Widerstand, Bauform 0805, 10 Ohm	Reichelt	0.1	0.1	EUR
14	SMD-Chip-Widerstand, Bauform 0805, 100 Ohm	Reichelt	0.1	1.15	EUR
6	SMD-Chip-Widerstand, Bauform 0805, 330 Ohm	Reichelt	0.1	0.62	EUR
6	SMD-Chip-Widerstand, Bauform 0805, 470 Ohm	Reichelt	0.1	0.62	EUR
5	SMD-Chip-Widerstand, Bauform 0805, 1,0 K-Ohm	Reichelt	0.1	0.52	EUR
4	SMD-Chip-Widerstand, Bauform 0805, 1,8 K-Ohm	Reichelt	0.1	0.41	EUR
1	SMD-Chip-Widerstand, Bauform 0805, 2,2 K-Ohm	Reichelt	0.1	0.1	EUR
1	SMD-Chip-Widerstand, Bauform 0805, 4,7 K-Ohm	Reichelt	0.1	0.1	EUR
9	SMD-Chip-Widerstand, Bauform 0805, 10 K-Ohm	Reichelt	0.1	0.93	EUR
2	SMD-Chip-Widerstand, Bauform 0805, 12 K-Ohm	Reichelt	0.1	0.21	EUR
9	SMD-Chip-Widerstand, Bauform 0805, 15 K-Ohm	Reichelt	0.1	0.93	EUR
4	SMD-Chip-Widerstand, Bauform 0805, 10 M-Ohm	Reichelt	0.1	0.41	EUR
2	SMD-Widerstandsnetzwerk, 1206, 47 Ohm	Reichelt	0.02	0.04	EUR
2	SMD-Vielschicht-Keramikkondensator 15P, 5%	Reichelt	0.05	0.1	EUR
4	SMD-Vielschicht-Keramikkondensator 22P, 5%	Reichelt	0.05	0.2	EUR
4	SMD-Vielschicht-Keramikkondensator 100P, 5%	Reichelt	0.05	0.2	EUR
2	SMD-Vielschicht-Keramikkondensator 10N, 10%	Reichelt	0.05	0.1	EUR
47	SMD-Vielschicht-Keramikkondensator 100N, 10%	Reichelt	0.05	2.35	EUR
5	SMD-Tantal-Kondensator, 1,0µF/16V	Reichelt	0.05	0.25	EUR
1	SMD-Chip Elko, 10µF/35Volt	Reichelt	0.07	0.07	EUR
2	SMD-Chip Elko, 100µF/16Volt	Reichelt	0.08	0.16	EUR
2	Elektrolytkondensator, 6,3×11mm, RM 2,5mm	Reichelt	0.04	0.08	EUR
2	Elektrolytkondensator, 8×11,5mm, RM 3,5mm	Reichelt	0.03	0.06	EUR
1	Miniatur-Federleiste, Print, gerade, 2x 7-polig	Reichelt	0.34	0.34	EUR
2	40pol. Stiftleiste, gerade, RM 2,54	Reichelt	0.14	0.28	EUR
1	PeakTech 3360 – Digital-Mul	Reichelt	79.85	79.85	EUR
1	WELLER-Lötstation, regelbar	Reichelt	59.85	59.85	EUR
1	Shipping	Reichelt	28.56	28.56	EUR
			Total:	314.2	CHF
1	UAVP-NG 1x Acc Breakout PCB (LIS3LV02DQ)	NG UAVP	1.00	1.00	EUR
1	UAVP-NG HW-0.22 PCB (FC + SB)	NG UAVP	20.00	20.00	EUR
1	UAVP-NG 3x Gyro Breakout PCB (MLX90609-R2)	NG UAVP	3.00	3.00	EUR
1	Shipping	NG UAVP	4.00	4.00	EUR
1	MWST	NG UAVP	1.80	1.80	EUR
			Total:	47.68	CHF

Da die Boards sozusagen freigegeben sind habe ich zwei Bestellungen aufgegeben, eine bei Sparkfun und eine bei embedded projects GmbH. Der ARM7 CPU LPC2148 (das rote Board welches auf die Flight-Controll gesteckt wird, der Haupt-CPU) war bei Sparkfun nicht an Lager. Ich habe diesen deshalb bei embedded projects bestellt. Der Accelerometer LIS3LV02DQ war bei Sparkfun leider auch nicht mehr vorhanden, der bereits gelötete Sensor auf einem Breakout-Board jedoch schon. Da ich diesen jedoch selber löten möchte und etwas Geld sparen werde, wird dieser erst später bei Farnell gekauft, wo er noch ohne Breakout-Board erhältlich ist.

Zudem habe ich ein Venus GPS-Modul gekauft welches eine Aktualisierungsrate von bis zu 10Hz erreicht. Der NG UAVP kann mit den GPS Daten heutzutage noch nicht viel anfangen, ein GPS-Modul ist auch nicht in der offiziellen Stückliste zu finden. Jedoch ist mein Ziel bei der Entwicklung von GPS Funktionen mitzuwirken, weshalb ein GPS unabdingbar sein wird.

Das GPS-Modul wird per UART angeschlossen und kann daher direkt mit dem ARM7 verbunden werden. Optional könnte auch I2C verwendet werden, allerdings würde dies nicht ohne Codeanpassungen beim NG UAVP funktionieren…

Die Liste der Bestellungen wurde daher auch wieder etwas grösser:

Qty	Bezeichnung	Bestellort	Einzelpreis	Total
1	LPC2148 ARM Adapterplatine (LPC-H2148)	embedded projects	33.53	33.53	EUR
1	Shipping	embedded projects	3.32	3.32	EUR
			Total	58.96	CHF
3	Single Axis MEMs Gyroscope – MLX90609-R2	Sparkfun	39.95	119.85	USD
1	MicroMag 3-Axis Magnetometer	Sparkfun	59.95	59.95	USD
1	Venus GPS with SMA Connector	Sparkfun	49.95	49.95	USD
1	Antenna GPS Embedded SMA	Sparkfun	11.95	11.95	USD
1	Shipping	Sparkfun	33.03	33.03	USD
			Total	302.20	CHF

Viele Neuigkeiten um Weihnachten: Bei mir sind inzwischen alle Voraussetzungen eingetroffen. Zudem habe ich gehört, dass die Boards am 26C3-Kongress verfügbar sein werden . Nur leider kann ich da nicht Teilnehmen. Aber direkt nach dem Kongress soll der Shop eröffnet werden, so dass ich schon bald mein Exemplar des 0.22 Boards in den Händen halten werden! Zudem wurde die Bauteilliste freigegeben (jedenfalls inoffiziell), so dass der Bestellung derer nichts mehr im Wege steht!

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.

Aller Anfang ist schwer. Das gilt auch in der Quadrokopter Community. Ich habe mich am Anfang ziemlich schwer getan mit all den Begriffen und Abkürzungen wie MK, BC, FC oder SB. Vieles findet man irgendwo in der Doku, für Einsteiger ist es jedoch recht verwirrend, da man gar nicht weiss wonach man suchen soll… Deshalb habe ich mir ein Glossar geschrieben! Um auf dem laufenden zu bleiben bin ich auch häufig (naja, vieleicht nicht ganz so häufig wie ich mir das wünsche ) im IRC-Channel des NG UAVP-Projekts. Viele der Entwickler sind dort anzutreffen und diskutieren über Neuigkeiten und Probleme. So bleibe ich am Puls des Projekts und erfahre die Neuigkeiten am schnellsten.

Inzwischen ist die Hardware in der Version 0.22 angekommen. Jedoch muss noch überprüft werden, ob diese einwandfrei laufen. Danach sollten diese über die Webseite bestellbar sein.
Seit dem letzten Blog-Beitrag habe ich die Voraussetzungen beschafft. Leider bin ich noch nicht zum Bau des Rahmens gekommen, aber auch die Einzelteile zu beschaffen haben mich stark beschäftigt. Da ich noch nichts in Sachen RC für den Multicopter besass, musste ich einiges neu beschaffen. Ich habe mir deshalb eine Liste erstellt was ich alles beschaffen muss und wo ich das tun werde. Als Anhaltspunkte welche Brushless-Controller, welche Motoren oder welche Rotoren ich verwenden sollen half mir die User-Copters-Seite und persönliche Beratung im IRC-Channel weiter.

Qty	Bezeichnung	Bestellort	Preis	Total
2	CenterPlate	Flyinghigh	8.60	17.20	CHF
3	Propellerpaar EPP1045	Flyinghigh	5.70	17.10	CHF
1	ACT DSL-4top (40 MHz) Typ: MK	Flyinghigh	65.60	65.60	CHF
1	SerCon (RS232-TTL & SI-PROG)	Flyinghigh	7.85	7.85	CHF
1	Shipping	Flyinghigh	9.50	9.50
			Total	117.25	CHF
5	TURNIGY 28-30-azj	HobbyKing	7.99	39.95	USD
5	TowerPro w25A	HobbyKing	11.75	58.75	USD
1	Turnigy 4000mAh 3S 30C Lipo Pack	HobbyKing	35.69	35.69	USD
1	GT A-6-10 200W Balance charger & discharger	HobbyKing	67.95	67.95	USD
1	HobbyKing Super Glue CA (50g / 1.7oz) Thick	HobbyKing	2.49	2.49	USD
1	HobbyKing Super Glue CA (50g / 1.7oz) Medium	HobbyKing	2.49	2.49	USD
1	Shipping	HobbyKing	10.00	49.07	USD
			Total	264.52	CHF
1	Graupner Fernsteuerung MX 12 mit Empfänger	Ricardo	164.00	164.00	CHF
1	Shipping		8.00	8.00	CHF
			Total	172.00	CHF

Einiges der Hardware ist bereits angekommen. Ich werde in den nächsten Tagen über die wichtigsten Einzelteile berichten.
In der nächsten Woche wird das NG UAVP-Team am 263C-Kongress in Berlin sein. Ich hoffe dass sich die 0.22-Boards dort definitiv als Funktionstüchtig bewähren, sodass dem Verkauf nichts mehr im Weg steht. Leider kann ich das Team nicht besuchen, da ich bereits anderes in dieser Zeit geplant habe .

Schon seit Jahren träume ich davon RC-Modellflugzeuge zu steuern. Vor einigen Jahren hab ich mir diesen Wunsch auch erfüllt, und ein Graupner Trainer 400 gekauft. Nach dem Zusammenbau war er bereits nach wenigen Flugstunden wieder in Einzelteile zerlegt. Seither hatte ich keine Lust mehr, soviel Aufwand in solch kurze vergnügen zu investieren. Zudem benötigen Modellflugzeugen viele äussere Parameter die passen müssen: Wetter, vor allem der Wind, Start- und Landeplatz sowie massig freien Luftraum.  Helikopter sind da etwas weniger anspruchsvoll, dafür um so schwieriger zu fliegen und deutlich teurer. Beide RC-Fluggeräte bestehen hauptsächlich aus Mechanik und Elektronik. Für mich als Programmierer keine nahe liegende Bereiche.Vor etwa 3 Jahren hat sich eine neues RC-Modell-Fluggerät hervorgetan: Quadrokopter oder auch Multikopter, da es heute auch solche Fluggeräte mit mehr als vier Rotoren gibt. Ein Quadrokopter besteht üblicherweise aus vier mit Elektromotoren angetriebene Rotoren (wovon je zwei in eine Richtung rotieren), einem Gestell, einer Batterie sowie einer Steuerung. Nur dank dieser Steuerung ist es möglich, das der Quadrokopter ruhig in der Luft fliegen kann. Diese Steuerung wird mit Mikrokontrollern realisiert, wofür es entsprechende Software benötigt. Also auch ein Bereich der für mich als Programmierer naheliegt.

Nachdem ich nun mein Informatikstudium abgeschlossen habe, entschied ich mich in die Welt der Quadrokopter einzutauchen. Mein jüngerer Bruder, welcher gerne mit Elektronik bastelt, hat mir seine Hilfe zugesagt, um einen Quadrokopter zu bauen. Er besitzt auch eine Elektronikausrüstung (Lötkolben, Messgeräte, Labornetzteil etc.) und bastelt gerne damit, sodass wir uns perfekt ergänzen . Es gibt verschiedene Projekte welche Quadrokopter realisieren, wobei mir vor allem der Open-Source-Gedanke wichtig war. Ich habe mich deshalb entschieden einen NG UAVP zu realisieren. NG UAVP steht für Next Generation Universal Aerial Video Platform. Dabei geht es darum den etwas in die Jahre gekommene UAVP mit einer neuen Architektur zu versehen. Das Projekt steht zurzeit (Dezember 2009) noch in der Entwicklungsphase, ideal um etwas beisteuern zu können.

Dieses Blog soll den Aufbau des NG UAVP Quadrokopters dokumentieren. Angefangen von der Bestellung der Komponenten, über den Zusammenbau, bis zum Erstflug und der Weiterentwicklung. Viel Spass beim Lesen…

Hi everyone,

It seems I only find time to blog about the NG when new hardware arrives! You will find more about the new hardware below.

At first, I would like to tell your what happened since my last post from mid sommer! We were busy developing the NGOS further and we succeeded in supporting most parts of the hardware!

This means our RC-Controller now has control over the two DSL inputs and the sum-signal input. This also means we are now fully supporting up to 4 DSL receivers and two times sum-signal input for RC control. This will allow all forms of diversity, teacher/student as well as channel extension up to 4 times the number of channels you normally may have.

Furthermore the new RC-Controller firmware receives attitude data from the Flight Control's Kalman filters and uses it to do Servo Attitude Compensation for Pitch and Roll.

We implemented two servo operation modes, one where servo attitude compensation is done on servo 1+2 and servos 3-5 are available for other things, and another where the Flight Control has full control over all 5 servo channels. This will allow us to implement different Hardware Abstraction Layers (HALs) which not only use I2C actors but also those needing servo control like airplanes and helicopters.

Our SB-Controller firmware was completed as well. It now supports the MicroMag3 3-axis magnetic compass. To do that, it receives regularly attitude data from the Flight Control, uses it to do compass attitude compensation and then delivers the result to the Flight Control.

Looking at the device table on the Flight Control we now see this:

# show devices

Detected devices:

  Addr  Bus     Description

  0x16  I2C0    Atmel 644P RC/Comm Controller
  0x18  I2C0    Atmel 328P SB Controller
  0x02  ADC12   ADXR/MLX MEMS Gyroscope 12bit (nick)
  0x01  ADC12   ADXR/MLX MEMS Gyroscope 12bit (roll)
  0x00  ADC12   ADXR/MLX MEMS Gyroscope 12bit (yaw)
  0x00  SPI0    LIS3LV02DQ 3-Axis Accelerometer
  0x02  SPI0    ADS1255 24bit Analog Digital Converter
  0x03  SPI0    AD7924 12bit Analog Digital Converter
  0x00  SBCTRL  MicroMag 3 Magnetic Compass
  0x01  RCCTRL  ACT DSL Receiver 0
  0x02  RCCTRL  ACT DSL Receiver 1

As you can see all our newly supported devices pop up, even those attached to peripherial CPUs. I had no actors attached, so it's normal that they do not show up.

These peripherial CPUs implement a new protocol called NGPP - The NG Peripherial Protocol.

NGPP represents a register based store/load framework allowing direct memory access on the slave devices. It's possible to implement it on most physical character based interfaces, which allowed us to implement it on top of I2C and which will allow us to use it on other serial devices like the UART. Those of you knowing the MODBUS protocol will recognize a lot of similarities.

NGPP is able to issue several read/write requests within one cycle. It's also able to read or write multiple sequential registers in one request allowing for a very efficient data transfer between slave device and host. Currently the NGPP implementation is built on top of our I2C physical layer, which by itself is a task based framework able to run several "state machine tasks" sequentially allowing NGPP to queue requests and get notified when the finish.

The RC-Controller as well as the SB-Controller both use the NGPP a lot to transfer data between slave and host devices several times per cycle.

Current RC- and SB-Controller NGPP statistics look like this:

    NGPP RCctrl read:      16 ticks/100 cycle   (max:   17, ngpp overrun 0)
    NGPP RCctrl write:      5 ticks/100 cycle   (max:    6, ngpp overrun 0)
    NGPP RCctrl read:      66 bytes/100 cycle   (max:   76)
    NGPP RCctrl write:     41 bytes/100 cycle   (max:   45)

    NGPP SBctrl read:       6 ticks/100 cycle   (max:    7, ngpp overrun 0)
    NGPP SBctrl write:      5 ticks/100 cycle   (max:    6, ngpp overrun 0)
    NGPP SBctrl read:      11 bytes/100 cycle   (max:   13)
    NGPP SBctrl write:     31 bytes/100 cycle   (max:   36)

As you can read from the above statistics data, we have no problems in transfering the needed amount of data. Since NGPP requests can be issued during the whole closed-loop cycle as well as from any user space context (meaning the shells and their associated processes) we are free to model our code according to our needs.

We can access the registers directly from any Flight Control shell:

# show ngpp sbctrl

NGPP sb-ctrl registers:

  sb.devices          1
  sb.nick            57
  sb.roll           -35
  sb.mag.x          -67
  sb.mag.y           21
  sb.mag.z          335
  sb.heading       3164
  sb.test1           42
  sb.test2           43

And set them directly if they have a read-write flag:

# set sb.test1 44

NGPP: wrote sb-ctrl register 7 value:     44

To demonstrate the cooperation of the three CPUs in our distributed system, I made a small movie showing Servo Attitude Compensation:

UAVP NG - The OS Multicopter: Servo Attitude Compensation from Amir Guindehi on Vimeo.

After having implemented support for most hardware devices on the new NG, our hardware developers also produced a new revision of the NG PCB boards.

The newest revision is called HW-0.22 and is a pure bug fix revision as all 0.2x versions were. The next feature revision will be HW-0.30 on which brainstorming and work already has begun.

We received the new boards today!

Here are the first pictures of the new HW-0.22:

Opening the packet and looking inside it seems that the boards look fine:

We also received a separate panel containing the 7 breakout boards which we will include with each HW-0.22 board!

We now have six accompanying MLX and ADXR610 gyro breakout boards (three of each) as well as a LISL breakout board:

A set of these 7 breakout boards will be included with each FC+SB PCB set.

We will start to investigate the new hardware and should everything be in order, we will release them to the broad public. Be sure to check our homepage in the next days.

We will open up the new UAVP-NG Shop soon!

Stay tuned!

I should blog about our new Hardware Abstraction Layer for a long time now and having written an article about the new HW-0.21 just before, I decided not to stop and to describe our new feature just now.

As you all know, Multikopter get built in all different forms and sizes. Trough one problem remains: As soon as you change the motor / propeller geometry, you have to change the closed-loop control to incooperate the new dimensions and positions of your motors and propellers.

This is about to change!

The new NGOS essentially partitions closed-loop control and physical motor / propeller geometry. That means that the output of the controller code in the NGOS no longer contains direct motor actor values but only corrections on pitch, roll and yaw axes. A new API layer called HAL (hardware abstraction layer) encapsulates the physical motor / propeller configuration. The API layer is kept very simple and essentially implements how a correction on a corresponding axis has to be executed by the motors.

The current NGOS implements HAL as abstract modules separate for the controller code. So essentially all controllers can be flown with all HALs.

We currently have implemented the following HALs:

• Quadcopter HAL
  Essentially the good old quadcopter you all know and love
• QuadcopterX HAL
  The good old quadcopter turned by 45 degrees to fly in X-Mode
• QuadcopterR HAL
  The normal quadcopter HAL, just in reverse
• Y6 HAL
  The Y6 HAL to fly Tri-Coaxial multicopters

Arbitrary new HALs can be implemented by adding a simple HAL module containg two simple functions to the source code.

On the NGOS side of things this looks like this:

# show hal

Current HAL: quadcopter

    HAL Id:                    1
    HAL Description:           The classical 4 rotor QuadCopter HAL
    HAL Quality:               proven

    Needed number of actors:   4
    Detected number of actors: 4

    Motor 1: front
    Motor 2: back
    Motor 3: right
    Motor 4: left

Description:

This is the classical 4 rotor (non-cross) QuadCopter HAL. It allows
to fly a classical QuadCopter with a front, back, left and right motor.

Current HAL configuration:

  HW.HAL     quadcopter          HW abstraction layer

Switching to a Y6-HAL is as simple as entering the command "set HW.HAL Y6", which I did for this demonstration. This results in the following output on inspection:

# show hal

Current HAL: Y6

    HAL Id:                    4
    HAL Description:           The Y6 Hexakopter HAL
    HAL Quality:               flying

    Needed number of actors:   6
    Detected number of actors: 4

    Motor 1: front-left_up
    Motor 2: front-right-up
    Motor 3: back-up
    Motor 4: front-left-down
    Motor 5: front-right-down
    Motor 6: back-down

Description:

This is the new Y6 HAL in normal mode. It allows to fly a Y6 hexacopter.
You need to attach front-left up/down, front-right up/down and back up/down motors.

Current HAL configuration:

  HW.HAL              Y6                  HW abstraction layer

  HAL.fact.top        1.00000000          Throttle factor for top layer
  HAL.fact.bottom     1.10000000          Throttle factor for bottom layer

As you can see, every HAL describes how their actors how to be mounted, what the actor addesses are, how many of them there have to be and how many of them have been detected. The NGOS won't let you start the actors if there have not been detected enough actors for the current HAL. Every HAL can have HAL-dependant parameters. As you can see above the Y6-HAL defines two parameters which allow the user to define the throttle factors for the lower and upper prop-layer.

I think I forgot to mention till now that we can switch between different HALs in-flight? Yes, it's true! Since the HALs are totaly independant from the closed-loop controllers, we are able to change them using behavior rules whenever we like.

You don't belive me? Then check out the following small movies...

In this first movie, I switch between the normal Quadcopter-HAL and the QuacopterX-HAL (x-mode) while flying:

UAVP-NG - The OS Multicopter: In-Flight switch between +-Mode and x-Mode from Amir Guindehi on Vimeo.

In the next movie I switch between the normal Quadcopter-HAL and the QuadcopterR-HAL (reverse-mode) while flying:

UAVP-NG - The OS Multicopter: In-Flight switch between +-Mode and Reverse-Mode from Amir Guindehi on Vimeo.

In this last movie Markus, a friend of mine, demonstrates his new Y6-NG flying using the Y6-HAL he implemented (and I have to mention: He's no programmer himself!):

MY new NG.Y6 from MarkusBec on Vimeo.

As you can see the new HAL concept performs very well and seems capable of implementing very different HALs. I imagine we could have a Helicopter-HAL or even a Robot-HAL! Current HALs are able to use up to 16 actors.

I will tell you more about other features in my next blog entry...

Sorry guys, I never found the time to update my blog with the newest developments!

Hopefully this will change again...

It's time to revive this blog!

There was a lot of stuff going on behind the scenes. Our hardware developers designed the next hardware revision 0.21. And our software developers extended the NGOS in the meantime with a lot of new features like a Hardware Abstraction Layer (HAL) to support arbitrary propeller configurations and up to 16 motors, PT1 compensation, a new framework for our peripherial processors, the NG Peripherial Protocol (NGPP) and more. I will write separate blog entries in the near future describing them...

Anyway... today's News is: The new hardware 0.21 has arrived!

These hopefully will be the final prototypes which - when everything checks out - will then be produced for the masses.

Here are some first pictures of the packet I received today...

The boards look great!

We will test them out ASAP and order more if they perform to our expectations...
... expect the new hardware available to the public within several weeks!

We are back from the 25c3 - The 25. Chaos Computer Club Congress in Berlin.

This years CCC Congress took place in Berlin at the BCC Congress Center from december 27 to 30. Some of the NG developers joined the congress to present our project's work and to meet in person for a developer meeting with a lot of hacking, talk and fun.

Besides the NG project folks from the MK project as well as folks from Motodrone were at the congress. I will tell you more about this further on.

Axis de-coupling

In the last days before the congress we finally found the time to look into axis decoupling.

Having had a big discussion with Tensor, a bright guy also hacking on IMU algorithms, who confirmed that my formulas were correct and who even showed me a new way to calculate them without hitting the poles of the formulas, I implemented the no-poles solution as well as the solution with poles in my NG controller. Short test flights in my living room showed no degradation in normal hoovering flight and further tests showed the big improvements the formulas brought with them.

Taarek and I did three small movies to demonstrate the new behavior!

The test is quite simple: Taarek shakes the NG around multiple axises at the same time and he does this using large angles. This makes sure that the integration without axis de-coupling will misbehave and the NG suddenly does no longer know where it's horizontal position is. After a while of forceful shaking Taarek let's the NG free so that it can take the position it thinks is horizontal. That's the moment one is able to see very good what the NG thinks to be horizontal.

In the first test, without axis de-coupling activated you see the error very well. Furthermore you see how the Kalman filter corrects the quite heavy error within some seconds. That's one of the reasons we fix this so late...

Wolferl-NG: HW-0.20 with NO axis decoupling from Amir on Vimeo.

In the following second and third test, we switched the axis de-coupling on. As you can see there is no visible error anymore.

Wolferl-NG: HW-0.20 with ACTIVATED axis decoupling - part I from Amir on Vimeo.

In the following third test Taarek shakes the NG a while longer.

Wolferl-NG: HW-0.20 with ACTIVATED axis decoupling - part II from Amir on Vimeo.

As you can see, this works out very well!

25c3 flights

We did several test flights in the living room (outside it's simply to cold) and it all performed well, so we did our flights at the 25c3 all with activated axis de-coupling.

He's one of them, where I test our new kernel concept we implemented:

UAVP-NG: 25c3 - CCC Congress in Berlin - OS Multicopter from Amir on Vimeo.

Here's another 25c3 movie showing some flights our friends of the MK team did. I wouldn't let you miss those flights! Some of the MK pilots are very good and show off in the big conference room. The movie was created by Ingo (der_oschni) who seems to have missed everything pointing to the NG project. Can you spot us? ;)

25C3 - CCC Mikrokopter in Berlin from der oschni on Vimeo.

All in all it was a very cool congress (as every year) with a lot of progress, talk and networking. Besides testing the new axis de-coupling one of our developers started digging the deeper magic of the ARM RISC CPU.

User, System and IRQ mode: We have a real kernel now!

Axel, as every year searching for a topic he can solve at the 25c3 investigated our sensor and actor busses using his logic analyzer. In the progress of that, he discovered something which we were all aware of, but which started to bitch us as soon as we saw it printed on the screen!

Up to then our closed-loop control worked inside a timer interrupt. Because that and because we do not do nested interrupts, all other operations cease to function until the closed-loop step has finished. This is not the best behavior in a system where Input/Output is only lightly coupled with processing. We specially want to use the ability to continue acquiring sensor data and to output actor control commands while we calculate the next step of the closed-loop control.

One of the solutions to that would be to use nested interrupts. Digging the internals of the ARM RISC CPU deeper, we remembered the different operating modes the ARM CPU can use! The ARM CPU has user, system as well as IRQ contexts. Privileged opcodes can't be used in user mode, which makes sure a user process will never switch uncontrolled to one of the other operating modes.

Having remembered these features we immediately saw the prefect solution: We move our non real time tasks into the user mode and let the timer interrupt, which executed our closed-loop control step until now, switch from IRQ to system context, enable nested interrupt and then execute the closed-loop control step. That way all interrupts are still able to interrupt the closed-loop control step! User context processes like our shells have to use system calls to get into the system context to use privileged opcodes.

Axel did great work and rewrote our NGOS through the 25c3 according to these ideas. We now have all the above implemented and looking at the sensor and actor busses it all works now a lot smother! Actors and sensors get accessed while the closed-loop control step takes place and so our output/input/process closed-loop control can operate lightly coupled together with the IO drivers.

As you can see in the above movie, the NG flew wonderful using these changes, through no immediate differences in flight behavior were visible... as expected it did not change much, to handle the 1ms tick smother since 1000Hz are enough anyway for the closed-loop control.

Exception handlers & crash logs

Being hacking all this low-level stuff Axel implemented exception handlers for all exceptions. We now store the exception data in non-resettable memory and do a reset. That way we are able to log into the NG and check the crash-data should there ever be a exception! This works wonderful as well.

Hardware Abstraction Layer

Since this blog article starts to get very long, I will elaborate in my next article on our new Hardware Abstraction Layer (HAL) which allows us to use up to 16 motors in arbitrary physical configurations.

In my last blog entry I presented our new HW-0.20 boards. Today I would like to show you our finished HW-0.20 prototype boards.

As you all know we were busy porting the NGOS from HW-0.10 to HW-0.20. A lot of design changes and new peripherals need to be supported while still being downward compatible to HW-0.10.

Being downward compatible allows us to release one HEX file for all existing hardware platforms. This is important since the planed Mini-NG will have a similar design as the HW-0.10. You don't need air pressure and GPS for mini Quads and Funflyers, so we will downsize the new design later on to a one-board design for fun flying.

The port of the NGOS is working fine and starts to support the new devices and different hardware platforms.

Here you can see how the NGOS detects the hardware platform it's running on:

# show version

Wolferl-NG, Version 0.42 pre-beta (non-public), Revision r2352

FC HW-ID:  FC-0.20
SB HW-ID:  SB-0.20

In the next section you can see how the NGOS probed for the available devices and then activated their associated drivers:

# show devices

Detected devices:

  Addr  Bus     Description

  0x02  ADC16   ADXRS MEMS Gyroscope 16bit (nick)
  0x03  ADC16   ADXRS MEMS Gyroscope 16bit (roll)
  0x00  ADC16   ADXRS MEMS Gyroscope 16bit (yaw)
  0x01  ADC16   ADXRS MEMS Temperature 16bit
  0x00  SPI0    LIS3LV02DQ 3-Axis Accelerometer
  0x02  SPI0    ADS1255 24bit Analog Digital Converter

As you can see, most of the new hardware gets already detected and used. The 16bit ADC does not yet show up in the device table (difficult to probe) but it's already getting used to sample the gyros.

The peripheral CPUs do not yet show eighter. Some of our developers are working hard on their firmware and we hope to integrate the peripheral CPUs soon. But there is no need to hurry with that. We are fully downward compatible and so we are able to fly even without support for the RC-controller or GPS-controller.

The new hardware was fully assembled in the meantime and it's current state looks like this:

Since most of the NGOS now is ported to the new hardware and the new peripherals are supported now, we started to build a full Quadcopter with the new HW-0.20.

The first fully assembled NG-0.20 looks like this:

Update:

Tonight we did the maiden flight of the new NG-0.20! Everything went according to plans and except for a small sign error which we fixed within minutes, it all worked very well!

But see for yourself:

Wolferl-NG: HW-0.20 is airborne! from Amir on Vimeo.

We will continue our test flights in the next days!

In my last article I introduced the new NG hardware 0.20 and showed first Gerber files of it. In the meanwhile our board producer was busy creating the new boards.

Today the first prototype boards have arrived! But see for yourself...

The panel packet:

The topside of the panel:

And the backside of the panel:

The boards look great! The next days will show how they perform!

You probably all wondered why there was so little news in the last weeks. One reason was that I was on holidays. I was off for a week to the Red Sea for diving. The second reason was that everyone was very busy in the last days and weeks.

Since there was a lot of progress, but no time to document it all, I will blog here about it, without going into too much detail.

Our hardware developers were busy all the time and fiddled with the last design changes of the new NG hardware. It includes numerous fixes and extensions! They did smashing work redesigning the hardware 0.20!

In essence it has become a 3 processor system using the LPC2148 as the main processor running the closed-loop control and having a Atmel 644p and a Atmel 168 as peripherial processors for preprocessing and communication purposes.The main CPU no longer does any measurements itself. It uses peripherial processors or external ADCs for that.

Besides 16bit ADC and new filters for the gyros, we included an air pressure sensor and a compass sensor in the new design. We will support ADXR and MLX gyros. The new hardware has 4 (or even 5) UARTs on different processors and will support the ACT DSL protocol on several of them. This will allow arbitrary ACT receivers (SPCM, PPM, 2.4Ghz) to work with the NG. Furthermore the UARTs will support the NMEA GPS protocoll besides the normal shell access and will allow to attach all sorts of NMEA compatible GPS to them.

In the last weeks our hardware developers cleaned up the new design and fixed the last bugs. They generated Gerber files and panelized them with the help of our board producer.

This week we finally were able to start production of our first alpha boards of the new hardware 0.20. If all goes well, we will receive the first prototypes within the next two weeks!

The above shows parts of the Gerber files of the two layer panel for the new hardware 0.20. It consists of a flight control board, a sensor board and four breakout boards for MLX gyros.

When we receive the new boards, the huge work of porting the old 0.10 software and writing new software for the additional processors can start.

Most of my spare time I spend with the development of Quadrocopters. About 1year ago I started a new project together with some other guys. It's called UAVP-NG. We have quite many targets for the future, actually too much to list all of them here - at least for the moment.

Since the beginning of this year we are airborne. That means we fulfilled our main target:)

Currently we are flying the first hardware revision. As usual, while doing new stuff, we found a couple of things to improve during the software development phase. For that reason we decided to start work on a 2nd hardware revision.
Two of my co-members are currently busy with finalizing the PCB routing of the sensor board and ARM7 flight controller. The new hardware will also make use of 2nd processor. Its job will be the handling of 2 or even 3 RC receivers to allow diversity, the control of up to 5 servos and maybe sending out IR-commands to fire a digital camera.
The picture below shows a prototype which I will use to write the necessary software before the new PCBs are ready. It only consists the parts needed for the functions described. The processor will later communicate via I2C with the main-processor.

I will let you know as soon as it is alive:)