SFX-100 (SFX-150) driven by Odrive

First, thanks to this community that inspired me so many years ago to go down the rabbit hole that is motion simulation. I have been lurking around here for a long time and after several partial starts I finally got enough time to really make progress on adding motion to my rig.

First off, instead of building from scratch, I managed to pick up a full rig from someone local at a pretty good price so I started off with a basic sim and then have been working to add motion.

The base rig is a Sim-Lab TR1 (Team Redline) rig, with Simucube 2 wheel and Fanatech Clubsport V3 pedals, with Fanatech shifter, and handbrake. The seller didn't want it parted out and wanted it picked up in person so I got quite a deal on the full setup. This is mainly for racing but I hope to do some flying in the future. I have no experience with that though. This is all run by a PC with AMD Ryzen 9 5900X and an Nvidia GeForce RTX 3080 graphics card (that was quite a challenge to get back in mid 2021). I'm generally racing in VR using an HP Reverb G2 but also will roll a screen in front of my rig on a portable desk sometimes...it's not optimal FOV but works for the kids who are too young for VR and for a quick lap or two for me.

For the motion system I decided on using an SFX-100 concept but have been adapting it to use brushless motors and Odrive as the controller. I did this partially as a learning experience not necessarily because it's the cheapest or most ready-made option out there. It has been quite a learning experience for me and so far I the design is looking like it's going to work out quite well. I ran into EMI issues as expected but so far have beaten them back. I'm hoping to go farther by adding a CAN communication layer in the future but I'm not there yet.

The actuators are pretty standard SFX-100 design with a few modifications to make them 150 mm travel.

• 300 mm long ITEM 100x100 extrusion for the main housing since that was easier to source for me in the USA. (I also tapped the extrusion directly and used larger bolts as advised in the SFX-100 guide).
• Extended the hollow shaft to 320 mm to accommodate the extra travel.
• Extended ball screw to 300 mm to accommodate the extra travel.
• I modeled a new linear bearing mount to invert the linear bearing so that it fits inside for a more clean appearance and sits flush against the extrusion. I saw this mod somewhere else, I didn't come up with the idea.
• Driven by Odrive 3.6 56 Volt version - more details on this below.
• I (re)modeled ALL of the 3D printed components so that I have control over them as I wanted in Fusion 360 and I could manage tolerances and dimensions more directly than scaling someone else's finished models.

For Odrive, I started this journey when the Odrive 3.6 was still relatively new and just being proven by @SilentChill and his rig really was my inspiration for trying out BLDC linear actuators.

In contrast to some of the Odrive designs that I have seen here, I have just used the standard Odrive firmware (v 0.54). From what I have seen there doesn't seem to be a reason not to use the official firmware at this point (2023) as it has homing and end stop capabilities though I haven't added that into my setup just yet.

I'm currently using FlyPT Mover (shoutout to @pmvcda for contributing something amazing here). Without it I think I would be stuck. I'll add another post with details on the software setup but a quick teaser is that I'm not using the settings from the FlyPT mover website. Rather than giving commands in counts the current Odrive firmware expects position to be provided as the number of turns. This is easily accomplished in Mover by simply using basic math to covert the actuator position in mm to a number of turns. Again, I'll provide details and screenshots in a future update but so far this is all working quite well. I'm planning to dig in to Simtools soon enough but so far Mover has been working for me.

In a future post I'll include a more detailed BOM and costs. For now, here are a few drawings and some of the key components (this is definitely not a full list).

• 4x Flipsky 6374 (190 kV) motors (~$120 USD each)
• 2x Odrive 3.6 (v 0.54 firmware) - One sourced form OdriveRobotics, one from Flipsky (~$100 USD each)
• 1 Meanwell 48V 500W power supply - (~$110 USD)
• 4x CUI AMT102-V encoders - (~$40 including cabeles)

I have a basic test setup on my rig right now with only two actuators at the back and the front propped up. It's not very realistic but in this scenario even while supporting my full weight (195 lbs) and ~50% of the rigs weight I only pulled a max of ~30 W driving two actuators during test runs that were very poorly tuned and moving pretty aggressively. Much of the time my draw was only about 15 W according to my Kasa plug so I'm looking foward to seeing how the full system performs.





Yes, that's just common pine board attached to extrusion with a very much DIY approach to prove the concept but it made me convince myself that the approach should work so now I'm starting to build the other two actuators. I'll do a more detailed build log of those as I didn't really document the steps for the first two.

I have a question out to the community in THIS post looking for suggestions on how to extend my rig's extrusion frame so the actuators clear the frame better. Any thoughts are appreciated as I'm trying not to fully rebuild the frame base if I can avoid it.

Thanks to everyone who has contributed to my learning over the years and for inspiring me to get started and I look forward to sharing more details as this progresses.

Hi,
Interesting post ....about odrive
Can you give details about the calcul that you made into mover for the conversion counts to turn ?
Thanks

This is very nice. The flipsky + odrive is something I wanted to try but never got to. Would you mind sharing a video of a test run?

It's not so easy as it explained to use odrive directly with the original firmware ... .-) However there's many other solutions to use odrive easily.... If you want video test, you can watch my different thread based on odrive ;-)

@Will974 My apologies, after I set up this thread, I had a number of personal things come up that took me away from the project for a while and I didn't see your post.

Now that I got back to the project and building out the two additional actuators I got sucked into a bunch of troubleshooting as I couldn't duplicate the setup that I have with 2 new motors. After a couple of weeks of off and on playing with it and chatting with people on the Odrive Discord it looks like there's a hardware issue with my board. I bought my second board from a Chinese supplier and unfortunately, I have had little to no support from them and no response about replacing the faulty board so far. I'm stuck at the moment either buying a new board (probably from Odrive directly) or taking a chance with another cheaper supplier. As soon as I get a second board, I'll put everything back together and get some video and finish documenting the project.

Now, for your question about calculations.
In FlyPT mover I use the Rig actuator filtering to map the actuator position in mm to a number of turns which can be fed directly to ASCII output in the Serial output <P Axis 3a> for example.

I have a ball screw with 5mm pitch, so every turn is 5 mm of position or 1mm = 0.2 turns.
In actuator filtering I then apply REMAP(MUL(VALUE;0.2);-11;11;0;-22).

My zero position is with the actuator fully retracted so the mid-point is 55 mm extended which is 11 turns (55 x 0.2 = 11). Since my Odrive is set up with the encoder at zero when it's fully retracted and to account for the direction of motor turn, I then remap the -11 to 11 turns that Mover wants to output to zero to -22. That just offsets the coordinate system from having zero in the middle to zero at the top of the actuator and makes sure my direction of motion is correct. I could have flipped the direction in Odrive settings and probalby applied an encoder offset as an alternative but for now I'm just letting Mover do the remapping.

In testing I have the Odrive running trapezoidal control with 95 turns/sec/sec acceleration and deceleration with a max velocity of 110 mm/sec. That's pretty quick motion so I started playing with filtering in Mover but since I only have two actuators running right now, I didn't spend much time on tuning.

As soon as I get a working Odrive board I'll take the time to document everything and share screenshots and videos. Thanks for the interest and patience.

@theoptimisticcynic Thanks for this explanation. It looks a simple and efficient solution to use odrive directly. I have some experience in odrive use, that's why, i'm very interesting to follow your evolution. Indeed, not all chinese odrive is good . i already had some bad experience with ODESC ( same board than odrive) ... The best will be to stay with original odrive board but price is not cheap .
Your power supply looks small for your use. Only : 10,4 A ... it can explain the low speed that you have : 110 mm/s ? ( Theoricaly , you can add : (190 x 48) = 9120 tr/min 9120x(5mm/60) = 760 mm/s ) and other problems...

The power supply is relatively small and my original intent was to use one per Odrive board but for the moment it's working with just the single power supply. In my very limited testing so far the only thing that is really stressing the power supply is a crash. As I do more testing I'll provide some detail on the power draw.

I need to make a correction to my previous post though. I was moving too quickly and stated inaccurately that the trapezoidal control max velocity was 110 mm/sec. That parameter is actually 110 turns/second which translates into 550 mm/sec with my 1605 ball screw.

Now the fun begins.

Unfortunately the FlipSky team became completely unresponsive and I have yet to resolve my bad board issue with them. Based on this I can not recommend purchasing through them. I have had good luck with their motors, but the ODESC as they call it has not been a good experience and 0/1 worked. Despite the cost I went back to the original Odrive so that at least I could have confidence it it working and getting support if it didn't. I would love a lower cost supplier that's also reliable.

