Results tagged “QuadCopter” from Amir Guindehi's Blog

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!

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

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!

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

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

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

Hi guys,

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

Cheers!
- Amir

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

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

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

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

Hi everyone,

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

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

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

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

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

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

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

# show devices

Detected devices:

  Addr  Bus     Description

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

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

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

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

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

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

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

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

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

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

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

# show ngpp sbctrl

NGPP sb-ctrl registers:

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

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

# set sb.test1 44

NGPP: wrote sb-ctrl register 7 value:     44

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

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

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

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

We received the new boards today!

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

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

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

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

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

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

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

Stay tuned!

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

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

This is about to change!

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

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

We currently have implemented the following HALs:

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

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

On the NGOS side of things this looks like this:

# show hal

Current HAL: quadcopter

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

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

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

Description:

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

Current HAL configuration:

  HW.HAL     quadcopter          HW abstraction layer

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

# show hal

Current HAL: Y6

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

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

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

Description:

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

Current HAL configuration:

  HW.HAL              Y6                  HW abstraction layer

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

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

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

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

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

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

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

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

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

MY new NG.Y6 from MarkusBec on Vimeo.

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

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

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

Hopefully this will change again...

It's time to revive this blog!

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

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

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

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

The boards look great!

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

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

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

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

Axis de-coupling

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

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

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

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

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

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

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

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

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

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

As you can see, this works out very well!

25c3 flights

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

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

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

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

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

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

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

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

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

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

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

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

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

Exception handlers & crash logs

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

Hardware Abstraction Layer

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

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

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

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

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

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

# show version

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

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

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

# show devices

Detected devices:

  Addr  Bus     Description

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

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

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

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

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

The first fully assembled NG-0.20 looks like this:

Update:

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

But see for yourself:

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

We will continue our test flights in the next days!

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

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

The panel packet:

The topside of the panel:

And the backside of the panel:

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

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

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

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

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

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

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

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

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

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

Hello everybody!

You probably already read about it in the forums, but I thought I should write a nice blog article about it as well. Not everybody is digging the forums as troughly as we do... :)

We are now able to understand the proprietary DSL protocol of the RC receivers from ACT. This allows us to connect any receiver with a DSL interface to the NG. ACT produces great cheap and expensive PPM, PCM, SPCM and 2.4GHz receivers and most of them have a DSL interface. We can use all of them now! I've already ordered a SPCM receiver for myself... :)

To be able to test out the stuff, I've upgraded my NG to 1x sum signal + 1x DSL receiver, an ACT DSL8 to be exact.

My NG now looks like this:

Software support for DSL was added to the NG firmware and the NG is now able to use DSL receivers on any of it's UARTs. Being able to parse the DSL protocoll, we now have the possibility to connect serveral rc receivers at the same time to the NG. The current NG is able to use up to 3 rc receivers that way (2x DSL + 1x sum signal).

We implemented Diversity and Teacher/Student functionality! Teacher/Student was implemented in two different forms. We have the "ts-switch" mode which allows the user to switch between teacher and student mode using a behavior rule which is a able to check for arbitrary conditions eg. buttons, changes on sticks... essentially any behavior condition implemented. On the other hand we have the "ts-mix" mode, which will continiously mix the teacher and student signals.

We used the Teacher/Student mode for our first FPV tests and it performed perfectly.

Using the Diversity features seems a bit more troublesome. If you would like to do frequency diversity (as I do), then you have the problem to get two identical signals on two different frequencies into the air. It seems that there are not many possibilities to do that...

ACT offers a double sender module allowing Graupner MC24, MC22 and Futaba RCs to be extended. Sadly the module works with two quartz crystals and has no synthesizer. Since I extended my MC22 with a synthesizer, I don't really like the idea to go back to quartz crystals.

Another possibility would be to use two RC controls and link them using the teacher/student features of the RC. Since normaly only the teacher rc is sending a signal this will need some fiddeling in the remote controll to be able to have both rc send the same signal on two frequencies at the same time.

As you see, there's a lot room for further experiments!

As NG developer I normally don't get round to fly very often (except for silly test-flights where you learn nothing), so my fly hour count is not yet that high. But after a year of testing and flying these things, something finally seems to have registered in my brain and I'm able to fly circles in front of me and around myself.

I would not let you miss the fun, so here it is, my latest flight! Be sure to note the flown circles... :)

Wolferl-NG: Amir flying circles outdoors with his 38cm NG from Amir on Vimeo.

The KML File of the flight following this one is available here.

Update: Three days later I tried it again. This time I decided to fly even more circles. It seems to me that I'm slowly getting the hang on it! It starts to be real fun:

Wolferl-NG: Circles, circles, circles from Amir on Vimeo.

Hello everybody,

I would like to let you have the latest News: The NG is able to use the GPS for tracking!

After having implemented the GPS NMEA parser some while ago I left the GPS beside because to use GPS for controlling you need a working compass. Since the compass of the current hardware revision is not really useable for that sort of thing, I never got round to use the GPS for something sensible.

Last week I suddently realized that even trough it's not possible to use the GPS for controlling purposes without a compass it surly is possible to use it for tracking! So I started hacking on the GPS tracking feature. I store the GPS positions in RAM and for that I reduce the 3 double precision floats to 6 byte. That way it's easy possible to store 1000 points in the free RAM.

I also implemented a small XML generator which directly outputs KML standard files which can be directly loaded in Google Earth. Furthermore I wrote a new behavior action named gps.track() which takes one parameter telling it to switch it on or off.

Writing a behavior rule to switch on GPS tracking when reachin flightstate FLYING and a second rule to stop GPS tracking when leaving flightstate FLYING took another minute and was a two-liner in the NG console.

The first GPS tracking flight was done on the 11.July. You can download the KML file here.
A second GPS tracking flight was done 4 days later:

Wolferl-NG: Amir's maiden flight of his 38cm NG from Amir on Vimeo.

The KML file of a third flight which was done a day later is available here.

... or better "About Modern UAV Sales Managers".

Being head developer of the UAVP-NG project I receive a lot of emails. Some of them are really nice to read, some of them are questions easy to answer and some of them are question better not asked, because they were explained in detail over and over in the forums.

Sometimes I also receive emails from commercial UAV enterprises.

Yesterday I received an email I would like to share with you all. The Sales Manager of MarcusUAV contacted me and asked if we would promote his product on our pages please.

I answered that I do not understand why we should promote a commercial UAV of unknown quality as we are a direct competitor to their market.

Now read for yourself how the MarcusUAV Sales Representative reacted to my answer:

Subject: Marcus UAV Greetings
From: sales@marcusuav.com
Date: Tue, June 24, 2008 2:46 am
To: Amir Guindehi

> Hi Corey,
>
>> Hello, I am Corey Zeimen, Sales Manager from Marcus UAV. We are a
>> manufacturer of UAV's for the civilian market.
> Nice to hear from you.

Go fuck yourself you douche bag.

>> We would like to offer you a wholesale discount if you were to promote
>> our website on your homepage.
> I don't understand why we should be interested in promoting your UAV?

So somebody that wants to slam out a business can have a UAV shipped to them.

> We are developing an Open Source UAV ourselfes and we are a direct
> competitor to your product. Our product will be free for everyone.

Oh yea? Send us one of your planes to sample

>> This discount is very large, and you stand to make a substantial profit
>> from even one UAV sale.
> We are not interested in profit.

Can I borrow $1000?

>> A link exchange can also be made possible.
>> We can discuss terms, as we are open to a variety of things.
> I don't think we are interested. I can't see any gain in promoting a
> commercial foreign UAV of unknown quality.

Are you a professor? I expect you to be

Suck My Balls,

Corey Zeimen
Sales Manager

I would like to warn you! As you can read the representatives from MarcusUAV are not up to the task. They seem not to know how regular business works and seem more than primitive in their language. I don't think a respectable business sales manager would talk to customers as seen above.

Everybody searching reliable and competent business partner for commercial UAVs should look into the direction of AscTec Technologies for proven reliable UAVs or towards DataCore GmbH if you would like to have something custom made for your enterprise.

Please do yourself a favor and ignore companies like MarcusUAV who are not even up to the task to talk to customers. Guys laughing about the status of a professor will not have the needed professional knownledge and experience to build a successful commercial UAV anyway...

Last but not least according to this page Corey Zeimen seems to be the CEO of MarcusUAV as well.

Did you ever think of your UAV as an entity?

Now, you probably will think we have gone crazy, but think it trough! You put it on the floor and let it go. And after it's flying you hope it will do what you tell it to do. You tell it to turn right and it turns right. You tell it to raise and it raises. You told it to warn you when the battery reaches less that 10V and it warns you, when it's battery reaches 10V.

In essence every UAV has a known set of behaviors and you expect it to behave according to these!

Now imagine that these behaviors are not a fix set of rules, but imagine you could customize these behaviors according to your needs. Let's say a behavior rule consists of a behavior condition, which when it evaluated as true makes sure that an associated behavior action gets executed. If you think it trough you will see that every and all of the current UAV features can be mapped to behaviors! You need calibration on channel 5? You want your cam 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... and... and... and...

I think you got my point...
... we can model every and all UAV features to one or more behavior rules.

We implemented the concept on the NG. You can define arbitrary behavior rules. Each behavior rule consist of a behavior condition, which when it evaluates to true will trigger an associated behavior action.

Conditions and actions are arbitrary functions implemented seperate in the NG framework. The implemented console commands show behaviors, show conditions and show actions are 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 with the command add behavior .... Each condition and action can receive user chosen parameters. These allow further customization.

In the newest NG firmware 12 predefined standard behaviors implement the normal behaviors you are used from your UAVs. This includes sensor calibration, config- and controller-switching when not flying as well as motors on and off stick positions. Furthermore the in-flight actions like rc calibration, hover calibration, emergency landing and more are defined using behaviors. Further empty behavior rule slots allow users to add their own behavior rules.

In the future we will implement even more complex conditions and actions. We already introduced behavior variables and test conditions for them which will allow more complex behavior definitions. We will also implement more complex actions like a gps.come.home(), ctrl.do.hover(), comm.uav.near() or ctrl.do.emergency.landing().

We expect to leverage the concept even further so that we will be able to implement complex inter-UAV behaviors using them. Eventually we will even move up to a byte code compiler and interpreter. This will allow very complex new behavior programms moving the whole concept to a fully new level.

