-
Navigation Chassis v0.1
01/16/2016 at 21:50 • 0 commentsAfter 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
DesignDue 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 AssemblyThe 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 RangefindersAs 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 SensorI’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.
CastersRather 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.
BumpersWhile I have yet to design in the bumpers for the robot, I plan on usingmicroswitches 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.
-
On Modularity
01/16/2016 at 16:49 • 0 commentsI 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.
-
Project Goals
01/10/2016 at 18:03 • 0 commentsRather 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!