PDA

View Full Version : How to divide analogue signals



thor
03-23-2011, 02:43 PM
OK I just got this working. It is a method to divide one analogue signal by another.

What it does:
This is a physical solution to dividing signals. Signals are treated as 100% = 1.0

Limitations:
3 decimal places of precision most of the time, 2 decimal places only in some situations
Doesn't work if the denominator is less than 23%
Due to 100% limitation if denominator is smaller than numerator it won't work (I think it returns 100%) - repeated subtraction can solve this
Takes a few frames to come up with the correct solution
Negative values not handled (they are, but since I use a tag sensor to measure distance it loses its sign) - this is easily remedied

Pros:
Not needlessly complicated
Low thermo
You can divide!! (And multiply!!)
Good for situations where you input continuously changing values, then the response time is lower
For certain ranges of values it has higher precision than 3 decimal places
Fun to make :)

How it works:
The joystick rotator! This allows us to put actual floating point values into the "real" world outside of logic. Unfortunately it has some drawbacks (the 23% thing is one of them). Seeing as we have no "positional" setting for pistons or movers or anything (how annoying), this is what we are stuck with. However it is very useful, because it already divides values for us.

The joystick rotator rotates an object to an angle arctan(y/x), where y is the up/down speed, x is the left/right speed, and arctan is the inverse tangent function. Now all we need to do is find the tangent of this angle, and we are done! Well here's a useful diagram showing the tangent:

http://upload.wikimedia.org/wikipedia/commons/thumb/9/9d/Circle-trig6.svg/500px-Circle-trig6.svg.png

In my solution I rotate the circle so that the tangent to the circle is vertical (note: there is no actual circle in LBP, but it is good to imagine as though it is there). Also I change some things around so I actually am changing a different angle with the joystick rotator, but the result is the same.

Now I just need an object which can both stay at a fixed angle to some object, whilst remaining on the vertical tangent line. I tried pistons and collision-based systems but both ultimately failed. Pistons drift very easily when you input rapidly changing values, and the collision system is not robust enough to deal with fast-moving objects - they either get destroyed, or if they are indestructible, they become embedded in each other.

The solution was to use two followers, max speed & acceleration, on two bolted pieces of material. Both disallow up/down movement, and one is on the piece that rotates with the joystick rotator, the other has a gyroscope to keep it upright. A not gate plugged into itself + another not gate provides a pulse that flips between the two followers so that neither one impedes the other's movement. This is a source of delay and I would love to hear a better solution for this.

Now measuring the tangent distance is actually tricky. Because of how the tag sensors work, you need to set a minimum distance so that it doesn't give zero distance for small distances. I have used a minimum distance of 0.1 and then added a fixed amount (truncated addition) to give the most accurate results. This is the biggest source of imprecision believe it or not. I would love a better solution to find the EXACT distance to an object, because it would make this a lot more accurate.

http://i3.lbp.me/img/ft/d738dc9115ad8da120c76472ce293cd834e8bd4f.jpg

On this image you can see two batteries (inputs), a "circle" centred at the green tag, a "tangent" meeting it at the blue tag vertically, and the device itself with its two microchips, and an output going to a logic probe beneath.

Edit: Here is an example; 0.5/0.9 ~ 0.55554

http://ic.lbp.me/img/ft/a9cd0d77bf591f4d37956b4a82a9f11e01acf3cd.jpg

Other things you can measure are actually easier to do; these include:
sin(arctan(y/x))=y/sqrt(x^2+y^2)
cos(arctan(y/x))=x/sqrt(x^2+y^2)
sec(arctan(y/x))=sqrt(1+y^2/x^2)

waD_Delma
03-23-2011, 04:55 PM
http://i5.lbp.me/img/fs/155417716bd0ebf5f522acd695c542322bbccd93.jpg (http://lbp.me/p/yxk8g-)
Could you use tags like in this?
I don't know if it's more precise but you might want to try (http://lbp.me/v/yc3h7-) it.

Dividing signals this way is very useful but only if you don't need object to be emitted.
(http://lbp.me/p/yxk8g-)

comphermc
03-23-2011, 08:56 PM
http://i5.lbp.me/img/fs/155417716bd0ebf5f522acd695c542322bbccd93.jpg (http://lbp.me/p/yxk8g-)
Could you use tags like in this?
I don't know if it's more precise but you might want to try (http://lbp.me/v/yc3h7-) it.

Dividing signals this way is very useful but only if you don't need object to be emitted.
(http://lbp.me/p/yxk8g-)

That is too small to be helpful. Try this:

http://i5.lbp.me/img/fl/155417716bd0ebf5f522acd695c542322bbccd93.jpg

thor
03-23-2011, 09:14 PM
http://i5.lbp.me/img/fs/155417716bd0ebf5f522acd695c542322bbccd93.jpg (http://lbp.me/p/yxk8g-)
Could you use tags like in this?
I don't know if it's more precise but you might want to try (http://lbp.me/v/yc3h7-) it.

Dividing signals this way is very useful but only if you don't need object to be emitted.
(http://lbp.me/p/yxk8g-)

I played your level, nothing that divides there (perhaps you misunderstood me?) but the device to convert an analogue signal to a length was pretty cool. It got me testing the tag sensors and as I posted in this thread (http://http://www.lbpcentral.com/forums/showthread.php?53573-Tag-sensors-how-do-they-work&p=811975#post811975), I don't think my machine can get any more accurate due to the limitations of the tag sensor...

thor
03-23-2011, 11:23 PM
Update:

Since playing with the tag sensor I decided that using lengths of 9 grid units (22.5 units) was best because it meant I could place everything on the grid to get most accurate results from the tag sensor - I also set the tag sensor itself to have minimum radius 0. Making the whole setup bigger could also result in more accuracy, but I've decided against that for now because I prefer it compact. It's also accurate to 3 decimal places now (I think all the time) and doesn't have the same "warping" at values near 0 that the old method did. Note that I still had to correct by a fixed amount (this time I subtracted 0.0006, only if the result was not exactly 1.00)

This time 0.5/0.9 ~ 0.5556
http://ia.lbp.me/img/ft/62acd0dc18959c57936dd8243e776e24889549ec.jpg

0.3/0.8 ~ 0.3751
http://ic.lbp.me/img/ft/1fc10d2de4eef0eec9a23b960823a93b798af47f.jpg

0.14/0.47 ~ 0.2980
http://i0.lbp.me/img/ft/7e044dae2f5987e7a0b21b52296a215625f69418.jpg

Thinking about it it may be beneficial to subtract a further 0.0001 but this makes it less accurate around 1. Swings and roundabouts :)