news

Development of version 4 started

(23.12.2014)

What does it mean? It means complete rework of AP core. Till now all was running in one loop. This has two disadvantages:

1. Unpredicable time of each task
2. One blocked task will block all others

So, new design wi create lets say "pseudo scheduler" which split AP to 1HU and 2HU.

AP 1HU will be running in real time sheduler part (from timer interurpt) and will be responsible for all needed to flight (RC, sensors, PID, IMU). Simply said, when loop is blocked, machine shall be still able to fly.

AP 2HU will be the rest (lights, GPS, EEPROM, MCP, ...).

This real time concept has following advantages:

1. More simple PSD regulators (with constant sample time) can be used instead of actual PID
2. 2HU shall not have influence on capability to fly (a little more save code).

Interesting idea

(20.12.2014)

As a biggest pain of servo gimbals is their shaking and jittering. It is almost impossible to find servo without this problem. Question is, how to use cheap servo without this uggly behavior?. Servo is simple regulator where action unit is motor and its position is measured as voltage on divider which is used as feedback for regulator. So what about to use cheep servo mechanics but drive it by by our FCU through PWM and A/D? It looks that I have something to think about during christmass ;-)

Important bugfix!

(14.12.2014)

Important bugfix of accelerometer and gyroscope calibration released in version 3.2.0. Code before this bugfix may cause serious problems in MPU initialization and either in some cases in flight!

Started work on new generation

(4.12.2014)

Because of incoming ARM based boards (NAZE32) it looks that AVR based versions are slowly dying. This is also the reason why I decided to support only Crius AIOP compatible boards. This means that a lot of unused code can be removed and simplyfied significantly. This also allow to implement more new features much easier way.

I also decided to digress completely from MultiWii and start development of a new software and features. However I'll try to keep MultiWii communication protocol supported as long as possible. Following features are planned in further development:

• New JAVA based GUI extended by new functionality (e.g. console).
• New UI will be capable to use simple console for easy tweaking and setup
• Started development of real time "pseudo scheduler" to separate first HU of AP from the rest of code.

and many other things, according to my spare time ;-)

Possibility of tuning PID directly from RC

(29.8.2014)

PID tuning is sometimes really complicated and time consuming. You have to connect PC or your Android phone to copter, change PID values, disconnect, fly and watch how it behaves and then everything again and again till tuning is done. I was thinking how to make this procedure as simple as possible.

Best option from my point of view is to be capable to change PID values in flight, so I prepared so called "in flight PID tuning". This feature can be switched on if you define RC_PID_TUNE macro in config.h file. Within this macro you can define AUX channels of your receiver which will directly tune P, I and D controller part. Which controller/regulator will be used is then selected by suitable check box. If you don't have enough AUX channels, you can define some unused for parts which can be tuned later by standard method, e.g. AUX5 for D part of controller.

Tuning is then very simple. You can select by check box which one of PID regulators will be tuned. When machine is armed, PID tuning is activated. This means that board remeber actual AUX values. When you change this values e.g. by potenciometers on your RC, suitable P, I or D part of controller is changed. You can adjust all parts of PID controller in flight. When you are done, you simply disarm machine and new values are written to EEPROM. Thats it ;-)

Of course when you come home, you should connect your copter to PC and load and store PID settings to file to be able to restore them when EEPROM is erased due to firmware update.

Added MegaPirate NG alternative

(29.8.2014)

I found this project also very well coded and I like the style how is it written. Therefore I decided that I'll make eclipse project also for it. Almost all required functionality is done in ArduPilot, but sometimes there is need to change a little in Crius HAL (e.g. when you want to use super simple gimbal with mixed servos). Therefore eclipse project has been created to do such work much more simple.

Measure current and voltage together - already done

(17.8.2014)

Current measurement unfortunately can not be done so easily, because error of difference measuring is much higher then measured value. Well, it seems that external current sensor is needed in all cases.

Measure current and voltage together

(12.8.2014)

So OSi-HEX is almost done (yesterday was first test flyght) and I got idea to use two A/D converters on Crius AIOP board to measure voltage and current together. In principle it should be simple, only third cable should be connected from node close to battery to first A/D. Second will be connected from input of one of BEC to second A/D. Current and voltage is then callculated from difference between this this two A/D coverters (higher difference means higher current and voltage can be fixed to get real value on battery). I created new issue/task so we will see when there will be time to do that ;-).

Hybryd chopter/plane

(28.7.2014)

My custom testing platform a'la HEX spider is almost finished. I have some hardware from first test quad platform which was unfortunately weak (weak motors and batteries), so I started thinking what to do, how to extend flight time to get more tha 4 minutes. I got inspired here and also here, so I started with creation of new frame QUADW as Quad Wing. Current existing models are flying in acro mode only, but I want to make it flyable also for beginer pilots. It should fly in horizon mode and mode chopter/plane shall be selected by toggling checkbox. So we will si how it happen ;-)

New concept started

(24.7.2014)

First version which go in directon more far from original MultiWii sources. Amount of configuration has been reduced, so only MEGA based boards are supported now and only multirotors are supported. Also prepared space for serial protocol extesion in in future.

New test platform

(7.7.2014)

When I started this project, my main aim was to create some stable code for FPV machine. Now I started building of one hopefuly powerful, but also designed to cost. Configuration will be called osi_hex and some plans can be downloaded here.

Supported boards

(15.6.2014)

After some time of exploring MultiWii codes I found that there is really huge amount of supported boards. Currently it is more than 60. Is impossible to maintain so many boards without possibility to prove functionality of all of them.

Therefore I decided to support only few MEGA based boards, where only Crius AIOP will be tested by me and the rest stays without waranty. This should significantly reduce code complexity and makes maintanance and implementation of new features much more easy.

This does not really mean that I don't want to support another boards. I want to use HAL based concept, so use of new board in future is not impossible. Intention is that only HAL (Hardware Abstraction Layer) must be created for this purpose and no other changes in code are needed.