Sie sind auf Seite 1von 21

SOEN422- Final Report

Page 1 of 21

SOEN 422 Final Report

‘ Remote Explorer 422 ’

Team information

Team Number

Member Name

Member SID

Gregorio Di Stefano


Kareem Afara


Jose Diaz



1 -

SOEN422- Final Report

Page 2 of 21

Table of Contents

Page 3 – Introduction

Page 4 – Project Description

Page 7 - Hardware Design

Page 9 – Software Design

Page 12 – Development Software

Page 15 – System Performance

Page 17 – System Delivery

Page 18 – Project Process Discussion

- 2 -

SOEN422- Final Report

Page 3 of 21

1 - Introduction

The purpose of this document is to discuss the life cycle of this courses final project.

We have compiled this documentation with enough information to provide guidance in re- creating the exact same project.

The hardware and software subsystems are thoroughly discussed with complete details on how the system s intercommunicate with each other to produce the end result: the ‘Remote explorer 422’.

Through out the documentation you will be able to see the challenges we encountered while constructing our robotic device. The report encompasses the entire steps w e took to have a presentable demo.

A demo can be seen here: - upl

- 3 -

SOEN422- Final Report

Page 4 of 21

2. Project Description

2.1 – The name and purpose of the unit

The name our device is ‘Remote Explorer 422’.

The purpose of this unit is to investigate it’s surrounding by capturing images and sending them back to our control software. The unit is also controlled wirel ess, via WiFi. This allows the user to manoeuvre the vehicle, and view images it captures from it’s surrounding.

2.2 - Unit function and performance

The device is expected to function in a very simple manner.

Once the ‘Beagleboard xM’ is powered up it will connect to a wireless network. In our case, the system will connect to the “Project1” wireless SSID. In order to increase simplicity, and to eliminate points of failure, this wireless network is not password protected / encrypted.

Once connected to the wireless network, a HTTP server will be executed. The server used is called TinyHTTPD. It is configured to run, and only list the currently logged in user’s home directory.

A software package called ‘motion’ will be used to capture images from the webcam and save them to memory. This image will eventually be transferred wirelessly to the client.

At this poin t, the server on the device is waiting for instructions on how to traverse its surroundings. The only possible instructions it can receive are received on TCP port 5555. The possible instruct ions are :‘w’, ‘a’, ‘s’, and ‘z ’. These instructions tell the d evice to move forward, left, right, and down, respectably.

- Once the ‘w’ instruction is received, the device will move forward for 100 milliseconds - and then stop.

- Once the ‘a’ instruction is received, the device will move left for 100 milliseconds - and then stop.

- Once the ‘s’ instruction is received, the device will move right for 100 milliseconds - and then stop.

- Once the ‘z’ instruction is received, the device will move backwards for 100 milliseconds - and then stop.

The device runs at full p ossible speed of the motors. This is due to time- constraints. Instead of using analogWrite() and various speeds, we decided to use digitalWrite(). Using digitalWrite() allows use to prevent the speed from being changed, thus allowing use to write less code for the java based Control Center and server.

- 4 -

SOEN422- Final Report

Page 5 of 21

Finally, on request, the Beagleboard updates a local file called ‘out.jpg’ with an image capture from the webcam. The image is transferred over to the Client. The resolution of this file is small, due to t he fact a low- quality webcam was used. The image, however, is of adequate quality.

2.3 Project Hardware

Beagleboard xM – This embedded syst em is one of the most critical parts of our device. This embedded system allows us to work in a Linux environmen t. This allows our device to be easily programmable in a high- level programming language, which thus lead to rapid application programming. Using the Beagleboard we were able to write a server programming in Java, and run various Linux software packages u sed to add functionality to our ‘Remote Explorer 422’. The Beagleboard

xM ’s USB ports, powered and controlled by the Linux kernel, allowed us to extend the hardware on our device in a module- like fashion. We were easily able to connect

a wireless card, an d a webcam to the Beagleboard .

Arduino Teensy++ 2.0 - This simple to program device was also crucial to our final device. The Arudino is the ultimate environment to program low - level devices with simplicity. Using the ATMEL processor – the processor on the Arduino, we were able to simple communicate with the H- Bridges using the Arduino’s high level programming language. Usually, this would be done using AVR assembly language. The programming of the h- b ridges allowed us to easily control the electrical m otors. This allowed us to move the device according to our instructions.

Webcam with LED : A generic, Chinese manufactured webcam was used to capture images. We connect the webcam to the device’s metal framework, and connected it to the beagleboard via US B. The technical details about this device are very limited.

This is due to the fact is a no - name, generic device. Ubuntu recognized this device as

a UVC device : USB Video Class device. A set of 3 LED lights is connected to webcam.

They provide a mean of light - source used to illuminate the camera sensor’s range.

Wireless Card: This device allowed us to wirelessly connect to an access point. This allowed us to connect to the server running on the Beagleboard xM using our client on another machine also connected to the same access point. The wireless card’s chipset was a Realtek 8187. This device was purchased due to that fact it’s chipset is well recognized and fully function in Linux. The wireless card connects to the Beagleboard xM using a USB cable. Ubuntu was able to recognize the device without an additional device drivers installed.

4 Electrical Motors: These were generic, electrical motors used to maneuver our device. They were connected to the H- Bridge’s on our breadboard.

- 5 -

SOEN422- Final Report

Page 6 of 21

2.4 Project S oftware

- Project software is discussed in a detailed manner in Section 4 of this documentation.

- 6 -

SOEN422- Final Report

Page 7 of 21

3. Hardware design

This section will discuss the hardware design, and the communication between the hardware. This section is written by Kareem Afara

3.1 - System Design

section is written by K areem Afara 3.1 - System Design Figure 1 - Illustrates the

Figure 1 - Illustrates the connectivity - Please reference diagram.jpeg

The Beagleboard xM running Ubuntu is connected to an Arduino Teensy 2.0++ via USB connection acting as an RS232 interface. The Beagleboard is also connected to a Wireless card via usb connection, in addition to a power source and a usb web cam that includ es LED lights.

The beagle board is powered with a custom programmed Java server that connects to the client, which runs on a separate computer. Commands are sent using the client program, that is transferred wirelessly to the beagle board that communicat e to the A rduino using the RXTX java library called by the server program, the teensy receives the instructions and sends them to the H- bridges that are connected directly to a power supply and to the motors.

- 7 -

SOEN422- Final Report

Page 8 of 21

3.2 – Subsystem Design

The Motors are regular simple DC electric motors. When the coils are powered, magnetic field is generated around the armature, which causes the wheels to turn in the direction specified according to the current coming from the H- bridges.

The H- bridge we used is the SN754410 whi ch is a quadruple high- current half- H driver designed to provide bidirectional drive currents up to 1 A at voltages from 4.5 V to 36 V.

The device is designed to drive inductive loads such as relays, solenoids, dc and bipolar stepping motors, as well as ot her high - current/high- voltage loads in positive- supply applications.(source pdf/view/28616/TI/SN754410NE.html )

We c onnected each two motors to a separate H- bridge. The h bridge was fed with an external power supply of 5v in the Vss pin (9). All of the Vs, EN, and EN2 (1,8,16) are fed connected to the 5v pin of the teensy in order to set them as enabled. The GND pins (4,5,12,18) are connected to ground. Out1, Out2 (3,6) are connected to one motor, and Out3, Out4 (14,11) are connected to the other motor on the same side. Pins ln1, ln3 (2,15), are connected to pins 15 in the teensy, and ln4and In2 (7,10) are connected to p in 16 in the teensy. The other h bridge is connected as follows: Pins ln1, ln3 (2,15), are connected to pins 25 in the teensy, and ln4and In2 (7,10) are connected to pin 26 in the . (Referring to datasheet provided by class Moodle)

