ord

I'll try to build more of thang010146's mechanisms. There are many interesting ones on his channel.

Thank you. Ah yes of course. I guess the only difference here is that the output is coaxial with the input. The usefulness of that: probably not much .

EDIT: rather than make a new thread for each of thang010146's mechanisms that I make, I'll post them all here. His YouTube channel is full of mechanisms that I'd like to make out of Lego, and if anyone else makes any feel free to post here too! I'll link to his original video in the title of each post. Rotation to coaxial oscillation I don't know what this could be used for or if it has been done before. I found it interesting nonetheless.

Cool! Nice work getting the flaps so thin

@dunes maybe this is stuck in a loop (motorC is never considered 'stalled'): while not motorC.control.stalled(): wait(1) Have you tried done() instead? while not motorC.control.done(): wait(1) As for wait=False being possible with run_until_stalled... I don't think it is. This is the workaround I use on my plotter project: motor_y1.run(50) motor_y2.run(50) wait(50) while motor_y1.speed() > 10 or motor_y2.speed() > 10: motor_y1.dc(30) motor_y2.dc(30)

Congratulations Balazs! Well deserved!

That is true. I am always in favour of slightly cleaner code though and maybe it would make things easier for beginners 🤷‍♂️.

Great! I can see this being useful for any robot where one would want the end effector to travel in a straight line (hopefully such a feature would support more than two motors :) )

Really cool concept and impressive that you achieved it as a B model .

@ibzyfitzy @Pybricks great, that makes sense. The problem with using track_target, if I understand correctly, is that my code is created from SVGs that have a mix of long, short, angled and perpendicular lines, and if a line was from e.g. (0,0) to (200,50) the plotter would draw (0,0) to (50,50) to (200,50) with track_target. Each motor would move to its target as fast as possible. I could potentially split the SVGs into many small lines to mask such moves, but this would increase the file size...

. Well thanks for showing how it's done anyway. True, examples are always helpful!

So, the method run_for_degrees() will not wait until finished before the next method runs? Synchronisation is tough. Removing acceleration limits was a big help for me - before I did this there would be cases where e.g. one motor would stop accelerating before another because it was going to a lower speed, and this would throw the timing out.

Could you explain how you got them running in parallel? That documentation was mentioned earlier in the thread and I couldn't work it out. I have tried this and indeed it helps a lot - there is just the smallest amount of sticking that remains and causes problems for me (I think having the chains tensioned doesn't help).

Thanks. I noticed in Pybricks Q&A topic that you found the method that I used. Did you get it working then? I'm intrigued by your robot - I don't think I've seen a SCARA setup like it before. P.S. If anyone is still following this topic - I am still working on the plotter. I think the turntables have too much friction, which makes for not-smooth y-axis movements. I might have to rebuild the whole thing with 36t gears instead.

This thread made me curious, so I recreated the test I mentioned but with wider tyres and on different surfaces (wood, lino, carpet again). The results were similar on all surfaces and compared to the previous test: not much difference in smoothness of drive and turning radius between running the motors at the same speed and running them at different speeds (i.e. electronic differential). Locking them together (as in photo) again made the turning radius far bigger (even more so this time) and also made the car jumpy and not smooth (I suspect due to the wider tyres giving more grip). This was controlled by the Powered Up app and I suspect that other apps/motors might behave differently, especially seeing that m2fel reported different results using nxt. I am interested to see how it works in your case @mudseason, because in my case I would say that using two separate motors in place of a differential is not very detrimental at all. :)

These were my thoughts. Slightly off-topic from what the OP was asking, but I tested the turning diameter of some different types of differentials in the video in this thread: My conclusion from the not-so-scientific tests was that the turning diameters (on carpet) of vehicles with mechanical differential, electronic differential and synchronised left/right motors (like OP is talking about, NOT hard coupled) were similar (within 5%) whereas the turning diameter with locked differential (hard coupled left/right motors) was much higher (+~20%). So, in theory your vehicle should still be able to turn pretty well, as long as you don't connect the left and right axles together. EDIT: Then again, different motors could behave differently, as could different apps.

Oh man, it would be tough to fit all 14 segments on the version 2 type, especially the angled segments. Here you can see that each segment requires ~4 studs of horizontal space (tile-liftarm-liftarm-liftarm-tile) with the current design: Thanks! They definitely did - they fitted the 14 'segments' perfectly. True true, surprisingly it also used up a large portion of my 6L axles - 90 to be precise.

@CheungsLegoCreation oh I see! Nice Biped! And also lots of other nice bipeds on your channel. Thanks for the info about the app update - they would be welcome features. For me Pybricks is the ultimate. It's just lacking at the moment for multiple hub support, as Lok24 said, unfortunately.

I upgraded the seven-segment display (version 1) to display fourteen segments. It no longer shows the angle of the hub/s but can display 0-9, A-Z, a-z, and some symbols. Enjoy!

This is great! A lot of Lego bipeds that I see don't lift their feet off the ground but rather shuffle. You managed to get the feet to clear the ground and make it look like a humanoid, well done. I recently made a program in the Powered Up app that controls two technic hubs and I thought it worked quite well (in terms of ease of programming, connecting and remote controlling). I couldn't get the ultrasonic sensor to work with it though. I'm not sure if I'm missing something or if it's just not supported.

I love it. It looks nice and clean and I think you've captured the shape well. Can't wait to see it with bellows!

... and utilises PF/PU. A transforming car/vehicle?

Thanks everyone for the nice comments. It could be done, but there really isn't much friction between the string and the curved part of the liftarm/connector.

Thank you all. It took about 2 minutes to wind 1 ball. I just noticed now that the full speed can't be realised from the video because it's sped up, but it goes really fast. That GIF is 1:1 speed. It would be easy to motorise . In fact, string balls are still wound today using the same method, just motorised.

It changes the shape of the ball. With the handle in a more vertical position a rounder ball will be produced, with it in a more horizontal position the ball will be more of a cylindrical shape. It also changes how the pattern of the strings look.