uwgraphics / relaxed_ik

RelaxedIK Solver
MIT License
186 stars 50 forks source link

Development update #16

Open djrakita opened 4 years ago

djrakita commented 4 years ago

The RelaxedIK solver has presented two main options over the past six months: (1) For a stable, reliable, yet relatively slow version of the solver, use the python implementation on the main branch; or (2) for a less stable, less reliable, yet much faster version of the solver, use the Julia implementation on the dev branch. My goal was always to iterate on the Julia version to become just as stable and reliable as its Python counterpart, and eventually unite these two camps into one on the main branch with the Julia version as the centerpiece.

However, there are a few idiosyncrasies that come along with the Julia programming language that have precluded those plans. First, the Julia version of relaxedIK takes at least a minute to do its JIT compilation and start from scratch each time. This is unacceptable for a stable release of a solver that should be convenient and lightweight to use. Plus, it makes development on top of the base solver incredibly tedious, since each little change requires this full JIT compilation. While the people developing the Julia programming language seem to be well aware of this issue for large projects developed in the language, and they may have a sufficient solution for this problem down the road, just waiting around and hoping this gets fixed does not seem like a good option. Second, while ros is somewhat supported in julia through RobotOS.jl, this library leads to mysterious errors too often to be the foundation of a stable release. With both of these issues in mind, I'd rather be proactive and just turn the page away from Julia and plan future development elsewhere.

So, over the next couple of months, I will be re-implementing relaxedIK in a fully statically compiled language (still TBD). Given recent testing, I anticipate the new solver will be even faster than the Julia version, without the JIT compilation hassle and stability issues. Everything will remain ROS compatible. The Julia and python versions will remain in the new release for backwards compatibility, but I anticipate new features will just be officially added and supported in the new language.

Along with the new language, I plan to add in a few other features as part of a "major" new release, such as better support for fast, standard IK solver options. The tools that make relaxedIK actually afford incredibly fast standard IK solver options (i.e., "standard" meaning just hitting end-effector pose goals accurately, without the motion continuity, collision avoidance, and other feasibility considerations included in relaxedIK). We've used these "standard" IK options in our prior work and, in our testing, it is faster and more reliable than other numerical IK solvers we have tried. I plan to make these features more publicly accessible and well documented.

If you have any comments or questions on any of this, feel free to use this thread to foster conversation. Or, if you prefer, feel free to email me directly at rakita@cs.wisc.edu

Thanks!

Danny

rohitmenon86 commented 4 years ago

Hello Daniel,

I found the relaxed ik paper quite interesting and I wanted to incorporate the self collision avoidance and singularity avoidance based IK into the core real time part of our robotic arm. However we are using C++ based Orocos framework for the same. Hence I would like to remove the ROS and python/julia dependencies.

I read that you have plans to re-implement relaxed ik in a statically compiled language. If that is going to be C++ , then maybe we can collaborate?

Rohit Menon

djrakita commented 4 years ago

Hi Rohit, thanks for the kind words about our work! The next re-implemented version of RelaxedIK will be written in Rust. That version is almost done and substantially improves on the python and Julia versions in terms of speed and reliability. However, we do have plans to continue developing out RelaxedIK after that. I bet C++ will eventually be in our plans longer term though, so if you do end up starting any C++ implementation before we get around to it, definitely let me know and we can compare notes at that time!

Your general point about having an Orocos compatible version of RelaxedIK is a good one though. Our philosophy has generally been that because the solver is hooked up in ROS, the data output from the solver is agnostic to the back-end programming language, thus allowing for easy swapping in and out of various PL options (python, julia, and now rust). But, that philosophy doesn't apply between ROS and Orocos. This will definitely be kept in mind going forward.

djrakita commented 4 years ago

RelaxedIK has been substantially rewritten in the Rust programming language. Everything is still completely ROS compatible and should serve as a drop-in replacement for older versions of the solver.

The Rust relaxedIK solver is MUCH faster than its python and julia alternatives. Testing on my laptop has indicated that the solver can run at over 3000Hz for single arm robots (tested on ur3, ur5, jaco, sawyer, panda, kuka iiwa, etc) and about 2500Hz for bimanual robots (tested on ABB Yumi and Rainbow Robotics DRC-Hubo+). All of the new code has been pushed to the Development branch, and will be pushed to the main branch after a brief testing phase. It is highly recommended that the development branch be used at this point, as it has many more features and options than the main branch.

 git clone -b dev https://github.com/uwgraphics/relaxed_ik.git 

If you are working with an older version of relaxedIK, note that you will have to start from a fresh repo and go through the start_here.py procedures again to work with the Rust version of the solver.

If you have any comments or questions on any of this, or if you encounter any bugs in the new rust version of the solver, feel free to post an issue or email me directly at rakita@cs.wisc.edu

Zju-George commented 3 years ago

@djrakita Using DNN to approximate the collision avoidance term is a smart idea, but I wonder if the trained Network only applys to one certain structure(including like arm length, etc) of robot.

djrakita commented 3 years ago

sorry, just seeing this now! Thanks for the question!

The neural network only applies to the one robot used to train it. The hope is that this one time training process will learn many of the implicit properties that make up the structure of the robot, such as its kinematics, arm lengths, and so on, but the patterns that the network learns only apply to one robot and do not generalize beyond that.

danzeeeman commented 3 years ago

I've updated the dev branch to work with python3, ros noetic, and 20.04LTS. Its over on the STUDIO's github https://github.com/CreativeInquiry/relaxed_ik/tree/dev-noetic.