Planet NG

Hi everyone,

Having been quite busy with work in the last few months I finally found time to write a new blog article about the latest developments in the UAVP-NG project.

In my last blog entry I announced that we will open the UAVP-NG shop soon, and so we did.

On the 26. December of 2009, the first day of the 26c3 - The 26. Chaos Computer Club Congress - we opened up the project's non-profit UAVP-NG shop to the public. We did not anticipate such a high demand and so we were sold out on the 13. January this year for two weeks... ;) We learned our lesson and increased our stock accordingly.

Having rolled out our hardware to the public we finally found time for some source code cleanup and further development.

End of January 2010 we released NGOS-0.55 with support for the VDRIVE2 and the new X8 and X8X coax HAL and the ng-tools source. End of March NGOS-0.56 which included a new test HAL called 'blc' to allow users to test single BLCs. In April NGOS-0.57 and NGOS-0.58 followed with rc-mode support, yaw stability improvements and a yaw filter. And finally, in June we released NGOS-0.59 which introduced the new native S3D 2.4Ghz support for the S3D receivers from ACT which Ralf and I implemented in spring.

In the meantime I pondered some new papers I've read on the DCM - The Direction Cosine Matrix and it's applications for UAVs. Several very smart folks wrote some heavy papers about the stuff and having read a lot about it in the last months I decided to try to implement a new DCM based controller, which I called amir-ng.

The basic idea of a DCM controller is to remember the attitude and orientation not by using 3 euler angles, but by using a DCM - a direction cosine matrix.

It's one of the 3 often used methods to remember attitude and orientation. Besides Euler angles and a DCM there are Quaternions to do the same. Mathematically a DCM and Quaternions can be shown to be identical except for the number of storage needed and some differences in mathematical complexity. Quaternions use 4 variables to describe the state, a DCM uses 9 variables, of which 4 are free.

The DCM essentially consists of the 3 axis vectors of the two involved coordinate systems, seen from each other. It will store the attitude and orientation, but needs to be corrected for mathematical deformation and for drift effects happening by the gyro integration and errors introduced.

This drift correction of a DCM can be done in different ways, similar to the Euler case, where you can use different Kalman filters or complementary filters to do the job of fusing acc and gyro information.

Contrary to Euler angles the DCM's state space resides in the SO(3) Manifold - the special orthogonal group of rotation - and there, the rotation problem is linear! This has several important implications...

As you probably know a linear Kalman filter is a optimal solution if, and only if, the problem is linear. Otherwise you have to resort to an extended Kalman, which tries to linearise the curve at the point of interest by using a first order Taylor approximation or similar solutions which essentially work, but also inherently fail to be optimal, by their way of working (eg. a first order Taylor approximation simply no longer is optimal).

So essentially you can't get a optimal solution using Euler angles. And the Euler angles singularities always will irritate you... *g*

Now guess what happens if we look at the problem in SO(3). As a rotation is a linear operation here, we can apply a simple linear Kalman filter to the problem and get an optimal solution. This is very helpful as a linear Kalman filter is implemented much more easily than an extended one.

So using three single linear Kalman filters to guess the drift compensation in SO(3) results in an optimal solution and I tried to implement this in the amir-ng controller.

The result seems to come out quite satisfying! Take a look for yourself on the following short movie showing the maidenflight of the DCM controller with Kalman drift compensation:

UAVP-NG - The OS Multicopter: DCM Maidenflight from Amir Guindehi on Vimeo.

Parallel to my work on the new controller, Stefan finished cleaning up the compass support on the SBCTRL side. While he was working on implementing compass and GPS support in the older amir controller, I decided to implement GPS and compass support in the amir-ng controller. This made sense as the application of the compass heading for drift compensation is different in the two controllers. Instad of using a heading over ground derrived from GPS measurements as used in many DCM implementations, we use the attitude compensated compass measurement for yaw drift compensation in the amir-ng controller.

Having implemented yaw drift compensation using a compass, GPS navigation suddenly was very easy to archive. As a DCM contains the coordinate axes of the two involed coordinate systems, it's very easy to compute heading deviations and courses. It's simply vector geometry...

Realizing that, a simple GPS Position Hold algorithm was hammered together and tested out, some weeks ago! This was the first successful test on the 24. June of 2010:

UAVP-NG - The OS Multicopter: First GPS Position Hold Flight from Amir Guindehi on Vimeo.

Again we use 3 linear Kalman filters to fuse acc accelerations and GPS position.

Having realized a first PH flight, we started preparations for the 3. UAVP-NG Multicopter and Developer Meeting here in Zurich, Switzerland.

It took place on the 9. - 11. July of 2010. Here's some footage on the event... I think we never had so many different NG flight controls in one place... :)

UAVP-NG - 3. Developer Meeting in Zuerich on the 9/10/11. July 2010 on Picasa

Rob's movie:

3. NG Developer Treffen from Rob Robot on Vimeo.

And Ygramul's movie:

NG Treff 2010 in Zürich from Ygramul on Vimeo.

I would like to thank all visitors for coming by! It was a lot of fun, as always!

So, I hope I got all the News out... ;)

Last but not least I was 2 weeks on diving holidays, but I will write another blog entry about that... :D

Cheers!
- Amir

The last days I worked a lot on my second NG UAVP quadrocopter. I had many of the parts ready since weeks. But I decided to do some things different than planned. But in between, all things were done and it was time to get my new aircraft airborne. And it flew! Unfortunately I had some interferences, but look yourself!

The second quadrocopter is a lot easier to build. The whole world of quadrocopter and radio controlled model making in general was very new to me. I made wrong decisions or just didn’t know how I want to have it in the end… Here is a small lists of improvements I made on my second quadrocopter. It might help other beginners to do it better in first place

Battery connectors

On my first copter I bought the same connectors for the quadrocopter which the batteries had: 4mm Bullet connectors. But connecting them was dreadfully: My connectors were a little bit to big, so I had to deform the plastic of the connectors a little bit. The plastic on the front was battered. Connecting them was very tough, in the end I didn’t connected them fully, it simply wasn’t possible anymore. So it was time to switch. I decided to use the XT60 connectors from Hobbyking (an alternative to the popular Deans connector system). They are cheap and you can also buy batteries with this connectors. The connection holds strong but you can connect and disconnect them without problem. No more half connected plugs in the air.

Power distribution

Using a board to distribute the power is definitely more comfortable, especially if want to connect something new or disconnect something. I used a two-sided 70µm copper bare board. Don’t forget to remove the coat before soldering if it has one. You also should have a soldering iron with enough power doing this. My 40W soldering iron was definitely a bit too feeble. Another good tip is to use silicon cable whenever possible. Its easier to solder them because the cable coating doesn’t melt.

Landers and centerplate

Having good landers from start is also very convenient. Starting from grass is no problem, calibrating the acceleration sensor is easier too. I already wrote about my new centerplates. They look good and are very strong.

LED’s

Its easier to distinguish the front of the quadrocopter with colored LED’s. I planned to add LED’s to my first copter already, but because the power distribution was inflexible I desisted installing them. On my second copter I bought 3mm plugs to connect them, and also added a cable to the power distribution system.

Recently I bought the nice GoPro HD digital camera. This week I mounted it the first time on my quadrocopter and flew around with it. But with the last battery the motor dissolved itself from its basement. Luckily my quadrocopter and the camera survived the crash without serious damage.

By the way, I made this video using PiTiVi, which seems to evolve to a very easy to use video editor. The features are a bit limited at the moment, but there is much effort in the community improve this drawback.
I’m still working on my second quadrocopter. I decided to solve the current distribution better than I did at my first quadrocopter. I going to use a blank board with 70µm copper on each side. Each side has one pole and its mounted directly above the center plate.
There is also lot going on in the whole community: Two weeks ago the third NG UAVP Meeting took place in Zurich. We worked a lot on the new DCM based controller. Watch this footage from Robert. Also ludiwawa did the maiden flight of his Klappa Hexacopter.

For my next Quadrocopter I plan a bit nicer frame. Because construction isn’t my strong point I prefer something simple but reasonable priced. These out of the box frames were too expensive. Construction one by myself was not an option. Fortunately Robert made some very nice Frames and Centerplates. At first I wanted to build a CargoNG. I opted for centreplates only but in exchange with carbon fiber. Without a full frame it is easier to build and I have more freedom In terms of adding more circuit boards or a digital camera. Also if once I test some newly developed code and undergo a heavy bug, its not that expensive to repair the Quadrocopter

