Eurobricks Vassals
  • Content Count

  • Joined

  • Last visited

About Heppu

Spam Prevention

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

Profile Information

  • Gender
  • Interests
    Robotics, automation, cars


  • Country

Recent Profile Visitors

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

  1. Really cool project and addition to an already amazing display of automation possible with Lego! Shame about the motor, hopefully it's salvageable somehow.
  2. Check Bricklink inventory for extra parts: https://www.bricklink.com/catalogItemInv.asp?S=42123-1
  3. Ahh, thank you so much for the insightful info! Yeah wasn't expecting anything spectacular from the camera. Was just curious because of the rather uncommon 356x292 resolution that there might be some better setting available. I will just stick to the Linux drivers then and try to deal with the bad quality :)
  4. Huge congrats to everyone who participated and especially the winners. Inventing new mechanics to move balls is a hard task, kudos to those who could.
  5. Oh wow, a pleasant surprise for someone to revive this topic just now! I've been toying with using just the camera for a project and got it working almost out of the box in Linux Ubuntu 19.04. with v4l2 drivers. The problem I'm facing is that with those drivers, the maximum resolution is 356x292px. Also the picture quality is also really dark and grainy. For comparison, here are some example pictures taken of the same model with different cameras in same lighting conditions. * all photos scaled to 640x480 resolution. So Im wondering, what are the improvements you experienced using the winXP drivers? Would it be beneficial for me to try and get this running instead with a WinXP VM? I would be ok if the image quality could be comparable to the Playstation 3 eye camera with 640x480 resolution. I've understood that 640x480 should be the theoretical max of the Logitech quickcam inside the Lego camera but the Vision Command software never enabled that.
  6. Sadly it's not really about the reliability but the speed. The current version processes balls at rate of ~1 ball/3sec. I would need to make it 3 times faster to be eligible for GBC standard of 1ball/sec.Big modifications would be needed to achieve that which I personally think I don't have time for atm. Something like that would indeed be cool. In general I'm not sure how viable using Mindstorms in multi-person organised GBC is. If something goes wrong, it can be almost impossible to quickly fix someone elses Mindstorms project.
  7. An update maybe? Or more likely a postmortem on all my attempts to make the stewart platform work as a GBC module. Unless some breaktrough happens, I'm not going to get this thing servicable for the contest. Here is the latest version: It is too slow, unreliable and not even close to what I had in mind when starting the project. It does not capture what movements the stewart platform is truly capable. Also I use 2 extra motors at the input feeder to just make the testing easier. In the future I had plans to operate the gate that feeds 2 balls at a time to the platform by just opening it mechanically using the platform tilting down to trigger the gate. I truly tried but no prototype really came close to what I wanted. The original pendulum idea was the one I fiddled with the furthest. The concept was 'fine' but the single axle connection meant that there was too much friction. Pendulum swings were too unpredictable and varied based on the weight of how many balls was in the scoop, often overshooting the desired ouput area with heavy loads. I got frustrated and tried to simplify the system by making the ball track static to the platform. First I tried a weird spiral but abandoned it because it would require another module to first lift the balls to required height. (Also it blocked the view of the main mechanisms which I did not like. Then I started experimenting closer to the latest version shown in the video above with a long circular track. It would have been nice to lookat, but the long track would have been too slow to meet the required 1ball/s requirement. That is why I decided to experiment with the more straight track shown in video instead (which is still too slow anyways). Anyways, good luck to anyone who is still participating! I'm kind of out of motivation to fix this machine when I know I'm most likely not going to present it at any exhibition as part of a GBC loop. I will still continue develop the stewart platform itself, but to some other purpose entirely. Cheers!
  8. Cool system and thanks for the video! Explains the mechanism better for sure. Impressive it can take so many balls at once! And you seem to be the first one to showcase a functioning module. I'm having so little time to work on my entry to iron out it's kinks, but hope to get something that works before the end. Also, glad that the angled gears approach worked. Personally I like to look of the model more like this. From the video it seems to work without issues using all the gears too and you gave good reasons to use them instead so use whatever is best for you.
  9. Looking forward to seeing a video of this. Sometimes just looking at pictures it's hard to grasp the full mechanism . Did you ever consider replacing the chain of gears at the top to bewel gear connections to reduce the amount of gears needed?
  10. Great to hear that everythig seems to be good to go ahead! I finished most critical parts of the control system code. Most important I calculated the inverse kinematics for the platform. It works such that I can input the height of the platform, tilt angle and the direction of the tilt. These are then converted and sent to desired motor angle coordinates. Second I made a reset function that calibrates the motor angles to a known value. It drives all the arms 1by1 towards the base until they drive against the axle with red bushes and and become 'overloaded'. Physically not much has change yet. The platform legs are changed from the modified bent liftarms to straight 7L liftarms to get a geometry that enables larger range of motion. made a small video to showcase the progress: In it the motors are calibrated and then the platform does 3 loops around at 10° angle. I was hoping I could pick up balls by tilting the pendulum up from below the box. Seeing the range of tilt angle and height now, I fear the angle range available might be too small for that. Also getting the pendulum to stop at exactly the desired position might prove difficult. These all might mean that the input box might also need a motor that is synced to load the pendulum when it is in position. We shall see.
  11. Sadly I do not own any working EV3 or other mindstorms hubs. I will use ev3dev operating system on it that supports both EV3 brick and Brickpi. There should be no major perceived advantage to using a raspberry.
  12. Promising start! I did a similar GBC back in 2016 and can attest that a wave-type module is a pretty reliable mechanism with little maintenance. Always a great quality to have for a GBC :) Looking forward to seeing where this goes!
  13. Hi, first time attempting to attending an Eurobricks competition. We shall see how this goes since my plan *might* be a bit too ambitious. The idea is to have a EV3-based 3DOF stewart platform to move the balls. I've wanted to make a stewart platform out of Lego for a while but never had a good application for it. GBC seemed like a good fit. Consept mechanism: Current status: In a three degree of freedom Stewart platform, 3 large motors working in tandem can change the platforms angle in 2 axis (roll and pitch) as well as move it up and down (heave). The current plan is to have a free moving pendulum with "ball fork" that pivots around the center of the platform. This fork would pick up balls on one side of the machine and swing to drop them off on the other side. The system will of course need an input sorter to lift the balls to required height. It will most likely be a semi standard stepper module. If I find the pendulum fork to be too unreliable or too slow to meet the 1ball/sec requirement, I might need to simplify the system. Most likely ditch the idea of the pendulum and use a fixed bucket and shute system attached to the the platform itself. There are still a lot of questionmarks with this project and wether it will finish in time. But I figured If I present it here, it might give me more motivation to work on it ;) ! Next up in line is to start on the code for controlling the platform and designing a better pendulum as well as some sort of input and output racks that mesh with it. Rules violation As is evident from the pictures my model includes non Lego elements. These are: Raspberry Pi with Brickpi3 board to control the EV3 motors. 3D printed case for the RaspBerry Custom made shorter length EV3 cables I understand that these violate the rule: "All entries are to include only real LEGO. No clone brands, 3rd party parts, or digital entries allowed." Since these are not part of the core mechanical mechanism to move the balls, I'm hoping these would be allowed. If not, I'm totally ok with that and will happily continue this project outside the scope of the TC23 competition.
  14. Cool project! Seeing and especially hearing all the mechanisms churn away gives it a nice vibe. This would definately be a hit attraction at some smaller Lego event. I don't see the need to change the color scheme to yellow but if you like that more, then go for it! (lots of rebuilding lol) As a minor thing I would attach the pneumatic cables better to to the claw structure so as to prevent them from hanging loosely and blocking the view.
  15. That's a lot of work for instructions on something only a few people (if any) could even consider building just because of its size and the piece count alone! Hope you enjoyed the process. I guess it will at least serve as a momento for you once its torn down and the pieces are used for other awesome projects.