The Arduino Teensy 2.0++ is connected to the beagle board using a usb cable, it is also grounded by the GND pin. The Vcc pin is connected with all the enable pins of the h - bridges. Pins 15 and 16 are connected to the In pins of the first h - bridge, this way it controls one side of the car that includes 2 motors. Pins 25 and 26 are connected to the other H- bridge to power the other two motors.(reference )

The beagle board is the centre of this car, where are the command are received, processed and then sent to the teensy using the RS232 emulator. We didn’t modify or hard wire anything to the beagle board, we just plugged in a web cam, a wireless card and the power supply.

3.3 - System intercommunication

Give details of the hardware that provide the communication channels between the components and any external device.

The hardware that we used to provide the communication between the beagleboard and the controlling computer, is the wireles usb card.

- 8 -

SOEN422- Final Report

Page 9 of 21

The hardware that we used to communicate between beagleboard and teensy is the usb cable

The hardware we used to communicate to the motors is the H- bridge , and connecting wires.


4.1 System Software design & 4.2 Software Subsystem Designs

Arduino (Teensy 2.0++):

An open - source microcontroller enviornment. The board contains an Atmel- AVR processor, and many input/outpt connections. This device also is easily programable using a “C- like” programming language. This embedded device listened to input from the beagleboard, and moved the motors accordingly.

from the beagleboard, and moved the motors accordingly. Figure 2 - Teensy 2.0++ Beagleboard xM: Figure

Figure 2 - Teensy 2.0++

Beagleboard xM:

motors accordingly. Figure 2 - Teensy 2.0++ Beagleboard xM: Figure 3 - Beagleboard xM This device

Figure 3 - Beagleboard xM

This device is an open- source, system on a chip embedded device. It runs an ARM Cortex processor, has it’s ow n 128Mb RAM, USB ports, RS232, audio ports and a SDHC slot. The SD memory chip came preloaded with Ubuntu 11.10. This device acts exactly like a modern computer. We used the linux operating system extensivly to get our project full functional.

Ubuntu 11.10 was used as an

operating system. This allowed us to





(webcam/wireless) and run


packages from the Ubuntu repository.

- 9 -

SOEN422- Final Report

Page 10 of 21

Java: We used the java programming language to develop two pieces of software. One being the client, the other being the server . The client was composed of the Swing library, in order to create the client’s GUI. The gui consisted of a hardcoded ip address to connect to, and a center image box. The GUI capture input from our keyboard, and se nt over the instructions to the server running on the beagleboard. The server was also programmed in java. It ran on the beagleboard. The server simply binded to port 5555, and waited for a connection. Once a connection was established, the RxTx library was programmed to connect to the /dev/ttyUSB000 device: the Arduino. Any messages sent to the Beagleboard would be parsed to a code understood by the Arduino, and transmittd to the Arduino via the RS232 cable.

Linux packages:

iwconfig ’ : This is one of the ‘Wireless tools for Linux’. 'iwconfig’ is used to connect a wireless adapater to a wireless access point. We use this tool to connect our Beagleboard to a wireless access point. For demonstration purposes we converted a Apple OS X machine into an access point, and directed iwconfig to connect to the ‘Project SOEN422’ AP. The way this was achieved was by running the following commands:

Sudo iwconfig wlan0 up sudo iwconfig eth1 essid "Project SOEN422" sudo dhclient wlan0
Sudo iwconfig wlan0 up
sudo iwconfig eth1 essid "Project SOEN422"
sudo dhclient wlan0

‘dhclient’ : dhclient is a DHCP client. All it does is request a dynamic ip address from the access point. Witho ut this, the Beagleboard would not have an ip address, and we would thus not be able to connect to it.

- ‘ motion ’ : detects motion from a webcam and outputs it to a file. All this piece of software does it connect to our webcam (/dev/video0) , if it detects motion, it write a file with the image. We simply modified the config file for this package to out put a file called ‘out.jpeg’. So if motion was detected, a new version of ‘out.jpeg’ would be written. This software package is open - source and available in Ubuntu. After being installed, this package must simply be run by executing:

motion &

