Translational Control

[texasflyboy]

I've reached a decision point and I was hoping you all could help. I'm trying to decide on the interface board. Here are the choices:

 

1) UltiMarc U-HID board, seems to be more plug and play but not as versatile. Much more expensive ($80) 

http://www.u-hid.com/home/overview_board.php

2) Arduino Micro, not as plug and play, may be more of a headache for a non-programmer. Much cheaper ($25)

http://www.instructables.com/id/Arduino-LeonardoMicro-as-Game-ControllerJoystick/

 

Appreciate any input!

 

Jon 

[Nuke]

leonardo is pretty easy to use and approachable for beginners. there is some programming involved, but its very much designed to be simple enough for non-programmers to pick up and do something useful with it. most important it has a lot of libraries for every kind of sensor imaginable. and there is a great community if you need help. you can also get one of the newer arduino micros which have the same mcu (atmega32u4) as the leo but a much smaller footprint, and you can get knockoffs on ebay for less than $10. joystick and mouse are supported by the built in libraries, you will need a 3rd party library for joysticks (heres mine).

the other board looks pretty good if you dont want to get your hands dirty (get code all over them). looks like you just send it commands over a cdc port (com port over usb) to configure it with a command set. or perhaps you need a lot of io pins and you dont want to mess with matrixing, shift registers, or port expanders. it will probibly work for what you want. but the arduino would be more flexible.

[texasflyboy]

Ok, I think we'll go Arduino Micro. Having a big support community is the deciding factor. 

Found an awesome harness supplier: https://www.pololu.com/category/19/connectors

Then we'll use the J-stick from Ultimarc and add some extra micro-switches for the other axis:

 

I'm also ordering four extra push-buttons to mount nearby for RCS, SAS, Invert SAS and Fine Control. 

 

[texasflyboy]

I'm not currently aware of a good way to post code so that it doesn't take up an entire page but figured this was short enough to be ok this time. How do you guys post code? 

Looks like the code part of this project (just the translational hand controller itself) is going to be pretty easy. How does this look? This is going into an Arduino Micro.

Any suggestion on specifically what pins I should be using? 

 

#include <Keyboard.h>

void setup() {

  pinMode(1, INPUT_PULLUP);
  pinMode(2, INPUT_PULLUP);
  pinMode(3, INPUT_PULLUP);
  pinMode(4, INPUT_PULLUP);
  pinMode(5, INPUT_PULLUP);
  pinMode(6, INPUT_PULLUP);

  Keyboard.begin();

}

void loop() {

  // UP
  if (digitalRead(1) == LOW) {
    Keyboard.write('k');
  }

  // DOWN
  if (digitalRead(2) == LOW) {
    Keyboard.write('i');
  }

  // LEFT
  if (digitalRead(3) == LOW) {
    Keyboard.write('j');
  }

  // RIGHT
  if (digitalRead(4) == LOW) {
    Keyboard.write('l');
  }

  // FORWARD
  if (digitalRead(5) == LOW) {
    Keyboard.write('h');
  }

  // BACKWARD
  if (digitalRead(6) == LOW) {
    Keyboard.write('n');
  }

}

[Nuke]

use code tags: [ code ] putCodeHere(); [ /code ] without the spaces in the tags (or use the <> icon in the editor).

you can use any pin you want. some pins have advanced features like pwm, serial, i2c, spi, interrupts, etc, but you usually dont need those for what you are doing (passing some buttons as keystrokes). you can even use the analog pins as digital if you run out, analog 0-5 corresponds to digital pins 14-20.

pretty much you got the right idea. im looking over the keyboard library and it looks like the Keyboard.write() function passes keypress events (press followed by release). it might be better to pass them as press/release event pairs.

if (digitalRead(1) == LOW) {
    Keyboard.press('k');
}else{
    Keyboard.release('k');
}

 

Edited April 8, 2016 by Nuke

[texasflyboy]

I did go back and forth (actually re-wrote then went back) between write --> press --> write. I think what it'll come down to is if the processor is running fast enough that I don't notice the really fast press/release/press cycle, the write function should work. I'm always happy to listen to rationale or past experience though! Any particular reasoning?

Thanks

[Nuke]

if you are getting weird button behavior you might want to google "button debouncing" to find some hardware/software methods for smoothing out your signals. some people use low pass filters, schmitt triggers, or both on the hardware side. i usually opt for debouncing in software, especially if you are doing a large number of inputs.

[texasflyboy]

I should be able to try it all out on Monday when the hardware arrives. I appreciate the debounce reminder. I think the arduino has a debounce software function that I can try as a start. 

[texasflyboy]

On 4/9/2016 at 0:40 PM, Nuke said:

