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.

 

 

 

 

 

 

 

 

 

 

 

 

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.

Links
TYESA Competion Website: http://escorgie0.tripod.com/ (seems to be down at the moment?)
Project Github: coming soon