CSE-690 INDEPENDENT STUDY

GUIDE- JYOTI SINHA (VISITING FACULTY IIITD)

BY- RAHUL BATRA MT13049

Problem Statement-
To study the theoretical and practical implementation of Processing and Arduino
programming by designing ways, 1) to interpret , analyize and visualize sensors data
dynamically, 2) to manually upload the microcontroller programs to the arduino board
without using the API, 3) to formulate a way to include parallelization in Arduino
programming for better speed and performance, 4) to generate code for a line following
robot using IR sensors.

Introduction-
Processing relates software concepts to principles of visual form, motion, and
interaction. It integrates a programming language, development environment, and
teaching methodology into a unified system. The processing language is a text
programming language specifically design to generate and modify images.
Sketching is necessary for the development of ideas. It allows us to analyse how the data
varies and interpret the changes needed to incorporate for obtaining the desired result.
Arduino is a single-board microcontroller, intended to make building interactive objects
or environments more accessible. Arduino is a tool for making computers that can sense
and control more of the physical world than the desktop computer. It's an open-source
physical computing platform based on a simple microcontroller board, and a
development environment for writing software for the board.
Arduino can be used to develop interactive objects, taking inputs from a variety of
switches or sensors, and controlling a variety of lights, motors, and other physical
outputs. Arduino projects can be stand-alone, or they can communicate with software
running on the computer (e.g. Flash, Processing, MaxMSP). The Arduino programming
language is an implementation of Wiring, a similar physical computing platform, which
is based on the Processing multimedia programming environment.

Sensors and communication-

Physical phenomena are measured by electronic devices called sensors. Different
sensors have been invented to acquire data related to touch, force, proximity, light,
orientation, sound, temperature, and much more. Sensors can be classified into groups
according to the type of signals they produce (analog or digital) and the type of
phenomena they measure. Analog signals are continuous, but digital signals are discrete
and are constrained to a range of values (e.g., 0 to 255).

Most basic analog sensors utilize resistance. Changes in a physical phenomenon modify
the resistance of the sensor, therefore varying the voltage output through the sensor.
An analog-to-digital converter can continuously measure this changing voltage and
convert it to a number that can be used by software. Sensors that produce digital signals
send data as binary values to an attached device or computer. These sensors use a
voltage (typically between 3.5 and 5 volts) as ON (binary digit 1 or TRUE) and no
voltage as OFF (binary digit 0 or FALSE). More complex sensors include their own
microcontrollers to convert the data to digital signals and to use established
communication protocols for transmitting these signals to another computer.

Analog voltage signals from sensors can’t be directly interpreted by a computer, so they
must be converted it to a digital value. Some microcontrollers provide analog-to-digital
converters (ADC or A/D) that measure variations in voltage at an input pin and convert
it to a digital value.
Data is sent and received between microcontrollers and computers according to
established data protocols such as RS-232 serial, USB, MIDI, TPC/IP, Bluetooth, and
other proprietary formats like I2C or SPI. Most electronics prototyping kits and
microcontrollers include an RS-232 serial port, and this is therefore a convenient way to
communicate.

The following examples connect sensors and actuators to a Arduino board and
communicate the data between the I/O board and a Processing application. When the
Arduino board is plugged in to a computer’s USB port, it appears on the computer as a
serial port, making it possible to send/receive data on it.

