[MOC] 6 Axis Robotic Arm, 4th revision

[Glaysche]

It's been a very long time since I have posted about my robotic arm.  I have been working on it / obsessing over it for several years now and have published multiple versions on Rebrickable.  I have now published my 4th revision which is almost entirely different than anything I have posted here before.  For this reason, I decided to put it into a new topic rather than resurrecting my ancient topic.

 

Rebrickable pages (free to download Stud.io files and PyBricks code):

• https://rebrickable.com/mocs/MOC-244253/glaysche/6-axis-robotic-arm-mk4/#details
• https://rebrickable.com/mocs/MOC-244757/glaysche/6-axis-remote-control-mk4/#details

Basic stats for the robotic arm:

• 9 motors
• 2 Spike Prime hubs
• 1 Spike Essential hub
• Over 100 gears

The robotic arm is controlled by a 6 axis remote control.

Basic stats for the remote:

• 7 motors used as rotation sensors
• 4 Spike Essential hubs
• 0 gears -- all motors are directly coupled to the components to eliminate any slop

 

Here is a video showing the robotic arm being controlled by the remote:

 

Gearing

The gearing has evolved over the years.  At first, I was really interested in mechanical complexity and some clever uses of the differential to mechanically compensate for the coupling that happens when functions are transferred through a turntable.  This worked but resulted in a ton of backlash and slop in the gear trains.  This new version is focussed entirely on reducing slop and making it work as well as I could given the limitations of building out of injection molded parts.  Here are all the gears in the arm:

This is focussed on making each gear train as short and low slop as I could.  The goal is not actually to have the lowest friction.  As you can see, there are several redundant gear trains for different axes.  This is needed to be able to generate the required torque, especially in axis 2 -- tilting the whole arm.  That axis has 8 12t gears driving two turntables.  Driving the turntables with fewer gears can result in destroying axles because the torque is too high.  Having multiple gear trains also is a great way to greatly reduce backlash.  You can "pre-tension" the different gear trains so the axles act as springs pushing against each other.  The bottom two tilt axes are each powered by two motors.  The was the only way I could get reasonable speed.  I needed a ~40:1 gear ratio on Axis 3 (tilt axis at the top of the humerus) with a single motor but was able to use a 15:1 ratio with two motors, greatly improving performance.

I used a 3d printed part to be able to pass three functions through a turntable, driving axes 5, 6, and the gripper.  This was designed by @efferman.

I would have preferred to use pure Lego parts but this was needed to get the functionality I needed in a compact form with minimal slop.  Here is a view of this part in place.

It's a little hard to see the part going through the turntable.  This picture shows how short I was able to make the gear trains to drive axes 4, 5, 6, and the gripper.

Another interesting part of the gear train is the 5th axis.

I was able to use the blue 20t beveled clutch gear to transfer a function through the turntable.  I haven't seen this configuration on another model.  The extra 12t bevel gears help stabilize the blue gear and reduce slop.

All these gears needed proper bracing to function well.  This and making the basic structure more rigid is where most of my effort has gone over the last couple years.

Structure

If you look at the above pictures or download the Stud.io file from Rebrickable, you will see a very solid structure, especially in the base and shoulder modules.  Pieces are form-locked together as much as possible and I never miss an opportunity to fill a pin hole with a pin.  2072 of the 3633 parts are pins.  I made the robotic arm modular -- only a few pins attach each of the above 6 modules together.  This really helps constructing and improving it.  You can quickly isolate the piece you want to work on without taking apart more than you have to.

Control

I use PyBricks to control it.  It is the only software that can run on the Spike hubs and be able to communicate between the hubs.  It generally works quite well.  I didn't spend a lot of time of the software because it was my least favorite part of the project.  It's a bit ironic because I am actually a software developer.  It's just the software I write for my job is way more interesting than the software running on my Legos.

As part of controlling the robot, I needed to calibrate it.  I use a few sensors and the encoders in the motors to do this.

This uses color sensors for the 3 rotation axes, and a touch sensor for axis 2 -- the bottom tilt axis.  The other axes drive the motor until it stalls to find the end point.  This uses one other interesting trick.  It uses the tilt sensors in the hubs to point axes 2 and 3 straight up during the initial calibration.  This is a quick way to get things into a known state and ended up working quite well.

Parts I wish I had

Much of the evolution of this robotic arm came because Lego released new parts.  The 3x19 and 3x13 frames, for example, revolutionized most of the design when they came out.  Similarly, flip flop beams and the 3x5 flip flop L have dramatically improved the structure.  I have a list of parts that would have really helped me if they were available:

