• ManiPylator - Part 2 - Simulation & Motion Planning

    Leo Goldstien • 05/26/2025 at 17:54 • 0 comments

    Intro

    For those who skipped part 1, let me remind you where we stand. Last time I told you about how I 3D printed a robot based on the Toolbox Robotics EB-310 Collaborative Arm design. Using off the shelf components, and an open source 3D printer firmware I demonstrated how to move each joint independently or in concert, but couldn't figure out how to get the arm to move to a specific location.
    This post follows directly and tries to answer the question: 
    how can I do something actually useful?

     

    In this chapter, we'll cover how to move a robotic arm to a
    given position and trace a path in 3D space. After which we'll apply this  knowledge in a simulator, to control a virtual clone of our arm (which I've
    started calling Manny). Finally, we'll attempt to have my
    physical robotic arm replicate the same movements we observed in
    the simulator.


    For readers who are already familiar with controlling robots, do check out my ManiPylator repo which demonstrates a complete lab environment for simulating and controlling a robot manipulator using exclusively FOSS, including Genesis, robotics-toolbox-python, spatialmath-python, SymPy, Mosquitto and Klipper.

    Describing a Robot Arm

    Having settled on a design for Manny in part 1, it would be useful to write some movement equations. Happily enough, this is a solved problem. The derivations have been done, formulas exist, and they're written in a format called Denavit-Hartenberg parameters . Briefly, by figuring out the distances and angles between the motors of our robot, we can use a stock formula to calculate where the end effector will end up. Unfortunately, this is often complicated by DH parameters being a convention, and multiples exist. Some sources report Modified DH parameters or other variants, and while not impossible to compare, I found confusing and tedious. For example, I learned that the simple act of finding an example problem and working through it can be infuriating, after more than once the answer was written using a different convention to my own.

    Although covered in depth in all the introductory texts I tried, DH parameters confused me far more than sharpened my understanding. Finding them difficult to keep straight and visualise, I was hoping for an alternative. I came upon the Elementary Transform Notation (ETS) (as described in this paper) available as part of the robotics-toolbox-python package. While still having to deal with right hand rule shenanigans, the notation immediately struck me as easier to grasp. Furthermore, breaking up the process into a sequence of elementary operations helped me visualise the task, while making finding mistakes more likely. And best of all, at the end of the process we get the same result. A formula that given a set of motor angles directly calculates the position (and direction) of the end effector.

    While DH parameters have historical traction and ETS definitely helped me "see" things clearly, the most useful way I found for describing Manny was a URDF. This XML based format is widely used in the ROS ecosystem and is often provided by vendors. In addition to the details encoded in DH/ETS, URDF also includes the capability for specifying meshes, a feature we'll soon use, when we visualise Manny in a simulator.

    Thankfully, I was exempted from handcrafting the file by using onshape-to-robot to export my OnShape model directly to a URDF, available here. After taking this welcome shortcut, I had an interoperable description of Manny that I could use with most robotics software, including robotics-toolbox-python and the recently available Genesis.

    Before we can do that, we need to take a short detour through mathland. As my goal here is to get to the cool stuff ASAP, my focus will be on the bare minimum details that I find necessary. That notwithstanding,...

    Read more »

  • ManiPilator - Part 1 - Where to start?

    Leo Goldstien • 09/02/2024 at 20:29 • 3 comments

    This is my robot. There are many like it, but this one is mine.

    This robot is my latest obsession. It is the tool I use to push myself to learn new skills. I must master it as I must master my life.

    Without me, my robot is useless. Without my robot, I am bored. I must use my robot to do cool things. I must share my findings with others for these findings might lead others to the same path, or at least get me some kudos. (Loosely based on the Rifeleman's Creed)

    Intro

    In this series of posts, I'll try to share my experiences in learning through building. Specifically, by building a six-degree-of-freedom (6DOF) manipulator, AKA a robot arm. I'll try to cover everything you need to build your own, share some relevant examples and demonstrate one way of diving into robotics. But first, I'd like to clarify my reasoning. 

    Why write "yet another robotics tutorial"? Over the years I made many attempts at getting through an introductory robotics text book. The first attempt was given up on quite early, retaining little beyond some basic definitions. On successive attempts I had little more success. A promising new book or tutorial might catch my eye, I'd spend a few weeks working through example problems and inevitably giving up yet again. Not only did the maths seem impenetrable, the goal of "doing cool stuff™" was nowhere in sight. 

    Not wanting to spend hard earned cash on yet another hobby that ends up collecting dust in a cupboard, I decided on a foolproof test. "If you get through one of those books" said I, "that means you're into the hobby enough to put money on it". As should be clear from the above paragraph, no such luck. The urge to play around with robots never left, and scaling the mountain of introductory robotics never seemed any more achievable. 

    Thankfully, my wife resolved the conflict with a simple question: "How about we buy a 3D printer? I heard they're getting cheap". Agreeing excitedly, I immediately knew the answer to her next question: "What will you build with it?". "A robot" was my response.

    Some time later, we're doing a sanity check with a relatively functional arm. We were trying to make the arm follow a specific path and return to it's initial position, but couldn't get it  right. Making the arm to return to an initial position was straightforward, but tracing out a path just didn't seem to work. In hindsight, why would it? I was doing it all wrong. 

    "Maybe all those matrices are actually good for something?" I wondered, uncertain.

    Since then, I've become a close personal acquaintance with a variety of matrices, even of the rotational and homogeneous persuasion. Similarly, quaternions no longer seem so malicious nor are reference frames a confusing jumble of notation & convention. There's still a lot to learn, but failing at controlling a physical robot arm helped me get over the hump of jargon and start seeing the forest through the trees. 

    Whether you're a robotics enthusiast, a maker looking to expand your skills, or simply curious about the concepts behind robotic arms, these posts might have something for you. Join me as we delve into my attempt to scratch a robotics itch using open source software.

    Components & Design Considerations

    It seems my plan to avoid spending money has failed. I was now in the hole for a 3D printer and who knows how much filament. When it rains, it pours and little did I know how many more purchases were in my future. At that point, being comfortable with spending actual cash, my design considerations changed somewhat. Specifically, since I was now getting access to a limitless variety of plastic parts, I felt it was important to have them make up as much of the robot as possible.

    3D Models

    Hopping on Thingyverse (and a few others), I started searching for a robot arm. Although the community created some extremely, creative, models, nothing clicked. I didn't like the look of them, you might say. Eventually, somewhat...

    Read more »