CAMELOT: A Board Game playing 5-DOF Robotic Manipulator and A.I. Engine

Camelot is 5-DOF Robotic Manipulator that plays a board game themed after the sentient computer HAL from “2001: A Space Odyssey”

This project remains the cumilative work of two graduate level semester projects, completed two years apart while attending NYU Tandon School of Engineering.

Academic Description:

CS4613 – Artificial Intelligence (Spring 2015): The semester long project assignment consisted of writing an AI agent for implementation of an abreviated version of the board game of “Camelot” in the language of the students choice. All game code for this assignment was written entirely in python by the author, including game logic, the GUI interactive elements, and AI agent. While a GUI was required, it was not graded. For fun, the author themed the game after the malicious sentient computer “HAL” from the 1968 film “2001: A Space Odyssey.”

Submission guidelines included a research paper, all code and graphical elements, as well as a live demonstration of playing the game against the AI demonstrating the scope of it’s search functionality.

Artificial Intelligence elements include:
1. Search: Minimax using Alpha-Beta Pruning, Iterative Deepening, Local move ordering
2. Static Evaluation: Goal found, Piece Count, Closest Piece to Goal, Average Closeness

Video of AI and VREP simulation footage for Camelot by Eason Smith

EL5223 – Sensor Based Robotics (Spring 2017): The semester assignment was to apply lessons learned in class into a non-trivial robotics research project of the students choice using the VREP robotic simulation software environment and its associated APIs. With permission from the instructor, the original Artificial Intelligence class final project was used as a basis and a 5-DOF robotic ARM and 3D gameboard environment were created in a VREP scene. The original game code was updated to control the robotic manipulator. The manipulator can move 3D models of the pieces on a game board sitting on a tabletop in the VREP simulation environment. New features include robotic task and 3D way-point generation after a move has been decided. The arm will move pieces for both players.

Submission guidelines included a research paper, all code, vrep scene and graphical elements, as well as a live demonstration of the Robotic manipulator moving pieces and playing the game.

Video of AI and VREP simulation footage for Camelot by Eason Smith

How to play:
Gameplay is similar to checkers, but with the added element of the two respective center goal tiles added at the upper and lower ends of the board. Players alternate moving one piece per turn. Players may move any of their own pieces by one unit to a free square in any direction (“plain move”). They may also jump (“Cantor”) a friendly adjacent piece, moving to the free space on the friendly piece’s opposite side. A “capture” move is performed by jumping over an enemy piece that is adjacent to the players tile (similar to checkers), and removing the opposing piece from the board. The official rules were modified for this class to reduce the original search space and also to simplify it down into a viable semester-long project.

There are two ways to win.
1. Capture all of the other sides pieces by jumping over them.
2. Move one of your own pieces into the opposing sides goal while defending your own.

AUTHORS NOTE: This project and its elements are strictly not intended for redistribution of any kind, commercial or otherwise. This repo is maintained by the author for academic and reference purposes only.

Camelot game and VREP manipulator created and programmed by Eason Smith | All other works are copyright of their respective owners.

Other credits:
1. Camelot (board game) was created by Parker Brothers
2. 2001: A Space Odyssey novel by Arthur C Clark
3. The 1968 film of the same name is directed and produced by Stanley Kubrick
3. Game board and Game Piece graphical elements are from
4. Uses sound clips from: and


NYUSat is A 1U CubeSat developed as part of my senior design project at NYU Tandon School of Engineering. I designed and programmed both the payload hardware and the software for the real time embedded system which controls the Mission Science Payload on board the spacecraft.

Team Members:
Dymytro Moyseyev (BS E.E. | 2017) – Radio/Antenna modules
Danny Chiang (BS E.E. |  2017) – Power / Battery / Solar Array module
Matt Cocca (BS Comp.E. | 2017) – Mechanical Design / Radio / Antenna Release
Abhimanyu Ghosh (MS E.E. | 2017) – Primary On Board Computer
Eason Smith (BS E.E. & Comp.E. | 2017) – Mission Science Payload (Sensors / OBC)


NOTE: For the best overview of this project, I recommend downloading the PDF below, which details all of my work on the project’s hardware and software components (including electrical schematics):

NYU CubeSAT – Mission Science Payload – Final Report (PDF)

Basic Overview

My primary responsibility on NYUSat is the real time embedded development of the mission science payload modules. This includes programming the ARM Cortex M4 chip to collect scientific data from a variety of navigational and weather related sensors, and then relay that data over a CAN bus or other means to the main OBC for transmission with a ground station. This role involved both embedded hardware and software design. For hardware, I am responsible for electrical design and PCB’s for the OBC and payload modules, which happen to be located in the middle of the “stack” on the satellite. That also includes all scientific instruments on the satellite. On the Software side, I am responsible for chip configuration of the STM32F4 we are using as our Payload OBC, it’s real time thread and interrupt management which uses FreeRTOS (a real time operating system), as well as basic driver development and setup routines for the various sensors and communication methods required by the payload for the satellite to conduct it’s experiments.

Payload OBC: 
STM32F407VTG6 ARM Cortex-M4F microcontroller

Mission Science Payload:
LND712 Geiger Tube
SI7021 Humidty Sensor
BMP280 Pressure Sensor
Venus638FLPx GPS receiver
MPU9250 Gyroscope/Accelerometer/Magnetic Compass

Other IC’s used inside the payload modules:
SN65HVD232 CAN Tranciever
INA219 Current Sensor
TPS62162 Voltage Regulator
TPS22994 4-channel Load Switch


Payload Software on my Github:


NASA Lunar Mining Robot

The team cleans the robot before our first run in the Arena.

The team cleans the robot before our first run in the Arena.

In Fall of 2013-2014 school year, I took on the roles of Lead Project Manager and Captain for NYU’s Team Atlas. Team Atlas serves as a unique opportunity for both graduates and undergraduates of different engineering backgrounds to come together in a year long project to apply what they’ve learned in class in order to construct a large lunar robot. The robot must be able to mine and deposit regolith (a fine powdery soil commonly found on the moon) semi-autonomously and teams from all across the country travel to NASA Kennedy Space Center each year to compete in the competition. It’s a lot of fun and the competition is a blast.

Above: This is a brief “midnight indoor test” we did demonstrating general mobility and basic teleop of the robot.


Team Atlas From left to right: Eason Smith (me), Pawel Sawiki, Devon Simmons, Sam Huang, Nicholas Reid, Kevin Veersammy

Our robot was unique in that our final design was extremely light at ~26 kilograms and also was notable because our primary digging mechanism was through our wheels. We ensured a light final weight by using carbon fiber parts and emphasized risky but emerging new technologies like 3D printing while other teams did not. In fact, all of our wheels were entirely 3D printed by our uniquely gifted mechanical engineering team. Since a single wheel was bigger than the working space used by our 3D printer, the wheels were designed to be printed in 6 smaller pieces, then interlocked together like a puzzle in order to make one large wheel of the correct size. The wheels drive normally in one direction, and when driven in reverse will scoop up lunar soil which then slides through a hole in the tread through the inside of the wheel, and then out through a special slot near the axle down into a centralized collection bin.

From left to right: Sam and I adjusting the dual actuators. Kevin re-connecting the pulley motor, Devon adjusting the height of the pulley system.

From left to right: Sam and I adjusting the dual actuators. Kevin re-connecting the pulley motor, Devon adjusting the height of the pulley system.


My primary duty was to make sure the project remained on schedule and that things get built, however on a large scale year long multi-disciplinary project such as this, you find that you end up wearing as many hats as the team requires each day in the lab. As an electrical and computer engineering major, I made significant contributions to both the computer and electrical design of the robot. This included primary oversight of the electrical design on the robot, as well as spending quite a bit of time with our computer science team helping to implement an effective communications protocol and making sure the robot was safe and under control.


The Comm trailer was really cool. This is me pretending to control the robot while we wait for NASA to set up the arena before our run.


This is a screen capture showing our team getting the robot ready inside the mining pit arena. The local news station Fox 35 in Orlando covered the competition.


For computer hardware, we used an Arduino Mega as the primary robot CPU. The Arduino communicated via a special WiFi chip with a laptop running a custom LabVIEW virtual instrument panel located in a NASA hauler 50 feet away. We chose to use these programs based on ease of use and a large existing support base they already had on the internet. We operated the robot with a wired Xbox 360 controller which allowed us to both drive and control the Pully mechanism, as well as both actuators which controlled the lifting of the robot’s collection bucket.

This is the front of the control panel I designed in LabVIEW.

This is the front of the control panel I designed in LabVIEW.


