Multi-Disciplinary Senior Design Conference
Kate Gleason College of Engineering
Rochester Institute of Technology
Rochester, New York 14623
Project Number: P09204
1 KG PAYLOAD MODULAR ROBOTIC PLATFORM
Nandini Vemuri
Electrical Engineer
Jason Jack
Computer Engineer
Emily Phillips
Electrical Engineer
Ryan Schmitt
Computer Engineer
Jeff Howe
Electrical Engineer
John Corleto
Computer Engineer
ABSTRACT
NOMENCLATURE
The Robotic Platform for 1kg Payloads (RP1) is a
robotic assembly and physical platform built for the
purpose of expediting construction of robotics of a
higher complexity. Quite frequently, rudimentary
navigation and obstacle avoidance logic consumes a
large portion of time when building any robotic
device. This platform is intended for applications in
which a robotic device needs navigation control, but
the builder does not want to focus a lot of time or
money into designing the components which
manipulate motion.
The RP1 system consists of two core assemblies: the
RP1 Control System developed by P09204, the RP1
Mechanical Motor Module developed by P09203 and
chassis to be developed in 2009 academic year. The
results indicated that the chosen design seen in Fig. 1
works well, but has room for future improvements.
Figure 1: Completed RP1 Prototype
COTS - Commercial Off The Shelf
DC – Direct Current
EDGE - Engineering Design Guide
Environment
EMF – Electromotive Force
GUI – Graphical User Interface
PIC - Peripheral Interface Controller
PID – Proportional Integral Derrivative
PCB – Printed Circuit Board
PWM – Pulse Width Modulation
RIT – Rochester Institute of Technology
RP1 – Robotic Platform 1 kg
RP10 – Robotic Platform 10 kg
and
INTRODUCTION AND BACKGROUND
Introduction: The goal of this project is to construct a
land-based robotic platform for the Vehicle Systems
Technology Track. This 1 kg platform is just one of a
family of scalable platforms ranging from 1kg to
100kg. This project focuses on improving and
reducing the size of previous projects, which fell short
of expected outcomes. The platform is to be used in a
variety of education, R & D, and various outreach
applications.
RIT Mechanical Engineering has
provided funding for this project’s continued
improvement. Long term motivations for the sponsor
include educational and outreach applications (i.e.
robotics competitions), as well as improving the
reputation and visibility of the multi-disciplinary
senior design program at RIT. [1]
Copyright © 2009 Rochester Institute of Technology
Proceedings of the Multi-Disciplinary Senior Design Conference
The control system is designed so that it will be able to
carry a one kilogram payload. The payload can be a
variety of different types including a ‘dumb’ payload
(just a weight), sensor payload, or smart payload. The
smart payload will be any robotic device which will
build off the RP1 platform as a basis for motion. This
will allow the payload to control the navigation of the
platform.
Background: The establishment and clarification of
customer needs was a crucial part of the concept
development process. An initial set of customer needs
was provided to the team. The customer expressed a
desire for these to be used in a freshman class. Thus
the overall cost was a great concern as many would be
needed to realize this goal. In order to minimize costs,
keep an open architecture, Commercial Off The Shelf
hardware needed to be kept to a minimum, as they
greatly affect the cost of the system as a whole. The
needs were developed further by the team after
meeting with the customer, assigning a hierarchal
ranking to each specific need. The customer needs
were then translated into deliverables stating what the
team would attempt to achieve [2]. These high level
customer specifications are listed below.
(1) The design must reuse as many parts from
previous designs as possible.
(2) The platform must be able to carry a payload
of 1 kg.
(3) The cost to design and build must fit within
the $1000 budget and minimize production
cost.
(4) The RP1 shall provide tethered, wired, or
wireless
communication
to
the
microcontroller.
(5) The platform must perform all testing
requirements successfully.
(6) Commercial Off The Shelf (COTS) hardware
use shall be kept to a minimum. In-house
designs are preferred to maintain a fully
open-architecture hardware design.
(7) The platform must be able to be scaled up or
down in size as well as payload capacity.
(i.e. scalable design.)
(8) The platform must be open source, robust and
well documented on the team’s EDGE
website [3].
(9) Battery life shall be able to power the control
system and two RP1 motor modules for a
minimum duration of one hour.
(10) Physical size of the RP1 shall be an order of
magnitude smaller than previous Robotic
Platform 10kg (RP10) variant.
Page 2
Then, having identified the needs of the customer, the
group began to examine and work toward exceeding
the expectations of the customer.
PROCESS
First, the team examined the materials left by previous
teams and determined what the desirable traits were
and what needed to be improved upon. It was noticed
that many of the previous products looked
unprofessional and lacking. It was also noted that the
documentation of previous projects was deficient,
which made it difficult to determine how to use the
product. Due to these reasons, the team decided to
start from the ground up to meet the needs of the
customer, while leaving a legacy of transparency and
thorough documentation to future users and
developers.
To arrive at the final designs, a Pugh chart, which
visually shows the advantages and disadvantages of
each concept, was used to make design choices. Each
idea was thoroughly examined and then, after
weighting the advantages and disadvantages of each
concept, the best solution was identified. Common
factors that were considered in this process were ease
of implementation, advice from current RIT faculty
members, engineering specifications, and personal
experience.
The microcontroller that was implemented was
decided upon promptly due to its vital importance to
the project. The Brian Dean Microcontroller (BD
Micro) was chosen due to its open source and
architecture characteristics as well as a team member’s
prior experience with it. This design decision was
strongly supported by multiple faculty members.
The next decision to be made was the type of motors
that would be used. The combination of DC for drive
and servo for direction was chosen due to power
consumption, ease of use, cost, experience, size, and
scalability. This decision was not easy by any means,
but ultimately reflected the most efficient way to meet
the requirements. This motor choice was then passed
on to the Motor Module development group for
implementation.
The team then began to develop circuit designs
for motor control and power distribution. The DC
motor is used to control forward and reverse motionin
the motor modules. A simple low power signal from
the microcontroller is used to control flow of a higher
power signal to actuate the DC motor. The DC motor
driver is controlled via a programmable PWM signal
and two discrete inputs. One discrete input is reserved
for enabling or disabling the driver entirely while the
Project P09204
Proceedings of the Multi-Disciplinary Senior Design Conference
other is used to drive the motor in forward or reverse
directions. This circuit requires both 5V logic and 12V
motor power. Voltage clamp diodes are used to
prevent back EMF from effecting the logic signals and
electrolytic capacitors are placed on the 12V power
rails to ease the impact of large current draws when
the motor is actuated from full stop. The DC motor is
actuated via a mechanical relay by the
microcontroller.[4]
The power distribution boards are instrumental in
delivering the correct voltage levels to the different
motors and components. Both boards incorporate
fuses for safety of the users, the motors and the boards
themselves. The system was designed to allow for the
addition of up to two motor modules.
The 9V power distribution board is used to supply
power to the microcontroller and other logic
subsystems. The current is limited to less than 700mA
by a fuse at the input. A status LED is used to indicate
the operation of the system and a power sense output
is used to supply a reading of the voltage input. The
9V input is fed through a 5V regulator and
subsequently fed to four identical 5V outputs.
Capacitors are utilized at both the input and output of
the regulator to improve stability and prevent rapid
changes in current. This current is again limited
through the use of a fuse to under 500mA. All fuses
are mounted with fuse clips to provide ease of access
and replacement as necessary. [4]
While the 9V system supplies the microcontroller and
logic systems, the 12V battery is used to deliver power
to the motor systems. This 12V power distribution
board feeds 12V directly to the DC motors as well as
regulating and supplying 6V to multiple servo motors.
The 6V regulators again use capacitors to ensure
stability and limit current spikes. Fuses are used both
at the 12V input and at the output of each regulator. A
status LED is used to indicate operation of the entire
system. Separate LEDs are used to indicate operation
of each servo distribution subsection. Four 12V
outputs are present along with two 6V outputs used to
power DC and servo motors respectively. [4]
By implementing discrete boards for these tasks,
modularity is greatly improved. For example, to use a
high power motor requiring more current, only the DC
driver board and power supply board would need to be
altered and not the microcontroller system. The
boards utilized a large number of surface mountable
parts that eventually could be placed in by a machine
in the manufacturing process. The team ordered five
sets of boards and parts which allowed for additional
systems to be built at a later date.
Page 3
Once the boards arrived, they were populated and
tested with a multimeter to ensure proper functionality.
One problem found immediately was that the relay did
not properly fit into the through holes. A trace cut was
also necessary for the logic power board in order to
work properly. Also, the ground pins on the DC motor
driver board were not connected, but this was fixed
using jumper wires. All of these discoveries have
been addressed and the board design was adjusted for
future production.
The motors require PWM signals, but it was
discovered that the microprocessor did not have
enough PWM outputs. This gave rise to the need for
peripheral computing to send PWM signals to the DC
and servo motor, while the BD micro was
communicating with the computer. Initially a PIC was
chosen due to its open source nature. However, a PIC
was not in the final design due to its complexity and
time constraints. The controller chosen was the
Arduino Nano due to size and ease of use. The
Arduino Nano is an open source microcontroller that
functions as a PID controller. A PID controller is used
to achieve the desired speed without much overshoot
while minimizing the rise time. This allows the robot
to gradually attain a desired speed while controlling
the jerk derivative. The PID controller directly
controls all servos, PWM drivers for the DC motors,
and monitors encoder feedback. It communicates with
the Processing Subsystem using the I2C bus controller.
The I2C bus uses only two bidirectional open-drain
lines, Serial Data and Serial Clock, with pull up
resistors. The I²C reference design has a 7-bit address
space with 16 reserved addresses, which allow for a
maximum of 112 nodes to communicate on the same
bus. This allows the user to add more addressable
items and sensors in the future by simply connecting
them to the bus.
The 12V battery was chosen to meet the electric
current requirement and to achieve the desired battery
life. The battery also needed to be as light as possible
to reduce the weight that the motors would need to
move. The best type of battery to meet these
requirements was a Nickel Metal Hydride battery.
A secondary 9V battery was also used to help remove
the spikes seen by the motor because the logic power
is very sensitive. This was a serious problem seen by
the previous platforms and caused the overall system
to fail. As a result, a second battery was used.
To achieve the customer requirement of wireless
capability, it was initially decided to reuse the
previous teams Crossbow wireless. However, upon
Copyright © 2009 Rochester Institute of Technology
Proceedings of the Multi-Disciplinary Senior Design Conference
Page 4
Figure 2: Functional Block Diagram of the RP1
further investigation in the prior team’s code, it was
determined that wireless using crossbow could not be
implemented. Hence, in the interest of time, two
IOGear Bluetooth Serial Adapters were used to
implement wireless communication. These have an
adjustable baud rate and allow the user a wireless
range of up to one hundred meters. Each adapter was
configured to the baud rate of 38400. The adapter
connected to the computer was designated as the
master, and the one connected to the microcontroller
was designated as the slave. The adapters do not
require additional software.
The Graphical User Interface (GUI) provides the user
a simple way to control the robot. The interface has
two modes of operation: basic and advanced. This
interface is able to control specific motors to move a
specific speed or distance. It also allows the user to
communicate with future sensors or devices that will
be implemented.
able to drive their motors and that the encoder
feedback was read by the microcontroller for future
development. Thus the teams worked very closely to
ensure that both projects were a success.
RESULTS AND DISCUSSION
The overall final product was put through a variety of
test cases. The first test case was performed by
prototyping the DC motor and servo motor from the
BD Micro which passed with flying colors. The next
test was to build the circuits on breadboards to ensure
that it would perform successfully and not overheat.
Through these tests, the boards were adjusted,
mistakes were found, and overall functionality was
proven. The final boards arrived and were tested.
They were found to work equally well and performed
without overheating. The 12V Power Distribution
board designs are shown in Fig. 3 and Fig. 4. [6].
The structure and subsystem interconnects are
summarized above in Fig. 2.
This shows the
connections and interactions between the separate
components.
The team also worked extremely diligently on
improving the documentation which would be left for
the future users. The team developed a user’s guide
that allows future developers a simple way to begin
using the RP1. Hardware, software and system design
information were documented so as to provide future
teams with the complete data, as required by the
customer in the Control Documents [4] [5]. The
intention was to be thorough enough so that any future
team could reuse the software and designs that were
developed, rather than discarding material.
The project also required a large multi-team approach
in order to fully meet the customer’s needs. The team
worked very closely with P09203 who were
developing the motor module that our system would
be driving. It was important that our system would be
Figure 3: PCB design of the 12V power distribution
system.
Figure 4: Hardware Implementation of 12V power
distribution on platform
Project P09204
Page 5
Proceedings of the Multi-Disciplinary Senior Design Conference
The voltage regulator was tested by applying various
input voltages and confirming a steady output of 6V.
In order to test the effectiveness of the reservoir
capacitors, a transient current spike was applied to the
input of the regulator as the output is observed. A
substantially smoother output relative to the input
verified the functionality of the reservoir capacitors.
The Operational Software for the BD Micro was also
unit tested. Unit testing is a subset of software tests
which implement unique, isolated functionality of
software modules, namely drivers. The software unit
test verified all functionality of a specific software
module while using the least number of modules.
Ideally, the only code that is executed on the target
platform during the test is the unit under test. The
different commands and communication protocols
were tested successfully.
The PID controller software analysis involved testing
the individual commands used by the Operational
Software and the PID controller to communicate with
each other. The PID controller was unit tested by
isolating it from the motor module (when possible)
and the Operational Software. The PID is controlled
over the I2C bus using a custom communications
protocol [5].
The GUI was implemented as shown in Fig. 5. It was
desired that the interface would be simple enough that
even the most basic user would be able to use, while
being open enough for advanced users to implement
sensors in the future. The GUI was tested with the
entire system and worked as expected. The GUI was
also tested both by itself (unit testing) and with the
entire system (integration testing) to ensure that it was
robust and would not cause errors with a user input.
The GUI unit testing checks each software module of
the GUI client software. Every command sent to the
microcontroller is tested through the executing a
sequence of actions in the GUI. Integration testing is a
form of ad-hoc systems testing which requires GUI
control of the microcontroller. These test represent the
highest level of abstraction from the inner working
system command protocol and behavior.
Figure 5: Graphical User Interface
The final test that was implemented was the IOGear
Bluetooth wireless communicators.
They were
initially tested using two computers to ensure that they
would communicate. Then, they were tested for
proper integration by connecting the adapters to the
system and tested by sending a command from the
GUI to the robot. This is shown on the finished
prototype in Fig. 6.
The battery was also tested to ensure that it met the
specifications of battery life and electrical current
draw. It was found that the Nickel Metal Hydride
battery was able to last at least 5 hours under a
strenuous load. However, the 9V battery was only
able to sustain a battery life of 1.5 hours. While it
does meet the specifications, it has much room for
improvement. The temporary battery placement is
shown in Fig. 7.
Figure 6: Wireless Communication on Prototype
Copyright © 2009 Rochester Institute of Technology
Proceedings of the Multi-Disciplinary Senior Design Conference
Page 6
Testing the boards went smoothly, but the team was
slowed down by not having a specific test fixture to
use. The complexity of the wiring involved made it
difficult to tell if the system was not working or if it
was simply a wiring mistake. In the future it would be
a good idea to either have a predesigned test setup or
to have the necessary cables made ahead of the boards.
The lack of a full set of cables made testing much
more difficult than necessary.
Figure 7: Temporary battery mounting harness on
prototype.
CONCLUSIONS AND RECOMMENDATIONS
After the customer demonstration, the feedback
received about the prototype was positive. It has
either met or exceeded all the customer requirements
and was easily adaptable for new and more complex
applications.
Although the product was successful, some minor
improvements are planned for future teams. The
overall cost of the design, while within budget, was
cost prohibitive for large scale implementation. Also,
the batteries should be combined so that the 9V battery
will not expire faster than the 12V battery.
Another issue that the customer identified was the use
of COTS products like the IOGear Wireless
communicator. It was necessary to use for successful
implementation, but in the future a much more cost
effective solution should be chosen.
Additionally, the microcontroller boards were
discussed.
Because the schematics for the
microcontrollers are open source, it was suggested that
the board designs be combined. This would greatly
reduce cabling, complexity and ultimately, the cost.
The team also had suggestions for future groups.
These suggestions stem from issues experienced in
PCB design, manufacturing and testing. A vendor and
layout package were chosen early in the process. This
proved to be an inconvenience later on when sourcing
PCB manufacturers. Unbeknownst to the team, the
software selected provided files that could only be
used through one specific vendor. This limited the
team’s options and meant a higher price had to be paid
to have them made. For future teams, it would be a
good idea to do more research into vendors and
software options ahead of time.
Concerning the electrical systems, the power supply
for motor and logic can be greatly improved. The
current design is simple and provides basic
implementation, but can be replaced with a more
efficient switching power supply. In this regard, much
of the power consumption can be reduced. This would
also reduce heat dissipation, so smaller heat sinks can
be used. Furthermore, magnetic isolation between
battery source voltage and load circuitry can be
achieved using the switching power supply. At the
moment, to isolate sensitive logic equipment and
motor equipment, two batteries are used. However, if
the power supply were replaced with a switching
regulator and transformer coils as opposed to the
current linear regulator, then a single battery can be
used so that a cleaner, more efficient, and safer power
can be provided to the system.
Concerning software, the command line protocol
could be changed from an ASCII communication
interface to a binary interface, as to reduce the number
of bytes sent across the serial channel. This would
increase response time of the commands sent from the
GUI. Additionally, there is a persistent bug in the
GUI which may be caused by the underlying Serial
RxTx library which causes the GUI's serial
communication to fall out of sync with the Operational
Software on the microcontroller. Using an in-house
communications library in the GUI or other more
secure serial library may improve response time and
increase system stability further.
In conclusion, the project has room for improvements
that should be easily attained in a single further
revision. The project meets or exceeds the customer’s
expectations through a design philosophy of
modularity, scalability, and open architecture
implementation; it is easily adaptable to future needs.
ACKNOWLEDGMENTS
The project would not have been possible without the
help of organizations such as RIT the Mechanical
Engineering Department and the Gleason Foundation.
Special thanks to Dr. Edward Hensel, Dr. Wayne
Walter, Todd Fernandez, Dr. Jay Yang, Dr. Kenneth
Project P09204
Proceedings of the Multi-Disciplinary Senior Design Conference
Hsu, Dr. Farat Sahin, Dr. Mark Hopkins, and Dr.
Christopher Hoople. Also special thanks are given to
Ken Snyder who spent time out of his busy schedule
to help with parts and acquisition..
REFERENCES
[1] Walter, Wayne, and Edward Hensel, 2008. "
Family-Based Project Approach to Multidisciplinary
Senior Design." Proc. of ASME 2008 International
Mechanical Engineering Congress and Exposition,
Boston, USA.
[2] Phillips, Emily C., Jeffery J. Howe, and Jason A.
Jack. "Customer Assessment."
<https://edge.rit.edu/content/P09204/public/document
ation/week8/Needs%20Assessment%20%28Week%20
8%29.pdf>.
Page 7
[3] P09204: RP1 Motion Controller Gen 2. 2009.
Rochester Institute of Technology. 8 May 2009
<https://edge.rit.edu/content/P09204/public/Home>.
[4] Vemuri, Nandini, Emily C. Phillips, Jeffery J.
Howe, and Jason A. Jack. “Hardware Control
Document.”
https://edge.rit.edu/content/P09204/public/documentat
ion/Hardware%20Control%20Document.docx
[5] Jack, Jason A., John Corleto. “Software Control
Document.”
https://edge.rit.edu/content/P09204/public/documentat
ion/Software%20Control%20Document.docx
Copyright © 2009 Rochester Institute of Technology