Jonas

Content Count
240 
Joined

Last visited
Posts posted by Jonas


This is a very clever design of a machine that solves a practical task. (BTW, just an hour ago I had to change a chain on my bicycle. So I know what the task is about.)

I want to show you my new robot. Its construction has been inspired by the robot seen on the webpages of the German company Orange Apps  link. It is their 3rd version of the robot, the older one could be found on their Facebook page. They sell the robot either as a building kit or already assembled. (Both are pretty expensive, though.) Anyway, the robot is really elegant, with eye catching and smooth orange shell. I looked at their videos and designed something similar, but not the same. My primary goal was to build a 6DoF robot that would be lighter and more compact than my previous one inspired by Akiyuki.
Here are several pictures:
And a video showing the current state in programming. The program written in Pybrick micropython includes modules for automatic homepositioning, sequential control between preset points and optional manual control via IR beacon. I am still working on the implementation of inverse kinematics control. Here, I must thank MrJos for showing us that it is manageable and giving us some hints.

Just to explain my motivation for a small and compact design. I am using interchangeable heads in my robotic arm (it is still WIP) and they must use the same interface. Here is an example of two heads:

5 hours ago, Horologist said:Interesting concept, but wouldn't the reduction be greater if the carrier was static and the 28t gear was the output? (12/24)*(8/28) is 1/7.
You are right. Unfortunately, in my case, connecting the carrier to the remaining construction would more difficult.
36 minutes ago, Mr Jos said:The 56T large turntable is also 1/7 reduction with a 8T gear, not 1/3?
The 1:7 ratio holds for the outer gear ring of the turntable. But in my first article I was speaking about the use of the inner 24t ring for a planetary system. Yet, I was wrong with the ratio, sorry, it should be 1:(24/8 +1) = 1:4.

10 hours ago, HectorMB said:Nevertheless, you your purpose, did you considered the 42099 planetary gears?
I did not know that special element existed. It seems pretty expensive, though.
2 hours ago, 2GodBDGlory said:Nice! Even more reduction could be achieved by replacing the 12:24 gearing with a 8:28 one, though.
You are right. In this case, however, bracing would be more difficult.

In my robotic arm, I needed a significant speed reduction for the rotation of the last moving element, i.e. no large torque, but small compact design. I tried several gearing solutions, incl. the wellknown planetary gearing with a large 56t turntable. The latter one is compact, but its 1:3 gearing ratio is not sufficiently low and also it suffers from large friction between the two pieces of the turntable.
After some experiments I came with a compact planetary mechanism that uses a small (28t) platform and a 2stage downgearing train producing 1:6 ratio, more precisely 1:6. Besides the turntable, 2 24t gears and 4 (or just 2) 8t gears. Here is a couple of pictures:
And a video showing the mechanism on a test bench:

Hi Mr. Jos,
you have done an amazing job. I have just purchased the instructions to support your wonderful work. I do not think I will copy your design but I will use it as a reference in my building attempts.
This applies mainly to your codes where I believe to find answers to some coding challenges. From your description, I believed that the codes would be included in the downloaded data. Unfortunately not. When I try to download the codes from your Bricksafe depository, it says Forbidden. Anything wrong?

On 5/7/2021 at 9:42 PM, Mr Jos said:I could hardprogram a set of coordinates with preset speeds to do some 'showing', and it would not be jerky as cycletimes would be way lower, but that was not my goal to be hardcoding a long time for 1 show run, when I can now make limitless amount of 'showruns' by teaching it with the PS4 controller just a few points, and let it do the calculating and adjusting on its own.
Your v2 robotic arm is amazing.
As to the demo shown in the video, I see a paradox there. When you navigate your arm by PS4 and store the coordinates of the checkpoints in the memory, it would seem to be more rational to store the angles of all the motors. Then, no inverse kinematic equations would be needed, as you could just move from the current angle to the next point angle.
Yes, the IK is important and you made amazing programming work, but this particular show task can actually run without it. Or am I wrong?