We wrote Labview programs to give us live feedback on how far the actuators were extended, as well as power consumption and battery life indicators. Behind the scenes, the labview program was receiving and parsing messages from the robot, and packaging and sending out commands to be received. Everything was timed via a heartbeat system and watchdog timer, letting both the robot and the control panel know that communications had been lost if either party did not hear an acknowledgment after half a second or so. If the robot lost communication with the control panel, it would shut down it’s motors and enter a fail safe mode, attempting to reconnect with the LabVIEW host control panel. Likewise, the labview panel would attempt to reconnect with the robot automatically if the watchdog ever fired.

The watchdog timer subsection of our VI.

The watchdog timer subsection of our VI.

The auto-reconnect feature.

The auto-reconnect feature.

Each wheel had a current sensor allowing us to tell if a wheel was stalled or stuck in the sand. All of this data was captured in real time and saved in log files for later inspection.

Wheel Closeup

Each wheel was 3-D printed in 6 separate pieces, which fit together like a puzzle. Regolith would be collected from openings at the end of each fin, and the lunar soil would fall out through an opening near the adjacent fins axle.

A large portion of the robot was 3D printed, which was an early design choice based on our lack of access to a full machine shop (which was under construction). This saved us quite a bit of weight in the final design, but forced us to get creative when we wanted to build a larger structure (such as our wheels) using the limited printable space which the Makerbot could allow. To overcome this problem, we split the wheel design up into 6 smaller pieces, and designed them fit together like a puzzle. Because our robot used it’s wheels to dig while driving, you can imagine the complexity of this final cad design. I’m quite proud of the mechanical team for the work they put in on those wheels and what I felt was a great highlight on our robot and really innovative design choice. The rest of the robot used carbon fiber tubes held together with custom 3D printed locking corner pieces which also served to hide all of the electrical wiring from dust in the Arena.



NYU Robot Source Code | (Arduino)
by Nicholas Reid and Eason Smith



Command and Control VI | (LabVIEW)
by Eason Smith



NYU Lunabotics Website
NASA Robotic Mining Competition

Wireless NES Controller


This project is a modified wireless NES controller which is USB compatible with windows. It has the modern functionality of today’s controllers but the look and feel of the original classic.

Note: Even though this project has long been officially retired, I am still actively working to update this page and it’s documentation.  Please pardon the mess.

This project features work or was inspired by work from the following individuals:
Dean Cameron | LUFA USB Stack
Darran Hunt | Arduino Hacking Blog
Mark Feldman |
Ryan97128 | Nintendo Controller MP3, Version 2.0
Mike McCauley | Virtual Wire Library

Project Source Code
Link | (Github)

WIRELESS NES Controller Schematic

Problem Space
Nowadays, anyone can buy  a wireless or Bluetooth video game controller for their computer and play old school video games using an emulator. But I prefer the feel of the original NES controller when playing all those classic games because it helps bring back a sense of nostalgia each time I play. At the same time, I have grown accustomed to the wireless features of today’s controllers and find going back to having a ridiculous controller cable draped across the living room a hassle. From a historical perspective, there actually were a few wireless NES controllers that were mass produced during Nintendo’s heyday, but many if not all of those solutions were based on infrared transmission technology, and likewise suffered from the same line of sight and interference issues your television remote does. This issue made games nearly unplayable, and is the reason those controllers were never a big hit. This project is my attempt at to fix that problem from years ago by giving the original NES controller a modern wireless upgrade. Additionally, this project would become an important step in my journey toward understanding electricity and what programming was all about. Roughly a year later, I had a modified classic NES controller in my hands which is wireless, rechargeable and USB compatible. Completing this project is part of what inspired me to go back to school and become an engineer.

Basic Features:

  • The NES controller transmitter contains an atmel328p IC running the Arduino bootloader.
  • Light up “Nintendo” logo w/ custom wakeup, sleep, low battery, shutdown, and startup LED effects.
  • Internal 3.7V IPod Nano Lipo battery (boosted to 5V).
  • Sleep mode after inactivity (with LED warning pulse).
  • Wake from sleep on button press.
  • Transmitter can be easily modified to work with other controller protocols  (SNES, ATARI, etc.)
  • Physical On/Off switch
  • 2.5mm barrel jack for insertion of a polarized charging cable.
  • 4-wire JST connector for quick controller firmware updates.
  • Uses an RF Link 315Mhz receiver and transmitter pair running at 4800 baud.
  • The Base-Receiver is an Arduino Uno with the Atmel 8U2 flashed with custom firmware to appear as an HID joystick in windows.

Development Cycle

