MultiWii Conf for more than 4 AUX channels

cGiesen · Post by **cGiesen** » Tue Oct 09, 2012 9:15 am

Hello,

I'm happy to see, the MWii now support more than 4 AUX Channels when using the sum signal.
But the GUI can't show this

So again: here you can find a GUI to show more than 4 AUX channels:
https://github.com/cGiesen/multiwii-gui-processing.git

I split the screen in to screens, one for settings:

on for liveview:

But in general we have to think about a more flexible way, my solution is also limited to 8 AUX channels

Regards
Carsten

shikra · Post by **shikra** » Tue Oct 09, 2012 10:43 am

I cant imagine ever needing more than 8. I don't even use four and my copter is pretty blinged up with addons...

Or maybe just a rubbish pilot ! - can't deal with more than 2 or 3 switches on a copter when flying!

cGiesen · Post by **cGiesen** » Tue Oct 09, 2012 10:53 am

This is not realy helpfully

There are a lot of user who ask for more than 8 channels.
The new code can deal with that!
But you can't see this and can't set it up.

So this is only for user, who are interesting in that.

fiendie · Post by **fiendie** » Tue Oct 09, 2012 11:17 am

shikra wrote:I cant imagine ever needing more than 8. I don't even use four and my copter is pretty blinged up with addons...
Or maybe just a rubbish pilot ! - can't deal with more than 2 or 3 switches on a copter when flying!

I always hate it when people say stuff like this: "I can't imagine it being useful therefore nobody should need it!".
I am a particularly crappy pilot and even I can think of ways to use more than 4 AUX channels.

There is already so much arcane stuff in MultiWii that only a few people need/use (LCD anyone?), why stop here? There certainly is no technical reason IMO.

shikra · Post by **shikra** » Tue Oct 09, 2012 1:30 pm

LOL.

cGiesen - I agree - unhelpfull - just thinking aloud

fiende - - you misquoted me. I hate that viewpoint too ... I was talking purely for myself... if you need more - fill your boots.
I use LCD a lot BTW... No laptop to take to field.....
Also use OLED / bluetooth android. Android app is best, but I like the LCD/OLED because always work on dev versions...

Sebbi · Post by **Sebbi** » Tue Oct 09, 2012 2:51 pm

shikra wrote:I cant imagine ever needing more than 8. I don't even use four and my copter is pretty blinged up with addons...

Or maybe just a rubbish pilot ! - can't deal with more than 2 or 3 switches on a copter when flying!

1) set flight mode (acro/level/althold)
2) gps (pos hold / rth)
3) switch led pattern
4) camera pitch
5) camera roll
6) camera yaw
7) camera shutter
8) camera zoom
9) flaps
10) landing gear
11) next waypoint
12) data uplink (slow modem)

I could think of more, but then it gets rediculous ;-)

It's hard to imagine a copter that needs all this functionality during a single flight, so profile switching or a seperate RC für the camera would be fine too.

fiendie · Post by **fiendie** » Tue Oct 09, 2012 3:02 pm

shikra wrote:fiende - - you misquoted me. I hate that viewpoint too ...

Fair enough

I was talking purely for myself... if you need more - fill your boots.

would need more but my Tx only has 8 ;P
Still working on a way to multiplex switches with open9x/er9x.

I use LCD a lot BTW... No laptop to take to field.....
Also use OLED / bluetooth android. Android app is best, but I like the LCD/OLED because always work on dev versions...

That's kinda my point, isn't it?
I don't use it but if it floats your boat, by all means...
As long as I can turn it off I'm fine with it

shikra · Post by **shikra** » Tue Oct 09, 2012 6:02 pm

Yes. For all this functionality as long as can disable/enable its perfect...

But so much now in config. I haven't got a clue what half of it does...

All cool.... Sorry to hijack thread cGiesen...

cGiesen · Post by **cGiesen** » Tue Oct 09, 2012 7:45 pm

Hello,

my GUI didn't show the additional channels, because of missing commands in the serial.ino.

to get it working please change the

Code: Select all

r1143

code liek this:

row 52:

Code: Select all

#define MSP_WP                   118   //out message         get a WP, WP# is in the payload, returns (WP#, lat, lon, alt, flags) WP#0-home, WP#16-poshold

#define MSP_AUX_COUNT            119   //out message         number of AUX channels

#define MSP_SET_RAW_RC           200   //in message          8 rc chan

row 310:

