Robotic Cartography Part 6: Graphical Display Code

Rover Robot

I used the Processing programming language and IDE to write DisplayPathway, a program that communicates serially with the Arduino Uno and receives the position data recorded during the execution of NavigateObstacles. The program receives data in the form of (distance,angle) pairs that represent the robot’s movement vectors. DisplayPathway then calculates approximate stopping points along the robot’s path and plots lines between the points representing the robot’s approximate path (see Introduction).

Processing is an open source language based on Java, and a free IDE for OS X, Windows, or Linux can be downloaded here. I like Processing because its IDE behaves exactly in the same way as the Arduino IDE, and so learning and using both languages is quite easy. Documentation for the processing language can be found here.

See my github repository for the graphical display code:

Robotic Cartography Part 5: Robot Code

Rover Robot

The C program, NavigateObstacles, is transferred to the Arduino Uno board via USB. It contains all of the instructions that control the robot’s motors, sensors, and data logging capabilities. You can copy and paste the code from below or download my original .ino file from the Dropbox link included. I’m also setting up a GitHub profile so that I can get feedback from readers in the future. Stay tuned!

See my github repository for the navigation and graphical display code:

Robotic Cartography Part 4: Wiring Diagrams

Rover Robot

Photos and circuit diagrams made in Fritzing are shown below. The circuit layouts are meant to minimize the number of digital pins used and to maximize the number of sensors and actuators used. The pin numbers referenced in the diagrams correspond to the numbers of the digital pins on the Arduino board. Every digital I/O pin on the Arduino Uno R3 board was used with the exception of pins 0 and 1. Pins 0 and 1 serve as serial communication pins, and they were left unused so as to not interfere with serial communications during operation. In order to further expand the capabilities of this robot with more digital devices, the Arduino’s analog pins would have to be used as general I/O pins. Alternatively, less useful devices (e.g. indicator LEDs) could be removed to free additional digital pins.

Front Circuit
Front Circuit


Rear Circuit
Rear Circuit


Robotic Cartography Part 2: Parts Overview

Rover Robot

Parts Lists
This post is a basic introduction to the parts I bought in order to build the cartographer robot; advanced makers may wish to skip to subsequent blog posts in this series in which I describe building, wiring, and programming steps.

Main Build List:

Other Useful Parts Sources:

Knowledge Resources:

Part Review: Arduino Uno R3
This is a universally useful microcontroller board that can store and execute C programs written on a Mac or PC. It has analog and digital I/O pins that can be connected to an enormous number of sensors and actuators. Arduino is loved by the hobbyist community because its standardized, open-source design eliminates engineering problems that are often prohibitively difficult to a beginner. With Arduino, there is no need to select the right microcontroller out of thousands of options, make a regulated power supply for it, and then learn surface mount soldering to connect it to a circuit; the board does all of that for you at a very low cost.


I like Arduino because it is very well designed. One part of its genius is the standardized pin layout that has been adopted by part manufacturers who make Arduino-compatible expansion boards or “shields.” Once plugged in, Arduino shields add functions such as Internet connectivity, data storage, or wireless communications. The shield pictured in the images below is a prototyping shield that adds more electrical connections to the Arduino. Even more useful is the ability to expand Arduino with sensors or actuators that aren’t necessarily designed for it; via its I/O pins, Arduino can power and communicate with any device that uses a 5V power supply. This example gives a sense of the breadth of the selection of devices that can be used with Arduino. Arduino’s great design gives it an infinite potential for creative expression.

Breadboard Shield

Part Review: Parallax BOE Robotics Shield Kit
The first iteration of this rover is based on the Arduino-compatible Parallax BOE Robotics kit. I chose the BOE kit because I wanted to make the first prototype as quickly as possible by not doing my own mechanical design. Furthermore, the kit reduces the acquisition time of useful parts because it comes with almost every sensor, actuator, wire and resistor needed to complete this build; the applicable continuous rotation servo motors, infrared sensors, and wiring will be described subsequently. One additional advantage of the kit is that it acts as a motor interface shield for the Arduino while not blocking additional expansion with more shields. I take advantage of this capability by adding both the BOE shield and the prototyping shield shown in the above section. Although prototyping speed is advantageous with the BOE kit, high unit cost and quite large physical dimensions are drawbacks; for future iterations, I plan to 3D print my own chassis and solder my own circuit layout to reduce unit cost and robot dimensions.


Part Review: HC-SR04
The robot uses an HC-SR04 ultrasonic sensor to complement the infrared sensors included with the BOE kit. An ultrasonic sensor is a good complement to infrared sensors because it can more easily determine distances to obstacles. Furthermore, infrared sensors have trouble detecting transparent and black obstacles because they do not reflect enough light; ultrasonic sensors do not have this problem.


Part Review: Parallax Serial LCD
The Parallax serial LCD is useful because it allows the robot to easily communicate with humans. Other, cheaper, “Arduino-compatible” LCDs exist, but they require 16 pins in order to be used. The Parallax version comes with a microcontroller on the back that allows Arduino to communicate with the LCD via software serial techniques that require only 3 pins. The Parallax LCD is also useful because it includes a speaker, thus further reducing the number of pins needed to communicate with human users. This LCD vastly increases ease of implementation, but it adds computational overhead and cost: serial communication is notoriously slow, and 16-pin LCDs cost 1/3 as much.


Robotic Cartography Part 1: Introduction

Rover Robot

I wanted a rover robot that would explore an area and then map it out once the exploration is finished. The robot would move at random, use simple sensors to detect obstacles, and store its movements as vectors in memory. Obstacle locations could then be inferred from movement vectors because the vector direction must change as the robot detects and responds to each obstacle. Given sufficient inferred obstacle location data, a map with obstacle locations could be produced so that future exploration could be intelligently guided, not random. Human visualization of movement and obstacle data would also be a useful capability.

I built a robot prototype that approximates the above functions. I used an Arduino Uno R3 board to control the robot’s movements and store movement data in the EEPROM of the board’s microcontroller. At this point, the robot operates on the tenuous assumption that turning its continuous rotation servos at a constant speed results in constant movement of the robot itself. I then wrote a program in the Processing language that acquires movement vector data from the Arduino Uno via a serial cable and then plots the movement vectors for the user to interpret. Below are images of the robot and of the path plot generated by Processing. I’m currently working on a Processing algorithm that will make assumptions about the movement vectors to generate a “map” of the robot’s surroundings.


Path Displayed

Because this cartography technique relies on high-volume data acquisition and because the environment could immobilize or destroy the explorer robot, using only one autonomous robot to generate a map would be slow and not robust. I envision a future system in which a swarm of expendable, small robots could be deployed in unison to gather large amounts of data; loss or immobilization of a fraction of the robots would be acceptable and would not significantly impede data gathering.