Hi All, I’m looking for some feedback on suitability of ODrive components for a design I want to make.
The challenge is that I need 3Nm of torque at the handle of a force feedback knob to overcome friction and variable user input, and I need to position the knob with 0.005 revolution (1.8deg) precision.
I’ve done a first iteration with a Moteus BLDC motor and 4:1 pulley but it didn’t go well. The controller couldn’t overcome friction (high torque) and control very low velocity well at the same time (e.g. moving from 0.0 to 1.8 degrees). The flex in the pulley didn’t help either.
The ODrive motors have enough torque to directly drive without a pulley, have way lower kV (lower velocity) and the controllers appear to have a low speed mode (though I don’t understand it fully) so I’m considering making the investment.
Thanks in advance!
Andy
ODrive can do this particularly with anticogging enabled for that low speed precision.
Agreed with Paul on the feasibility. You can definitely try the S1+8325s start kit. The only concern I’d possibly have is with the S1’s onboard encoder’s noise and resolution limiting the fine grained force feedback you can get, but adding an external high-resolution incremental encoder would be quite easy. You could also use the S1 + 6374 + AMT21 (16384 CPR RS485 encoder), though that’ll take a bit of 3d printing to set up.
Hi All,
Thanks for the input!
I read about the anti-cogging and it looks straight forward to do. I’m curious to try doing that calibration and then running the motor with just FF to see just how smooth (cogless) the system is when turned by hand with no position control going on.
The D5065 motor with dual shafts for easy encoder mounting sure looks nice to use. It has lower torque but it might be ok to use its peak torque for haptic feedback since it will spend a lot of time just sitting and cooling off.
I’m going to order some goodies and see what happens!
Andy
I got the D5065 and AMT21 up and running with the S1 after printing the NEMA housing for the motor. What a sweet system ODrive is! Out of the box using the GUI I was up and running in minutes and the default parameters for the motor provided very good velocity control as well as incremental positioning performance.
Setting up the anti-cogging was easy after reading all of the docs on absolute reference. It makes the big motor feel like a much smaller motor when in Torque Mode with target torque set to 0 and it makes it possible to handle the fine position resolution.
After a bit of tuning the position control parameters I was able to get 0.001 rev resolution on my position with sub-second settling time even with a load that requires the full torque of the motor.
Thanks all!
1 Like
Super super glad to hear that’s all working out! Very impressive, would love to see some pictures if you’re willing to share!
Hopefully I can get the setup cleaned up and packaged nicely for a photo-worthy moment!
Update and question about static-to-dynamic friction and ramping down torque after positioning:
I realize that this is very specific to my setup and I need to address some mechanics, but I’m throwing this out in case others have addressed similar things before or do in the future.
I’ve got quite a few hours into tuning the system here and running it in our demo room. My setup has a friction drag element to make the motor and haptic feedback wheel not spin completely freely. At first I tried using the motor to provide a electromagnetic resistance to rotation when haptic feedback was not active but the character of the feel was not consistent and smooth.
Over time and cycles my mechanical assembly has developed a bit of “stiction” or increased static friction to dynamic friction ratio as things have worn together. This has of course caused issues for the position control loop because after the static friction “breaks” there’s a bunch of torque built up that causes the velocity to spike and position to overshoot…this I have mostly tolerated with tuning and using my application controller (Adafruit Feather RP2040 CAN) to change FF parameters based on how far and what direction I’m moving. Likewise when velocity gets low enough static friction kicks in again and stops the motor before its exactly in position…in this case the gains of the controller and the small position error are not enough to make the motor move and overcome the resistance, which from a positioning standpoint is ok. However, when I switch the controller to Idle from Closed Loop so the user can freely turn the motor there is a loud clunk as the torque quickly goes to zero and the system relaxes. I’ve tried reading the torque_estimate at the moment I want to go to Idle, switching to Torque Control and ramping down the torque over 100 or so milliseconds, but its inconsistent and mostly ineffective.
I’ve run out of ideas on how to use inexpensive software to overcome my expensive hardware limitations so I’m looking for some new drag solutions like a wet brake of sorts. If anyone has thoughts on how to better leverage ODrive for these different challenge points I’m all ears!
Thanks all,
Andy
Hi! It feels like there may be a bit of an xy problem here, especially if we’re starting to talk about friction brakes and wet brakes and everything – definitely want to make sure we’re on the right path in the first place.
Would you mind giving as much detail as possible as to your application / end use case, mechanical setup, desired functionality, operating modes, etc? Just super basic concept of operations so I can make sure I’m fully understanding the desired end outcome and am able to recommend possible paths of action. Pictures/a video if possible would be super super helpful!
Generally the ODrive can provide quite accurate force feedback and dynamic braking – we have users using it for force feedback racing wheels, so that’s definitely a known-good application, and robot proprioception falls into much the same category, so this feels like it may be a matter of figuring out the best way to utilize the ODrive.
Hi Solomon,
Yeah, the friction element is a complication. It was added because the system was too easy to turn giving it a non-realistic feel but now its becoming a liability.
I’m away from my lab for a few days, but the mechanical stackup is this: a D5065 in the 3D printed NMEA23 frame with the RS485 encoder on the rear and a pulley on the front. The pulley has a belt going to the shaft of the force feedback wheel, and the pulley gives a 2:1 gear reduction. The motor housing is on a pivot so the belt can be well tensioned. The ODrive uses the RS485 motor shaft encoder for control, but for diagnostics I put a magnet on the end of the wheel shaft and an AS5600 encoder positioned next to it so I can read the exact position of the wheel (with my RP2040 controller, not with ODrive). There is less than 0.001 revolutions of play between the motor and the output shaft during motion, but when the motor is fighting static friction before the output shaft moves it can be almost 0.002 rev. This wind-up in the system I think is whats causing the motor to snap back when torque is sudden disengaged.
The output shaft is where I installed a metal disk, and built off of the frame of the system is a friction pad that contacts the disk (with a spring and set screw to adjust pressure) to make the shaft not spin freely. This is where the “stiction” issue is coming from. If I could apply a constant and smooth drag force to the shaft using the motor that would allow me to remove this mechanical element. I’m curious about what ODrive strategies others have used to add resistance without having a spring back or “return to center” effect.
There are two modes that this system operates in. First is non-feedback mode where the user can turn the input shaft as desired, this mode is where that drag friction is important. Second is the haptic mode where the motor can oppose the user and/or position the shaft as appropriate for what is happening in the higher-level system…in this case the shaft may be moved in tiny increments (like 0.0025 revs) or moved coarsely to any part of the logical travel range. In the second case the drag friction is unnecessary and complicates the control system since it can’t be turned off.
Hi there! My apologies for the delay in my response.
If I could apply a constant and smooth drag force to the shaft using the motor that would allow me to remove this mechanical element
Yes, this is quite straightforward. Put the ODrive in velocity mode, set vel_integrator_gain to zero, and set input_vel to zero. Then the ODrive will emulate a viscous friction element with a coefficient of vel_gain (N/m)/(rev/s). You can try enabling bEMF_FF for even better performance. The “spring back” / “return to center” is likely caused by the velocity integrator – set vel_integrator_gain to zero to disable this.
Haptic mode definitely depends on what exact functionality you want. Position mode with a vel_integrator_gain of zero will emulate a spring around a point, which is nice for detents, or you can just use torque mode with an outer controller/loop on the RP2040.
Hi Solomon, thanks for that! I’m going to try that this week and ditch the mechanical stuff…fingers crossed!
Andy
Best of luck! One thing to note is that bEMF_FF_enable requires a pretty accurate motor KV value for full effectiveness. One way to tune:
- If you zero the
vel_gain and vel_integrator_gain then put the motor in closed loop (velocity control), try moving the wheel by hand. If it feels like the motor is providing some drag (more than it would when turned off), increase the motor’s KV value in the ODrive (well, here it would be torque_constant = 8.27/KV). If it feels like the motor is providing extra force in the direction you move the wheel, decrease the motor’s KV value.
1 Like