Custom homing for scara kinematics

[JelmerV]

Hi, I noticed the recent addition of more kinematics. Therefore this might be a good moment to merge my scara kinematics. This is tested and works nicely. However, I have not yet implemented homing abilities and I want to move some things to configurable settings.

My scara robot uses a parallelogram configuration. This makes homing more complicated because the allowed angle difference between both links is limited. Otherwise, the parallelogram folds flat and intersects with itself. So my planned homing cycle was as follows:

• Couple both motors (A and B) to move in sync. Rotate counterclockwise until Limit A is reached. Then move both back by a configurable pull-off of about 135 degrees.
• Fix motor A and home motor B as regular in the clockwise direction. Then use a different configurable pull-off of around 45 degrees

I could configure this as 2 separate homing cycles. However, then I need individual pull-off distances for each cycle. And I need an option to couple the motors for the first homing cycle.

Do you have any tips on how to implement this? or perhaps you have an alternative suggestion?

[terjeio]

Therefore this might be a good moment to merge my scara kinematics.

WIll you create a PR for that? I guess you already have noticed that I have moved the kinematcis implementations to the kinematics folder...

You can modify homing behavoiur to some extent via the existing callbacks and events. I had to modify one event signature for the delta kinematics, perhaps further modifications, events and callbacks are needed as well? And possibly new settings too? I have set aside ten settings id's for kinematics implementations, feel free to use them for whatever kind of settings you need.

Perhaps the latest homing code for the delta robot can give you some ideas for for how to proceed? E.g. I redirect the kinematics.transform_from_cartesian entry point while homing so I can modify the distances.

[JelmerV]

Nice, thanks for the tips. I will try to get the homing working and do some more tests before I create a pull request. You will see that show up when I reach that point

[JelmerV]

Hey, I am kind of stuck and starting to make a mess of things. I have pushed my latest version here in which I added some configurable options, but most of the homing functions are completely wrong.

I am having a hard time trying to understand the homing functions and I can not figure out how to implement the things I need. The following things are going wrong:

• I don't understand what to set in limits_set_target_pos. Currently, I get ALARM:9 pretty much as soon as it starts homing motors A or B.
• During homing, the motors A and B need to move in sync. So, when homing motor A clockwise, motor B should also be moving clockwise at the same rate. The direction is based on settings.homing.dir_mask.value. I thought this was what scara_limits_get_axis_mask did, but can't figure out how.
• After homing, the robot position needs to be set based on the scara_settings.home1_offset angle (and the pulloff distance).

If you could offer some help, I would greatly appreciate it. For reference, this image may help to understand my scara robot configuration:

Also, when the robot starts up, I want it to assume an initial position with a 90-degree elbow. Otherwise, the robot is in a singularity which results in problematic kinematics. For that, I would overwrite the sys.position, but the moving of the kinematics init call seems to have broken that. The way I implemented this now, is to add a kinematics.init_position function. This sets the sys.position correctly after a hard reset.

And lastly, sorry if I am using GitHub incorrectly. I have not committed to someone else's code before. If you prefer this to be in a pull request, let me know.

[terjeio]

Homing is complicated...

For the delta robot I have subscribed to some core events in order to modify parameters on the fly. See the attached file in this comment for what I have done this far.

delta_limits_set_target_pos() just sets the sys.position counters to 0.

Since the position counters represents steps/radian I had to modify the target positions accordingly. I do that by subscribing to hal.homing.get_feed_rate in delta_limits_get_axis_mask(), delta_get_homing_rate() will be called when feed rate is set. This is a hack to avoid changing the core - I will likely do so later.
delta_get_homing_rate() is only used to record which homing move is to be performed, seek, locate or pulloff.

In homing_cycle_get_feedrate() I temporarily redirect kinematics.transform_from_cartesian to get_homing_target() so that I can return the desired position in radians instead of mm, this since the original transform cannot be used when the current position is not known. I later reset the kinematics.transform_from_cartesian handler in delta_homing_complete().

get_homing_target() returns the target positions in radians based on the recorded move type.

Also, when the robot starts up, I want it to assume an initial position with a 90-degree elbow. Otherwise, the robot is in a singularity which results in problematic kinematics.

The above "hack" was to work around not knowing the current position, could it work for you as well?

Soft and jog limits handling for non cuboid work envelopes needs core changes - I will add those later.

[JelmerV]

Thanks, I copied your new delta kinematics and tried that. Now at least the z homing seems to work, but the pull-off move between seeking and locating is extremely slow. Like around 1 mm per minute, while other moves are at 100mm/min. Any idea what might be causing that?

Also, could you maybe give a rough outline of the homing process? Like I am setting a target position now but I can not really figure out how this influences the homing cycle. Can this be used to couple/sync the motor moves?

And about the kinematics.init_position method, this is mainly to have a known position that I can put the robot in and avoid having to home at every startup. My robot cannot physically reach the 0 angle on the second joint, so it needs an alternative starting position. This might also be useful for other robots that can not reach the 0,0,0 positions.

[terjeio]

Now at least the z homing seems to work, but the pull-off move between seeking and locating is extremely slow. Like around 1 mm per minute, while other moves are at 100mm/min. Any idea what might be causing that?

You need to transform the feedrate from mm/min to degrees/min?

Also, could you maybe give a rough outline of the homing process?

There are four phases:

• Seek: fast move towards the limit switches with target set to configured max travel multiplied with the search scalar (defaults to -1.5)
• Pulloff: fast move to the target from the configured pulloff distance.
• Locate: slow move towards the limit switches to the target from the configured pulloff distance mulitplied with the locate scalar (default 10) .
• Final pulloff.

Motion is relative to sys.position which is the step counters. Typically set to 0 before each phase starts.
Seek and locate phases gets a bit more complicated when auto squaring an axis.
For the delta robot I modify the target since distances are in radians. Easier to understand, at least for me.

And about the kinematics.init_position method, this is mainly to have a known position that I can put the robot in and avoid having to home at every startup

Assuming anything about the robot is not a good idea? It is possible to configure the controller to force homing on startup, IMO the safest option. BTW a new kinematics.init_position call is not needed? It can be set during in the existing init call?
Alternatively the HAL has an entry point, hal.get_position, you can hook into to set it. Currently this is called after initializing kinematics code, it could be moved before. Other options is to register a callback that will be called after startup is complete (main protocol loop is entered) or delay it until any private settings are loaded.

In the latest commit I have changed the signature of a kinematic function and added some new core events/handlers in order to make it easier to implement a kinematics driver. Major changes is that it is now possible to add functions to handle soft limits and jog constraining to non-rectangular work envelopes. It is also possible to write a completely custom homing function that overrides the default one.

Some of these changes are already made use of in the latest delta robot kinematics code.

[JelmerV]

You need to transform the feedrate from mm/min to degrees/min

This also applies to the z-axis, which is linear. And only applies during the pulloff move. Not sure what is going on here.

register a callback that will be called after startup is complete

This works great so I have reverted my changes to the kinematics API.

And thanks for the explanation of the homing process. I seem to be a bit closer to a working homing cycle but I am not too confident that I will get it working soon. Then the coupling of the motors during homing is a whole other challenge. I guess for the time being I will keep using the robot without a homing cycle.