Final Report

DR. ZHEN GAO 4TR1

KELSEY MCLEAN, SEAN ANDERSON, SHIVAM RHODE

TABLE OF CONTENTS
Contents
1

Introduction: ......................................................................................................................................... 1

Literature Review .................................................................................................................................. 1

2.1

Comparison to Previous Technologies .......................................................................................... 3

2.2

Application .................................................................................................................................... 5

2.3

Kinematics ..................................................................................................................................... 5

2.4

Fuzzy Logic .................................................................................................................................... 6

2.5

Mobile Base................................................................................................................................... 8

Design.................................................................................................................................................... 8
3.1

Initial Design.................................................................................................................................. 8

Components .......................................................................................................................................... 9
4.1

Cbot Arduino Compatible 4WD robot car chassis ........................................................................ 9

4.2

Motor Control ............................................................................................................................. 12

4.2.1

Motor/Stepper/Servo Shield for Arduino ........................................................................... 12

4.2.2

PWM/SERVO Shield for Arduino ......................................................................................... 13

4.3

PIXY CMUCam ............................................................................................................................. 14

4.4

Intel Galileo ................................................................................................................................. 15

4.5

Power Supply .............................................................................................................................. 16

4.6

Robotic Arm ................................................................................................................................ 16

4.7

Component Wiring Diagram ....................................................................................................... 18

4.8

Code Design ................................................................................................................................ 18

4.9

Bill of Materials ........................................................................................................................... 19

Completed Work ................................................................................................................................. 21

Project Plan ......................................................................................................................................... 22

Discussion and Conclusions ................................................................................................................ 22

7.1

Sean Anderson Discussion .......................................................................................................... 22

7.2

Sean Anderson Conclusion.......................................................................................................... 23

7.3

Discussion Kelsey ..................................................................................................................... 24

7.4

Conclusion Kelsey McLean ....................................................................................................... 24

7.5

Discussion Shivam Rhode ......................................................................................................... 24

7.6
8

Conclusion Shivam Rhode ........................................................................................................ 25

References: ......................................................................................................................................... 27

1 INTRODUCTION:
This report details the design concepts, research, and our project plan for building and
testing the Mobile Object Seeking Color-Coding Automated Robot (MOSCAR). MOSCAR will be a
versatile mobile robot with pick-and-place functionality. This design will be a prototype robot that will
automatically find and categorize/identify specific objects, pick them up with a robotic arm, deposit
the object into respective bins, all while navigating itself without colliding into obstacles. Because of
the nature of the robot, there are 4 main focuses of this project; robotic arm, navigation, image
processing and interfacing.
Image processing will likely take up most processing power, the rest of the system is highly
dependent on this module. Imaging processing will give the controller capability to determine the
robots position relative to the objects, it will identify objects, and act as the main feedback to the
controller. Navigation and the robotic arm are also highly dependent on the image processing
module. Both navigation and the arm will react to information sent from the imaging module.
Interfacing will involve the communication network between components, in order for the system to
work efficiently interfacing will have to be optimized.

2 LITERATURE REVIEW
Across the world, robotic specialists are automating previously human-completed task
such as picking and placing. With developing research there is a growing demand for such
automation. Demographic researchers from the Engineering department at Lancaster
University in the United Kingdom declare a specific demand for mobile robots equipped with
robotic arms to enter dangerous environments for decommission of nuclear components 1. The
UK government has also got involved in developing and implementing this technology and have
created a demand for such robots stressing importance of human safety. By using mobile
armed robots, we can enter such dangerous environments while maintaining a safe distance
preventing the loss of human lives and illnesses. J.D Cox was quoted There is a demand for
armed Robotic systems within decommissioning, sub-sea and even space because of the
potential range of complexity of the applications2. Robots like MOSCAR arent necessarily only
efficient for a single process. This is why we are focusing on giving MOSCAR the tools to
understand his own environment and the capability of being easily re-programmed. As
mentioned, space would be a environment where a robot could greatly assist humans. Armed
mobile robots are versatile tools for engineers to use. Currently there is a mobile armed robot
assisting the Starlifter construction robot with a similar design3. The Starlifter is also an armed
mobile robot designed for construction in space. Space development is growing and requires a
demand for these robots to continue at such a pace4. In hopes, MOSCAR could one day be
capable of such a task.

1|Page

