MultiWii roadmap for 2.3

This forum is dedicated to software development related to MultiWii.
It is not the right place to submit a setup problem.
Software download
Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

MultiWii roadmap for 2.3

Post by Alexinparis »

This is topic to list the functionalities I would like to see included in multiwii for the next release 2.3
Some of the functionalities already exist at a beta stage and are not yet integrated.
Some of them come from the whish list.
Some of them come from different feedback.

Multiwii is an open source project and everyone is free to modify the code for its own purpose or suggest some code.
But everyone should also understand not everything can be included in the official release for many reasons: it’s a hobby and devs have personal affinities with some functionalities, so they tend to code only what they are interesting in / reading other contributions takes a lot of time whatever the quality of the code / adding a contribution always require a significant amount of time to conceptualize the optimum merge (avoid duplication / re organize some parts, …)

So the next question is: who decides what is included or what is not included in the official release :
for specific parts than have no or minor impact on the whole project, multiwii google code committers or me
for structural changes impacting the whole code. In fine, me Alex.


My personal view of what is mandatory for 2.3 :

- refactor the YAW PID to have a KK yaw style feeling.
This is a need I saw many times. Multiwii was basically an acro plateform and the yaw control has always been a weak point comparing to other platform (even if it performs quite ok) I think it should be an easy task to change.

- refactor the file layout : keep only one .ino file, and move to a .h or .h/.c structure
Keeping a compatibility with Arduino IDE is mandatory. This is personally the only tool I use for developments since the beginning. So minimizing the number of file is still an objective to be still compliant with this IDE.
Advantage: we are no more tied to Arduino lexical file order inclusion for the sketch compilation / using another IDE should be much more easier / might also make easier other proc port project as less than 10% of code is very processor specific.

- refactor some variable structure: my first tests show we can save a little bit more than 1k flash size in MSP serialization process just by using fine structs.

- uniformize servo usage in the code for every needs.
The purpose is to be able to use a servo in the mixer table in a generic way, just like we use currently motors.

- introduce configuration of servo in GUI (we have to discus every aspects: endpoints, midpoint, direction/proportion/ maybe other)

- allow the configuration of more variable in the GUI
How to cope with the genericity need: how to add a new parameter with a minimum impact in the GUI.

- refine the vario mode
With an objective comparison of what is really needed regarding code complexity.

- introduce RTH + failsafe and autoland

- headfreemode based on GPS direction from home

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: MultiWii roadmap for 2.3

Post by Hamburger »

Could we _aim_ for a next release in 3 months from now please? Not really binding but just as an intention.
Release early and r3lease often.

Frans-Willem
Posts: 6
Joined: Tue Mar 05, 2013 10:36 pm

Re: MultiWii roadmap for 2.3

Post by Frans-Willem »

If you want to split up the source nicely, please please please don't go with just sticking code into header files.
Do it the nice C way:
For each component have a C file with the source code, and a H file with the definitions of functions/struct/etc that should be accessible from other components, and then let the linker do it's job.
Don't treat your code like one big block of text split over multiple files (for example by just concattenating them together with #include), but think of it like seperate components and let the linker link them together for you.
I also recommend wrapping your header files in an #ifdef _HEADER_H, #define _HEADER_H, #ifndef block (where HEADER_H is obviously the header filename) to prevent it being included twice. (e.g. you have A.h and A.c which define some functions, you have B.h and B.c which define some new functions, and use A.h, and then you have C.h and C.c which uses both A and B. without the ifdefs, A's header would be included twice, which will mess up).

User avatar
dramida
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest
Contact:

Re: MultiWii roadmap for 2.3

Post by dramida »

About yaw authority:

1- I have to remember that GPS positioning is less than 30% accurate when yawing. This precision when yawing would help to a better aerial panorama function.

video with an earlier version- hexacopter
http://youtu.be/Jx80YNWy_n4?t=41s

video with mwc 2.1 and tricopter
http://youtu.be/2GpTA8-glQs?t=3m2s

2- If you hand launch MWC armed with motors off, there is a yaw overflow witch make the copter spin uncontrolably. See video. Tried twice with same results. Maybe an overflow in yaw error accumulation.
http://youtu.be/bCrAMUykk1o?t=22s

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: MultiWii roadmap for 2.3

Post by EOSBandi »

