Standardize the "extensions" channels?

More
25 Jun 2015 14:29 #34652 by mwm
I've been updating the docs for protocols, and have noticed I find annoying:

we have a 7 models with "extensions", that are basically hacks to add (mostly) on/off channels in unused bits of a 4-channel radio system. As such, we can assign these functions to pretty much any channel we want. But they're a hodge-podge. Here's the table of what I have:
            9x9     6x6      v912    Hubsan4 V202    YD717   SymaX cx10 dm007 cg023
lights       5       5               5       5       6                         5
video        6       8               7       8       8       8       8     8   8
still        7       7                       7       7       7             7   7
flip         8       6               6       6       5       6       6     6   6

headless             9                       9       9?                    9   9
RTH                  10
calib                11+                     10+
rate                                                                 5     6   10

About the only thing they all agree on is that still cameras should be on 7, and headless mode should be on 9.

I propose we standardize these things. If we go with:
5 -> lights (either on/off, or rate)
6 -> flip
7 -> still camera
8 -> video 
9 -> headless
RTH -> 10

WIth the understanding that if a quad has a function, it should be on that channel. If it doesn't have one, it can do whatever it wants with it.

Then we will only break two protocols: Flysky V9x9 will need to swap flip & video, and YD717 will need to swap flip & lights.

Hubsan4 will need to move video to 8. We might be able to set it up so that both 7 and 8 can start/stop video, depending on how it works. I can investigate that.

Note that since these aren't real channels, but are handled internally by flipping bits in other channels, the only cost for having unused channels is needing to scroll past them in the mixer. But there won't be many of those.

I'm not sure if the "rate" control on the cx10's and the cg023 is really a rate, or is some form of envelope control. If someone knows, we ought to document that.

In any case, trying to set up standards for both rate and two calibration channels would push us out to 13 channels. So maybe we should break all of those, and just have "calibration", which triggers all of them (do you really ever want to calibrate a single axis?), and put rate on the other one.

Do not ask me questions via PM. Ask in the forums, where I'll answer if I can.

My remotely piloted vehicle ("drone") is a yacht.

Please Log in or Create an account to join the conversation.

More
25 Jun 2015 17:12 #34655 by PhracturedBlue
Replied by PhracturedBlue on topic Standardize the "extensions" channels?
This has come up a couple times. I'm not big on changing protocols that were available in previous official Deviation releases. Any protocols that were not part of 4.0.1 are fair game. Victzh, goebish, hexfet, and others have already done some work to align some of these. While it is useful to have a standard, it is probably better to break the standard for legacy cases than to break existing model files to match the standard. In the end, most users are unlikely to try to take a given model file and make it work with a different protocol without going thorugh and fixing the channel alignment stuff.
I also don't recall when different options were added, so I'm not sure how much of this is pre 4.0.1 vs after.

Please Log in or Create an account to join the conversation.

