MultiWii

Tommie

But you can't activate a single function like HEADFREE with let's say AUX1 L and AUX2 H or something like that. Which is a dealbreaker for many applications. Why not ditch processing and put more effort into the existing Swing GUI project, which actually provides real widgets and not just a drawing...

Tommie

I just pointed that out; if you have a switch that enables HEADFREE, you probably want the same switch to engage ANGLE mode as well - even if there alredy is another switch fr controlling the flight mode (NONE/HORIZON/ANGLE)

Tommie

A short time ago, the capability to store 3 different configuration profiles was added to the firmware; this patch makes this addition optional and configurable through config.h; I do not need multiple profiles in my firmware, but the associated code occupies ~150 byte of flash memory. This addition...

Tommie

Up to 12 AUX channels and 6 binary style encoded steps per channel. The only downside of the new layout is that one function can not be enabled by more than one AUX channel anymore, but at the moment I don´t know why somebody wanted to this!? What do you think? This is needed. If I enable HEADFREE,...

Tommie

And again, I rebased the patch to the latest _shared branch. I'd really ike to spark some kind of technical discussion about this - something I haven't seen in a while. What is the technical reason for not including this? m Actually only the first patch is needed, the second one just adds a compatib...

Tommie

Hi, If every developer would maintain features in their own branches, the community could quickly decide what a good feature/fix/improvement is and Alex can merge it with trunk (or master in git-language) sooner. Ok lets say it happens. How to deal with incompatible features ? (example: the same MS...

Tommie

But any attempt to represent the extra channel in the GUI should deal also with extra BOX. Tommie suggested and adaptation I'm not ok with. I would like to see discussions on the implementation before discovering a sudden commit about this, especially when MSP part is concerned Well, that's what I ...

Tommie

Ok, now I'm with you. That's the reason I split the screen. But why didn't you go one with my project? It based totaly to your AUX Because your project did not exist when I extended my firmware and GUI? I'm still not quite getting your point - please join the IRC channel, I guess that'll be easier ...

Tommie

http://stefans.datenbruch.de/temp/multiwii-gui-aux-5-6.png There you go. The copter informs the GUI about the number of AUX channels (6) and steps (3), and the gui draws the appropiate number of boxes. Not pretty, but working since 2012-06-26 Feel free to join #multiwii on the Freenode network, it'...

Tommie

It was possible from day one. Just adding advanced AUX capabilities to the firmware without updating the GUI would have been quite useless.

https://github.com/wertarbyte/multiwii- ... x_channels
The branch aux_channels contains the patches necessary for it.

Tommie

cGiesen wrote:And even you didn't have a solution to do the settings for the new functions.

What do you mean by that? I can assign stuff to AUX5-8 fine here using my GUI fork.

Tommie

cGiesen wrote:Setup flightmode functions to AUX channel higher then 4 is not possible because of the design of the firmware

It's not like there hasn't been a patch available for months now:
viewtopic.php?f=8&t=2470

Tommie

Hello! @Tommie: What do you exactly meant by "havoc"? - uncontrollable behavior of copter (SW crash) or - behavior that is unexpected by user (that expects instant and hard recovery of angle mode) Copter flipped on its head and crashed with HORIZON + HEADFREE, probably because the MAG cou...

Tommie

Hamburger wrote:So there really is no reason to debate further if everones desired result can be achieved regardless of precedence.

Which is clearly not the case. If you have a switch that enables HEADFREE, that same switch has to disenage HORIZON mode if it has a higher priority.

Tommie

it was corrected but in the other way: HORIZON mode supersedes the ANGLE mode I use 2 separate switches to activate either one. I prefer the current superseding over the inverted alternative. Can you explain why? I'd argue that the conservative approach of using ANGLE instead of HORIZON is the righ...

Tommie

I am using a switch to change between three states: HORIZON, ANGLE, ANGLE+MAG. Another switch enables HEADFREE mode. Engaging HEADFREE mode while in HORIZON wreaks havoc. So I made the switch enable ANGLE mode as well, but this has to disable HORIZON mode as well (since all switch positions are ORd)...

Tommie

While playing around with HORIZON and HEADFREE mode, I noticed that combining HEADFREE/HORIZON as well as HORIZON/ANGLE/HEADFREE can wreak havoc; I therefore added this patch to make the stricter ANGLE mode supersede the less rigid HORIZON mode.

https://github.com/wertarbyte/multiwii- ... 52962f736f

Please merge.

Tommie

it was already debated here: http://www.multiwii.com/forum/viewtopic.php?f=8&t=1933 to sum up my view: not against the idea, but against the suggested implementation Have your tried the rebased implementation? It actually uses less flash memory than the one currently used by Multiwii while prov...

Tommie

While in flight and while not hovering above the ground, the landing lights are usually turned off. This patch allows the inclusion of the lights into the pattern of the LED flasher code, so the landing lights are on while at low sonar altitude and start flashing with the other light signals accordi...

Tommie

Depending on the type of transistor used, inverting the output pin controlling the landing lights is needed; this
patch adds this capability (just like the previous patch does for the LED flasher):

https://github.com/wertarbyte/multiwii- ... c3f8ab366d

Please merge.

Tommie

I'm not claiming to be the first to come up with the idea; I am just complaining that submitting patches to this forum and project is obviously completely useless; they get completely ignored, there is no technical discussion about the reasons for that, but sdometimes, the same feature pops up later...

Tommie

It's just something I pointed out several times before: people invest time to create patches and fix problems with their firmware, publish the patch in this forum - where it gets ignored and starts rotting due to the source code base moving further. Then after some time, somehow picks up the idea, r...

Tommie

Oh yes, I just checked your links - looks like someone already created a patch for Multiwii with checksum creation in april. Oh, I also just noticed that it was me.

Tommie

Oh, I stand corrected, using a mod checksum of course lessens the risk of accidental misvalidation. I still would have appreciated some kind of technical discussion in this thread before making an existing and proposed patch obsolete by another implementation with the same goal.

Tommie

Please look again. My patchset performs several checks to ensure the validity of the configuration data: 1) is the version number identical? 2) is the configuration struct size identical? 3) are the magic canary numbers intact that frame the configuration data? 4) does the XOR checksum match? 2 and/...