Code: Select all

   case MSP_RC:
     headSerialReply(RC_CHANS * 2);
     for(uint8_t i=0;i<RC_CHANS;i++) serialize16(rcData[i]);
     break;

row 409:

Code: Select all

   case MSP_AUX_COUNT:
     headSerialReply(2);
     serialize8(RC_CHANS);
     serialize8(3);
     break;

regards
Carsten

cGiesen · Post by **cGiesen** » Sun Oct 14, 2012 10:29 am

Hello,

I stop my project take the actual one and enhance showing the channels.
Setup flightmode functions to AUX channel higher then 4 is not possible because of the design of the firmware

cu
Carsten

Tommie · Post by **Tommie** » Sun Oct 14, 2012 10:40 am

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

cGiesen · Post by **cGiesen** » Sun Oct 14, 2012 11:03 am

Yes, I know. I used this code to use my channels.
But when you see the diskussions here, you see what they are thinking about ideas, that are not from the masters...

And you see me first GUI. But nobody see the chance to go a different way.
And even you didn't have a solution to do the settings for the new functions.
And you didn't use my startup to, so my work is for the garbage can.I have to be realistic...

I have now more time for HoTT telemetrie ...

Tommie · Post by **Tommie** » Sun Oct 14, 2012 11:23 am

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.

cGiesen · Post by **cGiesen** » Sun Oct 14, 2012 11:29 am

Perhaps I'm blind....
But I download your GIT this morning and try the diffrent PDE's

I didn't find a way?!?!?!

Do you have a screenshot?

Tommie · Post by **Tommie** » Sun Oct 14, 2012 11:32 am

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.

cGiesen · Post by **cGiesen** » Sun Oct 14, 2012 12:40 pm

I try it from day one, without any luke.
Thats the eason I start my project.

Please give me screenshot.

Tommie · Post by **Tommie** » Sun Oct 14, 2012 12:49 pm

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's probably a faster and easier way to solve such misunderstandings.

cGiesen · Post by **cGiesen** » Sun Oct 14, 2012 1:21 pm

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

cGiesen · Post by **cGiesen** » Sun Oct 14, 2012 1:23 pm

Bye the way....
Use 6 Steps and 4 channels.
This break your screen.

And we are allway allone....

Tommie · Post by **Tommie** » Sun Oct 14, 2012 1:30 pm

cGiesen wrote: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 for both of us.

copterrichie · Post by **copterrichie** » Sun Oct 14, 2012 1:35 pm

I would advise NOT joining that IRC channel, but to each their own way of thinking and opinions.

cGiesen · Post by **cGiesen** » Sun Oct 14, 2012 1:49 pm

I'm sitting in a car with my iPad. I can't join the channel.
But perhaps I'm comming to the meeting in essen, when I'm back in time.

But please try my version. I'm interssting to know if it work for you.
But load the previos version!!!

nicog · Post by **nicog** » Sun Oct 14, 2012 1:51 pm

@copterihci: Seriously?

Spooky. Are they real?

cGiesen · Post by **cGiesen** » Sun Oct 14, 2012 1:52 pm

copterrichie wrote:I would advise NOT joining that IRC channel, but to each their own way of thinking and opinions.

I'm thinking the same as tommie!!

But the community thinking different.
For my opinion tommie's way is the better one...

copterrichie · Post by **copterrichie** » Sun Oct 14, 2012 2:07 pm

Then keep the discussion within the community verse moving it to an IRC chat room, if I may suggest.

Alexinparis · Post by **Alexinparis** » Thu Oct 18, 2012 12:00 am

I saw Hamburger committed a change to transmit every RC channel (MSP_RC).
Why not as it won't interfere with existing GUIs that will just skip the extra 9 and + chans.

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

cGiesen · Post by **cGiesen** » Thu Oct 18, 2012 12:26 am

Hello Alex,
Way mot your comment earlier
Please see the start of this thread.
To deal wih that, we have to splitt the screen as so see in the first post.
I have that, but nobody see that??!
Or are interesting in that.
So what should we do?

cGiesen · Post by **cGiesen** » Thu Oct 18, 2012 7:22 am

And by the way.
As long, as the firmware can't handle AUX for for more than 16 items, it is not important to deal with that.
And in the moment I do not see that this is comming.
Yes Tommie has a solution, but only get messages like this:
No body need that, who can remember more than 4 switches and 3 stepps.

I have my old code of corse. I can upload again.
But than than the horizion is not in.

And a completly other question. Is there a w

cGiesen · Post by **cGiesen** » Thu Oct 18, 2012 7:23 am

