Why development has stopped?

e_lm_70 · Post by **e_lm_70** » Fri Jul 04, 2014 4:22 pm

msev wrote:I really don't know whats the problem that all classic multiwii devs also don't collaborate with baseflight/forks developement directly, because price surely isn't a factor...
Because TC's "STM32 Development Board" which is sort of a STM32 32-bit variant of the Arduino Pro-mini, is only 6$ more expensive than arduino pro-mini. So even for the budget minded I don't see any problem. Even Elm who is a very budget minded person used a similair board .
I'm sure TC+users of naze32 would be happy if useful, properly formatted contributions would be made to baseflight.
Because if you look at the number of pages in the Naze32 threads on various forums (rcgroups,mwii,fpvlab) you see that naze32 is the most popular variant of multiwii derived firmware.

Also why wait for Eosbandi if he log's in just once in a few months , why doesn't one of the lead-devs iron out the very few remaining bugs, and credit Eosbandi properly? So 2.4 could be released

Just a few thoughts.

We have already Baseflight for STM32 ... this is already MultiWii running on STM32 ... at least in my book
STM32 environment is a bit different then MultiWii, so some people familiar on Arduino may not like to move on Baseflight ... also ... for properly compile Beseflight it is need a software that cost around 2000$ in licenses

The question that I have not got a clear answer is: does MultiWii still have a future after 2.4 ... or the mission of the original developer group has been accomplish ?

PS:I think it is fair to wait for EOS, 2.4 sound more a blessing of a work already available in the download page.
PPS: I think that MultiWii on Atmega8bit still make sense and it can still evolve ...

copterrichie · Post by **copterrichie** » Fri Jul 04, 2014 4:27 pm

Personally, I believe few can argue with the Mega328 and the Arduino IDE simplicity for development. Sure, some have complained about the Bitwise shifting but over all, most people attempting any modifications to the code have pretty much accomplished what they set out to do. I also believe other platforms 32bit system developments should run concurrently and personally have a few however, they are not for the Noob programmer in my opinion. What gave MultiWii its popularity is its simplicity and cheap do it yourself hardware and that should remain a constant.

With this said, I would like to see the rebirth of i2c-gps-nav with the ability to handle PWM and PPM-SUM and the actually Navigation (waypoints, RTH and Follow-me etc) handle on it and the course change/modification sent to the main flight controller via MSP-SET codes via the I2C bus. Of course this raises a new set of problems because the i2c-gps-nav operates in Slave mode with the Master polling it to get the current RX information however, I believe these issues can be worked out.

sanity93 · Post by **sanity93** » Fri Jul 04, 2014 4:49 pm

e_lm_70 wrote:We have already Baseflight for STM32 ... this is already MultiWii running on STM32 ... at least in my book
STM32 environment is a bit different then MultiWii, so some people familiar on Arduino may not like to move on Baseflight ... also ... for properly compile Beseflight it is need a software that cost around 2000$ in licenses

How so... If you read the Wiki https://github.com/multiwii/baseflight/wiki/Building-with-Eclipse cost $0

e_lm_70 · Post by **e_lm_70** » Fri Jul 04, 2014 5:01 pm

@copterrichie ... I totally find useless the i2c GPS module (a 328 chip wasted for a dummy task) ... but maybe build up an array of ProMini for make some computation task could be something interesting to explore ... but ... I'm not sure the added complexity of multi processor will really give any edge over a single but more powerful CPU

@sanity93 ... The Baseflight version compiled in a Keil environment (by TimeCop) use 30% less memory then the same code compiled with ARM-GCC ... yes, build up the environment for ARM-GCC is not a big thing (on virtual machine running lubuntu : it is really few sudo install lines) ... set up eclipse and ARM-GCC on my Win8 was long and it did not fully work for me

copterrichie · Post by **copterrichie** » Fri Jul 04, 2014 5:08 pm

e_lm_70 wrote:@copterrichie ... I totally find useless the i2c GPS module (a 328 chip wasted for a dummy task) ... but maybe build up an array of ProMini for make some computation task could be something interesting to explore ... but ... I'm not sure the added complexity of multi processor will really give any edge over a single but more powerful CPU

Perfect example of why NOTHING gets done and development has almost come to a complete stop. Enjoy.

Plüschi · Post by **Plüschi** » Fri Jul 04, 2014 6:22 pm

Personal rant:

MWii is good and fun for acro + level modes, but the more sophisticated stuff barely works. Why not blatantly copy stuff that works instead of reinventing the wheel ?

