cpen capstone final report - autonomous port loading vehicle final report

Running head: AUTONOMOUS PORT LOADING VEHICLE FINAL REPORT 1

Computer Engineering Capstone Final Report:

Autonomous Port Loading Vehicle

A. Schaffer, D. Hamblin, D. Smith, & C. Framiñán

Department of Physics, Computer Science, and Engineering (PCSE)

at Christopher Newport University (CNU)

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


Computer Engineering Capstone Final Report:

Autonomous Port Loading Vehicle

The objective of the IEEE SoutheastCon 2016 Hardware Competition describes a

simplified simulation of a shipping terminal.

“The IEEE SoutheastCon 2016 hardware competition is designed with the intention of

simulating modern port logistics and its related traffic. This IEEE Roads port provides a

challenging game of robotic skill and logistics. Each team has to successfully detect

shipping goods on a barge (three types of shipping container) which are strategically

placed in a harbor field. Correct shipping goods then have to be picked up and

transported to the correct shipping zone, and they will be further transported by the boat,

by rail or by truck. Each team will have 5 minutes to complete the task.” (Jovanovic,

2016)

This project attempts to meet the demands of this challenge using a platform of Arduinos and

TETRIX MAX components. Different controllers, motors, and auxiliary electronics were

considered before a final realization of the design.

1. Design Considerations

1.1 Robot Chassis

The rules of the IEEE Southeastcon 2016 Hardware Competition (Jovanovic, 2016)

specify that all robots must fit inside a 12 inch cube. After leaving the starting area, robots may

expand to fill a 20 inch cube. Any systems that are used to define the chassis of the robot must be

able to meet these size requirements, while also being flexible enough to maneuver the


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


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.


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


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


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


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.


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.


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.


2. System Design

2.1 Robot Chassis

The final resulting dimensions of the robot’s chassis were within the specifications of the

competition rules. The robot was 12.0 inches tall at its shortest and 12.5 inches tall at its tallest.

The robot was a static 12.0 inches from bow to stern and a static 11.5 inches from port to

starboard. The final design sported a flat platform with 4 Mecanum wheels arranged in a

rectangle. The base sported to center masts supporting a platform that supports the robot’s claw.

On the back of the masts is a shelf that holds the two microcontrollers and the motor shield.

2.1.1 Base Platform. The main base of the robot uses two TETRIX MAX Flat Building

Plates which are approximately 7.6 inches long by 2.5 inches wide. The pieces are set at

approximately 1.25 inches apart from their nearest edges. These plates provide a stable support

across a wide surface area, making them well suited to act as a base. Immediately connected to

the base are the four DC motors along with the wheels, as well as the vertical lift mast. The main

rationale behind this design is to set a foundation that will ensure the robot does not exceed the

size constraint of 12 inches in any direction. With the base at no wider than 8 inches, the robot

can ensure that pieces that extend past the length of the base have room without overstepping the

size restriction. Limitations of this design come from the fact that it consists of two individual

pieces. Since the two pieces have a gap over an inch wide between one another, some stability is

lost with less connection between the two and additional steps must be taken to ensure the base is

stable. Alongside this, having a gap leads to less available space to build upon the base, limiting

options for progress.


2.1.2 Vertical Lift Mast. The vertical lift mast extends approximately 9.9 inches upward

off of the chassis base. Two TETRIX MAX geared racks run up the entire length of the front of

both masts. Attached to these racks is the vertical lift platform. This connection is made using the

TETRIX sliding brackets that are designed in tandem with the racks.

2.1.3 Vertical Lift Platform. The vertical lift platform supports the robot’s claw and the

servo used to drive the robot’s claw. An additional servo is fitted with an axle and two gears.

One of the gears is used as a pinion, a gear slotted into one of the gear racks, allowing the

platform to scale the side of the mast. The other gear is used to turn the gear attached to the

vertical lift encoder, which is also carried by the platform. The platform also carries the Pixy

camera and its housing. The platform is designed to reposition, such that the claw has access to

all of the heights where blocks can be located. The encoder is used to ensure that the platform is

moved to the correct position.

2.1.4 Robot Claw. The final design of the claw uses two parallel arms wrapped in rubber

bands. To close the claw, the rightmost arm is held stationary while the leftmost arm is moved

toward the right. This is accomplished by attaching the arm to a long gear rack which is driven

by a metal gear attached to the 180 degree servo. Wrapped around each arm are rubber bands,

used to increase friction between the arm and the block. While the force of the arms alone

provides decent holding power, the arms are smooth aluminium and have low friction.

One limitation behind this design is that the force to close is delivered at the back of the

claw and spread to the front. This means that the gripping force is strongest at the back and gets

weaker towards the tip of the arms. Since the claw picks blocks up from the front of the claw,

and commonly carries them with only the front, the amount of force actually being distributed to


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


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.


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


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


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.


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.


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


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


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.


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


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

.5TurnsLif t,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 ResistanceRf loor = A

R 200ΩΔ Pot = 4

.0VΔV Pot,Theo = 5

(Voltage Divider)( )V Pot,Min = ΔV Pot,Theo 10KRfloor

(Voltage Divider)( )V Pot,Max = ΔV Pot,Theo 10KR +ΔRfloor Pot

VΔ Pot,Actu = V Pot,Max−V Pot,Min

V .0V ( )Δ Pot,Actu = 5 10KRfloor − 10K

R +4.2Kfloor


V .0V (Δ Pot,Actu = 5 )10K4.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.0V2.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 inches0.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


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.


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.


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


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.


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


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


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


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


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


weeks of the project, a servo was destroyed while attempting to determine if it could rotate both

directions.

For future CNU Robotics projects, a better inventory of the department’s resources

should be drafted. A master department resource log would yield quicker and more accurate

conclusions on components that are available for lease. This inventory could also contain a filing

system for technical documentation of controllers and ICs, which would help students quickly

determine which components they need and ensure that they know how to properly operate these

components. Alongside keeping inventory, ensuring that components work properly would

eliminate additional time lost to attempts at integrating an inoperable component.

The final step remaining for this project is the return of materials to the department. To

assist future largescale CNU Robotics groups, various TETRIX structures should be

photographed before disassembly. One issue that hindered the initial assembly of the robot was

the lack of experience assembling TETRIX structures. The disassembly of the previous project

was hasty and antieducational. The previous project contained structures that had to be

reimplemented in the design of this project, without a guide to follow. By having a record of

unintuitive design structures, future groups will be able to build on the successes of previous

capstones. The TETRIX Building Guide is not effective at showing the full potential of its

building components and only covered the construction of oddly specific, generally unhelpful

usage cases.


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/


Pixy (CMUcam5). (2016). Charmed Labs. Retrieved 14 April 2016, from

http://charmedlabs.com/default/pixycmucam5/

TETRIX Robotics. (2016). tetrixrobotics.com. Retrieved 14 April 2016, from

https://www.tetrixrobotics.com/


Appendix A Full Electronics Package


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


Appendix C Finite State Machine Structure for Software Agent Function


Appendix D Mecanum Wheel Positioning


Appendix E Vectored Movement using Mecanum Wheels


Appendix F Sharp Digital Distance Sensor Measuring Characteristics


Appendix G Robot Front and Rear


Appendix H Mecanum Wheel Implementation


Appendix I Vertical Lift Mast


Appendix J M1 and S1 Arduino Controller Package


Appendix K 4cell and 2cell LiPo Batteries


Appendix L Lift Encoder and Claw Grip

cpen capstone final report - autonomous port loading vehicle final report

Documents