Introducing AtMega2560 only functions, such as :
Waypoint navigation - Have to write a state machine that handle navigation (this will be the part of the GPS code refactoring)
Dataflash support for in-flight data logging - Already done, just need to eliminate classes becuse for some reason classes are condemned evil....
Last edited by EOSBandi on Mon Mar 11, 2013 11:15 am, edited 1 time in total.

Sebbi
Posts: 478
Joined: Sun Jul 08, 2012 1:08 am
Location: Germany
Contact:

Re: MultiWii roadmap for 2.3

Post by Sebbi »

Generic telemetry functions to send data to different receivers (FrSky, HoTT, Telnet or data logger, like suggested by EOSBandi) would be nice to have on such a roadmap when code is already being rearranged.

alexia
Posts: 85
Joined: Sun Jun 17, 2012 10:23 pm
Contact:

Re: MultiWii roadmap for 2.3

Post by alexia »

data loging seem to be a great feature..GPS improvement will be already a great 'step

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: MultiWii roadmap for 2.3

Post by EOSBandi »

Alex :
I'm happy to donate you a full boxed Visual Studio 2012 Pro, if it helps you to move away from the arduino IDE...

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: MultiWii roadmap for 2.3

Post by Alexinparis »

Frans-Willem wrote:If you want to split up the source nicely, please please please don't go with just sticking code into header files.
Do it the nice C way:
For each component have a C file with the source code, and a H file with the definitions of functions/struct/etc that should be accessible from other components, and then let the linker do it's job.
Don't treat your code like one big block of text split over multiple files (for example by just concattenating them together with #include), but think of it like seperate components and let the linker link them together for you.
I also recommend wrapping your header files in an #ifdef _HEADER_H, #define _HEADER_H, #ifndef block (where HEADER_H is obviously the header filename) to prevent it being included twice. (e.g. you have A.h and A.c which define some functions, you have B.h and B.c which define some new functions, and use A.h, and then you have C.h and C.c which uses both A and B. without the ifdefs, A's header would be included twice, which will mess up).


I knew this debate will happen :mrgreen:
Ok, this is how an academic c code should be structured.
I read systematic .c + .h structure is mainly an advantage because .c could be compiled separately as obj and does not need to be recompiled each time a mod is done somewhere in the code. Interesting for huge project or for libs or for purists

But please look at this mwc spin-off code and tell me the drawbacks to have only .h files ?
https://code.google.com/p/mwc-ng/source ... comp%2Fsrc

scrat
Posts: 925
Joined: Mon Oct 15, 2012 9:47 am
Location: Slovenia

Re: MultiWii roadmap for 2.3

Post by scrat »

EOSBandi wrote:Alex :
I'm happy to donate you a full boxed Visual Studio 2012 Pro, if it helps you to move away from the arduino IDE...

So how we will then upload our code to fc with Arduino or something else?

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: MultiWii roadmap for 2.3

Post by Alexinparis »

dramida wrote:About yaw authority:

1- I have to remember that GPS positioning is less than 30% accurate when yawing. This precision when yawing would help to a better aerial panorama function.

video with an earlier version- hexacopter
http://youtu.be/Jx80YNWy_n4?t=41s

video with mwc 2.1 and tricopter
http://youtu.be/2GpTA8-glQs?t=3m2s

2- If you hand launch MWC armed with motors off, there is a yaw overflow witch make the copter spin uncontrolably. See video. Tried twice with same results. Maybe an overflow in yaw error accumulation.
http://youtu.be/bCrAMUykk1o?t=22s


I think a new YAW PID implementation could only correct the 2-

1- might be improved currently thanks to the new angle calculation (currently in 2.2), but I think the problem is deeper

scrat
Posts: 925
Joined: Mon Oct 15, 2012 9:47 am
Location: Slovenia

Re: MultiWii roadmap for 2.3

Post by scrat »

Alexinparis wrote:
dramida wrote:About yaw authority:

1- I have to remember that GPS positioning is less than 30% accurate when yawing. This precision when yawing would help to a better aerial panorama function.

video with an earlier version- hexacopter
http://youtu.be/Jx80YNWy_n4?t=41s

video with mwc 2.1 and tricopter
http://youtu.be/2GpTA8-glQs?t=3m2s

2- If you hand launch MWC armed with motors off, there is a yaw overflow witch make the copter spin uncontrolably. See video. Tried twice with same results. Maybe an overflow in yaw error accumulation.
http://youtu.be/bCrAMUykk1o?t=22s


I think a new YAW PID implementation could only correct the 2-

1- might be improved currently thanks to the new angle calculation (currently in 2.2), but I think the problem is deeper