Sorry, tapatalk .....

Is there a way or an addon that I can easier

cGiesen · Post by **cGiesen** » Thu Oct 18, 2012 7:25 am

Merre
Is there a way that I can easier create a graphik GUI.
In the moment it is try and error.
I see there is a other controll set, but changing is not realy a optiom

Hamburger · Post by **Hamburger** » Thu Oct 18, 2012 8:35 am

Alexinparis wrote:I saw Hamburger committed a change to transmit every RC channel (MSP_RC).
Why not as it won't interfere with existing GUIs that will just skip the extra 9 and + chans.

I contacted Danal to check for side effects (Danal is the author of spektrum support with 12 channels). He verified it was ok. I am not personally interested in this 9+ channel thing, I did the commit as a favour. Now i am out of this.

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

Danal is interested in working on the GUI side as well.

Tommie · Post by **Tommie** » Thu Oct 18, 2012 11:42 am

Alexinparis wrote: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 asked for - I still don't see the catch with my implementation. The current setup of assuming 4x3 AUX channels is just a dead end that cannot be extended without introducing a new message type.
The MSP_AUX message I proposed is flexible, allowing any number of channels and steps, so we are safe for future extensions. And it does not even increase the flash footprint. Sometimes it is just time to admit that one has painted oneself in a corner with hardcoded assumptions and just cut the losses.

cGiesen · Post by **cGiesen** » Fri Oct 19, 2012 12:39 pm

Alexinparis wrote: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

Hello Alexinparis,

please can you say what you realy want?!?!?!?!?!
You want to have the new idea from tommie, but you are not OK with this ideas.

So what do you want?

And by the way. I do nothing in processing any more!
Even not, now body give a clear position here and coding in processing is nightmare.

When I do some thing, I start with eclipse and WinBuilderPro.
Processing is a dead end and an "No Go"

cu
Carsten

Danal · Post by **Danal** » Sat Oct 20, 2012 10:50 pm

I've read this thread and I'm not sure I understand all the points of view. I believe the following are facts, correct me if I'm wrong:

A "Regular" receiver puts 4 to 8 channels into MultiWii
Serial Sum PPM, Spektrum, and Futaba SBUS all put more; 12, 12, and 18 respectively
The received data for the extra channels are updated correctly in the rcData array (and all the arrays and code that lead up to it in the rx.ino module)
No part of the Multiwii code does anything with more than 8 channels as written at this moment

And:

Hamburger made a change to MSP code in Multiwii to send whatever length of data (8, 12, or 18 channels x 2 bytes each) was compiled. There is/was no associated change to the Processing GUI
I tested that change to ensure it broke nothing in the Processing GUI
It didn't break anything in the Processing GUI; the MSP protocol, when presented with bytes that the individual 'case' statement doesn't read, 're-syncs' itself to the next occurrence of the header; no harm
I don't know if this would break any other GUIs, like the Android one, or whatever. If it does break them... then they are not very robust!!

Hopefully, that's a good recap. Now my opinions:

Based on the second group of facts, I personally do not see any need for any other changes to the MSP protocol. In particular, there is no need for a message that says how many channels are sent. The header length of the message containing the channels themselves already sends you this. As such, I don't even really see Hamburger's change as a change to MSP. Then length of message 105 should never be assumed; it should be parsed. That's why we have headers...

And... Whatever we decide to do with the GUI to allow it to display more AUX channels, dynamically depending on the content of message 105, whether it's change the size of the whole window to gain more room, or put a scroll bar by the channels, or change it to two (or more) "Tabbed" windows... whatever we decide to do as a group, I'm willing to do it. In processing.

Danal

cGiesen · Post by **cGiesen** » Sun Oct 21, 2012 8:59 am

Hello Danal,
that's realy a very good summary.

But now we have to discuss the future. OK You say, stay at processing. Did you have a way to have same more assistans to design the GUI?
I didn't found a way, but I faund a way witch Eclipse...
If there is way like that, than it's ok for me.

When you see the start of this thread, you see, I have startet to change the GUI and have two tabs.
I stopped, because of the design of MultiWii. There is no way to use more than 4 AUX, because the var has only 16 bit.

So my change, to only show the additional AUX Channels is only a "nice to have".

But it's up to Alexinparis now, he has to say, why he block every work and ideas in this direction.

If he go with us the way to have a flexible way to handle additional AUX channels (say idea from Tommie is a very good way) we can discuss how we can change the GUI to.
Otherwise is's only work for the trashcan.

cu
Carsten

Danal · Post by **Danal** » Sun Oct 21, 2012 1:18 pm

cGiesen wrote:There is no way to use more than 4 AUX, because the var has only 16 bit.

I'm not sure I grasp this. Which var?

Mis · Post by **Mis** » Sun Oct 21, 2012 1:19 pm

Additional channels (above AUX4) can be used for gimbal pitch & roll control, or for something else like control interval of CamTrig servo, and maybe for some others features. Can be directly transferred to servo outputs too.

arne · Post by **arne** » Sun Oct 21, 2012 1:35 pm

@cGiesen: I think your tone won't help you with this. Yes, like Tommy's approach, you did offer a modified GUI to deal with the additional AUX channels, both are fine for basic testing, but not ready for the masses. It has a lot of free space and shows the input values and the AUX channels on different pages, which doesn't help while testing. Listen to the other dev's and offer a nice + complete patch and I'm sure you will have success.
I really like to see more aux channels and more channel states support for MWC, but I'd rather wait some time for a nice flexible solution instead of multiply hacks to the current one.

Sebbi · Post by **Sebbi** » Sun Oct 21, 2012 2:18 pm

Danal wrote:
cGiesen wrote:There is no way to use more than 4 AUX, because the var has only 16 bit.

I'm not sure I grasp this. Which var?

I think he is refering to the MSP_SET_BOX command, which sends a 16 bit variable for all checkbox items to determine what value (low/mid/high) should be set for which AUX channel. That allows for only 5 AUX channels, before running out of bits and would require a change for 32 bit, which would allow 10 AUX channels or a more flexible solution to set individual ranges per AUX channel.

However, you can use additional channels (the 6th, 7th, etc) for potentiometers to directly control servos, without modification of the protocol (think headtracking, gimbal control, zoom, etc).

copterrichie · Post by **copterrichie** » Sun Oct 21, 2012 2:39 pm

Just seems to me, it is time to consider building specialized Digital bidirectional radio system that will handle telemetry and flight commands. there are pockets of developments underway, just need some centralization to bring it all together.

Sebbi · Post by **Sebbi** » Sun Oct 21, 2012 3:15 pm

That is called Xbee and works for kilometers/miles ... nobody know why RC pilots are not using it ... maybe because no normal TX supports Xbee modules directly, but I have a friend who flys his quad with xbee only ;-)

Danal · Post by **Danal** » Sun Oct 21, 2012 5:04 pm

Sebbi wrote:
Danal wrote:
cGiesen wrote:There is no way to use more than 4 AUX, because the var has only 16 bit.

I'm not sure I grasp this. Which var?

I think he is refering to the MSP_SET_BOX command, which sends a 16 bit variable for all checkbox items to determine what value (low/mid/high) should be set for which AUX channel. That allows for only 5 AUX channels, before running out of bits and would require a change for 32 bit, which would allow 10 AUX channels or a more flexible solution to set individual ranges per AUX channel.

However, you can use additional channels (the 6th, 7th, etc) for potentiometers to directly control servos, without modification of the protocol (think headtracking, gimbal control, zoom, etc).

Got it, thanks!!

