I have tried to configure them in encoder mode first, but without success.
According to description ppr is 1024 as well as shadow count
CPR should be 4096 ( ppr * 4 )
Pole pairs is 10 ( we opened one of spare motors and counted poles - 20 in total ).
With this values it’s not able to calibrate complaining about CPR_OUT_OF_RANGE, if i relax calib_range to 1 - it’s fine, but in closed loop mode it’s not spinning at all.
According to plots current is being increased till reaching the limit, but still motors is not spinning.
There is no errors.
It’s able to spin in sensorless mode - absolutely fine.
What else should i try to tweak in order to make it spin?
Also almost same issue in hall mode - it works from scratch with configs that is provided in https://docs.odriverobotics.com/hoverboard, even though pole pairs and cpr is different, it’s not spinning when i set correct pole pairs and cpr ( in hall it’s 256 ).
Also tried with firmware 0.5.1, but it didn’t change anything.
Eh, from the aliexpress page ‘Wire Definition’ it looks as if it doesn’t have an index pulse, only A and B outputs from the encoder.
But it’s working now?
Er yeah, but use_index=True is meaningless (and wrong) if you have an AB encoder with no index pulse!?
It might let you get into closed_loop when it shouldn’t, for example… If the disconnected index signal were activated by some noise, then the ODrive would think it has a valid commutation reference when it doesn’t, so you could get all sorts of weird behaviour.
configs were erased and then i set
cpr = 4096
pole_pairs = 10
calib_range = 1 ( otherwise it spins in 1 direction and then gives error cpr out of range, same as when use index = True )
it calibrated without errors
but when i try to spin it in closed loop, it makes small move and then only current is growing, but wheel is not spinning at all
So once again, you have fudged something without understanding what it is you are doing, to make it calibrate when it actually can’t.
calib_range=1 sets the calibration tolerance to 100% i.e. simply disables the CPR_OUT_OF_RANGE error. It is set by default to 2% for a very good reason - the drive will not be able to commutate unless it knows where the magnets are in relation to the coils.
This is a sanity check to make sure that PP electrical cycles == one mechanical revolution, to some reasonable tolerance (2%). It checks that your pole pairs and encoder counts are consistent.
Setting this value to 1 means “I don’t care that the encoder information is totally wrong, go anyway” - and you get the expected result.
Are you quite sure that you have a 4096ppr encoder?
Can you rotate the shaft manually by exactly one turn and see what encoder.pos_estimate says?
(easiest if you call encoder.set_linear_count(0) first.)
I also have performed another test taking into account what you told about calib_range - decreased the cpr = 1024 and it was able to calibrate with calib_range = 0.09, but still it didn’t change anything in its behavior ( p.s. firstly i tried to calibrate with cpr 4096 and calib_range 0.5, but it failed to calibrate )
Well that’s interesting… I don’t understand how it could move the motor by 10 electrical cycles but the encoder moves only 1/4 rev. Can you see it skipping any poles or does it move smoothly? How far does it turn on calibration? Can you post a video of that?
From your video, I agree it looks like a 4096ppr encoder. Although it’s hard to be certain it’s not 4000?
It’s possible that you have some electrical noise coupling onto your encoder wires, which is causing it to give inconsistent readings when the motor is active (but it’s OK when the motor is off). Although I would have expected this to cause additional counts, not fewer counts.
You could try lowering calibration_current, and/or placing 22nF capacitors to GND on each of your A and B inputs.
No, it’s definitely 4096, as per the spec ppr is 1024. Plus manual movement also shows this, it’s very sensitive, but i see when the mark didn’t reached it’s origin on which it was 0.
Calibration looks smooth, here Calibration video
And the output of plots
Everything is same as if it was cpr 4096 and calib_range 1
Yeah, we thought about give a try to the capacitors, but didn’t checked it for some reason. ( Before with other motors it wasn’t improvement, but opposite - the encoders couldn’t calibrate at all always giving different errors )
I’ll check calibration_current and maybe capacitors later.
In that calibration video, it is moving by 1/4 rev… Exactly what I would expect if the pole count was set too low.
Stupid suggestion (another fudge) but have you tried setting pole_pairs to 40?
It could be one of those unusual kinds of motor geometry that multiplies the effective pole count (although it doesn’t look that unusual!)
Yeah, i tried in the past and it was able to calibrate with calib_range 0.1, but behavior didn’t change at all. Double checked right now, same - it moves to pose 800 and back to 0 upon calibration and not spinning in closed loop.
In that case, I’m stumped. Sorry.
You’ll have to wait for one of the devs to comment.
Looking at encoder.cpp (Encoder::run_offset_calibration), it looks like my understanding of the calibration movement was wrong. It moves by a fixed amount, not dependent on configured pole pairs. But forcing it to do the calibration more slowly or over a longer distance might yield more accurate results - especially if your motor is extremely coggy.
Have you tried increasing encoder.config.calib_scan_distance or reducing calib_scan_omega ?
It’s unable to calibrate like this complaining about CPR ( described in previous comments and topic description )
I’m not using firmware 0.5.1, so i have tried changing this odrv0.axis1.config.general_lockin.current ( used axis1 as its easier to film it ).
I changed value from 10 to 15 and 20, then tried also increasing from 10 by 2 - 12, 14…20.
Without any changes.
I’m also unable to add link to the video, because website counts it like a spam for some reason. (As well as all my previous posts )