MultiWii

The trunk has been now been migrated to use .cpp and .h files instead of the traditional Arduino IDE .ino files. There remains a single "MultiWii.ino" file that will load and compile everything in the Arduino IDE.

For background, see this thread: http://www.multiwii.com/forum/viewtopic.php?f=8&t=2931

Many thanks to casquad and alll for making this possible. They did most of the heavy lifting to get everything converted over.

If you're interested in a turnkey set of Eclipse projects to build the new .cpp/.h code, see this thread: http://www.multiwii.com/forum/viewtopic.php?f=8&t=3775

Anyone got a working makefile for the new layout?
The old set (from original ardupilot I think) which tries to imitate arduino ide style does not understand the ne files layout.
I would like to get my nightly builds working again asap but prefer to avoid double work.

Is this the way MultiWii is headed or is this just a custom offshoot for those that want it?

Curious because as an artist and not a programmer I may not be able to do much with (.cpp) files like I can with (.ino) files.

thank you for this clough42

Alexinparis wrote:thank you for this clough42

You're welcome. Casquad and alll did a lot of the work.

RCvertt wrote:Is this the way MultiWii is headed or is this just a custom offshoot for those that want it?

Curious because as an artist and not a programmer I may not be able to do much with (.cpp) files like I can with (.ino) files.

This is the way forward, and will lead to higher quality code (hopefully) and better separation of functions/drivers/etc.
The original .ino mess of 100s of global variables, etc was not helping proper development at all.

clough42 wrote:

Alexinparis wrote:thank you for this clough42

You're welcome. Casquad and alll did a lot of the work.

I am really happy we got it done, and that everybody see the benefit of it, thought the hardest work has still to be done, "the real reorganization" .
As TC said, a more modular structure, with reusable "pluggable" independent functions, less global variables is needed. Eclipse IDE / CDT will help the developers/coders to hopefully reach that modular "re"-design.
"A new functionality should not compromise the proven working base code"
And when someone implements or come with a new functionality and wants to get it in the trunk, a proper flowchart/documentation should be included so less skilled coders, can understand and add their experience / thoughts to it (eg.: new PID control loop of Alex).

We have a proper developing environment now, let's reorganize the working base code, and only after having this SOLID base, "plug" new independent functionality to it.

Thanks to all (coders and mwii-flyers)

manu (alll)

