odriverobotics
Add support for homing-specific switches
Due to the current way homing is implemented through the min_endstop, issues #634 and #625 arose. Industrial motion controllers often offer double-layer endstop switches in which the first endstop pressed does not interrupt execution like the current implementation of min and max endstops. i.e. :
in a linear motion example:
--o-----x------------------------x-----o--
^ ^
this is the real this causes a
limit switch warning but doesn't interrupt
the execution cycle
Double-layered endstop switches or software-defined endstops In some situation, an endstop hit doesn't correlate to an immediate fatal accident (it could mean start of emergency deceleration but not imminent stop) so it can be convenient to have available an additional safety net to avoid full stop of the motors.
At the same time, software-defined endstops could help with this, for example raising a warning instead of an error, and triggering some action in response.
Another case where this can be helpful is during homing: the newly implemented warning switch could act as homing switch and we could be shure not to raise an unnecessary error.
Revolute joint case In the case it is needed to perform homing on a revolute joint, the current implementation through min_endstop prevents the joint to be able to rotate more than one rotation (due to physical switches this is not even a full rotation). So a solution where homing is done in another way could solve this problem.
This is not an issue where an absolute encoder is mounted on the joint but in other cases (incremental encoder, joints with meccanical reduction) it is not possible to use such an encoder. A solution to this could be to implement a double encoder setup (absolute encode after reduction) but this adds more layers of complication and is not the subject of this proposal.
TL:DR - Homing shouldn't depend on endswitches being enabled or present.
BUNCH-OF-CONTEXT: Speaking for our use case, we simply don't have endswitches: The masses of the axes are large enough that any endswitch that COULD stop mechanical damage would by necessity rob us of too much operating volume. There are mechanical buffers to avoid the worst, and a main axis crash in operation by necessity involves recalibration = downtime.
As such, it's common for the operating envelope to include the homing switch, with the caveat that the homing switch should always be actuated for the whole envelope that extends past it (so the axis knows which way to home).
Essentially, the user should never be able to successfully enter a value outside the working envelope, and the programmer and tester are responsible for getting the axis crashes done (and fixed by the constructor) before the device is released to production.
That said, when your drives, motors and encoders are from the same vendor with parameters of both known to the drive, it's much more difficult to encounter "runaway" motors. Any crash would thus be the result of an out-of-envelope position command, resulting in the drive simply nopeing out due to overcurrent, when it encounters the end buffer.
Given that there is talk of CANopen support (and I'm assuming that means CiA 402 Motion Control Profile / IEC 61800-7-{1, 201, 301}), there are standard homing modes (not all need be supported), see https://demero.pl/files_mce/stober/sd6/442708_00_app_ci_a_db_en.pdf (2.2.3.3).
The case I described would be reference method 21 (2.2.3.3.10).
You mean a homing sensor should be active always when the drive is outside the working range?
How is this implemented in a revolute joint/rotating drive?
Thanks for the suggestions. I think these are some good inputs on possible homing use cases.
I think from an implementation perspective the key is to decouple a bunch of things:
- determining the absolute position of the end effector after controller startup (using one or more index switches or edges or a software command from a higher level controller)
- actively moving the motor in a certain way to help determining the absolute position (e.g. based on GPIO level)
- once the controller knows its absolute position, make it try to always stay within a software-defined working envelope (position limits, velocity limits, etc)
- hard limit switches that disarm the motor, accounting for unexpected software/mechanical issues
We will keep this in mind for when we revisit the homing implementation.
ve always when the drive is outside the working range?
How is this implemented in a revolute joint/rotating drive?
This particular homing method only applies when you have a finite movement envelope. You wouldn't use that method on an infinitely rotatable table, for example. For that, methods 7, 11, 23 and 27 are available to home either to the first encoder Z pulse before the start of the reference switch, start of the reference switch pulse, end of the reference switch pulse or the first Z pulse after the end of the reference pulse.
In those applications, there wouldn't really be "endswitches" either, semantically.
Or perhaps I misunderstood what you meant. The homing switch isn't always actuated when outside the working range. In our case, the homing sensor ("reference switch" in the nomenclature used in the linked manual) is always actuated when the axis is "to the left" of the zero position. That means that the axis always knows which way to move at the start of a homing operation: Switch 1: move right. Switch 0: move left. The actual working range is only referenced to the rising edge of the reference switch: actual working limits are enforced in software as "number of encoder pulses to the left" and "number of encoder pulses to the right" of zero, which is some fixed offset from the rising edge of that reference switch. Usually that offset is itself zero.
If you have an infinitely rotating joint, you probably don't care which way to start moving when homing: at some point you will trigger the reference switch, and will know your location.