Making MWC easier to use

AngelEyes · Post by **AngelEyes** » Thu Jan 17, 2013 11:10 am

MWC has done a great job in providing a system that controls flying vehicles, but we have found it a little difficult to get used to. Even though we are satisfied with its performance, we found it slightly inconvenient to use, especially the GUI provided for the configuration.

First of all, to compile MWC, one needs to have some fundamental knowledge of C language, and at the very least, understand what macros are.

Compiling and configuring MWC generally involves the following steps:
1. Commenting and uncommenting some macros or changing the value defined in config.h to choose the type of aerial-vehicle, the motor ideal speed, max/min throttle and so on.
2. Compiling and uploading it to your Arduino board.
3. Running the configuration application MultiWiiConf to configure the flight settings.

: MuitiWiiConf

MultiWiiConf provides a great deal of configuration options in a single UI page. For beginners, it often seems intimidating. Normally, users have to spend a lot of time to truly understand what each button and slider represents, especially the PID settings.

So, we believe that a better organized and a more user-friendly configuration application is needed. For example, we think that it will be more reasonable to set PID easier and user can choose the copter type while configuring it.

After going through the MWC source code, we realized that the code isn’t too complex to understand and the amount of code is not much. So we believe it is possible to make MWC easier to use.

2.jpg: code files of mwc; (13.74 KiB) Not downloaded yet

3.jpg: code file of multiwiiconf; (2.23 KiB) Not downloaded yet

The code of MultiWiiConf is written in Processing, wich is suitable for artists. It isn’t convenient to write complex GUI applications in Proccesing, so we will use C++ and Qt to write the new configuration application.

Our Goals:
1. Simplify the configuration program
a) Create a user-friendly GUI that is easy to get started with.
b) No need to set PID values.
c) No need to check yaw/pitch/roll middle values manually.
d) User can choose the copter type in the configuration program.
2. Reconstruct the MWC code
a) MWC will be modified to adjust for the new configuration application.
b) Reduce support to some specific sensors and gyroscopes.
c) Refine the flight algorithm, if possible.

3. Develop special flight control board and power/status display module
We aim to create a control board that is robust and cheap
Reserved I/O:
a) Roll、Pitch、Yaw、Throttle
b) Flight mode Control Input
c) Gimbal control output
d) GPS I/O
e) Power/status I/O

Power/status display module
a) Status led、buzzer
b) The module that makes the power voltage down to the voltage suitable for Arduino
c) USB programming interface

Contribution:
Under GPL V3 license.
Code hosted on github
….

Development Language and Frameworks:
C/C++, Arduino, Qt.

Rewards based on your contributions:
T-shirt
Notebook
Flight control board
Multicopter

This is our another open source project, RC Touch, https://github.com/angel-eyes/RC-Touch/commits/master.

weisseruebe · Post by **weisseruebe** » Thu Jan 17, 2013 12:40 pm

Hi Guys,

this is very creditable. But I'm not sure if it will be better to make a complete new project out of that - or (even better in my opinion) contribute at one of the great existing projects like MPNG.

One thing I really like concerning MWii is the overall simplicity of the code.
Since the Gui is Processing / Java and is written in a very simple way, it is pretty easy to understand, even for beginners. QT / C++ isn't that easy at all. It is much more complex to setup a build environment and to understand the Code. Creating and distributing a stable application in QT for Windows / Linux / Mac isn't that easy (see QGroundControl!).
The GUI is exactly ONE file. In terms of proper software engineering, this is normally seen as a nightmare. But it is just a GUI, and it works. And it is easy to compile, easy to understand, easy to distribute. If I would have the time to do work on MultWiiConf, I would take the Java Code, bring it to Ecplise, and split it to several classes, or I would build a new Java Application based on the old code (With RXTX, SWT or Swing).

I'm working as a Software engineer and I have some years of experience with Java, QT and Arduino. But I also learned that well-engineered solutions often become too complex. Sometimes, a beginner's code was much easier to maintain and to understand than the code of an experienced professional. See Roberto at FPV-Community. He developed a very well-working alt-hold algorithm, he posted his changes as ZIP-Files, and he's not a professional. I'm afraid that a more complex ecosystem with QT, GitHub and a more complex code would chill people like him.
And it can be very frustrating to set up a QT build environment with all that dependency stuff.

When I read through the MWConf-Code the first time, a red alert in my brain came up saying "REFACTOR!!!". But then I thought: Wow, that works, I understand it pretty well. I would have done that in a very different (better????) way, but as long as it works....

MultiWii is a great project, and in my eyes, it lives from simplicity and from people's will to understand what's going on. There are many projects which don't require basic coding knowledge and PID-Tuning (KK, Naza etc.).

tovrin · Post by **tovrin** » Thu Jan 17, 2013 3:43 pm

first, let me say, cool, i am excited to see what you develop. thats the beauty of open source, and I'm always excited about new ideas.

now, allow me to describe my experience with MW.

