ord

I agree that Stud.io is in general a better option (and fantastic software IMO) but it can't simulate movement like LDD can. It's discussed in this thread: LDCad I've never used, if it had this kind of feature that would be cool?

Rotation transmission with 8-bar linkage Backstory: I've found LDD to be a good tool to simulate linkages. However, it can't simulate gears - this is the workaround I came up with to transmit rotation for a walker I'm working on.

That's an interesting anecdote and cool that you got to use such equipment! I will admit, I've watched a few videos of older machines on Youtube just for fun :P (e.g. https://www.youtube.com/watch?v=iziP0cQhOFY , https://www.youtube.com/watch?v=hpmRMP6rKro).

Paper size: A4 Tip speed: 40mm/s Software used: Pybricks, vpype, Studio 2.0, Blender (Freestyle) Electronics: Mindstorms 51515 hub, 2 large angular motors, 2 medium angular motors Pen/paper: anything that fits in the pen-holder/bed WIP topic: [WIP] Mindstorms 51515 Plotter

Thanks! I think the curved/abstract plots look the best with it.

I have finally gotten around to finishing this and would like to post an update before making a presentation video. Update: Every component has been rebuilt and improved. It is now modular Lower and slimmer main gantry Paper stops are now at the front New paper clamps at the front Turntables replaced with 36t gears It now plots at 40mm/s (previously 20mm/s on A4 version) Trying new pen/paper: File: Metaball Moons (SVG) Paper: A4 black card Speed: ~40mm/s Plot time: ~9min Pen: Metallic silver Sharpie Final thoughts: Upgrading from A5 to A4 was a lot of work - stiffer frames needed, more inertia to deal with. For a fast machine, A5 paper was much easier to work with There is an inherent problem with this design - by maintaining tension in the x-axis chain, there is friction between the sliding 8t gears and 32L axles. This causes a moment on the main gantry when it moves in the y-direction, and higher tension -> more friction -> bigger moment There is also an inherent problem with using these motors in such a design - they simply do not run smoothly at ~<10% speed (source). This is visible whenever there is an angled, near horizontal or near vertical line. With the gearing I was using, the speed I was running it at (40mm/s) was already <35% of the maximum theoretical speed (x max. = 120mm/s, y max. = 156mm/s) so the problem was further exacerbated. I changed the gear ratios so that the maximum theoretical motor speeds are now as close as possible to my desired 40mm/s plot speed (x max. = 43mm/s, y max. = 56mm/s) It would be difficult to plot much faster. I tried a couple of times at 100mm/s and the accuracy was much worse, the ink couldn't flow fast enough and the hub crashed (presumably it couldn't keep up with the speed) This was one of those projects that had me frequently scratching my head. There are so many variables to deal with and so many possible causes for a bad looking plot (e.g. backlash amounts, plot speed, gearing, timing between moves, different pen/paper, tension amounts in chains). It took many hours to work through these to get it to the point where it is now. I am glad to call it finished :) Thank you for reading/following the build. Regards, ord

The holes in the middle two cross-braces should be rotated 90°. Not ideal, as it prevents one running an axle through the middle. Still, very much looking forward to this part and how much easier it should make bracing.

A nice mechanism to test . As do I. Couldn't wrap my head around what causes a particular part to move. Two things I did notice were collision detection and the tendency for parts to want to snap to another connection...

I see what you mean... True! Like this Hart's A-frame that @GerritvdG shared in another thread (had to create an axle connection to the orange liftarm):

That's a nice feature. It looks like the yellow part is moving. Can you fix it in place somehow?

3: 10 5: 6 7: 4 1: 3 8: 2 2: 1 (sorry if this formatting is bad - I can't get single spaced lines on mobile)

Thanks! I agree. There's lots of good GBC inspiration on thang010146's channel. Thanks a lot! I believe they all are, in some form or another, in that the ratio of the outer planet gear to the sun gear is always 2:1. Thanks for sharing your creations! That's a nice, simple solution with the 24t/12t gear combo and the Hart's A-frame looks interesting. I think it's really cool to be able to create such straight line movements without any prismatic joints whatsoever.

Thank you! Straight line drawing mechanisms

You're welcome, and thank you. I've spent the best part of my day reading through your code - It's a fine achievement getting to where you did. You and Akiyuki are the only two I know of who have achieved inverse kinematics with Lego. So congrats! I plan to make an arm with the Robot Inventor set, and have just now tested sending signals from the Mindstorms LED display to the technic hub through the Mindstorms colour sensor. Hooray for a hackish 7th motor for an end effector! I now better understand your example from earlier, and I believe the starting position of your robot is a singularity. You've managed to overcome it, but for what it's worth: when I used to run a Yaskawa Motoman, if the robot's position came anywhere near a singularity it would stop and throw an error, because the joint speed approaches infinity here. It's starting position looked more like a limp arm to avoid this, with no 90° angles, and the user just had to know to avoid them when programming. That's a good analogy with the forklift and makes sense to have the robot capable of both heavy loads and fast speeds. I think when I make my robot, I'll have it throw an error if any of the motors can't reach their programmed speed, and just say to the operator: "You'll have to send this move command at a slower speed if you want it to happen." I don't know for sure, but I would guess that this is what happens on a real 6-axis robot. Anyway, now I'm more motivated than ever to finish off my plotter and free up parts for the robot arm. Thanks again for your help @Mr Jos

No need to be sorry - the more the merrier! Indeed it is a challenge, when building a robot arm that has to potentially reach to a far distance and lift a load. I agree. There is a lot to ponder here. It's probably time I read up about how industrial 6-axis robots operate...

Wow, thanks for the detailed write-up and it's good to hear that you're still working on it :). I ask because I am in the early stages of making my own 6DOF robot - I will definitely take your learnings into account and hopefully too can achieve the holy grail of a robot capable of linear movements ;). If it is the case that a motor cannot physically reach its desired speed, is this not a design problem rather than a programming problem? i.e. fixed by gearing down/slowing down/spring balancers/counterweights? If it is the case that a motor could theoretically reach its desired speed but doesn't, then maybe this is something that can be fixed with PID tuning? (I don't know - it is all new to me) The way I look at it is that each motor should track its desired speed/position as closely as possible at all times, no matter the load. If this is achieved, then the robot will be as accurate as possible (IMO). The reason I think about this comes from my plotter project, where any deviation from the programmed path is very visible on the plot. It took me some time to figure out that the majority of the deviation I was seeing stemmed from the period during which the motors were accelerating (even with equal loads/acceleration rates, one axis will take longer to accelerate if its accelerating to a higher speed [see below]). The performance of the plotter significantly improved when I removed the acceleration limits of the motors, and they tracked their desired positions as quickly as possible. Have you done this for you robot? (The next problem, and what I am working on now is making it stiff enough to handle such high accelerations). Here you can see the problem visualised, before I removed acceleration limits. At ~14750 the program is ready for its next move but the x-axis is only at ~92mm instead of 103.3mm (I think similar to your example only being at 80°). After removing acceleration limits, the actual positions (solid lines) very closely track the desired positions (dotted lines). Anyway, this is all said with the goal of having the most accurate movements possible, and maybe this is not your goal :).

@Mr Jos sorry to dig up an old topic but I was reading about PID controllers on Wikipedia and the example there refers to a robotic arm. It reminded me of your fantastic robotic arm and made me curious - did you ever try changing the PID parameters on this project? Perhaps more aggressive settings could eliminate the need to re-calculate the forward kinematics at each waypoint...

I'm torn. Really want this motor but at local resellers it's 3x the price of a PU large motor. I wouldn't mind the Spike Essentials set; the small hub could come in handy. That too is expensive though - costs about the same as 51515 :(.

incredible. I think I'll have to watch this one a few times...

I prefer this! I think it makes the number more readable and as howitzer alluded to - a narrower gap could make it even better. I think a dull black box is just fine, as it allows the viewer to focus more on the mechanism and appreciate what's inside - but that's just my opinion! Again, great work and can't wait to see it finished.

Personally I think it would look clearer without the red lines and with the boxes against each other so it's a solid black wall, if that's possible.

It appears that there is a new mold for this part Top - old; Bottom - new. Does someone know the reason for this change? Maybe easier to insert? The new version seems to be slightly looser, but not by much.

Sorry, I tried to link the time frame, it's at 1:05. He has some kind of stopper below the flaps, so that they don't wobble when they fall down (not that it's a big deal or anything).

Congratulations, it looks great. Do you plan to add a stopper like in this video?

Pick and place mechanism