Tommie

magic_be and magic_ef seem to be an over protection No. Consider removing a boxitem, which results in the removal or addition of 2 byte from the conf struct: this will not alter the checksum value, and depending on the values will slip through unnoticed. That's why the canary members magic_be and m...

Tommie

I have more a generic question: Why take ideas from the forum, re-implement them in an inferior way, and not even give a single line of credit to the proposer in the commit message? m While I appreciate the addition of a checksum to the conf struct, my changes address the issue far more thoroughly; ...

Tommie

These patches transport the magnetic and headfree reference heading to the GUI and indicate them inside the compass; I find it extremely useful to have this information while playing around with MAG and HEADFREE modes:

https://github.com/wertarbyte/multiwii- ... sp_heading
https://github.com/wertarbyte/multiwii- ... sp_heading

Please consider integrating this into the main codebase.

Tommie

Feel free to merge, the patch set is there.

Tommie

So like, this patch simply makes aux arming a compile time decision to include or not. you can simple apply the patch, make the function included by default, and there is no difference for end users. Why is this discussion 2 pages long already. Well, especially since this is the wrong thread about ...

Tommie

Well, no one advocates removing the ARM box for everyone, I just find it convinient to remove it through my personal configuration choice.
Please look at patches being discussed before crying about how stuff is taken away from you.

Tommie

why is arming via aux useless? I fly three different copter softwares and all use an arm switch.imho there is no alternative to that. I want control over armed status like in my car. you do not have to use it . just leave the boxes empty. Leaving the boxes empty does not help if an undetected EEPRO...

Tommie

As we found out, arming the copter via AUX can be dangerous, especially if a stray bit launches the copter by itself.

This patch adds the ability to remove the ARM-via-AUX function from the copter firmware:

https://github.com/wertarbyte/multiwii- ... le_aux_arm

Please consider adding this diff to the main code base.

Tommie

I enabled/disabled camstab tonight during some debugging. And your fear confirmed - the arm button became enabled. Of course I had the props off... Can someone PLEASE merge the patch that makes arming via AUX configurable? => https://github.com/wertarbyte/multiwii-firmware/compare/upstream_shared.....