- ‘tinyhttpd’: is a popular http server available for UNIX based operating systems. We used this to transfer over out webcam image produced via ‘motion’. We used a webse rver to transfer over files simply because it could be done. It also demonstrated how simply functionality could be added to the beagleboard. We chose tinyhttpd over apache2 (most popular http server) because tinyhttpd is very simple to configure using co mmand line arguements. Instead of having the full blown, completely customizable server that apache provides, we used tinyhttpd since it was very easy to deploy. The following code was executed to start the server, and getting it to list file from the home directory:

thttpd –d /home/shawarma

- 10 -

SOEN422- Final Report

Page 11 of 21

4.3 Arduino functions used

The setup portion of the Arduino code is used only to open a connection with the Serial port. This is done using Serial.begin(9600);. The only argument supplied is ‘9600’ which is the baud rate. The setup portion also contains some code to open up some pins for ‘output’ mode. This reverses the pins for the loop code, which will eventually be executed.

The loop code then begins execution.

Before even beginning to read the serial connection, the pins conne cting to the motor are set to “LOW”. The purpose of these four lines of code is to switch the motors off. This is performed so that the device is not constantly moving in one direction.

Then, the code begins listening to the serial input, using Serial.r ead(); It reads one, single byte, and runs a series of if statements. The matching if statement then executes a four digitalWrite commands with the arguments for how to control each wheel. So, for example, to move forward, the ‘w’ if statement is executed. This ends up calling 4 digitalWrite commands. The first argument is the pin connected to the motor, and the second is either HIGH or LOW.

4.4 System Software Communication

The system software communicates simply. We have two communication points. On e wireless, and one USB. The wireless network relies on the wireless card. We simple use standard Linux commands to get the Beagleboard connected to a wireless network. ‘iwconfig’ is used to connect the wireless device to an access point, ‘dhclient’ is used to get an actual IP address. Once we have a physical link going, our Java application creates an application layer. This application layer, our server, binds to local TCP port 5555 and waits for a client to connect. Once a client connection is made to the server, information is recieved on the application layer on port 5555. The server than processes this information accordingly.

There is also communication between the Beagleboard xM and the Arduino. The communication is only unidirectional: the Bea gleboard is able to commun icate only to the Arduino. The Arduino is not able to write to the Beagleboard .

5. Development Software

An Apple OS X computer was used often during the project life cycle. OS X was simple to use, and also provided a UNIX foundation. Therefore, a ‘ssh’ client, and ‘screen’ where already pre- installed in the operating system. The Arduino IDE and loader are available for OS X. Also, a personal home computer running Arch Linux was also used without problem.

- 11 -

SOEN422- Final Report

Page 12 of 21

Also, please keep in mind that all of these tools were easily obtainable, and installable using Ubuntu’s package manager, ‘apt - get’.

Development on the Arduino was very straightforward. The only software that was Required was the Arduino IDE and development kit available from . The simple to use IDE was essential to writing software for the

Figure 4 - Arduino IDE running in Linux
Figure 4 - Arduino IDE running in Linux

Teensy 2.0++. The teensy loader was required to actually flash the software we wrote to the actual device.

actually flash the software we wrote to the actual device. Figure 4 - Teensy loader running
actually flash the software we wrote to the actual device. Figure 4 - Teensy loader running

Figure 4 - Teensy loader running in OS X

Figure 5 - Connected to Beagleboard via 'screen'

- 12 -

SOEN422- Final Report

Page 13 of 21

On the Beagleboard, a lot more software was involved to successfully develop and complete this project. The first challenge was to connect to the Beagleboad’s Ubuntu console. As a n advanced Linux user – Greg took control of most situations involving this device. Firstly, instead of listening to Corey’s instructions on how to connect to the Beagleboard, Greg used the ‘screen’ application. Connecting to the device was rather simple this way.

The first piece of software installed on the Beagleboard was the ‘openssh- server’ package. This was installed because using the RS- 232 cable was very tedious and not to mention an outdated (but still a standard) solution to opening a shell. Once the ssh server was installed, all we needed to do was con nect an Ethernet cable to the Beagleboard, and a home router. At this point, we no longer used the supplied RS - 232 cable, but instead used SSH (an industry standard) to connect to the Beagleboard.

‘vim’ – an amazing text editor – was used to edit files o n the Beagleboard. This was used to edit dot files, such as the configure files provided by the ‘motion’ package. It was also used to make small changes to our server without the need to re- transfer the file.

‘Eclipse’ – a JAVA IDE – this w as a useful, but not entirely useful piece of development software. Eclipse provided a nice, but heavy, work environment to develop in. We could have simply used ‘vim’ instead, but we used Eclipse initially due to habit. However, vim was used match more t owards the end of the life cycle. This might actually be due to the fact that vim is a lot more lightweight than Eclipse, and that most of the code was already written. Eclipse was used heavily during the initial coding, however, ‘vim’ proved to be much m ore useful in making small changes to our existing framework.

‘javac’ – the java compiler – was used to compile the file on the Beagleboard /Laptop to executable bytecode. Obviously, java was one of the most important parts of the development. Without the Java development kit, nothing would have been done.

‘java’ – the java run time environment – was used to actually execute our Server.class and Client.class file on the Beagleboard/Laptop.

‘scp’ a file transfer utility that works over SHH, was used to transfer versions of the server over to the Beagleboard from our development machines. ‘scp’ is a great utility for transferring files from one UNIX based machine to another.

‘tcpdump’ – this was used for wireless troubleshoot ing. ‘tcpdump’ is a packet sniffer. Essentially, it displays the contents of every packet to console. During the initial wireless testing phase, we ran into problems. The Beagleboard was not getting an IP address and the issue was localized to the Beaglebo ard’s environment or the actual

- 13 -

SOEN422- Final Report

Page 14 of 21

wireless adapter. This utility assisted in determining the source of the problem. The problem will be discussed further in the next section of this report.

Finally, we chose Java for several reasons. Obviously, its portability was one of main reasons. With Java, we were able to write a Server and Client, without the use of any native operating system code. This made it feasible to run the client on different operating systems without rewriting any code. During our initial demo, we tested the Client on an OSX machine, and a Linux machine and at both times it worked flawlessly. In addition to portability, Java is a simple language to program in. Programming a GUI and sockets in C++, for example, would have required much more w ork. Java provided a very simple way of using sockets, and a GUI in S wing. Finally, we were taught Java at Concordia, and have used it heavy since. We were very happy with out decision in picking Java.

- 14 -

SOEN422- Final Report

Page 15 of 21

6. System Performance

In t his section, the testing phase of the project’s life cycle will be discussed. We will not cover the Beagleboard and Arduino as components, since if they were the point of failure – it would have been immediately obvious.

6.1 Component testing

Motors : The motors were tested simply by writing a simple sketch in the Arduino IDE and making sure the motors responded accordingly. We initallaly tested without using a H - bridge, but eventually incorporated the H - bridge between the Arduino and the motors. The motors never caused us any problems, however, once we incorporated the H - bridges, we noticed some serious problems.

H- Bridges: When we initially incorporated the H- bridge in lab 4, there were no obvious problems. We successfully completed our lab, and everything was functional. We were able to change the PIN from high to low on the H- bridge, and it acted according and change the polarity of the motors. It was not until the beagleborad was introduced to the project, that difficulties arose.

The problem we encountered was strange. Towards the end of the project, when everything was put together, everything was working well, except for the fact that our Robot was only able to move (or process instructions for it’s direction) more than a couple steps, before t he Beaglebaord would crash. We knew the Beagleboard was crashing because of the obvious ‘kernel panic’ being displayed on the Beagleboard’s console session. At first, we had no idea what was going on, however, we got to the conclusion that the problem was only occuring when we change the direction of the motors. A further look at the situtation confirmed a problem with the H - bridge. Mistakenly, the PIN on the H - bridge designed to be connected to an external power source, was actually being connected to the Arudino’s +5V PIN. We changed this configuration, so that the datasheet and our actual were setup were identical. Viola! The Beagleboard stopped crashing.

