Why development has stopped?

This forum is dedicated to software development related to MultiWii.
It is not the right place to submit a setup problem.
Software download
User avatar
ezio
Posts: 827
Joined: Sun Apr 01, 2012 11:03 pm
Location: Paris
Contact:

Why development has stopped?

Post by ezio »

I'm curious why there is no progress in the code for some time now?
Where are the smart people who were here before?

Bart

Frank
Posts: 16
Joined: Wed Jul 17, 2013 8:59 am

Re: Why development has stopped?

Post by Frank »

I think they got dull after getting dissed for codingstyle etc. over and over again by the "experts". Or maybe they just moved further to shiny new projects ?

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

Re: Why development has stopped?

Post by timecop »

ezio, what do you have in mind? promini is full, so there's nothing else to add.
next step would be rewriting everything in ASM to free up some more flash space.

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

Re: Why development has stopped?

Post by Hamburger »

Noone is really qualified to answer your question once for all devs but

For me I spend more time flyinc plus the project has matured for most needs and reached a semi.optimal state.
My personal wishlist has become rather short.
Some higher goals like autonomous flight do not drive me. From looking at other similar projects I do not see anything to wet my appetite. Or to see it fit for a community project.

The socalled advanced hardware advocates have completely failed to deliver inspiring features.

So yes, you could call it a lack of driving force - ideas to raise interest that is. Maybe we need to open a new wishlist and see what people come up with.

User avatar
ezio
Posts: 827
Joined: Sun Apr 01, 2012 11:03 pm
Location: Paris
Contact:

Re: Why development has stopped?

Post by ezio »

Yes you are right, development on pro mini should stop here. Squeezing code to save couple bits is a nonsense as we have other still cheap microcontrollers. There is still some free space in mega. Maybe we can finish the Nav code and finally release 2.4?
I can see that many ideas or patches are completely ignored or often criticised.
It wasn't like this couple years ago.

PatrikE
Posts: 1976
Joined: Tue Apr 12, 2011 6:35 pm
Location: Sweden
Contact:

Re: Why development has stopped?

Post by PatrikE »

I have plans to implement the FixedWing RTH code to main.
It still fit in the mini.
There's only positive reports on the latest code so i think it's good for a V2.4 release.

dominicclifton
Posts: 202
Joined: Tue Feb 05, 2013 10:28 pm

Re: Why development has stopped?

Post by dominicclifton »

moving the code to github would probably help.

User avatar
treym
Posts: 258
Joined: Sat Jul 21, 2012 12:28 am

Re: Why development has stopped?

Post by treym »

Hamburger wrote: autonomous flight do not drive me.
[...]
The socalled advanced hardware advocates have completely failed to deliver inspiring features.


i am too not very driven by full autonomous flight ..

but i dont agree one the second statement .. we dont need to recompile everything each time we need to change a setting , imho this is one of the best added feature .

also , the old 8bit promini totaly failed at using a gps .. you could buy a mega , but that is stupid failed expensive old hardware

also , you can remap almost all pin , even if this is unlikely use be the average joe , it lead to more capabilities ..

BUT : it looks like using 12 motors a gimbal and 2 rx is kinda a specific setup that is either not wanted nor needed by the 99%

there are indeed code that is not merge , caused it is either expensive or not directed toward the community or just private code ..

e_lm_70
Posts: 297
Joined: Fri Aug 09, 2013 8:35 pm

Re: Why development has stopped?

Post by e_lm_70 »

Why not open a discussion about the list of wanted new features ?

What about auto PID tuning ?
What about improved gyro readying (16bit) and more accurate acro/horizon ?

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

Re: Why development has stopped?

Post by copterrichie »

Considering how difficult it is to work with Google Development nowadays, moving the code to github should be priority number one.

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

Re: Why development has stopped?

Post by Alexinparis »

ezio wrote:I'm curious why there is no progress in the code for some time now?
Where are the smart people who were here before?

Bart


Hi,

I can understand here a sort of frustration about the slowness these weeks ;)
There will be a 2.4 for sure.
And it will be released as soon as last EOSBandi code will be merged and tested.
What he did about navigation is great.
Now, the last time he logged here was more than 2 months ago. quite long


The so called advanced hardware advocates have completely failed to deliver inspiring features.

I share this view too:
ok 328p is too short for elaborated options like navigation.
but I still didn't see a must have feature that can't run on a mega just because of its limitation (at least on open code)

What about improved gyro readying (16bit) and more accurate acro/horizon ?

I posted something on this some times ago: accuracy is not only tied to the number of bit.

mabaka
Posts: 21
Joined: Thu Oct 17, 2013 12:03 pm

Re: Why development has stopped? -> many millis()

Post by mabaka »

Hi.

There will be a 2.4 for sure.


Inspecting MultiWii sources, there are around 14 calls to millis(), which does not mean there are 14 calls in each main loop.

This is millis() code:

Code: Select all

unsigned long millis()
{
   unsigned long m;
   uint8_t oldSREG = SREG;

   // disable interrupts while we read timer0_millis or we might get an
   // inconsistent value (e.g. in the middle of a write to timer0_millis)
   cli();
   m = timer0_millis;
   SREG = oldSREG;

   return m;
}


It is short and fast, but MultiWii could be optimized placing once in the main loop:

Code: Select all

millis_now = millis();

being millis_now a global variable, and substituting millis() with millis_now (caring and checking) in the rest of the code.

Benefits:
-Save some code on 32K limited implementations (if compiler doesn't optimize extremely).
-Faster; no interrupts mess (cli()).
-No need to worry or wander about millis() overflow, effects of what its internals do, etc.

micros() is different, since it is used for delays.

Or I am completely wrong...

mabaka
Posts: 21
Joined: Thu Oct 17, 2013 12:03 pm

Re: Why development has stopped?

Post by mabaka »

I'll respond to myself partially, after a fast test:

-Save some code on 32K limited implementations (if compiler doesn't optimize extremely).

No: just the opposite. Adds four bytes (if uint32_t) of ram, and it seems that using an uint32_t occupies more than a function call.

The rest of benefits apply, if I am not wrong further.

User avatar
shikra
Posts: 783
Joined: Wed Mar 30, 2011 7:58 pm

Re: Why development has stopped?

Post by shikra »

I suspect there is a correlation between the reduction in development and the move away from Arduino to C style coding. There is much smaller population now able to follow the code.
For all itsproblems, easy to use Arduino has brought many into helping develop.. I think this was a major strength for MultiWii and part of its success - after Alex of course :)

+1 for github - but really there is no real point / benefit gain to all if there are few contributors...

For the guys I fly with and who choose not to use MultiWii, its the same 3 items..
- They like Naza style of GPS control
- MultiWii GPS hold / alt hold just does not come close to Naza unless lucky / get settings spot on
- Config is too complicate for a newb

None of these bother me, but I get their point

e_lm_70
Posts: 297
Joined: Fri Aug 09, 2013 8:35 pm

Re: Why development has stopped?

Post by e_lm_70 »

Alexinparis wrote:
ezio wrote:I'm curious why there is no progress in the code for some time now?
Where are the smart people who were here before?

Bart


Hi,

I can understand here a sort of frustration about the slowness these weeks ;)
There will be a 2.4 for sure.
And it will be released as soon as last EOSBandi code will be merged and tested.
What he did about navigation is great.
Now, the last time he logged here was more than 2 months ago. quite long


The so called advanced hardware advocates have completely failed to deliver inspiring features.

I share this view too:
ok 328p is too short for elaborated options like navigation.
but I still didn't see a must have feature that can't run on a mega just because of its limitation (at least on open code)

What about improved gyro readying (16bit) and more accurate acro/horizon ?

I posted something on this some times ago: accuracy is not only tied to the number of bit.


Got to know that EOSbandi work will be official from 2.4.

Still while we wait for him, there is no point on thinking other improvement then the EOS waypoints navigations.

328 is fine for everything expect the GPS handling ... there is enough memory and power for handle 10DOF ... GY-87 or BMP180 should be supported, making MultiWii 10DOF with 328 even more price competitive vs other boards.
Actually without GPS, there is still a lot of free space left on 32k for do the acro and all the advanced feature without GPS.

About acro ... I find amazing that Baseflight use a 3500uS cycle, and MultiWii on 328 can make this cycle in much less time ... how it is possible that people price the accuracy of acro of naze32 ?
My response to it, is the 14bit, and other low bit values used in MultiWii ... we have already a working project showing how can be easily extend the acro accuracy of MultiWii: viewtopic.php?f=8&t=5088
Why not invest on this and add in the main stream ?

Finally ... once autotunig is added ... it will be very fast and easy to everybody to adopt MultiWii.

The main advantage of MultiWii compared to other projects, it is that it is a clean and well design code, so my compliments for the work done by multiple developers here. But I think there is space for take the clean approach for advance with more accurate controls and advanced feature like autotuning.

Possibly it is also the time to abandon some old sensors ... everybody now does use only these sensors: 6050 + 5883 ... no sense to support other gyro/acc and mag (at least not much sense to invest time on old compatibility support) ... related to the baro sensor ... the two baro in the market are BMP180 and MS5611, on cheap and one expensive, BMP180 does not look to me to be properly supported by MultiWii (maybe was only a bad quick test on my side, but when I tried I did fail)

Finally ... but this is more in the hands of HW board manufactures ... I'm getting the feeling that KK2 style board with LCD and buttons + MultiWii could be a very attractive platform for get more momentum on MultiWii ... especially if HW produce will add a 5883 and BMP180 on these boards ... so 644+10DOF+LCD+4 buttons sound a way to boost multiWii, and place in a space still empty in the "market"

So ... I feel MultiWii has huge potential to improve still ... but as ezio already mention above, the perception from outside is not so positive now.

User avatar
treym
Posts: 258
Joined: Sat Jul 21, 2012 12:28 am

Re: Why development has stopped?

Post by treym »

mpu6050 ...

using spi and baseflight i have a quad flying with a 250us cycyletime .. since my transmitter and my biological hands dont allow me to exceed the current capabilities of the sensors i can not see the difference with 3500us cycletime ... nothing to mesure from my perspective.

i did not tried the f4 and his higher speed in order to match the 8khz of the sensors ..

ps , 3500us give you plenty of time for doing other task

e_lm_70
Posts: 297
Joined: Fri Aug 09, 2013 8:35 pm

Re: Why development has stopped?

Post by e_lm_70 »

treym wrote:mpu6050 ...

using spi and baseflight i have a quad flying with a 250us cycyletime .. since my transmitter and my biological hands dont allow me to exceed the current capabilities of the sensors i can not see the difference with 3500us cycletime ... nothing to mesure from my perspective.

i did not tried the f4 and his higher speed in order to match the 8khz of the sensors ..

ps , 3500us give you plenty of time for doing other task


I did not make your type of test, but I feel safe to take your words for granted.

In my book this it is translated that Atmega 8bit running at 16Mhz has no problem to achieve the same level of acro stability like Naze32 is reported to have.

So the difference between MultiWii and Baseflight, it is not in the CPU power, but in the code, this is the point that I was trying to make with the 14bit vs 16bit gyro data, and the 16bit internal computation in this area instead of 32bit computation (mainly for integrate the gyro data for have a more accurate attitude) ... in the link that I post above some people report to have better result (even emulating the MAG without having it) ... due to this more accurate computation.

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

Re: Why development has stopped?

Post by timecop »

Dunno why we're discussing this stuff in this thread, but since PID is dependent on loop time (again, due to over-optimization and removing things), changing it rescales PID values up or down.

User avatar
treym
Posts: 258
Joined: Sat Jul 21, 2012 12:28 am

Re: Why development has stopped?

Post by treym »

yes , back to topic

good to see that a version 2.4 will be released, the development is not stop :)

argotera
Posts: 17
Joined: Sun Oct 20, 2013 1:40 pm
Location: Athens, Greece

Re: Why development has stopped?

Post by argotera »

+1 for auto-tuning
+1 for better fixed wing integration.
I think these features would make it much more approachable to rc world.

Here

http://www.rcgroups.com/forums/showthread.php?t=1922423

is an implementation of autotuning in a thread in rcgroups. Maybe it could be ported or to Multiwii.

Thanks of course for all the work so far guys.

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

Re: Why development has stopped?

Post by Alexinparis »

e_lm_70 wrote:About acro ... I find amazing that Baseflight use a 3500uS cycle, and MultiWii on 328 can make this cycle in much less time ... how it is possible that people price the accuracy of acro of naze32 ?

I think the problem is elsewhere here.
It is true that doing everything with float/int32, with the exact trigonometry, with the full resolution everywhere, will give a better result and is conceptually cleaner.
What I'm saying and is hard to admit for purists: the expected "better result" is unnoticeable in a real flight.

My response to it, is the 14bit, and other low bit values used in MultiWii ... we have already a working project showing how can be easily extend the acro accuracy of MultiWii: viewtopic.php?f=8&t=5088

Another problem here: assumptions
I pointed a not valid code in this post.
The original suggested code seems to work, but results in a low deviation just because the computation is wrong.
so the obvious conclusion is 14 bit = low deviation and 16 bit would be super. no no

Why not invest on this and add in the main stream ?

It will be, just to prove this ;)

Finally ... once autotunig is added ... it will be very fast and easy to everybody to adopt MultiWii.

I'm not against, but I want to be sure it is a really expected and working feature that does not work only under restrictive conditions.

Possibly it is also the time to abandon some old sensors ... everybody now does use only these sensors: 6050 + 5883 ... no sense to support other gyro/acc and mag (at least not much sense to invest time on old compatibility support)

For newcomers, probably. but would you be happy to see 6050 support disappear just because there is a new magic chip on the market ?
It's not very complicated to support all sensors the way it is done now.
But yes, one will really disappear in the code: nunchuk

Finally ... but this is more in the hands of HW board manufactures ... I'm getting the feeling that KK2 style board with LCD and buttons + MultiWii could be a very attractive platform for get more momentum on MultiWii ... especially if HW produce will add a 5883 and BMP180 on these boards ... so 644+10DOF+LCD+4 buttons sound a way to boost multiWii, and place in a space still empty in the "market"

side note: how many knows there is an ethical problem with KK boards and HK ?

e_lm_70
Posts: 297
Joined: Fri Aug 09, 2013 8:35 pm

Re: Why development has stopped?

Post by e_lm_70 »

Thanks Alex for sharing your point of view.

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 ?

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

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

Re: Why development has stopped?

Post by timecop »

Also ... there is no IPR issue to make a smarter KK2 alike board, with LCD + buttons + 10DOF + 644 cpu.

The only "issue" would be doing a new design with absolutely dead atmega644. That just makes absolutely no sense at all.

e_lm_70
Posts: 297
Joined: Fri Aug 09, 2013 8:35 pm

Re: Why development has stopped?

Post by e_lm_70 »

timecop wrote:
Also ... there is no IPR issue to make a smarter KK2 alike board, with LCD + buttons + 10DOF + 644 cpu.

The only "issue" would be doing a new design with absolutely dead atmega644. That just makes absolutely no sense at all.


;)

I don't agree that 644 is dead.

But, yes ... a design around stm32 would be better. But then we are no more speaking of MultiWii ...

Anyhow:

Will you do a board with 10DOF + LCD + 4 buttons and STM32 , in the 5x5 format ?
I know that you can, the question is only if you want to do it.

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

Re: Why development has stopped?

Post by timecop »

Hardware is not the problem. It can be made in a day.
The problem is, who's going to be writing firmware? If you just copypaste MultiWii lcd.cpp, well,,, yeah...

e_lm_70
Posts: 297
Joined: Fri Aug 09, 2013 8:35 pm

Re: Why development has stopped?

Post by e_lm_70 »

timecop wrote:Hardware is not the problem. It can be made in a day.
The problem is, who's going to be writing firmware? If you just copypaste MultiWii lcd.cpp, well,,, yeah...


I think the i2c LCD is already supported by Baseflight ... but I never tested it

