Idea: Direct Drive Sim Racing Wheel

Hi there,

has anyone looked into using oDrive to build a “Direct Drive Sim Racing Wheel”?

There are a couple of great DIY projects around using Granite Devices Argon/simuCube and Ioni servo drivers. The quality (fidelity and smoothness) seems to be very good. The price tag or servo driver and servo is around €650,-.


https://granitedevices.com/wiki/About_SimuCUBE

Would it be possible to use oDrive as a replacement for Argon/simuCube + Ioni and source a less expensive brushless motor without sacrificing quality?

Regards

-jay

I think ODrive should be capable to run a racing wheel simulator very well. We may need some firmware tweaks to get it to interface nicely with whatever simulation software is running on the PC, but in terms of motor control it should work as well as an industrial drive.

One thing that may be worth spending some money on is to get a motor with low cogging torque, since that will probably be quite noticeable in a haptics application like this. We do have the experimental anti-cogging implementation, and it will be interesting to see what that can do once it matures. But yeah a better motor will still be better.

Hi @madcowswe ,

thank you for your reply.

There is some software/hardware combo to interface the simulation SW on the PC to a servo driver.
https://forum.virtualracing.org/showthread.php/92420-DIY-USB-Force-Feedback-Controller
The site is in german, sorry.

This SW uses an STM32F407Discovery board as interface to the PC and the simulation. The HW/SW combo registers as a HID on the PC. It processes the force feedback information from the simulation for the steering wheel and transforms it to either of three output modes:

  • mode 1: PWM 0-50-100%
  • mode 2: PWM & Dir
  • mode 3: 4 x PWM for H-Bridge
    Can one of this output modes be used by oDrive?

You are absolutely right about the cogging. That’s a major issue to get a smooth movement. Any ideas on what motor to use? What would be a sensible choice considering cost, smoothness and fidelity? (The torque people are achieving with the builds stated in my original post is 15-20Nm. But around 10Nm would be plenty I guess.)
Yeah, and the anti-cogging implementation would improve the haptics.

Kind Regards

-jay

There are two options: One would be to use the ODrive’s usb connection directly, and interface it to the simulation program. Otherwise, you can use Mode 1 once we finish the correpsonding feature.

For that kind of torque, the hoverboard wheels are pretty good option, and they’re not even that coggy.

This seems to be a very good idea! I have read some documentation, and it seems that it could be used with the standard firmware, Hope somebody can help confirm a couple of things:

  • If using the ASCII protocol, I suppose we can give the current command with decimals? (Float/string value)

  • Is it possible to read the encoder value with ASCII protocol?

  • Setting up the drive parameters encoder ppr etc is done with only with the Odrive tool?

  • The Native protocol would be preferable, but I’m not sure if i can do the above operations without CRC16?(Don’t want to waste CPU time for that in the arduino…)

  • An alternative is to control the torque with PWM and direction, but function isn’t yet implemented, but how soon can we expect that function? Update: Seems like it is included in the latest release, but just RC PWM. We need 0-100% duty cycle PWM controlling the current.

I’ve had the same idea of using ODrive to do a FFB steering wheel.
I’ve got Mige 130ST-M100-10 BLDC motor, but I didn’t manage to make it work with ODrive.
It seems that the current fw doesn’t handle that kind of resistance/inductance.

Concerning the direct input side, I know how to do a fw (I’ve done one on a Arduino Leonardo, and I’m working on the adaptation to other boards). What would be needed is either a high speed serial communication between the game device board and the ODrive, to send the torque and retrieve the encoder position, or it could be done with PWM and encoder signal decoding, but that would not be the best way. The PWM needs to be much higher frequency than a RC signal though.

You must be the “Aiwave” Eitenne right? :grinning:

Yes I am :sunglasses: