Hello every one:
I am testing my walking algorithm on Bolt,quiet often met the encoder error problem,since i do not use the ADC,so i store the encoder error degree value indexError_counts/5000.0 in ADC field,so that i can know what exactly error degree is on PC.
I found that many times when the encoder error occurs,the error degree is huge,such as more than120 degree,200 degree.
I think the shock of the joint can’t cause such huge degree error,does anyone meet the same problem or have any idea?
Thank you very much！
here is the code i modified on udriver firmware SPI version, line 1385 of file dual_motor_torque_ctrl.c,
//SPI_REG_u16(to_write, SPI_SENSOR_ADC_1) = D32Q24_TO_D16QN(HAL_readAdcResult(halHandle, POTI_RESULT1), SPI_QN_ADC);
//SPI_REG_u16(to_write, SPI_SENSOR_ADC_2) = D32Q24_TO_D16QN(HAL_readAdcResult(halHandle, POTI_RESULT2), SPI_QN_ADC);
_iq test_val0= _IQ16((float)gQepIndexWatchdog[0].indexError_counts/5000.0);
_iq test_val1= _IQ16((float)gQepIndexWatchdog[1].indexError_counts/5000.0);
SPI_REG_u16(to_write, SPI_SENSOR_ADC_1) = test_val0;
SPI_REG_u16(to_write, SPI_SENSOR_ADC_2) = test_val1;
SPI_REG_u16(to_write, SPI_SENSOR_CR_1) = D32Q24_TO_D16QN(0, SPI_QN_CR);
SPI_REG_u16(to_write, SPI_SENSOR_CR_2) = D32Q24_TO_D16QN(0, SPI_QN_CR);
on PC, received ADC value multiply by 360.0,this the degree error value i can see from output.
Hello,
There is some input filtering on GPIOs (see this article from TI) which results in a speed limit above which encoder ticks will be filtered out and thus missed.
In our firmware, we already reduce the “qualification period” for the GPIOs of the encoders to allow higher velocity (see dual_motor_torque_ctrl.c; we set it to 11, the default value is 22).
With our settings, using a 5000-lines encoder should work up to about 6000 rpm (of the motor, i.e. for the joint it should be ~666 rpm = ~70 rad/s). When you move faster than that, you will miss encoder lines, which will result in an encoder error.
If you really get motions that fast, you could try reducing the qualification period even further (however, if you reduce it too much, you might get problems with noise).
Otherwise I would assume some hardware defect. Either the encoder disc is not fixed properly or there is a loose contact due to a broken cable. At least on the TriFinger robots a broken cable is almost always the cause if we get encoder errors (unfortunately this happens from time to time, as the cables are routed through the joints and thus are bent back and forth a lot if the joints move).
I hope this helps.
Felix
1 Like
Thank you Felix for your very detailed reply。
I’ve been struggling with this question for a long time.
After reading your reply,i check the all things again,the control parameters,the control trajectory，when doing sim2real,the joint velocity is not fast.
I suspect there may be a problem with the encoder,but actually i replaced it with a new one for times.
So now i have no idea to solve this problem 
Does this problem happen when you assemble SOLO8,SOLO12 and Bolt?
Is this a very common situation or rare？
At least with the TriFinger Encoder errors due to broken cables are very common.
For Solo/Bolt I don’t know. Maybe @fgrimminger can answer that?
Hello,
we didn’t have any issues due to broken wires on our legged robots in the last couple of years.
When we built the first prototype we noticed that the ribbon cables and the precrimped Hirose cables that we used initially were too inflexible and would break after a couple of thousand cycles.
That’s why we switched the encoder wires and the motor phase wires to the highly flexible and high quality wires from Kabeltronik.
Endurance testing of those wires resulted in 50 days of continuous operation and more than 14 million position commands executed without any damage to the wires.
If you are having issues due to damaged wires I would recommend to use the LifY Cable 0,14 mm² wires for the encoder and the LifY 0,50 mm² wires from Kabeltronik for the motor phases.
Best. Felix
Thank you for reply, i replace all the wheel,encoder and wires,this problem occur less frequent.
There is another problem.
When just control single motor for test,everything is good.
When i do the sim2real job,first,i calibrate all motors one by one,this is also good,not error occur, and then i control the six motors of Bolt at the same time,the LED of 8305 may turn red and then all the motors seems out of control,this happen quite often.
All the motors are connected to a DC power supply which max current is 12A.
I check the code of udriver,it seems the firmware doesn’t handle the error of 8305.
What is the meaning about Led of 8305 turn red?
BTW,when this error occur,the motors sound a little noisy.