Background information
I was nearly an absolute beginner in both in electricity and in programming at the start of this project. Additionally, I had just finished building my first HTPC, which I put a bunch of old school emulators and games on that i wanted to play. At around this same time, I also become very curious about electricity. I saw a special on TV hosted by a yet-to-be-famous Bre Pettis (future co-founder of the popular 3-D printer company Makerbot). In that special, I saw Bre charge and power an odometer on his bike using magnets attached to his bike wheels. After seeing that, I walked into the local radio shack and bought a battery, wire, a switch and a light bulb and started doing my own experiments. I also heard about something called an Arduino, and took the “Intro to Arduino” workshop at NYCResistor, a makerspace close to my apartment. That 3-hour class taught me how to solder and put together a Freeduino (Arduino-clone) and program it. Up till this point, that was my only soldering experience. I also wrote my first piece of C code while I was there, blinking S.O.S. in a loop. I got a thrill from these experiences, and I saw this project as the perfect opportunity to continue having that thrill. I started discussing this wireless controller idea with friends and they were all very supportive, but I’m also sure they secretly thought I was over reaching. I can’t say I blame them. How many non-engineers do you know who just suddenly “want to make a wireless video game controller” out of the blue, and go off doing it? I didn’t know anyone either, quite frankly. Which also meant I’d have to figure much of it out on my own. I wouldn’t have someone I knew who I could go to when I had questions. But by the end of this project, I learned how to go out and get many of these answers for myself.

I started on this project by narrowing down the scope of the project to a few main goals and wrote down any questions I’d need to answer.

Major Design Goals
1) Read the buttons of an NES controller and store which are currently pressed and not pressed
2) Modify that controller to be battery powered and rechargeable
3) Make the controller transmit it’s current button states across a living room (in a reliable way)
4) Make the receiver unit pass these received button presses off to a windows PC
5) Make the computer read the received button presses as a USB joystick (preferable) or as USB keyboard presses.

Questions I had at the start of this project which needed to be answered to complete it:
Is the Arduino the right microcontroller for this project?
How do I read a button with an Arduino?
How does a video game controller work?
How do you read/make an electrical schematic?
How do I measure and test my circuit before I implement it?
How does a multi-meter work?
What are the different hardware and software methods used by video game consoles for reading and sending button presses?
What wireless communication technology should I use?
How does wireless communication usually work?
What commercial wireless transmitter units will work best with Arduino?
Will there be any noticeable “button press” latency in this system?
How should I best measure the latency in my system?
Will any component necessary for completion of this project be really expensive?
How do I safely use, monitor, and recharge a LiPo battery in a project?
How big of a battery do I need?
How is battery capacity measured? units?
Can I fit an Arduino, LiPo battery, wire and everything else inside the existing cramped space of a video game controller?
How can I make an Arduino send custom messages to my computer?
How can I make the computer think I have a USB joystick?
How can I update that “USB Joystick” with my button press data?
How does USB protocol work and how do USB joysticks typically collect and send data?
Is there anyone else out there who has done something like this before?
Where are some good places to find answers to some of these questions?

After compiling questions, I methodically pieced together a high-level development plan based on all of the above, in an order I thought made the most sense to me, and began to research, implement, and test each item as it was completed. The nice thing about my chosen development plan was that it was high level and flexible enough that I was free to modify and adjust to any new unknowns as they presented themselves in the development cycle. It also allowed me to fill-in any low-level objectives as development progressed.

Development Roadmap
1) Use an Arduino to read a single button on a breadboard. Test by printing the output to the screen.
2) Figure out how the Atari, NES, and Sega Master system controllers are electrically wired.
2) Start with the simplest controller (Atari), and read all of it’s buttons using an Arduino. Test by printing the output.
3) Find/connect a cheap wireless solution for the Arduino. Send a simple message wirelessly across the living room. Test by printing output on the receiver.
4) Combine the code from the Atari and the wireless solution. Test by making the atari light up LED’s from across the living room.
5) Replace the Atari controller in the system with an NES controller. Change the arduino code to read NES button presses instead.
6) Research LiPo battery characteristics. Find a small enough battery. Design/pick a LiPo recharge circuit. Test by charging a battery.
7) Create a “bare-bones” minimal Arduino circuit on a breadboard. Estimate if it’s small enough to fit inside a controller.
8) Figure out how to program a bare bones Arduino in on a breadboard without using a USB cable. Test it by uploading a blinky sketch.
9) Create a working electrical schematic of all of the pieces put together. Solve the circuit using ohms law. Check and re-check calculations.
10) Solder and connect the electrical modules together. Test continuity using a multi-meter.
11) Fit everything inside the NES controller. Test by making the NES controller wirelessly light LED’s across the living room on the receiver.
12) Figure out how to implement a USB joystick solution which can be recognized by my PC and how to best interface with it.
13) Connect the receiver Arduino to the USB solution, and tell the USB solution what buttons are being pressed to update the PC. Test by playing a game.

