Tech « Robot Claw

Archive for the ‘Tech’ Category

Things We Saw At The Computerspielemuseum

Tuesday, August 25th, 2015

A couple of weeks ago (it’s been that long?!) K, B and I visited a museum in Berlin dedicated to Computer Games. It was small, but it was very good, and perhaps even the best of the few I’ve visited over the years. Here’s a random selection of things we saw in the museum…

In the earliest part of the museum they had the landmarks of pre-computer gaming, such as (very) 1st edition Dungeons and Dragons:

And the first gamebook every written, Sugarcane Island (written 1969, published 1976):

They had holy grails of the Golden Age:

Crazy game art from the 1980s:

A small but good condition arcade:

A well-done series of rooms decorated to resemble certain ages of gaming. Here’s Bernard in the 1980’s attic room (presumably a typical German household attic from that era):

They also had Germany’s own homegrown console from the early 1980s. Only about 40 games were ever released:

You could design your own sprites:

You could post with Lara Croft(s):

Or you could look ridiculous playing Atari Ms Pac-Man using a titanic joystick:

And you could even risk your life playing the Painstation:

This is a massive two-player Pong game where the players are penalized for mistake in the form of heat, electric shocks or whips to the hands (see details here). We watched two people play it and as the game progressed they certainly seemed to be feeling the pain. I would have played it, but my compatriots were hesitant 🙂

As I said, a small museum but a goodie. If it wasn’t hot and we weren’t already overcome by ruination, I would have liked to have spent hours there reading all the information. Recommended if you’re in Berlin.

Posted in Art, Games, Tech, Trip | Comments Closed

The 30 year old Zoid

Thursday, May 14th, 2015

A few weeks back I went to a local convention and bought this:

I’m sure I don’t have to explain why, but in case you’re having a senior moment…

This, my friends, is a Zoid. Specifically from the series called ‘Robo Strux’, which were the US Zoid rereleases from 1985. Zoids are robot animals (often dinosaurs or predatory cats) and I’ve always liked their design. As a child we were too poor for me to ever own one, but I’ve been remedying that in recent years! I was agog to see such an old one for sale at my local con, and my agog-level doubled when I discovered it was unmade. A quick ebay search told me his price (at which I first baulked) was low, so I snapped it up. I was a very happy man that day.

Unquestionably the value of this product was mostly due to the fact it was still unmade and almost complete (only the sticker sheet was missing). Were I a fanatical collector, I would have put it somewhere safe and been happy in the knowledge I owned it. But I bought it to make it, and this past weekend I did. Here’s what was inside the box:

And this was between the pages of the manual:

So it was purchased in NYC back in March 1987, almost certainly for $9.99. That’s about $21.50 in todays money. Which is much less than I paid 🙂

The basic construction of the kits is remarkably similar to today’s models. There were several runners, molded in 5 different colours. It was snap together, and very easy to assemble with only cutters and a file (to remove the flash). However since the model is motorized and the legs need to move, some pieces were loose against each other and held on by interesting rubber caps:

Even after 30 years, the rubber was still perfectly pliable.

As a kit designed for children, there weren’t nearly as many pieces as one of the ‘High Grade Master Model’ kits I’ve been buying recently, but there were still enough to make it interesting and fun. The design was very clever, especially of the legs. Here he is the first time he was able to stand up:

Assembly took me about an hour, and was great fun. I wish the dude at the con had had more of these buggers for sale!

And here he is finished:

Oooh! Dangerous and mighty he looks, but Gordox (or more correctly Gordos) is apparently a specialized command unit more useful for his long-range sensor and communications than his offensive abilities.

He’s also a bit slow…

Isn’t he cute!

Posted in Animals, Blog, Crafts, Miscellaneous, Models, Otaku, Tech, Time | Comments Closed

The Nixie Clock

Sunday, March 22nd, 2015

Nixie tubes were invented in 1955 and were a popular pre-digital form of displaying numerals in electronic circuits. They use a technology somewhat similar to neon lights, and are designed so the shape of the discharge corresponds to numbers (or rarely letters). They were obsoleted in the 1970s by LCD displays, and even more so in the 1980s by pixel displays.

But they have experienced a bit of a resurgence in recent years since they are so pretty, and so retro. It is a great regret of mine that several years ago, while cleaning out old lab equipment at school, I discarded a (broken) nixie geiger counter from the 1960s. I should have kept it, and fixed it!

And then this year, for my birthday, KLS purchased me a Nixie clock do-it-yourself kit. I made it this past week, and it was easily the most challenging kit of any kind that I have ever made.

It starts with the above – many components, an empty printed circuit board (PCB) and a whole lot of fitting and soldering to be done. Now I’m not the biggest fan of soldering, and despite once being paid to teach others how to do it (hi Florence!) I don’t consider myself very good. But I borrowed an iron from school, prepared a comfortable work surface and started…

That’s about 3 or 4 hours later. Most of the resistors are in place, as well as the diodes and all the capacitors. I believe, at this point, I had soldered over 170 connections. It turned out to be easier than I thought, but at the same time very detailed work. If I didn’t have any experience at all, it would have been almost impossible to do it correctly due to how close some connections were.

The hardest thing to this point was actually preparing the nixie mounts. This photo shows the process:

The circular bakelite discs had to have the conductive pins pushed into them and then the whole thing was soldered to the PCB. The difficulty was the pins were molded inside plastic and you had to break them out. This was much harder than it should have been and I cut myself more than once. It was frustrating but I got it done.

The next step was to add the LEDs:

Then a few more components (including the chips) before testing to see if everything had been done correctly:

The relief I felt at this point was incredible. This was during the second day of assembly, after a half dozen hours or so. I’d been frustrated up and down by this point since the ‘instructions’ for the kit consisted of a series of forums posts on a website that were lacking (in my opinion) in certain pieces of information that would have made things much easier had I known them in advance.

But I was half way through the PCB assembly and it was working (the LEDs were lit and the current was ~20 mA). Here’s the back of the kit at this point:

The next step was to add the nixies, as well as the other essential components to actually make it a clock (motion sensors, crystal, battery backup etc.). Here’s one of the nixies:

The kit comes with five in total: four numeric and one symbolic (+,-.>.<). Putting the 13 leads into the sockets on the PCB was easily the hardest and most frustrating part of the entire kit, and took about an hour in total for all five. Here we are mid-process:

And when it was done – time to test it all:

OMG it works! I was super relieved here – everything lit up as it should have and the whole thing seemed to work. Little did I know I still had a lot ahead of me.

Next I had to start building the case. Unfortunately two pieces were received broken, and a third was miscut. The case as a whole was poorly designed, and the pieces didn’t fit together anywhere near as good as I feel they should have. I had to do a lot of sanding and drilling to get things looking acceptable (but as you see later, believe I mostly succeeded). Again, a complete beginner would have been in trouble in this step. Here’s a shot mid case assembly:

The five blue LEDs are asthetic, and you can see in the photo two above that they are all on (under the nixies). That was the last photo taken of them on, because for reasons unknown after I soldered the final component (the backup capacitor battery) and put it in the case the middle LED stopped working. Here’s a photo of the clock – all wiring completed – showing this (the case is not yet complete):

In the front, just to the left of one of the chips, you can see a black LED. Right behind that (slightly up left) is a sensor chip. These two parts are required to set the clock, which uses a virtual motion controlled ‘air switch’ to set features like time, date, 24-hour mode, alarm etc. It’s a remarkably full-featured clock, but mine had a big problem: the motion sensor barely works.

It took me endless trial-and-error to get the switch working, entailing making IR blocks out of black-colored paper and moving my hand around like a deranged puppet for about an hour trying to control the ultra-unresponsive switch. Countless times during this process I lamented the fact the designer didn’t just choose to add buttons. But eventually I got the time set, and now – five days later – the clock continues to keep perfect time.

Here’s a shot of my completed clock:

I think I did very well in hiding the breaks in the case, and I think the middle LED being burned out is mostly unnoticeable. In fact I think it looks very nice, and certainly is very striking in our entertainment center under the TV where it glows impressively in the dark.

The nixies are very, very pretty aren’t they. This shot is with the cover (of the case) of, and you can see a piece of blackened paper I have resting over the sensor to prevent it from flaking out again. The clock is permanently set to 24 hour time, and the middle nixie alternates between – and + every second. It’s quite lovely.

It was an extremely difficult and frustrating kit to build, and I don’t think it’s probably worth what it cost. But I did my very best, and it works and looks quite good, so in the end I’m quite happy with my new nixie clock 🙂

Posted in Art, Blog, Miscellaneous, Otaku, Tech | Comments Closed

How Far Can You See In The Woods (part 2)

Saturday, March 14th, 2015

If you’ve been reading the comments of the previous blog post, you will have seen Bernard coded the simulation I described. You can play with it here. This simulation doesn’t answer the original ‘field problem’, but instead the more general problem of ‘can you see your friend if you’re both standing in a forest’?

