OpenADR: Motion Test #2

May 18, 2016 kelliott121 Projects open hardware, open source, OpenADR, robotics

I just finished testing v0.2 of the chassis and results are great! The robot runs pretty well on hardwood/tile but it still has a little trouble on carpet. I think I may need to further increase the ground clearance but for now it’ll work well enough to start writing code!

To demo the robot’s motion I wired up an Arduino Leonardo to an L9110 motor driver to control the motors and an HC-SR04 to perform basic obstacle detection. I’m using a backup phone battery for power. The demo video is below:

Over the next couple of days I plan on wiring up the rest of the ultrasonic sensors and doing some more advanced motion control. Once that’s finished I’ll post more detailed explanations of the electronics and the source code!

OpenADR: Navigation Chassis v0.2

May 15, 2016 kelliott121 Projects 3D Printing, open hardware, open source, OpenADR, robotics

Based on the results of the first motion test, I made several tweaks to the chassis for version 0.2.

As I stated in the motion test, ground clearance was a big issue that caused problems on carpet. I don’t know the general measurements for carpet thickness, but the medium-pile carpet in my apartment was tall enough that the chassis was lifted up and the wheels couldn’t get a good purchase on the ground. This prevented the robot from moving at all. I’m hoping 7.5mm will be enough ground clearance, but I’ll find out once I do another motion test.

I added a side wall to the robot to increase stiffness. With the flexibility of PLA, the middle of the robot sagged and as a result the center dragged on the ground. Adding an extra dimension to the robot in the form of a wall helps with stiffness and prevents most sagging. My first attempt at this was in the form of an integrated side wall, allowing the entire thing to be printed in one piece. This, however, turned out to be a bad idea. With the wall in the way it was extremely difficult to get tools into the chassis to add in the vitamins (e.g. motors, casters, etc.). DFM is important! So instead of integrated walls I went for a more modular approach.

The base is much like it was before, flat and simple, but I’ve added holes for attaching the side walls as separate pieces. The side walls then have right angle bolt hole connected so the wall can be bolted on to the base after everything has been assembled.

One thing I don’t like about this method is that all of the bolt heads that will be sticking out of the bottom of the chassis. I’d like to go back at a later time and figure out how to recess the bolts so the bolt heads don’t poke though.
With the stiffness added by the side wall I decided to decrease the thickness of the chassis base and wall from 2.5mm to 2mm. This results in saved plastic and print time.
Adding the side wall had the downside of interfering with the sonar sensor. I’m not too familiar with the beam patterns of the HC-SR04 module, but I didn’t want to risk the wall causing signal loss or false positives, so I moved the distance sensors outward so the tip of the ultrasonic transducers are flush with the side wall. Unfortunately, due to the minimum detectable distance of the sensor, this means that there will be a 2cm blindspot all around the robot that will have to be dealt with. I’m unsure of how I’ll deal with this at the moment, but I’ll most likely end up using IR proximity sensors or bumper switches to detect immediate obstacles.
Other than the above changes, I mostly just tweaked the sizing and placement of certain items to optimize assembly and part fits.

This is still very much a work in progress and there are still several things I’d like to add before I start working on the actual vacuum module, but I’m happy with the progress so far on the navigation chassis and think it’ll be complete enough to work as a test platform for navigation and mapping.

OpenADR: Motion Test #1

April 20, 2016 kelliott121 Contests, Projects 3D Printing, open hardware, open source, OpenADR, robotics

This is just a quick update on the OpenADR project. Last night I hooked up the motor driver and ran a quick test with the motors hardwired to drive forward. I wanted to verify that the motors were strong enough to move the robot and also see if there were any necessary tweaks that needed to be applied to the mechanics.

Looking at the result, there are a few things I want to change. Most notably, the center of the chassis sags a lot. The center was dragging on the ground during this test and it wouldn’t even run on carpet. This is mostly due to the fact that the test chassis has no sidewalls and PLA isn’t very stiff, so there’s a great deal of flex that allows the center to touch the ground. This can be fixed by adding some small sidewalls in the next test chassis revision.

