Hello all,
My name is Adam Pettinger. I am a first year PhD student with the Nuclear & Applied Robotics Group at The University of Texas at Austin, and I would like to do a Google Summer of Code project with MoveIt this summer. For my project, I want the primary deliverable to be porting the moveit_jog_arm package to ROS2. I would also like to take the opportunity of being under the hood of the jogger to make functionality improvements including allowing different IK methods and lowering the barrier of entry for new users.
My Master’s work involved developing a manipulator controller and relied heavily on coding in C++ and integrating with MoveIt. Since then, I have been doing work in the area of teleoperation, and have been extensively using and working on moveit_jog_arm.
I will lay out the jog_arm current state and my working project proposal ideas below
Jog Arm Current Status
In this section I just want to give a brief overview of the status of some parts of jog_arm, specifically areas where I think improvement is possible.
Overview
moveit_jog_arm accepts continuous end effector velocity commands from the user, and outputs joint commands to the low-level controllers using an Inverse Jacobian method. The outputted joint commands are restricted to follow limits set in the URDF/SRDF.
Inverse Kinematics
At every loop iteration, Singular Value Decomposition is taken on the Jacobian at the robot’s current position. This is used to 1) get the condition number and 2) invert the Jacobian in a way that is more stable near singularities than the standard pseudo-inverse. The inverted Jacobian is multiplied by the EEF velocity command to get the joint velocities, which are then checked for position, velocity, and acceleration limits.
Collision Checking
In a separate thread from the IK, the planning scene is used to check collision proximity. As the manipulator gets closer to collision, the velocity output is scaled to 0 to avoid crashes
Singularity Handling
Right now moving towards singularity in the Jacobian is treated the same as collision checking. The output velocity is scaled to 0 as the manipulator gets closer. To determine if it is moving closer, the nominal joint velocities from the IK are used to update the future joint states, and SVD is again taken there to find the “future” condition number.
Outputted Commands
The commanded joint velocities and (optionally) positions are currently published to a ROS topic for some controller to follow.
GSoC Project Overview
Main Objective
Port the jogger to ROS 2. This will probably involve splitting the current jogger into a C++ only implementation (non-trivial), then writing a ROS2 wrapper for it.
Secondary Objectives
-
Ease of use and new robot setup: I hope to have great documentation, tutorials, and examples so that someone new to ROS/MoveIt can get started with the jogger quickly and with low amounts of frustration
. Additionally, I would like it to be easy to set up a new robot with jog_arm. Right now there are some abstract parameters (scaling factors, low-pass filter coefficients) that really can only be determined via trial and error. I would like to make that a little better and more intuitive. -
Allow and implement different IK methods: I would like to focus on improving the IK used in the jogger, specifically when the manipulator is near singular. To this end, I think being able to allow different IK methods is an interesting feature. During the summer, I would like to think about implementing Damped Least Squares, Selectively Damped Least Squares, and direct joint search. In addition to this set of IK methods, I would like to make it easy for a user to write and use their own method.
-
Allow different sources of Jacobians: Along a similar vein of allowing the user to write their own IK method, I would like to allow some flexibility in the source of the manipulator Jacobian. Right now, the jogger gets this from the MoveIt robot state. I think it would be interesting to let the user provide their own Jacobian if they want, for cases where they have a parallel robot, or one with non-revolute (or non-prismatic) joints.
-
Real-Time considerations: I would like to make the jogger as “real-time” as possible by reducing internal ROS messaging and system calls, and eliminating mutexes. I believe MoveIt2 is moving this way and hope to follow suit. One area of interest might be interfacing the jogger directly with ros_controllers to eliminate the ROS topic transmission of joint commands.
Closing Remarks
I am hoping to spend this summer first porting moveit_jog_arm to ROS2, then making as many of the improvements listed above as possible.
I am posting here to get feedback before applying to GSoC, and would love to hear whether or not y’all think this is a reasonable project. I am also interested in more improvements or extensions that would be useful to the community, or changes to the scope of the project I laid out above to make it a more reasonable project.
Thanks!
Adam