The current NG implementation allows all standard UAV behaviors you are used from normal UAVs like the MK or the UAVP. More complex behaviors will follow.

Today I finished my third NG. It's dedicated for fun flying and because of that we choose a frame span of 38cm. This is the minimal span possible for EPP1045 propellers. The new NG is using Hacker 20-28 clones for motors and Holger's BL-Ctrl 1.1.

The small size allows agile manoeuvres and reduces the weight of the whole construct down to 635 grams.

The following movie shows a short maiden flight done in my living room. I will make a longer movie outdoors when the weather clears up.

Wolferl-NG: Amir's maiden flight of his 38cm NG from Amir on Vimeo.

A following outdoor flight some days later looked like this:

Wolferl-NG: Taarek's outdoor flight of Amir's 38cm NG from Amir on Vimeo.

If you are interested in the detailed specifications of my new NG, be sure to hop over to the UserCopter page of this NG.

I have to tell you hot news: Yesterday a picture of my UAVP got printed in the press!

Prof. Dr.-Ing. Heinrich Warmers of the HS Bremen invited to a QC convention in Bremen. He asked me if I could provide a good UAVP picture for an article in the local press covering the QC convention. I offered him all my archives including the pictures from the QC convention in Regenstauf and by chance he choose a nice picture of my UAVP.

But see for yourself:

As you can read in the text we did not get mentioned even trough Heinrich told the authors that it's a UAVP. On the other hand the Paparazzi project was mentioned, which is another open source project implementing QC favored by Heinrich and his team.

We finally came round to dig through our pictures made at the Quadrocopter convention in Regenstauf.

My brother and I joined the Quadrocopter convention in Germany on Saturday around midday after having driven 450km to Regenstauf, a village near Regensburg. At first we visited Cadmium's lab, where we meet Wolfgang and a lot other folk of the QC szene. Later that day, around 18:00, we went to a sports hall where everybody sent his QC into the the air.

As you can see on the photos, a lot of different projects and different UFO designs joined the convention. It was great fun to see them all flying!

Direct Link to the album: UAVP - Treffen Regenstauf

The convention in Regstauf was really great stuff and every km we had to drive was worth it!

We did some more test flights with our cam onboard our UAVP. I think we did some good air pictures and I wouldn't let you miss these!

Again we mounted a Canon Powershot S50 directly under the UAVP. It had no servo support or anything and was turned by 45 degrees so that the landing gear wasn't showing on the picture as before. I talked about this in my last blog entry.

I've explored Picasa (the Google thingy) a bit and this is a first test of placing the pictures on the picasa webserver.

Let's see how this works out:

Direct Link to the album: UAVP - Second In-Flight Pictures

Another movie I would like to show you is our first near-night flight while making a small movie.

We started in with the last light and then flew until our batteries were empty. In the end it's really dark and one can observe our 3x 3W Luxeon LEDs in full colors... :)

I'm sorry that you did not hear from me for such a long time!

It was holliday time so I went diving in the Red See on a dive safari and was quite busy the rest of the summer. Today I finally found a little bit of time to write a new blog article. Expect some more blogs about my hollidays and a nice collection of underwater pictures and movies soon!

Yesterday we took a cam into the air for the first time! The pictures are not really spectacular but I thought I should not let you miss them.

We mounted a Canon Powershot S50 directly under the UAVP. It had no servo support or anything and was turned by 45 degrees so that the landing gear wasn't showing on the picture. The whole cam we mounted in a box of styropor and attached that to the backside of my UAVP.

The cam was switched to series-pictures and we blocked the cam's trigger button.

But take a look for yourself: The first aerial pictures

One of the better pictures is this one:

We could even shoot a pictures of ourselfes while flying:

Later on we dismounted the cam and did some flights in the half dark. After we finished the first battery we mounted a new one and wanted to start again. I don't know what I thought but since my flight timer was not set to zero because of the first flight, I wanted to reset it.

For that I simply switched of the remote control! What a big mistake.

I already had switched my UAVP into flight mode and so, when I switched off the remote control the UAVP lost RC connection! The receiver switched to fail-mode and switched the throttle channel to hoover-power (another bad idea of mine which I corrected now)...

But watch for yourself what happend:

I was lucky... :) Nothing really bad happened!

I broke two screws and I had to replace the antenna, which came into one of the propellers.
Everything is already fixed again... :)

This weekend we had wonderful weather and we were out for more testflights. Sadly we soon discovered that my brother's UAVP had a hardware problem. He was able to start but soon after starting his UAVP suddenly nicked into one direction and crashed.

We could reproduce this several time as you can see in the short video below and each time the same happened. We think it could be another unclean soldering pad.

But watch for yourself how Taarek's UAVP crashed:

After this unsatisfying result we fetched my UAVP and tried again.

This time the hard work showed!

My UAVP flew way better than any time before. Using the new throttle curve I was able to hoover, nearly fly a full circle (I paniced in the end :}) and I even flew out over the feld and back. It was absolutly amazing how much it gained from the new throttle curve.

I've plotted the new throttle curve and you can see it here:

