OpenADR: Project Goals

Rather than diving head first into this project without a plan, I’ve taken the time to outline some goals that will help guide the design of the robot vacuum’s first revision.  They’re listed below, categorized by their relative importance, along with a brief explanation of each one.

Primary

Vacuum with reasonable strength:

A robot vacuum should obviously be capable of vacuuming.  Reasonable strength is pretty relative, but my intention is that it’ll be strong enough to contend with a regular robotic vacuum.  CNET has an interesting test that they use in their robot vacuum reviews, as shown in this Neato Botvac review,  that I’d like to replicate at some point with my final product.

Obstacle detection:

The vacuum should be able to detect when it hits an obstacle.  A front bumper that can distinguish between the left and right side seems to be the industry standard, so I’ll probably do the same thing.

Works on various floor types:

Fairly simple, I’d like to be able to run the vacuum on different types of floor, such as tile, carpet, and hardwood.  Luckily all three are represented in my apartment so testing this should be easy.  Some tweaking of wheel size and floor clearance will probably be necessary to find a good balance between all types of floors.

1/2 hour runtime:

This is really just a baseline.  I’d like to be able to run the vacuum much longer than this, but a half hour seems like a good goal for a prototype.

Modular:

I think modularity is important for multiple reasons.  It’ll allow for an upgrade path by designing in the ability to upgrade vacuums without changing the navigation module, and vice-versa.  It also makes the system easier to develop by allowing design of individual modules, rather than modifying a monolithic robot.

Easy to empty:

Since I have full control over the mechanics and I’m already going to make the system modular, having a simple connection mechanism between the vacuum and navigation modules shouldn’t be difficult.

Secondary

Cleans corners:

Due to its round shape, vacuums like the Roomba aren’t able to clean corners as well as squarish vacuums like the Neato.  The upside to round vacuums is that they aren’t as likely to get stuck in corners.  The square front makes navigation and turning in corners more complex, so I will be using the round design for now.  The use of a side brush might help mitigate the corner-cleaning problem.

Obstacle avoidance:

Rather than simply detecting obstacles when they’ve been hit, this would entail some sort of rangefinding to map out the locations of obstacles so they can be avoided.

Intelligent movement algorithm:

Rather than simply moving about randomly, a more complicated movement algorithm would enable the vacuum to move about the room in a pattern maximize the amount of floor vacuumed.

WiFi connectivity:

Wireless connectivity would greatly aid in the ability to debug and control the robot.  With the ESP8266 being so cheap, WiFi is the obvious choice.

Tertiary

Room mapping:

Using a variety of sensors, room mapping would allow the robot to create an internal representation of the room it’s currently cleaning.  It could then use this map to refine its movement algorithm over time.

HEPA filter:

For starters I’ll just be using a simple mesh, but somewhere down the line I’d like to find an easily available and cheap HEPA filter that can be integrated with the vacuum for better filtering.

Adapts to floor type:

The suction requirements between hard floors and carpets are very different.  Adding sensors to detect the type of floor the vacuum is on would allow the robot to throttle down the fan speed when on hardwood or tile, saving power and increasing battery life.

Ultrathin:

Most robot vacuums are between 7cm and 10cm in height.  After doing some preliminary measurements around my apartment, I found that a few pieces of furniture had gaps around 5cm underneath of them.  To handle these situations I’d like to eventually design the robot to be below that height.

App/Web controlled:

With the Internet of Things gaining steam, control apps are being released for all sorts of appliances.  The newest Roomba and Neato robot vacuums both have phone apps allowing scheduling, statistic, and other features to be controlled remotely.  Creating a phone or web app would allow greater control of the robot and provide advanced debugging capabilities.

Wireless firmware updating:

Being able to wirelessly program and update the robot would be a huge step forward for usability and development.  The ability to push out OTA updates via the app would also allow for a more diverse group of beta testers by removing the need for manual connection and driver knowledge from the equation.

While I’m sure this list will continue to grow and evolve as the project progresses, I think there’s plenty here to work off of for the basic design.  If you have any suggestions or think I missed something, feel free to leave comments below!

Advertisements

2 thoughts on “OpenADR: Project Goals

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s