You can check the code from kapteinkuk for YAW. ;)

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: MultiWii roadmap for 2.3

Post by EOSBandi »

scrat wrote:
EOSBandi wrote:Alex :
I'm happy to donate you a full boxed Visual Studio 2012 Pro, if it helps you to move away from the arduino IDE...

So how we will then upload our code to fc with Arduino or something else?



It will still compile in arduino ide fine, but with an advanced IDE you can separate the functions into separated source files, and you can lift the ban on adding new source code files.... :D

scrat
Posts: 925
Joined: Mon Oct 15, 2012 9:47 am
Location: Slovenia

Re: MultiWii roadmap for 2.3

Post by scrat »

EOSBandi wrote:
scrat wrote:
EOSBandi wrote:Alex :
I'm happy to donate you a full boxed Visual Studio 2012 Pro, if it helps you to move away from the arduino IDE...

So how we will then upload our code to fc with Arduino or something else?



It will still compile in arduino ide fine, but with an advanced IDE you can separate the functions into separated source files, and you can lift the ban on adding new source code files.... :D


Thanks EOS.

fiendie
Posts: 151
Joined: Fri Apr 20, 2012 4:22 pm

Re: MultiWii roadmap for 2.3

Post by fiendie »

EOSBandi wrote:Alex :
I'm happy to donate you a full boxed Visual Studio 2012 Pro, if it helps you to move away from the arduino IDE...

I know Visual Studio is a great IDE but if there is a move to officially support another IDE it should probably be something open like Eclipse with the AVR-Eclipse plugin.

The plugin wraps uploading code to the target MCU with avrdude (which is everything the Arduino IDE does).

Plus, you could just put working config/project files in the repo. I tried that with baseflight with some success.

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: MultiWii roadmap for 2.3

Post by EOSBandi »

Alexinparis wrote:
Frans-Willem wrote:If you want to split up the source nicely, please please please don't go with just sticking code into header files.
Do it the nice C way:
For each component have a C file with the source code, and a H file with the definitions of functions/struct/etc that should be accessible from other components, and then let the linker do it's job.
Don't treat your code like one big block of text split over multiple files (for example by just concattenating them together with #include), but think of it like seperate components and let the linker link them together for you.
I also recommend wrapping your header files in an #ifdef _HEADER_H, #define _HEADER_H, #ifndef block (where HEADER_H is obviously the header filename) to prevent it being included twice. (e.g. you have A.h and A.c which define some functions, you have B.h and B.c which define some new functions, and use A.h, and then you have C.h and C.c which uses both A and B. without the ifdefs, A's header would be included twice, which will mess up).


I knew this debate will happen :mrgreen:
Ok, this is how an academic c code should be structured.
I read systematic .c + .h structure is mainly an advantage because .c could be compiled separately as obj and does not need to be recompiled each time a mod is done somewhere in the code. Interesting for huge project or for libs or for purists

But please look at this mwc spin-off code and tell me the drawbacks to have only .h files ?
https://code.google.com/p/mwc-ng/source ... comp%2Fsrc



Although it looks ok, there are usually several drawbacks:
-A free (defined outside a class scope) non-inline function in a header file will be compiled any time a source file include such header (and this will give you a linking error). And this also adds include order dependency.

-Using header files with definitions and .c files with the source will make platform separation, and automatic source code documentation easier.

-It induces header cascades. Code in headers will probably need some other header to be included, which will need another header and so on.

Header files commonly do not contain any data definitions (ie. those that reserve memory), as this could result in multiple instances of the same symbol being declared in different files, which would cause linker resolution problems. It also may be unclear who 'owns' the item. Similarly, executable code in header files is to be avoided (other than in macros). By insisting that header files are completely passive, causing no memory to be reserved for data or for code, readers and users can be confident that no definitions are 'invisible' to them.

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: MultiWii roadmap for 2.3

Post by timecop »

Alexinparis wrote:I read systematic .c + .h structure is mainly an advantage because .c could be compiled separately as obj and does not need to be recompiled each time a mod is done somewhere in the code. Interesting for huge project or for libs or for purists

But please look at this mwc spin-off code and tell me the drawbacks to have only .h files ?
https://code.google.com/p/mwc-ng/source ... comp%2Fsrc


Because header files are not for code.
Especially not in C.
Plus it helps you to define a clean interface for each C-based module if you only export functions/structures/etc you require from them.

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: MultiWii roadmap for 2.3