For "st7565" the KK2 LCD, I have a working MultiWii 2.3 with this LCD ... still not fully coded for all the setting, but not a big thing to complete this project.

Code LCD support and 4 buttons it is a quite trivial job ... it did took me not much time on Arduino environment, so far less then 2h spend on this project for have 3 screens supported on MultiWii 2.3 .. 2h more and I can close the project with full setting over KK2.1 LCD

Possibly from HW point of view all what is missing is a LCD module that has 4 buttons ... but 4 buttons on i2c can be a pain, or 2/4 extra wires.

Actually if somebody produce a board similar to your Naze32 plus LCD and buttons ... I'm quite sure the code will arrive quite soon ...
Possibly ... from your side ... all is needed is to redesign a bigger board with 4 buttons ... and have a space for plug a i2c display (this is already available for few USD) ... so HW wise .. very very little effort
Firmware wise ... it will come ... easy.

Still ... I was trying to motivate Alex, I see still some good life possible for MultiWii power by 8bit AtMega chips.

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

Re: Why development has stopped?

Post by fiendie »

Regarding the move to github:

We get a lot of pull requests for our MultiWii mirror and always have to turn them down and tell the committers to post patches in the forum. It's a hen-and-egg problem. If you make participation unnecessarily hard you can't complain that nobody wants to participate. There have been a lot of contributions for baseflight from all over the place since the move to Github.

You don't have to worry about giving credit to people because it's crystal clear who wrote what. And if the patch/pull request is properly formatted all it takes to apply it is clicking one button.

Just sayin' ;)

Frank
Posts: 16
Joined: Wed Jul 17, 2013 8:59 am

Re: Why development has stopped?

Post by Frank »

It is true that doing everything with float/int32, with the exact trigonometry, with the full resolution everywhere, will give a better result and is conceptually cleaner.
What I'm saying and is hard to admit for purists: the expected "better result" is unnoticeable in a real flight.


Being just a pilot: Therefore I´m still loving Nanowii etc., because its easy-going and I dont feel that any other FC really *flies* better (especially in acro). They feel different, but not really better(once you got the PIDs sorted out)

The main-problem is about "development-power", which is a limiting factor for all OS FC-projects... some perform better due to good/motivating community-"maintenance" and environment, some worse...
But as Multiwii is still the grandfather of many FCs, doing this hard/seemingly useless work (exact trigonometry etc.) might build a good and stable base for the more advanced features. I´m sure if someone does this basic work, it will be thankfully used by many other projects and maybe a good base for more complex features :)

Frank
Posts: 16
Joined: Wed Jul 17, 2013 8:59 am

Re: Why development has stopped?

Post by Frank »

BTW,

its good that such a debate on principles is still possible here. Makes me feel that MWC is not dead yet (and might even outlast other projects) :)

Joseph97
Posts: 16
Joined: Sun Jun 08, 2014 8:15 pm
Location: US of A

Re: Why development has stopped?

Post by Joseph97 »

e_lm_70 wrote:two baro in the market are BMP180 and MS5611, on cheap and one expensive, BMP180 does not look to me to be properly supported by MultiWii


That makes no sense. There's less than 1% difference in price between GY-87 with BMP180 and GY-86 with MS5611but the second is 10 times more accurate. Not just theory but in practice. Why more support for an old bad performing sensor just because one or two people have one in the junk box.

Less from very smart guys who post in forums but instead from my own perspective and that of fellow club and class members:

1. Autopilot is fun but make RTH easier. It is much more important to stop losing planes and copters than have fun with waypoints. From experience I can say PatrikE code works great and should be made part of the standard ASAP.

2. Make the GPS easier to work with regular serial and use I2C for the GUI. Like with LCD. Carrying around a PC is not required to run Multiwii but GPS is needed to stop flyaways and should have higher priority. Myself and many friends cannot afford the expense and long wait to get an extra I2C adapter board. There's also the added complexity and weight of wiring it in.

3. Auto-tuning of PID and more options for configuring so we dont have to get involved with writing code. Hacking is a very exclusive club and its not fair to lock everybody else out.

4. Stop talking about 32 bit and less about Mega2560 too. Promini is cheap and easy to buy so IMHO code experts should concentrate on making that more efficient and versatile instead of more powerful but also more costly and complicated alternatives.

PS Just a viewpoint from someone who is not a power user but likes to fly planes and multicopters more than playing with software.

mike105105
Posts: 38
Joined: Tue Apr 22, 2014 8:20 pm

Re: Why development has stopped?

Post by mike105105 »

As to your #4...Having a forward looking goal towards new hardware allows room for expansion and improvement. That's why our computers aren't still running a 286 or z80 processor, new tech made progress possible in what we could do on the desktop. Streamlining code is always good, but when you are doing it more because of size and not because of speed you should think about moving up.

If any of that is incoherent I'm sorry, working on 3hrs sleep lol.

What I would like in the next ver: I would love to have the ability to map tuning params to a rx channel so I can make adjustments in the air like some other products allow. Possibly a rough pid adjustment based on ratios to get you in the right range before fine tuning. The alt hold def needs some fixing as well.


Mike

Joseph97
Posts: 16
Joined: Sun Jun 08, 2014 8:15 pm
Location: US of A

Re: Why development has stopped?

Post by Joseph97 »

Yes, you have a point about progress and I would agree more if there was a clear advantage to the new hardware. Two of my friends are using Mega boards and one fellow an ARM platform but most of the people in my circle still have Promini and there don't seem to be a clear advantage in performance or security. There's the extra serial port for GPS but that small feature don't seem to outweigh the cost penalty for me. I guess there will always be those who consider inexpensive hardware and simplicity less important than extra features but thats not me. Too bad the vast majority of hobbyists who have an interest in Multiwii don't take part in these forums. I just felt the need to speak up.

e_lm_70
Posts: 297
Joined: Fri Aug 09, 2013 8:35 pm

Re: Why development has stopped?

Post by e_lm_70 »

Joseph97 wrote:
e_lm_70 wrote:two baro in the market are BMP180 and MS5611, on cheap and one expensive, BMP180 does not look to me to be properly supported by MultiWii


That makes no sense. There's less than 1% difference in price between GY-87 with BMP180 and GY-86 with MS5611but the second is 10 times more accurate. Not just theory but in practice. Why more support for an old bad performing sensor just because one or two people have one in the junk box.

Less from very smart guys who post in forums but instead from my own perspective and that of fellow club and class members:

....

PS Just a viewpoint from someone who is not a power user but likes to fly planes and multicopters more than playing with software.


Why you quote my text ?

What you stated really make no sense

My message was to limit the number of sensor supported to only 4 : 6050 + 5883 + BMP180 and MS5611 ... nothing to promot BMP180 vs 5611 or 085

Speaking about price, you make wrong reference too, GY87 cost 9.9$ at ebay, GY86 16 at ebay, or 14.5$ somewhere else .. this is 50% price difference, that speaking of price of BMP180 vs price of MS5611 , the difference is 300% ... accuracy wise ... BMP180 is not that bad, but as far as I know it is supported only by baseflight (not even so good for my limited tests)

Anyhow ... you start off topic and in a free aggessive mode ... :shock:

About promini and gps ... do you know that most of gps module support i2c natively? You can get a ublox MAX7 for 16$ module with exposed and functional i2c pins ... this is the smart way to handle gps on promini
But on promini you can at best have RTH with GPS, EOS waypoint will not work. If you add configurable sensors like on naze32... definitely the 32k flash are not enough on pro mini.

ps: I smell you just want to be provocative ...

Joseph97
Posts: 16
Joined: Sun Jun 08, 2014 8:15 pm
Location: US of A

Re: Why development has stopped?

Post by Joseph97 »

e_lm_70 wrote:Speaking about price, you make wrong reference too, GY87 cost 9.9$ at ebay, GY86 16 at ebay, or 14.5$ somewhere else .. this is 50% price difference, that speaking of price of BMP180 vs price of MS5611 , the difference is 300% ... accuracy wise ... BMP180 is not that bad, but as far as I know it is supported only by baseflight (not even so good for my limited tests)

About promini and gps ... do you know that most of gps module support i2c natively? You can get a ublox MAX7 for 16$ module with exposed and functional i2c pins ... this is the smart way to handle gps on promini

ps: I smell you just want to be provocative ...


Maybe you have good sense of smell but I dont know about shopping. If you are here in USA the lowest price for gy87/gy-87 is $16.72 http://www.ebay.com/sch/i.html?_odkw=gy ... r&_sacat=0. About the same for gy86/gy-86. For me the bmp180 was of no use for altitude-hold. Meters vs centimeters difference. Same for couple other guys here with navigation.

As far as GPS modules none of the popular lowest cost modules like NEO-6 http://www.ebay.com/itm/301185426235?ss ... 1439.l2649 have I2C capability nor is the chip capable of that.

PS: I've added some links. So we have different information. I would be glad to be proven wrong. If you can supply any links for your amazingly low prices I would be very grateful.
Last edited by Joseph97 on Thu Jul 03, 2014 10:38 pm, edited 5 times in total.

kilby
Posts: 76
Joined: Wed May 28, 2014 10:17 am

Post by kilby »

In a past.life I was a coder and for pleasure I was a coder.

When you are writing stuff (not for work) you write code to do the things you want a project to do.

To get a project to have the features you want you have to create a lot.of stuff you are not really interested in which supports the interesting bits (this is tolerable)

So if a devs want RTL then he has to write a.lot if support code for GPS, stabilisation, altitude hold etc.

However he will not write waypoint mission code because he doesn't need to and it would be boring as it serves no purpose to him/her.

Hence you will probably find that waypoints will not be included in the codebase.

Why.move to newer faster boards?

I used to specialise in speed optimisation for games. Eventually you find you are spending.much.more time optimising code than actually writing it it gets dull.

Secondly speed.optimised code is usually much.larger (enrolled loops, longevity boundary, optimised data structures) and you start.to run out of memory.

Size optimised code runs slower which on very.low end processors is not good.

Eventually devs get tired of this compromise and use a faster board with more.memory.

This this is why development eventually slows and even bug fixes cease

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

Re:

Post by timecop »

kilby wrote:Why.move to newer faster boards?
I used to specialise in speed optimisation for games. Eventually you find you are spending.much.more time optimising code than actually writing it it gets dull.
Secondly speed.optimised code is usually much.larger (enrolled loops, longevity boundary, optimised data structures) and you start.to run out of memory.
Size optimised code runs slower which on very.low end processors is not good.
Eventually devs get tired of this compromise and use a faster board with more.memory.
This this is why development eventually slows and even bug fixes cease


