I realized that in my last blog post I stated how modularity was important to the design of OpenADR, but I never actually defined my vision for what modularity means and what it would entail. Thus far I've identified this project as a robot vacuum. My ultimate goal, however lofty it may be, is to design a system of robots and extensions rather than just an autonomous vacuum. There are home robots of all kinds on the market today such as vacuums, mops, and gutter-cleaners. They're always complicated and always expensive. The thing is, I don't think they need to be.

As an engineer I look at the design of these robots and see unnecessary complexity. As a programmer I see redundancy and chances to optimize. As a Maker I see an opportunity for the community to make something better. Those thoughts were my inspiration, and the reason I decided to create this Open Source project. I wanted to make something simple and elegant with a low barrier to entry so that anyone can contribute.

To aid in this endeavor I looked at the current domestic robot market and saw the redundancy in the designs. A robot vacuum, robot mop, as well as other types of robot can really be broken up into two different parts. There's the navigation unit (e.g., the localization sensors, drive motors, encoders) and the cleaning system (e.g. vacuum, mop, waxer). Rather than buying a vacuum for each separate task and effectively paying twice for the navigation hardware I've decided to first design a navigation robot and leave a large slot in robot body to allow for various swappable extensions. The first, proof of concept extension will be the vacuum. Doing this will reduce the number of duplicated components and cut costs of the overall project. It will also save time on hardware and software design.

Another benefit of this modular system is additional ease of development. Large software projects like the Linux kernel having componentized designs, breaking the software into parts based on architecture, use case, abstraction level, etc. By having these functionally separate components, new contributors don't need to understand the entire project just to add to a small part. The barrier of entry to the project is reduced and project members can focus only on the components they're most comfortable with.

This is my ultimate goal with OpenADR. I'm most comfortable in the realms of embedded design and firmware development. I hope that by providing a strong base for the project, people who are much more proficient than I in other areas will join in to help OpenADR move forward.