Tommie

Are you actually using the ARM function via AUX switch? I once proposed a patch making it possible to disable that feature. It did not get included though.

Tommie

With the latest changes, the EEPROM layout changes with the options enabled in config.h; if a copter does not use GPS, the configuration struct lacks the necessary fields for it. This creates a potential danger that fields might be misplaced if additional sensors are added or removed from the copter...

Tommie

Depending on the lighting conditions, having a strong flashing pattern can be helpful or distracting; therefore while switching the pattern to a static illumination (LEDMAX) might be desired, turning the LEDs off completely might be an option as well. This patch adds the ability to select a low inte...

Tommie

I have rebased my patches for increasing the number of AUX channels and steps; with those it is possible to change the number of AUX channels as well as the number of steps in each channel. It also requires a new GUI, but also decreases the flash size slightly when sticking to the new message code f...

Tommie

Depending on the wiring (PNP or NPN transistor), the LED controlled by LED_FLASHER might be inverted. This configuration define inverts the control loop so the desired behaviour is achieved:

https://github.com/wertarbyte/multiwii- ... b71826d820

Tommie

In current _shared, LED_FLASHER cannot be compiled if BUZZER is undefined. This patch fixes this issue:

https://github.com/wertarbyte/multiwii- ... a6439f9737

Tommie

Mis wrote:If anyone use ledflasher output for control led strips, with this we have visual feedback of any alarm indicated by buzzer, but if buzzer is silent, the ledflasher work normally.

And it breaks compilation if no buzzer is attached.

Tommie

What does this change do? void auto_switch_led_flasher() { uint8_t seg = (currentTime/1000/125)%8; if (led_flasher_sequence & 1<<seg) { switch_led_flasher(!isBuzzerON()); } else { switch_led_flasher(isBuzzerON()); } } So the flasher pattern is inverted if the buzzer is on? ? If anyone use ledfl...

Tommie

https://github.com/wertarbyte/multiwii- ... a6eb44aa8c
This is the commit.

a) what is the LEDFLasher change supposed to do?
b) can we please stuff even more completely unrelated changes into single commit?

Tommie

What does this change do? void auto_switch_led_flasher() { uint8_t seg = (currentTime/1000/125)%8; if (led_flasher_sequence & 1<<seg) { switch_led_flasher(!isBuzzerON()); } else { switch_led_flasher(isBuzzerON()); } } So the flasher pattern is inverted if the buzzer is on? ?

Tommie

I'm having the same issue, the copter is just wobbling like crazy. But it seems that it is possible to use the ESCs:
http://www.datmartens.com/en/projects/q ... copter.php
https://www.youtube.com/watch?v=V1Ls-s3ZBoc
https://www.youtube.com/watch?v=D8PtcZ4Hydk
Any ideas about that?

Tommie

I tried to replicate the changes you added to my patchset here; I condensed them a little bit, can you check whether all changes are actually included?

https://github.com/wertarbyte/multiwii- ... x_channels

New stuff: https://github.com/wertarbyte/multiwii- ... a490fd47d8

Tommie

Hm, somehow a lot of stuff got included into your patch, not just the AUX channel improvements. Would you mind joining #multiwii so we can straighten it out a little bit?

Tommie

What does this change do? void auto_switch_led_flasher() { uint8_t seg = (currentTime/1000/125)%8; if (led_flasher_sequence & 1<<seg) { switch_led_flasher(!isBuzzerON()); } else { switch_led_flasher(isBuzzerON()); } } So the flasher pattern is inverted if the buzzer is on?

Tommie

It might also depend on your hardware (Bluetooth, USB2serial, operating system etc.); I actually planned to limit UI transmissions so that only one request is "up in the air" at any given time, so that the next request is only issued once the former one has been answered, but somehow that ...

Tommie

Hello Tommie Since my patch regarding boxitems (http://www.multiwii.com/forum/viewtopic.php?f=8&t=2107 using an enum instead of #defines) has been applied (although somewhat changed: m), I had to rebase this patchset; it has already been done, please check: m whats the base of this patch? I try...

Search found 438 matches