The new throttle curve doesn't sound so angry like the one before. Compared to the throttle curve Wolfgang implemented in Trunk it still allows optimal hoovering at around 50% and it still allows to reach the maximum throttle by using a steeper gradient in the end which exactly reaches the maximum all the time. The new throttle curve has a parameter L which allows to lower or elevate the curve for different motors while still keeping the input maximum at the maxium output.

After the movie session I took another round and flew until my 5000mAh and my 2500mAh batteries were empty. It was great!

Furthermore I have to mention that I started on my new "fixcoordinate" branch. It will try to decouple nick and roll from yaw and would allow to fly differently.

Imagine flying into one direction while yawing all the while around your own yaw axis? Or a fly-by while the copter turnes to keep one side directly orientated towards another object?

If this sound interesting to you, read my enhancement ticket on dev.uavp.ch. It describes the idea in detail.

Ah, and last but not least:

Are you interested in helping us?
Would you like to become an UAVP Developer?

If so, check out the page How To Become UAVP Developer on dev.uavp.ch!

As I wrote in my last blog we got our IOGEAR Class 1 Bluetooth Serial Adaptors. Cracking the case was easy and within minutes the bare board lay before us.

At first we paired it with our PC and got a COM43 as our Bluetooth COM port. We then first tested the adapter with the power supply and our proven RS232 cable. We were able to receive the startup message of the UAVP but we were not able to send characters to it at first.

A short investigation showed that the adaptor needs RTS and CTS connected to be able to send characters to a device. So we soldered a new SUB-D-9 plug with RTS and CTS connected. Using this plug the connection worked perfectly and we were able to control the command line of the UAVP via Bluetooth!

In detail it looks like this:

Sadly UAVPSet, the great configuration software Thorsten wrote for us, only shows COM1 to COM9 and seems not to be able to use COM43. I wrote Thorsten about this and I hope he will be able to fix this. It would be very cool to be able to flash via Bluetooth!

Later on we mounted the adaptor (back in his case) to the UAVP:

We also expect a lot of knowledge from debugging information captured while flying via Bluetooth!

We finally came round to hack the Wolferl software. As promised in ticket #7 we implemented a throttle curve for UAVPs with overpowered motors like ours.

The implementation was streight forward and when we finally realized that IGas does not get reset on each cycle but only when the RC interface receives a new value the hack was done within minutes. Tuning the throttle curve graph took a while longer.

This is what we came up with:

Implementation of the above throttle curve took place in revisions r170 and r171 in the subversion repository.

A short test and debugging session followed. During that time we plottet the IGas input and output values to see how our new throttle curve is behaving.

As you can see the new curve starts steeper (while we did not yet reach flight velocity) and a while (at 75) before we reach flight velocitoy (which is around 110-120) the new throttle curve starts to have a gradient of 1/2. This allows for a lot smoother control of the motors.

When we finally came round to a real flight test of the new patch we found out, that we were very successfull! Flying our overpowered motors has become a lot easier as you can see in the following short movie which we made while testing:

We are pondering now, if we shall extend the throttle curve to a more general form where 3 different grantends and one free location of gradient change can be choosen or if the orginal solution is fine enough for everybody like it is.

We will see... further tests will follow.

Last but not least I need to tell you of my newest gadget. It's a Class 1 Bluetooth Serial Adaptor from IOGEAR. I've already cracked the housing and made some pictures of it.

This is the top:

and the downside:

It should be a able to do Bluetooth to RS232 forwarding up to 100m. We will see if it does it as promised. I found one problem. It's powered by a 6V/0.3A power supply. I need to find a way to generate that power on-board.

There will surly be a way... :)

Yesterday we re-soldered everything on our two boards. After having seen sudden changes in behavior, perfect first flights and terrible second ones, we decided to have a closer look at our soldering on the board.

Further inspection discovered several unclean soldering pads which we corrected.

And guess what happened today? Our UAVPs flew perfectly and without these erratic changes in behavior! We were both able to fly our 5000mAh batteries to the end!

Now, before I write down too much, have a look yourself at our testflights of today!

The first movie shows my brothers flight. Something went amiss with the FLV encoding, so I would propose to download the WMV file... it of better quality anyway!

In the second movie you can see the testflight of my own UAVP. As you can see it flys a lot more stable and controlled than the last few times! It seems that a lot of the problems we had have their cause in unclean soldering.

My newest testflight was very successful if one ignores the unclean landing at the end...

I think both our UAVP are now stable enough to start playing with the software. As you can see in the enhancement ticket queue on dev.uavp.ch I have several ideas I would like to try out and eventually merge to the main trunk, if the implementation gets stable enough.

I'm sorry it took so long to write my next blog entry, but we were quite busy debugging our UAVPs and fixing problems.

But let's start at the beginning. As you all know we had 2 big problems. First, we had to set the yaw integral to zero and second the whole UAVP had a tendency to flip.

After long investigations with sepcially hacked debug firmware (written by Wolfgang) we finally could isolate the flip problem. It turned out to be quite simple... Since the motors never should stop, we had a sort of lowest level of thrust we allow the motors. Now if the UAVP needs to stabilize it speeds up one motor and slows down a second. Should it happen, that the motor slowing down reaches the minimum allowed speed, we keep it at that and do not allow it to go lower.

BUT, the second motor speeding up we allowed to go faster! This resulted in a inbalance which in turn escalated to flipping the UAVP!

