denkbots’ cRi3D [Part 3] Robot Requirements
We used the tools discussed in Part 1 – Game Theory to determine our strategy in Part 2 – Strategy and Research for this season’s game (and game manual). Now we are ready to define our Robot Requirements.
Requirements
In engineering/business, requirements are the building blocks of a new product. A requirement is a clearly defined and measurable function of the product. When running development teams with several people in multiple locations, requirements allow everyone to have an understood path forward.
So how do we determine requirements? Requirements are derived from your and Robot Strategy, guided by your Robot Mission Statement, and bound by your CONstraints.
Don’t worry, there isn’t going to be a whole other article on constraints, because we already know all of them. Remember the game manual and all of those numbered rules, like G7, G40, R3, etc.? Each one of those clearly defined and observable rules serve as anti-functions for our robot, by explicitly explaining the things our robot can not do. For the sake of this article, we will highlight a few of the notable constraints for this game below.
- [CON.G27] A ROBOT may not transfer BOULDERS from the NEUTRAL ZONE to the opponent’s SECRET PASSAGE.
- [CON.G38] ROBOTS may not control more than one (1) BOULDER at any time.
- [CON.R3.C] The ROBOT must satisfy the following size constraints: C) ROBOT STARTING CONFIGURATION height must not exceed 54 in.
- [CON.R5] The ROBOT weight must not exceed 120 lbs.
Moving on, if we look back at Part 2, we discussed how to choose a Robot Mission Statement and defined ours as:
- [RMS] Compete for a State Championship.
Now, if we take our decision from Part 2 to “evaluate designs for a robot that can most efficiently score Boulders in the High Tower Goal” we can start defining a few simple Robot Requirements immediately. For example, we want a robot that will hurl Boulders in the High Tower Goal, so our primary Robot Requirement [RR] would be:
- [RR.04] The Robot shall be capable of scoring Boulders in the High Tower Goal.
Notice that we do not say how we are going to score Boulders, pickup/transport Boulders, or anything specific. We are just defining the high level system functionality at this point. By codifying these initial strategy decisions in Robot Requirements, we ensure that all following design decisions are made only to achieve these system functions. With this approach in mind, we can define the remaining Robot Requirements:
- [RR.01] The Robot shall be capable of traversing the Low Bar.
- [RR.02] The Robot shall be capable of collecting a Boulder.
- [RR.03] The Robot shall be capable of securely transporting a Boulder.
With our strategy clearly defined in Robot Requirements, we are ready to begin designing a robot! It is important to note: Because the team got to this point through a set of easy to understand and well defined procedures as a group, moving forward as a unified team is easy and staying focused is more manageable.
Design Elements and Prototypes
Next, we take the research we did in Part 2 and the requirements we set above, and define Design Elements. Design Elements answer the question “how will we accomplish this requirement?” At this stage of the design phase, we begin prototyping. Because this is a conceptual Robot in Three Days, we will give you some pointers on how to move forward, and then reveal our robot concept.
Drawing upon your research, personal experience, mentor expertise, and student ingenuity; come up with multiple mechanisms to achieve your robot requirements. Build prototypes quickly, but deliberately; and make sure prototypes are fair representations of the final product. Be cautious of “under-building” the prototype of a design you are not fond of and using that as justification for a different design. This can cause you to pass on ideas that might have been just a few man hours away from giving your robot the edge. Here are a few more tips when choosing mechanisms:
- Where possible, try to accomplish the most robot requirements with the fewest mechanisms possible.
- Choose the most repeatable, durable, robust solution whenever possible.
- Pick the best solution, not your solution…
This last point gets to the essence of what being a Scientist is all about; As Socrates once said “We must follow the argument wherever it leads.” Setup fair tests, build equivalent prototypes, collect the data, then do what is best for the team.
Summary
So how does this method of robot design help a team? By using an inclusive and objective process that brings in all team members to define a clear path forward, a team is much less likely to waste time arguing about the overall design of the robot or lose time due to confusion about the robot’s objective. By clearly codifying the robot objectives in well defined and measurable Robot Requirements, mentors and students are much less likely to get distracted or lose focus when designing/building subsystems to help the robot achieve those requirements. By researching existing technologies, building prototypes, and fairly testing those prototypes; The team can be confident in its decision and path forward which increases moral, expedites fabrication, and allows for creativity and inspiration to drive the creation of the team’s mechanisms and subsystems, not stress and pressure.
Hopefully these three articles can help you and your team start a new season off right. Feel free to adapt these exercises and methods to fit your team’s style. Most importantly, remember why you do this:
- “The direction in which education starts a man will determine his future in life.” Plato
- “Education is an ornament in prosperity and a refuge in adversity.” Aristotle
- “Education is the most powerful weapon which you can use to change the world.” Nelson Mandela
Please feel free to tell us what you thought on our Facebook or Twitter, and share your experiences, questions, and thoughts on these topics!
NOTE: The Reveal of our cRi3D can be found here.