Jonas

Eurobricks Citizen
  • Content Count

    232
  • Joined

  • Last visited

Everything posted by Jonas

  1. 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?
  2. 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 pre-computed. It might save some milliseconds.
  3. Jonas

    [MOC] Medieval Tavern

    The Blacksmith house and Tavern fit together really well.
  4. Jonas

    Compact single direction output

    Thanks, Cadder, for sharing it. I have built it and verified that it works. It is a very useful and compact mechanism.
  5. 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.
  6. 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. 
  7. 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?
  8. That looks really interesting and innovative! What is that suction cylinder? A standard pneumatic cylinder with a transparent body?
  9. Fantastic work, Berthil! You just reached Akiyuki's master level by this design.
  10. 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.
  11. Warm greetings to Pybricks experts! I started to program my EV3 in Pybricks/MicroPython and it is great fun. Good job done by its creators! Now I have built a 6-motor robot and I want to control it by 2 EV3 bricks. I know how to do it in EV3_G block diagrams but I definitely want to accomplish it in MicroPython. My first question: What communication channel between the 2 bricks should I use? I would prefer USB cable, but Bluetooth is also OK. The second: is there any example of a Micropython program that controls motors attached to a master EV3 and other motors attached to the other (slave) EV3 brick? Thanks for any help.
  12. Jonas

    6 DOF robotic arm by Jos

    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.
  13. 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.
  14. Jonas

    6 DOF robotic arm by Jos

    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.
  15. Jonas

    6 DOF robotic arm by Jos

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

    6 DOF robotic arm by Jos

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

    6 DOF robotic arm by Jos

    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.
  18. Hi, this question could be most probably answered by David Lechner. In my EV3 project, I was trying to increase the speed of the robot gripper movements. It is controlled by a medium EV3 motor and set as follows: motorGrip = Motor(Port.B, positive_direction=Direction.COUNTERCLOCKWISE, gears=[1,24]) Increasing the speed value in the statement motor[m].run_target(speed,...) does not help when a certain speed level is reached. From the documentation I understand that this threshold level is set by the statement motor.control.limits()) So I tried this: print (motor['Grip'].control.limits()) motorTestRunTarget ('Grip', doReset=False, waitTime=1000, safetyFactor=1) motor['Grip'].control.limits (35, 67, 100) motorTestRunTarget ('Grip', doReset=False, waitTime=1000, safetyFactor=1) sys.exit () The first line prints these values: (33, 67, 100). The second line is executed well, but the third one where I try to increase (only slightly) the speed limit, rises Error: File "/home/robot/Client/main.py", line 111, in <module> OSError: [Errno 1] EPERM: Is there anything wrong in the way I try to use the control settings? And another question: how the internal speed limit is set? Does it depend on the used motor (medium, large) or on the specified gear rates, is it based on a safety factor? When I tried to calculate the physical speed limit from the known revolution/s (260 for medium motor), I got a value which is larger than that read in the above piece of program.
  19. I have also built a robot inspired by the Akiyuki's famous one. I built it as a 'toy' on which I want to learn EV3 programming in Micropython (see my thread here on Eurobricks.) I decided to go on in smaller steps. So my recent task is simplified, because I am going to control only 5 motors (Body, Arm, Forearm, WristBend and Gripper) as shown in the picture. In this simpler version, the inverse kinematic task can be decomposed to simpler subtasks (body rotation + planar 3DoF scheme + gripper) that can be linearly combined. I have written the equations for forward and inverse directions and I hope to implement and test them soon. Though, I am struggling with some other challenges that should be solved first, such as reliable and repeatable homing (without additional sensors), position variability due to gear backlash, 100% reliable communication between two EV3 bricks (in Pybricks it is little tricky, one needs to add waits here and there), etc. Hope I will be able to show some progress soon.
  20. Jonas

    [GBC] Akiyuki Ball Factory

    You surprise me! My XT version was nothing special. That time I just felt that the empty place on the left baseplate needed to be filled. It might look well but in reality the whole assembly did not work as reliably as hoped, though the main troubles occurred always on the Akiyuki's original part - or better say on my implementation. When Berthil's version occurred, I gave it a try (with high expectations and hopes), but my attempt failed again. Soon I realized that such a complicated machine with so many rather fragile and mutually interlinked mechanisms simply cannot reach a higher value of the MTBF (Mean Time Between Failures). Being tired after frequent needs for reapeted fixes and re-tunings, I decided to gave up and dismantle it. Since that time I prefer to build less complex GBC modules and run them in a series if required. I really wonder if some of you guys own a Ball factory that can be taken from the shelf, started and run at least 30 minutes without any critical failure.
  21. Jonas

    New ! Flex Robot Leg

    Your projects and their video presentations are very original. I like to watch them.
  22. Implemented and works! Thanks once again and wish you good luck in your project!
  23. Thank you very much, Jos. I think I tried something very similar, but probably the waiting was not long enough. Or maybe I had another bug inside. The good thing is that now I can be sure that it must work, eventually. BTW, I follow and admire your current project. It inspired me to learn more about the robotics. Three days ago, I knew nothing about Denavit and Hartenberg. Now I have watched multiple videos about it and filled several papers by pictures of triangles, equations and matrices. It reminds me my uni years more than 40 years ago, though my brain was much fresher and faster those days.
  24. Hi, I need a help. I am stuck in the problem of concurrent control of motors on the local and remote EV3 unit. As shown above I can start a remote motor by sending a message to its EV3 and wait until that EV3 sends back a message that the motor has done. Something like mboxControl.send (ParamsForRemoteMotor) # send a control command to the client mboxConfirm.wait () # wait for message from client This works but the wait statement does not allow for concurrent control. I tried several solutions to replace the wait by a loop where I repeatedly read the mboxConfirm and check if its content has changed, but it does not work as intended. It seems that I miss some important information how the mailboxes operate. Unfortunately, it is not explained in the brief Pybricks documentation. In other words, my goal is to have something like that: motorArmTarget (ArmSpeed, ArmTarget, Stop.HOLD, False) # local motor motorForeTarget (ForeSpeed, ForeTarget, Stop.HOLD, False) # local motor motorLiftTarget (LiftSpeed, LiftTarget, Stop.HOLD, False) # local motor motorTwistTarget (TwistSpeed, TwistTarget, Stop.HOLD, False) # local motor mboxControl.send ('motorTurnTarget, TurnSpeed, TurnTarget, Stop.HOLD, False)) # remote motor while not (motorArm.control.done() and motorFore.control.done() and motorLift.control.done() and motorTwist.control.done() and mboxConfirm.read()=='TurnDone'): wait(10) Any advice or hint?