With that said, I finally received the new board and assembled everything and after a minor battle with EMI and needing some ferrite cores. (We'll ignore the time I lost due to a poor wiring job on my part). I got everything working for my first test run using Assetto Corsa and FlyPT Mover.

This is just an initial test with a monitor way off to the side as I normally use VR. I was driving around a track but was all over the place just trying to see how the rig responded. You can see braking and acceleration pretty well but I seem to have cut off my wheel but you can see roughly how I'm turning. This was a BMW M3 with lots of driving over curbs and braking/accelerating including in turns just to see how it all worked.

I'm now away for a few days for the holiday here in the US so won't be able to continue testing but I thought I would share my results here. I had previously downloaded an SFX-100 profile and used that as a baseline but I need to learn how to tune the motion. If you have any tips out there please let me know. I read through the documentation and found it challenging to translate the description into a method of tuning the motion to get a good feel. I'll make another post with Mover settings in the near future.

When the Odrives power on they search for the encoder index and then go into position control mode. In the video below you see the initial connection to them in Mover followed by my messing around driving a bit. I would love to hear first impressions!

Wow this looks amazing!

I am realy looking forward to build my own Sfx 100 system but i have so many questions ...

I am struggling to find the right extrusions... Kinetic discontinued the model. Item in the USA do something similar but you need to own a company... and i dont know if i should trust other stuff i see on chinese websites or Aliexpress...

I saw that the Simfeedback for arduino closed their discord so no more support and profiles... so we need to go with Thanos system?

I saw full kits ready to assemble with Thanos system on Aliexpress for 3046$ Canadian dollars (i am canadian) so i am wondering if i should go with that instead?

You did an amazing job! Have a great day

You could get any of these cheap Chinese actuator kits, but I would advise against the ones that say they include Thanos controller... read more why on my website...

Thanks
Thanos

@Rodg Well sorry that I missed this. I haven't been signed in for quite a while and didn't realize that anyone had engaged with the post. I do still owe a more comprehensive overview of the build details. The system has been pretty good but I still have EMI challenges occasionally and cutout if I have a bad crash but it's probably related to my settings.

I would definitely be skeptical of the clones on popular Chinese websites, at least for the electrical components. For mechanical items I think there are decent deals out there. If you are still looking for parts then I do have a contact at a Chinese manufacturer of components that I used. I'm sure they are on Alibaba and similar, but I bought bearings, balls screws, shaft couplers from them and I was very satisfied. I was referred to them by a member elsewhere.

I have not had a good experience with cheap boards from overseas. High failure rate and no tech support.

As for the SFX-100 rig, it works quite well. I purchased extrusion directly from ITEM just by contacting the regional distributor. I got them on the phone and explained that I was doing a one-off build and explained what I needed and they sent me a quote no problem so I'm surprised by the business requirement. I modified all of the 3D printed parts for my own design so I basically duplicated everything that you would download from the main SFX-100 website.

As for the interface, I'm driving my system off of 2 Odrive 3.6 boards controlled by FlyPT Mover so I didn't use Simfeedback. I do want to get Simtools working but I just haven't taken the time yet. Since the Odrives have a serial protocol built in there's no need for Arduino or other support boards. I'm considering shifting the rig to CANBUS for better stability but with proper cable shielding and routing it's manageable without.

Now that I'm back engaged I'll share more of the electronic setup. Sigh...I really should finalize my cables and enclosures. It's all still cobbled together in prototype form.

My friend, what an interesting project, I was researching how to make actuators like this but with hoverboard motors using a ball screw with a larger pitch, I believe it can achieve a sufficient linear displacement speed by sizing the correct spindle, however in this case I would like to use the odrive, xdrive, odesc boards with a single output, my biggest difficulty would be in configuring the odrive to communicate with simtools or flyPt Mover, do you have a link where I can search to better understand the odrive configuration? what do you say about using hoverboard motors? Here in my region they are much cheaper.

I don't have experience with hoverboard motors but the Odrive can definitely be used with them. The Odrive community documentation is pretty good but there are modifications needed to use hoverboard motors. The Discord is pretty active and helpful when you get into challenging situations. They are most helpful if you are using genuine hardware of course. There's a hoverboard motor setup section in their documentation so that's the best place to start and learn the basics.

As for communication, I have been using the Odrive with their out of the box serial communication protocol so setting it up was as simple as connecting the USB cable and using the FlyPT mover serial output and setting the right startup and output strings and COM ports. Since I'm using the filters to remap the output range of my rig and my zero point is offset from the way Mover normally works my range is a bit different than others. There may be a better way of accomplishing this, but it's working for now. The attached screenshot shows my Mover setup.

I'm still considering converting the rig over to CAN but would need to write some code to make that work so haven't tackled it.

it makes you want....

Just spotted this build and your project is almost identical to mine, I'm also using ODrive v3.6.

I've written some janky Python code as below to do the CANBUS conversion. Took a lot of fiddling and research, but it works pretty well now. I would comment out the 'debug' lines which print the axis and position when you run it for real.

In Mover, just set the Port and IP address for the 'UDP Output' the same as in the python code.

The output string is basic, you can add as many axis as you like, the Python code is dynamic for that.
Just need to set the CAN ID on the ODrive board for each axis.


I can't post links, but I'm using the Makerbase "MKS CANable V2.0 Pro" from AliExpress.

Code:

#import math
import can
import cantools

import socket

# Socket settings for UDP.  Should be set as UDP Output in Mover
UDP_IP = "127.0.0.1"
UDP_PORT = 5005

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.bind((UDP_IP, UDP_PORT))

# Define some minimum and maximum limits for safety.  Backup for min/max crop in Mover.
min_position = 0  #
max_position = 14 # Needs to align with max output of Mover.  14 turns = 14*5mm = 70mm


# Load the ODrive DBC file
db = cantools.database.load_file(".\odrive-cansimple.dbc")

# Define the can bus to use.  Check device manager for the COM port
bus = can.interface.Bus(bustype='slcan', channel='COM5', bitrate=250000)

while True:
    try:
        # Read UDP input
        udpdata, addr = sock.recvfrom(1024) # buffer size is 1024 bytes
        # print("received message: %s" % udpdata)
       
        print ("** ", end =" ")  #Start a new line of debug output, don't print a newline character.
       
        # Split the UDP message into array - split funtction useses newline delimiter
        axisdata_array = udpdata.split()
       
        #For each block of data in the array....
        for axisdata in axisdata_array:
           
            # Extract the relevant bytes for axisID          
            axisID_bytes = axisdata[0:1]
           
            # Convert axisID to an integer
            axisID = int(axisID_bytes)
           
            print (axisID, end =" ") #print the axisID value, but don't print a newline

            # Extract the relevant bytes for position
            position_bytes = axisdata[1:6]

            #Convert the position to a float
            position = float(position_bytes)
           
            #Set some safety limits
            if position < min_position:
                position = min_position
            elif position > max_position:
                position = max_position
               
           
            print (position, end =" ") #print the position value, but don't print a newline
           
            # Now try encoding and sending to the CAN BUS
            try:
                # Note that 'Axis0_Set_Input_Pos' below is agnostic as it's the same encoding for all axis
                data = db.encode_message('Axis0_Set_Input_Pos', {'Input_Pos':position, 'Vel_FF':0.0, 'Torque_FF':0.0})
               
                # The actual axis ID gets added to the CAN message here
                msg = can.Message(arbitration_id=axisID << 5 | 0x00C, data=data, is_extended_id=False)
               
                # Send it to the CAN bus!
                bus.send(msg)
               
            except Exception as error:
                # Failure to encode CAN message or sending to bus
                print ("Failure to encode CAN message or error sending to bus", error)
                pass #Keep going!
               
        print (" **")  # Finish the debug line of output
       
    except Exception as error:
        # UDP read failure
        print ("UDP read failure", error)
        pass #Keep going!

Forum won't let me edit, but the Mover output string is as below, with as many axis as you like.

Code:

1<PAxis1a><10>2<PAxis2a><10>3<PAxis3a><10>

Sorry for the delay on this one, I guess I missed the notification but @DaveH I really appreciate you sharing your code. I may play around a bit. The place I have my rig set up just has too many wires and my USB isolators don't seem to make a great connection and the slightest bump will kill my USB connection to the Odrives. I could probably tie up my cables and make it all more stable, but just haven't made it that far. Unfortunately where I route the cable for my VR headset is close enough that it sometimes bumps the USB hub or the isolator cable and lose connection. Just enough frustration for me to seek out another solution.

I have a couple of ESP32 boards laying around that I haven't touched and thought maybe it would be a fun exercise to turn it into a Bluetooth connection with CAN to the Odrives so that I simply can't bump the USB cable. Anyone have experience with Bluetooth? Concerns about latency?

I should probably play around with Python first.

I think bluetooth might introduce some latency. I've found CANBUS to be rock solid. I have issues with noise on the encoders and have to be really careful to keep the motor wires and encoder cables separate. But CANBUS doesn't care, it just works with zero issues so far.