More Related Content Similar to CPEN Capstone Final Report - Autonomous Port Loading Vehicle Final Report (20) 2.
AUTONOMOUS PORT LOADING VEHICLE FINAL REPORT 2
Abstract
The rules of the Institute of Electrical and Electronics Engineers (IEEE) Southeastcon 2016
Hardware Competition describe a challenge for small autonomous robots. Each robot must
navigate a model of a shipping terminal and complete a series of tasks. This model terminal
features three barges of varying heights, each bearing a different combination of colored
shipping containers. The tasks required of the robot include exiting a starting terminal,
navigating to each of the barges, successfully lifting a block, and correctly delivering each block
to its respective destination based on its color and initial placement. This project was designed to
meet the objectives and description of the competition, using TETRIX building components,
Arduinos, and a Pixy Camera (CMUcam5).
Keywords: IEEE, PCSE, CNU, robotics, Arduino, Pixy Camera (CMUcam5), TETRIX
4.
AUTONOMOUS PORT LOADING VEHICLE FINAL REPORT 4
competition course. The chassis system must support the addition of sensors, actuators,
controllers, and power supplies.
The robot was constructed using TETRIX MAX ("TETRIX Robotics", 2016)
components. The PCSE department had purchased a TETRIX MAX R/C Starter Set for use with
senior robotics projects. This helped keep costs directly related to the robot’s chassis relatively
low, even though additional parts had to be ordered for the final design of robot’s chassis. This
order of new parts cost approximately $90. In total, the cost of all the TETRIX components used
to finalize the design of the chassis was $700; however, all TETRIX components can be used in
future projects.
1.1.1 Durability. TETRIX MAX components are cut from 0.128 inch thick aircraftgrade
aluminum. Some of the larger, flatter pieces are susceptible to bending and flexing. The smaller
pieces are more robust and can handle more stress. The IEEE hardware competition models
shipping containers with SprucePineFir Furring Strips, cut to both 5 inch lengths and 2.5 inch
lengths. Any arrangement of TETRIX MAX pieces should be more than strong enough to
support a collection of these wooden blocks, as well as the combined weight of the robot.
1.1.2 Reusability. TETRIX MAX components connect using a system of precut holes,
socket head cap screws, and kep nuts. The kep nuts allow MAX components to be tightly fitted,
while also being relatively easy to be disconnected, with small amounts of wear. This aspect was
invaluable, as the robot’s chassis was redesigned twice.
1.1.3 Servo and Motor Support. The TETRIX MAX system was designed for student
and hobbyist robotics projects. As a result, the MAX R/C Starter Set contains an assortment of
5.
AUTONOMOUS PORT LOADING VEHICLE FINAL REPORT 5
motors and servos, along with various struts and mounts for attaching these components to the
robot.
1.1.4 Flexibility. The larger components provided in the TETRIX MAX R/C Starter Set
measure 12 inches in length. None of the 12 inch pieces could be used in the design of the robot
chassis, given that 12 inches was also the robot’s maximum starting dimensions. In addition,
TETRIX MAX components have precut holes in regular arrangements at regular intervals. The
smallest static angle that can be created using a TETRIX MAX system is 15 degrees, limiting the
system’s ability to create specific forms and geometries. Smaller, unsecured angles can be
created using hinges or servos.
1.2 Robot Motor System
The design of the robot specifies a fourwheeled platform bearing a center mast, bearing
a platform with a blockgripping claw. This design requires two to four motors for driving the
robot’s wheels, one motor for raising and lowering the center platform, and one motor for
opening and closing the claw. Each motor must be appropriate for its assigned task. Servo
Motors, DC Motors, and Stepper Motors were all considered for addition into the final design.
1.2.1 Servo Motors. The TETRIX MAX Start Kit contained both a continuous rotation
(CR) and a 180° servo motor. The CR servo operates by continuously spinning the motor in
either direction at speeds that are relative to a function of the frequency of the input signal. CR
servos have no positioning feedback and their speed is easily reduced when under load. The 180°
servo has an angular range of 180° and operates by rotating the axle to specific angles based on
a function of the input frequency.
6.
AUTONOMOUS PORT LOADING VEHICLE FINAL REPORT 6
Using these servos reduces the overall cost, as they were included in the original starter
kit. The CR servo was considered for the vertical lift system, since its range of rotation is not
limited. However, without position feedback, additional components would be required to
determine the height of the lift platform. The 180° servo is considered for opening and closing
the claw, as it can be set to the same position without decay. The advantage of using servos in
these situations is their high torque. These servos have the torque required for holding the claw
closed and holding the vertical lift in place at the cost of precision.
1.2.2 DC Motors. DC motors utilize voltage input into them to produce torque. The
specific motors that were considered have an operating voltage of 12V, although they will
continue to operate with power input as low as 6V. These motors accrue no additional
construction costs since four were included in The TETRIX MAX Start Kit. These motors have
sufficient torque for building and maintaining the speed of a platform built from TETRIX
components. As a drawback, these motors need a 12V to operate correctly, which requiring a
dedicated power supply, since most of the robot’s other electronic components use 5V.
1.2.3 Stepper Motors. Stepper motors operate similarly to servos, except they are
designed to move a specific number of degrees for a given input, allowing for precise control of
its movement. A stepper motor could be used for raising and lowering the vertical lift. The
advantage of a stepper in this configuration would be knowing how many steps it has moved,
instead of requiring an additional encoder. However, the cost of the project would increase, as
various specialized stepper motors would have to be purchased. Also, stepper motors generally
do produce high torque, which could prevent a stepper from moving the mast upward. Even if a
7.
AUTONOMOUS PORT LOADING VEHICLE FINAL REPORT 7
reasonably sized stepper could lift the vertical mast, it would operate slower than a less
expensive servo with an encoder.
1.3 Robot Wheels
The rules of the competition specify that the floor of the competition space will be a
wooden 8 foot square. The surface of this square will be coated in oilbased black paint. The
competition space also features various obstacles. The rules of the competition created some
debate on wheel types. The wheels provided in the TETRIX MAX R/C Starter Set and Mecanum
wheels with TETRIX compatibility were the two primary objects of discussion.
1.3.1 TETRIX MAX Wheels. The TETRIX MAX R/C Starter Set provides a set of 4
simple drive wheels. Each wheel has a 3 inch diameter and features a rubber coating on its
driving surface, to help keep high traction. Using these wheels would help minimize construction
costs, since they were included in the TETRIX starter set. These wheels also have a relatively
small footprint, which could keep the overall size of the robot low.
1.3.2 Mecanum Wheels. A Mecanum wheel (Diegel, Badve, Bright, Potgieter, & Tlale,
2002) is one particular wheel design that allows a vehicle to move in any direction. These wheels
feature rollers as their driving surface, each slanted at 45 degrees. This angle allows the wheels
to displace the force slightly to either side, which in turn allows them to strafe when the back and
forward wheels move in opposite directions, as well as turn in place without issue. In addition,
the alternating direction of the rollers on the robot grants it stability in its movement.
Mecanum wheels are costly, due to their unorthodox design, and are a heavier investment
than using the wheels from the TETRIX kit. Unlike the TETRIX wheels, which would only
8.
AUTONOMOUS PORT LOADING VEHICLE FINAL REPORT 8
require two motors, Mecanum requires a separate motor for each wheel for directing the robot
to strafe, and turning the wheels in general.
Due to the roller design of the wheels, the robot will experience a bumpy ride that may
knock it off course or move components around. However, course correction can be applied
while the robot is driving.
1.4 Controller
The competition rules require robots to operate autonomously while finding, acquiring,
and transporting blocks. A controller must be chosen than can process and perform operations on
all of the information gathered from sensors. This hardware will act as the central “brain” of the
robot, sporting a finite state machine to control various actuators. For the purposes of this
project, Arduinos and NI’s myRIO were investigated before incorporation into the final design.
1.4.1 Arduinos. Arduinos (“Arduino”, 2016) are opensource microcontrollers that are
commonly used in electronics projects. Arduinos are common due to their low cost, reliability,
and ease of use. They also feature a flash memory, allowing them to retain programs when
unpowered. Arduinos fall short in processing power, given their 8bit Arithmetic Logic Unit, a
typical clock frequency of 16MHz, and small memories for stored programs. Various types of
Arduinos are available, but only the Uno and the Mega 2560 models were considered for this
project.
Unos and the Mega 2560s are relatively low cost and modular, increasing their
replaceability in the event of component failure. The Mega 2560 is the more expensive of the
two, due to its increased number of available, programmable pins. Both Arduinos can be
expanded with shields, external devices designed specifically for Arduinos that add extra
9.
AUTONOMOUS PORT LOADING VEHICLE FINAL REPORT 9
functionality. Adafruit has developed various Arduino Motor Shields, allowing Arduinos to
easily command a system of motors. In addition, Arduinos were designed for communication
with other Arduinos, facilitating networks of controllers,
Overall, a purely Arduino system is sufficient for the objectives and restraints of this
project. They are relatively low cost and are generally small for microcontrollers. This project
could be accomplished using a system with two Arduinos. One could be used primarily for
commanding motors and the other could be used primarily for reading sensors. A communication
protocol (Appendix B) was drafted in the event that a 2Arduino system was implemented.
1.4.2 myRIO. The myRIO (“NI myRIO”, 2016) is a controller developed by National
Instruments (NI) for student electronics projects. The myRIO features several onboard
components and considerable processing power. The device features a dualcore, ARM®
Cortex™A9 processor, a Xilinx Z7010 FPGA, 40 programmable digital I/O lines, 16 analog
lines, and a Linux operating system. The myRIO is programmed using either LabVIEW, NI’s
proprietary systemdesign platform and development environment, or C. The device also
contains an onboard accelerometer, a feature that could be used to implement bump detection.
The myRIO is not an inexpensive controller, costing up to $1,000 when purchased
directly from National Instruments. However, the PCSE department owns several myRIO
devices, so that it can be readily replaced in the event of a component failure. The advantages of
this device include its large memory and its processing power, which could be helpful for
decoding images and issuing commands. However, the options for programming the myRIO are
not ideal. Also, myRIOs are large devices, contributing considerably to the overall size of the
robot.
10.
AUTONOMOUS PORT LOADING VEHICLE FINAL REPORT 10
1.5 Software Package
The competition rules require robots to operate autonomously while finding, acquiring,
and transporting blocks. The tools chosen to develop the robot’s software package must scale to
the scope of the project and must allow code collaboration. All software development is
additionally limited by the device chosen to control the robot.
1.5.1 C and C++. The Arduino programming language is a set of rudimentary C and C++
functions. As a result, projects built around an Arduino platform only support code compiled
from C and C++. C and C++ classes and libraries can be compiled and linked for Arduinos,
providing greater computational flexibility. However, an ATmega328, the core of an Arduino
Uno, has a 32 kilobyte flash memory for program instructions and a 2 kilobyte SRAM for
program variables. This limiting factor creates additional stress as an Arduino’s software
demands increase.
1.5.2 LabVIEW. LabVIEW (“LabVIEW”, 2016), short for Laboratory Virtual
Instrument Engineering Workbench, is a visual programming language from National
Instruments. This software development suite employs a block diagrambased development
environment, a draganddrop approach to interfacing with devices. The myRIO is a National
Instruments product that supports LabVIEW as its primary development environment, but also
allows developers to program the device using C. Initial software development efforts
implemented LabVIEW, but the development suite was eventually discarded. LabVIEW was
determined to be incompatible with this project, due to an unfamiliarity of its details and
concerns regarding version control and collaboration.
11.
AUTONOMOUS PORT LOADING VEHICLE FINAL REPORT 11
1.6 Auxiliary Electronics Package
The robot’s auxiliary electronics package includes the power supply, the four IR distance
sensors, a vertical claw encoder, and a Pixy camera. These components are supplemental to the
robot’s computational hardware and its motor system. The most important feature of the robot’s
auxiliary electronics package is its power supply. Most of the electronic components that were
considered for the final design operate correctly when given 5V. Both of the investigated
controllers have voltage regulators. DC Motors typically require 12 Watts to drive at full speed.
Both AA and lithium polymer (LiPo) batteries were considered for the robot’s power circuit.
1.6.1 AA batteries. The TETRIX MAX Starter Kit comes with various sizes of cases for
series of AA batteries. AA batteries are low cost and nonvolatile when drained. Unless
rechargeable AA batteries are purchased, costs may substantially accrue as AAs are drained to
meet power demands. A system that uses two Arduinos and four 12V DC motors can draw a
current of up to 6 Amps. Alkaline AA batteries have a typical capacity rating of 2,500 mAh and
NiMH AA batteries have a typical capacity rating of 1,500 mAh. Each hour of testing would cost
approximately 3 Alkaline AA batteries or 4 NiMH AA batteries.
1.6.2 LiPo batteries. LiPo batteries are rechargeable and output large, steady voltages.
These batteries are effective at powering larger robotic systems, but are a safety risk. LiPo
batteries can explode if overcharged and can irreversibly decay if used when undercharged
("Lithium Polymer Batteries", 2016). The advantage of these batteries is their capacity, high
voltage and current capabilities, and their reusability.
14.
AUTONOMOUS PORT LOADING VEHICLE FINAL REPORT 14
the blocks is less than what is being initially delivered to the claw. While this works out in the
case of light wooden blocks needed to be picked up, as the weight of objects increased the force
distribution would begin to fail.
2.1.5 Overall Evaluation. TETRIX MAX components were well suited for the
requirements of this project. The components are robust, lightweight, and modular, allowing a
final realization of the robot’s chassis. The primary compatibility issue between the project and
this building system was its lack of dexterity and its overabundance of large pieces.
2.2 Robot Motor System
2.2.1. TETRIX DC Motors. Four The motors used in driving the wheels are four
TETRIX 12V DC motors. These motors come packaged with the TETRIX MAX kit and would
suit all the initial needs, so no further searching for motors was done. While some designs only
call for two motors to power the wheels needed to drive, and let steering be done by other
wheels, this implementation calls for all four wheels to be powered simultaneously due to the
Mecanum wheels. This calls for a much higher power draw as well as increased complexity in
ensuring all motors are synchronized, but the greatly increased mobility options arguably
outweigh the costs. The TETRIX DC motors perform reliably once a sufficient amount of power
is supplied to them, though can be spotty at lower voltage levels. One main factor that affects the
performance of the motors is their turning speed. This speed is a value written in the Arduino
code from 0 to 255, the former stopping the wheels and the latter making it go full speed. At
lower speeds the motors turn less precisely and can lead to the robot losing its orientation quickly
when attempting to drive straight. It is necessary to find a balance between an operating speed
15.
AUTONOMOUS PORT LOADING VEHICLE FINAL REPORT 15
that is quick enough for the motors to be accurate and slow enough that it does not throw the
robot off balance.
2.2.2. CR Servo. A continuous rotation (CR) servo is used on the robot for moving the
vertical claw to the different positions required by the competition description. This servo will
continue rotating in either the clockwise or counterclockwise direction at a constant speed,
depending on the value set programmatically, until it is manually told to stop. Combining this
servo with a 10k potentiometer with 10 turns, and reading the voltage value through it, different
levels can be determined for the positions it requires. The speed at which the servo is able to
move the claw is determined by the amount of power it is receiving, as well as the weight of the
claw system.
2.2.3. 180 servo. The second servo on the robot is limited to 180 degrees of movement,
which it uses to open and close the claw. The servo turns by selecting a degree value between 0
and 180 in the software. When the servo gains power, it will turn to a default position before
executing any code. Rather than turning the degree value stated in the programming, it instead
turns to a set value, making it easier for testing and multiple uses of the servo during operation.
A gear is attached to the turning rod of the servo, which when turning moves against a
TETRIX MAX Channel piece. This allows horizontal movement for the system that the servo is
attached to, which includes the left side of the claw. When turned to 75 degrees, the claw is open
enough to fit a block in the middle and fit the sides of the claw through the space between the
blocks. It is closed with just enough pressure to hold the block and prevent it from dropping at
155 degrees.
16.
AUTONOMOUS PORT LOADING VEHICLE FINAL REPORT 16
2.3 Robot Wheel System
The final design opts to use a set of Mecanum type wheels as opposed to the standard
wheel set that came as a part of the TETRIX kit, a decision mainly influenced by their improved
mobility options. Mecanum wheels are a type of wheel that are designed to be able to move in
any direction and are not restricted to the forward/backward movement limitations of
conventional wheels (Diegel et al., 2002). The way Mecanum wheels achieve this is by having
rollers set at an angle around the circumference of the wheel which displace the force at which it
they move (Diegel et al., 2002). The wheels individually displace the force laterally, however
when combined with the force from the other wheels can be directed forwards, backwards, left or
right. The main area where these wheels find their advantage is in small lateral movements. As
the robot is required to pick up blocks that are not very large and have little space in between
them, some precision is required in lining up to be able to successfully grab a block. By having
Mecanum wheels in place, the robot is able to make lateral movements with ease in order to line
up to a block; it simply needs to strafe left or strafe right. If a set of regular wheels were to be
implemented instead, the robot would need to back up, drive forwards and slightly to the side,
and straighten out, then repeat if more adjustment is necessary.
The set of Mecanum wheels used in the final build is the AndyMark am2626 4”
Mecanum Wheel set, which includes four unassembled wheel kits and cost approximately $90.
The wheel kits are assembled by hand and are made so that two are “right handed” and two are
“left handed” as according to the design instructions (“AndyMark”, 2016). With the wheels
constructed, they are placed in a fashion resembling an ‘X’ with left handed wheels in the top left
17.
AUTONOMOUS PORT LOADING VEHICLE FINAL REPORT 17
and bottom right corners, and right handed wheels in the top right and bottom left corners. This
structure can be seen in Appendix D, and its implementation in Appendix H.
Each wheel is operated by a TETRIX 12V DC motor which receives power from the
Adafruit motor shield. Each wheels is rotated independently depending on the robot’s desired
direction of motion. If the robot needs to move forwards, backwards or turn, the wheels can be
operated as if regular wheels were attached. All motors set to forwards will drive the robot
forwards and vice versa. When the robot needs to strafe, each wheel needs to be rotated in the
opposite direction as the two closest wheels. This causes each wheel to cancel another’s forward
or backward moment, forcing the robot to drift perpendicular to its fronttoback axis. A diagram
showing how each wheel should be rotated in order to drive the robot in any given direction is
shown in Appendix E.
For a wheeled robot that needs unrestricted movement in 2dimensions, Mecanum wheels
are a very good choice. They are not necessarily ideal. At its best, the set compatible with
TETRIX MAX operates acceptably. In the final implementation, the Mecanum wheels were
prone to skidding and drift, and its rollers rotate with varying degrees of resistance. Ultimately,
they are imprecise. This could be remedied with either a higher quality set of Mecanum wheels
or a different, nontraditional wheel setup.
2.4 Computational Hardware Package
The final design of the robot involves the use of two Arduino Unos serving as its
computational hardware. This platform was chosen based on availability of the devices, the
purpose of the project, and not requiring the computational power of a myRIO or Raspberry Pi.
Two were required for the purpose of using motors, servos, and sensors they would not all fit
18.
AUTONOMOUS PORT LOADING VEHICLE FINAL REPORT 18
on one device, with the lack of pins, memory size, and to ensure the Arduino did not receive too
much power. One of these Arduinos, referred to as M1, has an Adafruit motor shield attached to
it to operate the motors and servos of the robot. The other, referred to as S1 from here on,
contains the main software package of the code that issues commands to M1 through the serial
communication lines on both devices pin 0 and 1, RX and TX respectively as well as the
connections to the sensors and Pixy camera. These two devices control all of the logic for the
robot.
2.4.1 M1. Arduino M1 operates as more of a receiver than anything, performing the
commands it is issued and reporting to S1 that it received them. Due to the presence of a motor
shield, the majority of the pins on the Arduino are unusable, but the functionality to control up to
four motors and two servos is added. The main purpose of M1 is to operate the motors that drive
the Mecanum wheels of the robot, the CR servo that controls the claw’s vertical movement, and
the 180 servo that opens and closes the claw. The four infrared sensors two for aligning the
robot and two for identifying when to stop driving are also attached to the analog pins of M1,
and determine how long the motors should drive for.
The C++ project for M1 includes a while loop for waiting for commands to be sent from
S1, along with a ready bit that tells it whether to read in a command or not, and selects a case in a
switchcase statement that includes all of the commands it may receive. When it receives a
command, it will initially tell S1 that it has it with “REC”, and once it is done it will reply
“DONE”. This is to ensure that the proper order is followed for commands, and it does not flood
the serial buffer on M1 with extra commands.
19.
AUTONOMOUS PORT LOADING VEHICLE FINAL REPORT 19
2.4.2 S1. The main controller of the robot is S1, which handles issuing the commands to
M1 for movement of the robot, processing image information from the Pixy camera, and
encapsulating the robot’s agent function. The information from the Pixy tells S1 what color
block the robot is holding grabbing, as well as the color of the delivery bins.
The majority of the C++ code between the two projects is loaded onto this Arduino, and
there is sufficient space on the board to not produce any issues. The software on the board is
discussed in more detail in Section 2.5: Software Package.
2.4.3 Arduino Communication. The two Arduinos communicate through the use of two
ready lines and two serial communication lines. The pins used include one for informing M1 that
S1 is ready to send a command, one to inform both Arduinos when the power switch is on or off,
and two for the distance sensors that indicate when the robot should stop moving. The Tx and Rx
lines on M1 are connected to the Rx and Tx lines of S1, allowing serial communication between
the two. This allows S1 to send commands to M1 in the form of ASCII characters, allowing easy
debugging and configuration of commands. A command protocol can be found in Appendix B.
2.4.4 Arduino Failures. Working with the two Arduinos and auxiliary electronics
package caused several issues during development and implementation. The initial configuration
of the system, powering M1 with the same four cell LiPo battery responsible for powering the
motors and servos, proved to be disastrous. After power spikes burned out an Arduino Mega and
two more Unos, M1 was switched to a power source plugged directly into the power pins of the
Arduino, and not through the power connections of the motor shield. After testing this
configuration, the Arduinos stopped burning out.
20.
AUTONOMOUS PORT LOADING VEHICLE FINAL REPORT 20
Also, the Arduino suffered failures and strange behavior when touching the aluminium
surface of the TETRIX pieces it sat on, causing the device to reset the software loaded on it, and
produce wonky behavior with sensor readings. This was remedied by placing a piece of
cardboard under the Arduino, which appeared to resolve the issues.
2.4.5 Ideal. In an ideal situation, the entire robot would run off of the logic from one
device, eliminating all device communication issues. This would reduce the amount of code
required, as well as the complexity. Such a device would also support programming languages
that are more user friendly and have better highlevel utilities. Raspberry Pis support Python
projects, which would allow more useful software to be drafted more easily. Inexperience and
the project’s time budget restricted too much experimenting with other devices. Too much time
was spent on myRIO integration, resulting in a pure Arduino implementation.
2.5 Software Package
The computational hardware of the robot is programmed in C++, the language supported
by the Arduinos. The software package on the two Arduino’s consists of an Arduino .ino file and
C++ classes/header files, developed in the Arduino IDE plugin to Microsoft Visual Studio 2015.
This development environment supports largescale projects with many files, whereas the
Arduino IDE is suitable only for a couple of files there is no project management functionality.
For each Arduino, a separate project was developed in Visual Studio that are uploaded to the
devices through a USB connection to the PC with the projects.
Each project contains a main class, the .ino file from which all of the code is ran from, as
well as several classes depending on the functions. These classes include one for the motor
functions, a robot class with values for the motors and servos, a claw functions class, a block
21.
AUTONOMOUS PORT LOADING VEHICLE FINAL REPORT 21
functions class, and a general functions class with other methods required to satisfy the objective.
The project for M1 contains libraries for the Adafruit motor shield and servos, and the other
Arduino S1 includes a library from Pixy that allows manipulation of the images processed from
the camera.
2.5.1 Finite State Machine. In order to separate sections of code required for the
different stages the robot will be in, a finite state machine structure (FSM) was established. The
four main stages of the FSM are: the robot looking for blocks, adjusting to a block and picking it
up, looking for the bin it belongs to, and then adjusting to the bin and dropping the block off.
Once the final stage is completed, it goes back to the first stage and the process is repeated, until
the power switch is turned off. A diagram of the structure can be seen in Appendix C that shows
more of the ways it can change states.
2.5.2 Challenges. Using this specific software package with the hardware configuration
of the robot provided several challenges. This includes difficulties of using the C++
programming language, the communication between the two Arduinos for issuing commands,
and the memory requirements of the code versus the allowed space on the devices.
First, optimal code for the robot could not be developed due to inexperience with
Arduino’s custom C library. This led to general solutions to programming challenges that were
not idiomatic.
Next, the communication between Arduinos proved to be a difficult task, which requires
transmission through serial ports, and reading in the data between C++ projects. Whenever a
message is sent between the devices, it is left in a 64bit buffer on the device until a read
command is sent, but the challenge was in having it read the message as it arrived, without
22.
AUTONOMOUS PORT LOADING VEHICLE FINAL REPORT 22
getting pushed back behind a newer message or erased. This problem was remedied through
code that supplies indicators that it was both ready for a message and that it had received the
message once processed.
Finally, the challenge of memory space on the Arduinos is due to using the smallest size
models, Unos, which can only hold 32 kilobytes in flash memory for instruction. This also
presents a problem for image processing, which was handled by the Pixy camera’s internal board
and relayed as arrays of blocks that can be accessed in the code without hassle.
2.6 Auxiliary Electronics Package
2.6.1 Power. The final power arrangement of the robot included the use of a twocell
LiPo battery and a fourcell LiPo battery. Each cell of a LiPo battery has a nominal voltage of
3.7V, so their voltages had to be stepped down and regulated. A 12V Battery Elimination Circuit
(BEC) is used regulate the fourcell LiPo to provide power to the robot’s motors. This BEC can
handle current up to 5 Amps, equal to the maximum power draw of the system when all motors
are running at full power. The twocell LiPo is regulated down to 5V using a 5V BEC. The
twocell LiPo battery is used to power the two Arduinos and the auxiliary electronics package.
The twocell LiPo’s BEC is rated to 3 Amps, which is well above the maximum current draw
from the two Arduinos and their supplemental electronics. Both LiPo batteries were equipped
with voltage alarms, to signal when one of their cells had fallen out of its nominal voltage range.
When the LiPo batteries were low on voltage, they could be charged with an IMAX B6 LiPo
charger, ensuring safe operation.
2.6.2 Pixy Camera. Necessary for identifying the colors of blocks and bins during
pickup and delivery, the CMUcam5 Pixy camera is included in the final design of the robot.
23.
AUTONOMOUS PORT LOADING VEHICLE FINAL REPORT 23
Within the software PixyMon (“Pixy (CMUcam5)”, 2016), color signatures can be set for the
Pixy that correspond to the four colors of the blocks/bins red, blue, yellow, and green.
Whenever one of these signatures is reported by the camera’s feed, the Pixy will report the
information through its SPI connection to the ICSP pins of the Arduino S1. The Pixy camera
performs onboard processing of image files it captures, before talking to the Arduino, identifying
these color signatures as blocks in a C++ class. The software package on S1 can take the array of
blocks and identify the color, X, Y, and size characteristics of each individual block the Pixy
processes. The advantage of this system is that the controller is not slowed down by having to
process a continuous video stream.
The final design of the vertical lift platform includes a 3D printed mount that the camera
can sit in, situated just under the two arms of the claw for clear visibility of both blocks and bins.
The 3D mount is printed using MakerBot software and the MakerBot Replicator 2X, which
accrue no additional cost to the project, utilizing plastic filament. The final design consists of a
housing that encases the sides and a partial section of the back of the camera, leaving the front
and the Pixy’s I/O port open. On the back is a clip that allows the housing to slide on to the
vertical lift platform. This design is advantageous as it allows the mount to snugly fit around the
camera and hold it in a place that was previously unreachable to attach parts. One disadvantage
of the design is that the housing has no way to control the light being fed into the camera.
Without a consistent light source, the camera can lose accuracy in its readings or even not read
anything at all when too close to a block.
2.6.3 Vertical Lift Encoder. The servo that drives the platform up and down the center
mast does not accurately report any information regarding the number of times it turned. A 10K
24.
AUTONOMOUS PORT LOADING VEHICLE FINAL REPORT 24
potentiometer was added to the vertical lift to tell the motor controller how far the platform had
moved up the center mast, acting as a primitive motor encoder. A 40 tooth gear was attached to
the shaft of the vertical lift servo and a 24 tooth gear was attached to the shaft of the
potentiometer.
The potentiometer can vary a resistance of 10 kOhms over 10 turns of its shaft; however,
the vertical lift servo only turns 2.5 times over its full range. The maximum number of turns of
the lift servo limits the maximum number of turns of the potentiometer to 4.2 turns, given a gear
ratio of 40 to 24.
0.TurnsPot,Max = 1
.5TurnsLift,Max = 2
urns 2.5Turn
24 Teeth
*T Pot,Act = Turn
40Teeth
urns .2T Pot,Act = 4
Since the potentiometer cannot turn its true maximum number of rotations, it cannot vary
its resistance by a full 10 kOhms. The potentiometer’s new resistance range is effectively 4.2
kOhms. The potentiometer is powered by constant 5V, giving the device an effective voltage
range of 2.1 V.
rbitrary Minimum Potentiometer ResistanceRfloor = A
R 200ΩΔ Pot = 4
.0VΔVPot,Theo = 5
(Voltage Divider)( )VPot,Min = ΔVPot,Theo 10K
Rfloor
(Voltage Divider)( )VPot,Max = ΔVPot,Theo 10K
R +ΔRfloor Pot
VΔ Pot,Actu = VPot,Max −VPot,Min
V .0V( )Δ Pot,Actu = 5 10K
Rfloor
− 10K
R +4.2Kfloor
25.
AUTONOMOUS PORT LOADING VEHICLE FINAL REPORT 25
V .0V(Δ Pot,Actu = 5 )10K
4.2K
V .1VΔ Pot,Actu = 2
The difference between the minimum and maximum potentiometer voltages is 2.1V,
which will limit the vertical resolution of our vertical positioning system. Arduinos feature a
10bit ADC, mapping values from 0 volts to 5 volts to a 10bit value. Instead of having 210
(1,024) distinct voltage readings over the full range of the vertical lift, only 430 distinct voltage
readings will be available to the Arduino for determining. Since the range of the vertical lift is
6.5 inches, the vertical resolution of using this potentiometer in this configuration will allow us
to reliably distinguish height measurements that are 0.015 inches apart. This is an acceptable
result, given that all of the measurements specified by the competition can vary by up to 0.125
inches.
alues 2V = 5.0V
ΔV Pot,Actu BitsADC
alues 2 values 30 valuesV = 5.0V
2.1V 10
= 4
ertical Resolution .5 inches/430 valuesV = 6
ertical Resolution .015 inches/valueV = 0
To verify this result, two readings taken 0.5 inches apart were compared using the
Arduino’s serial monitor. Theoretically, the difference between two lift heights of 0.5 inches
should be approximately . A quick test showed that two readings taken 0.530.5 inches
0.015 inches/value = 3
inches apart had a difference of about 40.
To complete the encoder system, the differences between a single reference height and all
other preconfigured heights were recorded. These preconfigured heights represent the six
26.
AUTONOMOUS PORT LOADING VEHICLE FINAL REPORT 26
different heights of the blocks on the barge of the competition board. Before each test, the
robot’s vertical lift must be positioned to this reference point, so it can record its voltage value to
determine the voltage values of all of the other heights.
2.6.4 IR Sensors. Four Pololu Carrier with Sharp GP2Y0D810Z0F Digital Distance
Sensors were added to the auxiliary electronics package. These sensors output a binary signal
depending on their detection of an obstacle. The sensors can detect obstacles between 2 cm and 8
cm away and will output a low signal once an object has been recognized. A chart showing the
sensor’s effective output can be seen in Appendix F. Two sensors are located near the base of the
robot by each front wheel, which are used to detect when the robot has reached a wall. The other
two sensors are hanging below each gripping arm of the claw, which are used to align the robot
when it needs to lift a block. These sensors will tell the robot if one arm of the claw is in front of
a block, to which it can strafe so that each arm fits within a gap between blocks. The two sensors
on the base are attached by pieces of foam doublesided tape, which holds them in place firmly
while also making sure that too much pressure is not being placed on them, as well as their pins
not making direct contact with the metal chassis. To attach the two sensors to the ends of the
claw, two custom housings were 3D printed. Inventor and a MakerBot Replicator 2X were used
in the 3D modeling process. A limitation of the IR sensors used is that their digital response
leads to a lack of precision. Since any obstacle within a 2 to 8 centimeter range will return a
signal, the robot could only discern an estimate of its orientation. This makes adjusting the robot
to be even against an obstacle or wall very difficult, since there is no way to determine if the two
sensors are the same distance from said obstacle. Distance sensors with an analog outputs should
have been used instead.
27.
AUTONOMOUS PORT LOADING VEHICLE FINAL REPORT 27
3. Testing and Evaluation
The final product was tested thoroughly for any changes required in the design, as well as
for how well it achieves the objective set forth. The robot is evaluated in terms of what
succeeded in the end, and what did not. Each component and their compatibility with other
components is tested to see if it meets the functionality it was designed for. Unfortunately, the
robot was not completed in time for the IEEE Southeastcon 2016 Hardware Competition, the
primary goal of the project, as it was plagued by issues as the deadline for registration
approached.
3.1 Testing
Through testing of the components of the robot, the effectiveness of each could be
determined and redesigned based on issues or ideas for improvement. First, the chassis of the
robot was tested to ensure that it could hold all of the components of the robot within the
constraints of the project, while optimizing their location on it. To this end, the chassis was
sufficient in its design, working well and not requiring any changes after completion.
The motor system, including the servos and DC motors, are tested with code supplied by
the Arduinos. The servos were tested by performing the functions of the claw through code
supplied by the controllers. The vertical lift was raised to each of the six positions required by
the competition rules utilizing the claw’s encoder several times to check for precision and
accuracy. Also, the claw is opened and closed repeatedly to test that it will stay consistent each
time the robot needs to pick up a block. Toward the end of the project period, the claw began
exhibiting strange behavior that could not be remedied in time, in which it would move much
slower than before, and stop at different intervals.
28.
AUTONOMOUS PORT LOADING VEHICLE FINAL REPORT 28
Next, the DC motors and Mecanum wheels were tested to determine the consistency in
the direction they drove the robot taking drift into account. The motors, when operating off of
the 12V from the LiPo battery, were able to drive at varying speeds without decay. However, due
to the unorthodox design of the Mecanum wheels and their collection of rollers, the robot
experienced a bumpy ride that could knock unsecured components around, and make the robot
drift in different directions. Despite this issue, the alternative would be to use the TETRIX MAX
wheels supplied with the kit, which would require more complexity in the coding of the
controllers.
Powering the components of the robot led to several large redesigns while testing. The
12V power source was originally used to power the controller M1 through the motor shield
attached to it, which then powered the DC motors, servos, and sensors. This led to a burnout of
Arduinos that were attached to the design as M1, and the 12V was then relegated to powering
just the motor shield, motors, and servos, while the Arduino drew its power from the 5V power
source that powered the other Arduino S1. Testing this new power configuration worked to the
design, removing the issue of destroying controllers.
The controllers of the robot, M1 and S1, operated without issue once the power problems
were resolved. The serial communication between the two worked with the intended design in
the code, allowing the Arduinos to properly issue commands to the rest of the system and to each
other.
The IR sensors were tested to verify their range of consistent use as well as other
operating conditions. Upon powering the sensors, it was apparent when they were operating
correctly by a bright red LED lighting up on the back, as well as the digital “low” signal read out
29.
AUTONOMOUS PORT LOADING VEHICLE FINAL REPORT 29
from the sensor. After mounting the sensors to the chassis it became evident that the sensors had
issue when making direct connection with the aluminium body, as well as if there was too much
pressure being placed on them. This ruled out the initial option of screwing the sensors on to the
body, and a method had to be created in which neither of these issues would occur.
In the beginning of the project, the Pixy was tested for its functionality to detect and
report statistics about different color signatures. This proved effective in identifying the location
of different blocks, based on larger signatures. By the end of the project period, the Pixy
camera’s mount was completed, and it was placed just under the claw. However, shortcomings
of the mount design are apparent when the claw needs to close, as the bottom of the mobile arm
can get caught on the top of the mount, since the dimensions were printed slightly too large.
Another shortcoming of this design is that the closed back cuts off access to the camera’s
miniUSB port for debugging. While the camera will work and communicate to the rest of the
robot while in its housing, it cannot be tested and verified over the computer while attached. The
PixyMon software requires this miniUSB connection to set the color signatures of the device.
The lack of time at the end prevented a redesign of the mount with a shorter top. Ultimately, the
Pixy’s use was changed, and the new functionality was never completed, as other issues took
precedence toward the end of the project period. Due to this, the Pixy camera was never properly
implemented into the overall system.
The code for the controllers, to allow the robot to run through the autonomous actions
and complete the competition, remained unfinished. It was utilized to test many of the
components, although without having all of the issues resolved, the later steps required in the
FSM structure could not be tested sufficiently.
30.
AUTONOMOUS PORT LOADING VEHICLE FINAL REPORT 30
Overall, testing each individual component proved to show that they followed the design,
but crippling issues caused certain components to stay unfinished.
3.2 Evaluation
The evaluation of the robot deals with how closely it met the goals proposed at the
beginning of the project period. It will serve as a discussion of its final status and what it was
able to achieve.
Though as a whole the robot did not meet all of the qualifications desired, many of its
components still worked by themselves. Between being able to successfully drive, detect
obstacles nearby and pick up blocks, the robot was able to succeed in individual tasks. Powering
the robot and consistently being able to upload code are other seemingly small successes that the
robot was able to accomplish. Where the robot failed to meet goals, however was in consistency
with all of the moving parts as well as synthesizing all components.
Once the wiring reached a design that could correctly power all components, the robot
was able to move all of its parts without anything breaking. The wheels could turn consistently
and drive the same way through our tests; and though they would drift frequently, it would be
consistent. Sensing obstacles proved to be reliable, though only enough had been implemented to
consistently check for a wall and stop. The sensors were also able to work well with driving, and
could reliably stop or start moving the robot based on their reading. For the most part the claw
could operate as intended, and as long as it could be lined up to the block it needs to lift.
Synthesizing parts was where the robot failed to meet expectations. While the robot could
drive and stop at an obstacle, by the time it reached the wall the robot would be disoriented and
the sensors would not be able to assist in adjusting to become even. In addition, the sensors had
31.
AUTONOMOUS PORT LOADING VEHICLE FINAL REPORT 31
not been implemented to be able to slowly adjust to when a block could be picked up. This lead
to the claw not being able to accurately close in on a block or commonly knocking it off of the
platform. At the end of the project period, the vertical lift of the claw stopped responding to its
directions for movement and exhibited strange movement or none at all. Testing the alignment
for the robot to the blocks on the barge was very minimal, as the mounts for the sensors on the
claw were not completed until the very end of the project, which was a major requirement for
picking up the blocks for delivery. In addition, the Pixy camera proved to be of little use since its
functionality could not be implemented in time. To go along with this, the claw would have
issues with getting caught on the camera’s housing, as it was printed just a bit too large.
4. Conclusion
The robot was not prepared in time for the IEEE Southeastcon Hardware Competition.
Various setbacks proved to be large obstacles and the project progressed slowly. However, the
project was progressing in a positive direction. Individual systems had designs that proved to
work independently. The main problem was that these individual systems had compatibility
issues when connected into a single unit. Much was learned as a result of this project and there
are plenty of ways to ensure that future iterations of similar projects progress more effectively.
4.1 Lessons Learned
4.1.1 3D Printing. The IR Range Sensors and the Pixy Camera needed special mounting
brackets that were not provided by the TETRIX MAX Starter Kit. New parts were 3D printed to
connect these components to the chassis. With 3D printing being a new area to the group, there
was a small learning curve on how long it took to create models, prepare for printing, and learn
which printing techniques led to better results. With the software being free and advocated by
32.
AUTONOMOUS PORT LOADING VEHICLE FINAL REPORT 32
professors, Autodesk Inventor was the way to go to create 3D models. Prototypes were made up
based off of byhand measurements, and then exported as print files. The print files were then
uploaded to the 3D printing software MakerBot, which is compatible with the 3D printers in
CNU’s possession. With the print file uploaded to MakerBot software, the object could be
resized, rotated on all axes, and previewed before a final print file is ready to put onto an SD card
to insert into the MakerBot Replicator 2X. After a few printing cycles, it was clear that there
were favorable positions to have the object print on, as the plastic did not form correctly when
there was an area with no support. Also, after a piece would be printed out, it would be placed on
the robot to see how it fit with the other components. It took about two attempts on both the
camera and sensor mounts to get it just right. These were both mostly due to minor errors in hand
measurement. Once the 3D models were updated and reprinted, the mounts worked with our
design.
4.1.2 C++ with Arduinos. The Arduino programming language is a set of functions
implemented in C. This is not initially clear, because all Arduino code files have a .ino extension.
Once it was determined that these .ino files used a C compiler, the project started to adopt C++.
C++ gave the software package much more flexibility and allowed for a class structure. This
helped ease software development efforts and solidified C++ programming experience as a
necessity. In addition, the Arduino “IDE” is underpowered and is not a good resource for C/C++
development. Arduino plugins for Visual Studio were found, which proved to be an invaluable
resource.
4.1.3 Soldering and Safety Precautions. A lot of electrical components needed to be
soldered, unsoldered, and resoldered throughout the duration of this project. Some of these
33.
AUTONOMOUS PORT LOADING VEHICLE FINAL REPORT 33
connections were the DC motor connections, the BEC connections, and the IR sensor
connections. Unfortunately, soldering is not a topic that is covered in the base computer
engineering curriculum. Some instruction was necessary to ensure that all soldering was
performed safely. The melting point of most solder is around 188°C (370°F). The tip of a typical
soldering iron can reach temperatures between 330°C and 350°C (626°F and 662°F). When
soldering, burns and fires may occur if the area is not properly prepared or the individual is not
properly instructed. Also, proper eye care must be observed to prevent blindness from molten
airborne solder particles.
4.2 Changes Next Time
A large amount of lost time throughout this project was due to learning new technologies.
Some time was lost to attempts at integrating the myRIO into the controller setup. Additional
time was lost due to using a nonstable power system. The original power circuit design caused a
burnout in the USB driving chip of the primary Arduino, because the mechanics of power
bridges were unclear. With more experience in robotics, much more of the foundations of the
project could be smoothly implemented. In the future, a more simplified robotics package that
better suits its goals would be ideal. If the process of designing and building the robot is
smoother, more time could be allocated for designing the robot’s agent function and testing its
implementation.
4.3 Proposed Further Work
In relation to this specific project, too much time was wasted. Building the robot’s frame
to meet the competition's requirements was a large sink of time. Electronic component failures
were a large sink of time. In order to complete the project, the software package needs to be
34.
AUTONOMOUS PORT LOADING VEHICLE FINAL REPORT 34
finalized. The Arduino Mega acting as M1 failed, which set the project back considerably. The
issue was quickly determined and a complete redesign of the power circuit was completed.
After this system failure, M1 had to be downgraded to an Uno given an absence of spare
Megas. M1 was responsible for various ready bits and certain specific sensors, since the Mega
had plenty of extra pins. All of M1’s digital IO ports are completely obscured by the motor
shield, forcing their transfer to S1. This would require an expansion of the project’s
communication protocol, to account for sensors that inform M1 directly.
This project could be adapted into curriculum for instructing the next CNU Robotics
team. One of the pitfalls of this project with our given team was the lack of background
knowledge needed to get a project such as this off of the ground. A considerable amount of prior
mechanical, electrical, and autonomy knowledge was required, and much time was lost making
up for that inexperience. By demonstrating projects like this as case studies, more students can
be exposed to aforementioned topics. With faculty advising along with upperclassmen support,
students can be better adjusted to dealing with delicate equipment and avoid many of the
experienced issues.
This project exposed some issues with the department’s inventory system. When trying to
source a 10 turn potentiometer for the vertical lift encoder, every lab that might contain electrical
components were searched, only to discover that there were none. Also, when the Arduino Mega
experienced a power failure, finding a replacement in the department proved to be a challenge. In
addition, some of the Arduino Unos that were sourced as a replacement had irreparable driver
issues. There is also a lack of technical documentation in the department. Within the first few
36.
AUTONOMOUS PORT LOADING VEHICLE FINAL REPORT 36
Bibliography
Ada, L. (2016). Adafruit Motor Shield. adafruit.com. Retrieved 11 April 2016, from
https://learn.adafruit.com/adafruitmotorshield/overview
AndyMark 4” Mecanum Wheel (am2626). (2016). andymark.com. Retrieved 14 April 2016,
from http://files.andymark.com/am2626%204in%20Mecanum%20Wheel.pdf
Arduino. (2016). Arduino.cc. Retrieved 11 April 2016, from http://arduino.cc
Arduino Environment. (2016). Arduino.cc. Retrieved 14 April 2016, from
https://www.arduino.cc/en/Guide/Environment
Diegel, O., Badve, A., Bright, G., Potgieter, J., & Tlale, S. (2002). Improved Mecanum Wheel
Design for Omnidirectional Robots. Freie Universität Berlin. Retrieved 14 April 2016,
from
http://ftp.mi.fuberlin.de/pub/Rojas/omniwheel/DiegelBadveBrightPotgieterTlale.pdf
Jovanovic, V. (2016). Hampton Roads Shipping Container Terminal Challenge. Hardware
Competition IEEE Southeastcon 2016. Retrieved 11 April 2016, from
http://sites.ieee.org/southeastcon2016/studentprogram/
LabVIEW. (2016). National Instruments. NI.com. Retrieved 14 April 2016, from
http://www.ni.com/labview/
Lithium Polymer Batteries. (2016). Horizon Hobby. Retrieved 14 April 2016, from
https://www.horizonhobby.com/pdf/EFLLiPoSafetyWarnings.pdf
NI myRIO. (2016). National Instruments. NI.com. Retrieved 11 April 2016, from
http://www.ni.com/myrio/
39.
AUTONOMOUS PORT LOADING VEHICLE FINAL REPORT 39
Appendix B
Serial Communication Commands
Command Meaning Values Examples
C[y] Set claw open or
closed
0 or 1 C0 // Close
C1 // Open
V[h] Set vertical lift to
height h
0 through 7
0 → Lowest pos.
6 → Highest pos.
V1 // Set height to 6.5”
V4 // Set height to 10”
V5 // Set height to 11.5”
(W|A|S|D)[n] Move (Forward,
Left, Back, Right)
at Speed n
0 through (9 or 0xF) W7 // Forward 7 (0111)
A3 // Left 3 (0011)
SC // Back C (1010)
D0 // Stop (Right 0000)
(Q|E)[n] Spin (Clock,
Counter) at Speed
n
0 through (9 or 0xF) Q5 // Counter 5 (0101)
E4 // Clockwise 4 (0010)
QD // Counter D (1101)
B[c] Block color c 0 through 4 B0 // None
B1 // Red
B2 // Green
B3 // Yellow
B4 // Blue