While we're at it, how about picking a coding style and sticking to that, too?
Could always go for standard K&R indent/spacing, or something like this -
http://state-machine.com/resources/AN_Q ... andard.pdf
Which is pretty close to K&R except function opening { is on same line where K&R its on next line.

Bug probably caused by cpp/h migration (it worked before).
When enabling

I get error while compiling that cosZ is not defined...
The definition is still in MultiWii.cpp

but it seems it does not get properly included.

I'm using Arduino (not Eclipse).

Regards
Andrej

crashlander wrote:Bug probably caused by cpp/h migration (it worked before).
When enabling

Code: Select all

THROTTLE_ANGLE_CORRECTION

Fixed in r1535. Enjoy.

Thank you it compiles now.
But IMO comment is not accurate enough, because that setting increases TH with respect of multi inclination (wind or no wind).

Regards
Andrtej

MultiWii.h


MultiWii.cpp


I suppose other similar cases still exists..., Eclipse will quickly tell you the references

manu

alll wrote:I suppose other similar cases still exists..., Eclipse will quickly tell you the references

manu

Almost certainly. This got through because there is no COPTERTEST that includes it.

That could be fixed. Is someone actively managing the test configurations?

clough42 wrote:Almost certainly. This got through because there is no COPTERTEST that includes it.

That could be fixed. Is someone actively managing the test configurations?

I set up the COPTERTEST when I started automated nightly builds to detect side effects of commits. Everyone is free to extend the suite of tests, only no one ever cared but me.

Just remember COPTERTEST is not meant as a shortcut for your copters but to cover a broad range of features' combinations for compile testing. When your compile breaks after an update but the existing tests do all pass, that is when you have found a good candidate for a new test.

I fixed the script that is hourly compiling trunk and makes the results of various configurations available here: http://sebbi.de/multiwii/

It now auto includes all *.cpp and *.h files found in the base directory besides the *.ino file(s)

@hamburger: I'm using "arduino-cmake" to compile Arduino projects

My generated CMakeList.txt now looks like this:


(last command "generate_arduino_firmware" repeated for all the different configurations)

Please check compilation with

#define SERVO_TILT
#define MEGA_HW_PWM_SERVOS

in a MEGA1280 or 2560

Thanks.

timecop wrote:This is the way forward, and will lead to higher quality code (hopefully) and better separation of functions/drivers/etc.
The original .ino mess of 100s of global variables, etc was not helping proper development at all.

Ok thanks. The longer variable and function names look much more cluttered to me but to each his own. Took a quick look at the trunk>MultiWii_shared cpp files and it doesn't look much different from the ino files so it's all good.

Best of all the Mixing tables in (Output.cpp) looks the same as the former ino file which is great. I'll be doing most of my tests with that section.

Since the code is now easier for you programmers to use, does this mean we will get some Kinect support for close quarters navigation and object recongnition?

Videos...
https://www.youtube.com/watch?v=ZZrmPLas66E
https://www.youtube.com/watch?v=quGhaggn3cQ

"Arduino and Kinect Projects" book...
http://www.barnesandnoble.com/listing/2 ... 6004245623

Hamburger wrote:I set up the COPTERTEST when I started automated nightly builds to detect side effects of commits. Everyone is free to extend the suite of tests, only no one ever cared but me.

I care. I write software for a living, and I don't know how I would do it without a battery of unit tests. The compile-time COPTERTESTs are great.

I've been thinking about how to automate some basic unit tests for something like this, and it's a difficult challenge.

Are there particular areas that have been more brittle than others? Is there something that keeps getting broken over and over?

I'm using avr-libc version 1.8 so prog_char doesn't exist ... I either had to add some compiler flags or change :
void SerialGpsPrint(const prog_char* str) {
to
void SerialGpsPrint(const char* str) {

and I needed to changed :
#if defined(UBLOX)
prog_char UBLOX_INIT[] PROGMEM = {
to
#if defined(UBLOX)
const char UBLOX_INIT[] PROGMEM = {

The const needed to be added even if I went the compiler flags route. This UBLOX_INIT array also generates loads of warnings along the lines of :
narrowing conversion of '138' from 'int' to 'const char' inside { } is ill-formed in C++11 [-Wnarrowing]
changing its type to int removes them all.

There are a couple of quite worrying warnings too :

Line 1296 in MultiWii.cpp
'errorAngle' may be used uninitialized in this function [-Wmaybe-uninitialized]
Line 1261 in GPS.cpp
array subscript is above array bounds [-Warray-bounds]

mgros wrote:Please check compilation with

#define SERVO_TILT
#define MEGA_HW_PWM_SERVOS

in a MEGA1280 or 2560

Thanks.

This issue predates the cpp/h conversion. It was present in r1506.

clough42 wrote:

Hamburger wrote:I set up the COPTERTEST when I started automated nightly builds to detect side effects of commits. Everyone is free to extend the suite of tests, only no one ever cared but me.

I care. I write software for a living, and I don't know how I would do it without a battery of unit tests. The compile-time COPTERTESTs are great.

I've been thinking about how to automate some basic unit tests for something like this, and it's a difficult challenge.

Are there particular areas that have been more brittle than others? Is there something that keeps getting broken over and over?

Glad you like COPTERTEST. Yes, automated testing beyond compiling is challenging. I was keen on using an emulation that had been mentioned earlier but nothing ever surfaced, so I skipped that part.

Most developers seem to fly quad coptertype, so checking for servo related coptertypes could be your first bet. From there it is heuristic; for one I use and care about some features I had implemented; then there are those features which require widespread code fragments & interactions, those are likely candidates; last is all code that is dependant on cpp conditionals in various combinations and locations (for this last thing you can find a small collection of cpp sanity checks in def.h). Overall, tests are following an evolving pre-post scheme, mostly based on intuition (pre) and errors (post).

Another interesting thing to consider now that we're on proper c/h files, is to draw the line where tarduino pro mini support ends, make a branch for that where only bugfixes go into, then remove all #ifdef garbage and turn any further development into tarduino 2560 only.

Sebbi wrote:@hamburger: I'm using "arduino-cmake" to compile Arduino projects

thanks. In the meantime I had adapted my makefile (with arducopter origin). It is mimicking the arduino ide build scheme using an existing arduino ide installation.

timecop wrote:Another interesting thing to consider now that we're on proper c/h files, is to draw the line where tarduino pro mini support ends, make a branch for that where only bugfixes go into, then remove all #ifdef garbage and turn any further development into tarduino 2560 only.

Not sure I agree. Most of my controllers are 328p based. There's a lot of life left in them. And they're cheap.

Perhaps something can be done to abstract the code in a cleaner way?

clough42 wrote:

mgros wrote:Please check compilation with

#define SERVO_TILT
#define MEGA_HW_PWM_SERVOS

in a MEGA1280 or 2560

Thanks.

This issue predates the cpp/h conversion. It was present in r1506.

Anyone can solve this?

thanks in advance

clough42 wrote:

timecop wrote:Another interesting thing to consider now that we're on proper c/h files, is to draw the line where tarduino pro mini support ends, make a branch for that where only bugfixes go into, then remove all #ifdef garbage and turn any further development into tarduino 2560 only.

Not sure I agree. Most of my controllers are 328p based. There's a lot of life left in them. And they're cheap.

I am not convinced either to abandon atmel/arduino. That new target timecop describes he has done already, removing all features he does not like and all hardware support not used for his naze32 (namely garbage?); calling it bogflight. Makes no sense to repeat going that route.

To implement some new mindblowing functionality that used the extended possibilities of bigger hardware, that would be a next step (which none of the higher hardware projects have achieved yet - maybe a 32bit mcu is not up to that task but a real computer with a real OS etc. was needed for this leap). But other projects have demonstrated it is quite possible to support a broad range of target hardware, so why should not we do the same and avoid supporting & backporting separate branches. Support for older atmel/arduino is going to phase out over time in this project, I think.

mgros wrote:

clough42 wrote:

mgros wrote:Please check compilation with

#define SERVO_TILT
#define MEGA_HW_PWM_SERVOS

in a MEGA1280 or 2560

Thanks.

This issue predates the cpp/h conversion. It was present in r1506.

Anyone can solve this?

dunno, but I can look into it over the week.

anyone else got experience with baro code after the migration?
For me it does compile (bmp85) and upload but keeps rebooting. I have not looked into this any further yet.

Hamburger wrote:removing all features he does not like

Really now? ya, lemme go readd support for wii-motion-plus real quick that noone uses.
I'll #ifdef it with indentation, so that no sensible code formatter could make sense of it.
then I'll add #ifdefs in the middle of if() statements, to further confuse things.

This is the kinda shit I'm talking about.

timecop wrote:Really now? ya, lemme go readd support for wii-motion-plus real quick that noone uses...

I like to consider myself a user
Getting my WMP/Nunchuck working with 2.2 has saved me a lot of trouble and eased my transition from (1.7) substantially.

Just bide your time man. They have moved away from the Arduino language and are trying to move away from the Arduino IDE to Eclipse. The writing is on the wall and more movement is being made behind the scenes to do exactly what you are asking for. It won't be long before they ditch the Arduino chip and form factor also.

So shhhhh.... we just can't move too fast since we need Alex on board. Oops, did I say that out loud

RCvertt wrote:Just bide your time man. They have moved away from the Arduino language and are trying to move away from the Arduino IDE to Eclipse. The writing is on the wall and more movement is being made behind the scenes to do exactly what you are asking for. It won't be long before they ditch the Arduino chip and form factor also.

Yep, that sounds like the direction, which is fine with me

Hi,
may I ask for a favor?

I have not much spare time left because of family issues.

Is it possible to make ashort howto/faq on how to set up /compile this and make it a sticky post.

sorry if already happened.

Nils

jevermeister wrote:Hi,
may I ask for a favor?

I have not much spare time left because of family issues.

Is it possible to make ashort howto/faq on how to set up /compile this and make it a sticky post.

sorry if already happened.

Nils

Sure.

If you want to build in the Arduino IDE, check out MultiWii_shared as "MultiWii". Double-click MultiWii.ino. Select your board. Edit config.h. Click build.

If you want to use Eclipse: http://www.multiwii.com/wiki/index.php?title=Developing_in_Eclipse

That Eclipse tutorial seems to be very Windows specific.

Especially these days not everyone (esp. Developers) uses Windows. If MultiWii does not remain platform agnostic, it will shed developers like --- well --- like Windows. If it sheds developers, it's toast.

I build on Linux, and I have access to Mac's but I do not have a Windows machine.

For now, and for at least the near term future, I see that I can still use the Arduino IDE. I have also used Eclipse for other stuff (Android, Java...).

I assume I do not need a replacement for WinAVR, since Linux already has compilers/cross compilers, but I have never built for Arduino on Eclipse. I'm sure I can find that info (If/When) I need to, but I and others would appreciate it if the Wiki was kept as platform-agnostic as possible.

I followed that through for a Mac ... the only thing I did differently was use mac ports to install the avr stuff and had xcode installed (don't know if this made a difference but it was already installed on my machine). Depending on which distribution of Linux you should be able to do something like :

apt-get install binutils-avr gcc-avr gdb-avr avra avrdude avr-libc

Then follow the rest of the instructions.

Thanks, BarneyG, that's helpful. Perhaps someone with permissions could put it in the Wiki.

As I mentioned, I think I will still be able to use the Arduino stuff for quite a while.

I am also not really brave enough to put cutting edge development stuff on my current (only) quad, but I have "messed with" the code a bit (see my other posts), so actually making a helpful contribution is not out of the question.

Perhaps if I find a few hundred $$$ laying around someplace I'll be able to build a second development vehicle.

If someone wants to walk though this on Linux and MAC and send me specific steps, I'd be happy to update the wiki. I have done my best to make this as concrete and clear as possible. There's lots of general information floating around the web, but for the uninitiated, the learning curve to get all the details right can be pretty steep.

I expect the big differences will be in the actual installation, how the AVR plugin finds the command-line tools and the specifics of specifying a port for the programmer. The Eclipse team has done a pretty good job of abstracting most of the rest.

an alternate route is to use Eclipse with Makefile for the project. Works on mac and *ix. I have modified a Makefile originating from arducopter project. It is nice as it searches for and uses an existing arduino IDE for the toolchain and mimics the arduino build process.

linuxslate wrote:That Eclipse tutorial seems to be very Windows specific.

Especially these days not everyone (esp. Developers) uses Windows. If MultiWii does not remain platform agnostic, it will shed developers like --- well --- like Windows. If it sheds developers, it's toast.

Are you fucking kidding?
Disregarding the complete bullshit about windows "dying", have you actually used eclipse? It's cross platform for a reason - all the fucking screenshots in the tutorial apply to your favorite dying OS as well, just the fonts will look much shittier.
Because in 2013, lunix still can't fucking render fonts properly. Yeah, let's move all developers to lunix, maybe someone will develop a proper font rendering engine, it's only taken them 3 decades to get it wrong.

Hamburger wrote:an alternate route is to use Eclipse with Makefile for the project. Works on mac and *ix. I have modified a Makefile originating from arducopter project. It is nice as it searches for and uses an existing arduino IDE for the toolchain and mimics the arduino build process.

Actually it's not nice as arduino uses some ancient gcc, by building with a recent avr-gcc toolchain you get all the benefits of NOT using ancient gcc.

timecop wrote:

Hamburger wrote:an alternate route is to use Eclipse with Makefile for the project. Works on mac and *ix. I have modified a Makefile originating from arducopter project. It is nice as it searches for and uses an existing arduino IDE for the toolchain and mimics the arduino build process.

Actually it's not nice as arduino uses some ancient gcc, by building with a recent avr-gcc toolchain you get all the benefits of NOT using ancient gcc.

http://www.sebbi.de/multiwii uses avr-gcc 4.5.3 while Arduino 1.0.1 uses avr-gcc 4.3.2 (from 2008!!!) ... the result is a smaller binary size (saves almost 1000 bytes on coptertest 3). So yeah, the compiler in the Arduino IDE is ancient :/

viewtopic.php?f=8&t=2931&start=20#p37239
To be quick up and running on most OS's, most is done by the effort of others...
Install Arduino
Install Eclipse C++ for developers (+ eventually Java)
Install the Eclipse Arduino plugin
Install the Eclipse SVN plugin
Test your installation
Get the Multiwii Repository
Check out...

manu
Just a quick feedback there i have no time now, sorry

I think I found a bug ... calibrating ACC from the GUI doesn't work as expected anymore, e.g. it only calibrates every 10-20 button presses. Am I the only one with this problem?

Are you comparing it to version (2.2)?

With 2.2 I noticed I have to hit the GUI acc calibrate button a couple times before the indicator would level out completely. Maybe the calibration time is too short?

Maybe there is a value we can adjust for lengthening the accel and gyro calibration routines to make sure they don't stop prematurely?

Comparing it with 2.2, yes. When I click on "Calibrate ACC" all graphs immediately go to 0 for a few seconds ... with the current trunk the actual calibration doesn't always happen, when clicking the button.

P.S.: There are some side effect with sharing variables over multiple cpp-files, e.g. when I split the GUI code from Serial.cpp the checksum for the protocol wasn't calculated correctly because that variable was used in both files. No amount of "extern" or "volatile" modifiers changed that strange behaviour (the variable definition was visible from both files, otherwise the compiler would have shown an error, right?

Sebbi wrote:

timecop wrote:

Hamburger wrote:an alternate route is to use Eclipse with Makefile for the project. Works on mac and *ix. I have modified a Makefile originating from arducopter project. It is nice as it searches for and uses an existing arduino IDE for the toolchain and mimics the arduino build process.

Actually it's not nice as arduino uses some ancient gcc, by building with a recent avr-gcc toolchain you get all the benefits of NOT using ancient gcc.

http://www.sebbi.de/multiwii uses avr-gcc 4.5.3 while Arduino 1.0.1 uses avr-gcc 4.3.2 (from 2008!!!) ... the result is a smaller binary size (saves almost 1000 bytes on coptertest 3). So yeah, the compiler in the Arduino IDE is ancient :/

You guys may have decided for yourselves to ignore the arduino compatibility. But it is one of the MWii principles still. And it is the sole basis for common development. Bug reports referring to some other compiler than the default one from arduino IDE? I can live without.

I know about the size matter, thank you.

My bug report (regarding Calibrate ACC) happens with Arduino IDEs compiler ... we are not stupid Am I the only one where this happens? Hardware is Arduino mega 2560

And for the future: what is the correct way to file a bug? One thread per bug or as a reply somewhere?

After some debugging, I found out that my FC (Flyduino Mega) may have problems on the serial line as the checksum computation often fails while it doesn't on other FC boards I have :/ Or in other words ... never mind.

Sebbi wrote:My bug report (regarding Calibrate ACC) happens with Arduino IDEs compiler ... we are not stupid Am I the only one where this happens? Hardware is Arduino mega 2560

And for the future: what is the correct way to file a bug? One thread per bug or as a reply somewhere?

Well...turning on issue tracking in the googlecode would be a great way to track defects and feature requests. It would allow others to comment and developers to take ownership and keep track of ongoing work.

Barring that, one thread per issue seems like the best way to not miss something.