Post by EOSBandi »

fiendie wrote:
EOSBandi wrote:Alex :
I'm happy to donate you a full boxed Visual Studio 2012 Pro, if it helps you to move away from the arduino IDE...

I know Visual Studio is a great IDE but if there is a move to officially support another IDE it should probably be something open like Eclipse with the AVR-Eclipse plugin.

The plugin wraps uploading code to the target MCU with avrdude (which is everything the Arduino IDE does).

Plus, you could just put working config/project files in the repo. I tried that with baseflight with some success.


I'm not starting a platform War. Anything else than the Arduino IDE is better. BUT most of the current bans and limitations are coming from the fact that Alex is using the Arduino IDE for development. Moving to another IDE will/should maintain Arduino IDE compatibility (best example is the Ardu code, which still compiles under Arduino IDE).

However ATM the best free alternative for Windows is VS2012Pro+Visual Micro+VisualSVN.

QuadBow
Posts: 532
Joined: Fri Jan 04, 2013 10:06 am

Re: MultiWii roadmap for 2.3

Post by QuadBow »

timecop wrote:However ATM the best free alternative for Windows is VS2012Pro+Visual Micro+VisualSVN.


Maybe Visual Micro is available for free, but that does not apply for MS Visual Studio Pro, doesn't it?
And Visual Micro will not run with Visual Studio Express as to my knowledge and experience.
I am also suffering from the Arduino IDE but I still haven't found any alternative as to it.

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: MultiWii roadmap for 2.3

Post by EOSBandi »

QuadBow wrote:
timecop wrote:However ATM the best free alternative for Windows is VS2012Pro+Visual Micro+VisualSVN.


Maybe Visual Micro is available for free, but that does not apply for MS Visual Studio Pro, doesn't it?
And Visual Micro will not run with Visual Studio Express as to my knowledge and experience.
I am also suffering from the Arduino IDE but I still haven't found any alternative as to it.


Visual Studio Pro is available for free via the WebSpark program.
A

scrat
Posts: 925
Joined: Mon Oct 15, 2012 9:47 am
Location: Slovenia

Re: MultiWii roadmap for 2.3

Post by scrat »

But arduino works on all platforms.

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: MultiWii roadmap for 2.3

Post by copterrichie »

scrat wrote:But arduino works on all platforms.


+1 and not linked to MS.

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: MultiWii roadmap for 2.3

Post by EOSBandi »

copterrichie wrote:
scrat wrote:But arduino works on all platforms.


+1 and not linked to MS.


Guys, you are missing the point totally. I'm not trying to link anything to MS or any other thing. All I want is to convince Alex to not to use the Arduino IDE as his development enviroment. If somebody else can convince him to use Eclipse it also fine. I proposed VS since it is the easiest way to do Arduino development in a state of the art IDE (while keep compatibility with the actual arduino) and you can get the user experience within minutes.
(install VS2012, install Visual Micro and VisualSVN, open VS, set where your arduinio ide is installed, open->Arduino project.... and there you are.)

It was my last post regarding IDE, I promise. The offer is still valid...

QuadBow
Posts: 532
Joined: Fri Jan 04, 2013 10:06 am

Re: MultiWii roadmap for 2.3

Post by QuadBow »

EOSBandi wrote:install VS2012, install Visual Micro and VisualSVN, open VS, set where your arduinio ide is installed, open->Arduino project.... and there you are.


I understood from the MS homepage that only Visual Express or the trail version (for 3 months) are free.
The homepage directs to some local dealers offering Visual Studio Pro for hundreds of euro.

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: MultiWii roadmap for 2.3

Post by Hamburger »

I am with eos all the way.
Alex has maxe it clear that whatever dev layout and environment will be used, compatibility with arduino ide must be maintained.
Good. The choice of dev environment is mostly personal taste from there. I will most likely stick to eclipse and some tailored makefiles, but it simply should not matter.
The layout of files/code should follow our needs for changing and adding functionality, not any academic abberations please.
That is all my requests to this - I would prefer to not waste much time discussing this matter..

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: MultiWii roadmap for 2.3

Post by copterrichie »

My only point was and is, MS has a clear history of giving stuff away for free, killing off the competition then charging outrageous prices for their products once the competition is gone. If a person wants to use VS or Eclipse (my choice) that is a personal choice but we need to keep the lowest common factor. Lotus or WP anyone?

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: MultiWii roadmap for 2.3

Post by EOSBandi »

QuadBow wrote:
EOSBandi wrote:install VS2012, install Visual Micro and VisualSVN, open VS, set where your arduinio ide is installed, open->Arduino project.... and there you are.


I understood from the MS homepage that only Visual Express or the trail version (for 3 months) are free.
The homepage directs to some local dealers offering Visual Studio Pro for hundreds of euro.


Go here : http://www.microsoft.com/web/websitespark/webpro/
register as a individual developer, you will get VS2012pro plus a bunch os other goodies....

fiendie
Posts: 151
Joined: Fri Apr 20, 2012 4:22 pm

Re: MultiWii roadmap for 2.3

Post by fiendie »

copterrichie wrote:My only point was and is, MS has a clear history of giving stuff away for free, killing off the competition then charging outrageous prices for their products once the competition is gone. If a person wants to use VS or Eclipse (my choice) that is a personal choice but we need to keep the lowest common factor. Lotus or WP anyone?


What he said.
This wasn't supposed to be a platform war. Just a matter of simplicity. If you want to maintain support for another IDE, pick one that runs on every platform. Maintaining Arduino compatibility with (AVR-)Eclipse is as easy as it would be with VisualStudio.

Sebbi
Posts: 478
Joined: Sun Jul 08, 2012 1:08 am
Location: Germany
Contact:

Re: MultiWii roadmap for 2.3

Post by Sebbi »

EOSBandi wrote:
QuadBow wrote:
EOSBandi wrote:install VS2012, install Visual Micro and VisualSVN, open VS, set where your arduinio ide is installed, open->Arduino project.... and there you are.


I understood from the MS homepage that only Visual Express or the trail version (for 3 months) are free.
The homepage directs to some local dealers offering Visual Studio Pro for hundreds of euro.


Go here : http://www.microsoft.com/web/websitespark/webpro/
register as a individual developer, you will get VS2012pro plus a bunch os other goodies....


From Microsofts homepage ...

Since Microsoft is making these powerful new resources available to you without cost, the WebsiteSpark program will no longer be accepting new membership applications.


And it's only about web stuff ... Visual Studio 2012 Pro isn't going to be the tool for everyone (since it is expensive). Eclipse is free and available on all platforms.

RCvertt
Posts: 172
Joined: Fri Sep 14, 2012 11:45 am

Re: MultiWii roadmap for 2.3

Post by RCvertt »

Alexinparis wrote:My personal view of what is mandatory for 2.3 :

- refactor the YAW PID to have a KK yaw style feeling.

-Keeping a compatibility with Arduino IDE is mandatory.


I agree with this. I would add that keeping as much compatibility with existing arduino boards would be helpful also. Namely the ProMini and Mega. I know they don't have all the bells a whistles of some of the other chips but just like the IDE they are easy for non-programmers like myself to use and easy to get. I can go down the street to Fry's electronics and get some.

One ino file with some .h files sounds good to me for keeping the amount of files down. MultiWii has already shown that it is possible to have most of the features that the other Arduino based quad projects have, without the need for all the extra "Library" files and such that make it more difficult for a newb programmer or non-programmer like myself to understand the code.

If you guys make the code easy enough for a non-programmer like myself to read, we can help create some cool stuff also.

I also wouldn't mind seeing bit shifting kept to a minimum as well :)

shufflez
Posts: 42
Joined: Sat Nov 19, 2011 5:26 pm
Location: Amsterdam, Netherlands

Re: MultiWii roadmap for 2.3

Post by shufflez »

To break into the IDE discussion, I'd like to go a little further on an improvement already proposed by Alex.
As I fly 2 units with a gimbal and change them out depending on the need, in addition to the servo changes for Bi/TRI servos I would really appreciate a feature where I can change GIMBAL servo settings in the GUI instead of having to compile new builds each time.

Additionally; I'm not sure this is possible within the Java-based GUI (it has been many many years since I programmed Java last), but maybe it's an idea to implement different tabs/pages like MW-WinGUI?
For example;
1) Radio+TX/RX
2) PID settings
3) Servo tuning
4) Sensor data

Maybe this would eventually enable lower-end devices to use the GUI more easily (for example for use in a field-programming-case), because they dont need to display the graphics data?
Personally I don't have a use for that (field programmer is full x86 tablet), but it might have some benefits for others?

Just spilling some thoughts though... :)

RCvertt
Posts: 172
Joined: Fri Sep 14, 2012 11:45 am

Re: MultiWii roadmap for 2.3

Post by RCvertt »

scrat wrote:You can check the code from kapteinkuk for YAW. ;)
Can you translate his evil Assembly code into something that looks a little more like MultiWii so I can read it? I recall a post from the KK developer where he said he looked at MultiWii code after he was impressed with how much more stable it was than his early KK code so I'm sure he wouldn't mind us taking a little peak under the hood of his ship.

I was able to put the aeroquad heading hold into multiwii (1.7). It looks very promising except for some creep when yawed to the left. Right yaw using the gyros only seams to hold its heading just fin as if a magnetometer was being used. I'm sure I messed up how the current heading is being calculated which is causing the drift.

Sebbi
Posts: 478
Joined: Sun Jul 08, 2012 1:08 am
Location: Germany
Contact:

Re: MultiWii roadmap for 2.3

Post by Sebbi »

Regarding the .c and .h split. Wouldn't it be nice to have all the hardware related stuff done in a library sub folder with clean C++ code? I know I am proposing the impossible, but it is a normal Arduino thing to have and use libraries for hardware functions and reduce the normal code to just the basics like switchOnLightOverThere() or getBarometerHeight() or setMotor(X,Y).

Doing it this way would certainly make it easier to abstract hardware differences for different plattforms (like STM µCs). Of course it should be done in way that there is no code in those libraries that needs to be edited by a user.

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: MultiWii roadmap for 2.3

Post by copterrichie »

Sebbi wrote:Regarding the .c and .h split. Wouldn't it be nice to have all the hardware related stuff done in a library sub folder with clean C++ code? I know I am proposing the impossible, but it is a normal Arduino thing to have and use libraries for hardware functions and reduce the normal code to just the basics like switchOnLightOverThere() or getBarometerHeight() or setMotor(X,Y).

Doing it this way would certainly make it easier to abstract hardware differences for different plattforms (like STM µCs). Of course it should be done in way that there is no code in those libraries that needs to be edited by a user.


I believe if not mistaken, this is how MegaPirate is doing it. In other to compile MegaPirate, you need to download the IDE with Libraries.

fiendie
Posts: 151
Joined: Fri Apr 20, 2012 4:22 pm

Re: MultiWii roadmap for 2.3

Post by fiendie »

copterrichie wrote:I believe if not mistaken, this is how MegaPirate is doing it. In other to compile MegaPirate, you need to download the IDE with Libraries.


And AeroQuad https://code.google.com/p/aeroquad/source/browse/#svn%2Ftrunk%2FAeroQuad%2FLibraries

scanman
Posts: 74
Joined: Thu Jun 21, 2012 9:26 am
Location: Durban, South Africa
Contact:

Re: MultiWii roadmap for 2.3

Post by scanman »

Can we please AVOID the microsoft debate , it is similar to the iphone/android debate and has no ending.

scrat
Posts: 925
Joined: Mon Oct 15, 2012 9:47 am
Location: Slovenia

Re: MultiWii roadmap for 2.3

Post by scrat »

RCvertt wrote:
scrat wrote:You can check the code from kapteinkuk for YAW. ;)
Can you translate his evil Assembly code into something that looks a little more like MultiWii so I can read it? I recall a post from the KK developer where he said he looked at MultiWii code after he was impressed with how much more stable it was than his early KK code so I'm sure he wouldn't mind us taking a little peak under the hood of his ship.

I was able to put the aeroquad heading hold into multiwii (1.7). It looks very promising except for some creep when yawed to the left. Right yaw using the gyros only seams to hold its heading just fin as if a magnetometer was being used. I'm sure I messed up how the current heading is being calculated which is causing the drift.


His :twisted: evil assembly code is already translated into C.

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: MultiWii roadmap for 2.3

Post by EOSBandi »

I'll add two things which are already coded and will commit them to shared after some flight test (code is originating from HAdrian)
- Angle Thrust correction
- Advanced Headfree mode

scrat
Posts: 925
Joined: Mon Oct 15, 2012 9:47 am
Location: Slovenia

Re: MultiWii roadmap for 2.3

Post by scrat »

EOSBandi wrote:I'll add two things which are already coded and will commit them to shared after some flight test (code is originating from HAdrian)
- Angle Thrust correction
- Advanced Headfree mode


Will you please post a video?

alexia
Posts: 85
Joined: Sun Jun 17, 2012 10:23 pm
Contact:

Re: MultiWii roadmap for 2.3

Post by alexia »

