General Problem Statement
Iterative design and physical problem solving are arguably the most important parts of an engineer’s design process, but they are rarely a focus in academic settings. Team Enginyte believed that these particular components of the design process were vital in establishing a passion for STEM. Our goal was to design and build a combat robot with iterative processes. We aspired to have numerous CAD designs and models of varying fidelity with a competition-ready robot as the final result, and we met that aspiration. We hope that this demonstration of our processes alongside our completed combat bot illustrated the importance of iterative design and ignited a passion for STEM.
Stakeholder Needs
We decided to compete in the NHRL, Norwalk Havoc Robot League, which is based in Norwalk, Connecticut. After much needed discussion and research, we selected this competition because of our timeline, budget, and experience. We constructed a 30 lb. battle bot and competed in their competition which took place on April 23rd. We placed 9th out of 13 competitors.
https://www.youtube.com/watch?v=lryZVhNCwYo
Most of the NHRL safety requirements were the same as the SPARC (SPARC is the official rule guide for Battle Bots the television show) specifications for weapons, but the robot’s physical specifications were different. We decided that our battle bot will move with wheels as this is the quickest form of mobility for our weight class, and it will be the easiest to design for. We also decided that our attack system would involve a vertical spinner. The NHRL does not have any specific rules for spinners or wheels, but they do have some general rules for all 30 lb. combat bots:
- All bots must fit in a 36”x36”x36” box in a fight ready condition (may expand during the match)
- Robots are limited to a 72 V powered system
- Robots must include at least one active weapon
- Weapons which use fire or heat must be able to self light, and self extinguish- see Safety for more information on flame-based weapons
- The following weapon types are prohibited:
- Nets
- Projectiles over 150 mph
- Liquids of any kind
- Weapons which purposefully disrupt radio signals
- Strobe Lights
- Lasers
- All robots must have a weapon lock that prevents any weapons from moving outside of the cage
- All robots must have a way to turn off power without disassembling the robot
- All robots must pass a radio fail safe test
- Radio powered on first, then robot will be powered on
- Competitor will be asked to show motion and demonstrate their active weapon
- The competitor will be asked to turn their radio off
- The robot should then stop all linear motion and the weapon should begin spinning down
- The weapon should come to a complete stop within 60 seconds of the radio being powered off
Functional Goals
In order to successfully design a working battle bot, we created a general process that each component and subsystem had to achieve before assembly could begin. Guaranteeing the completion of each preparedness level before moving forward in our design helped to limit the amount of error possible in our overall build. We also defined criteria for the success of our build which allowed us to measure whether or not the result of our build was successful.
Enginyte Preparedness Marks for Combat Bot- Build
| Ready To Go | 10 | Any discrepancies to subsystem or whole system have been solved |
| Assembly | 9 | Physical component is implemented into the overall model, and functionality testing of the whole system has been completed. |
| Iterative Design | 8 | Iterations to the physical model have been made and retesting has occurred. |
| Testing | 7 | Testing of the physical model is completed. |
| Manufacturing | 6 | Manufacturing of the model is completed. |
| Iterative Design | 5 | Iterations to the theoretical model have been made and retesting has occurred. |
| Testing | 4 | Testing of the theoretical model is completed. |
| CAD | 3 | A theoretical model has been built. |
| Theoretical Modeling | 2 | Formulation of plan of attack is completed with research in mind. |
| Research | 1 | Extensive research of a specific subsystem has been conducted, and a plan of attack is ready to be formulated. |
Enginyte Success Levels for Battle Bot- Result
| Bonus | Win NHRL Tournament |
| 12 | Compete in NHRL |
| 11 | Meet all requirements for NHRL competition |
| 10 | Combat bot’s main subsystems (Mobility/ Attack) work but we did not meet the requirements to compete in the NHRL. |
| 9 | Combat bot works by remote control. |
| 8 | Combat bot’s subsystems work independently but not together. |
| 7 | Combat bot’s mobility works by remote control. |
| 6 | Combat bot’s subsystems work by wired control. |
| 5 | Combat bot’s subsystems work independently by wired control. |
| 4 | Combat bot’s mobility works by wired control. |
| 3 | Combat bot is assembled but none of the subsystems work. |
| 2 | Combat bot is assembled in CAD and should, in theory, work |
| 1 | “Yeah, building a combat robot would be cool.” |
Design Constraints, Objectives, Metrics, and Specifications
While we made many strides towards reaching our goal, defining the constraints, objectives, metrics, and specifications of most of our components was possibly the most difficult part of our design process. Since the battle bot competition and design was very open ended, we had to specify each of these along the way for all components of every different subsystem. Once our functional requirements were specified, our design process could begin. All components were then bought or designed in order to fit said requirements. More information on our final design choices for all these components can be found on our “Functional Requirements” page.
Sources: