Custom inverse kinematics applied to a robot

edit

Of course, getting into MoveIt is a bit of a learning curve all by itself, and it also uses ros_control "under the hood" to send commands to actuators (and get feedback from them).

Pedantic, but MoveIt does not use ros_control directly. It can be configured to do so with special "controllers" on the MoveIt side, but typical configurations will use an Action client to talk to a JointTrajectoryAction server.

And also please the precise when talking about ros_control: ros_control itself does not run any controllers, nor does it talk to robots or do FK/IK. Nodes hosting ros_control-based hardware_interfaces and ControllerManagers can do these things, but only when written and configured as such.

If you want to execute complete cartesian trajectories, you might want to load a joint_trajectory_controller and again implement your IK in a different node. This node would now convert full cartesian trajectories into series of joint configurations and send them to the controller

Unfortunately the joint_trajectory_controller does not support Cartesian trajectories.

As its name implies, it executes joint trajectories, ie: trajectories in joint space.

@gvdhoorn Oh right, i should have been a bit more precise with with node actually hosts the controllers. As for joint_trajectory_controller: What i meant was the same basic procedure as in option 1, meaning: Custom IK node receives cartesian trajectory, converts it to full joint trajectory, and sends this to the joint_trajectory_controller for execution (this is also why i mentioned time parametrization, which this custom IK would have to do by itself). Maybe i should have been more explicit about this.

@lucasrebra If you need some inspiration for messages for these approaches, take a look at this design document which reviews the commonly used types for this and seems like something that could become the basis for future ROS/ROS2 based cartesian interfaces (see here and the associated issues for some discussion).

@lucasrebra ah i see, closed chains can be... tricky. A first step i would suggest: Think really hard if you cannot in any way convert this into a serial chain using the urdf mimic tag. I just saw your previous question on this topic where you said this was not possible, but i cannot quite see what should not work here - i have previously worked with a parallel linkage mechanism (in the torso of a humanoid robot) which worked just fine. I'll try writing together something over there once i have some time.

Looking back at moveit plugins: It seems i actually forgot about one perhaps easier solution. There already is a srv_kinematics_plugin, which allows you to implement your IK in a different node (this seems to specifically target "difficult" kinematics). For this you would just have to provide a service of type moveit_msgs/GetPositionIK. This could make your task much easier, as most of the boilerplate is already implemented for you. On the MoveIt side, you would just have to select this plugin for your move group (either in the setup manager or via config).

If you decide to actually implement a custom plugin: I have only ever implemented "simpler" plugins (like MoveItSensorManager), but my main advise: Look at other implementations. Specifically srv_kinematics_plugin should help a lot when cross-referencing, combined of course with the interface specification. This goes for both pure source code and the associated build system and integration, e.g. the proper exporting via pluginlib. At least you will have some different reference implementations, but this will still be the most boilerplate- and work-intensive path to choose, with the least chance of generating easily reusable code (this is just personal experience...). This is also why i would look really hard if any other way works.

@RobertWilbrandt Ok I see that working over the example of srv_kinematics_plugin would be much easier and I think is a good way for working with plugins. I know there are examples, but sometimes It's a little bit difficult for me to understand some mechanisms of ROS (and plugins are a little bit different from the rest I think).

Talking about the mimic: I tried to implement It and I found imposible to implement the relation between the elbow and shoulder joint as the real robot movement. Probably I'm not doing It properly because, as you say, there are lot of people working with 4 bars. My robot is a sainsmart 6dof, could you give me some advices just for the URDF and the rviz representation?

Thank you so much