In terms of functionality, over the past recent years, there is a growing demand for
wireless control of robotics. Various researching internationally are working on improving the
ways systems can connect to multiple devices for transferring data. This leads to a demand for
MOSCAR like technologies whom allow us to wirelessly complete tasks at a distance or
autonomously. The most current demand in this sense is for mobile robots that are functional
to complete pick-and-place operations both autonomously and with wireless control5. With the
common industry practice of implementing Arduino control systems and microcontrollers,
MOSCAR fulfills the needs of this demand. A key focus of our design process is to create a
robot with the capability of operating in various spectrums of speed, distance and loads which
are the forerunners of the competitive mobile pick-and-place market. Many robots are
designed for specific settings such as MBP-ASR robot from Karlsruche, Germany which will be
explained shortly. We are designing MOSCAR to have as much ability as possible on the
prototype level. To do so we are allowing MOSCAR to see for itself because it would be best if it
can assess situations and environment on its own. The more versatile the robot, the larger the
demand for it5.
One of MOSCARs applications is garbage removal. The robot can navigate a field
seeking trash and rubbish and deliver it to the appropriate recycle/waste/compost bin for
collection. CORDIS has invented 2 robots who work together to complete such a task. These
robots are known as DUSTBOTS and are currently in the design phase. Europe produces 250
million tons of waste a year and multiple countries have requested robotic assistance with the
matter6. The DUSTBOTS are the supposed solution from CORDIS who have made these
automated robots networked and cooperative. The hope is to implement them into
unstructured environments such as squares, parks and streets and to one day even include
collecting small amounts of waste from citizens doors on demand. The two robots are
DustClean and DustCart. DustClean uses tools such as a brush and vacuum to remove dirt (ie.
salt from the street used to melt ice in the winter) while reporting air quality on factors such as
pollution percentage. DustCart is the robot more like MOSCAR, equipped with an arm and bin
seeking larger and bulkier waste like litter and rubbish. The DustCart also reports area
cleanliness and conditions like how littered the environment was. The robot is 1.5 metres high
and can carry 80 litres/30 kilograms of waste in its bin. Battery supply allows 16 kilometres of
autonomy while working in combination of optics and area maps. MOSCAR will be designed
with the same ideals as dustbin but on a smaller scale for the prototype phase. MOSCAR and
DustCart both possess optic vantage on other robots in the field. Introducing this ability vastly
increases efficiency and proficiency of the robot in carrying out its task while allowing the robot
to function in multiple different environments without the need of reprogramming. The
demand for such robots is being taken very seriously by the Information Society Technologies
Thematic Area of the Sixth Framework Programme consisting of 9 partners from 5 countries
who have funded 2 million Euros toward the project.

Figure 1 DUSTBOTS, a blue and green version of DustCart and

a blue DustClean in the center. These are non-functional
prototypes of the robots.

2.1

COMPARISON TO PREVIOUS TECHNOLOGIES

There are many real-life applications that come in comparison to MOSCAR or

applications that can be implemented based on the generics of MOSCAR. These applications
can potentially aid in many aspects in the modern era. A real-life application such as the
Roomba vacuum cleaner aids in automatic vacuum cleaning without the aid of human
interference. Roomba uses iAdapt Responsive Navigation Technology to vacuum every section
of a floor multiple times. In comparison to MOSCAR, we can use such technology to avoid
hitting any obstacles or avoid dropping from any heights in order to risk any damage to the
robot. MOSCAR will use similar sensors to avoid obstacles however; it will stop at
sites/positions where it detects objects that are in need of picking using the robotic arm. For
instance, any metal waste objects that it comes across will be picked up by MOSCAR and taken
to the appropriate locations.
The MBP-ASR (Mobile Bin Picking with an Anthropomorphic Service Robot)
presented by the IEEE and ICRA is a robot extremely similar to MOSCAR that serves for
the same purpose/task. The objective of both robots is to grasp individual objects in an
area or from an unorganized bin/field. The MBP-ASR is designed for a static field where
bins are fixed and the path does not change where MOSCAR is designed for a variation
in an open field.

Figure 2 The MBP-ASR in its workplace

Previous implementations of bin-picking robots relied on a fixed/mounted optical

sensor overhead of the bins but, MBP-ASR are both equipped with their own optical sensors
making them more maneuverable and universal. The MBP-ASR uses a range image optical
sensor that uses shape-primitive technology where MOSCAR will be equipped with a PIXY
camera module. Their differences between the technologies are:

MBP-ASR : range image sensor

-

uses 3D vision
object recognition
low resolution image processing
requires algorithm or pre-programming
not cognitive (shape and orientation)
specific to given details

Figure 3 MBP-ASR vision and representation

Figure 4 MOSCAR PIXY camera vision and representation

MOSCAR : PIXY camera module

-

uses 3D vision
object recognition
high resolution image processing
vision same as human eye
cognitive (shape and orientation)
multiversal, can be taught easily

The Pixy camera makes MOSCAR much easier to program and work with because of its
simplicity and low processing requirements. Another difference in these robots is the mobility.
Both are mobile robots however MOSCAR does not have the restrictions that MBP-ASR has.
Although both have obstacle detection, MBP-ASR follows a predetermined, fixed path stopping
at obstacles until removed. MOSCAR can roam freely within the field and when encountering an
obstacle, redirects itself in pursuit of the target object. As a result of MOSCARs versitility, it will
have a reduced downtime than MBP-ASRs.

2.2

APPLICATION

MOSCAR is designed to fit many different environments, tasks involving picking and
placing as well as object seeking. This characteristic allows MOSCAR to be a suitable solution to
various applications. As previously mentioned, an application could be used for garbage pick-up and
sorting recycling for garbage sites. We can automate our robot to go around a dump site or household
areas using the Pixy camera and picking up any plastic, glass, or metal objects in order to dispose of
them in a proper manner. This will minimize any human error and will promote the proper elimination
of waste in keeping our environment clean.
MOSCAR allows users to select the target object and deliver them to another location. Another
good application for MOSCAR would be to fetch items from a warehouse. The benefit of using MOSCAR
in this application would be the ease of implementing it. Large, commercial/industrial warehouses are
very expensive to own, maintain and modify. Purchasing an additional warehouse to automate is
expensive and so would altering an existing warehouse to be automated wouldnt be much cheaper.
MOSCAR is adaptable to its environments and can therefore be implemented in a human-operated
warehouse either by itself or alongside human workers. MOSCAR would decrease retrieval times as well
as human necessity. For example, an order needs to be fetched of dramatic size for a customer. Fetching
multiples of this order is common and therefore time consuming to do manually. It can also be
dangerous in the situation of not having enough employees on hand to fetch such a large order safely.
Instead, the order can be given to MOSCAR who can hastily fetch the order without struggle.

