Space Navigator PE Driver Development Thread

[inh]

heres a snippet to determine which axis is being acted upon. what was happeneing is that i had it set to play/pause the song when i pressed down on the hat (z axis) and to turn the volume up or down when i twisted it, but when i would twist it would change the z value a bit so the song would pause.. This is a snippet that will determine which axis is being acted upon the most.. Its really sloppy and nasty, but as of now im not aware of any functions or other features of the glovepie scripting language that would speed this up..

Code:

//Routine to determine which axis is being acted upong the most due to it being
//inevitable that more than one axis will change at a time
//this checks all values after a specified time and determines which one changed the most

//get a position reading from all axises
var.roll.1 = MapRange(Joystick1.roll, -1,1, 0,1)
var.yaw.1 =  MapRange(Joystick1.yaw, -1,1, 0,1)
var.pitch.1 =  MapRange(Joystick1.pitch, -1,1, 0,1)
var.x.1 =  MapRange(Joystick1.x, -1,1, 0,1)
var.y.1 =  MapRange(Joystick1.y, -1,1, 0,1)
var.z.1 =  MapRange(Joystick1.z, -1,1, 0,1)

//wait a bit, then get positions again
wait 200ms
var.roll.2 = MapRange(Joystick1.roll, -1,1, 0,1)
var.yaw.2 =  MapRange(Joystick1.yaw, -1,1, 0,1)
var.pitch.2 =  MapRange(Joystick1.pitch, -1,1, 0,1)
var.x.2 =  MapRange(Joystick1.x, -1,1, 0,1)
var.y.2 =  MapRange(Joystick1.y, -1,1, 0,1)
var.z.2 =  MapRange(Joystick1.z, -1,1, 0,1)

//compare second reading to first usign subtraction, then use th absolute function so that even negative values
//return whole numbers. the greated var.whatever.diff value will be the axis that has changed the most
var.roll.diff = abs(var.roll.2 - var.roll.1)
var.yaw.diff =  abs(var.yaw.2 - var.yaw.1)
var.pitch.diff = abs(var.pitch.2 - var.pitch.1)
var.x.diff =  abs(var.x.2 - var.x.1)
var.y.diff =  abs(var.y.2 - var.y.1)
var.z.diff =  abs(var.z.2 - var.z.1)

//super-sloppy if tree to figure out which var.*.diff is the greatest, and then act accordingly..
//as of now it just spits out which axis is being acted upon up in the debug bar at the top
//of the scripting window..
if ((var.roll.diff > var.yaw.diff) and (var.roll.diff > var.pitch.diff) and (var.roll.diff > var.x.diff) and (var.roll.diff > var.y.diff) and (var.roll.diff > var.z.diff))
   var.roll.dir = sign(var.roll.2 - var.roll.1)
   if (var.roll.dir = -1)
      debug = "Roll (Twist Left)"
   elseif (var.roll.dir = 1)
          debug = "Roll (Twist Right)"
   endif
else if ((var.yaw.diff > var.roll.diff) and (var.yaw.diff > var.pitch.diff) and (var.yaw.diff > var.x.diff) and (var.yaw.diff > var.y.diff) and (var.yaw.diff > var.z.diff))
     var.yaw.dir = sign(var.yaw.2 - var.yaw.1)
   if (var.yaw.dir = -1)
      debug = "Yaw (Tilt Right)"
   elseif (var.yaw.dir = 1)
      debug = "Yaw (Tilt Left)"
   endif
else if ((var.pitch.diff > var.roll.diff) and (var.pitch.diff > var.yaw.diff) and (var.pitch.diff > var.x.diff) and (var.pitch.diff > var.y.diff) and (var.pitch.diff > var.z.diff))
     var.pitch.dir = sign(var.pitch.2 - var.pitch.1)
   if (var.pitch.dir = -1)
      debug = "Pitch (Tilt Forewards)"
   elseif (var.pitch.dir = 1)
      debug = "Pitch (Tilt Backwards)"
   endif
elseif ((var.x.diff > var.yaw.diff) and (var.x.diff > var.pitch.diff) and (var.x.diff > var.roll.diff) and (var.x.diff > var.y.diff) and (var.x.diff > var.z.diff))
        var.x.dir = sign(var.x.2 - var.x.1)
   if (var.x.dir = -1)
      debug = "X (Slide Left)"
   elseif (var.x.dir = 1)
      debug = "X (Slide Right)"
   endif
else if ((var.y.diff > var.roll.diff) and (var.y.diff > var.pitch.diff) and (var.y.diff > var.x.diff) and (var.y.diff > var.yaw.diff) and (var.y.diff > var.z.diff))
     var.y.dir = sign(var.y.2 - var.y.1)
   if (var.y.dir = -1)
      debug = "Y (Slide Forewards)"
   elseif (var.y.dir = 1)
      debug = "Y (Slide Backwards)"
   endif
else if ((var.z.diff > var.roll.diff) and (var.z.diff > var.yaw.diff) and (var.z.diff > var.x.diff) and (var.z.diff > var.y.diff) and (var.z.diff > var.pitch.diff))
     var.z.dir = sign(var.z.2 - var.z.1)
   if (var.z.dir = -1)
      debug = "Z (Pull Up)"
   elseif (var.z.dir = 1)
      debug = "Z (Push Down)"
   endif
else
    debug = " "
endif

Edit: tweaked the code a bit to give you a better idea of what axis is being affected... I'm sure i'll have a useable script up in a bit

[cherrybomb]

Quote: Originally Posted by azhar97

Thanks Turbo!...

even with this joystick driver....there are million possibilities...
i wonder why people dont search a little....
all i see here was lot of effort to run this device, but, the impression after reading this thread was that nobody have even tried to search on google to find some links?................or maybe "they" did, but, dont want to disclose it?....I really dont know.

anyway....this small driver is definitly the answer which can be used just right after installing the navigator!

i will post some more links on this device soon....

Interesting stuff. It's true I didn't do any searching for drivers on this, of course, I pretty much took the word of everyone else that there wasn't a good solution.

So, are we devoted to this combination of stuff as the solution?

I'm actually pretty well along with a driver for capturing and pushing the axis data from the device. It can even toggle the LED on or off. What Sama and I are working on would be darn small, specific to this application, and only require a single application installed. Plus, no coding, other than maybe some configuration of your FE.

What's the consensus, do we adopt this as "the solution", or pursue our own community grown solution?

[inh]

i vote for the driver since im not too good at coding in a true native language and it would be really beneficial to not have all the overhead glovepie and all the other crap adds...

but for the time being im gonna play with glovepie because it gives me something to do...

[sama]

I did search for a mechanism to use the SpaceNavigator but must have missed that one somehow. I would certainly not have hidden it since the initial approach was to use girder, and not to have a driver.

Regardless, I still think a driver is the better solution, as you will be able to do gestures and context-based mapping reconfiguration.

[azhar97]

Quote: Originally Posted by cherrybomb

Interesting stuff. It's true I didn't do any searching for drivers on this, of course, I pretty much took the word of everyone else that there wasn't a good solution.

So, are we devoted to this combination of stuff as the solution?

I'm actually pretty well along with a driver for capturing and pushing the axis data from the device. It can even toggle the LED on or off. What Sama and I are working on would be darn small, specific to this application, and only require a single application installed. Plus, no coding, other than maybe some configuration of your FE.

What's the consensus, do we adopt this as "the solution", or pursue our own community grown solution?

The best is to have direct aproach using builtin HID on SN.
3DConnexion have stopped supporting Microstation (one of the best CAD in the market which i use).

so, my only challenge (which is not linked to carpc at the moment) is to make an interface between SN and Microstation.

Off the subject but, maybe worth later: microstation have built-in application support written in MDL (sources and compiler is C). and what i am working on is to write a MDL application to use SN directly in Microstation (Using HID).

at the moment, for CarPC even a very little plugin with a long route on using is worth....so, till one of us make something better then what we have, I think its best to use it.

[cherrybomb]

Quote: Originally Posted by azhar97

The best is to have direct aproach using builtin HID on SN.
3DConnexion have stopped supporting Microstation (one of the best CAD in the market which i use).

so, my only challenge (which is not linked to carpc at the moment) is to make an interface between SN and Microstation.

Off the subject but, maybe worth later: microstation have built-in application support written in MDL (sources and compiler is C). and what i am working on is to write a MDL application to use SN directly in Microstation (Using HID).

at the moment, for CarPC even a very little plugin with a long route on using is worth....so, till one of us make something better then what we have, I think its best to use it.

Okay, so we'll definitely continue work.

Not to sound ignorant, but what does the acronym "SN" stand for?

Also, sounds like you're doing some development too, or just adapting the device for use with your 3d app? If you've done any dev work with the device, I'm sure we could share info that would make each of our efforts more successful. :-)

[azhar97]

Quote: Originally Posted by cherrybomb

Okay, so we'll definitely continue work.

Not to sound ignorant, but what does the acronym "SN" stand for?

Also, sounds like you're doing some development too, or just adapting the device for use with your 3d app? If you've done any dev work with the device, I'm sure we could share info that would make each of our efforts more successful. :-)

SN is SpaceNavigator

what i am doing for microstation at the moment is a direct approach using HID. There is no way I can adapt this technique in that software. thats a real 3D CAD system - does'nt take joystick for anything. it needs its own environment and application.
once i am done (hopefully soon) i will definitly share my findings and approach on this.

[azhar97]

BTW: best place to start with is http://www.3dconnexion.com/support/4h.php

this is the SDK (software development kit) from 3dconnexion if you are planning to write an interface with any of there devices.

It does have sample codes/header files/libraries for C compilers (both in 32bit and 64bit)

[sama]

I've come up with a config file, which I'd like some input on, before I go on and code away to implement the features in there.

Most of it is explained within, but if anything is unclear, please let me know. It's by no means fully defined, but it does show the intended feaures.

I think the best way would be to imagine you were editing this, and see how intuitive (or not) it is, and what things are missing etc.

# Space Navigator PE Config File
#
#
# AXIS MODE DEFINITIONS
# ---------------------
# There are two modes that can be assigned to an axis, they are BINARY and PULSE.
#
#
#
# BINARY MODE
#
# syntax: binary, tirgger_threshold [float]
#
# tirgger_threshold : specifies how far you have to travel along the axis before an event is triggered.
#
# eg: PAN_X = binary, 0.1
#
#
#
# PULSE MODE
#
# syntax: pulse, tirgger_threshold [float], start_pulse_rate [integer], end_pulse_rate [integer], acceleration_mode [linear,exponential]
#
# tirgger_threshold : specifies how far you have to travel along the axis before an event is triggered.
#
# start_pulse_rate [integer] : once the threshold is reached, the pulse rate will be fired at the provided fequency (measured in Hz).
#
# end_pulse_rate [integer] this defines the pulse rate to fire at when the axis is flexed to its entire range
#
# acceleration_mode [linear,exponential] : the accelerating behaviour of the pulse rate increase, between the start and end of the above defined range.
#
#
#
#
# CONTEXTS
# --------
#
# Settings can live either in a global context, which means they'll be applicable all the time, or they can live in specific contexts.
# If a setting exists in both a global and a specific context, then the specific context setting will override the global context setting.
#
# It is possible to assign an action to switch context using the syntax:
#
# <action> = CONTEXT_SWITCH
#
# where the action can be a button press, or a gesture definition.
#
#
#
#
#
# ACTIONS
# -------
#
# These are defined in the following format:
#
# <action> = MAPPING
#
# The <action> can be an axis or a button name, or it can be a gesture. An axis must also define a + or a - sign following its name, to identify the
# intended direction. A + defines RIGHT for twisting/panning/tilting horizontally, UP for panning/tilting vertically, and PUSH for the vertical axis.
# A - is the opposite.
#
# Gestures are defined as a chain of axis or buttons, and times, seperated by pipes (|). The times define how long to wait before assuming the user has finished.
#
# For example:
#
# GESTURE: TWIST+ | 100 | TWIST-
#
# If the user is to twist the knob to the right, then witihin 100ms twists the knob left, then the action assigned to that gesture will be carried out.
# By that same token, if there are two gestures defined as follows:
#
# GESTURE: TWIST+ | 100 | TWIST-
#
# GESTURE: TWIST+ | 100 | TWIST- | 100 | VERTICAL+
#
# If the user gets to the TWIST- and within 100ms presses the VERTICAL axis, then the only the second gesture will be actioned. This is something to avoid however to reduce mis-gesturing!


[CONTEXT GLOBAL]

[AXIS]

PAN_X = binary, 0.1
PAN_Y = binary, 0.1
TILT_X = binary, 0.1
TILT_Y = binary, 0.1
TWIST = pulse, 0, 1, 50, exponential
VERTICAL = pulse, 0.1, 1, 1, linear

[END_AXIS]

[ACTIONS]

BUTTON_R = CONTEXT_SWITCH_UP
BUTTON_L = CONTEXT_SWITCH_DOWN

[END_ACTIONS]

[/CONTEXT]


[CONTEXT AUDIO]

[AXIS]

PAN_X = binary, 0.1
PAN_Y = pulse, 0.1, 1, 1, linear
TILT_X = binary, 0.1
TILT_Y = binary, 0.1
TWIST = pulse, 0, 1, 50, exponential
VERTICAL = pulse, 0.1, 1, 1, linear

[/AXIS]

[ACTIONS]

GESTURE: VERTICAL+ | 100ms | TWIST+ = CONTEXT_SWITCH_UP
GESTURE: VERTICAL+ | 100ms | TWIST- = CONTEXT_SWITCH_DOWN

VERTICAL+ = CMD: exec.exe PLAY
VERTICAL- = CMD: exec.exe STOP

PAN+ = CMD: exec.exe (what ever would scroll the play list up)
PAN- = CMD: exec.exe (what ever would scroll the play list down)

[/ACTIONS]

[/CONTEXT]


# This is used for GPS
[CONTEXT GPS]

[AXIS]

PAN_X = MOUSE_X
PAN_Y = MOUSE_Y

[/AXIS]
[ACTIONS]

TWIST = pulse, 0, 1, 50, exponential

[/ACTIONS]

[END_CONTEXT]

[inh]

I like it, although i think it would be best to have a config file that makes it easiest for you, and gets the most felxibility out of the device, and then whip up a quick frontend in something as simple as VB...

Also, woudl it be possible to spit out keypresses? This would enable context specific actions, as defined in keysTBL and execTBL.. By defining names to certain key combinations in keystbl, and then certain actions depending on where in RR the user is to the funcitons defined in keystbl, its context sensitive

just a though, as you made it seem earlier that a hardcoded driver was the only way to get the device to behave differently on different skin pages..

Theres a thread describing exactly what im talking about, but i am unable to find it right now =[

[sama]

simple for me is no good, it's got to be hard

what would you need a front end for?

regarding the mechanism for switching contexts, I was thinking it would be better if the frontend somehow told the driver which context it should be in. I'm sure we can think of a few mechanisms to do this. That way, if the touchscreen is used to switch to a different screen, the context would also be switched.

[sama]

I wonder how exec would behave if the exponential mode is on, and it the driver is sending something like this:

exec.exe FAST_FORWARD (or whatever the command is)

at 200Hz!

[inh]

Well, with the keymapping, you define what action you want to take on what skin page, or it can be universal for all skin pages, or it can have certain functions for certain skin pages, and then one default action for the rest.. I'm going to try to dig up that thread again. Why add in extra complexity when RR already features mechanisms for this

as for the front end, it woul dbe great to just do a gesture, and have the lil app figure timings and such...

[inh]

this isnt THE thread i read, but it pretty much explains it..
http://www.mp3car.com/vbulletin/show...hlight=context

[sama]

Ah, I see what you're saying now. That's a good idea, I'll get it to spit out keys too so that can be used. In that case, you'd only define one context.

Might still be worth including multiple contexts for other FE's. I wonder how many other front ends do this, if at all. Any idea anyone?