Althold in APM really works, flip that switch, kazing ... the copter stays there. In mwii it starts to oscillate ... and nobody gives a fuck. No, its NOT the PID, its the code.
RTH or loiter in APM really works 100% of the time, flip that switch, kazing ... the copter stays there or comes home. In mwii it somewhat works sometimes ... and sometimes flies away ... and sometimes tilts sideways and crashes ... and nobody gives a fuck. No, its NOT the PID, its the code.

Oh yes, we need waypoints and stuff in mwii. That is much more intresting than debugging and redesigning the messed up parts.

Oh yes, we need to optimize the code to the level of becoming totally unreadable, because of looptimes ... listen, baseflight deliberately chooses a 3.5ms looptime and flies better. So why do you optimize the shit out of the code? It doesent make it better, it just makes no sense. Look at imu.cpp, that has been optimized into unreadability to gain 0.001us, while a simple drop of double sensor reads would gain you 600us. Deal ?

fuh · Post by **fuh** » Fri Jul 04, 2014 7:58 pm

I think you've nailed it.

copterrichie · Post by **copterrichie** » Fri Jul 04, 2014 8:31 pm

If it was an issue of just having something that works, then Buy DJI and forget about it.

Plüschi · Post by **Plüschi** » Fri Jul 04, 2014 9:14 pm

copterrichie wrote:Buy DJI and forget about.

I have a DJI Phantom2 which is an exceptionally well made and reliable copter. Just the new firmwares suck (i live and fly near an airport).
I also have a walkera qr350 which is total crap firmware. Unusable shit.

Problem ?

copterrichie · Post by **copterrichie** » Fri Jul 04, 2014 9:34 pm

Good for you, I happen to like creating things from scratch, something that others are not doing. Enjoy.

timecop · Post by **timecop** » Sat Jul 05, 2014 1:27 am

Plüschi wrote:I also have a walkera qr350 which is total crap firmware. Unusable shit.

I heard rumors the firmware in that runs on (surprise) atmega2560 and can actually be made to run multiwii.

Plüschi · Post by **Plüschi** » Sat Jul 05, 2014 3:36 am

The hardware can run mwii, but walkera FW might be a megapirate clone instead, like their "pro" board is. QR350 just got totally fucked up by walkera people.

btw ... basecopter ? stmcopter? basepirate ?

The drivers are the same and if it behaves right ... killer app ...

e_lm_70 · Post by **e_lm_70** » Sat Jul 05, 2014 6:26 am

copterrichie wrote:If it was an issue of just having something that works, then Buy DJI and forget about it.

Here we agree ..

Strange that you took the i2c gps module comment for show as reason why development is slow down

Above people complains and make quite some wrong argumentation over GPS functions from MultiWii

AltHold on MultiWii with 5611 works perfectly ... make alt hold with 085 is a waste of time for get it accurate

About GPS:
Fly away happen only if people don't calibrate the mag, or mount it wrong ... same fly away will happen with every firmware, even apm and as well known on dji too
MultiWii RTH works perfectly, and as well the waypoint navigation
Only GPS Position Hold, due to the absence of any fusion between gps and accelerometer data, this is all up to the GPS accuracy ... so it will never be precise as APM or DJI ... but does the job, accepting an error of +/- 3 meters ... more then enough if you have 'action mode' like on my hacked MultiWii ... action mode = automatic climb in gps PH, 360 deg panaorama , and return back ..

The beauty of GPS multiwii is the simplicity ... it does not have any extra complexity like APM .. this make it much more safe to be used then APM

If you read some APM report ... these are scarring ... if the GPS report an error in the sensed/estimated velocity ... this can cose the APM firmware to get confused enough and crash upside down

... this type of code , that a parameter used only for GPS orientation , could effect the stability it is totally unacceptable for my taste. On multiwii, gps can only change copter inclination up to a configurable level, so it will never cause a crash

GPS function on MultiWii are simple but solid ... after EOS update there is not much to be added there in my book

Back to usefull features ... in my list, on the top is AutoTuning ... and then improved stability (16bit + improved math)

For the first it is needed some smart research
The second has been already implemented ... so it is only about to merge it (maybe via ifdef for keep as well the original version too)

fuh · Post by **fuh** » Sat Jul 05, 2014 8:05 am

Why are you against mixing GPS data with sensor data ? Rock solid position hold is a missing feature and it's the one most dji guys will mock you on with.

e_lm_70 · Post by **e_lm_70** » Sat Jul 05, 2014 8:52 am

fuh wrote:Why are you against mixing GPS data with sensor data ? Rock solid position hold is a missing feature and it's the one most dji guys will mock you on with.

The beauty of multiwii is simplicity (at the code level, simple and clear)
GPS sensor are getting more accurate every day ... and they have their own filtering inside.