This is a video I made while testing the wireless transmitter/receiver using an Atari controller. You can see that it blinks LED’s controlled by a receiver Arduino set up across the living room.

Hardware Breakdown and Modifications
The controller’s main IC is a bare-bones Atmel 328p running the Arduino bootloader, which reads and controls the NES pad’s shift-register in order to read all of the button states. The transmitter code was written in Arduino’s variant of C. The receiver unit is an Arduino UNO, which has it’s internal 8U2 IC’s firmware flashed to present itself as a video game controller to the host PC. The Arduino UNO base unit, plugged into my HTPC, receives button state messages from a 315MHz RF Link transmitter over the air and then passes along that information via standard UART to the 8U2 chip. The 8U2 chip organizes the button presses into a special USB HID report packet and sends that message off to the host PC continuously.

Controller Case Modifications
I cut out a lot of unnecessary plastic support pieces inside the controller with my Dremel, in which I followed pretty closely to Mark Feldman’s modifications. (see: Front Plate Preperation section of his site). This allowed me to fit all of the extra electronic componants, including the battery, inside the cramped space of the controller. Additionally, small square incisions were cut into the the top of the controller to fit the programmer connector and a small on/off switch. Lastly, the entire label on the front of the controller was carefully peeled off/removed and a long trench of rectangular plastic was cut out from just underneath where the Nintendo logo is placed. I glued a diffused piece of clear plastic (for the LED’s to shine through) in that channel. Details on how to do that can be found in steps 6 and 7 of Ryan97128’s Instructables tutorial.

Controller Power and Battery
Power was supplied by a thin 400mah 3.7V Ipod mini battery I bought off EBay, inspired by it’s selection in Mark’s project. At the time, (2009-ish) small thin lipo batteries were not as plentiful, nor as cheap as they are now. I believe in todays market you should be able to find an even thinner/smaller lipo battery for about the same mah rating for much cheaper. Voltage from the battery was then boosted to 5V using a pololu boost regulator which went on to power both the 328p and the HopeRF transmitter. A 2.5mm barrel jack socket sits in the original opening for the controller cable and acts as a proprietary power plug connector for an external charger. A tiny on/off switch sits near the right index finger to shut off all power from the battery to the controller. When i wasn’t using the controller, I plugged in a 2.5mm male audio jack at the end of a wire connected to a sparkfun lipo charger (based on the max1555) to recharge the controller. Because LiPo’s are sensitive to over-voltage and under-voltage charging and usage conditions, the atmega328p actively monitors the battery voltage and powers down the controller when the battery level dips below ~3.3V. To conserve battery life, the controller puts itself into a low power sleep state when inactive for 7 minutes (ie. no buttons pressed). The controller can be woken up by holding down the select button (or another button if wired appropriately). The LEDs within the Nintendo logo flash to indicate the transition between different powered states. (startup, sleep, low battery, shutdown etc.)

LED logo FX

The logo is lit by 2 (red) LED’s from inside the controller through a diffused piece of clear plastic placed directly underneath the logo.

Behind the LEDs, I put black electrical tape to help keep the light from escaping and shining out of other areas of the controller. The original black lettering on the Nintendo Logo painted on the front sticker itself was actually carefully and painstakingly chipped away by hand with a toothpick and nail polish remover in order to allow the diffused LED light to shine through the lettering. The necessary details for this portion of the project can be seen in Instructable’s user Ryan97128’s Nintendo Controller MP3, Version 2.0  project blog (specifically steps 5 through 8).  Once the modification was done, the sticker was put back on the front of the controller. PWM is used in software to create the custom logo effects for wakeup, sleep, low battery, shutdown, and startup events.

There is actually a lot of wire routed in this project, because it is not implemented with a custom PCB. To help fit all of the wires inside the actual controller, I used really thin wire wrap wire (24 AWG or more), which was the thinnest kind of wire I could find. It is very brittle however, and it can potentially break very easily by tugging on it too hard when opening up the case so I had to always be very careful when taking the controller apart to test it. 

RF Communication
I used a cheap 434Mhz RF Link pair ( transmitter | receiver )  that I bought from Sparkfun to send payloads one way from the controller to the base unit at 4800bps. I cut ~6 inches of wire for the antennas, and wrapped the transmitter antenna around the perimeter inside the NES controller. This transmission pair is nice in that it forwards standard UART serial data at 4800 baud over the air without much modification, but I found that data reception success rate was very sporadic with attached antennas. But when researching the issue I stumbled across the VirtualWire library by Mike McCauley, and once I integrated that library I had no more communication issues at all and everything transmitted perfectly.

For this project I used a Arduino Uno rev2 which includes a removable atmega 328p IC. I programmed the onboard 328p chip with the transmitter code first, then physically removed the IC from the UNO and replaced it with a brand new 328p chip that included the arduino bootloader. I then I uploaded the reciever code onto the new 328p chip using the Arduino IDE.  Next I installed Atmel Flip to burn firmware to the 8U2. Note that once you burn the custom hex file to the 8U2, the UNO’s neighboring 328p IC can no longer be programmed using a USB cable. Note: In order to reprogram the UNO’s main IC after this point, you must re-burn the ORIGINAL 8U2 arduino firmware back onto the chip to restore its USB serial functionality.  You may wish to try using the 6-pin ICSP header for programming the UNO’s main chip, since I believe that method should still work even with a reprogrammed 8U2.

Once the base unit code was uploaded, I put the arduino’s onboard 8U2 IC into DFU mode using these instructions for the UNO rev2, and uploaded the new hex file via Atmel’s FLIP software. Atmel Flip can be downloaded here and Instructions on how to change to 8U2 firmware on the arduino using Atmel flip are listed here. The hex file is a compiled binary of the Lufa Library (ver. 100807) with a custom USB HID descriptor which describes a large single player joystick with 32 buttons. Much of the code compiled into that hex file was adapted from code written by Darren Hunt And Dean Camera, so please visit their sites and support all of their projects. Darran’s original 8U2 source files can be found here and the Lufa Library (Version 100807) can be found here.

Updates that are coming soon: 8U2 Hex File, BOM, Base Station Schematic



RF Stick


Current state of the RF Stick. (4 Layer PCB)


RF Stick (work in progress)


The ‘RF Stick’ ,  is a project I am currently working on which is an AVR/arduino based wireless IoT platform. A side-goal of the project is to allow the pcb to be easily implemented into the innards of old school video game controllers which I am adapting into wireless versions for my HTPC. The stick is being developed to be modified for a number of other uses, especially concerning wireless IoT devices which may require a more accurate and robust battery monitor.

The main features of this PCB include:

  • 2.4Ghz RF transceiver
  • on board Power Monitoring/LiPo Battery Gas Gauge IC
  • on board Lipo Charger IC
  • Based off of an Atmega 328p chip
  • I2C/SPI ready
  • on board USB and Lipo Battery connectors
  • 3.3V regulated input/output

Status:Board needs cleaning up and so do the schematic files. The schematic needs to be framed and sectioned and the load sharing transistor still needs to be chosen along with a few other small electrical details. The PCB traces and parts need to be labeled and then it’s off to the PCB fab house.




Lipo+ is a battery charger PCB which is perfect for small projects. It has a small form factor and will charge any single cell LiPo you throw at it. I designed this PCB as a test PCB (of sorts) for it’s overall inclusion into a larger electronics project I am working on because I generally find that breaking down a large project first into smaller pieces and then testing those pieces alone leads to a quicker design flow than the alternative. You can use the smaller PCB’s to test the larger one before throwing everything together in a single design file, saving lots of headaches.

Included in the design are breakouts for the load, battery connector, and has a mini-usb connector as a charging source.

Microchip MCP73831 Lipo Charger IC  | (PDF)

Eagle files | (GitHub)



LipoCC is a Coulomb Counter / Battery Gas Gauge PCB for use in single cell LiPo batteries which I designed based around the LTC4150 IC. The overall schematic and board implementation is fairly straight forward in terms of design and further details can be found within the Linear Technologies datasheet below. I developed this project as a launching point for including 4150 as part of a much larger future project and I wanted a chance to test the circuit design as a standalone design first.

LTC4150 Coulomb Counter/Battery Gas Gauge  | (PDF)

Eagle files | (GitHub)

Line Follower Robot


From August 2011 to May 2012, I had the privilege of leading a student design team in building a line follower robot for the 2012 SUNY TYESA Student Design Competition.

BMCC Robotics | Team “Shika-Bob”
Members: Eason Smith, Mohammad Christi, Adel Njeim, Mario Feliz
Team Advisor: Simon Kravtsov (Teaching Assistant)
Team Sponsor: Prof. Mahmoud Ardebili

(Note: much of this page is still currently under development)

This project was the second major electronics design project I took on after completing my wireless NES controller during the previous year. I had started this project with maybe a year of c++ programming experience under my belt and I had just begun to push my circuit theory knowledge beyond just “the basics” of ohms law. So for me, this project is a great time capsule to the time when I was just starting out. This project also taught me several skills that would later help me on NYU’s robotic competition team.  It was my first time managing a student level multidisciplinary engineering team, which I found to be an enjoyable and rewarding experience that was also much harder than it appeared.

In general, I try to co-purpose my electronics projects with a few educational side-goals in order to get the most out of them. My side objectives for this particular project were:

  1. Learn how to implement PID in software for fast and smooth line following.
  2. Read the line as frequently as possible with the highest resolution possible.
  3. Learn how to design schematics and PCB’s using Cadsoft Eagle.
  4. Etch my own custom circuit boards and try to find an edge on commercially available sensor bar PCB’s my competitors might use.
  5. Write my own software interfaces for the sensors and actuators in orderto learn how they work at a low level.

Above all, my main goal was to win. Sadly, even after a years worth of drawing schematics, soldering, writing code, looking over datasheets, cutting, etching, drilling, and testing PCB’s, the final outcome was not what we aimed for. Three weeks before the competition began, we experienced a full RUD while testing the motors with a pair of new motor drivers, causing a massive failure in our MCU’s. I have since learned that this was due to an inherent design flaw in the robot’s main chassis circuit (the motor and MCU loads were not isolated/buffered from each other on the power rail). While this flaw and several others are obvious to me now, I was not yet experienced enough to recognize it at that time.

Regardless, we were able to resurrect our original prototype and brought home a 2nd place finish for our robot. In addition, over the course of that year I accomplished many of the side goals I had set for myself, and I learned a lot of things about managing large scale electronics projects. Most importantly, I got to experience how a product design process evolves from start to finish. Yet, even with a big setback, we kept our chins up and stuck together and pulled through to make a solid finish. In the end it was the teams unity, the depth of our robot’s research, and also the quality of our final presentation to the judges which helped us lock in a 2nd place finish.

Design Evolution

The robot consisted of 2 major design iterations.

Design 1: The Prototype (9/29/11 – 4/6/12)
The prototype was an Arduino-based design, and in the beginning, centered around mostly commercially available components and sensors. Following the design goals I had set for myself, I quickly learned enough about Eagle and DIY PCB etching to make a single thru-hole version of the robot PCB’s  by the end of that year, replacing the existing heavy chassis, breadboard, wires, and a popular Sparkfun contrast sensor bar we were using for development up to that point. This significantly made the robot much lighter and faster. On top of this design was a ball passing mechanism I made using wood craft sticks and hot glue and attached a servo to it for operation. This design is what I ultimately competed with once I lost Bob and Shishka.
Design 2: The Twins: “Shishka” and “Bob” (3/24/12 – 4/19 / 12)
Shishka and Bob were built around a 32bit 3.3V ARM Cortex-m3 Leaflabs Maple Board, which i then ported our Arduino software into. The motors were high RPM, low torque motors we ordered from Pololu and were supplied them with  a regulated 8V from a 11.1V battery. Regulating the motor supply is often not as necessary on small robots. But because we implemented PID, regulating the motor supply was quite necessary to maintain consistent response from the robot for a given set of PID constants.

We tuned PID while the prototype robot was running live on the test track using wireless 2.4ghz XBEE RF modules. The robot would send serial data to my laptop of it’s current set PID values and it’s track lap times, and I would send it back characters which would increment and decrement kp,ki, and kd values by preset factors in Terraterm. We increased Kp first until the robot oscillated about the line but was still recoverable, and then we increased Kd to get the oscillations to stop, with a slight increase in ki to round out the procedure and logged the resulting track times and values.

Misc. Early Design files

The Contrast Sensor Bar

Version | Pics| Date | Notes
V1  | sch,  brd | 10/12/2011 | Initial schematic and a clumsy PCB design.
V2  | sch , brd | 10/31/2011  | Changed out the rainbow connector. Much improved single sided PCB design. I learned quick.
V3  | sch , brd | 12/16/2011  | Added a small power rail capacitor to both files
V4  | sch , brd | 12/26/2011  | moved traces to bottom PCB layer, but smt on top and no vias? This is a non-functional pcb.
V5  | sch , brd | 01/02/2012  | finally made a GND plane on bottom layer. Still haven’t realized I need to flip the sensors or add some vias…
V6  | sch , brd | 03/22/2012  |  converted to all SMT components. Moved everything back to the top layer. Added a 3-pin pwr header.
V7  | sch , brd | 04/01/2012 | design used for etching. Lots of changes. Also cleared out a square for cutting the roller-wheel in the middle.


A small collection photos I still have from the original project.

Clockwise from top right: Contrast Sensor Bar PCB, The Chassis PCB, Second Place finish, The Prototype Robot

Prototype Chasis PCB

Prototype Chasis PCB

Contrast Sensor Bar

Contrast Sensor Bar












Lessons Learned:

Etching is a messy
While it is very nice to be able to just make a PCB whenever i feel like it from the comfort of my own home, I learned that it is often much easier and nicer to custom order my PCB’s from a fab house (I now use OSHpark for all my PCBs) The end product looks more professional, and it avoids hazardous chemicals in the house.

Don’t integrate a switching power regulator if you don’t have to
At this point in my electronics knowledge, I was still largely self-taught and hadn’t fully gained the understanding behind some of the more complex elements used in the circuit, such as the switching regulators. Given these factors, I believe I should have chosen an off-the-shelf switching regulator, and designed the peripherals around an lm7805/3 instead of taking this on myself.  Regardless, we took an unnecessary design risk in designing (two!) complex switching regulators into the chassis PCB just to save a tiny bit of battery. As a beginner, that’s a tall order and I should have just kept it simple with the voltage regulation and power supply. Even using separate batteries would have been a better choice here, given my inexperience.

Isolate your sub circuits
As was mentioned earlier, my circuit had several different voltage rails running in parallel, all with extremely different voltage and current requirements. The motors being the biggest factor in affecting the circuit when they were under load. When the motors draw a lot of current, all of the node voltages and currents in the whole circuit will change, especially if they aren’t isolated properly. This can cause it to do strange things like shut down suddenly or even much worse. If I could do it over again, I would isolate the power rails from each other using opamp buffers and add an appropriate value fuse and  some power blocking diodes to the 3.3V and 5V rails.

Don’t pre-optimize the robot
In the early build phase of our robot, I felt design-wise that we focused on making it “light and fast right away” instead of “consistent modular upgrades, integrated with each other over time”. I now have grown to appreciate modularity in design development, and the “rapid prototype and test” approach that allows a team to quickly get an idea up and running, optimizing the different areas of a design as the development cycle continues on. The key design takeaway for me was: “build a model, test, integrate, optimize”

#include libraries
I was still a beginner and had only been coding for about a year when I designed the largely arduino-based software for our robot. Looking back, the code is largely procedural, not broken into small functions, and is much too large for a single sketch/file. Debugging using print statements (which at the time was the only way I knew how to debug) became an awful tool and didn’t scale very well as the robot’s code base grew. I wanted to avoid abstract design elements which i couldn’t speak for in my code (a black box for software), but this cost me in code quality since the important stuff that “must be right” was now largely written by a novice/beginner (me.)  Eventually, I came to understand why external libraries would have been well suited for a project like this . They bring reliability, they’re usually well tested, they’re portable, they’re widely supported, and are usually more efficient pieces of code than what a beginning programmer can write on their own. All of that just accumulates into speedup of software development and often more efficient code. If i could rewrite the code today, I probably would use object oriented design principles or a C library structure for separating functionality which is more common to embedded systems. I discovered not being able to recognize your own code style from 5 years ago is also a great chuckle when that happens. Still learning.

TYESA Competion Website: (seems to be down at the moment?)
Project Github: coming soon


L298 Breakout Board

L298thumb_i  L298_Schemthumb_i

This is a simple breakout board I designed for the L298N motor driver. I have used this motor driver on a few projects in the past, and having a breakout board for it makes prototyping much easier. Note that this design does not include flyback diodes, but they are strongly recommended. See the datasheet for details.

L298 Breakout Board

L298 Motor Driver | (PDF)

Eagle files | (GitHub)