How do you acquire the axis position data for a 3D Connexion SpaceNavigator joystick?

[ifc]

I am using a SpaceNavigator joystick (by 3D Connexion), which has 6 axes and 2 buttons. Using the standard "Initilaize Joystick" VI and "Acquire Input Data" VI, I can easily grab all button and axis info. The problem is this: the axis info does not describe the position of the joystick (as I would have expected), it instead returns an integer which increments/decrements according to the position of the joystick. That is to say, for example, if I push the joystick far forward the x-axis integer increments quickly, and if I push it lightly forward the the x-axis integer increments slowly. When I let go of the joystick, the x-axis integer remains constant. Therefore, the only way to read the actual state of the joystick is to look at the rate of change in the integer value for a particular axis.

Maybe it's just me, but this seems entirely counter-intuitive, as it is much easier to integrate a discrete signal (smooth output), rather than differentiate it (noisy output). I would think that at the basic level the joystick is returning the position of its axes, and the "integration" operation is happening later on.

For my application, I need to know the current state of the joystick, therefore, I look at the relative change of each axis integer and divide it by the time period between loop iterations (which varies since this is not an RT system). This obviously causes a lot of noise, so I have a very-low-pass filter to keep the output smooth, which of course introduces lag into the overall system and requires additional computing.

Has anyone else ever experienced this when working with joysticks in labview? If this happened for every joystick, I assume there would be more discussion posts about it. Does anyone know of a good way to get around this problem and extract the real axis data?

[Intaris]

There is probably no "real Axis data" as you write.

This kind of behaviour os perfectly allowable according to the HID specification document.

Analog controllers like this can have several different types of feedback.  "regular" joysticks tend to be absolute, but relative is actually a perfectly legitimate HID response.

You'll have to monitor the rate of change yourself in software I think.

Shane.

[io io]

With rate measurements, you must establish a sample rate.  The sample rate will dictate the bandwidth of the change that can be detected.  It is not enough to measure static voltage, but a high speed ADC must be used (Like the NI FPGA Module would do the job).

We are building a Flight simulator using the 3D connexion SpaceNavigator and the NI FPGA hardware. 

[BruceAmmons]

Very easy.  Read the joystick at a regular rate (every 100 msec or however often you need it) and subtract the previous value.  You can store the previous value using a feedback node.  The difference is the current rate.

If you read slow enough, the noise will be minimal.  Just put it in a timed loop by itself.  How often do you need to update the joystick value?  It seems like 100 msec would be adequate, even if other loops are running faster.

Bruce

[io io]

We are reading the joystick every 5mS using the because we are trying to make it very sensitive and fast responding.

We are trying to use the 7831R to implement the real-time loop.  Have you implemented this 3-D space joystick?

Thanks for the input,

Carlos

[Intaris]

1kHz is the max allowed response rate for a HID. (1ms Polling).

Your device will declare its maximum report speed in the device descriptor so if this entails more than a 5ms wait, then you're wasting your time polling faster than that.

Shane.

[BruceAmmons]

5 ms seems like overkill.  The human body just can't respond that fast.  I would suggest starting with 100 ms and see if it responds fast enough.  If not, divide by two or five and try again.  Repeat until it is responsive enough.  I think you will find a much longer interval than 5 ms is perfectly adequate.

Bruce

[Intaris]

I agree that for human response reasons 5ms is too fast (although I'd say 100ms is too slow) but I don't know what they're using it for.  If the device has a maximum update rate of 10ms then 5ms is overkill even if it's a robot moving the joystick.....

Shane.

[Intaris]

If you look at my USB nuggets I actually have an example for reading data from a HID.

You can easily wrap events around that and have your own signalling process for any device in question.  The VISA functions will only return data when data is available so you can just run it at full speed (no timing) and you'll pretty always have the maximum read speed of the device.

You jsut need to make a. inf for the device for VISA.

Shane

[io io]

I will use printed out the two nuggets.  I will review and implement.  THanks! 

As with any control  or sensory data - sample rate is an engineering decision made up front and then fine tuned. 

I have seen system with low sample rate and it misses many events.  I have also seen system with an overkill

on sample rate and the data read is too much to handle. 

I think the two nuggets might solve the problem. 

Carlos