I am an electronics engineer by training, a Sr IT field tech by trade. I got into quadcopters because I wanted to do something uncommon (2 years ago when i got started multirotors were not near as popular as they are now). I had never used an arduino before, but bought one (the wrong one for this project initially) and learned to program it, learn to build a BoB and attach the motors to it. learned to adapt existing code to my own needs (by commenting and uncommenting etc) and then finally learned to build my own frame, balance props, and get into the RC side of it, long before i ever got to fly it. this is my first adventure in flying anything besides tiny indoor helicopters.

i have only ever used MW, so i cant vouch for the differences in other open source software for flight controllers, but if i hadn't done things int he order and learned the intimate details of my bird, its construction, its software, I wouldn't be as excited about continuing this project as i am. I now have 2 birds i fly, a small (250mm) 1600Kv acrobird, and my soon to be FPV/photo bird (850Kv 450mm) i started with, and am also building a baseflight 32 bit flight controller using timecops software. this is what i do, i love doing it, its very relaxing to me.

I understand that not everybody enjoys doing the build part like i do, they just want to fly, and I'm not certain those are the people for MW, maybe hoverfly is what they need, a lot expensive, but stable and easy right out of the box.

I believe that creating your software is going to provide plenty of challenges due to the nature of the MW software, unless you build it to support your flight controller only (which suddenly sounds like APM), as the ability to use almost any sensor configuration, as well as frame configurations and TX/RX setups is what makes MW so versatile and so complex.

Eric · Post by **Eric** » Thu Jan 17, 2013 3:55 pm

Glad to see you moved the post from 5imx here.

As I mentioned there, you have to take some time reading multiwii code.

To make the copter type configurable, you have to:

1. Dynamic logical/switches for all copter types, this might cause performance issues.

2. Compile all copter/modules code into the final binary, this is almost impossible. As most Arduino board does not have enough storage.

MultiWii conf is really simple and straightforward. It is not the GUI is to complex, it's the user have to know some basis about MultiCopter.

About the PID, it is the only logical required from human. And the default values works for most setup. The user has to take some time to make it BETTER!

Maybe multiwii can be changed to be more intelligent to avoid crash due to really bad PID values.

Yes, multiwii does lacks documents. Especially in Chinese.

In other words, multiwii is great, just needs more time to understand it. For me.

I guess you can contribute to the documents. ;-)

jy0933 · Post by **jy0933** » Thu Jan 17, 2013 4:32 pm

i will still suggest to make this a BRANCH of master... a dedicate fork is good... but it wont benefit the master to help more people out or make it easier for people other than your users.... which might ended up like some RuBBIT(sh) FC that totally ditch origin....

it is not difficult or hard to use MWC.. but the documentation is not elaborated enough for users to understand what should be done to make the best out of MWC. For example, the PID tuning in wiki is ok.. but there are problems not illustrated like why it is hard to maintain hover(pid setting, I too high usually)...
furthermroe, for example level pid

P is the dominant part of autolevel mode.
I will tell how much force must be applied when the mesured angle error persit
D is used to clamp the maximum correction for autolevel mode

only P looks understandable... I,D? not so much

the PID requires a deeper understanding of the code. which is not going to happen to most of users... If you really want to help... documentation/tutorial will be a fairly good start for you guys

it is always welcome to make some improvement.. for EVERYONE

AngelEyes · Post by **AngelEyes** » Sun Jan 20, 2013 6:36 am

Thanks for your reply.

Perhaps QT/C++ is not a good idea for beginners to get started with, and might frighten beginners away. But I think that people with some background will not have a lot of problems with this.

Our goal is making MWC easier to use. Using more sophisticated techniques can lead to a more easily maintainable code, a more easily upgradable system and a user-friendly configuration program.

Reconstructing by Java is also a good choice and we will consider this approach.

Naza does not require one to configure the PID settings while still have the vehicle fly stably.I guess the roll/pitch/yaw sensitivity settings is a high level package of PID in Naza. Perhaps Naza has an algorithm to learn the optimal PID, since its brain is a 72MHz ARM CPU.

AngelEyes · Post by **AngelEyes** » Sun Jan 20, 2013 6:39 am

tovrin wrote:first, let me say, cool, i am excited to see what you develop. thats the beauty of open source, and I'm always excited about new ideas.

now, allow me to describe my experience with MW.

I am an electronics engineer by training, a Sr IT field tech by trade. I got into quadcopters because I wanted to do something uncommon (2 years ago when i got started multirotors were not near as popular as they are now). I had never used an arduino before, but bought one (the wrong one for this project initially) and learned to program it, learn to build a BoB and attach the motors to it. learned to adapt existing code to my own needs (by commenting and uncommenting etc) and then finally learned to build my own frame, balance props, and get into the RC side of it, long before i ever got to fly it. this is my first adventure in flying anything besides tiny indoor helicopters.

i have only ever used MW, so i cant vouch for the differences in other open source software for flight controllers, but if i hadn't done things int he order and learned the intimate details of my bird, its construction, its software, I wouldn't be as excited about continuing this project as i am. I now have 2 birds i fly, a small (250mm) 1600Kv acrobird, and my soon to be FPV/photo bird (850Kv 450mm) i started with, and am also building a baseflight 32 bit flight controller using timecops software. this is what i do, i love doing it, its very relaxing to me.

