Expose STARBackend.iswap_rotation_drive_move_y()#1020
Merged
BioCam merged 4 commits intoPyLabRobot:mainfrom Apr 30, 2026
Merged
Expose STARBackend.iswap_rotation_drive_move_y()#1020BioCam merged 4 commits intoPyLabRobot:mainfrom
STARBackend.iswap_rotation_drive_move_y()#1020BioCam merged 4 commits intoPyLabRobot:mainfrom
Conversation
Comment on lines
+9953
to
+9954
|
|
||
| iswap_radius = STARBackend.iswap_rotation_drive_diameter / 2 |
Comment on lines
+9994
to
+9996
| if not (1 <= acceleration_level <= 2): | ||
| raise ValueError(f"acceleration_level must be between 1 and 2, got {acceleration_level}") | ||
|
|
Member
There was a problem hiding this comment.
this is 6250 steps / s2 or 2 * 6250
so 6250 * 0.046302082 = 289.388 mm/s or twice that?
Collaborator
Author
There was a problem hiding this comment.
For level 1:
6250 * 0.046302082 = 289.388 mm/s
For level 2 twice that
Is how i understood it
BioCam
added a commit
that referenced
this pull request
May 1, 2026
* expose iswap_rotation_drive_move_y * shuffle iswap move y next below move x * Expose `STARBackend.iswap_rotation_drive_move_z()` Adds the absolute Z-axis sibling to `iswap_rotation_drive_move_x` (#1018) and `iswap_rotation_drive_move_y` (#1020). Wraps `R0 ZA` and accepts the rotation-drive plane Z (matching `iswap_rotation_drive_request_z`); the 13 mm offset to the gripper finger plane is applied internally. `acceleration` is exposed in mm/sec^2. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * clarify `bottom` return (per LFB PLR expectation) PLR users expect left-front-bottom referencing; for channels this changes to center-center in x-y but in z people still expect bottom; since we are referencing the actual rotation drive here and its bottom is 13 mm above the finger_z_plane I have added a short comment to make this clearer * `make format` --------- Co-authored-by: Camillo Moschner <camillo.moschner@biocam.guide> Co-authored-by: Camillo Moschner <122165124+BioCam@users.noreply.github.com> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
BioCam
added a commit
that referenced
this pull request
May 1, 2026
* expose iswap_rotation_drive_move_y * shuffle iswap move y next below move x * Expose `STARBackend.iswap_rotation_drive_move_z()` Adds the absolute Z-axis sibling to `iswap_rotation_drive_move_x` (#1018) and `iswap_rotation_drive_move_y` (#1020). Wraps `R0 ZA` and accepts the rotation-drive plane Z (matching `iswap_rotation_drive_request_z`); the 13 mm offset to the gripper finger plane is applied internally. `acceleration` is exposed in mm/sec^2. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * clarify `bottom` return (per LFB PLR expectation) PLR users expect left-front-bottom referencing; for channels this changes to center-center in x-y but in z people still expect bottom; since we are referencing the actual rotation drive here and its bottom is 13 mm above the finger_z_plane I have added a short comment to make this clearer * `make format` * create `iswap_rotation_drive_request_predefined_z_positions` * create `iswap_rotation_drive_request_predefined_y_positions` * add iSWAP Y/Z drive conversions and correct pip Y resolution * tighten iswap_rotation_drive_move_z error messages and document Raises * create `iswap_rotation_drive_request_predefined_z_positions` * create `iswap_rotation_drive_request_predefined_y_positions` * add iSWAP Y/Z drive conversions and correct pip Y resolution * tighten iswap_rotation_drive_move_z error messages and document Raises * drop firmware-internal constraints from predefined Y/Z parking-pose docstrings * reword Z increment-range comment to drop misleading return claim * decouple iSWAP rotation-drive Y/Z from PIP-channel conversions * rename increment version to `_` and provide public API in expected mm * make everything that references rotation drive return rotation drive data * `make format` * simplify: compress increment and mm returns into one method * simplify z conversions --------- Co-authored-by: Rick Wierenga <rick_wierenga@icloud.com> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Tame the iSWAP - Part 7
The center of the rotation drive is the "base of the SCARA part of the iSWAP".
In the previous parts I've exposed requesting the position information of it, then added it's movement in X.
In this PR, I'm adding its movement in Y.
Because the iSWAP is not alone on the rail / its X-coordinate, this is the PR in which I am adding the iSWAP safety features in the Y dimension:
-> from now on you can no longer crash your iSWAP into ...
Because it is tedious to always think about arm positions I added
make_spaceargument to:...adapted from
position_channels_in_y_direction'smake_spaceTo make this calculation possible I took the iSWAP channel diameter to be
30.5mm, as described in the operator manual - see #1011Please let me know whether you think we should make
make_space: bool = Falseby default; it might help people but does introduce implicit behaviour - though expected behaviour?