Let's try to release 2.1: second try based on r964

This forum is dedicated to software development related to MultiWii.
It is not the right place to submit a setup problem.
Software download
gompf-2
Posts: 136
Joined: Sun Jun 05, 2011 11:46 am

Re: Let's try to release 2.1: second try based on r964

Post by gompf-2 »

Hamburger wrote:
gompf-2 wrote:ESC calib: initOutput() shoud be done before.

Sounds very reasonable. Did you verify it worked (better) with that change?

Yes, I compiled a V-Tail config on Arduino 1.01 and wanted to test the esc-calib first, led was blinking after a while but all outputs dead, tested with oszi. SW without esc calib was fine and esc calib worked fine also after i moved initOutput. Tested with scope and a mixed setup 2x BS 20A + 2xBS12A, still with stock Firmware.

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

Re: Let's try to release 2.1: second try based on r964

Post by alexia »

Sebbi wrote:
alexia wrote:
Jochen wrote:I got today a very interesting new Crius Board:

http://www.rctimer.com/index.php?gOo=go ... oductname=
(ATMega 2560 ·MPU6050 ·HMC5883L ·MS5611-01BA01 ·FT232RQ USB-UART chip and Micro USB receptacle)

It wold be a fine if anyone could add the IMU Code from the manual into the new release 2.1
http://www.rcgroups.com/forums/showatt. ... 1341616938



i think it s a good idea because this board will become a new standar in an near futur!!!matmega 2560 is a necessary for the next development!
i hope it will be take in consideration for the next release


The definitions for this board are the same as for FreeImu 4.3 ... just use that. As for the atmega 2560 being the future ... I seriously hope not, it is not a bit faster than then 328P and just offers more ports and rom/ram ... everyone should switch to 32 bit ARM and Arduino ist working on that (called "Due").



like alex say before,arduino is a good plateform and use 32bit plateform doesn t change anything in flight performance..but we need more rom and more memory for the next development so for me this new boad is new "standart"!!
http://fpvcentral.net/2012/07/crius-all ... ii-part-1/

itain
Posts: 75
Joined: Tue Aug 23, 2011 10:32 pm

Re: Let's try to release 2.1: second try based on r964

Post by itain »

Alexinparis wrote:Again a Github debate...
Doing this via a forum allows to have some discussions before thinking about modifying the code.
What you can "unproductive" is what I call "stability" ;)
True distributed development can only work among a trusted community of developers sharing the same view.
I realized it's not so obvious here because some choices were made deliberately to keep some Arduino principles.

Use of a forum for development is very important and it is independent of using Github or not. As I see it, GIT makes hierarchical development easier, and it reduces some overhead of merging. As of now, some hierarchy is already enforced by using separate branches.

I understand that being compatible with Arduino is important as it keeps a large user base. I agree that Multiwii should be able to compile with the Arduino environment for Arduino compatible controllers. Arduino would be happy to use C/C++ and H files and not just INO files (* comment below).

IMHO it is a good idea to change INO files to C or C++, and add required H files. I see only advantages: Cleaner code + it would also be possible to compile MultiWii outside the Arduino environment + it would make it easier to add CPU architectures that are not supported by Arduino + ports to different architectures can still use the same code base.

Well... That will not happen before 2.1 gets released, but please let us know if such change is acceptable for future versions.

* I just tried it, actually the .INO file can be empty if there are setup() and loop() functions in C files, or use main() instead and save valuable 294 bytes of program memory (for a sketch that contain nothing but these functions)!

LenzGr
Posts: 166
Joined: Wed Nov 23, 2011 10:50 am
Location: Hamburg, Germany
Contact:

Re: Let's try to release 2.1: second try based on r964

Post by LenzGr »

Hi Alex,

Alexinparis wrote:
LenzGr wrote:The code compiled fine and initial tests on the bench (using the stock PID values) looked good. The values displayed on the GUI were OK. I hope I'll get a chance to take it out tomorrow and will report back. Are you looking for any particular feedback? Any new feature that should be enabled?

I just expect a check on your own config, to detect a potential bug or a possible ambiguity in a function.

Thanks. I finally had a moment to take the copter out for testing, using my previous configuration. Everything worked as expected, it flies really well. Stable mode seemed to behave more reliable/predictable, but I don't have any hard evidence, just my personal impression. The Altitude hold mode seems to have slightly regressed compared to the code that's currently in the SVN trunk, but the weather conditions weren't that good yesterday to further investigate this.
The only thing that confused me (I did not notice this change when merging my old configuration) was the new possibility to also arm the copter using the roll stick - I suggest disabling that one by default to avoid nasty surprises for people who are used to arming with the yaw stick and not aware of this change.

ok, this if a wise remark.
//#define ALLOW_ARM_DISARM_VIA_TX_ROLL
will be commented by default.

