Archive: 10 posts

---

I was back thinking about manipulating analog speed and thought long and hard about how I could "capture" a speed. You could think of it as a single register for an analog value. I'm happy to announce that my Speed Conversion demo level now includes a demonstration and prize (optional of course) of a system which will store the analog value of a Speed switch whenever the latch button is pressed. The system works by driving a piston (piston block) at the desired speed for a fixed amount of time. This piston block pushes another block (magnet block) closer to a magnet sensor until time expires. After time expires a winch draws the piston block back, leaving the magnet block to maintain the analog value. Think of it as analogous to the single bit storage blocks that push a block near or away from a sensor to hold on to a single digital value. I've had some material troubles, where the rubber-on-dark matter simply is not providing adequate friction. When I switched to rubber on rubber things started breaking. If you can improve upon this idea please let me know.

2009-02-14 05:13:00 Author: larryjoe701 Posts: 68

---

Rubber on glass maybe? Not entirely sure what you mean.

2009-02-14 07:48:00 Author: Whalio Cappuccino Posts: 5250

---

I looked at it and I was thinking, how would we use this in a level. Its well made but I don't see a point, although good work

2009-02-14 12:01:00 Author: Defaultsound Posts: 137

---

Rubber on glass maybe? Not entirely sure what you mean. The problem I'm having is that the magnet block is sliding, who'd is reducing the overall accuracy. I'll give glass a try. I think rubber on rubber should stop the block the fastest, but like I said it was binding and breaking. Last night I had a thought where I replace one of the winches pulling the magnet block (two for less binding) with a zero strength stiff piston. Then maybe I can go back to rubber on rubber. I looked at it and I was thinking, how would we use this in a level. Its well made but I don't see a point, although good work I assure you that someone creative can find a use for it. Already I had thought about a distance measure for an obstacle course and another way to implement 2-player puzzles.

2009-02-14 14:51:00 Author: larryjoe701 Posts: 68

---

This sounds very clever. I would like to see it used in a level, although I dont see what use it would have.

2009-02-14 14:58:00 Author: moleynator Posts: 2914

---

I checked it out. The storage mechanism was cool. A thermometer-saving way to do it would require sacrificing a level of accuracy by having multiple AND-gated-to-enable mag speed switches along the piston path. Cool stuff.

2009-02-14 20:44:00 Author: snowflakecat Posts: 102

---

With some thinking about calculus and differential equations (or maybe just trying stuff out) I have a much better speed storage system. It is now also in my Speed Conversion demo level. Pros: - No more waiting - Continuous updates - Switch controlled storage - Functions as a speed->position converter... you CAN control the position of a block now! Cons: - takes several layers - requires a bar twice the range of the sensor (though you can flip in and have a little cart travel around the level... perfect for those levels where something follows you) How it works: The key is a wheel that performs subtraction... layer one wheel with a motor bolt on top of another going the opposite direction. Connect one to a speed signal of your choice while the other is connected to a mag sensor on dark matter. Place a long bar with a magnet on top of the double wheel (outer most disk, add a second for stability). As the bar moves the magnet closer to the mag sensor, the two speeds cancel each other out on the wheels and the bar stops. Change the input signal and the bar will move in or out to match it.

2009-02-20 04:13:00 Author: larryjoe701 Posts: 68

---

yep I also implemented this idea after reading about it in larry's other post. You're basically rotating a wheel attached to another wheel with speed that matches the input speed. Any change in speed on the input wheel would cause a finite movement in the attached wheel before the speeds match up again. If you rest a bar on top of the attached wheel the difference in speeds can result in a physical displacement. The ability to attach a wheel to another wheel means that you can take the incoming speed as a reference so discrete methods wouldn't have to be used. The beauty of it is in mechanics. Often times limiting the dof of an input allows different reference points, making problems easier. It has less to do with calculus and differential equations and more to do with mechanical engineering IMHO, since all this stuff was probably used centuries ago albeit with gears and counterweights.

2009-02-20 06:39:00 Author: snowflakecat Posts: 102

---

The implementation is certainly mechanical engineering, and people were able to build certain machines prior to their understanding of calculus, but the principles of calculus are inherent in this particular machine. Consider a bar on a wheel with a speed input. The displacement of the bar is the integration of the speed signal. In this way you could make an throttle, which controlled a wheel and put a displacement sensor on the bar (using magnets) and use that speed signal to control... well... speed. In doing so we have converted a speed signal to displacement (basic physics calculus) and then used the displacement value as a speed. When we incorporate a bit of feedback into the bar displacement, then we've moved into differential equations (calculus with feedback, basically). I took a mechanical engineering class once (well part of one, fluids) and they were all about calculus I liked your various ADCs and DACs SnowFlakeCat, and how you used the speed storage system to make the ADC. You definitely had some creative ideas. Like SnowFlakeCat said, with the ability to convert speed to position we ought to be able to build machines that perform all the analog calculations we might want. For example, a very simple one is to turn a speed signal on/off. Just have the speed input connected to the speed storage system for on and to turn off, just "store" the speed and remove the magnet sensor using a normal piston. The operations I've been thinking of are as follows: On/Off control Probabilistic AND (a * b) Probabilistic OR (a + b - a*b) Minimum of two inputs Maximum of two inputs Inverse of an input With the speed signals converted to position we should be able to use geometric construction to calculate some of these. If anyone knows of a way to "construct" multiplication, please post it. I have an approach which uses similar triangles but thus far have not been able to implement it.

2009-02-21 18:11:00 Author: larryjoe701 Posts: 68

---

nice post larry. Like you imply, everything can be deconstructed into math. The difference between math and engineering is application, and since LBP is about creating devices in a world which simulations physics, well, it would be more engineering than math. The concept is mathematical (integration), but the device is the result of engineering. I think with the ADC proof of concept it would be easy to do 1-6, with two inputs possible by having an additional wheel (three in total, the last is the one that counteracts the speed differences of the two input wheels, similar to the two wheel ADC setup). Analog capture like you said would simply involve a vertical piston that moves the bar away from the wheels, which can easily be done but would require some tweaking due to weight (A heavier bar would require more traction to achieve the same displacement with equal responsiveness). I've thought about an analog multiplier but don't have a good idea for the implementation yet. Since I am an electrical engineer (unemployed =/), I would probably use the ADC to simulate op-amps, comparators, etc which were used heavily during the vacuum tube age (everything is still analog today; it's just that digital has made specific circuit designs less relevant when the same can be achieved by programming a uC/CPLD/FPGA). Since variations in the speed can be sampled, this opens the possibility of DSP (the actual implementation of DSP would be more thermometer intensive, so signal processing is probably best kept analog). When all is said and done, having analog equivalents of "digital" LBP logic is to introduce potential thermometer-saving devices at the expense of setup and configuration time. I might consider publishing a speed manipulation level for creators using EE equivalents (will have to teach and model transistors, etc).

2009-02-24 02:30:00 Author: snowflakecat Posts: 102

Posts: 1077139    Threads: 69970    Members: 9661    Archive-Date: 2019-01-19

Aus dem Archiv wurden alle persönlichen Daten wie Name, Anschrift, Email etc. - aber auch sämtliche Inhalte wie z.B. persönliche Nachrichten - entfernt.
Die Nutzung dieser Webseite erfolgt ohne Speicherung personenbezogener Daten. Es werden keinerlei Cookies, Logs, 3rd-Party-Plugins etc. verwendet.