Multi-Disciplinary Senior Design ConferenceKate Gleason College of Engineering
Rochester Institute of TechnologyRochester, New York 14623
Project Number: P09204
1 KG PAYLOAD MODULAR ROBOTIC PLATFORMNandini Vemuri
Electrical Engineer
Emily PhillipsElectrical Engineer
Jeff HoweElectrical Engineer
Jason JackComputer Engineer
Ryan SchmittComputer Engineer
John CorletoComputer Engineer
ABSTRACT
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
NOMENCLATURE
COTS - Commercial Off The ShelfDC – Direct CurrentEDGE - Engineering Design Guide and
EnvironmentEMF – Electromotive ForceGUI – Graphical User InterfacePIC - Peripheral Interface ControllerPID – Proportional Integral DerrivativePCB – Printed Circuit BoardPWM – Pulse Width ModulationRIT – Rochester Institute of TechnologyRP1 – Robotic Platform 1 kgRP10 – Robotic Platform 10 kg
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]
Proceedings of the Multi-Disciplinary Senior Design Conference Page 2
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.
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 Page 3
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.
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
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.
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
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].
Figure 3: PCB design of the 12V power distribution system.
Figure 4: Hardware Implementation of 12V power distribution on platform
Project P09204
Power Distribution Subsystem
Wireless Communication Subsystem
Graphical User Interface
Processing Subsystem
µCSerial
Communication
Bus Controller
Motor Module
H-Bridge
DC Motor
PID Controller
Bus Controller
DC Motor PWM
Output
Servo PWM Output
Encoder Input Encoder
Servo
Proceedings of the Multi-Disciplinary Senior Design Conference Page 5
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.
Proceedings of the Multi-Disciplinary Senior Design Conference Page 6
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.
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.
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
Project P09204
Proceedings of the Multi-Disciplinary Senior Design Conference Page 7
Walter, Todd Fernandez, Dr. Jay Yang, Dr. Kenneth 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/documentation/week8/Needs%20Assessment%20%28Week%208%29.pdf>.[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/documentation/Hardware%20Control%20Document.docx[5] Jack, Jason A., John Corleto. “Software Control Document.”https://edge.rit.edu/content/P09204/public/documentation/Software%20Control%20Document.docx