Whoops, looks like I kicked off a bike shed discussion with this :)

LenzGr
Posts: 166
Joined: Wed Nov 23, 2011 10:50 am
Location: Hamburg, Germany
Contact:

Re: Let's try to release 2.1: second try based on r964

Post by LenzGr »

Alexinparis wrote:
Sebbi wrote:* general stuff: my copter flies pretty well and I attribute a lot of my problems to me being a beginner. The code looks clean enough but could use more comments from the authors of some of the algorithms used to make it easier to understand and improve the source code. Which brings me to the last point? Why is this not on Github or some other hoster which supports true distributed development? Github would also offer a bug/issue tracker. Doing this via a forum seems very unproductive ;-)

Again a Github debate...
Doing this via a forum allows to have some discussions before thinking about modifying the code.
What you can "unproductive" is what I call "stability" ;)
True distributed development can only work among a trusted community of developers sharing the same view.
I realized it's not so obvious here because some choices were made deliberately to keep some Arduino principles.

I don't think that moving from SVN to a distributed VCS system like git or Bazaar would render this Forum useless. In the end, communication and discussion is an essential part. However, I do believe that it would aid in the following ways:

  • Lower entrance barrier for contributions. Using SVN it's very inconvenient for new developers without commit rights to work on a new feature or larger code change, as checkpointing your work requires commit access to the central repository. Managing a patch without being able to commit makes it very tedious, especially if you want to keep your local branch current with the ongoing upstream development. With a DVCS, I can commit my changes locally and still keep my branch in sync with the main branch.
  • Stability. Right now, there is a _shared branch which acts as the central development/staging branch for all new features and code changes. As we've seen in the past, this approach can suffer from the "too many cooks" syndrome - it's possible that changes made by an individual affect the work of others, causing unnecessary friction. This would not be the case if everyone could work on his own branch, evolving and refining his code changes separately, but in sync with the main development. Once the individual change/feature has matured enough, it can be merged in one step, and the burden of merging can be offloaded to the contributor (by requiring him to keep his branch current with the code in trunk, for example). The trunk would be updated more incrementally, each time a new feature/bug fix has been merged. Right now, everything seems to be stuck in _shared and the next merge into the trunk will be huge.
  • Better change tracking and documentation. SVN does not do a very good job in carrying over individual commit messages when you merge from one branch to another. If you look at the trunk, you will see a commit message "merged from _shared" or similar. But what exactly was merged? A DVCS preserves this change history, making it easier to reconstruct who changed what and when, even after the code was merged several times.
  • Disconnected operations. I could work on the MultiWii code in the field, outside, while doing flight tests. Being able to commit these changes locally (without having to be online) might be another benefit
There is a number of additional advantages. I gave a presentation on that topic some time ago - you can see the video recording here, the slides can be reviewed from here.

Btw, Google Code supports git and mercurial, too - it's very easy to convert an existing SVN repository. There is no need to move to github, if you feel this is too much overhead. In fact, people who prefer to work on github can of course continue doing so, git does not really care where a repository is hosted).

And unrelated to the discussions about which tool we should use for managing the code, I do think it would make sense to look into using a bug tracker for keeping track of open issues and feature requests. A forum is nice for discussion, but it sucks for keeping track of things. The Google code bug tracker is there, we just need to make it a habit of using it...

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

Re: Let's try to release 2.1: second try based on r964

Post by Hamburger »

+1 on using a bug tracker, if the resulting aspects are clarified first:
- how do we educate the user base to use it (or is it a tool for developers only?)
- who does the work of managing the bug tracking/assigning/closing etc.?

warthox
Posts: 65
Joined: Sat Jan 29, 2011 10:05 pm

Re: Let's try to release 2.1: second try based on r964

Post by warthox »

Bledi wrote:No I had disarming 2 times during some special accro moves ... Now I always use switch to arm


how have u managed to disarm while flying?
its more or less impossible.
you can only disarm when throttle at zero which (throttle at zero) also means that the copter will not react to any stickinput nor it stabilzes itself....
i never had an accidently disarmed copter midair.

LenzGr
Posts: 166
Joined: Wed Nov 23, 2011 10:50 am
Location: Hamburg, Germany
Contact:

Re: Let's try to release 2.1: second try based on r964

Post by LenzGr »

Hamburger wrote:+1 on using a bug tracker, if the resulting aspects are clarified first:
- how do we educate the user base to use it (or is it a tool for developers only?)

I would start by establishing it as a tool for developers only, as they usually have a better insight for what's a bug and what isn't. Similar to how bugs and issues in the code are currently reported on this "Current development and bugs" board.

But of course it should be left it open for regular users to report issues as well. However, for a "normal user", it's usually hard to determine if their problem is a genuine bug in the code or a configuration/user error, so it's probably better to steer the discussion on the forum first. However, if during such a discussion it turns out that the problem is actually a bug, it should be filed and tracked accordingly (maybe including a link to the related forum discussion for background info).

