|Sep 06, 2013, 12:19 PM|
TX User Interface Design
I would like to start a thread on TX (transmitter) UI (User Interface) design. I have some ideas I would like to share and hopefully generate some discussion. I am not selling anything and this is not some sort of a stealth marketing probe. I am not interested in bashing brand X or claiming that brand Y is much better. Personally I think every TX I have ever owned has a bad UI in one way or another. Most wonít do something that I want to do, and they are all more complicated and difficult to learn to use than they need to be (IMHO).
I realize that some people will wonder what the problem is. If they have used a particular TX for some time they will have figured out how to do all the things that they regularly need to do, so at that point the UI seems pretty good. There is also a tendency to not like any other brand, or even another model of TX from the same brand because the UI is different and it is frustrating to know how to do something in your old TX and struggle to do the same thing in your new one. So, my measure of goodness in this respect is not whether a TX is easy to use once you know it inside and out, but whether it is easy to learn.
I also realize that the more capable and flexible a TX, the more difficult it is to learn to make use of all that capability. This complexity often makes it more difficult to do even the simple things, like setting up a simple 4 channel aircraft without any fancy mixes or curves, just EXPO and dual rates. My issue is that a good UI should make the simple things easy to learn and do, and should not overcomplicate the more sophisticated features to the point where many users simply wonít bother to use them.
For myself, I fly everything from simple aircraft to complex VTOL aircraft where a servo that controls roll in one configuration might control yaw in another. I need features that are only offered on the most expensive TXís, but then I despair at how difficult they make it to learn and use those features.
This is not a hardware discussion. I have no intention to spend the next 2 years implementing these ideas in an Arduino platform, or any other. For now, it is just a discussion of UI design philosophy. I suppose there is no point to such a discussion beyond enjoying the discussion itself. At best, we might hope that some of these ideas will find their way to an actual TX supplier someday.
My personal experience includes various models of Futaba, Spectrum, and Multiplex transmitters. If some of the language I use is unfamiliar, then it probably relates to the Multiplex way of thinking, which is quite different from the various AR (Asian Radio) way of thinking.
I will start the discussion with things I want and donít want, and then invite others to add to the lists.
1. A radio that can do most anything I can conceive of.
2. So many models that it hardly matters to specify the maximum number.
3. Unlimited mixers with unlimited inputs.
4. The TX to power up and wiggle servoís right out of the box.
5. To tell each servo what to do separately. The TX doesnít need to know what snap flaps or crow means.
6. To be able to program the TX so I can plug any servo into any RX channel.
7. The trainer cord input channels to be just another set of inputs. I can modify them, or not, servo by servo.
8. The program to be as simple or as complex as it needs to be, but no more so. In other words, I donít want to have to mess with or even look at hundreds of parameters that donít even relate to what I am trying to do.
9. To be able to down load and upload individual model programs as a simple ASCII string so I can cut and paste them, share them over the internet, or back them up on my PC.
10. The entire program to be right there in front of me so I donít have to remember which of a few dozen menus contain the parameter I need, or which of a few hundred parameters, does what I want to do.
11. To be able to show you exactly how I accomplished this or that nifty function, with a chunk of easily readable code. There should be no long confusing discussions about changing these 7 parameters on those 5 menus, all the while assuming that 12 other parameters are already set appropriately.
12. Full basic math capability. Mixers essentially add or subtract, but I want to be able to multiply as well.
13. Full basic logic capability. (AND, OR)
14. A true GUI programming interface with point and click, drag and drop, cut and paste, pull down menus, searchable help, help bubbles, and all the features I have come to expect from a typical PC based application. In short I want to be able to plug my TX into my PC or smart phone and program it there.
15. I also want to be able to program it from the small LCD screen on the TX, but I will accept that the interface might not be as full featured or as easy to use.
I donít want:
1. To have to reverse engineer the TX designers intentions to figure out how he intended I should do the thing I want to do. I just want to do it the way I want to do it, however clever or foolish that may be.
2. Any convoluted work arounds to get the TX to do what I want.
3. Funky little Icons that I have to look up in the manual to figure out what they mean. Give me plain English, or contractions, or if you must, acronyms. Any symbols should be standard ones like ď+Ē (plus) etc.
4. Dozens of menus under menus under menus under menusÖ.
5. Anything global. I donít want to have to worry about breaking models 1 through 5 while programming model 6, and I donít want to have to memorize which parameters are global.
6. Helicopter mode, airplane mode, glider mode, wing types, tail types, swash plate types, or any other types or modes, just inputs like sticks and switches and output channels.
7. Mode 1, 2, 3, or 4. I will tell the TX which sticks or other inputs move what servo and thatís all it needs to know.
8. Templates that restrict what I can do. Example programs are fine, but I donít want my programming choices to be limited by the example I started with.
9. Assignment lists, global or otherwise. Data will flow from widgets to a single servo, and get processed along the way but there should be no choosing from limited choices that have to be adapted to do what I want.
10. To have to memorize hardly anything. It should all be pretty much obvious just by looking at it.
11. To go round and round in circles reversing the flap direction and then have the ailerons be backwards, etc.
12. To look up a model I programmed 3 years ago and be confused by something I once understood perfectly.
Ran D. St. Clair
|Sep 06, 2013, 01:00 PM|
United States, UT, Herriman
Joined Jan 2012
Sounds like OpenTX/ER9X etc.... With the PC application to go with it. Don't think they are stored in ASCII, but it might be XML. Either way, you can download the model programs and share them on the internet, back them up, mix and match from other model files, etc..
Note that those are the software inside the radio, not the TX itself. So far, the best hardware that can run them seems to be the Taranis, if you can get one.
|Sep 06, 2013, 08:28 PM|
Thank you for pointing me to the FeSKY Taranis and the Companion Program that runs on a PC.
I barely know anything about this TX and programming system, but after watching just a couple of videos I can see that I have lost the war. They went in a very different direction than what I wanted, but by using all the brute force power and GUI capability of a PC it looks like they have made the user experience pretty nice.
It's not elegant, or simple, but it probably works for most people, especially if they come from a background of one of the Asian Radios (Futaba, JR, Spectrum, etc.) .
I still think my way is better, but I also think this radio and UI are the future, not my ideas, and certainly not the Multiplex (Profi, Evo) style, which is an overcomplicated mix of my ideas and the Asian Radio style.
As much as it pains me to admit, it's time to move on to something more productive.
|Sep 06, 2013, 09:30 PM|
Spektrum (not Spectrum) is designed in the USA, not Asia. And yes, your use of the term AR shows a Multiplex background very obviously. Be careful, here, for "AR" is an invalid term and one which is typically associated with a superiority complex of certain individuals. It has little to do with reality. Having used multiple brands of radios myself (Kraft, World, Heath, EK, Futaba, Hitec, and Spektrum, as well as having developed UI's for another radio company), I can categorically tell you that there is no "Asian" style. Even the radios you lump together Asian are in fact quite different conceptually.
One of the things we at Spektrum hear again and again is that our radios using the AirWare firmware (which I wrote, and still write) are the most intuitive to program. Our radios also have a huge amount of flexibility in them, but not in a way that makes programming complicated. You'd be surprised how many people have never even cracked open the manual and are doing some amazing programming. I find some of the things they are able do to be beyond anything I could have imagined.
Part of the reason they are easy to grasp is a consistent, simple interaction with the radio - a basic tenet of good UI design. Another factor is the level of understanding the radio has encoded in it about many standard (and not so standard) airplane configurations. Also the layering of rarely-used functions deeper down, with most-used functions in the forefront.
While your desire to not have any two control surfaces implicitly related to one another is a nice idea for absolute flexibility, it quickly undermines any attempt at simplicity. For example, define differential, and note how many mixes it takes to accomplish that. Which is simpler: defining multiple mixes that depend on multiple inputs, or selecting a value from -100% to +100%? Then remember that you need to create different combinations to support aileron, elevon, flap, and V-tail differentials.
As for complex aircraft such as VTOLs, the most successful creators of this type of model do not use the transmitter to do all their programming. The transmitter programming and type can be greatly simplified, as well as in the a/c, by use of customized programming on an in-vehicle system. This is not because the transmitters are incapable, it is because certain control mechanisms properly reside in the a/c and the input abstractions are managed separately. This is both good UI design, good system design, and good controls engineering.
Your desire for simple text configuration is found in our SPM file interface. Many users have looked inside them and found and enabled features that they didn't know their radios had.
I'm sure by now you've read Shellim's reference. It obviates the OS orientation of the underlying system (widgets). You know what? AirWare does the same thing - they're called "devices" (yes, I'm very un-original)
I'm sorry to see you so quickly abandoned this thread. I do hope you return to read it.
|Sep 07, 2013, 11:31 AM|
United States, UT, Herriman
Joined Jan 2012
I don't know that you can say you lost anything. Perhaps if you show some screen mockups for what you have in mind? Maybe you have the better ideas. For opentx, there's no reason one couldn't put a different ui over the top of the underlying mixing etc.. and maybe Andy will add them to a Spectrum radio.
|Sep 07, 2013, 08:16 PM|
Joined Jun 2007
I would really, really like to see a P/C program that can interpret the TX programming data from the downloadable TX files, show the relationship of the various inputs (controls) and the output channel(s). Where mixes or other combinational relationships exist, they should also be shown. When all is said and done, I'd like to be able to highlight a symbol representing the input, function, or mix, and "drag" it, followed by removing or adding a connection to the next step in the chain.
Available inputs, functions, etc. should be shown on a page separate from the active in use page, and be transferable to the active page.
(And So On!)
|Sep 09, 2013, 12:01 AM|
There is currently a website where you can upload your programming files and share it with others or download programming files from other people. I don't remember the link but it's in the Taranis thread in the Radio forum somewhere.
Ideally, Vendors like HobbyKing or Aloft Hobbies who themselves sell radios based on the OpenTX family of firmwares should provide these programming files for us. Then programming a model is just downloading the programming file linked to the page you bought it from.
Currently the ER9X based 9XR from HobbyKing and the OpenTX based Taranis from FrSky have some incompatibilities when it comes to the more advanced features of the TX but they both handle the basic mixing in the same way and Companion9X is able to do limited format conversion. Hopefully the two main projects will converge around common features in the future so we can create "Universal" programming files that can work on all OpenTX style radios.
|Sep 09, 2013, 12:36 AM|
OpenTX was derived from the ER9X firmware which was itself derived from the TH9X firmware originally written by a German programmer. So I guess we can call it the German style of programming since the Multiplex style also came out of Germany.
If you are familiar with Multiplex style radios then you'll be quite comfortable with the OpenTX firmware except that for the most part the OpenTX is slightly less complicated IMHO.
|Sep 09, 2013, 08:25 AM|
One former MACINTOSH designer had some input on this some time ago...
Dear Ran D. St. Clair:
The PIPE Here - I'm one of those "knobby fliers", who HAS to use a three-axis "single-stick" transmitter for ALL of my flying needs, and since I've always built all my own RC radios since 1977, I'm quite certain that I've got some sort of valuable input to add in a thread like this one.
My most recent knobby RC radio project, completed in 2003 and used at least a few times before I had to leave the RC hobby for the second time later that year (and still out since I've been out of work for quite a while)...
...is something that has used a user interface I devised for my own needs about a third of a century ago, and still find comfortable today for practicing my flight skills (to keep them fresh) in Ikarus' AFPD flightsim on my computer.
This radio of mine in the photos above, which will be joined by a twin to it that I'll whip together sometime after I get back to work, uses Gordon Anderson's great MicroStar 2000 encoder, in its originally-released Mk.III version (the previous "marks" were for development only) - its current Mk.V version has a smaller footprint than the pair of "MS2K" Mk.III units I've got here at home, and has twelve times the onboard memory, enough for 96 memory positions, versus the eight in the Mk.III.
I DO know that in your initial post you stated that:
You MIGHT want to check out the "Tx user interface" ideas of a now-departed Apple Computer pioneer, a person who helped to design the Apple Macintosh in the early 1980s and flew RC for their own hobby enjoyment. The late Jef Raskin's archived pages on this very subject — which, by the way, does promote the knobby radio as being a possibly preferable main control interface — are a good resource to check out on the general subject of Tx user interface design.
I've also placed my own ideas about general Tx design and construction — and the choices I've consciously made in arriving what I've got on that MS2K-encodered knobby radio — on Gordon's site as well.
In closing, I did want to add that after thoroughly checking all the likely Arduino "controller-on-a-board" solutions one could currently use for basing a Tx on, it seems that all the choices are still solely 8-bit (256 steps per channel) ones — although I'd love to be proven wrong on that! Gordon's MS2K boards were already at 10-bit resolution a decade ago, and the current Mk.V unit can be built for a 12-bit resolution if one wanted to.
Please give Gordon's pages a good checkout, as well as the late Jef Raskin's...there's a LOT of good stuff to read about and digest a bit in one's mind, on the ideas of Tx user interfaces at both sites.
|Sep 09, 2013, 09:55 AM|
My own encoder has about 11.5 bits resolution (the 0.5 is because I'm not using the full range).
So it appears that you haven't quite "thoroughly checked" all the solutions currently available, Arduino based or otherwise.
Heck, HobbyKing sells spare 9XR encoders capable of 11 bit resolution for $7. You can certainly use that as a base for a homebrew TX.
|Sep 09, 2013, 10:22 AM|
First off, much respect for someone who has done actual work in this area. Also I meant no disrespect by mispelling Spektrum and do currently own two Spektrum radios. I used the term AR (Asian Radio) as a reference to a style of programming, and certainly meant no disrespect. I didn't invent the term, as it was commonly used many years ago to describe the general difference between the Multiplex style and pretty much everything else. Just to be clear, I was speaking of the broad general concept of a radio that asks you what kind of aircraft you have and then speaks in high level concepts like crow or butterfly. The Multiplex style is more of a "blank slate", do whatever you want style, but even the Multiplex EVO and Profi have numerious examples of model type specific programming and functions.
My personal preference is for the "blank slate" style but that doesn't mean I love the EVO or the Pofi. They both have various features that I hate.
For simple models, and models of a standard configuration that is supported by the specific radio, the "model specific" style works fine. I think it has long since proven to be the most popular style, and probably always will be, mainly because most models are relatively simple and the supported model types has grown to cover the vast majority of what is out there. The Spektrum radios that I own are indeed easy to program within those limits. They annoy me when I have to start moving servo's around on the RX to handle simple elevons, but that is a pretty minor complaint.
I have spent the last few days studying the open TX UI and like everything else, I love it and I hate it. I love that it is more "blank slate" than any radio I have yet seen, and I love that it is fundamentally more powerful/capable than any radio I have ever played with. I am not thrilled about the "long push / short push" method of menu navigation which expects the user to know what to do without any prompts on the screen. I am also not thrilled by the number of menu's required, though it is vastly superior to something like the Profi that must have over 100 of them. I also think that it is more complicated than it needs to be, meaning all the current functionality could be retained, but with a simpler interface. That, however, is a very hard thing to do, so most of all I am greatful to the people who did all the work to make it happen and I have no right to complain.
I recognize that my ideal UI would probably be a marketing failure, because my perspective is too unique. The "model specific" style is probably the best answer in that respect.
I must say, I am gratified by the number of responses to this thread, even though I pretty much abandoned it right after starting it. This must be a hot button issue for at least a few people.
I think I am seeing various somewhat unrelated topics emerge in this thread.
1. The UI as it relates to TX Programming
2. The UI as it relates to a PC interface to ease TX Programming
3. The UI as it relates to a PC interface to simulate the TX
4. The UI as it relates to the ability to upload and download TX Firmware
5. The UI as it relates to the ability to updoad and download specific model programs.
6. The UI as it relates to the physical interface between user and TX
Thanks to everyone for your comments.
|Sep 09, 2013, 10:45 AM|
If we really want to take all this to the next level then we want a graphical UI, with drag and drop modules that allow you to custom configure the data paths in more of a block diagram view. Yes, that requires a big screen, and is potentially way too complex for a beginner, but it's fun to think about.
|Sep 09, 2013, 01:05 PM|
In some ways that's the Multiplex approach. The feature based/model specific programming you mentioned that the Multiplex has along side the underlying mixer is actually just a UI layer on top of the mixer. I mentioned earlier that the OpenTX firmware (Taranis & Turnigy 9X) is simpler than the multiplex. The reason I feel it's simpler is that it doesn't implement the additional feature based programming layer that Multiplex has. As such it is a more pure mixer based system which in my opinion is easier to learn and understand.
My own TX software is a function based design which is sort of a hybrid between the Multiplex style and the traditional feature based programming. Whereas the Multiplex and OpenTX style has the structure of a table:
ch1: 100% aileron, 60% elevator ch2: 100% aileron, -60% elevator
[ch1, ch2] = mix( scale(aileron,100), scale(elevator,60) )
_______ _________ ch1 <---| a|----[scale 100]-----< aileron | mix | ________ ch2 <---|______b|----[scale 60]------< elevator
I found it significantly more elegant than my approach due to its utter simplicity. In term of interface "style" I think it's hard to improve upon without adding significantly more complexity. But I do think it can be improved. The thing still requires too much button pressing for my tastes. A touch screen would allow simple point and click editing of the mixer. A channel or variable list or pallet would allow drag and drop editing of input variables. Simple syntax highlighting will make the mixer much more readable and less prone to syntax errors etc. But I think the mixer itself should remain a table based system. Only that it should behave more like Excel rather than Notepad.
I still think it's possible to implement the widget based drag and drop editor like my original idea on top of a Multiplex/OpenTX style mixer. But I'm not convinced that it's better than just giving the user the mixer table.
|Category||Thread||Thread Starter||Forum||Replies||Last Post|
|Discussion||PC output to RC tx interface?||chopperdudes||DIY Electronics||9||Jun 16, 2013 04:09 PM|
|Help!||Programming DX6i: non-user interface||RotorHead460||Off-road Cars||3||Apr 28, 2013 03:42 AM|