• 5L flip flop beam -- there are many places where the structure or axle support would have been much better
• 3x7 frame -- I think this would be a great boon in several structures
• 4L pin -- I could improve the strength of many structures with this.  Sometimes I am able to use 2 2L pins with a 4L bar but this doesn't work in many places
• 7x9 frame -- this will probably never happen but this would help make some things more compact
• 6L and 7L axles with stops would be super helpful in a few places.  I currently use the axle with no stop in these cases and the axle can fall out during assembly / disassembly which is unfortunate
• A few recolors into my favorite lime green, especially of flip flop beams

 

Anyway, I hope you found this interesting.  I am happy to answer questions.  If you want the Stud.io files, PyBricks code, or STL file for the custom part, be sure to download them from Rebrickable.

Edited December 22, 2025 by Glaysche

[Ts__]

Really cool and well thought out. I work with robots professionally, so I know a bit about this topic. And yes: axes 4/5/6 are particularly challenging...

Since this is already the fourth version of your work, I think you've learned and improved a lot. The video impressively shows the possibilities. THAT is Technic!

 

Thomas

 

[Glaysche]

8 hours ago, Ts__ said:

Really cool and well thought out. I work with robots professionally, so I know a bit about this topic. And yes: axes 4/5/6 are particularly challenging...

Since this is already the fourth version of your work, I think you've learned and improved a lot. The video impressively shows the possibilities. THAT is Technic!

Thanks you for the kind words.  It's been a fun project.

Oh yeah, I wanted to show a comparison between version 2 which I had previously posted and this version in terms of gears.

Version 2:

 

Version 4:

 

The bottom two axes have similar gear trains (but different support structure not represented in these renders).  Axes 3, 4, 5, 6, and the gripper are completely different.  Version 2 has around twice as many gears.  I still have version 2 built because I love the complexity but version 4 works way better and has a better range of motion.

[SNIPE]

There may be a stronger way to have drive going thru the turntables without needing a few 12 tooth single bevel gears and the blue clutch gears but I'm still experimenting with that. I tired knob wheels but they were 1L further out on either side of the turntable, so there was an axle with 3 knob wheels in series going thru the turn table, then a knob wheel meshed at 90 degrees on both ends.

I originally tried the 3x3 disc connector that has 2 pinholes and 2+1 axle holes as well as some stud pins and 58176 baroke eyes but they are too wide for the teeth on the knob wheels.

I know that your bevel gears spin when the turntable spins so it's simpler in that respect but yeah, finding something that can go inside of the turntables while not jam against them is hard.

[Glaysche]

26 minutes ago, SNIPE said:

There may be a stronger way to have drive going thru the turntables without needing a few 12 tooth single bevel gears and the blue clutch gears but I'm still experimenting with that. I tired knob wheels but they were 1L further out on either side of the turntable, so there was an axle with 3 knob wheels in series going thru the turn table, then a knob wheel meshed at 90 degrees on both ends.

I originally tried the 3x3 disc connector that has 2 pinholes and 2+1 axle holes as well as some stud pins and 58176 baroke eyes but they are too wide for the teeth on the knob wheels.

I know that your bevel gears spin when the turntable spins so it's simpler in that respect but yeah, finding something that can go inside of the turntables while not jam against them is hard.

For this application, the torque is actually pretty low since both get geared down more for axis 6 and the gripper.  The thing I have tried to optimize for is reducing slop.  One source of slop is when the 9L axle bends and the 20t clutch gear tilts.  The extra 12t bevel gears help reduce that.  Another thing that helps reduce the axle bending is replacing the 9L axle with an 11L axle and adding additional axle support on the outside.  Aesthetically, I really wanted to reduce or eliminate anything sticking out beyond the 9L width of that section of the robot so I ended up with the solution presented.

[2GodBDGlory]

Nice work! It's fun to see another development of that project

[Aleh]

There are ways to lay 3 functions through a turntable avoid using cusom parts. :)

 

[Glaysche]

16 minutes ago, Aleh said:

There are ways to lay 3 functions through a turntable avoid using cusom parts. :)

I tried that very early in this project.  I’m not sure if it was exactly this design but similar.  I was very hopeful at the time but I couldn’t make it work.  It was super bulky and had a lot of backlash.