The bug tracker should not be considered an alternative way of getting support - questions of such kind should be closed right away, with a hint to use the Forums instead. These bug reporting guidelines should be posted on the Wiki or as a sticky note on this board.

- who does the work of managing the bug tracking/assigning/closing etc.?

I'd handle this in an open fashion and improve/modify the process as we go along. Primarily it should of course be the "core developers" who work on the code base already anyway (and might even be the authors of the functionality in question). When you contribute new code and functionality, you should be prepared to maintain and improve it and to assume some responsibility. So again, the people initially in charge of handling bugs would be the ones working on the code already.

User avatar
Bledi
Posts: 187
Joined: Sat Sep 10, 2011 6:36 pm

Re: Let's try to release 2.1: second try based on r964

Post by Bledi »

warthox wrote:
Bledi wrote:No I had disarming 2 times during some special accro moves ... Now I always use switch to arm


how have u managed to disarm while flying?
its more or less impossible.
you can only disarm when throttle at zero which (throttle at zero) also means that the copter will not react to any stickinput nor it stabilzes itself....
i never had an accidently disarmed copter midair.

Eh I am not Warthox lol :D

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

Re: Let's try to release 2.1: second try based on r964

Post by Hamburger »

LenzGr wrote:
Hamburger wrote:+1 on using a bug tracker, if the resulting aspects are clarified first:
- how do we educate the user base to use it (or is it a tool for developers only?)

I would start by establishing it as a tool for developers only, as they usually have a better insight for what's a bug and what isn't. Similar to how bugs and issues in the code are currently reported on this "Current development and bugs" board.

But of course it should be left it open for regular users to report issues as well. However, for a "normal user", it's usually hard to determine if their problem is a genuine bug in the code or a configuration/user error, so it's probably better to steer the discussion on the forum first. However, if during such a discussion it turns out that the problem is actually a bug, it should be filed and tracked accordingly (maybe including a link to the related forum discussion for background info).

The bug tracker should not be considered an alternative way of getting support - questions of such kind should be closed right away, with a hint to use the Forums instead. These bug reporting guidelines should be posted on the Wiki or as a sticky note on this board.

- who does the work of managing the bug tracking/assigning/closing etc.?

I'd handle this in an open fashion and improve/modify the process as we go along. Primarily it should of course be the "core developers" who work on the code base already anyway (and might even be the authors of the functionality in question). When you contribute new code and functionality, you should be prepared to maintain and improve it and to assume some responsibility. So again, the people initially in charge of handling bugs would be the ones working on the code already.


thank you for giving this thorough in depth thoughts. I agree easily with what you said.
Only thing I am hesitant about is assigning bugs to others. Maybe it just requires getting used to, but not everybody may feel happy assigning bugs to others or even getting his own bugs assigned. In the worst case it could become associated with putting or receiving a blemish.
Seeing how we currently work this could be resolved by each developer fetching his own bugs himself; same like we do via the forum now. We have no assigning here now, so we may live for some more time without, just use the bug tracking software to ease our burden.

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

Re: Let's try to release 2.1: second try based on r964

Post by Hamburger »

gompf-2 wrote:
Hamburger wrote:
gompf-2 wrote:ESC calib: initOutput() shoud be done before.

Sounds very reasonable. Did you verify it worked (better) with that change?

Yes, I compiled a V-Tail config on Arduino 1.01 and wanted to test the esc-calib first, led was blinking after a while but all outputs dead, tested with oszi. SW without esc calib was fine and esc calib worked fine also after i moved initOutput. Tested with scope and a mixed setup 2x BS 20A + 2xBS12A, still with stock Firmware.

thank you. It is in the latest v2.1rc3 now.
(I only have flashed ESCs, so I could not test myself and prior responses did not clarify)

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

Re: Let's try to release 2.1: second try based on r964

Post by Hamburger »

itain wrote:I understand that being compatible with Arduino is important as it keeps a large user base. I agree that Multiwii should be able to compile with the Arduino environment for Arduino compatible controllers. Arduino would be happy to use C/C++ and H files and not just INO files (* comment below).

IMHO it is a good idea to change INO files to C or C++, and add required H files. I see only advantages: Cleaner code + it would also be possible to compile MultiWii outside the Arduino environment + it would make it easier to add CPU architectures that are not supported by Arduino + ports to different architectures can still use the same code base.

Well... That will not happen before 2.1 gets released, but please let us know if such change is acceptable for future versions.

* I just tried it, actually the .INO file can be empty if there are setup() and loop() functions in C files, or use main() instead and save valuable 294 bytes of program memory (for a sketch that contain nothing but these functions)!


good points for the future multi architectures MultiWii. more here viewtopic.php?f=24&t=1938