Still fuse GPS and sensor data it is the only way to achieve outstanding result ... still not everybody may need these super position hold ... like TimeCop said ... a pole can works even better then a DJI :geek:

Anyhow, if there is a smart way to fuse properly in a simple and clean way GPS and Sensor data (like MultiWii somehow does with baro) why not.

Definitely APM should not be the way to be "copy" here ... read this:.

The velocity accuracy is much more important than most people realise, as it is the GPS velocity readings that allow the autopilot to correct for inertial forces and thus controls whether the aircraft can get an accurate attitude. If the GPS produces a great position but terrible velocity numbers then the aircraft will know where it is but won't know which way is up. This has been the root cause of many crashes, as poor GPS velocity leads to a poor roll/pitch solution and the aircraft turns on its side and crashes.

This is what reported by a APM developer ... my comment is only .. OMG

GPS support should never cause a copter to have an inclination above the configurable angle, like MultiWii does right now.

If APM can lead to crash a copter due to data from GPS ... then really ... this is a bad example to follow !
Also ... it sound a waste of time to even read the GPS speed or even use the GPS speed !

BTW: This is the level of GPS hold that I manage to achieve with MultiWii 2.3 ... after clean up and simplified the MultiWii code .. yes ... my position has a drift of +/- 3 meters ... a bit more then the GPS error ... but even in the strong wind ... GPS hold does the job very well ... and I don't need any special mount for the copter nor to care much about vibrations.

http://www.youtube.com/watch?v=T2wpMEYAIZk (MultiWii does UAV -> GPS hold with automatic climb and return)
http://www.youtube.com/watch?v=J0xIYXu_q8c (MutliWii does UAV + a long GPS Position hold)

If we need to use as reference the position hold code ... we have to look in Harakiri in my opinion

Plüschi · Post by **Plüschi** » Sat Jul 05, 2014 3:27 pm

e_lm_70 wrote:The beauty of multiwii is simplicity

What in the gps or althold code is simple and clear? Last time i checked it was a total mess, not only code wise but also logic wise. Bad coding at its finest.
To rely on notoriously shaky velocity to do pos or althold IS a BAD BAD BAD idea, and thats how mwii does it. Bad performance by design.

Look at partrike's code for plane. That is simple, nice, and WORKS!

I have flown APM and i can in no way confirm the things you say about it. Althold is rock solid, i can speed around in altfold mode, because tilt compensation in APM actually WORKS. Loiter is rock solid, even in high wind conditions, and RTH did never fail. This is with STOCK PID's. I did use the SAME frame for mwii before, and it did totally FAIL in althold and often also FAIL in RTH too.

fuh · Post by **fuh** » Sat Jul 05, 2014 7:29 pm

I don't know if people are aware of how GPS really works.. GPS aren't getting any more "accurate" in the future, they are "inaccurate" by design. The 2m error is because you don't have access to the military GPS encrypted data stream that allows for error compensation and pinpoint a coordinate to the centimeter. Even Galileu will have one meter error to the general public, any poshold solution must correlate the GPS data to other sensor data otherwise is a fucking sphere. GPS velocity is a calculated metric based on two points in time, if you have a 2m error margin then the velocity reported by the GPS will never be accurate and will fluctuate. True velocity must have a dedicated sensor (the one with that little tube pointing into the direction of the movement).

copterrichie · Post by **copterrichie** » Sat Jul 05, 2014 7:29 pm

One of the issues with the usage MWC that is not present in other systems like DJI is, the variances in each copter's uniqueness aka nonconformity of the copter to a standard build specification. Various factors such as Motor KV, Props, ESCs, AUW, CG position, Arm length all play a role in the over all copter performances. The other MAJOR FACTOR is, people's personal BIASES, Likes, Dislikes and Expectations. No two pilots will interpret the flight behavior of a copter the same especially when there is no video present and even then, it is not always conclusive.

fuh · Post by **fuh** » Sat Jul 05, 2014 7:34 pm

I'm sorry but that's only valid for a Phantom, on a F550 you can use whatever you'd like and it flies and poshold out of the box.

copterrichie · Post by **copterrichie** » Sat Jul 05, 2014 7:37 pm

You surely can not with APM, as for other DJI projects, they have their own issues like flyways etc.

fuh · Post by **fuh** » Sat Jul 05, 2014 7:43 pm

But I have a theory for dji fly always.. the typical person who use dji products are not tech savvy as the typical person who can make a mw fly and interop with openlrs and minim osd and so on and so forth. Flyaway will be most probable caused by bad failsafe and poor signal.

copterrichie · Post by **copterrichie** » Sat Jul 05, 2014 7:48 pm

Regardless, there are issues with all products out there and MWC is no exception. The Differences with DJI, they have a PAID STAFF to work out their issues where as MWC, you get the rest of the story.