Hi Jos. I am glad that you go on with the project.
I tried to look at your last piece of code and I still see some multiplication terms that occur in all the three equation and that could be precomputed. It might save some milliseconds.

The Blacksmith house and Tavern fit together really well.

Thanks, Cadder, for sharing it. I have built it and verified that it works. It is a very useful and compact mechanism.

4 hours ago, ord said:@Jonas Sure, hopefully these help:
Thank you very much. I have already built it (or at least something very similar), so I can check some details now. I was not sure mainly regarding the frontrear axis where I had some problems with smooth movement. At the moment I can move the axes only by hand crank as I need to wait for my EV3 motors to become available after disassembling the current robot.
Once again I must say that your design is really nice, clever and compact. Thanks to it I learned some new stuff about parallely controlled robotic arms and found some other nice examples on youtube.

It seems that there is interest in this amazing creation. Would it be possible for you to add some more pictures from other angles? Thanks in advance.

This is a well thought mechanical solution. I am surprised by its precision. I suppose that each arm is kept only by a single (long) thread link. Am I right?
Do you think that it could be enlarged to get a slightly larger working space?

That looks really interesting and innovative!
What is that suction cylinder? A standard pneumatic cylinder with a transparent body?

Fantastic work, Berthil! You just reached Akiyuki's master level by this design.

On 1/30/2021 at 6:02 PM, Mr Jos said:When you build your new one, try putting at least 2 gears on each joint. The backlash will get smaller by just having 2, and if needed you can put the 2nd gear 1 teeth further, making the joint under tension and having no backlash at all. That is, if you put good bracing that it can not skip gears to release the tension. It is what I do on my theta1, 2gears with small tension.
Have fun rebuilding it! In my opinion it always gets better when I rebuild the same kind of machines, as you know the shortcomings of the previous.
Thanks for your advice. Actually, all my joints had at least 2 gears  simply because I followed Akiyuki's design where he had applied his longterm experience.
During the robot disassembly process I played a bit with the robot rotation assembly. When I was building it weeks ago, I could just guess the internal solution from Akiyuki's video. And now I found at least 2 major reasons for the large backlash.
First, I had used the large EV3 motor, which is known to have a large intrinsic backlash. Next time I am going to use the medium motor, which is better in this aspect.
Second, the drive train controlling the robot rotation included an 8t gear, which is also known for the largest backlash between all the Lego gears. Next time I want to use only double bevel gears that are larger and have better meshing properties.

I can just repeat what I have already written several times in this thread: Very concentrated work and wonderful results!
In your video, I liked mainly the last task when you draw the contour of the square baseplate at zero height. A master piece.
Although I noticed that you had also some visible (12 studs) deviations, namely in the corners. I suppose it is due to the mechanical limitations of the plastic material.
I wonder what will be your next big challenge.

