Sponsored software development

dramida · Post by **dramida** » Mon Oct 15, 2012 8:09 pm

I prefer to sponsor new feature in multiwii than buy some other fancy controllers . I already did that twice for members of this community, privately. I encourage all interested folks to post here the prize for achieving different features of multiwii and multiply our financial efforts. It works like a gentlemen's agreement. Teaming up the coding efforts will split the price between coders. Ofcorse all the code will be available to everyone

Maybe this topic should be transformed in a new sub-forum.

I'll donate 100 Euro for each of the following feature:

1 Keeping track of each installed controller is difficult without an identifaction name/number. We need an editable field in gui in witch each board identifies itself. Ofcorse this field should be keeped in EEPROM and ideally not affected by software upgrades or parameter reset. When saving/loading configuration from GUI, the name should be saved as well .

2 Keeping track of flight time would be important for kowing the wear of the engines. So using actual time counter, when disarm the copter, a value on the EEPROM should be incremented. On time this value will reflect the wearing of the engines/props so a maintenance strategy could be applied and even a warning threshold at startup witch sais :"warning, your copter needs service" Of course, this flight-time field should be visible and editable on GUI and not affected by software updates.

If you have any question about functionality described above, please fell free to ask publicly.

ps. more to come

alexia · Post by **alexia** » Mon Oct 15, 2012 9:14 pm

great idea.
i think we could ask at some sellers(rctimer and many others serious) to help communauty
it s just an idea but it could be fun

janekx · Post by **janekx** » Mon Oct 15, 2012 9:49 pm

Somewhere i read that MW gets to boost adding new features prior finish and tune them to be useful.... I thing that the priority is to tune flight features at first and add features supporting fly like sonar opto ad so.
Then will be space to make decisions what else.... User friendly setting and profiling and next....

Alexinparis · Post by **Alexinparis** » Mon Oct 15, 2012 11:03 pm

I understand the idea, but I think it's a little bit risky to link money and development in a shared and open source project.
The wish of one person is not always the wish of the community.

dramida · Post by **dramida** » Mon Oct 15, 2012 11:24 pm

This is what i've done with multiwii last week.

http://www.fotografieaeriana.eu/panoram ... olare.html

I need a reliable platform and i am ready to support people who help me:)
Alex, I thank you for this wonderful project and the way you chosed to lead the way.

Hamburger · Post by **Hamburger** » Tue Oct 16, 2012 9:04 am

I am with Alex on the general question of sponsored development.

Still, I have been considering the idea of permanent record keeping (in eeprom) for some time.
For me that would be number of flights, total number of failsafes, number of critical battery low voltage;
plus some flags for error conditions (constantly updated during flight, if possible);
plus a log of armed times plus power consumptions (mAh), (only keeping as many as eeprom space permits).

It would not be difficult to write the stuff to eeprom 'backwards' from the end; but I would access it via the arduino IDE serial monitor (only because it is easier to implement).

Hamburger · Post by **Hamburger** » Tue Oct 16, 2012 9:43 am

quick update - the board name can be set now in config.h (6).
It gets displayed upon startup on the OLED/LCD or in arduino IDE's serial monitor.

Some things come easy

cGiesen · Post by **cGiesen** » Tue Oct 16, 2012 2:59 pm

Hamburger wrote:quick update - the board name can be set now in config.h (6).
It gets displayed upon startup on the OLED/LCD or in arduino IDE's serial monitor.

Can we add this to MSP_IDENT ?
Than I can add it to GUI.
By the way, we can add Subversion too!

Hamburger · Post by **Hamburger** » Tue Oct 16, 2012 4:29 pm

cGiesen wrote:Can we add this to MSP_IDENT ?
Than I can add it to GUI.

I do not know Alex' strategy on changing already defined MSPs. Would require a version increment; thus all GUIs etc. would have to adopt this change. Sounds like the natural way to go, but I will not start it.
As I hardly use the GUI anymore I have for now stopped coding features in processing.

By the way, we can add Subversion too!

? you mean the revision number? How would you do it in an automated fashion that works on all 3 platforms?

cGiesen · Post by **cGiesen** » Tue Oct 16, 2012 6:45 pm

Hamburger wrote:
cGiesen wrote:
By the way, we can add Subversion too!