The greatness of MOSCARs capabilities is that the same unique tools that allow him to
operate efficiently autonomously also allow him to be diverse and replace competitor
technologies in their workplaces. Examples of this are the MBP-ARS and DustClean/DustCart
robots.

2.3

KINEMATICS

Kinematics is the study of motion. As we know, inverse kinematics refers to the reverse motion
process. For instance in a two-joint robotic arm, given each angle of the joints, the kinematics equations
provide a position for the tip of the arm. If the desired location is given, we would compute the angles of
each joint for the tip to reach this desired location as shown in Figure 1 below. Once a desired location is
set, the problem comes down to finding each angle of the joint. However, with more joint on the robotic

arm, the more the angles, hence the inverse kinematics becomes much more complicated. It is a matter
of calculating the joint angles from the tip using a coordinate system of X, Y and Z in a 3D space.

Figure 5 Two-joint robotic arm with two angles

2.4

FUZZY LOGIC

For simple two-joint arms, the kinematics is fairly straight forward provided the position
of the tip is given. However, with more arm joints we can use the fuzzy logic in which, we
construct a Fuzzy Inference System which deduces the inverse kinematics as long as the
forward kinematics is known. Fuzzy solution is an easy approach to figuring out the angles of
the robotic joint arms.

Figure 6 Showing all possible angle values

l1 = 10; % length of first arm

l2 = 7; % length of second arm
theta1 = 0:0.1:pi/2; % all possible theta1 values
theta2 = 0:0.1:pi; % all possible theta2 values
[THETA1, THETA2] = meshgrid(theta1, theta2); % generate a grid of
theta1 and theta2 values
X = l1 * cos(THETA1) + l2 * cos(THETA1 + THETA2); % compute x
coordinates
Y = l1 * sin(THETA1) + l2 * sin(THETA1 + THETA2); % compute y
coordinates
data1 = [X(:) Y(:) THETA1(:)]; % create x-y-theta1 dataset
data2 = [X(:) Y(:) THETA2(:)]; % create x-y-theta2 dataset

Through the design process so far, there are many anticipated problems with using fuzzy logic
and we have therefore changed our logic methods to Inverse Kinematics. Currently we have a
complete and working model for the arm identified below including the complete kinematic
matrices. Using Arduino, also allows us to directly define the kinematics for the arm and this
will be how we specify positions and end positions based on the situation perceived by
MOSCAR.
Arduino has a servo library that we will be incorporating into our design. This library allows an Arduino
board (Intel Galileo included) to control servo motors. The servos operate between 0 and 180 degrees
and can be positioned at various angles but can also be allowed to rotate 360 degrees as well. The
library supports up to 12 motors. The motors can then be controlled without interfering with the PWM
functionality of the pins. This library also saves programming MOSCAR with multiple segments of
standardized code by allowing the use of the entire library with a single call.

2.5

MOBILE BASE

MOSCAR, in this prototype, will be designed to be able to pick and place objects
weighing up to 3 pounds. Given the weight of the load and physical factors, the base will have
to counter weigh the arm and load increasing the overall weight of the robot. Speed and
efficiency is a key focus for designing MOSCAR therefore, the motors controlling the wheels of
the base must be able to withstand the overall weight.
Factors:
Voltage - Based on battery capacity and capability for the entire robot. Also to be determined
by desirables such as speed.
Gear Ratio - Having determined optimal performance, increasing the gear ratio will increase
torque however will result in reducing speed.
Max speed/ Load speed - The size of the motor will be established by the desired operating
speed with and without load. The speed will of course be programmable and variable for both
with and without load.
These factors will be tested, measured and analyzed to output the desired performance
of MOSCAR. MOSCARs mobility is a focus of the system and will therefore require DC motors
with balanced particular specifications.

3 DESIGN
3.1

INITIAL DESIGN

The objective of this project is to make a robotic system that efficiently and effectively
combines a pick-and-place robotic arm with a self-directing mobile robot. Equipped with an
optical sensor / camera module. The system will be able to seek out targeted or user defined
objects in an established field of variable size. The system will be autonomous with a manual
override setting for situations where more control of the systems behaviour is required and for
safety. For the system to be able to seek objects effectively and efficiently without aimlessly
driving around searching, the optical sensor will be mounted on a tilt and rotate platform to
increase the vision radius. Once the object is spotted, 4 synchronized DC motors (1 for each
wheel) will propel the system within reaching radius. While enroute, the system will dodge
obstacles and seek only the targeted object. Upon coming within proximity of the object, the
system will halt and extend a robotic arm mounted on top of the mobile base, with a claw-like
end-effector to grasp the object. With the object in possession, the arm retracts to balance the
load over the robots center of gravity and then the system proceeds to move to the respective
delivery location while still maneuvering around obstacles. The object is raised over the
selected bin, dropped and the system will continue. Until all targeted objects are retrieved or
by any other specification suiting the users needs.

