Amir Guindehi's Blog

UAVP-NG: Mini-NG with 3D sensors, GPS on-board and NGblc-4mini

2012-11-13T12:45:10Z

And again it's getting winter and I've not updated my blog for too long. ;)
Let's change that...

At last year's 28c3 Chaos Communication Congress the UAVP-NG developer team succeeded to get (our back then brand new hardware) HW-0.23-mini-r0 airborne.

The new hardware - designed by Volker and Ben, two of our NG developers - no longer contains analog sensor technology but instad uses modern 3D digital sensor chips. This gave enough room to include the GPS sensor on-board. We also designed a GPS antenna perfectly suited to be mounted on top of the flight control.

In spring 2012 the 7. UAVP-NG Developer Meeting took place in Heidelberg. It was a great event - we were very lucky with the weather - and lot's of folks showed up. We all had a lot of fun and had great 4 days. Thanks to Volker & Ben again for making that great location available to us!

After 28c3 Ralf, one of our NG developers, started designing the new NGblc-4mini-r0, a quad-BLC for small Mini-NGs. His first design was airborne in spring 2012. After testing serveral smaller design changes were done and a NGblc-4mini-r1 was produced and tested successfully.

Small changes in print and a footprint error resulted in a NGblc-4mini-r2 design which we will produce now and hope to have ready for the 29c3 congress at the end of this year.

Besides that we started testing the new HW-0.23-mini-r0 in spring 2012 and we had to find out that the combined gyro/accelerometer called MPU6000 has a shortcoming: It only contains one filter set for both, the gyro and the accelerometer. As both sensor have opposing filter requirements in our application, we concluded that it would be nicer to have an additional accelerometer.

In our new hardware design HW-0.24-mini-r0 which we designed over summer 2012 we include a secondary additional footprint for a second (optional) accelerometer. We choose the proven accelerometer we used in previous designs. Furthermore we added a antenna PCB allowing everyone to build flight control sized GPS antennas perfectly suited to be mounted on top of the flight control.

HW-0.24-mini-r0 got airborne some weeks ago. Except for small textual fixes which we will incoperate in HW-0.24-mini-r1 everything worked out fine! We hope to have HW-0.24-mini-r1 with us for 29c3.

As you can see the new HW-0.24-mini-r0 includes the flight control PCB, a GPS antenna PCB with the same size as the flight control, the Cam/RC controller PCB, an external compass PCB, a JTAG connector PCB and two push button PCB.

Besides all the above some of our developers took the time to design NGlight, a small I2C peripherial devices to the flight controll allowing control of 16 PWM LED channels for control of RGB leds. It allows you to control different colors of 5 RGB LEDs while choosing the color in a range of 0.255 for each of the 5x 3 RGB channels.

Last but not least I should mention our UAVP-NG assembly at the 29c3 Chaos Communication Congress 2012 in Hamburg. If you live near Hamburg feel free to visit us from 26.12.2012 to 30.12.2012 at the congress!

UAVP-NG @ 28C3 - Chaos Communication Congress 2011

2011-12-20T17:25:20Z

It's winter again and I did not update my blog for half a year. Evil me. Let's change this...

Let me start with this summer's CCC Camp, which was a great event and everybody who joined us in the UAVP-Village in Finowfurth had a lot of fun. If you head over here, then you will find some pictures of the event.

After the camp we had a nasty surprise, when we found out that our new hardware HW-0.22-mini-r2 of the Mini-NG had a non recoverable bug on the PCB. It was nobody's fault in special, we all should have take more care in checking the changes, which have been done. To make up to our users, who already got a revision 2 board, we replaced them for free with a HW-0.22-mini-r3 board, produced immediately after we found out about the bug.

The new HW-0.22-mini-r3 of the Mini-NG performs admirably and many of us are now flying these boards, which offer exactly the same features as the big HW-0.22 tower, except that it's only one board with 55x55mm.

In the meantime we also developed new features for NGOS. Having received my new ACT 2.4GHz Kit with Diversity on both sender and receiver side together with telemetry, we decided that it would be time to support the telemetry system from ACT (M-Bus) and Multiplex (M-Link). Both systems are essentially identical. The new NGOS supports up to 14 different on-board values to be transmited on the back channel to the sender. The user is free to define which of the 14 slots should transmit which on-board data. A ACT UDP or a Multiplex sender is able to show these slots on his display to the pilot. Documentation and configuration examples can be found here, in the extensive NGOS documentation.

Having completed my new Mini-NG with all sensors, including GPS and compass, I decided to give Position Hold, Coming Home and Waypoint flying a bit of priority.

Having already completed the new NGCTRL2 communication protocol in summer, I decided to give Qngctrl a update and visualize all the new navigation stuff using the new features of NGCTRL2.

NGCTRL2 is a framed packet based communication protocol, where each packet may contain an arbitrary amount of data-sets which in turn each contain a type and a payload. The packet content is encoded with the COBS (Constant Overhead Byte Stuffing) algorithm making sure we only use up 1 byte in 256 for byte stuffing (worst case) which in turn makes sure we can always detect our framing byte and also assures, that we may use all possible byte values inside the packet. The COBS encoded packet content then gets a XOR checksum and a framing byte at the end and is sent over the unsecured serial connection.

Each of the NGCTRL2 data-set packed into a packet contain a type value, describing the payload type and it's implicit length. libng, our PC client library for NGOS communication has a poll() API allowing client applications to easily receive and parse the NGCTRL2 packets. As each data-set contains a type field, a client can request arbitrary dump intervals for each data-set type. A NGOS is even able to send data-sets which were not even requested by a client, thus allowing NGOS to inform a client of events happening on the copter side.

I've implemented waypoint flying on the NGOS side by giving NGOS a new waypoint table, which describes the coordinates of the available waypoints. The table can be manipulated with the normal "show" and "set" commands in the NGOS shells. There is a new suite of shell commands starting which the keyword "nav", allowing the user to issue navigational commands like "nav position-hold" or "nav fly-waypoint-fdw". The amir-ng controller was changed to understands the concepts of target, waypoint and it's navigation algorithms were adapted to be able to fly with different behaviors. Each waypoint is defined by it's coordinates, a dwell time and a action and argument, which will allow for a lot of new cool features in the future. At the moment, we only know two actions called "reach, next" and "reach, dwell, next". More actions are to be expected.

On the client side I implemented a new GPS Map view, which visualizes all navigational information received from a NGOS and displays it's position, it's target, it's waypoints as well as all navigational data needed to calculate the curse, consisting of target deviation and target distance. A nice small navigational control shows the headings of the different target/waypoints/home positions and also shows the result of the navigation algorithm for debugging purposes.

This is the above mentioned GPS Map. At that moment it shows a NG flying in a simulated flight using real GPS data and currently doing waypoint flying forward with 5 waypoints currently heading towards the first of them:

As you can see the GUI not only shows multiple waypoints and targets but also many of the on-board states like the battery voltage and the controller flight state. These get transmitted to the client whenever they change. Altitude Height controls are missing yet and will be implemented soon.

In the meantime our hardware developers were busy too and they redesigned the Mini-NG in HW-0.23-mini-r0. The new prototype will use the MPU6050 3D acc and gyro sensors and features an on-board GPS. First prototypes have been built and we hope to bring some of them to 28C3.

Last but not least work on our next-generation hardware platform HW-0.30 has begun. It will feature 2 STM32 CPUs with single precision FPU running at 168MHz combined with a dual-port RAM for fast direct memory communication. We hope to port NGOS to the STM32 architecture during summer 2012 and so support multiple architectures within one source code.

Currently everybody is preparing and packing for the 28C3, this years Chaos Communication Congress in Berlin where we will participate as every year.

On the 28C3 we plan to work on the NGOS software for the upcoming HW-0.23-mini release. Also we plan to further develop HW-0.30. Everybody interested in our project is invited to visit us at 28C3.

Besides our new hardware revisions, some developers are currently working on new brushless-controllers, a controller for lights called NGlight and other fun projects. We're looking forward to discuss, improve upon and show prototypes of them on 28C3.

28C3, we're incoming... ;)

UAVP-NG @ Chaos Communication Camp 2011

2011-07-23T18:05:19Z

The time is near... The Chaos Communication Camp 2011 will start the 10th August and continue until the 14th August in Finowfurt near Berlin, Germany Europe, Earth, Milkyway!

Chaos Communication Camp 2011 Trailer from elektropunk on Vimeo.

The Chaos Communication Camp 2011 is an international, five-day open-air event for hackers and associated life-forms. It provides a relaxed atmosphere for free exchange of technical, social, and political ideas. The Camp has everything you need: power, internet, food and fun. Bring your tent and participate!

Make sure to join us in the UAVP-NG Village at the Chaos Communication Camp 2011 in Finowfurt!

UAVP-NG: Taarek's first pirouettes

2011-06-29T17:40:16Z

Hi all!

As you probably know, neighter Taarek nor I ever flew anything before we found out about quadcopters. We were real noobs when we started with the stuff and trough having flown the old UAVP and the commercial MK we both never had a lot of pilot experience.

Switching to the UAVP-NG did not really help the issue. As a test pilot you are never sure if the fault was yours or if the software or hardware failed... ;)

Still after a while you get a bit of feeling for piloting and it seems that Taarek finally got the groove. Using a not so heavy NG probably helped too as we did this using our new Mini-NG, which you can see on the following picture:

Using the above Mini-NG it has suddenly become quite easy to fly pirouttes and I did a small movies of Taarek's first stunts. Flying NG is fun... ;)

UAVP-NG - The OS Multicopter: Taarek's first pirouettes from Amir Guindehi on Vimeo.
These are Taarek's first pirouttes flown with my brand new Mini-NG

Best regards!
- Amir

UAVP-NG: Size comparision NG / Mini-NG

2011-06-28T13:14:32Z

Hi all,

I would not let you miss the great photo Timo has shot showing the size differences between our normal size NG (HW-0.22) and the Mini-NG (HW-0.22-mini):

Cheers!
- Amir

UAVP-NG: The 5. NG Developer Meeting in Heidelberg

2011-06-28T10:08:30Z

Hello everybody!

Finally I found the time to update my blog! End of last month we had the 5. NG Developer Meeting in Heidelberg. Ben and Volker organized the event and it was a lot of fun! Peoples from all over Europe showed up and we had 3 days of BBQ, discussions and flying.

Now, a month later some of the movies shot have been cut and posted to the net. Below you find Robert's and my moving pictures of the event.

UAVP-NG - The OS Multicopter: 5. Developer Meeting in Heidelberg from Amir Guindehi on Vimeo.
This is a summary movie of the 5. NG Developer Meeting in Heidelberg, which took place the 27./28./29. May 2011

NG UAVP Meeting Heidelberg from Rob Robot on Vimeo.
Short Movie of the NG UAVP Meeting in Heidelberg Germany from 27 to 29th May 2011

I would like to thank all visitors and special thanks goes to Volker and Ben for organizing the great event!

Best regards!
- Amir

UAVP-NG: A fully assembled UAVP Mini-NG

2011-05-30T12:46:32Z

Hi guys,

Timo did some very nice shots of an fully assembled Mini-NG, which I could not let you miss:

Cheers!
- Amir

UAVP-NG: The new Mini-NG - a full NG on 5.5x5.5cm

2011-03-22T11:47:39Z

Hello everybody!

It has been a while since my last post, again. In the meantime we survived winter and had a lot of fun at the 27c3, the yearly CCC Congress in Berlin.

Spring is coming - and as every year, we need something new to play with... ;)

The new Mini-NG hardware has arrived!

Over winter time Volker redesigned our original HW-0.22 into a HW-0.22-mini. The new hardware is fully feature compatible to the old one, is running the normal NGOS and was shrunk to a size of 5.5cm x 5.5cm on 4 layers!

The RC-Controller was moved to a small separate PCB so that only folks needing additional DSL channels or servo channels will have to use it. The functions of the SB-Controller are provided by the LPC itself.

Here are the first shots of the PCBs...

Top side:

And bottom side:

Next, we will test the new PCBs and should everything work out, we will make them available in the NG Shop. Please note that the boards need to have a LISL acceleromenter directly soldered to the board. This means you need hot air to solder it by youself.

Our first Mini-NG prototype was airborne in december 2010 at the 27c3 congress!

A fully assembled HW-0.22-mini (this is our prototype which was airborne at 27c3) looks like this (courtesy of KeyOz):

Volker did a great job and the new Mini-NG looks nice and cute (at least for my humble eyes)!

We hope to be able to provide Mini-NGs with pre-soldered LISL and eventually even with pre-soldered LISL and ADXRS620 gyros in limited numbers in the NG Shop.

Check the NG Forum for Project News on that.

Cheers!
- Amir

UAVP-NG: Source code release of NGOS - The NG Operating System

2011-01-07T04:02:15Z

The Next Generation Multicopter team would like to announce the source code release of NGOS - The NG Operating System under a GPLv3 license after 3.5 years of intense development time.

Check out the UAVP-NG homepage for more informations!

Official binaries:

* http://ng.uavp.ch/moin/Download

Release source code repository:

* https://pub.uavp.ch/svn/releases

List of supported platforms:

NG HW-0.10
NG HW-0.20
NG HW-0.21
NG HW-0.22
NG HW-0.22-mini

For a complete list of changes refer to the Release Notes at http://ng.uavp.ch/moin/Download

The Beginning

This project was started in summer 2007, half a year after the original UAVP, also a GPL project, was released. All over the world UAVPs started to get built. At that time, many of us started dreaming of bigger and more powerful processors, peripherals and sensors. The current projects available at that time seemed not to be able to scale according to our needs, so the idea of something new was born. In April 2008, about a year later, there were about 500 UAVPs airborne around the world.

Having flown most of the other open projects available at that time some of us decided that they did not offer the resources we wished to have on our copters. Especially when looking into the future it seemed that none of them had the scaling possibilities needed. Studying the available processors we realized that we needed to switch processor types to get the computing power we dreamed of. Neither PIC nor Atmel could provide what we needed.

In the end we decided to go for an ARM7 and started the Next Generation Multicopter Project.

Our Goal

The development of a free Open Source Multicopter software and hardware framework for further research based on a high performance 32bit ARM7 RISC CPU.

The Story

We started work in August 2007 as a small team which met on IRC. The first hardware (HW-0.10) went airborne in January 2008. The software has been extended with a lot of new features after that. We then worked on a new hardware revision (HW-0.20) in summer 2008 and the first prototypes were produced some weeks before the 25C3 congress. The new hardware got airborne in December 2008. After 25C3 we improved the flight control software immensely and started working on the peripheral controllers software support for the new hardware. Having tested and flown HW-0.20 a lot we decided to improve the hardware in summer 2009 and so we started work on the next hardware revision (HW-0.21). We finished that in June 2009 and produced enough boards for all beta testers and developers to thoroughly test the hard and software. The new hardware got airborne in August 2009. Discovering small problems and print issues we decided to produce one last hardware revision 0.22 fixing those before a final release. We hoped to produce this revision before 26C3 and have it ready for a first public release at 26C3. We succeeded and did a hardware release with HW-0.22 at the 26C3 Congress in Berlin.

Finally having a stable hardware platform out in the green, we started working on the source code immediately after returning from the 26C3. Cleaning out the source, commenting and polishing while still implementing new bells and whistles took the time from then until today.

Be aware that this still is work in progress. We decided that it's time to let everybody play with it, now that the hardware has reached a stable state but this is still a very livid project and new hardware revisions and software changes have to be expected any day... ;)

The Design Principles

The design principles of the NG project are simple:

"Complexity, modularity and encapsulation where performance allows it, simplicity and directness where performance requires it."

This has led to a quite complex framework which we started calling the NG Operating System. The system uses abstraction and complex pointer tables where necessity requires it and performance allows it. It uses global variables and breaks encapsulation where performance requires it. We use classic Open Source tools like the autotools suite, gcc and gnu make. We adhere to common C design rules. And we try to provide a user friendly interface with features like help for commands and verbose error messages.

The Key Features

The NGOS has a design rather different from most available flight control software. Instad of building a fully synchronous system as most did, we built a fully asynchronous system which only synchronizes when needed. This allows for a much more modular design and also allowed us to implement modern operating system like features.

A Multicopter only flies as good as its algorithms allow. Since the model is inherently unstable the closed-loop control algorithm is most critical for flying. People tend to have different ideas about the right algorithms. In order to allow different developers to implement different algorithms and to help compare them we designed the NG controller framework.

Our NGOS uses a modular, pluggable extension framework for closed-loop control algorithms, called controllers, and allows for several of them to be implemented at the same time using a simple abstract programming interface. This enables simple extensions to the system's closed-loop control algorithms by people not used to firmware and system programming. The modular controller framework is coupled with a modular configuration framework, allowing each Controller to have a different set of parameters in different configurations. Several controllers have been implemented. We have a good flying heading hold controller, a Kalman filter based integral controller with a lot of features like PT1-compensation and more and last but not least a port of the old Wolferl-controller from the old UAVP, which, BTW, flies very good with a closed-loop running at 1kHz... ;)

The system allows multiple interactive command shells and their spawned commands to be used concurrently on the different physical i/o devices. This means you can log in to your NG several times through one of the two UARTs or the USB port. Other available character devices could be supported as well. The shell command interface is also very modular and allows developers to add new commands quickly for debugging and testing purposes. A command can "take over its controlling tty", which allows an implemented shell command to put the shell to sleep, take over the physical i/o device and start doing with it what it likes. This allows for implementing new communication protocols (for ground station communication or similar) side by side with older and/or different protocols without having side effects or worse.

Controllers and configurations can be manipulated online using one of mentioned shells above. The controllers output the results of their calculations to a physical hardware abstraction layer called HAL which uses a similar modular framework as the controllers. Different multicopter models (eg. QuadCopter, OktoCopter et al.) can be implemented and flown using different HALs. Different flight styles can be implemented this way as well (X-mode, Reverse-Mode). It's even possible to mix different actors (eg. i2c bl-controllers, pwm-servos and i2c-servos) to control models different from the common multicopters. We already support a whole bunch of HALs (quad, quadX, quadR, Y6, X8, X8X) and new ones are implemented easily.

The above is tightly coupled with a behavior system which allows the user to configure arbitrary behavior rules using simple behavior conditions and behavior actions. Users can customize these behavior rules according to their needs. A behavior rule is defined by a behavior condition (which can have arguments) which, when triggered, executes a defined behavior action (which can have arguments too). Conditions and actions are arbitrary functions implemented separately in the NG framework. The implemented console commands can be used to inspect the currently defined behaviors as well as the predefined conditions and actions. Users are able to define custom new behaviors using the predefined conditions and actions. As each condition and action can receive user chosen parameters these allow further customization by the user.

If you ponder the above behavior concept you will see that every and all of the current UAV features can be mapped to behavior rules. You need calibration on channel 5? You want your camera to make a photo when channel 8 goes to 100%? You would like to turn on the lights, when you have reached 10m or more... it's all possible.

The NGOS supports several different types of RC receivers. It supports the normal sum-signal input as well as the faster sum-signal from the ACT 4+2XS 2.4GHz sum-signal receiver. Furthermore it supports the proprietary serial DSL protocol from ACT which allows us to attach any ACT DSL receiver to the NG. ACT produces great cheap and expensive PPM, PCM, SPCM and 2.4GHz receivers and most of them have a DSL interface. The NGOS contains an rc-mixer which allows to mix several rc input signals in different ways. Currently a primary and a secondary device are supported which can be mixed as teacher/student or for diversity. As the DSL protocol contains the signal quality received the diversity mixer can mix the two signals accordingly. If in teacher/student mode, the mode can be switched using arbitrary behavior rules defined by the above user configurable behavior system.

The NGOS

Do you wonder why we call the firmware an Operating System? Now, we all agree, it _is_ a firmware, but it has become a firmware with many, many operating system like features. The NGOS does hardware probing on startup and activates hardware dependent interrupt handlers. It outputs bootup messages while starting. It is split into user, system and irq context, the closed-loop controller is running on the system level, the user mode shells have to use system calls to use privileged opcode. Furthermore it has a timer scheduler and a task scheduler with a process table, it has a device table and it has tools to inspect all of them. The NGOS's device-probing dependent interrupt handlers could be called drivers. The started consoles implemented as cooperative shell tasks in user context (which are able to fork off commands) executed by a round-robin scheduler conclude the operating system like features.

