Difference between revisions of "Xor/Essentials of Good Prototyping Robot"
< Xor
Jump to navigation
Jump to search
m (Xor moved page Xor/Essentials of good prototyping robot to Xor/Essentials of Good Prototyping Robot: upper cases) |
|||
| (One intermediate revision by the same user not shown) | |||
| Line 1: | Line 1: | ||
| + | {{stub}} | ||
* Maintainable: so it’s easy to change | * Maintainable: so it’s easy to change | ||
| Line 5: | Line 6: | ||
And with these attributes it will be easy to evolve, reducing the pain of climbing up the rumble. Any thoughts about those attributes? | And with these attributes it will be easy to evolve, reducing the pain of climbing up the rumble. Any thoughts about those attributes? | ||
| + | |||
| + | == Why this Article? == | ||
| + | |||
| + | I used to treat prototyping robot as personal programming project, rather than software system, where I found it much easier to implement (at first). But later I found the cost of changing it overwhelms the cost of (initially) creating it, while restarting from scratch all the time isn’t viable (as new code are often “bugful”). | ||
| + | |||
| + | Since in the long run, the majority of the costs are the costs of changing it, it’s probably cheaper to design the full system with software engineering methods and techniques. And the first step is to set the goals. And then came this article. | ||
Latest revision as of 19:30, 17 December 2017
| This article is a stub. You can help RoboWiki by expanding it. |
- Maintainable: so it’s easy to change
- Reliable: so the performance is consistent
- Effective: so you can evaluate it faster
And with these attributes it will be easy to evolve, reducing the pain of climbing up the rumble. Any thoughts about those attributes?
Why this Article?
I used to treat prototyping robot as personal programming project, rather than software system, where I found it much easier to implement (at first). But later I found the cost of changing it overwhelms the cost of (initially) creating it, while restarting from scratch all the time isn’t viable (as new code are often “bugful”).
Since in the long run, the majority of the costs are the costs of changing it, it’s probably cheaper to design the full system with software engineering methods and techniques. And the first step is to set the goals. And then came this article.