{A quick note: if it appears to crash your browser, just force-quit because the code is in an infinite loop. This happens a lot with high wood density and low tree radius. On an ipad, force-quit by returning to the home screen then double tapping the home button and swiping the browser up to close it.}

I’ve done some analysis using this early version of the simulation, and here’s a table of results:

That’s a surface plot of the percent chance to see your friend indexed by wood density (0.1 = 10% trees) and tree radius. A few comments:

– The distance between you and your friend is randomized.
– The tree position is randomized.
– The tree radii are unphysical, and the code doesn’t seem to support non-integer (cm) values.- I used 2500 trials each, except when radius was low (percentage ~ 0) where I dropped to 250.

Interestingly you can see the percent chance increases with tree size, but decreases with wood density. You are more likely to be able to see your friend if the trees are large, and less likely if they are close together. Currently there is no upper-bound on tree size, and it seems the percent chance simply increases as they get bigger and bigger.

As for the distance question, I’m happy to report that Bernard also added metrics to help you calculate this. I’m going to pick 20% wood density and 7m tree radius (!!) as an example. Here’s a simple representational plot of one such forest complete with friends:

In the above – generated by the simulation – the friends are far apart and can’t see each other. The obvious question is what is the relationship between distance and ability to see each other, and here are the metric results from 1000 trials with these parameters:

We can’t read too much into these since position is randomly chosen, but on first glance it seems (in this case) the friends were more likely to see each other at about 50 meters. However if you look at the bottom plot, you’ll notice there were quite a few occasions around the 50m mark where they could not see each other. I’d estimate about 20 or so, which means only about a 60% chance (seen/total) of seeing each other at about 50m. Glancing at the two plots it is, as we’d expect, the case that the chance to see each other decreases with any distance beyond standing adjacent.

So the results are interesting, but these are early days yet. Were I to modify the current code, here’s what I would do:
– Input wood density input as an integer between 1 and 99
– Input tree radius in cm
– Output result plots as percent chances per distance – one plot, rather than two, of (times seen at that distance)/(total times separated by that distance)
– Add variable tree radii
– Add foliage transmission support- Make the map circular, and distribute the trees according to a Gaussian distribution (this is more physical) {This may be for V2.0}

If and when these adjustments are made, you may see part 3 of this post 🙂
–

Posted in Miscellaneous, Otaku, Tech, The Unknown | 1 Comment »

How Far Can You See In The Woods?

Thursday, March 12th, 2015

This is one I’ve been thinking about for a while: how far can you see in a forest?

I’ve always been intrigued by the effect forests have on our vision. Even in forests where trees are far apart that you can’t touch two at a time, you usually can’t see too far. When Bernard and I went up to the Grand Canyon last year, the forests there are very light on underbrush and the trees have a decent distance between them and you still can’t see much further than a few dozen feet. When I was camping in January and I got up early and saw pademelons everywhere, I couldn’t see them beyond a few meters into the woods.

So I’ve been thinking, is there an equation that governs view distance in a forest? Which naturally led me to try and devise one myself.

Once you sit down and think about it, you find it’s a bit of an open-ended problem. So I decided to start by thinking about an easier problem, and then expanding from there. So consider this one:

“You stand somewhere on one side of a flat field, and your friend stands somewhere on the other side. The field is full of trees. What is the percent chance you can see your friend?“

This is not a brain teaser with an easy answer, and the result will depend on many things:
– Where you stand
– Where your friend stands
– The size of the field
– The number of trees
– The size of the tree trunks

Problems with many unknowns can get difficult to solve quickly, so the first step is to eliminate some. The first two (location of you and your friend) can be expressed as the distance between you and them. The last three (field size, tree count and tree size) can be expressed as a ‘wood density’ (ie. the total cross-sectional area of the trees divided by the area of the field).

I speculate the general solution is some function of the distance between you and them, and the wood density. But how does one calculate the result?

As I teach my students, always approach a problem from extremes. The two extremes here are easy:
– If the wood density is zero (there are no trees) the chance you can see your friend is 100%
– If the wood density is 100 (the field is chock-a-block with trees) the chance you can see your friend is 0%

So we expect an answer somewhere between 0 and 100%. This may seem trivial, but there are problems in which the percent range can be much tighter and it’s useful to know we have the full 100%.

But what if there is only one tree? Consider these possibilities:

On the left you (A) can’t see your friend (B) because a tree is smack in the middle. In the middle you can (the tree doesn’t block your view), but on the right you can’t either because the tree just blocks your view. Any general solution must account for all such possibilities (and an infinite amount more).

