University of Central Florida
IRIM
INEXPENSIVE ROBOT WITH
INTERIOR MAPPING
Senior Design Documentation
TEAM#: 27
HUNG LE
ALVARO MONTOYA
IBRAHIM SHOFIQUEL
JAIME QUINTERO
i
Table of
1.
2.
Introduction .......................................................................................................................... 1
1.1.
Executive Summary.................................................................................................... 1
1.2.
Motivation and Goals ................................................................................................. 1
Project Details ...................................................................................................................... 2
2.1.
2.1.1.
Designed Features .............................................................................................. 2
2.1.2.
Additional Features ............................................................................................ 3
2.2.
3.
Project Requirement and Specification ................................................................ 2
Milestones ..................................................................................................................... 3
Research ............................................................................................................................... 4
3.1.
Existing or Similar Projects...................................................................................... 4
3.1.1.
Mapping Solutions for Low Cost Mobile Robot .......................................... 5
3.1.2. Building Mobile Robot and Creating Applications for 2D Map Building
and Trajectory Control ....................................................................................................... 7
3.1.3. ROS – based Mapping, Localization and Autonomous Navigator using
a Pioneer 3-DX Robot and their Relevant Issues ....................................................... 8
3.1.4. Development of a 3D mapping using 2D/3D Sensors for Mobile Robot
Locomotion........................................................................................................................... 9
3.2.
3D Scanning Devices ............................................................................................... 10
3.2.1 PrimeSense Sensors .............................................................................................. 11
3.2.2 Cubify Sense ............................................................................................................ 12
3.2.3 Kinect Variations ..................................................................................................... 13
3.2.4 Lidar Sensors ........................................................................................................... 14
3.2.5 Stereo Camera ......................................................................................................... 16
3.2.6 Ultrasonic Sensor ................................................................................................... 16
3.2.7 IR sensors ................................................................................................................. 16
3.2.8 Sensors Comparison (14 -1)................................................................................. 17
3.3.
3D Scanning Libraries ............................................................................................. 19
3.3.1 Point Cloud Library ................................................................................................ 19
3.3.2 3D Display and Development Library ................................................................ 21
3.3.2.1 Libfreenect............................................................................................................. 22
3.3.2.2 Kinect SDK 1.8 ...................................................................................................... 22
3.3.3 Image Processing Library ..................................................................................... 23
3.3.3.1 OpenCV .................................................................................................................. 23
ii
3.4.
Robot Platform ........................................................................................................... 23
3.4.1 J-Bot v2.0 .................................................................................................................. 23
3.4.2
RobotGeek Geekbot Bare Bones Kit ........................................................... 24
3.4.3 Lynxmotion Tri-track Chassis Kit ....................................................................... 24
3.5.
Motors .......................................................................................................................... 26
3.5.1.
Hobby motor ....................................................................................................... 26
3.5.2.
Gearhead motor ................................................................................................. 26
3.5.3.
Voltage range ..................................................................................................... 27
3.5.4.
Motor control ...................................................................................................... 27
3.5.5.
Load capacity ..................................................................................................... 29
3.5.6.
Torque .................................................................................................................. 29
3.6.
Locomotion sensor .................................................................................................. 29
3.6.1 Motor Encoder ......................................................................................................... 30
3.6.2 Accelerometer .......................................................................................................... 34
3.6.3 Magnetometer .......................................................................................................... 36
3.7.
3.7.1.
Tiva C.................................................................................................................... 37
3.7.2.
MSP430G2 ........................................................................................................... 39
3.8.
Wireless Components.............................................................................................. 41
3.8.1.
Sub-GHz Radio Frequency Transceivers.................................................... 42
3.8.2.
Bluetooth BLE .................................................................................................... 43
3.8.3.
Internet of Things (Wireless Fidelity) ........................................................... 46
3.9.
4.
Microcontroller .......................................................................................................... 37
Power ........................................................................................................................... 47
3.9.1.
Nickle-metal hydride battery .......................................................................... 47
3.9.2.
Lithium ion battery............................................................................................ 47
3.9.3.
Lithium Iron Phosphate battery..................................................................... 47
3.9.4.
Power set up....................................................................................................... 48
3.9.5.
Voltage Regulation ........................................................................................... 49
Design .................................................................................................................................. 53
4.1.
Hardware Design ....................................................................................................... 53
4.1.1.
Robot Platform ................................................................................................... 53
4.1.2.
Power Requirements ........................................................................................ 53
4.1.3.
Computational Requirement .......................................................................... 53
iii
4.1.4.
PCB Design ......................................................................................................... 54
4.1.5.
Motion .................................................................................................................. 64
4.2.
4.2.1.
Software Design Overview ............................................................................. 66
4.2.2.
Robot Operating System (ROS) ....................................................................... 67
4.2.3.
Point Cloud Library (PCL) ............................................................................... 70
4.2.4.
3D Display ........................................................................................................... 76
4.2.5.
Simultaneous Localization and Mapping (SLAM) .................................... 77
4.2.6.
Navigation ........................................................................................................... 80
4.2.7.
Autonomous System........................................................................................ 80
4.2.8.
Accelerometer Communication..................................................................... 84
4.2.9.
Magnetometer Communication ..................................................................... 85
4.2.10.
Encoder Communication ............................................................................ 86
4.2.11.
Wireless Communication ............................................................................ 87
4.2.12.
Programming Languages ........................................................................... 88
4.2.13.
IDE ..................................................................................................................... 88
4.3.
5.
6.
Software Design ........................................................................................................ 66
Design Summary ....................................................................................................... 90
4.3.1.
Design Overview ............................................................................................... 90
4.3.2.
Software System ............................................................................................... 91
4.3.3.
Hardware Summary .......................................................................................... 92
Construction....................................................................................................................... 96
5.1.
Robot Platform Assembly ....................................................................................... 96
5.2.
3D Scanner Mounting .............................................................................................. 97
5.3.
Software Installation ................................................................................................ 98
Testing and Evaluation .................................................................................................... 98
6.1.
Unit testing.................................................................................................................. 98
6.1.1.
Robot Platform Testing ................................................................................... 98
6.1.2.
Power and Regulation Testing .................................................................... 100
6.1.3.
Input Output Testing ...................................................................................... 100
6.1.4.
Circuit Testing.................................................................................................. 101
6.2.
Software Testing ..................................................................................................... 101
6.2.1.
6.3.
3D Scanner Testing ........................................................................................ 101
Performance Testing ................................................................................................ 105
iv
6.3.1.
Known Environment .......................................................................................... 105
6.3.2.
Unknown Environment ..................................................................................... 105
Financial and Administrative ....................................................................................... 106
7.
7.1.
Bill of Materials ........................................................................................................ 106
7.2.
Budget ........................................................................................................................ 108
8.
Conclusion ........................................................................................................................ 110
9.
Reference .......................................................................................................................... 110
10.
Copyright Permissions .............................................................................................. 114
v
1. Introduction
1.1.
Executive Summary
While the robot has been used in the industry for over a decade, unmanned robot
are being develop for military purpose and autonomous vehicle are on the roll,
there is however little development for domestics purpose. The main reason for
this slow development are due to the price and development cost of the robot, thus
only major corporations or government can afford the cost of robot. However, as
the rise of technology, where faster processor being develop, sensors technology
become cheaper, there is no doubt that robot would become a much more
common sight as much as the progression of cellphone and recently the smart
devices.
Still, building a robot is a complex process, much less having the robot to move,
navigate within the environment, or specifically building a map of the environment.
The process of building a robot often require extensive knowledge wide range topic
of mechanical design, electrical system, and software programming. The online
instructions are often complex or detailed specifically for certain type of reader,
thus building the robot can become time consuming, costly, and frustrated.
Unfortunately, modern engineers often focus on one single aspect of the robot thus
making the task building a functional robot even more discouraging. Usually, a
software engineer would buy an expensive mobile platform and try to make their
software work with it, while an electrical engineer would try to build their own robot
and often struggle getting the program to function with their custom made robot.
The project Inexpensive Robot with Interior Mapping (IRIM) is expected to address
this issue by providing a simple mobile robot platform, which allow software
engineers to spend less time and money for the robot and focus on the software
aspect while letting electrical engineers to design their own robot with minimal
need of software knowledge.
1.2.
Motivation and Goals
What does it mean to be engineers, it is only by develop the technology that serve
ourselves, people, and environment that make us engineers. As engineers, it is
out desire to make life become more convenience, to make house become home,
to entertain people, and to have fun doing engineering work.
The origin of the project, came from a discussion with a fellow student majoring in
computer science, who desired a functional mobile platform that can be control
from a remote computer, and a friend majoring in electrical engineering, who liked
to have a program built in a robot that can be extend and improve. As it turn out,
software focus students often find themselves lacking the actual platform to study
the dynamic environment of robot, while electrical students frequently having
trouble writing a program to accommodate their robot.
The goal of this project is to assemble a robot chassis with electrical circuit that
maximize extensibility, thus allowing any electrical engineer to modify and extend
1
the design while still have a functional robot. The project at the same time also
transparent the electrical system, and hardware communication from control
software thus allow software developer to experiment with the robot without the
need to understand the electrical system within the robot.
2. Project Details
2.1.
Project Requirement and Specification
This project composed of two main components:
One is a mobile robot platform with differential drive that capable to perform basic
two-degree-of-freedom maneuver: movement along the y-axis (back and ford),
and rotation along the z-axis (yaw.) Preliminary specifications of the mobile robot
platform are provided in table below (Table 2.1.a)
Robot Platform Specification
Width
10 inches
Length
12 inches
Height
4 inches
Average Speed
2 feet/second
Max Speed
5 feet/second
Average Rotation Speed
0.35 radiuss/second (~20
degrees/second)
Max Rotation Speed
1.05 radiuss/second (~60
degrees/second)
Table 2.1.a - Robot Platform Specification
The other main component is a 3D Scanning device that capable to provide depth
image or point cloud data. The expected specifications of the device are listed in
table below (Table 2.1.b)
3D Scanning Specification
Width
≤ 5 inches
Length
≤ 12 inches
Height
≤ 4 inches
Minimum Range
5 feet
Max Range
10 feet
Table 2.1.b – 3D Scanning Device Specification
2.1.1. Designed Features
The designed features are requirements that define the project’s characteristic and
integrity. They are the features that being expected and must be satisfied before
any other additional features. The designed features are listed below:

The robot platform is expected to be able to drive with at least two degrees
of freedom (back and ford, and yaw)
2

The robot platform is designed to be control from distance either through
remote controller (radio wave), handheld devices (Bluetooth), or computer
(Wireless connection). The remote feature allow users to fully manipulate
the robot when they desired or in case of the robot autonomous system
failed to function.
 The robot platform is designed to avoid falling off the cliff (such as down of
the staircase). The feature is mean to protect the robot from getting damage
but expected to be override by users’ remote control should a need arise.
 In cases of handheld devices, or computer controlling, the robot is designed
to display its vision (camera image) to user. The feature allow user to control
from distance without having the robot within users’ field of vision.
 The robot platform is designed be autonomously mapping the environment
and navigate within given environment. The robot should have at least two
autonomous mode. The exploration mode in which the robot will trying to
map the environment as detail as possible. The navigation mode in which
the robot is given a destination (with in the mapped environment) by users
and the robot will move to the destination without collide to any obstacles
(including human) along the way.
 The robot software should be maximize the extensibility. The project was
design to be used by hobbyists, students, and engineers as the mean to
test their personal idea, thus the robot software should allow others to
integrate their design into the robot with as little work as possible.
2.1.2. Additional Features
The additional features are feature that are less important and are not required to
have. The additional features are mean to add more depth and functionality to the
robot. The additional features range from developers additional display to extra
autonomous mode, which are the features that normally could be extend from the
robot by users. Few are listed below:



2.2.
The robot will display 3D data of the known environment. This allow user to
have better vision of the environment.
The robot will able to detect motion. This allow the robot to act as a small
mobile security camera during the period in which the environment is
supposed to be free of motion (at night or during working hours).
The robot will able to be controlled by user over long distance through
wireless connection. This will allow users to leave for a long distance trip
and still able to monitor their house at any position (more favorable than a
stationary security camera).
Milestones
Though this project is complex in term of functionality and performance quality,
the project is however composed of multiple modules that can be study,
research, design, and implement separately. This is very important for the project
as well as future extension, as the main goal of the project is to allow engineers
of different discipline to try out their ideas independently and able to put the
3
pieces together with minimal effort. The following figure (Figure 2.2) is the
estimated schedule for the project in the following semester (Senior Design 2)
Month
December
Goals
 Buy all materials
 Prepare for following semester
 Allocate jobs
January
 Begin building subsystems
 Begin programming software
 Begin building testing circuits
 Begin testing communication
February
 Continue programming
software
 Finish building circuit boards
 Begin programming motor
control board
March
 Finish software programming
 Get boards manufactured
 Begin unit testing
 Begin integration testing
April
 Finish unit testing
 Finish integration testing
May
 Turn in and present
Table 2.2.a: Milestone chart for Senior design 2
3. Research
As stated before, under the description of the project this autonomous robot is
expected to work indoors, due to the fact that the robot is gathering its data from a
Kinect and a Kinect is not suitable to work in outdoor environment because the
projector inside works with IR light which if taken outside it would not recognize
anything.
People have experimented with this mapping technology for quite a long time
already, therefore there are many projects similar to this senior design idea
presented. This section is going to discuss the similarities and differences of this
project versus some previous projects done in the past.
Analyzing previous projects will provide vital information about what parts are
useful and inexpensive as well as the most common challenges other groups faced
during the implementation phase of the project, thus facilitating the realization of
the project and narrowing down the scope of the research. Since many features
are common from project to project these are going to be analyze in detail in this
section.
3.1. Existing or Similar Projects
There are many research projects and prototype projects done in the area of 3D
mapping. In this section some of the most closely resemble projects to the one
discuss in this paper are going to be analyzed, the goal is to compare and contrast
4
the many features such as the hardware parts and software programs used to
realize the project. The analysis based on other projects would allow for
improvement on certain phases where other groups failed or did not have the
means to realize the desired results.
3.1.1. Mapping Solutions for Low Cost Mobile Robot
The 2D mapping mobile robot is a thesis for a master’s degree in Computer
Science. The student was aiming to provide an inexpensive yet reliable and robust
way to map, localize, and achieve path planning with a mobile robot. The student
used TI’s OMAP4430 Panda board to power his robot and realize all the functions
planned.
This particular project focused on the mapping and path planning section of
robotics. The project was realized in a way to have a fully functional robot indoors
and outdoors environments by using the Panasonic time of flight camera which if
adjusted the right way can be suitable for outdoor environment due to the high
tolerance of ambient light, as well as indoor environment.
The paper show and review the different hardware parts that may provide the best
results and yet be of low cost. Various sensors are discussed in detail focusing
mainly in the pros and cons based on this, the project used the Time of Flight or
TOF camera which has a decent performance in relation to the cost of the
hardware. The author of the paper also researched the various algorithms for path
planning and formats for mapping. The student used a Grid-based map which
provides a high resolution image; advantages and disadvantages are also
discussed in detailed.
In order to realize path planning a clear and neat map is necessary to generate the
optimal paths the robot is to travel by.
The image below was generated by the TOF camera, that is the raw data, after
this data is acquired then modifications such as filtering noise and removing
redundant points is done to get a clean imagine of the obstacles and facilitate the
path planning task (Figure 3.1.a).
5
Figure 3.1.a: Imagine captured by the Kinect (this is known as raw data) (Printed with courtesy of
Xuan Wang author of the research paper)
After the author used an algorithm called featured-grid hybrid map to filter out the
undesired points and to make the image clearer the processed image looks a lot
simpler and more suitable for path planning which was one of the author’s main
goals in his thesis (Figure 3.1.b).
Figure 3.1.b: This image shows the processed by an algorithm raw data captured
by the Kinect (Reproduced with permission from Xuan Wang author of the paper)
6
3.1.2. Building Mobile Robot and Creating Applications for 2D Map Building
and Trajectory Control
This particular project focused on mapping and planning the robot trajectories
based on the information captured by the IR sensors. This particular project was
broken up into three different stages to have better organization and to ensure all
the aspects of the planned project were taken care of. The first stage of the project
was the designing of the robot in order to provide a flexible mobility in case of
obstacles in the path of the trajectory and the positioning of the different
components on the platform. The second stage was to ensure the construction of
the map to be accurate for the robot to create a correct trajectory or path. The third
and last stage of this project was to focus on the path generation based on the
information collected by the IR sensors.
This project and the project described on this paper relates in terms of the
communication from robot to PC which are accomplished by wireless
communications. Both of the projects have a system of master and slave, that is,
the computer being the master in this system sending commands based on the
results given by the IR sensors to the microcontroller which is the slave who
execute the different commands which are transmitted in serial. Since the project
use IR sensors the different functions of the robot are carry out in an indoor
environment.
Figure 3.1.c: Robot using IR sensors to capture images to construct the map. (Reproduce with
permission given by Senka Krivić one of the authors of the paper).
The collection of the data in order to generate a map is carry out by the IR sensors,
likewise, the mapping described in this paper is realized by a pair of IR sensors,
one is to capture the imagine and the other sensor provides the depth of the
imagine, resulting in valuable data to be transform to a point cloud map for
navigation purposes.
7
3.1.3. ROS – based Mapping, Localization and Autonomous Navigator
using a Pioneer 3-DX Robot and their Relevant Issues
This project was realized by three authors, the main goal was to improve on
research and previous works done with autonomous robots used primarily for
mapping and localization.
The group focused mostly on the software side of the project. It did not have much
design in the implementation of the hardware since it was realized with a pioneer
3-DX robot which already comes with an embedded controller, motors with
encoders ready to use as well as ultrasonic sensors in the front and rear end; the
robot would only require to be programmed and connected with a computer in
order to control the robot. In this case the group decided to add a laser for range
finding which works better than the sensors already mounted by the manufacturer
(Figure 3.1.d).
Figure 3.1.d: The image above shows the artificial environment created by the
researchers for testing purposes (Reproduced with the permission of Safdar
Zaman coauthor of the research paper)
The project was implemented using the Robot Operating System or ROS, which is
an operating system exclusively for usage to operate a robot. ROS is based on
Linux and has many features to share different resources with the different parts
of the robot. It is also in charge of the synchronization of the hardware parts
resulting in an optimal communication. This operating system is able to
communicate with other computers through packages which contains executable
programs which are in charge of data collection from the sensors.
The robot operating system provides various packages for the implementation of
essential functions for a robot. The process of programming the robot to realize
the functions of mapping, localization, and autonomous navigation are facilitated
by the different packages provided by the ROS and the group of experimenters
made used of this advantage.
8
The next image (Figure 3.1.e) shows the result of the artificial map without being
modified (Raw data).
Figure 3.1.e: Mapping of the indoor artificial environment (Reproduced with the permission given
by Safdar Zaman, a coauthor of the paper)
3.1.4. Development of a 3D mapping using 2D/3D Sensors for Mobile Robot
Locomotion
This particular project focused on the simultaneous localization and mapping
algorithm (SLAM). The main sensor to generate an image in order to process a
map is the PMD camera. This device is able to capture 3D images and fast enough
to be considered real time capturing; this is essential whenever the project is
aiming at developing a map as the robot is in motion. Since this camera only
generates images in gray scale the author used a RGB camera to provide a
colored map.
The PMD camera is capable of generating depth images thanks to the time of flight
feature, that is, the time the light takes to travel to a particular object and back to
the receiver. The depth of the images are very accurate due to the information
every pixel provide back to the camera.
The authors of the project also achieve a realistic 3D map by merging the image
generated by the RGB camera and the PMD camera (Figure 3.1.f). This process
involved the matching of depth registers to pixels in the 2D image. The researchers
admits there is loss of data in the process but not as significant to affect generation
of the map.
The four wheeled robot has a small platform just to provide the space for the PMD
and RGB cameras, a microcontroller and an embedded PC, significantly lighter
than the robot being develop in this paper.
9
Figure 3.1.f: The resulting map from the RGB and PMD cameras (Reproduced
with permission given by C. Joochim and H. Roth authors of the original article)
3.2.
3D Scanning Devices
Nowadays, the technology of modeling real world objects has advanced and
improved at higher speeds than expected and this is mainly due to the introduction
of the 3D printers to the market. Even though 3D printers have been introduced for
quite a while many people are still unaware of how this devices work.
The 3D scanners are powerful electronic devices which are employed to realize
many tasks, such as modeling objects, facilitate improvements of already created
models, and to accurately model the real world. In this project the intention is to
employ a scanning device to create a map about the surroundings of the robot.
This map is then used for localization, path planning, and generation of 3D images.
These devices are capable of generating multiple measurements; they make use
mainly of lasers to generate in most cases point cloud maps. Compiling all these
measurements and with help of special software to refine the output of them, many
applications can be realized.
There are various scanning devices in the market today; they are classified as
short range and middle to long range scanners. Based on the distance range the
scanner has its way of scanning objects, that is, if the scanner is a short range
then it usually employs a single laser method. The single laser method points
towards the object and then a sensor detects the laser when it bounds off the
surface of the object, and since the angle between the sensor and the laser is
known the distance can be calculated. Another method is called structured light, in
this case the laser projects a grid and the sensor calculates the distance by the
deformation of the edges of the lines. Both of the methods have their pros and
cons, the single laser method known as the laser triangulation is resistant to
ambient light, meaning that a scanner with this implementation is suitable for
10
outdoor environment. The disadvantage is the low accuracy it poses. The
structured light method is more accurate but it may require specific lighting to
accurately function. (1)
In the case of the long range sensors, these are sensors which detects objects
from a distance of two meters or more they employ different methods. There are
two main methods which are the most popular. The first method is the pulse based,
this method calculates the distance of the object from the sensor by measuring the
time it took to signal to travel from the laser to the sensor. Since the speed of light
is known, this ease the task of calculating the distance. The other method is known
as phase shift, as its name suggests the usage of difference of the phase from the
laser being sent out and the receiving laser is compare to calculate the distance.
Pulse based method is suitable for long range sensing whereas, phase shift is
more suitable for medium range, but more accurate than the pulse based sensors.
(1)
In this section various scanning devices are analyzed to check the advantages
and disadvantages of their functionality and the reason for the choice made when
finding the right scanning device to fulfil the expectations of the project and to
stay within the financial limits.
3.2.1 PrimeSense Sensors
PrimeSense sensors are a robust and high performance sensors to generate 3D
images. These sensors work with structure light technology, that is, the sensors
projects a surface of pixels on to any surface and as this pixels deform the objects
or anything on top of the surface becomes recognizable by the sensor and the
distance from the camera to the object or the depth of the image is known using
this strategy.
The company PrimeSense contributed with Microsoft in a first Kinect for the Xbox
360. The technology as to find the depth of the image is technology implemented
in the PrimeSense sensors. However, this section focus on the most powerful
sensors manufactured by the company. (3)
There are at least three types of sensors which are popular and they have been
used to realize a series of projects. PrimeSense manufactured a long range sensor
along with a short range sensor. The long range sensor known as the carmine 1.08
is able to scan from a distance of 0.8 meters to 3.5 meters, and poses a resolution
of about 1.2 cm at 30 frames per second.
The short range sensor is called, Carmine 1.09. This sensor may be able to capture
objects from a distance of 0.35 meters to about 1.5 meters with an average depth
resolution of 0.5 cm. Mainly the software supporting these sensors is OpenNI SDK,
but Windows SDK for Kinect may also be used. (4)
The following table shows some of the advantages and disadvantages of the
PrimeSense Sensors (Table 3.2.a):
11
Pros
A more compact device
Cons
Lower drivers quality
Does not required power supply
only USB connection
Does not work with USB 3.0
The size of the sensor is small
Price out of budget
Lightweight sensor easy to
handle
Table 3.2.a: Pros and cons of Primesense sensors
The following table summarizes most of the specifications for the Carmine 1.08
and 1.09: (Table 3.2.b) (2)
Feature
Operating
Temperature
Data Interface
Field of
View(Horizontal,
Vertical,
Diagonal)
Data Format
Depth Image
Size
Dimensions
Maximal Power
Consumption
Maximal Frames
per Second Rate
Carmine 1.08
5 – 40
Carmine 1.09
10 – 40
Unit
°C
USB 2.0/3.0
57.5, 45, 69
USB 2.0/3.0
57.5, 45, 69
N/A
Degrees
16
640 x 480 (VGA)
16
640 x 480 (VGA)
Bit
Pixel x pixel
18 x 2.5 x 3.5
2.25
18 x 2.5 x 3.5
2.25
cm
Watt
60
60
N/A
Table 3.2.b: Carmine specifications
As the table displays the specifications, both of the sensors are similar in almost
every aspect.
3.2.2 Cubify Sense
Cubify sense is a 3D scanner with high portability, and light weight. This sensor
was developed to be a handheld device and friendly for daily base usage. The
device has a rectangular shape and in the middle there is a rectangular shaped
hole to allow the user to grab on to it while scanning.
The device has to be connected via USB to the computer, both USB 2.0 and 3.0
are supported, and it uses a special software to display the images and sent all the
data that is being collected while scanning.
12
The software which is called sense, compensate for all the gaps that the original
scan created due to a fast scan or a non-ideal distance from the object during
scanning process. Also, the software can tell the user if he/she is doing a scan too
far away or too close from the object. 3D sense was developed originally with
windows support only, however, 3D systems expanded platform support to
Macintosh recently. (6)
The following table display the technical specifications for the sensor: (Table 3.2.c)
(5)
Table 3.2.d weighs the pros and cons of the Cubify Sensor.
Feature
Specifications
Unit
Platform Supported
Windows 7(32 and 64
bit), Windows 8(32 and
64 bit), and Mac OS X
10.8 or later
5.08(W) x 7.08(H) x 1.3
(D)
0.35 – 3
2.25
N/A
Dimensions
Inches
Operating Range
Meters
Maximum Power
Watt
Consumption
Field of View
45, 57.5, 69
Degrees
(Horizontal, Vertical,
Diagonal)
Data Format
16
Bit
Operating Temperature
10 - 40
°C
Depth Image Size
240 x 320
Pixel x Pixel
Maximum Image
30
Frames per second
Throughput
Table 3.2.c: Technical specifications for Cubify Sense
Pros
Cons
High portability
High price for the budget
Multi-platform support
Table 3.2.d: Pros and cons of Cubify Sense.
3.2.3 Kinect Variations
In this section the different versions of the Kinect are analyzed and many features
are compared. The Kinect for windows and the Kinect for Xbox are similar in
hardware as well as the software support for applications. The hardware of both
devices are almost identical, Kinect for windows has a shorter USB cable which is
more reliable when used across multiple computers. Both of the devices work with
the same APIs, Kinect for Windows SDK, OpenKinect SDK, and OpenNI SDK. (7)
It is the Kinect for windows which offers a variety of extra features, which the Xbox
Kinect does not contain. The differences are a few but yet the user has to be aware
of the features not included with the Xbox Kinect. When it comes to choose the
13
right device the user should consider the functions his or her project is aiming to
accomplish, based on this an analysis should be made comparing the features
both of the Kinects contain, and finally the person should make his/her choice after
a thorough evaluation.
The differences between the Windows Kinect and the Xbox Kinect lied mainly in
the software aspect. As previously mention the Windows Kinect offers more
features, one of the features is the near mode, any object may be as close as 40
centimeters and the Kinect will allow this without compromising accuracy and small
degradation. In terms of skeletal tracking the windows Kinect is more powerful,
since it can detect the person’s head, neck, and arms while seating down or
standing. The options for camera settings are broader in the windows version.
The windows Kinect has a feature called Kinect fusion; this feature facilities the 3D
mapping of objects. The process to generate a 3D map involves the collection of
the depth of the images taken from different viewpoints. The camera pose is track
when the sensor is moved, later the tracking collected is used to relate the frames
and thus, generating the 3D model. (8)
In the aspect of price, the windows Kinect is a more expensive device, due mainly
to its commercial license. In other terms, if a developer wants to create his or her
own applications and sell them, they may do so, unlike the Xbox Kinect that does
not provides any license therefore, it cannot be used for commercial purposes. The
price for the windows Kinect is at $250 while the Xbox Kinect stands at about $70.
(7)
The Xbox Kinect should be considered for experimental and non-commercial
purposes. Most of the researchers when in a budget the best option is the Xbox
Kinect, which has most of the functionality as the Windows and at a lower price.
3.2.4 Lidar Sensors
Lidar is a method which uses a transmitter which sent out a laser pulse, then the
laser bounds off of the molecules and aerosols in the atmosphere and a receiver
would detect the laser pulse after bouncing off the molecules or whatever object
the laser has hit in its way. When the laser is captured back by the receiver the
range from the transmitter to the object can be calculated using the speed of light
the receiver would know how far and how long the pulse has traveled. (9)
Lidar technology has been used for many purposes, to scan the surface of the
earth and provide 3D maps for scientists to study, to collect information about the
atmosphere such as level of pollutions, or even the law enforcement to check the
speed of a car (Figure 3.2.a). (10)
The device which employs this method usually poses a laser, a scanner and a
GPS which main function is to receive the pulse in order to calculate the range.
14
A sensor which uses Lidar technology is the HDL-64E. This sensor has powerful
capabilities and thus, it has many uses, from autonomous navigation for vehicles,
and navigation for vessels to obstacle detection. This sensor would provide an
excessive power to the experimental autonomous robot described in this paper.
The performance of the robot would be exceptional but the concept of creating a
mapping robot at an inexpensive price would not apply anymore if the robot would
use this powerful sensor. (11)
The following table displays the specifications for the HDL-64E sensor (Table 3.2.e).
Specification
Value
Unit
Field of View
Field of View Update
Lasers/Detectors
Operating Temperature
Degree vertical Field of
View
Wavelength
Voltage
Weight
Dimensions
Spin Rate
360
5 – 15
64
-10 – 50
26.8
Degree
Hertz
N/A
°C
Degree
905
15 +- 1.5 at 4 amps
29
10 Height 8 Radius
300 – 900
nm
Volt
lbs.
Inches
Rotations per Minute
Table 3.2.e: HDL- 64E sensors
The table displays the different specifications for the sensor. It is heavy and outside
the size range for the platform of the robot this experiment intend to use. (11)
Figure 3.2.a: The image shows the point cloud of the surroundings generated by
the HDL-64E S2. (Reproduced with the permission by velodyne.com)
15
3.2.5 Stereo Camera
The camera is designed with two lenses in order to provide a human-like way to
capture its surroundings also known as a binocular view. It has many uses due to
the different features it poses.
It identifies every segment of a scene from different cameras, after all the different
views are collected, by a process called triangulation which consists of determining
the location of a point in a 3 dimensional space from other points given the angles
they make to the specific point. (12)
Pros (13)
Cons (13)
Easy integration with other machines
It needs calibration before use
Fast process of collected data to 3D
Data is ambient light sensitive
images
Relatively low price
The accuracy of the distance is not exact
No lasers or projectors required
Full field of view from a single image
Table 3.2.f: Pros and cons of a stereo camera
3.2.6 Ultrasonic Sensor
Ultrasonic sensor mainly use is to measure distances from moving or stationary
objects, they are suitable for this type of measurements since the method
employed is based on a sound wave rather than light as most of the sensors work.
Since the sensor has a relative low price, it is employed for many tasks.
Some of the most typical applications for the ultrasonic sensors are:




