-
Notifications
You must be signed in to change notification settings - Fork 345
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove front_steering from steering library #1166
base: master
Are you sure you want to change the base?
Remove front_steering from steering library #1166
Conversation
c83dce3
to
71800b2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I support the idea, thanks!
Please deprecate the old parameters and add the new ones to support both temporarily. Then we can also backport such changes.
Additionally, please add migration notes here.
steering_controllers_library/src/steering_controllers_library.yaml
Outdated
Show resolved
Hide resolved
steering_controllers_library/src/steering_controllers_library.yaml
Outdated
Show resolved
Hide resolved
Have you read and considered #692? Ideally, we should solve it with this PR. |
The idea is the same, is all about generalize the steering library a little more.
Next PR will allow that, I am thinking about extending the current ackermann instead of new controller, if you add a pair of traction and steering joints and define the instantaneus center of robot you can have this by modifyting a little the IK and odometry. Also you can keep the current ackermann by configuring the instantaneus centor or robot at the traction joints and using the same IK and odometry. |
3965416
to
c09d17b
Compare
c09d17b
to
41b3219
Compare
This pull request is in conflict. Could you fix it @qinqon? |
Tests working
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I unearthed this PR, I changed my mind and think it makes sense to merge this before a possible rewrite of the library.
Thanks @qinqon for the initial work, on top of that I did
- add proper backwards compatibility
- updated the docs
- added migration and release notes
- fixed a bug, that with Ackermann kinematics a different wheel track of the steering and traction axle was not supported (although the parameters were there from the beginning).
It's hard to see on mobile. But I see a separation between tracked and steered wheels. |
No, this is is not possible yet. I made a proposal once to configure this more freely, but haven't started going in that direction. |
Co-authored-by: Reza Kermani <[email protected]>
@christophfroehlich happy that the PR did help with the effort, let me know on whatever you need. |
Hello, I am interested in the work here and would like to see it merged. I am currently testing this branch on jazzy and face some issues, probably due to parameterization. Is there any specific order required for @qinqon Are you still working on the 4WD patch? I'd be also willing to contribute or help with testing. |
Does your config work with the current version without this PR? After merging, we have to fix the ackermann_drive_controller of gz_ros2_control_demos, @skasperski maybe you want to work on that and create a PR there? then we can troubleshoot together if something is not working properly. |
Ok, I will look into this. For now the parameters are misspelled in the deprecation messages. Can I somehow add commits to this PR? |
you can review in the "Files changed" tab, and I can commit the changes. |
{ | ||
RCLCPP_WARN( | ||
get_node()->get_logger(), | ||
"DEPRECATED parameter 'front_steering', set 'traction_joint_names' or 'steering_joint_names' " |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Parameter is actually called "traction_joints_names".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
@@ -172,22 +170,22 @@ class SteeringControllersLibraryFixture : public ::testing::Test | |||
command_ifs.reserve(joint_command_values_.size()); | |||
|
|||
command_itfs_.emplace_back(hardware_interface::CommandInterface( | |||
rear_wheels_names_[0], traction_interface_name_, | |||
traction_joints_names_[0], traction_interface_name_, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here it is always assumed that there are exactly two joints in the order [right, left]. This is as far as I can tell not documented anywhere.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
only for ackermann, and there is this note in the beginning of the test:
// NOTE: Testing steering_controllers_library for Ackermann vehicle configuration only
I added this information to the parameter yaml.
} | ||
} | ||
// END OF DEPRECATED | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here it should be tested that traction_joints_names
and steering_joints_names
have exactly length 2, because it will crash during update if not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added checks here.
I am currently unable to compile these packages, because all tests fail to build with this error:
I have no idea why that is, because the generated struct does have this member. Could this be some compatibility issue between jazzy and rolling? Edit: Never mind, the binary installed version of this package had leaked into the workspace. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@skasperski thanks for the hints. I pushed changes, let me know what you think.
@@ -172,22 +170,22 @@ class SteeringControllersLibraryFixture : public ::testing::Test | |||
command_ifs.reserve(joint_command_values_.size()); | |||
|
|||
command_itfs_.emplace_back(hardware_interface::CommandInterface( | |||
rear_wheels_names_[0], traction_interface_name_, | |||
traction_joints_names_[0], traction_interface_name_, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
only for ackermann, and there is this note in the beginning of the test:
// NOTE: Testing steering_controllers_library for Ackermann vehicle configuration only
I added this information to the parameter yaml.
{ | ||
RCLCPP_WARN( | ||
get_node()->get_logger(), | ||
"DEPRECATED parameter 'front_steering', set 'traction_joint_names' or 'steering_joint_names' " |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
} | ||
} | ||
// END OF DEPRECATED | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added checks here.
To Accommodate controllers that are not only steering at front or rear
this change remove the
front_steering
variable fromsteering_controller_library, as a byproduct of that the notion of
front or rear wheel radius is also removed from dependant controllers
and the library has know "traction_joints_names" and
"steering_joints_names" instead of "front_wheels_names" and
"rear_wheels_names".
Depends on: