@ this thread.



I've got a quarter that says he doesn't do it either.

11/12/2005 2:08:35 PM

I mean I hate to be a buzz kill, I really do, especially when tech talk is entirely too devoid of people doing cool shit....but this guy has a "feel good idea" or "grand scheme" about once a week. My guess is it coincides with when he takes his medicine or takes too much of it or whatever.

11/12/2005 2:46:57 PM

snewf is a pothead english major that will never accomplish anything more than managing a few shitty small bands - he just hasn't come to grips with reality yet

11/12/2005 2:51:26 PM

state409c is a faggot but he's right

11/12/2005 4:00:00 PM

the problem of identifying the pieces is ridiculously simple. just paint the bottoms of the pieces different colors and put a white LED and photocell beneath each square.

connect all the leads to a microcontroller and have at it. connect the output of the microcontroller to a serial port and send it to a PC for even more fun

easy peasy


hahahaha oh shit i just read the first post. Looks like great minds think alike. this actually is the easiest way of solving the problem

all you trendy ass motherfuckers with your fancy schmancy "RFID" are an embarrassment to the tradition of engineering

[Edited on November 12, 2005 at 4:18 PM. Reason : s]

11/12/2005 4:14:11 PM

11/12/2005 11:15:16 PM

i hate having to read the file name before you fucking "get it"

11/12/2005 11:23:49 PM

instead of the money can I kick you nay-sayers once in the balls?

11/13/2005 1:02:33 PM

you can do that even if it doesn't work

11/13/2005 1:09:42 PM

better lay some more finer points on this bet, or you guys are gonna be out $100

11/13/2005 6:49:25 PM

It'll cost well over $300 in parts.

Quote :

"If you are trying to use the thing like I think you are, then you are going to have to digitize the analog images it captures, and then process them - which, if I am not mistaken, is DIGITAL SIGNAL PROCESSING."

I assumed you were talking about Digital Sound Processing and digital audio synthesis.

11/14/2005 10:00:51 AM

if its all in software I don't think it will cost $300

11/14/2005 12:24:40 PM

you should just go with my solution.

11/14/2005 1:10:33 PM

This is so retarded I do't even feel like trolling it anymore.

11/14/2005 1:31:53 PM

i would definitely recommend not using the video camera setup. i'm thinking for reusability, you should make it a self-contained unit with the processing and logistics all taking place in the chess board and pieces.

in my opinion, it would be sooooo much simpler to program it using a two-dimensional array that holds the original configuration of a chessboard, and updates one move at a time. Only one piece ever changes its place on the board per move (except in the case of a capture), so after a move, you hit a little button on the board telling it to update. If there is one piece less on the board than the previous move, a capture has been made, and it checks to see where the missing occupied spot on the board is to know which piece was used to make the capture. If the number of pieces is the same as the previous move, it checks to see which piece moved. Very simple, and you could also easily program error-checking to make sure the move was valid--each square on the board is assigned a number from 0 to 6, 0 being unoccupied, 1 being king, 2 being queen, ... 6 being pawn. The program checks to see which square is now unoccupied, and uses that to determine the kind of piece which moved. Then it checks to find the now-occupied square, assigns that kind of piece to it, and checks to see if it was a valid move for that kind of piece.

all you would need for that kind of setup is any means you choose to determine whether a square is occupied. weight-sensitive squares on the board, electrical contacts on the bottom of the pieces that complete a circuit, etc. nothing is needed to distinguish the different kinds of pieces, because that's all held in the array. just need a switch to reset the board and tell it a new game should be starting.

If you don't like the artificiality of hitting a button on the board to tell it to update, then you simply integrate that button into the clocks being used to time a player's move, and then you have nothing which is outside the normal experience of a professional chess match.

11/14/2005 2:57:58 PM

^ that's still not as simple as my solution

but its the next best after mine, i'll give you that. and quite original

[Edited on November 14, 2005 at 3:14 PM. Reason : s]

11/14/2005 3:12:41 PM

Quote :

"the problem of identifying the pieces is ridiculously simple. just paint the bottoms of the pieces different colors and put a white LED and photocell beneath each square. "

Elaborate please.

Because I'll assure you, my system is about as simple as it gets from both a hardware and software implementation point of view. Much simpler than yours, in total.

[Edited on November 14, 2005 at 3:18 PM. Reason : x]

11/14/2005 3:18:18 PM

so then you just poll each sensor whenever your program wants to determine the placement of the pieces. the resolution of easily obtainable photosensors is so fine that you could probably actually just paint the bottoms of the pieces in gray scale.

11/14/2005 3:19:53 PM

