[WIP] Delta Robot using control+ and pybricks

[schraubedrin]

Seeing a delta robot in real life finally made me try to built one myself.
As it's not only a model but (more or less) complicated robotics as well, i'm learning a lot.

But first, here's a clip of the current state:

(Some day i will learn proper lighting, filming and editing. But not during this project)

The project started with a proof of concept, just to get a feel for the mechanics at play.
Here i understood how the twin rods on each arm remove all rotational degrees of freedom by only allowing parallel movements.

As i was pondering whether to revive my old RCX or investing in used mindstorms, i remembered the existence of pybricks.
And oh boy is it great! I was prepared for an evening of IDE installs and debugging, but everythinig just worked
All it needed was a bluetooth dongle, a Windows restart and the browser (although i prefer the offline program to stay independent)
I had the Control+ hub LED showing a rainbow not even 30 minutes after i started this endavour

With this proof of concept, the next step was to actually build the delta robot.
Although the end goal is to pick up parts with a pneumatic grapper, i concentrated on the movement platform for now.
The result is very ... prototype-y.
The whole assembly is held only by the + holes in those three Technic Beams in the very center:

The motors just sit on the Technic Pins of the frame assembly, being held there by bent Technic beams

I geared down the motors 3:5 for increased accuracy of the angle measurements and to give the mechanics more space to move:

With the construction "completed" (i'll rebuild it once i feel like i know what i'm doing), there was nothing to do but maths.
To move the platform to a specific point, each lever has to be in a specific point, with quite complex dependencies.
There are two calculations you might have to make:

• Forward Kinematics: given the angle of each lever/motor, what is the position of the effector in space?
• Reverse Kinematics: given a specific point in space, what angle does each lever/motor have to be to get the effector there?

Fortunately, i found this super interesting github repo, where someone much smarter than me implemented all the calculations in Python (and much more).
I copied his reverse and forwards kinematics code directly into pybricks. But the different math libraries used made me uncertain of the results.
So i tried to understand the calculations myself, for which i highly recommend this tutorial on a (defunct) robotics forum.

Trying to test my code, i stumbled upon a problem i haven't been able to solve: i can't get reliable absolute angles of the XL motors.
Upon startup the reported motor.angle()s are always different.

According to the documentation, there is a way to reset motors to their absolute values with motor.reset_angle(), but only if they support it.
So it seems the XL motors only show the differential angle? The documentation regarding those motors is very sparse.
In one of the best collections of lego motor data, it is said that they have "an absolute encoder".
Internally, they look as if they would support it, but i can't find anything about this (hall sensor?) IC online.


@Pybricks, can you confirm or deny whether it's possible to get the motor position of an Powered Up L motor without manual calibration?

Right now i implemented a manual calibration routine, which is a little bit annoying because i have to lift the whole robot in the air for it to work.

Well, back to testing my kinematics code. The first test that came to mind was moving on a constant level.
To detect deviations from the plane, i put a pen in the middle that would draw the shape i programmed, with the intensity of the line showing the quality of the movement.
Fortunately i found this small, ten year old pen, that fit inside the effector quite easily:


Only after doing my first test did i realise that i effectively built a printer
Here's some more artwork:

The latest setback were empty batteries from all my testing.
Based on a model i can't find any more (sorry!), i designed and printed a dummy battery with an USB-C PD trigger board set to 9V.
Now i can supply the energy straight from a wall plug. Much more economic with all the debugging i have to do.

 

So, what's next?

• Implement smooth movement: have the hub calculate the next movement during the current one and understand where this start-stop behaviour comes from
  Understanding the behaviour of track_target() and run_target() together with multasking and coroutines seem to be the best bet here.
• Build a pneumatic gripper (and buy/steal/accuire the motor for it)
  It has to be fast acting and work with one motor allone. Finally a legitimate reason to use an airtank
• Find something to grip and move that fits in the relatively small action radius
  I was thinking of something along the lines of Tower of Hanoi, with different colored stacks of pulley wheels (although they might be to big)
   

Edited November 29, 2024 by schraubedrin
so many typos

[Glaysche]

I love this!  I am a sucker for all things robotic.

I've only used the absolute positioning on the angular motors (https://rebrickable.com/parts/69730/motor-large-angular-position-light-bluish-gray-housing-black-wire/ and the medium and small versions as well).  With those, you are able to access the absolute position.  I at least used it from Mindstorms software -- I haven't used PyBricks.  The angular motors also have a printed mark on them for the 0 position.  That helps lining things up when you build it.

[oracid]

This looks very interesting. Congratulations. I'm looking forward to the video.

[Heppu]

Always cool to see delta robots and robotics projects in general! I have such a fondness to having built a few of delta-robots with Mindstorms myself. Excited to see your progress and final application with this.

I'm unfamiliar with the motors you are using, but if you are unable to figure out the starting angle of your motors, you could always implement some startup sequence which raises all the motors slowly up against some stopper and try detect when they stall to reset the encoder to a known angle.

