Joystick widget

Well I was going to use this to control a boat speed and rudder, but have noticed it moves in a circular path.

Which means when you turn left or right you lose the throttle value. :confused:

Surely the joystick should move a square path, so that you can have full throttle while turning…

1 Like

It’s intentional: SAFETY is the priority!
… Just kidding. But YES, it should be changed. But not really an error, maybe a design issue :slight_smile:

You can easily map incoming values so that certain vertical range won’t affect the throttle. Same for turns.

I don’t think that would be a solution, imagine trying to manouvre and having to return the tiller to centre just to adjust the throttle, and vice-versa.

No, in order to use the joystick effectively, you have to have independent and simultaneous control of both the X and Y axes, just like the Throttle/Rudder and Aileron/Elevator controls on an airplane RC transmitter.

You can use 2 sliders then. Be creative :slight_smile:

I did, works fine for controlling my AWESOME Blynk Powered Volkswagen T1 Transporter Hippie-de-Luxe van. :wink:

1 Like

I had thought of that Pavel, but there are going to be another 2 sliders on this project, and manipulating more than 2 at once on a small iPhone screen is just going to be cumbersome…

Maybe I’ll give it a go and see how it pans out, but I do like the idea of controlling the boat movement with one finger, or a thumb …

Well, rectangular can be put inside of a circle. Which means it’s a pure math to map the values from joystick to do what you need.

Another thing against using sliders is that you can’t have Auto-Return to centre like the round joystick can have. This boat controller will have forward/reverse, and left/right, so “hands-off” would be straight and stop, ideal for the application, where accurate boat positioning will be the goal.

I like the idea of the rectangle inside the circle, I’ll have a think about the math involved, although I feel it would limit the usable range of the joystick control, giving 0-100% over SQRT(2) of the travel.

I truly believe that making and hacking is all about taking the tools and things you have, and adapt it to your needs.

Blynk offers various tools, and it’s up to you and your imagination how to use it to achieve your goals. In this case - joystick fits your goals like 90%? Make the rest 10% by hacking it :wink:

And I truly believe that if I don’t have the correct tool in my toolbox, I go out and get one, rather than risk making something inferior, restrictive, or cumbersome to use.

If you are saying you are not going to consider making a square 2-axis joystick, where the two axes do not interfere with each other, then I will have to look elsewhere, and not use Blynk.

Sorry to hear that, but I’m just being transparent. We don’t plan to implemet square joystick in the nearest time for 2 reasons:

  1. You are the first one to request it in 3 years of Blynk. We would need a few more requests, obviously. Then it can get to the roadmap.
  2. Your use-case can be covered with existing widget + a few lines of code on hardware side.

Well, I’m not using joystick and not planning to. I wonder how popular is this widget? For sure @Gunner uses it for his project. :stuck_out_tongue: As “not a user” I try to keep away, but still have a “right to vote”. Well there is one important (?) reason to change it to “square mode”: Almost every widget in Blynk emulates real world control devices (yet I’m not aware of any Zergba remote control :wink: ), but not Joystick. That’s all!

2 votes counted then :wink:

1 Like

Well as apparently as the unofficial “other user of this widget” :stuck_out_tongue: (I do use it for two different projects, a mobile rover and a Pan & Tilt for my PiCam) I should cast my vote… however I have no strong feelings either way.

EDIT - OK, I re-read my post and I guess I do side on the “leave it as is” side after all :innocent: )

I can see both sides… Yes, it “just works” well enough as is :slight_smile:

But in order to use the corners with full X/Y values, it would need to be a “square”.

As is, one can extrapolate it out with math… but I belive it would also require a reduction in resolution to account for the truncated values in the current “corners”.

E.g. With a setting of -255 to 255 (leaving 0 as center) one can see how the round “corners” prevent reaching full 255 values for both axis… thus the device side math will have a reduced values to work with for extrapolation and more processing required for said math anyhow.


However… I feel that for most real IoT purposes, true corners and/or extrapolated resolution loss would be completely negligible, particularly for basic directional controls. I have found that anything requiring such motion precision probably shouldn’t be using a virtual interface anyhow as there is no tactile feedback required for such human interface precision.

I personally would prefer to see Blynk resources going to much more practical uses like a 4x20 LCD (OK, kidding… sorta :stuck_out_tongue_winking_eye: )… actually more like graphical customisation of buttons, sliders, gauges with user supplied imagery to complement the built in options. Including a true image viewing widget - pulling data from the device/server as needed. And so on. But that is for another topic :blush:

PS, I haven’t bothered to sit down and measure it… but suspect that aside from the very fancy optically driven ones… even physical joysticks based on potentiometers will run into a small degree of “round” corners… these are analog devices based on physical limitations of rotation… not square touch pads :wink:

Also, I suspect that most precision controls never expect to be driven to the stops in any axis.

Actually they do the full scale (except some s*tyy ones, where I owned one some time)

Where I agree, is a low priority of this modification. But it’s not the best design as it is currently

They can be close… but not physically possible to be stop to stop in a corner with dual pots and no mechanical “adjustments” that make the full x or y top/bottom out before full lever extension anyhow. Like a box inside of a circle… only now the loss is on the sides not the corners.

Comparing analog with digital will always have digital “averaging” to some small degree.

It is a dual lever design: One lever hinged to the other, which is hinged to base. That way one pot doesn’t influence the movements of the other. But… is it important at all??

Exactly the point :+1:… Aside from the intellectual debate of mechanical vs. virtual (which admittedly the engineer wannabe in me enjoys) arguments can be made either way, but for this topics OP, well… the widget just simply works for what it needs to do :slight_smile:

1 Like