THIS.
Why have 50kbytes of output.cpp doing software PWM output in ASM or specialcase spare 8bit timers to try and get 127steps of PWM resolution out of obsolete hardware when you can have 16bit timer running at any period, to deliver 1us PWM resolution for free?

Why do shit like

Code: Select all

  line[0]  = '0' + v  / 1000000000;
  line[2]  = '0' + v  / 100000000 - (v/1000000000) * 10;
  line[3]  = '0' + v  / 10000000  - (v/100000000)  * 10;
  line[4]  = '0' + v  / 1000000   - (v/10000000)   * 10;
  line[6]  = '0' + v  / 100000    - (v/1000000)    * 10;
  line[7]  = '0' + v  / 10000     - (v/100000)     * 10;
  line[8]  = '0' + v  / 1000      - (v/10000)      * 10;
  line[10]  = '0' + v  / 100       - (v/1000)       * 10;
  line[11] = '0' + v  / 10        - (v/100)        * 10;
  line[12] = '0' + v              - (v/10)         * 10;

When you can just printf("%011d") ? Yes, printf will bring in like 2-3k of code. Who cares. Oh, I guess you do, on obsolete hardware with 16/32k flash.

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.
The whole thing about AVR not having hardware divide instruction and the insane shit needed to work around it is just a waste of time.

e_lm_70
Posts: 297
Joined: Fri Aug 09, 2013 8:35 pm

Re: Why development has stopped?

Post by e_lm_70 »

Joseph97 wrote:
e_lm_70 wrote:Speaking about price, you make wrong reference too, GY87 cost 9.9$ at ebay, GY86 16 at ebay, or 14.5$ somewhere else .. this is 50% price difference, that speaking of price of BMP180 vs price of MS5611 , the difference is 300% ... accuracy wise ... BMP180 is not that bad, but as far as I know it is supported only by baseflight (not even so good for my limited tests)

About promini and gps ... do you know that most of gps module support i2c natively? You can get a ublox MAX7 for 16$ module with exposed and functional i2c pins ... this is the smart way to handle gps on promini

ps: I smell you just want to be provocative ...


Maybe you have good sense of smell but I dont know about shopping. If you are here in USA the lowest price for gy87/gy-87 is $16.72 http://www.ebay.com/sch/i.html?_odkw=gy ... r&_sacat=0. About the same for gy86/gy-86. For me the bmp180 was of no use for altitude-hold. Meters vs centimeters difference. Same for couple other guys here with navigation.

As far as GPS modules none of the popular lowest cost modules like NEO-6 http://www.ebay.com/itm/301185426235?ss ... 1439.l2649 have I2C capability nor is the chip capable of that.

PS: I've added some links. So we have different information. I would be glad to be proven wrong. If you can supply any links for your amazingly low prices I would be very grateful.


Ok .. maybe my smell did fail on me this time.

I appreciate your reply now: You just put down the facts that you are aware of, which did drive your assumptions ;)

I find a bit off compare GY-86 vs GY-87, since these module include also 6050, 5883 and the 3.3v reg ... but lets bring here the links:
GY-87 : 9.76$ shipped -> http://www.ebay.com/itm/10DOF-MPU6050-B ... 1502462171
GY-86 : 16.13$ shipped -> http://www.ebay.com/itm/NEW-10DOF-IMU-M ... 1037787023

These are the two lowest prices on eBay, with shipping to EU

Still you can DIY GY-87 by buying the single component and have even cheaper:
2.07$ BM180 -> http://www.ebay.com/itm/1Pcs-BMP180-Dig ... 1522031227
2.58$ 6050 -> http://www.ebay.com/itm/MPU-6050-Module ... 0787042912
1.42$ 5883 -> http://www.ebay.com/itm/3V-5V-HMC5883L- ... 1265889993
Total -> 6.07$ :geek:

The cheapest MS5611 chip/module does cost 12.87$ -> http://www.ebay.com/itm/New-MS5611-high ... 1171800917

For my math MS5611 cost 6 times more then a BMP180

About accuracy ... In my bench test BMP180 has an accuracy of around 75cm ... more then enough for the MultiWii task. MS5611 has an accuracy of around 40cm .... Please note .. I speak about accuracy not of resolution. Also measuring pressure for guess the altitude is a method that has already lot of errors due to the changing of the weather condition, at different altitude temperature , humidity, etc can have different values and the pressure sensor will just make a bad guess of what is the altitude ... as well a change in weather condition will make think a pressure sensor sitting on a table to rise or decline.

Still ... no question that MS5611 is the best baro under 20$ for make the MultiWii job, but BMP180 is a really good option for the cheaper control board, and this BMP180 does fit nice on low budget with cheap ATmega328 chip, but even with cheap STM32 ... what is missing in my view, it is a proper code support on MultiWii for it. BMP180 it is not in the list of supported sensor in MW.23

About GPS ... u-blox in their chips does support natively i2c, but you are correct many module don't expose i2c, or they just use i2c internally for connect a memory. Still ... here is a cheap module that has exposed i2c exposed -> http://www.ebay.com/itm/RYN25AI-10Hz-UA ... 1339542977 .. 17$ shipped ... and MAX7 is a better GPS then NEO6 ... I'm sure looking around there could be more GPS module with i2c exposed ... but this is good and cheap ... i2c direct GPS support should be supported by multiwii ... it will really make a benefit on simple 328 chips with only 1 serial interface.
Last edited by e_lm_70 on Fri Jul 04, 2014 8:44 am, edited 2 times in total.

e_lm_70
Posts: 297
Joined: Fri Aug 09, 2013 8:35 pm

Re: Re:

Post by e_lm_70 »

timecop wrote:
kilby wrote:Why.move to newer faster boards?
I used to specialise in speed optimisation for games. Eventually you find you are spending.much.more time optimising code than actually writing it it gets dull.
Secondly speed.optimised code is usually much.larger (enrolled loops, longevity boundary, optimised data structures) and you start.to run out of memory.
Size optimised code runs slower which on very.low end processors is not good.
Eventually devs get tired of this compromise and use a faster board with more.memory.
This this is why development eventually slows and even bug fixes cease


THIS.
Why have 50kbytes of output.cpp doing software PWM output in ASM or specialcase spare 8bit timers to try and get 127steps of PWM resolution out of obsolete hardware when you can have 16bit timer running at any period, to deliver 1us PWM resolution for free?

Why do shit like

Code: Select all

  line[0]  = '0' + v  / 1000000000;
  line[2]  = '0' + v  / 100000000 - (v/1000000000) * 10;
  line[3]  = '0' + v  / 10000000  - (v/100000000)  * 10;
  line[4]  = '0' + v  / 1000000   - (v/10000000)   * 10;
  line[6]  = '0' + v  / 100000    - (v/1000000)    * 10;
  line[7]  = '0' + v  / 10000     - (v/100000)     * 10;
  line[8]  = '0' + v  / 1000      - (v/10000)      * 10;
  line[10]  = '0' + v  / 100       - (v/1000)       * 10;
  line[11] = '0' + v  / 10        - (v/100)        * 10;
  line[12] = '0' + v              - (v/10)         * 10;

When you can just printf("%011d") ? Yes, printf will bring in like 2-3k of code. Who cares. Oh, I guess you do, on obsolete hardware with 16/32k flash.

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.
The whole thing about AVR not having hardware divide instruction and the insane shit needed to work around it is just a waste of time.


Why bother ? (I could argue with your points that are quite misleading ... but this will drag the discussion even more offtopic)

Here Ezio did ask about the future of MultiWii.

Some people believe Atmega 8bit chip can still make a very good job as control board, also with GPS and 10DOF
Yes, there are other platforms more powerful ... like the insane and useless power from "Pixhawk", that make a stm32 72Mhz 128k looking a little joke (on paper, only on paper)

Anyhow, the question was not if MultiWii will be migrated on stm32 ... there is already baseflight doing it.

The question is .. what should be the expected evolution of MultiWii after 2.3 or the bless of EOS work into MultiWii 2.4 ... is there still any interest to progress and in case in which direction.

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

Re: Why development has stopped?

Post by timecop »

No misleading points. Just stating the facts, but yes, arguing about it is pointless.

Joseph97
Posts: 16
Joined: Sun Jun 08, 2014 8:15 pm
Location: US of A

Re: Why development has stopped?

Post by Joseph97 »

e_lm_70 wrote:
Joseph97 wrote:GY-87 : 9.76$ shipped -> http://www.ebay.com/itm/10DOF-MPU6050-B ... 1502462171

here is a cheap module that has exposed i2c exposed -> http://www.ebay.com/itm/RYN25AI-10Hz-UA ... 1339542977 .. 17$ shipped


Thank you for those links. I missed them because there was no mention of GY87 or MAX7 in the description. You are the best shopper after all. :) Even though I have a budget problem I'm going to order both based on your comment about BMP180 accuracy and the GPS having I2C that works with Multiwii.

Also I agree with Timecop that software PWM is a stupid waste of Mega328 resources. But the chip does have 6 hardware PWM channels and Multiwii can take advantage if these. No need for complex overkill 32 bit for that reason.

I do still feel that there is room for improvement making Multiwii easier to use for the silent majority and also the importance of RTH as implemented by PatrikE.

PS On ordering it appears there is additional $2 shipping for the BMP180 module so since almost the same cost as GY86 I'm gong to skip that. As for that GPS unit I can't find info on activating the I2C interface in the spec. Will it send NMEA? Can you help me find some info on using that with Multiwii?

Frank
Posts: 16
Joined: Wed Jul 17, 2013 8:59 am

Re: Why development has stopped?

Post by Frank »

Yup,
stm32 might ease a lot of things for the devs. But for the average joe it seems as 32bit hasn´t made the rapid progression we where told a year ago. Nor it seems that all the freetime-devs are happily accepting the 32bit stuff.
For GPS, waypoint etc. some people are already looking at pixhawk and all the spinoffs.
So, back to topic. We hope that there are still some enthusiastic people who are more familiar with oldschool 8bit-avr and have no problem to stay oldschool.
Keep up the great work from the last years. Maybe the 32u4 is good for some more fun :)

User avatar
fuh
Posts: 72
Joined: Thu Jun 13, 2013 5:12 pm
Location: Portugal

Why development has stopped?

Post by fuh »

Naze32 is impossible to get on my country with an acceptable price.. I would switch to it any day to have dji like features for 1/5 of the price.

Frank
Posts: 16
Joined: Wed Jul 17, 2013 8:59 am

Re: Why development has stopped?

Post by Frank »

fuh wrote:...to it any day to have dji like features for 1/5 of the price.

Lol, tc is going to quit his hobby ;)

User avatar
fuh
Posts: 72
Joined: Thu Jun 13, 2013 5:12 pm
Location: Portugal