if you are getting weird button behavior you might want to google "button debouncing" to find some hardware/software methods for smoothing out your signals. some people use low pass filters, schmitt triggers, or both on the hardware side. i usually opt for debouncing in software, especially if you are doing a large number of inputs.

So I do seem to be getting some weird behavior but I'm not sure (the circuit is just prototyped right now). The Arduino will reliably output the letter I want it to, but the output will continue for a few moments after the pin goes high again. 

If you were to write debounce code for this particular application, debouncing each of the six switches, how might you write it? I'll have another look but it's not immediately obvious right now. 

From a hardware standpoint, I'm also wondering the best way to create a power "bus" for these low voltage circuits. I want to take the 5V pin and distribute it to each of the 6 switches. What hardware would I use to do this? 

The ground bus is obvious, using the chassis of the panel and tying the ground pin there as well. But I haven't seen any good solutions for the 5V bus other than perhaps this:

 

 

[stibbons]

For my low-voltage power and signal connections, I'm settling on dupont-style connections. These sorts of connectors plug on to plain old header pins soldered to your controller at the other end.

I wrote a long post about how I debounce inputs in my controller in the KSPSerialIO thread a while ago. It was intended to describe how to latch inputs to work with action group state changes, but most of it is still relevant here.

And I'm not convinced that Keyboard.write() is the best option here either. But you should also check if the current button state has already been sent. I'd implement it something like

// debouncedState is the reading we've taken from the button after debouncing
// currentState is the reading that has been processed and sent to the PC
if (currentState != debouncedState) {
  if (debouncedState == LOW) {
    Keyboard.press('X'); // or whatever
  } else {
    Keyboard.release('X');
  }
  currentState = debouncedState;
}

 

[Nuke]

keyboard write passes a keypress event. if you press a button, then every time the loop cycles through its going to send a new keypress event, which is a press and a release. essentially as if you were tapping the key really fast. which is why you want to send separate press and release events depending on the state of the buttons every loop.

debounce all comes down to heuristics really. you want to keep some memory of previous button states. i wanted to post my code but i couldnt find it. its kind of spaghetti and probibly needs to be rewritten as a library, its also kind of designed to work with button matrices. it was also set up so i could debounce an entire port in one pass. it uses low level port designations which are different on the atmega32u4 (i wrote it for the atmega328p for radio control applications), so i would have to dig through datasheets or port it over. its also not in a library but rather is a nasty blob of code floating around somewhere in my sketch folder.  i actually use this algorithm, the debounce function is at the bottom. pretty much takes a bitfield where every bit is the state of a button, and then it debounces them all in parallel. but i have mine set up to be really fast with a lot of low level code.

Edited April 13, 2016 by Nuke

[texasflyboy]

Quick update:

Now that all the hardware is here, I was finally able to try a real test. Using INPUT_PULLUP and then connecting the switch between the ground pin and the input pin, I was very reliably and consistently able to get crisp commands of the letter 'k' into Notepad. I think from a software and conceptual standpoint, we're set. It appears that the Keyboard.write() works great and requires less code, so I'm happy for now. 

Now back to trying to mount this joystick so it can move through the third axis.

IMG_8724 by Jon Griffith, on Flickr

Edited April 14, 2016 by texasflyboy

[texasflyboy]

By the way, from a mechanical standpoint, this is what I'm trying to accomplish. If anyone has any good sources for parts or suggestions, please let me know. 

Linear Motion by Jon Griffith, on Flickr

Edited April 14, 2016 by texasflyboy

[moogoob]

On 3/28/2016 at 6:37 PM, nukeboyt said:

I use an x-box controller for PC.  I have the D-pad setup for left-right / up-down translation.  And the "Y" button for forward and "A" for backwards.   This works very well (for me).

 

I use L and R bumpers for forward and backwards thrust - but otherwise the controller has all the axes needed for both translation and rotation, with room left over for SAS toggle, IVA view toggle, gear, brakes, throttle up/down and staging.

[Nuke]

5 hours ago, texasflyboy said:

By the way, from a mechanical standpoint, this is what I'm trying to accomplish. If anyone has any good sources for parts or suggestions, please let me know. 

Linear Motion by Jon Griffith, on Flickr

that looks pretty good. plastic bushings should be sufficient vs linear ball berings. they slide easier and dont require lubrication (or precision rods). the spring system should work but you might want to put calibration screws at the ends. if you can find rods with threaded ends but a smooth center, you could just use two nuts, one to adjust and a second to lock it in place. you want to calibrate so that the springs fit snug but wont fight eachother near the center. you might be able to get away with a single ended calibration system, with the back springs butting up against the back plate, with the front springs with adjustment screws. you might even do a single push/pull spring which could simplfy things a lot.