Specifically, I am interested in how you distiguish among peices based on color?

11/14/2005 3:21:20 PM

Just realized it would take some extra programming to get around the case where a piece has more than one possible capture. However, this is easily circumvented if your board/pieces are designed in a way so that the computer can determine whether a piece is white or black. Then it can just check to see which space is now occupied by a piece of a new color, and that way it knows where the capture took place.

So, to summarize... have the computer store two arrays, one (array A) for the previous state of the board, one (array B) for the current state after a move. Now we need each cell to store two numbers, one indicating the kind of piece, one indicating the color of the piece. Say each cell is assigned (0,0) for unoccupied, (1,1) = white king, (2,1) = white queen, ..., (6,1) = white pawn, (1,2) = black king, (2,2) = black queen, ..., (6,2) = black pawn.

After a move is completed, compare the arrays--keep in mind the piece color is determinable by the computer because of the design of the pieces. Thus, at this point all we know is that each square is either (0,0), (*,1), or (*,2). Exactly one square in array B should now be unoccupied which was occupied in array A. Exactly one square in array B should either (a) be occupied which was unoccupied in array A, or (b) should contain a piece of an opposite color than it is in array A. If not, an illegal move or change in the board has occurred. The only exception to this rule, I believe, would be castling--this would be programmable by having a separate indicator variable which indicates whether or not the king has moved prior in the game. If not, it can check the board configuration to make sure castling was a valid move at that point. You'd really want to have a pretty kickass power chord play if someone castles. Totally. Maybe even a little guitar solo.

Here you also check whether the move was legal, in accordance to the type of piece which was moved, knight bishop etc. The computer reads the type of piece from the square in array A which is now unoccupied in array B, and determines whether that type of piece is able to move to the square which is now occupied in array B. The only quirk in this stage of the game is to make sure that if a pawn moves diagonally, you must have a capture (situation (b)), and if it moves vertically, you must not have a capture (situation (a))--also, pawns only move two spaces vertically if they were on their starting row. If an illegal move was made, you've got to hit some pretty massive dissonance.

If you have a legal move, then the computer now knows what type of piece moved, and if applicable, what type of piece was just captured. It could use that information to play different chords or music for any different kind of capture. It then assigns the type of pieces information in array B, completes the move, plays the music, and then makes B the new array A for the next move.

11/14/2005 3:23:48 PM

I think Excoriator's and my solutions are basically the same now, since I realized mine does need a way to distinguish white vs black pieces. though if he's talking about painting in gray-scale to distinguish each individual piece, not just white vs black, my way of doing that part programmatically might be easier. Then again, my background is in programming, not electrical engineering, so both might be simple.

i've just gone into a lot more detail than he has, giving the special cases for the program, etc, but that's the only difference.

11/14/2005 3:28:40 PM

And now you are searching desperately for "photosensors" to support this fanciful idea you have of distinguishing peices based on color.

11/14/2005 3:38:53 PM

the guy that wants to accomplish this - his background is in english

11/14/2005 3:41:26 PM

^^i'm not. i'll leave that to the engineers. i'll just program.

11/14/2005 3:43:05 PM

this is my very naive attempt at an idea to determine the color of a piece, since i'm not familiar at all with photosensors... each square on the board has two open circuits on it. put electrodes on the bottom of the pieces, but in different places on the bottom according to whether the piece is black or white. that way, one of the circuits is completed if the piece is white, and the other one if it's black.

that would, however, seem to be a bit dodgy if the pieces aren't placed precisely on the squares. maybe you could put an electrode covering the entire bottom of the piece on black pieces, but only a small dot in the middle of the white piece bottoms. then have a dot and a larger ring on the squares, so that if both the dot circuit and ring circuit are completed, it must be black; if only the dot is completed, it must be white. seems like that could be designed geometrically to be much less error-prone. just make the spacing between dot and ring large enough, so that the dot on a white piece could not physically complete both circuits. then make the ring large enough so that a black piece would always cover both circuits, no matter where it's placed in the square.

anyway, if i can come up with that in just a few minutes' thought, i'm sure an engineer who knows what the hell to do with circuits could come up with a much better system.

11/14/2005 3:49:46 PM

Not you, excoriator. Because at the moment, I don't see any sort of easy solution with anything based on light to detect the peices, this will take DSP...unless there is some other esoteric solution to this.

^^^ It isn't so much that Snewf is an English major, EcuAlum was a Business Major at ECU and could rape just about any regular poster on this board when it comes to .NET programming. It's the nature of this English major, which makes this a pretty laughable feat to attempt.

[Edited on November 14, 2005 at 3:50 PM. Reason : x]