Hello, fellow robotmak3rs, I am returning after 1 month spent by occasional programming, experimenting and testing.
The communication between the two EV3s has been managed, hence I focused on the inverse kinematic control task. My robot is a modified (simplified) version of Akiyuki's, to which I added a simple gripper. This also means that I did not have to bother with the most complicated part  wrist posing. Actually, I was dealing with a 4 DoF scheme only. I have made a diagram of the main robot parameters and coordinates:
After that I spent some time to solve geometric tasks to obtain equations that describe relations between [x,y,z] coordinates and the 4 angles depicted in the picture, both in forward and backward (inverse) direction. Then I wrote simple Python functions for each basic step in FW and INV kinematics. I decided to do it step by step rather than in a single routine as I wanted to keep control (and full understanding) in each step. I am a beginner in Python so my code is as it is. I have made screenshots of the main kinematic functions in my program.
Some other screenshots are in my Brickshelf gallery
After writing the code and a lot of debugging, I played with some toy tasks like moving in the 3D space based on [x,y,z] coordinates. Yet, my main interest was to see if the robot can do some more practical tasks, like using its gripper to move (pick and place) objects, e.g. something similar to chess figures. I made a test bench where I could place small tables and objects in positions given by [x,y,z] coordinates measured in studs. And now, I faced realworld problems. I saw that the positioning was not as precise as I hoped. What made my headache was a strange behavior for the negative values of the y coordinates. While for positive y values the positioning was rather good, for the negative ones the deviation from the correct position was unacceptable (12 studs). I checked the program by altering between forward and inverse computation and it always gave the same relations between spacial and angular parameters. Also I checked the computation for mirrored positions that differed only in the sign of the y coordinate, and the values were exactly same (except of the sign for 1 angle). Hence, my conclusion is that the issue has a mechanical reason (gear backlash and probably also some sort of tension in the construction), that causes the robot body to drift towards positive y values. You can see the issue in the video:
At the moment, I do not see any idea how to improve the movements of the robot. To be honest, I am also tempting to build a new (smaller and more compact) robot now, after I gained some practical experience. So today was the robot's last show and tomorrow it will donor its key organs to its  hopefully better  successor.

Thanks for the explanation. I was also wondering how you managed to find almost 'unlimited' time to work on your project. Now I understand. I could work on mine during Xmas holidays but now it is much harder to find some longer time as any interrupt slows me down.

I have another question: How do you handle multiple solutions to the IK task? Or do you just take the first one?

Your progress is amazing. Moreover, you have proved that even a large project with rather complex math can be implemented in Pybricks.

Good job, Jos! I am glad that you did not give up.
Two questions:
1. When you say the end effector is moving in a straight line, do you mean pointbypoint straight line? In other words, do you run incremental control?
2. How difficult was to incorporate the compensation of the mechanical links ( θ4, θ5 and θ6) into the IK equations?
Just FYI: In my own project, I am pausing now. I managed to program and run 4DoF IK control. It runs well when you move the arm in free space but when I wanted to apply it for a real task (a sort of chess figures moving), a lower precission of positioning became critical. That is why I am trying to build a smaller and more compact robot, now.

Need help cleaning math calculations for better cycletime
in LEGO Mindstorms and Robotics
Posted · Edited by Jonas
I played with MrJos' code a bit and made some optimizations that are based on a) precomputing some variables, b) applying goniometric formulae for a difference between two angles, and c) rearranging some terms in the equations. The new code is more compact and about 2 times faster. (Now, the main speed bottleneck is the physical reading of the 6 motor angles.)
Here is my code:
yawbasecos = math.cos(yaw_base_angle) yawbasesin = math.sin(yaw_base_angle) pitbasecos = math.cos(pitch_base_angle) pitbasesin = math.sin(pitch_base_angle) pitarmcos = math.cos(pitch_arm_angle) pitarmsin = math.sin(pitch_arm_angle) rolarmcos = math.cos(roll_arm_angle) rolarmsin = math.sin(roll_arm_angle) yawarmcos = math.cos(yaw_arm_angle) yawarmsin = math.sin(yaw_arm_angle) #new angle introduced and its cosine and sine computed difpitcos = math.cos(pitch_arm_angle  pitch_base_angle) difpitsin = math.sin(pitch_arm_angle  pitch_base_angle) #new variables added tempA = rolarmcos * yawarmsin tempB = a67 * rolarmsin * yawarmsin tempC = pitbasesin * pitarmcos * yawarmcos  tempA * difpitcos tempD = a67 * tempC  a45 * difpitsin + a3 * difpitcos  pitbasecos * (a67 * pitarmsin * yawarmcos  a2) #significantly simplified equations x_pos_fork = round(yawbasecos * tempD  yawbasesin * tempB) y_pos_fork = round(yawbasesin * tempD + yawbasecos * tempB) z_pos_fork = round(a67 * (tempA * difpitsin  yawarmcos * difpitcos) a45 * difpitcos  a3 * difpitsin + a2 * pitbasesin + a1)