EOSBandi wrote:I'll add two things which are already coded and will commit them to shared after some flight test (code is originating from HAdrian)
- Angle Thrust correction
- Advanced Headfree mode



wooo great eosbandi.

Sebbi
Posts: 478
Joined: Sun Jul 08, 2012 1:08 am
Location: Germany
Contact:

Re: MultiWii roadmap for 2.3

Post by Sebbi »

fiendie wrote:
copterrichie wrote:I believe if not mistaken, this is how MegaPirate is doing it. In other to compile MegaPirate, you need to download the IDE with Libraries.


And AeroQuad https://code.google.com/p/aeroquad/source/browse/#svn%2Ftrunk%2FAeroQuad%2FLibraries


AeroQuad doesn't use c++ in it's libraries ... it's basically the .h-files only approach except they are all in the libraries folder so they don't appear in the arduino IDE (but can be seen in other IDEs).

Frans-Willem
Posts: 6
Joined: Tue Mar 05, 2013 10:36 pm

Re: MultiWii roadmap for 2.3

Post by Frans-Willem »

I've sent most of my arguments on this issue to Alex in a PM, so I don't want to waste a lot of text here, but I'd like to make one thing clear:
We're losing track of what we're discussing.
The whole multiple .ino files, multiple .h files, or proper .c/.h files has nothing to do with IDE.
Yes, it's probably a good idea to move to another IDE, but an IDE shouldn't influence how you structure your code.

So, if people would like to discuss IDE's, that's absolutely fine, but please don't make the mistake of thinking moving to .c/.h files would force you to use one IDE or the other:
it might make working with the Arduino IDE somewhat more difficult, but every reasonable IDE (Eclipse, Visual Studio, notepad) will allow you to work this way.

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: MultiWii roadmap for 2.3

Post by Alexinparis »

Hi,

When I say compatibility with Arduino IDE must be maintained, it is especially because it's one of the easiest way to customize config and inject code in an Arduino from a zip sketch.
So the principle Arduino IDE+zip+customize config.h+upload via USB will not change. I strongly thing it's one the the reason Arduino is so successful.
I know there are some limitations (for instance the obsoleted gcc with windows Arduino IDE), and I hope Arduino people will soon or later update the IDE to support the latest gcc, just because the generated code could be even better.

Now I admit it's not the most convenient tool for development.
EOS, thanks for the offer, but I prefer to use open source tool when it's possible to do. (just one more paradox as I use WinXP ;) )
I installed eclipse without special difficulties and will probably use it more and more.
eclipse is an example, and I agree the debate should stay about the code structure, not about the IDE.

Limiting the number of files is probably more a fear from me that everything spreads without control.
So, according to your arguments, one .ino + .c+.h seems the way to go.

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: MultiWii roadmap for 2.3

Post by EOSBandi »

Alexinparis wrote:Hi,

When I say compatibility with Arduino IDE must be maintained, it is especially because it's one of the easiest way to customize config and inject code in an Arduino from a zip sketch.
So the principle Arduino IDE+zip+customize config.h+upload via USB will not change. I strongly thing it's one the the reason Arduino is so successful.
I know there are some limitations (for instance the obsoleted gcc with windows Arduino IDE), and I hope Arduino people will soon or later update the IDE to support the latest gcc, just because the generated code could be even better.

Now I admit it's not the most convenient tool for development.
EOS, thanks for the offer, but I prefer to use open source tool when it's possible to do. (just one more paradox as I use WinXP ;) )
I installed eclipse without special difficulties and will probably use it more and more.
eclipse is an example, and I agree the debate should stay about the code structure, not about the IDE.

Limiting the number of files is probably more a fear from me that everything spreads without control.
So, according to your arguments, one .ino + .c+.h seems the way to go.


Great, thanks ! Case closed... :D Now we can focus on functions and code polish :D

QuadBow
Posts: 532
Joined: Fri Jan 04, 2013 10:06 am

Re: MultiWii roadmap for 2.3

Post by QuadBow »

Sebbi wrote:From Microsofts homepage ...
Since Microsoft is making these powerful new resources available to you without cost, the WebsiteSpark program will no longer be accepting new membership applications.

And it's only about web stuff ... Visual Studio 2012 Pro isn't going to be the tool for everyone (since it is expensive). Eclipse is free and available on all platforms.


Having in mind those recommendation I tried to install eclipse due to the instruction available in the www.
I managed to install the arduino.plugin from http://www.baeyens.it/eclipse/ as well.
However, I am currently struggling with the configuration, since I have to do some settings in Window|Preferences