Why development has stopped?

Post by fuh »

OK I should have provided a context to my answer.. ;-)

I'm not speaking speaking about Naze32. I'm speaking about 32bit boards in general. The example is Naze32 that's hard to get here and that's the issue, if people start buying more 32bit FC boards price and will come down and availability will go up.

User avatar
fuh
Posts: 72
Joined: Thu Jun 13, 2013 5:12 pm
Location: Portugal

Why development has stopped?

Post by fuh »

Oh and btw, switch to GitHub ASAP.

e_lm_70
Posts: 297
Joined: Fri Aug 09, 2013 8:35 pm

Re: Why development has stopped?

Post by e_lm_70 »

Joseph97 wrote:
e_lm_70 wrote:
Joseph97 wrote:GY-87 : 9.76$ shipped -> http://www.ebay.com/itm/10DOF-MPU6050-B ... 1502462171

here is a cheap module that has exposed i2c exposed -> http://www.ebay.com/itm/RYN25AI-10Hz-UA ... 1339542977 .. 17$ shipped


Thank you for those links. I missed them because there was no mention of GY87 or MAX7 in the description. You are the best shopper after all. :) Even though I have a budget problem I'm going to order both based on your comment about BMP180 accuracy and the GPS having I2C that works with Multiwii.

Also I agree with Timecop that software PWM is a stupid waste of Mega328 resources. But the chip does have 6 hardware PWM channels and Multiwii can take advantage if these. No need for complex overkill 32 bit for that reason.

I do still feel that there is room for improvement making Multiwii easier to use for the silent majority and also the importance of RTH as implemented by PatrikE.

PS On ordering it appears there is additional $2 shipping for the BMP180 module so since almost the same cost as GY86 I'm gong to skip that. As for that GPS unit I can't find info on activating the I2C interface in the spec. Will it send NMEA? Can you help me find some info on using that with Multiwii?


I did say GPS has working i2c ... I did not say MultiWii support it ... I did test my MAX7 over i2c interface (all is missing are the 2 pull up resistors for make it works) ... I did test with some arduino sample code that I found around ... mainly there is a i2c command for read the data stream from GPS, and the data are in the same way as over serial ... so NMEA if you want NMEA or u-blox binary if you want this. I would need to hack my MultiWii 2.3 for support this ... but I'm messing around on other projects.
Only minor issue on this GPS, it is that it has no permanent storage of the configuration ... so it is possible to configure and keep the set up for few hours even without power ... but unless used every day ... it need to be getting a new configuration ... most of NEO6 cheap module no have EEPROM included ... this module does have not.

About shipping options ... I find out the cheapest eBay offer including shipping to EU ... you need to make a search for your shipping code for get the cheaper offer .. some seller send for free to EU, but ask extra money for send to US ... don't ask me why :?

DIY GY-87 is the cheapest option ... 6$ including shipping to EU.

Finally ... never assume anything .. not even if state by TimeCop ... Atmega328 has 2 16bit timer, and 4 8bit timers, the ATmega2560 has tons of PWM at 16bit ... PWM at 32bit are useless, 16bit is more then enough, but even the 7/8 bit PWM from multiwii do works quite fine too ... actually on my MultiWii over KK2 I'm using only the two 16bit timers for PWM out ... very simple code ... once you clean away the tons of different alternative CPU .. the output.cpp it is a very little and small code ... if you remove the #ifdef from the code, related to function/CPU that are not relevant for you usage ... the multiwii code is the most clean code you can ever find on the open source domain for FC

kilby
Posts: 76
Joined: Wed May 28, 2014 10:17 am

Post by kilby »

timecop,

I was stating general reasons why people walk away from older platforms.

I agree with your point, there also comes a time to walk away from old ways of doing stuff and use improved methods of doing something.

Development stops when either it's a pain in the ads or the developers have everything that they want.

msev
Posts: 186
Joined: Thu Apr 14, 2011 11:49 am

Re: Why development has stopped?

Post by msev »

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 :D, 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.

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

Re: Why development has stopped?

Post by copterrichie »

e_lm_70 wrote:About accuracy ... In my bench test BMP180 has an accuracy of around 75cm ... more then enough for the MultiWii task. MS5611 has an accuracy of around 40cm .... Please note .. I speak about accuracy not of resolution. Also measuring pressure for guess the altitude is a method that has already lot of errors due to the changing of the weather condition, at different altitude temperature , humidity, etc can have different values and the pressure sensor will just make a bad guess of what is the altitude ... as well a change in weather condition will make think a pressure sensor sitting on a table to rise or decline.


I own a home weather station and when I first purchased it, I sat and watched how the barometric pressure would change with temperature, wind speeds and a host of other variances. Measuring altitude in 100's of feet, I can visualize that with no problem but trying to hold altitude within a foot or so without the usage of some sort ground measuring system laser or sonar is impossible.

Joseph97
Posts: 16
Joined: Sun Jun 08, 2014 8:15 pm
Location: US of A

Re: Why development has stopped?

Post by Joseph97 »

e_lm_70 wrote:if you remove the #ifdef from the code, related to function/CPU that are not relevant for you usage ... the multiwii code is the most clean code you can ever find on the open source domain for FC


Thanks for answering my questions.i think maybe it's time for me to learn programming and after simple demos it sounds like Multiwii might be a good next step. I already have an understanding of the hardware and maybe stripping down the code like you say would help too.

Post Reply