How to Make an Object Detection Robot | Arduino

In this post, I’ll show you how to make an object detection robot using Arduino. This robot will move around a room and when it bumps into an object, it will turn around and go in another direction. Reminds me of the iRobot vacuum cleaner!



Here are the requirements:

  • Make a robot that can turn around and go in a different direction after bumping into an object.

You Will Need

The following components are used in this project. You will need:


First, I position the snap action switches so that the corners are aligned with the side and front of the lower base of the robot. I will make a mark with a pencil to indicate where I should glue (we’ll glue them down later).


Grab three pieces of 6-inch male-to-female jumper wire.


Cut off the female end of the jumper wire.


Remove 0.25 inches of insulation from the end of the wire that you just cut.

Twist the loose ends of each wire.


Before you solder, it is helpful to first stick the wire strands through the pinhole of the terminal.


Solder one wire to the NO metal terminal of a switch (black wire).

Solder one wire to the NO metal terminal of the other switch (brown wire).

Solder one wire to the COM terminal of the switch that will go on the right side of the robot (white wire).

Get 3 inches of solder wire and connect the COM terminals of both switches (yellow wire).


If you don’t know how to solder, check out this video (skip to the soldering part):

Now we need to test the switches.

Plug the jumper connected to the Right switch COM into Digital Pin 4 on the Arduino.

Plug the jumper connected to the Right switch NO into Digital Pin 2 on the Arduino.

Plug the jumper connected to the Left switch NO into Digital Pin 3 on the Arduino.


Now, upload the following code to the Arduino. When you press down one of the switches, the built-in LED on the Arduino should light up.

 * This program is to test the snap action switches
 * @author Addison Sears-Collins
 * @version 1.0 2019-05-12

 *  This setup code is run only once, when Arudino is 
 *  supplied with power.
