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

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

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

This is a small plan of the Helengeli island itself:

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

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

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

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

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

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

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

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

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

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

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

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

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

Then more near...

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

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

And they did not shy in any form...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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!

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.

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!

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!

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.

I'm back from holidays! My girlfriend and I went to Marsa Alam at the Red Sea for a week. Staying at the Oasis Hotel, we visited the Sinaidivers dive center there and went diving for 5 days.

On the first day I've meet Tim, an old friend from Sinaidivers in Sharm el Shaik. He was doing holidays in Marsa Alam before we arrived and afterward helped out in the dive center for the next three weeks.

In the last three days we went two times to Elphinstone, a famous dive cite near Marsa Alam. Elphinstone is a Shaab, meaning an offshore reef near the coast of Marsa Alam just east of the Oasis hotel. It's a difficult dive site with the sea going down to 200m at all sides.

In summer you can find a lot of Tiger sharks there. We hoped to see them, but sadly the season was already over and they left the reef. But we were lucky: In autumn the Oceanic White Tip shark season just began!

We were able to dive two times at the Elphinstone reef, each time reaching the reef by zodiac. Both time we did a marvelous dive at the reef and tried to spot the sharks. The first time we did not find them while diving, but coming back to the zodiac the sharks suddenly showed up!

They like stuff swimming at 5m or even at the surface of the sea. They are very intelligent and they like to investigate stuff swimming in their district. Being already in the zodiac and jumping back into the water, I forgot to bring my cam with me. Luckily Tim had his own cam with him and was able to record a small movie of the shark!

But look for yourself:

Two days later we visited Elphinstone a second time by zodiac. This time we brought 15L tanks with us, giving us approximatly 50bar air more. This allowed us to do a 1h 15min dive!

Since we did not find the sharks on the west side of the reef the first time, we decided to jump in at to north tip and do a drift dive on the whole east side of the reef. Having 15L tanks allowed us to dive the whole length of the reef... it's quite long. We even had enough air to let us drift out into the blue for 15 minutes at the end of the reef!

We did not find the sharks at the east side of the reef the second time either, but having enough air with us we just drifted out into the blue staying at 5m while putting up a surface marker buoy to make sure no zodiac drives over our dive site.

It did not take long and the Oceanic White Tips found us!

At first a big one showed up in front of us, quite far away. We saw it for half a minute or so until it disappeared again into the blue. At the same time Michael, one of the divers accompanying us, spotted a second shark behind our back! The second one was a bit smaller and it seemed to us as if the first, big one tried to sidetrack our attention so that the attack of the second one succeeds! The second one came as near as 3m or so and I was able to shoot some very very nice pictures of him!

Here it comes behind our back:

... just turns at our side:

... decides that we are no lunch:

... and leaves again:

Be sure to notice the Pilot fishes at his side! Both swim behind the fins of the shark! That way they can keep away from its mouth. They do that as soon as they notice that the shark is hungry, to make sure not to become lunch! Furthermore both bust fins are pointed downwards which gives the shark maximum maneuverability when attacking.

Looks like it thought we could be a fine lunch and then decided against it when he was near. We were 5 divers near together so probably we seemed to big to attack to him.

I heard that two weeks ago a girl was not so lucky and an Oceanic White Tip took a bite of her arm while she was trying to get onto the zodiac. That's the most dangerous moment, when the diver is not paying attention and the sharks sees the most perfect prey pattern he's used too: penguins trying to get into an ice floe. But normally nothing happens if the divers are paying attention. One just should keep an eye on them and bang them on the nose if they get uncomfortable near you.

All in all it was a wonderful dive!

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!

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.

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.

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.

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.