[WIP] Mindstorms 51515 Plotter

[ibzyfitzy]

Love the project!

I've got a similar project going although it's a SCARA robot trying hopelessly to paint with a brush! I have a similar problem to yours in that I can't get motors to run simultaneously using the official app. May I ask how you managed to connect your RI hub to pybricks? It doesn't seem to detect mine. I'm an experienced builder but new to programming.

Many thanks

[ord]

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.

[ibzyfitzy]

Yeah got it working but simultaneously managed to finally get two motors in parallel using the deeper level documentation of lego micropython via https://lego.github.io/MINDSTORMS-Robot-Inventor-hub-API/class_motor.html

It opened up a whole bunch of new questions such as how to wait before they all finish their motion, and a million other things I don't know, but that's the aim of this project for me - to get good at programming/coding.

Yeah I've grown to hate those turntables after loving them for so long! Not only do they have a lot of friction, but it gets worse over time as bits of plastic roughen up the insides. For that reason I switched from the white design to the yellow one in the images below. It uses the ginormous planetary gear instead.

[image won't load I'll try again later]

[Philo]

Yeah, Friction in turntables can be a pain. In some critical cases I opened them and added a teeny bit of silicon grease... Helps a lot!

[ibzyfitzy]

Aha thanks for the tip, Philo. 

I spotted new, small planetary gear parts on the new AT-AT set. At £700+ I won't be buying it sadly 😭.

[ord]

12 hours ago, ibzyfitzy said:

Yeah got it working but simultaneously managed to finally get two motors in parallel using the deeper level documentation of lego micropython via https://lego.github.io/MINDSTORMS-Robot-Inventor-hub-API/class_motor.html

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.

12 hours ago, Philo said:

Yeah, Friction in turntables can be a pain. In some critical cases I opened them and added a teeny bit of silicon grease... Helps a lot! 

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).

[ibzyfitzy]

24 minutes ago, ord said:

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.

Yeah so you want to take off Import motor at the top and instead put Import hub. Then for your motor objects use: hub.port.A.motor (or whichever port you want). Mine looks like this:

from mindstorms import MSHub, ColorSensor, DistanceSensor, App

from mindstorms.control import wait_for_seconds, wait_until, Timer

from mindstorms.operator import greater_than, greater_than_or_equal_to, less_than, less_than_or_equal_to, equal_to, not_equal_to

import math

import hub

 

# OBJECTS:

upper_arm = hub.port.F.motor

lower_arm = hub.port.A.motor

end_effector = hub.port.E.motor

colour_sensor = ColorSensor("C")

 

lower_arm.run_for_degrees(30, 30)

The next thing I need to try and do is get them all to start and finish a particular plot move in the same time frame. They may be in parallel but they're not totally synchronized just yet, as some motors finish before others.

[ord]

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.

[ibzyfitzy]

15 minutes ago, ord said:

So, the method run_for_degrees() will not wait until finished before the next method runs?

That's right, it doesn't wait. In fact I now have the opposite problem whereby I don't know how to make it wait when I need it to! I wish there were some examples in the documentation.

[ord]

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

[ibzyfitzy]

You're welcome! Last night I made good progress too:

Here's how you wait until all your motors have stopped:

While motor_a.busy(1) or motor_b.busy(1):

sleep_ms(10)

It's basically checking them every 10 milliseconds to see if they're no longer 'busy'. The 1 indicates a busy state. 

[Pybricks]

Quote

What a difference a few lines of code can make...

By adding the following line for each of the motors, their accelerations are effectively no longer limited by the control, meaning a lot faster plots:

My only concern is whether this will quickly cause damage to the motors. Perhaps someone who knows more about motors can answer this?

That is fine. When you increase acceleration to infinity, it just tries to get to the target speed right away. That's a bit closer to PF 1.0: turning on full power right away.

But you might want to try the track_target function. It skips the acceleration phase entirely. Then you can make both motors follow your own angle as a function of time. That also ensures they synchronize.

 

[ord]

@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...

Edited November 17, 2021 by ord

[Pybricks]

That is true. It sounds like we need to add a method where you can specify both target angles, while the robot will figure out the speeds such that they arrive at the same time. I'll add it to our wishlist!

[ord]

 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 :) )

[ibzyfitzy]

You can do it with just a little math though. I divide the speed of the one that has to go slower by the rotation ratio. My end effector is now staying nice and straight :)

[ord]

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

[ord]

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

[Mr Jos]

Looks great! It's drawing nice curved lines.

[ord]

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

[ElectricTurtle]

What did you make the plate that holds the paper with? I can't find anything that has no cracks.

[ord]

It's just made of liftarms connected together. In order for the cracks to not show up on the plot I used thicker than usual paper - 200gsm seemed to work well.

[ElectricTurtle]

Thanks! I'm working on a plotter using CoreXY with nylon thread, I got all the math worked out but now I need to put a pen on it.

[ord]

Nice! I originally planned to build a CoreXY style plotter but figured out other ways to mount the motors remotely, so went with that.

Hopefully we can see yours in action soon.

[2GodBDGlory]

Ooh, cool! I built a very basic RC-controlled CoreXY thing a while ago, just to wrap my head around its kinematics, but going further and programming it looks like a very interesting project!