More
26 Jun 2015 09:29 #34670 by mwm
Replied by mwm on topic Standardize the "extensions" channels?
9x9 is the oldest of the bunch. What's I find interesting is that it's not even compatible with itself. So even though you can fly a V626 (I think that's it) with a V959 model.ini, the extended functions won't work right. Of course, since the V9x9 extensions are in the throttle channel, and the newer models treats those as actual values, trying to fly a new model with a V9x9 protocol is dangerous.

All the ones that need to be changed exist in v4.0.1. Possibly we should change the documentation to name the new flavors, and then document the legacy versions as different, to encourage authors of future extensions to do it the more common way?

Do not ask me questions via PM. Ask in the forums, where I'll answer if I can.

My remotely piloted vehicle ("drone") is a yacht.

Please Log in or Create an account to join the conversation.

More
29 Jun 2015 12:03 - 29 Jun 2015 12:24 #34830 by goebish
Replied by goebish on topic Standardize the "extensions" channels?

mwm wrote: Hubsan4 will need to move video to 8. We might be able to set it up so that both 7 and 8 can start/stop video, depending on how it works. I can investigate that.

Yes, this can be done, I think the "video" channel is mostly unused anyway, I think it's only for the H102D heli.

I'm not sure if the "rate" control on the cx10's and the cg023 is really a rate, or is some form of envelope control. If someone knows, we ought to document that.

Sorry for my bad English :blush: rate translates to the "20% 60% 100%" selection of the stock TX. For the CX10-A format option, 3rd rate is headless actually, that's also how it works on stock TX.

In any case, trying to set up standards for both rate and two calibration channels would push us out to 13 channels. So maybe we should break all of those, and just have "calibration", which triggers all of them (do you really ever want to calibrate a single axis?), and put rate on the other one.

That's not a good idea to have both calibration axis on one channel, because you've to do stuff on the machine after enabling this function, eg move the aircraft... So I'm not sure it will work well. I've no machine to test (V6x6 ...).

I'm not sure that's really possible to standardize channel/function for all machines, but at least that would be super cool to have a table as you did in post #34652 in the manual :)
Last edit: 29 Jun 2015 12:24 by goebish.

Please Log in or Create an account to join the conversation.

More
29 Jun 2015 12:55 - 29 Jun 2015 12:55 #34831 by PhracturedBlue
Replied by PhracturedBlue on topic Standardize the "extensions" channels?

goebish wrote:

I'm not sure if the "rate" control on the cx10's and the cg023 is really a rate, or is some form of envelope control. If someone knows, we ought to document that.

Sorry for my bad English :blush: rate translates to the "20% 60% 100%" selection of the stock TX. For the CX10-A format option, 3rd rate is headless actually, that's also how it works on stock TX.

I still don't understand. What is the 20%, 60%, 100% actually adjusting? gyro sensitivity, input sensitivity? If it is the latter, we probably shouldn't expose it at all. since setting up dual-rates/expo is trivial in Deviation.
Last edit: 29 Jun 2015 12:55 by PhracturedBlue.

Please Log in or Create an account to join the conversation.

More
29 Jun 2015 13:13 - 29 Jun 2015 16:16 #34833 by goebish
Replied by goebish on topic Standardize the "extensions" channels?
This is the later, but channels have a low resolution on cg023 (less than 7 bits) and I think you lose accuracy when using high rate+D/R versus low rate.
SebyDocky thinks like you (it shouldn't be exposed, just use the maximum value), but not everyone agrees, we should decide on a consensus :)
Last edit: 29 Jun 2015 16:16 by goebish.

Please Log in or Create an account to join the conversation.

More
29 Jun 2015 15:47 #34838 by PhracturedBlue
Replied by PhracturedBlue on topic Standardize the "extensions" channels?
If you want to be fancy, you could map the current value to set the bits automatically.
for instance if the stick is +-20% set the 20% rates and scale the value by 5, if the value is 20-60% set the 60% rate and multiply by 5/3, otherwise use 100% rates. You'd need to try it though to ensure you don't get any jerkiness in the transitions.

Please Log in or Create an account to join the conversation.

More
29 Jun 2015 16:04 #34840 by goebish
Replied by goebish on topic Standardize the "extensions" channels?
At first I implemented "rate" as a protocol option, but I've been told it's better to use a channel so it can be changed on the fly with the press of a switch. I personally don't mind.

Please Log in or Create an account to join the conversation.

More
29 Jun 2015 20:02 #34857 by mwm
Replied by mwm on topic Standardize the "extensions" channels?
I never really saw a clear answer as to what the rates actually do. I'm going to try and be very clear here, which probably means repeating a lot of things everyone knows. My apologies for that.

Yes, I understand that this is what happens when you set the RTF Tx to those rates. That it actually transmits bits to the Tx is, um, disturbing. Normally, setting those on an RTF Tx doesn't transmit any bits to the Tx, just changes the interpretation of the stick positions, and that behavior is what is usually meant by rates.

So in this case, a 20% rate would mean that, with the sticks at full throw, the aircraft changes orientation at 20% of the speed it would with a 100% rate. As noted, this doesn't really need to be sent to the aircraft, as deviation can do all this in the Tx. Using Tx rates and then PB's hack of setting the Rx rate to deal with the lack of bits in the protocol sounds like a good idea, as it means that someone who uses expo to less sensitive sticks near the center would actually get that in all rates.

The alternate case I'm wondering about is if the rates affect the maximum orientation of the aircraft. In this case, a 20% "rate" would mean that the aircraft stops changing roll and pitch orientation when it reaches 20% of the value it would go to with a 100% "rate". This is a useful feature, and requires that the rate information be sent to the aircraft.

Do not ask me questions via PM. Ask in the forums, where I'll answer if I can.

My remotely piloted vehicle ("drone") is a yacht.

Please Log in or Create an account to join the conversation.

More
01 Jul 2015 10:24 #34935 by Richard96816
Replied by Richard96816 on topic Standardize the "extensions" channels?
If channels are virtual why give them numbers at all? Why not give them functional names?

Instead of assigning video to channel x, assign it to 'video'. And a table can cross reference 'video' to some other level of abstraction. Or to actual hardware.

If you don't like how the assignments are laid out in your transmitter then change them. By reference. No one else needs to know or care. Everyone can move things around on their unit as they please. Without changing model files. If I want a certain switch to control video on every model I just set it up. one time. Then every model conforms to my wishes. And I know better what to expect from any model.

If model.ini files could eventually reflect this functionality they would become more readable too.

Please Log in or Create an account to join the conversation.

More
01 Jul 2015 15:30 #34946 by Richard96816
Replied by Richard96816 on topic Standardize the "extensions" channels?
Press a button and a picture of the transmitter appears on the display. With all switches and controls labeled according to function.

Please Log in or Create an account to join the conversation.

More
01 Jul 2015 16:51 #34949 by hexfet
Replied by hexfet on topic Standardize the "extensions" channels?

mwm wrote: The alternate case I'm wondering about is if the rates affect the maximum orientation of the aircraft. In this case, a 20% "rate" would mean that the aircraft stops changing roll and pitch orientation when it reaches 20% of the value it would go to with a 100% "rate". This is a useful feature, and requires that the rate information be sent to the aircraft.

This is what "rates" means for the majority of toy quads - the maximum angle of deflection from horizontal. Often called angle mode in hobby quad controllers, it also means the aircraft self-levels when the sticks are returned to zero. Stick position controls the angle of the aircraft..

In what's called "rate mode" the limit refers to the maximum rate of rotation allowed by the controller. Stick position controls the rate of rotation.

For example the Syma X1 operates in rate mode because it only has a gyro. I think a couple of the WLToys quads support both, but most toy quads with accelerometers ("6-axis").are always in angle mode.

Please Log in or Create an account to join the conversation.

More
01 Jul 2015 17:48 #34952 by mwm
Replied by mwm on topic Standardize the "extensions" channels?

hexfet wrote:

mwm wrote: The alternate case I'm wondering about is if the rates affect the maximum orientation of the aircraft. In this case, a 20% "rate" would mean that the aircraft stops changing roll and pitch orientation when it reaches 20% of the value it would go to with a 100% "rate". This is a useful feature, and requires that the rate information be sent to the aircraft.

This is what "rates" means for the majority of toy quads - the maximum angle of deflection from horizontal. Often called angle mode in hobby quad controllers, it also means the aircraft self-levels when the sticks are returned to zero. Stick position controls the angle of the aircraft..


Well, that's not my experience, but I haven't bought many of the toy quads since they started showing up with 6-axis gyros: just a couple of Estes Proto X's (one SLT, one normal). If so, it also means we aren't handling "rate" mode on the majority of the toy quads, as only a few of them (just the cx10, dm007 & cg023) implement it. At least, that I noticed when updating the manual.

This makes me wonder if we can turn off the rate mode in some of them, even if the RTF Tx's don't allow that. The lack of such a mode is one of the reasons I haven't bought many of them. It would make them a lot more interesting, even if still had auto-levelling.

Do not ask me questions via PM. Ask in the forums, where I'll answer if I can.

My remotely piloted vehicle ("drone") is a yacht.

Please Log in or Create an account to join the conversation.

More
01 Jul 2015 17:57 #34954 by mwm
Replied by mwm on topic Standardize the "extensions" channels?

Richard96816 wrote: If channels are virtual why give them numbers at all? Why not give them functional names?


Because we don't have any other method of communicating between the user interface and the mixer output but channels. Which have numbers. Yeah, it makes this kind of thing clumsy, but there's really no other way to handle things. I guess we could try looking for virtual channels with those names and use those if they existed, but that's not really a lot better.

FWIW, I've been contemplating a desktop config editor that would let you do this kind of thing. You'd give it a config file that listed your favorite mapping from functions to switches, and could then pick a protocol and set of functions, and it would write out a model config file. Or (the real goal), it could read in a config file for some arbitrary Tx, use heuristics to figure out the functions, then write out a model using your config - which means it would work on your Tx, even if it's a different one. Not a single line of code written yet, so don't expect it soon, if evern

Do not ask me questions via PM. Ask in the forums, where I'll answer if I can.

My remotely piloted vehicle ("drone") is a yacht.

Please Log in or Create an account to join the conversation.

More
02 Jul 2015 02:39 #34969 by hexfet
Replied by hexfet on topic Standardize the "extensions" channels?

mwm wrote: Well, that's not my experience, but I haven't bought many of the toy quads since they started showing up with 6-axis gyros: just a couple of Estes Proto X's (one SLT, one normal). If so, it also means we aren't handling "rate" mode on the majority of the toy quads, as only a few of them (just the cx10, dm007 & cg023) implement it. At least, that I noticed when updating the manual.

This makes me wonder if we can turn off the rate mode in some of them, even if the RTF Tx's don't allow that. The lack of such a mode is one of the reasons I haven't bought many of them. It would make them a lot more interesting, even if still had auto-levelling.

I wasn't clear. The "rate" controls on most 6-axis toy quads set the maximum angle - the quad always flies in angle mode. The CX10 doesn't have a "rate mode" (it's the only one of the three you named that I own). The nanoQX is an example of a RTF quad that supports both rate mode (SAFE agility mode) and angle mode (SAFE stability mode).

Please Log in or Create an account to join the conversation.

More
02 Jul 2015 03:38 #34971 by greenfly
Replied by greenfly on topic Standardize the "extensions" channels?

mwm wrote: FWIW, I've been contemplating a desktop config editor that would let you do this kind of thing. You'd give it a config file that listed your favorite mapping from functions to switches, and could then pick a protocol and set of functions, and it would write out a model config file.


That's an interesting idea. I can also think of many interesting opportunities that present themselves with a desktop config application...
  • Model managment
  • Graphical curve editor
  • Configuration comments... maybe?....
  • etc...

Please Log in or Create an account to join the conversation.

More
02 Jul 2015 04:41 #34973 by mwm
Replied by mwm on topic Standardize the "extensions" channels?
To see a desktop config system that's been in development for a few years, take a look at the OpenTx companion app. Emulator, configuration editor including graphical curve editing, model management, etc.

I think the most useful thing would be template system, to make it easy to set up oddball fixed wing things. Then again, that's also something I have no experience with, so maybe it isn't nearly as hard as I think.

Do not ask me questions via PM. Ask in the forums, where I'll answer if I can.

My remotely piloted vehicle ("drone") is a yacht.

Please Log in or Create an account to join the conversation.

Time to create page: 0.061 seconds
Powered by Kunena Forum