Eurobricks Citizen
  • Content Count

  • Joined

  • Last visited

About Jonas

  • Birthday 01/25/1957

Spam Prevention

  • What is favorite LEGO theme? (we need this info to prevent spam)

Contact Methods

  • Website URL
  • ICQ

Profile Information

  • Gender
  • Location


  • Country

Recent Profile Visitors

1182 profile views
  1. 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/", 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.
  2. 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.
  3. 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.
  4. Jonas

    New ! Flex Robot Leg

    Your projects and their video presentations are very original. I like to watch them.
  5. Implemented and works! Thanks once again and wish you good luck in your project!
  6. 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.
  7. 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'TurnDone'): wait(10) Any advice or hint?
  8. Jonas

    [MOC] Walking Windmill

    After seeing this little moving gem I could not resist and had to build it. Fortunately, I found the wind-up motor in my supplies (from an old Harry Potter set). I have built the walking base and gave it to my 3y-old grand-daughter. She liked it very much and called it the Little Spider. Thank you for the inspiration of a nice little Christmas toy!
  9. Jonas

    6 DOF robotic arm by Jos

    Nice! A lot of inspiration for me. Enjoy your quarantine and happy Christmas, too.
  10. Jonas

    [MOC] Walking Windmill

    Very interesting and unusual model! I wonder which type of motor you used. The link in the text seems to be wrong.
  11. The currently set movement limits are as follows: body rotation: -90 to 90 deg (mainly due to cables) arm down/up rotation: -40 to 90 deg (due to construction limits and for sake of robot stability) forearm down/up rotation: -60 to 60 deg (due to construction limits and robot stability) wrist twist:-175 to 175 deg (almost 360 deg) - here I see the only possibility to have unlimited 360 deg rotation guarded by an optical sensor wrist up/down rotation: -90 to 90 deg (to avoid conflicts with driving gears) gripper opening: 0 to 50 deg
  12. I am going to use this thread to document my progress in building a robot controlled by multiple EV3 units. I have built a robot based on Akiyuki's famous 6DOF robotic arm. Mine is slightly modified. I added a grip and removed the end rotator. So I used 6 EV3 motors (3 large and 3 medium). Four of them (responsible for arm and forearm movements) are controlled by Master (Server) EV3, the remaining 2 that control body rotation and grip opening are governed by a Slave (Client) EV3. I have chosen this split because the 4 above mentioned motors need to be mutually coordinated as some of the movements are more or less mechanically interlinked. My programs are written in Pybricks micropython and for me this is the first micropython project of this size. For the Server-Client communication I created 3 mailboxes: Two used by the Master to send the Client messages and another used by the client to provide feedback (or confirmation). The master specifies requested actions as text messages (e.g. 'TurnReset', 'TurnTarget') sent via Textmailbox. Parameters for some of the actions (like speed, angle, stop-commands) are packed into a single int32 number and sent by a NumericTextbox. The Client responses by brief confirmation text messages via a Textmailbox. The Server controls all the 6 motors by functions which have similar declarations and names. The functions for the remote motors include communication with the other EV3. A sample code at the server side: # a locally controled motor def motorTwistTarget (speed, target, then_opt, wait_opt): if (target > TwistMoveLimitPlus): target = TwistMoveLimitPlus if (target < TwistMoveLimitMinus): target = TwistMoveLimitMinus motorTwist.run_target(speed, target, then=then_opt, wait=wait_opt) # a remote controled motor def motorGripOpen_Remote (): mboxAct.send ('GripOpen') mboxCon.wait () encParam = motorParamEncode (GripSpeedLimit, GripOpen, Stop.HOLD, True) mboxPar.send (0) mboxCon.wait () def motorGripTarget_Remote (speed, target, then_opt, wait_opt): if (target > TurnMoveLimitPlus): target = TurnMoveLimitPlus if (target < TurnMoveLimitMinus): target = TurnMoveLimitMinus mboxAct.send ('GripTarget') mboxCon.wait () encParam = motorParamEncode (speed, target, then_opt, wait_opt) mboxPar.send (encParam) mboxCon.wait () return ( ()) A sample code at the client side: # MAIN CONTROL LOOP action = 'Start' while (action != 'End'): mboxAct.wait() action = mboxCon.send('OK') print (action) if (action == 'TurnReset'): motorTurnReset () mboxCon.send('Done') elif (action == 'GripReset'): motorGripReset () mboxCon.send('Done') elif (action == 'TurnTarget'): mboxPar.wait() params = speed, target, then_opt, wait_opt = motorParamDecode (params) motorTurnTarget (speed, target, then_opt, wait_opt) mboxCon.send('Done') elif (action == 'GripTarget'): mboxPar.wait() params = speed, target, then_opt, wait_opt = motorParamDecode (params) motorGripTarget (speed, target, then_opt, wait_opt) mboxCon.send('Done') elif (action == 'GripOpen'): mboxPar.wait() params = speed, target, then_opt, wait_opt = motorParamDecode (params) motorGripOpen (GripSpeedLimit, 40, Stop.HOLD, True) mboxCon.send('Done') elif (action == 'GripClose'): mboxPar.wait() params = motorGripClose (GripSpeedLimit) mboxCon.send('Done') mboxCon.send('All done') As I said before, this is my first Pybrick project that includes also Bluetooth communication, so an advice from experts is welcome. At the moment, the robot is able to perform basic movements as shown in the video. The next steps and improvements in the software should focus mainly on: enabling parallel movements of Server-controlled and Client-controlled motors (at the moment it does not work as intended) better coordination of the wrist movements and program compensation of the mechanical interlinks some sort of algorithmic position planning based on applied inverse kinematics
  13. Jonas

    6 DOF robotic arm by Jos

    Keeping my fingers crossed for you! I am working on a very similar project, also inspired by Akiyuki's arm. As to the 360 deg unlimited rotation: It looks fine but for a practical application I had to add stops to each of the rotating mechanisms in order to define start positions needed by a control program. It seems that I have already managed the 2-EV3-brick control via Micropython, thanks to your initial advice. Jonas
  14. Thanks, Jos. Is there any special reason to use USB connection? So far, I have been using Wifi connection between my PC and the bricks.