Robot Navigation
Security Systems
Monitoring Levels of liquids
Parking Assistance Systems
This sensor sends a pulse also known as an ultrasonic burst and then it receives
the pulse again, based on the time it took to the pulse to return the distance can
be measured. In order to make use of the different features this sensor poses, a
microcontroller should be used. The interfacing part is relatively easy since the
communication between the sensor and microcontroller is through a single I/O pin.
Table 3.2.g details the specifications of the sensor. (14)
Feature
Value
Unit
Range
Power Requirements
Operating Temperature
Dimensions
Communication
0.083 to 10
5 at 35mA
0 – 70
0.81 x 1.8 x 0.6
Positive Transistor –
transistor pulse
Feet
VDC
°C
Inches
N/A
Table 3.2.g: Ultrasonic sensor specifications
16
3.2.7 IR sensors
IR technology is widely used in a variety of wireless devices, this method is mostly
used in sensing. In the electromagnetic spectrum IR lights are at the top of
microwaves with higher frequencies and below visible light.
IR sensors are listeners of IR light, which is invisible to the naked eye. These
sensors are most commonly used in TVs and DVDs, since they have to sense the
IR signal from the controller which contains the emitter.
These small sensors are used for a variety of applications such as: (17)




Security – Movement, Fire Alarms, etc.
Computers – Mouse and keyboards.
TVs, DVDs – Remote control.
Industrial – Measurement, motor encoders.
The following table (3.2.h) displays the different specifications based on the
TSOP38238 sensor manufactured by Vishay semiconductors: (16) (15) (18)
Feature
Value
Unit
Sensitivity Range
800 – 1100
Operating Power
3–5
Frequency Range
35k – 41k
Dimensions
5.20 L x 6.98 W x 7.96 H
Weight
0.43
Operating Temperature
-25 to 85
Range
Power Consumption
0.010
Nanometer
Volt
Hertz
Millimeters
Grams
°C
Watt
Table 3.2.h: Specifications of TSOP38238. (19)
Pros
Cons
Low cost
Popular in use
Prone to miss small objects
If fixed straight ahead sensors may
miss objects not in the way
Lightweight, small size
Table 3.2.i: Pros and cons of TSOP38238
3.2.8 Sensors Comparison (14 -1)
The following table compares the sensors being discussed in the previous
sessions with the exception of IR sensor since the PrimeSense carmine 1.08 and
the Xbox Kinect are equipped with IR sensors.
Sensors
Prime
Sense
Cubify
Sense
Xbox
360
Kinect
Lidar
Stereo
Camera
Ultra
sonic
17
Field of
View
57.5° H,
45° V,
69° D
640 x
480
USB 2.0
/ 3.0
45° H,
57.5° V,
69° D
240 x 320
43° V,
57° H
360°
40° H
40° H
N/A
752 x
480
FireWire
1394a
N/A
USB 2.0
640 x
480
USB 2.0
Size
18 W x
2.5 H x
3.5D cm
12.9 W x
17.8H x
3.3 D cm
7.2W
x12H x
11.5D in
10H x
8r in
47.4W x
36 H x
157D
Weight
0.5lbs
Not
Available
3lbs
29lbs
342g
22H x
46W x
16 D
mm
9g
Range
0.8 –
3.5 m
0.35 – 3
m
2m
Not
available
2cm –
3m
Platform
Support
Mac OS
x,
Window
s, Linux,
Win 7(32
bit or 64
bit) Win 8
(32bit or
64 bit)
Windows
XP
service
pack 1
N/A
Price
$294.99
$399.00
$1895
$29.99
Resolutio
n
Data
Interface
RS232
50m on
paveme
nt
120m
for cars
Win7,
Linux,
Win 8,
Win,
Win
Mac
Embedd
OS x,
ed 7 or 8 Android
, IOS
$99.99 $75000
1 I/O
pin
The previous table compares the different technical specifications for every sensor.
Some of these sensors such as the ultrasonic sensor does not provide any imaging
data. Likewise, in the platform support section of the table is not specified any
operating system since the compatibility is based on what type of microcontroller
is interfaced with. The ultrasonic sensor solely purpose is to send information to a
microcontroller about the time it took for the sound wave to return to the receiver.
In the table the PING ultrasonic distance sensor is used as a reference. For the
PrimeSense sensor the carmine 1.08 which is the long range sensor version of the
carmine models was used for information purposes. The lidar sensor used for
comparison was the HDL-64E S2 which uses lidar technology, it is a very robust
sensor with many powerful features as described in section 3.2.4. The bumblebee2
stereo camera was used as a reference for the stereo camera section. After a
thorough analysis and comparison of the sensors, a decision was made according
to the requirements of the project and the budget.
18
The final choice for a depth sensor was the Xbox Kinect; this device provides the
required features to realize an autonomous robot and generate a 3D map for
display purposes.
Some of the sensors prices displayed are based on unofficial websites rather than
the official website of the manufacturer, such is the case of the PrimeSense
Carmine 1.08. Since the company was acquired by another company the website
stop selling any products, in this case the reference for the price was taken from
amazon.
A similar case happen when researching for the prices of the PING ultrasonic
sensor and the HDL 64E S2. Both of the sensors did not have their respective
prices under their official sites, and the reference for their prices were gathered
from unofficial sites selling the devices.
3.3. 3D Scanning Libraries
The different libraries created by communities of developers, or specific groups of
developers are designed with the purpose of facilitating the usage of software and
to provide the necessary tools to realize multiple applications.
With the rapid changes in technology and the new challenges that arise with them,
developers tend to think ahead of time when it comes to work on complex
technologies. To facilitate the process of developing and compiling new
discoveries of methods to realize a function on any specific language, the
communities of developers have created libraries which provides the tools
necessary to process, modify, contribute or create projects.
Software languages contained multiple packages, each of these packages are
made up of methods to realize the different applications the user desire to develop.
For instance, in the case of java the library provided by oracle is designed for many
applications to run on any platform regardless of the operating system.
3.3.1 Point Cloud Library
Point cloud library is an open source, large scale project which aims at providing
the tools for point could processing and modify 2D and 3D images.
This library is suited for commercial and experimental purposes. It contains many
modules which makes the library extensive. To ease the management of the library
the different modules are used and deployed instead of deploying every module.
(20)
Some of the features the library provides for developing purposes are surface
reconstruction, model fitting and segmentation, feature estimation, filtering of data
among other methods.
Our project aims to employ the data generated by the Xbox Kinect, namely the
point clouds generated from the surroundings, the data generated as the robot
19
navigate through a given environment is raw data. This raw data is distorted by
many factors such as ambient light, distance, or how fast the scan was performed
are just a few factors that may corrupt the data. In order to process and redefine
the raw data, the usage of the libraries are essential.
The point cloud library was developed to be highly portable, and it is composed of
modules. Each module aims to provide the tools for a specific task to manipulate
the raw data. The modularity of the point cloud library brings benefits for platforms
with limited resources, since the platforms would only use the modules need it for
the task at hand.
Another advantage to use the point cloud library the hassle-free if working on
different platforms. The library has been used in platforms such as Linux, MacOS,
Windows, and mobile platforms as Android and iOS.
The following modules are the most popular in used:








Pcl_filters: This module helps to filter out undesired points in the cloud which
may distort the data and complicated the process of developing anything
from it.
Pcl_io: The I/O module is clearly essential to work with any sensors. In this
project we are working with the Kinect and this module would ease the task
of reading and writing the data generated.
Pcl_keypoints: The keypoints in the data allows for representing the original
data when used with other features. We are considering the use of this
module in case of some data being lost in the transferring process from the
sensor to the microcontroller.
Pcl_features: Basically the module contains data structures which
constructs patterns based on the points close to a specific one.
Pcl_kdtree: The module facilitates the searches of the nearest neighbors
points from a specific point, we must use this module since is vital in the
processing of point cloud data.
Pcl_octree: Allows the user to create hierarchical trees from the data. These
trees speed up the process of searching for the closest points which is an
important part of the processing. Some function such as serialization and
deserialization of the data allows the encoding of the trees into binary data.
We may consider to use this module for speeding up the process of
formatting the data.
Pcl_segmentation: This powerful module is used when the point cloud data
has many isolated parts, it is then taken by segments and process
independently. The group may use this module depending on the raw data
generated by the Kinect. After some testing the decision of whether to use
this or not can be made.
pcl_sample_consensus: This module facilitates the recognition of certain
objects which has common geometric shapes such as planes, cylinders,
20



etc. We may use this module if the processing times of the point cloud are
improved since the recognition of objects is faster. But the real benefit would
be obvious in the testing part.
Pcl_recognition: The library contains this module for object recognition, this
module differ from the sample consensus in the way it recognizes objects.
By the use of different algorithms the goal is achieved rather than comparing
the data with common geometrical shapes.
Pcl_surface: It allows the reconstruction of the point cloud if the data is
noisy. This library becomes useful especially when there are various scans
made on the same area or object and matching of points are needed to
modify the data and make it clear.
Pcl_visualization: The main goal of this module is to generate a fast
prototype and visualize the results of the algorithms. It has many features
to modify the raw data. We are going to use this module in the early stages
of the testing since the prototypes of the data are needed to estimate how
the point cloud is going to be displayed, and if the results are satisfactory.
Figure 3.6: In the figure the pci_filter module is applied to left image(raw
data) and the result is the image on the right.
The graph shows the distribution of the points in the images
(Permission Pending)
3.3.2 3D Display and Development Library
In this section two of the development libraries are discussed, the libfreenect is an
open source project where many developers cooperate to expand and add
functionality
21
3.3.2.1 Libfreenect
This library is currently being developed by a community of people by the name of
OpenKinect, which aims at facilitating the use of the Xbox Kinect in different
platforms namely, Windows, Linux, and Macintosh. (21)
The library is an open project as the point cloud library, but this library has a
specific interest in employing the Xbox Kinect for many purposes other than
gaming. Open libraries such as this one can be modify by the community, this
community of developers are welcoming new developers who want to join to
expand the library for the benefit of not only the developers community but also for
the researchers who may want to implement the Xbox Kinect for useful functions.
In our case we would explore the various classes and functions provided by this
library to realize an autonomous robot using the Kinect as our main sensor to
gather data about the surroundings.
Libfreenect contain all the necessary software for the initialization and
communication with the Xbox Kinect, this library also contain an API which works
in Windows, Linux, or OS X. Some of the languages supported as of now is C,
C++, .NET, Java, Python are the most popular. Since the OpenKinect community
is focusing on this library, as others developers become interested in working with
other languages they are going to be available in the library. The API in the near
future is going to support more applications to expand the functionality of this
software.
3.3.2.2 Kinect SDK 1.8
The Kinect SDK provides the necessary APIs to develop applications on the Xbox
or windows platform. Microsoft developers designed the SDK with the windows
Kinect in mind but since the Xbox Kinect has a similar hardware then development
and testing can be made in the Xbox platform but those applications are not
allowed to be used as commercial applications. The group sees this as an
advantage since we do not have to spend the money required to buy the windows
platform which is expensive if we consider to stay in budget and our usage for the
Kinect is strictly experimental. The difference in the price is mainly due to the
license the windows Kinect poses for commercial applications.
The SDK allows the developers to realize robust applications such as the
recognition and tracking of people by employing the skeletal view the sensor
provides, find the source of audio by implementing noise and echo cancellation,
develop voice commands applications using speech recognition, or determining
the distance of an object using the depth data are just some of the applications
capable of running in the Kinect.
The following is a brief list of the contents included with the download of the
windows SDK 1.8


The development kit comes with drivers and instructions to help the
developers in the realization of applications. (23)
Documentation for the programming of managed code, that is, code
executing under the control of the common language runtime, and the
22

programming of unmanaged code which is code executing outside the
control of the CLR. (24)
Samples showing how to work with the SDK properly. (23)
3.3.3 Image Processing Library
3.3.3.1 OpenCV
OpenCV is a library which aims at providing the tools necessary to work in the field
of computer vision. Essentially this library supports the same operating systems
than the point cloud library. It is cross platform and supports Windows, Linux, Mac
OS X, iSO, and Android. The languages supported are C, C++, Java, and Python.
Our project main goal is to use the raw data generated by the Xbox Kinect and
process the point clouds to redefined them and make them useful for navigational
purposes. Another function we would like to realize is the image display of the map
in real time, for the display purposes OpenCV is the library we are considering to
use, since most of the modules alleviate the time for image processing. We are
still discussing about the image processing. At this stage of our project the most
important part is to focus on gathering the data necessary to generate the point
clouds and make this data available for navigational purposes.
3.4. Robot Platform
3.4.1 J-Bot v2.0
The J-Bot v2.0 is a four wheel drive, two tier rover robot. Each tire on the J-Bot is
driven by four 3-12VDC high quality micro-speed motors. The dimensions of the
J-Bot are 200mm x 170mm x 105mm. The base is a hollow case to house the four
motors and a five-battery holder. The tiers are separated by spacers to allow space
for batteries, micro-controllers, boards, etc. The height of the second tier can be
customized by adding extenders to the spacers. Both tiers have holes of different
size and shape to fasten attachments on to the plates as needed. The J-Bot v2.0
speed is listed as 90 cm/s, to put this in value in a better unit the J-Bot reaches
speeds of 2.95 ft/s. This is a great speed compared to the other platforms
considered for the project. (25)
The J-Bot v2.0 was chosen for this project because of its basic design that met all
of our requirements for the rover. The requirements were that the robot rover
should have a basic chassis design as to not over complicate the motor control.
Also, having a basic design usually translates to a cheaper price for the robot.
Price is important because as the title of the project suggests the rover should be
‘inexpensive’. The next requirement is that the robot should be big enough to allow
space for everything needed to be put on the rover, most importantly the Microsoft
Kinect. The Microsoft Kinect is most important because, not only is it what we will
use to create a point cloud, but it will be the largest device on the robot rover. The
Kinect is about 11 inches at its widest point which is the top piece, but the base is
about 4 inches wide. It was decided that the chosen platform should be
customizable, not just with space, but with parts as well. This will allow us to test
different vantage points for the Kinect to see which works best. Also, the motors
can be changed for other motors if more power is required. Another factor that
23
worked in the J-Bot’s favor is the size and material of the wheels. The wheels are
about 1.5 inches wide and the plastic rim is wrapped by a rubber tire. These are
way better than the Geekbot’s wheels.(25)
3.4.2 RobotGeek Geekbot Bare Bones Kit
The RobotGeek Geekbot is a two-wheeled, two tier robot. Each wheel on the
Geekbot is powered by 6V RG-4C continuous turn servo motors. The dimensions
of the Geekbot are 220mm x 190mm x 100mm. The body of the Geekbot is made
up of two tiers separated by pillar-like spacers similar to the ones on the J-Bot. The
height of the second tier can be changed by adding extenders to the pillars. The
tiers are made of plexiglass. Similar to the J-Bot, the tiers have holes all over to
accommodate the addition of attachments. Although unlike the J-Bot, the holes are
only circular and organized in rows and columns across the plexiglass. (1cm x
1cm) The Geekbot speed is listed at 1.3 ft/s, significantly slower than the J-Bot.(26)
The RobotGeek Geekbot met most of the robot rover requirements set for this
project. Its simple design was desirable. The Geekbot’s simple design translated
to its price which, for the project, was an important factor in the decision making.
The Geekbot is also customizable another great quality and something required
for this project. In fact, the Geekbot’s selling point is its modularity and how easy it
is to customize. With an array of sensors, turrets, arms, guns, and controllers the
Geekbot is easily the most customizable platform of the bunch. The reasons the
Geekbot was not chosen was because of it two-wheeled chassis design, speed
included motors produce, and the material and design of the wheels. The twowheeled did not look as dependable and sturdy as a traditional four-wheeled
chassis design. The speed the motors included with the Geekbot kit left much to
be desired. With a greater top speed the luxury of choice is created. Some
situations, like tight spaces or turns, may call for a lower speed. Higher speeds
may be useful in areas with ample room or on straightaways that have no obstacles
to avoid. Lastly, the wheels seems to be made out of the same material the decks
are which make me question its gripping ability on slicker surfaces like laminate
flooring, linoleum, or certain carpets. Also, the width of the wheels is about a
quarter inch. Comparing the width of the Geekbot’s wheels to those of the J-Bot,
the Geekbot’s wheels are about 4-5 times thinner. (26)
3.4.3 Lynxmotion Tri-track Chassis Kit
The Lynxmotion Tri-Track chassis kit is a tank rover with two triangular tracks on
each end. The dimensions of the Tri-Track are 280mm x 25.5mm x 120mm, but
this is not very representative because the tracks take up a considerable amount
of space of the overall dimensions. The dimensions of the base (usable space on
the Tri-Track) are 130mm x 180 mm x 120 mm. The Tri-Track body is made lasercut Lexan structural components, and custom aluminum brackets. This robot rover
has excellent traction made possible by using heavy duty polypropylene, rubber
tracks, and durable ABS molded sprockets. The motors included with the Tri-Track
are two 12VDC gear head motors. Unlike the previous two platforms, the Tri-Track
is two tiered but the height of the second tier cannot be changed. The body is
hollow, most this space is used to house the wiring for the motors and the
Sabertooth motor controller. There are extra holes on the Tri-Track plates available
24
to use for customization purposes. The price of the Lynxmotion is the highest of all
three platforms being compared. This is probably due to the complex design of the
tracks and the materials used for the rover (aluminum, rubber, and polypropylene).
(27)
The Lynxmotion Tri-Track was not chosen as the platform for this project because
it did not meet all the requirements needed and the ones it did meet were not
satisfactory. The design of the tracks were too complex. If a piece of the track were
to break it would not be replaced as easily (or at all) as the J-Bot’s. Figure 3-1 and
Figure 3-2 show the track of Tri-Track mid-assembly, so one can gain an
understanding of the complexity of the design. The price of the Tri-Track is not
exactly what you would call inexpensive. The rover did not allow much room for
customization, the tiers could not be elevated if needed, this is important because
during prototyping and assembly things may need to be moved around, added on,
and removed to adjust to the situation. Customizability is also reduced due to the
lack of holes on the tiers. Although the overall size for the Tri-Track was within the
range we were looking for the usable space (base) was too small. (27)
Figure 3-4.a: Lynxmotion Tri-Track chassis assembly (Permission pending)(28)
Figure 3.4.b: Lynxmotion Tri-Track track piece (Permission pending)(29)
25
3.5. Motors
3.5.1. Hobby motor
Hobby motors are usually used in small vehicles and robots. Hobby motors can be
used to drive the propeller of a boat, the wheels on a car, the blades on a
helicopter, a fan. Hobby motor is a very general term that can encompass many
different kinds of motors with different power outputs. A better term for these would
be brushed DC motor and brushless DC motor. Brushed DC motors are an
internally communicated electric motor designed to be run from a direct current
source. Brushed DC motors have been around for a very long time now and were
used in many places in industry. A few places and uses that still utilize brushed
DC motors are electrical propulsion, paper machines, cranes, and steel rolling
mills. (30) (31)
Brushless DC motors are synchronous motor powered by an integrated switching
power supply. These motors have replaced many brushed DC motors in many
applications, but not all. The main reason for this is that brushed DC motor brushes
wear down and must be replaced. Brushless DC motors have been widely used in
hard-disks, CD/DVD drives, radio controlled cars, cordless power tools, and
cooling fans in electronic devices. To put this motors efficiency into perspective in
a radio controlled car a brushless DC motor out performs nitro and gasoline
powered engines. A small brushless DC motor can produce twice as much torque
and about 4 times more horsepower than these engines. (30) (31)
Neither brushed DC motors nor brushless DC motors were used in this project.
Two main reasons made these motors inconvenient to use. Firstly, the shaft that
spins on these motor is a cylinder with no grooves. This makes attaching things
like wheels a challenge. Some kind of adhesive or epoxy may be used but it may
come loose with heavy use. This is definitely a problem because the robot rover
should work every single time it is used and require a little maintenance as
possible. Lastly, the spinning shaft on these motor is in-line with the motor making
mounting a problem if there are no holes to fasten the motor with a screw.
3.5.2. Gearhead motor
A gearhead motor is a DC motor that utilizes gears to produce more torque. These
motors also come in different sizes, shapes, and output capabilities. This kind of
motor is the kind that came with the J-Bot kit. One factor in choosing the J-Bot over
other platforms were these motors. They are powerful and they are also
ergonomic. These motors produced the greatest speed of the platforms
considered. These motors are ergonomic because they are L-shaped which is
convenient because space is a limited, precious resource. This L-shape is more
formally known as a motor with a 90 degree shaft. The best thing about these kinds
of motors is the shape of the tip of their shafts. The shafts are cylindrical in shape
but taper toward the tip ending in a half cylinder shape. This conveniently allows
for part like wheels with the same shape to be attached with no worries about the
shaft slipping in the slot or adhesive breaking off. Figure 3-4 is an image of the
geared motor that comes in the J-Bot kit. (34)
26
Figure 3-4: gearhead motor included in J-Bot Kit (Permission Pending) (32)
3.5.3. Voltage range
The voltage range of a motor is the range of voltages that will make the motor run
well. Motors also have a nominal voltage which makes the motor run at the highest
efficiency. Operating a motor outside of it voltage range you will run the risk of
burning out the motor if you apply too much voltage, or if you apply too little voltage
the motor will not turn due to low torque and it will also burn out. Robot motors
usually work around 3, 6, 9, 12, and 24 volts because batteries are usually used
to power robots, and these values can be attained with batteries. (33) (35) (36)
(37)
The motors that come with the J-Bot have a voltage range of 3V – 12V. The
specifications sheet give values for speed, current, torque, and stall current for
motors operating at 3V and 6V. These are probably the voltages the manufacturer
expects these motors to be used. Testing will be required to see how much voltage
is most appropriate for locomotion. This will depend on the overall load the rover
has to carry. Minimizing the load on these motors will be a priority. Alternatively,
changing the motors with stronger motors is also an option. This would most likely
require a different battery because the voltage range may be different with new
motors. (33) (35) (36) (37)
3.5.4. Motor control
Motor control is an important factor in directing where the robot moves. If you just
apply a voltage source to the motors, the motors will move forward indiscriminately.
This is not acceptable, the robot should be able to move forward, backwards, turn
left and turn right. Achieving this would be very difficult without a motor controller.
(38)(40)
Motor controllers control voltage and current supplied to motors. It is simple to
make a motor move forward, but everything else isn’t so simple. To move
27
backwards you need to reverse the flow of the current through the motor. This
would be a simple task if you wanted to do it manually with a switch but since this
robot requires automation this cannot be used. What can be used is an H-bridge.
An H-bridge is a circuit that contains 4 MOSFETS with the load (in this case the
motor) connected in the middle. By opening or closing the correct you can make
the motor move forwards or backwards. By turning on A’ and A you will connect
the left lead of the motor to the power supply and the right lead to ground this will
make the motor turn forward. Conversely, if you turn on B’ and B the left lead of
the motor will be connected to the power supply and the right lead will be
connected to ground. Caution must be exercised when using an H-Bridge because
if A’ and B or B’ and A are opened then you will create a low-resistance path
between the power source and the ground. This is effectively making a short-circuit
between the two and you can fry the H-Bridge or something else in your circuit.
(38)(40)
H-Bridges can be bought as integrated circuits from different companies. The one
being used in this project is the L293. The L293, manufactured by Texas
Instruments, is a quadruple H-Bridge. The L293 works with a voltage range of 4.5V
– 36V which is perfect because this range covers the range of the motors on the
J-Bot and will probably cover the range of other motors we might have to use.
(38)(40)
Figure 3-5: Typical H-Bridge design (Permission Pending) (39)
28
Turning is also a concern because it’s not as straight forward as it may seem. With
the J-Bot there is to steering wheel or even the capability to turn the wheels. This
limits you to turning by making the wheels on one side run slower than the ones
on the opposite side. To turn right the wheels on the right side have to turn slower
than the ones on the right. To turn left the wheels on the left have to run slower
than the ones on the right. The greater the difference between the two sides the
sharper the turn. (38)(40)
All these things must be considered when choosing a motor controller and any ICs
that one may want to implement on the board. Also choosing the right
microcontroller for the job is important. One factor in choosing a microcontroller is
making sure you are familiar with the language. Many different architectures exist
all with their own syntax and ways of doing things. Choosing a microcontroller that
can get the job done and you are comfortable with can make coding instruction for
the motors easier. (38)(40)
3.5.5. Load capacity
Load capacity or max load is the maximum weight the motors can carry. This is an
important factor because you need to be careful when adding things to the robot.
Weight should be minimized, you do not want to over work the motors. A
requirement of the robot platform used was customizability. This is important here
because if it is not known how much load the robot will carry then being able to
exchange the motors for more powerful ones is imperative. (33) (35) (36) (37)
3.5.6. Torque
Torque is defined as the tendency for an object to rotate around a pivot, axis, or
fulcrum. A good way to understand torque is the rotational force around a point.
For example the torque of a wheel around the axel of a car. Torque is usually
measured with a unit of force being multiplied by a unit of length. Classically torque
is measured with the Newton-meter (N • m). A good way to picture this is: if you
have 1 N • m on a plank rotating around a point and you apply 1 N of force in the
opposite direction of rotation 1 m away from the point of rotation the plank would
hold up the object applying the force.
If a motor cannot put out sufficient torque it will fail to move the load on it. This is
why finding the right motor for the robot rover and minimizing the load on it is
important. The motors on the J-Bot put out 1.92 kg-cm each. (33) (35) (36) (37)
3.6. Locomotion sensor
In order to properly utilize the waypoint algorithms, we will need to know the
position of our robot at all times. We would also need to know whether the robot
has reached the waypoint or not. The direction in which it should travel should also
be determined which would require knowledge of the current heading of the robot.
In addition, it is necessary to have a redundant system in place to let us know
29
whether the wheels have rotated the proper number of times in order to reach the
waypoint or not. For each of these conditions we need separate modules that can
provide the necessary data. Ideally we wish to receive these unique pieces data
simultaneously in order reduce unnecessary latencies due to receiving and
processing.
3.6.1 Motor Encoder
In order to make the robot move we will need an electric motor. The motor itself is
a simple electrical machine with a discrete nature. If powered on, the motor will
spin. If there is no power it, it will stop. Of course, the rate at which the motor shaft
rotates is variable in nature and directly related to current supplied to it. The
duration in which it rotates is also variable and dependent on mechanism that
applies current to the motor. In order to control these two variables: duration or
rotation (time) and speed at which the shaft/wheel rotates (velocity) we would need
to utilize a Motor Encoder. The motor encoder will help us verify whether the
motors have spun the right number of times with in the right number of seconds or
not. This also yields to us two important piece of information. It gives us the
velocity. By knowing the rate at which the wheels are turning and knowing the
wheels circumference, we can determine the velocity of the robot. This is very
much similar to an automobile’s speedometer. This velocity then provides us with
the current traveled distance once we factor in the time. With both the current
traveled distance and the desired distance, we can determine in real time the
current position of the robot. Normally to get feedback from motor we would need
rotor sensors. These rotor sensors would provide relevant data to determine the
angular velocity of the motor. We would also need to have detailed information of
the electrical makeup of the motor. The added hardware would make the design
more bulky and more costly. This affects development time since it would require
extra code to be developed that can receive and understand the data as well as
react appropriately which if coupled with the amount testing required to get
rudimentary data about rotation speeds under different loads would drastically
increase development time. The powering of such a system would also require a
larger power source. It would be more cost effective if the system intelligently
determined all the necessary and understood it. In order to handle these many
different functions the use of a robust software package would be ideal. One such
software package is the InstaSpin-FOC and FAST that TI provides with its
PICCOLO motor controller MCU. (41) (42)
InstaSPIN-FOC (FOC = Field Orientated motor Control) is capable of identifying
major details about a motor within minutes. The software responsible for it is the
FAST technology. The acronym FAST is derived from the four key pieces of
information needed for effective motor control. Flux, flux Angle, motor shaft Speed,
and Torque. FAST is available in the ROM and provides the necessary data realtime by taking in various inputs from the motor. Thereby allowing function calls that
utilize this information to make real-time decisions. Below is pictorial diagram of
the FAST architecture and InstaSpin-FOC architecture respectively: (41) (42)
30
Figure 3.6.1.A: FAST Software Architecture (reprinted with Texas Instruments
Permission)(43)
Along with FAST, InstaSpin-MOTION, which utilizes both the SpinTAC Motion
Control Suite and FAST estimator both of which are embedded in ROM, helps in
controlling how the user wants their motor to spin. It also provides accurate speed
and position control. Accuracy of speed and position of great importance since this
robot will be implementing waypoint calculations for navigation purpose. In order
for the velocity and position values to be accurately determined, SpinTAC utilizes
four components: Identify Control, Move, and Plan. Identify focuses on estimating
the inertia (an Objects resistance to rotational acceleration around its axis). This is
important because when they load increases the amount torque increases as well.
Since FAST is able to control torque we are able to increase the torque when
necessary to achieve a desired velocity. However since there is always a
possibility that other forces can affect the velocity besides load, such as friction
(slipping), SpinTAC Control component is capable of proactively estimating and
compensating of such disturbances in real-time. Compared to PI controllers,
SpinTAC Control is better at handling and/or rejecting any disturbance to system
that may affect the motor, it is also has better performance in trajectory tracking.
The user can specify the reactivity of this system. SpinTAC Move component is
capable of computing the fastest route between two points by finding the
smoothest transitions between speeds. It allows the user to input starting
velocities/positions, ending velocities/positions, acceleration, and jerk (change in
acceleration).
31
Figure 3.6.1.B: InstaSpin-FOC Software Architecture Overview (reprinted with
permission from Texas Instruments)(44)
Since there is always a possibility for a system to make sharp movements between
two points this will cause the change in acceleration to be high which then causes
mechanical strain on the motor. To control this we can set our jerk to be infinite (as
is with jerk being any value), bounded (jerk cannot exceed or fall below set values
[discrete in nature] but still is judder-ish) or continuous (allows jerk to change but
gradually reducing the judder and controlling the jerk). Thankfully, TI has its own
proprietary curve the st-curve that sets the position, velocity, and acceleration to
be smooth and the jerk to be continuous. Below is a diagram of the different
available curves: (41) (42)
Figure 3.6.1.C Curves Available in SpinTAC Move (reprinted with permission
from Texas Instruments)(45)
SpinTAC also allows for pre-planning of how the system should behave i.e. state
diagrams. SpinTAC Plan component allows for easy to build state diagrams to
32
describe how the system should behave. This reduces development type by
increasing abstraction. In our case, we will not need this since this type of
predefined behaviors is not applicable. Below is a diagram of the InstaSpinMOTION:
Figure 3.6.1.D InstaSpin-MOTION Software Overview (reprinted with permission
from Texas Instruments)(46)
However, due to the complexity of the pin assignment of the selected MCU’s that
have either InstaSpin-FOC or InstaSpin-MOTION and cost of the MCU’s, it would
be more efficient to build our own encoder with a microprocessor that is simple
and already understood. The type of encoder of choice is an optical encoder. For
under 2 dollars, these can be designed and put together.
The optical encoder consists of a LED, a light detector, clear wheel with ticks, and
a motor. The basic idea is whenever the light detector notices that the tick mark is
blocking the light then it will produce a voltage that the microprocessor will
determine to be active high, since voltage will be the highest at that time. When
the light is not blocked then the voltage that is produced is at its lowest so the
microprocessor will translate the signal to be active low. Since the number of ticks
and circumference of the wheel are known ahead of time, the displacement per
tick can be determined. Moreover, if we set a timer than we will have both the
displacement and time frame which would allow us to determine the velocity.
Depending on how the desired distance is represented, with either a velocity and
time or a displacement, we can make sure the robot reach its destination. Below
is picture of the completed encoder: (41) (42)
33
Figure 3.6.1.E Encoder IR Detector and Encoder Wheel (Permission
Pending)(47)
3.6.2 Accelerometer
Although one of the above motor encoder is robust enough to handle disturbance
in real-time it is necessary to consider the fact that all calculation by processors
are done with binary computation which, when converted to base ten, has some
marginal error. To ensure proper arrival to the waypoint, we will need a redundant
system to handle this marginal error. The accelerometer is one such system. The
accelerometer provides the acceleration of an object. This is essential in
determining whether an object has covered a specified distance. The robot will
determine waypoints for it to arrive at. These waypoint calculations provide the
desired distance for the robot to travel. Considering the fact that all movements of
the robot will be linear in nature, we would be able to determine whether an object
has covered distance by considering the number of seconds that has passed
during the duration of the movement. The Microcontroller will keep a “traversed
distance” variable that will checked with the desired distance. The distance
calculated using the following formula: (48-54)
𝑡𝑓
𝑡𝑓
𝑠 = ∫ ∫ (𝑎)𝑑𝑡
𝑡𝑖
𝑡𝑖
Where “s” is the displacement and “a” is the acceleration. We can use the double
integration method to determine displacement. The problem with it is that overtime
the error increases and generally does not give the accuracy needed. The reason
for this is that the accelerometer has noise. This noise has a non-zero mean that
is that when averaged over a specific interval it does not yield to a zero value. This
unnecessary noise adds to the true acceleration to yield an inaccurate acceleration
that will be integrated not once but twice over a time interval. This type of process
is known as Dead Reckoning. The particular error is known as sensor drift. If the
interval is small enough then the error is not large enough to cause a problem. As
integration is the area under a curve or the sum of small rectangular areas under
34
a curve. We can see how this would be detrimental to the true accuracy of the
result. Therefore, even if the first integration (Velocity) is relatively accurate the
second integration (Position) will be very inaccurate. To handle this we would need
a digital filter that would filter out the nonzero noise. In addition, we need to keep
a working distance to check against the target distance. In order to obtain the
current working distance, we take the integration of the current acceleration from
zero to the moment of acceleration sampling, for each time we sample. We would
make sure that there is no real discernable delay in motion so we must tune the
speed and acceleration sampling. The Accelerometer of choice is the on in Ti’s
SensorHub BoosterPack that will work in conjunction with the Ti’s Tiva™ C Series
TM4C LaunchPad. This board has a 9 axis MEMS motion tracking device
InvenSense MPU9150 9-Axis Motion Sensor (from here on out will be known as
MPU9150) with three types of sensors. The first is the 3-axis gyro sensor. Since it
does not pertain to our project, it will not be discussed in detail. The 3-axis
accelerometer, which is the focus of this section, and the 3-axis Compass, which
will be explained in detail in the following section. (48-54)
The MPU9150 provides a digital output for accelerometers in the X, Y, and Z-axis.
These digital outputs are produced in the flowing manner. Inside the MPU9150’s
there is a unique system called micro-electro-mechanical system (MEMS). For
each of the three axis a MEMS have the flowing design. MEMS devices consists
of a proof mass with a cantilever, each with its own capacitance. When
acceleration occurs the capacitance between the two objects (proof mass and
cantilever) changes producing a voltage. These series of voltages will be
converted from analog to digital using an ADC. The digital signal-conditioning unit
will then convert the digital value. It will then convert this value to an appropriate
digital value that can be stored into the dedicated sensor register and read through
the I2C by the host processor. MPU will then make discussions about motor control
from integration.
These different axes are digitized by Analog-to-digital converters (ADC) and are
then transmitted for use by the MPU9150’s Inter-Integrated-Circuit’s (I2C)
interfaces. The MPU9150 is a System in Chip (SiP) that is made up of an
MPU6050, which actually contains the 3-axis accelerometer in it, and the Digital
Motion Processor (DMP), which is capable of computing the complex algorithms
of MotionFusion. The MPU9150 will then interface with the Application processor,
which is an ARM –based processor of the Tiva-C series. As shown below: (48-54)
Additionally this data can then be interface to a computer form the Tiva-C any
motion related application could utilize it. The a-fore mentioned InvenSense’s
MotionFusion™ combines all of the data from the three sensors into a single bit
stream. MPU9150 I2C interface is primarily used to communicate this information
to the ARM processor of the TIVA-C series. The MPU9150 Bus connection with
the ARM processor is always slave. Meaning, it can only be used by the ARM
processor and nothing else. (48-54)
35
Figure 3.6.2.A MPU-9150 Interfacing
3.6.3 Magnetometer
The current direction of the robot is necessary in waypoint calculation. Since the
robot must be able to take in account that there may be curved obstacle that it
must traverse through, it is not guaranteed that the waypoint will be in the current
direction of the robot. In order for the robot to calibrate and position itself, so that
it turns to that direction, we will need the magnetometer to tell us whether we turn
right or left. In addition, the duration of the turning will be controlled by constantly
sampling and checking the robots direction to the desired direction. Example it the
current heading of the robot is NE 45o and the waypoint falls NE 60o then the robot
will turn itself to the right until the current heading is NE 60o. The magnetometer
of choice is TI’s SenseHub. It utilizes AKM’s AK8975 3-axis digital compass. The
AK8975 utilizes magnetic sensors (Hall Sensors) that detect terrestrial magnetism
in all three axis. This is also uses an I2C bus interface that sends its data to an
external CPU. Hall sensors are relatively small, dissipate low amount of power,
and are cheap. The Hall Effect is the phenomenon that occurs when a magnetic
field is applied to a conductive a plate the electrons flow along the curves of the
filed that thereby produces a voltage. Depending on the polarity and strength of
this voltage, one can determine Magnetic north. When coupled with a second
conductive plate at a right angle to the first plate we can provide two axis for the
magnetic field. This in turn provides us one of eight directions. Below is a diagram
that depicts this phenomena: (55-60)
But it requires a that there are no other magnetic fields because Earth’s magnetic
field is weak in addition to the fact that with a two axis hall sensor we would need
to keep it flat and leveled with the earth itself. To compensate for this, a third axis
is implemented. The third axis performs “electronic gimbaling” also known as
“electronic tilt compensation.” This uses a dual axis tilt sensor that measures the
X and Y deviation or pitch and roll. By combining this tilt output info with the Z-axis
reading, we can determine the deviation if the X and Y axes from the horizontal
plane and then mathematically rotate it back. The analog signal from the hall
sensor will be converted to a digital output string along with the accelerometer
outputs as mentioned in the previous section. (55-60)
36
Figure 3.6.3.A: Hall Effect sensor (Reprinted with Permission from electronicstutorials.ws)(61)
3.7. Microcontroller
3.7.1. Tiva C
The Texas Instruments Tiva C Series TM4C123G is a low cost microcontroller.
The ARM Cortex M4F is the processor used for the microcontroller. The
TM4C123G is interfaced with a USB 2.0 device. The TM4C123G features Onboard In-Circuit Debug Interface (ICDI), USB Micro-B plug to USB-A plug cable,
LCD controller, serial communication, and Preloaded RGB quick-start application.
The attractive thing about the TM4C123G is that it can easily interface with booster
packs, packages, memory, and other peripheral devices. Since the Tiva C Series
TM4C123G comes from Texas Instruments you can rely on the company and the
community of users for solutions to problems. Not only this but Texas Instruments
gives you the TivaWare, a software to easily get started working with the
TM4C123G. (62-67)
The TM4C123G is driven by the ARM Cortex M4F microprocessor. The Cortex
M4F was created to satisfy the demand for an efficient, easy-to-use blend of
control and signal processing capabilities. The focus of these cores are to make
them highly efficient yet low cost and low power. One reason the Tiva C Cortex
M4F was considered was because the Cortex M4F focuses on motor control,
automation, and power management aspects. The Cortex M4F can reach speeds
of up to 80 MHz. The core has a 3-stage pipeline with branch speculation. The
Cortex M4F has a single precision floating point (FPU) unit that is IEEE 754
compliant. It has an optional 8 region memory protection unit (MPU) with sub and
37
background regions. Non-maskable Interrupts with up to 420 physical interrupts
are implemented on this core. Power saving sleep and deep sleep modes are
included with the processor. The Cortex M4F uses anywhere from 12.3 µW/MHz
to 157 µW/MHz. (62-67)
Size being an important of this project the Tiva C Series TM4C123G is a great size
of the J-Bot platform. The official dimensions are 2.0 in x 2.25 in x .425 in (L x W x
H). It can be said that the TM4C123G will definitely not pose any problems with
size. Even with booster packs attached the space taken up will be small, not to
mention well used. (62-67)
One focus of this project is to make a rover that is inexpensive. The price for the
TM4C123G is one of the best. This microcontroller is the second cheapest of them
all. This is one advantage the TM4C123G has over other microcontrollers being
considered for use in this project. (62-67)
Another attractive point working in the Tiva C Series TM4C123G is that it is created
by Texas Instruments. The support for Texas Instruments products is attractive
because no project is without bugs and problems. Having the support from the
company and communities built around their technology is a priceless commodity
to have available. Texas Instruments’ E2E is huge community on the Texas
Instruments website. It includes Q&A forums with over 1,506,000 answered
questions on almost any subject one could think of. These forums can be used to
answer questions about ARM processors, digital signal processors,
microcontrollers, amplifiers, power management, interfaces, applications, and etc.
Additionally, the community has on-going blogs on can keep up with on a subject
area one is interested in. For example the Texas Instruments MSP430xx
microcontroller line. You can make a TI account as post questions on the forums
and blogs. Your questions can be answered by other users that might have
encountered the same problems, TI aficionados who are well versed with TIs
technology, and even TI employees! Truly, the amount of support is overwhelming
when using any Texas Instruments product. (62-67)
As mentioned before the TM4C123G comes with the TivaWare software, the
TivaWare is a suite of software tools designed to simplify and speed up
development of applications based on the Tiva C MCUs. The TivaWare is
completely royalty-free and has a free-license. TivaWare is written in C to allow for
efficient and easy development. TivaWare comes with royalty-free libraries of all
kinds, and notes and documentation. These are all important because with royaltyfree libraries users can create full-functions and easy-to-maintain-code. Answers
to questions could be found within the code examples for the TM4C123x devices
and the documentations.
As far as memory goes the TM4C123x microcontrollers have 258KB flash memory.
Additionally, the TM4C123G has 2KB of EEPROM and 32KB of SRAM. This
microcontroller allows for direct memory access (DMA). Direct memory access is
when certain subsystems are allowed to access the main memory independently
without the CPU. (62-67)
38
Some additions to the TM4C123G that make it an attractive choice for the IRIM
project is that the microcontroller comes with six 32-bit pulse width modulators, six
64-bit pulse width modulators, and LDO voltage regulator. All these parts are
required to drive the 4 motors on the J-Bot. unfortunately the voltage regulator on
the TM4C123G is a linear voltage regulator. Which means all the unfavorable
things that come along with those will also be present. This is probably why Texas
Instruments included a temperature sensor on the MCU. Space is limited and it will
be waste of space to use a linear regulator as it will require a heat sink. (62-67)
In the end the Tiva C Series TM4C123G was not chosen for this project for a few
reasons. As previously stated the LDO voltage regulator on the TM4C123G is a
linear regulator which comes an array of problems and unwanted characteristics.
Everyone in the team has already worked with MSP430 and are familiar with its
environment and programming style required for it. One thing that the TM4C123G
really had going for it was the support from the company and community. Luckily
the MSP430 is also a Texas Instruments product and has an even bigger support
community behind it. (62-67)
3.7.2. MSP430G2
Like the Tiva C series TM4C123G, the Texas Instruments MSP430G2 is a low
cost, low power microcontroller. The MSP430G2 is a great choice for
microcontroller unit for any project because it is designed for general purpose
applications. This means it has a wide array of instructions that can be applied for
multiple kinds of projects. The MSP430G2 CPU is designed around the Von
Neumann architecture and it support the MIPS16 instruction set. The MSP430G2
is very versatile, it comes with a 20 pin connector that can be connected with any
booster pack in its line. The MSP430G2 is attractive because of its versatility,
compatibility, size, price, and familiarity. Like the Tiva C Series MCU the MSP430
has great support from the company and the community. The MSP430xx line has
a stronger community than the TM4C123G. Also along with support, the software
provided by Texas Instruments makes it easy to go from purchase to programming
in no time. (68-72)
The MSP430G2 CPU is designed around the Von Neumann architecture. This
means that there is one common memory for data and code, buses are used to
access memory and input/output, and direct memory access is allowed. Memory
is byte-addressed, and 16-bit words are combined in a little-endian format. The
CPU supports The MIPS16 instruction set and contains 16 16-bit registers.
MIPS16 is a very simple instruction set. It only has 27 unique instructions
separated into three families (R-type, I-type, J-type). The CPU runs at about 16
MHz. The MSP430G2 is ultra-low power at 2.2V it takes in only 220 µA. It wakes
up from standby mode in <1 µs. In standby mode the MSP430G2 takes in only .4
µA. The MSP430G2 has five power saving modes. (68-72)
Because size is such an important factor in this project, it is important to take this
into consideration when choosing an MCU. The MSP430G2 is very small, in fact it
is smaller than the MCU from the Tiva C Series by a little bit. The dimensions are
39
2.55 in x 1.95 in x .432 in (L x W x H). This small, but powerful MCU will not take
much space on the J-Bot.
Another small thing about the MSP430G2 is its price. Out of all the Microcontrollers
considered for this project its price was the cheapest. It is very fortunate that a
microcontroller that can handle what we need from it is so cheap. (68-72)
Figure 4-1: Functional block diagram for the MSP430G2 (Reprinted with permission from Texas
Instruments) (71)
Since the MSP430G2 is a Texas Instruments product it has a vast amount of
support available online. The E2E community is available for anyone. It is likely
that someone has already encountered your problem and a solution is already has
been reached. The question forums can be searched also the blogs can be. An
attractive addition to the MSP430G2 is that the MCU has its own blog. Apart from
the E2E community there is a lot of literature online with solutions, other projects,
and forums. All this support, literature, solutions, experts, videos, forums, and
blogs speak volumes of a product’s reputation. So many people wouldn’t not
dedicate their time to a product that doesn’t work or they don’t like. (68-72)
The Tiva C Series TM4C123G came with the TivaWare, the MSP430xx line comes
with Code Composer Studio (CCS). The Code Composer Studio is an integrated
development environment (IDE) that is comprised of a suite of tools used to
develop and debug applications. Included comes a C/C++ compiler, source code
40
editor, project build environment, debugger, profiler, and other features. With this
IDE one can program the MSP430G2 easily and quickly. Code Composer Studio
uses the Eclipse frame work along with advanced debugging capabilities from TI
resulting in a development environment for embedded developers. You can be
assured that with Texas Instruments you will have an updated and fluid
environment. (68-72)
The MSP430G2 has a 16 KB flash memory. Additionally, it has a 512B RAM. Flash
memory is a widely used, nonvolatile, and reliable memory to store data and code.
One of the advantages and purposeful design points of the MSP430G2 is its
compatibility with other parts and booster packs. It has already been discussed
that voltage regulation will play an important role in the creation of the motor control
board. For example the MSP430G2 can be paired with a TSP62120. The
TSP62120 is a 15V, 74mA high efficiency Buck converter. Basically it is a highly
efficient switching voltage regulator. The TSP62120 has a 96% efficiency rating,
thus making it low heat. This is important because a heat sink would not be
necessary with this regulator. (68-72)
The MSP430G2 was chosen as the MCU for this project for a few reasons. Firstly,
The MSP430G2 is low cost and this is important because the project focuses on
making an inefficient interior mapping robot (IRIM). Also, the MCU is an ultra-low
power which is important for battery life. The MSP430G2 power consumption is
unmatched in the market. Next, the MSP430G2 compatibility is important because
it is almost inevitable that this MCU will have to interface with another part. Most
importantly the MSP430G2 was chosen because all members of the group are
familiar with it and have programmed one prior to taking on this project. This saves
a lot of time in designing and programming the motor controller. This was ultimately
the deciding factor in the decision for an MCU. If an MCU that everyone is familiar
with is available to use and will get the job done it makes it hard to argue against
not using it. Learning a new instruction set and how to program with it is not an
easy task to take on in the middle of a project. (68-72)
3.8.
Wireless Components
Navigation systems and obstacle avoidance systems require visual input and
heavy processing power. Our robot is meant to be autonomous and capable of
roving freely without any strings attached so to say. For it to achieve this it must
use a small computer to process this data onboard. The reason for a small
computer is because the size of the robot is a restrictive factor and the availability
of space for component mounting is limited. One such component would be TI’s
OMAP4430 PandaBoard, which has a dual-core ARM® Cortex™-A9 Processor.
However, the cost of the PandaBoard is roughly $200. Our objective is to design
an Inexpensive robot. Therefore, like any business model that sees the expense
of having native workers it would be best to outsource the job. In our case, it would
be best if we outsourced the job of processing to a normal everyday computer. In
order to conceive this we would need wireless communication. There are three
possible communication methods and nine possible combinations for sending and
41
receiving data. We can use Radio Frequency Transceivers, Wireless Fidelity, or
Bluetooth.
3.8.1. Sub-GHz Radio Frequency Transceivers
Radio Frequency Transceivers are one of the oldest wireless communications.
They are able to transmit data at rates up to 100 GHz. However, we will not be
implementing speeds over 1 GHz due to bandwidth allocations by the FCC.
Instead, our RF Transceiver modules will be operating in the 902-958 MHz ISM
bands. ISM radio bands sections of the radio spectrum reserved internationally for
industrial, scientific, and medical purposes other than telecommunications. The
main advantages of RF are that unlike Wi-Fi it does not need a third party network
in order to establish a connection and it provides the same data rate of a Bluetooth
transmission over a longer distance. This is primarily because Bluetooth operates
at 2.4 GHz whereas the RF transceiver will be operating at sub-GHz frequencies.
It is a known fact that the higher the frequency the shorter the distance. Because
as the frequency increases so does the tendency of it being absorbed by physical
objects in its environment. To make up for the signal loss additional signals need
to be transmitted causing a delay in message completion and increase in power
consumption. Due to this quality, low frequency signals tend to “hug” the earth’s
surface since they are able to bounce off the atmospheric layers. (73-75)
The module of choice is TI’s CC110L RF BoosterPack. It works in conjuncture with
the MSP-EXP430G2 LaunchPad development kit as an extension. The CC110L
uses Anaren’s integrated radio A110LR09A. The A110LR09A is capable of
implementing a plethora of wireless networks. Most importantly and obviously, it
can implement point-to-point networks. In our robot system we will be transmitting
data to and from a computer. Such wireless connections that utilize RF are halfduplex that is that they cannot send and receive data simultaneously. This is a
major drawback for an autonomous system that must react to obstacles as close
to real time as possible. In Half-Duplex a receiving device must wait until the
transmitting device is finished transmitting before it can transmit. (73-75)
It is feasible to implement a full-duplex connection by using self-interference
cancellation. Self-interference works as such:
“The receiver “listens” to determine the RF environment and uses algorithms to
predict how the transmission will be altered by the environment and cancel it out
from data received from the receiver. By doing so, the problem of self-interference
goes away, and the receiver can “hear” the signal it is supposed to hear while the
transmitter is active. The major cost for this approach is increasing complexity in
terms of software, which can slightly impact battery life,” (76)
One additional drawback is that communication between the robot and computer
will unencrypted thereby allowing for malicious interference. This would require
more development time than it is worth. Although it has an advantage of distance
over Bluetooth and reliability in network over Wi-Fi, it will much simpler in design
to implement one of the other two. However, if there is such a library predefined
by TI or Anaren then we will most definitely take that course. (73-75)
42
3.8.2. Bluetooth BLE
One method, out of the three, that is quite simple, is to implement Bluetooth as a
UART. Bluetooth technology has been around for a while and has extend from
phones interfacing with headsets and speakers to full-blown data transmission
from computer to computer. The main advantage that Bluetooth has over RF is
that it requires less hardware, less development for interfacing two devices with a
high throughput, and all communications are AES encrypted, which allows for safe
communication. Instead of having to design two Bluetooth transceiver, we only
need to design the Bluetooth transceiver on the robot side and purchase a
Bluetooth dongle for the computer. Since RF is restrained at sub-GHz frequencies,
its throughput can be lower than Bluetooth if the computer and robot are within the
same vicinity without physical interference. Another advantage it has is over WiFi. With a Wi-Fi network, we have to consider a third party system (the internet).
Our connection reliability is dependent on the assumption the internet will be
available. In addition, an Internet of Things connection (IoT) is restricted in where
the Robot and Computer is located. The Bluetooth connection is not reliant on a
third party system so those restrictions do not apply. The downside to Bluetooth is
that it is restrictive in range from the object. It lacks the range capability of Wi-Fi
(provided that the robot is in a Wi-Fi hotspot and the computer is in a Wi-Fi hotspot)
and lacks the range capability of the sub-GHz RF transceivers because the RF
transceivers are at a lower frequency so their range is higher due to the a-fore
mentioned reasons in 3.8.1. (78-87)
The Bluetooth module we will be using is the Emmoco Development board
Bluetooth Low Energy (EDB-BLE) booster pack for the TI MSP430. The EDB-BLE
utilizes TI’s CC2541 system on chip (SoC). Bluetooth currently comes in multiple
flavors, Bluetooth Smart, Bluetooth Smart Ready, and Bluetooth Classic. The
CC2541 is the first type. This falls in the classification of so-called “single-mode”
device. The main advantage of these devices is that they connect to both singlemode devices and Bluetooth Smart Ready devices also known as “dual-mode” and
that they have low energy consumptions. However, the benefit of low energy
consumption will be lost to our implementation. Low energy Bluetooth devices are
devices that are not on all the time. They are only active for a short burst (when
they need to do a particular job) and then go back into sleep. These are devices
with short duty cycles. An example would be a heart-rate belt monitor. It only sends
out a few bytes per second and that only occurs a small percentage of time that it
is attached. The percentages are usually in the single digits. In our implementation
of the BLE, we will be using the Bluetooth as a UART. Bluetooth will be in constant
use, meaning a high duty cycle. Nonetheless, the benefits of the Bluetooth are
good enough for consideration. (78-87)
The CC2541 interfaces with the MCU though the I2C. The MCU uses the CC2541
as a wireless version of a serial communication like that the RS232 serial
communications. It runs in the ISM unlicensed bandwidths along with Wi-Fi and
ZigBee. The CC2541 is able to work in point to point networks. That is one
Bluetooth module will be the master and the other a slave. It possible for the
CC2541 to trade places between master and slave. This is not necessary for a
43
point-to-point network. Because the idea behind a master-slave network is that,
the master can request data and send data to and from any slave. The slave can
only send data to and from the master. Our Master will be the computer and our
only slave is the CC2541 on the robot. However since the CC2541 allows for
piconets we can add more Bluetooth modules for different connections. This will
allow for a more loosely coupled system. The Kinect can route data straight to the
master computer. The SenseHub can route its data straight to the computer and
the Piccolo can also route data to the computer. This will increase throughput of
sent data since one CC2541 will not have to put all this data into a queue and
artificially cause a delay. The only CC2541 that needs to be spoken back to is the
one in charge of the Motor Control. The only challenge is to let the computer see
these as parallel connections through one communication port.
The Bluetooth connections process takes three steps. The first is the initial inquiry
of the devices. Each Bluetooth device has a unique address. This address is 48bits and usually coded in 12-bit hexadecimal. The upper half (most significant half)
identifies the manufacturer. The lower 24-bits are the unique address of that
module. This is important since we need destination address for each device that
will pair up. This makes sure that data packets will not be sent to the wrong
recipient. The next stage is called paging. In this stage the actually connection is
established (handshake). Once established the connection becomes encrypted.
Once a device is connected, it is in one of four states: Active Mode Sniff Mode,
Hold Mode, or Park Mode. Active mode is the mode our Bluetooth device will be
since the devices will be actively transmitting and receiving. Sniff mode is when
the device is in sleep mode and will only wake up every so often to listen for
transmissions. Hold mode is when the device is told to sleep and wake up after
some time. Park Mode is when the device is put to sleep indefinably and will be
woken up by the master explicitly. (78-87)
Since our focus is to replace the typical RS232 serial connection with the
Bluetooth, (the Bluetooth was originally designed for this). The way to do that is to
use Serial Port Profile (SPP). The idea is that the applications that are involved
see an emulated wired connection. These devices are legacy applications and they
do not know how the
Bluetooth connecting will work so a separate application will be needed. This is
known as the Bluetooth-aware helper. The Bluetooth-aware helper will then utilize
the Bluetooth stack to transport data to and from the other device. Figure 3.8.2.A
describes the stack:
Application A and Application B will the legacy applications that use RS232
connections (wired connections). The scan only process and transmit RS232
signals. So Application A will try to transmit RS232 signals through an emulated
connection. The Serial port Emulation or any other API (the Bluetooth-aware
helper) will then initiate the RFCOMM will transmit data with TX connection or
receive data through the Rx connection. It is also known as the serial port
emulation.
44
The SDP (service discovery protocol) will check if the services that Application A
is valid or available through from Application B. It should be noted that Both
RFCOMM and SDP receive inputs and outputs from the Serial port emulation API.
The LMP (link management protocol) is the protocol in charge to establish the
connection of the two devices. It also handles power control queries device
capabilities. Once the connection has been established and data is being
transmitted then it is up to the L2CAP (Logical Link control and adaption protocol)
segment the data to be sent out.
Figure 3.8.2.A Bluetooth Protocol Stack
Each segment will have a header with the part number. This is essential since data
is being transmitted wirelessly and there is a possibility of lost or corrupted packets.
Therefore, we need the data to be segmented. The Receiving Bluetooth will use
the L2CAP to reassemble this code. The packets are formed with three distinct
sections. Access Code, Header, and Payload. The access codes are used in
paging and inquiry procedures. The header contains the members address, the
code type, flow control, acknowledgement indication, the sequence number, and
header error check. The payload holds the actual data that is being sent or
received. The L2CAP is responsible for maintaining the Quality of service that the
higher levels demand. The Baseband is responsible for the acknowledgements
and retransmission of data. It controls the synchronization of data by adding and
offset to the free running clock of the system. This allows a temporary
synchronized clock for both Bluetooth devices. Another aspect of the Baseband is
the frequency hopping. The Bluetooth protocol utilizes the 2.4GHz frequency that
is 83 MHz wide. Out of that, the Baseband uses frequency hopping spread
spectrum to “hop” between 79 different 1 MHz-wide channels in this band. This
allows for three advantages. The first is that using FHSS signals are resilient to
narrowband interference. The reason for this is because when collecting the signal
from different spectrums the interference signals also become spread, making the
interference much smaller and easier to handle also due to the smaller magnitude
it can even fade into the background. The second advantage is that spread signals
are difficult to intercept. Meaning not only do the listeners pick up jumbled up noise
but also if they want to jam the signal it will be just as difficult. This is due to the
45
pseudorandom sequence of the signals. Unless this pattern is known, it is hard to
intercept or jam. The third advantage is that since this allows data to be transmitted
among various spectrums, the possibility if interference with another device that
uses the same 2.4GHz but in a narrow band is very low. The noise levels will also
be low. This results in a more efficient use of bandwidth. The Base band also uses
Time division multiplexing. This allows a signal to use the entire spectrum for a
short amount of time. This is ideal since data packets are relatively small and
transmissions times are short. Therefore, we are able to transport the entire data
packet within the period at a high bandwidth. Bluetooth’s TDM variety is
Synchronous. It allocate a fixed time for each signal. Which is 625 microseconds.
These bit streams are sent ahead of the logical data packets so that bit
manipulations are done to increase reliability and security. The bits are used for
power control, link supervision, encryption, channel data rate (changes for quality),
and multi-slot packet control. However, the biggest weakness is range. Bluetooth
devices require a distance of 100 meters and in some devices (like low energy
devices) 50 meters at most. This would require that computer and robot to be within
the same vicinity. The solution to this problem would be to implement Wi-Fi as our
medium. Which would mean to apply the Internet of Things (IoT) to our project.
(78-87)
3.8.3. Internet of Things (Wireless Fidelity)
Modern day communication is heavily dependent of wireless connectivity. Things
as important as GPS and things as insignificant as a celebrities tweet all rely on
some mobile internet capable thing and the internet. The Internet of Things is the
movement when physical devices, that have not need for the internet and its
plethora of content to function, use the internet complex and robust network to
achieve connectivity. It is difficult to create an entire network that can be robust
enough to handle different activities. Ideas as monitoring a patients heartbeat,
sugar levels, and blood pressure in real time from miles away without developing
a network to cater to that was difficult to realize. To have a system where a hotel
can adjust the light and temperature settings at the customer’s preference without
having to add additional hardware was vexing. However, all this can be realized
by using the internet as a medium. We can have pacemakers that sends data out
an IP address although the Wi-Fi. We can have hotel employees modify the hotel
temperature and lighting ahead of time with an app. Internet of Things simplifies
the process of data transmission and reception. All we simply would have to do is
specify which IP address the data should go and come from this removes
unnecessary low-level software development. In addition, the data rates are much
faster than that of the previous two implementations. This environment is the ideal
setting for our project. (88-94)
Our testing environment is indoors since the Kinect can only work indoors. The
location of our testing environment is any building in the University of Central
Florida. Every building that is in UCF is Wi-Fi ready. Also with the other
implementations we would need to be within a reasonable distance but with Wi-Fi
the distance no longer matters. Considering our small time-frame for developing
our autonomous system, developing with IoT will drastically reduce code
46
development and debugging. The Wi-Fi module of our choice is the TI CC3000.
(88-94)
TI’s CC3000 is a complete IoT solution for any MCU. It integrates all the necessary
requirements for internet and Wi-Fi protocols. This alleviates development on the
MCU, since normally the protocols must be developed per MCU. Ease of
development from hardware specific because it is available in any easy to use
QFN (quad flat no-lead) package. The advantage of that is when it comes to PCB
design it is easy to apply. (88-94)
The CC3000 supports the following security modes for personal networks: WEP,
WPA, and WPA2 with its on chip security accelerator. Its supports 802.11 b/g radio
in the 2.5 GHz ISM band with a throughput of 1-54 mbps. It also includes Integrated
IPv4 TCP/IP stack. In addition to its development usefulness, it also excels in
power consumption. With its own DC-DC converter, it is able to draw its low energy
requirements from a variety of power supplies. With its own ARM MCU, it is able
to go into low power modes and consume as small as four micro amps. (88-94)
3.9. Power
3.9.1. Nickle-metal hydride battery
A Nickle-metal hydride battery or a NiMH battery is a type of rechargeable battery.
A NiMH uses positive electrodes of Nickle oxyhydroxide and negative electrodes
of a hydrogen absorbing alloy. NiMH batteries are very efficient batteries they have
three times the capacity of a NiCd battery of the same size. Also, the energy
density of the NiMH is close to that of a lithium-ion cell. NiMH batteries usually
come in AA size. In the early 2000s NiMH batteries were on the rise but since then
have fallen in popularity. (95)
Although these batteries are very efficient they do have a down side. NiMH
batteries have a 4% loss of charge per day of storage. A low self-discharge variant
were made in 2005, but this lowered capacity by 20%. One advantage of using
these batteries is that they already come in AA and AAA sizes and shapes which
ameliorate their use in a project. (95)
3.9.2. Lithium ion battery
A Lithium ion battery is a type of rechargeable battery. Lithium ions move from the
negative electrode to the positive electrode during discharge and vice versa during
recharge. Lithium ion batteries are common in consumer electronics such as cell
phones, tablets, and laptops. Their popularity stems from having high energy
density, no memory effect, and slow loss of charge. An advantage to using these
batteries is that you can use a battery back to provide the same voltage as leadacid batteries. This is convenient for robot project that require voltages produce by
batteries of this kind. (97)
3.9.3. Lithium Iron Phosphate battery
A Lithium Iron Phosphate battery is another kind of rechargeable battery. These
batteries use LiFePO4 as cathode. Although Lithium Iron Phosphate batteries have
47
lower energy densities they offer longer lifetimes and they have better power
densities. Having higher power densities mean that the rate at which energy can
be drawn from them is higher. These batteries are also safer than their lithium ion
counterparts. Lithium Iron Phosphate batteries, like Nickle-based batteries, and
unlike lithium ion batteries they have a constant discharge voltage. With a slow
capacity loss these batteries maybe a good choice to use for a project with
longevity in mind. In a robot rover situation these batteries can be put a battery
pack to produce 12.8V with four cells. This would be equivalent to having a six-cell
lead-acid batteries. (96)
3.9.4. Power set up
There are a few options when it comes to the way you want to power your robot
microcontrollers and motors. The two main options are having multiple batteries
power different components of your robot or having one battery power everything.
Both have their advantages and disadvantages. (98-100)
One way to set up your power design is to use one battery to power every
component of your robot. The advantages to this are only having one battery to
change and minimizing the weight added to the rover since you only have one
power source. One disadvantage is that you will need a voltage regulator to control
how much voltage a component is getting. Most microcontrollers operate at around
12V while motors can operate anywhere between 3V to 9V. Also, most electronics
work at around 5V for example sensors. This makes the wiring complex and
requires more work. (98-100)
The other option is to have multiple batteries that power different components of
the project. The advantages to doing this are it is a simpler design thus making
your design time much shorter. Another advantage is the project can work more
efficiently because having multiple batteries makes the project have a modular
layout. The disadvantages to using multiple batteries are some components wills
top working before others do. This can be easily avoided if recharging of batteries
is done regularly and appropriately. (98-100)
This project will use the one battery approach. This was chosen to keep the design
simple, lower cost, and minimize use of space on robot. A simple design is
favorable because with more parts come more problems and complications. One
complication is that if multiple parts of the robot have their own power source each
source will require some kind of monitoring to assure the right amount of
voltage/current is being supplied at any given time, thus complicating the design
of the motor controller board. Keeping the cost down of this project is important
because the point is for it to be inexpensive. Not only this but, lowering cost should
be a priority of any project whether academic or corporate in nature. Needless to
say that performance and meeting requirements does take priority over cost but if
equal results can be achieved with both methods then the cheaper one is most
48
attractive. Minimizing the space usage on the robot is important because space is
limited. (98-100)
The battery being chosen is a lithium ion battery. The batteries are LG Lithium
18650 3.7V rechargeable cell. These batteries produce 2600mAh or 9.62Wh. A
battery pack will be needed to provide the amount of voltage needed. This battery
pack will be used because it can hold four batteries. The battery pack will produce
14.8V which will be more than enough. (98-100)
3.9.5. Voltage Regulation
Voltage regulators output a predetermined magnitude that remains the same
regardless of changes to the input or load conditions. There are two kinds of
voltage regulators: linear or switching regulators. (101-106)
Linear regulators utilize active pass devices such as BJTs or MOSFETs controlled
by a high gain differential amplifier. By comparing the output voltage with an
accurate reference voltage it can adjust the pass device to maintain a constant
output voltage.
Switching regulators differ from linear regulators because while linear regulators
act as an adjustable resistor switching regulators act more, as the name implies,
a switch. Switching regulators periodically store energy in the magnetic field of an
inductor, then discharges the energy into the load. The switching action usually
switches between 50 kHz to 100 kHz depending on the circuit. The time the switch
remains closed between switches varies to maintain a constant output voltage.
While the switch is closed the inductor is charging and the diode which is in reverse
biased acts like an open circuit. When the switch is opened the energy stored in
the magnetic field of the inductor is discharged and the diode is conducting. (101106)
Both regulators have the same results but at different costs. Linear voltage
regulators are very cheap which make them favorable in project with limited funds
or a tight budget. Linear voltage regulators are great for low power applications.
Compared to switching regulators they are easy to use as well. Although cheap in
price linear when it comes to power because they use up so much of it mostly to
waste it. Linear voltage regulators, as previously stated, behave like adjustable
resistors this makes them highly inefficient. Typical efficiencies for linear voltage
regulators are about 40% to as low as 14%. As resistors do this wasted power is
released as heat. In some situations the heat released is so much that large and
expensive heat sinks must be used to dissipate the heat. This much wasted power
also translates to having a reduced battery life for the project. Even with advances
in linear voltage regulation technology, they are still highly inefficient. For example
LDO (Low Drop-out) regulators are in efficient but they allow flexibility with input
voltage drops. Like resistors, linear voltage regulators can only step down voltages
which can be highly impractical for project that require more flexibility from their
regulators. Another advantage of linear voltage regulators is that they produce a
much smaller noise than switching voltage regulators. (101-106)
49
Switching voltage regulators are almost the opposite of linear regulators as far as
advantages and disadvantages are concerned. Switching voltage regulators are
more expensive than linear regulators. This may dissuade their use in projects.
Although it is not favorable to pay a lot for a single regulator if a project does not
require many regulators, the advantages of these voltage regulators far outweigh
the price tag. Switching voltage regulators are highly efficient, anywhere from 80%
to 95% efficient. Since their efficiency is less dependent on the input voltage these
regulators can handle powering load from higher voltage sources. This is important
because the regulators can be utilized more flexibility with a wider variety of power
supply and voltage ranges. As a result of their efficiency they do not require to be
cooled down as much. This is great because spending a little more on a switching
voltage regulator can save you money by not having to purchase an expensive
heat sink. In a way this balances its self out. Additionally, with this higher efficiency
battery life is less impacted and will last longer. Switching voltage regulation
circuits are more complex than linear voltage regulation circuits thus complicating
the design. Fortunately, many companies sell switching voltage regulators as ICs
(integrated circuits) taking the complexity out of the hands of the designer. These
integrated circuits even come in a three pin format like linear regulators do. Unlike
linear voltage regulators, switching voltage regulators can step up and step down
the voltage in the output. This is something linear voltage regulators cannot do.
Although more efficient switching voltage regulators have a higher noise than
linear regulators. With higher switching frequencies come smaller inductors and
capacitors, this also means a higher noise in the circuit. Switching voltage
regulators require a means to vary their output voltage according to input and
output voltage changes. This can be achieved with a pulse width modulator
(PWM). With a PWM controlling the rate at which the switch opens and closes. A
constant output can be achieved by adjusting to changes in the output voltage of
the voltage regulator. (101-106)
Voltage regulation plays a pivotal role in the design of the PCB board because
without it a one battery design would not be possible. There are many components
on the motor control board that work at different nominal voltages. One could see
the great need for voltage regulation. There are so many different kinds of
regulators, one must be careful when choosing a regulator for a project. Most
importantly one must identify what functions are required of the regulator. This may
be step-up, step-down, or both. These are the most common. Next the type of
regulator much be chosen whether a linear or switching will be needed. To drive
the J-Bot it has been decided that a switching step-up/down voltage regulator
would be best. Although a linear step down or a switching step down can be used
the latter was chosen because it allows for greater flexibility when testing the
board. Three voltage regulators where considered for this project: The Texas
Instrument TPS71501, the Pololu S18V20ALV, and the Motorola MC34063AP1.
The Motorola MC34063AP1 was chosen was the voltage regulator to be used on
the board. (101-106)
The Texas Instrument TPS71501 is a linear step-down LDO, single output voltage
regulator. The TPS71501 is advantageous because it offers high input voltage, low
50
drop out voltage, low power operation, low quiescent current, and small packaging.
The TPS71501 operates from 2.5V to 24V input voltage. It can output from 1.2V
to 15V. The TPS71501 has an adjustable output voltage which is imperative for
this project because the motors require different speeds to make turns. One side
of the rover will need to be moving slower than the others to make turning possible.
This cannot be achieved with a fixed output voltage regulator. The TPS71501
outputs a maximum of .05 A or 50mA. The TPS71501 has an output accuracy of
4%. This voltage regulator was not used because it is a linear regulator and the
concern of wasted power came into play. Dissipating the heat produced by this
regulator is a concern because space is limited on the J-Bot. Also, battery life is
an important factor in any project and the PCB board will be using a minimum of 5
regulators that will each waste too much power and produce too much heat. The
design of the board is not low power enough to be justify the use of a linear
regulator and accept their inefficiencies. Also, the maximum output current of the
TPS71501 is too low for the application it is need for. The motors on the J-Bot have
a no load current of 120mA and 160mA at 3V and 6V respectively. Additionally,
the motors have a locked-rotor current of 1.5A and 2.8V respectively. The .05A
maximum that the TPS71501 puts out is too small to meet these values. (101-106)
Figure 3-6: Here is the circuit diagram inside the TSP71501. (Reprinted with permission from
Texas Instruments)(108)
The Pololu S18V20ALV is a step-up/down switching voltage regulator. The
S18V20ALV is advantageous because its offers a 2.9V to 32V input voltage, puts
pout 4V to 12V, high efficiency (80%-90%), flexibility, low heat, small size, and
good output current. The motor controller will be powered by a 14.8V power supply
so the input range for the S18V20ALV is perfect. The motors can be operated from
3V-12V depending on what speed is required of each one. This is one reason the
Pololu S18V20ALV was not chosen because it has an output voltage range of 4V
to 12V. This range is almost perfect but the two nominal voltages of the motor are
3V and 6V as suggested by the manufacturer. 3V is just outside the range for the
S18V20ALV. Another reason the S18V20ALV was not chosen is because of its
price. It is far more expensive than any of the other three voltage regulators. Since
51
the S18V20ALV is a switching voltage regulator it has a high efficiency which
translates to good battery life and low heat. Low heat is important because we will
not require any heat dissipation which will add to the complexity of the design and
take up space, a precious commodity. While on the topic of space the size of the
S18V20ALV is no bigger than a quarter! The official dimensions are: 0.825″ × 1.7″
× 0.38”. Finally the S18V20ALV has a good maximum output current measured at
2A. it is safe to say that the Pololu S18V20ALV barely does not make the cut. It
could be included in this project but with all the options available in the world of
ICs settling for an almost ideal part doesn’t make much sense, if the perfect one is
available! (101-106)
The Motorola MC34063AP1 is a step-up/down single output 8–pin switching
voltage regulator. The MC34063AP1 is advantageous because its input voltage
range is 3V to 40V, output voltage range of 1.25 to 40V, high efficiency (87.7% at
12V in), precision, low heat, small size, and flexibility. As stated before the motors
need to be operated anywhere between 3V and 12V, the MC34063AP1 has a very
wide output voltage range making it a great choice for a regulator. The power
source will supply 14.8V which is fin because the input voltage range
encompasses this voltage with ease. Since the MC34063AP1 is a switching
voltage regulator it will be highly efficient. For example: 87.7% at 12V in, 83.7% at
25V in, 62.2% at 5V in, and etc. Since the regulator is a switching regulator will not
experience high amounts of heat. No heat sink will be required to cool down the
board. The MC34063AP1 output is accurate with in a 2% range, typical values are
4%. The MC34063AP1 is very small, it is not bigger than a penny! The official
dimensions are: 10.16 x 6.6 x 3.44 mm. (101-106)
Figure 3-7: Circuit diagram for the Motorola MC34063AP1. (Permission Pending) (109)
52
4. Design
4.1. Hardware Design
4.1.1. Robot Platform
The J-Bot must be organized to optimize space and make its use count. The inside
of the body will house the 4 motors that come with the J-Bot kit and the battery
holder that holds four 3.7 lithium ion batteries. The first tier will be used to hold the
motor controller board. Additionally, the first tier will hold the battery pack and all
other connections that will power the Microsoft Kinect. The second tier will hold the
Kinect by surrounding it with 4 pegs around its base to hold it in place while the JBot moves around and turns.
4.1.2. Power Requirements
The power requirements of this project are different for each component. Data
sheets of part will be an important resource because you do not want to supply
parts with currents or voltages that they are not rated for. The MSP430 processor
that will be used for the motor controller runs at 5V. All four motors will usually be
operating at 6V each. Other parts such as the proximity sensor, magnetometer,
accelerometer, and encoder require 3–5 V. all of these will be powered by a 14.8
V lithium ion battery. It is evident that voltage regulation will play a pivotal role in
the design of the motor controller.
Voltage regulation will be taken care of by the Motorola MC34063AP1. This
switching voltage regulator will be used to step down the voltage from the power
supply to the processor. Additionally, the MC34063AP1 and the L293 will be used
to adjust the voltage given to the motors.
Although a one battery design has been implemented to power the motors and
PCB motor controller the Microsoft Kinect will have its own power supply because
it requires 12V to power. The 12V need to come from a wall socket connection.
12V will be supplied by the same set up as the power supply to the motor controller
board. This means 4 3.7V lithium ion batteries will be placed in a batter holder that
will output 14.8V. Since the Kinect runs at 12V and 1.08A the voltage and current
will be regulated to match these values as closely as possible. Using the
MC34063AP1 to regulate should be possible because of it wide range of voltage
and current outputs. Since the Kinect takes power from a wall socket the cable will
be cut after the AC to DC converter box and we will supply the 12V and 1.08A
directly into the cable.
4.1.3. Computational Requirement
This is a project were data processing is essential. The first is the visual feed that
will come from the Kinect. The Kinect provides four streams. Three visual and one
auditory. The auditory is not needed so it will be discarded. The three streams are
image stream, the depth stream, and the skeletal stream. The skeletal stream is
not needed so we can excluded it. The image stream is purely an aesthetic stream.
It holds no value in the navigation of the robot. The only stream that will be of use
is the depth stream. The depth stream is a 16-bit value per pixel that tells the
53
computer how far that pixel is from the Kinect. This information must be converted
from the USB’s differential signals to an RS232 stream that can be sent over WiFi. This stream will then be processed by the off board computer. This conversion
is done by the TUSB3410, which is a RS232/IrDA Serial-to-USB Converter. There
is no need for typical setup for USB connection. TUSB3410 has 10KB of ROM that
pre-configures the USB connection at boot time. The data stream is then filled into
a buffer that will be sent over Wi-Fi. The buffer is actually the size of one pixel
representation. If we use the smallest data type, 8-bit char, then for each bit of the
16-bit stream it will take 128 bits to represent a single pixel. The image itself is
80x60 pixels. That is 4800 pixels. That means a total of 614400 bits of data must
be sent. If we guarantee ourselves a network speed of 1mps (1024*1024 bits)
upstream and downstream, then total amount of time required for all the data to be
sent is roughly .6 seconds. This is a very good time for sending this data.
Immediately after that, the MSP430F16x series processor will take this information
and pass it to the MSP430G2 to be sent via Wi-Fi. Alternatively, we could send it
directly from the MSP430F16x. The reason for this is that the MSP430F16x can
add on external memory, which would increase the buffer size and decrease
fragmentation (more can be sent at one time). It should also be noted that the data
would be sent on a UDP protocol, it will be “blasted” over the connection. The
reason for this is that there are so many point that a few pixels being lost will not
cause an error big enough to worry about. The Wi-Fi protocols will be handled by
the CC3000 meaning the packet creation with headers and payloads will be
controlled by the CC3000. The MSP430G2 in the locomotion module will be
responsible for the control of the motors. It will also take the Accelerometer and
Magnetometer information and process it to find out the current heading of the
robot as well as speed and displacement of the robot. This MSP430G2 must also
be able to process the encoders input to determine the velocity of each wheel. This
will verify whether the wheels are rotating at the right speeds. If any deficiency is
found, the system will self-correct it.
4.1.4. PCB Design
The PCB will have all of the following modules on it. It will have the Wi-Fi module,
a communication module that links all other modules to the Wi-Fi module, a
Locomotion module that controls the motors as well as receive feedback about the
motion from the robot and the robot’s wheels, Voltage regulator, a Power supply
to supply the raw voltage values, multiple motor assembly’s, and the Kinect.
Although the computer is displayed, it is not on the actual PCB but rather is part of
the High Level Abstract Representation.
One of the most fundamental part of our project is the communication between the
robot and the Computer. In order to do this we decided to pick one of three different
methods. We could use RF signals and achieve a long distance without
interference but we would still have to follow the robot around. The connection
would not be encrypted and the design of the data packets would be up to us
entirely. It also adds hardware since both the robot and the computer would need
RF transceivers to communicate. Bluetooth was a candidate since it had a wellestablished library of protocols and it required one less component than RF
54
transceiver in that a Bluetooth dongle could be bought to communicate with the
robots Bluetooth transceiver. The only problem was that the Bluetooth had a
shorter distance. Therefore, the final decision was to use WiFi as our medium.
Since our robot will be functioning indoors and more specifically in a Wireless
internet rich area, it was the best option especially since the protocols have already
been defined and the libraries for it have already be developed. Our Wi-Fi module
of choice is TI’s CC3000 as shown below:
Figure 4.1.4.A CC3000 (reprinted with permission from SparkFun) (111)
Figure 4.1.4.B: MSP430G2553 (reprinted with permission from Energia) (112)
The CC3000 is a simple to install Wi-Fi module. The pin assignments are simple
and it interfaces with the MSP430G2 processor. Below are the schematic diagrams
for both the MSP430G2 and CC3000 as well as the pin assignments from Ti.
55
Figure 4.1.4.C: Schematic Diagrams for CC3000 and MSP430G2 respectively
(reprinted with permission from Texas Instruments (113-114)
MSP430G2 to CC3000 Pin Assignments
Pin Number
Assignment
1
VBAT_IN
2
VBAT_SW_EN
3-6,8-13, 16-17
NC
7
WL_SPI_CLK
14
WL_SPI_DOUT
15
WL_SPI_DIN
18
WL_SPI_CS
19
WL_SPI_IRQ
20
GND
Table 4.1.4.A MSP430G2 to CC3000 Pin Assignments
CC3000 to MSP430G2 Pin Assignments
Pin number
Assignments
1,9-11,16,18,20-22,25,31-34,36-46
GND
2,4
Reserved
3,6,8,24
NC
5
WL_EN1
7
WL_EN2
12
P2.6
13
P1.6
14
P2.7
15
P1.7
17
P1.5
19,23
VCC
26
P1.0
56
27
SDA_CC3000
28
SDA_EEPROM
29
SCL_CC3000
30
SCL_EEPROM
35
ANTENNA
Table 4.1.4.B CC3000 to MSP430G2 Pin Assignments
The antenna circuit design that is recommended by Texas Instruments is as
follows:
Figure 4.1.4.D: Suggested Antenna Design for CC3000 by Texas Instruments
(reprinted with permission from Texas Instruments) (113-114)
This circuit requires the following parts:
AT8010-E29HAA
C1 = 2.2pF
L2 = 2.2nH
C2 = 10pF
Additionally additional circuit is required in the CC3000 as shown below:
57
Figure 4.1.4.E: Suggested Additional circuitry by Texas Instruments (reprinted
with permission from Texas Instruments) (113-114)
The following capacitors are needed:
C4, C5 = 1uF
The most essential part of this project is to transport the data to the computer
through the Wi-Fi. For this to be possible, we need a USB type A port that will
receive a data stream form the Kinect.
Figure 4.1.4.F: USB Type A Breakout board (reprinted with permission from
SparkFun) (115)
The Kinect will be supplying depth data stream at an 80x60p resolution. Each pixel
is represented by a 16-bit value. Therefore, to transport one frame of the Kinect,
we need roughly 9-10 kilobytes of memory. This is plenty considering the left over
6 kilobytes can be used for instructions. In order to accomplish this we must
change the MSP430G2 from being a device to being a host. The Kinect is a device
58
and not a host. Therefore, we need the MSP430G2 to become a host in order to
initialize and configure the Kinect so that it may send data. The piece of hardware
responsible for the USB hosting is the emulator that is seen on the MSP430G2
launch pad. It comprises of the MSP430F16x, USB type A female adapter, and a
TUSB3410VF, which is a bridge between a USB and a legacy connection like
RS232.
The USB will send its differential signals to the TUSB3410VF. The TUSB3410VF
will convert the differential signals to RS232 signals that can be understood by the
MSP430F16X. The MSP430F16X will then send out the RS232 signals to the
MSP430G2. Below is flow chart of this communication and the schematic
diagrams:
Figure 4.1.4.G: Data Flow (reprinted with permission from Texas Instruments)
(118)
59
Figure 4.1.4.H: MSP430G2 USB Host Schematic (reprinted with permission from
Texas Instruments) (119)
To be able to determine where the robot needs to go and if it has gotten there in
time we need Accelerometers and Magnetometers. Our choice is the MPU 9150.
Figure 4.1.4.I: SparkFun 9 Degrees of Freedom Breakout - MPU-9150 (120)
This chip is capable of providing the accelerometer and magnetometers
information as a Digital output that can be read by a processor. Below is the
schematic diagram of both the MSP430G2 and the MPU9150:
60
Figure 4.1.4.J: MPU-9150 and MSP430G2 Schematic diagrams (reprinted with
permission from Texas Instruments) (121-122)
MPU-9150 Pin Assignments
Pin Number
1
2
3
4-7
8-9
10-11
12-13
14
15
16
17-18
19
20
21-22
23
24
Assignment
GND
NC
VCC
NC
VCC
GND
VCC
NC
GND
NC
GND
NC
GND
NC
P1.6
P1.7
Table 4.1.4.C MPU-9150 to MSP430G2 Pin Assignments
61
MSP430G2
Pin Number
Assignment
1
VCC
2-7
NC
8-13
RSRV
14
SCL
15
SDA
16-19
NC
20
GND
Table 4.1.4.D MSP430G2 to MPU-9150 Pin Assignments
TBC assignments refer to the fact that those pins will be assigned to a later module.
In particular, they will be assigned for motor control and motor feedback. It is
necessary to be able to control the power state of the motor, the rotation direction
of the motor, and the rate at which the motor can be spun. For each of these
conditions three pieces of hardware are needed. For the first condition, controlling
the power state of the motor, we can use a transistor and a micro controller. The
microcontroller provides a discrete voltage to the motor through the transistor. The
transistor acts like a switch or to be more accurate, a gate. When the voltage is
below the “turn on voltage,” the transistor will not allow voltage to flow into a motor.
However, once the microcontroller sends a voltage that exceeds the turn voltage
of the transistor, the “gate is opened,” and the voltage “floods” into the motor, thus
allowing for a discrete “on-off” state of the motor. However, this is not enough. We
must be able to control the direction of rotation. In order to spin the motor backward
we must apply the voltage in reverse. This can be accomplished with an H-Bridge.
The H-bridge will allow forward and reverse rotations by applying a forward or
revere bias voltage. However, there is still the matter of speed control. The nature
of a DC motor is when a voltage is applied the motor spins but once the voltage is
removed the motor stops spinning. The longer the voltage is applied the higher the
number of rotations can be achieved. The speed is the number of rotations per
time unit. The application of voltage can be called a “pulse.” Microcontrollers such
as the MSP430 are capable of doing this with pulse-width-modulation (PWM). This
will now complete the motor control in its entirety. The following diagrams show
the PCB connections between the MSP430G2 and one of the H-Bridge:
62
Figure 4.1.4.K: MSP430G2 (reprinted with permission from Texas Instruments) and
L293D Schematic Diagrams (123)
L293D Pin Assignments
Pin Number
1,8
2
3
4,5,9,12,13
6
7
10,11,14,15
16
Assignment
VCC
P2.0
MOTOR1
GND
MOTOR1
P2.1
NC
VCC2
It should be noted that one H-Bridge is sufficient to control all four wheels. We
have already determined that the wheels on the left hand side will rotate
simultaneously and the wheels on the right hand side will rotate simultaneously.
The H-bridge can control two motors simultaneously. Since the left two will rotate
at the same speed we can put those two in parallel and connect them to the same
side of the H-Bridge. The same goes for the right side. This will reduce the number
of pins required to control the wheels. Normally we would need two microcontroller
pins per motor. This will use up all of our general-purpose pins and we would not
have any left over for feedback processing. If we implement so that all four motors
run on a single H-Bridge we not only save pins (4 to be exact) but we save in cost
by eliminating another H-Bridge. With the four remaining pins, we can connect
encoders to the motors and have, 4 signals fed back to the microcontroller for
checking. We have opted to design our own encoders with a low cost bracket.
Below is the basic schematic of our IR Encoder:
We will let R1 = 100 ohms LED L1 will not burn out and Let R2 = 10k ohms to kill
the current when the IR detector is dark. VCC should be at 1.9V so Vout will not
go over the MSP430G2 pin input limits. The reason is when T1 is on Vout = VCC.
T1 is any IR detector.
63
Figure 4.1.4.L: Infrared Emitter Detector Basic Circuit (Permission Pending) and
Infrared Emitters and Detectors (reprinted with permission from Texas
Instruments) (124-125)
Below are the necessary parts:
Resistors: R1 = 100 ohms, R2 = 10k ohms
Infrared Emitter: L1
Infrared Detector: T1
All electronic components need a turn on voltage of at least 3.3 volts. Other
systems require a power supply of more than 3.3 volt and others require less than
3.3 volts. To be able to supply the proper voltage to each every component we
need a voltage regulator. We picked Texas Instrument’s TPS715 series and the
MC34063AP1.
This particular voltage regulator can handle up to 24 volts of input voltage and can
supply 1.9 volts to 5.0 volts. For each different voltage, they have a voltage
regulator for it. They are also manufactured in an adjustable version as well. We
need the following voltage parameters. For the MSP430’s and CC3000 we require
3.3 Volts. Therefore, the voltage regulator for them would be the TPS71533. For
the VCC of the encoders we will need 1.9 volts. Therefore, for that part we need
the TPS71519. The H-Bridges require 5 volts so the regulator it will be the
TPS71550. For the motors, we need a max voltage of 12 volts with a current max
of 1.5 amps. So in order to achieve this we need the MC34063AP1 voltage
regulator. This supplies voltage based on the PWM signal. The frequency controls
the voltage being supplied to the motor. This means we can control the actual
speed of the motor. The range of voltages go up to the maximum voltage the motor.
For the Kinect we need the same MC34063AP1 voltage regulator.
4.1.5. Motion
The J-Bot will move with a combination of autonomous movement and coordinated
movements. The autonomous movement will come from the sensors on the J-Bot.
64
For example a proximity sensor will alert the robot it is about to run into something
and the robot will stop moving before doing so. The coordinated movements will
come from the computer the robot is communicating with. Using accelerometer,
encoder, and magnetometer information a program will calculate where the robot
should go next.
The IRIM can work in several different settings and environments. The usual
environment will be in some kind of room. As long as the floor is able to be
navigated the J-Bot rover will go around the room. The J-Bot rover will not be able
to climb stairs. So if a certain area is inaccessible that area will not get scanned
past the depth of range of the Microsoft Kinect. The depth of perception of a
Microsoft Kinect is 4m or ~13ft. Any obstacles impeding the J-Bot rover’s
movement will be avoided using the 2D map made from the Kinect’s 3D point
cloud. The J-Bot’s tires are made of rubber and should easily travel on most
surfaces such as: carpet, hardwood floors, tile, concrete, brick, and etc. Since the
Kinect’s depth of perception reaches about 13ft it will not be so useful in wide open
areas where there is nothing to make a point cloud of (not that you would want a
map of an open area anyway). The IRIM works in most temperatures, no promises
are made in extreme conditions (absolute zero, volcanoes).
Accuracy is a big issue in a project like this. The position of the robot rover and
where it should be going are important. Small errors can amount to large ones with
a longer use. For example if the J-Bot is scanning a very large room the errors may
add up towards the end and the rover might encounter obstacles it should not be
encountering. If the position of the robot and the position the computer thinks the
robot is in differ too greatly this will cause problems. This is why the magnetometer,
accelerometer, and encoder are being used. With information from these modules
the J-Bot rover can keep track of its position and correct its self from deviating from
its path. It is rare for a vehicle to move in a straight line or follow a path perfectly.
Extensive testing will have to be done and data must be recorded to figure out the
tendencies of the rover. For example if the rover pulls to the right after a certain
distance traveled or amount of degrees deviated from its original intended heading
passes a threshold it will correct its self. Error can occur by making complex
movements also. For the Kinect to have optimal scanning the J-Bot will make a
360 degree turn at waypoints. If the turn was not exactly 360 degrees error arise,
luckily the magnetometer will correct these mistakes. The goal is to achieve a 98%
accuracy level. Data will be collected through testing to be able to set distance and
angle values before making error correction or detection.
Turning will be an important aspect of moving the rover. As mentioned before it will
be easy to move the robot forward or backward. Turning is a different story. To
turn the motors one pair of motors on the same side have to turn more slowly than
the ones on the opposite side. The greater the difference between the two the
sharper the turn. This means having to change the voltage the regulators put out
to the motors. The regulation of the voltage of each side will need to be
independent of each other to achieve this result.
65
As far as speed is concerned it will not be an important factor. We will not be drag
racing with the J-Bot rover. The J-Bot will need to move fast enough as to not be
boring to look at. What is important is that the motors provide enough torque to
move the weight on the rover. The motors will almost always be operated at 6V
which gives it a no load speed of 200 RPM. At 3V the rover has a no load speed
of 100 RPM. The J-Bot should not be moving that quickly anyway because it could
mess up the Kinect’s ability to create a point cloud. Also, if the J-Bot takes off too
quickly or is moving too fast and comes to a sudden stop it could knock the Kinect
out of its holding place. This would not be good at all.
4.2. Software Design
4.2.1. Software Design Overview
The software is the brain of the project, thus the software design is an important
factor that determine the complexity, reusability, and extensibility of the whole
project. The following figure (Figure 4.2.1.a – Software Overview Diagram)
described the general design of the high level software component (little or no
direct interaction with hardware devices).
In the (Figure 4.2.1.a) the top most ovals are the list of expected inputs from either
device drivers, simulated data, or data collected. The boxes are the subsystem
that handle a specific task. The directed arrows represent the flow of data from
drivers or sub system to another. For 3D scanning data, the input go through point
cloud multiplexer to convert into point cloud data that can be used for mapping and
navigation. This also is the point where different setting can be set to determine
how data being handle and process. Dead reckoning subsystem as the name
implied are using feedback from motor encoders and data from inertia
measurement unit (IMU) to calculate the robot displacement, thus in general
determine the current location and rotation of robot in the environment. Robot
Operating System (ROS) is a set of open source software libraries that help handle
the data. For this project specific, ROS was used to handle sharing resources,
threading, and increase the modulation of the project. Mapping is subsystem that
attempt to map the environment given point cloud data, robot orientation, and
possibly landmarks from image. The subsystem may possibly using simultaneous
localization and mapping (SLAM) to create a map as the robot move within the
environment. Navigation subsystem are one that taking a map produce by
mapping subsystem and perform path finding algorithm to find the shortest path if
available to the destination. The navigation system need to take into account the
size of the robot, turning radius, and obstacles to determine the path. Some
common algorithms being consider including iterative deepening, A*, and D*.
Finally communication subsystem mainly handles sending command to the robot
and receive the sensors data from the robot. Currently there are two approach
being considered, one is directly convert the commands into byte code and send
over the network, another approach is simply divide the command into sub66
command and have corresponded drivers to convert the sub-command to byte
code and finally forward to system that transmitting the signal. (128-130)
Indoor
Scanning Data
Outdoor
Scanning Data
Collected Data
Encoders
Data
Inertia
Measurement
Unit Data
Camera
- Merge Data from multiple in put
- Switch Input source depend on environment
conditions
- Using the data from motor
encoders and IMU to calculate
the robot position
- Publish the data that can be used by other
process
Point Cloud
Data
Images
Robot
orientation
vector
Environment Map
- Using the robot orientation,
point cloud data, and possibly
combine with image processing
to create a map of the
environment.
- Given a map, try to
navigate through the
environment
Robot Command
- Communicate with the ro bot
platform and send appropriate
commands through network
(Bluetooth or wireless)
Figure 4.2.1.a – Software Overview Diagram
4.2.2. Robot Operating System (ROS)
For this project, aside from being a functional robot, the extensibility and
exchangeability are essential. Robot operating system is a set of open source
libraries that help speed up the process of building a functional robot. In specific,
ROS abstract the process of threading thus allow the software to function more
efficiently and independently. ROS also support sharing resources between
different processes thus typically reduce memory usage. (128)
The software component of the project will based on ROS publish-subscribe
architecture. A simple way to describe is in this project, ROS will act as a black
board where data can be publish by multiple different processes, and at the same
time the same data can be subscribe by multiple processes. (128)
In the (Figure 4.2.2.a) a data can be subscribe by multiple process even though
there are no process publishing it. In this event, no actual data will be process until
there is a process that publish the data. When the data is received, ROS will trigger
67
the function in subscribing processes, thus the whole system are technically event
driven system rather than polling.
In (Figure 4.2.2.b) a data can be published by multiple processes, in this cases
ROS can be configure to maintain a queue of certain size thus reduce the problem
of processes collision and synchronization between multiple processes.
Point Cloud
Data
Figure 4.2.2.a – Multiple Subscribers
Robot
Commands
Queue
Figure 4.2.2.b – Multiple Publishers
In the (Figure 4.2.2.c) is the demonstration of two processes subscribed to a topic
called “/chatter”, which is a topic that contain a “string”. Since there is no process
that publishing the data, there is no actual data being received. ROS however
provided a software called “rqt_graph” that allow to monitor the connections
between processes and topics.
In the (Figure 4.2.2.d) is the demonstration of two processes publishing to the
same topic called “/chatter”. Again, since there is no process that subscribe to the
data, there is no actual data being process.
68
Figure 4.2.2.c – Multiple Subscribers demo on Terminal
Figure 4.2.2.d – Multiple Publishers demo on Terminal
In the (Figure 4.2.2.e) is the combination of two processes publish to the same
topic and two processes subscribe to the topic. In this case two publishing
processes are simulated to send the data at different rates from each other, this is
69
similar to real life scenario where different sensors can have different rate of output
or when the result from one process is more expected than others. As the result,
the different rate of publish/subscribe data allow developers to prioritize resources
for important processes rather than distribute computational power evenly among
all the processes.
Figure 4.2.2.e – Multiple Publishers and Subscribers with different Publish rate
4.2.3. Point Cloud Library (PCL)
The goal of the project is not just completing the robot and navigation system but
also allow the users/developers to exchange and expand different devices depend
on the goal’s specific needs. Thus even though this project was design to be an
indoor robot, it is important that the software allow users/developers to switch out
indoor scanning devices (Kinect) with a more powerful outdoor scanning devices
(LIDAR). (129)
Therefore this project use point cloud to store depth information of the scanning
devices. By converting the scanning data into point cloud data, the project abstract
the processing layer from the device specific, thus any process that require
scanning data can be work independent with simulated data or previously collected
data without the present of actual scanning devices. (129)
The point cloud library not only allow the scanning devices to be exchange but also
allow multiple devices to work in conjunction all together at the same time. The
following (Figure 4.2.3.a) show the general idea of point cloud abstraction and
multiple functional scanning devices.
70
Collected Point
Cloud Data
Point Cloud
Output
- Merge Data from multiple input
- Switch Input source depend on
environment conditions
Indoor Scanning
Device
- Publish the data that can be
used by other process
Outdoor
Scanning Device
Figure 4.2.3.a – Point cloud application for project
From above figure, (Figure 4.2.3.a), depend on the configuration, the project
should allow the different choices of how the system handle input from multiple
devices. For example, the robot can used high power outdoor scanning device
while outside then switch to lower power indoor scanning device when inside, or
simply reduce the rate of collecting data of outdoor scanning device while inside.
Since the robot platform is small, there is a limit of how much processing power
and memory it can have, thus it is important to take note that the point cloud data
is memory consuming as the explored area become greater. The software need a
way to reduce the amount of point cloud data such as filter area of interest (only
keep the point cloud of certain area or height), flatten data (the height of all point
cloud are set on the same plane), density reduction (limit the density of point cloud
in the area), point absorption (new points that are closed to existing points will not
be remembered), and polygon representation (polygon of points cloud that present
the surface).
Filtering area of interest is the basic technique of computer vision. When a robot
receive the image feed from camera, it is a common technique to filter out the
undesired color, or isolate a specific color. The same concept can be apply to point
cloud. By specify a certain area relative to the 3D sensor (origin of point cloud) the
amount of point cloud can be significantly reduced.
The (Figure 4.2.3.b) demonstrate a simple filtering using the height of point cloud.
The technique is simple to implement, computationally fast, and very effective for
navigating and mapping. For this project, the robot is height is about one foot, thus
it is very reasonable to filter out any point that is higher than one foot. The filtered
point cloud not only small in memory but also provide a side benefit that the robot
now can move under certain areas such as table, chair, or horizontal bar.
71
Also in this project, the robot was mean to work within a building or place with flat
floor, thus the robot can take advantage of this and also reduce the point cloud
around the plane of the floor as displayed in (Figure 4.2.3.c). Note that in the
(Figure 4.2.3.c) some points lower than the floor plane were not removed, it is
important to keep such points because it tell that there is an area where the ground
lower than acceptable level. When encounter such situation, the points can be
treated as any point above the floor plane and marked as obstacles.
Height of
Interest
Figure 4.2.3.b – Point Cloud Filtering using Height
Height of
Interest
Floor Plane
Floor Plane
Figure 4.2.3.c – Point Cloud Filtering using Height, and Floor removal
For simple robot such as this project, there is no value to know whether a wall have
hole on it or there are one objects stacked on another, thus there is an option to
flatten the point cloud to a single plane so it can easily be used for navigate and
mapping. The (Figure4.2.3.d) show how a filtered point cloud being flatten to a
plane, let called it obstacle plane. The process of flattening the point cloud can be
done at the same time as filtering the point cloud, thus it is a relatively cheap in
computation. While this technique is good for navigating or mapping, it is at the
same time reduce the detail of scanned data. Thus as mention before, the
technique only useful for simple robot that does not required to interact with
environment.
72
Obstacle Plane
Obstacle Plane
Floor Plane
Floor Plane
Figure 4.2.3.d – Filtered Point Cloud being Flatten to Obstacle Plane
Filtering point cloud is fast and simple but when multiple point clouds are being
stored rather than being disposed, over time the point clouds can overlap each
other. Multiple point cloud held together can take a lot of memory space, thus result
in performance drop, therefore, it is important to resolve the issue. One of the
available options is to reduce the point cloud in the area to a specific amount, in
short density limiting. The (Figure 4.2.3.e) show how a dense point cloud can be
reduced to save memory. The concept of density reduction is in a group of point
clouds that are too closed to each other, only keep one of them and remove other
points. This in general retain the point cloud integrity and achieve goal of memory
saving. The nature of this technique is trade of the finery of point cloud data for
memory save. The method is generally similar to the resolution of image, whereas
a high resolution image may look sharp and clear but the size would be very big,
while a low resolution image is smaller in size but blurry and lack of details. Also
note that the point cloud present the point in 3D space thus computing the distance
between the points, and checking for close points around a certain point would is
not very cheap in computation.
Figure 4.2.3.e – Overlap Point Cloud (Left) Density Reduction (Right)
73
While density reduction is good to save memory space, it would cost a lot of
computation when the size of point cloud grow. Thus rather than reduce the density
for the entire point cloud stack, it is more reasonable to perform the reduction when
the new set of point cloud is received. For each point in the new point cloud, simply
check if there already any point cloud nearby, if there is, then either not add the
new point cloud to the already exist, or remove the detected points and add the
new one places. The (Figure 4.2.3.f) show the reduction of point cloud when new
point cloud is received, the new point cloud will not be added if a point is detected
nearby. In the (Figure 4.2.3.f), the left side is the old point cloud (black) and new
point cloud (while). After reduction (right), only points that have no closed
neighbors will be added (grey point).
Figure 4.2.3.f – (Left) New Point Cloud (White) Overlap Old Point Cloud (Black)
(Right) Remain Point Cloud (Grey) that be added
Of all the mentioned methods of memory saving, they all have the same problem
that is as the robot explore the area, the size of existing point cloud grow
exponentially together with the explored environment, and as the result, will limit
the area of operation of the robot. Not only that, most of the methods are tailored
based on robot navigation reference, thus area that robot can go through may not
available for human, and the area that human can maneuver through could be
impossible for robot to know. Such limitation could easily be noticed for scout
drone, or search and rescue robot. One potential solution for the problem is
actually a concept that is already used in video game industry, which is polygon
representation. In a game, there are exist many objects, and a character can using
ray casting method to determine the distance to an object. While the robot is
different from a character in a game, however, if the point cloud can be clustering
together and using those points to create a polygon to represent the object, then
a great amount of memory can be saved. The main idea can be understand in two
stages, first is to create a polygon from known point cloud, second is to determine
if the new point cloud is belong to the object.
74
The concept of create polygon using point cloud is well known in modeling and
simulation field. It is however often take a lot of computation, thus not very practical
for robot, which function in real time. A fast and simple way to create a polygon
from known point cloud is by connecting the points that are closed to each other.
The (Figure 4.2.3.g) demonstrate the concept of create polygon by connecting
points that are closed together from newly received point cloud. On the left of
(Figure 4.2.3.g) is a simple connected scheme where each point only connected
to two other point that closed to it, the last point what cannot find any closer point
will reconnected to the starting point. The scheme is less refine and may miss
some important point, it is however relatively fast and simpler than highly
connected scheme, which is to the right of (Figure 4.2.3.g). Notice that there are
some point that is not include to the polygon because they are too far away for
others, they could either left as it is for a couple scan since there is possibility that
they would be included to the other scan, or they could simple regarded as noise
and be removed. The goal here is a cluster of point cloud now can be represent
as an object using a much smaller group of point thus greatly reduce the memory
usage.
Figure 4.2.3.g – (Left) Simply Connection Polygon
(Right) Highly Connected Polygon
Once the objects were created, every time a new point cloud are receive, it will be
tested against the already exist object. If the tested points collide with the existing
object, they will be removed. The remained point cloud will connect together to
create a new object as shown in (Figure 4.2.3.h). Notice that there some of the
remained points can create a small insignificant object like the one made of three
grey points in (Figure 4.2.3.h), it is typically reasonable to remove an object that
was created by a small number of points.
75
Figure 4.2.3.h – New Point Cloud absorb by Objects
All the point cloud figures in this section (4.2.3.) were represented as 2D data just
to show the proof of concept. The actual point cloud data will be stored and
processed in 3D space, thus much more complex and computational intensive.
Also noted that point cloud received from 3D scanner may contain noise from the
devices, shock from movement of the robot, as well as false data due to inaccurate
orientation of the robot. Such problem will also need to be resolved in order to
display correctly.
4.2.4. 3D Display
While there is no need to display the point cloud data to construct navigation map
or navigate in the environment, the image can convey a lot of information to human.
Thus it is very important for human to be able to observe the environment collected
by robot and analyze the information from the robot point of view.
It is also important to take note that I/O operation is slow and computational
intensive, thus for 3D data displaying will be limited for high end computer or during
development process rather than mandatory, especially when human can make
sense in most of the situation with just 2D image from camera.
The (Figure 4.2.4.a) is the accumulated point cloud of the environment in one
revolution around the robot. In this image, the point cloud simply overlapping each
other and slowly disappear over time. Therefore as the robot move to another
point, it would not be able to remember what it has seen. On the other hand, if the
point cloud was to be allow to remain forever without any algorithm to resolve the
stacking of points on the same spot, the system memory would run out and the
program will either freeze for crash. The correct 3D display of the environment
should filter out the overlapping point cloud so that only a single set of point cloud
to forever remain on the surface of the object. With only a single set of point cloud
to cover the area, there will be more memory to spared for bigger environment,
thus allow the robot to remember that object location even when it no longer able
to see the objects.
76
Figure 4.2.4.a – One Revolution of Point Cloud around the Robot in Simulated
Environment
The (Figure 4.2.4.a) was produced using the configuration parameters from
turtlebot library, an open source library that built for turtlebot robot, then run on
simulation software gazebo and display using ROS integrated software rviz.
Gazebo is a great tool to simulate the environment but the learning curve is steep.
Rviz is the software to view the ROS topics and good for developers, it is however
unnecessary for end users who are not supposed to configure the parameter of
the ROS system.
4.2.5. Simultaneous Localization and Mapping (SLAM)
As the robot moving in the world, it is important to know the location of the robot
with in the environment and the map of the environment so that the robot can
navigate through with efficiency. The outdoor robot often equipped with high
accuracy Attitude and Heading Reference System (AHRS), which often consist of
GPS, gyroscopes, accelerometers, and magnetometer, thus the localizing an
outdoor robot is relatively easier than indoor robot and from then it can do the
mapping with less problem. Since this project feature indoor robot, localization and
mapping is a very difficult problem because for a robot to know where it is within
the environment it need an accurate map. On the other hand, for a robot to produce
accurate map it need to know where it is within the environment. Both localization
and mapping are strongly depend on each other, therefore simultaneous. In this
project, the robot will be using gMapping which is openSLAM integrated to ROS.
The gMapping provide a solution for localization and mapping by using local map
77
and global map. As the robot move around the environment, it recorded a set of
data about the environment and store in local map, then by compare the local map
with global map, it would be able to estimate the probability of its location and then
merge the local map to global map. (130)
In the (Figure 4.2.5.a) is the map produced by gMapping in a simulated
environment, which the objects are mostly static. The real world however is very
dynamic thus what was there before may no longer be there the next time the robot
look at it. The robot not only need to map the objects to the global map but also
need to know how to remove the objects from the map if it no longer there. It is
also important to note that the real world will not produce perfect scanning data
whether it can be noise produce by the devices, people who happened to walked
by, or dynamic objects in the environment.
Figure 4.2.5.a – gMapping in Simulated Environment.
Another problem with the gMapping is that it compare the scanning data with 2D
map, which mean it does not make full use of the environment landmark and
structure. The (Figure 4.2.5.b) show simple pair of local map and global map. From
the local map, it is difficult to determine where the local map is in the global map.
The effect is especially severe in the environment where multiple place in the
global map have the same structure similar as in (Figure 4.2.5.c). The gMapping
78
would then failed to make used of landmarks, colors, signs, and other components
that may help identify the location.
Figure 4.2.5.b – A pair of local map and global map
Figure 4.2.5.c – A pair of local map and global map (multiple places with similar
structure)
79
4.2.6. Navigation
In modern world, as seen in many video game and simulation, navigation may
appear to be a rather simple problem to solve. It is however not entirely correct as
in simulation, the world is known, the map is perfectly accurate, the objects are
easy to recognized, and there is no noise from scanning. For a robot, however,
navigation remain a challenge. There is no guarantee that the robot movements
will always perfect, that mean just because the robot was trying to straight do not
mean it will physically go a perfect straight line. Also the world beyond robot line
of sight remain dynamic thus the original plan may no longer correct as the robot
execute the plan. As the result, it is important to make sure that the robot is capable
of dynamically change the plan when unexpected obstacles present within the
planned path.
Some well-known path finding are A*, D*, Dijkstra, and Wavefront planner. A* is
good to quickly find the solution with known map and relatively simple to
implement. It is the most standard path finding algorithm used in video game
industry, where the environment is always known. D* is good with dynamic
environment that change often. Dijkstra is a good path planning algorithm for
searching multiple places or devise multiple plans. D* dynamic planning is very
efficient compared to re-compute the plan, thus also often used in many robots,
though the algorithm is more complex and hard to implement. Dijkstra is another
common path finding algorithm that can be used to plan the paths not to a single
target but multiple targets, and note that the paths are also the shortest paths.
Dijkstra can also be used to compute multiple path to the same target, thus if one
plan is fail, there always an option to used other plans. Wavefront planner is a well
function for a known map, static goal, and less dynamic environment since it
provide the shortest path to the goal from any location. However, when the area is
unknown, and the world can change quickly, wavefront planner is an expensive
algorithm. For this project, it would be beneficial to implement different path finding
algorithm to be executed at different situation. When the robot first receive the way
point to destination, it would use the A* to quickly compute the path, if the world is
changing, it would then switch to D*.
4.2.7. Autonomous System
A robot that can navigate through the environment is nice, but how does it decide
the destination. Whether the robot is in fully autonomous mode, semi-autonomous,
tele operating, or remote control by human, there are a need to implement some
special behavior that could prevent the robot from damage human’s properties, or
damage itself. Other mechanisms such as fail safe, energy saving, or power report
are essentially important for a robot as well. Still sometime, human can make a
judgment that the robot need to perform a certain action that may result damage
the property or robot, hence there also a need to allow human to manually override
any preset behavior as they see fit. There is also cases where the robot may
receive false data either due to devices error, environment conditions, or
interference from external source, such situations must also be resolved in certain
80
way. Thus generally, the robot require some form of autonomous system or a more
complex intelligence system.
There are many way to implement an autonomous system. One of the most
common autonomous system is finite state machine, which is used a lot in video
game industry, robotics field as well as commercially smart products. The finite
state machine offer a fixed pattern of behaviors, where a behavior will be execute
once certain conditions are triggered. The behavior within a finite state machine is
predictable, easy to test, debug, and control. For most robot in general and this
project in specific, it is a good idea to implement the finite state machine at the very
bottom level, where behaviors such as stop when detect object, or sleep when no
command is received. The down side of finite state machine is that the robot are
fixed with the known pattern of behavior and cannot act outside of the preset
conditions. Thus when encounter unknown conditions, or when the developers
failed to account for all the possible situations, the robot may start to behave
strangely and sometime dangerously, such as ram over a glass or fall off the table.
Another approach for robot that is current being study is reinforce learning. Used
in few video games, and some research robots, reinforce learning is much harder
to predict and difficult to test, debug, and reproduce, since the trigger conditions
for a certain behavior could be difficult to reproduce, or just some noise from
sensing devices. Nevertheless, reinforce learning may possibly produce a more
flexible, diverse, seemingly intelligence behaviors, and, to many people, just plain
entertained interesting behaviors.
For this project, the finite state machine for the bottom level will consist of simple
behavior, the state machine here will be called reactive system. The reactive
system is the most basic and fundamental behavior of the robot in which the robot
will prioritize over any command other than manually override human given
command. The (Figure 4.2.7.a) is the basic finite state machine graph of reactive
system. The state “Complete Stop” is .when the robot attempt to shut down the
whole system as if the user issue shut down command. The action would prevent
the robot from suffer any electrical damage or loss of data due to sudden loss of
power. The state “Stop” is an emergency state where robot may encounter
something totally unexpected or when user want the robot stop doing whatever it
is doing. The “Move Back” state is a simple reactive to help robot avoid suffer any
damage due to the change in the environment such as moving object, or when
there is error in the decision system or navigation system that may cause the robot
to crash into object. The state, under normal condition, would save the robot from
damage such as falling or crash. The “Wait for Command” state literally take
whatever command either from decision system or human and execute. It is in this
state that human can manually override the reactive system, and command robot
perform task that it normally would not perform, including crash to the wall at full
speed and drive off the table.
81
While the reactive system is simple, it is naturally not going to do much other than
waiting for human command. Thus there is a need for a higher level state machine
where the decision is made based on sensory data and data processing. The
(Figure 4.2.7.b) is the basic design of decision making system, also called planning
system.
Finished
Move Back
Robot tilt forward
OR
Detected Object too close
Power Online
Complete Stop
Waiting for Command
Lowe Power
Low Power
Emergency Stop
Stop
Emergency Released
Figure 4.2.7.a – Finite State Machine of Reactive System
From the (Figure 4.2.7.b), the robot will have the most basic states “Idle”, “Stop”,
“Mapping”, Navigating”. “Idle” state is the fundamental state where the robot will
conserves its energy while waiting for command from human. When in this state,
the robot may follow the basic reaction such as “Move Back” and will not attempt
to return to original position. That behavior can be understand as when the robot
was not told to remain in place, then it is practically free to do anything as
necessary. This project is design so that it would be as general as possible and
maximize extensibility. Therefore such behavior is very favorable for general robot,
especially if the robot is the kind that work in museum, or as helper. The general
robot then can be implemented with other non-essential states, where the robot
could start execute when it is not occupied doing human command, or simple
wandering around the environment where it may randomly receive command from
human, rather than having human go to them to give command. Similar to “Idle”
state, “Waiting” state is the state in which robot also conserves its energy while
waiting for command from human. The different is the robot will not take any
command with lower priority until it is released from the “Waiting” state. Also if the
robot by any reason have to move from the position, it will always attempt to return
82
back to waiting place. This is a standard state in most robot system, in which the
robot is locked in specific place for further command. The “Mapping” state is the
main function of this project. While in this state, the robot will attempt to map out
the environment as much as possible. Since the field of operation may be large
and unnecessary to map out the entire area, it is important that the mapping action
can be interrupted or aborted. The final state is “Navigating”, with the known map,
the robot should be able to navigate through the environment. If the destination,
however, is not within the boundary of known map, the robot will change to
“Mapping” state and attempt to map the area to the destination. There is no
guarantee that the destination can be reached or for any reason the robot cannot
map the area to the destination, the state require condition to abort the task.
No matter what state the robot currently in, the robot must always available to
receive the command from human, the command could be vary from adding the
next command to the queue, having the robot to abort the currently task and move
to the next one, or simple clear out the queue task and return to “Idle” state. Since
one command can interfere or even interrupted the currently being executed task
as at worst the whole chain of task within the queue, it is require that each
command be marked with priority level. It is so that human can confirm that they
know exactly what the consequence of the command.
Request Stop
with Release Condition
Waiting
Condition Meet
Resume
Condition Meet
Requested Stop
with Release Condition
Requested Stop
with Release Condition
Resume
Condition Meet
Path to Destination
Mapped
OR
Receice Waypoint
Request to Explore
the Area
Idle
Mapping
No more unknown Area
OR
Interrupted
No Path to
Destination
Arrived at Destination
OR
Interrupted
Navigating
Receive Destination Way Point
Figure 4.2.7.b – Basic Finite State Machine of Planning System
83
4.2.8.
Accelerometer Communication
The Accelerometer’s data is raw input. It only interfaces with the MCU and nothing
else. The MCU will either do double integration to determine the position value or
do a single integration or compare the velocity to the target velocity. The master
computer will send either a target velocity and time interval or a desired distance.
Based on which implementation would be the “best fit” in terms of accuracy,
performance, and efficiency.
To initialize the system we need to send a signal straight to the MCU to let it know
to start receiving data from the computer. This initial signal will set the “fetch” bit
so that the MCU will receive data. MCU will then sample the Accelerometer’s data
and determine whether it should continue moving or whether it should stop and
fetch the next set of coordinates. Once it starts moving, the fetch bit will be set to
“low” indicating that the MCU should not receive any data. It is should also send
similar signal to the computer to temporarily disregard the Kinect feed. This will
prevent unnecessary computation. Once MCU has received the information about
getting to the waypoint, it will spin the motors until it has reached the right amount
of seconds and the target speed or it has traveled the desired distance, whichever
format the computer sends. Once the condition is met, the fetch signal is set to
high allowing the robot to continue navigating. Below the figure describes the
subsystem.
Figure 4.2.8.A: High-Level Representation of Accelerometer
Communication
84
4.2.9.
Magnetometer Communication
Along with the information for traveling the right amount of distance, the heading
is also important information. The computer needs to know what the current
direction of the robot is so that it is able to tell the robot to which direction it should
turn before moving. The magnetometer information needs to be used by both MCU
and the computer. Therefore, the MCU must now transport the Magnetometer’s
information as well as the Kinect feed. The magnetometer information is only sent
to the computer when the robot comes to stand still and the signal for fetch is set
to high.
The information data received by the computer is going to be transmitted by the
magnetometer to the msp430, and the msp430 would communicate with the
computer. Once the information is in the computer the data is used for the
calculation of the expected location of the robot. The computer will then compute
the desired heading as an offset of the current heading. Based on the results the
computer will send the offset data back to the MSP430 which is going to send the
calculated data back to the msp430 on the motor controller. Then the information
will be used as a reference and will turn to the proper heading.
Figure 4.2.9.C: High-Level Representation of Magnetometer
Communication
85
4.2.10.
Encoder Communication
To account for possible error in acceleration, we need the encoder to provide the
angular velocity of the wheels. We can translate this angular velocity to
translational velocity by doing simple calculations. This Encoder information will be
feed into the MCU so that it can determine whether the motors need to keep
spinning or not. To use the encoder as the judge, we would need to be provided
the distance beforehand and count the number of rotations occurred. This will yield
the distance traveled per time unit. The procedure is very similar to the
accelerometer’s procedure. The only difference is in how the velocity or distance
traveled is derived.
Figure 4.2.10.D: High-Level Representation of Encoder
Communication
86
4.2.11. Wireless Communication
All communication between the computer and the MCU will be through the internet.
However, since both devices will be connected to the same IP address it will be
difficult for the Wi-Fi module of both the MCU and Computer to differentiate which
packets are from itself and which are from the other Wi-Fi module. So in order for
their not to be a conflict we need a 2 more IP address that will be recognized as a
recipient and a transmitter. In other words, we need two separate web servers.
The computer will send packets to the webserver 1 and will actively wait for a
packet from the webserver 2. The webserver 1 will relay the data packet to the
MCU. The MCU will also be sending the Kinects’ visual feed to web server 2.
Having two webservers reduces dependencies. Below is a diagram of how the five
are connected.
Figure 4.2.11.A: High-Level Wireless Communication Software Architecture
The wireless communication from the computer standpoint expects the data to be
sent as a USB form after gathering the data the internal hardware from computer
would convert the data into RS232 for interpretation.
The model used for communication works as follows, the Kinect sends data to
the IBM Bluemix which is the server. The server is going to have an IP address
where the data will be located. The software from the computer would retrieve
the data from the server through a port which is going to be allocated for this
communication. The ROS would utilize the data and carry out the necessary
87
procedures to display continuous real time video using the frames generated by
the Kinect.
4.2.12.
Programming Languages
During our project we found a few languages to meet the requirements to realize
the work. The list of the following languages are the possible choices that meet the
criterion of the project based on the restrictions of the hardware and software.



C – Is a programming language fully supported by the Libfreenect and
OpenCV libraries.
C++ - This language is supported by Libfreenect, the Robot Operating
System.
Python – This is another language supported by both the Libfreenect and
the Robot Operating System.
The programming languages our group are going to use is definitely C++. This
language besides the flexibility and object oriented features it provides, it is also
one of the few languages supported by the Robotic Operating System. Since there
were only two programming languages to choose from there was not much
decision making during the process of choosing a language. The other option
besides C++ was python, but we do not have as much experience with this as we
have with C or C++. Furthermore, in case we decide to implement image display
later into the design of the project the optimal library to process our imaging data
would be OpenCV, since is written in C++ this will provide consistency in the
software. It is prefer to realize if possible all the applications in a single language.
This will facilitate future troubleshooting of the software during the testing phase
as oppose to have multiple languages implemented in different parts of the project.
With more than one programming language in our project the troubleshooting part
of the project can become hectic, since some of the members in the group may
have more experience than others time have to be spend on scheduling who is in
charge of the troubleshooting of a specific part of the project.
4.2.13.
IDE
For this project to manipulate the data and develop applications for the Kinect, we
are going to use various platforms. The Visual Studio 2013 was first used to check
the Kinect SDK packages. In the preliminary stages of the project this IDE was
used to get ourselves familiar with the code and the different functions
implemented already in the SDK for Kinect. Visual Studio support various platform
of the windows operating system but in this project we are planning to work with
the Robotic Operating System or ROS, which only supports the Linux Ubuntu
platform, for this reason it is not possible to employ the Visual Studio IDE for
development purposes but only to test the different functions from the SDK with
the Kinect hardware connected.
Since we are using the robotic operating system, we have to find alternatives IDEs
which are supported by Ubuntu. ROS supports various IDEs such as:
88

Eclipse – This development environment is the most likely to be employed
by our group to develop, maintain, and troubleshoot the code necessary to
realize the applications we desired our robot to performed. At stage of the
project we have decided this to be our primary IDE for realization of the
project.
 CodeBlocks – This IDE also have the C and C++ languages available for
development purposes.
 Emacs – is a text editor similar to the gedit text editor built in the Ubuntu
platform. This editor lets the developer browse through the ROS package
file systems.
 Vim – This IDE is not fully supported by ROS because the support is
provided thanks to a plugin. We are not aware of the capabilities and
function we can create with this environment. It is not one of the possible
IDEs for the project.
 NetBeans – it is an IDE written in Java with support of many languages,
among them C++. The group has consider this IDE but we do not have
previous experience with it.
 QtCreator – it does not required a setup. The developer may work from the
terminal.
4.2.14.
Linux
Linux Ubuntu is the operating system the group has chosen to work on the
development of applications for the navigation and mapping functions. This is due
to the free access for the Ubuntu operating system. Ubuntu is a user-friendly OS,
similar to the operating systems installed on our personal computers which
provides us with a familiar interface. Linux contains other versions of operating
systems. Some of these distributions are the most popular and the majority are not
supported by ROS.
Mint Linux is a distribution of Linux which has a well support interface for desktops,
this version of Linux is one of the most popular in used nowadays along with
Ubuntu. This distribution is not officially supported by ROS but it may serve as an
experimental platform in the future as more users become interested in the version.
Mageia is also a recognized version but not as popular as the mint version,
However, in recent years the popularity of this distribution has increased rapidly.
Mageia is not supported by the ROS but is an alternative of the Ubuntu version for
development of other applications except anything that has to do with the robotic
operating system.
Another of the popular distributions of the Linux operating system is the Fedora
version. This version is lower in popularity as compare to the other versions
discussed above. Fedora uses GNOME 3.x as its package management. (25)
The last version of Linux to be discussed according to its popularity is called
Debian. This distribution is one of the first versions being develop during the early
90s. Many versions as of today are based on Debian, the most popular version
based on this distribution is the Linux Ubuntu. (25)
89
4.2.15.
Windows
Windows is suitable for development with the Kinect since the sensor is
manufacture by windows. In the design stages to realize our project various
restrictions were encountered. The first problem we ran into was on how we can
develop applications for the Kinect without the software development kit, as the
SDK supports windows only. After an extensive research about what platforms
suitable to get our robot running, we decided to employ the robotic operating
system. Previous projects about mapping with an autonomous robot used the ROS
to simplify the amount of functions needed to realized navigation and mapping
since the operating system already comes with packages which alleviate the
amount of time that a developer need to spend on creating an application from
scratch.
The first released of the Kinect SDK to allow developers create new applications
for the Kinect and employ the Kinect in other areas other than gaming itself
supported Windows 7.
The following is a list of the operating systems compatible with the software
development kit:




Windows 7
Windows 8
Windows 8.1
Windows Embedded 8
4.3. Design Summary
4.3.1. Design Overview
The general design of the project consists of the robot platform which will be
mounted with 3D sensor, proximity sensor, and motors encoders. The robot itself
is equipped with a reactive system, which simply uses a proximity sensor to avoid
collision, and motor encoders to maintain desired speed. The robot will send the
3D data over the network to the control center where it will processed the received
data and return back an appropriate command. The control center will mainly use
the 3D data received from the robot platform to perform mapping and navigation.
The robot will use a finite state machine to control, whether a human is controlling
the robot or it is in autonomous mode. The state machine will also be used to allow
the robot to switch the appropriate behavior depending on the situation. Another
task of control center is provide graphical user interface so human observe the
state of the robot, and control the robot from distance.
90
Point Cloud
Data
Mapping
System
Navigation
System
Graphical
User
Interface
Control
Center
Finite State
Machine
Kinect
Robot
Platform
Reactive
System
Sonar
Motors
Encoder
General System Design
4.3.2. Software System
A simple summary of the software system can be seen in (Figure 4.3.2.a). The
control center will take in the raw data from sensors, which usually depend on the
driver software of each individual device, and manipulate or convert the data to a
more general form such as point cloud, image matrix, etc… Once converted, the
data from sensors then can be used by other processes such as mapping,
navigating, filtering, and construct 3D display. Using the point cloud data, the robot
will attempt to construct a map of the environment. Then using the map, the robot
will able to navigate within the known world. The autonomous system take in all
the information including sensory data, map, and navigation plan and convert to
command, in which the robot would then execute. It is also the responsibility of the
autonomous system to report the current state of the robot. The report to GUI may
include the current velocity of the robot, current state of action, sensory data, and
planned path. Also from the GUI, the user should be able to give direct command
91
to the robot, such command should have higher priority than most command from
autonomous system.
Mapping
Sensors Data
Motors Controller
Input
Processing
Output
Processing
Point Cloud
Image
3D Manipulating
Image Processing
Navigation
Velocity
Autonomous
Command
GUI
Figure 4.3.2.a – Software System
4.3.3. Hardware Summary
The Wi-Fi module uses is single antenna to transmit and receive data. It is
connected to the Communication Module via the Inter-Integrated Circuit interface
(I2C). Figure 4.3.3.B shows he Communication module in more detail.
92
Figure 4.3.3.A High Level Representation
The Wi-Fi module uses is single antenna to transmit and receive data. It is
connected to the Communication Module via the Inter-Integrated Circuit interface
(I2C). Below shows he Communication module in more detail:
Figure 4.3.3.B Communication Module Flow Chart
The MSP430G2 receives a maximum of two inputs at any given time. The Kinect
feed will be continuously sent to the processor. However, it only transmits that data
when the Computer requests for it. The Kinect’s feed is sampled when the
computer receives a request for coordinates. Once the request is sent, the Kinect
feed and current heading is sent over the Wi-Fi to the computer. The Computer
will then process the feed and determine the waypoint. It will send the waypoint
data to the MSP430G2. The MSP430G2 will process this data and send it to
Locomotion in a form that locomotion can understand. Then movement occurs.
When robot comes to a stop (i.e. arrived at waypoint), Locomotion module will send
93
a coordinate request signal along with the current heading. The MSP430G2 will
relay this request and data to the computer and the whole cycle begins. The reason
the MSP430G2 is being a relay is because the number of I2C pins are limited. The
Wi-Fi interfaces with the same pins that the Accelerometer/Magnetometer
interfaces with. Therefore, we dedicated a processor each and split the work up
between the two. The Kinect interfaces with the MSP430G2 using a USB port that
is interfaced with the MSP430G2’s UART pins (TX and RX). The MSP430G2 and
Locomotion module will be connected via general-purpose pins. The Locomotion
module is shown in more detail below:
Figure 4.4.3.C Locomotion Module Flow Chart
The actual Locomotion unit consists of three types of hardware. The first is the
second MSP430G2 that is in charge of the motor control and motor feedback. The
second is the motion sensor called the MPU9150. The MPU9150 is an
accelerometer + magnetometer + gyroscope. It sends to the MSP430G2 the
acceleration and compass heading of the robot. This is important since the current
compass heading is need so that the robot knows which direction it should turn
form the coordinate information provided by the Computer. In addition, the
Computer needs to know the current heading of the robot whenever it computes
the waypoint so that it can tell the processor to move X-number of degrees from
any of the compass points. The robot can act upon that and turn accordingly. The
acceleration information is just as important since it can provide the velocity at any
time step vie an integration or the current displacement via a double integral. The
third are the H-Bridges that allow for bidirectional rotations of the wheels. The
MSP430G2 receives the coordinate information from Communication module and
sends the PWM signals to the H-Bridge. There is one H-Bridge for every two motor
assemblies. The reason is that the left side wheels will rotate at the same speed
and the right side wheels will rotate at the same speed. While the wheels are
rotating, the motor assembly is providing feedback about the rotational speed of
94
the wheel. This information is then fed back to the MSP430G2. The MSP430G2
will continue to send PWM signals to the motors until it has received the right data
from the encoder’s feedback. There are two conditions for robot to perform
properly. The first is that it covers the necessary distance. The second is that the
wheels spin at the proper speed. Both of these pieces of information can be yielded
using the accelerometer and the encoder. A double integral of the accelerometer
information yields the current displacement. The encoders can also provide us the
displacement by takin the number of tick marks that occurred. Since we know the
displacement per tick mark, we can determine the overall displacement in real
time. Moreover, once the desire replacement is met we can stop the robot so that
it may scan again. Alternatively, the encoder provides the wheels rotation. It is
quite possible that each wheel rotates at a different speed. So to keep this in check
we must constantly check to make sure each wheel is rotating properly. However,
this is just a fail-safe system. Below is a detailed look at the Motor assembly:
Figure 4.3.3.D Motor Assembly Module Flow Chart
Our power supply is a 14.8 battery. Of course, all voltage values need to be
properly applied, so the need of a voltage regulator or a series of voltage regulators
are needed. The voltage levels required for the project vary. We need 1.9 volts for
the encoders, 3.3 volts for the MCU’s and Wi-Fi module and 12 volts for the motors.
Below is a diagram of how the different voltage regulators supply voltage to each
module.
95
5. Construction
5.1.
Robot Platform Assembly
The J-Bot v2.0 was fairly easy to assemble. All parts were well labeled. The parts
were accurately manufactured. The materials are light weight yet strong, it seems
the robot could handle come rough situations easily. The instructions for assembly
are clear and all diagrams are helpful in guiding along the construction. Very little
tools are needed to put together this robot. Only a Phillips head screwdriver and
pliers are needed. Figures 5-1, and 5-2 are a few photos of the robot fully
assembled.
Figure 6-1: This is the J-Bot fully assembled.
96
Figure 6-2: This is the inside of the body of the J-Bot.
5.2.
3D Scanner Mounting
The Microsoft Kinect will be mounted on the second tier of the J-Bot. The second
tier was chosen because it has the highest vantage point on the rover, it has the
most space since there is nothing above it, and nothing else will be on the second
tier so the view will not be obstructed by other items. A high vantage point is
important for the Kinect because it gives it the best view of the room it is scanning.
The second tier has the least amount of components and gives the most space to
the Kinect. This is advantageous because the Kinect is by far the biggest
component of this project and requires space for it to operate. On the first tier space
is taken up by the motor control board which will lay flat thus taking up the
maximum space it can. Also, on all four corners are the pillars that hold the second
tier up and they will obstruct the Kinect’s view of the room. The first tier is 3in lower
than the second tier. Taking away this height from the Kinect’s vantage point would
contribute to the projects detriment.
The Kinects power cable is very long (15ft) and in the middle there is an AC to DC
converter that is quite bulky. The power cable is so long probably because a Kinect
is meant to be placed above a television. A long cable would facilitate supplying
the Kinect with power. It was decided that the cable will be cut past the AC to DC
converter and power will be supplied directly with a separate power supply.
Since the Kinect will be on the second tier it will feel the movement of the J-Bot the
most. Luckily the Kinect has a rubber pad on the base that does a great job of
keeping it in place. To be safe the Kinect will be held in place by four metal rods
similar to the pillars on the first tier. The four rods will be placed around the base
of the Kinect. The rods are ~2.25in long. This is a good length to catch the Kinect
if it were to tip over. The rods will be fastened to the second tier plate with nuts
below.
97
5.3.
Software Installation
For this project to function properly, there is many software need to be installed.
The software including operating system (Linux Ubuntu), driver for Kinect
(OpenNI), base system (Robot Operating System), and Point Cloud Library. The
detail installation process can be found at the respective website, the following is
the quick summary of the installation process of necessary software.
The operating system for this project is Ubuntu 14.04, a Linux operating system.
To install, the developer need to download “.iso” file from official website
(www.ubuntu.com), and burn the file into a DVD disc. Next restart the computer,
make sure the computer boost from the DVD disc. The computer should display
multiple options at the loading screen, choose install Ubuntu and the developer
can follow the install wizard of Ubuntu. (131-132)
The Kinect was design to work in Windows operating system, thus for it to function
in Ubuntu, the developer need to install OpenNI as driver. Also because there are
some variation of Kinect, each may has slightly different procedure. The following
website
(http://choorucode.com/2013/07/23/how-to-get-started-with-kinect-forwindows-on-ubuntu-using-openni/) describe the process to install OpenNI so that
it may work with Kinect for Windows.
Robot Operating System (ROS) is the backbone of the project. The version used
to develop for this project is “indigo”. The detail procedure can be obtain from
official website (http://wiki.ros.org/indigo/Installation/Ubuntu).
Point Cloud Library is the main 3D data processing library, the one being used for
this project is the prebuilt binary for linux, in which the procedure can be obtain at
the official website (http://pointclouds.org/downloads/linux.html).
6. Testing and Evaluation
6.1. Unit testing
6.1.1. Robot Platform Testing
Testing the robot platform will comprise of testing the motors, tires, sensors, load
capabilities, turning, speed, and movement. Data will be collected from these test
to sharpen the accuracy of the results. Results should be as close to theoretical
values as possible. This is not always possible but there should not be a great
amount of error. For example the error in movement will only be allowed to be no
greater than 2%
Testing the motors will be done in a few steps. First the motors will be tested with
no load. This will confirm that power is reaching the motors and they are in working
order. Next, a load will be applied. For this for test the load will be the weight of the
J-Bot rover itself. This will confirm the motors are spinning with enough torque to
carry the weight of the J-Bot rover. Also with this initial load test, it will also test the
tires. The test will confirm if the wheels stay on the J-Bot and work on the surface
98
we put them on. Next, we will do a load test with the full equipment to see if the
motors can handle the weight. If this test fails it means we need to choose a new
amount of power to supply the motors with. This test fails if the motors fail to move
the rover at an acceptable speed. This value will be recorded to make sure that
under no circumstances will the motors ben supplied with that much power.
Testing the tires will consist of running the J-Bot at full load at different speed on
different surfaces. Signs to look for will be if the rover’s wheels are slipping. These
tests should be easily passed by the tires included in the J-Bot kit. Another factor
to be considered when testing the J-Bot’s tires will be paying attention which
surfaces will cause the most wear. Concrete, brick, and other rough surfaces will
probably do the most damage. While tile, carpet, and hardwood floors will do the
least amount. This should not be a problem because the wear should be minimal.
Wear would be a concern on rough surfaces with the Geekbot wheels because of
the materials they are made from and their width.
To test the sensors first the rover will be run in and empty setting to make sure the
sensors are not miss-firing. Next, a simple obstacle will be placed in front of the
rover’s path to test if the sensor is reacting a stimulus. The rover should encounter
an obstacle, the sensor should then signal the processor to stop moving the
motors. Once the motors have stopped moving the processor should being with a
sequence that will reverse and turn the J-Bot in a different direction and wait for a
new instructions from the computer. This situation should not happen unless the
obstacle was out of range for the Kinect to see. By the time the J-Bot has stopped,
reversed, and turned the Kinect should have identified the obstacle and updated
the 2D map.
Turning is one of the more complex movements the J-Bot can perform. It involves
all the components of the motor control board. First turning will be tested by seeing
if all the basic turns can be made. The basic turns are: left and right moving
forwards, and turning left and right moving backwards. If any of these tests fail the
programming must be re-revised. Next, testing how hard the J-Bot can turn will be
important. This data will allow us to understand its limitations. Once this data is
collected it must be assured that the J-Bot will not be put in a position where it will
be asked to make a turn it cannot make. Testing this will begin by making a slight
turn and progressively making a tighter turn. Eventually the J-Bot will reach a limit.
This limit might be the lower limit of the voltages allowed for the motors. The next
test will determine if the J-Bot can turn about an axis perpendicular to the floor.
This will be important for the Kinect to scan a room efficiently. This turn can be
accomplished by moving the motors on one side of the J-Bot rover forwards while
moving the other two backwards. In a perfect world this turn can happen if the
motors turn at the same rate. Getting the motors to turn at the same rate should
mean supplying them with the same amount of power. In the real world, this is not
always the case. Data will have to be collected to get all motors to turn at the same
rate.
The next set of tests will evaluate the speeds the J-Bot can achieve at full load. A
few important data points will be the slowest speed the J-Bot can be operated at
99
and the fastest speed. These values will be of use because the motors should not
be provided with more power than what these speeds require. Another important
speed to calculate will be a good speed to select as the average speed for the JBot. This speed will be the operating speed of the J-Bot most of the time. It should
be a speed where the J-Bot can reach destinations quickly without messing up the
Kinect’s point cloud or knocking any components over/off the rover.
6.1.2. Power and Regulation Testing
Testing the power and regulation of the motor control board is an important part of
the testing process. If components do not receive enough voltage they will not
operate correctly or may not operate at all. Testing these components will require
a multimeter to measure voltage, and current. If the components are receiving too
much voltage they may not operate and burn out. This doesn’t have to happen
right away. Even if you are getting the correct reading the noise in the circuit over
time will damage parts of your board. Oscilloscopes can be used to accurately see
what is going on in your circuit. Every single component on all boards need to be
tested to check for output values and functionality.
6.1.3. Input Output Testing
Objective:
The objective of this test is to make sure the velocity of the autonomous robot
match the desired value. In order for the robot to maintain velocity at all times all
the motors have to receive certain voltage. The group is going to test the velocity
of every motor to calculate the pulse width needed to maintain the angular velocity
provided by the encoder.
Hardware Components:




Microcontroller
Encoder
Motors
Wheels
Pre-Test:
The encoder has to be connected with the motors and it also has to have a
communication with the MCU. The group is going to have a specific velocity to test
the velocity each motor is going to provide for the wheel. Every motor is slightly
different and may need extra or lower voltage.
Test:
A team member is going to send a specific velocity to the MCU initially, The MCU
will transmit the information to the encoder, and after gathering the information the
encoder will provide the motors with the angular velocity.
100
Since every motor have a slightly different requirements to provide the desired
angular velocity, the encoder will provide the information from the motors to the
MCU. Finally with the information collected by the encoder, the MCU can calculate
the pulse width required for each of the motors to keep the required number of
rotations.
Expected Result:
In theory the initial given velocity to the encoder should be return to the MCU if the
motors would provide the same number of rotations to the wheels.
6.1.4. Circuit Testing
More testing can be done on the communication board to see that everything is
working appropriately. Testing the board components will be easy since the parts
either work or they don’t. If the computer cannot establish a communication link
with the board then the Wi-Fi card may not be in working order. Once the
communication link can be established we can pinpoint which components are not
sending information. Testing will consist of testing each component for input and
output then gradually more components will be added until all components are
working simultaneously.
6.2. Software Testing
6.2.1. 3D Scanner Testing
The first test for the 3D Scanner is to make sure it is function in the environment
specify by manufacture. The 3D scanner for this project is the Kinect for Windows,
thus it was tested in Windows operating system using demo software that come
with Microsoft Kinect SDK 1.8. The (Figure 6.2.1.a) show the Kinect for Windows
is function in Windows without any error.
Figure 6.2.1.a – Kinect for Windows tested in Windows Operating System
101
The next test is test the 3D scanner in the development environment of the project,
which is Linux operating system (Ubuntu 14.04). The driver used for the Kinect is
OpenNI. The (Figure 6.2.1.b) show the Kinect for Windows is function in Ubuntu
as intended.
Figure 6.2.1.b – Kinect for Windows tested in Linux Operating System (Ubuntu)
After verify that the Kinect is function properly, next test is the range of the 3D
scanner. In this project, the range of the Kinect specify by manufacture is from
800mm to 4000mm. The (Figure 6.2.1.c and Figure 6.2.1.d) show the Kinect being
tested in Ubuntu with 825mm being the minimum range and 3900mm range for
acceptable noise level.
Figure 6.2.1.c – Kinect Minimum Range tested in Linux Operating System (Ubuntu)
102
Figure 6.2.1.d – Kinect Maximum Range tested in Linux Operating System
(Ubuntu)
With the Kinect range known, the Kinect need to be tested with Robot Operating
System to ensure the compatibility between them. The test will also test the update
rate of Kinect to ROS as well as the detail of data. The (Figure 6.2.1.e) show the
Kinect function in conjunction with ROS.
103
Figure 6.2.1.e – Kinect Compatibility tested with ROS in Linux Operating System
6.2.2. Communication System Testing
Objective:
The objective of this test is to check the data received by the computer matches
the data originally sent over the network by the MSP430 Microprocessor.
Hardware Components:



Computer
MSP430 Microcontroller
Xbox Kinect
Software Components:




IBM Bluemix Web server
Computers IP address
Server 1 IP address
Server 2 IP address
Pre-Test:
For communication purposes since the computer and the Kinect are going to use
the same IP address there is a confusion problem with the data sent and received.
To solve this issue the group decided to use IBM web services called IBM Bluemix.



Establish a connection with the IBM server
Set up the communication of the MSP430 with the IBM server.
Connect the computer to the server
Test:
The group will generate data using the Kinect by capturing an image. The Kinect
will sent out three streams of data this will be process by the MSP430 which is in
charge of sending out the streams of data to the server. From the server the
computer will gather the data, process the information and sent the requested data
by the Kinect back to another server. From that server the MSP430 will received
the requested data.
Expected Results:
The expected information received by the computer should be the same
uncorrupted data sent by the MSP430.
104
6.3. Performance Testing
6.3.1. Known Environment
Testing in a known environment will be the most basic testing of the full capabilities
of the system. This will test the J-Bots abilities to move a way point created by the
computer. This will test the Wi-Fi connection card, the communication between the
communication board and the motor controller, and the motor controller’s ability to
interpret instructions. The computer will create a way point and send this
instruction to the motor control board through the communication board. Once the
motor control receives the instruction is should operate the motors and take the JBot to the desired destination.
These tests will also test the communication feedback from the magnetometer,
accelerometer, and the encoder back to the computer. These re important factors
because using this feedback can keep track of the robots position. Also the
accuracy of this information will determine if any measure need to be taken to
correct errors in traveling. This is where the information collected in unit testing will
come into play.
6.3.2. Unknown Environment
Testing the IRIM system in an unknown environment will be more complex than in
a known environment. This is because all the components in the previous test will
be tested but also the Kinect’s ability to scan, the communications board ability to
receive and transmit the data stream from the Kinect, the software’s ability to
display the 3D point cloud, and create a 2D map. All these processes are important
for the IRIM to be fully functional.
Once the scanning begins the Kinect should create a point cloud. This information
will be passed on to the communication board. The Kinect should not have a
problem scanning because it was received in working condition from Microsoft.
The data stream provided by the Kinect will be taken in by the communication
board via USB connection. This data will be passed on to the computer via Wi-Fi
connection which then it will be interpreted.
If the data was correctly passed on to the computer the software will interpret the
data stream and display a point cloud. Additionally, a 2D map of the room will be
created to help navigate the J-Bot rover. Way points will be created using the 2D.
Instructions for the motor controller board will then be communicated back to the
J-Bot.
105
Figure 7-1: Block diagram of data flow through IRIM system.
The IRIM system should successfully do all the things previously mentioned as
they are requirements of the system.
7. Financial and Administrative
7.1.
Bill of Materials
Passive Components:
Items
Distributor
Manufacturer
Quantity
Total cost
1
Price per
unit
$.89
2.2 pF
Capacitor
22 pF
Capacitor
10 pF
Capacitor
.1 µF
Capacitor
2.2 nF/50V
Capacitor
.01 µF
Capacitor
10 nF
Capacitor
1 µF/6.3V
Capacitor
16 pF
Capacitor
2.2 kΩ
Resistor
10 kΩ
Resistor
100 kΩ
Resistor
15 kΩ
Resistor
1.5 kΩ
Resistor
3.3 kΩ
Resistor
33 Resistor
Jameco
AVX Corp
Jameco
Jameco
2
$0.19
$.38
Jameco
1
$.19
$0.19
Jameco
Jameco
Valuepro
Panasonic
5
$.25
$1.25
Farnell
Kemet
1
$.29
$0.29
Jameco
Panasonic
1
$.76
$0.76
Digi-key
TDK Corp
1
$.84
$0.84
Jameco
AVX Corp
4
$.79
$3.16
Newark
Multicomp
2
$.20
$0.40
Jameco
Jameco
Valuepro
Jameco
Valuepro
Jameco
Valuepro
Jameco
Valuepro
Jameco
Valuepro
Jameco
Valuepro
Jameco
Valuepro
2
$.04
$0.08
3
$.05
$0.15
2
$.05
$0.10
1
$.05
$0.05
3
$.05
$0.15
2
$.04
$.08
2
$0.04
$0.08
Jameco
Jameco
Jameco
Jameco
Jameco
Jameco
$0.89
106
33 kΩ
Resistor
100Ω
Resistor
47 kΩ
Resistor
2.2 nH
Inductor
Total
Jameco
3
$.05
$0.15
6
$.05
$0.30
5
$.05
$0.25
Mouser
Jameco
Valuepro
Jameco
Valuepro
Jameco
Valuepro
Taiyo Yuden
1
$0.10
$0.10
-
-
-
-
$9.65
Jameco
Jameco
Processors, ICs, hardware, and analog components:
Items
Distributor
Manufacturer
Quantity
Kinect
Microsoft
store
Jameco
Microsoft
J-Bot 2.0v
MSP430G2
processors
MSP430F16
MPUN150
USB Female
Type A SMD
TUSB3410VF
Wi-Fi module
(CC3000)
AT8010E29HAA
Switching voltage
regulator
TPS71533
Texas
Instruments
Texas
Instruments
Invensense
Sparkfun
Texas
Instruments
Texas
Instruments
Digi-Key
Jameco
1N4148 Diode
Texas
Instruments
Texas
Instruments
Texas
Isntruments
Jameco
12MHz SMD
oscillator
Texas
Instruments
TPS71550
TPS71519
1
Price per
unit
$149.00
Total
cost
$149.00
Jameco
Kitpro
Texas
Instruments
Texas
Instruments
Invensense
4UCON
1
$84.95
$84.95
2
$2.80
$5.60
1
$0.00
(sample)
$6.62
$1.25
$0.00
Texas
Instruments
Texas
Instruments
Johanson
Technology
Inc.
Motorola
1
$0.00
1
$0.00
(sample)
$0.00
(sample)
$1.28
5
$.59
$2.36
Texas
Instruments
Texas
Instruments
Texas
Instruments
Major
Brands
Texas
Instruments
1
$.89
$.89
1
$.89
$.89
1
.89
.89
1
$.05
$0.05
1
$0.00
(sample)
$0.00
1
1
1
$6.62
$1.25
$0.00
$1.28
107
Sparkfun
LITE-ON
1
$1.95
$1.95
$6.74
$53.92
2
$15.47
$30.94
4
$3.75
$15.00
2
20
$29.95
$.15
$59.90
$3.00
PCB
OSH Park
AA Portable
Power Corp
AA Portable
Power Corp
Texas
Instruments
Parallax Inc.
Autosplice
Inc.
OSH Park
8
Proximity sensors
Pins
AA Portable
Power Corp
AA Portable
Power Corp
Texas
Instruments
Jameco
Sparkfun
2
$5/sq. in
$60.00
Total
-
-
-
-
$478.49
IF
Emitter/detector
Batteries
Battery holders
H-Bridge
7.2.
Budget
Subsystem
Motor Control system
Communication system
Software
Hardware
Power system
7.3.
Total cost
$165.84
$84.18
$0.00
$233.95
$84.86
Facilities and Equipment
Companies and labs will be used to facilitate the creation of IRIM. Facilities will be
used during building, testing, and manufacturing. One of the requirements for the
senior design project is to make a circuit board instead of buying one. Making a
PCB will require experience. No one in the group has experience making circuit
boards so it was decided to allocate the work to a company. Eagle CAD is a free
circuit design software. Using a file created using Eagle CAD, OSH Park will create
a PCB board for us.
Facilities:
OSH Park:
About OSH Park: Osh Park is a community PCB order. It started out from another
PCB order and has been growing ever since. You can go on their website and
make your order right there. You must upload the file containing the design of your
board. OSH Park accepts the Gerber CAM files. The design must follow certain
rules which will be described in the following section. Turnaround time for designs
are 12 business days.
Design rules:

6 mil minimum trace width
108




6 mil minimum spacing
at least 15 mil clearances from traces to the edge of the board
13 mil minimum drill size
7 mil minimum annular ring
Pricing:
Standard 2-Layer order: $5 per sq. inch - This includes 3 copies of your board.
You can order more copies as long as it is in multiples of 3.
Standard 4-layer order: $10 per sq. inch - This includes 3 copies of your board.
You can order more copies as long as it is in multiples of 3. Orders are sent weekly,
and turnaround time is about two weeks.
OSH Park is the company we decided to go to get out PCB boards printed. This
company has been referred to us by more than one person and after some
research we feel comfortable with them.
UCF Senior Design Lab:
The UCF senior design lab will be used to build and conduct tests on our systems.
The lab will provide all the machines we will need to use to collect data. The room
will be a good place to keep our project in a neutral location if anyone wants to
work on it outside of scheduled hours.
Resources used:











Tektronix MSO 4034B Digital Mixed Signal Oscilloscope, 350 MHz, 4
Channel
Tektronix DMM 4050 6 ½ Digit Precision Multimeter
Tektronix AFG 3022 Dual Channel Arbitrary Function Generator, 25 MHz
Agilent E3630A Triple Output DC Power Supply
Resistors
Capacitors
Inductors
Breadboard
Dell Optiplex 960 Computer
Lockers
Multi-sim SPICE
Lab Hours:
Luckily the lab is open 24 hours a day 7 days a week. This is definitely an
advantage for us.
109
8. Conclusion
This project is the final test that we made for ourselves in order to measure our
knowledge that we learned, the abilities of each individual, the spirit of teamwork,
and the determination for success. The project complexity is not just a challenge
but also an entertainment factor in which we want this last two semester to be an
unforgettable and “enjoyable” experience, a memory that would accompany us to
the rest of our career.
This project was not mean to be one shot attempt, instead we hope that this
project would be the starting point in which we can expand further in the future, a
project that we can share to the community of computer science and electrical
engineering. The electrical component of the project was design to be very basic
in which any engineer can expand further. The software in this project will be
extensible and easy to install by any computer enthusiastic or computer major
student alike.
9. Reference
[1][2][3][4][5][6][7][8]-
[9][10][11][12][13][14][15][16][17][18]-
http://www.rapidform.com/3d-scanners/
http://www.i3du.gr/pdf/primesense.pdf
http://www.forbes.com/sites/sharifsakr/2013/05/22/xbox-one-wins-firstround-of-console-war/
http://www.scanner.imagefact.de/gb/depthcam.html
http://cubify.com/en/Products/SenseTechSpecs
http://www.youtube.com/watch?v=Ot7lQ2GplaI
http://www.kinectingforwindows.com/2012/09/07/what-is-the-differencebetween-kinect-for-windows-kinect-for-xbox360/
http://blogs.msdn.com/b/kinectforwindows/archive/2013/03/06/kinectfusion-demonstrated-at-microsoft-research-techfest-coming-soon-tosdk.aspx
http://www2.engr.arizona.edu/~arsl/lidar.html
http://oceanservice.noaa.gov/facts/lidar.html
http://velodynelidar.com/lidar/products/brochure/HDL64E%20Data%20Sheet.pdf
http://www.ptgrey.com/stereo-vision-cameras-systems
2D mapping solutions thesis paper (pdf thesis paper)
http://www.parallax.com/product/28015
https://learn.adafruit.com/ir-sensor/overview
http://www.adafruit.com/products/157?&main_page=product_info&cPath=3
5&products_id=157
http://www.digikey.com/en/articles/techzone/2012/feb/using-infraredtechnology-for-sensing
http://www.adafruit.com/datasheets/tsop382.pdf
110
[19]- http://www.rssc.org/content/pros-and-cons-range-sensors
[20]- (14-1)http://www.parallax.com/sites/default/files/downloads/28015-PINGSensor-Product-Guide-v2.0.pdf
[21]- http://pointclouds.org/about/
[22]- http://openkinect.org/wiki/Main_Page
[23]- http://openkinect.org/wiki/Roadmap
[24]- http://msdn.microsoft.com/en-us/library/hh855348.aspx
http://msdn.microsoft.com/en-us/library/ms973872.aspx#manunman_rcw
[25]- http://www.jameco.com/webapp/wcs/stores/servlet/Product_10001_10001_
2146345_-1
[26]- http://www.trossenrobotics.com/robogeek-geekbot-barebones
[27]- http://www.robotshop.com/en/lynxmotion-tri-track-chassis-kit.html
[28]- http://www.lynxmotion.com/images/html/build115.htm
[29]- http://www.lynxmotion.com/images/html/build103.htm
[30]- http://en.wikipedia.org/wiki/Brushed_DC_electric_motor
[31]- http://en.wikipedia.org/wiki/Brushless_DC_electric_motor#Radio_controlled
_cars
[32]- http://www.dfrobot.com/index.php?route=product/product&path=47&produc
t_id=100
[33]- http://www.robotshop.com/blog/en/how-do-i-interpret-dc-motorspecifications-3657
[34]- http://electronics.stackexchange.com/questions/97477/difference-betweena-dc-motor-and-gear-motor
[35]- http://boards.straightdope.com/sdmb/archive/index.php/t-313597.html
[36]- https://www.clear.rice.edu/elec201/Book/motors.html
[37]- http://en.wikipedia.org/wiki/Torque
[38]- http://www.modularcircuits.com/blog/articles/h-bridge-secrets/h-bridgesthe-basics/
[39]- http://www.precisionmicrodrives.com/uploads/media_items/h-bridgeconfiguration.690.595.s.png
[40]- http://www.ti.com/product/l293
[41]- http://www.ti.com/lit/ug/spruhj1f/spruhj1f.pdf
[42]- http://www.societyofrobots.com/sensors_encoder.shtml
[43]- http://www.ti.com/lit/ug/spruhj1f/spruhj1f.pdf
[44]- http://www.ti.com/lit/ug/spruhj1f/spruhj1f.pdf
[45]- http://www.ti.com/lit/ug/spruhj1f/spruhj1f.pdf
[46]- http://www.ti.com/lit/ug/spruhj1f/spruhj1f.pdf
[47]- http://www.societyofrobots.com/sensors_encoder.shtml
[48]- http://www.x-io.co.uk/oscillatory-motion-tracking-with-x-imu/
[49]- http://cache.freescale.com/files/sensors/doc/app_note/AN3397.pdf
[50]- https://stackoverflow.com/questions/17572769/calculating-distances-usingaccelerometer
[51]- http://invensense.com/mems/gyro/documents/PS-MPU-9150A-00v4_3.pdf
[52]- http://www.invensense.com/mems/gyro/mpu9150.html
111
[53][54][55][56][57][58][59][60][61][62][63][64][65][66][67][68][69][70][71][72][73][74][75][76]-
[77][78][79][80][81][82][83][84][85][86]-
http://www.dimensionengineering.com/info/accelerometers
https://en.wikipedia.org/wiki/Accelerometer#Structure
http://pdf1.alldatasheet.com/datasheet-pdf/view/535562/AKM/AK8975.html
http://wikid.eu/index.php/Hall_effect_Magnetometer
http://www.ni.com/white-paper/8175/en/
http://www.memsic.com/userfiles/files/publications/Articles/Electronic_Prod
ucts_Feb_%202012_Magnetometer.pdf
http://www.sensorsmag.com/sensors-mag/electronic-gimbaling-6301
http://www.spectronsensors.com/articles/Magnetics2005.pdf
http://www.electronics-tutorials.ws/electromagnetism/mag26.gif
http://www.ti.com/tool/ek-tm4c123gxl
http://www.ti.com/lit/sg/spmt285d/spmt285d.pdf
http://www.arm.com/products/processors/cortex-m/cortex-m4processor.php\ (64)
http://e2e.ti.com/?DCMP=Community&HQS=e2e
http://www.ti.com/lit/ug/spmu296/spmu296.pdf
http://www.ti.com/tool/sw-tm4c
http://www.ti.com/ww/en/launchpad/launchpadsmsp430.html?DCMP=mcu-launchpad&HQS=msp430launchpad
http://en.wikipedia.org/wiki/TI_MSP430#MSP430_CPU
http://www.ti.com/tool/ccstudio?dcmp=PPC_Google_TI&k_clickid=cc67264
f-e57d-48a2-9ed0-5fdef0927369
http://www.ti.com/lit/ds/symlink/msp430g2213.pdf
http://www.ti.com/lit/ds/slvsad5/slvsad5.pdf
From: http://www.edaboard.com/thread34173.html
http://www.ti.com/lit/sg/slya020a/slya020a.pdf
http://www.anaren.com/sites/default/files/usermanuals/A110LR09x_Users_Manual.pdf
http://www.extremetech.com/extreme/187190-full-duplex-a-fundamentalradio-tech-breakthrough-that-could-double-throughput-alleviate-thespectrum-crunch
https://commons.wikimedia.org/wiki/File:HalfDuplex.JPG
http://www.ti.com/lit/wp/swry007/swry007.pdf
https://learn.sparkfun.com/tutorials/bluetooth-basics]
https://learn.sparkfun.com/tutorials/bluetooth-basics
https://developer.bluetooth.org/TechnologyOverview/Pages/SPP.aspx
https://en.wikipedia.org/wiki/List_of_Bluetooth_protocols#Radio_frequency
_communication_.28RFCOMM.29
https://developer.bluetooth.org/TechnologyOverview/Pages/Baseband.asp
x
http://www.anotherurl.com/library/bluetooth_research.htm
http://www.hp.com/rnd/library/pdf/WiFi_Bluetooth_coexistance.pdf
http://www.campusnikalo.com/2013/02/multiplexing-types-withadvantages.html
112
[87][88][89][90][91][92][93]-
https://en.wikipedia.org/wiki/Frequency-hopping_spread_spectrum
http://www.ti.com/lit/ds/symlink/cc3000.pdf
http://techcrunch.com/2013/05/25/making-sense-of-the-internet-of-things/
http://www-01.ibm.com/software/info/internet-of-things/
http://www.ti.com/product/cc3200
http://www.ti.com/lit/ug/swru331a/swru331a.pdf
http://processors.wiki.ti.com/index.php/CC3000_Basic_WiFi_example_application_for_Launchpad
[94]- http://www.ti.com/lit/ds/symlink/cc3000.pdf
[95]- http://en.wikipedia.org/wiki/Nickel%E2%80%93metal_hydride_battery
[96]- http://en.wikipedia.org/wiki/Lithium_iron_phosphate_battery#Advantages_a
nd_disadvantages
[97]- http://en.wikipedia.org/wiki/Lithium-ion_battery
[98]- http://www.robotshop.com/blog/en/how-do-i-choose-a-battery-8-3585
[99]- http://www.batteryspace.com/Battery-holder-Li-Ion-18650-Battery-Holder4S1P-With-2.6-long-20AWG.aspx
[100]- http://www.batteryspace.com/lg-lithium-nmc-18650-rechargeable-cell-3-7v2600mah-9-62wh---icr18650b4-un38-3-passed.aspx
[101]- http://www.ti.com/product/TPS71501
[102]- http://www.pololu.com/product/2572/specs
[103]- http://www.jameco.com/1/1/703-mc34063ap1-1-5a-step-down-invertingswitch-voltage-regulator.html
[104]- http://www.analog.com/en/content/ta_fundamentals_of_voltage_regulators/
fca.html
[105]- https://www.dimensionengineering.com/info/switching-regulators
[106]- http://www.digikey.com/en/articles/techzone/2012/may/understanding-theadvantages-and-disadvantages-of-linear-regulators
[107]- http://www.rason.org/Projects/swregdes/swregdes.htm
[108]- http://www.ti.com/general/docs/datasheetdiagram.tsp?genericPartNumber=
TPS71501&diagramId=SLVS338Q
[109]- http://www.jameco.com/Jameco/Products/ProdDS/316945.pdf
[110]- https://www.jameco.com/webapp/wcs/stores/servlet/ProductDisplay?storeI
d=10001&productId=316945&langId=1&catalogId=10001&ddkey=https:CookieLogon
[111]- https://www.sparkfun.com/products/12820?gclid=CIWw2eifoMICFc1i7Aodp
CcApQ
[112]- http://energia.nu/Serial.html
[113]- http://www.ti.com/lit/ds/symlink/cc3000.pdf
[114]- http://www.ti.com/lit/ug/slau318e/slau318e.pdf
[115]- https://www.sparkfun.com/products/12700?gclid=CJvp46vEqMICFSwV7Ao
dhRIAtg
[116]- http://www.ti.com/graphics/folders/partimages/MSP430F1612.jpg
[117]- http://www.ti.com/product/tusb3410
[118]- http://www.ti.com/lit/ds/symlink/tusb3410.pdf
[119]- http://www.ti.com/lit/ug/slau318e/slau318e.pdf
113
[120]- https://www.sparkfun.com/products/11486
[121]- http://www.ti.com/lit/ug/spmu357b/spmu357b.pdf
[122]- http://www.ti.com/lit/ug/slau318e/slau318e.pdf
[123]- http://www.ti.com/lit/ug/slau318e/slau318e.pdf
[124]- http://www.societyofrobots.com/schematics_infraredemitdet.shtml
[125]- https://www.sparkfun.com/products/241
[126]- http://www.ti.com/product/tps71501
[127]- http://www.jameco.com/1/1/703-mc34063ap1-1-5a-step-down-invertingswitch-voltage-regulator.htm
[128]- http://www.ros.org/
[129]- http://pointclouds.org/
[130]- https://www.openslam.org/
[131]- http://www.microsoft.com
[132]- http://www.ubuntu.com
[133]- http://choorucode.com/2013/07/23/how-to-get-started-with-kinect-forwindows-on-ubuntu-using-openni/
10. Copyright Permissions
114
115
116
Texas Instruments:
http://www.ti.com/corp/docs/legal/copyright.shtml
SparkFun:
https://www.sparkfun.com/static/contact
117
Energia:
http://energia.nu/faqs/
Creative Commons Liscensing:
https://creativecommons.org/licenses/by-sa/3.0/
Figure 3.8.1.A
https://commons.wikimedia.org/wiki/File:HalfDuplex.JPG
Hall-Effect Sensor image:
118
Permission Pending:
119
Encoder Images and Circuit;
2D mapping solutions for low cost mobile robot
(Figure 3.3 & 3.4 in original paper) (Figure 3.1 and 3.1.1 on this paper)
Building Mobile Robot and Creating Applications for
2D Map Building and Trajectory Control (Figure 3) (figure 3.2 on this paper)
120
ROS – based Mapping, Localization and Autonomous Navigation using a
Pioneer 3-DX Robot and their Relevant Issues
(Figure 3.3 & 3.3.1) (Figure 4 & Figure 5 on the original paper)
Development of a 3D mapping using 2D/3D Sensors for Mobile Robot
Locomotion (figure 7 in original article) (figure 3.4 in this paper)
121
HDL 64E S2 permission to reproduce the image form the datasheet (Figure
3.5)
Permission request to reproduced figure 3.6 on this paper
122
123