I used to believe in my scientific world, it is always better for me to do something not perfect (that is, having functions less than what I liked it to have) than not doing/finishing it at all. After all, making something by updating its working imperfect version, is much easier and more practical than starting from scratch.
It happens that the OP here insists to start (and finish) building a complete perfect robot (having all elite features the OP has in mind). To OP, the idea of doing anything less first is somehow a waste of time.
I totally agree with this. Whether I'm writing software, model engineering, designing and building electronics, I have found the "Agile" approach far, far better. Actually I don't advocate the full-blown Agile suite of techniques. Rather, I mean choosing a tiny bit of the final product, knocking it together, and through a tight cycle of refinement and improvement making it ever more functional and robust. Frequently it exposes an approach that cannot work, or won't scale, or is sub-optimal in some way. Starting small makes debugging so much easier. In some respects the early efforts are a kind of feasibility study, but one which morphs smoothly into and through the design and implementation stages.
Another benefit is that this highly iterative approach helps to clarify the actual requirements. Sometimes it becomes clear that what you've built this afternoon (say) isn't actually what you need, it's what you
thought you needed. So we can also fold in the requirements capture stage into the smooth flow of work. Breaking the problem into bite-sized pieces helps with modularity, which plays a crucial role in the design, development and testing stages. It makes continuous improvement of the system much easier.
The oft-quoted downside is that you often have to rework something you've already done. That is true, and is part of the philosophy, but it's better to think of it as an opportunity to improve upon your work. It's also important to remember that the traditional approach of requirements capture, design, develop, test, frequently exposes shortcomings far too late, when it costs a lot more to fix.
Both approaches have advantages and disadvantages, but if I were attempting
@artbyrobot's project I would do it the way I've described. I firmly believe his approach will fail because he thinks he can
design perfection into it, and then build it right first time. I don't believe that is remotely feasible for this project. After ten years, I'm would have a finely-tuned set of subsystems - limbs, appendages, power units, all working well and set aside ready for integration into the final system. Most people would have. Ten years is a long time, and he's still fiddle-arsing around with flimsy tin tack and superglue pulley systems which will be ripped apart the first time someone shakes hands with the robot. He needs a new approach.
Home
Help
Search
Login
Register
