robot

OpenADR: On Modularity

kelliott121 Projects , , , , ,

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.

OpenADR: Project Goals

kelliott121 Projects , , , , ,

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!

Octopod Mechanics Complete

kelliott121 Projects , , , ,

I’ve finally finished printing all of the mechanics for the Octopod!  Below is a pic of it all assembled.

2014-09-11 22.26.23

 

So the next step is to assemble the PCA9685 breakouts from Adafruit and test out some walking!  In the mean time I wanted to list a few improvements that I would make to the Mark II chassis.

  • Longer Body – If you look at the legs you can see that there isn’t much space in between them.  This means they don’t have a very large range and therefore won’t be able to take large steps.  I designed the chassis have 15 degrees between each leg, thinking that would be enough for a good range of motion, however I didn’t account for the bulky servos getting in the way.  One way to fix this problem would be to make the chassis longer, allowing for the hip servos to be spaced apart more.  I’ll have to investigate how much space I can add and still fit the body in my printer’s 6x6x6 inch build volume.
  • Add servo horn holes – The servo horns fit fairly snug in their printed holes, but tend to fall out if too much strain is applied.  I applied hot glue to better keep the servo horns in place, but a better solution might be to add holes to the 3D printed parts and bolt them into place.
  • Longer Legs – As previously stated, step size is going to be a key factor in the speed of the robot.  Another way to improve the step size would be to make the legs longer.  I also think longer legs would improve the spider aesthetic.  I’m currently unsure of the load bearing abilities of the 9g servos, so I’d like to experiment with this chassis so I can determine how much longer the legs can get without sacrificing too much torque.
  • Mounting Holes – Depending on what board(s) I end up using in the final product, I’d like to add mounting holes to firmly attach them directly to the body.

3D Printed Spider Robot

kelliott121 Projects , , , ,

Since receiving my 3D Printer, I’ve done a few test prints as well as a few upgrades for the printer itself.  Now that I feel like I’ve tweaked the print settings to a point I’m happy with, I’ve decided to go ahead with a more ambitious 3D printed project.  Enter the Octopod.  I was fascinated by the T8 and wanted to make a cheaper version.  Servo and motion control is also a huge part of the field of robotics that I have little experience with so I thought this would be a good opportunity to gain experience with these skills.  More details on this project are on the Octopod page.