Add homing procedure

[lokiledev]

Add a procedure for finding the endstop.
This would be a good addition with #114 .

It would work only in position mode, typically for a robot joint control, where there are mechanical endstops.
It is hard to make a generic procedure that works for all sizes of robots, but the algorithm could be something like the following.

• Start with target position = current position.
• Create a moving target position with a constant speed, the speed can be the input parameter of the procedure, the sign of the speed target gives also the direction of the motion.
• Monitor measured position, once the position error between target and measurement passes the tolerance, it means the endstop has been reached.
• Set the detected position as the new zero position.

Alternatively if using #124 the new found position could be set as one of the position limits, so that the new zero is the real zero.

[yconst]

Yep sounds good, thanks.

Not sure if it would be best using delta_pos, I would try also by observing torque (=effort), they are related after all.

[lokiledev]

Not sure if it would be best using delta_pos, I would try also by observing torque (=effort), they are related after all.

Yes that is an option, however I feel that it will be too dependent on the motor and reduction parameters, it's hard to find a generic torque threshold, as for position since the axis is blocked on the endstop, the difference between target and measurement will always increase.

I will implement it externally to do a proof of concept, if that works maybe it's not necessary to implement it in the board, it adds complexity to the firmware for a specific mode only (position mode).

[yconst]

Yes that is an option, however I feel that it will be too dependent on the motor and reduction parameters, it's hard to find a generic torque threshold, as for position since the axis is blocked on the endstop, the difference between target and measurement will always increase.

You have a point. However, I would argue that similar limitations hold true for position-based endstop detection. Namely, what would be the Δpos (setpoint-estimate) that would be acceptable? This depends on the reduction of a system of course. In addition, there is a danger that if the current limit is not properly set, advancing the position beyond the endstop could cause mechanical damage.

In the end, it is a matter of what the user would prefer to set before the process. On one hand, position-based detection should have a current limit and Δpos_max set by the user. On the other hand, torque-based would need a max torque (=current limit) and eventually a min time period that the torque is applied, beyond which the endstop would be confirmed.

Food for thought.

I will implement it externally to do a proof of concept, if that works maybe it's not necessary to implement it in the board, it adds complexity to the firmware for a specific mode only (position mode).

Looking forward to your results when you manage to do so!

[ThotAlion]

Another idea for homing procedure shall be to control the motor in speed (low speed) and observe when the encoder really stops (maybe with a small shock profile). The algo can be set_velocity_setpoint -> if abs(encoder velocity)take the encoder position as a mechanical stop. This may be less dependent on a threshold dependent on the robot.
Whatever, the homing procedure shall be done in ideal conditions (no mechanical disturbance, no gravity torque)

[lokiledev]

I agree, the catch is that however the algorithm it's hard to make it generic /compatible with all scenarios and there will need to be some parameters. It's probably better to let the external controller do this stuff and just provide a command to set the zero and or even only position limits.

[lokiledev]

Another idea could be to have an external index signal like the switches in a 3d printer that are used for homing. Maybe on next board revision.