So the extrachannels make it from TX to RX, and into the array in the flight code... and we can do anything we want in flight by pulling them directly out of the array... they also get reported to the GUI as individual channel values (after Hamburger's change) but are not displayed (yet). It is checkbox that is awkward at the moment.

Understood.

Alexinparis · Post by **Alexinparis** » Sun Oct 21, 2012 7:02 pm

Thanks Danal,
It's a very good summary

Danal wrote:I've read this thread and I'm not sure I understand all the points of view. I believe the following are facts, correct me if I'm wrong:
A "Regular" receiver puts 4 to 8 channels into MultiWii
Serial Sum PPM, Spektrum, and Futaba SBUS all put more; 12, 12, and 18 respectively
The received data for the extra channels are updated correctly in the rcData array (and all the arrays and code that lead up to it in the rx.ino module)
No part of the Multiwii code does anything with more than 8 channels as written at this moment

And:
Hamburger made a change to MSP code in Multiwii to send whatever length of data (8, 12, or 18 channels x 2 bytes each) was compiled. There is/was no associated change to the Processing GUI
I tested that change to ensure it broke nothing in the Processing GUI
It didn't break anything in the Processing GUI; the MSP protocol, when presented with bytes that the individual 'case' statement doesn't read, 're-syncs' itself to the next occurrence of the header; no harm
I don't know if this would break any other GUIs, like the Android one, or whatever. If it does break them... then they are not very robust!!

Hopefully, that's a good recap. Now my opinions:

Based on the second group of facts, I personally do not see any need for any other changes to the MSP protocol. In particular, there is no need for a message that says how many channels are sent. The header length of the message containing the channels themselves already sends you this. As such, I don't even really see Hamburger's change as a change to MSP. Then length of message 105 should never be assumed; it should be parsed. That's why we have headers...

And... Whatever we decide to do with the GUI to allow it to display more AUX channels, dynamically depending on the content of message 105, whether it's change the size of the whole window to gain more room, or put a scroll bar by the channels, or change it to two (or more) "Tabbed" windows... whatever we decide to do as a group, I'm willing to do it. In processing.

Danal

Alexinparis · Post by **Alexinparis** » Sun Oct 21, 2012 7:18 pm

cGiesen wrote:Hello Alexinparis,

please can you say what you realy want?!?!?!?!?!

Could you please take time to read carefully the previous discussion on this topic.
Especially this post and the followings:
viewtopic.php?f=8&t=1933&start=20#p19394

cGiesen wrote:You want to have the new idea from tommie, but you are not OK with this ideas.

Where did you read I "want" this new idea ?

And by the way. I do nothing in processing any more!
Even not, now body give a clear position here and coding in processing is nightmare.

When I do some thing, I start with eclipse and WinBuilderPro.
Processing is a dead end and an "No Go"

I don't understand the point.
You've got some multiwii compatible and open source GUIs which are not at all coded with processing (hint: EOSBandi or Ezio).
Why do you stick on the processing one ?

But it's up to Alexinparis now, he has to say, why he block every work and ideas in this direction.

Where did you read I "block" any ideas?

cGiesen · Post by **cGiesen** » Sun Oct 21, 2012 7:42 pm

Alexinparis wrote:
cGiesen wrote:
cGiesen wrote:You want to have the new idea from tommie, but you are not OK with this ideas.

Where did you read I "want" this new idea ?

Alexinparis wrote: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.

Some posts earlier in this thread...
You say (with my words (sorry for my english): "When we change the GUI, than you want to see the extra Box from Tommie"
But you don' t want this...

For me, that means: You do not want to change the GUI

Alexinparis wrote:
cGiesen wrote:But it's up to Alexinparis now, he has to say, why he block every work and ideas in this direction.

Where did you read I "block" any ideas?

In every post from you, were you say NO to the idea to have more than 8 channels.

debay777 · Post by **debay777** » Thu Sep 18, 2014 12:36 pm

I think I am in the same predicament here.
Radio:Turnigy 9XR/opentx/orange module
Rx: Orange 6 channel and soon Lemon 8
Flight Control Board: whitespy pro3 w/EZ plugs

I have but 1 3 way switch. I have learned how to assign a 2 way switch to create 6 positions with a single 3 way switch. The problem I run into is that they all transmit on aux (chnl5) . Each aux channel only supports 3 switch positions clow/med/high. Is there a way to trick multiwii into seeing more switch positions? Or is there a way to trick the radio into sending 3 of the switch throws to aux (chnl6)?

-ralf- · Post by **-ralf-** » Thu Sep 18, 2014 5:43 pm

Use MultiWii - Navi - Beta and enable EXTENDED_AUX .....

EOSBandi · Post by **EOSBandi** » Thu Sep 18, 2014 8:11 pm

-ralf- wrote:Use MultiWii - Navi - Beta and enable EXTENDED_AUX .....

Or use R1700 or up... navi beta is now integrated into _shared..

-ralf- · Post by **-ralf-** » Sat Sep 20, 2014 7:21 am

EOSBandi wrote:
-ralf- wrote:Use MultiWii - Navi - Beta and enable EXTENDED_AUX .....

Or use R1700 or up... navi beta is now integrated into _shared..

But for now MultiWiiConf doesn't support it .....
we still need WinGUI-Navi-Beta or EZ-GUI, right?

EOSBandi · Post by **EOSBandi** » Sun Sep 21, 2014 6:23 pm

-ralf- wrote:
EOSBandi wrote:
-ralf- wrote:Use MultiWii - Navi - Beta and enable EXTENDED_AUX .....

Or use R1700 or up... navi beta is now integrated into _shared..

But for now MultiWiiConf doesn't support it .....
we still need WinGUI-Navi-Beta or EZ-GUI, right?

Indeed.