Just discovered the oDrive. I have an application that could use smoother motion than I get with steppers, was looking at BLDC. AS compared to a stepper, that I have to leave powered up to hold a position, how does the Odrive work? I issue a command, assume via Text for now, to move to a position. It will hold there? Will the motor get hot form this hold like a stepper? Can the current be reduced while holding (maybe not necessary).
I understand the motor destination command is in turns. How are partial turns communicated, what is the resolution?
Thanks for any tips or pointers I should consider.
ODrive is a closed-loop servo driver with some motion planning capabilities. For your use case, if you are in position control mode, the motor will hold the position that you tell it to. For a perfect system with no load, the holding current is 0. The current required to hold a position depends entirely on your load, so if there is no load, there is very little current. If it’s holding a 50lb weight off the ground with a rope, the motor might warm up a bit.
The input_pos parameter is a floating point number. You can give it any valid float as an input (1.23456 for example). The resolution is dependent on your encoder - ODrive can’t do any better than 1 / <encoder cpr> [turns], where cpr is the resolution of your encoder.
For the step/direction interface, the parameter of interest is turns_per_step - this sets how many turns a step pulse corresponds to. By default, it’s 1/1024, so it takes 1024 step pulses for the commanded position to be 1 turn ahead of where it started.
Also - ODrive supports a few different input modes. One that is useful for smoothing out step/direction commands is the Filtered Position Mode described here: https://docs.odriverobotics.com/#other-control-modes.
Thank you. My application is basically a level, belt driven, X-Y system moving around an unchanging (weight) 50lb load. Once positioned, it’s stable, no load. So that’s great.
Now I understand the position parameter, thank you. I figured that was it, but wanted to be sure I understood.
No problem! One important difference with the ODrive vs a stepper motor is that it needs an absolute reference for the encoder position vs motor phases. In other words: with an incremental encoder, the motor has to move a bit on startup (to figure out “where it is”) before it can be put into closed loop control. With an absolute encoder, the drive can start and go.
The absolute encoders that we support use SPI for communications, which requires some special care with regard to noise. Incremental encoders are more robust.
My device will have a long cable from the control to the Y axis. so SPI noise may be problematic, dunno. Cable will be over 12 feet. When you say “move a bit”, can you elaborate on “a bit”. 2 encoder steps, 2 revolutions of the motor, how much? I need to know if I need to plan for a vibration at my tool or a move that must be dealt with to prevent a crash.
I need to read up on encoders, I’ve only ever used plain step motors and encoders are new to me. I appreciate you sharing that detail.
If you use an incremental encoder without an index, the motor will have to move roughly 2 revolutions to calibrate the offset between the encoder and motor phases. With an incremental encoder that has an index pin, like the AMT102-V in the store, the motor only has to rotate until the index position is hit. That will always be less than 1 whole revolution.
For your application, something like a CNC xy gantry, the startup sequence might look like this:
If the gantry is in a position where an axis would crash during encoder calibration, manually move it towards the middle of the range of the axes
Turn on machine, ODrives not set to closed loop control on startup
Use an Arduino or similar device to send the command for encoder calibration and then the command to enable closed-loop control
Proceed with step and direction commands just like a stepper-driven setup.
This only happens at the Odrive board’s power-up, right? What happens if the BLDC motor can’t move, due to machine limits, I assume it’s gonna keep trying. A stepper would just give that horrible lost step noise, while it applies a lot of force. I have no experience with the BLDC.
In the case of a machine limit being reached, is there any way to trigger a limit switch and have ti try to calibrate in the other direction? Or at the least cause a reset/stop.
ODrive does support some limit switch functionality, but I’m not sure if it’s integrated into the calibration sequence. If the motor hits a limit during calibration, the ODrive will just error out and stop. The calibration doesn’t happen automatically on startup unless you configure the ODrive to do so, so the comments about the Arduino are a way for you to have some control over that process based on if the machine is ready for calibration or not.
When the axis attempts to find the index pin, it would run into the limit switch which is connected to the Encoder Z pin on the Odrive. The ODrive thinks this is the index from the encoder. This works as long as the relative position between the motor angle and homing switch never changes (i.e. no belt slippage)
Ah. I think I get it now. And I’d wire in parallel so if the system did a startup away from the switch it would find the index pin first and that becomes it’s reference. But if it hit he limit switch subsequently, it would think it was off track and that could be a problem.
The device I’m moving is a 3rd party machine, I have limited control over it directly. It has 3 states, 1. engaged (with workpiece) and idle, 2. disengaged and idle, and 3. ready to operate upon movement (engaged). So, it could be in the worst case which is engaged but idle state, at startup, so that fact may make using the BLDC a non-starter anyway. Unless I can find a way to ensure it is in a disengaged state before this required homing routine, which may not be possible.
Assuming I cannot mechanically detect the engaged state, if the system does a worst case 99% turn to a index point, something will break or be damaged. So that’s no good. Unless the system can operate at very low torque for this startup routine? I mean low enough that it would slip with the tinyest of resistance and fail initialization if the state was engaged. Possible?
You want to use one or the other, not in parallel. It should always hit the reference at the exact same electrical angle every time.
The torque needed is surprisingly high during the “lockin” movement, actually. It sounds like you need an absolute encoder, though, if it can’t move a little bit during startup. We are working on a solution that should work for long-distance (your 12 foot wire won’t be a problem) encoder setups. You’ll just need an ethernet cable.
I can make a CAT6 shielded cable, not problem. That, I know how to do LOL. But I thought the absolute encoder needed a couple of revolutions for startup, worse in my case than the indexed encoder.
From above: 'If you use an incremental encoder without an index, the motor will have to move roughly 2 revolutions to calibrate the offset between the encoder and motor phases. "
My bad there, I might not have been clear when I said that. There are three good options: Incremental encoder without index signal (worst case for amount of motion required before the motors will accept commands), incremental encoder with index signal (less movement), absolute encoder (no movement).
Thanks guys. Yes I missed the absolute encoder as a no move option. Had to go look up the differences but now I understand. And boy are they proud of those encoders LOL. ($$$) Have any recommendations for one similar to your CUI indexed encoder?
Unfortunately all of the encoder options that work with ODrive natively are susceptible to noise, except the one we’re putting together. What’s your timeline?