Proceedings of the Multi-Disciplinary Senior Design Conference Page 5
Project Number: 13215
Copyright © 2013 Rochester Institute of Technology
Proceedings of the Multi-Disciplinary Senior Design Conference Page 5
Wandering Ambassador Technical Document
David GilletteEE - Motherboard / Matt Pendel
EE – Motherboard / Enclosure
Sagar Saxena
EE - Controller / Baabak Mamaghani
EE – Team Lead / Navigation / Anjit Rana
EE - Navigation
Armando Briones
CE – Coding / Software
Copyright © 2013 Rochester Institute of Technology
Proceedings of the Multi-Disciplinary Senior Design Conference Page 5
Abstract
The Wandering Ambassador has been a mascot for the Electrical Engineering Department at Rochester Institute of Technology. It began as a sustainability project and has been modified over the years to serve various purposes such as a plowing snow and squirting water. Over the years, the robot has become disorganized, in terms of physical appearance, documentation, code and purpose. Our task was to create a new payload mission (give the robot a new mission in life) while making it a presentable/organized project. In the end, it was decided to make the Wandering Ambassador a maze solving robot.
The Wandering Ambassador is a robotics project that has been developing over the past few years at Rochester Institute of Technology. While the purpose of the robot has changed significantly since its birth, one feature had not been s consistently failed to be implemented: autonomy. The intent of this project isis to rework the current robot's existing hardware and software to provide a robust and expandable framework on which an intelligent autonomous system can be designed and implemented. This was achieved by designing a new motherboard, reworking the navigation system, and rebuilding many software modules. Additionally, a wireless remote control was implemented as a manual override to the navigation system and software controllers.
In the end, the individual components worked very well. The remote control and the website were able to control the robot’s movements with good accuracy. The encoders and sonars were both able to measure accurate distances of travel and objects respectively. Finally, the Wandering Ambassador’s new PCB helped save a ton of space and allows for expandability.Crucial modules of the robot were modified. The motherboard was redesigned to allow new hardware modules to be connected. The software used for motion, sensor data collection, and web-based remote control was recreated to use the more efficient, interrupt-based capabilities of the underlying hardware. Additionally, a wireless remote control was integrated.
RESULTS!
NOMENCLATURE
PSoOC : Programmable System on a Chip
PSOC 5 : Cypress SoC Development Board
PandaBoard: A board with modules to stream data and other media
UART: Universal Asynchronous Receiver/Transmitter
KGCOE: Kate Gleason College Of Engineering
Javascript/JQuery: Scripting languages used in web applications for data manipulation and transmission
introduction
When the project was handed to us, we quickly realized how disorganized it was. The benches in the Senior Design Lab, the hardcopies of documents from previous teams, the previous team’s EDGE pages and the robot itself were all disorganized. The first few weeks of the Multidisciplinary Senior Design I became very frustrating because there was no idea where to start or what to look for. It was immediately decided that organization was going to be a key component of our project. As for the robot, there were many parts that were poorly done. The PCB, navigation, software and overall aesthetics stood out the most. It was decided that these would be the key things our team would focus on.
The Wandering Ambassador project is the development of a a legacy robotic system consisting of several integrated modules dedicated to gather data, process data and to navigate the real world by the use of of four wheels, two motors, and various navigation electronic peripherals. and circuit board. As the robot was handed off from group to group, the appearance and purpose of the robot changed drastically. The robot was originally intended to be a display of engineering for sustainability. The robot was tasked with the upkeep of a few living plants as well as charging its batteries using equipped solar panels. Succeeding groups chose change the direction of the project, replacing all sustainability aspects with things such as motorized snow plows, remote controlled water guns, and a streaming webcam. Regardless of the purpose, all groups attempted to incorporate, without success, a sort of autonomy to the movement and navigation systems. The project underwent a series of uses and modifications from its conception to its latest implementation. Every iteration of the robot undertook a different task and its focus ranged from being a prop at a fair to being a self-sustaining entity. The underlying goal of all past projects was the implementation of autonomy. However, none of the many attempts succeeded. A careful exploration of the limited documentation provided an explanation to this problem. Poor organization and the small amount of attention given to expandability was identified as the main problem. After sorting through the unorganized past of the Wandering Ambassador project, it came apparent that each group essentially began from scratch. Most groups designed their own motherboard and coded their own software. This resulted in a large amount of time and resources wasted relearning/redesigning all existing systems of the robot. Additionally, many body modifications (the addition or removal of new hardware, wires, and metal) to the robots frame caused the robot to become cluttered, disorganized, and, in some cases, dysfunctional.
A major objective of the Wandering Ambassador project was decided to be the organization and implementation of a sturdy and robust framework for the implementation of an autonomous task. To facilitate this rework, the robot was to be first dismantled, cleaned, and painted. In parallel, a new motherboard with features common to all previous motherboards (see motherboard section below) was designed with longevity in mind. A durable enclosure was designed to properly house and display all circuit boards used on the robot's chassis.
Adding to the objective of organization are the ideas of expandability and ease of use. The robots framework was designed to be basic. In other words, aspects of the framework will not need to be replaced or removed, only appended or enhanced. Current hardware peripherals and software modules were repurposed and made easily accessible. Additionally, all relevant documentation was gathered in a binder to be handed down to the next group of engineers assigned to the Wandering Ambassador project.
A secondary objective, reliant on the completion and proper operation of the first, was the implementation of a semi-autonomous navigation and movement system that is capable of moving the robot a certain distance forward whiling avoiding any obstacles along the way. A third and final objective was to implement a wireless remote control to bypass all control systems to move the robot for debug purposes and an easy method of movement.
The following process section describes the technical design and implementation of the new framework and autonomous process.
process
PCBMotherboard
The parts copied were, H-bridge, the two onboard 3.3V regulators, the two 5V regulators and encoder connections. The two external 5V regulators were left to be connected to the main board. A battery power meter was designed to be placed on the board. Two 12V and one 5V connections were added for LEDs and a fan. Two 40 pin connectors were added for connecting to the PSOC and several 6 pin connectors were added for connecting signals and power to future daughter boards.
The design of the board was laid out onto a 4-layer board to make for a smaller board with less chance of cross talk and better high current abilities. The components were compacted into a small area to make the board cheap and small. The main objective of the board was for expandability through daughter boards, an abundant amount of power, small design and basic robot functions. This was done so that potentially future teams do not have to have the main board rebuilt or at least they will have an easy time using the free and easy to use ExpressPCB software.
Previous motherboards contained similar circuits used to control the robot and supply power to other control boards. These few circuits were used to design a new, smaller form motherboard. The board contains a fused 12V battery input, an H-bridge block for both motors on the robot, inputs for two encoders, various 5V and 3.3V regulators, and a collection of header pins. Two 40 pin headers are included for signal routing to the PSoC board. See Ffigure 2 for a block diagram. Making the board simple and general avoids the possibility it will need to be replaced by future teams.
The motherboard was designed using ExpressSCH and laid out using ExpressPCB. For better signal shielding and a smaller form factor, a four layer board was chosen. To satisfy the objective of expandability, the board was designed to be able to interface to several daughter boards with more specific purpose and circuitry. The motherboard is capable through the 6-pin headers to supply power (5V or 3.3V) and access to signal pins on the PSoC.
Additionally, the motherboard supports supply to two external regulators (designed by a previous team) to power the PSoC and Panda Board and various two pin headers used to power the LEDs and case fan.
Navigation
The mission of the robot was determined to be a maze-solving robot, which meant that the robot would always be on level floor. This resulted in the removal of the front guard, which ultimately resulted in the removal of the IRs. One of the potential ideas for navigation was to follow a line using the IR sensors. During testing, it was observed that the IR sensor on hand could only measure the distance. It was not very sensitive with respect to different color. This ruled out the possibility of having the robot follow a black line. Since, change in elevation was not a concern for our design, the IR sensors were discarded.
The plan revolved around using the RFID system that was received from another MSD project (P13015 – Navigation Aid for Visually Impaired/Blind). When the RFID tags and reader were received, they were examined and tested. It was concluded that the RFID system from the other group was not usable. The addition of extra wires/components (which was accomplished very poorly) along with the lack of documentation made it near impossible to implement the RFID system we were given. Also, their RFID system was based on MSP430 chips, and we did not have access to the codes that they used. The older RFID system that they used (Skyetek M9) looked promising, but the missing antenna unit and the broken module rendered it unusable.
Since our budget did not allow us to purchase a new RFID system, we decided to go with our backup plan, the shaft encoders. The encoders output a voltage based on the rotation of the shaft. Using this, the wheel of the robot was correlated to the rotation of the shaft. This in turn gave the distance of the robot in terms of the shaft rotation in the encoders. The wandering ambassador would then navigate in terms of length with the sonars helping them along the way.
Figure 1: Sonar Orientation
Controller
These 4 signals from the receiver chip (RX) need to be translated to the right combination of 6 signals (INH_L, IN1_L, IN2_L, INH_R, IN1_R, IN2_R) to the H-bridge that will control the motors and move the bot.
Simplified/summarized note on working of the H-Bridge:
· First three signals control the Left Motor’s H-Bridge and remaining three control the Right Motor’s H-Bridge.
· INH_L and INH_R are enable signals for their respective motor’s H-bridges.
· IN1_L makes Left Motor turn counter-clockwise while IN2_L makes it turn clockwise or vice-versa (I’m really simplifying the H-bridge working here). Same for the Right Motor signals.
· The correct combination of CW and CCW rotations of the Left and Right Motor will make the bot move FWD, BCK, LFT or RGT. Example;
FWD: Left Motor CCW, Right Motor CW
RGT: Left Motor CCW, Right Motor CCW etc.
· Consequently, a truth table was made to implement these 6 signals;
RX Chip signals / Signals to H-BridgesLFT
pin6 / RGT
pin7 / BCK
pin10 / FWD
pin11 / Right Motor / Left Motor
INH_R / IN1_R / IN2_R / Motion / INH_L / IN1_L / IN2_L / motion
0 / 0 / 0 / 1 / 1 / 1 / 0 / CW / 1 / 0 / 1 / CCW
0 / 0 / 1 / 0 / 1 / 0 / 1 / CCW / 1 / 1 / 0 / CW
0 / 1 / 0 / 0 / 1 / 0 / 1 / CCW / 1 / 0 / 1 / CCW
1 / 0 / 0 / 0 / 1 / 1 / 0 / CW / 1 / 1 / 0 / CW
Table 1. RX Chip and H-bridge Signals
The resultant combinations of RX signals that give the appropriate H-Bridge signals are;
· FWD + LFT = IN1_R
· BCK + RGT = IN2_R
· BCK + LFT = IN1_L
· FWD + LFT = IN2_L
Note that with the above configuration, the robot can ONLY do FWD/BCK or RGT/LFT. The bot will not respond to FWD and RGT signal at the same time (Because of the current version of the truth table- if the table were to be expanded, more possibilities can be available at the cost of more hardware).
Also note that since the enable signals (INH_L and INH_R) were high all the time, the +4.5V or +5V powering the RX chip and the OR-gate chip can be used to directly feed them and keep them on all the time while using the RC controller (system level testing didn’t show any possibilities of a screw-up since the H-Bridge and motors are very, very robust- if the RX chip, OR-gate chip gets fried, they can be easily replaced)
The back-up controller makes use of an RC controller which includes a TX chip that transmits signals and a RX chip on the receiver module that receives these signals. The RC controller transmits 4 signals (FWD, BCK, RGT and LFT). These 4 signals received by the RX chip are to be translated to an appropriate combination of 6 signals (INH_L, IN1_L, IN2_L, INH_R, IN1_R, IN2_R) which are sent to the H-Bridge circuit to make the bot move.
Simplified/summarized note on working of the H-Bridge:
· INH_L, IN1_L, IN2_L control the Left Motor’s H-Bridge and INH_R, IN1_R, IN2_R control the Right Motor’s H-Bridge.