Building a Robotic Chess Piece

[00:00:09]For over 1,400 years, people use their hands to play chess. Gross. I can fix that. Sure, there have been robots built to move pieces automatically, but they can only move one piece at a time. So, I thought, what if I made each piece an independent robot capable of thinking and moving autonomously? I'd like to see somebody else try that.

[00:00:30]Ah Well, mine is cooler. It can wiggle. It can jiggle. It's nearly silent. It can Well, that's pretty much it. But it's only 31 mm in diameter.

[00:00:40]It's powered by stepper motors. Costs only $10 each. Oh, and it can self-locate on this board. And you bet it took a ton of work to get to this point. So, let's get right back to the start. That way, you can see everything that went wrong along the way. And here's the first version. It literally didn't work at all.

[00:00:58]This is my first time building a PCB with an ESP32. And wouldn't you know it, the hardware dev guy that they have.

[00:01:04]It's got some good tips. So, I made some changes and ordered a fixed replacement.

[00:01:08]These boards take about a month to produce. So, in the meantime, I reworked the original boards to make sure that next time it's going to be fine. And sure enough, I was able to get that board booting and enumerating. Yay.

[00:01:19]>> Not too much later, I got motors spinning on it. Great.

[00:01:24]Now, these motors are dumb. And by dumb, I mean cheap, brushed DC motors. Why?

[00:01:30]Well, size and cost both are critical for this project. But these tiny motors have no gearbox and basically no torque.

[00:01:36]So, I need some way to gear it up. For that, I came up with this maybe lazy or maybe clever motor mount. The motors just drive the outside of the wheels directly and are pulled up against them using O-rings as springs. The only problem was getting enough traction between the motor spindle and the wheel.

[00:01:52]In comes McMaster car to save the day cuz where else would you find heat shrint tubing this insanely small and yeah that actually worked pretty well.

[00:01:59]The motors spin the wheels now. And this exposed my second hurdle and it's a big one. The motors that I picked out, they have so little torque that I just can't spin at any slow speed consistently. As I said before, a gearbox would help, but those take up a lot of space and they're fairly expensive. So, back to the drawing board. Maybe the solution to my problem was hiding in plain sight all along. Like, you see this lens? Wait, no. The camera needs that to work. Okay, better. Well, this lens must have some kind of tiny actuators to handle moving the lenses and focusing and all that, right? Right. In the past, I frequently relied on stepper motors for their high torque and precise control. So, why the heck did I not use them here? Well, they're a bit too big. Or so I thought.

[00:02:43]Turns out a lot of computer accessories and, you guessed it, camera lenses use stepper motors. And you know what that means? Not only do these exist and they're really tiny, but thanks to mass production, they are insanely cheap.

[00:02:54]Driving them was another problem, though.

[00:02:58]With brush DC motors, all you really need to do is apply power. To slow them down, you reduce voltage or PWM the power lines. If you want to change directions, you need just a little bit more silicon. An Hbridge will do the trick. These chips are very cheap and still very simple to control. Stepper motors, though, they require a little more precise control of the motor's internal coil sets. For ideal motion, you want to drive it using two phase shifted sine waves. In reality, though, stepper drivers handle most of the hardware, but this added complexity does drive up the cost of the IC's. I'd say it's worth it, though. Steppers can produce more low-speed torque more precisely, and they're quieter, too.

[00:03:36]Oops. Uh, anyway, this let me attach the bot wheels straight to the motor, which really simplified my design as well. So, I keep mentioning size and cost are my main constraints. Why? Well, I want my chest set to look as normal as possible.

[00:03:51]And the smallest piece, the pawn, is typically around 30 mm diameter and 50 mm high. But cost, on the other hand, well, consider this. I don't have one chess robot, I have 34. Even if I get each bot down to just $10, which is quite impressive. That's still $340 in total. Yikes. In addition to that, I'm also going to want to have precise motion control between 10 and at least 100 millm a second. Obviously, I'm going to need an onboard battery, power management, wireless communication, and keeping power consumption low would be nice to get longer run times. And finally, the best for last. I need a way to locate each piece on the board with subm accuracy to make sure the pieces can navigate around each other. And did I say best? I meant hardest. How the heck am I going to do that? Way ahead of you. See this collection of smart rocks?