For smoothing out movements, consider also how much slack is introduced by  the gears. If you suddenly switch the direction you move the motor in, the slack in gears can cause some jerkiness in the movement if not accounted for. This effect can be really noticeable especially in delta-robots where the end effector can be far away from the supporting structure.

 

Edited November 30, 2024 by Heppu

[2GodBDGlory]

Very cool! I'm mostly familiar with these kinematics from Delta 3D printers, and they're just amazing to watch!

[schraubedrin]

On 11/29/2024 at 9:29 PM, Glaysche said:

I love this!  I am a sucker for all things robotic.

Thank you, i'm developping feelings for robotics as well

 

On 11/29/2024 at 9:29 PM, Glaysche said:

With those, you are able to access the absolute position

I know of those, i really have to try them in pybricks to debug my issues.
But right now, i only have the motors of 42100 on me. And not that much Lego Money in my budget

 

On 11/30/2024 at 7:11 AM, oracid said:

I'm looking forward to the video

Right now i can only give you the first gif.
I wasn't sure how to embed it, does it work when you click on it?

 

On 11/30/2024 at 1:12 PM, Heppu said:

I have such a fondness to having built a few of delta-robots with Mindstorms myself

That's awesome, i really feel like i'm stepping on the shoulders of giants with this project

 

On 11/30/2024 at 1:12 PM, Heppu said:

the slack in gears can cause some jerkiness 

Thanks for the pointer, i might be in luck here because everything is so small.

 

On 11/30/2024 at 1:12 PM, Heppu said:

raises all the motors slowly up against some stopper

That was my idea, just that in the current design, it's not possible to raise them all to the top at the same time.
But i think i'll follow your advice and implement some stoppers for this to be possible.
My overoptimising brain will have to accept the minuscule loss in total possible range

 

On 11/30/2024 at 4:39 PM, 2GodBDGlory said:

Very cool! I'm mostly familiar with these kinematics from Delta 3D printers, and they're just amazing to watch!

Thank you!
Seeing the Prusa Delta printer might be one of the reasons this project exists

 

 

Unfortunately it might be some time until there are interesting updates.
Right now there's life happening and mostly code to refactor...

 

Edited December 3, 2024 by schraubedrin
added link

[gyenesvi]

Wow, this is pretty cool, I like the fairly smooth movement of the actuator, I did not expect such precision from a lego machine. And if that can be improved, even better.

On the mechanical side, I have a question. Does this type of actuator movement guarantee that the head moves in a plane, and does not lift up? I guess that would make sense. Do you have more details of that?

On the software side, you say that there is a start/stop pattern due to commands following each other and you wish to improve that. I think a key would be to have an infinite loop in which you are constantly calculating where the head is and where it wants to be and continuously correcting course instead of issuing distinct commands that have a beginning/end. Is that what target tracking does? I have never tried that in Pybricks.

As for the XL motors, even if absolute positioning works (I think it should) they are not so precise at positioning in my experience. Did you try the L motors? They are much better in that respect. 42100 has at least 3 of them.

[Berthil]

On 11/29/2024 at 8:00 PM, schraubedrin said:

can you confirm or deny whether it's possible to get the motor position of an Powered Up L motor without manual calibration?

I'm making a six axis robot arm and I have programmed in such a way that at shutdown it always goes to the start position (also called shutdown position), or if something goes wrong, I have a manual mode with a remote where I can move everything manually to that position. If you then shutdown and startup the hub and make all movements relative to that position, no calibration is needed as the start position is the calibration point.

Edited December 3, 2024 by Berthil

[oracid]

8 hours ago, schraubedrin said:

Right now i can only give you the first gif.
I wasn't sure how to embed it, does it work when you click on it?

Yes, it works !  Sorry, I didn't realize it was an animated GIF.

[schraubedrin]

On 12/3/2024 at 10:56 PM, gyenesvi said:

guarantee that the head moves in a plane

If i implemented the reverse kinematics correctly (and it seems i did) and input points along a plane, then yes, it moves in a plane.
In case you're asking about the degrees of freedom, i can only forward you to the wikipedia article and the wider internet.
Unfortunately i can't find the article which explained such robots for the classroom any more

But i can highly recommend you try to build an unpowered version, it helped me a lot in understanding the behaviour!

 

On 12/3/2024 at 10:56 PM, gyenesvi said:

a key would be to have an infinite loop

On 12/3/2024 at 10:56 PM, gyenesvi said:

instead of issuing distinct commands that have a beginning/end

pybricks is kinda doing this with the wait=False flag, but i'm thinking about a redesing that's similar to your recommendation.
The problem is the step of generating the next target point.
This calculation takes some time and i only need to target the new target once the old target has been reached (this sentence is weird).
My idea is to use a "current target" and "next target" to look a step into the future. This way there shouldn't be a waiting time once the current target has been reached.

 

On 12/3/2024 at 10:56 PM, gyenesvi said:

they are not so precise at positioning in my experience

Right now i'm trusting the 1° resolution i get from the pybricks API.
But you're making me curious, once i get the heart (and time) to rip those L-Motors out of my 8043 MOD, i'll compare the accuracy of both.

 

