Differentiating between Roll and Spin

[PowderGoblin]

Did anyone program something beyond the C# example given here?
If "yes" will appreciate any tips on the following

It appears that the Spin and Roll Forward/backward are registered with the same output parameter - in the C# example it is given with "Ry".

The only visible differentiation I saw was that the values for Roll are +/- 0.000123 and the values for Spin are +/- 0.990123.
These are example values - do not cling to them - bottom line is that one can reliably differentiate between a Spin and a Roll by monitoring IF > 0.99f

The same seems to be the case for various other axes.

Here is the problem I am facing now: To filter out noise from other axes and to guess correctly the intention of the operator a series of conditions seems to be needed.

I am trying to guess what these have to be - but I am thinking - maybe somebody already figured it out.

Will be most thankful if you share ...

Just to put it in other words so that we stay on the same page:
I am not talking about calculating angles from the values. If you look at the 3Dconnexions demos then the Jet demo is an example of very "sensitive" mode where the slightest movement in any direction is presented. In other demos, however, the movements are much more simplified - in these demos the feedback from the unit is DEFINITELY filtered out. This filtering seems to be happening based on conditional processing of the various axes - so - these conditions are important because the cut-off values there are specific and me guessing them is probably not the best thing to do.

Btw. ... now that I deal with the unit programmatically - I begin guessing why this thing is not put out in a Joystick mode - it is completely different animal

[jwick]

All 6 DOFs should be arriving on their own separate values. Make sure you don't have some of them turned off in the driver (3DxWare GUI).

What example are you referring to? Maybe there is a bug in it.

Jim
3Dx Software Development

[PowderGoblin]

It is the C# sample you posted.
It does not look like there is a bug in it though - looks fine:
Tx.Text = sensor.Translation.X.ToString("#.######");
Ty.Text = sensor.Translation.Y.ToString("#.######");
Tz.Text = sensor.Translation.Z.ToString("#.######");
Rx.Text = sensor.Rotation.X.ToString("#.######");
Ry.Text = sensor.Rotation.Y.ToString("#.######");
Rz.Text = sensor.Rotation.Z.ToString("#.######");

If you run it carefully tapping the axes to prevent noise you will notice the following:
Roll Forward/Backward shows in the Ry field without noise on the other axes and the typical values are +/- 0.000###
The Spin (twist) of the unit comes also in the Ry field yet there the typical values are +/- 0.99####

You can never get a Roll value even close to the values you get with Spin and you will never get Spin values as low as the Roll values.

Yet they both appear under Ry - so - when I am programming my camera I need to tell it when to roll and when to spin - yet the values are both coming from Ry.

Btw. same thing for other axes but let's focus on this - the rest is a derivative.

Let me know if something does not make sense.

[PowderGoblin]

in addition to the above.
Here a sample situation.
When you zoom (Tz) and push the unit forward you may (depending on how careful you are holding it) get noise components which are both as Roll Forward and/or Spin.

To handle the intention correctly and prevent the camera from faithfully representing any twitch you have to have a way to recognize the intention.

Hope this adds to the above.

[jwick]

That's a very basic example. It doesn't tell you how to use the rotations. You need to use the angle along with the axis data.

A better example is the csmonitor example on the ftp site.

ftp:/ *** ***
login: ***
password: ***
subdir: TDxInput



Moderator Edit: the sample code is no longer available from the FTP service. Please contact 3Dconnexion API Support if you need further assistance.

[PowderGoblin]

Great - will check as soon as I get to a dev PC
Many thanks Jwick!

[PowderGoblin]

Thanks JWICK

Works like a charm.
Due to the different approach I had to rewrite the entire joystick handling - but the good news is that with your unit now the coding is much simpler and faster.

I still maintain that there is a large market for users wanting the unit to register as joystick out of the box.

However, for programmers there is absolutely no problem using your samples as-is.

If I may propose something. To put the whole C# issue on the shelve forever only three minor things will have to be done.
1. The current post named C# example has to be removed - it leads to a project which needs adjustments. If you are new these adjustments are tough to get right - you, naturally, think you are doing something wrong yourself.
2. Copy my step-by-step recipe on how to create a project of your own. Add to it explanation on where on the FTP site to find the two ready projects (the simpler and the one with calculating rotation).
3. Put the whole thing somewhere easy to find.

As it turns - you had all parts - we just have to serve them now

Other than that - the unit is phenomenal! I am dying to open it and see the sensors - this very smooth detection of micro-movements in such a small space - fascinating ... I want to know - where was it first developed!

Hey - btw ... how do I start the driver programmatically? Can it be done.
I used the code from the current examples but the unit seems to want to be started manually first. I know ... the setup of the drivers is such that it starts the drivers at start but I did not pick this option.

Many thanks again.

[jwick]

Other than that - the unit is phenomenal! I am dying to open it and see the sensors

That's definitely going to void your warranty

Hey - btw ... how do I start the driver programmatically? Can it be done.

The COM interface disables the autostart of the driver. Don't bother starting it on your own because it will run all the time in the next major release (even if you don't have a device attached--so it can handle hot plugging).

[PowderGoblin]

Ah ... warranty, shmarranty ... gimme the hammer

Got it - this closes the thread.
Thanks JWICK!