"...We're making great progress, and I love all the strides we're making. Make sure the other people on your team understand what you're doing and why.
Ensure you're communicating with each other, even if you're working on different tasks. Like we did yesterday, check in with each other periodically. If you're having a discussion, ensure everyone agrees with what's about to happen and why.
Take the time to share what you've accomplished over the last hour or so. It's important that your group understands what's going on because they are there to help you...."
https://www.instructables.com/Arduino-FFT-Visualizer-With-Addressable-LEDs/
---------------------------------------------------------------------------------------------------------------
Team Katawa- prototype basketball shooter- cardboard prototype, motor prototype
Ed reviewed design ideas with the airplane team- he suggested building an RC plane from a kit in the interest of time, plus perhaps some DIY gliders-- see for example:
From MIT Aeronautics: Basic Airplane Design Rules
If we need more later, we can have actual customizations, maybe for aesthetics or other additions to the plane. This way, it becomes more personalized and not just a standard kit. It will save time and allow them to gain more experience with the mechanical aspects. It will also make it easier to divide the work so that it's not just one person mostly taking the lead.
You have one person who decides how they want the project to proceed and another person who figures out what to type in. The designer focuses strictly on what they want it to do, while the engineer concentrates on how to make that vision happen. You can choose which role each person should play based on how you think their social interaction will go, whether it's arbitrary or well-considered. I encourage you to do this because it forces them to communicate effectively, likely resulting in faster progress as they bounce ideas off each other.
Whether it was through the suggestions of the mentors in that group or simply because it happened that way, you touched on a crucial aspect of prototyping at this stage: the difference between a "looks like" prototype and a "works like" prototype. For example, can we build something that works like a prototype? We don't care if it's just a piece of wood found in a scrap yard with a motor taped to it. What matters is that we can see it shooting balls, identify potential problems, understand the size of the thing, and determine how much material is needed and where all the parts will go.
Many teams build one of these prototypes. It's not always necessary to do both, but sometimes it's helpful to push them to consider both aspects. For instance, when making a dancing robot smarter, it's useful not only to work with the servos to make things move but also to build an entire arm out of cardboard to understand its size. Both approaches are useful and it's important to think of them as separate tasks. People often get stuck in the idea that a prototype must both look like and work like the final product, which slows down the process. By making something ugly but functional or something visually accurate but non-functional, progress can be made much faster than trying to achieve both at once...."
No comments:
Post a Comment