LenzGr
Posts: 166
Joined: Wed Nov 23, 2011 10:50 am
Location: Hamburg, Germany
Contact:

Re: Let's try to release 2.1: second try based on r964

Post by LenzGr »

Hamburger wrote:thank you for giving this thorough in depth thoughts. I agree easily with what you said.

Thanks! I'd be happy to contribute to the suggested sticky note or some general bug reporting guidelines. This is something I have been involved with professionally many times before.
Only thing I am hesitant about is assigning bugs to others. Maybe it just requires getting used to, but not everybody may feel happy assigning bugs to others or even getting his own bugs assigned. In the worst case it could become associated with putting or receiving a blemish.
Seeing how we currently work this could be resolved by each developer fetching his own bugs himself; same like we do via the forum now. We have no assigning here now, so we may live for some more time without, just use the bug tracking software to ease our burden.

It's probably a question of how bug reports are being perceived, and the overall amount of incoming bugs. I personally am happy about any feedback I get on code that I wrote, so I don't consider bug reports as a burden or something negative. Of course, the ideal case would be that bugs are simply grabbed by the individual most experienced in the code at hand (how it's actually done in this forum at the moment). Once the inflow of bugs increases, it may make sense to appoint someone (or multiple persons) to act as "gatekeepers", to go through the incoming bugs and do a first-level classification/screening. If they actually happen to know who might be the best individual to look into a bug, they should be entitled to also re-assign it to him right away.
But I expect this workflow to gradually evolve - it's just a matter of getting started and making it a habit to ask for the submission of a bug report when discussing an issue or feature request on the forum. The nice thing about a bug tracker is that it allows you to organize and prioritize the work.

warthox
Posts: 65
Joined: Sat Jan 29, 2011 10:05 pm

Re: Let's try to release 2.1: second try based on r964

Post by warthox »

Bledi wrote:
warthox wrote:
Bledi wrote:No I had disarming 2 times during some special accro moves ... Now I always use switch to arm


how have u managed to disarm while flying?
its more or less impossible.
you can only disarm when throttle at zero which (throttle at zero) also means that the copter will not react to any stickinput nor it stabilzes itself....
i never had an accidently disarmed copter midair.

Eh I am not Warthox lol :D


:D

it was more or less a serious meant question. really.
i set throttle with throttle trim that its only possible to disarm when throttle is really at zero. a bit over zero throttle and the stabilization is active and disarm isnt possible.

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

Re: Let's try to release 2.1: second try based on r964

Post by Alexinparis »

itain wrote:
Alexinparis wrote:Again a Github debate...
Doing this via a forum allows to have some discussions before thinking about modifying the code.
What you can "unproductive" is what I call "stability" ;)
True distributed development can only work among a trusted community of developers sharing the same view.
I realized it's not so obvious here because some choices were made deliberately to keep some Arduino principles.

Use of a forum for development is very important and it is independent of using Github or not. As I see it, GIT makes hierarchical development easier, and it reduces some overhead of merging. As of now, some hierarchy is already enforced by using separate branches.

I understand that being compatible with Arduino is important as it keeps a large user base. I agree that Multiwii should be able to compile with the Arduino environment for Arduino compatible controllers. Arduino would be happy to use C/C++ and H files and not just INO files (* comment below).

IMHO it is a good idea to change INO files to C or C++, and add required H files. I see only advantages: Cleaner code + it would also be possible to compile MultiWii outside the Arduino environment + it would make it easier to add CPU architectures that are not supported by Arduino + ports to different architectures can still use the same code base.

Well... That will not happen before 2.1 gets released, but please let us know if such change is acceptable for future versions.

Yes, it's fully acceptable.
There is also one drawback with .ino file: we can't choose the merging order (in fact it's based on the first letter for the ino file).

Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: Let's try to release 2.1: second try based on r964

Post by Tommie »

LenzGr wrote:[*] Lower entrance barrier for contributions. Using SVN it's very inconvenient for new developers without commit rights to work on a new feature or larger code change, as checkpointing your work requires commit access to the central repository. Managing a patch without being able to commit makes it very tedious, especially if you want to keep your local branch current with the ongoing upstream development. With a DVCS, I can commit my cnges locally and still keep my branch in sync with the main branch.

Don't forget that interested users can pick changes from various repositories. Take for example the code for optical flow sensor: It is extremely inconvinient to integrate it into a current code base. With git, picking and integrating those features would be much easier. I'm maintaining a set of local changes in my github repository, staying in sync with the main codebase. I have no idea how I'd be able do that at all with SVN.

Of course, this requires proper use of the version control system, e.g., don't do this:
* Change 10 different things in a single commit; one commit should always atomically handle a single topic so it can easily be picked, reverted or bisected
* write meaningless ("change stuff") or empty commit messages

Of course, this applies to SVN as well.

Post Reply