Jonas

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.

Your projects and their video presentations are very original. I like to watch them.

Implemented and works! Thanks once again and wish you good luck in your project!

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.

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?

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!

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

Very interesting and unusual model! I wonder which type of motor you used. The link in the text seems to be wrong.

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

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 (mboxCon.read ()) A sample code at the client side: # MAIN CONTROL LOOP action = 'Start' while (action != 'End'): mboxAct.wait() action = mboxAct.read() 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 = mboxPar.read() speed, target, then_opt, wait_opt = motorParamDecode (params) motorTurnTarget (speed, target, then_opt, wait_opt) mboxCon.send('Done') elif (action == 'GripTarget'): mboxPar.wait() params = mboxPar.read() speed, target, then_opt, wait_opt = motorParamDecode (params) motorGripTarget (speed, target, then_opt, wait_opt) mboxCon.send('Done') elif (action == 'GripOpen'): mboxPar.wait() params = mboxPar.read() speed, target, then_opt, wait_opt = motorParamDecode (params) motorGripOpen (GripSpeedLimit, 40, Stop.HOLD, True) mboxCon.send('Done') elif (action == 'GripClose'): mboxPar.wait() params = mboxPar.read() 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

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

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.

I made the first experiments based on the example in the documentation and it works. Now let me ask a more practical question. How do you do the development works in this case of multiple EV3 bricks? Do you use a separate computer to write/debug programs for each brick? Or is there a trick how to use a single PC (and single/multiple VS Code IDE) together with multiple bricks and easily switch between the bricks and their programs?

I stopped buying official sets from TLG several years ago. But this is a model I would buy immediately.

Thank you, Jos and David. I read that mentioned chapter in the documentation before, but I hoped there is another, more straightforward, way. This also means that a wired (USB) communication between the 2 bricks is not possible, right?

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.

Thank you very much for the pictures. Doug. I need that 3x3 profile because in its center there will be a longitudial axle to drive an end effector. Now I know that the new rack is a piece to consider when making the next BL purchase.

Thank you Doug. I watched your video earlier but there is no detail look at the rack housing there. Therefore I was not sure. And as I wrote, a Studio,io simulation did not work in this case.(I could not align the rack part and the housing part to fit together.) I also watched official instructions for the models where this rack piece is used and noticed that they always drive the rack by the new worm gear.

Ok. I tried to make a sketch that shows a construction of two parallel racks. I wonder if it could translate inside the 3x3 space in the depicted housing. Sorry for spamming your thread. Please delete this stuff later.

Thank you again. Unfortunately, I do not have that rack and simulating my desired solution in Stud.io did not work, so that is why I am asking. My intention was to use a pair of the racks (joined back to back as in your picture) and make a long rack that would be moved by 12t gears in a tiny profile of 1x3 studs, definitely without the housing. I am thinking about a small robotic arm with translate movements.

Thank you, Doug. Actually, my question was wrong. I meant 12t gear. Can you show me if it fits with studless beams?

Hello Doug, I have a question concerning this rack piece. Can it be moved by a 16t gear? I mean the gear rotating directly above the rack's teeth.

The steam engine is really cute. Please, make a video of its moving.

Wonderful original idea and fantastic realization!

Nice and clever design. I am going to put it on my build list.