CarlsenBot – Detailed Report (long post)

As of now, CarlsenBot v1 is completed. It just went through the final presentation with flying colors, I’m happy to report. This post will detail the project, my findings, possible future plans, etc…

Here is this post in video form:


title picture

It’s a gargantuan thing

CarlsenBot is my team’s final project for ECE4180 Embedded Systems at Georgia Tech.

CarlsenBot was built by me and my teammates: Anthony Trakowski, Daniel Paul Martin, and James Flohr. Since I had the idea for the project, I assumed the managerial role. CarlsenBot is a voice activated chess playing robot. It’s exactly what it sounds like: user (or users) can say the chess move they want to make, and the robot realizes them (the idea is to emulate “Wizard’s Chess“, from Harry Potter lore). For a sample, check out the video below:


diagramA highly simplified project flow diagram is above. **There is a slight typo: “mbed1” and “mbed2” should just be “mbed”. Mbed ( is the microcontroller platform we are using. It has a lot of support, and is the microcontroller used for the majority of this class.

The major components are: a speech processing unit for recognizing commands,  a game tracking unit that does everything related to the actual chess game, and a robot control unit, that controls all the hardware. These are discussed in detail next.

Voice Recognition

As mentioned above, the idea was to emulate Wizard’s Chess. Users would use the usual chess jargon, i.e. “Knight to e4”, to indicate a move. The problem would occur when that choice leads to an ambiguity, if say, two knights could both move to e4. Because of this, we indicate moves by indicating both a start AND destination square, e.g. “f3 to e4”. This would lead to yet another problem, where two letters could potentially sound the same, such as “b” and “d”, making speech recognition difficult. This was circumvented by using the Navy phonetic alphabet (‘a’ = “alpha”, ‘b’ = “bravo”, etc…). Future revisions may include work to make this sound more natural, and more alike to the standard chess move notation. For now, moves are recognized by saying a letter, number, letter, and number in succession, with the assumption the first number-letter pair are the source square, and the latter half the destination square. With the standards set, we set upon finding a suitable voice recognition platform. We ultimately found a hardware solution in EasyVR (below).easyvr

Microphone not shown

EasyVR can be programmed to recognize both trained and untrained words, though obviously to a limited capacity, but it should be enough for four users. Prior to usage, each user needs to have trained the first 8 phonetic alphabet letters. For reference, they are:









These reference columns on the chess board. EasyVR comes preprogrammed with SPEAKER INDEPENDENT recognition for the numbers 0-9. Only 1-8 is used for referencing chessboard rows.

**EasyVR is very sensitive to noise. It’s important that if the reader intends to replicate this project and continue using EasyVR, to be in a suitable (read: quiet) working environment.

Once all four parameters are recognized, it is passed serially to a desktop containing the next unit of our project…

Chess Game

A desktop nearby is running a chess engine called “chess-at-nite” (thanks to the creators). The engine does all the functions related to the game itself, such as keeping track of turns, detecting checks/mates, and most importantly, validating moves. We had to modify it to accept serial data coming from the mbed (well, James did). The serial data is just a four-character (letter-number-letter-number) string with the intended move.  If it is indeed valid, it gives the OK for the robot to make the necessary hardware movements. It does this by passing back the string to the mbed. If the move is not valid, the recognized parameters are nulled, and the current turn begins anew. Here’s an example of the program output:

terminal 4

(Little does it know I’m setting a trap for it…)

* Thanks to James and Tony for going above and beyond what I had in mind. It was my intention to write our own validation function. Moreover, I had only intended for this to be player vs. player, but this engine allows a player to play against a computer. It’s easily in my opinion the coolest part of this project: to play against a computer in a physical sense.

** The link above is the original, bare engine, and does not contain our modifications. Please email me, Ben Yeh at for our changes. I will also put it up on my github in due time.


Here is my contribution: Paul (Daniel) and I built this “robot”, having no prior mechanical engineering experience. Go us.

setup with axis marking

Look in the picture above for the standard axis orientations. For the sheer span, two motors are needed to realize movement in the x axis. Here are the motors and a close up picture of how they move:

motor x1 x2 side by side When the X motors turn, the gear translates the rotational movement into linear movement (the technical term for the setup is a pinion (the gear) and rack (toothed rails)). When they move, they carry the platform in between them along the x axis. Resting on the Y axis is a similar setup to the X axis, just in a smaller scale. Because of this, it only requires one motor.

2013-04-29 15.14.45

Here’s a closeup of the platform in between X motors, on which this travels:

y axis motor 2

Wire management leaves something to be desired

Lastly, sandwiched between the double rails is the section for the Z motor to rest on:

2013-04-29 15.11.25

In this picture, the double rails are the Y axis, and the motor on the left controls the z axis. Unlike the X and Y axis, which moves with respect to a fixed rack, the Z axis motor is fixed, and moves the arm up and down.

sensorThis picture deserves some explanation. Our rig uses simple DC motors from Vex to turn the gears. Vex also produces these encoders  as separate I2C devices that attach to the back of the motors. The encoders are quadrature encoders that will allow us to poll them to determine the current position. All motors are identical (with the exception of the Y axis motor, which is just slightly more powerful), so they can all be affixed with the same encoder. It was an oversight on my part to not buy enough. With more time, we would have waited until we bought another, but we received all the parts with about a week and half to finish the project. Instead, we opted for using a distance sensor, shown above. The distance sensor is fixed on the Z axis bracket, and senses the distance between it and this variable barrier:

z sensor with arrowMacGyver would be proud. (That’s Paul in the picture)

On the other end of the Z axis arm is the claw:

2013-04-29 15.12.31

We glued some foam pieces onto the end, so as to allow us to grab pieces more easily. The claw is controlled by a servo motor, with only two set positions in code: OPEN and CLOSE. When X, Y, and Z are done moving, the claw is then free to grip or release a piece.

As mentioned, the encoders on the motor is important, since it provides feedback. PID loops control all the motors (well, actually just PI in the case). I couldn’t quite tune it to get what I wanted to happen, so a fix is that the motors just get “close enough”, and then moves with the minimum speed to its destination. You may see this in some of the videos: the rig moves with variable speed towards its destination, stops, and crawls for some small amount. This has successfully fixed overshoots without too much delay.

When the current move is done, the engine updates the game, and CarlsenBot waits for the next move.

To get the mbed code, please follow this link and scroll to the bottom:

Hope you’ve enjoyed reading. Please email me at if you have any questions.

Here are some more videos: (This video shows what happens in a checkmate. It’s not as dramatic as I’d like it to be. If you pause at the end where show the terminal results, a line that says “…mate!” is printed at the top. (This was our first successful capture)

Future works:

  1. There’s no way to tell it to castle. Because of this, it’s not likely we can play a full game with the computer. This shouldn’t be hard though.
  2. It’s VERY loud, but that’s more than likely the mechanical design. There are grinding between metal parts.
  3. Once in a blue moon it will drop a piece. A better engineered claw should fix that.
  4. It’s slightly unstable, but again, that’s more on the mechanical side.
  5. Cleaner look
  6. As mentioned, try to implement the usual chess jargon

Thanks for reading. If you have questions, don’t hesitate to comment or send me an email at


CarlsenBot – fourth update

We have movement!

We finally got this moving towards the end of the day yesterday. It needs some fine-tuning, and integration with the other part of the project: the voice control, which my other teammates have been working on in parallel. Be looking for that in another post soon!

CarlsenBot – Third update

2013-04-25 21.19.04

Since last time, my rig got an upgrade in placement of the y-axis movement racks and z-axis movement racks. It looks pretty sweet, I know. It’s still got some ugly wires, but believe me, it was looking much worse earlier. May have to get some tubing for the remaining wires.


2013-04-25 21.19.18

Here’s the rig controller. 4 identical H-bridges control each of the motors. I will probably adjust it so all the wires stay flush against the breadboard.



2013-04-25 21.19.28

Lastly, here’s the Sparkfun claw affixed to the end of the z-axis. It is the only thing that’s not part of the system, as evident by its leads unconnected. I’m heading back to the lab to fix that as soon as I finish eating. You will also see in the back the distance sensor we plan to use to determine the height of the z-axis. You might wonder why don’t we just use the encoder? Because I had an oversight, and didn’t get enough encoder attachments for the motors.

A simple test revealed that everything moved without fail, which is a huge relief. It means that this rig is ready for a day of programming. Look out for the next update!

CarlsenBot – Second update

Since the last time, the rig’s got one new edition: racks to enable movement in one direction. It looks like this:

2013-04-19 15.02.45

And video of “movement”:

I should have known better than to film vertically… The program runs a simple movement command for a short time, at the end of which I reset the microcontroller and step back to get the shot. Let it be known I do terrible prototype wiring. It will no doubt be cleaned up as we progress.

That being said, it’s awesome to finally see movement, after having so many setbacks. There was going to be another problem though: the motor movements are tracked with an encoder on one of the motors, just one though, so it’s possible the other one will lag. That’s been fixed by changing the other motor to one with an encoder, so this picture actually isn’t the one that’s most recent.

I thought programming was going to be a huge headache. And it was/is. I don’t know a whole lot about controls, and until I know a little bit more, movement is going to be a little naive: move towards desired position at full speed, and ramp down speed as platform approaches.

Here was another thing that was testing me as I was programming. The vex motor encoder is an i2c device, and the mbed microcontroller only has two i2c sda/scl pair of output pins. We are using a minimum of at least 3 encoders, so at least two encoders will be put on the same bus. To distinguish between the encoders on the same bus, you have to change their address (I’ll assume you know the basics of i2c from here). According to the datasheet for the encoder, you can change the address by opening up communication with the default address of 0x60, then writing the value 0x40, which is the address of “change default address” register, followed up by a final write of the desired register address (which should be in the range of 0x20-0x5E). The mbed i2c library is a little strange, because these two should do the same thing…but they don’t:

char changeAddr = 0x4D; // change address register
char newAddr = 0x20; // new address
i2c.write(0x40, &changeAddr, 1); // tell encoder I want to change default address
i2c.write(newAddr); // write new address

// that didn't work, but this did:

char changeAddr[2] = {0x4D, 0x20}; // put values to write in an array
i2c.write(0x40, changeAddr, 2);

the mbed’s i2c API specifies two versions of the write method, write(addr, char*, int) where the first argument is the address of the device, the second is a pointer to the values being written (hence why in the first try, and the third is the number of bytes to write. The other write is just write(byte) which writes a single value on the line. I thought after sending the device the value 0x4D, it knows that I am sending a value of the new address I want. But that can’t be done in a separate write. The “write” method includes the start and stop commands, so that was probably why. That took me way too long to figure out. Not enough experience working with i2c I suppose.

The encoders are also a bit different from other i2c devices in that multiple devices on a bus are actually daisy chained together, as opposed to devices attaching themselves to the bus like the other devices I’ve worked with, and there is a register that tells each device in the chain whether to pass through the clock and data along. If it does not, it is called a terminator. This is set in a register. If you do in fact want an i2c bus, you must disable the terminator register, and the next device can be initialized just as in the above.

Hopefully this phase of the programming will be done soon, and what I learn can be applied to movements in the other axis.

CarlsenBot (working title) – first update

Some time ago I announced my final project for my Embedded Systems class: a voice activated chess-playing robot. Turns out another group did something similar a couple semesters ago, and they called it Kasparobot, clearly named after Gary Kasparov. It played with a chess engine by registering moves through OpenCV. Inspired by the name, I’ve christened our robot CarlsenBot, after Magnus Carlsen. I spent a few days looking at similar projects, namely this one: It’s very well documented, and the various pictures help immensely. I’m very glad I found this, as it will provide a most excellent skeleton for my own project. My team and I spent a few hours digging through the parts in the lab and rigging together this setup:

2013-04-12 14.39.04 2013-04-12 14.39.16 2013-04-12 14.39.29

Zoom in on the first picture. The green thing is a toothed rack, which turns rotary motion from a motor into linear motion with a gear that travels on the rack. We plan to place racks on the two arches to create movement along one axis, and create a movable platform positioned by motors and pinions, that will allow movement in the other two axis. You can see a claw that looks like it came from the same set we found these racks.

* To my annoyance the arches are slightly less than parallel, but I suppose if the racks are position parallel, it doesn’t really matter.

We will have to order a few new parts pronto, and assemble the platform I have in mind.

In parallel, we also have to get a program running to recognize dictated commands. For that, I think we might use this: We’ve also got another option in EasyVR, which is a voice recognition hardware module: It’s got an advantage of having a library already created by some other user on our microcontroller platform, but has the disadvantage of needing to be trained.

Hopefully a rough prototype can be completed this week, and finished next week, with plenty of time to debug before the demo.

New project – Voice controlled chess robot

For the final project in my embedded systems class, I’ve decided to build a voice controlled chess robot. I’ve got three other people working with me now so it should be manageable (or, it turns out to be a really easy project and we coast for the rest of the semester).

Just off the top of my head, here’s what we have to get done:

– find a voice recognition engine. For this we might use a EasyVR module, or Microsoft’s Speech SDK. I think EasyVR has to be trained, and I’d really like it to be independent of speaker, so that anybody can sit down and dictate.

– use the mbed to control motors that move a pick-and-place machine. Luckily mbed’s huge support will make this easy, hopefully. Encoder and motor libraries already exist, so I’ll be taking advantage of that.

– build the chassis for the pick-and-place machine.

Stay updated for progress during the next month!