So how to calculate a percent chance for one tree? There is no way I can surmise to solve this via a general equation solution, so the required tool is computer simulation, specifically Monte Carlo simulation. In essence: generate a very large amount of ‘maps’ (of you, your friend and one tree) and calculate the percent chance from solving each and adding them.

For instance, if the only possible configurations were those shown above, the chance of seeing your friend would be 33.3% (only one in three maps). Of course there are many, many maps though (as many as you want actually), and it would be impossible to solve them all, so a more rigorous method is needed.

Here’s how I would do it – and I welcome any theorists to give their techniques in the comments. This is (at this point), for one tree only:

1) Randomly generate your position (A) on the edge of the field
2) Randomly generate the position of your friend (B)
3) Determine the vector connecting the two of you (AB)
4) Randomly determine the position of the tree
5) Determine if the vector between A and B is blocked by the tree

This last step is trickier than it sounds, and the easiest way to do it (aside from a clever technique I discuss below*) might be to:
5a) Calculate the vector passing through the center of the tree perpendicular to the vector AB (this just requires some vector algebra)
5b) Calculate the intersection of these two vectors (more vector algebra)
5c) Calculate the distance between the point of intersection and the center of the tree (easy)
5d) If this distance is less than the tree radius, line-of-sight is blocked

The simulation would repeat the above steps many (n) times, incrementing a counter (p) by 1 every time you could see your friend. The final result would simply be (p/n)*100%

I imagine with only one tree the percent chance would be very high. But what about many trees?

That’s only 3 possible examples (from a pool of infinity) of five trees (well, six on the left!). You can see how much more complex the problem seems to become.

Interesting though, the simulation wouldn’t change much. The only difference would be to step 4 above, which would become:
4) Randomly populate the field with trees, saving their positions in an array

And then step 5 would be repeated for every tree. You wouldn’t have to test every single tree against line-of-sight for each AB vector, you could just stop when one blocked the view.

With this modified algorithm, I’d save (into my output file) the following:
1) Position of you (A)
2) Position of friend (B)
3) Size of field
4) # of trees
5) % chance of seeing friend (output of simulation)

Tests would have to be run to find out how many times the simulation needed to be ran. One thing I learned writing my simulation for my PhD was how few runs were actually necessary. My code would have happily ran all day long simulating billions of photos (each of which required hundreds of calculations) but in the end I stopped at only 1000. I found that the variability of the results for photon counts above 1000 was essentially 0, so there was no need to run more. It would be interesting to do the above coding and plot the results vs ‘maps’ ran and see where the plot gets flat. I bet it’s lower than we’d expect.

Once the basic simulation was in place, modifications I would add include:
– Variable tree size. The wood density would decide the total cross-sectional area of trees, and you could rather easily vary the radius per tree and keep track of total area so as not to exceed the desired density
– Foliage. Trees (bushes) could have a ‘transmission ratio’, possibly linked to a secondary radius (to discriminate between trunk and leaves). So line of sight could be half-blocked for instance if you were viewing your friend through leaves (as opposed to blocked by a trunk)
– Variable field size. The field is nothing more than a construct to give some constraint to the problem. It would be trivial to instead solve the following: “You and your friend stand in a forest full of trees. What is the percent chance you can see your friend?“

I strongly suspect the results would show a strong proportionality between the magnitude of AB, the wood density and the chance of seeing your friend, and it’s likely an equation could be fitted to allow for a general solution. It’s tempting to suppose the trivial result would simply equal wood density (ie 50% trees = 50% chance), but my gut tells me it isn’t that simple.

One interesting consideration is the dimension of the field, and how it may affect results. I have mostly ignored it here, but it may be worth considering. Consider the following examples:

Each permutation has 6 trees, but the first two have very narrow fields, both of which will lead to very low chances to see your friend (for random A, B positions). It’s true that the ‘wood density’ varies strongly between the first two the one on the right, and I wonder if that will be enough to correlate the results. In other words, can the exact field dimensions actually be ignored?

So lets return to the general problem, and what has caused me to think about all this: How far can you see in the woods?

It’s a much more interesting problem to imagine, but I think I may save it for another post 🙂

About that clever technique: It occurs to me a completely different way of solving this would be to do it graphically and exploit hardware graphics techniques. For instance, make the trees sprites and draw a vector between A and B and see if there is a collision with a tree. Do this enough times and save the results. The resolution (and I don’t mean computer screen resolution) would be necessarilly less, but maybe this technique – which saves a lot of coding and vector algrebra calculations – could work?

Posted in Miscellaneous, Otaku, Puzzles, Tech, The Unknown | 6 Comments »

Robot Claw