Example 1: Switch
This example sends the status of a switch (ON or OFF) connected to the Arduino board
to a Processing application running on a computer. Software runs on the board to read
the status of a switch connected on digital pin 4. The value 1 is sent to the serial port
continuously while the switch is pressed and 0 is sent continuously when the switch is
not pressed.
Example 2: Light sensor
This example brings data from a light sensor (photoresistor) connected to the Arduino
board’s analog input pin 0 into a Processing application running on a computer.
Software runs on the board to send the value received from the light sensor to the serial
port. Because the light sensor is plugged into an analog input pin, the analog voltage
coming into the board is converted into a digital number before it is sent over the serial
port.
Example 3: Turning a light on and off
This example sends data from a Processing program running on a computer to a
Arduino board to turn a light ON or OFF. The program continually writes an H to the
serial port if the cursor is inside the rectangle and writes a L if it’s not. Software running
on the board receives the data and checks for the value.
Example 4: Controlling a servomotor
This example controls the position of a servomotor through an interface within a
Processing program. When the mouse is dragged through the interface, it writes the
position data to the serial port. Software running on a Arduino board receives data from
the serial port and sets the position of a servomotor connected to the digital I/O pin
number 4.
Arduino Programming-
First have an introduction on how the Arduino board is used for microcontroller
programming.
An Arduino board is a microcontroller situated on a PCB with other components to
make it easier to program, attach/detach components, and turn on and off. This board
typically have components to regulate power to protect the microcontroller and a USB
or RS-232 serial port to make it easy to attach cables. The small pins on the micro-
controller are wired to larger pins called headers that make it easy to insert and
remove sensors and motors. Small wires embedded within the PCB connect pins to a
corresponding header. Small reset switches make it easy to restart the power without
having to physically detach the power supply or battery.
Arduino boards use the Wiring language to program their microcontrollers and use a
development environment built from the Processing environment. In comparison to the
Processing language, the Wiring language provides a similar level of control and ease of
use within its domain. Wiring has some functions specific to programming micro-
controllers and omits the graphics programming functions within Processing. Like
Processing programs, Wiring programs are translated into another language before
they are run. When a program written with the Wiring language is compiled, it’s first
translated into the C/C++ language and then compiled using a C/C++ compiler.
Arduino is a powerful system (the board has more memory, I/O pins, serial ports, and
other internal capabilities) and is therefore expensive. The microprocessor on the
Arduino board can be removed and replaced if it is damaged.
 Arduino Software IDE

Arduino I/O Board

Arduino Development Environment-

The Arduino development environment contains a text editor for writing code, a
message area, a text console, a toolbar with buttons for common functions, and a series
of menus. It connects to the Arduino hardware to upload programs and communicate
with them.

Uploading

Before uploading our sketch, we need to select the correct items from the Tools >
Board and Tools > Serial Portmenus. On Windows, it's probably COM1 or COM2 (for a
serial board) or COM4, COM5, COM7, or higher (for a USB board) - to find out, we look
for USB serial device in the ports section of the Windows Device Manager.
Once we've selected the correct serial port and board, press the upload button in the
toolbar or select the Upload item from the File menu. Current Arduino boards will reset
automatically and begin the upload. With older boards (pre-Diecimila) that lack auto-
reset, we'll need to press the reset button on the board just before starting the upload.
On most boards, we'll see the RX and TX LEDs blink as the sketch is uploaded. The
Arduino environment will display a message when the upload is complete, or show an
error.
When we upload a sketch, we're using the Arduino bootloader, a small program that has
been loaded on to the microcontroller on our board. It allows us to upload code without
using any additional hardware. The bootloader is active for a few seconds when the
board resets, then it starts whichever sketch was most recently uploaded to the
microcontroller. The bootloader will blink the on-board (pin 13) LED when it starts (i.e.
when the board resets).
Sample Arduino program being uploaded using Arduino API-
Manually Uploading the Arduino Program without the use of API-

Steps to upload arduino program-

Download Arduino1.5.8 BETA from http://www.arduino.cc/en/Main/Software
Windows: ZIP file (for non-administrator install)
Unzip the contents in the document folder
Create a sketch_oct03a\sketch_oct03a.ino inside arduino-1.5.8
Run the following command-
C:\Users\rahul batra\Documents\arduino-1.5.8>arduino_debug --board
arduino:avr:uno --port COM28 --upload sketch_oct03a\sketch_oct03a.ino
wait for some time and see the output-
Parallelization in Arduino Programming-
We need to find a way so that multiple arduino programs can be uploaded at the same
time which will benefit by allowing us to make short programs instead of one big
program and then running them on arduino board. This will help to improve the speed
and performance of arduino board where we can perform multiple tasks simultaneously
without waiting for each task to proceed sequentially. To do this task we need to first
understand the arduino build process and how it can be configured .

Arduino Build Process-

A number of things have to happen for the Arduino code to get onto the Arduino board.
First, the Arduino environment performs some small transformations to make sure that
the code is correct C or C++ (two common programming languages). It then gets passed
to a compiler (avr-gcc), which turns the human readable code into machine readable
instructions (or object files). Then, the code gets combined with (linked against), the
standard Arduino libraries that provide basic functions like digitalWrite() or
Serial.print(). The result is a single Intel hex file, which contains the specific bytes that
need to be written to the program memory of the chip on the Arduino board. This file is
then uploaded to the board: transmitted over the USB or serial connection via the
bootloader already on the chip or with external programming hardware.

Multi-file sketches-
A sketch can contain multiple files. To manage them, we need to click on the right-facing
arrow just above the scroll bar near the top of the environment. Tabs have one of four
extensions: no extension, .c, .cpp, or .h (if we provide any other extension, the period
will be converted to an underscore). When the sketch is compiled, all tabs with no
extension are concatenated together to form the "main sketch file". Tabs with .c or .cpp
extensions are compiled separately. To use tabs with a .h extension, we need to #include
it (using "double quotes" not <angle brackets>).

Transformations to the main sketch file-

The Arduino environment performs a few transformations to the main sketch file (the
concatenation of all the tabs in the sketch without extensions) before passing it to the
avr-gcc compiler.
First, #include "Arduino.h", is added to the top of the sketch. The header file (found in-
<ARDUINO>/hardware/cores/<CORE>/) includes all the defintions needed for the
standard Arduino core.
Next, the environment searches for function definitions within the main sketch file and
creates declarations for them. These are inserted after any comments or pre-processor
statements (#includes or #defines), but before any other statements (including type
declarations). This means that if we want to use a custom type as a function argument,
we should declare it within a separate header file. Also, this generation isn't perfect: it
won't create prototypes for functions that have default argument values, or which are
declared within a namespace or class.
Finally, the contents of the current target's main.cxx file are appended to the bottom of
the sketch.
Targets-
The Arduino environment supports multiple target boards with different chips
(currently, only AVRs), CPU speeds, or bootloaders. These are defined in a
board preferences file.

Build process-
Sketches are compiled by avr-gcc.
The include path includes the sketch's directory, the target directory
(<ARDUINO>/hardware/core/<CORE>/) and the avr include directory
(<ARDUINO>/hardware/tools/avr/avr/include/), as well as any library directories (in
<ARDUINO>/hardware/libraries/) which contain a header file which is included by the
main sketch file.
When we verify a sketch, it is built in a temporary directory in the system temp
directory. When we upload it, it is built in the applet/ subdirectory of the sketch's
directory .
The .c and .cpp files of the target are compiled and output with .o extensions to this
directory, as is the main sketch file and any other .c or .cpp files in the sketch and any .c
or .cpp files in any libraries which are #included in the sketch.
These .o files are then linked together into a static library and the main sketch file is
linked against this library. Only the parts of the library needed for our sketch are
included in the final .hex file, reducing the size of most sketches.
The .hex file is the final output of the compilation which is then uploaded to the board.
During a "Verify" the .hex file is written to \Documents and Settings\<USER>\Local
Settings\Temp (on Windows). During upload, it's written to the applet sub-directory of
the sketch directory (which we can open with the "Show Sketch Folder" item in the
Sketch menu).