11/14/2005 3:50:15 PM

ah, ok, didn't know if you had lumped me in with the photosensor crowd or not...

anyway, do you think that geometric circuits idea could work, perhaps?

11/14/2005 3:53:37 PM

Obviously the level of "error checking" and fool proof-ness will govern the complexity of the detection scheme. Even my grid layout has a few problems as I first specified it.

The concept of your idea would work fine, but then you need an extra wire to help determine which is which.

The idea that the game begins from a reference state should be all the information we need for "control". Any type of scheme that could be accomplished in hardware can basically be mostly accomplished in software such that you only have to know what the previous state was and from that point what are all the valid next states. Again, depending on what type of error checking and control is desired will determine how much additional hardware help is needed other than my simple grid structue. The ordinary mechanics of chess could be perfectly captured with just the grid, but if you wanted to guard against purposefully moronic things, then yea, you'll need more.

11/14/2005 4:35:42 PM

Yeah, but the reason I was saying you might need to distinguish color by hardware is that from the previous state, if you have a situation where one white piece could capture multiple black pieces, you would need to have a way to tell which square has the white piece on it now. Simply diff'ing the arrays wouldn't be able to distinguish between the captures unless you first have the color information from the squares. there's no way to "guess" which of the next valid states the player chose to take.

i agree it would be better if that could be done with software, but at least under my way of approaching it, i'm not thinking of any way that multiple capture possibilities could be resolved programmatically.

[Edited on November 14, 2005 at 4:51 PM. Reason : ]

11/14/2005 4:48:55 PM

determining what piece is where is a moot point - simple electronic chess games have accomplished this for years now - the computer knows how to respond correctly thus the position of every piece is known - i'm talking about games for under $50

http://boardgamecentral.com/games/chess_electronic.html

i can't believe you 2 argued about this ridiculous point for so long

11/14/2005 4:57:44 PM

i still stand by my camera idea

11/14/2005 4:58:36 PM

Your camera "idea" isn't an idea at all and get the fuck out of the thread please. Your faggot know it all ass doesn't belong here.

That $40 Kasparov looks to use as its control mechanism, one method I envisioned to not need to "know" per se which peice is which, but rather the last state and next state.

http://www.chesssets.com/cart/shopper.cfm/action=view/key=CL008?source=affiliates&bid=4042&aid=CD1723&opt=Kasparov_Travel_Chess_Computer

That is, you have to remove one peice in order for the next peice to be placed down. With a grid structure tied to a microcontrollers this is easily accomplished. The micro is fast enough to detect which peices are picked up and the final state. If it is whites turn, if the black peice is picked up first, then the white, its pretty easy to know what went where.



[Edited on November 14, 2005 at 5:09 PM. Reason : x]

11/14/2005 5:03:58 PM

it's pretty safe to say that entire chess set was made for ~$10-20 - and it includes logic for the computer counterpart - so snewf has nothing to worry about on the cash side - he's going to end up making money I'M SURE!!

11/14/2005 5:21:08 PM

Quote :

"Because at the moment, I don't see any sort of easy solution with anything based on light to detect the peices, this will take DSP...unless there is some other esoteric solution to this."

i'm being polite in this thread. i'd appreciate it if you'd stfu with your "fanciful" and "esoteric" comments.

getting to your question - i dunno how many chess pieces there are. Let's say there are 20 black, 20 white. So you need a gray scale with at least a resolution of 40, but 100 would be even better for error margin. If you bought a multiple-color photosensor then you'd have the highest resolution because you could paint each piece a different shade and color also.

But lets keep things simple and stick to grayscale.