Edited April 14, 2016 by Nuke

[nukeboyt]

2 hours ago, moogoob said:

I use L and R bumpers for forward and backwards thrust - but otherwise the controller has all the axes needed for both translation and rotation, with room left over for SAS toggle, IVA view toggle, gear, brakes, throttle up/down and staging.

Agreed!  I use my bumpers for SAS & RCS toggle, so we're very close.   I use the triggers for throttle up & throttle down.   Had to set throttle "rotation axis " as both Primary and Secondary, then invert one of them.  I have the ESC set as the "start" button and time warp at "B" & "X",  When I"m playing I never have to touch the keyboard (not even to pause for taking out the garbage) .   Still have to use the mouse though (to change viewing angle, and select from menu, etc)

Edited April 14, 2016 by nukeboyt

[moogoob]

2 hours ago, nukeboyt said:

Agreed!  I use my bumpers for SAS & RCS toggle, so we're very close.   I use the triggers for throttle up & throttle down.   Had to set throttle "rotation axis " as both Primary and Secondary, then invert one of them.  I have the ESC set as the "start" button and time warp at "B" & "X",  When I"m playing I never have to touch the keyboard (not even to pause for taking out the garbage) .   Still have to use the mouse though (to change viewing angle, and select from menu, etc)

What do you set brakes to? Or do you not use planes/rovers? If that's the case I wouldn't bother mapping brakes either.

Also, I wish it would let you map the big "X" button in the middle of the controller. I would SO use that for staging.

Edited April 15, 2016 by moogoob

[nukeboyt]

I map the brakes to the button on the other side of the big x, opposite the start. (not at home now so not sure of the name).

I also wish we could use the big x.. I stage with the right joystick (push button) and throttle cutoff with the left 

[texasflyboy]

Ok, it's been a little while, but I'm back! 

Recently, through some assistance over at the Adafruit forums, we came up with the proper bearing solution (panel bearing) for this application. 

Edited April 28, 2016 by texasflyboy

[texasflyboy]

The panel bearings do not give the smooth motion needed for this controller. So back to the drawing board in search of other bearing solutions. It's either going to be nylon panel bearings as suggested by Nuke (if anything like this exists) or linear ball bearings, if I can find them in a small enough package (and at the right price). 

[Sputnix]

On 3/29/2016 at 8:37 AM, texasflyboy said:

Hi Everyone,

I've seen some pretty awesome custom control panels but can't seem to find specific hardware solutions for translational (up, down, left, right, forward, backward) control. Ideally, a three axis joystick would be perfect for this, but I've never seen one available to the general public. The closest I've seen is what we used for the space shuttle, but just can't seem to find any available salvage hardware

 

 

Heya,

Sorry for the delay in this - but I wound up getting myself a 3D Connexion Space Navigator, after I saw similar discussions on the forum about it.

They're designed more for navigation in 3D modelling environments, but it works great in KSP for translation control. And it works just as you'd expect. What's more, from what I understand, an early version was used on Columbia (Space shuttle) to control the arm.

It's pretty much plug-and-play (once you install the drivers). All you have to do is hit 'scroll lock' to enable / disable the 3D mouse from being used for translation controls.

Not sure if this defeats the idea of what you're wanting to do (ie. build one / DIY) but it does meet the requirements of
 

Quote

one available to the general public

 

[texasflyboy]

Sputnix, you're correct, this seems to be the only commercially available controller that has the ability to control translation. I'm familiar with them as used to control CAD software views. My main problem with them is that their "feedback" is pretty mushy, as they're meant to finely control a 3D environment. When maneuvering, it's very useful/intuitive to know when the jets (or arm motion in this case) are on or off. So crisp and obvious feedback, as well as digital on/off control, ends up being the most useful. I think this is one of the reasons the Shuttle program ended up adopting the translational hand controller for translation arm movement as well. With so many degrees of freedom available to a spacecraft, it seems that taking analog control out of at least the translational axes (though in some modes the rotational axes is the same, digital), makes this task easy for the brain to comprehend. 

[Sputnix]

Ah yes, got you.

I completely agree. I've found it an adequate solution - but that feedback you talk of would be so darn nice! 

I'll be following your progress! Definitely interested to see what you come up with

[texasflyboy]

I know it's been a long time but I may have found a solution. What's better is that it uses the joystick I ended up buying. I can't believe I didn't think of this!

 

http://www.sgtnoodle.com/projects/kerbal-control-panel/

 

Enjoy,

 

Jon 

[Nuke]

pretty cool. the whole unit has an awesome aesthetic to it.