It was pretty interesting that the Beagleboard was crashing, when the actual problem was isolated t o the Arduino. Somehow, correcting the issue with the H- Bridge fixed the problem.

Webcam: The webcam was very easy to introduce to Beagleboard since it was already being used on my Linux machine. Simply looking at the Ubuntu’s log messages on the Beagl eboard showed that the device was being recognized, and configured by Ubuntu.

Wireless : Like the webcam, this wireless device was already working on a personal home entertainment system powered by Linux. Verifying Ubuntu’s log showed that the device was being detected, and configured without any problems.

- 15 -

SOEN422- Final Report

Page 16 of 21

6.2 System test

The first part of the system testing consisted of testing the communication between the server and the client. We had a hard time getting the server to print the command the client wa s send over to it (we were just testing the client/server on the loopback device). The software we used to troubleshoot the problem is called ‘netcat’ . ‘netcat’ has the ability to run as a server, or as a client. This enabled us to easily determine where the source of failure was. Eventually, with the help of ‘netcat’ we were able to isolate a simple but with the server.

netcat –t <port>

netcat <host> <port> (to act as a client)

(to act as a server)

One of the major problems discovered during the last steps of putting together the project was that the wireless card was not gettin g an IP address. Initially, the Beagleboard was being tested without the wireless connectivity. We simply connected the Beagleboard to the router using an Ethernet cable and testing that the Java application, webcam, and motors were all working correctly.

The problem with the wireless card was that after following the following set of commands:

Sudo iwconfig wlan0 up

sudo iwconfig eth1 essid "Project SOEN422"

sudo dhclient wlan0

The ‘dhclient’ would stop responding. Verbose output of ‘dhclient’ showed that the machine was waiting for an IP address, but was never being assigned on e. A quick Google search (after 4- 5 hours of fiddling around with Ubuntu’s wireless setting!) provided a solution to the problem. ‘network- manager’ was removed using Ubuntu’s package manager, and soddenly , dhclient started working! The Beagleboard was equipped with an IP address!

The java applications worked seamlessly. We encountered very few problems. The only one that comes to mind is that that the IP address in the client is hardcoded into the source code, instead of reading the mutable input bar w e placed that said “IP Address”. This was not properly implemented due to a lack of time (and possibly lack of motivation since we were so please with our work J ).

- 16 -

SOEN422- Final Report

Page 17 of 21

7 . System Delivery

Since the reboot was submitted in tacked, this section will ignore the exact wiring of the components.

7.1 System initialisation

These instructions assume that the user does not have access to a personal router. Using a personal router would simplify the following instructions, but since routers are not always avail able, we will use the RS - 232 to connect to the Beagleboard.

Also, please not, I am assuming the user is using a OS X or Unix based operating system.

The following lists of instructions are required in order to get the robot functional.


Connect the ext ernal power source to a computer/ USB plug adapter. This power source draws 5V from the USB standard.


Connect the Beagleboard’s AC/DC adapter to an external power source. This is used to provide electricity to the Beagleboard.


Please take note that that the Arduino is directly connected to the Beagleboard, and thus drawing power from it.


Connect the Beagleboard’s RS232 to your personal laptop/computer using the RS - 232 USB adapter.


Once connected, connect to the Beagleboard using ‘screen /dev/ttyUSB0 115200’ (or connect via SSH if a personal router is available)


Once the terminal is opened. You simply must instruct the Beagleboard to connect to a wireless network. This is achieved by executing the following code:

Sudo iwconfig wlan0 up sudo iwconfig eth1 essid "<SSID TO CONNECT TO>" sudo dhclient wlan0
Sudo iwconfig wlan0 up
sudo iwconfig eth1 essid "<SSID TO CONNECT TO>"
sudo dhclient wlan0


Once connected to the wireles s network, the following commands will execute the software required to acquire messages from the webcam, open a webserver, and run the Java software:

motion &

thttpd –d /home/shawarma &

- 17 -

SOEN422- Final Report

Page 18 of 21


At this point the Beagleboard/ server is functional. Now it is time to power up the client.