The Developers and Users

Essentially the NGOS provides a simple API for controllers, configurations, HALs and behaviors programming for developers while giving users of the system very broad possibilities to customize their multicopter and the available features. This way the whole system will be interesting to users and developers with its unique options and possibilities.

The firmware is built modular and enables different closed-loop control algorithms to run side by side to allow different developers to share and compare their algorithms and designs. The abstract closed-loop controller framework allows non-programmers like mathematicians, closed-loop engineers and similar minded folks to implement new closed-loop control algorithms without having to understand more than input and output structures of their algorithms.

The Catch ;)

Please be aware that much of this source code was written by a single person - me. I am an EE engineer specialised in computer sience, system programming, network protocols, high-availability, clustering and security. I'm in no way a specialist for closed-loop controls, embedded system programming and aeronautics. Please be aware of this when studying the chosen solutions and implementations in these fields. I'm sure many experts out there could contribute a lot better solutions.

This all was - and still is - a very interesting experience and a lot of fun for me and I learned more about embedded programming and closed-loop control than I ever imagined I would... ;)

Your Contribution

If you would like to contribute to the project make sure to check the development page in the NG wiki.
It can be found at http://ng.uavp.ch/moin/Development

Thanks

I would like to mentions some great guys who joined our team and contributed to improve hardware and software to where we stand:

Markus Bechtold
Michael Buhr
Axel Burri
Patrick Schmid
Nabil Sayegh
Ralf Hager
Stefan Agner
Tim Pambor
Nabil Sayegh

Also special thanks goes to Wolfgang Mahringer who built the original UAVP and infected many of us with the multicopter virus and to Bernd Richter who infected us with a lot of new ideas and who was a great source of information and knowledge to us.

The Spirit

We hope to be able to provide a platform for experiments, new ideas and research for all Multicopter fans out there!

Best regards!
- Amir Guindehi & The NG Team

UAVP-NG: HW Release, Shop, DCM, GPS & Developer Meeting

2010-08-03T09:10:07Z

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

UAVP-NG: Hardware 0.22 has arrived - Public HW release is imminent!

2009-11-26T18:05:28Z

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!

Helengeli: Mantas, Sharks and Walesharks

2009-07-29T08:49:33Z

Hello everyone!

I'm once again back from hollidays! My girlfrend and I went to Helengeli, that's a small island on the Maldives in the North-Male atoll.

To give you a small impression of the island... this is how Helengeli looks from above:

Helengeli really is a nice place to stay. It's a wonderfull marvel of a classical Maldivian island with a lot of trees and bushes and wonderfull clear beach with white sand and blue water.

This is a small plan of the Helengeli island itself:

My brother already visited the island some years ago and he told me that it's a nice place for diving! Staying in the hotel managed by Manta Reisen, we visited the Ocean Pro Dive Center there and went diving for 12 days.

The dive center manager is called Uwe. He's a very experienced diver who knows the place and the sea very well and he was able to show us really nice places!

I should not forget to mention Line, Manja and Gio, all dive guides of the Ocean Pro dive center, who organized the dive excursions besides Uwe. Line was with us when we all saw our first waleshark...
... but let's start at the beginning.

When we arrived we were quite tilt. Neighter Kathrin nor I could really sleep in the plane and so we were up for 30 hours or so. First thing we did was to check in everywhere and then drop dead to bed.

The next day and the following two days we did some refresher dives where we did not see a lot of stuff. I have to mention that I had a new dive computer with me, an UWATEC Gallileo, which i wanted to test during the hollidays. It lit up like a christmas tree under water... ;)

Luckily I had my old dive computer with me as well and so I was able to dive as always using my old one while exploring the new and shiny one which shows so much more information under water that you're simply confused at first... :D

Anyway, after some dives I had found out that I needed to activate Profile Dependend Intermediate Stops but change the air integration to accept 30 bar as reserve for the Remaining Bottom Time calculation instad of calculating with a 80 bar reserve, which I anyway don't have and don't want. Having changed that, it suddenly was quite a lot of fun to have beats per minutes of your own heart, remaining bottom time approximation, microbubble protection and profile dependant intermediate stops. It also plots very nice profile graphs overlayed with bpm or temperature at which you can look live under water. It would even support multi-gas features like adaptive microbubble predictive multi-gas algorithms but that's nothing I can use atm. since you need to have multiple tanks with different gases for that.

Here's a small map of the dive spots around Helengeli (the upper right part):

Anyway... having mastered the new computer and having made some easy dives we started off for Bodu Thila, a dive place near Helengeli where some current has to be expected. Now, to be true... it was a lot more than some current and having never experienced that much current under water, using up my air in exorbitant rate, I aborted the dive and Kathrin and I came up after 19min, which probably is our shortest dive ever... :)

Needless to say that my girlfriend performed more than great and was not half as stressed as I was... *hide* Kathrin is starting to become a really experienced diver!

After that crazy dive at Bodu Thila, everything started to normalize. And from then on we had wonderful dives! Check out these nice corals:

Sometime in the first week we finally visited Farytale. That's a place where Mantas can be found often in this time of the year. And we were lucky! More than 6 animals came by in the time we digged us in on the ground and we had wonderful 74 minutes under water!

I made as many pictures as possible...
... at first we only saw them from afar...

Then more near...

But then the next ones flew directly over our heads...

And you won't belive it, there came more and more of the huge animals...

And they did not shy in any form...

But behaved, as if they own the sky, the land and the sea...

... and nothing on earth could ever change that!

It was great! Can't say more... simply great, great, great... ;)

When we visited the place a second time, two days later, we did not find the mantas again. On the other hand we swam into a pack of White Tip Sharks hunting on the reeftop we were drifting over. The pack consisted of 6 very active hunting White Tip Sharks, which swam around us for more than a minute!

Some days later we visited the Trix Caves. Another famous dive spot, where big open caves are carved into the 40m deep dropoff at the outer reef. Here's a picture where I look from the Trix Caves out into the blue, where we saw a Waleshark some minutes after I made this picture!

Directly out of the blue you see in the above picture a gigant 7-8m long waleshark appeared, swam parallel to us for some seconds and then disappeared again into the blue again! You can't belive how shocked we all were, suddenly seeing such a huge monster (it looks very shark-like!) appear out of the blue!

Our guide - it was Line on this day - did not yet have seen a waleshark near Helengeli eigther and was very happy when it suddenly happed! This is how she looked afterwards... do you see how exhilarated she was? ;) We all looked similar...

And I should not forget to mention that we saw two Spotted Eagle ray immediately after the waleshark... we could not belive our luck!

Kathrin had loaned a lamp in the dive center and had a lot of fun exploring the Trix Caves with it! There are so many colors down there, if you only have light to show them! It's like Alice's wonderland... you just have to open it up with a light-thrower... ;)

Kathrin also found her first slug by herself! And I even was able to make a picture of the second one she found! It's a Wart Slug becoming up to 7cm in size!

Some days later we finally were able to visit Bodu Thila a second time! This time the current was very easy and we saw several white tip sharks near the Thila...

On the same dive we also saw a Yellow Spotted Burrfish, which looks very strange and nearly alien!

On the third to last day we did another dive at Bodu Thila. This time we had a bit more current, but it was still easy going. No comparision to the first dive we did there. This time we found some more sharks...

All in all it were wonderful hollidays and we had a lot of fun! We saw nearly everything we wanted to see and some of it even in abundance!

The new dive computer also performed very well and if it would not be so expensive (it costs EUR2000 with all sensors) I probably would buy one for myself. Let's see if I can simply loan it, next time I go diving...

Let's hope it does not take long until we find the time for the next dive hollidays!

UAVP-NG: Hardware Abstraction Layer

2009-06-25T15:29:29Z

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...

UAVP-NG: Hardware 0.21 has arrived

2009-06-25T09:20:41Z

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!

UAVP-NG @ 25c3: Axis decoupling, User/System/IRQ mode & exception handlers

2009-01-01T11:50:47Z

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.