void setup() {

  // Pin 13 is LED output
  pinMode(2, INPUT);  // Right Switch
  pinMode(3, INPUT);  // Left Switch
  pinMode(4, OUTPUT); // Ground for Switches
  digitalWrite(2, HIGH); // Enable pullup resistors
  digitalWrite(3, HIGH); // Enable pullup resistors
  digitalWrite(4, LOW);  // Set ground to 0 volts

 * Light LED pin13 if pin 2 or 3 goes LOW (i.e. pressed)
void loop() {
  if ((digitalRead(2) == LOW) || (digitalRead(3) == LOW))
    digitalWrite(LED_BUILTIN, HIGH);
    digitalWrite(LED_BUILTIN, LOW);
  delay (100); 

If everything is working OK, go ahead and glue the switches to the lower base of the board.


Now, upload the following sketch to the Arduino, and then place the Arduino on the floor.

#include <Servo.h> 

 *  This robot will move around a room and when it 
 *  bumps into an object, it will turn around and 
 *  go in another direction.
 * @author Addison Sears-Collins
 * @version 1.0 2019-05-12

// Create two servo objects, one for each wheel
Servo right_servo;
Servo left_servo;

// Volatile keyword is used because these variables
// can change at any time without any action having been
// taken by the compiled code. 

volatile int left_switch = LOW;   // Left switch flag
volatile int right_switch = LOW;  // Right switch flag
boolean already_started = false;  

 *  This setup code is run only once, when Arudino is 
 *  supplied with power.
void setup() {
  // Set the pin modes for the switches
  pinMode(2, INPUT); // Right switch is input
  pinMode(3, INPUT); // Left switch is input
  pinMode(4, OUTPUT); // Pin 4 is ground
  // Turn on the internal pull up resistors for the switches
  // Keeps input from floating when the switches are not
  // pressed
  digitalWrite(2, HIGH);   // Right switch default to high
  digitalWrite(3, HIGH);   // Left switch default to high
  digitalWrite(4, LOW);    // Pin 4 default is ground

  right_servo.attach(9);    // Right servo is pin 9
  left_servo.attach(10);    // Left servo is pin 10
  // Declare the interrupts
  // attachInterrupt(digitalPinToInterrupt(pin), ISR, mode)
  // Interrupt when go from high to low
attachInterrupt(digitalPinToInterrupt(2), hit_right, FALLING); 
attachInterrupt(digitalPinToInterrupt(3), hit_left, FALLING);  
  already_started = true;  // Bot can now move

void loop() {
  if (left_switch == HIGH) {   // If the left switch is hit
    go_backwards();            // Go backwards for 1 sec
    go_right();             // Turn to the right for 1 sec
    go_forward();              // Move forward
    left_switch = LOW;         // Reset the flag
  if (right_switch == HIGH) {  // If the right switch is hit
    go_backwards();           // Go backwards for one second
    go_left();                // Turn left for one second
    go_forward();             // Move forward
    right_switch = LOW;       // Reset the flag
// Interrupt routine for left switch bumping into an object
void hit_left() {
  if (already_started)     // Valid if the program has begun
    left_switch = HIGH;    // Set flag high to get serviced

// Interrupt routine for right switch bumping into an object
void hit_right() {
  if (already_started)    // Valid if the program has begun
    right_switch = HIGH;  // Set flag high to get serviced

 *  Forwards, backwards, right, left, stop.
void go_forward() {
void go_backwards() {
void go_right() {
void go_left() {
void stop_all() {
  right_servo.write(90); // Tweak the 90
  left_servo.write(90);  // Tweak the 90

Power it up by turning on the servos:

  • a13 to e3 = left servo ON
  • e13 to e28 = right servo ON

Then plug in the Arduino’s power.

In order to actually start the program, you need to depress one of the switches. Make sure the Arduino is on the floor before you start the program.

Watch the Object Detection Robot move!


Round-Robin vs Function-Queue-Scheduling | Embedded Software Architecture

Table of Contents

In this post, I will discuss the tradeoffs of using the Round Robin, Round Robin with Interrupts, and Function Queue Scheduling approaches when building an embedded system. Let’s consider that we will use an Arduino to perform tasks such as capturing sensor data and downloading to a host machine (e.g. your personal laptop computer).

Round Robin



The Round Robin architecture is the easiest architecture for embedded systems. The main method consists of a loop that runs again and again, checking each of the I/O devices at each turn in order to see if they need service. No fancy interrupts, no fear of shared data…just a plain single execution thread that gets executed again and again.


  • Simplest of all the architectures
  • No interrupts
  • No shared data
  • No latency concerns
  • No tight response requirements


  • A sensor connected to the Arduino that urgently needs service must wait its turn.
  • Fragile. Only as strong as the weakest link. If a sensor breaks or something else breaks, everything breaks.
  • Response time has low stability in the event of changes to the code

Return to Table of Contents

Round Robin with Interrupts


This Round Robin with Interrupts architecture is similar to the Round Robin architecture, except it has interrupts. When an interrupt is triggered, the main program is put on hold and control shifts to the interrupt service routine. Code that is inside the interrupt service routines has a higher priority than the task code.


  • Greater control over the priority levels
  • Flexible
  • Fast response time to I/O signals
  • Great for managing sensors that need to be read at prespecified time intervals


  • Shared data
  • All interrupts could fire off concurrently

Return to Table of Contents

Function Queue Scheduling


In the Function Queue Scheduling architecture, interrupt routines add function pointers to a queue of function pointers. The main program calls the function pointers one at a time based on their priority in the queue.


  • Great control over priority
  • Reduces the worst-case response for the high-priority task code
  • Response time has good stability in the event of changes to the code


  • Shared data
  • Low priority tasks might never execute (a.k.a. starving)

Return to Table of Contents

What is the Shared Data Problem?

Table of Contents

Before we discuss the shared data problem when building embedded systems, it is important to understand what interrupts are.

What are Interrupts?

The most basic embedded software has a main program that runs uninterrupted…that is, it runs until either it stops on its own or something else causes it to stop.

For example, if you unplug your refrigerator, all programs that were running will immediately stop, and the refrigerator will shutdown. Otherwise, while the refrigerator is plugged in, programs will continue to run uninterrupted. This is called embedded software without interrupts.

You also have software where the main program executes normally but stops either periodically or due to some code (that is not part of the main method) that must get executed immediately. The main program stops, some other code is executed…(i.e. code that is not part of the main program). We call this an interrupt service routine. When this interrupt service routine is finished, control is shifted back to the main program, and the main program gets back to doing what is was doing prior to being interrupted.

Here is an image that shows what I just explained:


You likely trigger interrupt service routines all of the time without even knowing. For example, normally your desktop computer runs various background programs when you are not on your computer. Let’s call this the main() program. As soon as you click your mouse or type on your keyboard, you trigger an interrupt service routine. The computer handles this interrupt service routine by exiting the main() program temporarily, reading what you just did and doing what you commanded it to do (i.e. servicing the interrupt).

After that, the computer exits the interrupt service routine, goes back to doing what it was doing before you interrupted it (i.e. control shifts back to the main() program). That is a lot like how interrupts work in embedded systems, and you will find them in many if not most embedded programs in some form or fashion.

Return to Table of Contents

The Shared Data Problem

A big problem in embedded systems occurs in embedded software when an interrupt service routine and the main program share the same data. What happens if the main program is in the middle of doing some important calculations using some piece of data…an interrupt occurs that alters that piece of data…and then the main program finishes its calculation? Oops! The calculation performed by the main program might be corrupted because it is based off the wrong/different data value. This is known as the shared data problem.

Real-World Analogy: Running a Bakery

Imagine you own a bakery. You are trying to calculate how much money you made in 2018. You have just entered the revenue for each month listed in a Google spreadsheet. It looks like this:

Addison’s Bakery 2018 Revenue By Month

  • January: $10,000
  • February: $10,000
  • March: $10,000
  • April: $10,000
  • May: $10,000
  • June: $10,000
  • July: $10,000
  • August: $10,000
  • September: $10,000
  • October: $10,000
  • November: $10,000
  • December: $10,000

You get out your handy calculator.

“calculator” by stockcatalog is licensed under CC BY 2.0 

Starting with January through March, you add the first three months of revenue into your calculator “10000 + 10000 + 10000 +” and then all of a sudden, your assistant (whose job it is to keep revenue updated periodically), interrupts you and asks if he can update something in the spreadsheet. You say, “Sure.”

You get up from your chair and go to the break room.

In the meantime, your assistant (i.e. the “interrupt service routine”) then gets on your computer.

While you are in the break room, your assistant changes the revenue on your spreadsheet in January 2018, increasing it from $10,000 to $15,000. He then leaves the room.

You then return from the break room. You get back in your chair and continue entering in the numbers in your calculator for the other nine months, for April through December. You conclude that the revenue for 2018 was $10000 per month for 12 months (i.e. $120,000). You record that number so that you can use it for your tax filings. Oops! See the mistake?

The main program (i.e. you) was unaware that the interrupt service routine (i.e. your assistant) made a change to the January 2018 revenue data, so the value of $120,000 is not consistent with the updated data. It should be $125,000 not $120,000.

This in a nutshell is the shared data problem. We need to make sure that you, the main() program, are NEVER interrupted while you are in the middle of making important calculations on your calculator. You and your assistant both share responsibility for making sure revenue is accurate, but we need to make sure you both aren’t working on the revenue at the same time.

In the real world, this would take the form of you posting a “DO NOT DISTURB” sign on your door to keep your assistant out when you are making critical calculations. In software engineering, we call this “disabling interrupts.” While interrupts are disabled, nothing can interrupt the main program.

Disabling interrupts is like the main program putting up a big DO NOT DISTURB sign. Source: Wikimedia Commons

Real-World Example: Designing an Automatic Doggy Door


Let’s look at a real-world example to further show you the shared data problem.


Imagine you are a software engineer working at a company. Your team is responsible for designing an automatic dog entry door. This embedded device can be wirelessly updated with RFID tags for dogs or other pets to be allowed entry.

The door needs to automatically unlock for dogs that are in the vicinity of the door. A pet must be allowed to enter even when the table of RFID tags is being updated. The RFID tag IDs are shared data since the interrupt service routine that must update the tag IDs and the main() program that is responsible for automatically unlocking the door when dogs are in the vicinity both share and use this data. A problem will occur when the doggy door is in the middle of an RFID tag ID update when a dog needs to get through the door. We wouldn’t want to let the poor dog wait outside in the freezing cold while the device is in the middle of an RFID tag update!

How do we create a solution that solves the shared data problem? The RFID tags need to be updated regularly but that same data is needed regularly by the main() program to let dogs enter when they need to. Let’s solve this now.

System Requirements

Dogs wearing RFID tags/cards need to be able to enter the door (i.e. gate) when they get close to the doggy door.
  • This embedded device can be wirelessly updated with RFID tags.
  • Dogs or other pets must be allowed entry when they are in the vicinity of the door.
  • Dog must be allowed to enter even when the table of RFID tags is being updated.
  • RFID tag IDs are shared data which must be managed.

In the shared data problem for the doggy door controller, we need to make sure the dog can enter at all times while the RFID tags are being updated. Because this is a dog, it is unacceptable for the door to remain locked and keep a dog waiting.


To solve this problem, I would design the following loop for the main program in pseudocode:

While (True)

  // Begin Critical Section of Code - Can't Be Interrupted
    Scan to see if dogs are in the area (i.e. RFID scan)
      If a valid dog is in the area, unlock the door
      Else, do nothing
  // End Critical Section of Code That Can't Be Interrupted

  Update RFID table (interrupt service routine)
  // In the meantime, dog is walking through the door
  Check if the door is unlocked
    If the door is unlocked, delay 30 seconds to give 
    the dog sufficient time to enter

  Make sure the doggy door is locked
  Go back to the beginning of this loop

The above architecture satisfies the requirements and enables a dog to enter even when the table of RFID tags is in the middle of an update.

Return to Table of Contents