Added Omnimove external control #152
Conversation
sending stop command when commanded velocity not changing.
…ervice and direct
# Conflicts: # .gitignore
allow movement of lift with platform for caterpillar.removed caterpillarlift command increase rotation speed in caterpillar tests
|
omnimove_external_control/include/omnimove/external_control_message.hpp
Outdated
Show resolved
Hide resolved
omnimove_external_control/include/omnimove/omnimove_external_control.hpp
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
this example is almost the same code as the iontec test, would be better to combined these with some parameters
There was a problem hiding this comment.
I think the best would be to use a parameter file with the position values. Evertyhing else could be in one python file that would be valid for all KUKA robots (not only using RSI)
There was a problem hiding this comment.
So, for now, i've made one file with the robot_type as a parameter, and changing position according to type. But i think i'll change it to have the parameters coming from outside
There was a problem hiding this comment.
movements are fully configured in a parameter file, fully extendible
There was a problem hiding this comment.
how do you start the example? Would not be a launch file necessary to "give" the config files to the node?
examples/kuka_rsi_robot_tests/kuka_rsi_robot_tests/quantec_test.py
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
what is the startup sequence for this driver?
all of our other drivers have a robot_manager node with a lifecycle interface, where activation starting the actual real-time communication. It would be nice to also add this component here, as the launch sequence is non-deterministic in timing which could lead to severe issues in my opinion
There was a problem hiding this comment.
I use the standard ros robot_manager node. So i didn't need to reinvent my own. I guess it becomes clear with the changes in kuka_robot_descriptions repo.
There was a problem hiding this comment.
What do you mean by the standard robot_manager node? This node was implemented by us and is part of the common non-real time interface for all drivers
The reasoning for needing this addtional node can be found in the wiki
Please add this robot_manager node to your driver as well, and move the config and launch files to this package too, as is the convention in this repo
|
please add a short doc somewhere about setup and launch process |
omnimove_external_control/include/omnimove/external_control_message.hpp
Outdated
Show resolved
Hide resolved
omnimove_external_control/include/omnimove/external_control_message.hpp
Outdated
Show resolved
Hide resolved
Co-authored-by: Áron Svastits <49677296+Svastits@users.noreply.github.com>
removed unused variables, removed unneeded test files. renamed variable
…t with configured robot_type Added boost dependency directly in CMakefiles simplified if statements to remove code duplication. removed commented out code
| <version>0.0.1</version> | ||
| <description>A ROS2 hardware interface for use with KUKA UTV3 vehicles</description> | ||
| <maintainer email="ravi.rathnam@kuka.com">Ravi Rathnam</maintainer> | ||
| <license>Apache 2.0</license> |
There was a problem hiding this comment.
| <license>Apache 2.0</license> | |
| <license>Apache-2.0</license> |
|
|
Another thing that is missing is the controller for calculating the offset from the starting position that could update the transforms from world to base_link to enable visualization and planning |
No description provided.