Glaysche

Eurobricks Vassals
  • Content Count

    49
  • Joined

  • Last visited

1 Follower

About Glaysche

  • Birthday 01/12/1975

Spam Prevention

  • What is favorite LEGO theme? (we need this info to prevent spam)
    Technic
  • Which LEGO set did you recently purchase or build?
    42043

Profile Information

  • Gender
    Male
  • Location
    San Francisco

Extra

  • Country
    United States

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Glaysche

    Efferman's Custom Parts

    Thank you very much! That would be amazing.
  2. Glaysche

    Efferman's Custom Parts

    Is it possible to generate files for this part that can be imported into Stud.io? I built my 6 degree of freedom robotic arm using this part and I am now building a Studio version of it so I can share the design.
  3. Yeah, I normally try to avoid 3D printed parts but I think there is a really compelling case here. The first reason is that it is a much better representation of the original. How the original produced the mechanical calculations is probably more interesting than the calculations themselves. The second reason is that you can’t simulate the original mechanism completely with pure lego. The slotted gears are interesting to see them work. There seemed to be other parts of the mechanism that I suspect would also be hard or impossible with pure lego. This second thing is what made your more advanced prototype you showed in the video so interesting to me.
  4. This is very, very cool. Thank you for posting here. I had no idea we had decoded and have such an understanding of the original device. The last I read about it was a long time ago and it was still considered a mystery. I have now spent way too long reading about this. In the video you showed a more advanced antikythera mechanism. Are you planning to make instructions and Shapeways parts available for that as well?
  5. Here's a simple example of the code blocks for a toggle switch: This tells the motor to hold at 0 until someone moves it 90 degrees. It will then hold the position at 85 degrees. Similar logic to go back to 0. This has the effect of allowing two distinct positions for the motor. You can compare the position of the motor with 45 to decide which position it is in. This could easily be used on the Zetros to control the diff lock.
  6. I think you could configure a motor to act as a toggle switch. Basically hold position until it is moved a certain amount (say 60 degrees) and then move it to the new position and hold it there. With that, you could have a physical switch for diff locks on or off. I haven’t tried this yet but I’m sure I will when I get the Zetros. There are also force sensors available via Spike Prime you can use as buttons. I don’t think the PoweredUp app knows how to deal with those yet, however. It’s funny you should mention it is expensive. I thought the opposite. I have a lot of motors and hubs laying around from the various sets I’ve purchased. I don’t tend to leave them assembled so I have lots of parts for MOCs and experiments like this. It’s a great use for otherwise unused parts.
  7. One of the biggest complaints I have heard (and felt) about PoweredUp is the lack of a physical controller. While Lego doesn't build one, we can build our own using Lego. Here is a proof of concept controller I built: It is meant to be reminiscent of classic hand held RC controllers for cars. Since this is a proof of concept, I didn't put much effort into styling plus the motors you see are just the random ones I had available. Here's a view of the back: The interesting thing here is that you can use the motors for position sensors and as the "spring" to return the steering wheel or trigger back to center. You use the "hold" code block to accomplish that. Here's the PoweredUp code blocks that hook this controller up to a 42124 buggy: Hub #1 is the controller and hub #2 is the buggy. For steering wheel and throttle trigger, you set the max power low (15% and 30% respectively) and tell the motor to hold its position. The bottom two code blocks hook up the buggy's throttle and steering to the controller. Here's a simple video to demonstrate it working: https://www.flickr.com/photos/188456966@N07/51337316883/in/dateposted-public/ The car is much more fun to drive around with this controller than using the touch screen. Using this same technique, it would be easy to make controllers of different physical form factors. There are two downsides I can see. First, the control is a bit laggy. This is often a problem using the touch screen controller as well. Second, you still need a smart device hooked up and running. I think it may be possible to use Pybricks and fix both of these issues but that becomes much more complicated for people to use.
  8. Glaysche

    T-Bot (3axis gantry)

    Yeah, I think you're right. It does at least sound better with the gray gears. I changed mine back, too. I also added some of my signature lime green accents. I'd probably call this "done" for now... until I think of something else to change.
  9. Glaysche

    T-Bot (3axis gantry)

    I played around quite a bit with the PoweredUp programming and ended up with this as a basic control: The top bit does initialization and calibration. The bottom bit does the controls. Here's a quick video I made. You even get to see me run the robot into the side. It still seems pretty quick even with the 24t drive gears. The rack driving in and out also seems pretty quick. There seems to be plenty of torque for that axis so I could probably gear it up more but it was tough to fit more gears in. (Embedding videos doesn't seem to work from Flickr): https://www.flickr.com/photos/188456966@N07/51323492017/in/dateposted-public/ One additional note: I made it a bit more robust with better axle support for the horizontal shuttle: Before this change, there was an 8t gear on a frictionless axle pin that would sometimes slide out of place. That's now supported from both sides and no longer has the problem. I also used the red 16t clutch gears with 3L frictionless pins. This more securely holds the frames together. It seems pretty robust now.
  10. Glaysche

    T-Bot (3axis gantry)

    I have found all the frame sizes incredibly useful for robotic arms. I ended up buying hundreds of them from Bricks and Pieces in all available colors and sizes. My 6 axis arm uses all sizes extensively. I think my new favorite piece is the 15L beam with alternating holes. The 11L version should be available in August and hopefully they will produce all the lengths over time.
  11. Glaysche

    T-Bot (3axis gantry)

    I can probably make a video tomorrow. Right now, the controls are basic through the PoweredUp app with the math thrown in so I can have one vertical and one horizontal slider for x and y that just control the speed. The in and out axis has a slider for speed as well which is problematic when you run it into the stops. I’m sure I can come up with something better with more experimentation with the PoweredUp coding blocks.
  12. Glaysche

    T-Bot (3axis gantry)

    @Mr Jos This is a very clever robot design. I'm impressed! I made my own interpretation of it: I made significant changes. I don't have an EV3 set so I made mine with PoweredUp components. I used medium Spike Prime motors and a standard control+ hub. There are no extension cables for PoweredUp motors so I needed to put the hub at the top where the wires will reach. I tried to make the external frame as rigid as possible using lots of frames, panels (in the top back) and triangles. I made the horizontal sliding piece out of 7x11 frames instead of 5x7 frames. This has the downside of reducing the horizontal range of the robot but it made the mechanics simpler and allowed me to use 4 horizontal 32L axles for better stability. This also allows me to keep the chains mostly parallel / at right angles which seems nice. Here's a close up of the horizontal slider: If you look very close behind and to the right of the bottom 28t gear, there is the red 8t sliding gear that transfers power down the right hand vertical 32L axle. That power is transferred from the red 8t gear you can barely see behind the 24t gear on the right. The red 8t gear in the middle is jammed against a 2L beam to keep it stationary. This pairs with a DBG 8t gear jammed against a 1L beam in the bottom module, closeup in the next picture. The right axle drives the gear rack in and out. The left axle attempts to keep the bottom module from rotating. This bottom module is as compact and symmetrical as I could make it. This was a super fun build and something I hadn't thought of before seeing your post.
  13. I would love it if theory #2 turned out to be true. I would love to see Mindstorms sensors that are wireless. Color or force sensor would be great. I would also love to see an encoder that’s separate from the motor to accurately measure rotation. I suspect that 600 mAh is probably too large for these applications, however, so it seems very unlikely to me.
  14. Glaysche

    Pybricks Q&A

    Thanks for doing this Q&A! Are there generic timers and counters in Pybricks? I looked through the API docs and didn't see anything. Specifically, a counter you can read that returns a monotonically increasing counter at a fixed frequency would be useful. That could be the number of ms that the hub has been turned on or perhaps a counter running at the clock frequency of the CPU. Also, a wait_until(count | time) would be very useful. There is a wait(ms) function but that's not quite what's needed. Being able to configure an event to be received at a specific time in the future would also be helpful. An example project that could be made with this is a clock. Say you want to update a display every second. You wouldn't want to put an update_display() and wait() in a loop because you would get cumulative error. If you instead used wait_until(), you could calculate the time to wait for to be exactly 1 second after the last one no matter how long the other processing takes.
  15. Glaysche

    Strange behavior with 51515

    Yes, indeed. My goal has not been to make a high precision, high performance robot for a private assembly line. My goal has simply been to push Lego as far as it can go. Before I started on this project, I didn't understand the limitations of plastic parts. I didn't understand that long axles act as rotational springs and can cause strange jitters in the output. I didn't understand just how flexible plastic beams are and how everything needs careful bracing in multiple directions to create a rigid structure. I didn't understand much about backlash in gears and how to mitigate it. This project has taught me all those things and more. Having the limitations inherent in Lego has been a great learning experience. Oh, and I have already destroyed a good number of Lego parts. I have improved the design to reduce the stress on those critical parts. If I happen to destroy a motor or two, that would be a bit of a bummer but I'm sure I will learn from it and figure out how not to destroy the next one. The software half of it is different. I actually have written software my entire career but at a much lower level than what is offered by Lego Mindstorms. I would feel much more comfortable writing C and assembly directly on the hardware. So my challenge to myself here is to do as much as I can with the tools provided by Lego and see what limitations I run in to. If I'm really lucky, I may be able to make some suggestions that can improve the Lego software roadmap. Even if not, it's still fun to challenge yourself to build something with constraints you have to work around.