Fixing this was simple... if we have to limit the motor slowing down, we also limit the motor going faster. Wolfgang implemented this simple fix and the UAVP does not flip anymore.

I still ponder if this is the best solution. Imagine a "dynamic throttle adjustment" which will increase the throttle as soon as the motor slowing down crosses the limit. Increasing the throttle would increase the spinning of all motors allowing the motor slowing down to be able to do so!

I think I will try to implement this solution sometime.... I made a enhancement ticket on our new UAVP development server dev.uavp.ch.

Small sidenote: You can reach the new UAVP development server under all the UAVP domains dev.uavp.de, dev.uavp.at, dev.uavp.ch and dev.opensourcequadrocopter.de

The second problem concerning the compass could be fixed quite easily as well. Wolfgang had used a fixed constant value of 16 to correlate the compass's and the yaw-integral's influence. Reduncing this value to 8 or 6 corrected the problem. So it really was a sort of fight between yaw-integral and compass. Wolfgang made this value configurable.

But back to the last test flights. Using the newest firmware (a pre-3.13 version) my brother was able to fly for as long as 6 minutes, which is one of our longest flights.

But watch for youself:

We hope to fix the last problems soon. Then nothing will hold us back from flying up to 20 minutes with our 5000mAh batteries. And there are as big as 8000mAh batteries available out there. I think the weight will be no problems on ou overpowered UAVPs...

Hammer, another UAVP enthusiast, released a new movie today!

It shows his UAVP flight capabilities as well as a stunt, where he flies over water while he's still using the IDG300 sensors which have quite some temperature dependence and which theroretically could get irritated by the temperature difference between air and water.

As you can see, his UAVP flys a lot more stable and is better controllable than ours. He's using smaller motors with less power which allows him to hoover a lot easier.

We completed the last flights for today. I can say, we are back in the air!

Setting the gier integral value to zero worked wonder! Everything is back to normal and as long as you do not make too great movements with the sticks everything works fine.

It seems that the new software version 3.12 has problems with large stick movements so I switched on the "Specky-Bit" which reduces nick and roll signal to half the normal maximum.

Today I was able to complete my testflights without loosing a propeller!

Now watch my newest testflights:

As you can see it's stable enough again to try some outdoor flights. Sadly the weather seems to play bad and we hope to be able to fly outside to the end of the week.

Now that our UAVP fly again, eventually we can try to work on the software. I have several ideas I would like to try to implement. Attitude stabilization, coordinate translations using the compass, throttle adjustments and special throttle courves, GPS support, it all should be possible...

Today we continued our testflights. We still want to eliminate the periodic movement we have on the gier acis. We tested a lot of different parameters, bigger and smaller integregrals as well as no dampening by setting the differential values to zero.

It all seemed to no avail. We had that periodic movement all the time exept when we started perfectly so that no gier correction seems neccessary. As soon as some movements on the gier axis starts the periodic movement never ends again.

Strangly my brother does not experience this problem through he experiences another problem which I have as well. Suddenly without cause the whole UAVP flips or extremelt starts correcting in one of the nick or roll axis. This most often results in a crash or even a broken propeller.

We taped my tests again. You will see our testflights with the 3.12 software using different integrals and no differential. Later on we raised the differential parameter as well in the hope to dampen the periodic movement. In the last scene I rolled back to the 3.11 software to see if the periodic movement exist there as well but as you can see on the movie, it does not exist in the 3.11 software which let's us guess that the problem has something to do with the compass support which 3.12 introduces.

Interesting is that my brother is able to fly 3.12 without a periodic movement on gier, but on the other hand, his gier seems not to be very stable and we saw turn arounds of 180 degrees!

This where my testflights:

Later on we powered up my brother's UAVP and did further tests. It seems that the perodic movement of the gier axis can be eliminated by setting the integral value of the gear closed-loop control to zero.

More tests showed that even a value of one in the gier integral will result in small periodic movements.

Following we show yoy the later testflights my brother did. They were quite successful as you can see! Setting the gier integral to zero seems like a very good idea at the moment!

I think this movie shows quite good that the new setting with the gier integral value of zero is at least a good fix for the moment to counter the priodic movement problem.

The testflights from yesterday clearly showed the need for parameter tuning. So we dedicated today purely to finding the best parameters.

The be short, we failed. After much testing and tuning we can say, that we did not find the best parameters and even have more problems than yesterday.

Yesterday we noted that our gier was periodically swinging. So we tried to fix this today and had to notice that as soon as the gier integral gets a bit bigger the periodic swinging starts. Even when we configured a differential part of 80. Only reducing the integral part to -3 ot -5 helped and even then we had a small periodic movement on our gier.

Furthermore we now have a aperiodic tremble on nick and roll. We tried to compensate with a bit of differential and less proportional, but we could not eliminate it fully.

It seems our parameter tuning turned out to be a bad idea. On the whole the UAVP flies less stable than yesterday and we do not know why.

The problems started with the upgrade to the version 3.12 of the software. It's clear that the changes in the software required changes in the parameter (compass support & differences in P & D calculations of the closed-loop control). But up to now we could not find really perfect parameters.

Here come some movies of our testing today.

First we show you the flip my brother got today. We do not really know what caused it:

Next I show you some of my testflights. If you watch carefully, you see the tremble on nick and gier as well as the periodic movement on gier:

The result of my last flight was another broken propeller...

We will ponder the results of today tests and the try to fix the parameter debacle.
Expect more to follow...

Today the newest testflights have take place! I have to raport that our piloting skills are growing from non existant to the point of being quite miserable...

My brother was the first starting today and he was partly successful. His start was a bit shaky but when he got into the air he stayed there for a little while. Aproaching the trees he looses orientation and starts to correct into the wrong direction crashing streight into the bushes:

Then the problem arose how to recover the UAVP. It seemed lost in quite dense bushes which my brother didn't seem to mind and rushed trough them searching for the missing UAVP. In a short period of time he found it and brought it back:

After this my brother was out of the game for now and my time began...

I started my UAVP quite good and was able to hoover for some time in front of me. Then the UAVP aproached me a bit too much and I tried to stear against. This resulted in such a big changing angle that I automatically panic like an amateur and counter-steered even more in the other direction. It seems I steered a bit too much...

... the results were 1.5 loops and a defty crash:

After this I was out of the game and my brother who meanwhile recovered and fixed his dented UAVP took over. This time his flight was much more controled. He was in the air for a long time and finally landed when his battery run out:

The conclusions are that the new version 3.12 of the Wolferl software definitivly behaves different that the version before. The changes in the paramter P and D resulted in a very different flight behavior and will result in much parameter changing for us.