Figure 7 3D model of MOSCAR Design

4 COMPONENTS
4.1

CBOT ARDUINO COMPATIBLE 4WD ROBOT CAR CHASSIS

This mobile platform will be simple to control and meets load requirements for the robotic arm.
It comes with four D.C motors giving power to each wheel. The aluminum alloy body will make
it sturdy and flexible to cope with rapid movements of the robot. The chassis sits low to the
ground, which lowers the center of gravity, making the whole system more balanced. Product

reviews for this item say that the aluminum chassis itself is great, but the motors do not always
provide reliable torque capability. There is a chance that the D.C motors that come with this
chassis will have to be replaced with more powerful motors.

Figure 8 4WD Arduino Compatible mobile chassis

Chassis Specifications:

Length: 215 mm
Width 205 mm
Height 65 mm
Distance from ground: 13 mm
Weight 700g

Motor Specifications:
Voltage: 3V-12V
RPM Ratio: 1:48/1:120
No-load current 100mA (160 mA Max)
Final Decision
We have chosen to design and build our own body, chassis and base for MOSCAR. The
entire base will be made of PVC plastic. PVC was chosen because of its strength on-edge,
lightweight, durability as well as flexibility. A to scale draft drawing of our design is below. The
reasons we chose to design and build our own base was to make sure we had enough room for
all of the components that needed to be mounted and housed on and in the body. This also
allows us to remove the constraint of size from our design. The motors will be mounted to the
underside of a tray-like chassis. This tray is separate from body so that the inside can be
accessed easily. The body over laps the tray when connected and reaches lower to the ground.
The axis for the wheels poke through slots creating a skirt effect. The idea behind the design is

to maintain a low profile for MOSCAR and giving the robot some protection against dust/dirt in
ideal application settings such as dusty/dirty areas.

Figure 9 MOSCAR Interim Chassis Design

4.2

MOTOR CONTROL

The following components will be used to interface the motors with the Intel Galileo. The
shields will reduce the likelihood of burning out the microcontroller, make wiring a lot more
organized, and reduce space requirements on the chassis. MOSCAR is connects a total of 5
servo motors and 4 dc motors for a total of 9 motors. The shields are absolutely necessary in
the design to aid in balancing power and logic constraints of the Galileo. Both shields are
Arduino compatible and come with Arduino IDE compatible software libraries that will make it
easy to control, troubleshoot and interface the motors and the shields.
An addition power supply independent of the controller will be combined to power these
motors; this will also reduce noise in MOSCARs system.
4.2.1

Motor/Stepper/Servo Shield for Arduino

This stackable motor shield kit has the ability to drive up to four D.C motors, two 5V servo
motors, and two stepper motors. This shield makes connecting all the motors easy, and
minimizes the number of pins required on the Galileo microcontrollers. The chip handles all
motor and speed controls over the I2C protocol, collectively only using 2 pins on the
microcontroller (SDA & SCL). The shield will be powered by a separate power supply than that
of the microcontroller, this will provide protection to the microcontroller as well as reduce
noise.
Specifications:

Motors automatically disabled on power-up

Terminal block connectors to connect wires and power
4 H-bridges: TB6612 chip set provides 1.2A per bridge with thermal shutdown
protection
The 4 DC motors that will be responsible for moving MOSCAR are designed and specified given
the table below:

DC Motor Requirements
Total mass of system

12 lbs

Number of wheels

Radius of each wheel

1 inch

Maximum robot velocity

1 meter / second

Supply voltage

6 volts DC

0.2 meters / second2

Suggested acceleration

Given the requirements determined by design goals above, the following table defines the
required specifications of the motors:
DC Motor Specifications
Angular velocity

39.38 radians/second

Torque

0.18905 newton meters

Total Power

7.44 watts

Maximum current

1.204 amps

Battery Pack

2.4810 Ah

375 RPM

Given these specifications, we have selected the following motors for MOSCAR:

Banebots : RS-540 12 16800 RPM DC motor

Robotshop, ID# RB-Ban-68

$6.25 +tx / ea

Motor Properties

Physical Properties

Voltage

approx. 12v

Weight

5.8 ounces

Speed

16800 RPM

Shaft diameter

0.12 inches

Efficiency

71%

Shaft length

0.3 inches

Torque

0.278 newton meters

Motor diameter

1.52 inches

Current peak

6.6 amps

Motor length

1.97 inches

4.2.2

PWM/SERVO Shield for Arduino

A PWM/Servo shield will also be required to power and control the servo motors. Since these
shields are stackable and use the I2C protocol, this shield and the DC motor shield will be using
the same SCL/SDA pins. This shield has two power supplies:

VCC, 5V from the Arduino, is used to power the PWM chip and determines the
I2C logic level and the PWM signal logic level.
V+ power supply is used to power the servos
There will be extra room on both of these boards, however this room can be saved for
prototyping and serves as a safety cushion if any pins were to fail.
Specifications:

4.3

I2C-controlled PWM driver with a built in clock, making it completely free

running, i.e: doesnt not need signals continuously sent to it from the
microcontroller
Adjustable frequency PWM
12-bit resolution for each output

PIXY CMUCAM