1. What path do I have to add for the entry "Atmel Part Description Files"?
2. What path do I have to add for the entry "Arduino IDE Path" - the obvious path to adruino.exe is not accepted ?

Any help from the experts who are familiar with this mighty tool is appreciated.

QuadBow
Posts: 532
Joined: Fri Jan 04, 2013 10:06 am

Re: MultiWii roadmap for 2.3

Post by QuadBow »

QuadBow wrote:Any help from the experts who are familiar with this mighty tool is appreciated.

In order to answer my question myself:

QuadBow wrote:1. What path do I have to add for the entry "Atmel Part Description Files"?

This entry is not mandatory. select the path including files like atmega328p.xml within the AVR Studio subdirectories.

QuadBow wrote:What path do I have to add for the entry "Arduino IDE Path" - the obvious path to adruino.exe is not accepted ?

Obviously, the path pointing to the executable arduino.exe. However, the integration to the arduino beta version 1.5.1 I used failed.
With the regular version 1.0.4 eclipse accepts it.

RCvertt
Posts: 172
Joined: Fri Sep 14, 2012 11:45 am

Re: MultiWii roadmap for 2.3

Post by RCvertt »

Alexinparis wrote:Hi,

When I say compatibility with Arduino IDE must be maintained, it is especially because it's one of the easiest way to customize config and inject code in an Arduino from a zip sketch.
So the principle Arduino IDE+zip+customize config.h+upload via USB will not change. I strongly thing it's one the the reason Arduino is so successful...


I think the arduino syntax plus the easy access to inexpensive arduino boards is the reason.

Without the easy to understand arduino syntax there isn't much point in staying with Arduino. The syntax was specifically designed to help those that aren't great with code, make cool things. Hence its popularity. If you stray from the Arduino syntax then those that stay with the project aren't going to care much about the IDE or board that is used.

felixrising
Posts: 244
Joined: Sat Mar 23, 2013 12:34 am
Location: Australia

Re: MultiWii roadmap for 2.3

Post by felixrising »

RCvertt wrote:
Alexinparis wrote:Hi,

When I say compatibility with Arduino IDE must be maintained, it is especially because it's one of the easiest way to customize config and inject code in an Arduino from a zip sketch.
So the principle Arduino IDE+zip+customize config.h+upload via USB will not change. I strongly thing it's one the the reason Arduino is so successful...


I think the arduino syntax plus the easy access to inexpensive arduino boards is the reason.

Without the easy to understand arduino syntax there isn't much point in staying with Arduino. The syntax was specifically designed to help those that aren't great with code, make cool things. Hence its popularity. If you stray from the Arduino syntax then those that stay with the project aren't going to care much about the IDE or board that is used.


Seconded. I'm just learning and keeping the code base in Arduino really helps with the learning curve. I also think any major code overhaul belongs in a major rev 3.x.
IMHO 2.3 should be about new features like nhadrian has been submitting: failsafe improvements like auto-land/improved or fixed rate altitude decent/RTH failsafe, as some examples. Basically what OP said in 1st post + Advanced Headsfree mode and Angle Thrust correction as EOSBandi suggested. :j

kharmine
Posts: 3
Joined: Fri Apr 05, 2013 2:15 am

Re: MultiWii roadmap for 2.3

Post by kharmine »

I'm curious, has the following option ever been considered?

Create a .h header file for each existing .ino file, but don't change the .ino files to .cpp files.
This would maintain compatibility with Arduino IDE, but would also allow the code to be compiled using C/C++ tools such as Eclipse, AVR Studio, avr-gcc, etc., as long as the tool is configured to treat .ino files as .cpp source files. (Or, one could simply rename the files in their local copy.)

(I am new to MultiWii, but I have of C and C++ development experience.)

Sebbi
Posts: 478
Joined: Sun Jul 08, 2012 1:08 am
Location: Germany
Contact:

Re: MultiWii roadmap for 2.3

Post by Sebbi »

For the IDE it makes no difference if files are named .cpp or .ino. But they get compiled differently: INO files will be concatenated while CPP/H will be compiled to objects and linked together at a later point.

Some core functionality could also be implemented using libraries in the library folder (same level as the MultiWii folder in your Arduino sketchbook). They wouldn't appear in the IDE as editable files and could hide technical stuff from the "user" so the Arduino code could look cleaner and would be easier to edit. Other compilers/IDEs can treat it as a directory for includes.

Post Reply