? you mean the revision number? How would you do it in an automated fashion that works on all 3 platforms?

3 Platform? Witsch?
And I think it's not easy. Every upload increment the number.
But it would be nice

Sebbi · Post by **Sebbi** » Tue Oct 16, 2012 7:06 pm

Please switch to Git and forget about revision numbers as soon as possible. Revision numbers are only interesting if you use svn and are a developer ... why would anyone just flying with MultiWii need them displayed?

@general-idea-of-sponsoring-stuff: I like the bounty hunting concept in open source. 100 Euro is certainly not much, but the bounties show what is important to the community so people with time to spare can implement it (just like with the summer of code project from Google). Also, something like a wishlist where users can enter features they'd like to see and others can vote them up (or down) could be helpful too. This could be organised on the wonderful Trello website (https://trello.com) for example (they are using it internally to visualize their development, too: https://trello.com/board/trello-develop ... 136000000c).

IceWind · Post by **IceWind** » Tue Oct 16, 2012 7:58 pm

I'd say that more important that moving to Git, Mercurial or whatever is to move from a ad-hoc project managing model to a task/feature oriented.
In google code it's more or less possible to do it, by users logging features that later will be voted.
That way is possible to see the top ranked ones as well as assign/determine who is working on what.

penpen77 · Post by **penpen77** » Tue Oct 16, 2012 9:03 pm

bad idea, sponsored stuff shouldn't have this place here...

dramida · Post by **dramida** » Tue Oct 16, 2012 9:35 pm

Thanks, you just got yourself 100 euro. Send me please your paypall account on PM, or even better, write it here, maybe someone else would appreciate your contribution

. I hope this feature will evolve into MSP command.
Add regarding logging in eeprom, for an end-user, all logs are not necesarry. Al he need to know is when he should go to maintenance service by triggering an audio/video alarm at boot-up. So a simple flight time counter should be enough for now.

Hamburger wrote:quick update - the board name can be set now in config.h (6).
It gets displayed upon startup on the OLED/LCD or in arduino IDE's serial monitor.

Some things come easy

dramida · Post by **dramida** » Tue Oct 16, 2012 9:45 pm

Alexinparis wrote:...The wish of one person is not always the wish of the community.

True.
Someone should decide what features should be implemented in the name of the comunity. I think that person is you Alex.
If someone gets rewarded for coding some features/ removing some bugs, is a win-win-win ( me -codder - the comunity)

Can we agree on following functions?

Controlled rate of climb/dive by throttle
Auto-landing on RTH
Reliable GPS pos Hold especially when using YAW for panorama pictures (i will video demonstrate how PH accuracy is greatly decreased when rotating even very slowly)
Waypoint navigation with servo triggers

mahowik · Post by **mahowik** » Tue Oct 16, 2012 10:43 pm

dramida wrote:Controlled rate of climb/dive by throttle

Could you describe in details how you see this? More throttle (from point where althold was activated) => more climb vertical speed? As for me it works in my b2, b3... has some lag but good for smooth altitude tuning, i.e. not for rapid acro fliers

dramida wrote:Auto-landing on RTH

As for now I have almost finished sonar integration with new alt hold... viewtopic.php?f=7&t=1033&p=25164#p25067
auto-landing next step

dramida wrote:Reliable GPS pos Hold especially when using YAW for panorama pictures (i will video demonstrate how PH accuracy is greatly decreased when rotating even very slowly)

As I remember from Eosbandi's posts it's known issue when you have not quite accurate calibrated mag...

dramida wrote:Waypoint navigation with servo triggers

What do you mean "Waypoint navigation with servo triggers"?

thx-
Alex

dramida · Post by **dramida** » Tue Oct 16, 2012 11:23 pm

mahowik wrote:
dramida wrote:Controlled rate of climb/dive by throttle

Could you describe in details how you see this? More throttle (from point where althold was activated) => more climb vertical speed? As for me it works in my b2, b3... has some lag but good for smooth altitude tuning, i.e. not for rapid acro fliers

dramida wrote:Auto-landing on RTH

As for now I have almost finished sonar integration with new alt hold... viewtopic.php?f=7&t=1033&p=25164#p25067
auto-landing next step

dramida wrote:Reliable GPS pos Hold especially when using YAW for panorama pictures (i will video demonstrate how PH accuracy is greatly decreased when rotating even very slowly)