fuh · Post by **fuh** » Sat Jul 05, 2014 7:51 pm

Sure.. and we are only rock solid poshold behind them.. ;-)

dominicclifton · Post by **dominicclifton** » Sun Jul 06, 2014 3:38 am

timecop wrote:Why write shit like
Code: Select all
BaroPID += errorAltitudeI>>9; //I in range +/-60
at all, because any decent compiler will replace foo / 512 by a shift if its deemed necessary.

Yes, I've been saying stuff like that about the baseflight codebase too

Gaijin · Post by **Gaijin** » Sun Jul 06, 2014 8:09 am

Now, Now, everyone play nice :lol:

For my part, I vote for inclusion of auto tune along with the nav features to 2.4 (and then rapid inclusion in 32bit ports but that's a personal preference), these two features would make the basic codebase nearly perfect In my opinion (in terms of features, I can't comment on anything else).

That said a position hold feature that uses accel compensation sounds interesting, surely the fun part of all this effort is trying things out, why doesn't someone give it a go, I assume you could assign the compensation to a switch and make it optional?

e_lm_70 · Post by **e_lm_70** » Sun Jul 06, 2014 9:32 am

Plüschi wrote:
e_lm_70 wrote:The beauty of multiwii is simplicity

What in the gps or althold code is simple and clear? Last time i checked it was a total mess, not only code wise but also logic wise. Bad coding at its finest.
To rely on notoriously shaky velocity to do pos or althold IS a BAD BAD BAD idea, and thats how mwii does it. Bad performance by design.

Look at partrike's code for plane. That is simple, nice, and WORKS!

I have flown APM and i can in no way confirm the things you say about it. Althold is rock solid, i can speed around in altfold mode, because tilt compensation in APM actually WORKS. Loiter is rock solid, even in high wind conditions, and RTH did never fail. This is with STOCK PID's. I did use the SAME frame for mwii before, and it did totally FAIL in althold and often also FAIL in RTH too.

Same 'frame' ?. you should mention also which board you used, which version of firmware, etc

If you use multiwii with bmp085 ... you will never get any decent alt hold
If you don't cover your 5611 ... again the same.

I have multiple videos on my channel showing rth, alt hold, navigtaions, etc based on multiwii ... only position hold is not precise as dji or apm (apm need also special anti vibration mount that I never used in my dopters)

About code ... I don't get the velocity comment above ... on my hacked multiwii I cut away the speed estimation in gpp-hold ... so I use a more simple version of it. Also I see the MAG adjustement in multiwii will not work outside the small angle ... so if the copter get some inclination, it will be out of control (other point I did remove)

About simplicity ... multiwii is way way more simle and clear then APM code ... still we are maybe entering in a subjective arena

Anyhow ... pos-hold is the weak point of multiwii .., if anybody has an idea how to imolement in a clean way (not coping from apm) .. then it make sense to be added ... patrik code has not position hold usable for quad, also alt hold based on throttle on airplane is something that I wil never ever use on my airplanes

Finally the speed sensor, in my book are usable only in airplane not on quad, still ... it more a new point of failure then a real benefit .. in an airplane the gps speed is very accurate, like gps heading ... so air speed sensors are mainly for check the 'wind speed' only .. something not much interesting if the airplane is configured enough motor power all the time that avoid and stall while in uav/rth ... together with a max climbing rate clearly ...

Plüschi · Post by **Plüschi** » Sun Jul 06, 2014 10:36 am

e_lm_70 wrote:the MAG adjustement in multiwii will not work outside the small angle

Care to elaborate? I dont get it.

Last time i checked poshold and althold would use velocity as input to PID, not position. Due to the noisyness of gps-derived-velocity i consider this to be a pretty bad design flaw. I did check this half a year ago, my memory might be wrong, but i'm too lazy to check again. Althold is the same story, and tilt angle correction of thrust is also totally flawed.

The APM hardware i use has the "good" baro, not the bmp85. Tests with megapirate on a 2560-bmp085 board are on the "to do" list. Mwii will still have its place on gps-less 328 and 32u4 boards. Cutting out the 328 and 32u4 support for mwii 2.4 could be a VERY BAD idea. Mwii in acro,angle and horizon mode performs VERY WELL. If you get rid of gps code the flash size limitation is gone.

I my humble opinion Mwii should:
- get rid of ALL ternary statements. Those are roadblocks for understanding stuff.
- get rid of optimizations which make the code unreadable (imo.cpp especially).
- clean up variables. What the fuck are local gps variables doing in multiwii.cpp?
- get rid of sensors / boards NOBODY uses any more. Who uses a nunchunk if a 6050 board can be bought for $19?
- get rid of code NOBODY uses any more.

Maybe split the thing into a clean and beginner friendly 328 - 32u4 part, and a totally messy overoptimized 2560 part for the gps boys to play with?

fuh · Post by **fuh** » Sun Jul 06, 2014 2:15 pm

Can we make a real step forward to the future of Multiwii and move to github, there are so many forks and branches of mw development that we're unable to follow them all properly. Nor we are able to properly submit bugs or code merge requests. We all know mw is only possible due to the work of volunteers, so let's ease the life of everyone.

Alexinparis · Post by **Alexinparis** » Sun Jul 06, 2014 11:37 pm

e_lm_70 wrote:Let me summarize:
- The acro-stability flying mode of MultiWii, even with the know limitation of bits/bytes/maths , in your opinion is good enough, so there is no point to invest lot of CPU/development power for a marginal gain ... correct ?
- AutoTuning is something that you may consider interesting for MultiWii ... but I guess you want to see somthing more concrete about this ... right ?

Yes, basically this is my view for acro and stability (level/horizon).
For other mode, I think there are ways for improvement and everything is open.

Finally .. what is the ethical problem with KK boards ?
I think there is no issue on support KK2.0 and KK2.1 boards with MultiWii 2.3 (I'm "working" on this , with good results : http://www.youtube.com/watch?v=J0xIYXu_q8c / http://www.youtube.com/watch?v=T2wpMEYAIZk)
Also ... there is no IPR issue to make a smarter KK2 alike board, with LCD + buttons + 10DOF + 644 cpu.
PPS: Possibly all what is needed on MultiWii side is not only to support i2c display, but make a i2c module with both display and 4 buttons

It's not related to MultiWii and any attempt to port it on this board. don't worry

To my mind, the problem is only with HK KK boards and the way they've just omitted kapteinkuk at least in the product description.
http://www.rcgroups.com/forums/showthre ... st25286685
first product:
http://www.hobbyking.com/hobbyking/stor ... ouse_.html
now:
http://www.hobbyking.com/hobbyking/stor ... 644PA.html

timecop · Post by **timecop** » Sun Jul 06, 2014 11:47 pm

fuh wrote:Can we make a real step forward to the future of Multiwii and move to github, there are so many forks and branches of mw development that we're unable to follow them all properly. Nor we are able to properly submit bugs or code merge requests. We all know mw is only possible due to the work of volunteers, so let's ease the life of everyone.

As much as I hate shithub and git in general, I gotta agree moving there was the best way to manage contributions from others with one click, instead of wasting time copypasting patches into google code.

Alexinparis · Post by **Alexinparis** » Sun Jul 06, 2014 11:57 pm

Plüschi wrote:
MWii is good and fun for acro + level modes, but the more sophisticated stuff barely works. Why not blatantly copy stuff that works instead of reinventing the wheel ?

Althold in APM really works, flip that switch, kazing ... the copter stays there. In mwii it starts to oscillate ... and nobody gives a fuck. No, its NOT the PID, its the code.
RTH or loiter in APM really works 100% of the time, flip that switch, kazing ... the copter stays there or comes home. In mwii it somewhat works sometimes ... and sometimes flies away ... and sometimes tilts sideways and crashes ... and nobody gives a fuck. No, its NOT the PID, its the code.

Oh yes, we need waypoints and stuff in mwii. That is much more intresting than debugging and redesigning the messed up parts.

I tend to agree:

- ALT HOLD: the process to have something working was really long and is still not perfect. No problem to test any new code and replace if it acts better. (I don't speak only about the current angle compensation which may be inaccurate)

- GPS CODE: timeline
I made the initial code but it didn't work. the algo was too simple.
Then came EOS.
He reworked the code, and you should know his work was based on apm algo

The code stayed like this since and apm GPS code evolved to something mode accurate.
Again: things are opened to import changes and improve it.

fuh · Post by **fuh** » Mon Jul 07, 2014 9:41 am

Thanks for your input Alex, but would you care to elaborate on the github point ?

Frank · Post by **Frank** » Mon Jul 07, 2014 10:25 am

So, as usual. Everyone´s free to contribute stuff. I hope github will be an option for mwc as it might ease contribution for some people who would like to stick to "old" stuff.
For the rest, theres 32bit baseflight on github, feel free to contribute there. Have fun over there.

No need to argue why keil environment etc. is so much cooler than mwc & avr.

e_lm_70 · Post by **e_lm_70** » Mon Jul 07, 2014 10:32 am

Alexinparis wrote:
e_lm_70 wrote:
Finally .. what is the ethical problem with KK boards ?
I think there is no issue on support KK2.0 and KK2.1 boards with MultiWii 2.3 (I'm "working" on this , with good results : http://www.youtube.com/watch?v=J0xIYXu_q8c / http://www.youtube.com/watch?v=T2wpMEYAIZk)
Also ... there is no IPR issue to make a smarter KK2 alike board, with LCD + buttons + 10DOF + 644 cpu.
PPS: Possibly all what is needed on MultiWii side is not only to support i2c display, but make a i2c module with both display and 4 buttons

It's not related to MultiWii and any attempt to port it on this board. don't worry
To my mind, the problem is only with HK KK boards and the way they've just omitted kapteinkuk at least in the product description.
http://www.rcgroups.com/forums/showthre ... st25286685
first product:
http://www.hobbyking.com/hobbyking/stor ... ouse_.html
now:
http://www.hobbyking.com/hobbyking/stor ... 644PA.html

Thanks Alex.

Based from your replies it is looking MultiWii is still alive .. this is what I did want to get from your.
Also, interesting about the comment over EOS work, so I still did not check the EOS special version of MW2.3 ... definitely something that I need to look at, in case something got better in the GPS-Postion Hold (this is the only minus point in my book in MultiWii ... still acceptable for my usage)

About KK ... the story of late payment ... KK has been reported on multiple times ... and sometime HK did acknowledge that they did pay him late, still they did pay him.
KK did refuse to support the KK2.0 evolution once the sensors on KK2.0 start to get hard to sourced ... so .. KK himself decided to get out of this "biznes"

There are now multiple producer both of KK2.0 and KK2.1 ... the HW of KK2.x is trivial ... the firmware is open source ... KK open up his code long time ago, and same the two guys that took from the KK code, have the code open.

Actually KK2.0 and KK2.1 is not a great HW design ... but the idea to have LCD + 4 buttons was brilliant ... a bit too little for get IPR for the rest of the life without any extra contribution.

Anyhow ... I personally don't see any moral issue here.
Actually, more board should come with LCD and buttons ... maybe a Naze32 v6 ... but why not a MultiWii 644 based ... or a MultiWii 2560 based board with 10DOF on board

PS: About autotuning .. I was having the following idea:
- I don't like to make autotuning in the air, like apm is doing .. since if the starting PID is too bad .. it will be a crash while first autotuning is going on.
- Autotuning ... maybe should be just check the latency and power/weight of the copter ... just using 1 motor-esc at time .. from a flat surface ... allowing the arm to rise to max 30 deg angle ... so never in the air.
- Autotuning should check the response time of ESC-Motor-Prop ... and feed back this information.
- Based on this information is possible to write a XLS table that could extract the ideal starting PID

This sound something simple and still valuable ... in my opinion the ESC delay, and the power/weight ration are the two parameters that effect the PID

e_lm_70 · Post by **e_lm_70** » Mon Jul 07, 2014 10:37 am

Frank wrote:So, as usual. Everyone´s free to contribute stuff. I hope github will be an option for mwc as it might ease contribution for some people who would like to stick to "old" stuff.
For the rest, theres 32bit baseflight on github, feel free to contribute there. Have fun over there. No need to argue why keil environment etc. is so much cooler than mwc & avr.

Keil is cool, very cool ... but it does also cost 2000$

Everybody is free to contribute .. one way to contribute or the other in my book does not make much difference ...

Also everybody is free to use a cracked version of Keil too ... ups ... free ups to some limit actually ... still some people just can't or don't want to use pirate software on their PC

fiendie · Post by **fiendie** » Mon Jul 07, 2014 10:52 am

e_lm_70 wrote:Keil is cool, very cool ... but it does also cost 2000$
Everybody is free to contribute .. one way to contribute or the other in my book does not make much difference ...
Also everybody is free to use a cracked version of Keil too ... ups ... free ups to some limit actually ... still some people just can't or don't want to use pirate software on their PC

Nobody needs Keil to contribute. There is good documentation on how to get it all running with open source tools (Eclipse + Plugins) in the wiki on Github. I had it running for 2 years now, debugging support included.

IMO Keil is a clunky piece of crap that only saves you the initial effort of setting it all up. I admit that this step is a major pain in the nether regions but you only have to do it once.

Frank · Post by **Frank** » Mon Jul 07, 2014 10:54 am

Well, its not only about Keil and its licence. I´m sure that, beside that, there are also other reasons why the 32bit section isn´t proceeding as fast as you might think when you read all the people here preaching the 32bit world. "They" have the superior 32bit, github, etc. . But I think most people are only arguing because they just own a cool 32bit-fc and have never tried to contribute code, otherwise they would understand the issues.

Whatever, we now know what the status quo is, that the project is still a bit alive and hope that old grandpa mwc is going to have a nice cool time although lot of people are preaching his death

Everyone knows about the problems with althold, gps etc., so, contribute whatever you like.

fiendie · Post by **fiendie** » Mon Jul 07, 2014 11:47 am

Frank wrote:Well, its not only about Keil and its licence. I´m sure that, beside that, there are also other reasons why the 32bit section isn´t proceeding as fast as you might think when you read all the people here preaching the 32bit world. "They" have the superior 32bit, github, etc. . But I think most people are only arguing because they just own a cool 32bit-fc and have never tried to contribute code, otherwise they would understand the issues.

What you're saying is just a load of crap. There is nothing cool about either STM32 MCUs or Github anymore. It's pretty fucking common. Right now you're more likely to come off as a Hipster for continuing to use Atmegas and Subversion like people who are still shooting on 35mm film

If what you said was true everyone would just snub there noses and not bring up the gazillion advantages a move would have.

Think about it.

brewski · Post by **brewski** » Mon Jul 07, 2014 12:12 pm

I am only a Newby to this amazing & mentally/technically challenging hobby, but would like to put my 2c worth in.
Being a semi retired Electronics Engineer (medical), I did my research online & from what I read I decided to go with Multiwii (well I Still have a functioning Amiga 500)
After building a quad from kit & then programming it & test flights by trial & error I can see why someone new to this hobby with limited technical knowledge would give
up & buy a RTF commercial quad.
I think developers need to get more people involved in Multiwii & this will result in a larger pool of talent to source from.
Being an engineer I could see that the flimsy nylon props & hubs that most builders get with kits are total crap. After I replaced the nylon props with descent APC composite with quality hubs I could actually fly!
It doesn't matter how good the code, if user has crap hardware there will always be issues.
The commercial coders have it so easy writing code for limited platforms with known parameters.
After attaining stable hover I switched on Headfree. Quad flew off to right & nearly crashed before I killed throttle.
I connected to PC & powered up quad with lipo & props on & held quad while increasing throttle. I was amazed that compass that was pointing North defected to East with full throttle!
How can code ever compensate for bad FC design..impossible.

After disabling onboard Mag & installing EXt Mag on mast I can now have confidence using Mag features.
Baro (height hold)mode is not so easily fixed. The sensor drift with barometric pressure is not so bad with stable atmospheric conditions, But temp drift from cold can be up to 1.5m over 5 minutes. After observing this I now allow up to 5 minutes for Baro to stabilise or at least 4 flashes of GPS status LED before arming.
My X525 with Crius AIOP V2 is running MW 2.3 Navib7, Ublox Neo 6M, & Bluetooth. With standard PIDs it will Pos Hold within 1m vert & 1.5m horiz.

I know MW has a WiKi but this is seriously out of date.
Why not have a Start page on Forum with all the basics & links so that more users will choose Multiwii. It took me quite some time to find out that MW had navigation & other advanced features which I am now using. Other flyers I have spoken to had no idea that MW had come this far & were using APM, Megapirates etc with mostly poor results.
Please keep the development coming. it is obvious to me that the cheap & fast 32bit processors are the future of MW. With efficient code these will allow real time filters for all sensors & a totally stable platform..that is providing FC designers don't do stupid stuff like putting a Mag chip on FC & relying on a Baro chip solely for Alt Hold.

fuh · Post by **fuh** » Mon Jul 07, 2014 12:18 pm

Why such hate around AVR ?
Auto tuning is possible on AVR, same as better poshold/althold, RTH and good GPS waypoints. Why should we shoot for the moon on the uC side ?

I can agree with a split between 328 based mw firmware and "pro" mega or better just to overcome the programmable space limit to new functionality.

e_lm_70 · Post by **e_lm_70** » Mon Jul 07, 2014 12:35 pm

brewski wrote:My X525 with Crius AIOP V2 is running MW 2.3 Navib7, Ublox Neo 6M, & Bluetooth. With standard PIDs it will Pos Hold within 1m vert & 1.5m horiz.

Based on this MW2.3 NavB7 has made a real step forward from normal 2.3
But ... I know that 1m or 1.5m is really a personal observations ... only a video can somehow prove it.

brewski wrote:...that is providing FC designers don't do stupid stuff like putting a Mag chip on FC & relying on a Baro chip solely for Alt Hold.

Design a FC with mag on board, is maybe as stupid as putting ESC power line or ESC power distribution board under the FC.

I use on board Mag on all my copters, and the noise level is never more then 5deg ... that is small enough for have everything working as it should be.

PS: MultiWii will be much more simple at two conditions:
- If MutliWii will support a single set of sensors
- If every Board supplier will provide a clean "configuration" for MutliWii
- Add and LCD, and have more memory for get more real configurable options instead to update code for any configuration change

brewski · Post by **brewski** » Mon Jul 07, 2014 12:50 pm

+1 & video coming. Std PID & 1KG mass seems perfect fit!

Frank · Post by **Frank** » Mon Jul 07, 2014 12:53 pm

fiendie wrote:... gazillion advantages a move would have.

Think about it.

The current topic is about original MWC, an avr-project. point. And yes, advantages, but why do you write *would* ? There is no "would", the move has already happened ! You have github & 32bit !
You (not in person, but 32bit) are just arguing with "old-schoolers" and always ranting that their shit is shitty. You have your playground, go, rant there.
Like those guys with <put newest cool tech-car here> flaming all the time about <put old car here> instead of just driving their circles on the race-track and having fun.

Its not about "hipsters", its about live and let live. Not everyone is in need to take the move to stm32, especially if we are talking about freetime hobbies. You have your area, you are free to put all your efforts on pushing 32bit development. Go and make it better, but dont flame old guys about being old.

Cheers

e_lm_70 · Post by **e_lm_70** » Mon Jul 07, 2014 1:02 pm

brewski wrote:+1 & video coming. Std PID & 1KG mass seems perfect fit!

Looking forward for your video

timecop · Post by **timecop** » Mon Jul 07, 2014 1:05 pm

Hey 'Frank', I think I know you who are (monkey avatar on rcg, right?), this isn't about 32bit or github, its about alex (and other avr-8bit-project-maintainers) having a much easier way to review, accept, and merge patches from other developers INTO THE CURRENT 8BIT MULTIWII BRANCH. Right now shit gets posted in this fucking forum in random formats, and he has to copypaste, merge, try to build, verify that it works, and then commit. If there are problems with the patch, he needs to reply to the forum post, wait for changes, apply them again, etc etc. All this stuff is automated by github, developers can comment on individual lines, resubmit changes after discussion, etc etc.

copterrichie · Post by **copterrichie** » Mon Jul 07, 2014 1:33 pm

Just my two cents on Auto-tuning, I strongly believe this should be a function of the GUI. Enter all of the variables such as Weight, Arm Length, Motor KV, Battery Voltage etc and the results should get the copter flying. Fine tuning such as performed with APM can be done in the air or by a skillful pilot.

Frank · Post by **Frank** » Mon Jul 07, 2014 1:42 pm

timecop wrote:Hey 'Frank', I think I know you who are (monkey avatar on rcg, right?), this isn't about 32bit or github, its about alex (and other avr-8bit-project-maintainers) having a much easier way to review, accept, and merge patches from other developers INTO THE CURRENT 8BIT MULTIWII BRANCH. Right now shit gets posted in this fucking forum in random formats, and he has to copypaste, merge, try to build, verify that it works, and then commit. If there are problems with the patch, he needs to reply to the forum post, wait for changes, apply them again, etc etc. All this stuff is automated by github, developers can comment on individual lines, resubmit changes after discussion, etc etc.

Hi, nope. I have no avatar on rcg

And on the github topic I totally agree with you, github is something the maintainers should definitly take into considerations. But as ezio stated in the beginning, some people might have been concerned if even github would have helped when the maintainers already moved to other projects (its their free decision). Happily alex showed some vital signs

And I understand the thoughts about if it makes really sense to include gps in mwc, and all the discussions about cleaner code, old hw-support... no easy decisions here if you filter out personal bias. I was just a bit bugged by the "Oh, stop your old shit dumbasses and everyone move to stm32 now." postings. No offence to the 32bit section, but some ppl dont understand the point.

e_lm_70 · Post by **e_lm_70** » Mon Jul 07, 2014 1:56 pm

copterrichie wrote:Just my two cents on Auto-tuning, I strongly believe this should be a function of the GUI. Enter all of the variables such as Weight, Arm Length, Motor KV, Battery Voltage etc and the results should get the copter flying. Fine tuning such as performed with APM can be done in the air or by a skillful pilot.

About auto-tuning
The most important factor is the ESC delay .. the RPM change from the PWM signal change.
How do you plan to put this in the GUI ?

copterrichie · Post by **copterrichie** » Mon Jul 07, 2014 2:18 pm

e_lm_70 wrote:About auto-tuning
The most important factor is the ESC delay .. the RPM change from the PWM signal change.
How do you plan to put this in the GUI ?

What are the maximum delays of all the ESC brands used? Seems to me, this information does not vary very much from a normal distribution curve and we can use the mean as a baseline.

copterrichie · Post by **copterrichie** » Mon Jul 07, 2014 2:24 pm

Just did a google search: http://www.rcgroups.com/forums/showthread.php?t=1250488