Deskbot Part 3: 3D Modelling

Yuan Gao (Meseta)
Meseta builds Robots
5 min readAug 22, 2020

In order to do proper path planning and collision checking, any robotics stack needs to have an understanding of the geometry and arrangement of joints in a robot. Also, to help with design, it’s also helpful to have a visual representation of the robot as well so that we can compare what we’re seeing in the real world with what’s going on in the robot’s stack easier.

To achieve this, I will model up the robot in 3D, and export two models — a visual representation of the part to help me, the human, do debugging. And a simplified blocky representation of the robot that will be used for collision calculations. This collision model should be simple to reduce computational complexity.

The software: SketchUp free version

The software I will use for this is Sketchup’s free online version. I’ve been a long-time Sketchup user, as a relatively simple and free tool for 3D printing. It’s not quite parametric like other CAD software, but it suits my purposes just fine. I’ve used various CAD tools in the past owing to my previous work as an engineer working with motors, but I can’t say no to Free.

At some point in 2018 or 2019, Sketchup pulled support for their free downloaded product, and went full-time online. I had initial reservations for this, never before having used an online version of desktop software that was any good. But surprisingly, Sketchup’s online version is quite close in functionality to their downloaded version. Aside from slight niggling of the smaller toolbox hiding more tool options in hover menus that make it slower to switch tools, it does mostly the same thing as before.

The modelling process

I checked for some engineering drawings or existing CAD for this robot online, and there seems to be multiple versions of it, with slightly varying dimensions. I’ve checked the dimensions of those online versions against the robot and they don’t all match, so I’m guessing this design has been widely copied and varied across manufacturers, and unless I can get the actual CAD this particular manufacturer I use, there’s always going to be some uncertainty.

Therefore, I’m going to just reproduce the robot from measurements myself.

I also have to reproduce the MG996R servos, which again, are supposed to be a standard size, but vary slightly. So I’ve measured the ones I have and have produced a model for them. It’s nice to be able to put the two parts together in CAD, and then measure clearances and distances between the geometries, and validate that they are what they are in real life — it means I’ve reasonably accurately measured and reproduced the model.

Here’s a quick timelapse of creating a part. It doesn’t take too long to do once measurements are taken. As you can see, with Sketchup not being parametric, a lot of the modelling process involves dropping guides out to the correct distances first, and punching in numerical values (note the input box in the bottom right, this is how you usually get exact measurements in Sketchup). This makes editing parts later a bit more challenging, but again, for a simple project like this, it serves the purpose fine.

The completed parts

The parts are completed. For the gripper, I went with a simplified model, since this was for visual appearances only. The interesting thing about the gripper is that it’s a somewhat complex mechanism, that is meant to be in collision sometimes, so I’m keeping it modelled in its fully open position for now.

Also note that I haven’t modelled in any of the screws, but I have modelled in the holes. The reason for this is that the holes can be used to help align the parts when assembled, but the screws are just an unnecessary additional level of detail. The screws do stick out slightly and should be factored in in the collision model, but this can be done by just expanding the bounding box a little.

The parts can now be put together in their assemblies, and grouped together by the parts that are rigidly connected, so that they can be exported as groups.

Collisions

To model the collisions, for each group, I make an approximate blocky representation, trying to keep to mostly blocks. Each block is a little bigger than the model they contain. The most important part is that the blocks are correctly sized so that they don’t overlap at the joints, otherwise the robot will complain that it is always in self-collision and fail to make any moves.

Note that none of the wires are correctly modelled. This is sometimes a problem, but flexible parts like wires are notoriously difficult to deal with, and the best option has been to manage the cables in a way that they won’t easily become tangled in the robot or the environment. Ideally robots have internal cables, but a simple robot like this, I’ll mostly be using a method of “hope it doesn’t happen, and when it does, apply more zipties and duct tape”

With all the modelling completed, I will export as .stl files and in the next part I’ll start constructing the robot’s URDF to put these models into the robot workspace.

--

--

Yuan Gao (Meseta)
Meseta builds Robots

🤖 Build robots, code in python. Former Electrical Engineer 👨‍💻 Programmer, Chief Technology Officer 🏆 Forbes 30 Under 30 in Enterprise Technology