As I remember from Eosbandi's posts it's known issue when you have not quite accurate calibrated mag...

dramida wrote:Waypoint navigation with servo triggers

What do you mean "Waypoint navigation with servo triggers"?

thx-
Alex

1- when you activate ALT Hold, the middle stick become hover. If your throttle hover position is naturally lower or higher than 1500us, then you have to move throttle at middle before having altitude control for up and down. If you leave the stick in its original position more than 10 seconds after activating alt hold (let's say you set the failsafe at 30% throttle and don't have GPS), the altitude in modified accordingly.

2- Sonar should be optional and only for precise touch down. Firstly, i would concentrate on point 1. Baro auto-landing should be an extension to automatic altitude variation control and usable like a fail-safe throttle position for non-gps users.

3- I'll do some video recorded tests on field tomorrow regarding GPS position Hold with yaw and i'll make sure that no metal is around me when calibrating mag.

4- Continuing the work of Eos Bandi: Clicking the map you define the route with points. Each point has some atributes as: Altitude, time to stay there and of corse, action witch could be a servo movement like camera trigger (already defined in config.h) Then upload into eeprom and when in flight, switching aux-X to High will start the navigation routine.

crashlander · Post by **crashlander** » Wed Oct 17, 2012 8:14 am

IceWind wrote:I'd say that more important that moving to Git, Mercurial or whatever is to move from a ad-hoc project managing model to a task/feature oriented.
In google code it's more or less possible to do it, by users logging features that later will be voted.
That way is possible to see the top ranked ones as well as assign/determine who is working on what.

Basic idea is already implemented in wish list that is maintained by Hamburger for every "next" release. Only upgrade could be to actually make a pool out of it so list members could vote for most wished feature (and maybe also lest wanted and already existent feature so the code size could go down by removing those features).
But of course in open source project like this it all goes by "if you need a feature write-it" and probably no pool or whatever will turn the mind of currently hard and good working developers to implement the feature they have no use of it.

Regards
Andrej

Hamburger · Post by **Hamburger** » Wed Oct 17, 2012 8:58 am

cGiesen wrote:3 Platform? Witsch?
And I think it's not easy. Every upload increment the number.
But it would be nice

3platforms is win*,linux,macosx; where arduino IDE runs on.
If you want to automatically insert the revision number into the code every time user does a checkout, it must work on all 3 platforms.
To my knowledge the subversion program does not have the functionality to include subversion information into files (like sccs did). If you build that functionality yourself on top of subversion, that must work on all 3 platforms.

yes, would be nice to know which version you are flying/crashing.

cGiesen · Post by **cGiesen** » Wed Oct 17, 2012 9:08 am

Perhaps it's better than nothing to have a define like your machine name?
Then the user can do it for his own.
It can be used for different settings to!

Hamburger · Post by **Hamburger** » Wed Oct 17, 2012 9:15 am

Sebbi wrote: forget about revision numbers as soon as possible. Revision numbers are only interesting if you use svn and are a developer ... why would anyone just flying with MultiWii need them displayed?

The version number has been 2.10 rsp. 2.11 for ages. Not very precise.
A revision number will identify exactly which version of the software you fly/crash.
Should be the first thing in every bug report too.

Hamburger · Post by **Hamburger** » Wed Oct 17, 2012 9:32 am

crashlander wrote:Only upgrade could be to actually make a pool out of it so list members could vote for most wished feature (and maybe also lest wanted and already existent feature so the code size could go down by removing those features).

voting on the web is a constant failure, subject to manipulation, and not representative.
It is not generally suited to steer development of an open source project.

But of course in open source project like this it all goes by "if you need a feature write-it" and probably no pool or whatever will turn the mind of currently hard and good working developers to implement the feature they have no use of it.

yes. No matter how many votes/likes a wish gets, in the end it requires a developer willing to implement stuff

shikra · Post by **shikra** » Wed Oct 17, 2012 9:44 am

Agree with beefburger - problem with surveys etc is its to quick and easy to register interest. Need to also know the strength of the interest / priorities. So I see where Sebbi is going with the tool for measuring that. So if that wer eto proceed - would contributors work/prioritise based upon the results?

Much that the level of interest in some of my own previous threads has been dissapointing (!) have to accept that the threads with the most conversation are the ones which on average there is most interest.....
They are consistently at the top overtime already!

Really its another meaningless post from me - because again I agree its up to contributors what goes forward. And personally I'm grateful for every contribution so far...

Hamburger · Post by **Hamburger** » Wed Oct 17, 2012 9:48 am

dramida wrote:Thanks, you just got yourself 100 euro.

that won't be neccessary, thanks. More info in PM.
What is more important to me, did you try it already?

Add regarding logging in eeprom, for an end-user, all logs are not necesarry. Al he need to know is when he should go to maintenance service by triggering an audio/video alarm at boot-up. So a simple flight time counter should be enough for now.

Well no. I think a user should know if copter had a failsafe (and revovered) during flight; even after the battery got disconnected (by user or by crash impact).

I encourage you to add those and other ideas of yours to the wishlist. It may be what is needed to trigger someone's thought and start implementation - maybe of something different than what you had in mind; maybe even better.

dramida · Post by **dramida** » Thu Oct 18, 2012 9:38 am

mahowik wrote:
dramida wrote:Reliable GPS pos Hold especially when using YAW for panorama pictures (i will video demonstrate how PH accuracy is greatly decreased when rotating even very slowly)

As I remember from Eosbandi's posts it's known issue when you have not quite accurate calibrated mag...
thx-
Alex

Here you can see a video of X-Y GPS position accuracy when yaw-ing slowly and when not yaw-ing.
http://youtu.be/Jx80YNWy_n4

Hexacopter Multiwii 21 R1177 an Crius AIOP with serial Ublox 6M gps

In my oppinion there is a software bug/ improvement to resolve here. Improving position hold when yaw-ing could be very helpful in making panoramas like that one (Witch I hardely did with MWC) http://fotografieaeriana.eu/panorama/pa ... olare.html

Sebbi · Post by **Sebbi** » Thu Oct 18, 2012 11:43 am

That's an interesting bug. I added it to the unofficial Trello board (https://trello.com/board/multiwii-devel ... 4c4d688e4c). I am not familiar with the GPS code, but after a brief look my theory is:

The whole position hold algorithm is based on velocity derived from GPS locations and a target velocity derived from the relative position error. It then calculates an "angles" it wishes to fly at so it reaches the target. These angles get rotated by the current heading so the copter tilts in the correct direction. I see multiple problems with this approach.
1) heading is more or less pretty stable when no metal is around, but GPS velocity is very inaccurate when the copter/person is moving very slowly.
2) the position error and calculated target velocities to go back to the target position should be ok
3) correct target velocities and slightly off GPS velocities probably leed to a tilt direction that is slightly off, but should come back the faster the copter gets ... hmmm

If this is correct improving accuracy of GPS velocity should counter this problem. Maybe with the help of accelerometer data (or airspeed sensors or optical flow) this can be achieved?

jy0933 · Post by **jy0933** » Thu Oct 18, 2012 4:35 pm

i believe the rate climb/decend on alt hold is similar to this that i wrote
might be my thought a bit over..

viewtopic.php?f=7&t=2344

mahowik · Post by **mahowik** » Fri Oct 19, 2012 5:33 pm

Sebbi wrote:That's an interesting bug. I added it to the unofficial Trello board (https://trello.com/board/multiwii-devel ... 4c4d688e4c). I am not familiar with the GPS code, but after a brief look my theory is:

The whole position hold algorithm is based on velocity derived from GPS locations and a target velocity derived from the relative position error. It then calculates an "angles" it wishes to fly at so it reaches the target. These angles get rotated by the current heading so the copter tilts in the correct direction. I see multiple problems with this approach.
1) heading is more or less pretty stable when no metal is around, but GPS velocity is very inaccurate when the copter/person is moving very slowly.
2) the position error and calculated target velocities to go back to the target position should be ok
3) correct target velocities and slightly off GPS velocities probably leed to a tilt direction that is slightly off, but should come back the faster the copter gets ... hmmm

If this is correct improving accuracy of GPS velocity should counter this problem. Maybe with the help of accelerometer data (or airspeed sensors or optical flow) this can be achieved?

One more assumption here. If this issue reproduced only with windy condition I suppose that is related to rotation of accumulated wind compensation, i.e. slow "I" part of PID controller and applying this to not proportional motor MIXes. Actually it's proportional but during rotation it becomes not proportional