Now, on the laptop/computer we will simply run the java Client program.


To run the java client, simply run the following code on the client machine:

java ~/Client

7.2 System operation

The Client GUI is very simple to use. Once the java Client is executed, the Cl ient is constantly reading the input from the keyboard. The directional arrows are the keys used to control the device. So if the up arrow, left arrow, right arrow, or down arrow are pressed, the direction is going to be sent wireless ly to the Beagleboard’s server, and the device will move in the specified direction.

In the center of the application, there is an image frame. Whenever the image is clicked on, the image is updated with the latest feed from the webcam. The image has to be clicked on for an update because we did not have the time to add a thread to the program to automate the process.

because we did not have the time to add a thread to the program to automate

Figure 6 - The Client GUI

- 18 -

SOEN422- Final Report

Page 19 of 21

8 – Project Process D iscussion

The completion of the project went rather smoothly. We did have some problems with the hardware, and some problems with the Wireless connectivity, but with due time, we were able to resolve this problems and create a successful device.

A good understanding of the Linux operating system was largely attributed to this p roject’s success. Much of the work being performed is done on the Beagleboard. Without a solid understanding on how the command line interface works, this project would not have been possible. The webcam, the wireless adapter, and the communication protocol is implemented on the Beagleboard. Thankfully our group was experience enough in Linux to configure all the devices correctly.

The learning experience this course provided was very useful. The entire Arduino environment is fascinating, and great to w ork with. Also, the beauty of a system on chip, such as the Beagleboard, is wonderful. The power such a tiny device can hold is incredible. As mentioned during our demo, it almost felt as if we create a remote control investigation device used by police enforcement.

At first, one of the most challenging parts of this course actually knew how to wire the Arduino on the Beagleboard. However, with the help of the labs, and the teacher assistant, Corey, we became more comfortable wiring the Beagleboard.

Fin ally, I would like to mention the difficulty involving our group. The project and report was not distributed equally around all three partners. This led to a lot of the project and report being created by two people, and not three.

- 19 -

SOEN422- Final Report

Page 20 of 21


Please see the ‘Source code’ folder for a complete source code.

Arduino code

//16 and 17 left side wheels 16=H 17= L means forward //26 and 25 right side wheels 25=H 26 L means forward

byte inbyte = 0;

void setup() { Serial.begin(9600); //open the serial port

pinMode(16, OUTPUT); pinMode(17, OUTPUT); pinMode(25, OUTPUT); pinMode(26, OUTPUT);

Serial.println("Super Motor Control for Super Falafel"); Serial.print(">"); //simulate prompt


void loop() { digitalWrite(25, LOW); digitalWrite(16, LOW);

digitalWrite(26, LOW); digitalWrite(17, LOW); // delay(100); inbyte =; //Read one byte (one character) from serial port.

if (inbyte == 'w') { digitalWrite(16, HIGH); digitalWrite(25, HIGH);

digitalWrite(17, LOW); digitalWrite(26, LOW);


Serial.println("forward"); //echo the command Serial.print(">");


if (inbyte == 's') { digitalWrite(16, LOW); digitalWrite(25, LOW);

digitalWrite(17, HIGH); digitalWrite(26, HIGH);


Serial.println("back"); //echo the command Serial.print(">");


if (inbyte == 'a') { digitalWrite(16, LOW); digitalWrite(26, LOW); digitalWrite(25, HIGH); digitalWrite(17, HIGH);


Serial.println("left"); //echo the command Serial.print(">");


if (inbyte == 'd') { digitalWrite(25, LOW); digitalWrite(17, LOW); digitalWrite(16, HIGH); digitalWrite(26, HIGH);


Serial.println("right"); //echo the command Serial.print(">");


- 20 -

SOEN422- Final Report

Page 21 of 21

if (inbyte == 'k') {

digitalWrite(25, LOW); digitalWrite(16, LOW);

digitalWrite(26, LOW);

digitalWrite(17, LOW);


Serial.println("stop"); //echo the command Serial.print(">");



- 21 -