[00:04:38]No, not those. These rocks. Yeah, these are responsible for amplifying audio, specifically ultrasonic audio. From this ultrasonic transducer, the plan is to more or less mimic how GPS works. But rather than develop my own space program and deploy geostationary satellites into orbit, I'm just going to plop these ultrasonic transducers in a few known locations and then have the robot record how long it takes to receive a signal from each station, allowing it to calculate distance to each. And as long as you have three distances and you're on a known plane, you can triangulate your position. But in the end, I never really completed this concept for a few big reasons. First, this transducer is massive and I would need to put it at the top or inside every single piece somehow, which is ugly and big and difficult. Second, this is only going to get me position, not orientation. And finally, my dog would just really hate this idea, so I killed it. But I retain its essence in my new plant. Have you heard of electromagnets? Probably. And I've had such great experiences with them.

[00:05:41]Oh no. So maybe I can somehow use those for bot location. Unfortunately, this magnetic field sensor that I've always used in the past is just not nearly sensitive enough for the task.

[00:05:52]Thankfully, I came across this one, a magnetoresistive three-axis sensor. And hooking up the devboard shows that yeah, it is insanely fast and insanely sensitive.

[00:06:04]Perfect. So, here is my plan. The chessboard will have a bunch of embedded electromagnets. I turn each of them on and off one at a time, and then each piece will use its onboard mag sensor data to somehow approximate its position on the board. Will it work? No, that's the wrong question. It has to work. Hey, new PCBs are here. Before writing some code, I'd like to thank PCB Way for providing their assembled boards and sponsoring this portion of the video.

[00:06:28]Check out all of their prototyping capabilities using the link in the description. And these boards look perfect and mostly they were. But hey, I need to put some code on them first.

[00:06:37]Want to see something cool? Hey, look, code.

[00:06:40]Okay, seriously, I wrote a lot of code.

[00:06:43]And this is my first time using free arts in a project. Free arts allows you to schedule a bunch of simultaneous tasks way more easily. This did add some unexpected complexities, but that's for later. In short, I have a base station that's going to transmit a message to each bot using the ESP now network. Each bot receives and parses its message and then executes the command. And finally, it'll send back an act or knack to the control station and include additional info like its position and battery level. So now we've got wireless controlled wiggles. Nice. Now the astute among you may have noticed the board shape has changed quite a bit. I don't know how, but I somehow managed to fit all of this functionality into a four-layer 28 mm circular PCB with a bunch of cutouts in it. That probably doesn't sound super impressive, but it's less than half the size of a normal ESP32 dev module, and it has so much more capability. Now, the astuterver of you may also notice some soldered wires on this one board. Yeah, don't trust random data sheets you find online. Uh, my my stepper motors had a completely different connector than what I thought they'd have. Uh, potatoes, potatoes, right? This board has the onboard stepper drives, the mag sensor, the battery charging, voltage regulation, and everything else that I need. And does it all work? Somehow, yeah. And now you're all caught up. What's next? Well, I haven't talked too much about the control station yet because as of now, it's just an ESP32. Eventually, this will be on its own custom PCB with all the added accessories that I need, but I'm still working on that part. And I probably should have started working on the electromagnet based positioning algorithms, but that's kind of boring.

[00:08:17]I've got a better idea. Remote controlled chest pieces. Yes, perfect.

[00:08:23]Does this advance the project in any way? Technically, no. But it's fun. And this did let me test out the capabilities of the robot a little more directly. Both the mechanics and the software.

[00:08:41]It's lights out and awake.

[00:08:44]>> So, after distracting myself with at least a full day of this, back to the task at hand.

[00:08:52]>> And that means figuring out the electromagnets, preferably without breaking anything this time. Yeah. Yeah.

[00:08:58]Okay, I get it. Now, I don't exactly know what the optimal coil properties would be for this application, but my intuition says going thin and wide should give me the widest effective field range and also keep my board profile pretty slim.

[00:09:12]I threw one together and powered it.

[00:09:14]Yay, electromagnetism. It it now it's not very powerful, like at all, mostly due to the lack of a core, but this was not a mistake. Coreless electromagnets have a lower impedance and a less focused field, meaning I can switch the signal faster and it should spread out wider. Now, to enable driving them both forwards and backwards, I'm using an Hbridgeidge just like what those original DC motors used. And that seems to be working, too. Nice. Next step is code, test, repeat.

[00:10:00]and just when I was ready to give up.

[00:10:08]Here's how it works. The onboard three-axis magnetic sensor measures the XY angle to each electromagnetic source.

