Not sure if I missed it, but I didn't see any mention of how player moves are detected. Is there a camera and CV? It's always seemed like a fiddly problem to solve with electronics as you end up needing a matrix of sensors so there's a lot of wiring.
I’ve always wanted to try making a smart chess board (with no moving parts; merely detecting moves rather than making them).
I’ve thought of:
- RFID. Have 64 antennas and multiplex them to detect which piece is on which square (idk much about RF so this felt tough)
- Vision with a fiduciary mark under each piece, and an acrylic board
- Hall effect sensors, where instead of knowing which piece is which, it instead assumes the normal starting position and pays attention to which square was picked up from and which square was placed onto to infer which piece moved.
I think with any of these approaches it’d be fun to make a tiny, single-PCB board.
> RFID. Have 64 antennas and multiplex them to detect which piece is on which square (idk much about RF so this felt tough)
The professional-level boards by DGT use RFID and retail for about $500.
I looked into building a competitor some time ago. 64 RFID antennas alone would have eaten up that budget. I believe they do something smarter like having 8 antennas and arbitrating the signals. They have some patents in this area.
I've seen Hall effect and barcode-based systems too. They've always been a bit less reliable than DGT. Actually DGT is not all that reliable: if you are broadcasting a 20-player tournament you will need to manually update the broadcast around once per round. However I think the position detecting (hardware side) is solid and they could do with improving the move detection in software.
None of this is meant to deter you from building this as a hobby project! I think all the approaches would be fun to try.
Put an ultrasonic emitter and an accelerometer in each piece. When a piece completes a move emit an ultrasonic pulse pattern unique to the piece. Pick that up with 3 ultrasonic microphones places around the board and use the time differences between when the pulses arrive at the 3 microphones to find the location of the piece.
Maybe use 6 different frequencies (one for the white King, one for white pawns, and one for the rest of white, and similar for black) to make it easier to handle moves that affect more than one piece.
The moves that involve more than one piece are captures (one piece of each color), castling (one King and one Rook), and pawn promotion (one pawn, one piece of the same color that the pawn promotes to, and possibly one piece of the opposite color if the pawn captures during the promotion).
I was trying to do something like this a while back, our approach was to have a different color underneath each piece, with an elaborate setup to get the colors reflected into a camera, but I could never get the color detection working reliably with the way we were doing it. It was a fun project though, there's got to be some easy way to detect moves and get a cheap-ish internet-enabled board.
Yeah there are some trainer chess boards that use hall sensors to track piece movements. But I think there is a possibility to actually encode pieces with different magnetic field strengths and flip them for each player. That way you can just do stateless reads and you'll always get the correct readout, plus you can recover from illegal states.
I did a project [0] a few years back that did this absolute encoding for senet, since there is only one type of figure and two players so just flipping the magnetic field worked really well once calibrated. I still need to make a proper writeup/video on that thing one day...
My only comment is that it feels like there are too many items for the amount of inventory space.
There will be rooms completely littered with boots that you just walk past. Every time you see something interesting like a potion you have to first chuck away a pair of boots before you can pick it up and drink it.
Cute! I wonder how hard it would be, rather than having the houses "bounce" up, to make some kind of CSS animation that would look a bit like they were being sketched, some kind of gradual reveal..
Yes, I think it does. But in my understanding that has been controlled in the research as well. Also, there is also a short-term downside to the physical contact. For me it took years of training to become less anxious about the proximity of another person. You are minutes at a time in hugging position with a person who can be a total stranger.
A friend of mine has motion sensors connected to an automatic sprinklers to keep the deer from eating his plants. It works pretty well, even though it doesn't use AI. Just motion sensors.
This is exactly what I've been wrestling with recently.. it's so disappointingly absent in all the offerings out there.
The solution I ended up with was to build my own pseudo-idempotency around Postmark. It helps that Postmark at least has proper persistence so you can query their API to check if you've already sent a certain email. I had to move away from Mailchimp because, if an email gets queued for some reason, it isn't reflected as sent in the API so there's no way of knowing whether an email is hiding in "queued limbo". Postmark doesn't have this problem.
The only caveat is that there is a delay between sending an email and it being reflected in the API (seems pretty standard across the different services). This means I had to implement a simple database backed lock to make sure I never try to send the same email more than once in quick succession.
It's kind of ridiculous, but.. I couldn't find any alternative.
Edit:
Wonder if it would be worth wrapping something like this up into some kind of a self-hostable proxy service. You'd provide the idempotency key in a header and it would do the rest
Any chance you could run this on the Effect codebase? Definitely an example of a project that can be hard to navigate due to its scope and gaps in documentation
Oh I see it's already done! Is it possible to update it to the latest and greatest version? I have to say, the chat responses are quite impressive so far. The linking to relevant sections of code or documentation not so much. I guess that's a pretty hard problem.
Love the sound of this tool! Seems a bit of a shame to permanently delete anything that's been completed, sometimes it's really useful to have a record of what you've been working on.
> Love the sound of this tool! Seems a bit of a shame to permanently delete anything that's been completed, sometimes it's really useful to have a record of what you've been working on.
I did originally have that; it lowered the signal:noise ratio.
I've found that there's isn't a need to keep around any frames of context for things that I have completed: generally there's already an artifact from that frame of context anyway (write this function, call that person, design that foobar, etc).
reply