feat(iiwa): add an iiwa14 config - #83
Open
lvjonok wants to merge 3 commits into
Open
Conversation
IiwaConfig.home_config was the Franka pose shared by the other configurations in this module. It puts A4 at -135 degrees, outside the +/-120 degree A4 limit of every iiwa in the range, so robot.home() commanded a pose the arm cannot reach. Replace it with [0, 30, 0, -75, 0, 75, 0] degrees, validated on an iiwa14 R820: every joint at least 45 degrees from its limit, manipulability sqrt(det(J J^T)) of 0.126 against 0.044 for the Franka pose and exactly 0 for the all-zeros candle pose, which is fully singular and a poor place to start a Cartesian impedance controller. base_frame was "world". lbr_fri_ros2_stack publishes lbr_link_0 as the root of the arm and no "world" frame, so a target pose expressed in "world" has no transform available.
Ready-made profile for the arm driven through lbr_fri_ros2_stack at its
default robot_name of "lbr", so Robot.from_yaml("iiwa14_r820") works without
hand-assembling a RobotConfig.
time_to_home is 10 s rather than the 5 s default: these are slow commissioning
moves made under an enabling switch.
The robot-specific examples are where arm-specific behaviour belongs, so this
replaces the circle in example_with_iiwa.py rather than adapting a numbered
example; 01_figure_eight.py stays generic and keeps defaulting to fr3.
Uses make_robot("iiwa14_r820") instead of assembling an IiwaConfig by hand.
Drops the parameter overrides. They set a task stiffness of 2500 N/m, which is
an order of magnitude above what this arm can render: the torque overlay acts
through the cabinet's own joint impedance, and asking for a stiffer impedance
than that coupling cannot be followed no matter the damping.
Homing goes through a local helper. robot.home() switches through the stock
switcher, which deactivates every active controller not ending in
"broadcaster" and offers no way to exempt one. Command interface values
persist, and lbr_ros2_control NaNs its command interfaces only once when the
hardware component activates, so deactivating the Cartesian controller leaves
its final torques applied for the whole homing move rather than invalidating
them. zero_effort_controller is held active to keep writing a real zero, and
fri_position_passthrough_controller is held across the Cartesian switch for
the same reason on the position side.
The figure is centred on the pose homing actually reached and keeps that
orientation, so the arm does not traverse the workspace to start and the first
move is not a large rotation. Tracking is plotted against the target, and
robot.target_pose is used rather than the private attribute.
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
1 participant
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.
Hello there!
I have recently had a chance to work with KUKA and tested the setup for it through crisp_controllers and crisp_py. The hardware repo is here: https://github.com/lvjonok/pixi_kuka_ros2
There might be some inaccuracies or problems, but so far it looks like it works! This PR is quite small, it actually just brings the tested config for KUKA! Let's work to bring this safely to main, so more robots get support!
iiwa_crisp_example_720p.mov