The PIXY cam will be used for image processing (object identification) as well as object avoidance
(navigation). This camera module was selected because the PIXY CMUCam can be programmed to send
only the information we need to the microcontroller. The module can be interfaced with the
microcontroller via UART serial, SPI, I2C, digital out or analog out, giving us the flexibility required to
both control the motors and the camera. We have not decided which communication protocol we will
use yet, that will depend on the process requirement for the motors. Lighting and exposure will not
affect the cameras effectiveness, this is an obvious advantage over using IR Sensors which can be
unreliable.
The PIXY CMUCam will be mounted to the robot with the Pan/Tilt base, which will allow the camera to
look around, giving the robot a larger, more efficient field of vision. The PIXY module gives us the ability
to design and create an efficient feedback control loop, which will interface all the hardware
components to work efficiently and effectively together. Also, the pan-tilt mechanism will be set into the
front end of the body (as seen in the image below on the right) in order to leave more room for the arm
to move in front of the robot.

Figure 11 Pixy Cam Pan and Tilt Mechanism

4.4

Figure 10 Front of Moscar Chassis - Accommodates Pan and Tilt

movements

INTEL GALILEO

This is the microcontroller that will be used to control the system. It is designed to be hardware
and software pin-compatible with Arduino shields designed for the UNO R3. The board is
compatible with the Arduino IDE, and also has its own very similar Intel IDE. External shields
and devices often come with their own Arduino Library that can be added to the IDE, giving
more flexibility and compatibility between hardware and software. There is an option to load
an operating system on to the Galileo but we have chosen to design away from that. Instead,
the operating system will be managed from the tablet. This allows 98% of the controllers
thinking power to be delegated to controlling MOSCARs functions and actions. the remaining
2% will be for communications with other devices such as the tablet.
Electrical Summary:
Input Voltage 5V
Digital I/O Pins: 14 (6 PWM outputs)
Analog Input Pins : 6
Total DC Output current on all I/O lines: 80mA
DC Current for 5V pin : 800 mA
Communication Protocol Summary:

UART TTL serial communication

o Digital pin 0 (RX) and 1 (TX)

4.5

o RS-232 support, connected via a 3.5 mm jack

USB Device allows for serial (CDC) communications over USB
o Provides for a serial connection to the Serial Monitor on your computer
o USB host port allows Galileo to act as a USB Host for connecting
peripherals
Ethernet RJ45 Connector allows you to connect to a wired network.

POWER SUPPLY

Intel Galileo: Requires 5V power

Options include:
4xAA batteries, provide 6V with alkaline cells.
Cell phone portable external battery charger
Servo Shield: Requires 5V power from the Arduino, and an external supply of 5 or 6 VDC.
Options include:
4xAA batteries, provide 6V with alkaline cells.
6V rechargeable RC battery pack
D.C Motor Shield: Selecting a power supply for this depends on the voltage output of the D.C
Motors, because we are unsure of the capability of the D.C motors supplied with the chassis we
can only speculate.
Also, as stated, there will be separate power supplies for the different components of MOSCAR so that
there isnt an overload in the controller and to reduce noise between components.

4.6

ROBOTIC ARM

A four degree of freedom robot arm made from PVC will be used to pick up objects. The arm
consists of five servo motors which will be interfaced using the servo shield as discussed above.
It is powered using three MG995 55g 180 degree servos, and one SG90 9g servos, and has
active joint bearing connection. This is the arm we will be using for MOSCARs design.
Arm Dimensions:

Figure 12 SainSmart 4-Axis Palletizing Arm

MG995 Servo Specification:

Working torque: 13kg/cm
Respond Rotation speed: 53-62R/M
Dead zone: 4ms
Rotation Angle 180 degree
Working Current: 100mA
Working voltage 3-7.2 V
Operation Speed: 0.17s/60 degree (4.8V), 0.13s/60 degrees (6.0V)
SG90 Servo Specification:

Working torque: 1.6kg/cm

Respond Rotation speed: 0.12-0.13s/60 degree
Dead zone: 5ms
Rotation Angle 180 degree
Working Current: 100mA
Working voltage 3.5-6 V

4.7

COMPONENT WIRING DIAGRAM

Figure 13 Proposed Wiring Diagram

4.8

CODE DESIGN

Code libraries can be downloaded and used in the IDE. These will provide extra functionality
and ease of programming while developing the code.
1. Tracking Objects
Object detection and location is handled by the image processing system inside the Pixy
module. The module analyzes the image, identifies objects matching characteristics that
we program into it. This information is sent as feedback to the controller, reporting
position, size and characteristic information of all detected objects. A function will be
required to adjust the pan and tilt mechanism to try and keep the tracked objects in the
center of the field view.

We will also have to make an algorithm for deciding which objects will be picked up and
sorted. The camera can detect multiple items, so we will probably program it so that it
will pick up the object closest to it, then it will decide what receptacle it gets placed in.

2. Approach Objects
The center of the cameras view will be the set point, by keeping the object in the center
of the view, the relative position of the pan and tilt mechanism can be used to
determine the position of the object relative to the rest of the robot. This value will be
used to control the speed differential between the left and right motors, which will
cause the robot to turn towards the object.

3. Object Identification
Object identification and classification can be programmed within the Pixy module. If
certain characteristics are met by the object then the robot will decide which receptacle
it goes into.
Pixy can learn objects, so we can calibrate the robot to be able to identify up to seven
colour signatures. Once pixy can decipher between objects we can make an algorithm
that will decide where it goes.

4. Robotic Arm Kinematics and Action

The mobile base halts upon reaching the object and the arm is activated. The arm is
programmed to approach the object at a certain angle with the claw-like end-effector.
Other end-effectors can be used as well such as an electromagnet for the purpose of
seeking out magnetic objects in the field. Leverage of the arm and load at the base of
the arm will be compensated by weighing down the mobile base and or with counterweight. The robot arm will receed upon grabbing an object so that the object is located
closer to the centre of gravity. This specification will keep the system balanced while
mobile.

4.9

BILL OF MATERIALS

Item
1

DC Motors

4WD
Chassis

Quanti
ty

Price

Product Link

TBD, depends on capability of the

chassis

Information

49.99

http://www.amazon.co
m/SainSmartAluminum-PlatformMEGA2560Duemilanove/dp/B008Q
47VKE/ref=pd_cp_e_1

16 Channel
12-bit
PWM/Serv
o Shield

Library:
1

17.5

http://adafruit.com/pro
ducts/1411
Tutorial

Library:
4

Motor
Shield V2
for Arduino

19.95

http://www.adafruit.co
m/products/1438
Tutorial:

Pixy
CMUcam5
Sensor

Pan and
Tilt
Mechanis
m

Intel
Galileo

SainSmart
Robotic
Arm

1.95

http://www.adafruit.co
m/product/85

13.49

http://www.rcplanet.co
m/Venom_Receiver_Pa
ck_p/vnr1500.htm

10

Shield
Stacking
Headers
Venom 6V
1200 Mah
Flat
battery 5
cell
VNR1500

74.95

http://www.adafruit.co
m/products/1906

General
Informati
on:

18.95

http://www.adafruit.co
m/product/1967

General
Informati
on:

General
Informati
on:

https://github.com/
adafruit/AdafruitPWM-Servo-DriverLibrary
http://learn.adafruit
.com/adafruit-16channel-pwm-slashservo-shield
https://github.com/
adafruit/Adafruit_M
otor_Shield_V2_Libr
ary
http://learn.adafruit
.com/adafruitmotor-shield-v2-forarduino/overview
http://www.cmuca
m.org/projects/cmu
cam5/wiki
http://www.sainsm
art.com/diy-4-axisservos-controlpalletizing-robotarm-model-forarduino-unomega2560.html
http://arduino.cc/en
/ArduinoCertified/In
telGalileo
http://www.sainsm
art.com/diy-4-axisservos-controlpalletizing-robotarm-model-forarduino-unomega2560.html

11

Yubi Power
YP250ABLK
2500mAh

14.99

12

MG995
13kg Servo
Motor

6.94

Total

http://www.amazon.co
m/dp/B00CD972YS?psc
=1
http://www.amazon.ca/
365buying-Tower-ProMG995Torque/dp/B0098M4R4
Q

Replacement for
broken Servo on
robotic arm

222.71

5 COMPLETED WORK
So far to-date, our completed work on the project is:
Programming and manipulating the robotic arm using the Galileo Micro-controller. This
includes wiring schematics.
Mobile base designs and construction has begun. We may need to make our own base
to fit our desirables for the system if the mobile base listed above through further
inspection will not be adequate.
Built a list of materials for the components required based on our current design.
Background research including: demand for system, competitors, applications,
purposed, variability, safety, protocols, etc.
Complete component wiring diagram
ISA Poster Presentation
We also have ideas to expand on the system if time permits such as introducing a
HMI/database that records the systems actions. For example, keep count of what and
how many objects went to which bins.

6 PROJECT PLAN
Completed Work

May-August 2015

2015 Fall Term

Design of chassis

Motor
requirements

Purchase Bill of
materials

Code arm actuation and

sorting process

Assemble and
interface
components

Build all component

libraries within the
Arduino IDE

If time permits we will build a

HMI tablet for speed control,
manual override and quality
monitoring

Program base of
robot to move to
targeted objects

Bill of materials

Component
Wiring Diagram

Programming
concepts

7 DISCUSSION AND CONCLUSIONS

7.1

SEAN ANDERSON DISCUSSION

MOSCAR is a very viable system because is versatile adaptive. Work places and fields are
always changing to needs and requirements, open and closed projects. Setting areas of your
workplace is space and time consuming but this is why MOSCAR is such a good solution to
implement. MOSCAR adapts to its environment because it can see for itself and it is
programmed in an operational way opposed to a conventional specialist way. Using its own
vision, the robot can recognize task-objects while avoiding obstacles. The programming for this
ability is generic to MOSCARs mobility so no matter where it is implemented, this is how
MOSCAR will approach the situation. If the system operated with a specialized program, it can
only perform a certain way, order and location much like the MBP-ASR which MOSCAR
outperforms in a majority of ways. This makes our system very relevant.
There is a multitude of applications and more definitively, a large demand for such mobile
pick-and-place robots. The demands come from a variety of fields and industries and therefore
a system that is adaptive, like MOSCAR, would be the most sought type of system.
There are however potential complications with MOSCARs implementation into work
streams. The main one being familiarity which goes along with the saying if it isnt broken,

dont fix it. Many companies will have some sort of system that they have already invested in
that they are attempting to use to the magnitude of MOSCAR. With that in mind, these
companies would be rather hesitant in pursuing MOSCAR as a replacement.
In our program, Process Automation Technology, we have been through the simplest to
the trickiest troubleshooting scenarios from our previous lab courses. In order to gain more
understanding and success, we have had to stick to it until the problem is resolved or a solution
is found. In this regard, the scheduling of MOSCARs construction leaves a lot of spare time for
such troubleshooting. I believe that there wont be a problem that given enough time we cant
solve. However, realistically speaking, we will maintain a constant assessment of our progress
vs our scope so that if we ever vary too far from the plan, we will turn to the simpler and faster
alternatives such as eliminating a nonessential element from MOSCAR.
The final design will be completely confirmed by the end of this semester. In the
meantime, we have begun construction and programming MOSCAR by part to test the
feasibility and extent of our project. Keeping the purpose of MOSCAR and its methodology, we
are going to incorporate some elements from the other robots made for this purpose, the
DUSTBOTS and the MBP-ASR. They both have their restriction, benefits, pros, cons, troubles,
errors and we will take these into consideration while developing our system to optimize the
process of constructing as well as the quality of our final project.

7.2

SEAN ANDERSON CONCLUSION

MOSCAR is a very exciting project in terms of purpose and its potential. There is a large variety
and magnitude of demand for such a system. There is premier appeal to the system since the
competing systems in its field have many restrictions and constrictions. There are so many uses
for this system, there could be requests to reproduce copies of it for distribution potentially
one day leading to a company who manufactures these systems. Different version of MOSCAR
with different specifications, wheel and motor types, end-effectors, etc will allow introduction
to niche markets as well. This prototype is just a simple representation of the base functions of
MOSCAR; to search a field for target objects, delivering them to target destinations. Adding in
the ability for wireless control and manual override, MOSCAR will become a tool for engineers
in even recreational uses. As stated, MOSCAR will be able to work along-side humans giving
definition to the word machine, a system or tool that makes work easier.
The current list of materials are all cheaper, simpler versions of components for the
purpose of prototype that current limit diversity in its purpose. Given funding and more time,
MOSCAR could be the start of automating more than just mind-numbing processes. In an
example, artificial intelligence is incorporated into MOSCARs programming. For more
imaginative results, voice recognition and internet access are also added. MOSCAR can now act
as a robotic employee to improve efficiency and productivity in your workplace. Add multiple
MOSCARS all added together and now you can replace entire manufacturing processes where

human interaction is required, for example a custom wood shop where pieces are not cut from
a standard shape/mold.
Without getting too far ahead, this design will be able to complete the problematic task at hand
with ease and to our hopes, efficiently, with the right method and detailed integration of its
components.

7.3

DISCUSSION KELSEY

With the help of Dr.Zhen Gao, and my teammates I am sure that this project is viable. The
important thing is that we take it step by step and go through the appropriate design process.
MOSCAR is very relevant to the world around us, it can be used to clean up garbage, and it
could be used to go into dangerous places where humans shouldnt go. This could even be
turned into a house-hold item, where users can program the robot based on what they need
and want, then MOSCAR can bring it to them, or clean up the playroom, or pick up branches
from outside.
Future implementation of this project could be difficult, there would have to be more research
and development on effective and rechargeable power supplies, especially because the future
version would likely have more power and be larger in size.
Over the summer I hope that our team will be able to get some components of MOSCAR
working together, so that when next semester comes around we will have time to interface an
HMI.

7.4

CONCLUSION KELSEY MCLEAN

For me this TR project is about taking the concepts and skills Ive learned over the past four
years, and challenging and showcasing them in a final project. The design of MOSCAR I think
covers my objectives. We have motion control, robotics, imaging, software development, and
hopefully we will have time to implement an HMI. Overall I think that not only is this project
very viable, but it will be a great learning experience.
So far the project design seems good, it is hard to say until we start building and programming
what kind of problems we might have, but I am very optimistic. With the completion of the
component wiring diagram, and CAD model of MOSCAR it seem that our project is starting to
become more tangible. The plan to start building over the summer term will be beneficial, as
we will need plenty of time for programming and building.

7.5

DISCUSSION SHIVAM RHODE

MOSCAR has a very high viability in todays world due to its lack of complexity, user
friendly and great adaptability of its environment. Industries or work places can rely on

MOSCAR to get the task in hand completed on time and effortlessly. There is always room for
improvement in any process or system, MOSCAR can help improve such processes or systems
and that is the key in making MOSCAR viable. Having the ability to adapt to its environment is
our set point in making MOSCAR sell for itself. Using its own artificial intelligence to navigate
itself through any environment is the implementation we will indulge into MOSCAR using
generic programming for the robot to run the exact same way for any environment it is in.
The relevance of our project is very clear: to be used in any process or system that
demands a pick-and-place orientation using a robot. There is a high demand in the automation
industry involving the pick-and-place apparatus. MOSCAR is mobile, which gives it an advantage
over CNC machines or any other automated robot.
There may be some probable complications when implementing MOSCAR as a whole.
For instance, the complex programming in regards to every position and movement. Not to
mention, troubleshooting the programming (or any other software issue) if any positions are to
be changed or altered with. Also, MOSCAR being able to recognize what needs to picked and
what does not need to be picked. This has to be very specific so that MOSCAR understands the
right versus wrong. We ask ourselves, Is this an obstacle I go around or is this an item I can pick
up? The best way to do this is to manually program each object into the Pixy Camera for
MOSCAR to distinguish an obstacle from an object to be picked up.
Keeping our focus while being patient with the programming aspect of MOSCAR will
ensure the software problems stay at a minimum. Our expertise is the main backbone we have
to rely on and trust what we have learned throughout our Bachelor of Technology program.
Moreover, we will have a technician just for the debugging and troubleshooting aspects of
MOSCAR, one technician for the hardware aspects of MOSCAR and one technician for
constructing and designing ways to improve MOSCAR in any means possible. Finally, a close
watch or continuous monitoring will allow us to carefully study every movement before it
occurs. In terms of the schedule, we have planned to complete all programming this summer so
when September comes around, we can work on troubleshooting and improving MOSCAR.
We tend on completing a prototype by the end of next term starting with buying all the
necessary materials to construct MOSCAR. Followed by, designing and programming MOSCAR
every part at time. Time being the essence, we want enough time to be left to test, debug and
improve our project as a whole making this an ongoing, continuous project.
Using our competitors to our advantage, we plan on using every bit of information, from
similar robots, to create a masterpiece that will work to continuously improve its existence.
Both advantages and disadvantages kept in mind to build a robot that will optimize maximum
benefits to our customers needs; keeping complications and restrictions to a minimum.
Basically, there are many similar robots to MOSCAR and we will utilize these robots to our
strengths in terms of navigation, location, mobility, robot arm movement, etc. As a whole, we
are on schedule and waiting on our parts to be delivered to start the building stage of all our
hardware.

7.6

CONCLUSION SHIVAM RHODE

MOSCAR is a well thought and innovative design in which todays environment can
benefit from. The idea of this project is to be accurate and efficient in order for MOSCAR to be
utilized in the correct manner. We plan on implementing a prototype along with the design for
the sole purpose of pick-and-place functionality. Due to lack of time our design will be thorough
and explicit; in other words, it will perform a simple pick-and-place operation. However, this
would just be an introductory prototype in comparison to what MOSCARs true capabilities are
expected to be. The true nature of this project would be to target engineers and technicians in
the aid of commercial, recreational or environmental uses. Also, the scope of MOSCAR is to
tackle real-life applications such as garbage dump sites, warehouse stacking and university
campus clean-ups.
In case we have enough time, we plan on adding a database to our prototype to be able
to track all our items in order to troubleshoot any lost items or wrong placed items. We also
plan on adding an HMI using a tablet to be able to control MOSCAR in case of any emergencies
(i.e. Emergency Stop). Finally, we will be implementing Infrared sensors onto MOSCAR for
better navigation reasons.
Different versions of MOSCAR will have different aptitudes and tasks best suited for the
customers need. Specifically in the automation industry, MOSCAR can assist humans in faster
processes, efficient work and zero human error. It is an ongoing project in which new
innovative ideas can help improve MOSCAR in order to eliminate human interaction and fasten
processes both effectively and efficiently. As we know, in todays era, the right change is the
key to any successful project and MOSCAR is that right change.

8 REFERENCES:
1. Canadian International Open, Advanced Robotic systems
by: Mohammed Bakari, Khaled Zied, Derek Seward
From: Engineering Department at Lancaster University, UK
August, 2014
2. J.D Cox Board member of the Institute of Electrical and Electronics Engineering (IEEE) Ph D
3. K Zied, International Symposium on Automation and Robotics
representative of Lancaster University, Ph D
4. Engineering Research and Technology Development on the Space Station textbook
by: the collaboration of: Committee on Use of the International Space Station for Engineering
Research and Technology Development, Aeronautics and Space Engineering Board, Commission
of Engineering and Technical Systems National Research Counsil
Jun 27, 2006
5. Procedia Engineering, International Symposium on Robotics and Intelligent Sensors
www.sciencedirect.com
by: Mohd Yusoff, Reza Samin, Babul Ibrahim
November 2013
6. Phys Org
CORDIS Community of Research and Development Information Services [EU]
www.phys.org/news/2014-05-robots-streets.html
May 1st, 2014
7. Mobile Bin Picking with an Anthropomorphic Service Robot
IEEE & International Conference on Robotics and Automation
Karlscruche, Germany
by: Mathias Nieuwenhuisen, David Dorschel, Dirk Holz, Jorg Stukler, Alexander Berner, Jun Li,
Richard Klein, Sven Benke
May 2013
Figure References:
Figure 1: www.stockholmnews.com , Photo: dustbot.org
Figure 2: MBP-ASR formal report7
Figure 3: Procedia Engineering, International Symposium on Robotics and Intelligent Sensors
www.sciencedirect.com
Figure 4: https://www.kickstarter.com/projects/254449872/pixy-cmucam5-a-fast-easy- to-use-visionsensor
Figure 5: http://www.circuitsathome.com/mcu/robotic-arm-inverse-kinematics-on-arduino

Figure 6: http://www.mathworks.com/help/fuzzy/examples/modeling-inverse-kinematics -in-a-roboticarm.html

Figure 7: http://www.mhobbies.com/cbot-arduino-4wd-robot-car-chassis-mobile-platform-kit.html
Figure 8: sainsmart.com/diy-4-axis-servos-control-palletizing-robot-arm-model-for-arduino-unomega2560.html