40 pieces = 40 different shades of gray on each piece. the led shines onto the bottom of the chess piece reflecting X amount of light back onto the photosensor. Photosensor then puts the output, whether its a voltage level or frequency (which i prefer but don't sweat it) onto a wire which you feed into a microprocessor input. you'll probably have to put a decoder in there between the photosensors and the uP since there are so many inputs. the only "DSP" you need is the A/D convertor in the chip... I wouldn't really consider that dsp, but whatever.

i don't see why this is so confusing ... what part are you having problems understanding - the microprocessor or just the LED/photosensor mechanism?

[Edited on November 14, 2005 at 5:28 PM. Reason : s]

11/14/2005 5:22:51 PM

excorciator - i think nobody cares anymore unless that can be done for $20

11/14/2005 5:28:47 PM

Quote :

"our camera "idea" isn't an idea at all and get the fuck out of the thread please. Your faggot know it all ass doesn't belong here."

how is it not an idea
have one camera and software instead of individual photocells

11/14/2005 5:30:39 PM

^^probably pretty damn close. photosensors, leds, and the uP are very cheap.

[Edited on November 14, 2005 at 5:32 PM. Reason : s]

11/14/2005 5:31:13 PM

you're right... my literature background is not going to be helpful at all when it comes to executing the technical aspects of this project

good thing I don't intend on doing that
there's a reason I have a team working on this

a team thus far consisting of a programmer and all around tech genius from VA Tech getting a multimedia arts degree from UNC-A, another programmer, yet another programmer with a background in electronic music, a psych major and musician and an audio engineer

my role is management... I've got a little experience in that

11/14/2005 5:31:45 PM

Yes, we know there are commercial electronic chess games that do this; I had one when I was a kid. The one I had was operated by slightly pushing down the piece on the square before picking it up and then pushing down on the square when you put the piece down again in its new position.

That would work just fine; the reason I didn't mention it before is that I'm trying to envision a system that's entirely the same as a regular chessboard in terms of ease of play. No special buttons (again, integrating that into the clock), no pressing the squares with the pieces, etc.

The point isn't that you can buy something that plays chess; the point is coming up with a system from scratch as an interesting project, and making it play music as well.

11/14/2005 5:32:46 PM

this gets funnier with every post because it's snewf's vision

11/14/2005 5:35:08 PM

Quote :

"have one camera and software instead of individual photocells"

that would probably also work if the camera was mounted beneath the playing surface and the bottoms of the pieces were all individually colored. But its considerably more expensive than the photosensor approach. But that's not necessarily a bad thing - just depends where you want to make your tradeoffs.

11/14/2005 5:35:22 PM

i didnt figure the price of the camera because it isnt something that would be used solely for this project

11/14/2005 5:38:24 PM

the camera wouldn't have to be THAT expensive

but there is, without a doubt, an off-the-shelf solution to this problem

11/14/2005 5:39:27 PM

BTW, I meant multiplexer not decoder.

sorry - its been a long day

11/14/2005 6:38:32 PM

Quote :

"but there is, without a doubt, an off-the-shelf solution to this problem "

not really, because you still have to construct a transparent chess board and camera mount beneath that board.

11/14/2005 6:39:46 PM

its really hard to draw lines on a peice of plexiglass

11/14/2005 6:44:43 PM

hey i'm just sayin.

11/14/2005 7:21:21 PM

Quote :

"i don't see why this is so confusing ... what part are you having problems understanding - the microprocessor or just the LED/photosensor mechanism?"

There is nothing confusing really. I am just curious to see you flesh some more of the interesting details of this out. For starters, it would be interesting to see you produce a photosensor (a 5 minute google search didn't yield anything great for me) that includes the circuitry on chip to output voltages (or frequency) in steps based on the gray scale of what it sees. I assume since you are recommending something that such a part indeed exists and DSP wouldn't be needed as in the case of an optical mouse which is what this idea feels like. Secondly, I'd like you to describe how the light from the LED is going to illuminate the "observation area" but not wash out what you are actually trying to observe. As this is accomplished somehow for a mouse, I am sure it could be done here, but I'll be impressed if you know the implementation. Lastly, I'd be interested to know the engineering tolerances on both the input side and on the paint control for painting the bottom of the peices with. It is one thing to represent different shades on a computer screen, quite another to represent them chemically.

Quote :

"how is it not an idea have one camera and software instead of individual photocells"

It isn't an idea in that you don't have any idea what you are talking about or how to techincally accomplish it as a viable solution. That is, you are a know it all without really following through on anything.

Quote :

"there's a reason I have a team working on this"

A group of guys sitting in a circle taking bong hits and talking out their asses does not a team make.

11/14/2005 7:33:11 PM

my senior design project was this problem in another implementation. its very possible.

sometime i might dig up my old documentation and find the manufacturer of that photocell that outputs frequency (although that's not the cheapest route)

to avoid washout you just set up a dummy color w/ led and photosensor in a nonconspicuous area that acts like a control and calibrates all the other led/photosensor units. again, this is where having a higher resolution (error margin) is handy because you'll need it given the large number of components with their own variances.


[Edited on November 14, 2005 at 8:02 PM. Reason : s]

11/14/2005 7:49:27 PM

Quote :

" It isn't an idea in that you don't have any idea what you are talking about or how to techincally accomplish it as a viable solution. That is, you are a know it all without really following through on anything."

lots of high school classes already do a simple version of this (tracking checkers moves) with a legos robot camera. if we could do that then i would think that if they have someone that is experienced with visual recognition software (im told they do) then its a completely viable, reasonable way to go and i wouldnt be surprised if thats what they end up doing

11/14/2005 8:24:30 PM