Is there a straightforward way to map a joystick axis so that instead of - 1.0 to 1.0, it outputs 0 to 1?
I could kludge something together, but am hoping there’s something out there already.
Do you mean -1.0 is 0 and 1.0 is 1.0?
Yes. Fixed the typo in the above.
joyVal = math.abs(Joystick.getRawAxisValue(1))/2;
Disclaimer: I don’t program robots and I just woke up. But I think this will work
Edit: maybe Definitely not
Definitely not!
1 Like
I hit post and then saw the problem
1 Like
Yahhh didn’t think so… Doesn’t that just divide it by 1?
1 Like
(x+1)/2
4 Likes
Man! I just got it!!! Early bird gets the worm.
Well, -0.5 would become 0.25. Maybe if we add 1 to the value, then divide by 2.
-1 + 1 = 0 / 2 = 0: yes
-0.5 + 1 = 0.5 / 2 = 0.25: yes
0 + 1 = 1 / 2 = 0.5: yes
0.5 + 1 = 1.5 / 2 = 0.75: yes
1 + 1 = 2 /2 = 1: yes
That math should work
Edit: I got beat to the punch
2 Likes
Yes, of course! Thank you.
I was thinking about it as a programming problem rather than a (rather trivial) math problem.
1 Like
Same… lol
1 Like
I had the idea of creating a mathematical function that would take any rang of numbers (i.e. -1.0 to 1.0) and convert them to whatever you wanted (i.e. 0 to 1.0). I think it would be useful especially to younger programmers.
Have you looked at Arduino’s map() function? Change long to double to work with floating-point numbers, but the math is the same.
That’s one of the reasons why computer science has a lot of math.
2 Likes
Well, as a physicist, the question should have been trivially easy. I’m not much of a programmer and have had to do far too much programming this year, and so my brain went in the “is there a library something-or-another for this?” direction rather than “this is math and I know math so this is a really easy problem.”
Thanks for the solution!
Mission successful!
Despite the official Command being called “rpm_gain” in our shooter code, I am unable to train my students not to call it “more yeet”.
And I guess that’s okay.
If it helps, we do have this as a library if you want to use it:
There’s a static version as well as a class instance, which is sometimes handy for saving conversion factors from an encoder or whatnot.
Also a word of warning about converting joystick axes like this: an unplugged joystick gas a value of 0, meaning your function converts it to 0.5. This means a missing joystick runs your shooter, or climber, or what have you.
If you’re using a throttle or slider, an unknown position is similarly hazardous.
We’ve done this a lot in the past, and for safety always set a state variable to lock out that control: until the joystick axis exceeds 0.9 or so(wherever your safe slider/throttle position is), the joystick input is ignored and the controlled system won’t run.
Looking at it briefly, I don’t think the lerp function and map function are mathematically equivalent. The map function looks like it gives the right value in this case but I’m not sure the lerp function does.
Heh. It works fine: We use it all over our code. Looks like one of the students expanded the math (x - in_min)/(in_max - in_min) -> x/(in_max - in_min) -(in_min)/(in_max - in_min) and no one noticed it.
Pretty sure this happened when we were looking at extracting x/(in_max - in_min) in the instance version to convert a division to a multiplication and slightly optimize the instance based version. This never wound up getting committed, so it looks like someone put it back in a hurry and we just never noticed because it’s the same math.
1 Like