Eurobricks Vassals
  • Content Count

  • Joined

  • Last visited

About ord

Spam Prevention

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

Profile Information

  • Gender

Recent Profile Visitors

770 profile views
  1. Cool project! Thanks for all of the updates - I'm really enjoying following this
  2. I present my latest MOC - it contains one part Try it yourself by pasting this code into the Mindstorms app (see if you can get 100 points):
  3. Wow! I always loved this car and it's great to see a near-perfect rendition of it. Excellent work!
  4. @2GodBDGlory there was a topic in the Mindstorms forum recently that might help: As far as I know, there are no other apps that offer both the programmability and the control (buttons, sliders, etc.) that the Powered Up app does.
  5. I've tried the suggestions for reducing file size and here are the results (only tested with one SVG file): I called mem_info() at the very start of the code (after imports) and at the very end of the code. Shown is the memory used at each point. Original code, program(speed): start 78KB, end 188KB Speed parameter set as constant, program(): start 73KB, end 80KB 'Program' function removed, move() calls only: start 73KB, end 78KB (speed constant) Positions stored in list, position_list[]: start 106KB, end ? (speed constant) I didn't wait for the plot to finish with the positions stored in a list, as it was taking a very long time (I think due to motor_z.run_target() being called with every move) and the memory used at the start of the program had already exceeded the memory used with the other suggestions. So I think setting speed as a constant will be the most helpful thing to reduce file size. I am now, however, running into errors such as ValueError('incompatible .mpy file') and MemoryError: memory allocation failed when simply pasting all of the moves in twice (which I thought would use <2x80KB<252KB). Maybe I'm making some other mistake here though. Anyway, it's not a huge problem to run a few programs for one plot if I need to.
  6. Back to the mechanical side of things... I now own four of each of the tread link sprockets and need to decide which will be best for the Y-axis. The smallest ones would make the whole MOC nice and slim but would be more prone to chordal action (variations in speed and position of the chain), so I investigated to see just how much... My conclusion: the speed and hence positional accuracy of the Y-axis will vary by a maximum of 13.4% if using the smallest sprockets, cyclically every 12mm. This isn't a huge amount, but combined with a radius variation of 1.6mm (chain will move up and down by this much every 12mm) I think I'll stick with the 10-teeth sprockets, or maybe even use the 14-teeth ones for maximum smoothness/accuracy.
  7. Thanks for the suggestions. They all sound good and I look forward to trying them. Is that different to what's shown in the official app's documentation? I'm confused. Either way, I checked out the Motor class on that page and couldn't see anything similar to run_target() with wait=False as a parameter, like what I use in Pybricks.
  8. Thank you Jos and Pybricks! That would be great! As a side note, I am continually impressed by the power of Pybricks and its many advanced features. So thank you @Pybricks for the work you've done to make such useful software and the documentation to go with it :) I convert the SVG file to a sequence of move(), head_down() and head_up() commands which I paste into Pybricks. Here is the start of such a sequence: def program(speed): move(581,10,speed) #Move to x = 58.1mm, y = 1.0mm at some speed head_down() move(583,16,speed) move(585,17,speed) move(587,13,speed) move(587,10,speed) head_up() move(594,10,speed) head_down() move(594,11,speed) move(596,17,speed) move(598,17,speed) ... Later, I call program() with speed as a parameter. The first two parameters of the move() function are X and Y coordinates. They are stored in 10−1mm units, which allows for 0.1mm accuracy while storing them as integers (this reduces the program size by about 75% by my measurements, compared to storing them as floats). Without an in-depth knowledge of how programs are sent to the hub though, it's hard to know how to make it more efficient. Would trimming down the move() function itself help, since it is called so many times?
  9. Thanks all! @Jonas I plan to make a Studio model of it once it's finished - it's still very much a work in progress. A small update: I found a very cool tool called SquiggleCam - it converts any image into a bunch of wavy lines for plotting. I love it. Here are two plots I've done with it so far... Plot #2: File: My desktop background (The Matterhorn), in squiggle format Paper: A5 200gsm Speed: 40mm/s* Plot time: ~30min (divided into 2 roughly equal parts) Pen: Rotring 0.5mm graphic pen Plot #3: File: A portrait of a friend of mine, in squiggle format Paper: A5 200gsm Speed: 40mm/s* Plot time: ~35min (divided into 3 roughly equal parts) Pen: Rotring 0.5mm graphic pen *The programmed speed of each linear movement, not necessarily the overall speed, as I'm still working on timing between linear movements
  10. Hi, I am working on a classic XY Plotter that is controlled by the new Mindstorms hub. It's a work in progress and hopefully I can show some improvements here over time. I made it with the Robot Inventor Hub instead of the Technic Hub simply because I wanted to try programming with the bundled Mindstorms MicroPython software. I was unable to achieve some crucial things with this software (most importantly a simple way to run multiple motors in parallel?) so I switched to Pybricks but kept the Mindstorms Hub. The code was adapted from my Cartesian Parallel Robot - easy! Features: Lightweight XY carriage with all motors mounted off the moving parts Pen raising and lowering Programmed to 0.1mm accuracy Programmed with backlash compensation (0.9mm in X, 0.5mm in Y) I hope to reduce the mechanical backlash some more. For the moment though, programming it out seems to help. Also, I have implemented the method described by Didumos69 here to maintain tension in 'loops' going through the chains and remove backlash in them (I found this to be a better solution than tensioning the chains with springs). In this video the hub's display shows when backlash is compensated for in each axis: Plot #1: File: Gaudi's Honeycomb (SVG) Paper: A5 200gsm Speed: 20mm/s Plot time: ~30min Pen: Rotring 0.5mm graphic pen I found a good website with some free SVG files to start with (link above). This particular file required around 4000 lines of Pybricks code to plot. I'm approaching the point where files are too big for the Inventor Hub (and its ~252KB of available RAM). Perhaps someone could tell me if there's some way to load larger files onto the hub using Pybricks or is this something that's only possible with the Mindstorms software or am I stuck with splitting larger files into multiple plots? I'm reasonably happy with the result. There are some obvious defects though and I would like to make it faster. Here's a short real-time video. What's next? I have a bricklink order on the way with parts to increase the plotting area to A4. I think this is the maximum size that this design can be, given the 32L axles along the Y-axis and for the pen raising/lowering. Aside from that, I will try to further reduce the backlash and increase the speed. Mostly though, I just want to plot some different things (which I will post here). Thank you for reading. More to come soon...
  11. That is good to know. Do you have information about the precision of other current generation motors (e.g. SPIKE Prime)?
  12. ord

    T-Bot (3axis gantry)

    Fair enough, I guess there are always some trade-offs and sometimes it's best just to keep it simple. I feel your pain with trying to make Lego precise. I'm currently building a simple XY plotter and the large links for the main rail are even harder to work with than the small links (imo).
  13. ord

    T-Bot (3axis gantry)

    Simple, yet effective. One small improvement I can suggest is to keep the chains perpendicular. Currently they are at an angle that will change with gantry position, which will reduce accuracy. At least I think that's how it works...
  14. Could you please clarify that the ends are in fact bars, not axle connections? I.e. It is connected to the motor only by friction
  15. Was that picture done with the robot? It looks good.