Hi
It is possible, because I’ve seen it done before.
But I don’t know by hard how
Cheers
On principale I don’t see why it wouldn’t work.
Just introduce your gear reduction ratio on odrv0.axis0.encoder.config.cpr and that’s it I guess.
Warning: I never tried myself.
Second warning: you should really severely torture test your setup before actually using it.
Because when the mechanical connection is lost between the encoder and motor movements, thing can go super wrong. That’s why i would keep the encoder as close as possible from the motor shaft. Since you’re not allowed to share details, I would be even more careful (in other words I wouldn’t do it)
Thanks for your answers and advices.
In any case ( if all goes well ), I will do it and test it.
I will make the design compatible with a 3.75 and 4 reduction ratio.
By now, I am not sure that the latest version of oDrive will accept a floating point value for the reduction ratio in odrv0.axis0.encoder.config.cpr. (I still need to get a board or dig into the firmware).
Note : in my case, if the mechanical connection is lost between the motor and the encoder nothing wrong can happen except crazy rotations of the motor which is not a safety issue.
Cheers,
Hi
I don’t think it’s that simple, the motor will only do one rotation to reach the cpr value, after that it spits out an error if it is not reached.
Cheers
Good remark. Thanks.
In this particular design, the driven shaft is only moving +90° to -90°, meaning less than two revolutions for the motor with a 4:1 reduction ratio.
In this case, I will need to modify the firmware to let the motor rotate for two rotations until reaching the cpr value.
or to choose another option than oDrive (e.g. stepper motor) if this does not work.
Sorry not to give more details, but that’s out of my control.
Cheers
Hi @jct, your question was clear from your first post, and it’s a great question.
The simple way would be to scale your cpr from 8192 (= ppr x4), to a new effective value. However, as you guessed, this must be an integer. In your case:
8192/3.75 = 2184.53333333
So that doesn’t work.
We have more options though. We can scale the pole-pairs and the effective cpr together. You can imagine that we form a virtual motor where we go around the physical motor twice, and we say that’s one virtual turn. In that case we scale the pole-pairs and the cpr up by factor two.
In fact, we can scale both together by any factor, as long as the resulting pole-pairs and cpr are both integers.
k * cpr_{effective} = cpr_{scaled} = \text{Integer}
k * pp = pp_{scaled} = \text{Integer}
I asked Wolfram Alpha to find the factors of your effective CPR, and it found this:
Therefore, i think you can use k = 15, and hence set your scaled CPR to 32769, and your scaled pole pairs to the physical pole pairs times 15.
3 Likes
Or use the 4:1 ratio gear, which may be simpler, but more expensive 
Hi,
Thanks a lot for your clear explanations.
After reviewing the overall design and taking into account that in fact GT2 15T/60T pulleys are readily available from some providers, I will use the 4:1 gear ratio.
In any case, it is very useful to know that other ratios are possible.
Impatient to get an oDrive board for testing !
Cheers,
very interesting! thanks
Sorry to revive this old thread, but I think this element that I want to discuss may be interesting not just to me in the context of this overall topic.
The concept of placing the encoder further along a transmission chain (away from the motor) is interesting because it places the position feedback closer to the final element or end effector, which is where we would most of the time wish to have the most certainty in positioning. We can already see however that backlash would in many cases lead to problematic behavior of the system.
If we assume an ideal, backlash-free speed-reducing transmission with a total reduction ratio that is an integer to properly multiply the polepairs for the ODrive to be able to commutate the motor normally, there would theoretically be no problems. However, no transmission is perfect and while we may be able to achieve a zero-backlash system, we may not be able to achieve a perfect scale-down of cyclic motion or velocity profile. In other words, there may be some unevenness in the elements of the transmission that leads to waviness in motion profile, causing motor commutation (magnetic sequence) and encoder counts to not always be in the same sync and ratio.
One illustrative example is this: We construct a single-stage roller chain speed-reduction transmission with a small chain sprocket directly attached to the motor and a large chain sprocket attached to the rotating end effector, where the encoder is mounted. We then mount a second, identical sprocket next to each respective sprocket of the transmission and use two identical chains and construct the sprocket hubs in such a way that the second (parallel) path’s sprockets can be rotationally offset in such a way that any backlash is taken out of the system by preloading the chains against each other and letting elastic averaging and chain tensioning do the rest (mechanical design needs to have purposefully chosen compliance characteristics in all elements, I do not necessarily recommend this sort of design but it illustrates the point).
If we consider the backlash to now be eliminated, we still encounter a problem: Roller chains exhibit a characteristic called chordal action or ‘polygon effect’ that leads to a (cyclic) acceleration and deceleration as one sprocket tooth is advanced. The roller chain is not a constant velocity system.
The question is now how much error the ODrive is able to tolerate when it comes to this sort of “wow and flutter” difference between magnetic phase sequence and encoder pulse feedback. This problem may actually to a certain extent be comparable to a poorly constructed motor.
Any thoughts on this are greatly appreciated.
I think it is interesting too as I have no idea if a PID is able to correct for hysterese / backlash error “down the line” or that it would require additional feed forward?
I don’t think that elasticity or unbalance is a problem, though and PID should work: the Odrive does not try to keep the rotation of the motor aligned it is sending currents to the motor to try and get it to move to the right encoder position, not rotor position.
But then I just ordered my Odrive and have to digg into the software that’s running on it 
As long as the polygon effect means that the peak error of motor position (as seen by the encoder) is 15 degrees electrical or less, the commutation should be okay.
What does “Okay” mean in this context? Is there an impact on efficiency / torque production?
I’ve never heard of the “polygon effect” in the context of field-oriented control of motors before. I can only find it in the context of gears and chain-sprocket wheels. What is it?
I suppose the drive is doing a linear interpolation along a discretely sampled sinus, and that’s what you mean by polygon effect?
Where can I find such info Madcowswe? That is really good info.
madcowswe was referring to my question, where I talk of a distant encoder that is driven by an encoder-less BLDC motor via a roller chain, so you are correct, we are indeed talking of chain sprockets. You could also change the question and ask what would happen if you had out-of-round or poorly manufactured timing belt pulleys that exhibit a cyclic error in transferred velocity and mounted the encoder on these pulleys instead of the motor.
Sounds like a recipe for disaster, tbh! Why wouldn’t you put the encoder on the motor? Or have two encoders, the motor one being used for commutation and velocity, and the load one used for position feedback only…
Also a single remote encoder would mean you cannot use any gearing on the motor, wouldn’t it?
Please read my post, it is all described in there. This is a thought experiment. If we had an ideal transmission that has infinite stiffness, no error in velocity scaling and no backlash, there would be no disaster as the transmission would act like a mechanical ‘scaler’ of the three-phase synchronous motor where the motor’s electrical revolutions needed for one geometric revolution would be multiplied by an integer that is the ratio of the transmission. Of course I completely agree with you that a “commutation encoder” and an encoder at the end effector would be ideal as is implemented in the RazorsEdge branch (sorry, I suppose ‘devel’) from what I understand, but I wanted to try and evaluate what the limits are because the dual encoders would of course use up the second channel. The point for me seems to be finding the sweet spot and figure out where this concept of a single encoder at the end effector (final output after gear reduction) falls apart, which I find interesting. A DC servo system may be advantaged in this specific thought experiment as it has no commutation demands from the controller side.
Again, I was specifically speaking of high-stiffness zero-backlash transmissions with waviness in motion and velocity scaling. This may be very interesting to explore because rotary transmissions that have high stiffness, are able to sustain very high torques, have zero backlash, are positively engaged and fixed with no slippage (no walking or drifting as with flat belts for example) and have very accurate scaling of movement are very expensive and often difficult to obtain as we are looking at flexspline (“harmonic drive”) reducers and rolling element (ball-gear) worm drive systems or other obscure solutions. If we remove the need for the immense accuracy in velocity scaling (and making it somewhat irrelevant by placing the master encoder at the end of the reduction chain), we may be able to achieve all the other aforementioned characteristics with a cost-effective transmission.
edit
PS: This all is, if we break it down, a thought that aims to ask the question if we can avoid ultra-low tolerance mechanical elements that are low-volume and/or specialty parts. Of course nothing is free and it means that a very good and high-resolution encoder will most likely be needed at the end effector.
Ah sorry, I should RTF(P?).
But perhaps you should have started a new thread, and simply linked to this one 
True in the current implementation, but it’s something I’d consider as almost a bug, or at least a bizarre limitation. There is no good reason for dual encoders to need to use up two channels when using SPI encoders, or a combination of SPI and incremental.
Harmonic drives do NOT have high stiffness, having worked with them considerably in the past, they are like having a large clock-spring in series with a high-reduction gearbox. The flex spline flexes a lot, including in torsion. We even used two harmonic drives connected to the same motor and output, but wound up tightly against eachother to try to counteract this springiness - just like you describe for your chain drive - but it was still a big problem.
Have a look into the drive systems of radio telescopes. IIRC they often use a flat high-tension stainless steel(?) belt, which is wound around both the dish mechanism and a drive wheel, in a kind of figure 8, where one loop of the 8 is much bigger than the other.
Ballscrew worm-drive? Maybe… If non-backdrivable, this may actually work! But in a backdrivable type, there would need to be some play between the elements to make it backdrivable I think?
All very well in theory, but in practice, just use a bloody encoder 
They are cheap! And it wouldn’t be a servo without one.
That is a very good point- I did just put these in the category I was roughly describing because these are considerations in this field, but they may not be a good example when it comes to isolated high stiffness characteristics. Also, high stiffness may be a vague term as you can get anything in larger versions when other aspects matter more (zero backlash for example). Normalized for volume there are stiffer solutions.
Well I am generally a big fan of super high tension flat belts because the pulleys can be made precisely so easily and the performance characteristics are just extremely good, but they can over time creep and you may lose the synchronization. So we could go back to the DC servo.
Right, the board has all the capabilities, hopefully it will be possible at some point.
Sorry to join the conversation so late. I have the exact same issue except using a 3:1 gear ratio. I found if I rounded I could get through calibration but using the above method I get pole_mismatch_errors. I would love to have just done something wrong. Could you give me some input.
I have a 3:1 gear ration and have done the following with a amt102-v encoder
- Therefore K = 3
- thus cpr = 24576
- pole_pairs = 7*k = 21(motor pole pairing naturally is 7)