But where can I let it mill? Several team members have a mill by them own, but sending plates around, over the frontier, was a bit too complicate. I found the little company Keiro located in Switzerland which makes kits for air planes and also has a CNC mill service. I found carbon fibre plates at suter swiss-composite group at reasonable prices. To minimize wasting of space I descided to mill two 340mm x 300mm, 1.5mm thick prepreg plate in one procedure. I never used a CAD software, so I’m an absolute noob! I tried to put together the dxf files with QCAD, which is open source, but I didn’t succeeded. It was the control concept which I could not work with, the simple functions like moving and coping weren’t at places I expected them. And once I found one item, I had to try several times until it worked as I wished and I searched it again the next time. AutoCAD is a very popular software, so I tried it with a trail version of it. Even with AutoCAD I needed some time to arrange all parts. But as you can see, I finally succeeded. Two weeks later my brand new centerplates arrived. As you can see, there are also some landers and some spare parts for crashes or another Quadro-/Hexacopter!

As I wrote yesterday I bougth the Bus Pirate from Seeedstudio and a nice case. Another team member found this nice tool. It can be used to prototype and test electronic deviecs with buses such as UART, SPI or I2C. As I saw the ability to work as an AVR programmer and even a JTAG adapter I was persuaded of it as well. It looks like a perfect devleoper device for the NG UAVP.
With delivery I paid about 55$ for both parts. The case from US arrived way faster then the Pirate itself from China, but finally both made their way to Switzerland! I needed to alter the case with a nail file a little bit to make sure the USB connector has enought space. Built into its case it looks very nice!
The firmware on the delivered device was not that up to date:

HiZ>I
Bus Pirate v3 (Seeed Studio)

http://dangerousprototypes.com

Firmware v2.4-Seeed
DEVID:0x0447 REVID:0x3043 (B5)

First I had to upgrade to V4 Bootloader. I connected the PGD and PGC pins of the ICSP header to trigger the bootloader. Then I changed bitrateindex to 8 (for 115200):

vi P24qp.ini

bitrateindex=8

Afterwards I could do the firmwareupgrade (just ignore the verification errors in the output, its a bug in v2 bootloader):

$ unzip v2tov41-bootloader-update-va3.zip
$ cd upgrader
$ sudo python P24qp.py --serial=/dev/ttyUSB1 -v --auto=BPv3-v2blupdaterVa3-v4.1.hex
....
Writing 256 bytes to address 0x0000AB80
Reading 256 bytes from address 0x0000AB80
Write operation complete.
Verified Okay.
Verification complete, switching to user mode

Now I removed the jumper and restartet the Bus Pirate. Pressing enter produced this output:

Upgrade cancelled.

Universal DS30 Loader installer v0.3 (C)hris 2010

Released under Creative Commons null license.
Found bootloader v unknown (probably v2)
Will install bootloader v4.1

Type 'Yes' to program the new bootloader.
Disconnect power if unsure (no harm done).

“Yes” started the upgrading

Erasing 0xA400... done
Erasing 0xA800... done
Writing row 0 1 2 3 4 5 6 7 done
Erasing 0x0000... done
Writing row 0... done

Success!
Upload new firmware with the ds30 Loader app to complete the upgrade.

When the update is complete, the MODE LED will blink and the upgrader will prompt you to upload a v4+ firmware. I connected the PGD and PGC pins of the ICSP header to trigger the bootloader once again and restarted the Bus Pirate. I then uploaded the v4.2 firmware directly (you can’t install the v4.2 bootloader since its only a version for programm with PIC directly):

$ unzip BusPirate.firmware.v4.2.zip
$ sudo ./pirate-loader_lnx --dev=/dev/ttyUSB1 --hex=BPv3\&v2go/BPv3-Firmware-v4.2.hex

Removed the jumper again and the Bus Pirate has a shiny new software version on it:

HiZ>I
Bus Pirate v3
Firmware v4.2 Bootloader v4.1
DEVID:0x0447 REVID:0x3043 (B5)

http://dangerousprototypes.com

AVR programmer (STK500v2)

One of the features I needed most was the AVR programmer. For that purpose you have to flash a special firmware:

$ sudo ./pirate-loader_lnx --dev=/dev/ttyUSB1 --hex=BPv3\&v2go/BPv3-STK500v2-v0b.hex

Afterwards you can use it like an STK500v2:

$ avrdude -p m328p -c stk500v2 -P /dev/ttyUSB1 -v -V -U flash:w:sb-ctrl.hex

Just a small performance comparission showed positive results. I wrote an Intel hex with 30178 bytes to an Atmel ATMEGA328P. These are the flash times:

Bus Pirate	STK500v2
10.75s	42.55s

Note: These are both out of the box configuration, with correct STK500v2 configuration you can probably gain more performance…

After several weeks of silence I could finally find enough motivation and time to update my blog. I renamed it to “Envolving NG UAVP”, because, you might have heard it, I joined the development team of the NG UAVP in between. Now I try hard to help evolving this wonderful multicopter platform! To address the international community I decided to switch the language of this blog to English. The old NG UAVP from Scratch blog posts stay in german and are archived under its own category NG UAVP from Scratch.

Currently we work on several things for the NG UAVP: First of all we improved GPS support. We also tested new build toolchains and think about new control algorithm. All in all, its very interessting and I’m very happy do be part of the team!

I also bought new equipment: I have now a maas SPS-30 II power supply to load my LiPo’s quickly. I also bought a Bluetooth Bee, a serial extender with X-Bee pin alignment, but I could not test it yet. Also from Seedstudio I bought the Bus Pirate, an universial bus connector, programmer and even debugger.

My NG UAVP is still flying! But nevertheless I plan to build a second NG UAVP: I want to use nicer Centerplates, better motors and, finally, the TowerPro BLC’s with Quax firmware. But I still build it as simple as reasonable possible, I prefer to spend my time on developing software than building nice frames!

Heute, am Dienstag der 23. März 2010, wars endlich soweit: Ich hab den Erstflug gemacht. Nachdem ich in den letzten Tagen schon ausführliche Tests “aus der Hand” gemacht habe, aber da noch einige Probleme sah welche mich verunsicherten, hab ich den Erstflug vor mir her geschoben… Ich habe gestern alle Stecker besser fixiert und die Sensoren mit Heissleim verleimt. Das letztere hat die Abweichungen des Beschleunigungsensor auf der Nick-Achse schon einiges reduziert. Nachdem heute auch noch schönes Wetter war, hab ich mich entschieden den Erstflug direkt nach der Arbeit durchzuführen. Alles ging Reibungslos von statten, ich habe während ca. 30 Minuten zwei Akkus “durchgeflogen”. Ohne Simulation und andere Flugerfahrung hab ich noch nicht viel gewagt. Anheben und etwa auf Augenhöhe umherfliegen hat mir fürs erste gereicht. Daher ist das Video total langweilig, sorry!

Nun werde ich fleissig fliegen üben und den Quadrokopter noch etwas verbessern. Da sind noch einige Baustellen: Fehlende Duo-LED’s, Verkabelung, Landebeine, besser Entkopplung der Steuerung, Kompass, GPS, etc… Auch möchte ich Erweiterung wie Bluetooth-Konsole, NGvideo oder Kamerahalterung realisieren, nur weiss ich noch nicht welcher ich den Vorrang geben werde

Geflogen bin ich mit folgenden Parametern

set controller amir
set T.idle 20
set T.reserve 20
set T.spinup 2
set P.nick 60
set P.roll 60
set P.yaw 60
set D.nick 50
set D.roll 50
set D.yaw 10
set I.nick 30
set I.roll 30
set I.yaw 15
set Kalman.Angle.Q 0.00030000
set Kalman.Bias.Q 0.00010000
set Kalman.Acc.R 3.00000000
set Kalman.Cycle 1
set Kalman.Limit 1
set P.z 1950
set D.z 5000
set I.z 0
set P.z.limit 20
set P.z.upfact 28
set KalmanZ.L1 1.29170001
set KalmanZ.L2 0.83420002
set KalmanZ.L3 -0.26930001
set RC.nickcorr 0
set RC.rollcorr 0
set RC.yawcorr 0
set RC.throttlehoover -100
set ACC.nickcorr 9
set ACC.rollcorr 28
set ACC.yawcorr 65
set TRIM.roll 0
set TRIM.nick 0
set TRIM.yaw 0
set RC.fact.nick 30
set RC.fact.roll 30
set RC.fact.yaw 65
set Axis.decoupling yes

Heute hat mein NG UAVP die ersten Flugübungen gemacht, allerdings noch in meiner Hand. Dabei hab ich bemerkt dass ich die Roll-Motoren verkehrt montiert habe, was für einen realen Fatal wäre: Gerät er nur etwas in Seitenlage würde er den Motor in welche er sich neigt stärker ansteuern. Da die Motoren verkehrt montiert sind würde der falsche Motor geregelt. Dadurch würde die Seitenlage noch verstärkt was eine noch stärkere Regelung zur Folge hätte. Ein Absturz wäre unausweichlich.
Das QNGctrl-Tool hat mir geholfen zu verstehen wie genau geregelt. So konnte ich auch die Parameter besser verstehen. Dabei sind auch Probleme aufgetaucht wie zum Beispiel seltsame Jitters in den Gyros (was eventuell auf mangelnde Befestigung hindeuten könnte) oder abweichende Signale bei laufenden Motoren und gestoppten Motoren (was wahrscheinlich mit mangelnder Entkopplung zu tun hat).

Nun aber zum eigentlichen Thema…

Nach etwas Probleme habe ich es hin gekriegt QNGctrl unter Ubuntu zu kompilieren und installieren. Da es einige Libraries braucht und viele sich nicht mit dem Kompilieren auseinander setzten möchte habe ich Deb-Pakete für Ubuntu erstellt.
libglc-1.10-dev_1.10-1_i386.deb
ng-tools_0.56-1_i386.deb
libglc-1.10-dev_1.10-1_amd64.deb
ng-tools_0.56-1_amd64.deb

67db0a74005a73ab78db0c0ac6300280  libglc-1.10-dev_1.10-1_amd64.deb
88f0bd7e447cb1383e38f6966e567685  libglc-1.10-dev_1.10-1_i386.deb
75f012e6c5402b06f1d3ced1912cd51d  ng-tools_0.56-1_amd64.deb
f0976410f3b8c7d62557b3bd95121c27  ng-tools_0.56-1_i386.deb

Für alle die selbst kompilieren möchten: Zuerst muss GLC_lib installiert werden. Dafür GLC-lib 1.1 downloaden und installieren (1.2 und höher funktioniert nicht!)

sudo aptitude install gzip qt4-qmake build-essential libqt4-dev
qmake
make
sudo make install

Dann NGOS herunterladen und unter sources/ng-tools folgendes ausführen

sudo aptitude install libqt4-dev libqwt5-qt4-dev libqwt5-qt4 lib3ds-dev lib3ds-1-3 libsdl-dev \
libsdl-image1.2-dev
./configure --prefix=/usr

Das qmake-Skript funktioniert nicht unter Ubuntu da die qwt Library einen anderen Namen hat. Dies kann aber angepasst werden: Die Datei qngctrl/Makefile.qm editieren und in der Zeile LIBS -lqwt mit -lqwt-qt4 ersetzen.

make
sudo make install

Die Dateien qngctrl, qngctrl-bg.png müssen Manuell installiert werden, da diese im install-Target fehlen.

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. (Update: Scheinbar lag dies an falschen Firmwares)

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. (Update 10.05.2010: diese Firmware haben zu Startproblemen geführt. Die für diese TowerPro funktionierenden Firmwares sind hier zu finden) 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 (Update 10.05.2010: Der Ton sollte mit den richtigen Firmware tiefer sein!)
• TowerPro 25A Quax v2009 (Update 24.05.2010: Der korrekte Ton)

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.

Update 10.05.2010:
Wie in einem späteren Beitrag zu entnehmen ist hatte ich mit den Motoren Startprobleme. Dies lag an falschen Firmwares. Die Richtigen sind hier zu finden.

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!