Upload process-
Sketches are uploaded by avrdude.
The upload process is also controlled by variables in the boards and main preferences
files. The board files include-
<BOARD>.upload.protocol the protocol that avrdude should use to talk to the board
(typically "stk500").
<BOARD>.upload.speed: the speed (baud rate), avrdude should use when uploading
sketches (typically "19200").
<BOARD>.upload.maximum_size, the maximum size for a sketch on the board
(dependent on the chip and the size of the bootloader).

Outcome-
Yes we can upload multiple programs at the same time to one Arduino board by
including them as multiple sketches but uploading a sketch to more than one arduino at
the same time is not possible because arduino is writing to its flash memory. The write
time for this is not the same on all arduinos, nor the same through the arduino's life
time. As the arduino has to signal back to the PC to get the next bytes to load we would
have to multiplex all the arduino's serial responses to see when they were all ready
which is not impossible but definitely not worth doing.
Line Following Robot
To make a robot follow a line using IR sensors first we need to understand that a dark
object reflects less light than a bright object, or a dark object absorbs more light than a
bright object, this is the only fundamental logic behind a line sensing robot. So, in a line
sensing robot, we make a sensor that detects the difference between bright object and a
dark object i.e. it distinguishes a black line from a white surface.

In our experiment we are using three IR sensors. So there are three possible conditions-
 The center IR sensor seeing the line
 The left IR sensor seeing the line
 The right IR sensor seeing the line
Now we need to use these conditions to design the way a robot always steer towards
the line. The information obtained from sensors is used to decide whether to continue
straight or to change the wheel speeds to turn or to stop.

First I am going to generate line following code using SpeedobotiX GUI, which is a
product of Omnipresent Robot Technologies Pvt. Ltd. It is a processing based graphical
user interface which is developed for school kids to understand robotics in an easy way.
The main aim of the company in designing this product is to provide school kids with
such a platform where they can run a robot by using normal logic without even getting
into programming.

Basic elements of SpeedobotiX GUI-

Start- It shows the start of a new flow chart. No element will be added before the Start
element is added.
Sensors- It will add a sensor in the flow chat. Each sensor has two components-
1. Position- Where the sensor is fixed in the bot i.e. Left, Middle or Right.
2. Pin- Which pin on the Edu – board is the sensor connected to. Pins- 3-12.
Each sensor will have two lines coming out of it in the flow chart depicting the output of
the sensor (ON – Green Line & OFF- Red Line).
Delay- Delay element is added to hold the logic to perform some task for given time.
Delay can accept time in ms (milliseconds). Generally it is added after adding a Motion
element to make the bot do the motion for a given time.
Motion- Motion element is added to give the bot command to -Move forward, Move
backward, Turn right, Turn left or Stop.
End- This element represents the end of a flow chart. No programme can be uploaded
without adding the End element in the flow chart. All the flow lines terminate to the End
element.

Options provided by SpeedobotiX GUI:

Select Motor Driver Set- The drag-able option panel to select the motor driver set can
be seen on the bottom left corner of the screen. It allows user to choose among the two
motor driver sets provided on the microcontroller board to run the DC motors. It can be
helpful when one of the motor driver is not working.
Upload- The upload button will generate the code to be run on the microcontroller
board, from the flow chart made by the user.

Speedobotix GUI-

Now we first generate the code for a simple program using SpeedobotiX GUI to test the
functionality of all elements, In this program the bot will move forward with a delay of
5ms if there are no obstacles and turns backward when encounters any obstacles in
front of it with a delay of 10ms.
The code generated by uploading the above flowchart is-

int Leftsensor=0, Rightsensor=0, Middlesensor=0;