I understand that not everybody enjoys doing the build part like i do, they just want to fly, and I'm not certain those are the people for MW, maybe hoverfly is what they need, a lot expensive, but stable and easy right out of the box.

I believe that creating your software is going to provide plenty of challenges due to the nature of the MW software, unless you build it to support your flight controller only (which suddenly sounds like APM), as the ability to use almost any sensor configuration, as well as frame configurations and TX/RX setups is what makes MW so versatile and so complex.

The information you posted is so useful.

"The wrong one for this project initially", does it mean that the speed and 16KB Flash of Arduino has becomed a bottleneck of the more outstanding MWC? We will choose the 32bit ARM platform.

The interest is one of the power to support us to go further, we like DIY step by step, but many people don't like this, they just want to enjoy the fun of flying. Why not let us take the pleasure bringing more fun to other people.

What kind of sensor is better? Now, the price of sensors is much cheaper than two years ago, we can chose some new specific cost-effective sensors. Repeating the whole creation of APM is a very bad idea, we will collect more information to make our vision more broader and finally determine the reasonable scheme, and avoid making the wheel again.

We think making MWC easier to use is very interesting, and we also konw that we will face many known and unknon challenges, but we believe that this goal can be achieved finnally.

AngelEyes · Post by **AngelEyes** » Sun Jan 20, 2013 6:43 am

Eric wrote:Glad to see you moved the post from 5imx here.

As I mentioned there, you have to take some time reading multiwii code.

To make the copter type configurable, you have to:

1. Dynamic logical/switches for all copter types, this might cause performance issues.

2. Compile all copter/modules code into the final binary, this is almost impossible. As most Arduino board does not have enough storage.

MultiWii conf is really simple and straightforward. It is not the GUI is to complex, it's the user have to know some basis about MultiCopter.

About the PID, it is the only logical required from human. And the default values works for most setup. The user has to take some time to make it BETTER!

Maybe multiwii can be changed to be more intelligent to avoid crash due to really bad PID values.

Yes, multiwii does lacks documents. Especially in Chinese.

In other words, multiwii is great, just needs more time to understand it. For me.

I guess you can contribute to the documents.

Ha ha, very surprised to come across a friend from 5imx.

Maybe Arduino's execution speed and 16KB Flash storage have become the bottleneck of the more outstanding MWC, so the 32bit ARM platform is the right way.

For most people, easy to use means it's pretty good.

"It's the users who have to know some basic knowledge MultiCopter. ", I think it is more suitable for those who love the DIY game. But most people don't care how the engine is made at all, they only want to go driving.

We are glad to have a chance to make contributions to the MWC document, and let more people enjoying the fun of MWC flight.

AngelEyes · Post by **AngelEyes** » Sun Jan 20, 2013 6:45 am

jy0933 wrote:i will still suggest to make this a BRANCH of master... a dedicate fork is good... but it wont benefit the master to help more people out or make it easier for people other than your users.... which might ended up like some RuBBIT(sh) FC that totally ditch origin....

it is not difficult or hard to use MWC.. but the documentation is not elaborated enough for users to understand what should be done to make the best out of MWC. For example, the PID tuning in wiki is ok.. but there are problems not illustrated like why it is hard to maintain hover(pid setting, I too high usually)...
furthermroe, for example level pid
P is the dominant part of autolevel mode.
I will tell how much force must be applied when the mesured angle error persit
D is used to clamp the maximum correction for autolevel mode

only P looks understandable... I,D? not so much

the PID requires a deeper understanding of the code. which is not going to happen to most of users... If you really want to help... documentation/tutorial will be a fairly good start for you guys

it is always welcome to make some improvement.. for EVERYONE

We think that in order to make MWC simpler and easier to use we have to sacrifice the flexibility of MWC. But it will always be under the GPL. It's not gonna be another RuBBIT(sh).

We will collect more information to make our vision broader and finally determine the reasonable scheme, and avoid making the wheel again.

PID is one of cores of a flihgt control, so we will do more work on it.

We are glad to have a chance to make contributions to the MWC document, and let more people enjoy the fun of MWC flight.

Hamburger · Post by **Hamburger** » Sun Jan 20, 2013 10:41 am

who exactly is this 'we' you keep repeating?

alll · Post by **alll** » Sun Jan 20, 2013 3:20 pm

Yes ? , who are actually the "lead" developers of mwii, the ones that have something to say what gets in and what is not?

Hamburger · Post by **Hamburger** » Sun Jan 20, 2013 5:50 pm

alll wrote:Yes ? , who are actually the "lead" developers of mwii, the ones that have something to say what gets in and what is not?

Technically everyone with write access to the repository,.on second order it is up to Alex to decide upon general project principles..this came up before you may read here if you got some time to spare http://www.multiwii.com/forum/viewtopic.php?f=8&t=1516&p=15878&hilit=hamburger+eosbandi#p15878

AngelEyes · Post by **AngelEyes** » Mon Jan 21, 2013 6:58 am

We are HeX, http://hex.angeleyes.it.

MultiWii