Recently in UAVP-NG Category

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!