void Move_Forward(){digitalWrite(0, HIGH);
digitalWrite(0, LOW);
digitalWrite(0, HIGH);
digitalWrite(0, LOW);
}
void Move_Backward(){digitalWrite(0, HIGH);
digitalWrite(0, LOW);
digitalWrite(0, HIGH);
digitalWrite(0, LOW);
}
void Turn_Left(){digitalWrite(0, LOW);
digitalWrite(0, HIGH);
digitalWrite(0, HIGH);
digitalWrite(0, LOW);
}
void Turn_Right(){digitalWrite(0, HIGH);
digitalWrite(0, LOW);
digitalWrite(0, LOW);
digitalWrite(0, HIGH);
}
void Stop(){digitalWrite(0, LOW);
digitalWrite(0, LOW);
digitalWrite(0, LOW);
digitalWrite(0, LOW);
}
void setup(){
pinMode(5,INPUT);
pinMode(0, OUTPUT);
pinMode(0, OUTPUT);
pinMode(0, OUTPUT);
pinMode(0, OUTPUT);
}
void loop()
{
if(Middlesensor == HIGH)
{
Move_Forward ();
delay( 5);
}
if(Middlesensor == LOW)
{
Move_Backward();
delay( 10);
}
}

Line follower code using three IR sensors-

First lets understand how to describe the motion of bot using the three sensors-
Let the ON state in green colour describe detection of white surface.
Let the OFF state in red colour describe the detection of black surface.

For three sensors we have eight different combinations (23 =8 ) as every sensor has two
possibility so in general for n- sensors we will have 2n possible combinations.

All the eight different possibilities are-

1)If the left, middle and right sensors are all OFF, that means we have reached a dead
end so we stop now.
2)If the middle sensor is OFF and the left and right sensors are ON, then it means we are
following the line so we move forward.
3)If the left, middle and right sensors are all ON, that means we are not following the
path i.e. all sensors detect white surface, so by default we move forward until we find a
path.
4)If the left sensor is OFF and the middle and right sensors are ON, then it means we
have deviated from our path to the right so we move left now.
5)If the right sensor is OFF and the left and middle sensors are ON, then it means we
have deviated from our path to the left so we move right now.
6)If the left sensor is ON and the middle and right sensors are OFF, then it means we
have detected an obstacle on the right, so we move left now.
7)If the right sensor is ON and the left and middle sensors are OFF, then it means we
have detected an obstacle on the left, so we move right now.
8)If the middle sensor is ON and the left and right sensors are OFF, then it means we
have detected an obstacle on the left and right and we are not following the path, so we
move backwards now.
The flowchart for all the above mentioned combinations, generated in the SpeedobotiX
GUI is-

The code generated for the line follower by uploading the above flowchart is –

int Leftsensor=0, Rightsensor=0, Middlesensor=0;

void Move_Forward(){digitalWrite(0, HIGH);
digitalWrite(0, LOW);
digitalWrite(0, HIGH);
digitalWrite(0, LOW);
}
void Move_Backward(){digitalWrite(0, HIGH);
digitalWrite(0, LOW);
digitalWrite(0, HIGH);
digitalWrite(0, LOW);
}
void Turn_Left(){digitalWrite(0, LOW);
digitalWrite(0, HIGH);
digitalWrite(0, HIGH);
digitalWrite(0, LOW);
}
void Turn_Right(){digitalWrite(0, HIGH);
digitalWrite(0, LOW);
digitalWrite(0, LOW);
digitalWrite(0, HIGH);
}
void Stop(){digitalWrite(0, LOW);
digitalWrite(0, LOW);
digitalWrite(0, LOW);
digitalWrite(0, LOW);
}
void setup(){
pinMode(5,INPUT);
pinMode(6,INPUT);
pinMode(7,INPUT);
pinMode(0, OUTPUT);
pinMode(0, OUTPUT);
pinMode(0, OUTPUT);
pinMode(0, OUTPUT);
}
void loop()
{
if(Leftsensor == HIGH && Middlesensor ==HIGH && Rightsensor ==HIGH)
{
Move_Forward ();
delay( 5);
}
if(Leftsensor == HIGH && Middlesensor ==LOW && Rightsensor ==HIGH)
{
Move_Forward ();
delay( 5);
}
if(Leftsensor == LOW && Middlesensor ==HIGH && Rightsensor ==HIGH)
{
Turn_Left();
delay( 5);
}
if(Leftsensor == LOW && Middlesensor ==LOW && Rightsensor ==HIGH)
{
Turn_Right();
delay( 5);
}
if(Leftsensor == HIGH && Middlesensor ==HIGH && Rightsensor ==LOW)
{
Turn_Right();
delay( 5);
}
if(Leftsensor == HIGH && Middlesensor ==LOW && Rightsensor ==LOW)
{
Turn_Left();
delay( 5);
}
if(Leftsensor == LOW && Middlesensor ==HIGH && Rightsensor ==LOW)
{
Move_Backward();
delay( 5);
}
if(Leftsensor == LOW && Middlesensor ==LOW && Rightsensor ==LOW)
{
Stop();
delay( 5);
}
}