[00:10:14]This lets you calculate the relative angle between them. And since we know where on the board the electromagnets are, this is almost enough to solve for position. The final constraint, I use the relative field strength between the two. This provides a relationship between those two sides of the triangle and fully defines the position. And unlike a GPS style approach, this solution actually gives an orientation, too. Yay. Now, what if I have three sources? Well, this lets me run this same calculation three times, once for each possible pair of electromagnets.

[00:10:41]But there's a complication with this whole strategy of electromagnetic pulsing, and that is timing. You see, each bot needs to know exactly when each electromagnet is going to be turned on and off. Cuz otherwise, it won't know which measurements correlate with which source. To solve this, my original idea was to broadcast a message over ESP now saying, "I'm going to do a sync." Then a few milliseconds later, I turn on all the electromagnets, and the pieces will then use their onboard sensor, see a spike in the signal, take a note of that time, and bring everybody into sync.

[00:11:09]Great. Well, great until clock drift becomes an issue. So, unfortunately, these microprocessors were not made in Switzerland, and that means that each one will tick slightly faster or slower.

[00:11:21]I'm talking hundreds of a percent. But this adds up surprisingly fast. And in fact, while testing this, I discovered that the drift between the server and this one specific bot was about 1 millisecond every 40 seconds. That equates to only 2 seconds per day. But that's actually a lot worse than I was anticipating. That means that my self-proclaimed genius magnetic pulse solution is not good enough.

[00:11:45]>> Wait, I need >> because at best that method could only capture sync within 1 millisecond. And that means I'm going to have to send sync pulses constantly. So I need tighter accuracy. A tighter sync accuracy means I need less dead time between turning on and off each of the electromagnets, which means that cycling through all of the magnets will take less time. So believe it or not, I'm just going to use straight ESP now messaging. Now, why didn't I do this in the first place? After all, I'm already sending that first message telling the bot to look for a sync. Why can't that just be the sync? Well, between task priority issues and free arts and variable jitter from the Wi-Fi radio, there's a random delay that gets added that can be up to 5 or 10 milliseconds.

[00:12:24]To make ESP now work on its own, I've got two tricks up my sleeve. First, I'm going to kind of do the same architecture of the sync. First, there'll be a message telling the bot to prepare for a sync. And the second will be the sync itself. That way, I can have the communications task hold priority, allowing it to receive incoming messages immediately. That solves the task priority issue. Now, for the Wi-Fi issues, rather than reinvent the wheel, I use some knowledge from the precision time protocol. Basically, the Wi-Fi radio and all this overhead is only ever going to add time. So, if I just spam this sync a ton of times and save the best time, it's going to minimize my error. And in practice, this actually worked so much better than I expected.

[00:13:08]At first, I was still seeing some outliers by up to 1 or 2 milliseconds.

[00:13:12]But after tweaking the burst settings, I was able to get the max sync error over hundreds, if not thousands of syncs to just 150 microsconds.

[00:13:22]So, now that the sync timing is fixed, let's see what the next problem's going to be.

[00:13:30]Wait, this isn't a problem. It's It's just working. Except for when it's moving.

[00:13:36]See, no position updates. Yeah, funny story. For some reason, I thought that all ESP32s were dual core. It turns out they are not. And the C3 I'm using is not. And the way I wrote the kinematics task, it basically just blocks everything while it's running. So, I do have an idea to fix this using RMT, which is meant for use with IR remotes and receivers, but I can repurpose it here to handle driving stepper motors rather than driving an IR LED. That's an optimization for next time, though. Now, as a little test of this full setup, I added some functionality to the GUI to command the bot to move between these three positions back and forth and back and forth. And just to prove that the positioning is working, watch what happens once I turn off the electromagnets.

[00:14:29]and turning them back on.

[00:14:33]And this also means that I can place the bot down just about anywhere and it's going to be able to navigate to the right spot.

[00:14:42]I am a little curious about power consumption.

[00:14:48]So, yeah, it it does consume a bit of power, but that's fine for now. With the onboard 170 mAh battery that I have, I should get at least an hour or two of runtime from each bot, which is good because charging them all is going to be a challenge.

[00:15:04]So, what's next? Well, I'm going to need to build up 33 more pieces, obviously.

[00:15:09]Make different toppers to differentiate the different types of pieces. Make the chest board. Make a ton more electromagnets. Design the main motherboard. Write a ton more code. And oh yeah, path planning. That's going to be fun. All the files and the code for this project are linked in the description below. Do you have an idea for an application of these swarm robots besides playing chess? Let me know. And now for one final question. What will come first? My next video or Levy becoming GM?

[00:15:37]See you next time.