GUI

Some thoughts about GUI usability. I hope I don't offend anyone when I say that the current GUI looks to me like it's hammered together for two causes: To prototype actual GUI elements and to test the underlying Tx functionality. It's hopefully not what the "end user" has to put up with in a later version.

So here's my take on use cases and scenarios for deviation. Note that "scenarios" describe actual situations you might be in and don't say a lot about how a specific UI element should be implemented in detail. However, the final implementation should make it possible to use the UI as described in the scenario, it's some kind of implicit specification.

I mainly see three main use cases:

(1) You've got your fleet in your car, are driving to the rc airfield and just want to fly.

(2) You've got a new model and need to do a complete set up from scratch.

(3) You've just maidened your model at the field and now it's about tweaking all the settings.


Scenario 1: A day at the field. You have a helicopter, a thermal glider with telemetry and a trainer you're using with a buddy box cable to a friends RX to teach him fly.

You start out with some helicopter 3D flying. Using the dual rate and flight mode switches feels familiar to your old Tx. While you're flying, you never look at the display, but an audible signal tells you when the timer ran out and you've got to land. You're pondering about telemetry in your heli monitoring the lipo voltage instead of using the timer, so you can get a couple of minutes more flight time. Since you don't trust all these new thingamagics, it would be nice to have both the timer and the telemetry alarm, distinguishable by different melodies or tones. Logging the flight times/battery voltages in combination with the model setup for the last bunch of flights would be a cool feature to tweak the model settings.

After your blood pressure went over 180 from all the 3D flying, you decide to take a break and watch a buzzard in the sky. Time to get out the glider!

You're pushing the "model select" hot key or a large icon on the display to get a list of models stored on your tx. The GUI elements of this list are large enough to push with fingers, so you don't have to fiddle out the stylus and possibly lose it in the grass. Alternatively, the GUI can be controlled by the Tx buttons. A beep and the display indicate that the Tx tries to bind to another receiver now.

After binding, the main display shows the telemetry data from your glider: battery voltage and altitude. You decide to activate the telemetry logger in the Tx by either using the hot key or that large, finger pressable GUI button, because the weather might give you a new record in thermal gliding.

After the bird is in the air, you rarely take a glimpse on your display to read telemetry data. Then you remember that new "audible variometer" mode and flip a switch on your Tx. Now your Tx does short high pitched beeps when your glider climbs, and long low pitched beeps when it's losing altitude. Ah, that's much better than holding up your Tx so high that you can see both the display and your plane at once (side note: I actually saw a guy at our field doing that, that was kinda hilarious).

An hour later, the telemetry battery alarm finally suggests to land. Meanwhile, your new flying buddy arrived at the field, presenting you his new ACME Transmitter.

You select the model configuration for your trainer plane in your transmitter. You somehow make your buddy's ACME Tx make output PPM through a 3.5" plug and connect his Tx and your Tx with a mono-cable. You enable "Trainer" mode on your Tx by pushing a large GUI button. With other Txes, you had to worry about overall compatibility, channel ordering, servo extends and trim setup, but the new "Trainer mode quick calibration" makes this all very easy: Your buddy moves the throttle stick to min, you press a button. Your buddy moves the throttle stick to max, you press a button. Same for the other three stick axes. In the last step, you're selecting which of the four main THR, RUD, AIL, ELE inputs can be switched over to the buddy Tx. You decide to check the boxes for aileron, elevator and rudder.

You're starting the trainer, bring it to a safe height and flip a switch. Controls are not immediately transfered to your buddy, but a short tone sequence tells him to get ready (BEEP-BEEP-BEEP-BEEEEEP, think Mario Kart).

After control is switched over, the trainer calibration makes sure that your buddy using RUD, AIL, ELE behaves exactly as if the same stick on your Tx is moved, i.e. it doesn't replace the mixer outputs of your Tx with the output of your buddy's Tx, but instead replaces the stick input of your Tx with the calibrated value of your buddy's stick.

Now your buddy lost it and you have to recover the plane. You flip the trainer switch back and a short beep informs both of you that control is back in your hands.

After a while, you decide that he's ready to get full control, so you bring the plane down, and change the battery for a fresh one. You turn your Tx back on and activate Trainer mode. Since the ACME Tx still has the same settings as before, you push the "Use last saved calibration" button on the Trainer quick calibration screen, also check the throttle check box on on the override screen and are ready to go.

---End of Wall-of-Text---

Wow, this has become longer than I initially expected.

I put up number (2) up there with a model setup wizard in mind. I hope this doesn't get as long as (1).

Scenario 2: You also have a 450 class heli and a FunJet that both have a Walkera RX2801 that you've previously flown with your WK2801Pro Tx. You also got a 250 class Heli and a MiniSwift with Spectrum receivers that you've previously flown with your DX6i. Since deviation seems to be stable enough, you decide to move them over.

Since you're at home in your workshop, you have no issues with sun glare and happily use the stylus to set up the model. You start by going to the model select screen. There's a smaller button "New Model Wizard" asking to be tapped.

You decide to set up the MiniSwift first, since it's a simple 4 channel glider.

The first thing you're asked is what kind of receiver you've put in. A list of supported RX protocol is shown and you press the button "DSM2".

The next screen informs you, that this kind of receiver requires to be bound to the Tx. It asks you to put a bind plug on the BATT connector, turn the RX on, wait until the LED stops blinking, turn it off, remove the plug and push the OK button.

The next screen asks you if you want to configure a plane or a helicopter. This looks like a plane. As soon as you push the "plane" button, you get a list of choices regarding the servo configuration: "Elevator + Rudder", "Elevator + Aileron + Rudder", "Elevator + 2x Aileron + Rudder", "Aileron + V-Tail", "2x Aileron + V-Tail", "Delta".

(lunch break.... going on later...)

You select "Elevator + Aileron + Rudder", because it fits the MiniSwift, and the first page of the individual servo configuration for the elevator comes up. You select the output for the elevator channel on the rx from a list box listing all unassigned channels. There's a test button that moves the servo to the up, down and center positions when pushed repeatedly. There's also a check box for reversing the servo and two sliders for setting the servo end points.

After pressing the OK button, you're getting to the aileron and rudder pages that work the same (but instead of up and down, the indicator beside the test button shows "left" and "right").

When the servo setup is finished, you have to enter a name for your model and it's saved to the filesystem as "modelname.ini".

...

MatCat wrote: I don't recommend using black for full transparency marker though because it is too valuable a color to be used.

Sorry to drag up an old post, but I'm reading through this thread to catch up with you guys and this rang alarm bells for me. Perhaps it has already been addressed; if so, ignore me, I'll get to the rest of the thread soon.

The redraw is painfully slow in Walkera's firmware, and one of the things I hope to help achieve with Deviation is a less laggy GUI. I suspect this is an unrealistic goal given the limitations of the serial link to the screen, but I'm willing to sink some time into it.

There is a good reason Walkera chose 0 as the transparent colour: on ARM you can optionally set the CPU status flags as if comparing against 0 after performing any ALU operation (or a load from memory) without incurring any extra cycles. This ties in well with every ARM instruction having a conditional predicate, allowing a good compiler/programmer to eliminate all branching within the inner loops of plot routines and other simple code. (We are generating ARM opcodes, right? Not Thumb?)

In short, we want the transparent colour to be 0 for the performance boost and denser code it will provide. Using the darkest shade of blue (the colour to which our retina is least sensitive) has been used for decades on other ARM platforms as an approximation of black. Most people never notice.