We presently use a driving simulator built on Blender and ROS in Ubuntu with the Logitech G29 gaming wheel. We want to replace the G29 with Simucube 2 Pro to increase the fidelity. We should be able to read steering commands from the wheelbase and give torque commands to it. Is there any way to do this?
The USB Physical interface device API is the same for both when used via some FFB library.
However, at the moment, there is an incompatibility issue for Linux - there are some USB effect descriptor fields that are missing that the kernel expects, and thus will not allow device detection. When we add those field to the device, the Microsoft HID driver stops working on Windows, therefore we are not adding those fields. You would have to patch the Linux kernel drivers to remove the requirement for the missing descriptor fields.
Also our True Drive device configuration software has not been compiled for Linux.
So the patch might help Ubuntu in detecting the wheelbase, and I should be able to interact with the wheelbase (like reading steering inputs and giving the torque commands) via ROS using the FFB library.
Do you have the list of descriptor fields that conflict between Windows and Ubuntu? Are you looking to compile the software for Linux in the future? Do I need True Drive device configuration I’m using ROS or something to else to read the signals and command torque?
We have a list somewhere, but no promises that the list would be complete.
Yes, when there are sufficient use cases for it, to warrant the extra effort to maintain it (which is not insignificant).
You would need some way to enable the High Torque Mode at device start, if you want to use full capabilities of the device. True Drive is not needed otherwise to operate the device - you could set the default configuration that gets loaded at startup with Windows.
That’s great. We have decided to go ahead with Simucube 2 Pro. We are planning to proceed as
Step 1: Develop a patch to make Linux detect Simucube 2 Pro.
Step 2: Develop an algorithm to compute FFB on the steering wheel.
Step 3: Communicate the FFB to the steering wheel.
We might need your help in executing steps 1 and 2. Could you provide us the list of descriptor fields that conflict between Windows and Linux?
In fact, I just tested the Linux things on Friday.
Notes:
We can add the missing fields to the interface descriptor, js0 interface is available, no warnings in /sys/log/syslog
We can compile the PC software for Linux, and superficially it works. However the HIDraw interface we are using via Hidapi library, is heavily buffered, so not all configuration software functions work as expected (some functions will time out from time to time due to buffering issues).
Linux Joystick (old classic interface) seems to expect -32767…+32768 (16 bit signed) range for the first two axises. At least the jstest-gtk software was not able to calibrate the joystick properly. Simucube uses 0…65535 (16 bit unsigned) range.
– Fixing this would need more investigations and changes to at least the device firmware, USB interface descriptor, PC software, and some testing.
There is a new interface - a more modern evdev-based interface for joysticks as well. We could not find any test software to see if it would accept 16 bit unsigned range for axises.
We can (maybe) compile the PC software for Linux, but not until September at the earliest due to huge work backlog and upcoming summer holidays.
Updating via Windows software would not be possible anymore, and updating with the Linux software would require testing and verification.
Regarding Linux FFB support, many people have just used our IONICUBE (or Simucube 1 with just the bootloader installed, no firmware) and implemented their own FFB interface via our SimplemotionV2 API. This means to give torque commands directly to the servo drive via the other USB port on Simucube 1.
I want to develop the interface with Linux. I can share the code once it’s working or along the development process.What do you think is the best way to start with?
The stuff required to be changed is mostly not in the open source codes.
If you can,please try to find out if the evdev interface expects 0…65535 or -32767-+32768 range for x and y sides. I could not find any test software for that.
Part of the firmware is open source, but the USB related parts including the device interface descriptor, is not open source.
The “old” js interface in Linux seems to expect x and y axises to have signed 16 bit range, and Simucube has unsigned range for these. So it was impossible to calibrate axises.
The new interface is the evdev interface, but no joystick testing tools that I could find for that. It would be great if we would not have to change the firmware.