schraubedrin

That's incredible! I love the idea of such a machine built in Lego. Looking forward to following your process.

Why don't you use a 24/12 gearing? This is achievable with a 1 stud vertical offset.

Thank you for those videos, they are great inspiration! Incredible that they manage to position those balls that precisely!

I think that's a good idea, to make this two separate contests (maybe with at least one vehicle in between to prevent burnout).

YES! i'm not sure i will be able to participate, but i love the idea. These kind of models really are underrepresented in the LEGO lineup and i feel in the MOCs as well.

These three are all the same ecosystem, just different controllers (as far as i know) pybricks supports them all.

That's a nice bike I love the detailed engine with timing belt and ignition. Do you have more detailed pictures/video on it? Stream of characters / no pictures here (Firefox) right click -> open image in new tab leads to some M$ OneDrive error reading something like "this element can't be loaded at the moment".

Thank you, yes. That's what i meant by: 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. Please do, this was exactly my starting point as well (without the mindstorms set lying around) This is my next goal in programming, inspired by the guy on github showing the movement of a glass of water without spilling

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. I'm glad, thanks for checking!

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! 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. 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. 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.

Thank you, i'm developping feelings for robotics as well 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 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? That's awesome, i really feel like i'm stepping on the shoulders of giants with this project Thanks for the pointer, i might be in luck here because everything is so small. 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 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...

Maybe that's pedantic, but do you want to play with robotics or with lego robots? Just to prevent frustration: depending on how custom of a robot you want to build, making it out of lego might be more difficult than other methods. If you're sure, you want to build robots with lego ... Welcome to the dark side There are a lot of different ways to go about it, but from your first descriptions it seems like more complex operations. There i agree with @Lok24, the way to go is to use the lego controlers (Control Plus / Technic Hub, Powered Up, Spike, Mindstorms, ...) only as fancy motor drivers / sensors and do the actual calculation and program flow on your mentioned edge computing device. This has been the concept for decades, one of the more prominent ones is Cubestormer: There are so many programming languages to choose from, i highly recommend the mindstorms wikipedia entry: https://en.wikipedia.org/wiki/Lego_Mindstorms#Programming_languages Personally, i recently discovered how easy pybricks is to use, can highly recommend My suggestion for you, as a first step: Buy a Control+ or Powered Up set, where you're comfortable with the price (used might be a good idea) and just try to program it with a firmware you're comfortable with (again, i had a great experience with pybricks)

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)

Exactly my thoughts on hearing of this concept for the first time That's why i had to build it. My pleasure, i'm glad other people find this as fascinating as me This version has the advantage of a similar range of motion in every direction. I'd guess the traditional platform is stiffer, depending on the design. And i'm pretty sure the reverse kinematics are more complicated if the joints are not on a plane

Somebody told me about a special form of movement platform that's a spin on the traditional Stewart platform: Instead of positioning the actuators in a flat triangle, they are mounted in pairs on the surfaces of a cube. As there are still six actuators, it's still able to move and rotate in any direction: The actuators aren't mounted in universal joints to simplify the construction and make it more compact. To get the necessary two degrees of freedom to rotation, the actuator can pivot in one direction and rotate around the actuator axis: The most time went into finding good positioning for the connection points so that there is enough movement range without internal collisions. This proved to be the hardest part because their positions are quite closely connected, so there isn't as much freedom in construction as you'd expect. In the end i found a nice balance of movement range and not too many collisions. Not making it a cube would have improved the movement a lot, but i liked this design much more I made one face of each the actuator side and the moved side as see-through as possible.