Eurobricks Citizen
  • Content Count

  • Joined

  • Last visited

Posts posted by Jonas

  1. 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)


  2. 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 home-positioning, sequential control between pre-set 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.


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

  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.

  5. 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 well-known 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 2-stage down-gearing 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:


  6. 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?


  7. On 5/7/2021 at 9:42 PM, Mr Jos said:

    I could hard-program 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 check-points 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?

  8. 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 front-rear 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.

  9. 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 long-term 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.

  10. 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 (1-2 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.

  11. 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 real-world 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 (1-2 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.


  12. 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 point-by-point 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.