Position sensor data.

[sergey]

Hello!

I am using C#. I want to try using SpaceMouse as a sensor. I don't need physical postprocessing of camera paradigm. I need to get 6DOF data. After that I want to do my own postprocessing taking into account my mathematical model. I don't need to rotate any camera. I don't need to get data from any paradigm. I need real device data.

I saw threads about RAW data on this forum, but they were linking to an old SDK. On the 3Dconnexion website page only the latest SDK is available for download. I can't find links to older versions of the SDK.

Please tell me how things are going with a simple short example of reading SpaceMouse moving and rotation data in 2025? Where can I download a C# library that will give specific 6DOF values?

[ngomes]

Are you referring perhaps to Microsoft's Raw Input API?

I do not recall if we have a C# demo program but we may still have some C++ code that shows how to use the Raw Input API to decode the SpaceMouse data. You will want to reach out to the API Support team (contact details here, registration is needed).

[sergey]

Hello! Thanks for replying to my message. After two days of struggling with the new paradigm, I just got the desired result using a third-party development on github. The repository is called DMXControl/3Dconnexion-driver. So I had to abandon the idea of ​​using the official SDK, because I could not find either a point to read data from the input device, or a point to assign any coordinates to the 3DxTestNL example program. By the way, 3DxTestNL is the only example program that compiled and then showed at least one moving point on the screen.

To use the DMXControl/3Dconnexion-driver repository from github, you need to compile it, and then add a reference to the resulting dll to your project.

After that, create a Button, TextBox and Label on the form. Paste the lines into the button handler and add the rest of the operators and functions from this text. There is nothing else to do. This is a complete working example.

I got "Msg==49646" from the debugger. You can comment out the "If(...)" line if the program won't work.

Code: Select all

        using _3DconnexionDriver;

        _3DconnexionDriver._3DconnexionDevice dev = null;
		
        private void button1_Click(object sender, EventArgs e)
        {
            dev = new _3DconnexionDevice("myOwnNewApp");

            dev.Motion += new EventHandler<_3DconnexionDriver.MotionEventArgs>(OnMotion);
            dev.ZeroPoint += new EventHandler(OnZeroPoint);

            dev.InitDevice(this.Handle);
        }
        protected override void WndProc(ref Message m)
        {
            base.WndProc(ref m);
            if (m.Msg == 49646)
            {
                if (dev != null)
                {
                    dev.ProcessWindowMessage(m.Msg, m.WParam, m.LParam);
                }
            }
        }
        private void OnMotion(object sender, _3DconnexionDriver.MotionEventArgs e)
        {
            textBox1.Invoke(new Action(() =>
            {
                textBox1.Text =
                    e.TX.ToString() + "\r\n" +
                    e.TY.ToString() + "\r\n" +
                    e.TZ.ToString() + "\r\n" +
                    e.RX.ToString() + "\r\n" +
                    e.RY.ToString() + "\r\n" +
                    e.RZ.ToString() + "\r\n";
            }));
        }
        private void OnZeroPoint(object sender, EventArgs e)
        {
            label1.Invoke(new Action(() =>
            {
                label1.Text = DateTime.Now.ToString();
            }));
        }

[jwick]

That's nice. It should work.
I assume it reads directly from the system.

I do have a C# example if you want it. It also reads directly from the system. It shows how to find and handle multiple devices.
I probably also have a C# example of how to use our API with C#.

The difference between going directly to the system and using our API:
1) Our API insulates you from device changes. With the system API, you need to do more work to support different devices. Especially when we release a new device.
2) Our API does some optimization to prevent motion overrun if your application is running at a slower rate than the device is sending data. This, though, means, you are probably not getting exactly the raw data from the user's hand. It is filtered.
3) You need to install our software to run use our API. With the system APIs, you don't need to install our software--just plug the device in. If you don't install our software, users don't have an external way to make modifications to the data (scale/filter), nor assign a wide variety of actions to the buttons.

[sergey]

Hello, I am a little surprised by your company's policy. I read messages on your forum, which are several years old, where some programmers ask you for a 5-line example to read data from a device. As far as I can tell, your API still does not have this functionality. Developers have to reverse engineer and write their own low-level libraries. Your management decided to limit the scope of your devices. According to your paradigm, all users must use the readable handle positions as velocities always. At the same time, the data should be integrated in an inertial-free and filtered world that does not have physics. If you gave people the ability to do the calculations they need, the scope of your devices would be much wider. For example, I do not work with the integration of the handle position at all, I do not need it. The only action with the data that I need to do is to divide the range of possible values ​​[-3000..3000] by 30. Thank you for making a wonderful input device.

[jwick]

Would you mind telling me what you are doing with the device?
Is it an industrial application? Yet run on Windows?

I agree that you should be able to access the raw data through our new API. Help me make a case internally.

ATM, the most data raw API is one of the Microsoft APIs. They are relatively easy to use. And the driver works with them (if it is told to). In fact, our driver uses them to get the data.

Now that I think about it, the majority of the functionality of the driver comes from handling all those variations of buttons. The cap is the mostly same (ATM) from device to device, so you could probably handle that yourself outside the driver.

I can also send you our old SDK. That is another API to learn, though it is as simple as I could make it. It is fully supported since it is underneath the new API.

The raw device axis data is, and has for quite some time, been linear in the +/-350 range. Software scales and warps that for human usage. This is good for most graphical applications, which is the majority of our users. Unless your usage is completely tied down, you can never rely on that [-3000,3000] you might be seeing today because users can install software to change it.

While it is quite sensitive, it isn't a laboratory device. The mechanism has its own quirks. E.g., the axes affect each other when you get toward the edges of the movement.

[sergey]

Hello. At the moment I do not use SpaceMouse for industrial purposes. I took one of these old joysticks from one friend to show some of my other friends how to use it in their project. My friends want to try out the control with this device. After testing it, they may or may not be interested in this method. Their project requires smooth control of the manipulator tip. That is, we are talking about manual mode, about direct copying of positioning without the integration operation.

Thank you for warning me about the nonlinear behavior of the sensors and the undefined limit of values. I have already paid attention to this, but I will add strict restrictions to the program.

I tried to find the coordinates [x, y, z, rx, ry, rz] of the joystick position in the SDK from your site, but the downloadable package does not contain examples of using the low-level API for C#. In addition, the documentation that is in the archive is practically useless, since it contains only function signatures without explanation of the parameters and without description of how to use them. You can register for a developer on your site yourself, download the archive and make sure that the downloaded SDK practically does not allow you to use it.

A programmer can use a library when there is a good description for it, but you don't have one at all.

About low-level access to USB. I understand that all devices work through drivers, but in relation to your device, you do not provide any documentation on this issue. Register for developers and make sure of this.

[jwick]

I'll email a C# package to you.