We both definitivly need more differential on the gier axis (it's oscilating!) and I surly need to lower the integral part of nick and roll, I don't want such a fast reaction to my flight control failures. And furthermore we both want to lower the proportional values of nick and roll too.

We will tune our settings and try out more in the days to come!
Expect more of the story here in my blog.

As you all know we are ready for the first test flights.

We want to keep you posted, so we thought we would not let you miss our latest experiences even trough they were not that successful and even a bit embarrassing. It seems piloting an airship is not such an easy endeavor for untrained guys like us, even trough the closed-loop control stabilizes and helps a lot! Things like mass, velocity and inertia keep you quite busy piloting an UAVP...

Sunday was a bad day for us test pilots... We went to the football training ground which we elected as ideal start place. On the way there we had to notice that there was quite a bit of wind (later that night a small storm hit our area). Silly us we decided to fly anyway...

First, Taarek tried to fly and crashed when he bounced on the ground and his antenna touched his rotor. If you listen carefully you hear the "click" when the antenna hits the rotor and gets cut in half:

Later on I tried my own luck and went into the air with my own UAVP. I was no more successful than my brother and crashed after 22 seconds:

Something went terribly wrong. When I touched the ground you hear the beeper start and then my motors stop and it crashes. It seems as if I lost my battery or my receiver when I crashed. having switched it off and on everything is fine again. I can not yet really explain what happened.

Next we will upgrade our UAVP software to version 3.12 which will support the compass. This will make sure the UAVP's orientation will be stable all the time, since the compass is a reference sensor with no integral error.

Be sure to hear more about our next flights in my next blog entry!

It flies! It flies!

But let's start at the beginning...

After having built our UAVP as described in my last article, today we fixed the last problems and did the first testflights indoors!

Everything went well after we fixed some bad soldering on Taarek's board and after having found out that one of the sensors of my own board was not sitting streight.

We made a small movie showing Taarek's UAVP flying in my living room:

Then finally, when it was nearly dark, we went out for the first outdoor testflight! There was barly enough light to make some camara pictures and so we failed to put the first outdoor flight on movie tape... :(

But to give you an insight in what went on, take a look at these outdoor pictures!

My own UAVP stands ready for it's first integral outdoor flight:

And up it went! As you can see it really flies:

And it can gain height quite fast, I was astonished myself:

And here you see Taarek's UAVP standing ready for it's first real outdoor testflight:

And it jumped into the air as well:

Then we needed to change our location since it was too dark for unexperienced pilots like us. We went up to the street, where there's some light from the street lamps.

Taarek successfully completed several flights near the street in front of the next building:

These first testflights were very successfull and showed the considerable potential of these UAVP constructs!

We were astonished about their ability to gain height within a very short time and about their considerable agility in the air. They are so agile that we even feared several times to crash accidentally against trees, buildings and the like, just because we could not assess how fast the UAVPs change direction, height or orientation.

Be sure to hear more about our next flights in my next blog entry!

As the honored reader probably already knows we finished flight controller and frame. For those new to the story I must mention that in my last two blog entries I talked about the construction of the flight controller and then described how we built our frames.

Our UAVPs already started to resemble quadcopters.

So next we started mounting the four brushless motor controllers which we intended to use. Both UAVPs will use YGE30 brushless motor controllers which are able to handle current up to 30A and should be fast enough for a quadcopter with 54cm diameter.

This will allow us to use a wide range of motors:

We added the flight controller in the middle of the frame and we put some Klett bands under the frame to be able to attach the Lithium ion polymer battery pack we intend to use:

When all connectors and power cable were connected it looked like this:

The second UAVP looks similar:

Next we started pondering the problem of crashes and how to protect the fragile flight controller from impact forces.

To be sure to have the electrics protected all the time we designed a sort of cap for it which surely will absorb some of the impact should it happen to fall on it:

Looking at it on the second UAVP it shows how tightly everything fits:

Mounting the Lithium ion polymer battery pack did not take long.

Finally ready to for flight we connected the serial connection to our laptop and started to tune the flight controller's parameters for it's PID closed-loop controls:

Here is another detail picture:

The second UAVP with mounted Lithium ion polymer battery pack looks similar:

With this we finally finished the construction of our two UAVPs. All pre-flight checks check out and it seems the two quadcopters are fully functional and ready for flight.

The new frames and flight controllers will have to prove themselfes in their first flights. I will tell you more about success or failure of our test flights in my next blog entry!

As I told you in my last blog, we successfully finished two fully functional Wolferl flight-controller boards for our future UAVPs:

Next we wanted to build two stable and strong frames for our quadrocopters.

We bought several four cornered aluminium poles which we used to build a aluminium cross by milling notches into the middle of the poles so that they fit seemlessly. We then secured them in their place by scews and small aluminium plates which we drilled holes into accordingly.

We built two different frame types, one built from solid aluminium poles and one built from hallow aluminium poles.

The hallow variation has a weight of 232g and looked like this:

The solid cross weights 524g and looks not really different:

As you can see the weight difference is nearly 300g so we decided to use the hallow version for our first try on a frame.

Next we drilled holes for the motor anchorage and mounted the motors:

One of the two UAVPs will use Hacker 20-20L motors with EPP 1045 propellers which will give it a thrust of over 600g per rotor. This will result in a total thrust of over 2.4kg for all four of them. Our expected total weight will be around 1kg so we will have some 1.4kg thrust in reserve:

The second one uses AXI 2217/20 motors and looked like this at that stage:

It's motors will do also around 600g thrust per motor with the same total thrust of 2.4kg:

With mounted EPP 1045 propellers the Hacker version looked like this:

Next we unmounted all motors again and started building some landing gear for the quadcopters:

In the end we went for a simple contuction which will also help absorbing some of the deformation energies of hard landings:

When we combined the frame and the landing gear it finally started to resemble something like a quadcopter:

This will serve as a frame for our future UAVPs.

The next step to completion will be adding all the powerlines and mounting the flight-controller in the middle of the construct.

I will tell you more in my next blog entry!

In the beginning it all started with a visit to CCC's 23C3 Congress end of last year where we saw a Microdrone in action. I wrote about that visit and our exceitment about the advances in closed-loop control in this blog entry.

Following the visit to 22C3 we discovered the comercial product X-UFO and bougth one immediately:

Later on we discovered the UAV Community on the network. Several Open Source projects have been very successful in creating their own version of a Universal Aerial Video Platform. Most notable are Wolfgang's UAVP , Holger's MikroKopter and last but not least the Paparazzi Project.

After long forum inquest and even longer discussions with my brother we decided to join the fun.

At first, we did not have any parts to build something, so we started simple by playing with the main processor of the UAVP Board. The board implements the flight stablilization closed-loop control using a PIC microprocessor, which I put on my experimental board to play with:

To be able to work professionaly on the project we cleaned up my workplace and prepared everything. Note the nice digital storage oszilosope I own now... :)

We got the first parts for our own UAVP two weeks ago from several german shops:

Over time all the other parts except for the frames were finally delivered and we started the construction of our own UAVPs.

It seems that the frame producer has big troubles delivering in time, so we decided to build our own frames. We still hope to receive the ordered frames sometime in the future. This makes sense, since we want to build several UAVPs and for that we need more than one frame...

We then started to work on the flight controller board. It's all implemented using SMD, so everything is quite small and complicated to hold and place:

Two days (and nights) later, we finished the two boards finally convinced that we burned most of the parts to hell and that the two boards will never work as expected:

But who would have belived it?

One of the boards worked perfectly immediatley, the second one we got to work after finding one badly soldered pin. This is near perfection!

Normally such SMD boards get made with a method called reflow soldering, which is something we can't do easily at home. I have to mention that this is not a complicated SMD board to solder for an experienced person, but to us doing this for the first time it was a real challange!

It looked adventurous when we checked out the boards:

The small green plates you see at horizontal and vertical angles on the board are the sensor breakout boards used by the flight-controller to stabilize the horizontal position of the flying UAVP.

So we finally got two working flight controller boards for our future UAVPs.

There's still the question of a frame to use and how to build it...
... but I will tell you more of our Quest in my next blog entry soon to follow!

Holger, one of the most advanced UAVP pioniers, released his newest Microcopter video showing his Microcopter standing in the air for several minutes using GPS while recording a movie of Holger sitting at a table an playing with his son.

It seems Holger's closed-loop control of his Microcopter reaches perfection! Except for the small moves which the Microcopter needs to do to correct and hold it's position in the wind it stands still in the air!

Take a look at this technical wonder by yourself:

Today Holger coupled his Microcopter with a GPS Sensor. He did this in a quite simple way and the used closed-loop control will swing up. That doesn't mean it's not impressive! It already shows how it would work. Please note how often Holger is not controlling the Microcopter! Long times it flys autonomiously!

May I present Holger's show:

Hammer, another UAVP enthusiast, released a new movie today! It shows his new UAVP setup using Hacker A20-L20 motors. It seems that Hammer's UAVP has won quite some agility and power! The sound of the motors is quite impressive too.

The movie shows quite good how powerful these motors are.

I already talked about different implementations of UAVPs. One of them, the Wolferl-Board, is a UAVP built by Wolfang Mahringer, one of the pioneers of QuadCopters. Wolfgang succeeded in building a successful flying UAVP closed-loop control already back in January 2006.

The following picture shows Hammer's QuadCopter using a Wolferl-Board:

Wolfgang continuously extended and improved his board design troughout the last year and it's now a very reliable base platform for building an UAVP. Many successful flying UAVP are built usinging a Wolferl-Board as base.

The day before yesterday I wrote a mail to Wolfgang asking if I could receive a copy of the software which runs on a PIC microcontroller in the center of the board. I could not belive it, but already some hours later I received the source code (version 3.05) from Wolfgang!

Thank you Wolfgang! For the great work you did, for the source code, for making it Open Source and available to everyone!

The big black chip in the center is the 8bit microcontroller PIC 16F876 built by the company Microchip. Note that it has a 8bit data bus but 12bit code and address bus which is a bit special.

The PIC16F876A features 256 bytes of EEPROM data memory, self programming, an ICD, 2 Comparators, 5 channels of 10-bit Analog-to-Digital (A/D) converter, 2 capture/compare/PWM functions, the synchronous serial port can be configured as either 3-wire Serial Peripheral Interface (SPI) or the 2-wire Inter-Integrated Circuit (I2C) bus and a Universal Asynchronous Receiver Transmitter (USART). It can be programmed in C and all needed development tools are free of charge which is something which suits me very well.

Dear interested reader, this is the thingy which runs the C source code I've received from Wolfgang. The code gets compiled into a .HEX file which then can be programmed into the PIC.

Looking into the code I realized that I got quite a nice bit of software here. Wolfgang's code is good documented and has a README explaining how to setup the free IDE MPLAB and the CC5X compiler needed to generate code for the PIC. The compiler integrates nicly with the IDE.

Wolfgang also wrote a very nice PDF documentation how to build a Wolferl-Board. This document contains plans, layouts and everything needed to build a Wolferl-Board by yourself.

Digging the code I realized that the code contained a command interface implemented using the serial console on the board which I understud quite easily. Using that serial console you can send commands to the board and control certain aspects and parameters of the closed-circuit loop. Soon I realized that it would be quite easy to extend this command interface with new commands.

I decided to implement new commands to continously monitor all sensor and actor data using the serial port. Furthermore I wanted to implement another command using which the 4 motors of the QuadCopter can be remotly controlled. This is exactly what David, who is an UAVP enhusiast also, chatted about on IRC last week.

I started last night and in the morning around 0500 I could compile the code on my own box and understud how to add new commands. It's now work in progress, but I think it won't take too long to finish...

Expect more information about this project soon...

In my last article I talked about Holger's Microcopter which uses a barometric sensor to measure air pressure to stabilize it's altitute. You can imagine that air pressure only differs minimal between a place 1m higher and another place 1m lower. So the sensibility of the air pressure sensor has to be very high to be able to recognize small altitude changes.

Such high sensibility has it's pitfalls and it seems to be fun to test them out. Holger found out that opening a door while flying indoors already results in such a big air pressure change that the Microcopter would race through the floor or roof if the linear acceleration sensors would not compensate!

Holger released a new video showing his indoor experiments...

In my last article I wrote about the inherent stability problem of QuadCopters and how closed loop control of modern electronics is able to compensate and stabilize it to make it possible to fly and steer such a construct.

Flying a QuadCopter while there is a storm at first sounded impossible to me.

Holger, an inventive guy from the QuadCopter Forum - inventor of the Microcopter - was crazy enough to try and test his Microcopter in a storm. Holger's Microcopter uses barometric sensors to measure air pressure which are used to stabilize the Microcopter's altitiude.

Looking at the movie one realizes, that Holger's Microcopter is up to the challenge and Holger is able to fly it without problems:

Did you ever see a QuadCopter fly? It rocks!

A QuadCopter or UAVP (Universal Aerial Video Platform) looks like this:

One nearly can't belive that such a construct is able to lift into the air! Modern electronic is able to implement impressing reaction times which are needed for such an enterprise!

Such a QuadCopter needs to update the motor power 100 to 300 times per second (100 to 300Hz) to be able to fly stable. This means the electronic has to do a measurement on all sensors all 10ms to 3ms!

Imagine... such a QuadCopter construct is inherently instable!

It's hanging in the air on 4 propellers each driven by it's own motor. The construct, the motors, the propellers - neighter is exactly the same but still the electronics has to be able to compensate and to drive the motors in such a way that the whole construct stands still in the air!

To make my point, take a look at the following small movie, showing a X3D QuadCopter starting and flying some rounds above a field...

I like the idea so much, that i decided to build my own QuadCopter, preferable using a real embedded Linux system on the QuadCopter.

That would allow for a lot of new features, like monitoring the fly parameters via a shell connection using bluetooth as well as logging those parameters. Furthermore it would allow to write the control in software and exchange it with friends easily.

Expect more information and an update to my own construction plans soon!

Today Hammer released another small movie showing the agility of his UAVP. He's playing indoor with fast attitude changes which can play bad games with stability...