Additionally, I’m not happy with the ground clearance. This chassis has about 3.5mm of ground clearance which isn’t quite enough to let the wheels rest firmly on the ground in medium pile carpet. In light of this, I’ll be increasing the ground clearance experimentally, with my next test having 7.5mm of clearance.

OpenADR: Navigation Chassis v0.1

January 16, 2016 kelliott121 Projects 3D Printing, 3DPrinting, DIY, open hardware, open source, OpenADR, robot, robotics

After tons of design work and hours of printing, the prototype for the navigation chassis is done! This is by no means meant to be a final version, but rather will serve as a prototyping platform to start work on the electronics and software for the robot. Pictures and explanations are below!

Components

Design

Due to print bed limitations I divided the navigation unit of the robot into three main sections, two motor sections and a front section. Each of these sections was then split in half for printing. There are mounting holes on each part that allow everything to be assembled using M3 nuts and bolts.

In terms of sizing I’ve left a 150mm square at the center of the robot as well as the back quarter of the circle as free space. These should provide sufficient space for any extensions I design.

Motor Assembly

The motor assembly is the most complex part of the design, consisting of five separate parts. For the motors I decided to use the most common motor found on eBay, a generic yellow robot motor. They tend to be very cheap and easy to use. They’re attached to the motor mount using M3 nuts and bolts.

While these motors usually come with wheels, I found them to be too large and cumbersome. Smaller wheels were necessary to conserve space so I designed simple, 3D printed ones using a spoked hub and TPU filament for the tires to provide traction.

I couldn’t find any cheap encoders that I was happy with on eBay, so I decided to design my own using magnets and hall effect sensors. The magnets are generic 1/4 in. and should be easy to find. My reasoning behind using magnetic encoders instead of optical is because magnetic encoders tend to be more robust when it comes to dirty environments. I’ll go into detail about the hall effect sensor PCB I designed when I do a write-up for the electronics.

Ultrasonic Rangefinders

As seen in the top image, I have five ultrasonic rangefinders that will be used for localization and mapping. They’re mounted on either side, in the front, and 45 degrees to the left and right of the front. This will provide the robot with a full view of obstacles in front of the robot.

Color Sensor

I’m still waiting for this part in the mail, but I’ve designed space for a TCS3200 color sensor module. This will be used for determining what type of floor the vacuum is on. This color sensor uses internal photodiodes to measure the amount of reflected red, green, blue, and white light. I’m hoping that I’ll be able to use the white light magnitudinal component as a primitive proximity sensor so the robot can detect stairs.

Casters

Rather than using metal ball casters like I was originally planning, I decided on designing 3D printed rollers instead. These are the same type of casters used on the Neato robots.

Bumpers

While I have yet to design in the bumpers for the robot, I plan on using microswitches attached to two 3D printed front bumpers to detect obstacles, on bumper on the front left and one on the front right.

Improvements

There are a handful of things that I’d like to tweak to improve upon this design. The current version of the navigation unit only has 3.5mm of ground clearance. I’ll be playing with this a lot in order to strike a balance so that the cleaning module is low enough to optimally clean the floor, yet high enough so the chassis doesn’t sag and drag on the ground.

While I’m currently using five ultrasonic sensors, I’m unsure as to whether that many is needed, or if the mapping will be fine with only three. I’d like to remove any unnecessary components to cut costs.

There are a few other difficulties I noticed when assembling the navigation unit. Mounting the wheel on the motor proved a little difficult due to the size of the wheel well. Since I have some extra space I’ll probably increase the well size to make mounting the wheel easier. The same goes for the casters. Because the axle can’t be 3D printed with the chassis design, I have to find a way to mount it on the front that allows it to be put in easily but doesn’t allow it to be knocked out during use.

As always my design files are available on the Github repository. Thoughts, comments, and criticism are always welcome. I’ll be doing a lot of tweaks on the design and wiring up the electronics in the near future. I hope to do a full electronics write-up soon.

OpenADR: On Modularity

January 16, 2016 kelliott121 Projects DIY, open hardware, open source, OpenADR, robot, robotics

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

January 7, 2016 kelliott121 Projects 3D Printing, open hardware, open source, OpenADR, robot, robotics

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!

Open Autonomous Domestic Robots

January 4, 2016January 16, 2016 kelliott121 Projects 3D Printing, open hardware, open source, OpenADR, robotics

I’m the kind of person who’ll go to great lengths to avoid boring tasks, despite the fact that the work spent avoiding them greatly outweighs the work of the tasks themselves. One of the most tedious chores I can think of is vacuuming my apartment; therefore I’m willing to put in a lot of work engineering a system to do the job for me. While it would be far simpler to buy a Roomba, it doesn’t seem like it should cost hundreds of dollars for what amounts to a vacuum strapped onto some motors.

Instead, I’m going to try and accomplish something of similar function with cheap hardware. Additionally, since the current domestic robots on the market require the purchase of separate robots for each target function (vacuuming, mopping, etc.), I’m going to try and design a modular system to both cut costs and reduce the redundancy between different robots.

While my initial goal is just to get the robot to vacuum, I hope that a modular design will lend itself to greater flexibility in the future. Somewhere down the line I’d like to have swappable attachments that mop, increase bin capacity, add battery life, etc. I also think that a modular approach will assist with development by allowing incremental updates for each component.

I anticipate this being a complex project requiring custom hardware, firmware, and software, so I’ve added this as a new project on my projects page. I’ll attempt to split up the work into logical chunks and do individual write-ups for each milestone.

The code for the project is hosted on my Github under OpenADR. Because a vacuum is an appliance that every home (hopefully) has, I’m sharing my work, designs, and code as an open source project in the hopes that other people will have comments, suggestions, or be interested in helping out.

Home Maker Server

October 30, 2015October 30, 2015 kelliott121 Office, Organization, Projects 3D Printing, 3DPrinting, DIY, github, open source, Raspberry Pi

Being a generally disorganized person who works as a professional engineer, I’ve noticed that the tools I use at work have really helped me stay organized and focused. After noticing this, I’ve decided to utilize some similar tools for my personal projects to keep me organized and motivated, and also to apply a professional touch to my hobbies. The most useful tools I’ve used at work are part databases, a version control system, and an issue tracker. Since the specific tools I use at work are targeted towards large companies and therefore have expensive licenses, I’ll be using open source or free alternatives. In addition to the tools I mentioned, I’m also going to install a 3D printing server so my Printrbot is no longer tethered to my main PC and prints can be uploaded and controlled from anywhere. I’ve bought a Raspberry Pi 2 Model B specifically to handle this software and become my official home maker server. The software that I’ll be installing as well as links to installation instructions are as follows:

PartKeepr – A part database. I’m constantly losing, buying multiples, and rediscovering parts so this will help give me a clear snapshot of all of my components, allowing me to better plan out projects and determine part requirements. I used this blog post for installation instructions, but here are a few quirks I noticed when installing:

I had to copy the partkeepr folder to /var/www/html rather than /var/www since that was the default root directory for my apache server
I had to be logged in as the super user (sudo su) for the pear part of the installation or it wouldn’t work

GitHub

Github – I don’t anticipate developing closed source code in the foreseeable future so I’ll just be using Github for version control.

Trello

Trello – A simple issue tracker with a convenient web interface. There’s not a lot of advanced functionality but it should be sufficient for what I want to do. Originally I was going to use a more sophisticated issue tracker called Trac because it has integration with version control and a built-in wiki, but decided against it. It would be another service to install and host on my Raspberry Pi and the additional complexity might deter my productivity. In addition, not having a private wiki could serve as encouragement to keep my projects better documented on this blog.

Octoprint

Octoprint – A 3D printing management server. It provides network access and a web GUI for uploading prints and viewing printer status. The installation instructions I used are from their GitHub page.

DIY Smartwatch: Code Hosting

November 3, 2013September 9, 2014 kelliott121 Projects DIY, github, open source, smartwatch

While I was waiting for my board to come in, I started playing with the screen, learning about Adafruit’s library as well as designing the watch interface and visuals. I’ve created a Github repository to host all of the test programs, image files, and final code. I’m currently using a modified Adafruit GFX library and the SdFat library, but will probably strip out the code not required for my application and start using a custom display library soon.