Programming Robot Arms: Why it's Tricky Even for Experienced Roboticists
If you've ever tried programming a robot arm, you'll know it's no easy feat. Even for experienced roboticists, working with robot arms presents a number of challenges. Let's take the seemingly simple task of moving the arm from point A to point B, for example:
Firstly, each robot arm has its own programming language, which can be quite different from more modern programming languages like Python or C++. For example, ABB robots use RAPID while Universal Robots use URScript. These programming languages are similar to low-level languages and are not as expressive as the modern languages developers are used to.
Another challenge with programming robot arms is something called robot singularities. This is when the robot arm is unable to move in certain directions, which can occur when planning robot trajectories by specifying the end-effector desired pose. Robot singularities can cause the robot arm to become blocked and unable to perform its intended function. Together, programming robots manually in the robot programming language combined with debugging and fixing robot singularities leads to long programming and deployment times. A robotics engineer may spend around 20 minutes programming a single robot motion, and several weeks programming the entire application.
Finally, there's a trade-off between compute and execution time in open-source motion planning methods. Optimization can find fast motions at the expense of long computation time, while probabilistic methods find a solution quickly, but the solution is usually sub-optimal
But, there is an alternative to traditional robot programming. The Jacobi platform allows you to program any robot application using Python or C++, with the Jacobi Studio providing a user-friendly interface for visualizing and debugging your code. The resulting motions are fast to compute and execute, and don't suffer from singularities. Check it out Here.
Blog overview