Top Three Mistakes to Avoid When Building and Programming Robots

Having built a number of robots, both solo and as part of a team, I thought I’d share some observations of mistakes that slow down new roboticists or foils their projects altogether. Speaking of saving you a ton of time and frustration, I’d love to announce that my book, Practical Robotics in C++, is now available from Amazon, Barnes and Noble, and directly from the publisher BPB Publiications. (links at bottom of post).

In summary: Practical Robotics in C++ is the book that I wished was available before I spent years accumulating the included knowledge so I could build and program my own autonomous robots.

It even held the #1 New Release designation for a time! If you’re not in the U.S., you can likely find it just by searching for “Practical Robotics” in your country’s version of the Amazon site.

Practical Robotics in C++ teaches real robotics without the reader needing a university degree to follow the tutorials. Topics covered include:

  • Choosing and setting up a computer for robotics
  • Electronics for Robotics
  • Buying, building, and hacking robots
  • Motors: Different types, how to control them
  • Communications with sensors and other devices
  • Robot control theory and controller design
  • Mapping and Autonomous Path-Planning
  • Autonomous motion
  • Robot tracking and localization
  • Sensors for robotics
  • Computer Vision
  • Sensor Fusion
  • Final project: Build and program a complete autonomous robot!

Without further delay, let’s get back to why we came here. Right after I share this link to a little video trailer I put together:

Mistake #3: Building too Large a Robot

I get it – big bots are awesome. They allow for operations on rougher terrain, carrying a payload, and let’s not understate how cool they are. Unfortunately, these upsides comes at a price that I believe is too high for first-time roboticists. When you’re first learning the basics, don’t let the inconveniences that large robots bring impede the valuable time you should spend developing and testing. Let me explain –

Aside from costing far more in terms of money, large robots have special requirements that limit the amount of time you can spend developing them and I cannot understate this fact. Rain, snow, and sunset can all require you to pack up and call it a day when you could be comfortably working indoors on a smaller robot. Then there’s a little extra time manuevering it out of the basement or garage, and just the inconvenience of having to go outside to set it up can keep you from doing a quick test when you have an idea. Even now, I have a large robot to get ready for the 2021 Intelligent Ground Vehicle Challenge (IGVC), but it’s well below freezing outside so my time tweaking and testing it has been limited.

A smaller robot that can be kept on or next to your desk is handy far more often, and is much more likely to be safe for you to keep online all the time. Imagine the convenience of a robot you can remotely connect to a work on from another room or even across the country while on a work trip. This is one reason I love hacking certain robot vacuum models – they come with a dock so even from out of town recharging them is as easy as getting it close to the dock and telling it to go home. (We touch on hacking robot vacuums in chapter 3, by the way). Even when self-docking is not available, small robots can often come along on a trip with you and almost all of the programming is transferrable to developing a large robot later.

Mistake #2: Working on advanced things before perfecting the basic platform.

You have big plans for your robot and I might even admit that it’s nearly impossble to not try and map out how everything is going to work. That’s ok, but let me caution you that coding the obstacle avoidance or autonomous path-planning features at the same time as low-level features like basic drive functions is a recipe for endless frustration. Somehow, it’s a mistake that I see all the time.

Imagine writing code to drive forward, find and stay withing painted lanes, and avoid obstacles along the way. You finish your code, excitedly fire up the program, and the robot immediately leaves the course and hits a table or perhaps doesn’t move at all. Is the drive code bad or is there a bug in the lane-finding code? What if it’s niether and there is a hardware problem with the motor driver wiring or the obstacle sensor?

Each of these items is a non-trivial matter that should be developed and tested piece-by-piece, starting with the basic platform that you can reliably drive manually with the same commands the rest of the software will use to command it. I suggest you get the drive system perfect before you find yourself troubleshooting part of the system that isn’t even broken until you you “fix” it.

Mistake #1: Coding different systems together (AKA lack of encapsulation)

To some extent, this often ties into mistake #2, above, and is known as in the software development world as “lack of encapsulation.” What I’m talking about is the tendency for newcomers in robotics to underestimate how complex the code for a robot with any level of autonomy becomes. It usually start with the idea that the code is going to go something like “Go forward, if sensor detects obstalce: turn.” I was there once, myself.

If one hopes to accomplish anything more than a motorized trinket, it is essential to separate your code early. The program that finds obstalces or lanes shouldn’t even know that the program that drives the motors exists. The motor driving program shouldn’t know if there are obstacles or not – that is for the path planner. Each of these programs (any many more) should follow something called The Single Resposibility Principle ( and each do exactly one thing.

Tools such as Robot Operating System (ROS) help to facilitate this encapsulation, although new roboticists sometimes avoid it out of impatience. True, it takes a little extra time to learn to use these tools with your code, but the it’s is an investment with a significant payoff as soon as your machine evolves beyond the “motorized trinket” stage.


That’s three mistakes that I see new roboticists make all the time but I hope you will now avoid. Some of the alternatives you can likely handle on your own, and some might require a little development of yourself as a programmer. I hope you’re not discouraged and instead see that a little extra time now is going to make the overall process much more enjoyable and productive. There’s nothing trivial about autonomous robotics, and if you’re not sure where to go next stay tuned here and at my YouTube channel at Of course, I’d be honored if you’d pick up a copy of Practical Robotics in C++. You’ll find the solutions to the problems we discussed here and so much more all written for the everyday person – no university degree required to understand the lessons.


Barnes and Noble:

The Publisher, BPB Publications:

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s