Search the Community
Showing results for tags 'kinematics'.
Found 2 results
-
As there is not much going on here yet, and my own projects with EV3 are not working out as I would want, I'll post this video from someone who designed a 6 DOF with 1x RI. He used my program I made to be used for a 6 DOF with 2x EV3 and changed it to work without homing sensors, as it has only 6ports, each needed for a motor. With my help explaining how I build up the program, and how he could make it work and what changes would be needed. He did manage to get the forward and inverse kinematics working, allowing the 6DOF to make straight lines and smooth movements, each axis motion ending at the same time. Before he started I thought the calculating power of the RI would be to slow, but it seems to be even faster than with EV3! Cycletimes are faster allowing smaller intermediate steps. If I had a RI I would try to make this aswell to compare the EV3/RI 6DOF. -
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)
