No. The intention with the electromagnets wasn't really to prevent malicious cheating, just mostly to enforce cooldowns since it's very easy to forget/miss the different color of lights. The games are generally very chaotic and due to user error there are usually a few incorrect touches throughout the game that have to be quickly corrected manually anyways, so enforcing legal moves wouldn't make the experience better.
As for moving multiple pieces at once, the rule I have is only one hand and one piece at a time. This goes a long way towards preventing accidental bumps into other pieces and weird board states where there are multiple pieces in the process of being moved at once.
Hey, I'm the one who made this! My video on it probably does a better job of explaining it than the github so I'd recommend checking that out: https://www.youtube.com/watch?v=y7VtSK23_Jg
If anyone has any questions about the engineering process/game itself I'd be happy to answer.
Thought about both of these, for various reasons they won't work. Trust me I spent a decent amount of time on this, I think objectively making the bottom transparent with thicker acrylic is the best solution, but motion tracking is the other viable option and I wanted to play with the cameras.
I was thinking about spending an hour or two hooking up a chatbot api and maybe even sending it live position/score data so it could customize it's trash talk, but in the end I just wanted to get the video out so didn't. Would have been funny though!
(I'm the person who made it) Yeah that's fair, but at least for me I wanted to focus on the interesting part of "making a foosball robot" which is the "foosball" part, not the "fiddle with a home built vision system that doesn't actually work" part. I realize this is a bit ironic given my channel name though haha (From Scratch).
Yeah, that's so the robot knows where the human is so it can accurately make shots. I didn't mention it in the video since it was more of an implementation detail and not too important to understand what's going on.
I think it has a lot of technical merit and I heavily appreciate the fact that it's open source which is why I used it here. That being said in terms of microcontrollers I don't think it's doing anything fundamentally that much better than ARM, most of it's competitive advantage just comes from the fact that it's open source.
Edit: just as a disclaimer I've never actually written any ARM assembly/silicon design so I'm probably not the most qualified to have an opinion on this
Thanks, was definitely hard to strike a balance between being understandable for non-nerds but also convey all the technical difficulties/achievements, but I'm pretty happy with how it turned out .
It was pretty much just me by myself on this other than for the raycaster engine, which was done by a friend of mine near the end. I'm on a few Discord servers on Minecraft computing, but it's pretty vastly different and the biggest parallel is just with high level accelerator stuff.
I would say the RISC-V immediate encodings were like that, on first look they seemed completely random but as soon as I started implementing the decoder I realized they were geniusly crafted to make my life as easy as possible.
I'm the one who made this. It's rv32i, and yes the 2017 specs. It passes every rv32i test in the repository you sent, see the test/ folder for the riscof plugin I wrote. I also have CI in a docker to headlessly run Terraria and programmatically run all these tests whenever the world changes on the main branch.
I'm not throwing around fully compliant lightly here!