The only problem with the above generated code is that it does not involve Calibration.
So if left or right sensor detects a change in sensor value they will steer towards their
respective ends, regardless whether the surface is black or not. So to distinguish
between lighter and darker surface and also ensure at what minimum reading change
the sensors should behave differently we need to write the Calibrate code. For this we
define a term threshold. Threshold is the difference in values required between the
center sensor and the left or right sensors before the robot decides to make a turn. We
can assume the difference to be any value, lets say 5. This means that the left and right
sensors would need to detect a value greater than the value read from the center sensor
plus the threshold value before action is taken. So, if the center sensor is reading a value
of 600 and the left sensor is reading 603, then the robot will keep going straight.
However, a left sensor value of 612 (which is higher than the center value plus
threshold) means that the left sensor is detecting the black line, indicating that the robot
is too far over to the left. So the motors would adjust to make the robot turn to the right
to compensate. The threshold value will vary depending on the contrast between the
floor (or whatever surface used) and the black line. This may need to be adjusted to
ensure the robot only turns when it has detected enough of a difference between floor
and line to ascertain it had moved too far left or right. So I wrote the following code for a
line follower robot using three IR sensors which includes the calibration code-

#define lights 9
int IR1, IR2, IR3;
int leftOffset = 0, rightOffset = 0, centre = 0;
int speed1 = 3, speed2 = 11, direction1 = 12, direction2 = 13;
int startSpeed = 150, rotate = 30;
int threshhold = 5;
int left = startSpeed, right = startSpeed;
void calibrate() {
for (int x=0; x<10; x++) {
digitalWrite(lights, HIGH);
delay(100);
IR1 = analogRead(0);
IR2 = analogRead(1);
IR3 = analogRead(2);
leftOffset = leftOffset + IR1;
centre = centre + IR2;
rightOffset = rightOffset + IR3;
delay(100);
digitalWrite(lights, LOW);
delay(100);
}
leftOffset = leftOffset / 10;
rightOffset = rightOffset / 10;
centre = centre /10;
leftOffset = centre - leftOffset;
rightOffset = centre - rightOffset;
}
void setup()
{
pinMode(lights, OUTPUT);
pinMode(speed1, OUTPUT);
pinMode(speed2, OUTPUT);
pinMode(direction1, OUTPUT);
pinMode(direction2, OUTPUT);
calibrate();
delay(3000);
digitalWrite(lights, HIGH);
delay(100);
digitalWrite(direction1, HIGH);
digitalWrite(direction2, HIGH);
analogWrite(speed1,left);
analogWrite(speed2,right);
}
void loop() {
left = startSpeed;
right = startSpeed;
IR1 = analogRead(0) + leftOffset;
IR2 = analogRead(1);
IR3 = analogRead(2) + rightOffset;

if (IR1 > (IR2+threshhold)) {

left = startSpeed + rotate;
right = startSpeed - rotate;
}
if (IR3 > (IR2+threshhold)) {
left = startSpeed - rotate;
right = startSpeed + rotate;
}
analogWrite(speed1,left);
analogWrite(speed2,right);
}