23 hours ago, Berthil said:

the start position is the calibration point

Thanks for validating me, that's how i started, with "lever is horizontal" as the starting point and my fingers pushing it there as my remote
The many mishaps of my programming and the surprising sensitivity of the robot to the angles made me abandon this way of calibrating.

 

[oracid]

7 hours ago, schraubedrin said:

If i implemented the reverse kinematics correctly (and it seems i did) and input points along a plane, then yes, it moves in a plane.

Moving on a plane is not an obligation. There is nothing to prevent you from using this technique to make what I would call a wrist. Here is a video that shows this possibility.

https://youtu.be/3fbmguBgVPA?si=vd-vmWGNSk8QwJoS

 

[schraubedrin]

8 hours ago, oracid said:

Moving on a plane is not an obligation. There is nothing to prevent you from using this technique to make what I would call a wrist. Here is a video that shows this possibility.

Well, to clarify, this traditional design with three pairs of parallel links moves on a plane.
The video illustrates this point quite well: all translations have the pairs moving in parallel, you only get rotational movement by splitting the movement of each pair of linkages.

One could implement further degrees of freedom with this rotational actuator design (your video uses translational movement as prefered by e.g. 3D printers) by separating the levers so that each link can move independently.

 

 

On 12/4/2024 at 7:01 AM, oracid said:

Yes, it works 

I'm glad, thanks for checking!

[gyenesvi]

36 minutes ago, schraubedrin said:

Well, to clarify, this traditional design with three pairs of parallel links moves on a plane.

Hmm, after looking at some videos and the mechanism online, I don't think that's accurate. I think what you mean is that without separation of the links, the actuator head remains parallel (or the pencil perpendicular) to the ground (base) plane. But you can raise and lower the actuator, just as shown in the video of @oracid, so you can move it out of a single plane, and if you want to keep it in a single plane (as you did in your example drawing machine), you have to calculate the right angles for the 3 motors. It seems relatively simple though, I wonder how complicated the inverse kinematics gets, whether there's a closed form for calculating the motor angles, or is there a need for some iterative approximation algorithm. I'll try to look into it. The whole machine looks simple to build as well, so I feel tempted to try this. I have a Mindstorms kit I have never really used for anything, maybe this is a good one :) I think the angular L motors would work fine for this without any gearing needed, and it also seems easier to integrate them due to their shape.

36 minutes ago, schraubedrin said:

The video illustrates this point quite well: all translations have the pairs moving in parallel, you only get rotational movement by splitting the movement of each pair of linkages.

And it's interesting to see how rotation and tilting can also be achieved with link separation.

 

[Heppu]

I also did not realise the first image was a video. The functionality looks pretty nice already!

The inverse kinemattics I dont feel are complicated at least for the 3 degrees of freedom robot being built here. Maybe for the 6-DOF ones like in the video linked by oracid it starts to get complex. For 3-DOF you just need to adjust the relative speeds at which each of the 3 motors turn to have each motor reach the desired angle at the same time.Trajectory generator is required for longer movements to generate "middle points" or otherwise some inverse kinematics solutions that have the end effector travel trough the x-y origin between 2 far away points can lead to the end effector not maintaining linear movement between the points.

Here are some pics and videos of my attempts at 3-DOF Delta robots if interested for inspiration https://www.flickr.com/photos/heppu/albums/72157704649606362/.

[Stereo]

Should be a closed form solution with some trigonometry I would think.  In z-up coordinates, use the x,y position to figure out how much parallelogram skew is needed for each motor, which effectively shortens the second length in the arm, and that simplifies it into a 2d 2dof arm which I think you can just solve using a triangle with positions of 2 vertices and side lengths known.  Though one of the images in this thread doesn't actually use parallel links, which would make it complicated (and probably not actually strictly 3 translation DOF, there'd be some rotations)

Edited December 7, 2024 by Stereo

[schraubedrin]

On 12/5/2024 at 5:41 PM, gyenesvi said:

I think what you mean is that without separation of the links, the actuator head remains parallel (or the pencil perpendicular) to the ground

Thank you, yes. That's what i meant by:

On 12/4/2024 at 11:33 PM, schraubedrin said:

If i implemented the reverse kinematics correctly (and it seems i did) and input points along a plane

 

 

On 12/5/2024 at 5:41 PM, gyenesvi said:

I wonder how complicated the inverse kinematics gets

On 12/7/2024 at 9:47 PM, Stereo said:

Should be a closed form solution with some trigonometry I would think

I highly recommend the archived forum i linked in my initial post.
The inverse kinematics is relatively simple with solutions that can be calculated independent of each other.

 

 

On 12/5/2024 at 5:41 PM, gyenesvi said:

I'll try to look into it. The whole machine looks simple to build as well, so I feel tempted to try this.

Please do, this was exactly my starting point as well (without the mindstorms set lying around)

 

On 12/5/2024 at 7:49 PM, Heppu said:

Trajectory generator 

This is my next goal in programming, inspired by the guy on github showing the movement of a glass of water without spilling