And I suppose that for QUADP/QUADX it's less reproducible because it has proportional MIXes (and applied power accordingly) for each 45 degree of rotation where HEX6/HEX6X has proportional MIXes only for each 90 degree... In two words when copter is stabilised in PH it means that integral part of PID controller keeps it tilted for wind compensation and when you start to yaw it, compensation become not actual because of the other power applied due to not proportional mixes...

So I see only one solution. It's GPS velocity improvement by using ACC to react on wind immediately but not only accumulated "I" slow part as wind compensation...

thx-
Alex

dramida · Post by **dramida** » Sat Oct 20, 2012 12:29 am

Let me tell you that i had the same gps pos hold bug with tricopter and also quadcopter ( i gathered a multiwii fleet here

) WInd is the incredient to test PH accuracy, because without wind, PH tests are pointless.
:idea:

Solution is simple and resembles with carefree mode : Rotate back correction vectors while copter yaws

But the way, in CF does it do the same? ( http://www.youtube.com/watch?v=Jx80YNWy_n4 ) ...to test tomorrow

dramida · Post by **dramida** » Thu Oct 25, 2012 8:43 pm

Sebbi wrote:That's an interesting bug. I added it to the unofficial Trello board (https://trello.com/board/multiwii-devel ... 4c4d688e4c). I am not familiar with the GPS code.........

Nice board about MWC software undies

dramida · Post by **dramida** » Sat Nov 03, 2012 9:50 am

I (http://fotografieaeriana.eu/index-en.html) want to donate an MWC UAV kit "UAV 433Mhz Autopilot GPS Flight Control System" (http://www.rctimer.com/index.php?gOo=go ... oductname= ) for each forum member who actively participate in GPS Waypoint Navigation software evolving.
Donations will be made gradually , accordingly to navigation software development.

dramida · Post by **dramida** » Mon Jan 21, 2013 9:43 pm

Thank you Hamburger for adding "service time" functionality in R1318 of MWC.

Code: Select all

//#define LOG_PERMANENT 1023
//#define LOG_PERMANENT_SHOW_AT_STARTUP // enable to display log at startup
 //#define LOG_PERMANENT_SHOW_AT_L // enable to display log when receiving 'L'
//#define LOG_PERMANENT_SERVICE_LIFETIME 36000 // in seconds; service alert at startup after 10 hours of armed time

So after 10 hours of running engines, it's time to change ball-bearings

If you still have the copter

)

Hamburger · Post by **Hamburger** » Tue Jan 22, 2013 11:21 am

dramida wrote: "service time" functionality in R1318 of MWC.
...
So after 10 hours of running engines, it's time to change ball-bearings If you still have the copter )

I prefer to think of it as it is time to upgrade the MultiWii firmware again

You are right, even more so for helicopters; with all that mechanics involved consistent maintenance is mandatory.

Mystic3D · Post by **Mystic3D** » Wed Jan 23, 2013 3:05 am

I am a noob to multis, but do understand the software development process. I get the sense from reading this forum, you guys have a pretty good handle on feature prioritization based upon the how many people are testing various features and contributing feedback( for those that don't have the skill). Each person writing the code has certain knowledge of various aspects, so they gravitate towards those naturally if interesting to them. Mostly just a great group of devs here, with a great leader.

I see Mutiwii greatly surpassing what a Naza can do this year. It already supports more copter configs, tuning ability, hardware types, not an easy task, the only piece missing is fail safe and good PosHold and RTH.

I am at a crossroads, I don't mind the work to get a Multiwii going, I just have a need to have a safety net for FPV. Maybe just keep the Paris(Multicopter) board and get a NAZA and a quad..

Anyway, amazing work guys.

dramida · Post by **dramida** » Wed Jan 23, 2013 9:24 am

I am curentrly flying FPV with MultiWii over long distances ( about 1-2 km) for aerial photography. I can tell you that RTH, position hold and Auto-landing is reliable for this purpose. (ps. autolanding and failsafe rth with autolanding is a newly implemented feature from NHAdrian, see viewtopic.php?f=8&t=2965)

ps. you may see the aerial pictures here:
www.facebook.com/filmare.fotografie.aeriana

MultiWii