game controller build thread (PS Vita analog stick, Cherry Red, Leonardo, LoL)

[Camineet]

I don't have an Arduino handy but think this should work for one button, it compiles ok...

Code: [Select]

boolean oState = HIGH;
boolean buttonState = HIGH;

void setup() {
  pinMode(2,INPUT_PULLUP);
  Joystick.begin();
}

void loop() {

  buttonState = digitalRead(2); //read physical button 2
   
  if(buttonState != oState) { //check against previous button state, if changed do something
    if(buttonState == LOW) { //button has been pressed
      Joystick.pressButton(0); //press "joystick" button 1
    }
    else { //button has been released
      Joystick.releaseButton(0); //release "joystick" button 1
    }
  oState = buttonState; //save state to compare next time
  }
}
From reading the example sketch I have no idea how they connected their many buttons...

yeah i don't know how to add more buttons either.  i tried jumping in and doubling some of the code for another button but couldn't get too far without becoming lost

[Camineet]

Thin wire, and lots of it?  You could get some on amazon (random example, may be available cheaper/in a more appropriate quantity) or if you have any Cat 5e Ethernet cables lying around at home/work/school they contain 8 strands of 24AWG.

i might try some cat 5e cable because it's meant for external rather than internal hookup applications.  anything labeled as hookup wire might have a limited lifespan in this application where movement is involved.  but cat 5e must use a rubber housing that's meant for a good deal of movement without cracking

[Camineet]

can't seem to find a decent project box.  you'd think there would be many.

this one looks cool, but too small to fit the shield

https://www.tindie.com/products/akafugu/project-box-for-arduino/

[suicidal_orange]

Glad to hear it worked!

My code is not complex enough to handle more switches than you have pins (you'll need to know where the switch connected to as well as which switch - this is called a switch matrix) but it would be good if you could work out how to add a second button as it's only going to get harder from here on in.  Perhaps a written explanation of the code will help?

The loop() function repeats indefinitely.  The first thing it does is check the current state of the switch and record it, then it compares this state with the previous one - did it change?  If it did then it checks what the new state is and informs the computer of it.  Then it saves the new state in oState ready for next time.  If on checking the state hasn't change (not pressed or released) nothing happens and it skips back to the top.

You could duplicate everything in loop() and make a pair of variables for each button, or better you could make a for loop around the existing code to go through all the pins and update that number-1 button.  I will say no more today, have a play

[Camineet]

maybe this...

http://www.ebay.com/itm/Acrylic-enclosure-for-Arduino-Uno-project-transparent-orange-Made-in-USA-2x-high-/231742155419?hash=item35f4e8aa9b:g:G9MAAOSwAYtWLQJD

[Camineet]

"I will say no more today, have a play "

lol, yeah trying now

[Camineet]

Code: [Select]

boolean oState = HIGH;
boolean buttonState2 = HIGH;
boolean buttonState3 = HIGH;

void setup() {
  pinMode(2,INPUT_PULLUP);
  pinMode(3,INPUT_PULLUP);
  Joystick.begin();
}

void loop() {

  buttonState2 = digitalRead(2); //read physical button 2
  buttonState3 = digitalRead(3); //read physical button 3
 
  if(buttonState2 != oState) { //check against previous button state, if changed do something
    if(buttonState2 == LOW) { //button has been pressed
      Joystick.pressButton(0); //press "joystick" button 1
    }
    else { //button has been released
      Joystick.releaseButton(0); //release "joystick" button 1
    }
  oState = buttonState2; //save state to compare next time
  }
 
  if(buttonState3 != oState) { //check against previous button state, if changed do something
    if(buttonState3 == LOW) { //button has been pressed
      Joystick.pressButton(1); //press "joystick" button 2
    }
    else { //button has been released
      Joystick.releaseButton(1); //release "joystick" button 2
    }
  oState = buttonState3; //save state to compare next time
  }
}

my lame attempt to build out the code for 2 buttons. it works a little bit. it compiles and uploads ok.  and i can press the buttons and get them to register on game controller settings in windows as below



problem is, as seen in the pic, the buttons won't release.  i've physically released the button 1, but the pic shows it's still being pressed down

anyway, good progress for today i'd say.  thanks for all the help

[Camineet]

hey i got it to work

Code: [Select]

boolean oState2 = HIGH;
boolean oState3 = HIGH;
boolean buttonState2 = HIGH;
boolean buttonState3 = HIGH;

void setup() {
  pinMode(2,INPUT_PULLUP);
  pinMode(3,INPUT_PULLUP);
  Joystick.begin();
}

void loop() {

  buttonState2 = digitalRead(2); //read physical button 2
  buttonState3 = digitalRead(3); //read physical button 3
 
  if(buttonState2 != oState2) { //check against previous button state, if changed do something
    if(buttonState2 == LOW) { //button has been pressed
      Joystick.pressButton(0); //press "joystick" button 1
    }
    else { //button has been released
      Joystick.releaseButton(0); //release "joystick" button 1
    }
  oState2 = buttonState2; //save state to compare next time
  }
 
  if(buttonState3 != oState3) { //check against previous button state, if changed do something
    if(buttonState3 == LOW) { //button has been pressed
      Joystick.pressButton(1); //press "joystick" button 2
    }
    else { //button has been released
      Joystick.releaseButton(1); //release "joystick" button 2
    }
  oState3 = buttonState3; //save state to compare next time
  }
}
heck, if weren't for the darned analog stick which is probably going to be the death of me, i could probably finish this project on my own from here

[suicidal_orange]

Haha, you were so close I nearly posted but thought you'd spot it   If you had enough pins to do one button on each, no analog stick, and didn't mind a bit of lag you'd be good but you still have all that fun stuff to overcome.

May as well do the analog next as that's independent of everything else...

[W11cE]

Nice, you have gotten this far

I will tell few things from my experience regarding joysticks.
Those buttons in the sketch are wired as "INPUT_PULLUP" , which means the value returned is 1 when not pressed and 0 when pressed. Don't know if you knew this already, but its a good thing to realize when you start to write more code yourself. In my experience it is much better to use "INPUT_PULLUP" (active low) instead of the regular "INPUT" (active high). At least on bare teensy boards driving a pin to 5v has caused some bad oscillations on the other pins on me on the past.

I haven't read through the code for that joystick yet, but if it sends the USB code every time you call "Joystick.pressButton()", you will start noticing some bad lag after 10-20 buttons. But this is something more advanced and fixable later, so i wouldn't worry about that now. Just something to keep in your mind for later, if you start noticing some input lag.

About the wire, 30AWG (often called also "kynar wire" for some reason) is enough for buttons. If you dont like handling it, because of the thickness. You can get thicker one, but there is no other reason.

[Camineet]

lol.  yeah this analog stuff is going to be something

the part from the Fin


think i could do that?  look at that thing!  money well spent

it came in a hand cut foam padding that i'm gonna use in the final application to house this precious piece

[Camineet]

good to know i will need to upgrade code to avoid lag.

i checked kynar wire and found that it's solid core.  i like the thin size, but won't this wire break after being moved around a lot?  it looks like it's only good for internal applications

[W11cE]

Premium packaging

i checked kynar wire and found that it's solid core.  i like the thin size, but won't this wire break after being moved around a lot?  it looks like it's only good for internal applications

Yes, you only bend it once (or twice, but no more than that). And mostly only for internal applications.

[suicidal_orange]

Nice, you have gotten this far

I will tell few things from my experience regarding joysticks.
...

Welcome to the party W11cE, sounds like you bring some much needed experience with this stuff

Just to clarify you meant to say it's better to use "INPUT_PULLDOWN" so the Teensy has less live pins causing less interference?  Makes sense...

By default the Joystick does update on button press but there's an option to do it manually.  As you say, one for later!

[Camineet]

i just tried running this sketch from W11cE tutorial here

http://xim4.com/community/index.php?topic=31390.0

Code: [Select]

#define STICK_X 0
#define STICK_Y 1

#define OVERVAL 256
int Xstick;
int Ystick;



void setup() {
  pinMode(0, INPUT_PULLUP);
  pinMode(1, INPUT_PULLUP);
}

void loop() {
 
  Xstick = map(analogRead(STICK_X), OVERVAL, 1024-OVERVAL, 0, 1024);
  Xstick = constrain(Xstick, 0 , 1023);
  Joystick.X(Xstick);
  Ystick = map(analogRead(STICK_Y), OVERVAL, 1024-OVERVAL, 1024, 0);
  Ystick = constrain(Ystick, 0 , 1023);
  Joystick.Y(Ystick);

  Joystick.button(1, !digitalRead(0));
  Joystick.button(2, !digitalRead(1));
 
}
and got this error message

Arduino: 1.6.5 (Windows 7), Board: "Arduino Leonardo"

vita_stick_1.ino: In function 'void loop()':
vita_stick_1:19: error: 'class Joystick_' has no member named 'X'
vita_stick_1:22: error: 'class Joystick_' has no member named 'Y'
vita_stick_1:24: error: 'class Joystick_' has no member named 'button'
vita_stick_1:25: error: 'class Joystick_' has no member named 'button'
'class Joystick_' has no member named 'X'

  This report would have more information with
  "Show verbose output during compilation"
  enabled in File > Preferences.

i'm guessing there should be something under this?

Code: [Select]

#define  STICK_X 0
#define STICK_Y 1

but i don't know what to use to define sticks.  are they booleans?

[sinusoid]

Hey, awesome project!

For inspiration, some old Steve Mann stuff:

note the beautiful manicure 

Protip: use wire for prototyping shape. 1mm soft steel wire, or copper. Tie it in bunches (duct tape, hot glue, twist it, whatever), shape the outlines of your prototype, fill in with sugru, or epoxy putty, or alu foil + sculpey + bake... whatever rocks your boat

That way you can work on the entire shape of the model at the same time.

[W11cE]

That code is for my modified teensy joystick usb type.
I modified this, so now it "should" work (haven't compiled this!):

Code: [Select]

#define STICK_X 0
#define STICK_Y 1

#define OVERVAL 0
int Xstick;
int Ystick;

boolean oState2 = HIGH;
boolean oState3 = HIGH;
boolean buttonState2 = HIGH;
boolean buttonState3 = HIGH;


void setup() {
  pinMode(2,INPUT_PULLUP);
  pinMode(3,INPUT_PULLUP);
  Joystick.begin();

}

void loop() {
 
  Xstick = map(analogRead(STICK_X), OVERVAL, 1024-OVERVAL, -127, 128);
  Xstick = constrain(Xstick, -127 , 128);
  Joystick.setXAxis(Xstick);
  Ystick = map(analogRead(STICK_Y), OVERVAL, 1024-OVERVAL, 128, -127);
  Ystick = constrain(Ystick, -127 , 128);
  Joystick.setYAxis(Ystick);
 
 
   buttonState2 = digitalRead(2); //read physical button 2
  buttonState3 = digitalRead(3); //read physical button 3
 
  if(buttonState2 != oState2) { //check against previous button state, if changed do something
    if(buttonState2 == LOW) { //button has been pressed
      Joystick.pressButton(0); //press "joystick" button 1
    }
    else { //button has been released
      Joystick.releaseButton(0); //release "joystick" button 1
    }
  oState2 = buttonState2; //save state to compare next time
  }
 
  if(buttonState3 != oState3) { //check against previous button state, if changed do something
    if(buttonState3 == LOW) { //button has been pressed
      Joystick.pressButton(1); //press "joystick" button 2
    }
    else { //button has been released
      Joystick.releaseButton(1); //release "joystick" button 2
    }
  oState3 = buttonState3; //save state to compare next time
  }
 
 
}
If i read the code correctly it is expecting axis value between -127 to 128 (or 127 ?). Which i think is a little wrong since 8 byte integer range is from -128 to 127. This should not cause problems, it is just bothering me.

Welcome to the party W11cE, sounds like you bring some much needed experience with this stuff

Just to clarify you meant to say it's better to use "INPUT_PULLDOWN" so the Teensy has less live pins causing less interference?  Makes sense...

By default the Joystick does update on button press but there's an option to do it manually.  As you say, one for later!

Thanks, I though you already have more experienced people on this forum?

I was not thinking completely what i remembered and wrote. This "active high" case was with "INPUT" without pulldown resistors. So, ofcourse it causes problems because it is just dropping back to floating position, which was just most of the time LOW. This was few years ago, when I wasn't that experienced yet.
Anyway, "INPUT_PULLDOWN" is not that widely supported, unlike "INPUT_PULLUP" which is supported by every(?) board. That is already a good argument to use "INPUT_PULLUP".

[suicidal_orange]

Thanks, I though you already have more experienced people on this forum?

There are some skilled coders here but they mainly write firmware to handle a large switch matrix as a USB keyboard.  There is also Swill who writes cool stuff (a plate CAD file generator and a PM search tool) but from the lack of input in this thread I can only assume no-one does joysticks.  That or they mistakenly think I know what I'm talking about (I don't - I'm learning as I go )) and are leaving me to it...

[Camineet]

these posts are the funnest part of my day. thanks guys

[Camineet]

i've been saying to myself that it isn't rocket science to make a game controller that not only has a lower potential for RSIs but also actually improves control (this whole aspect of the design wherein many buttons (many more than an X360 pad, for example, are available without finger or thumbs picking up and repositioning (for the most part).

but Steve Mann might as well be a rocket scientist.  so i guess it takes either a rocket scientist or an old guy with pain )

[Camineet]

Code: [Select]

#define STICK_X 0
#define STICK_Y 1

#define OVERVAL 0
int Xstick;
int Ystick;

boolean oState2 = HIGH;
boolean oState3 = HIGH;
boolean buttonState2 = HIGH;
boolean buttonState3 = HIGH;


void setup() {
  pinMode(2,INPUT_PULLUP);
  pinMode(3,INPUT_PULLUP);
  Joystick.begin();

}

void loop() {
 
  Xstick = map(analogRead(STICK_X), OVERVAL, 1024-OVERVAL, -127, 128);
  Xstick = constrain(Xstick, -127 , 128);
  Joystick.setXAxis(Xstick);
  Ystick = map(analogRead(STICK_Y), OVERVAL, 1024-OVERVAL, 128, -127);
  Ystick = constrain(Ystick, -127 , 128);
  Joystick.setYAxis(Ystick);
 
 
   buttonState2 = digitalRead(2); //read physical button 2
  buttonState3 = digitalRead(3); //read physical button 3
 
  if(buttonState2 != oState2) { //check against previous button state, if changed do something
    if(buttonState2 == LOW) { //button has been pressed
      Joystick.pressButton(0); //press "joystick" button 1
    }
    else { //button has been released
      Joystick.releaseButton(0); //release "joystick" button 1
    }
  oState2 = buttonState2; //save state to compare next time
  }
 
  if(buttonState3 != oState3) { //check against previous button state, if changed do something
    if(buttonState3 == LOW) { //button has been pressed
      Joystick.pressButton(1); //press "joystick" button 2
    }
    else { //button has been released
      Joystick.releaseButton(1); //release "joystick" button 2
    }
  oState3 = buttonState3; //save state to compare next time
  }
 
 
}
this code compiles and uploads fine

but in reading over the code, i can't figure out which pins the analog stick connects to.  i can see in this sketch that 2 buttons are connected to pins 2 and 3, but where to connect the pins coming from the analog stick?

there are 4 pins coming from the analog stick i will have to solder some hookup wire onto.   can someone tell me where those 4 wires should be inserted into on the board?

[suicidal_orange]

Pin 0 is X and pin 1 is Y as defined at the top - they are what gets "analogRead".  The other two pins need to be connected to ground (marked GND) and 3.3v.

[Camineet]

W11cE, can i trouble you to tell me what each of these pins is for?

i checked your tutorial but couldn't figure it out because the wires in your pics are different colors from the text that tells x, y, ground, and power

thanks

[suicidal_orange]

Comparing your adaptor with the pic below I think the soldered bit of your left of middle wire goes up and left, the right of middle straight up and the right one goes sideways, across 3 traces?  If so it's GND, X, Y, 3.3v as 1-4

[W11cE]

Yes, just like that.
1 GND
2 X
3 Y
4 5V

And notice that when you are using "analogRead", 0 means analog 0.
NOT the same pin 0 which you use with digitalRead. Yeah, does not make any sense, but thats how it was originally written.

So, you would use "A0" for X and "A1" for Y.

[Camineet]

thanks guys

black clay arrived today.  been doing some design work and look forward to adding the next row of keys leg

[Camineet]

it isn't getting any prettier, but it feels like it will work really well.  i fear sugru as the coupling material between legs 1 and 2 at the top will not be sufficient for rigidity and the device will require an icecream stick at the bottom to prevent flex when hitting outside keys.  i really didn't want anything on the bottom so that just my palm can rest on my leg instead of a foreign object.  we'll see later on when the sugru has cured overnight

[Camineet]

today yielded a great success followed by crushing defeat



i can't imagine why the Win7 game controller properties recognizes the X Axis/ Y Axis movement but xpadder doesn't see it the way it should.  usually when setting up an analog controller in xpadder, you click enabled in the sticks setup area, and the dialog box asking you to move the stick left pops up.  then right, up, and down. thereafter, the directions of the analog stick are mappable.  but in this case, the dialog box asks for the stick to be pressed left, and i do.  but nothing happens.



i have managed to get xpadder to see the analog stick's movements in one way.  by selecting x axis and y axis in the setup pictured above, the stick's movements register, but only in one direction.  and they're registering as continuous-on unless i wiggle the stick.  this probably has something to do with the fact that the at-rest position is in the lower left quadrant instead of dead center. 

i've already started doing some poking around the interwebs about xpadder recognizing analog sticks and will do some more.  but i'm stuck at this point any ideas?

[Camineet]

another pic with controller properties details in xpadder in case it helps


the x axis green indicator is twitching a bit, but not enough to affect gameplay i'd guess.

[suicidal_orange]

Nice to see some signs of life, but that doesn't look great.

What are the minimum and maximum values you can get in that last screenshot?

[Camineet]

nevermind.  going into settings in Win7 game controller properties and doing the calibrate wizard solved the problem

[Camineet]

properties after problem is resolved by doing calibration.  does this answer your question orange?

[Camineet]

wait, hold on..

[suicidal_orange]

I was going to calibrate in firmware, but that's looking good.  It was probably remembering the values from your previous controller whatever that may have been

[Camineet]

the green bars for x and y go all the way up to full, and all the way down to nothing.

the analog stick will be used for digital input in league, and the stick is working perfectly in xpadder now with u, d, l, and r mapped to the arrow keys.  seems i won't have to deal with any scaling or adjusting overval or anything else. seems to be working perrrrrfectly


launching league now to test in-game camera control...

patching...

5%

these league patches can take a while

[Camineet]

yeah, previous setups might have confused xpadder.  i've got 2 different xpadders on this system which i don't like.  probably will clean them all out and do a new xpadder installation at some point

[Camineet]

camera control works in league   and on this vita stick, it's sublime

i can see why others have gone to such lengths to get this stick into orbweavers and such.

other than needing someone to write me a 13 button sketch that doesn't have potential for excessive lag, i can probably handle the rest of this project because its just a matter of crafting/construction at this point

[Camineet]

it's 13 buttons right?  even after taking AO and A1, there are 13 available Digital I/O pins i'm free to fill up with buttons i assume.  that'll be plenty with alt-keymaps from xpadder

[Camineet]

another note on alt-keymaps.  thumbsticks present great possibility with alt-keymaps.  a thumbstick can essentially act as 4 buttons.  this means one appendage can activate 4 commands without traveling anywhere.  that's really useful.  using a thumbstick as camera control is great, but it doesn't end there.  not even close.

now add just one alt-keymap by hitting an outside leg key, and the thumbstick now gives you all 4 pings in league.  set another outside key to another alt-keymap, and you've got 4 more commands available in the thumbstick.  that takes care of dance, taunt, laugh, and whatever else. 

point is, thumbsticks in games with alt-keymaps offer a lot of possibilities

i had my x360 controller really tricked out with xpadder using trigger and bumper for alt-keymaps... until the RSIs came anyway

now if Riot would just make that darned radial ping picker compatible with alternative pointing devices like a Wii remote or pen tablet, those of us who can't mouse anymore, due to the trauma those things cause, wouldn't have to set up 4 separate commands just for pings

[suicidal_orange]

If I'm understanding this right all the actual commands the buttons do will be configured in xpadder, so you just need to update the button statuses?

Pretty sure that means you just need 13 pins (one per switch) setup with an "on change" interrupt, with the main thread running the analog stick.  If you can run an interrupt routine including the pin that triggered it this code might be even smaller than the two button example above!

[jaffers]

I'm really liking this thread so far! Great work and a really unique design, I think I have found a project for next year.

I'm interested to see how it will all turn out

[Camineet]

I'm really liking this thread so far! Great work and a really unique design, I think I have found a project for next year.

I'm interested to see how it will all turn out

glad to hear you're liking this thing   and thanks for checking it out and giving encouragement.

project appears to be in intermediate stages and will possibly be usable within 30 days with final wrapup after certain refinements are implemented in around 60 days if all goes well.

thus far not mentioned design point will be a thin layer of sugru over the clay to encase it and make it dirt proof. 

https://sugru.com/guides/how-to-apply-a-super-thin-layer-of-sugru-to-anything

i've wondered for a while how to deal with durability and getting dirty problems of handling clay over and over again as a game controller.  but with the thin layer of sugru idea above, i think i've solved that problem and am pretty excited about it.

cosmetics...

i have a plan to lay a flat wire into the clay to create a design such a racing stripe type of thing.  then i will lay one thin layer color of sugru into the channel created by the flat wire, perhaps white.  then i will lay another color of sugru onto the surrounding sections, perhaps red.  then i might order some white keycaps to really set this thing off.  i could just stick with black, but why not go nuts with cosmetics?

[Camineet]

more work...

had to cut the handset apart due to the need to redo a botched angling job on the outside leg.  this is the primary palm leg from which the outside leg anchor has been cut out...



cutting cured sugru is very easy and effective.  i was able to slice out the leg anchor and cut a new channel with the corrected angle very easily.

some unexpected things have happened when implementing the build to be optimally ergonomic.  the angling work is turning out to be important and a lot more involved than i originally expected.

i mean, you look at a keyboard or an orbweaver and you think, 'herpty flerp, keys go in straight lines'.  well, not here as most guys here have probably realized before me.

every key has the need to be positioned just right, and each key must have a unique tilt in alll directions to face and contact the finger just right, inside and out.

look at how severe the relative positions and tilts are on the keys (this is the outside leg).  i really didn't expect this.




with all of these fine tuned positions and tilts, i've managed to get an excellent fit for very comfortable and low-effort activation of keys...




i have yet to re-sugru the outside leg into place yet, which is why i'm having to hold it in place.  i plan to do it today.  but all seems to be that the device will actually work for effective gaming control.

by the way, i lied in an earlier post when i said i had managed to nail the angle of the icecream stick which will serve as the bed for the analog stick in a way such that zero extension out of the at-rest position is required of the thumb.

in the at-rest position, my thumb and probably anybody else's is actually touching the index finger as here

as mentioned before, one of the reasons i chose the vita stick is for its low profile which would allow me to construct this thing with thumb positioning as close as possible to the at-rest position.  unlike my orbweaver which forces the thumb well into something like 80% into the max range of extension - yuck!

anyway, in my build, the thumb is just over an inch away from the at-rest position when the vita stick is in place on the icecream stick.  i actually did nail the angle of the icecream stick when sugru-ing it into place as far as allowing the thumb to get as close as possible to the index finger and in terms of how the analog stick ends up coming into contact with the pad of the thumb.  but there's no way to have nothing in between the thumb and index finger allowing for zero extension.  there's got to be a base and the analog stick itself. 

at any rate, by my estimate from eyeing it, the extension requirement is about 25% into the range of possible extension.  not perfect, but i don't think there's any way to do better, and this amount of extension shouldn't be a significant contributor to RSI from long-term use

[Camineet]

it will be time soon to tear down the whole thing save for the parts that are sugru-ed in order to do a wireup and final assembly with a total re-claying.  when i do that, i can spend the time to smooth out all the ugly bumps and and notches and coat it in a smoothed out fine layer of sugru as mentioned before.  i'd like this thing to look nice to the extent possible.

one funny idea my fiance had was to make the keys look like teeth with some stickers or something.  this thing already kind of looks like a monster head biting my hand )

[Camineet]

If I'm understanding this right all the actual commands the buttons do will be configured in xpadder, so you just need to update the button statuses?

Pretty sure that means you just need 13 pins (one per switch) setup with an "on change" interrupt, with the main thread running the analog stick.  If you can run an interrupt routine including the pin that triggered it this code might be even smaller than the two button example above!

yep, all i need is more of the same we have achieved so far in terms of info sent to the pc.  so far, the sketch just tells the pc that game controller buttons 1 and/or 2 are getting pressed and the analog stick is moved U, D, L, and R.  don't need anymore from the arduino because as you asked about, xpadder will do all of the actual key-send assignments.

the sketch could be so simple and small?  that'd be mighty fine

[sinusoid]

This thread is totally AWESOME

I didn't expect you'd aim for such a tight fit on the fingers, this begins to look really epic! Begs for some hardware chording

Working with clay-like stuff for organic design is great, you get results that are near impossible to even approximate in digital design. Measuring results for 3d printing is hell too. But the slight turns of keys, minute differences in height, angles etc... those things are what makes a keyboard truly ergonomic.

I'll bomb your thread with some more stuff if you don't mind! (if you do, let me know, I'll carve this out)

I was researching into the effective reach of fingers and corresponding placement of keys, to max out the key density, and minimize the amount of reach you have to perform to press each of the buttons... and the result was something like this:


Alu foil and oil clay with keys ploughed out from some cheap Cherry rubberdome, used up most of they keys, and this is VERY comfortable.

My experiences were very similar to what you're writing about. Later I tried transferring this to digital and 3d printing, but as it turned out, the slight changes in key positioning were really crucial! The feel of the 3d print was really different.

If you wanna get a nice finish on sugru, try flattening a bit of it with a rolling pin, cut up into stripes/squares, and place them over the original.
Sugru is silicone based, so you can use caulking silicone with it, it should bind very well.
You can use a bit of mineral oil to polish both of these into hi-shine before it sets... as far as I remember... so try these things first on a sample if you want to attempt that.

Anyway, good luck with this! Waiting for more progress! 

[suicidal_orange]

I just checked, the Leonardo only has 5 pins which support interrupts so no super-easy solution.

I'm now trying to get my head round whether a 3x5 matrix could work where you cycle between the 3 and use the 5 on the interrupt pins.  Would it need diodes?  Can you switch what each interrupt does and keep track of all the statuses any quicker than just scanning?   Also you have your keys in blocks of 4 so perhaps a 4x4 would work better with wiring in mind, though that would make it slower.  Maybe 4x3 plus an odd one?

Think I need to get my breadboard out and have a play )

[Camineet]

This thread is totally AWESOME

hi friend thanks for your support.  indeed, with the help that these guys have given on this outstanding forum, this thread is indeed AWESOME   really, this project has been a breeze with the help i'm getting

the pic of your work is only viewable on my tablet for some reason.  in firefox, i can't see the pics.  anyway, i saw them and that's some serious work you've done

yep, i can what you've done must be totally comfortable.  bravo

My experiences were very similar to what you're writing about. Later I tried transferring this to digital and 3d printing, but as it turned out, the slight changes in key positioning were really crucial! The feel of the 3d print was really different.

yep, i realized early on that drawing this thing on a computer 1st would just result in an endless series of expensive 3D prints which would cause a lot of frustrating redos due to the hundred minute adjustments that can really only be made in the physical world with something in your hand.  I'm having enough redos as it is in hand.  had to cut out yet another botched sugru angling job on the outside leg today because of some bright idea i had to put a .... well it's not important.  point is, i'll be done screwing this thing up soon and get it right.   and then i can move onto actually getting the device ready to put to use

i don't know how this thing could be later scanned without a straight up pro design studio getting involved...

as you said, it would have to be done without the results coming out with a different feel because one millimeter off, and this thing not only doesn't feel right, it really doesn't work.  it seems when creating an input device for fingers that aren't supposed to move at all, no finger dancing, the positioning has to be absolutely spot on, which isn't easy to achieve.

one thing you might be able to relate to from your experience.  when taking the fingers into a curled position to reduce strain potential rather than having them straightened out and dancing, funny things happen.  for example, in my application, when wanting to move my ring finger to hit an outside key, my pinky wants to pop up too

even the inside keys sometimes see this weird hand event.  pulling my middle finger to hit inside key, my ring finger or maybe another one sometimes pulls too.  luckily, this not entirely unexpected side effect of this design doesn't appear to be a functionality killer.  seems like it will just take some muscle memory work such as when learning to do this )


widespread appeal for this design may be limited by the learning needed to use it effectively because of this.  i've done enough fiddling around with it on my own though to see that it will likely allow me to return to league without a problem *crosses fingers* 

like when one of my other fingers pops up or pulls unintentionally, it doesn't depress its corresponding key enough to activate it.  it just sort of bumps up against it as my intentional finger does its work.

[Camineet]

I'm now trying to get my head round whether a 3x5 matrix could work where you cycle between the 3 and use the 5 on the interrupt pins.  Would it need diodes?  Can you switch what each interrupt does and keep track of all the statuses any quicker than just scanning?   Also you have your keys in blocks of 4 so perhaps a 4x4 would work better with wiring in mind, though that would make it slower.  Maybe 4x3 plus an odd one?

Think I need to get my breadboard out and have a play )

thanks for looking into this orange.  your help continues to be invaluable

[W11cE]

Interrupts are overkill for something like this. The usb polling is minimum 1ms (don't know what it is in this code), which gives a lot of time for processing stuff.

If you have enough pins there is no reason for a matrix. Harder to use and probably more latency (have not measured), because all the buttons are polled separately on software.

I may be able to help with the code in 1-2 weeks. I have some other projects right now.