My only hope is for Lego to someday release a part similar to the 3D printed part.  There’s probably not much hope of that. :(

[Aleh]

17 hours ago, Glaysche said:

There’s probably not much hope of that. :(

Indeed :(

[Glaysche]

@thomas92, continuing the conversation from the older thread. I was just thinking that it might be possible to split up the motors and hubs differently to eliminate the 3d printed part.  If I put a 6 port hub on the humerus, it can connect to the motors for axes 3 (2 motors), 4, 5, and the sensor for axis 4.  That’s a total of 5 ports.  Then I could put 2 motors and a Spike Essential hub on the wrist.  Those two motors would control axis 6 and the gripper.  I might be able to use the small angular motor for those—they need lower mechanical power than the other axes.  Even the Spike Essential hub is pretty bulky but maybe this could be made to work.  Instead of transferring 3 functions through the turntable, only one function would go through, eliminating the need for the 3d printed part.  Could be a good solution.

[ord]

@Glaysche I was thinking of doing the same thing with the spike essentials hub on my robot arm (but decided not to mostly because the hub was too expensive).

I think it's a good idea and not too heavy if you use the small motors (or just one motor and pass two functions through the turntable with a differential). The essentials hub would also give you orientation data for the end effector, which could be useful if you end up doing inverse kinematics.

By the way, thanks for sharing the updates. That remote control setup is really nice!

[TeamThrifty]

Why doesn't TLG do something like this at full flagship scale? For those of us that couldn't give a sh!t about shelf-queen display models and actually want to engage in clever engineering, it would be excellent

1000 times more interesting than car-coma. 

[thomas92]

Quote

The essentials hub would also give you orientation data for the end effector, which could be useful if you end up doing inverse kinematics.

Interesting idea. The hub wouldn't be placed at the very end right.. and you would only have the rotation, not the position. Can probably do some clever tricks with that though. Another thing to take into account though is that the IMU is not 100% accurate:)

I've been thinking about adding a mini camera either in the end effector or somewhere at the base of the hub. And then use ArUco markers (via black and white LEGO studs) and some computer vision to figure out the position of the camera / end effector relative to the base.

Adding in non-LEGO parts is a bit of a last resort though.

Another idea (in theory) is that you could attach the small angular motor at a joint purely as absolute encoder. This has the downside of more space / motors / ports needed. But you could then very easily retrieve the absolute position of that joint.

Finally... even though the motors are geared down, and one 0-360 degree position can map to many joint positions, the number of joint positions are limited. If you combine that with the limited number of positions the other joints can be in (based on their motor positions), you already have a smaller solution space than all possible configurations. 

I'm probably a bit extreme in this but a LEGO robotic arm that instantly knows where it is in 3d space would be so cool.

Quote

Why doesn't TLG do something like this at full flagship scale? For those of us that couldn't give a sh!t about shelf-queen display models and actually want to engage in clever engineering, it would be excellent

I still remember building this Mindstorms robot arm as if it was yesterday🥹 

 

[Toastie]

8 hours ago, TeamThrifty said:

Why doesn't TLG do something like this at full flagship scale? For those of us that couldn't give a sh!t about shelf-queen display models and actually want to engage in clever engineering, it would be excellent

Because shelf-queen display models sell like good Danish beer . Clever engineering sells like ... uhm ... well, Danish tap water.

I'd go for sure with the tap water - there are many good beers around.

Best
Thorsten 

[ord]

2 hours ago, Toastie said:

Because shelf-queen display models sell like good Danish beer . Clever engineering sells like ... uhm ... well, Danish tap water.

. The unfortunate truth. I too would go with the tap water.

5 hours ago, thomas92 said:

The hub wouldn't be placed at the very end right.. and you would only have the rotation, not the position. Can probably do some clever tricks with that though.

I guess there are a few places it could be placed - my thinking was to place it between joint 5 and joint 6 and determine the orientation error at that point.

5 hours ago, thomas92 said:

I've been thinking about adding a mini camera either in the end effector or somewhere at the base of the hub. And then use ArUco markers (via black and white LEGO studs) and some computer vision to figure out the position of the camera / end effector relative to the base.

That is a great idea. Do you have any idea which camera and/or software you might use?

6 hours ago, thomas92 said:

Another idea (in theory) is that you could attach the small angular motor at a joint purely as absolute encoder. This has the downside of more space / motors / ports needed. But you could then very easily retrieve the absolute position of that joint.

Finally... even though the motors are geared down, and one 0-360 degree position can map to many joint positions, the number of joint positions are limited. If you combine that with the limited number of positions the other joints can be in (based on their motor positions), you already have a smaller solution space than all possible configurations. 

I'm probably a bit extreme in this but a LEGO robotic arm that instantly knows where it is in 3d space would be so cool.

For me, using the relative positions of the drive motors works very well to determine joint angles (and I think is more precise than direct joint encoders would be, because of the gearing down). I just save the motor positions to the hub every time I shut it down, and if they ever get out of sync with the joints I re-home the joints to the end-stops.

[Glaysche]

I put together a prototype of the wrist and elbow that doesn’t use the 3d printed part.  In total, I think it is a bit shorter and lighter weight than the version using the 3d printed part.  The gear trains have less backlash.  The wrist is only 2L longer than the previous one.  I think I have an idea that will shrink it by 1L.  The elbow is 3L shorter and has a better geometry.  I ran out of time tonight so I haven’t updated the code and tried it out yet.

i was able to fit the small angular motors somewhat well.  It’s unfortunate they stick out like that.  There is no obvious place to attach the Spike Essential hub.  I put it in a temporary spot I can use for testing. It needs to be on the wrist somewhere to the left of the middle turntable in this picture.

[Glaysche]

11 hours ago, thomas92 said:

Interesting idea. The hub wouldn't be placed at the very end right.. and you would only have the rotation, not the position. Can probably do some clever tricks with that though. Another thing to take into account though is that the IMU is not 100% accurate:)

I actually do use the IMU of the hub on the humerus in the initial calibration.  I broadcast the tilt to the hub in the shoulder and use that signal to quickly point the arm straight up.  I later use the touch sensor on the base to get an exact calibration of that axis.  Using the IMU like this has been helpful.  My goal with the calibration routine is to be able to start in any position and get to a known state.

Oh, the 6 axis remote control uses the absolute position on the angular motors to come up instantly calibrated. 

16 hours ago, TeamThrifty said:

Why doesn't TLG do something like this at full flagship scale? For those of us that couldn't give a sh!t about shelf-queen display models and actually want to engage in clever engineering, it would be excellent

1000 times more interesting than car-coma. 

I agree.  Doing robotics has been much more fun than the shelf queens.  I do usually end up building many technic sets but always take them back apart to use the parts to build something more interesting.  I don't have nearly enough shelves to actually keep them assembled, anyway!

[Glaysche]

4 hours ago, ord said:

For me, using the relative positions of the drive motors works very well to determine joint angles (and I think is more precise than direct joint encoders would be, because of the gearing down). I just save the motor positions to the hub every time I shut it down, and if they ever get out of sync with the joints I re-home the joints to the end-stops.

Yeah, with the gearing down, the positioning seems quite accurate.  This model has gear ratios in the range of 7 to 25 for the different axes.  With those ratios, you can position within a fraction of a degree theoretically.  Some of them have low enough backlash to actually see that in practice.

[TeamThrifty]

9 hours ago, Glaysche said:

but always take them back apart to use the parts to build something more interesting

This is the reason lego exists my friend  If it was meant to stay together forever it would come with glue!

[thomas92]

Quote

That is a great idea. Do you have any idea which camera and/or software you might use?

This is the one I bought a while back: https://www.amazon.nl/dp/B0BXDKQZ1K/ref=pe_28126711_487805961_TE_item. Python/OpenCV is the most straightforward. I would really like to have a camera that works via bluetooth, though.

Quote

For me, using the relative positions of the drive motors works very well to determine joint angles (and I think is more precise than direct joint encoders would be, because of the gearing down). I just save the motor positions to the hub every time I shut it down, and if they ever get out of sync with the joints I re-home the joints to the end-stops.

If you run a geared down motor to an end stop, it will put quite a lot of force on the gears and joints right? Gravity also plays a role with regard to the resistance. Personally I'm always a bit hesitant to run a motor with a lot of force until it stalls. But too little force and it might stop before the end is reached.

The approach of saving the joint angles on the hub is interesting. I'm wondering how you detect when the joints are out of sync. As far as I know, after booting up you can only retrieve the absolute position (-180, 180) in Pybricks from the motor. You can compare this to what you stored on the Hub of course. But that still leaves the possibility the motor is out of sync but happen to land at a position that is modulus 360 the same as what you stored... I'm a bit confused now 😅  I guess the chance of this happening for all connected motors at once is very small.

[ord]

On 1/22/2026 at 3:43 PM, Glaysche said:

I put together a prototype of the wrist and elbow that doesn’t use the 3d printed part.

Looks good - infinite rotation on joints 4 & 6 and with all Lego parts .

15 hours ago, thomas92 said:

If you run a geared down motor to an end stop, it will put quite a lot of force on the gears and joints right? Gravity also plays a role with regard to the resistance. Personally I'm always a bit hesitant to run a motor with a lot of force until it stalls. But too little force and it might stop before the end is reached.

The approach of saving the joint angles on the hub is interesting. I'm wondering how you detect when the joints are out of sync. As far as I know, after booting up you can only retrieve the absolute position (-180, 180) in Pybricks from the motor. You can compare this to what you stored on the Hub of course. But that still leaves the possibility the motor is out of sync but happen to land at a position that is modulus 360 the same as what you stored... I'm a bit confused now 😅  I guess the chance of this happening for all connected motors at once is very small.

I've found a duty limit of around 40% to be the sweet spot most of the time. As long as the end stops are properly braced there are no problems.

I don't detect in the program when they're out of sync. I save motor angles to be able to quickly test/use the robot in a reasonably accurate position without having to home it. Exactly - compensating for absolute position changes should make this more accurate, as long as the motors haven't moved by +/-180 degrees or more. This is probably worth trying :).

Edited yesterday at 07:53 AM by ord

[thomas92]

Quote

compensating for absolute position changes should make this more accurate, as long as the motors haven't moved by +/-180 degrees or more. This is probably worth trying :).

Great suggestion!