MSECode
commented
5 months ago After some knowledge transfer done with @ale-git, we understood that some changes should be done to the heuristic use in the method of the 2FOC where we perform the stator-rotor calibration looking for the index of the quadrature encoder mounted at the motor side of the joint.
The whole portion of code we are interested in is at this lines: https://github.com/robotology/icub-firmware/blob/master/emBODY/eBcode/arch-dspic/board/2foc/appl/2FOC-V3/src/2FOC.c#L353-L520
Here a brief explanation of what should we modified and what probably was the cause of the failing of the calibration procedure.
- First of all we need to clarify that if we do not want to find the
stator-rotor offset, so we are just looking for the index of the encoder and setting the zero at that position, we are just passing through the steps of the state machine defined by values0-1-2of the variablesAlignInProgress. So in this case we can limit our analysis to the lines here. - Considering this we can see a couple of variables that we need to take care of. They are:
- limit in the rotation of the fast shaft when looking for the index defined by this one
- timer/counter used for moving the fast shaft with a
stairs-likecurve, which defined here: https://github.com/robotology/icub-firmware/blob/master/emBODY/eBcode/arch-dspic/board/2foc/appl/2FOC-V3/src/2FOC.c#L383 and used in the if clauses with this value: https://github.com/robotology/icub-firmware/blob/master/emBODY/eBcode/arch-dspic/board/2foc/appl/2FOC-V3/src/2FOC.c#L391
- Supposed all of that we have to clarify that even if in different robots and setups we are using the same fw the hardware instead changes. Therefore, using a fw with values that are not parametrized depending on the multiple configurations we have it is most likely the cause of the misbehaviors we saw.
- To make an example we can talk about 2 different configurations:
- ergoCub robot is using on the legs motors with 4 polar couples
- in our setup the new joints have motors with 10 polar couples
- considering this, the value defined here, which is based on the electrical degrees per revolution (= (motor poles / 2) * 360 ), changes a lot when using different hw configurations. This can be a problem of the calibration since we are using that value for defining how many ticks should the encoder span on one direction and (eventually) on the other while looking for the index.
- moreover, considering the counter used for moving the shaft step-by-step, we did not change the value when we decided to reduce the frequency of the 2foc loop from 40 kHz to 20 kHz. Therefore, since each call of the
alignRotormethod occurs in the DMA interrupt service routine, we are basically moving the fast shaft with half of the speed.
- on top of this, since the timeout of the calibration defined by the EMS is still of 30 seconds, it happens that in some occasion, especially when close to the hw limit, the encoder does not have enough time for finding the index since the shaft is too slow to move towards one direction and the other. As a matter of fact, when the joint remained in the
not calibratedstate we saw from the raw data that:- first thing first the raw value of the ticks spanned was way lower than the limit defined here
- and the state machine stopped at the first phase (sAlignInProgress variable fixed to 1). So the shaft only had time to move in one direction, which is probably the one towards the hw limit where it started.
In conclusion, I did some tests by reducing the value of the timer for our setup where the number of motor poles is more than the double with respect to the motor in the robot and I was able to always finding the index. Thus, we need to revise together the heuristic used and parametrized the timing so that we are good in all hw configurations
cc: @valegagge @ale-git
valegagge
After some tested carried on in https://github.com/icub-tech-iit/ergocub2-design-upperbody/issues/43, we noticed that sometimes joint couldn' t complete the calibration because it doesn't find the index before the timeout of 30 seconds exipre.
We noticed that the motor does 3 or 4 complete tourns but the index interrupt isn't t triggered. So we need to create a setup with the oscilloscope to verify the index signal.
Moreover, in the procedure, some time constants need to be updated (or parametrized) since the 2foc now runs at 20KHz and not 40 KHz.
For more details please see this comment.
Dod The new procedure runs correctly both on the robot and on ergocub2 joints