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 (REQ).
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 (RMS), and bound by your CONstraints (CON).
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 Gn, G27, Rn, 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.G16] ROBOTS may not intentionally detach or leave parts on the FIELD.
- [CON.G27] ROBOTS may not control more than one GEAR at a time.
- [CON.R03] Maximum ROBOT size, including BUMPERS and all extensions, must be constrained to one of two volumes:
- A) 36 in. by 40 in. by 24 in. tall
- B) 30 in. by 32 in. by 36 in. tall
- [CON.R04] The ROBOT weight must not exceed 120 lbs.
Moving on, if we look back at Part 2, we discussed how to choose the RMS 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 retrieve and deposit GEARS” we can start defining a few simple REQs immediately. For example, we want a robot that will deposit GEARS, so our primary REQs would be:
- [REQ.05] The Robot shall be capable of depositing GEARS at the AIRSHIP.
Notice that we do not say how we are going to score FUEL, pickup/transport FUEL, or anything specific. We are just defining the high level system functionality at this point. By codifying these initial strategy decisions in REQs, 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 REQs:
- [REQ.01] The Robot shall be capable of traversing the playing field quickly.
- [REQ.02] The Robot shall be capable of collecting a GEAR.
- [REQ.03] The Robot shall be capable of securely transporting a GEAR.
- [REQ.04] The Robot shall be capable of correctly orienting a GEAR for deposit.
With our strategy clearly defined in REQs, 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 (DE). DEs 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 REQs. Build prototypes quickly, but deliberately; 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 REQs 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.” Set up 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 morale, 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
Head on over to The Reveal of our cRi3D more fun!
Please feel free to tell us what you thought on our Facebook or Twitter, and share your experiences, questions, and thoughts on these topics!