Eurobricks Vassals
  • Content Count

  • Joined

  • Last visited

About Eddie_Young

Spam Prevention

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

Recent Profile Visitors

1288 profile views
  1. The slip gears are actually only used to separate the front from the rear (the rear needs more motor rotation to transform). But the programming you mentioned is what I was going for with this: (this is what makes the legs work) You can see that the same motion of the top axle can move all four joints. The 20 tooth gears can be added to either side of the 12 tooth ones and that determines which direction the corresponding joint will move in relation to the others. The trick then is to build the surroundings so that there is less friction for things you want to move first and more friction for the rest... Thanks for all the kind words
  2. Hello! I wanted to share my latest MOC. I had an idea for motorising as many joints as I wanted with a single motor (happy to elaborate if anyone's curious) and then I tried to think of a cool way to use it and voila - a transforming Monster Truck. Has anyone seen a motorised transformation in LEGO before? I'd be interested in seeing another because I was disappointed that I couldn't make the robot stand up without help. Also, I like to think I came up with something new I've made instructions available on Rebrickable and added some nice photos to Flickr. Enjoy!
  3. Aha!! Thanks for pointing that out. It was missing a "wind up" tag. Fixed it Thank you again @sirslayer
  4. The instructions are now available on Rebrickable if anyone is interested!
  5. I was afraid someone might say that... No problem! Although I believe you won't be needing my help anyway. Thanks for the support!
  6. Ah I see...I just think that a beginner wouldn't understand what purpose such functions serve and anyone more advanced than that can make farely easy work of improvising it himself. No problem! Explaining it made me feel smart (for once... ) and I'm glad you liked it. Thank you.
  7. Ok...But only if you support my WInd-up Robot!!! Nah, just kidding...here we go: In the video, I demonstrated the single joint option. The explanation will be much simpler for that program, as the amount of nerd-talk increases exponentionally with the amount of joints (I'll be using screenshots, because I have no idea how I'd share the actual program) This is the program in all it's beauty! Let's break it down: The file that "file access" refers to as "abc" is the value of the A motors degree count from the program's last run. The original files are created in a calibration software which I'd be happy to share if anyone's interested. The first block says to jump to the beginning of the file, then to copy the value into a variable (reading a variable is easier for the EV3 than reading a file) and then to delete the file so that they don't get mixed up later on. The next loop simply takes the motor's rotation sensor output, adds the motor's last known position from the file access variable and writes a new variable which tells the program the motor's actual position. This is repeated until you end the program with the enter button, at which point the motor's actual position is copied into a file for later use. The file "abcd" is the last known value of the C motor which represents the bottom joint. The string of file access blocks reads the last known value and sets the bottom joint into an upright position automatically, it then sets the file to 0 because upright is the starting position. This is where it gets interesting! The maths block is in the advanced setting and the equation is "-10*(atan(a/b)+c/24)" "a" is the beacon's proximity (the proximity variable is written in the third and last loop) "b" is the lamp's height which is, in this case constant. If we add a line representing the direction of the lamplight, we get a right-angled triangle with the legs a and b. This means that the angle between the lamplight's direction and the lamps height is equal to arctan(a/b) (or atan(a/b) in the EV3 software) and that angle is exactly the angle which the top joint controls! c is basically the rotation sensor output, it is devided by 24 because of the gear ratio between the joint and the the motor. Therefore c/24 is the actual angle of the top joint. Now that we have the desired angle and the actual angle, all we have to do is to find and correct the variance between them! c/24 is actually negative because of the way the motors work, which is why there's a plus instead of a minus. What I did now, is I fed this difference (that is: atan(a/b)+c/24 ) directly into the motor's power input. On finding that it was a bit too slow and did the opposite of what I wanted, I added -10* infront of the mess and voila! This one should be much simpler! The "wait for beacon" loop holds the whole program (including the other loops) until you turn the beacon on. This is done through the green data wire. Once the beacon is detected, the proximity variable is written from the sensor's output and the "heading" output is fed through this equation: a*abs(a) or a * |a|. All that does is give the square value while preserving the positive/negative factor. An a^2 would give you a positive number from any value (except 0) and we can't have that because the +/- represents the direction of the turntable. The IR sensor is mounted on above the turntable which means it doesn't matter where the turntable starts or finishes. That's why I don't use the same file access trick for this motor. I'm not the best with explanations, as you no doubt have noticed, so please ask away!
  8. I'm not quite sure how I would use it... Can you elaborate? Originally, I didn't think it would be a problem and then I was too lazy to change the design, so...
  9. I wrote about that in the description... It melted through a couple system bricks on my first prototype with a full lampshade but as it is, there are no problems whatsoever!
  10. My thoughts exactly kbalage! And thank you!
  11. You know when you build a huge MOC and your lamplight doesn't illuminate the whole thing and you have to constantly aim and re-aim the lamp? You might not know it but this adds no less than 42 minutes to your overall build time! Outrageous! Luckily, I've found the solution: The video may be left to speak for itself: Now the build is pretty simple. The base was the toughest part. Getting two independant spinning axles througha turntable while keeping the area nice and clean! The whole structure rests on four tyres to eliminate vibration and the resulting sound. the bulb is clamped by a worm and 8-tooth gear. I did not alter any bricks to fit the bulb and the bulb can be taken out at any time if anyone requires a purely LEGO lamp. And who would dare! The lampshade is how it is because the lighbulb was very mean and melted through the system bricks that formed the first prototype. It brought a respectable amount of tears to my eye. This new framy lampshade has endured over two hours of maths homework with no sign of wear! Now, the programming did require some little thought. The aim in the vertical plane is done through a load of trigonometry, while the horizontal aim works directly with the IR sensor's "beacon heading" output. One thought I'm particularly proud of is my use of squared and cubed values to slow the motor down as they approach their desired positions, thereby eliminating any shaking from hesitation or even indicision! That's all I have to say but I'll be more than happy to answer any question from a fellow moving-LEGO-lamp enthusiast, if there ever was such a thing! Please check out my Wind-up Robot on LEGO IDEAS! Thank you, for reading my words!
  12. If you say so Awesome!!! You should be proud of this one